IRC channel logs
2025-08-08.log
back to list of logs
<human_equivalent>I'm trying to add extensions to PHP, but I'm getting stuck. Can somebody give me a pointer in the right direction? I believe the package definition first needs to be updated to the newer syntax, at least if I want to use origin like that. The errors I'm getting are at the bottom. I understand what they mean but I don't know the right way to solve it. <ieure>human_equivalent, You broke all the --with-blah configure-flags. <ieure>human_equivalent, They used to be --with-blah=/gnu/store/some-hashy-stuff-blah-1.2.3/ and are now just --with-blah, so PHP likely cannot find them. <apteryx>csantosb: you need to 'grep -rl --include='*.go' tigervnc-server | xargs && make' <apteryx>to rebuild every .go referencing tigervnc-server, which has been relocated <pizzapal>hey this is a super dumb question but should i install stuff as super user, like if i'm using guix system distro and i'm the only person who really uses this machine and the packages in question are like applications and not development libraries or experimental stuff? <pizzapal>im just doing that, it seems right but also maybe its wrong because the documentation doesnt seem to say you should do that <podiki>sneek: later tell pizzapal no, don't install things as root, you really only need root (via sudo) to execute the system reconfigure command, otherwise everything should be done as your user <csantosb>Deprecating packages is documented; what about deprecating the deprecation ? See #1881. I wonder if this makes sense. <ekaitz>csantosb: what do you mean by deprecating the deprecation...? <ekaitz>what you just did there I think is fine <andreas-e>csantosb: I think so too; you just remove a deprecated package. <andreas-e>I think there is a policy somewhere that deprecated packages should remain around for a year. <andreas-e>These date from 2021, so it is good. I am applying the commit with a small change to the commit message. <csantosb>Thanks; it takes ages to compile for me ... <andreas-e>Yes, it took a long time and failed at 100%... <identity>csantosb: section ‘Package name changes’ in (info "(guix) Deprecation Policy") cites one year as the timespan for the deprecated-package to stay around after the deprecation <csantosb>identity: This is precisely what I was looking for, thank you <gabber>same (also for the help-guix archive) <apteryx>I had to look in our guix-shipped gitconfig to remember the URL of that one :-) <human_equivalent>ieure: I tried with and without changing that part, gives the same result about ungexp after adding the add-after hook <ColdSideOfPillow>For some reason, there's a really annoying behavior: suspending my system, whether by a command or by closing the laptop lid, seems to shut it down instead. <hugohugo>Installing Guix on my third machine today. It has been a long time since I was this enthousiastic about an OS <Deltafire>ColdSideOfPillow: working as intended on my HP laptop with same config you posted <Deltafire>hugohugo: you wait until the substitute servers are offline, you might be lightly less enthusiastic ;) <hugohugo>Hahaha, yeah I know Deltafire... But still, Guix empowers the users like no other operating system does. I can solve such a problem autonomously, at least in theory. With most other OS'es you'd be stuck completely if the servers are offline. Setting up my own Cuirass server is on my TODO list. <Rutherther>I wouldn't find it comforting since it's been happening for few months and no one knows the cause :( <jakef>i think i see it after pulling new commits <squid64>Is there a way to get the latest GNOME desktop on Guix System? I currently have GNOME 46 and I did a guix pull recently. And latest should be GNOME 48. <cow_2001>you know how you can add a guix package revision number when using git? "-- Procedure: git-version VERSION REVISION COMMIT" from the info file <cow_2001>how would i do it if i give guix the git version tag instead of a commit? <cow_2001>i tried using git-version, but it complained that the COMMIT field is not a commit hash <ekaitz>you could manually obtain what commit is that tag <identity>cow_2001: you just use the version tag in the version field <identity>you need git-version if you are using a specific commit that is not tagged <ekaitz>cow_2001: if you already have a version you don't need to use git-version <identity>cow_2001: no, just (package (version version) …) <cow_2001>oops, what if i want to add a revision number? <ekaitz>cow_2001: why do you want to add a revision number? <cow_2001>oh! also! another question about revision numbers - should they go back to 1 when bumping the version or should it be an ever increasing number? <ekaitz>we use revision numbers when we pin a commit instead of a version <cow_2001>ekaitz: maybe i'd want to change something in the original to adapt it into guix <cow_2001>then revisions would be appropriate, at least from how i understand revisions <cow_2001>signalling a change in the packaging, not in the original <ekaitz>that's why we have the version numbers and the hashes and all that <cow_2001>maybe adding a patch to make it aware of some bit of guixness, or fixing an important bug <ekaitz>the revisions are reserved for packages that are pinned to something that is not an official version number <ekaitz>i'm not really informed about the reasons behind that decision <ekaitz>but i'm sure some people here would be <cow_2001>so when you make a revision, you use the whole commit hash, no matter that it has a git tag <identity>manual says revisions are used for when the version number is not monotonically increasing (a git hash is not, for example) <ekaitz>cow_2001: you use the tag as a "base" but it's really using the commit <identity>when the version (x.y.z) component increases you reset the revision to 0 <ekaitz>cow_2001: look at sioyek for example. It's broken in the current release but they added some commit on top that fixes it. So we use the latest version number possible but followed by the revision and the commit, because we don't really use the exact version. <ekaitz>(also I started the revision in 1, so my bad (: ) <squid64>Alright I guess I'll keep waiting for GNOME 48 then, thanks. <cow_2001>if you're counting things it would make more sense that revision 0 is no revision to the original and revision 1 would be the first revision guix does to the same version <cow_2001>but that's just me. others would look at in a different way <squid64>Guix does seem to be behind on some packages, kinda like debian in a way. But after trying NixOS, I still prefer guix because NixOS is a mess and many things that guix aready have like guix home, you need to install from github on NixOS. <identity>cow_2001: most of Scheme (and more broadly, computing (even more broadly, mathematics)) starts counting from 0 <identity>Lua does too, depending on the implementation <nikolar>doesn't every implementatnon start from 1 <nikolar>because every library assumes starting from 1 <squid64>Only thing I found confusing in Guix was when I read the docs I learned how to add some code to my config but I didn't know where to put it exactly because I didn't see file examples, but that's most likely a skill issue on my end. <ieure>squid64, The location your config is stored doesn't actually matter and there's not one set location for it. So if the docs said "/etc/config.scm" or whatever, it would be wrong in many cases. <squid64>ieure: I don't mean which file, more like where in the file, that's what I mean. <ieure>squid64, Ah, hmm, do you have an example? <squid64>I would get "invalid field specifier" every time I would run reconfigure. <squid64>Like I tried adding to services but didn't know I had to put the code after (list <squid64>Until I learned some emacs lisp and understood what (list was for, or at least I think it works the same way in scheme. <ieure>squid64, Guile error messages really don't help here either. <squid64>would have been nice to have some common example in the docs that include the whole file so people know where it goes without having to know the language much. Like on NixOS for example I had an easier time knowing where the code goes (but NixOS lacking in documentation). <squid64>But of course knowing the language is the best. <squid64>Was just annoying to me at first as a beginner. <dv>I assume there is a way to make guix pull --commit not pull from a channel if the local channel is already at the requested commit. <Rutherther>dv: if you mean you want to update only guix and not other channels, you would create a channel file with contents from "guix describe -f channels" and use that file in <identity>squid64: ‘list’, ‘cons’, ‘car’, ‘cdr’, are all the same in most dialects of lisp, if you are unsure about anything you can always consult the Guile manual or the R^NRS standards (they are considerably smaller and less intimidating than other language standards around), R^5RS texinfo comes pre-installed and R^7RS is in the ‘r7rs-small-texinfo’ package <squid64>Alright, thanks for the info identity <RavenJoad>How can I change the nice-ness of a Guix build? I know some particularly heavy packages (Linux for instance) automatically get a higher nice-ness, but I can't find the magic to do it. <podiki>i don't think there are any niceness parts of a package definition that i ever saw <podiki>you have the very basic max-jobs control or cores <podiki>some packages we force build with only one core for reproducibility for example, but otherwise probably just whatever the e.g. makefile does <RavenJoad>Ah. Ok. I am working on my packaging of souffle and there are >4500 tests, some of which take a long time to run (>1000 seconds). I wanted to nice them just because there are so many. <podiki>you could certainly do that for your testing, but i would say in the final package to leave it unless there is some issue <podiki>sometimes a higher max quiet time has to be specified for things that take hours, but usually that's on non-x86 builds <RavenJoad>I will definitely have to modify the test time-out. There was a test that took >3000 seconds on my laptop and ctest killed it. I have to remove ctest's timeout and make Guix manage the timeout. <RavenJoad>Fortunately, ctest outputs a bunch of text, so I shouldn't need to specify quiet time. <podiki>long tests can be annoying, i feel you <podiki>is it nss where the build is quick but tests take hour(s)? there are a few like that <RavenJoad>Build is relatively fast. On my laptop it takes ~5-10 minutes, most of it spent linking. The tests take a very long time, but fortunately they are very parallel. <RavenJoad>I really want to get this upstreamed so CI can start building it (and we get a datalog interpreter/compiler in Guix as well). <RavenJoad>podiki: Mail Issue 77448, if you are interested. <RavenJoad>I have some changes sitting on a branch on my clone of GUix. <andreas-e>RavenJoad: Is there a way of somehow limiting the tests and only doing a reasonable subset? Thousands of tests that take thousands of seconds make millions of seconds... Well, I suppose that not all of them take a long time. <andreas-e>We probably should not think of the build farm as being very parallel. In practice, it uses rather, say, 4 cores per package build. Do not forget we have 30000 packages! So when building them, essentially we parallelise over the coarse grain of the packages, and keep each build almost serial. For overall running time this is clearly better. <RavenJoad>andreas-e: There are thousands of tests, but _very_ few of them take that long. There are a very small handful of long-running tests. There is a small way to limit them, but it disables roughly half of the tests, the ones that are probably more important for souffle's operation. <podiki>RavenJoad: thanks, but won't have space for that on my docket currently <fnat>I was thinking of using the rootless Podman service on a system that has nftables. I see Podman seems to require iptables though and now I wonder whether I can safely have both firewalls running in parallel... any experience with that? <ieure>pootless rodman. that is all <podiki>vorta has no images, and i see "QImage::scaleHeight: Image is a null image" in terminal, can anyone reproduce (or know the issue)? <RavenJoad>podiki: No worries. I _really_ want to close my outstanding mail-based patches before the codeberg migration, that's all. <cow_2001>after putting that into my `~/.config/guix/channels.scm` and running `guix pull`, running `guix describe` does not show my kakafarm channel <sham1>What does it show if you were to do 'guix time-machine -C your-channels.scm -- describe'. Like, it should work since you've put it into ~/.config/guix/channels.scm, but that might still be interesting to look at <sham1>Nothing about the channel file seems off to me <ieure>cow_2001, Did you `hash -r' after the `guix pull'? You may have been running the old `guix'. <sham1>It probably won't do anything different, but might as well check <ieure>cow_2001, Did you see it print "Updating channel 'kakafarm'" when you ran `guix pull'? <ieure>If not -> problem with your channels.scm; if so -> problem with the `guix describe' you're running. <cow_2001>a bit squashed because of the thin emacs buffer <ieure>cow_2001, So if you run `hash -r', does `guix describe' show what you expect? <cow_2001>ieure: no, just the regular guix channel <ieure>cow_2001, Guix System or foreign distro? <ieure>cow_2001, Okay, you're probably missing the stuff in your shell dotfiles that update $PATH. Betting if you run `which guix', it'll point to the system-installed one. <cow_2001>no, which guix shows /home/yuval/.guix-profile/bin/guix <cow_2001>ACTION raises arms up on high and start flailing in frustration <ieure>cow_2001, Of course it works, it's like a shell, it sets the PATH to the right thing for you. <cow_2001>so what is wrong with my environment variables? <andreas-e>Rutherther has found the solution. It looks like you have installed guix into your user profile, which you should not do. <andreas-e>"which guix" should return $HOME/.config/guix/current/bin/guix <Rutherther>you would also not face this problem if you evaluated search paths from ~/.config/guix/current after you evaluated the ~/.guix-profile <andreas-e>Has anybody experience with packaging Qt6 applications? <andreas-e>Could not find a package configuration file provided by "Qt6Core5Compat" <andreas-e>Which provides a file Qt6Core5CompatConfig.cmake (in a subdirectory), which the package configuration complains about not finding. <RavenJoad>Does CMake and/or Qt have an environment variable that is missing something? <andreas-e>I do not know. I could set CMAKE_MODULE_PATH (and tried to put the directory where Qt6Core5CompatConfig.cmake) resides, but this does not help. All other qt modules are found without this. <andreas-e>Hm, there are messages about other variables to set. I will give it a try then. <RavenJoad>I've had to fight Qt stuff for making packages work in the past, so there might be something there, but I have no idea. <RavenJoad>You may want to set some of the CMake and QT_* env vars which increase the amount of verbose logging happens. Maybe something is just exploring the wrong spot or something. <andreas-e>My mistake... I did not realise something was failing in a dependency and not the package itself! Sorry for the bother. <pastor_>Hello, is anyone with some experience with scheme macros in the room? <ieure>pastor_, Might try #guile, #scheme, and/or #lisp. <ieure>I haven't gotten mad enough to figure them out, I just look at them and long for CL-style unhygenic macros. <pastor_>I see, do you know if typechecking is possible? <ieure>pastor_, I don't know 100%, but I would be surprised if it was, since Lisps traditionally have dynamic type systems. Maybe in Typed Racket. <sham1>Given that guile has syntax-case, you can get all your unhygienic stuff done with that <pastor_>I'm just making some basic syntax rules but I need to check that the first element is a string to not get patterns mismatched <pastor_>Ups, I didn't meant to past everything. But well. Just the last expresion of that file <ieure>pastor_, I see. I wouldn't call this "typechecking." What if `body' is an expression which evaluates to a string, like a variable holding the value? <identity>sham1: i think the ‘CL-style’ part is more important than ‘unhygienic’ <ieure>pastor_, In whatever thing you want to have the string. "Case: message + body" I guess? <pastor_>Yes, I need to check that `msg` are strings and that `level` are integers <sham1>Well you wouldn't get the CL lambda list like &body, &aux, and such, but you could absolutely do the stuff you can do over in CL with syntax->datum and then datum->syntax with the resulting forms <identity>Scheme macros are really neat once you figure them out, but figure them out you have to; ‘JRM's Syntax-rules Primer for the Merely Eccentric’ is a good introduction <pastor_>sham1: I think that's possible with syntax-case, no? <identity>‘syntax-*’ procedures are syntax-case stuff <ieure>pastor_, Sure. So in a normal pattern matching situation, that would be a called a guard. But what I'm saying is that at the time the macro expands, if you check for a string, you limit the macro to only taking values which are strings at the time of expansion. <ieure>pastor_, So if you want to do (with-nest-logging (string-append "blah") ...), that will fail. <sham1>Yeah, so in that case you'd limit your pattern to accept string literals <ieure>That is *usually* not what you want. <sham1>Eh, for logging I could see some use with limiting yourself to string literals, but yeah, in general <sham1>Anyway, I think there are tricks with syntax-rules for you to match strings <ieure>Typechecking is a compiler feature that tells you if you if you violate assignability, I wouldn't call this typechecking, and if you go asking for that, you're unlikely to get a helpful answer. <pastor_>I didn't know, thanks for educating me <pastor_>sham1: do you know where I could learn about those? <sham1>I hang out in #scheme and some people there are quite good at this sort of macrology (I'm not one of them, heh) <pastor_>The real problem is that when I have a body with a few expresion it thinks the first one is a level. So for example this is not matching the rule I want: <bdju>I haven't pulled in 5 days and there's still no substitute for ungoogled-chromium. Is something wrong? Also is it possible that there's a substitute on a newer commit than I'm on and it'll never hit my current one for some reason? <ieure>bdju, The ungoogled-chromium build has been broken for a while. <ieure>It's also very out of date and insecure. <ieure>There was talk of removing it unless someone stepped up to maintain the package. The person who used to be doing that is no longer contributing to Guix, is my understanding. <bdju>Oh yeah, that does sound familiar... For some reason I thought the build was fixed. <ieure>I don't know for sure, I don't use it. <ieure>You can try building it locally to see. <ieure>There have also been CI issues, so, it could be either. <bdju>Oh no, that would take over 24 hours on my T440p, I have specifically been skipping it and waiting for a substitute. <ieure>I built a T440p with a quad, that sucker was scorching. <ieure>Sold it, built another. I have an even faster quad, but never installed it. <ieure>Great machine, though. Patched the BIOS to remove the WiFi allowlist and put an AX210 in. <andreas-e>ungoogled-chromium has stopped building with the core-packages merge. It is scheduled to be removed on August 18. <andreas-e>My KDE application finally built with Qt6, but it crashes upon start... <gabber>are we the distro with the 2nd most packages? after nix? <identity>gabber: i think not, but sure are up there <ieure>luca, Debian doesn't count, counting was added in a newer version than shipped in Debian stable. <Deltafire>gabber: yes, out of nix and guix, guix has the 2nd most packages <gabber>i thought there was something more advertising to it.. no? <gabber>so, what other super-cool fact can i write? i'm trying to boast in an application <gabber>and first people to read it are HR/non-techies <Deltafire>i wonder why nix has so many, far more than debian. Perhaps a load of python/node/etc packages are in there? <luca>I believe they also package a lot of non-free stuff and stuff like static web apps (for the whole reproducability and declarative config thingamajig) <luca>and of course like guix, a lot of duplicate stuff across many versions <gabber>do we have some other impressive statistics about our project size? <luca>(also a lot of packages / lines of code "in general" is not a good metric) <gabber>luca: that is not the question (: <gabber>it's about sounding impressive to non-techies <gabber>how many contributors do we have?