<nee`>The murmur service is comming along well. I tested voice chat, text chat, and registering the server in the public server list today. I will probably send a patch in a few days, after I tested the other options. <atw>nice! How difficult is it to write a service? I might want to do one at some point <nee`>atw: Not very difficult in itself. But I find it to be a lot of work to get informed on all the options of a software and to write documentation. <atw>and then codify those options as options to the service procedure? Yeah, that does sound tough... <atw>Kinda means that services form a universal configuration language, right? <nee`>Yes, I think thats how it is. <ngz>Hello. I have a problem with some packages, e.g., Keepassxc, which do not build since a Qt update (c3bece41b7e). The error is pasted at http://paste.lisp.org/+7P5T <ngz>Basically, cmake cannot find an appropirate QtLinguistTools, even though qttools belongs to the input. <ngz>The same error appears when I try to update some qt-related packages (e.g., scribus). <ngz>For the record, I checked if there was some qt conflict among input, but Guix only provides one qt5 version (monolithic or modular), so I doubt it could be the case. <rekado_>I’d try to figure out how it detects the version first. <ngz>It uses the find_package function, whatever it is. <ngz>Note that this seems pretty standard since at least two packages are failing exactly the same way <rekado_>the find_package function uses these cmake files that are named after the package they are supposed to find. <rekado_>it prints the file name right there along with the error <rekado_>well, have you looked inside the file whose name it printed? <rekado_>that’s where you need to start the investigation <ngz>It is a very short file without much information. In particular, there is nothing about a version string. <ngz>Honestly, this is very opaque to me anyways. <ngz>rekado_: Oddly, at the same location in store, i.e, /gnu/store/...-qttools-5.9.2/lib/cmake/, Qt5UiTools/ provides Qt5UiToolsConfigVersion.cmake, which contains a version string. Qt5LinguistTools/ doesn't provide one. <efraim>It also happened for owncloud-client and I believe quassel <htgoebel>If I need an input native and propagated, can I list it twice? <ngz>Other distributions (in particular NixOS) do not do anything special about Qt5linguisttools. Very strange. <iyzsong>Oh, linguist.pro search ConfigVersion.cmake.in in 'QT_HOST_DATA/src', which point to the wrong place by qt.conf in the 'configure-qmake'. I'll fix it soon... <ng0>silly question, but how do I get the gfortran compiler into my userprofile and make gcc aware of it? just by installing 'gfortran'? <ng0>well I can now use gfortran, but that didn't make gcc aware of it. <ng0>or, is this even possible with the user-profile gcc we have? I can just use gfortran on its own, I simply saw that it's supported by gcc <rekado_>the wrapper script is written at gcc build time <rekado_>there’s a bug report about this from about 2 years back <ng0>yeah, that makes sense from what I read about the bootstrap of gcc <htgoebel>Any idea how to make strace-output including several processes and tons of "unfinished" and "resumed" more readable? <efraim>You can use -ff so each process gets its own log file <efraim>But I normally read strace logs a whole page or 3 at a time <htgoebel>it's too man interleaving syscalls, so i's hard to spot patterns if not separated. <efraim1>I thought b43-open was supposed to work with the linux-libre kernel <efraim1>updating my fonts is followed by `fc-cache -fv'? <ngz>iyzsong: I'm testing if your patch fixes my issue right now. <htgoebel>I need to patch KDE's kinit to search lib at the correct place. <htgoebel>What is the equivalent in both "guix environment" and "GuixSD"? <htgoebel>I assume its $GUIX_ENVIRONMENT and /run/current-system/profile/ <htgoebel>But this is not always set, so I assume this is not enough <rekado_>we don’t have an equivalent of NIX_PROFILES, also because it’s a hack. <rekado_>is this to find some sort of plugins that a user may have installed? <rekado_>for a similar purpose we patched gtk to respect GUIX_GTK3_PATH, GUIX_GTK3_IM_MODULE_FILE, and GUIX_GTK2_IM_MODULE_FILE. <rekado_>these vars are set as part of a profile hook, so they are correct no matter where a user installs things. <ngz>Is it fine to update a package and add inputs to it in the same patch or should I split that into two patches? <ng0>does the update require the new inputs? <rekado_>if the new version builds and works without the new inputs then these should be two separate patches. <htgoebel>rekado_ It's to load shared libraries (sic!) using Qt, which - according to the comment – does not respect RUNPATH <rekado_>ngz: this allows us to revert one or the other independently. <rekado_>htgoebel: what comment are you referring to? <ngz>rekado_: I know that, but my laziness expected a different answer, considering I conflated both changes in my local repository. <rekado_>htgoebel: are these libraries all located in the same package or provided by multiple packages? <rekado_>I think it’s odd to just search profiles for the libraries. <rekado_>instead there could be a mapping of names to absolute paths <rekado_>that’s what I did with our julia package <ngz>Patch question: Debian has a one-line patch for an issue. Should I use this patch or mimick it with a substitution in source code, referencing the bug report in a comment? <efraim1>I normally try for a substitute* line <ngz>As a snippet or in a dedicated phase? <htgoebel>efraim1: It's even worse: The lib (or programm) to be oaded can be passed on the command line :-( <htgoebel>Like this: /usr/libexec/kf5/start_kdeinit --kded +kcminit_startup <htgoebel>Which means: libkdeinit5_kcminit_startup.so will be load <htgoebel>Looks like I need to ask for assistance on the mailinglist <htgoebel>For developing the patch I need to work in kinit, but for testing the patch, I need to set up a full KDE Plasma environment with many packages depending on kinit. So every change-cycle will take half an hour (and more). How can I work around this? E.g. by using grafts? <efraim>I don't remember the flag, but guix build --help should show you the custom graft flag <htgoebel>efraim: Unfortunately it can only be passed to `build`, not to `system`. But hacking the replacement into the .scm file is not much of a problem. <rekado_>htgoebel: another easy trick is a slight variation of the Nix patch: define GUIX_KDE_LIBS_PATH (or similar) and search for libs in the listed directories. <rekado_>with a profile hook or the service we can easily figure out the value for GUIX_KDE_LIBS_PATH, and users can still override it if they want to. <htgoebel>rekado_: Sounds reasonable. Unfortunately this directory is /libs, thus I'm not sure if this is a good solution. <htgoebel>OTOH this would move the "burden" of setting everything up correctly to guix/guixsd. <rekado_>I don’t understand. What do you mean by “Unfortunately this directory is /libs”? <htgoebel>rekado_: "Unfortunately this directory is /libs” since this may lead to many unrelated entries in variable. <htgoebel>I'll try to find a way to move them into e.g. /lib/kinit or something like this <htgoebel>Is there a way to determine the output of a package without making the package an input – to avoid recursive dependencies? <rekado_>htgoebel: ah, I understand. But since this is just a lookup directory it wouldn’t be a big problem to have it point to /lib. It may be premature to try to optimize this at this point. <htgoebel>rekado_: ACK, premature opt. came to my mind, too. <rekado_>htgoebel: any store item you reference in a package should be an input. <htgoebel>rekado_: ACK. I found that this not an issue since it is *not* recursive – contraty to what I first thought. <htgoebel>But I do not get this "replacement" thing to graft my one package-to-be-changed. <htgoebel>The new package is "kinit-patched". For the orig package I added "(replacement kinit-patched)", but I get no grafts :-( ***Piece_Maker is now known as Acou_Bass
<ngz>During "validate-runpath" phase, I get a lot of "*.so: warning: RUNPATH contains bogus entries: ("some/directory/")". Where could it come from? <ng0>GNU has a very long waiting line for everything maintenance/maintainer. a simple request started in july, now the last message was already 1 month ago again. capital patience :) <ng0>it's probably just 2 people dealing with this, understandable