IRC channel logs

2017-12-22.log

back to list of logs

<pkill9>do Guix packages not honour the LD_LIBRARY_PATH environment variable?
<str1ngs>pkill9: generally its not needed. due to rpath being hardcoded
<pkill9>i'm trying to get guix applications to use my system's libgl
<pkill9>which i patched and put in .nix-libs
<pkill9>it works with Nix but not Guix
<pkill9>oh i think it's cos linux-lbire is deblobbed, ah well
<pkill9>not that that's a bad thing, but i just don't understadn this stuff enough to be able to add support for the nvidia drivers in my system to my install of Guix
<Apteryx>rekado: Per commit facac2928, you'll at least get a warning for symbolink links that don't exist at build time. It also fixed a bug that was creating broken links in our manpages compression profile hook. I'm curious where your error occurs exactly?
<rekado>Apteryx: the problem is with old profiles that still contain packages with broken symlinks.
<rekado>A user here has an old profile and hasn’t upgraded it for the duration of a project. Installing a new package into that profile (while keeping all existing packages unchanged) resulted in a failure to complete the man page hook.
<Stream>there is only linux libre kernel available?or there are also linux libre lts and so on?where can i find such information?
<brendyn>I can't see any lts kernel in the repo. I guess you could package it.
<Stream>i dont know how to do it, i dont even understand how to change slim to gdm
<wigust>Stream: Changing the kernel will not fix issue with monitor if it is a reason to you want to change
<Stream>no it is not related, just i had parabola with linux libre and it got broken, having lts kernel as a fallback option would help i think
<wigust>Stream: Did you ask on #parabola channel?
<Stream>no, it seems i need a usb flash drive to fix this issue but i dont have any, i thought i might buy one but then i dont know if it is a free software or not, also i found out that some flash drives have proprietary software built in that cant be deleted. and i dont know where to ask such questions whether x is free software or not
<wigust>Stream: There is https://www.fsf.org/resources/hw Also #gnu and #fsf good channels for such questions
<rekado>Stream0: we have a bunch of different kernel versions packaged.
<rekado>4.1, 4.4, 4.9, and the latest.
***Sahil is now known as mubarak
<brendyn>rekado: so the lts is not a different package name?
<wigust>brendyn: Yes.
<civodul>Hello Guix!
<cbaines>Morning civodul :)
<cbaines>efraim, I think using the system wiredtiger breaks MongoDB, at least the system test doesn't pass for me with that change, would you be ok with reverting it for now, just to get the service working again?
<cbaines>I think the other way of fixing it might be to enable snappy compression in the Guix wiredtiger package, I'll try that now
<efraim>cbaines: I think the issue with the bundled wiredtiger was that it doesn't recognize aarch64
<efraim>but if it has to be then I can work on fixing that part
<cbaines>efraim, the problem I'm having looks to be the lack of the snappy compressor with the Guix wiredtiger package
<cbaines>so I'm currently trying out adding the --enable-snappy configure flag, and building and testing MongoDB
<cbaines>hopefully that will work
<taohansen>so we have a ton of emacs packages bundled up as guix packages. i’m curious to know what emacs users here do to specify configs for installed packages. (use-package :local)?
<wigust>taohansen: After installing an Emacs package it will be auto-loaded, so no need for use-package. Then you configure it with "setq" or "customize" as usual.
<taohansen>wigust: is there no way to defer a “guixed” emacs package’s loading for the sake of speed?
<wigust>taohansen: you could even use guix-emacs-autoload-packages to not restart Emacs after installing a package
<taohansen>“ If, for some reason, you want to avoid auto-loading Emacs packages installed with Guix, you can do so by running Emacs with --no-site-file option (see Init File in The GNU Emacs Manual).” found my answer
<wigust>taohansen: I'm not sure what you mean, but with 55 installed Emacs packages 0.4 seconds to start.
<taohansen>so i could run with emacs with that flag then configure for deferred loading with use-package pointing locally
<taohansen>that is extremely fast
<wigust>taohansen: You could use use-package if you want to as (use-package PACKAGE), but I don't see a reason to use it except for packages without auto-load (rare case).
<taohansen>wigust: got it, thank you. i’ll try only setting variables and see how my start-time fares
<jlicht>hello guix
<civodul>heya jlicht!
<civodul>ACTION goes for lunch
<jlicht>civodul: o/
<jlicht>Reading about the emacs-25.3 problem at https://lists.gnu.org/archive/html/guix-devel/2017-12/msg00312.html, it seems to me that this might be a bug in our grafting implementation. Am I totally off base here?
***pksadiq_ is now known as pksadiq
<cbaines>efraim, ok, so building wiredtiger with snappy support is probably useful, but not sufficient, as the service still fails to start
<cbaines>unfortunately I can't quite figure out what is going on here, so I've sent a message to the mongodb-users mailing list https://groups.google.com/d/msg/mongodb-user/XKq2qm1mauE/UOcCcAnMBwAJ
<civodul>bah, Xorg/KMS crash
<ng0>hi! I know technically it doesn't matter what we use for starting a lambda, but can we stick with the convention of 'lambda' and 'lambda*'? There was a recent commit that used lambda* and λ : https://git.savannah.gnu.org/cgit/guix.git/commit/?id=00840ee004151c15c2207ea18efa153d49449435
<wigust>civodul: Ctrl+Alt+Backspace? :-)
<civodul>wigust: not even! i couldn't do anything apart from a hard reboot
<civodul>ng0: i think we should stick to 'lambda' for consistency
<ng0>Okay. Next issue: I think there is a misunderstanding with what I criticized on the website. I want talks, recording of talks, and their slides + papers accessible on their own. I couldn't be less bothered by the format they are presented in as long as the links to the files are listed somewhere, possibly with a preview.
<ng0>The current proposal looks like it would be just linking to the blog posts, which is not really a good solution
<wigust>ACTION likes previous 'talks' page, too.
<wigust>Could we just restore it?
<civodul>new news! https://www.gnu.org/software/guix/blog/2017/porting-guixsd-to-armv7/
<ng0>wigust: it's just a matter of copying and adjusting. it was mentioned in the original thread
<jlicht>civodul: that is amazing news :D
<civodul>isn't it :-)
<efraim>currently cargo can't be built on armhf, there's no logic telling armhf-linux to download the armv7 rust bootstrap
<civodul>oh
<civodul>i wonder if i should try EXWM
<civodul>EXWM doesn't sound entirely reasonable in a single-threaded context
<civodul>have people given it a try?
<apteryx1>rekado: do you have a backtrack of the crash? I'd like to know where exactly in the hook it is failing.
<pksadiq>civodul: I did try it once. But I didn't got the systray working. The rest was working pretty good. As It's hard to change the current workflow, I stopped trying deeper
<rekado>apteryx1: what crash?
<efraim>do the weechat tests work on other architectures?
<efraim>test 1 keeps on hanging on aarch64
<civodul>pksadiq: i'm particularly concern about freezes, let's say while checking email in Gnus...
<pksadiq>civodul: you can run an emacs inside it. Btw, I haven't yet found any workaround to fix ggtags updating in the main thread, which makes every emacsclient unusable for sometime.
<civodul>ggtags, from GNU GLOBAL?
<pksadiq>yeah
<pksadiq>ggtags is the emacs package name.
<civodul>ok
<m-o>go vote people: https://news.ycombinator.com/item?id=15987233 :)
<OriansJ>m-o: why vote? we need people to take the time to be responsible for that work. A million votes but no one working on it, makes not one lick of difference.
<rekado>OriansJ: it’s a vote for a story on Hacker News.
<rekado>more upvotes may make the story more visible.
<OriansJ>rekado: oh, my bad
<civodul>heya m-o
<m-o>hey
<ng0>civodul: it's not the first use of λ. grep for it in the root of the guix checkout
<ng0>woops
<ng0>ACTION reads the grep output again
<ng0>yep
<ng0>at least 7 times
<rekado>ACTION works on an SELinux policy for the daemon now
<ng0>\\o/
<rekado>weird: some daemon actions are identified with “comm="(x-daemon)"”, others with “comm="guix-daemon"”.
<rekado>I don’t know from where SELinux takes these identifiers.
<apteryx_>I'm wondering why cairo 1.14.10 is shown twice in a graph of the closure of ffmpeg: http://svgshare.com/s/4cm
<apteryx_>is it how a bootstrap would be shown? cairo -> poppler -> cairo (but cairo shown as 2 different boxes)
<apteryx_>Oh, yeah, seems it's a different version of cairo built without poppler (since it's used to build poppler). As can be gleaned from the sources.
<apteryx_>Is there something in "guix graph" to limit the graph to the 1st level of dependencies? (to limit complexity/number of nodes drawn)
<civodul>apteryx_: nope, would be nice though
<apteryx_>OK :)
<pksadiq>rekado: Hi. Hope you have got my email reply. My mail host sometimes swallow many emails.
<civodul>gasp, did you know that "Moby defines the future in specialized container systems building."?
<civodul> https://mobyproject.org/
<civodul>it even provides tools to "assemble the components into runnable artifacts"
<lfam>I should read the Moby source code. I've always wondered how to define the future ;)
<jlicht>The layered moby image is confusing me more the longer I look at it.
<civodul>lfam: actually we do have some experience with that in Guile: https://git.savannah.gnu.org/cgit/guile.git/tree/module/ice-9/futures.scm#n67
<jlicht>Nice to have a component for security. Why didn't anyone else think of just putting all of the security in one place. Way easier to manage that way :-)
<lfam>civodul: That's not the same thing. That procedure defines *a* future. But Moby defines *the* future, which is much more valuable
<civodul>good point, we have yet to learn from them
<lfam>(define the-future-in-specialized-container-systems gnu-guix)
<lfam>;)
<civodul>:-)
<lfam>I fixed it
<civodul>anyway, off for vacations now!
<lfam>Ciao!
<fogbugz>What's the state of Rust in Guix? I'm planning to try to compile an unbranded Firefox 57.
<jlicht>fogbugz: I don't know about compiling FF57, but I think our rust stuff has been working again since a commit 2 weeks ago
<jlicht>I have used it for some basic stuff from the rust book at least :-)
***contrapumpkin is now known as Social-Justice-D
***Social-Justice-D is now known as King-of-SJW
***King-of-SJW is now known as contrapumpkin
***contrapumpkin is now known as sn0wflake
<ng0>what changed in mapped-devices? my config suddenly no longer works
<ng0>ie it was valid and functional before
<ng0>what I get is:
<ng0>guix system: error: failed to load '/home/user/src/systems/guixsd/workstations/abyayala/config.scm':
<ng0>/home/user/src/systems/guixsd/workstations/abyayala/config.scm:46:9: /home/user/src/systems/guixsd/workstations/abyayala/config.scm:46:9: In procedure allocate-struct: Wrong type argument in position 2: 3
<ng0>can someone give me a quick summary on the recent changes in luks/mapped-devices?
<ng0>this is the current config of the system: https://c.n0.is/systems/plain/guixsd/workstations/abyayala/config.scm
<ng0>(should remove the comments
***sn0wflake is now known as c0ntrapumpkin
<ng0>hm
<ng0>fixed itself..whatever I've done in the last couple of commits
<ng0>I've done nothing in line 46 though
<catonano>ng0: dbus service ? What is it for ?
<ng0>nvm the content of the file, it's grown historic loads of crap
<ng0>you could express many things in there differently
<catonano>ng0: ah I see
<ng0>could be that it's in there because it's not part of %base-services and it would be easier to remove and maybe replace some services from %desktop-services, and I can't be bothered for now to fix it
<dustyweb>:(
<dustyweb>I'm still having the same problem I was a few months ago
<dustyweb>I can't upgrade my system profile because then x11 doesn't start up :(
<ng0>question: should I patch /bin/rm to 'rm' or the /gnu/store path to rm? I'm applying some fixes to mc.. I'll possibly upstream all of them next year
<ng0>store is more appropriate for us, but imo these paths shouldn't be absolute in the first place, they should be detetced at configure time
<rekado>how is detecting at configure time different from making them absolute? That’s what usually happens in the configure phase.
<ng0>forget what I wrote, I'm distracted and tired.. I can't articulate it right now.. but there are issues with it.
<rekado>dustyweb: oh, that’s bad :(
<rekado>dustyweb: saw your mail. I only have an x200s, which has a different chipset IIUC.
<dustyweb>rekado: ah!
<dustyweb>rekado: maybe that's why