<bjc>i tried guile-emacs a couple weeks ago and it wouldn't build. didn't dig into it past that <bjc>i was a bit disappointed, though. isn't one of the major goals of guix to make sure stuff like that doesn't happen? completely reproducible builds <bjc>or is it just that someone checked in a broken build, and one of the past ones would work if i bothered to spend the time to unearth it? <vagrantc>more likely something broke in guile-emacs's dependencies, and nobody noticed <vagrantc>reproducible builds presumes you have a working build in the first place :) <bjc>i assume it wouldn't have gone into the channel if it never built <vagrantc>it shouldn't, sure. but say working guile-emacs gets committed, and then some random guile package it depends on gets changed to an incompatible new version ... guile-emacs fails to build <bjc>i thought that kind of stuff wasn't supposed to happen. the dependencies are pinned <bjc>you'd have to update guile-emacs to use the newer dependency, then check that in <vagrantc>now, if you used the same commit that the original working guile-emacs used with guix time-machine, you should still be able to build the working version <vagrantc>bjc: the dependencies of a *built* object are pinned, but not "how to build package X" <rekado>guile-emacs hasn’t built in a long time, unfortunately <bjc>so, if i have a package foo, which depends on bar, i can get a build of foo on day 1, but on day 2 bar updates, now my build of foo breaks? <bjc>what's the point of it all then? <vagrantc>bjc: you can use guix time-machine to go back and build the same build from day 1 ... or use the package from an old profile <bjc>this is honestly pretty crushing news. maybe i'm missing something, but if dependencies aren't pinned by default, i don't get what the big deal about these systems is <bjc>honestly, you shouldn't have the ability to have floating dependency versions, at all, i think <vagrantc>the dependencies for the binaries are pinned, so you can have packageA depend on fooA, and packageB depend on fooB and coexist on the same installation <bjc>to create those binaries you have to build with specific dependency versions, though <vagrantc>which you can get by building from the same commit <bjc>right, i figured that <singpolyma>I'll admit I was shocked when I learned it's normal in guix main to edit the package definitions to represent newer versions and keep the variable name the same <bjc>i'm trying to mull over what this means to my use <vagrantc>each commit to guix is essentially an entire defintion of a distro at a specific point... all the available packages, package relationships, etc. are all essentially frozen to that commit <bjc>time machine may be acceptable. i'll have to read about it. i'm (obviously) very new to all this <bjc>i understand the guix repository concept. but that's orthogonal to dependency pinning <vagrantc>some commits in guix have more significant overlap that others, and might be able to produce the same binaries <bjc>well, explicit dependency pinning in the build manifest i should say, not in terms of outputs <vagrantc>there are multiple versions of some packages, and packages can depend on one of those <singpolyma>You can include the while package tree in your manifest if you want, that would pin it <bjc>i assume you *can* pin dependencies in your package manifests, but they just float by default? <yewscion>`wrap-program`, but it doesn't say anything about setting environment variables, only that the script should live in the `textmf` tree and a different script needs to call it. Should I just make a `plain-file`, or is there another mechanism for this case? <bjc>i'm still not sure how i feel about this, but i confess it may not matter as much as i think it does <vagrantc>bjc: and it is, of course, a bug for something not to build, but it takes someone to fix the build failures <vagrantc>guix will rebuild a package whenever it's dependencies change <bjc>on more mundane matters: is there a function somewhere that'll create a file-like-object from a git checkout+path? <bjc>it'd be nice to pull dotfiles or whatever from git for home usage <vagrantc>there is guix home for that sort of thing, haven't used it much myself <bjc>i intend to use it in guix home, if possible <bjc>but i suspect it'd be more generally useful <bjc>i suppose i could make a package for it, but that seems pretty heavyweight <singpolyma>Any source can be used many places a package can (such as in inputs) so depending on your context may not need to write a while package" ***rekado_ is now known as rekado
***iyzsong-www is now known as iyzsong-w
<PrincessCelestia>is there a list somewhere of like all of the various use-modules forms and their associated packages? <bjc>i've yet to find one. it would be very useful, though <bjc>oh, for that stuff you can use ‘guix package --show=openjdk’ <bjc>it'll show it lives in ‘gnu/packages/java.scm’, which is your module path <bjc>as for why it's not compiling, there may be other machinery necessary <bjc>for instance, it looks like the packages have version numbers in the names? i'm seeing: define-public openjdk17 <bjc>you can always use ‘guix package edit $package’ to have a look at the source for it ***jackhill is now known as jackhill[m]
***jackhill[m] is now known as jackhill
<awb99_>Is it a good idea to move all the package definitions of my user profile inside guix home definition? It seems guix home does not have options to show installed version numbers or to upgrade packages. Om the other hand this would make it easier as by using guix home for packages I dont have to keep config for system user and home. <AIM[m]>How do I create a wifi hotspot from guix? <AIM[m]>Idky I tried to create access point in nmtui ***roptat is now known as Guest8410
<attila_lendvai>i keep seeing "error: failed to compile 'guix/build/clojure-build-system.scm'" and then it goes away after a make clean-go or something along the lines... am i the only one? <attila_lendvai>the actual error is: guix/build/compile.scm:194:22: In procedure cdr: Wrong type argument in position 1 (expecting pair): #f <allana>Hi #guix! Is there a way to chain multiple guix commands that follow "guix time-machine"? I have tried "guix time-machine -- build something", and that works, but how does one pass multiple commands to time-machine? <rekado>allana: there’s no support for that. But “guix time-machine” caches the requested Guix, so subsequent invocations should be faster. <abrenon>how about shell itself ? Wouldn't it open a prompt at the right version of guix, where the build and other commands could be issued and would see only that particular version of guix ? <rekado>I don’t think that’s how it works. <rekado>guix/scripts/time-machine.scm only executes bin/guix from the given channels <tschilptschilp23>AIM: I've only tried for GNOME -- here I can basically go graphically via Network-Settings -> Wifi -> three dots in window top right -> enable Accesspoint. There one has to set the pw and then even an QR-Code for mobile devices gets displayed!!! *tschilptschilp23 feels like in futureland now <tschilptschilp23>interesting, for my android I actually have to use the QR to let it connect flawlessly <tschilptschilp23>on the downside, the hotspot does not seem to list connected devices there <attila_lendvai>if you were to add a with-syntax* to guix, where would you put it? <allana>Hey #guix, anyone know of a way to provide a name for a bundle packaged by "guix pack"? For example, when I create a guix pack -f docker and the resulting image has a name like python-python-something-python-something-python-something <civodul>allana: hi! currently you can't choose the name for Docker images <civodul>it'd be nice to make it configurable *attila_lendvai is also not aware of any downsides of building everything from git, especially when upstream properly tags the repo <abrenon>I don't know who would be the most qualified to review it but thanks for the link <abrenon>it's a very interesting issue, I didn't know we had this problem in haskell-build-system, thanks for fixing it <munksgaard>abrenon: You're welcome! My pursuits are entirely selfish, since that fix is necessary to build Futhark, a programming language I am working on (along with others). <munksgaard>abrenon: I'm not 100% sure that patch is the best way to fix it, but it seems to work for building Futhark. ***piyo`` is now known as piyo
<jackhill>xelxebar: `guix refresh -l patchelf` says that changing patchelf would cuase 1799 rebuilds, so it should probably be done in the separate 'core-updates' branch. I haven't checked to see if it's already being worked on there. <jackhill>xelxebar: on darn :(. Anyway, if you're up to it, I encourage youto submit an update (and feel free to ask here if you have questions) <jackhill>the usual answer to why things haven't been updated is just no one's gotten around to doing it yet. Fetching from git should be fine. <xelxebar>jackhill: Ah. That's a good sanity check. Thanks. It's mildly curious that the package explicitly sets release-monitoring-url to the github repo but fetches sources from nixos.org. <jackhill>yeah, I wouldn't have thought there were so many dependents until I checked :) <xelxebar>Anyway, I have half a mind to try tackling the patchelf bug first. <abrenon>munksgaard: I'll try and test it but I'm a bit busy at the moment <abrenon>do you know of other haskell packages having multiple internal libs ? <abrenon>it wouldn't hurt to test on them too ***Xenguy__ is now known as Xenguy
<aadcg>when running ./pre-inst-env, I get: guix build: error: gcry_md_hash_buffer: Function not implemented. any idea? <munksgaard>abrenon: Good point. Not off the top of my head, but let me look around a bit. <munksgaard>abrenon: `raaz` has multiple internal libs, but the importer doesn't seem to be able to handle it. <civodul>aartaka: hi! this may be a setup issue with guile-gcrypt <civodul>er, how did you install guile-gcrypt? <munksgaard>abrenon: It seems like the hackage importer doesn't support `elif` in the cabal file <Kalq[m]>so how will the package update work? emacs will be 28.1 and emacs-next will be 29? <podiki[m]>I actually use flatwhatson's channel for emacs, but looks like that should converge <podiki[m]>not sure what the status is of libgccjit exactly as that channel has some tweaks to that for emacs <abrenon>munksgaard: cool ! I didn't even hope we'd find other unhandled case that way ! I promise I'll test in a couple days when I have more time <awb99>I bought a new usb based wifi card, which I suppose will work with guix. Now I have to add the driver. Can anyone tell me how I can detect the chipset of the card, and where to find information how to add the wifi dirver to it. <tschilptschilp23>I just found something strange when running ~guix system list-generations~. Some of the listed generations don't list channel and commit information. Even more confusing is, that guix system describe tells me I'm on Generation 45 (with no commit listed), which should feature Kernel 5.16.15, while uname -a tells me it's 5.16.18. And the last Generation 44 matches what I see, and also matches the commit 9bd4ed which is shown by guix <tschilptschilp23>describe. I guess I messed something up, and am quite lucky to be on a functional system. Any ideas on that? <yewscion>Hey all, I have a question about convention. The software I am trying to package needs a script that calls the binary package (sort of like a wrapper, but without setting any variables) to be installed in a bin directory, but doesn't package such a script with their source. What is the canonical way to do something like that in Guix? <tschilptschilp23>mhm. I now switched back to system generation 44, deleted the other generations and reconfigured and am on a proper 45 where commit is shown and aligned with what I expected. And my system still boots. Along this journey I (re-)learned that there's ~guix describe~, ~guix home describe~, ~guix system describe~, all with their own versioning. But no ~guix package describe~ ;) <vldn>.guix-profile symlink links to the right position? <tschilptschilp23>I'm not really sure what the right position would be, I pretty much rely on home for that. But as there's now no other generations of anything left after this massacre, I guess so... <vldn>symlinks from $HOME/.guix-profile to /var/guix/profiles/per-user/USERNAME/guix-profile <vldn>maybe to a ls -a $HOME to check.. <vldn>didn't read the things you wrote before sorry, just here right 2 minutes or so :D <vldn>just guessing the problem <tschilptschilp23>I think it's fine now, it symlinks to the newest thing in ~/var/guix/[...]~ now, and all the mentioned describe commands point to the same commit. Thanks for pointing at that place! <tschilptschilp23>yes, I think I found the culprit. As I just learned, there's ~guix pull --list-generations~ as well. There where still a few confusing files left in ~/var/guix/profiles/[...], now things look consistant. ***sneek_ is now known as sneek
<atka>tschilptschilp23: I had an interesting guix update the other day that left me unable to list system generations or roll-back/switch-generations, I have no idea what I did to get to that state. I had to garbage collect everything but the current generation before everything got back to "normal" <atka>what files did you find "confusing" <lilyp>yewscion: if it's just a simple wrapper, you can write those on your own <lilyp>call-with-output-port is your friend <lilyp>if it's a 300 line bash script OTOH good look finding that <yewscion>lilyp: In the monolithic `texlive` package, the contents of the file used are 2 lines long. So it shouldn't be too much to put in the package def, if that's the way to go. <yewscion>Would I just dump the contents in a text file and then run `(chmod file)` before installing? <tschilptschilp23>Mainly confusing, because I hardly ever had a look at the place vldn mentioned before. As I understand it now Generation N as returned by ~guix home describe~ should reflect N in the guix-home-N-link file which the guix-home file links to. Generation N as marked active returned by ~guix pull --list-generations~ should map to the current-guix-N-link file which the current-guix file links to. Generation N as marked active by ~guix package <tschilptschilp23>--list-generations~ should reflect N in the guix-profile-N-link file which the guix-profile file links to. This is all in ~/var/guix/profiles/per-user/$USER/~. And the Generation K, which is marked active as anwer to ~guix system describe~ should be the K in the system-K-link file, which the system file is linked to in ~/var/guix/profiles~. And all these files containing N or K link to corresponding files in ~/gnu/store~. Puh, I hope <atka>tschilptschilp23: thanks for your breakdown, I think it has given me some insight into what went wrong on my system *tschilptschilp23 will be more cautious with --switch-generation in the future <tschilptschilp23>atka: I think here it got started with moving my home-directory to another drive and having selfmade-technical troubles mounting the new one... <atka>I think mine happened from playing around with guix home and restrictive permissions, umask 077 <tschilptschilp23>I also don't have anything to switch to anymore now, but I'm very happy with commit 9bd4ed3dde <meena>so, `guix package -u` reports: guix package: warning: package 'glibc-utf8-locales' no longer exists ***mark_ is now known as mjw
<meena>however, `guix package -r glibc-utf8-locales` says: guix package: error: package ' glibc-utf8-locales' not found in profile <apteryx>meena: hmm, interesting. Does 'guix package --export-manifest > your-manifest.scm' print the same error? <apteryx>then perhaps you can remove the "glibc-utf8-locales" entry from that file <apteryx>and update your profile with 'guix package -m your-manifest.scm' <rekado>apteryx: did you have a chance to try PXE booting into the installer image on node 129? <apteryx>not yet (I've been consumed by some truly deep rabbit hole -- polyglossia) <apteryx>meena: you're welcome (though I wonder if something could be made to smooth the bump on the road...) <jackhill>civodul: congrats on the release (and thank you!). The version number is typo-ed in the body of the email announcement though <civodul>kinda ridiculous, that shows the need for more automation <civodul>the code itself is less ridiculous that it used to be though :-) <meena>apteryx: it's very unintuitive that package -r doesn't work <KE0VVT>building /gnu/store/44pxqdvfqsdjhfb1x7n4ykvz0z7an3yf-telegram-desktop-2.9.3.drv...