<ytc>rekado: I mean, I still don't understand why Guix offers two ways to install packages for user. One can accomplish the same thing with manifest files also.
<ytc>creating and deleting profiles is also very elegant.
<ytc>but installing packages with home profile doesn't fill any gap
<rekado>ytc: home services can also install packages
<rekado>configuration and installation are often closely connected, so I think it makes good sense to allow for deployment and configuration in the same tool
<zamfofex>ytc: It’s a way to have a unified place for Guix‐related (and sometimes/ideally other program related) user configuration. I’d say ‘guix package’ is *mostly* obsoleted by it, but now serves a purpose as a lower‐level tool may you come to need it.
<ytc>home services will install packages that are needed, it is perfectly reasonable. i didn't like the way (home-packages (list "icecat" "emacs"))
<ytc>i didn't try it, when i switched to a new home profile, do I need to restart my window manager or something?
<rekado>zamfofex: I agree that with “guix shell” + “guix home” there is little technical reason for “guix package” to exist, though it still serves as a more familiar entry point for those who approach Guix as a package manager.
<dthompson>ACTION still hasn't made the switch to guix home
<ChocolettePalett>> Exiting the shell places the user back in the original environment before guix shell was invoked. The next garbage collection (see Invoking guix gc) may clean up packages that were installed in the environment and that are no longer used outside of it.
<ChocolettePalett>It is preferrable to use ``guix package`` for those who don't have a good internet connection or intend to reboot (if I understood the part about exiting shell right) while trying the new package
<ytc>saravia: I didn't know it was possible. How could I do it?
<saravia>ytc: I have guix in a virtual machine and never archieve change login image photo, is one of a reazons becose I'm here : P
<saravia>ytc: for the moment not in a file for build a enviroment, only for a clean instalation, I want put my photo in login screen : (
<ytc>gdm doesn't have a feature like this, or you should use gnome i guess
<cbaines>jpoiret, regarding https://issues.guix.gnu.org/60824 sounds like it could do with being pushed to a non-master branch. Then yeah, creating a guix-patches issue requesting that branch is merged would be good
<ChocolettePalett>saravia: You might want to try LightDM if you use XFCE, because GDM seems to be developed for Gnome. LightDM supports changing background relatively easy.
<mirai>cbaines, jpoiret: guix refresh gives me approx. 6 packages that would be rebuilt
<carmenshea[m]>Question: I have a Guix Home environment running, works well, however I would like to make some changes my .bashrc file. Currently that file is read only and is linked to the Guix Store. How do I edit the .bashrc file and then get the changes back into the Guix Home environment?
<carmenshea[m]>ChocolettePalett: I'd be willing to bet that davfs is a dependancy of another program. Its probably launched by a different program. I assume your trying to get access to a Calendar server?
<cbaines>civodul, the most significant change seems to be the julia breakage on i686-linux
<civodul>cbaines: oh? (i was looking at qgis on x86_64)
<cbaines>civodul, if you look at the i686-linux row, there's a big jump in the blocked number, which I guess is because of julia
<civodul>actually i don't know the difference between "Blocked" and "Unknown"
<cbaines>but going back to what I was saying about being informed, I'm not sure it's the qa-frontpage's job to say what's good to be merged, although I think it should say when it's finished doing testing, and flag the issues better
<civodul>i thought both had to do with pending builds
<cbaines>civodul, blocked is sort of like "failed (dependency)" in Cuirass
<cbaines>unknown represents builds that haven't happened yet
<civodul>oh! perhaps it should be labeled "Dependency failed" and "Pending"?
<evilsetg[m]>Hello guix, I am trying to symlink `/lib/ld-linux.so.2->/lib/ld-linux-x86-64.so.2` inside a guix container shell. I tried the -S/--symlink option but since /lib is mounted read only that does not work. Does anyone have an idea how I could achieve this?
<jpoiret>you'll need to add a package that contains the given symlink to the profile i'm afraid
<jpoiret>here /lib is symlinked to the profile's /lib directory, which is in the store and thus shouldn't be edited
<evilsetg[m]>Ah, okay, good to know. Then I will do that. Thank you :)
<mekeor>oh no, so many people having problem with .so files being named differently...
<jpoiret>evilsetg[m]: you could also patch the relevant binaries to use the right dynamic linker
<jpoiret>i think patchelf can do this, or just manually patch PT_INTERP
<rekado>we’ve got ourselves a labelled bucket, and for whatever doesn’t fit you can get yourself another bucket; and since the buckets all have the same opening diameter there’s no discrimination against the label on your buckets or their contents
<civodul>but yeah, it's very similar to being vegan
<civodul>another interesting with HN: 90% of the comments are off-topic
<civodul>like, it always instantly goes to Nix vs. Guix, NoN-FRee-oH-My, DSL
<janneke>there are similarities, when people find out i do not (hardly) use non-free software, they think i'm a freak, when they find out i won't consume animal cruelty, they often take personal offence
<bjc>i think it comes from people not deeply questioning their own preferences and how they align with their personal beliefs; they suspect the other person may be on to something, but don't want to give up their comfortable position of both believing in the rectitude of their morality and their actions, which may actually be somewhat opposed on deeper inspection
<janneke>re Nix vs Guix, it *should* be about nix/guix vs legacy (brute-force effort) package management
<bjc>i often think that, should humanity survive the next hundred or so years, we'll look back on this time and think about how barbaric we were to do such things to animals
<zamfofex>I have recently shared oh #hurd some interest on thinking about and working on some way to use Guix Home for limiting resource access to certain packages on the Hurd. The #hurd people seemed mostly unamused, but I was wondering what people here might think: https://logs.guix.gnu.org/hurd/2023-06-07.log
<jpoiret>zamfofex: i don't think you should be looking at package transformations for this
<jpoiret>we don't have nice abstractions with which to write "container environments" though
<zamfofex>Isn’t that what ‘guix shell -C -m’ is for? I guess you then don’t get to specify the resource access (e.g. ‘-N’) on the manifest file itself, though.
<jpoiret>you want a declarative interface to this like (operating-system ...)
<zamfofex>I suppose so, but the thing is that it won’t actually be used by anything other than ‘guix shell’, so it feels to me like, even though it would be nice, you could get away with a shell script that invokes ‘guix shell’ with the appropriate flags on your repo/project as a more immediate solution.
<csepp>anyone knows why this gcrypt error might show up when trying to import a package? "Function not implemented"
<csepp>i'm on a private branch that i recently rebased onto master, so it's possible i messed up something in the importer code, but it seems unlikely.
<csepp>both the local checkout and the build environment's guix are running commits from today
<johnabs[m]>jpoiret: Hey, I just realized, would it be possible to roll back gcc-toolchain to fix the xmonad problem we discussed yesterday until that fix you mention gets patched through?
<johnabs[m]>Actually, all the gcc-toolchains are now using glibc 2.35. And I'm not sure installing a downgraded version of glibc will work in this case.
<HexMachina>civodul: your article (re: HN) is very good but one thing in it that I haven't quite wrapped my head around, and that isn't explained, is the difference between (package (inherit ...)) and (package/inherit ... ), and both are used in one example right next to each other. And if the package-with-configure-flags method returns a package directly, why
<HexMachina>can't the define-publics just use its return value directly, instead of nesting it inside a slightly-different package inheritance mechanism?
<PotentialUser-11>how do I start the neon package: I just downloaded, but when I type neon nothing happens. Can anybody help, please?
<jpoiret>HexMachina: package/inherit interacts well with grafts (the replacement field)
<jpoiret>ie. if the original package is grafted, then the inherited package is grafted as well but still inherits the transformation
<jpoiret>otherwise, the inheriting package would not apply the transpormation to its replacement
<HexMachina>jpoiret would it be possible for these to be merged into one function that takes some extra arguments to alter its behavior? The presence of two very similar but subtly-different methods, used right next to each other in this article with no explanation, gives a big impression of "you need to be an expert to even start doing simple things"
<jpoiret>HexMachina: well, you can't really, because (inherit ...) is part of the (guix records) interface, it's usable for every single guix record, of which packages are an example. package/inherit is a specific function that only makes sense for packages.
<svn>Hello, i'm new to guix. i installed my system with the gnome desktop. Now i want to start to configure the system. As a first small step i want to use wayland, in the documentation i found that i can configure the gdm-service-type. But i stuck how i really do it? how do i know that the code is valid and so on? Sry for the noobish questions.
<psycotica0>PotentialUser-11: Maybe I'm crazy... but it doesn't look like that package has a binary called neon in it, so that's definitely not going to work. What are you trying to do? Is this your first time using guix?
<jpoiret>oops, it'll probably be %desktop-services and not %base-services in your config.scm though!
<jpoiret>it's written off the top of my head, didn't test it
<jpoiret>psycotica0: right, neon seems to be a library
<PotentialUser-11>psycotica0 So I just try to fine an alternative to dropbox, because I don't get the sync script to run. I figured, that I had to use an alternative, so I found owncloud. I tried davfs2, which is working, but way too slow. Then I went for the sync job from owncloud, which has an appimage. I failed to run that one as well and search for another
<PotentialUser-11>solution with webdav, that is hopefully faster. Am I doing something wrong here?
<PotentialUser-11>I just feel tremendous pain and it is a good, but I don't now, what I am doing wrong right now. Additionally chromium just crashes, when it wants to download something from my file system.
<psycotica0>PotentialUser-11: Ok... so how did you end up with guix at the end of that? And what does that have to do with the neon package?
<PotentialUser-11>psycotica0 I don't know how to start to the application or who to find the docs for that package in guix
<svn>jpoiret it worked thanks. what exactly i need to get this kind of things done by myself?
<jpoiret>reading through the manual will give you some ideas
<jpoiret>see the "System Services" heading under "(guix) Using the Configuration System"
<psycotica0>PotentialUser-11: Right, that's unfortunately a question that depends on what you want, and you may not know what you want.
<psycotica0>Docker and guix both solve the problem of giving you software with dependencies together, which makes it easy to download.
<psycotica0>Docker will make it so when you're running the code it is running in a contained environment, which can be good for some things. Guix on its own is just like running any software on your computer, it has access to the whole computer environment, but guix can *also* make a Docker container if you ask it to.
<psycotica0>So the hardest part will be learning enough to do what you want. If you find a guide in Docker that is already written and looks good, it may be easiest to follow that unless you have a reason not to.
<jpoiret>guix can also run software in isolated environments without relying on Docker at all
<jpoiret>the main difference between Docker and Guix is that Guix is a software distribution, not just an isolation tool. So you get better composability. Docker just relies on base images of distributions and their package manager
<morenonatural>another related subject: I'm doing guile scripts and sometimes I use 3rd party code, say guile-json... can I run guix in a "virtual env" that includes that code? can I have the resulting script using guile from that venv as shebang? would it run guile code as compiled?
<ternary>So I've needed to get the path of some built package and I came up with something that works, but it feels like I've definitely came up with a more complicated solution than is necessary. I would have thought that getting the path of a package was a common task
<ternary>(lowered-gexp-sexp (with-store store (run-with-store store (lower-gexp #~(#$packagename)))))
<jpoiret>Cairn: can you boot with nomodeset in the grub command line?
<jpoiret>use `e` in grub to temporarily change the command line
<carmenshea[m]>Good Morning. How do I edit my .bashrc file now that I'm running Guix Home? .bashrc is now read only and links to a Guix Store file. I do have the 'legacy' files where I can get the original .bashrc file and edit that...how do I put those edits back into my Guix home?
<tricon> carmenshea[m]: You can edit the source .bashrc file where Guix "homed" your original files, then redeploy your home.
<zamfofex>carmenshea[m]: You should use the Bash service configuration on your Home configuration file.
<ngz>sneek later tell rekado I fear scattering texlive-bin across packages may be a dead-end: most binaries contain a reference to texlive-bin itself, and it doesn't seen possible to create a lib output either (cycle detected in the references at the end of the build process).
<sneek>rekado, ngz says: I fear scattering texlive-bin across packages may be a dead-end: most binaries contain a reference to texlive-bin itself, and it doesn't seen possible to create a lib output either (cycle detected in the references at the end of the build process).
<ngz>rekado: It means that any minimal TeX setup needs to bring along 700Mb of texlive-bin.
<rekado>I’m having a question, which is really an itch to scratch: I need to work a bit on RStudio, and the package definition we have in guix-science comes with build phases that set up a few things before we can configure and build.
<rekado>Now I’d really like to be able to run those phases in my checkout to execute these preparations
<davidl_> when you have the non-standard output as an input package, for example (list isc-bind "utils"), then how do you refer to it with #$(this-package-input ??)
<rekado>has anyone played with running individual build phases outside of the daemon?
<rekado>can we perhaps generate the builder script as usual and pass it our own values for “out”?
<rekado>and add some extra control structures to run it selectively?
<rekado>in order to make this possible, would it make sense to retain a little more structure in the generated builder scripts?