IRC channel logs

2019-11-08.log

back to list of logs

<elais[m]>I figure if I continue tracking gallium-os' repos we'll be good on maintenance
<elais[m]>Like galliumOS this stuff won't be for the latest and greatest. But if somebody has $2-300 to drop on a Chromebook that was top of the line only a few years ago they'll probably appreciate having good drivers.
<alextee[m]>is any python expert here? I install python-pyqt but I can't import anything from 'PyQT5'
<alextee[m]>says ModuleNotFoundError: No module named 'PyQT5'
<alextee[m]>the homepage of the python-pyqt package suggests that this is the PyQT5 package
<alextee[m]>(main issue is that a package is trying to run ${PYTHON_EXE} -m PyQt5.uic.pyuic)
<mange>Is ${PYTHON_EXE} running python3, or just python?
<alextee[m]>good point, that could be it. i just tried guix environment on that package and python3 -m PyQT5.uic.pyic works, so it must be trying to run some other type of python
<mange>If it's just python (or python2), then you'll need to install python2-pyqt.
<alextee[m]>the weird thing is that i see this thing only in the scripts for windows builds... i should look for a way to disable them instead
<alextee[m]>i just realized
***catonano_ is now known as catonano
<xelxebar>Installing for the first time and setting up config.scm. Is there any particular reason the example configurations use (append (list foo bar) baz) instead of (cons* foo bar baz)?
<reepca>xelxebar: didn't write the examples, but I'd assume it's because the meaning of "append" is likely more immediately recognizable to those new to scheme.
<mange>Yep, that's it. I'm trying to find the message that actually proposed it, but so far I've only found https://lists.gnu.org/r/guix-devel/2019-01/msg00353.html
<xelxebar>Bam. If that's not a perfectly on point answer, then I don't know what is. Thanks!
<alextee[m]>i have a package that needs an "sdk path" to another library (package). that would be the parent of /include and /lib. how can i specify the system root path in the .scm file?
<elais[m]>I just use (cons* foo bar baz) because it looks lispy
<alextee[m]>i already built and installed the other package it needs and set it as one of the native-inputs
<mange>You can get the directory of the input by using (assoc-ref outputs "input-name"), but you'll need to look up how to pass that through to your package's build.
<alextee[m]>mange: assoc-ref %outputs "redkite" gives me #f
<alextee[m]>and i have redkite, "redkite" in the native-inputs section
<mange>Sorry, inputs.
<mange>(assoc-ref %inputs "redkite")
<alextee[m]>ah i think i found it assoc-ref %build-inputs "zita-resampler"
<mange>Ah, okay, build-inputs actually sounds more right.
<alextee[m]>yay it succeeded now, thanks!
*alextee[m] needs to start thinking more guix-y. i keep forgetting that each package has its own root
<alextee[m]>i keep getting guile: warning: failed to install locale in my git-based builds. any idea what that is?
<brendyyn>alextee[m]: it happens when the glibc-locales files cant be found, either because there is a version missmatch or because GUIX_LOCPATH isn't set right
<brendyyn>usually it is harmless but its an annoying warning that always keeps coming back in some situations
<alextee[m]>oh, 2.6.1 Locales, thanks
<alextee[m]>added to my ~/.*rc's
<alextee[m]>how do you force rebuild of something?
<xelxebar>Is there a way to specify a detached header for luks mapped devices?
<brendyyn>alextee[m]: annoyingly there is no general way to do that but you can run something like --check --rounds=2
<brendyyn>once its build and reproducible guix build will just output the cached build output again
<brendyyn>you'd have to use guix gc to delete it from the store if you wanted to rebuild it
<brendyyn>so actually i think you can do it
<alextee[m]>oh as long as you don't install it i think the guix gc approach will work, thanks
<alextee[m]>it's a bit weird that there's no --force option though
<alextee[m]>i naturally expected one to be there
<xelxebar>Alternatively, could I just feed raw arguments to cryptsetup?
<brendyyn>like this works guix gc -D $(guix build redis)
<str1ngs>alextee[m]: even if you install it. you can remove it and delete orphaned profiles with guix package -d . and now you can gc it. generally install is overused and most times build is all that's needed
<str1ngs>alextee[m]: in the context of build iterations
<alextee[m]>i see
<alextee[m]>brendyyn: thanks, i will alias that somehow to "guix rebuild"
<alextee[m]>ok so i have 15 packages ready to send, 12 new and 3 version bumps to existing ones :)
<alextee[m]>should i send 12 separate patches + 1 single patch for the version bumps?
<alextee[m]>some packages are related though, like a package uses a small toolkit made for it, i guess i could send those as single patches too
<mange>You'll be asked to split them into separate patches per package, and per version bump.
<mange>So you might as well just send them through like that.
<alextee[m]>oh, cool, noted
<brendyyn>alextee[m]: each unique change is a patch. you wouldn't make two changes for two different purposes in one patch. don't be afraid about making too many. it should be simple and clear what each path does and why
<brendyyn>when posting your patches you can first email guix-patches@gnu.org introducing your patches, and then when you get a response with the thread number, you can email them all as a response to that thread
<alextee[m]>oh that's a good idea, thanks brendyyn
***pc is now known as Guest13951
<alextee[m]>does guix not have a notion of optional dependencies?
<PurpleSym>Is there anyone here running guix in a cluster as described by https://hpc.guix.info/blog/2017/11/installing-guix-on-a-cluster/ ?
<elais[m]>alextee it does sorta. You can either write your own package and declare new dependencies while inheriting the original package or you can design the package to take in a record of some sort that lists all it's configuration
<elais[m]>I think that's sort of what is done with the Linux kernel
<alextee[m]>oh i can kinda understand the first method
<roptat>PurpleSym: I'd ask rekado and civodul ;)
<PurpleSym>roptat: Thanks.
<fps>hmm, does guix only package the gnu netcat utility? no bsd netcat in sight?
<roelj>I'm getting "In procedure bv-u8-ref: Value out of range: 33" when I try to load my own package module. What can cause this?
<wingo>roelj: probably a stale compiled .go file, perhaps run with GUILE_AUTO_COMPILE=fresh
<fps>there's one in nmap that at least talks unix domain sockets. ok!
<roptat>roelj, or maybe a wrong hash?
<alextee[m]>where would a gui toolkit for audio plugins go? audio.scm?
<nckx>alextee[m]: Yup.
<alextee[m]>nckx: thanks!
<nckx>alextee[m]: Guix doesn't have ‘maybe, sometimes’ dependencies. An input is demanded or it isn't, and there is either a reference in the build output or there isn't. You can tweak packages to your liking (for example, by inheriting as previously mentioned), but the package manager itself won't make run-time decisions that depend on the state of the system when you run it. I consider this a great feature by the way, but then optional dependencies in ot
<nckx>her distroes always grossed me out.
<alextee[m]>nckx: i completely agree, i much prefer it when things are explicit rather than being left wondering if a program was installed with something or not
*nckx also likes to exaggerate 🙂
<alextee[m]>so i guess the general idea is that guix packagers focus on sensible defaults, and if a user wants to change something they can just run guix edit before installing
<nckx>alextee[m]: Yeah, the PM simply doesn't have enough information to know whether X was installed a week after Y because you want Y to use it, or just because you wanted X. So it forever keeps X in a limbo state of ‘maybe needed i dunno’, which means its yours to manage manually or (more often) forget.
<nckx>alextee[m]: Yes. The user experience there leaves much to be improved, but something like that.
<alextee[m]>well, my impression so far is that guix has a lot of potential to appeal to normal users (non-hackers) because of its structure. it sounds easy to create simple GUI tools over it because it's so predictable
<nckx>alextee[m]: What kind of plug-ins were you talking about? I just noticed that LV2 plug-ins are in music.scm, so it would make sense to put like with like.
<alextee[m]>geonkick depends on a toolkit called redkite for example
<alextee[m]>i put redkite in audio.scm and geonkick in music.scm
<nckx>Ah, I see, that looks exactly like what I would've done i.e. correct™.
<alextee[m]>:)
***Server sets mode: +cnt
<peanutbutterandc>Hey there, can anybody please tell me how would I delete profiles? I don't seem to be able to find it
<sneek>Welcome back peanutbutterandc, you have 2 messages.
<sneek>peanutbutterandc, reepca says: wrap-program takes the filename of an executable program and search path definitions to {prefix|suffix|replace} environment variables, renames the program, and creates a shell script with its original name which modifies the environment variables as specified, then executes the (renamed) original program. In that example, "XDG_DATA_DIRS" is the name of the search path to affect, ":" is the delimiter
<sneek>peanutbutterandc, reepca says: that separates elements in the search path (optional, defaults to ":"), prefix tells it to prefix the search path with the listed directories (other valid values here are 'suffix and '=), which in this case is just the output directory for the package being built. In your case, you'd want `("PATH" ":" prefix ,(string-append (assoc-ref inputs "ffmpeg") "/bin")).
<peanutbutterandc>reepca, Thank you very much. :)
<roptat>peanutbutterandc, for the default profile, you can remove generations: guix package --delete-generations[=PATTERN]
<roptat>for another profile, you can use the same with -p <the-profile>
<roptat>for a guix pull generation, you can use guix pull --delete-generations[=PATTERN]
<roptat>if you want to delete a profile, and not just a generation, you can simply remove the profile symlink (not the one in the store)
<peanutbutterandc>roptat, I'm afraid deleting the symlink didn't do the trick. `guix gc` after deleting symlinks didn't clean up anything substantial (0 MiBs freed)
<roptat>you need to remove the gc root, so maybe the symlink went elsewhere? If you tried to remove your .guix-profile for instance, you need to remove the symlink from /var/guix/profiles/per-user/<your-user>/
<peanutbutterandc>roptat, The ones deleted (foobar and test) aren't in said directory currently. I suppose they've been removed from there too
<peanutbutterandc>Perhaps it deleted everything? o.O
<peanutbutterandc>... so that guix gc had nothing to do?
<roptat>maybe, try guix gc --list-roots
<roptat>it should give you the roots that are used. if your profile is not there, it probably already removed your profile and its dead content
<waynedpj>ahoy all. been looking for minimum requirements for GUIX, specifically RAM? would like to install the standard distribution (SD) on a headless VPS server but it only has 4GB RAM and 40GB space. it would be a light load (email+web servers mainly), but wondering how guix will run with those specs? thanks.
<str1ngs>waynedpj: 4GB is not so bad if you plan to use substitutes. you will only run into with ram if you are building large packages
<str1ngs>into issues*
<roptat>I run Guix on a server with 512 MB of ram
<roptat>it cannot build anything though, I have to rely on substitutes
<roptat>oh, and 20 GB of disk space
<roptat>it's starting to fill up though, I have only ~1GB free now
<str1ngs>someone needs to take the garbage out! :P
<kirisime>waynedpj: My /gnu is 38GB, I've run the system for half a year and never removed any generations or did a gc. Disk usage ultimately depends on if you're cleaning up things you no longer need.
<kirisime>For what you actually need for a running working system there isn't a reason why the Guix system should use more disk space than anything else save for if you're keeping old systems and profiles around just in case.
<bdju>I've ran into space issues with a ~100GB / partition :(
<bdju>made the mistake of having a separate home during install so that 100GB is even after resizing partitions a few times
<g_bor[m]>hello guix!
<g_bor[m]>hi bdju !
<g_bor[m]>Most of the times 100G on root should be enough.
<g_bor[m]>What are you trying to do?
<civodul>Hello Guix!
<civodul>bavier: do you happen to be familiar with ucx? i have troubles understanding how it selects the right IB driver (mlx4 vs. mlx5)
<bdju>maybe I update too often or something
<bgardner>Good morning guix, playing with my first non-server install and getting a segfault out of Gnome shell at boot (so gdm is alive but X is not). Thoughts on where I can start debugging?
<bgardner>'herd restart xorg-server' gives me a cursor and some flickers for a few seconds and then segfaults gnome again.
<waynedpj>g_bor[m]: thanks. just setting up a headless/VPS server as email, http, and file sharing server mainly. nothing intense but these days 4GB seems so little. before i met Guix i was planning on using something like Alpine to compensate, but since i am very newbie in Guix, not sure about setting up a lean system. and then keeping things up to date
<waynedpj>with Guix i was wondering about memory limits.
<waynedpj>thanks all. i just discovered the new guix deploy. if i understand correctly that would let me do lots of the heavy guix updating on my personal machine and deploy it to the server?
<roptat>waynedpj, right
<roptat>my colleague is asking me "do you know how to create a docker image, it's to send it as an artifact with our paper" I answered "hm... what about guix pack -f docker?" :D
<roptat>actually, would you use guix pack, or guix system docker-image for this use case?
<roptat>and do you know how to produce a docker image that has everything reviewers expect?
<roptat>civodul, maybe? ^
<roptat>if we manage to produce it, I promise to write an article for the blog or the cookbook :)
<civodul>roptat: i suppose you'd use "guix pack" to create an image that contains just the application, no?
<civodul>so your colleague would define a package for their application
<civodul>and then do "guix pack -f docker -S /bin=bin --entry-point=bin/the-app-executable the-app"
<civodul>something like that
<civodul>does that make sense?
<civodul>also with --save-provenance
<g_bor[m]>waynedpj: look for guix gc to keep the system to a reasonable size in this case.
<roptat>civodul, we'll try, thanks :)
<roptat>I guess we'll have to use another entrypoint though, there's a benchmark and tests, so I think we want to have everything to run them in he docker, and instructions to run them too
<roptat>it's not just about the app, it's about reproducing figures from the paper too
<civodul>roptat: you can make a (pseudo-)package for the programs that run the benchmarks and produce the figures (or the paper itself)
<roptat>civodul, right, I think that's what we will do
<roptat>a package whose output is the source for the benchmarks, with the benchmark dependencies as propagated-inputs, maybe
<civodul>yeah
<civodul>alternately, the pack could be seen as an "SDK"
<alextee[m]>when i install new apps, the gnome DE doesn't refresh (i can't search for the newly installed plugins)
<alextee[m]>you have to do alt+f2 and type refresh to make it refresh the .desktop caches it seems
<roptat>civodul, you mean, it contains the tools for the benchmarks, but not the sources for the benchmarks?
<roptat>I don't think that's what the reviewers expect
<alextee[m]>isn't this something that guix install should automatically do?
<roptat>it doesn't change your environment
<alextee[m]>it does say "building XDG desktop file cache..." though
<alextee[m]>on archlinux this happened automatically iirc
<alextee[m]>it does say "building XDG desktop file cache..." though
<roptat>yes, but that's because it's building stuff it puts in the profile
<roptat>it doesn't do anything outside of that profile
<roptat>it means it's building the set of .desktop files it will present to gnome (or any other DE) next time it asks
<roptat>but gnome doesn't ask automatically I guess
<roptat>how does gnome get new information on other distros?
<roptat>does the package manager do something special to call the refresh action, or does gnome somehow knows that something changed?
<alextee[m]>hmm, how complicated would it be to add hooks for DE-specific stuff?
<alextee[m]>roptat: im pretty sure the package manager just calls something special to refresh the DE's cache, but not 100% sure
<roptat>that's really not the kind of thing guix is good at
<roptat>it's not very guix-y to modify the global state of the system ;)
<alextee[m]>oh i think you can just touch the top level icon directory and then run gtk-update-icon-cache
<civodul>roptat: you could add a source as a package, plus the tools to build the source
<roptat>although, we could have a mechanism similar to what we do with grub for instance
<alextee[m]>yeah maybe this is not very guix-y
<roptat>alextee[m], I think web build the cache in the profile ^^'
<roptat>civodul, a source as a package? you mean a package that copies the sources to its output?
<civodul>yeah, something like that
<civodul>or a computed-file
<alextee[m]>also, i wonder why the default for guix gnome is a color background. in other distros it's one of the gnome-backgrounds
<roptat>can I use a computed-file in a pack though?
<jonsger>alextee[m]: maybe no one changed that :P
<alextee[m]>jonsger (@freenode_jonsger:matrix.org): any idea where to look to change that? i can send a patch
<alextee[m]>maybe a post-install script in gnome-backgrounds
<alextee[m]>founod it! gsettings get org.gnome.desktop.background picture-uri
<alextee[m]>just set that in a post install script i guess
<civodul>roptat: you can use a computed-file or anything "lowerable" in a manifest
<civodul>alextee[m]: ah! it'd be great if you could post to guix-devel what's missing to have a nice background by default
<roptat>ah right, a manifest
<roptat>didn't think of that
<alextee[m]>civodul: will do that right now
<pkill9>i don't suppose anyone has made a variant of url-fetch that doesn't require the base64 hash, so it just downloads the latest URL each time?
<roptat>not in code, I think, but --with-source might work?
<pkill9>hmm yea, i wonder if i can use the code used by --with-source to make a variant
<roptat>probably
<pkill9>oh sweet, there is *already* exactly what i want - "download-to-store", and --with-source just creates a new package object that inherits the package to transform and replaces the source with it :)
<bavier>reproducible-builds.org needs to update Guix's logo on their "who" page
<civodul>bavier: true, we should send'em a patch
<civodul>bavier: BTW, did you see my earlier question regarding ucx?
<bavier>civodul: not yet, on guix-devel?
<civodul><civodul> bavier: do you happen to be familiar with ucx? i have troubles understanding how it selects the right IB driver (mlx4 vs. mlx5)
<civodul>right here :-)
<bavier>oh! :) mmm, not familiar to that degree, sorry :/
<civodul>heh, np :-)
<civodul>all this MPI stack is such a mess...
<civodul>i've pushed a wip-mpi branch that fixes a few things for us
<civodul>but we're still having issues with some of our InfiniBand hardware
<civodul>anyway, week-end now, so i'll leave MPI alone for a few days and enjoy :-)
<bavier>yup, lots of moving pieces
<alextee[m]>i kinda broke my system. after reboot my user doesn't know what "guix" or "ls" or "gnome-session" is
<alextee[m]>is there a way to debug/fix this?
<alextee[m]>the root user seems to be able to use those fine
<leoprikler>alextee: what are your ~/.config/guix and ~/.guix-profile symlinks?
<alextee[m]>leoprikler: they point to /var/guix/profiles/per-user/alex/{guix-profile,current-guix}
<dongcarl>mbakke: Since we determined that rust doesn't depend on clang, but rather llvm, would it be okay to merge Mathieu's change that fixes clang startfile pickup to master?
<nckx>alextee[m]: Are they in $PATH?
<nckx>alextee[m]: ~/.config/guix/current/bin/guix should work, and everything else should be in /run/current-system/profile/bin (on Guix System) and/or ~/.guix-profile/bin.
<vixus>Hi all. I noticed the brightnessctl package includes some udev rules to fix the permissions on /sys/class/backlight, but they don't seem to actually get installed.
<sneek>vixus, you have 1 message.
<sneek>vixus, pkill9 says: sway's example config is in <sway-package>/etc/sway/config
<nckx>vixus: They are, but to the store. You can ‘apply’ them on Guix System with (simple-service 'custom-udev-rules udev-service-type (list …)).
<vixus>nckx: Ah ok, do I not need to do the whole modify-services thing then?
<nckx>Where … would be brightnessctl here. That should work; if it doesn't let us know.
<vixus>I'll give it a shot
<nckx>vixus: I don't think so, but that's someone else's example.
<nckx>You can use (service udev-service-type …) directly [as I do] but the one above seemed more friendly 🙂
<alextee[m]>nckx: there must have been some mixup in the paths i was setting in my shell profiles.. i deleted everything and just sourced the etc/profile thing that guix gives you, now it works!
<nckx>alextee[m]: Rad!
<vixus>nckx: Is there a way to check whether that worked?
<vixus>there doesn't seem to be an /etc/udev directory after `guix system reconfigure`
<nckx>vixus: I'm not sure. Rebooting is the only way I know.
<vixus>Does that config add a new service or just extend the existing udev one?
<vixus>`herd restart udev` seemed to do the trick
<vixus>and looks like I can change brightness now :D
<nckx>vixus: ¯\_(ツ)_/¯ but I'm glad it worked!
*nckx stays away from udev when possible.
<alextee[m]>can somebody help with building these 2 packages (carla, cadence)?: https://git.zrythm.org/cgit/guix-repo/tree/audio.scm#n244 should i ask in guix-devel instead?
<alextee[m]>these are reeeeaaallly important packages for audio/music but i can't manage to build them because of some pyqt stuff
<jackhill>join #webkitgtk
<jackhill>oops, sorry
<nckx>jackhill: If only real spammers were that polite.
<nckx>alextee[m]: You'll have more chance of a response there.
<alextee[m]>nckx: sweet, will post there then
<jackhill>heh :)
<bgardner>Following up on my own question, I was unable to get gnome to stop segfaulting, so I switched out gdm with slim and that works immediately. So I'm afraid I'm no smarter as to what gnome is mad about, but at least X works for me now.
<leoprikler>bgardner: does GNOME shell also segfault or just GDM?
<sirgazil>alextee[m]: Regarding application icons not displayed in GNOME immediately after installation, that's a known bug:
<sirgazil> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35594
<bgardner>leoprikler: Sorry, I wasn't clear - gdm never misbehaves, but gnome shell crashes every time. 'herd restart xorg-server' yields another crash message.
<bgardner>Well, did, until I swapped out gdm for slim
<leoprikler>Hmm, okay.
<dongcarl>found another thing bug in our clang toolchain: For it to do anything useful, it has to define `_GLIBCXX_HAS_GTHREADS`
<dongcarl>Any idea how to make clang do that automatically instead of a manual `-D_GLIBCXX_HAS_GTHREADS=1`?
<str1ngs>dongcarl: -D_GLIBCXX_HAS_GTHREADS=1 is a cmake arguement?
<dongcarl>str1ngs: No it's a clang argument
<leoprikler>I've crashed my GDM trying to restart it a few times already, but have not yet found out how to do it correctly.
<dongcarl>as in `clang++ -D_GLIBCXX_HAS_GTHREADS=1 test.cpp`
<str1ngs>ahh that is annoying yes
<str1ngs>dongcarl: wonder if the clang build has an option for that
<alextee[m]>str1ngs: oh this bug report is pretty spot on
<str1ngs>sirgazil: ^
<dongcarl>str1ngs: Right... Perhaps I'll ask on their IRC channel
<str1ngs>dongcarl: this might be a glibc issue, where that literal is not defined
<dongcarl>str1ngs: I'm pretty sure this is a libstdc++ issue...
<str1ngs>right CXX implies c++ not glibc sorry
<str1ngs>libstdc++-v3/configure:$as_echo "#define _GLIBCXX_HAS_GTHREADS 1" >>confdefs.h
<dongcarl>str1ngs: Huh... And what causes it to do that?
<jje_>is it possible to have haveged start at boot
<str1ngs>dongcarl: not sure just that literal seems to be defined by libstdc++
<dongcarl>str1ngs: `--enable-libstdcxx-threads`!
<str1ngs>dongcarl: that's what I was wondering to
<dongcarl>str1ngs: Yeah lemme try
*dongcarl crosses fingers
<str1ngs>I'm assuming GTHREADS is green threads. but not sure myself
<str1ngs>GUD THREADS!
<str1ngs># For gthread support. Depends on GLIBCXX_ENABLE_SYMVERS.
<str1ngs>GLIBCXX_CHECK_GTHREADS
<str1ngs>GLIBCXX_ENABLE_SYMVERS = yes so I guess it depends what that macro checks for
***jje_ is now known as jje
<str1ngs>dongcarl: GLIBCXX_CHECK_GTHREADS is defined in aclocal.m4 is and quite complicated. figuring out what it's looking for
<str1ngs>though I suspect this is more of a header inclusion issue.
<alextee[m]>this is very weird.. if i use guix environment -L . carla and build inside there it works, but if i use guix build -L . carla it fails
<dongcarl>str1ngs: Kk I'm gunna try experimenting too
<str1ngs>dongcarl: as far as I can tell it's checking if libgcc has __GTHREADS_CXX0X
<dongcarl>str1ngs: I think we just need `--enable-threads=posix` or `--enable-libstdcxx-threads`
<dongcarl>Trying now
<str1ngs>dongcarl: okay libstdc++ configure output should have 'checking for gthreads library' output. can also check config.log for ac_has_gthreads=yes
<str1ngs>well check for ac_has_gthreads value
<dongcarl>str1ngs: Ah very good to know
<dongcarl>Does anyone how to get the log of the last successful build?
<dongcarl>str1ngs: `checking for gthreads library... no`
<dongcarl>:-(
<str1ngs>ahh so this is an issue with libgcc.
<str1ngs>or GLIBCXX_ENABLE_SYMVERS is failing also
<smithras>hi guix!
<nckx>o/
<bavier>hey smithras
<smithras>In my guix system config, is there a way to set a different language for different users?
<smithras>The documentation suggests it's only done at the system level
<nckx>smithras: Yep. Guix doesn't handle per-user (shell) environment files, which is how this would be done when not using a DE to set your language preferences.
<smithras>nckx: thanks, I read a bit more and I'm going to look into setting the LOCPATH variable per-user
<nckx>Each user needs to set LANG/LC_XXX themselves if they don't agree with the default.
<nckx>smithras: Wait, LOCPATH? Are you sure?
<dongcarl>str1ngs: I guess that means... We gotta compile gcc (or at least libgcc) with posix threading?
<nckx>smithras: That sets the path to the locale database (part of glibc), not a specific locale.
<smithras>nckx: hmm I was reading the locale section of the guix manual, but that might just be for guix
<smithras>oh yeah you're right, I misread the manual
<smithras>thanks :)
<nckx>It's where all programmes look for the locale *data*, but it doesn't change per language. The *desired* locale is $LANG or $LC_SOMETHING, I always forget which one is moar correct.
<nckx>smithras: :)
<Formbi>hello
<Formbi> https://guix.gnu.org/manual/en/html_node/Initial-RAM-Disk.html
<Formbi>I don't understand how to make a blacklist
<Formbi>could someone help me
<Formbi>?
<nckx>Formbi: A blacklist of what? Devices? Kernel modules?
<Formbi>yes
<nckx>‘X or Y?’ ‘Yes.’ 😛 OK, modules I guess.
<nckx>Formbi: I think we support modprobe.blacklist=xxx[,yyy].
<nckx>Have you tried that?
<nckx>So (kernel-arguments (list "modprobe.blacklist=xxx" …)) in Guix.
<Formbi>sorry, my concentration is a little bit off :/
<str1ngs>dongcarl: possibly, but I would suspect it has that already
<Formbi>thanks :)
<nckx>Formbi: Oh, it just made me laugh, didn't mean to imply otherwise.
<Formbi>hmm, I remember trying the kernel argument and it didn't work
<Formbi>but maybe something improved
<Formbi>well, we'll see on the reboot
<nckx>Formbi: Hm, it definitely work[ed] here, I use it on one of my machines.
<nckx>cat /proc/cmdline after rebooting to make sure it looks OK.
<nckx>smithras: Pushed. Thanks 🙂
<smithras>nckx: Thanks for your help!
*smithras is learning that language packs aren't necessarily installed by default
<nckx>smithras: Which programme?
<nckx>IceCat needs ze download, yes.
<str1ngs>dongcarl: also /gnu/store/mr8x4g8sjakk95qlk0qahknsmkr77ky4-libstdc++-7.4.0 is unexpected what version is libgcc?
<str1ngs>or gcc:libs
<dongcarl>str1ngs: I know what's wrong now, at least I think
<dongcarl>str1ngs: During libstdc++'s autoconf
<smithras>nckx: icecat & libreoffice
<dongcarl>It tries to look for gthr.h
<dongcarl>But it should be looking for "bits/gthr.h"
***jonsger1 is now known as jonsger
<nckx>IceCat language packs are here: https://ftp.gnu.org/gnu/gnuzilla/. No idea about LO.
<dongcarl>str1ngs: Does that sound plausible to you?
<nckx>I have an icecat package that includes all of them but it's probably bitrot since the guix-preview update.
<str1ngs>dongcarl: config.log will give the output of that AC_TRY_COMPILE test
<smithras>nckx: should I try using the latest available (60.7) with my current 68 version?
<smithras>also no worries, libreoffice isn't as important
<str1ngs>dongcarl: "gthr.h" implies a relative path. not an included path
<str1ngs>dongcarl: CXXFLAGS="$CXXFLAGS -fno-exceptions -I${toplevel_srcdir}/libgcc -I${toplevel_builddir}/libgcc" also ensures libgcc path is included
<str1ngs>dongcarl: it's quite possible this is failing because configure is run as a project and not a sub project in the parent project gcc
<nckx>smithras: It's worth a try, most things should still be translated unless the format's changed (unlikely).
<dongcarl>str1ngs: Even more support for your "make libstdc++ an output" argument
<str1ngs>dongcarl: that is how it's normally sub packaged, as far as I know.
<dongcarl>str1ngs: Looked at the config.log... It seems they can't find gthr-default.h
<alextee[m]>does "$(something)" mean something special to substitute* ?
<alextee[m]>or does it take it literally?
<alextee[m]>actually nevermind, i did something else and it worked
<nckx>smithras: Things may have changed in 68, but older IceCat versions ignore $LANG. After installing the language pack, you['d] have to visit about:config and create a ‘intl.locale.requested’ key with ‘xx_XX’ value.
<nckx>If that has changed and it just works do let me know.
*nckx is still surfin' the net with Swiss-cheese 60.9.0.
***slyfox_ is now known as slyfox
<str1ngs>dongcarl that is why AC_TRY_COMPILE([#include "gthr.h"] fails?
<dongcarl>str1ngs: So... I've moved on and just started using the libstdc++ that's inside our gcc package... :-(
<str1ngs>dongcarl: i think that's the way to go too
<dongcarl>str1ngs: One of these days I'll come back to this problem