IRC channel logs
2024-12-11.log
back to list of logs
<homo>I actually wonder does every device in pinebook work with only free software, wifi and gpu are the biggest pain points in most laptops <dissoc> is there a way to define a service but not auto start it? i want one that depends on me manually mounting an encrypted volume and then me manually starting the service <divya>efraim: Finally found time to fix the blue-recorder patch series, take a look when you have time :) <apteryx>it seems still work correctly somehow, suggesting the fix in #26805 (exporting 'delete' from (guix build utils)) may not be necessary anymore? <s777>Is there anyone else who's on aarch64 and having trouble compiling guix when running guix home reconfigure (on a foreign distro)? <apteryx>efraim: I just stumbled on fe6b25287c5 introducing python-pydantic-2; the Python world is not equipped to face multiple versions of a same package, so this is to be done only in odd cases, unlike in rust or go <apteryx>I'll make it the current pydantic version on my wip python-team branch <apteryx>oh, python-pydantic-core is interesting as a cargo/python hybrid package <efraim>mfg: it's better to base the tree-sitter upgrade on the rust-team branch. Since it's so easy to cuase a world rebuild from rust crates I rarely make changes to master <efraim>apteryx: I think I did that one in conjunction with Sharlatan. It's also on the list this round to see about updating it to a newer version to keep it ahead of other python dependencies <basicnpc>Does the guix channel ever removed the build formula of a package with older version?!?! <basicnpc>Say now (define-public python ..) is 3.19.. when it's 3.20, do we have (define-public python-3.20)? <divya>I meant basicnpc: Indeed, that's the case. <basicnpc>That means if I don't contribute my formula to guix, it will be outdated? <basicnpc>For example, say now I have (native-inputs (python)), which points to 3.19. Later on, when the guix channel updates itself, the symbol python may point to a newer python? <divya>basicnpc: Indeed, it'll point to the version of python that's released under guix. But you can always specify a specific version if you want that. <unmush`>well, you /could/ do something like (specification->package "python@3.19"), but it would be better to look through gnu/packages/python.scm to see which variable is bound to python-3.19 (it's most likely just python-3.19) <unmush`>so (native-inputs (list ... python-3.19 ...)) <divya>yep basicnpc, exactly as such. If you've made the modules available in the scope, you can just get those symbols. <basicnpc>Will the symbol python-3.19 ever get removed? <divya>If it's a major release, nope. But as of now it doesn't exist :) <basicnpc>Yeah, that's just an example. I don't know what version is it now. <basicnpc>I mean, if I have a package say XYZ-0.9.0. <divya>Sure, the latest in guix is 3.12 <basicnpc>When the world moves to XYZ-5.9.3 .. is there a chance that the def of 0.9.0 gets removed from the channel? <divya>basicnpc: Yep, just check if it is in guix or not before using it. <divya>basicnpc: It depends, if it's required by some package, then it must be there, but 0.9 would be too old that it'll most likely be incompatible <basicnpc>... But perhaps some package that will be packaged in the future would need that. <divya>If it does, then you'll have to also package the older version of that dependency. <homo>when deleting generations using "guix gc -d", it doesn't remove old roots that I no longer use, is there a separate command to garbage collect old roots? <basicnpc>I think the channel should never remove a successfully buildable formula........ <divya>basicnpc: It probably won't, but it won't be there in the first place if something didn't need it. <divya>homo: It should, does `guix gc --list-roots` still show them? <unmush`>basicnpc: the usual approach to getting a thing-that-was-buildable-once-but-was-removed is to use inferiors to use an old version of the channel, which is what 'guix time-machine' uses <divya>homo: I just did the same, and all of my roots are removed <unmush`>where the situation could be improved is at stitching together package graphs between old versions of channels and new ones, since wanting to run an old python2 package probably shouldn't require using vulnerable cryptography libraries, for example <divya>homo: Maybe do a system reconfigure? <basicnpc>!!!!!!! WOW !!!!!!!!! After hours and hours of trying, packaging 23 packages, I finally successfully built maestral! pastebin.com/GKRhKFf8 <basicnpc>How do I know if it's usable? Any suggestions? I disable tests for almost all of them. I hope that's ok.. <divya>basicnpc: First try guix build -f [file.scm] <divya>Great, basicnpc congrats! Did you also go to the build directory and run the binary to see if that also works? <basicnpc>Ok, the binary runs. But how do I know whether it's really built successfully? <homo>I ran system reconfigure half an hour ago because I needed to build custom kernel <basicnpc>How do I know if there's some part that's not built right, which would lead to a runtime error later? <basicnpc>So.. maestral is a dropbox client. On its website, it says `python3 -m pip install --upgrade maestral` would install the cli version, while `python3 -m pip install --upgrade maestral[gui]` is going to install the gui version. <basicnpc>I'm aiming for packaging the gui version. But now the binary is only the cli version... <basicnpc>(And, hooray, the cli version indeed works ;) ) <homo>"sudo guix system delete-generations" removed all old system configurations, it appears "sudo gc -d" doesn't remove system generations <podiki>system generations are not included (i guess that is implicit rather than said explicitly) <mccd>Heya, if I want to prepend a file with a string in a gexpr, what's the best way to do so <mccd>basically I have `#$(file-append coreutils "/bin/cat")` and then I'd like to prepend it with "--passwordeval" <mccd>since it's a file-like object, string-append is not possible <mccd>and the error is wrong-type-arg "string-append" "Wrong type (expecting ~A): ~S" ("string" #f) (#f) <mfg`>has anyone used gittorrent? I just found out about it and thought this might be used to not rely as much on savannah which seems to be terribly slow atm for me <csantosb>I always wonder if having a mirror of guix somewhere else would make sense to avoid overloading savannah 🤔 <csantosb>Unrelated: any tip on building with guix pack and pushing to github registry ? <mfg`>well upon further investigation at least gittorrent seems to be an abandoned proof of concept. There is radicle though which solves the same problem. Might be worth looking into <mfg`>csantosb: not sure what tips you need ( and if i can give any...). I'd think creating a guix pack as a docker image would make it possible to simply push that docker image to any registry. <csantosb>mfg: sure, but first you'll need to load it, which means running the docker daemon, docker service and guix system <csantosb>I'd prefer to avoid all of this; just `guix pack` and push, somehow <mfg`>ahhh, but why do you need a guix system for that? <mfg`>you can load the pack pn any docker daemon, so even on a foreign distro <mfg`>it would certainly be easier to have a `guix pack --push=registry ...' tho <mfg`>but that would only make sense for the docker format i suppose <homo>well, if I understand correctly, git mirrors shouldn't be a problem as commits are signed, the user just needs to modify $XDG_CONFIG_HOME/guix/channels.scm to point to git mirror, right? <mfg`>csantosb: I don't understand. Do you mean you can't create the docker pack? <mfg`>Now i think i get what you mean. The image you are using already runs in CI, and therefore manual steps are extremely annoying <homo>using bittorrent to speed-up cloning git repositories sounds interesting, but it's strange gittorrent advertizes itself specifically as decentralization of github, which I personally don't use and instead recommend to host git repos on free software sites, as that wouldn't exclude contributors who care to run only free software <csantosb>mfg: the idea is to keep a repo with a couple of scm files; when they get updated, I push the new image to a registry <csantosb>This solves for good the problem people have with non reproducible environments <homo>I noticed gnu/system/images/pine64.scm but reading the file it's not clear for what device that image is: pinetab? pinephone? both? something else? git commits don't explain it either <homo>thanks, it appears to be impossible to have entirely free software system on recent phones and tablets :( <noe>Hi, is there a way to start some shepherd home services after my gnome session has loaded? <noe>The problem I’m facing is the syncthing home service booting up at the same time and strangling my disk io <dariqq>hmm offloading does not work currently for me: 'guix offload test' works but when trying to build something i get the "while setting up the build environment: a `*' is required to build `*', but I am a `x86_64-linux' " error <ennoausberlin>I am not sure if it is completely free regarding firmware, but I run it as a daily driver since years with libre kernel but usb dock for ethernet. <homo>if it has at least 3D acceleration, that's already a big step forward for me, my current laptop is hot even when running in pure tty because I refuse proprietary amdgpu firmware <homo>kernel driver is just a communication layer with firmware running on gpu <homo>so even though linux-libre has amdgpu driver, it's completely useless <homo>thanks, it appears there are still limitations with wifi and gpu, but even limited functionality will hopefully prevent laptop from being hot all the time <efraim>huh, libxcrypt FTBFS on powerpc-linux <homo>after building hugs package, I found a bug in its definition - it downloads extra packages, but skips installing them <Kimapr>i've found out that /etc/localtime is NOT a symlink to a file in TZDIR on my Guix System.. this seems to cause a few programs to fall back to UTC instead of my tz <dariqq_>Downgrading guile-ssh to 0.17 (updated in da3c8a963f83c044568d99921480259eaa26a923) seems to restore offloading for me it but i cant find an error anywhere. It just seems to silently ignore the offload machines? <mccd>is there a way to feed a definition, rather than a module, as input to a gexp? <mccd>if I have a function (define something (lambda (params))), can I feed that into the gexp? <graywolf>Would anyone know why we are using #:re-export for the `delete' in (guix build utils) instead of #:re-export-and-replace? <sneek>graywolf, you have 1 message! <sneek>graywolf, ArneBab says: do you have an idea *why* the REPL added a 26s delay? That seems like something to fix <graywolf>civodul: Would you happen to know why we are using #:re-export for the `delete' in (guix build utils) instead of #:re-export-and-replace? <civodul>graywolf: #:re-export-and-replace is a Guile 3.0 thing, but that code potentially runs on 2.0 during bootstrap and unit tests <graywolf>I see, that explains it. I was just trying to figure out if anything can be done about the warnings during the guix operations. Sad to hear apparently not :/ <jas>hi! i'm building shepherd on a debian machine and after installation i get a warning when running 'herd': <jas>WARNING: loading compiled file /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/shepherd/scripts/herd.go failed: <jas>In procedure load-thunk-from-memory: incompatible bytecode version <jas>it still seems to run, 'herd --help' works fine for example <graywolf>Hm, I cannot guix deploy after recent pull. What does "remote command ... failed with status 0" mean? Is not 0 usually a success return code? <graywolf>Oh this is interesting. When I revert a package change in my local tree, and do ./pre-inst-env guix build, it builds the correct reverted version. However when I do ./pre-inst-env guix deploy, it uses version of package the is currently available in my guix pull. <dariqq>graywolf: I think this is the same issue as I reported earlier today #74787 because of guile-ssh@0.18 <graywolf>Oh, so I will just revert the commit in my tree. <graywolf>Thanks for confirming, was already experimenting with that. <dariqq>reverting that fixed offloading for me , i assume guix deploy hooks into the same mechanism <janneke>civodul: i reconfigured and once again have a childhurd that i can offload to! <graywolf>Yeah, but I am trying to confirm that from the guix git before pulling it. And ./pre-inst-env guix build guile-ssh correctly builds 0.17.0, but ./pre-inst-env guix deploy still uses the 0.18.0 <graywolf>The semantics of open-remote-pipe* changed between 0.17.0 and 0.18.0 and no one adjusted the usage with the version bump. <janneke>ACTION wonders where their pandoc / ruby-pandoc system dependency comes from <janneke>there's a whole ruby/pandoc/ghc tree being pulled in from somewher.. <janneke>hmm, crytpsetup->ruby-ascidoc->ruby-pandoc->pandoc->ghc <janneke>ACTION thinks we should either cut that dependency or have a crytpsetup-minimal that we use <janneke>or maybe a ruby-asciidoc-minimal, dunno <civodul>janneke: yay! it was quite a journey to get there, thanks for going all the way down the rabbit hole! <janneke>ACTION makes a cryptsetup-minimal without ruby-ascidoctor <podiki>and master shows less substitute information (no ppcle for instance) <dariqq>hmm graywolfs patch does not fix offloading for me :( <janneke>maybe we should have -sans-doc variants of packages, dunno <ieure>janneke, I've seen several packages with "doc" outputs for the docs, that feels better than multiple packages IMO. <efraim>they still need to be built with all the inputs, including pandoc <janneke>ieure: a separate "doc" output doesn't help <janneke>ACTION pushed cryptsetup-minimal patch to core-packages-team <janneke>on the one hand, building a package without its documentation is evil imo... <ieure>Ohhh, I see. It's the inputs to build the docs. <janneke>but yeah, using a documentation system that pulls in world...equally evil? <janneke>possibly i will rename -minimal to -sans-doc, isn't that nicer? <fanquake>janneke: hopefully slightly less evil if it's packages for reproducible build containers, where you're trying to minimise the boosttrap & required deps <fanquake>anytime docs are involved, it's always a bit of a blow out <vagrantc>linux-libre 6.11.11 fails to build on aarch64-linux ... looks like some bugs were backported, as the previous version built fine ... some platform specific failures <vagrantc>(unless linux-libre patches broke something?) <janneke>fanquake: yeah--it's more that i'd like for upstream authors to take gain some knowledge and show some responsibility for the dependencies they pull in <janneke>ACTION knows the world cannot be changed... <janneke>efraim: the gcc.sh wrapper trick that we use for gcc-final is also necessary for gcc-11 (and probably all other gcc versions)... <janneke>i found out through a libgccjit[-11] dependency for emacs that didn't build. i've changed libgccjit to -14...but we probably want all gcc versions to build <janneke>ACTION is not looking at this kind of world rebuild atm, tho <x8dcc>Hello, I am trying to use 'xbacklight' on a Guix system, but it keeps saying "No outputs have backlight property", even when ran as root. Does anyone have an idea on what should be causing this? Does it need to be a privileged program, or something? <x8dcc>I installed it using 'guix install ...', not from my 'system.scm' file. <umanwizard>Hi all. How can I see why a particular manifest causes a particular package to be built? I.e. I'd like a command where I give a path to a manifest file and the name of a package and output (e.g. 'glibc:static', and it shows me the path of dependencies from some package in that manifest to 'glibc:static'. <umanwizard>Is this or something like it possible with some guix graph incantation? <Rutherther>umanwizard: sure should be possible. But probably not a simple command. One way could be to first make it into a profile, ie. "(use-modules (guix profiles)) (profile (content <the manifest goes here>))". Then you can guix build with -d to get the derivation path, and afterwards guix graph --type=derivation on the derivation path you get. <Rutherther>if you don't want for the derivation itself, but for built profiles, use guix build without -d, and then guix graph --type=references <Rutherther>alternative way of building the profile is to guix shell, then in the shell you have $GUIX_ENVIRONMENT variable that points to the built profile <Rutherther>so one simple bash command would be "guix graph --type=references "$(guix shell -m a.scm -- bash -c 'echo $GUIX_ENVIRONMENT')"", sorry it took so long had to collect all my thoughts :) <Rutherther>then you should still be able to use --path if you give it another store path you are interested in <umanwizard>in the time it took you to come up with the simple command I had already generated the .dot file that gave me the information I needed :) <vagrantc>submitted bug regarding the linux-libre build failures on aarch64 ... <fanquake>janneke: completely agree with that sentiment <ajarara>hi, I don't think I'm understanding something about guix shell: if I do `guix shell -C haunt`, I get a shell with haunt in the path, but I don't have the GUILE_LOAD_PATH set (which I want for development). cd "$(guix build haunt)" shows me that they're there in share, just not exported as what's in bin (which is). How do I get both exported (so that my repl picks up on GUILE_LOAD_PATH, and my compile picks up on $PATH)? <ajarara>I don't want to develop _on_ haunt which is what guix shell -C -D haunt gets me, GUILE_LOAD_PATH is set with commonmark (a haunt dependency). <ajarara>or is there only one env update per output and because the package stuffs everything into one output it just picks PATH? <Rutherther>ajarara: that is not actually related to shells directly, but to profiles. You can come to same problem with installing packages. You need to make sure to get the package that provides the search path itself. In this case it's guile. So "guix shell -C haunt guile" <ajarara>ah I read that part about python in the manual but it didn't click. That got it. Thanks! <ajarara>(the manual says you need to explicitly declare python to get the python path updates, I just glossed over it for whatever reason lol) <ajarara>oh so adding texinfo has the INFOPATH set because it defines the search path spec. Manuals, who knew. <dariqq>vagrantc: The line drivers/clk/meson/gxbb.c:2057:40 is correct in the upstream source (clk_init_data vs clk_init_da|a) , maybe a problem with the linux-libre scripts? <Rutherther>janneke: btw your gdb 15.2 with support for hurd broke gdbs with explicit targets. Since all of them assumed there is no argument configure-flags, so they just appended original flags, but the update commit added configure flags always, and since it comes later it was preferred. Working on a fix using substitute-keyword-arguments <Rutherther>if I am editing multiple packages, but basically same change for all of them, should I make commit per package? <janneke>Rutherther: if it's all gdb*, i would go for just one commit <reedm>I'm having trouble getting docker to work in a "guix system vm" via the docker-service-type. I'm running into issues that seem to be related to overlay filesystem not being supported. Has anyone run into this befeore? <Rutherther>janneke: and what about the commit name? "gnu: gdb:" or just "gnu:"? <janneke>if it's all gdb-* i would use gnu: gdb <Rutherther>one of them is the other way round avr-gdb, but I hope that doesn't matter :D <dariqq>vagrantc: but I checked our x86_64 linux-libre tarball and that also looks fine at that position. Not sure what is going on? <dariqq>I dont have an aarch64 machine to verify what the computed-origin build on aarch64 looks like <Rutherther>janneke: submitted as #74798. While we are at it, anyone know why the arm-none-eabi gdb is using mlambda while gdb-multiarch and avr-gdb are just plain packages? <janneke>Rutherther: there was a circular dependency in avr-gdb otherwise, iirc <Rutherther>janneke: like if avr-gdb was using mlambda there was a circular dependency? <janneke>Rutherther: no, if it wasn't there would be one <Rutherther>but there isn't one. It's there for gdb-arm-none-eabi <Rutherther>also the circular dependency would cause trouble right on evaluation, no? because I've just tried removing the mlambda and it was fine to build it <janneke>Rutherther: i cannot find anything in the history...so yeah, dunno <janneke>i must have misremembered/made something up... <vagrantc>dariqq: it is only code that is built on arm based systems <dariqq>vagrantc: i am talking about the deblobbing part because afaik that runs the deblob scripts on each arch seperately and repacks the source . When i look at 'guix build -S linux-libre' i get the source built for x86-64 where the source file that has the error for you looks normal <basicnpc>Hello! I'm packaging python-pyqt6, and I think there's a bug in its native input "python-sip", where the method .items() is applied to a list, resulting to an runtime error. <basicnpc>How should I fix this issue? I tried #'substitute* before the 'build phase, but that only works for files in the repo of pyqt6, not python-sip. <podiki>basicnpc: maybe check about updating python-sip? i see it can be updated and has < 100 dependents. or check on python-team branch first actually <basicnpc>I'm looking at its latest version on github, the code has that "bug" too. <podiki>(you could modify the python-sip package then to fix this bug, with a comment pointing to the upstream issue to track) <basicnpc>I'm still tracing back what config_settings is at runtime.. but I don't know how to do that efficiently. <podiki>also, is python-pyqt6 not the same as python-pyqt (version 6.7.1 currently in guix) <basicnpc>I tried that but the package I actually want complains not finding it. <basicnpc>(Thanks for looking it up for me though!) <dariqq>great. the default guix now also build without the offloading support <basicnpc>In any case, is there any way I can 'interfere' with the build procedure? <basicnpc>I want to know what value a symbol has at runtime, before it fails. <basicnpc>(I'm too used to developing in common lisp :/ ) <ieure>basicnpc, Probably easiest thing is to use `guix build -K', then poke around the build environment. <ieure>basicnpc, You can add a print of config_settings near where it's failing and run the build command(s) manually. <basicnpc>I'd love to print config_settings, but I don't know how to modify the code.. <ieure>Build it, let it fail, donk around by hand in the directory it left behind. <basicnpc>That buggy line is in a native-input, not the one kept in the keep-failed directory. <basicnpc>You mean build it manually, without guix? <ieure>Use the Guix tooling to give you the build environment, which you then manually mess around in. <basicnpc>But I can't change the code in a native input.. It is in /gnu/store/hashhash-dep-xyz already, and I can't (shouldn't) change it. <ieure>Though this is kind of an annoying problem, if I'm understanding... python-sip is a thing which itself builds fine, but when used in another packages build process, makes it fail? <basicnpc>It has a function that assumes its 1st param is either None or a dictionary. <janneke>ACTION 's been trying for over an hour to get /any/ version or python-numpy to build...terrible <ieure>basicnpc, Well, the hard way is to make a new package which inherits from python-sip, with a (substitute* ) form that adds debugging, then use that instead of the "real" python-sip in your package's inputs. <ieure>basicnpc, But something in your project is calling into this thing, yeah? So I'd think you have leverage to see what it's passing around without needing to mess with python-sip. <basicnpc>janneke I spent more than 30 hours on a single pacakge :D yesterday <basicnpc>I'm packaging pyqt6, and its build process did that, yes. <ieure>basicnpc, Yeah. Unfortunately, I have no idea how Python builds work anymore, because they looked at that "There should be one-- and preferably only one --obvious way to do it" thing and laughed before coming up with the current system. <ieure>I legitimately like Python as a language, but the build tooling is incomprehensible now. <basicnpc>Or perhaps I can break the read-only assumption (dangerously)? <basicnpc>And manully change /gnu/store/hashhash-python-sip directly..? <Rutherther>no, definitely shouldn't touch the store manually <basicnpc>Perhaps that's a metaphor learned from actual guix experience. <ieure>It's not that, it's just that you'd be violating a very fundamental invariant of the system. <ieure>basicnpc, It might be useful to use `guix shell' to build your thing the normal way and compare that to the guix build. <basicnpc>I'm trying to read the source for python-pyqt. <Rutherther>why don't you use guix search and clone guix to browse it? <ieure>basicnpc, It's been down a while, not sure what the deal is. `guix show python-pyqt' will tell you the location of the package in the source tree (which is in ~/.cache/guix/checkouts). Or `guix edit python-pyqt' will open it in an editor. <vagrantc>dariqq: ah, you mean the source file is unmodified between linux and the linux-libre tarball? <dariqq>vagrantc: I think the root of your error is the first line in your error message where a t is replaced with a | in "struct clk_init_data" in drivers/clk/meson/gxbb.c:2057:40. However I don't know where that comes from. I downloaded both the linux-6.11.11 tarball from kernel.org and the deblobbed one (guix build -S linux-libre) and in both of these the file looked normal <dariqq>the only difference i can think of is that something goes wrong during deblobbing on aarch64 but I cant test that. Can you check your tarball ? maybe it goes away if you redo the deblobbing? <vagrantc>looks fine in an extracted source tarball here as well <vagrantc>uncompressing the original linux tarball ... xz: (stdin): Compressed data is corrupt ... <basicnpc>In guile scheme, how do I make a temp folder, and returns its path as a string? <basicnpc>(I need to resolve this for packaging, as the build formula complains that the home dir exists not. <vagrantc>guix gc'ed the tarballs and trying again <basicnpc>Why doesn't (use-modules (ice-9 popen)) in my-package.scm gives `open-pipe*` during `guix build..`? <basicnpc>(I'm still trying to make a temp folder, and return its path as a string in the build file...) <ieure>basicnpc, Any modules your build gexp needs have to be in a list after the #:modules key in the package's arguments. <ieure>The bzip2 package has an example, certainly many others in Guix. <basicnpc>This.. is a bit worrying. That means if (ice-9 popen) is upgraded in the future, my build formula may break/change.. right? <ieure>Uh, sure. If anything your package uses breaks backwards compatibility, it'll have to get updated. <ieure>The chances of it being (ice-9 popen) are very small. <ieure>I would say Don't Worry About It (DWAI) <basicnpc>Yeah, but that means the build formula is still not very declarative. <basicnpc>It was made more declarative by requiring the sha256 of the source code. <basicnpc>But it has other symbols pointing to things whose content ain't fixed. <ieure>Right, if it pointed only at fixed versions of things, it'd be impossible to maintain packages. <ieure>Where "impossible" means "possible in theory, but so difficult in practice that the system would fall apart." <basicnpc>Btw, after I added `#:modules ((ice-9 popen))`, it complains that pyproject-build is unbound variable. <ieure>What's pyproject-build? Should that be pyproject-build-system? <basicnpc>I don't know.. I search the symbol pyproject-build in my file, but there's only pyproject-build-system. <ieure>Not sure, can you paste your package definition? Or is this in a repo I can clone? <basicnpc>The problem goes away after I remove that #:modules thing. <ieure>basicnpc, Okay, I think I led you down the wrong path. The modules stuff isn't an area I know super well, maybe someone else can chime in. Manual section (guix) Build Utilities may also be relevant. <basicnpc>Haha, it's just creating a temp folder, which got me stuck for almost an hour :-/ <basicnpc>I tried adding (guix build-system pyproject) into the #:modules list, but then it says it cannot find the code for that module. <janneke>ACTION gets numpy 1,26.4 to build somewhat..but now tests fail <basicnpc>Problem fixed. Turns out that I just have to set /tmp/ as the HOME folder.. as it's run in a separate container, so I don't need to worry any pollution. <basicnpc>WOW! After 3 days, I have finally built maestral_qt :-) It's my first 'successful' package! <basicnpc>(I packaged around 25 packages along the way. ) <basicnpc>Should I worry making them into guix channel? <basicnpc>Or should I use the binary for a while, make sure that it's working well and stably, and then think about the next move? <ieure>Definitely use it for a while. <ieure>The nice thing about Guix is that it's much easier to run a personal Guix channel than it is, say, an apt repo. <basicnpc>I disabled all tests (#:tests #f) for most of the packages build definition. <ieure>basicnpc, Generally, packages should run their tests. <basicnpc>ieure - I think of the guix channel, but my build formula may break in the future, as it's pointing to symbols defined in the current guix channel. <ieure>You'd certainly get feedback about it if you submitted patches where none of the package run tests. <ieure>And it's expected that if you don't run tests, there's a comment explaining why. <basicnpc>So if I want it to long-live, I should make my effort into the guix channel, right? <basicnpc>Nicety is that my build formula would be more stable. <basicnpc>If it only stays in my channel, then I have to maintain it, update it when guix channel updates. Right? <ieure>Well, it's a blessing/curse situation. The blessing is that others might update your package. The curse is also that others might update your package. <ieure>basicnpc, Probably a safe assumption that if it's not in Guix already, nobody has been motivated enough to package it, and you, being the one who care, will bear most of that burden. <ieure>Which ends up being more work, because you have to manage the Guix patch process. <basicnpc>ieure Do you mean if I made it into guix channel, <basicnpc>and when guix updates (resulting in a need of updating my definition) <basicnpc>then I'd probably be the one in charge..? <basicnpc>And if I don't make that effort in the future, they may remove my definition anyways. <ieure>I think packages are infrequently removed, but I suppose that's a possibility. <basicnpc>How often would guix update? (I know for most updates, I don't have to change.) <ieure>basicnpc, The bounds of your problem aren't "how often does Guix update," but "how often do any of the packages in the input graph of mine update." <ieure>Example, I started packaging CDE, the 1990s Unix GUI, which is now Free Software. It needs Korn Shell (ksh). The oksh package got upgraded, and the binary name changed from ksh to oksh. So I had to fix my package. <ieure>The CDE package is incomplete and broken, it's just in my personal channel. I hope to get it 100% working some day. <ieure>It builds and installs, but doesn't run properly. <Kolev>ieure, nice work! CDE's insecure, but still nice. <ieure>Kolev, Yeah, I'm sure it's inadvisable to run in a variety of ways, but it is also objectively Awesome and I'd love to mess around with it again. <ieure>Too bad OPEN LOOK and OpenWindows didn't get open-sourced, I always liked the look of those. Used to run olwm in the 90s. <civodul>ieure: woow, CDE the thing from Sun? <civodul>well maybe not from Sun, but definitely preinstalled on Solaris back in the day <ieure>civodul, It was released under the LGPL in 2012. <civodul>ACTION started working on replacing rottlog-service-type with Shepherd’s log-rotation <eikcaz>Is there a way to force a build of a package already in the store? <civodul>eikcaz: “guix build PACKAGE --check --no-grafts” <civodul>but it’s usually useless, unless the build process is non-deterministic