<maddo>Hello, is there any news on the ppc64le port? <sisyphe_>sorry, no answer for the books (and I can't help on this...) <eubarbosa>sisyphe_: are there any guile scheme 2.2 compatible scheme book? <bavier`>maddo: there's interest from a few people, if you'd like to help, maybe check or write to the guix-devel mailing list <pkill9_>joshuaBPMan: the build might be failing <pkill9_>that's something that would be nice to have, ability for substitute servers to tell clients that a build fails, so the client doesn't try to build it <maddo>bavier will do, I have a T2 comin' in a few weeks <maddo>>international shipping and all <mange>eubarbosa: I'm pretty sure SICP works fine with Guile, and from a brief look Little Schemer should be fine if you implement the "atom?" predicate. <tune>wanted to try out awesomewm but it doesn't show up on my login screen when I hit f1 a bunch <tune>I've got i3 installed in system profile and awesome in user profile if that matters <tune>I'm not sure how the display manager checks for environments <eubarbosa>tune: maybe you should install it with reconfigure... <tune>yeah I guess I'll do that <eubarbosa>Conversely to that, I install wm as user and call it with .xsession <tune>on other distros I typically have a .xinitrc and use startx, but my guixsd install has always had a graphical login <tune>I think it's part of %desktop-services <eubarbosa>tune: same. Slim( login manager) reads .xsession file and ignore wich wm you select at login <eubarbosa>tune: I am after to get rid of most destktop packages too <tune>alright installing it in system config and doing a reconfigure made it show up <tune>but I'll remember the .xsession thing for the future also <eubarbosa>I recall that %desktop-service is a bunch of services meant to cover full blow desktop DEs. In our case, WM dont need most of it. Up to search what to use instead <mange>I use awesomewm and have it installed as a user package. I can use it fine, but it doesn't show up as a login option. I've configured XFCE to start it instead of xfwm. <eubarbosa>mange: you can use ~/.xsession instead of XFCE, just call awesome with 'exec awesomewm' <eubarbosa>Slim( login manager) reads .xsession file despite which wm you select at login [ <mange>Using .xsession means that the rest of XFCE doesn't start up, though. <eubarbosa>oh, So you really WANT to start awesome inside XFCE! Ive heard about it! Cool <mange>Yeah, it's actually more annoying because I haven't figured out how to reliably save that to my dotfiles, which means that I have to remember how to configure XFCE whenever I make a new machine. <eubarbosa>mange: I dont think DE, others than KDE have that export config feature <mange>Yeah, but I would have assumed they would be in a file somewhere in my home directory. XFCE stores config under ~/.config/xfce4, but I have had issues trying to transplant the (relatively straightforward) XML files from one installation to another. <mange>It's not a bit enough problem for me to actually work out how to fix it, just a mild annoyance every now and then. <Swedneck>xfce is apparently supposed to have an export option ***Piece_Maker is now known as Acou_Bass
***joehillen_ is now known as joehillen
***langdon_ is now known as langdon
<reepca>strace indicates that it's getting stuck on a recvfrom system call <mange>reepca: Are you the only one seeing this? I could run that command without issue. <reepca>mange: hard to tell, I haven't tried running it on another network, seeing as the only systems on other networks I have access to don't have guix. But I've been able to reproduce it twice. <mange>Could also be kernel related? <reepca>that reminds me, I never found out if anyone else's guix download got stuck with texlive either <mange>The command from your email? I'll try it out. <reepca>also, once again the download works fine with wget <mange>I'm on 4.15.0-43-generic, which means I can't confirm the kernel. I'm not on GuixSD, so I'm hesitant to try changing my kernel. <reepca>what's your guix version like? I'm using a recently-rebased development branch with pre-inst-env that shouldn't have any differences on the download parts, will check it with my user's guix now and see if problem persists <mange>I'm on a custom branch coming off 6df4d8338, but I think I've only changed packages. <mange>The texlive download just finished. It stalled at 100% for a little while, and took up a lot of a CPU, but it completed. <reepca>my user's on a773f141c and it's getting stuck. Maybe my kernel is drunk on lack of sleep. <reepca>I guess I could grab my laptop and try reproducing there, in case it's a network driver thing <mange>Unfortunately I have to go to a meeting, so I can't test anything else for you, but good luck! <reepca>mange: thanks, you've given me much to consider <reepca>hm, download finishes just fine on my laptop - linux 4.18.5-gnu with guix 40c7476af <reepca>(download of the 0ad stuff, that is) <bavier`>the telepathy-glib build on my system sometimes fails when built with parallelism (i.e. with '--cores=1' never fails) <bavier`>this appears to be due to a race condition with python loading cache files that might not be completely written <bavier`>I don't know much about this aspect of python. I'd assume there'd be some protection against that <bavier`>The error I sometimes get is: from libtpcodegen import file_set_contents, u <bavier`>EOFError: EOF read where object expected <reepca>reconfigured and rebooted laptop, it's now on linux 4.20.0-gnu and pulled to latest guix, let's see if it still works... <noobly>will guix continue to depart from unix style OS's as hurd is developed? <reepca>laptop still succeeds at download. Puzzling. Perhaps something specific to 4.19.8? <reepca>so I was looking through the wget source code trying to figure out why it's working, and came across a comment that says that "the HTTP spec doesn't require the server to actually close the connection when it's done sending data", which is problematic considering our http client implementation tries reading until EOF... <mange>Then how does the HTTP server say that there's no more content, if it hasn't sent a Content-Length header? That also wouldn't explain issues with FTP (but I have no idea what the FTP protocol is like). <reepca>I haven't read the spec, but if that comment is correct I'd assume it's left up to the implementation whether to terminate the connection or send a content-length header, but at least one must be done. <reepca>the FTP spec *does* require that the connection is closed when all data has been transferred, but for some reason my system never gets wind of it happening when a lot of data has been sent. <reepca>I would guess that in practice most/all http servers do close the connection when all the content has been sent, including the one being used here, and the same issue experienced with ftp (certain connection terminations not being detected on my system for some reason) is causing the issue with http, and wget just happens to work around it. <reepca>I get the feeling that if I just reconfigured and rebooted the problems would all go away, but then I'd never know what exactly was causing it <reepca>and I have a lot of stuff open... ***Noctambulist is now known as Sleep_Walker
<reepca>hm, how can I get sudo to use my guix? guix --version and sudo guix --version both report the same stuff, but "sudo guix ..." gives a warning about being 11 days old on some commands, and I /just/ did a guix pull for my user. <efraim>sneek: later tell ng0 if you get guix's dependencies ported to pkgsrc I'll try it out on my PPC <reepca>ah, I think I see the problem... the warning uses $USER to look up which file's modification time it should use, so it looks at root's modification time. Because apparently sudo -E still changes $USER. <ArneBab>Is there a package for HTCondor somewhere? <reepca>anyone else try to do some emacs-guix command, and then it says "Starting Guix REPL ..." in the minibuffer and it all freezes up until you spam C-g, after which you can run commands fine? <reepca>desktop is now on linux 4.20.3-gnu with what is as far as I know the latest guix version, and still it gets stuck at 100% <efraim>I've heard there can be problems with the REPL in emacs consuming all the memory <efraim>I'm not an emacs user so I'm not sure <efraim>Have you already run make in the directory? I've heard that helps ***rekado_ is now known as rekado
<rekado>reepca: like efraim said, having a lot of uncompiled files ensures that the REPL will take a very long time to start. <g_bor>Blackbeard: can you give us some more context? <reepca>I was under the impression that "guix pull" automatically compiled the files for me - in this case I'm using standard guix-pulled-an-hour-ago guix. <g_bor>Is this a bare metal or a vm? <Blackbeard>i only get a build error and it says it is usually because i ran out of space <Blackbeard>i tried erasing generations and the garbage collector <g_bor>Blackbeard: what does df say? <g_bor>is it possible that you run out of space on some other filesystem? <g_bor>also why does it try to build icecat? <Blackbeard>it says build failure that usually happens because i lack disk space <g_bor>do you have substitues enabled? <cnmne>I don't know if this is good advice, but sometimes I get memory errors on my vm and I just run the command again and it goes through <Blackbeard>when i update or anything it says it is downloading files from the new build server <roptat>How much ram do you have on the machine? <roptat>My guess is you run out of space on /tmp, which is a tmpfs on most distros <roptat>Also, could you post the build log on paste.debian.net? <roptat>Ok, that should be more than enough <roptat>Can you unmount it and try again maybe? <Blackbeard>the build log is huge all that it says is run out of space <roptat>Sure, but I think icecat needs more than 2g of files <Blackbeard>i was also checking with du to make sure it wasn't full <Blackbeard>but i will do it in the morning, it in 2:15 right now for me <roptat>According to LFS, firefox needs at least 9g <Blackbeard>it is weird because is the first time this happens <roptat>That will make you swap a lot though <roptat>Icecat? Did you get substitutes before? <g_bor>Do we have a template for business cards? <g_bor>I'd like to have some printed for FOSDEM. <g_bor>Also, I've mentioned earlier that I could have some reference cards printed. <g_bor>I am going to send my stuff for printing this week, so if we need that I need to know how many to print. <civodul>g_bor[m]: we don't have a template for business cards <reepca>anyone have any idea why my desktop system would be mysteriously cursed to randomly ignore sockets closing? The laptop with a very similar config.scm does just fine... <reepca>civodul: did your guix download of texlive ever finish? <reepca>at this point it seems more likely that it's actually neither an issue with the servers nor with the guix download code and more like it's something inherently wrong with my system <reepca>so I guix pulled and reconfigured, got up to the latest kernel, and downloads are still getting stuck :-/ *civodul tries downloading 0ad <reepca>that one worked fine for mange too ***w2gz is now known as w1gz
<civodul>are you sure it's not something on the network that's blocking transfers? <reepca>my desktop is directly connected to the same wireless router that my laptop uses, and it succeeds on my laptop <reepca>and it's not like it's blocking transfers, it's just messing up the connection termination <reepca>and only in very specific cases, apparently <reepca>having to do with connections that lots of data pass through <reepca>I'm at a bit of a loss as to how to debug this. I could try to write a minimal test program, but I already have a good idea of what happens: the connection never gets closed. Whatever mechanism is supposed to do that is probably in the tcp/ip stack in the kernel somewhere, right? <civodul>did you make sure you have precisely all the bytes of the file when it hangs? <reepca>hm, no I haven't. I strace'd wget (which succeeded at downloading) and ran it with --debug and it never had to retry anything and just did a bunch of recvfroms, and it got all of the bytes (it stopped once it got the amount corresponding to the content-length header). But in the texlive-over-ftp case it did time out and have to restart for the last 200 or so bytes, so it'd be worth checking out. <reepca>civodul: it ends up getting stuck with 691929088 out of 691973492 bytes read. <reepca>which makes me doubly confused, because now even using the content-length header, wget should get just as stuck. <g_bor>civodul: Thanks for the info. <eubarbosa>maddo: I hope Guile Emacs takes off this year <eubarbosa>maddo: wlroots is almost done, so I expect EXWM maintainer to begin his wayland port ... <g_bor>Then I intend to create a business card template. I would like to create it as a 85*50 mm size, so that it can be printed on both the 90*50 and the 85*55 sized cards. Is that ok for you? *rekado reconfigures berlin <g_bor>also, if we would like to participate in the FOSDEM keysigning the deadline is Wednesday, 23 January 2019 <maddo>eubarbosa: I was under the impression guile-emacs was dead and the EXWM main dev can't port exwm to wayland because emacs is not a real GTK app, thus it doesn't work natively in wayland <maddo>I mean last commit to Guile-Emacs was in 2015 and it was mostly a one-man effort <eubarbosa>maddo: yep, Exwm guy said that Emacs need to ported to wayland/gtk too <eubarbosa>maddo: well, I will restart this one-man journey, again! :D <maddo>oh it was you? I didn't know, it's only recently that I got into the emacs (and libre actually) world <rekado>the (current-guix) package fails to build on berlin. It fails to patch tests/syscalls.scm. <eubarbosa>but I reckon most FLOSS projects are "done" that way. One begin, and other people keep on with its progress!! <rekado>ha, that’s because the source code for guix-current only includes “gnu” and “guix”, nothing more. <cbaines>gnome-shell has been crashing for me for a little while when I've been opening the activities overview. There are some messages about problems loading icons. Is this a known issue? <cbaines>I'm guessing it's something system specific, as it's only one of my machines with this issue. <pkill9_>cbaines: i think it is, but it's been a while sinc ei last used it <pkill9_>it's due to gnome-shell not handling missing icons or something <pkill9_>yeah im starting to remember, i think gnome-shell tries to find a cursor icon and just crashes if it doesn't find it, the solution i had at the time was to copy the default cursor to the filename that it looks for <nly>i have a test `--mirror` repository in /srv/git/guile-web.git <cbaines>so what are you seeing instead of cgit? <cbaines>So the Guix docs say by default, cgit can be accessed on port 80 <rekado>civodul: I’m not so sure about this any more. <nly>locally nginx is running on 80 <rekado>civodul: but this one guix-current source checkout is certainly weird. <nly>localhost:80/git is again 404 <nico202>Hi, is anybody working with julia? Someone is willed to upgrade the current guix version to the 1.0.0 release? I'd really love to see also the julia pkgs inside guix <nico202>I wanted to try the upgrade but my btrfs broke and I need to install guix again -.-" <nly>even `herd status cgit` returns service 'cgit could not be found <rekado>nly: that’s expected. There is no cgit shepherd service. <tune>I restarted awesomewm and instead of restarting in-place as expected, it sent me back to the login screen. Is this a bug? <tune>I've seen in youtube videos that it's supposed to just flash for a sec and leave your stuff running, like I'm used to with i3 <tune>it shows a TTY with text scrolling by briefly and then I'm back at the displaymanager <tune>I don't think it's supposed to restart x11 <tune>there's another bind to quit awesome which feels like what is happening <cbaines>nly, the fcgiwrap is the relevant shepherd service for cgit <nly>Status of fcgiwrap: It is started. <nly>;; Make sure fcgiwrap is instantiated. <nly> (service-extension fcgiwrap-service-type <cbaines>nly, I think the virtual-root configuration only gets passed to cgit <cbaines>You'll need to pass in your own nginx configuration to make that work <nly>thank you, like so? (cgit-configuration (nginx (list MY-NGINX-CONF))) <cbaines>Yep, although for my configuration, I don't pass it in wrapped in a list <nly>2019/01/18 17:01:57 [warn] 9505#0: conflicting server name "nly.info.tm" on 0.0.0.0:80, ignored <nly>i don't understand the %cgit-configuration-nginx object in cgit.scm <cbaines>nly, I think you need to work out how you want the nginx configuration to work, and then work out how to set that up with Guix <nly>yes, looks like it. Thanks :) <g_bor>I am making some really nice progress with openjdk reproducibility. <g_bor>It seems that there are only three files differing in the jdk output. <g_bor>I am now running diffoscope, to get some info. <g_bor>One file seems to be problematic to me, the other two: just don't know... <g_bor>the problematic one is lib/modules <g_bor>it is according to the doc something binary with undocumented format... <roptat>I don't know if you read it, but I've built sbt from a binary scala yesterday :) <roptat>the first thing it does is to download a binary version of itself though <g_bor>It's a bit sad it does that... <roptat>now I have a few more things to do: have an sbt-build-system that mirrors the way binaries are cached, rebuild generated scala code with contraband, continue building gradle, bootstrap scala and have a look at kotlin <lsl88>g_bor: hi! sorry, do you have your IPFS up? <civodul>rekado: do you have a link to the build log of the failed current-guix? <rekado>no, I don’t. The problem is with generating the source directory, though, not with the build itself. <rekado>civodul: the broken source directory is /gnu/store/msw7c5acy1sd7mdpvw1dl2da0v36n8m8-guix-current/ on berlin. <rekado>a good one for comparison is /gnu/store/32mdm49hgvp05f3j7limkdjvp82r37np-guix-current <rekado>the broken one was already there; I didn’t create it. I wonder if it was a left-over from an old build. <civodul>rekado: i'll take a look, but i'm guessing this happened when we switched to evaluations in inferior <civodul>because there we no longer have the full source tree <civodul>you get the same error i guess if you run: guix build -e '((@ (gnu packages package-management) current-guix))' <rekado>Well, I no longer get it, which is annoying. <rekado>I applied a patch to delete the offending build phase and tried again <rekado>that gave me a proper source directory <rekado>I removed the patch again, and things are still fine. <rekado>so I don’t think you should waste your time to look into this. <rekado>I’ll look at this later tonight. <rekado>here’s what I did on berlin: GUILE_LOAD_COMPILED_PATH= /home/rekado/guix/pre-inst-env guile --no-auto-compile ~/maintenance/hydra/install-berlin.scm 4 <civodul>rekado: so the machines are reconfigured with qemu-binfmt? <g_bor>any idea how to get diffoscope.comparators.java.Javap into the path? <g_bor>roptat: diffoscope tries to pick up its comparators at runtime from the path, that's why inputs are propagated. <g_bor>Now it complains that this is missing... <roptat>ah, I think you need icedtea:jdk <g_bor>I've also found a nice thing... There is a jmod file, which is a zip with a binary header, and there is a jar packed inside it... ***slyfox_ is now known as slyfox
<tune>a friend on arch confirms it doesn't happen to him <pkill9_>does it fail for anyone else when guix tries to get the channel for an inferior? <sisyphe_>where should I report a package failing to build ? I currently have two of them : perl for arm-linux-gnueabihf and python2-ipython ***ym555_ is now known as ym555
<civodul>sisyphe_: you could discuss it on guix-devel <civodul>not that not all packages cross-compile fine <civodul>often it's an upstream issue, so we make no commitment here <pkill9_>guix package: error: failed to load '/root/system-config/user-packages.scm': <pkill9_>it's the same thing when i tried to build a system config which uses an inferior <pkill9_>i'm using guix commit e6ab20f71d9fd4bb49ad0d004262f787552e6c14 <pkill9_>and both of them (the manifest and the system config, using an inferior) worked before <pkill9_>oh it's a mailing list not an irc channel ,lol <rekado>civodul: I was going to reconfigure the build nodes, but that’s when I noticed that I need to use (current-guix) instead of just “guix” to build the system and reconfigure on the remote. <jlicht>I am so psyched for FOSDEM and the fringe event :) <civodul>pkill9: with your manifest i get: "browserpass: unknown package" <tune>if one of my monitors is in portrait and has to be rotated via xrandr, what's the best way to do this automatically? *civodul does this manually <tune>yeah I do it manually so far... had a keybind for it in i3 even <tune>but I was thinking there's a better way <pkill9>(actually it's not private except some of those packages, i haven't gotten round to submitting them) <civodul>pkill9: on my machine it's building blender... <civodul>which i guess is what you want, except that there's no message showing up <pkill9>ah hmm, i wonder what's wrong on my machine then <bavier>I managed to build out my current profile on the core-updates branch <sisyphe_>guix refresh keeps failing with the following message "Error downloading release information through the GitHub API. This may be fixed by using an access token" <bavier>sisyphe_: github does rate limiting on their API when not using a token <civodul>bavier: re core-updates, you're ahead of time, we still haven't merged staging! :-) <bavier>civodul: well, good to give it a test anyways <roptat>it has a link for you to get a token <sisyphe_>good to know, however it is still failing bu with this new message <sisyphe_>"Error downloading release information through the GitHub API when using a GitHub token" <sisyphe_>should I give specific authorization to this token ? <bavier>sisyphe_: that can happen, it may be that the package has no release information <civodul>bavier: the error message would be different, though <bavier>I didn't investigate too far the last time I tried the github refresher <thomassgn>huh, guix started complaining about 'In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f' from one of my module files encoded as utf-8. most of my scm files are encoded ascii... ***janneke_ is now known as janneke
<rekado>I’m having problems updating the core-updates branch. <rekado>there are a few conflicts that don’t have obvious resolutions. *rekado pushes some packages needed for the gnome updates to master <rekado>bavier: one thing that’s confusing to me are, for example, CVE fixes or grafting commits. <rekado>It would be best to have those ungrafted on core-updates right away to avoid confusion. <Misha_B>I'm trying to setup the bitlbee service, with bitlbee-discord plugin, but it fails with 'ERROR: In procedure %resolve-variable:Unbound variable: bitlbee-discord' <Misha_B>this is the configuration (service bitlbee-service-type (bitlbee-configuration (plugins '(bitlbee-discord)))) <Misha_B>and I've declared both gnu packages messaging and gnu services messaging modules <Misha_B>and added bitlbee-discord to the packages list <rekado>'(bitlbee-discord) is a list of symbols. Is this correct? <Misha_B>it works with (list bitlbee-discord) <leungbk>after running guix environment guix, then ./bootstrap, then ./configure --localstatedir=/var, and finally make check, i get this after a few mins: <leungbk>18 (primitive-load-path "gnu/tests/base" #<procedure 4e1a040 at ice-9/boot-9.scm:3001:37 ()>) <leungbk>gnu/tests.scm:208:16: Throw to key `record-abi-mismatch-error' with args `(abi-check "~a: record ABI mismatch; recompilation needed" (#<record-type <bootloader-configuration>>) ())'. <leungbk>Some deprecated features have been used. Set the environment <leungbk>variable GUILE_WARN_DEPRECATED to "detailed" and rerun the <leungbk>program to get more information. Set it to "no" to suppress <leungbk>make[2]: *** [Makefile:5419: make-go] Error 1 <leungbk>make[2]: Leaving directory '/home/brian/mygit/guix' <leungbk>make[1]: *** [Makefile:4499: check-recursive] Error 1 <bavier>leungbk: do the 'make clean-go' thing <leungbk>make[1]: Leaving directory '/home/brian/mygit/guix' <rekado>please don’t paste so much output here. <leungbk>make: *** [Makefile:4967: check] Error 2 <bavier>leungbk: and use a paste service in the future