<axd-v>Does anyone know where xkb stores its layouts cache file that end in .xkm? They are supposed to be in /var/lib/xkb/, but I don´t even have that directory. `find / -name *.xkm` returns nothing.
<axd-v>Did I install setxkbmap wrongly? I have it in my user profile.
<Copenhagen_Bram>Has anybody played Cataclysm DDA? I noticed it's miraculously available for Guix
<axd-v>Man this package is gonna kill me. I can't find anything that it stores in /var or .guix-profile/var.
<nckx>axd-v: I use setxkbmap in my .xsession, and find / ... returns nothing for me as well. So the answer is definitely ‘nowhere’.
<axd-v>nckx: ... so you think the cache files that end in .xkm that every other distribution that deals with xorg's xkb uses are just not used in guix at all?
<axd-v>nckx: so there is no cache and setxkbmap "recompiles" them from scratch every time?
<axd-v>This doesn't explain why whenever I use a custom directory to specify my configuration (.config/xkb :: mirrors system's xkb dir) setxkbmap isn't able to see a changed layout. This is easily tested by leaving everything the same and simply modifying the file (e.g.) in symbols/us intl layout variant to print a '1' in place of usual "2" key and '2' for reverse. Running `setxkbmap -I $HOME/.config/xkb -layout us -variant intl -verbose 10'
<axd-v>shows that xkb continues to use the old definition of 'intl' layout. Don't know what to do, really HAVE to solve this problem and can't find any way to.
<axd-v>I've posted on the mailing-list for help-guix about my xkb problems. Hopefully someone with experience can chime in on there.
<nckx>axd-v: I don't think. I've no knowledge (never heard of .xkm files on any other distro either) or opinion about the matter; just confirming that you didn't install setxkbmap incorrectly.
<axd-v>nckx: oh I see, hehe, well thank you for that.
<nckx>FFS... Try to strace X, have fun hard-resetting & fscking.
<nckx>axd-v: Anyway, I presume any actual loading of keymaps is done by X, not setxkbmap, but I'm not poking any further after this. Sorry.
<axd-v>nckx: no worries, you have provided me with more to go on than I had. I'll try your suggestions
<buenouanq>Does anyone here know anything about the Libre5 phone?
<axd-v>buenouanq: not anything technically (don't know if they have finalized a bunch of details) but the project is very interesting. Purism's libre-distro ready laptop (like GuixSD) is well represented here on #guix. I'm sure that Guix will play with their hardware at some point. The Arm port needs to be finalized first probably. Similar with EOMA68 hardware, arm chips.
<axd-v>buenouanq: librem 5 got funded and the release date is set for beginning of 2019. I would think it's safe to assume that that date will slip until summer 2019. You can always wait a few more months and get it when you have $600 burning your pocket or just as a christmas 2019 present :)
<axd-v>PureOS just needs a bit more polish on the user-facing parts, but otherwize it's hard to mess up Debian Testing with some default software.
<g_bor[m]>I've now checked some advisory how to solve the timestamp in javadoc problem. I have found some suggestions how to include the -notimestamp option. I will try to fix the icedtea doc reproducibility problem reported by Danny.
<rekado_>I’m a bit concerned about the download speeds I get from berlin.
<rekado_>I’m just 300 metres away from the server and I get 400kB/s for downloading a tarball.
<rekado_>I need to apply some firmware upgrades on some of the servers today, so berlin.guixsd.org is likely going to be rebooted today
<vagrantc>oh... i bet the arm64 kernels are building with debug symbols enabled or something ... not sure what the norm is for kernel packages in guixsd
<vagrantc>that would increase the size of the build a lot
<nckx>g_bor[m]: That URI has the same hash so I'd say go ahead & add it.
<mbakke>vagrantc: That may be the issue, I'll inspect the binaries afterwards.
<g_bor[m]>nckx: I see two problems currently: There were reproducibility problems with github tarballs earlier, and there are lot of dependencies. I would like to check this with rekado_ ,if possible before the core-updates merge.
<nckx>g_bor[m]: The reproducibility problems are with auto-generated tarballs (/archive/ IIRC). This is a proper release archive (else the hashes wouldn't match).
<vagrantc>mbakke: the Debian config i based it on has debug enabled, but the debug symbols are stripped out into separate packages
<rekado_>the core-updates merge is not a release, so I’m fine with these github tarballs for now.
<mbakke>g_bor: Changing the source URL won't change the derivation (as long as the hash is the same).