<rekado>sneek: later tell suitsmeveryfine This is not a bug. When you use the git checkout and you run configure inside of ‘guix envirnoment guix’ a reference to the current guile executable will be embedded. There’s no gc root for it, so it will be GC’d. To fix this you only need to run the configure script again. <Petter>Hm, I've changed console (Ctrl+Alt+Fn) a couple of times now. Every attempt rendered my computer unresponsive, disabling my external monitor, and only showing a white underscore on a black background on my laptop screen. <Petter>I did hard reboots to recover :/ <gry>Petter: go to ctrl + alt + f1, f2, ... f6 for the virtual consoles, and f7, f8, ... for the gui ones <Petter>I tried Ctrl+Alt+F6 and Ctrl+Alt+F4. They disabled my external monitor, and Ctrl+Alt+F7 did not bring me back to the desktop. <Apteryx>Petter: Works for me. Intel integrated graphics. <Petter>I'll ask someone else with a X200 to try later. <lfam>Petter: I have an x200s. I have seen a similar problem a handful of times, when I was switching TTYs many times and / or quickly <marusich>Petter, I have an x200, and control+alt+FN keys work for switching to virtual terminals in GNOME. <marusich>However, I haven't run guix reconfigure in a couple weeks, so I might not be using the latest stuff. <marusich>Petter, also, I am not using an external monitor. <lfam>I haven't had that issue with an external monitor. I also don't use GNOME <Apteryx>Is there someone knowledgeable with guile-emacs in this channel? <reepca>working on a puzzle for an algorithms class. It's one where it *seems* like there's a really obvious solution, but the instructor is a tricky guy and you have this constant nagging suspicion. So okay overall. <Common_Era>I need to do some more programming. I'm kind of idle right now and I don't like being idle. <Common_Era>That's how I feel. I *need* to be occupied at every moment. <Common_Era>I got a nice little project set up earlier and I need to actually program now. <Apteryx>Found another small error in the manual: "The above commands only the use default output of the given <Apteryx>Let me try once more... "The above commands only the use default output of the given packages." --> should be: "The above commands only use the default output of the given packages. <Apteryx>albertoefg: What's that? Virtual machine software? <Apteryx>albertoefg: I don't see why it wouldn't work. It should work the way any GNU/Linux distro would. <Apteryx>albertoefg: Ah, Gnome Box is just a pretty and simplified front end for qemu <Apteryx>So if it's installed qemu must be as well. I suggest you just try and see what you like. <Apteryx>qemu is command line driven but you can always use virt-manager as a front-end if you are more a GUI person. <Apteryx>(or Gnome Box which I just learned about) <albertoefg>:) i wasnt aware of command line wirtual machines <Apteryx>Is it possible to configure an executable so that it always launches inside a guix environment? <Apteryx>I have standard emacs + guile-emacs installed, and guile-emacs needs the special environment treatment to avoid problems. <Apteryx>Any idea on how to make the fonts more smooth? I'm using the lightweight desktop configuration and it feels pretty 1995. <marusich>Apteryx, besides making your own wrapper, I don't know if there's something out of the box that always launches an executable in the same kind of environment you'd get with "guix environment"... <marusich>Not sure about the fonts, either. FWIW, things look pretty good in GNOME. <Apteryx>OK. Yeah that'd be easy to create a bash script launcher and put this in my path. I was just wondering if there was not a better way provided by guix! Thanks. <marusich>Apteryx, someone else might know, but I don't know <Apteryx>Good to know Gnome renders the fonts cleanly! I might have to inspect how they do it. <Apteryx>Would anyone know how to theme the IceCat browser? <Digit>"stylish" addon and a style (or several) from userstyles.org can get you quite far, Apteryx. :) <Apteryx>Digit: Thanks! That was tricky to install with IceCat but managed to do it. <Apteryx>Like your style, too! Although it looks like I have to match my X window color with it. <Digit>been a few months since i was on icecat, but iirc, about:addons is still a thing, albeit a bit different. and i think the install addon buttons from sites should still work too. some of the userstyles adapt more than the webcontent. for that, for gtk, i've long used lxappearance *checks it's available with guix package -s lxappearance* and tarkless: https://www.gnome-look.org/p/1014490/ <Digit>okies Apteryx. sleep well. :) <rekado>sneek later tell Petter I have an X200s with libreboot and I don’t see any problems switching VTs. ***Gottox_ is now known as Gottox
<csanchezdll>efraim: still trying to understand why the -boot0 versions of packages are pulled into build in our case <sneek>Welcome back csanchezdll, you have 1 message. <sneek>csanchezdll, efraim says: I reverted the expat commit on my aarch64 branch and I was able to build the static-binaries for the replacement aarch64 tar I wanted, so I can try that on the actual hardware in a few hours <csanchezdll>but if you want to go on you can confirm building the boostrap binaries using --no-grafts works <csanchezdll>ah, I see you reverted the expat commit, well, that's another way :) <csanchezdll>I am also advancing, back to real ppc hardware with re-generated bootstrap binaries ***the_ktosiek is now known as ktosiek
***fkz__ is now known as Guest82130
***Satyr1con is now known as Satyricon
<thomasd>ACTION builds QtWebKit5.7 for the 10th time... ***newdan_ is now known as newdan
<paroneayea>"guix build guile" isn't using a substitute here <paroneayea>if you fail to pull down a substitute, cancel the build, and rebuild, should it query for a substitute the next time, or will guix just jump to try rebuilding from the tarball it had pulled down again without querying for a substitute? <paroneayea>ACTION nervous to run guix gc right now after experiencing that recent "all my fonts stopped working" issue <catonano>paroneayea: don't run gc if you don't want to <catonano>paroneayea: I experienced this a couple of days ago too <catonano>paroneayea: I just let it build guile again. The good news is that with the current guile 2.0.11 the build process succeeds and it is not so long ***Sleep_Worker is now known as Sleep_Walker
<rekado>should qemu-system-arm work with KVM? I’m trying to build gcj in an armhf VM, but it’s very slow and I cannot seem to use KVM. <rekado>(KVM doesn’t work on libreboot anyway, but it’s a different error message when using qemu-system-i386) <paroneayea>configure:13082: error: possibly undefined macro: AC_LIB_LINKFLAGS_FROM_LIBS <wingo>paroneayea: probably you didn't have the right environment when autogenning the package <wingo>or perhaps i have a local file? <wingo>indeed that should be included in your aclocal.m4 <wingo>so don't regen the package, just package a release? <wingo>autoreconf creates aclocal.m4 as needed <wingo>evidently you didn't have the right ACINCLUDE path or whatever when you autoregenned the package <paroneayea>wingo: ok, I'm trying to package the v0.3.0 tarball from the guile-fibers page <paroneayea>but that's using effectively a git tag, it sseems <paroneayea>wingo: fibers should accept guile-2.1.* as guile-2.2 right in its configure script? <wingo>paste the config.log i guess <wingo>make sure pkg-config is a native input also <wingo>i think otherwise it won't get the pkg config path propagated i guess <paroneayea>ice-9/boot-9.scm:753:26: In procedure dynamic-link: file: "epoll", message: "file not found" <wingo>i guess you will have to munge the load-extension line in (fibers epoll) <wingo>right now it assumes that the $prefix/lib/guile/2.2/extensions or whatever directory is actually searched by guile <wingo>surely it should build tho, right? <quigonjinn>I'm going to submit a package that has optional github support. Should it be buitl without it, due to github not being reccommended by the fsf? <paroneayea>wingo: I guess epoll comes from... the currently installed kernel? <wingo>paroneayea: no, it's an extension built in the package <paroneayea>wingo: sorry, I was being dumb. my mind jumped to packaging tricky ffi packages in the past. <paroneayea>I'm not being quite as dumb as I thought, it is FFI related ;p <paroneayea>I'm not sure how to handle that. I'm not sure if the path needs to be hardcoded... if so hardcoding the path for "make" and then "make install"... they'd be two different hardcoded paths. <wingo>i can help later, finishing up some other stuffs <rekado>I packaged fibers before. I hardcoded the path to epoll. <enderby>hi, I'm having trouble getting systemd to start guix-daemon on startup. I'm on Fedora24 and have run the cp and systemctl commands, but it never starts the daemon. So i have to start it manually every time. Do I need to do something else too? <rekado>enderby: have you enabled the systemd unit? <enderby>is that just running 'systemctl start guix-daemon && systemctl enable guix-daemon'? if so, then yes <rekado>quigonjinn: enabling github support doesn’t seem like a problem. <paroneayea>rekado: if you're interested in finishing the fibers package and doing that hardcoding, you're welcome to take it up :) <enderby>when i run systemctl, it lists "guix-daemon.service loaded active exited Build daemon for GNU Guix", but I don't have any failures when I do 'systemctl --failed' <ng0>someone should open a general aspell bug if there isn't already one. at least for weechat it's not functional. but i think that's what the discussion with jookia was about <rekado>enderby: starting it manually works, though, right? <roptat>icecat crashes often and doesn't always play sound <Petterr>roptat: Do you have multiple IceCat windows open when it crashes? <sneek>Welcome back Petterr, you have 1 message. <sneek>Petterr, rekado says: I have an X200s with libreboot and I don’t see any problems switching VTs. <Petterr>rekado: Thanks for checking. I've later discovered it only hangs when I use my external monitor. <Petterr>rekado: Are you using an external monitor? <Petterr>roptat: Ok. It crashes often for me when I use multiple windows. <roptat>I mean, no, I use a single window <Petterr>When I have multiple windows open is also when I download a lot. Are you downloading when it crashes? <ng0>i wnated to drop back to the very familiar ground with gentoo to reduce time I spend creating the system I want, but now I have only one native gentoo system again because the positive thing about guixsd is that even when it's beta it's less annoying to maintain :/ <roptat>no, it happens when a loads I think (new tab, or link, or redirection) <roptat>but not always and after like half a second <ng0>roptat: did this happen before? <Petterr>Then you're downloading page resources. <roptat>and after that I can open the page properly <ng0>with earlier versions of icecat i mean <roptat>ng0, I used firefox before, so I can't tell <ng0>but that's the same.. depending on versions used <roptat>that never happened with firefox ***Petterr is now known as Petter
<rekado>Petter: let me try this with an external display. I only have a projector here, though. <Petter>My monitor is connected through a docking station, on DisplayPort. <rekado>oh, I don’t have display port, only vga <Petter>Would be interesting to see if you have any issues with VGA. <rekado>I cannot reproduce this with a projector attached to my VGA port. <Petter>Hm. I'll see if I can find a VGA cable. Maybe my probem is with DisplayPort. <lfam>I was worried, based on earlier comments, that the Go team was going to let Go 1.4 bit-rot. But it seems they are interested in making sure it remains possible to build it <Petter>Are there other tricks than Alt+PrntScrn+REISUB to reboot a unresponsive system? This trick don't work for me when my system crash after changing console. <alezost>I think if these sysrq keys don't work, then reset (or power) button is the only solution :-) <Petter>Thanks! This is what I've been doing :/ <Petter>I'm connected with VGA now, about to change console. Fingers crossed. <Petter>So, DisplayPort... looking at you. <roptat>Petter, changing VT hangs with VGA here <Petter>Could someone change console and back, and run "dmesg | tail -n 30" and see if there's a Call Trace? <Petter>roptat: Interesting! What is your setup? <roptat>I use a desktop station, with a graphics card <roptat>with the other one (that made xorg crash) changing VT hanged <roptat>the screen went black for a few seconds and then on again <roptat>but with my new (older) card, I can't reproduce <Petter>Can you try the dmesg command after and see if there's a Call Trace there? <roptat>there's nothing special in that command output <Petter>I get this Call Trace both with VGA and DisplayPort. With DisplayPort though it doesn't recover. <Common_Era>I've built my program with NCurses, but when I try to run it, I get a message saying that libncursesw.so.6 is not found, even though it's in the lib folder of my .guix-profile. <Gamayun>Petter: Hm, never had an issue with that.. Is it a weird laptop keyboard? <Petter>It looks like a DisplayPort issue. It works with VGA. <lfam>Common_Era: Try using `readelf -d` on the binary that fails to see what it's runpath is. Also you could try running the program with `strace` to see where it's looking <Petter>I'm using an external monitor by the way. <Petter>(Guess that went without saying.) ***kelsoo1 is now known as kelsoo
<Common_Era>What can I do with the output of readelf -d on that binary. <lfam>Common_Era: What is the value of the RUNPATH section? <Common_Era>Library runpath: [/gnu/store/xl19qrfzga52vrvp4ncccwjlnrjqwj95-ncurses-6.0/lib:/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib:/gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib:/gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/gcc/x86_64-unknown-linux-gnu/4.9.3/../../..] <lfam>Okay, and can you also run it with strace to see what it's doing? `strace -f -o /tmp/logfile $cmd` <lfam>efraim: Some of onionshare's dependencies are failing to build on core-updates. Do you want to take a look? <Common_Era>I get too much output to copy here, but I don't quite know what to do with any of it. <lfam>Common_Era: Put it on paste.lisp.org <ng0>is mumble problematic to package? <Petter>I believe Dave has tried to package Mumble. <rekado>Common_Era: when you say “I've built my program with NCurses” … how did you do that? <rekado>Common_Era: the lib directory in your .guix-profile does not behave like /usr/lib. If you want your program to find the library it needs to be told about the location. <ng0>mumble would be valuable.. like, it's part of the primary stack of applications why I keep gentoo as a user system around in addition to a developer system <rekado>Common_Era: when we package software for Guix we build in an environment where LIBRARY_PATH (among many other environment variables) is set to contain the lib directories of all declared inputs. <Common_Era>I see. I've just "sudo make install"ed, without a package definition. I modified path to include the prefix. Is that bad practice? <lfam>You should make a Guix package and use `guix package --install` <lfam>I suppose it's possible that you could make `make install` work, but it's ont recommended <lfam>I haven't experimented in this area, but I _think_ that if you want to use `make` like that, you should be using the gcc-toolchain package instead of a gcc package. <lfam>If you want to go that route, I'd recommend you ask on help-guix@gnu.org <Common_Era>Is there a method in origin for package definitions that lets me fetch a local file; I don't have any sort of hosting and don't want to set up Git yet. There's nothing in the manual, but I feel like I remember it being possible. <lfam>`guix build --with-source` ? <lfam>You should also be able to pass a local filesystem path in the origin <Common_Era>The latter is what I want to do. Using url-fetch? <lfam>Check out 5.1.1 Package Reference for more info. I haven't used this feature in over a year so I don't remember exactly how to use it <lfam>Whoever uses ipython should try updating it. It's failing to build on core-updates and there have been several releases since we packaged it. <rekado>lfam: I have a couple of ancient patches for updating ipython to 4.0.0 (which is also outdated now) <rekado>I hope I can still rebase them and make it build. <lfam>Ancient patches... they don't get better with time :) <lfam>I'm also looking at joblib, which is failing on core-updates as well. I tried updating it and adding all the dependencies it asked for, but there are several test failures <lfam>Ldc is failing to build on core-updates... we just fixed that on master! <lfam>I think the ldc failure is spurious. The build log looks like a success to me <rekado>did fftwf change…? it’s complaining about not finding the lib <lfam>fftwf has not changed according to `git log`. Assuming the commit message are accurate :) <lfam>Many failures of R packages due to missing tarballs :( <lfam>Oh, new 4.1 kernel. I'll update that <lfam>Assuming we want to keep it now that the libreboot / x200 clock issue is fixed. IIRC we kept the 4.1 kernel specifically because it avoided that bug <lfam>paroneayea: Keep your eyes peeled for new bugs. Else maybe we will can drop the 4.1 kernel series <lfam>I mean to say, Else maybe we can drop the 4.1 kernel series. <ng0>peel your eyes for bugs <paroneayea>I'm not sure I trust the Linux kernel to really do LTS <paroneayea>given that they don't label security issues as security issues <paroneayea>how do we know that things are being backported? <lfam>I'm pretty sure that GKH has some idea of what to backport and what not to <lfam>Of course, it's basically impossible to get it totally right in a project that size <lfam>I bet you could watch the LTS commits to learn where to look for important bugs <lfam>I guess there's no harm in keeping the 4.1 series around for as long as its supported <paroneayea>I think it's a good idea, since a number of people are still running minifree laptops that have the bug that linux-libre-4.1 isn't susceptible to <lfam>Okay, no rush anyways :) <ng0>4.9 will be the new lts i heard <ng0>when 5.x will be out <lfam>I just love dropping old versions of things! Looking at python-hacking gave me the heebie-jeebies <lfam>paroneayea: Yeah, it's a good time to test your backups ;) <lfam>And yeah, I think that 4.9 will be the next LTS kernel. Unless too many bad patches go in, which apparently tends to happen when people know that an LTS is coming <lfam>"Just one more patch ...."