<bandali>anyone know if it's possible to have local channels?
<oriansj>ZombieChicken: depends entirely on what you are installing; for example if you are just doing a minimal server 8GB is fine but if you are dealling with lots of packages, gnome and other big packages 40+GB would be recommended
<bandali>idk, try searching the bug reports? also, it's free software so you could technically contribute it yourself too :)
<bandali>(*not* answering on behalf of nckx, of course :)
<ZombieChicken>the last time I submitted a bug report it was ignored. The documentation isn't terribly clear, and the few times I've asked for clarification it was deemed acceptable, so I developed the impression the devs didn't give a crap
<ZombieChicken>as for contributing, I tried that before and found the codebase too much of a mess. I don't have the time to track through everything to figure out what needs changing where
<Minall>I mean, At this point I'm not sure how to use guix environment correctly... I'm not a developer but I want to be one, so I'm constantly reading, and I want to know how to integrate guix environment perfectly in my workflow
<Minall>I'll do... When I have the time I want to re-read the whole manual and try to improve it as much as I can, I noticed that the documentation of NIX has a part when they teach you how to install nextcloud, which is amazing. Not very updated thought, and I don't know if it does work
<brettgilio>I recently posted several WIP packages to guix-patches debbugs if anybody is interested in looking at them. They are from my channel and just aren't in a condition to be sent to Guix master just yet.
<peanutbutterandc>brettgilio, I see. I do not have enough knowledge about XDG stuffs, sadly. And this is what I managed to bump into yesterday. If there are any documentations, etc. that you could point me towards, I'd be happy to read up on them and poke around with guix
<peanutbutterandc>leoprikler, I see. I will try to poke around my guix profile then. Thank you
<thorwil>hi! so i’m trying to spellcheck german text in emacs. ispell-change-dictionary gives several options, among them “deutsch”. but ispell-buffer then fails with “The file "/usr/lib/aspell/deutsch” can not be opened for reading.
<thorwil>i installed aspell-dict-de. the store contains two paths ending in /lib/aspell that both contain an assortment of de* dat, multi, rws and alias files
<peanutbutterandc>brettgilio, leoprikler: Yes, it seems the most thing that was happening with the installation of gtk+ package was that `guix package --search-path` (which was being evaled in the /etc/profile.d/guix.sh init file) was listing XDG_DATA_DIRS.
<peanutbutterandc>I checked /etc/profile.d/flatpak.sh and that is exactly how flatpak does it's desktop integration
<peanutbutterandc>So, all anyone has to do is set that and it'll just work. I will update my gist accordingly.
<brettgilio>peanutbutterandc: yeah you shouldn't need the gtk+ package at all
<leoprikler>i.e. your ~/.profile should contan export XDG_DATA_DIRS=$HOME/.guix-profile/share:...
<peanutbutterandc>leoprikler, I think it'd be great if we had that in /etc/profile.d/guix.sh instead. And esp. if it was set during installation. (Perhaps an instruction in the reference manual for us foreigners)
<zig>(fwiw, I just benchmarked XFS vs EXT4, with my database server, it takes 5min to import 133MB, 1M lines file on EXT4, with XFS, it takes one minute less, that is 4minutes for XFS)
<peanutbutterandc>leoprikler, While I don't fully understand, I think people like you know best. I hope to learn more of functional-programming-fu myself.
<leoprikler>~/.profile and /etc/profile are quite dangerous files, that contain system-specific code and breaking those would impact most if not all of your shells.
***ioerror is now known as supercap88
<peanutbutterandc>...and guix would like everything that is does to the system be inside itself so as to be able to move back and forth in time? I see that about the init files. But I think I have been used-to with editing such files. Hence the surprise.
<leoprikler>Telling people to add ~/.guix-profile/share to XDG_DATA_DIRS inside of their shell profile on the other hand is safer, because unlike shell scripts people can understand shell scripts.
<peanutbutterandc>leoprikler, I think I kind of understand what you mean. In order to have the changes local to their own profile rather than the entire system.
<leoprikler>you can even make it for the whole system if you know your sh-fu (mainly checking whether $HOME/.guix-profile exists before doing stuff), but it's still a task better done manually than automatically
<peanutbutterandc>leoprikler, Hmm... I see. I just created a new user (with the /etc/profile.d/guix.sh as seen on the gist): so no .guix-profile in the first login. While it does pollute PATH with nonexistant address, there wasn't much of an issue... I should perhaps put the check in anyways
<supercap88>Hello everyone. I am getting an "input/output error" trying to upgrade my guix profile. Also, when trying to 'guix gc', it gets stuck in deleting unused links. Any tips except for reinstalling the system? See: https://paste.debian.net/plain/1121046
<leoprikler>okay, first of all, make sure to keep backups of your user data, as well as guix channels.scm, manifest.scm (if you don't have one, you can copy the one from ~/.guix-profile so you don't have to reinstall everything) and /etc/config.scm
<leoprikler>then, after looking at the smart stats as ng0 suggested, do a bad blocks check
<supercap88>Yes, all my user data is in another hard drive, and everything backed up. That hard drive is used only for the store
<leoprikler>then you can also reassing $GUIX_PROFILE instead of needing two variables
<peanutbutterandc>leoprikler, No, sir. May I ask why? I realized that until a user runs `guix pull`, the ~/.config/guix/current does not exist. So it seemed to me that a user could just use the /usr/bin/guix to install some packages before actually `guix pull`-ing.
<leoprikler>sure, but say a user logged in through ssh and guix pulled first but then his connection died and he was forced to log out
<leoprikler>when said user logs back in, he'd have a current guix which is not recognized
<peanutbutterandc>leoprikler, I see. That makes a lot of sense. I will make the change right away. (But I think I'll keep the two different variable names just because GUIX_PROFILE has been something that has confused me before and making the distinction between the user's profile and guix pull's profile will probably be educational to some, perhaps (?) )
<leoprikler>GUIX_PROFILE is just a nice name for a path that is a guix profile.
<peanutbutterandc>leoprikler, Yes. That confused me for a while. But then it turned out to be a great design decision by the developers to give us the ability to move back and forth with the packages without having to move back and forth with guix itself. Super neat.
<leoprikler>There are some other PATH variables set in /etc/profile, but for now it seems good.
<peanutbutterandc>leoprikler, Yes, I have therefore used caution not to over-write any of them. I am glad you think it seems good. I think we now have a good sample to point the foreign distro users to for their setup, should they want it. I hope.
<nixo_>Hello guix! Are you able to export org files to odt? I saw a couple of report on the channel with the same error (OpenDocument export failed: Buffer is read-only: #<killed buffer>) but with older emacs versions and no solutions
<leoprikler>I can't, but for a different reason -- zip is missing.
<nixo_>leoprikler: yep, to get until my error you have to install it
<rekado_>nckx, g_bor[m]: mumi did use fibers. It just stopped working for reasons unrelated to mumi.
<rekado_>after some upgrades it would run into locale errors when decoding debbugs XML from fibers threads.
<nixo_>this file is in the store, so it's ro. It's placed under /tmp/odt-*/styles.xml (still ro). I've worked around it by chmodding it _inside_ the org-odt-template function. We can patch this file maybe
<oriansj>(otherwise it wouldn't be an immutable store)
<nixo_>oriansj: Yeah my patch would be on the ox-odt.el file
<nixo_>oriansj: After copying it to /tmp/, make it writable
<oriansj>nixo_: well guix, like nixOS would produce a different hash with different inputs and thus the altered file would be in a mirror of the original directory
<nixo_>oriansj: no I think I've explained badly. ox-odt, during the export, copies a file from the (ro) store to tmp, tries to change it, and then creates a zip* (odt) file with the content. This is done by the user, in it's working directory, with the file he is working on. It's fine to have our store ro, the problem here is that once the file is copied, we need to make it rw
<oriansj>nixo_: ok, so a chmod needs to be added to the program as it incorrectly assumes rw on the file
<bandali>next up, i'm assuming the "--enable-link-time-optimization" configure flag is completely optional and okay to omit?
<leoprikler>1. I don't think that is possible. If it is exactly the same, you may be able to extract it from the emacs-package somehow, but copypasta should be fine imo (especially since Emacs 27 will replace emacs in Guix when it is ready).
<leoprikler>2. Probably so. Does it break builds/introduce non-determinism?
<bandali>1. ah, you're right. i was thinking it would get inherited, but it's inside (source ...) not the top level (package ...) form itself. i'll see about pulling the ones from the original package, like what you have done for (modules ...) using origin-modules
<bandali>2. i haven't yet tried; it's just that i never used the option when building emacs elsewhere, i think due to a caution or something in one of the readmes in emacs
<bandali>3. could you please explain the need for each of the modified phases there? and finally,
<bandali>4. can you elaborate why each of the additional native-inputs are needed? (besides autoconf)
<leoprikler>3. I don't know about 'make-compressed-files-writable, you'd have to ask valignatev about that. However, I believe it is to fix some build issue.
<leoprikler>'restore-emacs-pdmp restores the dump file that Emacs installs somewhere in libexec/ to its original state.
<leoprikler>The tricky thing about that is guessing the filename, which involves more magic than I could handle at the time of writing.
<leoprikler>So I decided to just go with find-files and call it a day.
<leoprikler>Both find-files invocations there will only return one file, so the for-each will delete the one wrapped file and put the original file where it was.
<leoprikler>4. again something valignatev came up on their own. Probably the build system changed pretty much between 26 and 27 leading to additional dependencies.
<bandali>leoprikler, gotcha, and many thanks! i'm now only curious why restoring that dump file is necessary, and why does emacs generate a new one and move the "real" one elsewhere
<leoprikler>This is not something Emacs does on its own. This is something glib-or-gtk-build-system does as part of 'glib-or-gtk-wrap, since the pdmp ends up in libexec (arguably a bad place for it to be in, but that's what the Emacs people chose). Moving it outside of bin or libexec will also not work, since that is where Emacs searches for it. I hope the Emacs folks can come up with a better solution for the actual 27 rele
<leoprikler>ase and also listen to Guix people about reproducability, but alas, they likely won't.
<bandali>ah okay, i see. do you happen to know if anyone has tried raising this with them? (if there's a bug# for it)
<leoprikler>I personally did not, and I don't know whether valignatev did, so no. Other than that I saw Ludo posting about the reproducability thing on one of the Guix lists once, but I'm not sure how many Emacs maintainers are aware of this post.
<bandali>gotcha. thanks again for all your help :)
<lispmacs>I'm working on a package definition that uses cmake. However, am getting build failure because the source files and CMakeLists.txt is not in the root directory of the source archive. What is the simplest way to deal with that problem?
<pkill9>lispmacs: add a phase before the configure phase that changes in to that actual source directory
<brettgilio>nckx: mostly if you have any insights as to how a proper bootstrap might be accomplished? Like should we get SMLnj packaged (I have a WIP bug open for that too) and bootstrap using that? I really hope there is no blobs in there.
<nckx>brettgilio: I have yet to try it. What's your use case?
<nckx>(‘Zip back a week for a full night's sleep’ doesn't count.)
<brettgilio>nckx: check my most recent push to master. The emacs-doom-themes package on a refresher commit has an issue with bytecomp overflow. My solution was to just disable bytecompilation for that package all together by deleting the phase, but that obviously isn't the /best/ way to do it. I kind of like what leoprikler suggested of tricking the phase by hiding the file, but I had already made the change before I read his message.
<brettgilio>Regardless, I wonder if having support for single file or list-based bytecomp exclusion is something we could utilize? Idk.
<nckx>You can tweak #:license-file-regexp "^foo.*bar$" if that would be needed (you know where!).
<nckx>See %license-file-regexp & install-license-files in guix/build/gnu-build-system.scm for the defaults & code.
<brettgilio>Man were the mailing lists down earlier? I just got hit with tons of emails from hours ago
<brettgilio>Including a bug report I tried opening hours ago
<lispmacs>there is a COPYING file in the root directory. Maybe the problem is I had to change directory inside the source, since source was not in the root directory, so COPYING file is not in that directory (...?)
<bandali>brettgilio, yeah there seem to have been a congestion of logs on the gnu mail server, saturating the disk
<nckx>lispmacs: Depends on the package (oh cool you're packaging hackrf) exactly how you'd fix that. Packages too clever for their own good, it happens.
<nckx>lispmacs: Is it supposed to run under a dedicated group? If so, you can just use #:configure-flags (list "-DUDEV_RULES_GROUP=hackrfuser") and when you/we later add a Guix service we'll use that group name.
<lispmacs>nckx: I'm not sure, my knowledge of udev is quite limited. I'll ask on #hackrf
<brettgilio>Took me three days to figure out civodul is ludo backwards
<lispmacs>nckx: if I tryu to add the configure flag as suggested, build fails because cmake cannot write to /etc/udev/rules.d. Package too smart for it's own good, I guess?
<nckx>lispmacs: This isn't that uncommon. You'll need to do something vaguely equivalent to adding a (string-append "-DINSTALL_UDEV_RULES_TO=" (assoc-ref %outputs "out") "/etc/udev/rules.d") to #:configure-flags.
<nckx>The exact name of the -DVARIABLE depends on the package though.
<nckx>Actually, looking at other packages that do this, the canonical location seems to be /lib/udev, not /etc. Makes sense.
<nckx>lispmacs: Look at the bluez-qt packages in gnu/packages/kde-frameworks.scm. That's your pattern.
<bandali>brettgilio, hehe. my first name is amin, my nick is my last name :)
<raingloom>could this be a packaging issue or should i file a virt-viewer bug? "(remote-viewer:28533): GLib-GIO-ERROR **: 23:44:37.561: Settings schema 'org.gtk.Settings.FileChooser' does not contain a key named 'show-type-column'"