<leungbk>The way I'm doing it now leaves double quotes around the string in the terminal output.
<rekado_>leungbk: is there a reason why you can’t use “leave”?
<rekado_>leungbk: if you can’t use it then let the procedure throw an error and catch it where it is called (and where you could presumably use “leave”)
<leungbk>@rekado: I don't want to use anything leave/error-related stuff because this is intended to be a case in a recursive importer where a particular dependency can't be found but I nonetheless want to make the importer keep trying to recursively import the remaining ones.
<cooper[m]>Thanks guy, I managed to boot properly with the encrypted partition now. I was wondering if it is recommended to have a system config (like the one made during the installation) and a user config somewhere in $HOME that I can put in version control
<tidux>hmm, looks like you have to manually point gpg-agent at your pinentry program
<tidux>this should be done by default given the weird paths involved
<leungbk>sneek, later tell efraim I think I figured out how to make the crate recursive importer work the way you wanted, but I'm currently using (string-append), which forces the failure cases to display with extra double quotes, so that instead of "failed to get metadata for x" actually shows the quotation marks. Is there an idiomatic way of removing the double quotes that doesn't require leave/error-type stuff (since that would cut off the
<sneek>efraim, leungbk says: I think I figured out how to make the crate recursive importer work the way you wanted, but I'm currently using (string-append), which forces the failure cases to display with extra double quotes, so that instead of "failed to get metadata for x" actually shows the quotation marks. Is there an idiomatic way of removing the double quotes that doesn't require leave/error-type stuff (since that would cut off the
<civodul>"/gnu/store/knv2sc44awjj23k29rrgh5c9rf9fbq1p-qtbase-5.11.3/lib/libQt5Core.so.5: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 3.16.0, stripped"
<civodul>notice "3.16.0", and old CentOS is at 3.10
<rekado_>civodul: oh, thanks! I forgot about the GWL web interface… :-/
<rekado_>gotta write a service and add it to the berlin config.
<rekado_>RHEL 7 is at 3.10, but the kernel is heavily patched.
<rekado_>I think we configured / patched qt5 so that it doesn’t use certain syscalls that aren’t available in the RHEL kernel that claims to be 3.10.
<rekado_>(version numbers are … frustrating. People think they mean something, but they are so arbitrary.)
<rekado_>sneek: later tell leungbk The CRAN importer retries imports from different repositories. If a package isn’t found on Bioconductor it will retry to import from CRAN. Same for imports from Git which are retried on Bioconductor (and then CRAN).
<roptat>berlin-ip6 is set to that link-local address
<raingloom>is there something like Nix's wrapQtAppsHook in Guix? is such a thing needed? i'm trying to package a QT app and it compiles and runs but breaks in weird ways. it's packaged in Nix and their package looks very similar to what I'm doing, except for that wrapper thing is missing from mine.
<raingloom>rekado_ it starts and detects voice but doesn't draw any waveforms and none the of the icons are there
<raingloom>so far i've figured out that it's accessing ~/.guix-profile/share/icons/default instead of hicolor, but i'm not familiar enough with QT to know why
<raingloom>i'm not yet sure why it doesn't draw the waveform, it didn't print a lot of debug info
<rekado_>you may have to wrap the executable(s) in QT_PLUGIN_PATH. See gcompris-qt for an example.
<rekado_>civodul: our “guix-install.sh” script does not lead to a functioning installation of Guix.
<rekado_>I just tried it and the daemon is started with GUIX_LOCPATH set to a non-existing location.
<rekado_>as a result setting LC_ALL fails and the substituter seems to just freeze.
<rekado_>the freezing could also be a networking problem here, but the point stands: GUIX_LOCPATH points to the root user’s default profile, which does not exist. We only install the current-guix profile.
<civodul>rekado_: that's on purpose: the idea is that people can run "guix install glibc-utf8-locales" as root
<civodul>but that if you're using one of the happy few locales, it just works
<rekado_>shouldn’t the installer script take care of this?
<rekado_>also: I *am* using en_US.utf8 but since the daemon runs in an environment that doesn’t have glibc-utf8-locales i will get the error (an ugly LC_ALL error, not a nice warning with a hint) every time I run a Guix command.
<rekado_>this is what I see when running “guix build hello”:
<apteryx>civodul: if I change the ntp-configuration record to take servers as a list of records rather than strings, I guess I must do the extra work to be backward compatible? (e.g. issue some deprecation warning and do the required tranformation?)
<apteryx>(when presented with a list of strings rather than records)
<quiliro>roptat: mi konas kiel ĝisdatigi pakagon...sed mi ne faris tion...mi faros tion :-)
<janneke>PotentialUser-67: have you run guix pull yet?
<PotentialUser-67>packages webpage loads fine for me, I just referenced it to see what was available in Guix land, and do see ungoogled-chromium listed there as mentioned in dev github page
<conceivably>Hi :) How do people who unfortunately depend on nvidia drivers (or other proprietary packages) for work deal with this on Guix? I'm having a hard time finding information about this. As best as I can tell, the proper way would be to use channels, but it seems a bit inefficient for every user to maintain their own package.