<quiliro>lispmacs: Hello... When you install with the "graphic" installer, it creates a config.scm file which would have almost all that you need. you could post it by installing a paste program on the installer with "guix install curl" and then post the url for people to look at it here
<amz3>dutchie: compiled kodi 18.2 without any problem.
<quiliro>lispmacs: when you install with the graphic installer, you get a saved config on /etc/config.scm
<PotentialUser-27>Hey there guys! I've recently downloaded and installed guix onto my librebooted X200. I have some fundamental questions as followS:
<PotentialUser-27>How do I browse the source for the distro from inside of it? There are many commands being referenced by the manual, but I want to understand what they are doing. I
<PotentialUser-27>I'm trying to get a base system config that I can instantiate with a file, is the reccomended method to install using manifest? Or should I just edit my config.scm file with the global packages I want?
<quiliro>PotentialUser-27: it is not clear what you want
<user5822>Good evening. I've just begun the guixSD journey, and was wondering how emacs configs are managed. The manual says to place the config files in $HOME/.guix-profile/share/emacs/site-lisp but the directory is read only
<amz3>I find the idea of GWL very inspiring, I hope it comes out great.
<user5822>rvgn: yes there is a .emacs.d in the home dir, although is ./guix-profile/../site-lisp seems to be populated, should one manage the init.el like "normal" from .emacs then? alright. Also, do you know how one can Symlink a directory in the .guix-profile/share/ to the home directory?
<amz3>quiliro: it is a paper from the giant ad company, that explains how *programs* are scheduled in their gigantic farms (this includes hard disk requirements, memory, CPU time and GPU). It is like k8s but ... hela scale
<amz3>quiliro: both long running amd short lived script can be scheduled, paused and restarted depending on the load taking into account geographical stuff etc...
<amz3>quiliro: to extent that is what guix deploy is going to become except it will not rely on static compilation etc...
<user5822>From the Documentation "2.6.5 Emacs Packages
<user5822>When you install Emacs packages with Guix, the elisp files may be placed either in $HOME/.guix-profile/share/emacs/site-lisp/ or in sub-directories of $HOME/.guix-profile/share/emacs/site-lisp/guix.d/. The latter directory exists because potentially there may exist thousands of Emacs packages and storing all their files in a single directory may not be reliable (because of name conflicts). So we think using a separate directory for each
<user5822>package is a good idea. It is very similar to how the Emacs package system organizes the file structure (see Package Files in The GNU Emacs Manual).
<user5822>By default, Emacs (installed with Guix) “knows” where these packages are placed, so you do not need to perform any configuration. If, for some reason, you want to avoid auto-loading Emacs packages installed with Guix, you can do so by running Emacs with --no-site-file option (see Init File in The GNU Emacs Manual). "
<user5822>But, one uses the .emacs.d/ in the home directory instead ? Anyhow, thanks!
<amz3>user5822: I think, the doc is somewhat mislead to think that the user (like me and you) can use guix profile dir to store emacs extensions. Never touch the guix profile directory and the /gnu/store you can break your Operating System
<quiliro>user5822: will you please post your enquiry on the help-guix mailing list?...it would be of more use
<fxer>hello, in guix system, where is gdm configured to start the wm? eventuall i would prefer init into a lower run-level and have the binary be executed from ~/.xinitrc. 2am here, in a hurry to test my newly build wm package and cannot find the config :-) thx
<bzp>hello to all, I need to run the 'Popcorn' program in guixsd, in another distribution that used it worked well just by using './Doccuments/Popcorn/Popcorn &', but in guixsd it does not work to see what it is and how do I solve it?
<Gamayun>nckx: Hm, at least video.scm uses upnp.scm, so maybe I'm better adding it there.
<nckx>Gamayun: I don't think this belongs in (gnu packages video), though.
<nckx>Why not upnp.scm? Just because video.scm already use-'s it?
<nckx>Oh I see. That's not the kind of cycle I meant. I meant the ‘Guile uses all your RAM & crashes’, ‘you'll know it when you see it’ kind, when there's actually a dependency loop between variables. Modules mutually importing each other isn't necessarily a problem.
<bavier`>something broke recently in the latest clang/llvm package
<bavier`>e.g. hedgewars gets a build error from the linker about not being able to find crt1.o, libgcc, etc
<bavier`>similarly for some other packages that use clang in their builds
<Gamayun>nckx: Ah, ok. I will keep it there then. It can always get moved later to a 'media server' module with similar things, if needed.
<ilikeheaps>amz3: thanks, I've checked emacs-guix documentation but it covered pretty much only the interactive commands. They explicitly stated that the documentation doesn't cover many things so I'll check it later. I've also seen use-package can use a custom package manager so that might be a way
<pie_>Hi folks, i'm a NixOS user, I don't have much scheme experience but I find the idea of approaching a fully / coherent language based system enticing, so I'm going to start idling here o/
<roptat>then, we have to make sure it doesn't add index.html to top-level pdf
<dwagenk>sorry, not accustomed to this webirc client, so excuse the premature messages, please... I know I can just list all of them in the (packages append (list packagename1 packagename2 etc) %base-packages)) part of the operating system declaration (and already have done that). This leaves me with the installe dapplications all beeing available insid
<dwagenk>e both i3 and XFCE. I'd like to make use of profiles, so that both are installed globally, but when I start i3, only the i3 packages are available (e.g. not showing thunar, the XFCE File browser) and when I start XFCE I don't see all my i3 applications.
<roptat>dwagenk, did we already talk a bit on mastodon? :)
<dwagenk>I've had a small conversation on this with roptat on mastodon and was recommended to put it in separate user profiles. I kinda see this as part of my OS, because I want the OS to have (two separate) fully functional Desktop environments and then put my user specific customization on top.
<dwagenk>roptat: so is there a way to specify several global profiles in the operating system configuration and preconfigure xfce to source one of it (plus the common one) and i3 to source the other one (plus the common one)
<roptat>if you want a declarative profile, you can still use a manifest to populate your separate profiles
<roptat>I don't think we have configuration options for i3 or xfce, other than installing the package, so it won't be declarative, but you can modify your ~/.config/i3/something to automatically source from ~/.i3-profile/etc/profile when it starts for example
<roptat>I don't know how to do that because I don't use either, but the internet might know :)
<dwagenk>roptat: is there a way to specify in the operating sytem declaration a manifest file for my user, e.g. 8users (cons( user-account (name "dwagenk") (manifest "dwagenks-prepared-maifest-file.scm") ...
<dwagenk>although roptat is away now, I'll extend on my thought regarding this: A'm I right, that I could globally install all required packages and then basically blacklist them in per-user per-desktop-environment profiles, by uninstalling them in those profiles? In combination with a service declaration, that takes care of initiating those profiles from m
<dwagenk>anifest files and a skeleton providing the adapted XFCE and i3 config files that source those profiles this should work, right?
<g_bor[m]>dwagenk: I do not believe that would work as intended. The packages in the system profile are not uninstallable from a user profile. The user and system profile work by adding their bin to path with the user profile taking precedence.
<g_bor[m]>What you could do instead is to add the minimal set of packages needed to the system profile, and have two user profiles for the two desktops.
<dwagenk>g_bor[m]: so it's again a per user thing? I guess I'll try that out. I still think it would be neat, to be able to provide multiple desktop environments separated from each other at the system level and not have to create those at the user level...
<roptat>dwagenk, I've thought about it a bit... you could have a manifest that would be a profile in the store (but not make it accessible from /var/guix) but something will have to reference it
<roptat>I don't know how you could configure i3 or xfce globally (even on a foreign distro), but if it's possible, you could create an i3-srevice-type that would reference that profile, same with xfce
<roptat>or you can create an etc-service-type that creates a script that sources the content of the i3 profile, and another for xfce, then you would load these files from your user configuration
<roptat>(guix profiles) exports profile-derivation that can take a manifest as its first argument
<roptat>it returns a derivation you can use in a gexp
<dwagenk>roptat: that sounds promising. i3 looks up it's config under /etc (probably patched to /gnu/store/...-i3-wm/etc in guix, right) if there is nothing in $XDG_CONFIG_DIR, so providing a default should work
<roptat>mh... you can't modify anything in the store
<dwagenk>roptat: aaah. so I'd need to create a new guix package, that contains the adapted config file?
<roptat>probably, or a desktop file with the right options
<dwagenk>it's getting complicated. Still need to get accustomed to guix and especially to the whole guile stuff, it still looks intimidating and confusing to me.
<dwagenk>roptat: thanks for all the suggestions. I think I'll need to back down a little and live with the non-separated desktop environments for now. I guess packagingone or two applications that I'd like to have will get em accustomed to guile a little more and then I can still come back to creatign new service types and maybe i3 with manipulated config..
<davidl>I cancelled a package build to install another package before finishing it, but then the build restarts as I install another package? Is there a simple way to avoid that?
<dwagenk>can someone point me to an example of packaging a bash script (https://github.com/TheLocehiliosan/yadm)? dependencies are git, bash and gpg and the installation on "normal" distros copies the bash file and a manpage to the right directories. Optionally there's a bash-completion script as well.
<roptat>davidl, could it be that you're building a build dependency for some package?
<dwagenk>I guess the trivial-build-system would be suited for that, but I'd like to look at an example, that's already packaged in guix, to have a clue where to start
<samplet>jonsger: You’re welcome. I spent to much time on it, but it feels worth it since it ended up upstream. :)
<apteryx>rekado, civodul thanks, I was reading linux-initrd.scm, yes. I'll try to add support for it! It's the last piece of the puzzle to properly support the use of Btrfs submodules in your system config.
<lsl88>rekado: the videos are uploaded in the internet archive, the idea was that the folks looked at them, some of them found typos and that kind of stuff, gave their opinion, and if everything was right, then upload them officially
<civodul>lsl88: maybe you need to reping "the folks" and set a hard deadline? :-)
<rekado>the ant-bootstrap failure is weird. I fixed it, but only by copying files around. It should be able to find these files without copying. I wonder what changed.
<jonsger>dongcarl: is there any particular reason to leave ppc64le out of the race?
<dongcarl>jonsger: Nope! In fact I've gotten a lot of pressure to include ppc64le from bitcoin core devs. However, the pull request to merge ppc64le support for our normal build system (non-Guix) hasn't landed yet, and I depend on our normal build system to do these deterministic Guix builds.
<rekado>hmm, ci.guix.gnu.org does not list any information for ant-bootstap.
<dwagenk>roptat: davidl: I've gone ahead and written my first package definition based on your packaged shell script suggestions. It works and seems OK. I'm quite unsure about rewriting the dependency paths and declaring dependencies though.
<roptat>dwagenk: rewritting dependency paths ensures that the package has references to its dependencies, so they cannot be garbage collected
<dwagenk>the shebang is /bin/sh and beeing rewritten to the /gnu/store/xyz-bash path by line 32 in the .scm file. The yadm script hands itself over to bash, if it's called from sh (they have a comment noting some portability reasons) and use exec bash "$0" "$@" for that. Is it correct, that I should have the package definition rewrite that to the /gnu/st
<dwagenk>ore path as well, to ensure it actually runs the specified version of bash, like I do in line 31 of the .scm file?
<roptat>It also allows you to have your script in your profile, but not all of its dependencies you don't care about
<dwagenk>aah that's a good point, although the bash dependency is in my path anyhow (might change if something requires a specific version)
<dwagenk>so basically all programms that are referenced in the packaged application should have their calls replaced by the full /gnu/store path, corect?
<dwagenk>it's starting to make a lot more sense now
<dwagenk>Since the package I'm working on (yadm) is mostly a wrapper around git, I guess this should be a dependency, too. I looked into the package specification of tig (terminal interface for git) for inspiration and noticed, it doesn't reference git at all as a dependency. this irritates me.
<dwagenk>A small difference I see between tig and my yadm package: tig is an enhancement for whatever git version you are using anyhow, while yadm is an application, that internally uses git for achieving it's goals.
<roptat>And it might depend on the purpose of the application
<roptat>If you might want to use it with multiple versions of git, without repackaging it, then you shouldn't embed the path I suppose
<dwagenk>roptat: I actually don't care about which git version is used in the background (maybe really ancient versions will cause problems), so from that point of view specifying the version would not be necessary. But on the otherhand for consistency (as far as I understand one of the main reasons for the whole functional package management thing) it woul
<dwagenk>d probably be good to have a fixed version.
<roptat>Yeah, if you don't care about git, just embed it
<lsl88>there are tons of thing to do, I wanted to create the subtitles, you can create new videos, we can generate translations (if the community agree), we have to improve the cli session videos colouring them
<rekado>something in GNU Classpath’s java/io/File.java must really be wrong.
<janneke>it seems i cannot #:use-modules (from a channel) ... hmm only guix is wrapped, guile cannot access the guix modules?
<rekado>it’s simple: createTempFile creates a “random” file name (derived from the current time), creates a new File object, and then keeps doing this while VMFile.exists(file.path) for that File object is true, i.e. it keeps trying if the file already exists.
<rekado>but in our case VMFile.exists(file.path) keeps returning true, even for files that don’t seem to exist yet.
<lsl88>nckx: it is a reminder, you know I take care ;)
<daviid>rekado: hello! did you find why configure fails for guile-cv, the standalone tex package not found problem ..?
<lsl88>quiliro: yes, those are the sources. Please, let me know if you understand how to build the videos, or whatever you need to know, even if you want to try and create a video. It helps us to improve the documentation of the process of how to create a video :)
<lsl88>here you have how everything works, it won't tell you which file you need to edit, but the general idea about how videos are created
<evhan>Hi there. Are there API docs for the various (guix ...) modules?
<lsl88>and if you read the README it mentions how to create each type of video and considerations that you should take. Maybe we should add something from the article to make it more clear, and what I can do the following weeks is write how to use the metacommands for simulating the cli sessions.