IRC channel logs

2019-12-14.log

back to list of logs

<Gooberpatrol66>when trying to install a package i get guix package: error: error parsing derivation `/gnu/store/p7c5660g2nslwvlazgiih0q7sc7nvfc6-libXt-1.1.5.tar.xz.drv': expected string `Derive(['
<Gooberpatrol66>the file's empty when i try to open it. how do i replace the file?
<nckx>Gooberpatrol66: Does ‘guix gc --delete <bad file>’ do the trick?
<Gooberpatrol66>nckx: yes, thank you
<ZombieChicken> How much disk space does guixsd need by default?
<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
***jje_ is now known as jje
<ZombieChicken>k, ty
<nckx>bandali: file://
<nckx>Just don't forget to commit.
<nckx>It's the only way I enjoy channels since SSH isn't natively supported yet.
<ZombieChicken>Can target in the bootloader config accept a list of targets? I have a RAID array I'm wanting to install to and would like grub installed to each of the 3 disk
<bandali>nckx, nice, ty!
<nckx>ZombieChicken: The bootloader installer currently takes a single device.
<ZombieChicken>Alright. Any plans on fixing that limitation?
<ZombieChicken>or does anyone know?
<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
<nckx>👍
<ZombieChicken>?
<nckx>And with that wonderfully positive twist, I'm calling it a night. Good night everyone! o/
<Minall>LOLLLLLL
<Minall>Omg sorry
<Minall>That was a good plot twist
<Minall>Good night nckx
<bandali>night nckx
<bandali>that's a shame
<Minall>bandali: o/
<bandali>i would've liked to elaborate and talk to them if they didn't leave all of a sudden
<Minall>Yep
<bandali>Minall, o/
<Minall>May be an angry person that just comes, complains and leaves
<bandali>ha
<Minall>If you're going to complain, stay and explain why are you complaining
<bandali>:)
<bandali>let's hope we catch them next time, and can have a nice discussion with them
<bandali>they may come around
<Minall>bandali: totally!
<bandali>:)
<bandali>fwiw, in my personal experience, i think things in guix are *way* better organized than traditional distros
<bandali>the module names are often quite helpful
<Minall>Yep, the only distro I can say that's VERY organized is hyperbola, and that's another world
<Minall>But I seem to enjoy guix at all
<bandali>haa
<Minall> He says that the documentation isn't terribly clear?
<Minall>What do you think about this bandali ?
<bandali>yeah, i've heard nice things about hyperbola; quiliro is a hardcore fan, it seems :)
<bandali>Minall, i've found the docs to be generally useful. sure, they're lacking in some areas, but that's not terribly unusual in free software projects, is it?
<Minall>Yep, I was with it yesterday, until I sayed, well, reinstall guix (I used it before)
<Minall>Quiliro and I passed a time on guix, but It seems that he likes hyperbola more, that's a lot of amazing work at hyperbola, they have they own web browser and are replacing pulseaudio for sndio
<Minall>bandali: Yes, But I think the documentation can be more helpful, by giving examples or showing how to get help...
<bandali>right, yeah they seem to be doing a ton of work
<bandali>Minall, for sure!
<bandali>please feel free to write to help-guix@ with concrete suggestions
<bandali>or open bug reports
<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
<bandali>ha, i see
<bandali>so, in this case, you mean the 'guix environment' subcommand specifically?
<Minall>Yes, I read the documentation a few times, but since I'm not very into the subject (just entering this world), I didn't get it how to use it, or what the advantages are
<bandali>right
<bandali>okay, so i'd suggest reading that section of the manual again anyway
<bandali>and let me see if i can find a concrete example quickly
<bandali>Minall, here are two nice examples:
<bandali> https://gitlab.com/librelounge/librelounge.org/blob/master/guix.scm
<bandali> https://gitlab.com/dustyweb/activitypub.rocks/blob/master/guix.scm
<Minall>Since we're on the subject, and I'm reading some of it right now, I personally that a good thing specific for the Guix System is the security it brings.
<Minall>Since we all know that complexity always brings more problems, it's good to keep things nice and simple.
<bandali>ha, yes it's nice in that you can get an environment with nothing but only the dependencies of the package you want to work on
<Minall>With guix, your user can install what they want in their environment, but the root will still have the basic packages, so it's less prone to bugs, and simple, so I think that more secure
<Minall>bandali: I'll re-read the part and check your examples, thank you a lot!
<bandali>Minall, yeah, it's great that guix has per-user profiles (that's the guix term for it) and each user can install their own set of packages independently, without requiring root access
<bandali>and cheers!
<Minall>cheers!
<Minall>thanks for all the info btw
<bandali>you're quite welcome Minall :)
<Minall>I may ask you for more help when I need to!
<bandali>sure! do keep in mind that i'm somewhat of a newb myself :p
<Minall>We'll both learn then! lol
<bandali>lol yup!
<Minall>bandali: I have to go!, thanks a lot!, I may connect tomorrow if I have the opportunity
<bandali>cheers!
<bandali>see ya Minall
<Minall>Bye!
<bandali>bye
<wdkrnls>Hi Guix
<wdkrnls>Are there any Guix wallpapers?
<wdkrnls>I tried googling, but all I could find were broken links and the artwork SVGs.
<bandali>hey wdkrnls
<bandali>i think there are some here
<bandali> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/backgrounds
<bandali>ah, scratch that
<bandali>i know the xfce package in guix comes with a couple
<bandali>oh lookie https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/xfce.scm#n751
<wdkrnls>Hmm... so it just creates the logos in the package. That's a neat trick.
<wdkrnls>err... wallpapers.
<bandali>yeah :p
<bandali>i think there's 3 of them
<bandali>if you can't or don't want to install xfce, i could upload them and /msg you a temporary link to grab them
<wdkrnls>That's okay. Thanks for offering :)
<wdkrnls>I don't suppose we could get these uploaded to the Guix website?
<bandali>cheers
<bandali>feel free to ask one of the maintainers when they're around :)
***lispmacs` is now known as lispmacs
<alextee[m]>hmm, can't seem to set up japanese with ibus-anthy anymore
<alextee[m]>anyone got japanese input working?
<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.
<brettgilio>bugs.gnu.org/38603
<brettgilio>bugs.gnu.org/38604
<brettgilio>bugs.gnu.org/38605
<brettgilio>bugs.gnu.org/38606
<brettgilio>That should be them.
<brettgilio>Make sure to read the cover letter for important information.
<brettgilio>leoprikler: thanks for your help on the telega package. Are you a user of that package, btw?
<peanutbutterandc>Hey everyone, I stumbled into a way to make guix-installed GUI apps visible from a host system's Desktop Environment menus yesterday. I have tested it on a few different DEs and have documented it here: https://gist.github.com/peanutbutterandcrackers/844c211a91137c19607ae75b59fa116f Please do let me know if it works/doesn't work for you. Comments on the gist itself would be more preferable. I hope this helps. (Perhaps the next release of the Guix
<peanutbutterandc>Reference Manual should have a similar section?)
<brettgilio>peanutbutterandc: the way nix does it is to leverage XDG_DATA_DIRS to reference the profile share/applications. I think we should borrow that method, too.
<brettgilio>It seems more standardized to use XDG, anyways.
<brettgilio>Less dependencies, too.
<brettgilio>Like export XDG_DATA_DIRS=$HOME/.guix-profile/share/applications:$XDG_DATA_DIRS
<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
<brettgilio>Something like that.
<peanutbutterandc>Hmm... I will look around regarding that then
<peanutbutterandc>If that is all it takes, it is certainly way more elegant!
<brettgilio>Sounds good. Let me know how it goes peanutbutterandc
<peanutbutterandc>brettgilio, I will try. However, please don't count too much on me. I am just a n00b. Is there anything you'd recommend for reading about it?
<brettgilio>nckx: Maybe we should work up a section in the cookbook on XDG for GNOME Menus and what not.
<brettgilio>peanutbutterandc: not off the top of my head. Email me brettg@posteo.net and I will get back to you on it.
<peanutbutterandc>brettgilio, I will. Thank you very much :)
<brettgilio>peanutbutterandc: I received your email. Will respond when I can.
<peanutbutterandc>brettgilio, Okay. I will try to look around over at freedesktop.org and all to see if I can make sense of anything. Thank you.
<roptat>hi guix!
<peanutbutterandc>roptat, Hello
<leoprikler>peanutbutterandc: fyi on Guix System, the apps get refreshed in GNOME after [Alt-F2 r]
<leoprikler>here ~/.guix-profile/share is added to XDG_DATA_DIRS
<peanutbutterandc>leoprikler, On a foreign distro, sorry. just `r`? Is it some kind of an alias?
<leoprikler>It's a builtin to restart the shell itself (doesn't work on Wayland tho).
<peanutbutterandc>leoprikler, I realized that is the case also with my foreign distro. I will run some tests. Perhaps that is essentially what installing `gtk+` package is doing?
<leoprikler>imo gtk+ should not be needed
<leoprikler>I certainly don't have it in my profile.
<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
<thorwil>i found this thread, but no solution for me: https://lists.gnu.org/archive/html/help-gnu-emacs/2013-12/msg00004.html
<leoprikler>thorwill: what's the value of `ispell-aspell-dict-dir'?
<leoprikler>s/thorwill/thorwil
<thorwil>Its value is "/usr/lib/aspell"
<brettgilio>leoprikler: I tagged you in a message earlier. Did you get it?
<leoprikler>ah, yes, I didn't see that because I was still sleeping then
<leoprikler>Yes, I am a user of emacs-telega.
<brettgilio>leoprikler: you should join our tg group for it :) @emacs_telega
<leoprikler>But what if I enjoy lurking anonymously? :(
<brettgilio>leoprikler: Come out of hiding. :)
<brettgilio>Get credit for helping with that ridiculously long package definition. Hahaha
<brettgilio>It is sooo long
<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
<peanutbutterandc>brettgilio, Yes. I realize it now.
<leoprikler>XDG_DATA_DIRS integration is handled by /etc/profile on Guix System
<peanutbutterandc>leoprikler, But not on a foreign distro
<peanutbutterandc>... which is why we were here scratching our heads - us foreigners. :D
<brettgilio>peanutbutterandc: I suggest fwding your solution for foreign distros onto the guix cookbook too
<leoprikler>That is correct, but it means you have to add code to your ~/.profile or /etc/profile instead of your ~/.guix-profile.
<peanutbutterandc>brettgilio, Perhaps the Guix Reference manual should have it too? That probably means I have to learn texinfo
<peanutbutterandc>...and get another email id which I didn't make when I was a 6th grader.
<brettgilio>I doubt it is as necessary for the manual. But that's just my opinion
<peanutbutterandc>#usershame
<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)
<peanutbutterandc>That is the route flatpak has taken and it "just works" for everyone.
<leoprikler>The thing is, we Guix people don't like breaking things through imperative programming :)
<brettgilio>^
<brettgilio>Declarstive methods are preferred here
<leoprikler>But you're right, we should at least put a hint up somewhere.
<brettgilio>Time for me to sleep. Baby is finally asleep. Goodnight all
<leoprikler>Goodnight
<peanutbutterandc>Hmmm... I am sorry but I don't quite understand how the guix.sh would be 'imperative'. (I am a n00b). Is it because it has 'side-effects' outside of the profile?
<peanutbutterandc>brettgilio, Good night!
<leoprikler>Well, shell scripts are known for their imperative nature, imperative being telling the computer what it should do instead of telling it what you want.
<leoprikler>But in this case, the side effects outside of the profile would be more harmful than adding a few user accounts.
<peanutbutterandc>leoprikler, I see.
<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.
<peanutbutterandc>I have updated the gist: https://gist.github.com/peanutbutterandcrackers/844c211a91137c19607ae75b59fa116f
<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>Can you still write to your disk normally?
<supercap88>leoprikler yes, I can also build other packages
<supercap88>It seems that there is an error with that specific store link
<leoprikler>interesting
<leoprikler>try removing this specific link -- perhaps it is broken
<leoprikler>or wait, before you do that, can you ls -l it for me
<supercap88>how would I go about doing that? Garbage collection is stuck at deleting links, and the store is read-only
<supercap88>ls: cannot access '/gnu/store/.links/1mhmwx8qp62acicp8xdljnqqghmprs51rqqcl0b7gzzx7hsf3lz4': Input/output error
<leoprikler>hmmm
<leoprikler>I'm pretty sure that gc gets stuck on this link because it can't read it
<supercap88>If I could get gc to somehow ignore it...
<leoprikler>I think the issue is more critical than that. How old is your hard drive, just so I know?
<supercap88>About 6 years old
<leoprikler>hmm, so you're heading into dangerous territory
<ng0>I'd look at the smart stats of it
<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
<supercap88>thanks for the tip, I'll do a bad blocks check
<peanutbutterandc>leoprikler, I have added the checks as you suggested: https://gist.github.com/peanutbutterandcrackers/844c211a91137c19607ae75b59fa116f#file-guix-sh Any inputs would be really helpful
<leoprikler>do lines 5&6 get executed if 3 fails?
<leoprikler>if not, I'd put them before
<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.
<leoprikler>And pull is a profile, so... :)
<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.
<peanutbutterandc>leoprikler, Also, I have made a bit more changes: https://gist.github.com/peanutbutterandcrackers/844c211a91137c19607ae75b59fa116f#file-guix-sh Any other thing that you could add please?
<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.
<peanutbutterandc>I know I will be using it from now on. :)
<leoprikler>I mean in Guix Systems' /etc/profile, e.g. INFOPATH and MANPATH.
<peanutbutterandc>leoprikler, I see. INFOPATH is listed by guix package --search-paths line. The MANPATH is not. But despite that, I am able to `man emacs` on my foreign distro... strange.
<peanutbutterandc>`man next` works just as well.
<peanutbutterandc>So I believe it is not a problem anymore.
<peanutbutterandc>I should probably switch to using GuixSD soon. Just a dozen of scheme/lisp/guile books and a few more on Operating Systems in general and I'll be there, I hope. :)
<peanutbutterandc>[declaring my own operating system with G/S-expressions, I mean. :) ]
<ng0>efraim: can you reproduce this bugreport I just closed? https://bugs.gnunet.org/view.php?id=5426
<ng0>with a current release of gnurl on guix
<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.
<rekado_>so I disabled fibers in mumi again.
<rekado_>I don’t have enough time to diagnose this now.
<rekado_>(apparently I do have enough time to add R packages… oh well.)
<Minall>Hello gui!
<nixo_>hello cli!
<Minall>o/
<Minall>I'm trying to run video on guix, but I'm unable to...
<leoprikler>what kind of video?
<Minall>Do I have to install something specific? I have installed already all the gstreamer plugins and gstreamer itself
<Minall>leoprikler: I don't know how to answer that, sorry
<leoprikler>a file on your disk, a stream in the interwebs, ...?
<Minall>Oh
<Minall>A stream on the interwebs
<Minall>The only videos that I can watch are from youtube, and I'm not watching from youtube
<leoprikler>So you can watch some videos, but not others.
<Minall>yep
<Minall>In other pages, (cybrary or treeknow) the player throws error without message, and in cybrary the video never starts
<leoprikler>From my personal experience, it's usually the server either not delivering a video at all or not doing so in a format usable by the browser.
<leoprikler>You can try separately downloading the video and opening it in gst-play/totem
<Minall>It may be that... Do I need to download some plugin or codec?
<leoprikler>depends, what plugins do you have so far?
<nixo_>I found the error!
<leoprikler>Nice, where is it?
<nixo_>the files styles.xml is copied from /gnu/store/hg2qd5ggvnxq5gfdhxqpidhm3rr8vysr-emacs-26.3/share/emacs/26.3/etc/org/OrgOdtStyles.xml
<leoprikler>so it needs to be made writable?
<Minall>leoprikler: How can I check which plugins do I have?, I installed manually every gst plugin (bad, ugly, base and good) and gstreamer
<leoprikler>try gst-libav as well
<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
<Minall>leoprikler: Yes, I have that instaled too
<leoprikler>okay, so you should be able to recognize all the formats
<leoprikler>open the debug mode in your browser, go to the networking tab and reload
<Minall>Ok
<leoprikler>search for the video, copy the curl, open a shell, then `cd tmp; guix environment --ad-hoc curl -- $CURL_CODE -o video.format; gst-play-1.0 video.format`
<leoprikler>replace video.format with a filename that makes sense
<nixo_>(fixme: right path is /gnu/store/hg2qd5ggvnxq5gfdhxqpidhm3rr8vysr-emacs-26.3/share/emacs/26.3/etc/org/OrgOdtStyles.xml)
<Minall>Thanks!
<Minall>Let's try that
<leoprikler>nixo_: Writing a patch for that would be very welcome. Also try fixing the zip bug while you're at it.
<nixo_>leoprikler: is that a bug? I see it more like an optional dependency
<oriansj>nixo_: well files inside of the /gnu/store are expected to be read-only
<nixo_>oriansj: the zip thing
<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
<nixo_>yep :)
<nixo_>(set-file-modes (concat org-odt-zip-dir "styles.xml") #o600)
<nixo_>regarding zip requirement? what do you think?
<oriansj>nixo_: that bit, just looks like you are setting a directory in the store into rw
<nixo_>this is in emacs's ".el" file
<oriansj>ok
<oriansj>that would probably do it
<nixo_>ops, my battery died
<nixo_>my last message was about the fact that this is done from emacs during runtime
<bandali>leoprikler, hey, you around?
<leoprikler>yep
<bandali>awesome
<bandali>so a few days ago valignatev pointed me to https://github.com/valignatev/guix-channel/blob/master/valignatev/packages/emacs-master.scm
<bandali>and said you helped them write it
<bandali>i was wondering if you could help answer a few questions i had about it
<leoprikler>sure
<bandali>awesome
<bandali>okay, so first off, it looks to me that the (snippet ...) bit is pretty much identical to the original emacs package, so i was thinking of omit it
<bandali>*omitting
<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.
<leoprikler>s/came up/came up with/
<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 :)
<nixo_>Just sent the patch for odt export :)
***ng0_ is now known as ng0
<jonsger> how can I use more then two sources in a package definition?
<nckx>jonsger: Add them as inputs?
<jonsger>nckx: is there somewhere an example?
<nckx>jonsger: Many, I'm sure. Let me grep.
<nckx>jonsger: isc-dhcp, axoloti-runtime.
<nckx>I'm sure there are more minimal examples if you keep looking.
<lispmacs>hi
<jonsger>thanks nckx
<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
<wdkrnls>Hi Guix
<wdkrnls>I'm trying to figure out when it's safe to upgrade my packages.
<zig>o/
<wdkrnls>I know the stock answer is to use guix weather.
<wdkrnls>However, it does not seem to have any integration with the %current-profile.
<wdkrnls>It makes you have to explicitly specify a manifest.
<wdkrnls>I saw in (guix profiles) that I can make a manifest object from my current profile, but it's not clear to me how I could use it from guix weather.
<wdkrnls>I suppose I could somehow make a temp file with the serialization (how?) of my manifest.
<jonsger>why does (invoke "cp" (string-append (assoc-ref inputs "libgnome-volume-control-source") "/*.h") "subprojects/gvc") not work? my opensuse `cp` can do it :)
<jonsger>cp: cannot stat '/gnu/store/9pca4yy4hcjp34lg1sc72cbb84qzq2hy-phosh-0.1.5-checkout/*.h': No such file or directory
<jonsger>ah nice got it. copy-recursivly is the solution :)
<bandali>sneek: tell valignatev: would you please ping me whenever you're around? got a couple questions about your emacs-git package?
<sneek>valignatev:, bandali says: would you please ping me whenever you're around? got a couple questions about your emacs-git package?
<bandali>-_-
<bandali>sneek: later tell valignatev: would you please ping me whenever you're around? got a couple questions about your emacs-git package?
<sneek>Will do.
<bandali>sneek, botsnack
<sneek>:)
<nckx>jonsger: * etc. only mean something magical to (some) shells. It was your opensuse bash turning the arguments into something else before your opensuse cp ever saw them 🙂
<jonsger>:)
<lispmacs>pkill9: how do I do that?
<nckx>lispmacs: (add-before 'configure 'enter-source-directory (lambda _ (chdir "the-directory-name") #t))
<lispmacs>nckx: does that go inside the package s-exp?
<nckx>chdir is stateful and persists across phases (which is why prefer with-directory-excursion is usually preferred) but its appropriate here.
<nckx>lispmacs: It goes inside your (modify-phases %standard-phases …) after the #:phases keyword in your arguments field.
<lispmacs>so, like (arguments #:phases (modify-phases %standard-phases
<lispmacs> (add-before 'configure
<lispmacs> 'enter-source-directory (lambda _ (chdir
<lispmacs> "the-directory-name") #t))))
<nckx>(arguments `(#phases, and no newline after 'configure, but otherwise looks legit.
<nckx>You should really know this by heart if you're writing packages, or you're entering a world of pain and confusing error messages. Examples abound (understatement) in gnu/packages/*.scm!
<Minall>o/
<lispmacs>nckx: definitely don't know this by heart
<lispmacs>why would it be `(#phases?
<lispmacs>isn't #:phases a keyword too arguments proc?
<nckx>I can see why you think that, but (arguments …) is a record field, not a procedure. Its value is a quoted #:keyword-argument list which *is* passed to a procedure at build time.
<nckx>You're not wrong but there's an extra level of indirection.
<lispmacs>nckx: oh, okay
<nckx>And #phases was of course a typo → #:phases.
<nckx>\o Minall.
<Minall>nckx: \o/
<nckx>~o~
<lispmacs>nckx: is it supposed to be `(#:phases or '(#:phases like in the manual example?
<Minall>nckx: You win
<nckx>lispmacs: Eehhh… it ‘depends’ 🙂 If you don't need to unquote (,) a single thing inside it doesn't matter and you can use ', but you need ` if you're unquoting anything.
<lispmacs>nckx: okay, nothing being unquoted here
<lispmacs>sorry, I should be more proficient in guile by now, but many distractions in RealLife
<lispmacs>mainly one involving trying to keep bills paid
<nckx>I don't actually know if there's a performance impact. In practice I'm sure I use ` more than is strictly necessary.
<lispmacs>the other one is toddlers
<nckx>lispmacs: No need to apologise.
<nckx>The people who should never do, and those who do are usually the one actually trying to learn.
<nckx>*s
<lispmacs>okay, I'm still getting a build error, but now it's a new one!
<lispmacs>i think that's progress
<nckx>\o/
<lispmacs>toddler just rebooted the computer. hopefully didn't miss anything important
<lispmacs>I can disable the power button but not the restart button, heh heh
<nckx>You missed nothing, but don't forget about logs.guix.gnu.org.
<Minall>What are some browsers that I can install on guix?, besides icecat and epiphany-browser?
<wdkrnls>Minall: next, nomad are some lispy ones you could install.
<wdkrnls>Minall: otherwise there is ungoogled-chromium
<civodul>janneke: do you mind if i push your #:implicit-inputs? patch for guile-build-system to master?
<Minall>wdkrnls: On it!, thanks!
<jonsger>brettgilio: I seperated the patches in http://issues.guix.gnu.org/issue/38588 and found another typo :)
<brettgilio>jonsger: thanks :) i will check it out when I get on my laptop.
<jonsger>brettgilio: no hurry :)
<brettgilio>The baby kept my wife and I up all night, so I am a bit delirious. :)
<brettgilio>civodul, nckx: when you get a moment will you look at bugs.gnu.org/38605? It has a bootstrapping issue I was hoping you might be able to weigh in on.
<jonsger>:) the first "baby" (dependent package) of libhandy is still in the makes :P
<nckx>brettgilio: Any specific questions? You're def right that patched ELF binaries are not upstream material.
<nckx>brettgilio: Random aside: you don't need a separate ‘register foo.scm’ patch. Just add & register in one.
<nckx>lispmacs: That's hilarious. Is your toddler named Molly by any chance?
<nckx> (https://packages.debian.org/sid/molly-guard)
<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.
<brettgilio>That said, even polyml has some blobs in it. What kind of blobs __are__ permissable in these instances? Like check this out. All plaintext blobs. https://github.com/polyml/polyml/tree/master/imports
<ngz>Hello. I am experiencing a strange issue with Emacs. It doesn't load installed packages, i.e., Guix Emacs packages do not seem to appear in the load-path. Is it a known issue?
<nckx>brettgilio: There's no hard & fast rule; the blobs you do see in Guix shouldn't be there, they're just tolerated on an ad-hoc (& probably arbitrary & unfair) basis.
<civodul>brettgilio: re MLton, i've just replied, essentially to confirm what you wrote :-)
<civodul>ngz: could it be related to the recent EMACSLOADPATH changes?
<brettgilio>We need to give Maxim a job with these EMACSLOADPATH issues haha.
<civodul>i think snape said this was fixed with the latest changes apteryx made
<civodul>heh
<nckx>brettgilio: TBH I'm not familiar at all with MLs, so can't say anything sensible without reading much more.
<brettgilio>nckx: no worries. :) Just wanted to see if there is anything worth considering
<brettgilio>civodul: thanks, I'll check back in a few.
<ngz>civodul: I just guix pull'ed to no avail though.
<brettgilio>ngz: guix describe and echo EMACSLOADPATH pls
<brettgilio>Use a pastebin service if it is long
<ngz>EMACSLOADPATH is empty
<ngz> guix 5c1bd7b (in short)
<ngz>
<ngz>I think I get it. I need to source .profile again. Let me check.
<ngz>Brettgilio: Sourcing .profile wasn't enough. I rebooted. Sigh. Here goes my uptime…
<ngz>In any case, the issue is now fixed.
<ngz>Thank you for pointing me to the right track.
<brettgilio>Is there a way to disable bytecompiling for a single file in the emacs-build-system?
<brettgilio>I am looking in the emacs-build-system file and I don't see where bytecompilation is referenced
<brettgilio>Nvm found it
<leoprikler>perhaps you can trick the build system by moving it elsewhere temporarily
<leoprikler>alternatively, you can add the file to #:exclude and install it after compilation
<brettgilio>God I love the time-machine feature.
<leoprikler>(since the compilation happens in-place)
<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.
<leoprikler>IOW a #:no-bytecomp list of regexps
<leoprikler>brettgilio: perhaps you can disable byte-compilation through file-local-variables as well
<leoprikler>The compilation phase uses byte-recompile-directory, which should read the variables from the source file.
<brettgilio>leoprikler: i like your #:no-bytecomp suggestion. I am going to open a bug report for it, I can't do it myself today.
<brettgilio>Moment
<brettgilio>I reported it leoprikler
<brettgilio>Parra: ;)
<Parra>brettgilio: hello!
<Parra>at the end I'm going back to guix
<Parra>it's impossible to do it by hand
<Parra>I have two branches right now, feature/build-scratch and feature/build-guix
<Parra>guix has some frictions but at the end it pays off
<kirisime>python-pyside-2 fails to build for me.
<brettgilio>kirisime: send log in bug report
<civodul>ngz: could you file a bug report (if there isn't one already)?
<lispmacs>what is the difference between an input and a native input?
<civodul>lispmacs: it has to do with cross-compilation, see https://guix.gnu.org/manual/en/html_node/package-Reference.html
<lispmacs>my package is failing to build now because the test phase is failing, there being no tests existing in the source. How do I disable the test phase?
<lispmacs>I'm using the cmake-build-system
<nckx>lispmacs: #:tests? #f
<nckx>At the same level as #:phases.
<lispmacs>nckx: thx
<nckx>And add a ‘; no test suite’ comment so people know why it's there.
<lispmacs>okay
<lispmacs>you mean, #| no test suite |#
<lispmacs>that will look fancier
<lispmacs>well, miracle of miracles, it finished building
<lispmacs>the install license files phase is complaining though about not finding the license files
<nckx>lispmacs: Are there any?
<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>Ah, that's probably it.
<brettgilio>Thanks nckx
<bandali>the fsf sysadmins are working on resolving it
<lispmacs>nckx: I am using cmake-build-system, also
<brettgilio>I mean bandali
<bandali>hehe :) no problem brettgilio
<nckx>lispmacs: (add-before 'install-license-files 'change-back (lambda _ (chdir "..") #t)), I guess.
<nckx>If there's a prettier way please do think of it.
<nckx>lispmacs: The phase is in gnu-build-system.
<nckx>Build systems can inherit from each other; most inherit from GNU.
<lispmacs>ah, okay
<lispmacs>that worked
<nckx>So… you have a working build?
<ngz>civodul: I solved the problem by rebooting, so there's no bug to report :)
<lispmacs>nckx: I see the bin and lib files in the store, haven't tried any of them yet
<nckx>Party hard.
<lispmacs>nckx: there is a complaint by the source's configure run that no udev rule has been specified, but guix didn't notice
<lispmacs>this is a library that allows you to connect an SDR radio over USB, so that might be an issue
<lispmacs>"HackRF udev rules will not be installed because no suitable group was found
<lispmacs>-- A group can be specified with -DUDEV_RULES_GROUP=<group>"
<brettgilio>leoprikler: here is that issue report for that proposed feature http://issues.guix.gnu.org/issue/38613
<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
*nckx just got hit by the mail wave.
<brettgilio>nckx: don't let the size of that mail wave drag you under the tide. Haha
*bandali is bracing for the wave
<nckx>(It wasn't that bad, just compared to the ‘silent… too silent’ rest of the day.)
<bandali>ha
***jje_ is now known as jje
<brettgilio>bandali: What is your name?
<brettgilio>Idk people's IRC aliases well.
<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.
<nckx>(Use assoc-ref though, it's better™.)
<lispmacs>what do you know, this is documented
<lispmacs>-DUDEV_RULES_PATH=/path/to/udev
<lispmacs>hackrf documentation says that by default it tries to give `usb` or `plugdev` group access to HackRF
<lispmacs>unless I specify DUDEV_RULES_GROUP
<lispmacs>nckx: what is the guix equivalent of the usb or plugdev group?
<nckx>lispmacs: dialout.
<nckx>Yes, I know.
<nckx>Accept it 😛
<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'"
<raingloom>(happens with both 7.0 and 8.0)
<nckx>raingloom: Looks like a packaging bug.
<nckx>If I'm right, the fix would look something like https://www.mail-archive.com/guix-commits@gnu.org/msg78895.html.
<mehlon>is it normal that it takes a long time to guix pull?
<nckx>mehlon: It's not unusual.
<nckx>(♪)
<mehlon>I have a guix/nix/windows triple boot so I can use all three
<nckx>It's more CPU-intensive than most people realise, and if there are no substitutes available then it takes a good while.
<str1ngs>mehlon: is it hanging? savannah has been flaky lately
<mehlon>well no it just compiles like a million things
<str1ngs>maybe you are not setup to use substitutes mehlon
<nckx>Unlikely on Guix System but who knows.
<mehlon>I did a standard install with 1.0.1
<str1ngs>I missed the guix system bit
<mehlon>ah yes, I am talking about GuixSD
<nckx>mehlon: You should be set to use substitutes then.
<nckx>I don't actually know a robust one-liner to test that.
<mehlon>I'll have to try again later
<str1ngs>best way to test. is guix build foo for a package that has not been downloaded before. of you can gc a package
<str1ngs>also guix weather is useful.
<nckx>Also ‘sudo grep 5741A840FF2D24F60F7B6C4 /etc/guix/acl’ should return something, but 1.0.1 would have the ‘new’ key.
<nckx>~ already.
<mehlon>I noticed that nix is a package in guix
<mehlon>however, guix is not a package in nix !
<nckx>Hmph.
<nckx>I'm mildly surprised.
<mehlon>and no one's requested it yet
<mehlon>I'm going to open a gh issue
<nckx>I really thought it was in Nix when I used it.
<nckx>Ah, I am not mad (well): https://github.com/NixOS/nixpkgs/commit/5dab370d7779b0e372da00dcd262c64c2d8b58eb
<mehlon>oh
<mehlon>nevermind then
<nckx>mehlon: Just asking someone to add it won't really work, packages need maintainers that care & keep bitrot at bay.