<civodul>davexunit: make-bootstrap.scm produces a relocatable guile <davexunit>maybe I can copy that and make a relocatable guile 2.1 <davexunit>that + some guile libs + some c shared libs and I can distribute my games to people that would rather not use guix <vtomole>I typed in "root" and it just hangs like that <adfeno>vtomole: Can you press Esc to show the terminal. If it doesn't show, try Ctrl + Alt+ F1 (or Ctrl + Alt + F7). <adfeno>Oh... Now I remembered... This might not work.... <adfeno>QEMU considers Ctrl + Alt as to exit mouse grab. <vtomole>The examples for configuration files show how to set user account but it doesn't have password <adfeno>We have to find a way for QEMU to pass the Ctrl + Alt + F-somenumber to GuixSD instead. <vtomole>I can't login to alice the account on the manual page <adfeno>You mean that the examples don't show how to set password? <civodul>vtomole: initially the 'root' passowrd password is empty, and the others are uninitialized <adfeno>civodul: He does this after installing GuixSD, from a terminal? <vtomole>SO i can login is a root and just use guixsd normally? Then i won't bother with the other accounts then <adfeno>Also, I think that setting these password in the config file is somewhat insecure. <adfeno>vtomole: As far as I know, accounts without password are disabled. <adfeno>Someone at Trisquel forum once told me that this is part of the reasons as to why there's no root user in Trisquel. <vtomole>Hmm i see, so this hanging thing... Never happened to you? <adfeno>Hm... Sorry for not informing you earlier, but I'm not using GuixSD. Instead, I use Guix on top of Trisquel. <vtomole>ahh yes, i want to do that now too, i know guixsd is in beta, I want to move to nixos cause everything has been working perfectly for me, but i just love lisp so much :( so i don't want to give up <vtomole>I've heard it's very easy to install on baremetal, but i don't want to do a full one, can i dual boot it? <adfeno>In my case, I'm still not ready to make my work-computer use GuixSD. So I decided to help the Guix project while testing some packages that I like from Guix (and occasionally testing other packages just to contribute fixing possible bugs with them, even though I'll probably uninstall them once finished). <adfeno>vtomole: That's my concern too. For both of us, I think it's better to make sure that you have a way to, while installing GuixSD, be online here at #guix (with other computer or cellphone) , just in case you need some support. <vtomole>hmm theres no other choice than to install guix on nixos then <adfeno>vtomole: And of course: be sure to back-up important things of your current work-computer before installing. <adfeno>(↑ my last message was still referrring to the installation of GuixSD) <adfeno>It means no test was registered at H-node. <vtomole>ahh i didn't such a database existed, so helpful :) <adfeno>Now, if we instead take each component/hardware model/name from your computer, and search for these instead (the links differ, but you would either go to "Hardware" or "Search" and select the category that fits said hardware). <adfeno>... then we **might** find good results. <adfeno>Based on what you gave me, I'll pick a list for us to search for in H-node (note: I'm not going to do the search for now, as it's too late for my eyes). <vtomole>Thank you, you don't have to do any of this for me <vtomole>I'll just ask around for the best notebook model that runs free software <vtomole>I have so money from Christmas i can throw away <adfeno>They might not be the fastest or powerful, but by buying them, you'll surely be helping the organzation which sells such product to continue offering freedom-respecting hardware. <adfeno>If you don't mind, I must be going now, it's 22:00 here. ***Steap_ is now known as Steap
<ZombieChicken>vtomole: There is also the Novena if you don't mind something a little more DIY <quiliro>i wonder why i do not get emails from the bug mailing list <rekado_>Compiling gcc generates hours of heat for my apartment. It’s great. ***dan_ is now known as Guest96294
<emyles>I made a module for a haskell package and its dependencies by doing 'guix import hackage [PACKAGE]' repeatedly. There is also a nix package. Next time would it be better to import the nix package somehow? <cbaines>quiliro, what are you interested in? <rekado_>I’m confused about the build of Hugs. <rekado_>after the last phase the build is restarted. <rekado_>/gnu/store/05lcvfm05sikmifl8f4zy9zfy649dm6x-hugs-Sep2006.drv <rekado_>/gnu/store/v2g4vpfsjl64aad1zcxz5c6psw4h02bh-hugs-Sep2006.drv <rekado_>ah, the architecture differs in the two files <rekado_>I’m running this: guix environment --system=i686-linux --ad-hoc gcc-toolchain@4 coreutils make hugs <rekado_>does it need to build the output for x86_64 before it can build the i686 thing for me? <civodul>but i don't really understand the context :-) <jmd>We should rename the "staging" and "core-updates" branches. <jmd>... and make them into rolling heirachies. <EvilPython>Can I import compiled from source package into Guix? <jmd>civodul: Once a merge-evaluation process has started, nobody is permitted to commit to the branch. So we need a staging-pending branch where people can commit to. When staging is merged, then staging-pending can be renamed to staging. <quiliro>cbaines: i would like 2 things: to be able to install offline and to have an end user ready desktop installation that does not take too long to install in an old machine...i reffer to the system distribution <quiliro>civodul already answered my question on the bugs mailing list. I am figuring out how to give feedback to that question <jmd>quiliro: Installing offline would be possible if somebody was to produce dvds mirroring hydra. <jmd>Answering your second question would require a definition of "too long" and "old". <cbaines>Hopefully you would just produce a USB installation image, which contains all the packges for a desktop environment <cbaines>I believe there are instructions for producing the installation image somewhere <cbaines>I'm guessing supporting offline installation is just about generating installation images which contain everything you want to install <quiliro>for the second objective i am looking for pentium 4 <cbaines>have you done an installation on "old" hardware? <quiliro>cbaines: yes...in fact i have on celeron D and now i am using a centrino duo <cbaines>do you know what it spent the time doing? I'm guessing it had to be compiling lots of things from source <quiliro>it would be useful to be able to install from the available substitutes only <cbaines>so, solving the "offline" problem should solve the installation speed problem as well <quiliro>if there are no latest substitutes, we should use older ones <cbaines>given you are installing offline, everything you need must be in the installation image, so you won't end up building lots of packages <cbaines>quiliro, that is not quite possible with substitutes <quiliro>what about new packages that are not contained in the installation image? <cbaines>So, say you have Guix, at one specific version that you are using <cbaines>in that copy of Guix, everything is specified exactly <cbaines>for some of those packages, there might be substitutes available, for some of the packages, there might not be <cbaines>to use other substitutes, you would have to install with the matching package definitions <quiliro>but it could be possible to have a version of all binaries as in other distros. it is not needed to be the latest...only have binaries available <cbaines>So, if you look in the docs, can you see this command: guix system disk-image --image-size=1G gnu/system/install.scm <cbaines>so, the gnu/system/install.scm file has an operating system definition in <quiliro>that will provide an image which can be can be mirrored <quiliro>which is copying without compilation <quiliro>what do you propose to do with this installation image? <cbaines>I think if you use that image to install Guix, and don't use any packages which are not contained within that installation image, you will get "offline" installation <cbaines>The problem then becomes creating an image which has all of the packages you want to install <quiliro>cbaines: nice... all i have to do is run that command? <cbaines>well, running that command creates the image <cbaines>what you might want to do, is edit the gnu/system/install.scm file first <cbaines>do you have an operating system definition that you actually want to install? <quiliro>perhaps desktop.scm might be an almost complete definition <cbaines>Now comes the complicated bit, the operating-system definition includes a list of packages that will be available on the installation image <cbaines>so, to make at least some of the packages for Gnome available, you could add the gnome package to the list of packages <cbaines>Then when you generate the installation image, within the store it will contain the gnome pacakge, which requires lots of other gnome packages (e.g. epiphany) <cbaines>One issue that comes to mind is the Guix package that will be included in the installation image. It needs to have the same packages that are being used to build the installation image <quiliro>cbaines: desktop.scm includes gnome and xfce <quiliro>i have some problems in my own installation which is i cannot view online videos on epiphany <quiliro>so i chose icecat which shows youtube videos but not vimeo's <cbaines>quiliro, if you want the xfce packages as well, I'd include the xfce package along with the gnome package <quiliro>cbaines: it is already done on the stock desktop.scm <cbaines>I'm talking about including packages in the installation image for offline installation <cbaines>The example desktop operating-system uses the gnome-desktop-services and xfce-desktop-services, but in the installation image, you just want the coresponding packages. <ng0>What's this in requirements.txt: requests[socks]==2.12.4 ... there's no requests-socks on pypi. Does this even exist? <cbaines>I think that is a setuptools thing for optional runtime dependencies <cbaines>So requests[socks], is just requests, but with the requirements that it specifies for the socks extra <ng0>so it is as I suspected, requests with an added socks (socksipy) <ng0>if it is, I must only create this inherit to fix the optional error <cbaines>you can find the list of requirements for the socks extra in the setup.py file usually <ng0>okay, IÄll try.. thanks :) <ng0>ah, yes.. makes sense ***jonsger1 is now known as jonsger
<jmd>Is it possible to install GuixSD with /gnu on a different partition to / ? ***jonsger1 is now known as jonsger
<civodul>ACTION inadvertently pushed the power button of the laptop <jmd>civodul: How did you manage that? I thought they all had a delay of about 3 seconds. <civodul>apparently Something intercepts it and shuts down the computer properly <civodul>i think shepherd received SIGINT and processed it right away (ctrl-alt-del also send SIGINT to PID 1) <quiliro>cbaines: i don't understand the difference between using gnome-desktop-services and "the corresponding packages" <civodul>quiliro: gnome-desktop-service does a lot more things than just providing the relevant packages <davexunit>weird. I have a package expression that is inheriting from another package, but everything I override seems to be ignored... <jmd>Is anyone working on getting btrfs in GuixSD? <sjoerd`>Who can help me with a problem during system init with a CPAN problem <paroneayea>but I think the core "why Guix is exciting" stuff is still true <sjoerd`>I am getting a nasty ftp-error then it tries another host which appears not to respond, and it hangs <jmd>Something is seriously broken with our recipe for aqbanking. <cbaines>I've got it failing on a couple of machines too <ZombieChicken>rekado_: Seems a mail on guix-devel from Ludo is making a claim that NSS fails on ARM <ZombieChicken>cbaines: rekado_ The email subject is: "Let’s fix build failures on ‘staging’!" if you want to add to the list of places where it is failing. <civodul>paroneayea: pretty cool, you should send the link to guix-devel! <paroneayea>interview with me (from late 2015, but published at last) about Guix <rekado_>“guix environment --system=i686-linux --ad-hoc hugs” really does build two variants of hugs <rekado_>one for i686 and then another for x86_64 <davexunit>civodul: I'm trying to make a relocatable version of guile 2.1.5. I got it to compile successfully but it breaks when I try to run the guile binary <davexunit>Throw to key misc-error with args ("primitive-load-path" "Unable to find file ~S in load path" ("ice-9/boot-9") #f) <davexunit>turns out it works if I manually configure GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH <civodul>davexunit: did you apply guile-relocatable.patch? <adfeno>Oh my... it seems that there's a test for a package which is taking almost three hours (and counting). <sneek>jmd`, lfam says: Something came up and I wasn't able to start the staging build when I had planned. But it is running now <lfam>jmd`: That's a very old message from sneek <lfam>I'm building it now myself. If it doesn't work, I'll revert the change that caused the rebuild and start an nss-updates branch. <rekado_>I tried building it on i686 and it failed after a couple of hours. <jmi2k_>cargo build fails when trying to compile dependencies because it can't find libgcc_s.so.1. What's wrong? I've installed gcc-toolchain. <lfam>rekado_: Do you still have the failure messages? <civodul>jmi2k_: you mean the "cargo build" command or the build of the 'cargo' package? <jmi2k_>civodul: the "cargo build" package, sorry <rekado_>lfam: sadly I don’t. The machine has been rebooted since. <civodul>jmi2k_: in that case no idea; you could try stracing 'cargo' to see how it invokes gcc and ld <civodul>basically it's invoking 'ld' instead of the 'ld'wrapper <ng0>oh... is nss broken on master? or just for arm? <ng0>oh... is nss broken on master? or just for arm? <ng0>which of the hours long tests? <adfeno>I don't know which phase it's at, but it seems to be taking hours to do the same thing over and over. <adfeno>Good thing it's not eating that much of CPU, so I can live with that. <adfeno>Oh... Actually it's somewhat CPU intensive. <lfam>I've reverted the change that caused the rebuild <ng0>now only rebuild again and I can test wether my p11-kit package is functional <lfam>We should just always update NSS on an nss-updates branch. <ng0>p11-kit builds okay.. anyone interested? I can move it out of my guix path into master for a patch <lfam>ZombieChicken: It's not fixed :) We'll just keep using the old version for now <ZombieChicken>Fixed in the sense I can update shit now, which is an improvement <lfam>Yes, the user experience is much better now ;) <lfam>Yes, see the --log-file option <adfeno>I wish there would be a way to tell `guix package -u` to "update everything except the following packages"... :) <ng0>like, guix package --do-not-upgrade=librebloat -u <ng0>I meant to answer the question <civodul>lfam: so what's your take on the other failures on 'staging'? <jmd>Is it possibly to install GuixSD with / and /gnu/store on different volumes? <lfam>civodul: Excluding mips64el, I think we have potential solutions ready to be reviewed for all the failures of non-leaf packages. <lfam>I just restarted scalapack, which appeared to be a spurious failure (the build log indicated success) <snape>how long should I wait before sending an updated patch, on the Prosody service? Not sure there is enough feedback <lfam>snape: I'd wait for a deeper review. So far I don't think anyone has read the patch very closely. <lfam>snape: Preliminary feedback: Please separate the changes to gnu/packages/messaging.scm into their own patch. We prefer one patch per change, and fixing a broken package is worth doing even without adding a service. <snape>lfam: well, the package changes don't make sense without the service <snape>because they are related to prosodyctl, whose only point is to talk to the service <lfam>snape: Do they make it impossible to use the package without the service? Or could people still use our Prosody package with another service manager? <snape>there are two binaries in the Prosody package. One is prosody and the other is prosodyctl <snape>(well, they are not binaries, but anyway) <snape>But yes, I guess prosodyctl could be used with another service manager. <lfam>I use Guix packages with other service managers. We can't tie our packages to Shepherd. <snape>I understand. My packages changes allow prosodyctl to find the Prosody conf and data files. <snape>So I guess they would be usefull for another service manager. I'll put the changes in another patch. <civodul>snape: yeah i think it's best to have them in another patch <civodul>ACTION just made the nickname/full name mapping :-) <snape>:), that's the point of /whois too! <lfam>"Nothing in fact (“alot” and “many things” are kinda synonymous? ;-))" <lfam>I'll be back in a few hours ***jonsger1 is now known as jonsger
<nivlo>Hi. After unpacking guix 0.12.0, there is no /var/guix/profiles/per-user/root/guix-profile/bin/guix-daemon file in the tarball. <nivlo>as it is said in the documentation. <nivlo>that is also the case for 0.11.0 <civodul>nivlo: you sure? i can see it here in the output of "tar tvf" <snape>btw, civodul, I'm not sure what is your workflow and whether or not I should remind you of a small patch that has not been pushed :) <civodul>(my workflow is becoming a mess, i have ~200 unread messages in guix-devel) <snape>Oh! so do not worry, it's not important <civodul>so yeah i basically review for a while, and then i stop and there are still many patches left <nivlo>it only shows the guix-daemon inside the store.. <snape>civodul: (about Prosody), is there any value added by testing with 'guix system vm'? <snape>I tested it on real computers <civodul>nivlo: could you use paste.lisp.org or similar? pastebin.com is inaccessible over Tor <civodul>snape: if you tested on the bare metal, that's even better :-) <civodul>a test would still be nice in the long run though <snape>yeah sure, I'll have a look at (gnu tests ...) then <nivlo>civodul: here is the md5sum of guix-binary-0.12.0.i686-linux.tar.xz : 1c7db0a1974d4c040c7ee42cebfb577f ***jonsger1 is now known as jonsger
<civodul>nivlo: /var/guix/per-user/root/guix-profile is a symlink to that /gnu/store/...-profile thing <nivlo>civodul: doesn't it have to show up in tar tvf even if it's a symlink? <nivlo>civodul: in case the user needs to create the symlink, then the docs miss that. <nivlo>civodul: ok, it seems the symlink points to /var/guix/profiles/per-user/root/guix-profile-1-link/, but that folder is empty then. <nivlo>sorry, for some reason that was empty on my system.. <davexunit>civodul: yes I did, but it doesn't seem to have the intended effect. <davexunit>I'm okay with the current situation though because I can get it to work. I had to drop the default-utf8 patch because it didn't apply but it looks like I need it. <davexunit>we really should just pull guix.el back in the source tree <davexunit>or occasionally dump in what's in the external repo <davexunit>there's just no good reason for it to be deleted. <adfeno>I think it would be bundling, no? <davexunit>it's not ideal but it's better than letting it be deleted.