IRC channel logs


back to list of logs

<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
<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>Any idea?
<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_>ngz: it says “version: unknown”
<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
<ngz>afk 5 min
<rekado_>the find_package function uses these cmake files that are named after the package they are supposed to find.
<rekado_>and that’s part of qttools
<rekado_>it prints the file name right there along with the error
<ngz>so ?
<rekado_>well, have you looked inside the file whose name it printed?
<rekado_>that’s where you need to start the investigation
<ngz>Yes, I did.
<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, search in 'QT_HOST_DATA/src', which point to the wrong place by qt.conf in the 'configure-qmake'. I'll fix it soon...
<efraim>htgoebel: yes
<htgoebel>efaim: Thanks
<mb[m]1>It looks like we may be stuck with GCC5 until this bug is fixed:
<efraim>Ugh that's annoying
<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_>gcc will remain unaware of it
<rekado_>the wrapper script is written at gcc build time
<rekado_>there’s a bug report about this from about 2 years back
<ng0>i see. thanks
<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>efaim: -ff seams useful.
<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'?
<efraim1>oh yeah, that's better
<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>Nix searches them in $NIX_PROFILES
<htgoebel>What is the equivalent in both "guix environment" and "GuixSD"?
<htgoebel>I assume its $GUIX_ENVIRONMENT and /run/current-system/profile/
<htgoebel>Or should I use some other env-var?
<castilma>in guixsd it should be GUIX_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?
<ngz>I don't think so.
<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.
<htgoebel>rekado_: This comment:
<htgoebel>I plan to patch it like Nix does:
<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>Fair enough.
<ngz>As a snippet or in a dedicated phase?
<ngz>(for a bugfix)
<efraim1>for a bug i'd go with a snippet
<ngz>Thank you.
<efraim1>er, i meant phase, sorry
<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: 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: Nice trick. Thanks.
<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.
<efraim1>at least its not too bad
<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>Many packages have /lib.
<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>Any tipps?
<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