IRC channel logs


back to list of logs

<ryanprior>Still won't build with this modified package definition, and the `localstate=/var` configuration:
<ryanprior>Still same error about "no code for module (gnu packages harvey)"
<lfam>ryanprior: Works for me with the linked diff and the command `./pre-inst-env guix build harvey`.
<lfam>The difference is that I removed the extraneous "harvey" line at the end and added the file to 'gnu/'
<lfam>Also I ran `make` after applying the diff
<ryanprior>X.X well jeez, I dunno how my system is so busted then
<ryanprior>I did add it to my, before I did that it didn't recognize it at all.
<ryanprior>Also I can't run `pre-inst-env guix build harvey` because `make` won't complete at all.
<lfam>Okay, what goes wrong when you run make?
<lfam>That needs to be working before proceeding
<ryanprior>When I run make:
<lfam>ryanprior: That seems like something related to your ~/.bashrc, but I don't know
<lfam>I'm guessing you export some variables in ~/.bashrc that are messing with `guix environment guix`
<ngz>lfam: Then wouldn't "guix environment --pure guix" help?
<lfam>ngz: No, because ~/.bashrc is executed each time a shell is started
<lfam>Bash environment variables should be exported for login shells (~/.bash_profile) but not interactive shells
<ryanprior>I just did `make clean` and I'm retrying with `guix environment --pure guix`.
<ryanprior>Also worth noting that I'm on the 1.0.1 tag, in case that matters.
<lfam>I think 1.0.1 is good for this
<lfam>The tricky part will be figuring out what that vte thing is
<lfam>Hard to do from here
<ryanprior>Oh the vte thing happens whenever I use `guix environment`, I've tried to track it down & don't know what's up. There's no reference to vte-anything in my bashrc.
<ryanprior>What I'm trying right now is moving my bashrc file and starting over.
<ryanprior>Here's the result of that: same exact error, but no __vte_whatever now that my bashrc is gone
<ryanprior>I suspect the vte thing is benign, the real issue sems to be that it cannot find the module for my harvey package
<ngz>where did you put the harvey.scm file?
<xavierm02>rekado_ : I can't find a way to add that to my bug report, but I tried replacing the texlive-union in the propagated inputs by the full texlive, and it didn't seem to help.
<xavierm02>And I also tried telling LyX which pdflatex to use, which didn't help either. After telling lyx which pdflatex to use, it gives the error support/Systemcall.cpp (276): Systemcall: '/gnu/store/qlg22dwl8i70qx68jz5p4j0ky0h941mw-texlive-20180414/bin/pdflatex "TTT.tex"' finished with exit code 1
<xavierm02>but /gnu/store/qlg22dwl8i70qx68jz5p4j0ky0h941mw-texlive-20180414/bin/pdflatex "TTT.tex" in a terminal works just fine
<xavierm02>so my next guess is that it's about some environment variables
<poet`>Hello. Is anyone able to tell me what I've done wrong? I'm on Debian 10, and no matter which guix command I enter, I get this:
***poet` is now known as poet
***scs is now known as Guest89253
<lfam>poet: It's harmless
<poet>lfam: It happens with every command I run though, and it takes a while to get through all the warnings.
<lfam>poet: It's definitely surprising and I'm not sure why you are seeing it
<lfam>Can you check the timestamps of one of the scm / go pairs?
<poet>One moment please...
<lfam>Every timestamp in /gnu/store should be from Dec 31 1969
<poet>Most of them are 12/31/69, but not all:
<lfam>poet: That file in your 2nd pic, 2019-08-12_17.png is strange
<lfam>It looks like your /gnu/store has been altered "by hand"
<lfam>All changes in /gnu/store must happen with the Guix tools and managed by the guix-daemon
<poet>What should I do? Start the install process all over again?
<lfam>I suppose but let's figure out what went wrong
<lfam>Which instructions were you following?
<lfam>Also, you didn't share the timestamps of the files I asked about, which are the scm / go pairs from your initial picture
<poet>Okay. Lemmie explain first: I'm on a Lenovo Yoga 2. I believe it has a bad motherboard, because when the download speed gets too fast, everything freezes. I ran the shell script to install guix, and it froze... so yes, you're right, I did install some things by hand.
<lfam>Do you mean you moved the files into /gnu/store by hand?
<lfam>Sorry, but that won't work. The guix-daemon has to do the work because it records the results in a database. This database is how Guix knows what's in the store
<lfam>The problem with the freezing computer is tricky though...
<poet>Yes, indeed it is. =(
<poet>I had another problem with the shell script...
<poet>When it tried to move /gnu/store and var/(something), it couldn't, because the directories weren't empty. So I changed the commands to cp -rvf
<poet>Should I change the wget commands in the script to "wget --continue" to overcome the freezing problem?
<lfam>For the first thing, if those directories aren't empty then it means you should delete them before trying the installation again
<poet>Ahh okay...
<lfam>For the second, I suppose, although I'm not sure which file is the one in question
<Minall>Hello guix!
<lfam>Hi Minall
<Minall>quiliro: Kiel vi Fartas!
<Minall>lfam: o/
<poet>It's the install script I got from the official guix website...
<lfam>poet: I mean, which file needs to be continued?
<lfam>Anyways, I think that if you are comfortable with the command line at all, you should just do the manual install rather than the shell script. It's not too complicated
<lfam>That's assuming you are installing the Guix to be used on Debian, not a full Guix system
<lfam>I suggest it because it will be a little easier to know what it's doing and where it goes wrong, and how to work around any potential issues
<poet>Definitely guix on Debian on this crappy Yoga for now, but I ultimately want to move to the Guix distribution. I'm a big GNU fan...
<poet>I want to learn it though...
<poet>lfam: One more thing please...
<lfam>Eventually it would be good to fix the freezing issue, because Guix is more resource intensive than Debian
<lfam>I use Guix on Debian on my primary computers and it's a nice combo
<poet>lfam: I don't think it's fixable. =( I haven't been able to isolate the issue, and I've looked *everywhere*
<lfam>Oh well, that's too bad
<lfam>Wild how these computers that are incredibly powerful have issues like this
<lfam>What's the other thing?
<poet>I'm going to try compiling everything manually... should I wipe the previous guix install completely clean?
<lfam>Yes. I would delete /gnu and /var/guix
<poet>Okay. Will do. I'll probably be back later or tomorrow. Thank you for your help, my friend. I genuinely appreciate it. =)
<lfam>We are happy to help :) Good luck
***scs is now known as Guest37443
<poet>Ohh shoot, lfam left. =(
<poet>Okay, I have a question I hope someone can answer...
<poet>I built guix manually, and this time everything seems to be working...
<poet>Then, per the instructions, I did "guix install hello"
<poet>Then guix started downloading and (is now) building a bunch of software, including linux-libre:
<will`>Hello everyone! =D
<efraim>poet: looks like you forgot to enable substitutes
<will`>Hello Guys! I have a question
<will`>Im new in GuixSD
<will`>and I already installed it in a virtual machine
<will`>but something strange happen (ramdomly)
<will`>when I log in DGM
<will`>sometimes I can get the Desktop environment (Mate or awesomeWM)
<will`>but other times after login it keep 'frozen' in the session manager
<will`>when that happen I move to the fist TTY
<will`>and try to stop restart the xorg server
<will`>but other weird thing happen then. If I use `sudo herd stop xorg-server`
<will`>it doesn't stop the process correctly and the screen keep in black. sometimes get back, others not
<will`>the only way to kill correctly the xorg-server is doing a `kill -9 [pid]`
<will`>someone else has the same problem?
<dafdafdafs>I want to use Guix on my non-root Android phone. Can it put the prefix in a private directory of /data like gentooprefix?
<nckx>will`: GDM itself is buggy and crashes a lot, but I haven't heard of it freezing (although I haven't been around a lot lately). Care to file a bug report at
<will`>nckx: Ok! do I need to attach some logfile?
<nckx>I'm afraid I wouldn't know as I don't use GDM.
<nckx>will`: If /var/log/gdm exists it might have goodies.
<will`>nckx: BTW, actually GDM doesn't get frozen at all. If I move to TTY 1 and then comeback to TTY 7, the login screen appears again (like comming back from the sleep). If I text my username and password again, the same happen again (just keep in there without take me to the desktop environment)
<str1ngs>will`: could be a Xsesson issue have you checked $HOME/ for .Xsession error logs?
<will`>nckx: Thanks! yeah! there is a log file in that path. Thank for you help! I'm goint to report the bug now
<will`>nckx: let me check
<nckx>s/nckx/str1ngs/ who hopefully knows more about GDM & frenemies.
*nckx → 😴 o/
<will`>I haven't any .Xsession file in my $HOME/ =/... its ok, I think the gdm log will be enough to report
<str1ngs>sneek: later tell will` it would be .xsession-errors case sensitive
<sneek>Got it.
***scs is now known as Guest80137
***byzoni[m] is now known as cyberwolf[m]
<nexgen>hello, why not adding more initialization systems like OpenRC? is it possible in the future?
<nexgen>for example devuan offers many RC systems for a user choice
<efraim>You're welcome to hack on Guix and try to add it in but for now Guix System assumes you're using Shepherd
<nexgen>is not GUIX tightly bound to Shepherd RC?
<nexgen>I do not argue against shepherd until it is light weight apposite to systemD
<nexgen>but who knows what happens later
<nexgen>may be shepherd will become a next systemD
<efraim>Systemd is actually not spelled with a capital D
<nexgen>but there is no Devuan alternative for GUIX
<nexgen>I type it capitalized to better indicate it is RC
<nexgen>*while it is light weight
<nexgen>about shepherd
<str1ngs>nexgen: the issue is if say you use openrc then you need a way to create services from scheme. due to functional nature of guix. because shepherd is configurable using scheme. it make more sense just to use it
<efraim>For the most part the services create config files which are passed to the daemons of the services. Like I said, if you're interested you're welcome to work on it.
<rain2>shepherd has code from systemd in it: elogind
***scs is now known as Guest61143
<nexgen>hopefully after getting more popularity GUIX will get alternatives for RC system
<nexgen>or will be forked the same way as Devuan is continuously being forked from Debian
<garjola>Is down?
<nly>is reachable for me
<garjola>Mmmm. Server not found.
<garjola>Whatever ...
<garjola>I have installed the guix package manager and I am having trouble with locales
<huuskes>well it just died for me
<garjola>guile: warning: failed to install locale
<garjola>substitute: /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
<garjola>substitute: /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
<garjola>I used the provided script for the installation (I am on Debian Buster) and PATH, GUIX_PROFILE etc. are OK
<garjola>This locale problem seems to affect also apps using gtk
<garjola>(process:7578): Gtk-WARNING **: 10:06:18.326: Locale not supported by C library.
<garjola> Using the fallback 'C' locale.
<nly>since this this is a new install, have you run 'guix pull' yet?
<nly>btw, substitutes are reachable for me
***scs is now known as Guest83406
<garjola>I did (I think!). Doing it again.
*nly guix build glibc-locales succeeds
<nly>i believe you must be following this manual:
<garjola>nly: Yes
<nly>section 8: "Application setup" does go over locales
<nly>maybe you've alceady done that?
<garjola>Well, I can't read the manual since I can't connect to guix's web site ;)
<garjola>But I didn't do anything special about locales. Is this doc available throug *info*?
<nly>yes, using 'info guix'
<garjola>Doing: guix install glibc-locales
<garjola>OK. Locale problem solved! Thanks!
<garjola>And I see that I still need to do other things like nscd and fonts.
<nly>great! :)
<nexgen>please let me know, how get correct environment after chrooting into GUIX from another system?
<nexgen>may be some script shall be executed
<nexgen>I miss even ls command after chroot
<efraim>can I force a package's source with a snippet to be gzipped instead of xzipped?
<efraim>doesn't look like it, looks like its unconditionally xz
<janneke>efraim: for bootstrapping it would be great to have it compres'ed
<janneke>the same goes for patches, i think
<jlicht>hey guix
<OriansJ>efraim: the unconditionally xz presents a bootstrap problem; as xz depends upon gz for it's compression of its source code and gz depends upon tar and down the rabbit hole
<efraim>I see
<efraim>janneke, OriansJ: so would gzip be better?
<OriansJ>efraim: simply allow the choice to be decided by the package name
<efraim>I just wanted to apply a snippet or patch to some rust crates :)
<OriansJ>*.xz gets uncompressed as .xz, *.gz gets uncompressed as .gz and so on;
<efraim>I mean if I have source.tar.gz and apply a patch the source that gets unpacked for building is source.tar.xz
***scs is now known as Guest94852
<janneke>efraim: gzip would not help me, we have a working uncompress in guile which could be used to eliminate xz from the bootstrap binaries
<janneke>efraim: oh wait, yes -- using gzip could help to move the need for xz further down the bootstrap path too
<janneke>gzip is pretty easy to build, xz is a pain
<efraim>I was only thinking of making it a flag option, like patch level is
<efraim>bzip is being ported to rust!
<janneke>i have no pressing need for this, the first target is removing coreutils&co
<janneke>good, we can have years of fun raising bootstrapping awareness :)
<OriansJ>janneke: decades atleast
<janneke>yes, you're probably right
<janneke>efraim: so what i meant to say was, if this gets attention let's consider making the compressor parameterizable
<efraim>janneke: sounds good
<janneke>we also have tar in guile, so civodul suggested iwbn to try creating a guile binary executable+payload to jumpstart a guix-based bootstrap process
<janneke>...but it all might flow/fork down another path, who knows
<reepca>libstdc++ in (gnu packages commencement) puts its output libraries in lib/ normally, but in lib64/ when built in test-env. That's really bizarre.
<reepca>and of course, gcc-final in the same module looks for libstdc++ under the lib/ directory, so by extension gcc-final fails to build in test-env
<janneke>nexgen: you probably want to do something like . /var/guix/profiles/per-user/root/current-guix/etc/profile, but ymmv
<janneke>it depends on what you are doing and trying to achieve
<nexgen>there is present file: /var/guix/profiles/per-user/root/guix-profile/etc/profile
<nexgen>current-guix is missing
<nexgen>I have installed GUIX in a virtual machine and it works fine
<nexgen>then mounted the same block device in a chroot of another OS
<nexgen>all commands are missing except bash embedded ones
<nexgen>actually I had to create a /bin/sh2 symlink to full path from point of view of the host from which chrooting happened
<nexgen>then issued: chroot /mnt/d1 /bin/sh2
<nexgen>now missing correct PATH and/or LFH to have any other command like ls
<nexgen>cannot run anything except embedded sh commands
<nexgen>sourcing /var/guix/profiles/per-user/root/guix-profile/etc/profile
<nexgen>did not help
<reepca>nexgen: how did you set up the chroot directory? Is /etc/profile present?
<nexgen>I mounted many dirs and files from host
<nexgen>just a moment
<nexgen>etc profile is present
<nexgen>sourcing it helped
<nexgen>thank you very much
<nexgen>another problem
<nexgen>guix pull does not want to work without some sockets, most likely related to shepherd
<nexgen>how can I start shepherd in a chroot?
<str1ngs>nexgen: you need a guix-daemon instance in the chroot
<reepca>AFAIK the only sockets guix pull should be concerned with are the one to talk to the daemon and those necessary for downloading from the internet.
<str1ngs>also I think you are better off just creating a container then using a chroot.
<str1ngs>guix is not FHS either
<str1ngs>though maybe a vm would be better if you want to test services and file structures now that I think about it.
***scs is now known as Guest71829
<ngz>When I want to recompile Guix, from an appropriate environment, I get "In procedure abi-check: #<record-type <operating-system>>: record ABI mismatch; recompilation needed".
<ngz>How could I fix that? I tried recompiling, but the error is the same.
<reepca>'make clean-go' would probably do it, but it's a longish recompile
<reepca>also, how exactly does libstdc++ in (gnu packages commencement) have *any* inputs? It has #:implicit-inputs? #f, and empty inputs, native-inputs, and propagated-inputs. Are there implicit-implicit inputs?
<ngz>reepca: Trying a recompile after a make clean-go. Thank you for the tip.
<reepca>ngz: the situation reminds me of
<ngz>So true.
<zaab>Hello I am completely new to guix and scheme. Can anyone spot why this is wrong?
<zaab>fails with "no code for module (guix package)"
<zaab>Another thing, I am interested in how I can discover interactively, e.g. how can I find the value of %standard-phases?
<zaab>from the guile rep
<reepca>zaab: the module is (guix packages), with an 's'.
<reepca>%standard-phases has different bindings for each build system, and is generally 'build-side' code. So for example, you could (use-modules (guix build gnu-build-system)) and then evaluate %standard-phases and it would print out the list of name-procedure pairs.
<reepca>Or if you're just giving it a one-off glance, you could also just evaluate (@ (guix build gnu-build-system) %standard-phases) in the repl.
<reepca>It might help to pretty-print it like so: ,pp (@ (guix build gnu-build-system) %standard-phases)
<reepca>also, there's another (understandable) reason your snippet is wrong: #:phases is most likely not bound to a procedure, but as it currently is it will be evaluated as a procedure. You can quote it to prevent evaluation, like so: '(#:phases (modify-phases ...))
<reepca>gah, I'm an idiot, didn't notice the inputs field of libstdc++
<reepca>been awake too long
<__Myst__>does guix support the propietary nvidia drivers?
<NewUser-57387>Hi, I installed Guix System a few hours ago. I would like to declare my to-be-installed packages in a file. I am thinking the globally-visible ones. Should I change /etc/config.scm and run `guix system reconfigure /etc/config.scm` from the root user? Or can/should it be done from my normal user? Thanks
<ngz>Globally visible packages should belong to /etc/config.scm.
<ngz>__Myst__: Guix relies on Linux Libre kernel, so, out of the box, there is no support for such hardware. However, it is possible to use any kernel you want.
<__Myst__>ngz: what do you mean by "no support" here?
<__Myst__>i'm on a dual-GPU laptop, as in I have an iGPU and an Nvidia 930MX
<ngz>I mean that out of the box, no proprietary driver, or firmware, is supported.
<ngz>As is: hardware does not work.
<__Myst__>So do I get no video output?
<reepca>__Myst__: Check to be sure about your hardware, but most recent AMD and NVIDIA cards require proprietary firmware for pretty much any acceleration (and to make it worse, the firmware is signed, so it's impossible to develop free replacements). It's possible rending unaccelerated to a single video output might work, though.
<__Myst__>reepca: I'm fine with NVIDIA propietary drivers for the simple reason that no good opensource exists or AFAIUI can exist
<NewUser-57387>ngz: Thanks. Is there a standard location of a manifest file for normal users, for user with `guix package --manifest`, or should I just choose my own "random" place for it?
<ngz>NewUser-57387: Choose your own.
***scs is now known as Guest35710
<HolyPanda>Hello, can someone please explain to me the following snippet from the manual (section 8.1): "One should never have to touch files in /etc or to run commands that modify the system state such as useradd or grub-install. In fact, you must avoid that since that would not only void your warranty but also prevent you from rolling back to previous versi
<HolyPanda>ons of your system, should you ever need to."
<HolyPanda>What is this warranty mentioned? What do I have a warranty on? I thought all GNU software has no warranty, _to the extent permitted by law_.
<reepca>HolyPanda: not a literal warranty, but a more general use of the phrase to mean "it's not meant to be used that way and stuff may break".
<bandali>HolyPanda, afaiu that’s just a play on words :) or a common expression, if you will
<reepca>although of course I'm not a lawyer and one might be able to twist that wording
<bandali>the point is that you should configure guix through a configuration file (usually /etc/config.scm but can be placed anywhere)
<HolyPanda>Okay, yes, I understand that. I was just confused by the use of the word warranty. Thanks for clearing that up.
<erudition>Haha yeah they're joking around
<mbakke>efraim: Rust failed to build on 'staging':
<reepca>I've tracked down the libstdc++ mis-build to gcc-boot0-wrapped providing different answers to 'g++ -print-multi-os-directory' depending on whether it was built in test-env or not. Anyone have any idea why that would change?
<ngz>During asymptote package compilation, I get this failure: It looks like a missing texlive package or some such. Anyone have an idea about what could be wrong?
<NewUser-57387>Is there any reason to not use globally visible packages for everything, if I only have a root and one normal user?
<reepca>NewUser-57387: changing globally-visible packages (adding or removing) requires root access and a full reconfigure. If you're keen on updating your system extremely frequently, I guess it's not a huge problem.
<reepca>ngz: I dunno much about texlive, but it mentions asymptote.log and CAD.log. Did you use --keep-failed?
<ngz>No, I didn't.
<ngz>Compiling again.
<ngz>It is not very long anyways.
<rekado>ngz: the texlive-epsf package should provide the missing file.
<vagrantc>NewUser-57387: occasionally something will fail to build, and having a minimal system configuration increases the liklihood of always being able to at least upgrade the system or the user's profile
<rekado>ngz: and ltxguide.cls is provided by texlive-latex-base.
<ngz>rekado: Aaahhh! Thank you.
<vagrantc>NewUser-57387: it's also a little easier to see which packages are in the user profile than the system profile
<NewUser-57387>reepca: Okay, thank you. So running reconfigure rebuilds a lot of stuff even though I only added a package?
<NewUser-57387>vagrantc: Okay that makes sense, thanks!
<reepca>NewUser-57387: it may or may not, depending on how much has changed since you last reconfigured (for example, if you've ran 'guix pull' and the kernel was updated, that will be updated as well). But it will always at least build a new system profile if anything has changed.
<NewUser-57387>reepca: Okay, makes sense! So should I both run 'guix pull' on my normal user, and 'guix pull' on root (less often)?
<ngz>rekado: I added texlive-latex-base to native inputs, but ltxguide.cls is still missing =/
<vagrantc>NewUser-57387: sudo -E guix system reconfigure ... should use the user's guix, so you only have to pull once
<zaab>any idea how I can debug something like a package definition that fails? specifically this
<NewUser-57387-re>Ah nice, thanks! So I all I have to do to keep my system up to date is run `guix pull && sudo -E guix system reconfigure /etc/config.scm` right?
<vagrantc>NewUser-57387-re: && guix package -u .
<reepca>Your *system*, yes, your user's profile can be kept up-to-date by also running 'guix package -u' after 'guix pull'.
<vagrantc>heh :)
<vagrantc>or using a manifest file for the user profile, which i really need to get in the habit of doing...
<NewUser-57387-re>Okay great :)
<ngz>vagrantc: Don't forget to write a blog post about it once you get that habit ;)
<NewUser-57387-re>Wait haha, so if using a manifest file, should i replace 'guix package -u' with 'guix package -m ~/manifest' ?
<reepca>zaab: see section 7.1.4 of the info manual: info guix 'Debugging Build Failures'
<zaab>reepca: thanks
<rekado>ngz: did you add it to the texlive-union?
<ngz>rekado: Yes, texlive-union is currently applied to this: (list texlive-amsfonts texlive-epsf texlive-latex-base texlive-latex-geometry texlive-latex-graphics texlive-latex-oberdiek texlive-latex-parskip texlive-tex-texinfo)
<nexgen>good evening or a time of the day
<nexgen>still not able to run shepherd in a chroot
<nexgen>etc profile works fine for get a working subset of LFH
<nexgen>epherd[19085]: system-error("open-file" "~A: ~S" ("No such file or directory" "/gnu/store/bhdbw9zn302rjzn838rms5j3qc8z5w8p-shepherd-0.6.1/etc/shepherd.scm") (2))
<nexgen>may be some more profile scripts need to be sourced
<nexgen>etc is missing in the /gnu/store/bhdbw9zn302rjzn838rms5j3qc8z5w8p-shepherd-0.6.1/
<nexgen> /etc/shepherd.scm is missing either
<nexgen>well, will try to bood in a VM to see where /etc/shepherd.scm shall link to
<nexgen>according to vm ps -Af there is another path for shepherd config
<nexgen> /gnu/store/xxx-shepherd.conf
<nexgen>how can I easily refer to it without complex xxx part?
<nexgen>does a symlink exist somewhere which could be reused by me in this situation of a chrooting
<nexgen>ran find
<nexgen> /gnu/store is the only
<nexgen>for now decided to solve this by creating a directory /links
<nexgen>and placing custom symlinks there
<mbakke>nexgen: you can start shepherd with "--config /your/custom/shepherd.conf"
<efraim>mbakke: I'm out right now, I'll take a look at it tomorrow
<mbakke>efraim: no worries, i'll just merge an earlier revision of staging
<zaab>hey can I symlink nvim->vim in my system definition?
<zaab>i will be back in a moment
***scs is now known as Guest57296
<sebboh>hello guix. How should I install quicklisp? The upstream project's installation method is to download and execute (load) quicklisp.lisp. The result is the creation of a directory in $HOME and optionally modification of your common lisp implementation's rc file. (so, .sbclrc or whatever.)
<rekado>zaab: yes, you can. Look for special-files-service-type in the manual.
<zaab>rekado: wheres a good place for the symlink to be in guix?
<zaab>is $GUIX_PROFILE/bin fine?
<zaab>rekado: what about setting environment variables?
<vagrantc>how are the source release tarballs generated? they contain some files not in git; presumably autotools boilerplate and maybe generates some translation related files?
<vagrantc>i'd like to build a similar source tarball from a git snapshot rather than waiting for a release
<mbakke>vagrantc: `make dist` will produce a shiny release tarball
<vagrantc>mbakke: thanks!
<mbakke>hmm, i just got a truncated log file on my own system
<mbakke>the build had legitimately failed, but the log file was apparently written before all the output had been flushed
<PotentialUser-84>hi i'd like to buy a computer with a fast cpu (amd ryzen 9). which motherboard do you recommend that works well with gnu guix?
<lsl88>hi Guix!
<alloy>Hey, I'm new to Guix Distribution and was wondering how can I suspend-to-ram?
<vagrantc>"make dist" appears to need to compile guix?
<lfam>alloy: I'm not sure if there is a built-in command but power management on Linux is controlled by writing to /sys/power/state
<lfam>So you can do `echo mem > /sys/power/state`
<alloy>Thanks! herd doesn't have a subcmd for it like systemd, does it?
<janneke>hi lsl88
<lfam>alloy: Currently herd only has halt / shutdown and reboot
<lfam>It would be nice to add a suspend
<alloy>yep, would be great!
<lsl88>janneke: hi! I made a mistake :/ I pushed to the videos repo without signing, how can I revert that?
<janneke>lsl88: what branch? i'm not sure what our policy is...
<kori>hello guix
<g_bor[m]>lsl88: hello. You can't. I've made that myself once.
<g_bor[m]>Hello guix!
<lsl88>g_bor[m]: hiiiii :)
<lsl88>and what can I do now?
<janneke>for a wip-branch, you can remove it altogether and push a new version -- no way to revert
<lfam>alloy: Looks like shepherd actually uses glibc for halt and reboot. But we could add a suspend using whatever technique we like
<janneke>lsl88: best to add an extra commit that you sign on top, that should be OK
<g_bor[m]>lsl88 : we could borrow some of the HACKING file, and the prepush hook from guix. Wdyt?
<lsl88>janneke: I am changing some other files, by committing with that signed would be fine?
<g_bor[m]>lsl88: I believe that would do just fine.
<lsl88>g_bor[m]: after pushing (and realizing that) I followed the steps in HACKING to avoid doing that again
<g_bor[m]>Ok. I ment that for future contributors.
<lsl88>g_bor[m]: sorry, I don't understand
<janneke>lsl88: yes
<lsl88>I have already pushed other changes :)
<lsl88>g_bor[m]: sorry, I don't get very well what I should do with the hacking file. Just add to the repo a HACKING file explaining that you need to sign your commits, or something else?
***scs is now known as Guest10223
<vagrantc_>make[2]: *** No rule to make target 'po/doc/guix-manual.pot', needed by 'distdir-am'. Stop.
<vagrantc_>so close
<mbakke>sneek: later tell alloy if you have the elogind service from %desktop-services, you can do "loginctl suspend"
<sneek>Got it.
<zaab>I am failing to make a symlink in my system definition. In the services I try to do (extra-special-file "/bin/vim" (program-file "nvim")). Problem is I do not know how to locate nvim from the store
<zaab>this is what I could find in the info page, but I do not understand any of the lingo yet :-)
<mbakke>zaab: you need something along the lines of (file-append neovim "/bin/nvim")
<zaab>mbakke: thanks. I'm learning!
<bob20190227131>So, not sure if this is the right place to mention this, but something seems broken around qt.
<bob20190227131>The qt dependencies for Calibre don't all build properly.
<bob20190227131>(Something can't be fetched or some such, despite my use of --fallback)
<bob20190227131>I don't have yesterday's logs, but I may be have new results in a few hours. It basically takes me a day to build it.
<mbakke>bob20190227131: have you run `guix pull` lately? there should be a substitute available for calibre
<bob20190227131>Yeah, ran it today. But substitute isn't built yet I think.
<bob20190227131>Also, I think I might simply be running out of memory during the build.
<mbakke>bob20190227131: try pulling again, there were some related changes a few hours ago
<bob20190227131>So it'd no longer point to alpha3?
<bob20190227131>( /gnu/store/b1mjiaia35cz1r8gxrw24xfrknkkxz3d-qtwebkit-5.212.0-alpha3.drv is the excessively slow to build deriv_
<mbakke>bob20190227131: /gnu/store/c64vcrlc0bsci56dv82fdxjm2x62pk69-qtwebkit-5.212.0-alpha3.drv is the current derivation
<len1>Hello, does anybody know how well does `guix import pypi` work?
<sneek>Welcome back len1, you have 1 message.
<sneek>len1, rekado_ says: This is a great first package! I’ve posted a comment on your gist with a new version.
<bob20190227131>Perhaps it wasn't cached when I started the build.
***len1 is now known as lenn
<g_bor[m]>lsl88: yes, that's what I was thinking about.
***len1 is now known as lenn
<lsl88>g_bor[m]: ok :)
<bob20190227131>Yeah. Seems I'm running out of memory in the ramfs it's making.
<bob20190227131>Ah, no, my bad.
<bob20190227131>My systemd /tmp tmpfs is being the issue.
<bob20190227131>Is there a way to make build temporary files appear elsewhere than /tmp ?
<g_bor[m]>bob20190227131: you can specify the tmp directory used in the daemon evironment
<bob20190227131>g_bor[m]: Thanks. I found that shortly after you posted, but I think I'll be fixing my system instead of having guix work around the issue.
<g_bor[m]>bob20190227131: yw!
<ngz>While building a new version of Asymptote, I have this TeX error: about missing "ltxguide.cls", even though texlive-latex-base belongs to the texlive-union in the package definition. Any idea?
<ngz>"ltxguide.cls" doesn't seem to belong to texlive-latex-base
<ngz>hhmmm. Actually, it belongs to some texlive-latex-base incarnations in the store, but not all of them. Odd.
***scs is now known as Guest86328
<ngz>This looks like a bug in Guix.
<rekado>ngz: nah, it’s probably a bug in the texlive-latex-base package after I merged the wip-texlive branch.
<rekado>looking at texlive.tlpdb I see that the “latex” package (which is called texlive-latex-base in Guix) should provide that file, but it doesn’t
<jje>2019-08-13 12:30 Slashdot [sd] YouTube Tests Bigger Thumbnails
<jje>2019-08-13 12:25 Ars Technica [at,unread] Wiseguy changes license plate to “NULL”, gets $12k in parking tickets
<jje>2019-08-13 12:21 ZeroHedge [unread,zh] Journalist For China's Global Times Brutally 'Arrested' By HK Airport Protesters
<jje>2019-08-13 12:15 Phoronix [p,unread] NVIDIA 435.17 Linux Beta Driver Adds Vulkan + OpenGL PRIME Render Offload
<rekado>that’s the problem with the tlpdb: it doesn’t say if a file is built from source or just copied.
<jje>2019-08-13 12:10 ZeroHedge [zh] Epstein Said He'd Witnessed "Prominent Tech Figures" Taking Drugs And Arranging For Sex: NYT
<jje>2019-08-13 12:00 Phoronix [p,unread] Vulkan Video Decoding Coming In H1'2020, Ray-Tracing Progressing
<jje>2019-08-13 11:55 ZeroHedge [unread,zh] Stockman Slams The Risible Myth Of The Savings Glut And The Lunacy Of Sub-Zero Yields
<jje>2019-08-13 11:50 Slashdot [sd,unread] Insect 'Apocalypse' in US Driven by 50x Increase in Toxic Pesticides
<jje>2019-08-13 11:41 Phoronix [p,unread] NVIDIA Continues To Be Involved With Making Vulkan More Appropriate For Machine Learning
<jje>2019-08-13 11:35 ZeroHedge [unread,zh] Wall Street Is Convinced A Recession Is Coming As Investors Are Most Bullish On Rates Since 2008
<jje>2019-08-13 11:15 ZeroHedge [unread,zh] Buchanan: China, Not Russia, Is The Greatest Threat
<jje>2019-08-13 11:10 Slashdot [sd,unread] Americans Would Rather Get Food Poisoning on Vacation Than Not Have Internet Access, Study Finds
<jje>2019-08-13 11:00 Ars Technica [at,unread] Owners of defective 2016 Google Pixels can now claim up to $500
<jje>2019-08-13 11:00 ZeroHedge [unread,zh] "I'm Not Crazy!": Naked Burglary Suspect Detained After Getting Stuck In Neighbor's Chimney
<jje>2019-08-13 10:40 ZeroHedge [unread,zh] 5 Reasons To Be Bullish (Or Not) On Stocks
<jje>2019-08-13 10:25 Slashdot [sd,unread] AI Used To Narrate E-books in Authors' Voices
<jje>2019-08-13 10:12 Ars Technica [at,unread] Trump administration announces changes to Endangered Species Act rules
<jje>2019-08-13 10:10 ZeroHedge [zh] 'Shrieking' Heard From Epstein's Jail Cell The Morning He Died
<jje>2019-08-13 09:57 Slashdot [sd,unread] How One City Saved $5 Million by Routing School Buses with an Algorithm
<jje>2019-08-13 09:56 Trading with The [tf,unread] Electronics are Safe; Lesser Men Sell Gold Here
<jje>2019-08-13 09:50 ZeroHedge [unread,zh] Trader Warns: Three Things Remain "Very Real Perils"
<jje>2019-08-13 09:44 Slashdot [sd,unread] Google's Jobs Search Draws Antitrust Complaints From Rivals
<jje>2019-08-13 09:30 ZeroHedge [unread,zh] Pentagon Launches Investigation Into $10 Billion JEDI Cloud Contract With Amazon
<jje>End of entries.
<bavier>any ops here?
*rekado just looked up how to become ops
<janneke>looks like an honest oops?
<ngz>"Naked Burglary Suspect Detained After Getting Stuck in Neighbor's Chimney" Wow. Really…
<rekado>but had it gone on longer then kicking would have been the merciful thing to do.
<janneke>someone should create a patch for ERC :-)
<rekado>I just can’t remember how to get ops…
<nalkri>"/msg chanserv op #channel"
***ChanServ sets mode: +o rekado
<rekado>indeed! Thanks nalkri.
<rekado>I tried /mode #channel +o rekado
***ChanServ sets mode: -o rekado
<ngz>Probably /msg ChanServ OP
<ngz>As nalkri said ^^
<rekado>ngz: so, about ltxguide.cls … It’s my fautl.
<rekado>I changed the package and made it download ltxguide.cls, because it’s not built from source.
<rekado>but I forgot to actually install that file…
<nalkri>For my sins I have op access elsewhere :p
<ngz>rekado: Where do you "install" the file? I mean, what part of the texlive build system is responsible for that?
<rekado>ngz: it’s not using the texlive-build-system because it’s needed for the texlive-build-system
<rekado>look at the definition of texlive-latex-base in gnu/packages/tex.scm
<sebboh>The user was using ERC. The pasteflood was indeed probably an accident. :)
<rekado>ngz: it’s using the gnu-build-system and has custom 'build and 'install phases.
<rekado>the 'install phase installs all built stuff, but it doesn’t install the extra source files.
<ngz>I'm looking at texlive-latex-base, but I failed to express myself correctly. Luckily, you're answering my question right now :)
<lenn>rekado: Hey, I saw your comment, thanks again for help. I'll need more of it :)
<rekado>ngz: fixing this would require a large number of rebuilds.
<rekado>luckily you can get around this
<rekado>I think you might be able to add (package-source texlive-latex-base) to the texlive-union.
<rekado>with a big comment that says that I screwed up and that this will be fixed on core-updates.
<ngz>so (texlive-union (list texlive-... ... (package-source texlive-latex-base) texlive-...)) ?
<rekado>ngz: yes, if that works.
<rekado>if that doesn’t work you can create a variant of texlive-latex-base that does the right thing.
<pen14641>Hi, does someone know which package I should install for compiling Java code? I installed 'openjdk' but that didn't give me the 'javac' command..
<rekado>pen14641: you need the “jdk” output of the “openjdk” package.
<rekado>try installing openjdk:jdk
<pen14641>rekado: Thanks, that worked! I need to get used to outputs :)
<ngz>rekado: Hmm. I get a backtrace. Guix doesn't like (package-source texlive-latex-base)
<rekado>ngz: hmm, well then you need to inherit from texlive-latex-base and install the sources in an extra phase.
<ngz>ewwww :)
<ngz>Another option: skip compilation of that particular TeX file
<lenn>there's no matrix client package on guix and I thought I'd just use weechat_matrix plugin for weechat but I am having troubles installing python package requirements ...
<ngz>lenn: There is an emacs matrix client
<lenn>oh, rly, that's nice
<lenn>I'll check it out tomorrow, ngz - thanks for info
<lenn>Does anyone ever get a feeling that they are using emacs for too many things?
<ng0>efraim: have you hit any warnings about unsupported operating system yet while packagaing rust crates? or is this identified properly as Linux? I've hit some
<rekado>ngz: nah, skipping compilation is the road to endless pain.
<rekado>(or is it the endless road to pain?)
<ngz>Why? It is a single change in a Makefile.
<rekado>it’s better to fix the problem at the root.
<ngz>On another topic, is there a way to test compilation of a package on Aarch64 and Armhf? Besides making blind changes and waiting for the CI to catch-up?
<ngz>(I don't own Aarch64 or Armhf)
<rekado>ngz: you can use the Qemu service
<rekado>search the manual for qemu-binfmt-service-type
<rekado>do enable the “guix-support?” option
<ngz>Can I use this on a foreign distro?
<rekado>probably not
<ngz>Ah =/
<rekado>which is a pity because I’d love to be able to run Guix system services in some sort of container.
<ngz>It could be useful for packagers to have a simple command to launch a guix vm with such service, ready for alien compilation.
<ngz>E.g., guix outer-space-build -s armhf-linux <package-name>
<sebboh>Hello! My system takes a really long time to `guix package -i $anything`. It seems that it is spending some large static amount of time "building XDG MIME database...". I kinda know what that is and I am sure that I don't need to automatically update it after installing any package. (This machine does not *have* X windows. Even if some app I installed is xdg aware, I'd rather manually update that DB on
<sebboh>demand, the first time I discover that I need to reference it.)
<ngz>rekado: So, in texlive-latex-base, I grab the list of files in /tex/latex/base that are not generated, bind it to, e.g., files-to-copy, then, in install phase, do (for-each (cut install-file <> target) files-to-copy) ?
<pen14641>When using 'guix system vm' should i avoid running the returned script with sudo? (If I don't use it I get an error about KVM, which I have no idea if I can solve without just using sudo)
<sebboh>Also, frankly, MIME types are kinda not my style. I generally invoke `$program $document`, not `xdg-open $document` or whatever magic. :)
<sebboh>anyway if I can remove or disable any XDG-related 'hooks' in my guix, I think I'd be better off. But, where are these 'hooks' defined?
<sebboh>"try installing openjdk:jdk" Neat. How do I get a list of "outputs" for a given package, or across all packages?
<bavier>sebboh: output are listed in 'guix package --show=...' and 'guix package -A ...'
<rekado>ngz: simpler. You can copy-recursively the source directory.
*rekado –> zzZZ
<ngz>But then I'll grab re-generated files too
<ngz>Which may not be desirable.