IRC channel logs
2016-09-20.log
back to list of logs
<rekado>finished porting xwidgets to the WebKit2 API. But scrolling is still defective (maybe even worse than before). <rekado>before I submit this to emacs-devel I’ve got to clean this up. <bavier>new julia release says "improved support for ARM", but we don't seem to support julia on arm... hmm <Common_Era>How would I connect to my Wifi once GuixSD is installed and running? <JamesRichardson>wicd-gtk or wicd-curses if wicd is installed and the wireless card is actually seen by the kernel. <Common_Era>Hmm. I installed the barebones and don't have access to ethernet... <JamesRichardson>For the wireless, something like wpa_supplicant or wicd and wireless-tools would be needed to the ESSID and keys to authenticate with the router. <Common_Era>wpa_supplicant isn't installed by default either. That was my first thought. <Common_Era>Trying "ifconfing wlp3s0 up", I get the "link is not ready" message. <JamesRichardson>I suspect you have wpa or some other security enabled on the router... <Common_Era>I've gone through /etc/network/interfaces, too, and it doesn't seem to do much. <JamesRichardson>try something like iwconfig wlp3s0 essid any or iwconfig wlp3s0 essid "name of actual ssid". Hopefully that will allow the link to come up. <Common_Era>Apparently the Guile site directory is /gnu/store/$(hash)-guile-2.0.11/share/guile/site/2.0, but that doesn't exist and /gnu/store is, of course, read-only. How can I install site packages? <OrangeShark>Common_Era: you would install the packages from guix <JamesRichardson>I think just add the packages to the (packages (cons* ...)) list in the config.scm file and run guix system reconfig <config>. <OrangeShark>you can create your own guix package for your project <OrangeShark>for development, some devs use a script sometimes called pre-inst-env which sets up the environment variables to run the program in guile <OrangeShark>so you can do "./pre-inst-env guile" and you now have a repl which should be able to load your guile modules <Common_Era>I saw that in the manual. Sorry for the dumb question, but where is this script. Or do I write it myself? <OrangeShark>I think most people just copy it from the other projects because they are pretty much the same <OrangeShark>Common_Era: if you want, I can show you my guile project and how I set it up <Common_Era>lostcoffee: I've seen it already, but thank you. <Common_Era>OrangeShark: I would really like that, if you can. <OrangeShark>you want to look at configure.ac, Makefile.am, guile.am, pre-inst-env.in <lfam>It's not clear to me if the vulnerable code is part of our ruby package or not <lfam>Our ruby package does depend on openssl <lfam>Can anyone look into this? <OrangeShark>oh and guix.scm is something projects have been adding. It allows you to do guix environment -l guix.scm and it sets up all the stuff needed to build your project <OrangeShark>I find it pretty handy, I can change guile-2.0 to guile-next and I will be able to test my project with guile-2.2 <lfam>Okay, I do see 'lib/ruby/2.3.0/x86_64-linux/openssl.so' in our Ruby package <efraim>Sneek later tell Common_Era can you send an email to guix-devel@gnu.org with how you got guixsd to work on your Mac? <quigonjinn>Yesterday i sent a patch series in guix-devel. Had it been sent correctly, shouldn't it have appeared by now? <jmd>quigonjinn: Look in the list archives. <quigonjinn>An updated patch series for the gcc cross compiler for arm-none-eabi <quigonjinn>it's the first time I used git send-email, that's why i'm unsure <quigonjinn>is it safe to assume it failed, and send it again or shall i wait? <snape>how many patches did you send? <snape>(there are 4 patches about cross-compilation, but they are from sept 18) <quigonjinn>i sent mine as a reply to those patches from Ricardo <jmd>quigonjinn: How long ago did you send it? <harxa1>hi, is it possible to get rid of old system ? i have some that wont work, and i would like to remove them somehow <harxa1>all systemconfigurations are available (in grub) which is good. but some of those are misconfigurated <snape>harxa1: I usually delete them manually from /var/guix/profiles <snape>but I'm not sure it's the right way <jmd>quigonjinn: Then I suggest that they didn't arrive at lists.gnu.org <jmd>Check your outgoing mailserver logs. <snape>quigonjinn: git send-email usually outputs something like "sent successfully" <jmd>snape: But that only means it "sent" to the local mailserver. What the mailserver did with it --- Who knows? <snape>harxa1, and then guix system reconfigure generates the grub config file depending of those symlinks in /var/guix/profiles <quigonjinn>snape: it did say it was sent successfully. But i sent it to guix-del as -cc= and not --to <jmd>quigonjinn: Should have been guix-devel <snape>jmd, yes I know, but that was just to be sure the problem did not come from the client <quigonjinn>also, my mail provider does not supply logs for mails i send out of the web client <snape>quigonjinn: I assume it is safe to try again with --to then :) <jmd>So far as I know, git-send-email cannot send over a web client. <jmd>quigonjinn: You do have some kind of smtp server running? <quigonjinn>i did test git send-email, sending the patches to my other mail address with --to , and they were sent correctly <quigonjinn>jmd: my mail provider provides an smtp server, which i'm using so far <snape>harxa1: could you share your conf? <jmd>quigonjinn: Let's get specific. Do you have anything listening on port 25? <harxa1>what is the url for the famous guile-pastebin again? <jmd>ok. Do you have a /bin/sendmail (or similar) ? <jmd>quigonjinn: Then I cannot imagine how get-sendmail can possibly work. <snape>jmd: because he uses an external smtp server <snape>git send-email works like a mail client that talks to a smtp server <jmd>snape: He would have to specially configure git-sendmail to use that. <snape>jmd: yes, I reckon he did.... <quigonjinn>jmd: I did configure it. and sent the patch series to my other mail address successfully <jmd>Well then perhaps your external smtp server dropped it (or has queued it for an excessively long time). <jmd>I would recommend installing a local mail server - that way you can investigate issues like this, without having to rely on someone else. <snape>jmd: there are no mail server packaged with Guix yet :) <jmd>snape: Yes there is. <snape>or maybe there is something simpler <quigonjinn>jmd: i'll give it a look, thanks. Never bothered up to now. I'll give it a couple of hours, and then resend the patches <jmd>snape: estmp for example <jmd>Although that is only a relaying daemon. <jmd>But we also have sendmail packaged. <jmd>Although we don't have a service configured which is what it really needs. <snape>harxa1: I think you should use title 'device instead of title 'label <snape>because "/dev/mapper/sth" is a device <dvc>thinking about business oportunities for guix/guixsd - I think we should market it as a development target for SaaS applications. I'm investigating the possibility of describing SaaS applications as a collection of <operating-system> objects. Then I want to export those operating-system objects into the open container format for easy deployment to existing orchestration services like docker-cloud. WDYT? <dvc>has someone done previous work for creating docker images from operating-system declarations? <dvc>the goal of this exercise is to get businesses with large cash flow using guix - from there there should be services and stuff that can be provided around this to monetize on it <harxa1>has someone realized a simple service similar to the old /etc/rc.local ? <adfeno>Which one should I use when setting the "PREFIX" variable for a recipe that uses "make"? Should I use out or %outputs ? <harxa1>my guix system reconfigure hangs at this : shephard: Evaluating user expression (register services (primitve load "/gnu/s...")). <jmd>adfeno: you should pass --prefix to configure <jmd>(if you believe it is really necessary) <adfeno>The package I'm trying to make assumes a PREFIX of "/usr/local" if not set. <adfeno>jmd: The package/project doesn't have a configure script. <adfeno>It seems to use a file called "config.h" in the root directory to accept adjustments. <jmd>adfeno: Then you will either have to set the PREFIX environment variable or mutate the Makefile, depending on what exactly they do. <adfeno>I'm thinking of doing: arguments`(#:make-flags (string-append "PREFIX=" out)) <jmd>You really need to look carefully at what the makefile does to know what is appropriate. <adfeno>From what I'm reading inside the Makefile, it seems to mainly test for the PREFIX variable, after that, if unset, it's set to "/usr/local/". <adfeno>After that, it tests for other variables, and if they are unset, uses PREFIX as base path and includes "/share", "/lib", "/bin", and "/include" for some other paths <adfeno>E.g.: From the actual source file: BINDIR := $(PREFIX)/bin <jmd>then yes, it sounds like setting PREFIX to (assoc-ref %outputs "out") is probably correct. <jmd>Whether is is best to do that with a make argument or with an environment variable, I'm not sure. <adfeno>jmd: Should I use (assoc-ref %outputs "out") even with no list of outputs set? (as far as I know, if you don't specify the outputs `(), then it defaults to a single one called "out"). <adfeno>If I replace the build phase in the GNU build system, do I also have to make sure that the phase accepts the #:make-flags ? <jmd>No. you would have to arrange that. But if you're replacing it, then why bother. <adfeno>I bothered because I was don't know much about make, but seeing examples it seems I only need to place the variable after the main make command. <jmd>There are some slight semantical differences between "make PREFIX=foo" and "PREFIX=foo make" - whether it'll matter or not depends on how the people have written the makefile. <jmd>But yes, I would prefer the former, if it works. <adfeno>OK, I guess I have some progress... <adfeno>Interesting... Everytime I use guix build, the substituteer tries to download module-import-compiled, but gets a hash mismatch. <adfeno>It doesn't happen with other guix-related commands <jmd>You've probably changed something you shouldn't have. <adfeno>Or in the configuration of `guix build`? <adfeno>About the possibility of changing a configuration of the `guix build` command: I don't recall doing so. <adfeno>So I really don't know how to fix. <jmd>You are working from git? <adfeno>ACTION notices the duplicated expat license selection, and fixes it. <jmd>Can you build other packages ok? <adfeno>Since I'm working with my own recipe without a VCS, I'm using: GUIX_PACKAGE_PATH="/home/adfeno/Tests/Guix" guix build "tahoe-lafs" <adfeno>The "Guix" folder has "tahoe-lafs.scm". <adfeno>I'll build hello, and also keep the GUIX_PACKAGE_PATH, just in case. <adfeno>The substituteer succeeded in downloading "hello". <jmd>try guix challenge hello <adfeno>guix challenge: warning: no local build for '/gnu/store/50lhfbi5jd00839yaq1ia67wid6lf7wl-hello-2.10' <adfeno>I guess I'll have to force guix build to build hello from source. <adfeno>Because it downloaded the substitute; <jmd>yeah so build it locally <brendyn>"Your Emacs was not compiled with Xwidgets support" :( <adfeno>Oh my... using --no-substitutes while doing `guix build "hello"` will even build gcc! <adfeno>Perhaps I should have installed GCC beforehand. <adfeno>Ok... Stoping the current build. <jmd>adfeno: If you build absoluitely all the dependencies of hello, it'll take about 24 hours unless you have a super fast machine. <jmd>... so don't do it then ... <adfeno>I use Guix in my copy of Trisquel, so I rarely have the usual packages a GuixSD user would have by default in the store. <jmd>I don't see that it makes any difference. <adfeno>So... If I do --no-substitutes, it discards even the things in the store? <adfeno>If so, then I agree... Building hello would take 24h. :) <jmd>--no-substitutes means that it will not download from hydra <adfeno>So what delays is the build process. :) <jmd> guix build hello --check should have finished by now. <jmd>so building things works then. <jmd>now do guix build your-package <adfeno>It "exited"/"exitted" with 0 status. <jmd>so it works. Congratulations! <quigonjinn>so... my mails actually passed twice. sorry for that <jmd>quigonjinn: You will be billed twice then :) <jmd>I don't know why that is. You could try with --fallback and see what happens. <adfeno>It's finally operating on my recipes. <adfeno>Now, the error that stopped the build was on my part really, I forgot to link Crypto++ library to python2-pycryptopp. <adfeno>And cryptopp doesn't need python2-setuptools; ?:) <adfeno>starting phase `unpack'; In execvp of unzip: No such file or directory; phase `unpack' failed after 0.0 seconds; builder for `/gnu/store/idds94y3gxq4b6cjpkkamxqb92kx7797-cryptopp-5.6.4.drv' failed with exit code 1 <adfeno>Interesting... I didn't change the "unpack" phase, but it still failled. <adfeno>Now the make doesn't find target dynamic.... <adfeno>Crypto++'s documentation says that using "make dynamic" should work... <ZombieChicken>hrm. Anyone having troubles cloning the guix git repo? I've been staring at "Cloning into 'guix'..." for some time now. I clones the shepherd repo a bit ago and it finished almost instandly <ng0>it seems like out apache (httpd package) is not build with htpasswd? <ng0>I've just tried guix environment httpd and it was not available <janneke>ng0: i have a /gnu/store/in2jc405scsn92i5q3kds2g851rmxdp4-httpd-2.4.16/bin/htpasswd in my /gnu <OrangeShark>ng0 shouldn't it be guix environment --ad-hoc httpd? <OrangeShark>if you want to have httpd built already and available in your environment <ng0>i use it not so often. you are right. <adfeno>I'm trying to make a Guix recipe for cryptopp library. <adfeno>I need this in order to build my desired recipe: Tahoe-LAFS. :) <ng0>doyou havedetails/logs? <adfeno>I'll share the recipe... Just a second... <adfeno>ng0: Doing: GUIX_PACKAGE_PATH="/home/adfeno/Testes/Guix" guix build --fallback "tahoe-lafs" ... and "build" phase of cryptopp fails because `make` can't find target `dynamic`. <adfeno>The documentation of cryptopp (the Install.txt file) says that this target should work. <adfeno>And I tested it with Trisquel's `make` and it does compile. <adfeno>... does compile using target "dynamic". <ng0>i think this can be passed as make-arguments or what it was called <ng0>#:make-arguments (list dynamic) <ng0>#:make-arguments (list "dynamic") <adfeno>lfam: As far as I know, I'm only using GNU make. <adfeno>At least this is what I expect #:use-module (guix build-system gnu) ... to do. <lfam>Okay, I didn't read the report closely since we didn't have a package. <lfam>Just letting you know about this issue :) <adfeno>lfam: Oh... I see... Thanks for being so caring. :) <adfeno>ng0: I'll try to re enable the #:make-flags again <ng0>also, shouldn't it be --PREFIX ? <ng0>which should be catched by gnu-build-system by default.. or didn't it work without it? <adfeno>`make` doesn't recognize option --PREFIX <ng0>usually this is passed to configure. I can look at the Makefile tomorrow, I'm tired. <adfeno>There's no configure phase for these project. :) <ng0>\\(delete `configure\\) \\; FIXME: Configuration is done inside "config.h" file. ... should you place PREFIX then in config.h ? <adfeno>as far the Install.txt says, it's not there. <adfeno>I'll check something really quick... <adfeno>Oh... I have an idea of what might be the problem. <lfam>Sleep_Walker: I believe that issue has been discussed lately. Check the logs and mailing list archives :) <lfam>Ah, I see. I finally started dipping my toes into Emacs last night, but I can't tell the difference between bugs in Emacs and bugs in my fingers :) <adfeno>Well... I tried both preserving the #:make-flags (and tested to see if they worked, and they did), but still, make says that there's no rule for target "dynamic". <adfeno>I'll try forcing something like "CXX=g++", just in case. <sneek>Common_Era, you have 1 message. <sneek>Common_Era, efraim says: can you send an email to guix-devel@gnu.org with how you got guixsd to work on your Mac? <ng0>wow. this is surprising. how can i force a rebuild of a package? I don't know if the complete gnunet testsuite is fixed now in master, i need a double proof <ng0>changing parts and dependencies changed nothing <ng0>so tests are enabled, and if they do not run again and it's just grafted, it should be good <Common_Era>Hmm. I'm writing a configure.ac for Guile, as suggested by OrangeShark, but the command GUILE_PROGS can't be found. Do I have to link to it somehow? <lfam>ng0: Use --check --no-grafts <lfam>Otherwise --check only re-grafts instead of rebuilding <OrangeShark>Common_Era: GUILE_PROGS is from guile, you might want to use a newer version from guile because there has been fixes that aren't in guile 2.0.11 <Common_Era>Uhh. What's my the Guile prefix? Is it the one in the Store? I thought those weren't supposed to be modified. <Common_Era>I feel stupid, but the whole thing is kind of new to me, <lfam>Common_Era: Never modify any files in /gnu/store. Only the guix-daemon should write to /gnu/store <lfam>I don't understand your question <Common_Era>That's what I thought. But then, how can Autotools install site packages? I'm very confused. <OrangeShark>ohh, you mean the prefix to install a guile package? <cue>hi, during the file download of a SD install i receive a "--fallback' to build derivation from source" error <OrangeShark>then when you install the guile package in guix, it will just be symlinked in your profile <lfam>cue: The message is telling you to add the --fallback option to whatever command has failed <cue>uhm, the rest of the error message states that it should be added to a source build <lfam>cue: In Guix, all builds are source builds, but if there is a binary substitute available, it will be substituted transparently. The system is a hybrid of build-from-source and binary package management systems <lfam>cue: Something has gone wrong with the binary substitution process, which is not expected. Use --fallback to build from source <lfam>cue: Can you say which package was not substituted correctly? <cue>thanks a lot lf: i'll give it a shot; since i tried a couple of times already, thinking it might be a connection problem, i was wondering if it'd be possible to avoid mkfsing the partition ervery time <lfam>cue: What command failed, and which package did it fail on? <cue>lfm sure: it's the gnome-control-center-3.20.1.drv package <lfam>cue: And you are using the GuixSD 0.11.0 binary installer? <cue>uhm, i'm using the stick image <lfam>And which command fails? Is it `guix system init`? <lfam>cue: You can restart `guix system init` if it fails. It's not necessary to redo the entire installation set up process <cue>that's what i tried already, and everytime it manages to load a new package or two, then the error msg pops <lfam>cue: After the command fails, are you still connected to the internet? <lfam>Are you still able to ping gnu.org? <cue>lfam thanks for confirming that a complete redo is not necessary everytime <Common_Era>Should I be able to SSH into GuixSD by default? I have the ssh-daemon started and the computer is connected to the internet. <cue>lfam i probably better leave that ping on <lfam>cue: You don't have to leave it running. I'm just wondering if you are still able to reach gnu.org after the command fails <lfam>As the error message says, the problem is often caused by connection failures <cue>yes, if i well remember <lfam>Common_Era: Can you give any more details about your problem? <lfam>cue: In any case, use --fallback to build from source. If you are disconnected from the internet, it will fail anyways, because it will be unable to download the source code <lfam>cue: What CPU architecture are you using? <cue>lfam i'll give it another try and verify if it pings eventually even after the error <Common_Era>Not really. I try to SSH into my computer, with the private or public IP address (port 22 is open) and the connect refuses. <Common_Era>Anyway, apparently scp can copy to computers. I thought it was only one-way. <cue>lfam i'm using the i686 image <lfam>cue: Honestly, the best way to install GuixSD is to start with a bare-bones system. There is a lot less that can go wrong than if you are installing a graphical system. Once the installation is complete, you can reconfigure the system into a graphical system <lfam>cue: The system is robust once it is installed but, as you can see, the installation process is still brittle <lfam>Common_Era: It's hard to say what's wrong without any more detail, sorry <cue>i tried the scm file being suggested in the guix.info.gz <Common_Era>That's fine. I understand, I'm just not getting anymore details. Thanks, anyway. <lfam>Common_Era: Can you establish a connection with netcat? <lfam>cue: There is a 'bare-bones' template in the manual, too <adfeno>Hi again: quick question: Which package provides C++ compiller ready to use? <lfam>Common_Era: Does it fail when logging in, or to fail to connect completely? <cue>lfam ok i'll give that try too in case the --fallback options doesn't work <lfam>cue: I always install my systems that way. <Common_Era>I never get to the password prompt. Connecting fails. <lfam>Common_Era: I recommend debugging with netcat <lfam>Once that works, enable verbose logging on the server <Common_Era>I used scp and that is fine for now, but, yeah, I will. <cue>lfam luckily enough the screen utility is very handy <cue>laters, and, thanks again <ng0>bah. enough for today... I think there's something changed in the last commits in gnunet, but it's too late and I need to learn to quit it and not just work until I got something just the same day. <ng0>test suite is definitely being wokred on, but it doesn't run like it used to and it's also reporting to be not reproducible or what it was but someone already works on that in gnunet. <Common_Era>Alright, I've used guix download -f base32 on my git repository, but it gives me %invalid-base32-character on guix package -f guix.scm. <Common_Era>OrangeShark: Sorry for bothering you, but can you help? <OrangeShark>make a copy of the repo and delete the .git then run guix hash -r repo-without-git <ng0>guix hash -x -r DIRECTORY <ng0>guix hash --exclude --recursive <Common_Era>Alright, still getting that same error with the updated hash. <lfam>A problem with the hash? I missed the earlier part of the discussion <ng0>i don't know what you are doing. can you describe exactly what you are doing <lfam>Common_Era: Please share the patch that causes the error using paste.lisp.org or some other paste site <Common_Era>I'm using a package definition to build my package from my git repo. <lfam>ng0: I tried to review your latest perl-net-psyc and libpsyc packages today, but I can't reach psyced.org to download the source code <ng0>yeah that's a problem sometimes.. we seem to have gained *someones* interest and the server security is very good, but we its being probed or ddos or something.. not the first time in the last 60 days.. sorry. Where should i inform you when its back? <lfam>ng0: Use sneek to notify me <ng0>the situation is unfortunate.. using some kind of cdn or multiple servers anyway for the dowloads would be good.. <ng0>usually it is very stable. <lfam>The situation is unfortunate. My understanding is that DDOS attack are becoming more common across the net <lfam>And, I *had* the source code earlier today, but I had to `guix gc` <ng0>in the last cryptogram i read someone is probing the internet backbone over the last years. <ng0>but our attacker is specific but unidentified so far <lfam>It's a scary situation. DDOS attacks are often used to mask more targeted attacks or intrusions <ng0>lfam: download page /files/ works again it seems