<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>I meant guix working on the librem 5 <buenouanq>I've preordered the EOMA68 and am looking forward to trying to put GuixSD on it. <buenouanq>I would love to put GuixSD on it aswell if I someday can. <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. <Apteryx_>Hello! How can I build the guix-daemon with debugging symbols? <kmicu>Digit: fortunately Guix did not make the same mistake as Nix. <nckx>It's all fun & games until Microsoft buys Savannah. <kmicu>Code for Savannah is available, that is not true for GitHub. <g_bor[m]>I am thinking of a self hosted setup, but currently it would not be financially feasible for me. <Digit>ACTION happy on notabug.org looking forward to #peers developments for a federated notabug2.0 and/or vervis and/or other innovations in this area <g_bor[m]>buenouanq: I guess 0.15 is not too far, usually there is a release after core-updates merge. <rekado_>tonight we merge core-updates into master. <efraim>i'm testing linux-libre on aarch64 again <civodul>(sorry for not being more active on this front...) <rekado_>I’m reporting this as a bug upstream. <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 <soundtoxin>speaking of rebooting, do you need to reboot to use a new kernel on guixsd, or does it get around that issue somehow? <rekado_>sorry for the short notice; will need to reboot berlin.guixsd.org within the next 30 mins. <rekado_>It may be offline for an hour or two as the firmware updates are applied. <rekado_>vigra builds now; pushed to core-updates <rekado_>sneek: welcome back, we missed you! Have a dried botsnack! <g_bor[m]>I've just tried a make check on core-updates, but the tests fail with an error: <civodul>g_bor[m]: any clues in tests/base32.log? <civodul>rekado_: also firewall` & i are moving guix-hpc.bordeaux.inria.fr to a new machine, so it's currently down <civodul>rekado_: re download speeds, i suspect the nginx proxy config isn't great <civodul>because 'guix publish' itself simply does sendfile(2), so it can't be more efficient than this <g_bor[m]>civodul: Actually, yes, test-tmp/db does not exists. <civodul>hmm, how does this relate to tests/base32.scm? <g_bor[m]>civodul: It tries to run canonicalize-path, and fails with path does not exist. <g_bor[m]>civodul: It seems to be somehow related to guix/gcrypt.scm. <pkill9_>wooo, someone's working on upgrading icecat to the latest firefox <civodul>g_bor[m]: could you paste the whole .log file? <htgoebel>I picked up again work on the "PYTHONPATH woes" issue. <htgoebel>Is it okay to push a temporary branch to share test-instructions, test-cases and patched? <htgoebel>Any suggestions for naming the branch? "WIP-..."? "TEMP-..."? <civodul>htgoebel: we use "wip-" (lowercase) for work-in-progress branches that may be rebased <civodul>so you could call it "wip-pythonpath" or something like taht <pkill9_>are most substitutes available on the core-updates branch? <rekado_>pkill9_: you can check with “guix weather -m my-manifest.scm” <catonano>pkill9_: how do you now that someone is working on updating Icecat to the latest Firefox ? <civodul>i think firewall` has been looking at adding an FSDG-compatible Firefox in Guix too :-) <civodul>it seems that Firefox is a hot topic <rekado_>0.0% (0 out of 6151) of the missing items are queued <rekado_>that’s what guix weather says about berlin.guixsd.org. <rekado_>23.2% substitutes available (1854 out of 8005) <civodul>weird, i think i had more like 50% a few days ago <civodul>but maybe that was just for my own profile actually <catonano>pkill9_: great, thanks ! Arre there gonna be problems with the bits made with Rust ? <rekado_>“0 queued builds” also doesn’t sound good. <civodul>rekado_: but you rebooted it 30mn ago <civodul>so i suppose cuirass is still figuring out which builds need to be restarted <rekado_>It says “evaluating for ’x86_64-linux’…” and then “next evaluation in 300 seconds” <civodul>thing is, the initial "retrieving list of pending builds..." is still running <efraim>that would explain why the load on my overdrive is 0 <civodul>BTW i really don't know what to do with mine :-/ <roptat>do we have a procedure to find the latest version in a list? <roptat>like return "1.5.0" from '("1.2.0" "1.5.0" "1.3.2") <civodul>efraim: i still get "Timeout connecting to git.flashner.co.il" <rekado_>roptat: ISTR that we have something like “version<” <catonano>if this is of any help to anyone, this is what I get form weather <catonano> 92.9% substitutes available (7416 out of 7987) <efraim>civodul: it should be the 100... address that's listed, i'll take another look at it <civodul>in other news, 'make check' works for me on core-updates <rekado_>fails for me: (canonicalize-path "/home/rwurmus/code/guix/test-tmp/db") <rekado_>In procedure canonicalize-path: No such file or directory <civodul>i configure with ac_cv_guix_test_root=/home/ludo/src/guix/test-tmp to share the test directory with my other worktrees <civodul>could you see where the error comes from? <rekado_>On this machine I’m not using worktrees. <rekado_>as g_bor[m] wrote, this happens when loading (guix gcrypt) <rekado_>it ends up loading guix/config, which defines %store-database-directory. <rekado_>in doing so it evaluates (and=> (getenv "NIX_DB_DIR") canonicalize-path) <rekado_>NIX_DB_DIR is set to test-tmp/db by the test runner <apteryx>how can I build the guix-daemon with debugging symbols? I'm trying to step the code with GDB to debug something. <civodul>so the issue also occurs in master, right? <civodul>apteryx: if you run "make" from a checkout it has "-g" (debugging symbols) <u0_a461>hello. is it possible to dual boot guixsd on windows 10. i read that we can dual boot linux by adding in the menu-entry section, but it didn't say anything about windows. <civodul>u0_a461: i don't think anybody tried, but it may work <rekado_>civodul: could it be that commit 7f9d184d9b688d13ce76eefabaddcfa76bdde2b5 broke the tests? <rekado_>urgh, I see a lot of lock error messages building certbot on berlin. <civodul>rekado_: yes it's definitely that commit <civodul>i think we can just remove canonicalize-path from there, but i haven't been able to check yet <mbakke>I suppose we'll need a "binutils/fixed", and somehow make linux-libre (and possibly others) use that linker on aarch64. <civodul>mbakke: indeed, if the issue is rare enough we could use it only where it makes sense <bavier`>rekado_: someone posted your "bootstrapping haskell" post to lobste.rs, no comments yet <atw>bavier`: small world, I recently met pushcx <mbakke>efraim: I'm testing the fix on AArch64 now (I think, just added a new "ld-wrapper" input to linux-libre). <efraim>mbakke: that sounds great. Right now I'm poking ovmf <htgoebel>I want to test if wide-string A starting at wide-character 22 contains wide-string B. <htgoebel>For small-strings I would use "strcmp(A+22, B)". <civodul>htgoebel: i've never used C's wide-character API <efraim>currently ovmf builds ia32 on i686 and ia32 and x64 on x86_64, i'd like to split the packages and create per-architecture packages, not sure what to do with the original ovmf though <bavier`>sahithi-ihtihas: any particular reason you want to do that? <sahithi-ihtihas>I tried adding to colorful-soft-port for ui.scm..... to test that i need to build a package... apart from writing package definition <mbakke>sahithi-ihtihas: You can use `guix build --check --no-grafts PACKAGE`. <sahithi-ihtihas>i made changes to source and testing it by building a new package. so want to try with hello instead which is more simple <bavier`>ACTION sees a "minimal" tool: "just install with `npm ...`"... <blink>... retreat! <nckx>‘The changelog file is obsolete, please view the commits log on github’ <nckx>‘People should let developers deploy binary blobs to their machine. You can't trust packagers to get things right!’ <nckx>I give up. I'd ragequit the Internet, but then where would I talk to myself. <g_bor[m]>Do we have a status page, where one can check if a branch is frozen? For example if a patch should be pushed to core-updates or core-updates-next? <nckx>I've suggested it, but very softly, as else I'd have to implement the thing. <bavier`>I would assume if a core-updates-next branch exists, it should be used <nckx>That's a much better policy than an out-of-band status page, actually. <efraim>I thought about using sneek but he gets confused if you overwrite messages <nckx>sneek: Please come back. <nckx>Wait what. How long has sneek been back? I'm so out of all the loops ☹ <nckx>sneek: Later tell nckx all about your adventures. <sneek>Welcome back nckx, you have 1 message. <sneek>nckx, nckx says: all about your adventures. <roptat>civodul: how do you translate "quote", "unquote" and "quasiquote"? <sneek>Last time I checked the cake is a lie <g_bor[m]>roptat: Actually I would rather not. In my translations I leave them as is. I feel translating it is just bound to create confusion... ***jonsger1 is now known as jonsger
<g_bor[m]>Oops, I have a hash mismatch: it's jbig2dec-0.14. <g_bor[m]>This is on core-updates, ant there are 3479 dependent packages. This seems quite serious. <jackhill>bavier`: are you a ham? (unfortunately) that hobby, like everything else often involves software work. Maybe I can take a stab at packaging some ham software when I get some free time ☺ <nckx>Here it's just a silly Puppet text file. <nckx>Which gives hope that it's a temporary thing. <g_bor[m]>nckx: Yes, you are right. I get only "pageok". <nckx>I checked their GitHub ‘releases’ page for a lazy fix, but it's several releases stale. I don't know the package so didn't investigate further. <nckx>Usually it's the other way 'round... <rekado_>I’m home now and ready for a core-updates merge. <rekado_>(keep in mind that core-updates has been waiting for a merge for months) <g_bor[m]>rekado_: It seems that the jbig2dec tarball is not available from the url. We got a puppet "pageok" page there. Is this something to worry about? <nckx>I can't double-check right now, but I thought I saw it cached on our content-addressed mirror. <efraim>rekado_: vagrantc might be unhappy about the linux libre failures on aarch64, they're running guixsd aarch64 machines <efraim>Linux libre doesn't build on aarch64 on core updates, something about the linker <efraim>mbakke said they were looking into it <vagrantc>release early, release often ... it'll get fixed eventually <vagrantc>i'm mostly working on these things out of interest; not using them for anything other than working on guix :) <mbakke>I think I have a fix, but the build machine ran out of disk space (8GB!). Trying again now, takes a while :) <civodul>roptat: re quote, i agree with g_bor[m]; if you wanted to explain the meaning you could write a translation in parentheses maybe <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). <rekado_>we should get rid of them soon though. <nckx>g_bor[m]: Since the hash won't change the number of dependencies doesn't really matter. So I see no reason to delay. <nckx>rekado_: It's a regular tarball. <nckx>s/dependencies/dependents/ <g_bor[m]>nckx: Ok I see, nice. I would say to go on with the merge then. <g_bor[m]>rekado_: I guess it is ok to fix this after the merge then. <rekado_>I get 73.5% of my substitutes from hydra. <sahithi-ihtihas>ERROR: In procedure display: Wrong type argument in position 2: #<<parameter> 1796600 proc: #<procedure 16b1a80 at ice-9/boot-9.scm:1419:15 () <rekado_>sahithi-ihtihas: what’s the line of code? Something with “(display … …)” <nckx>g_bor[m]: Thanks for finding that GitHub URL by the way. I'd ended up on a different GH project from some reason... <sahithi-ihtihas>can someone help me out with this error.... when tried to change source....and build i got this <rekado_>sahithi-ihtihas: this error most likely comes from your soft port. <rekado_>sahithi-ihtihas: the error says that you gave “display” two arguments, but the second argument is a parameter, not a port. <rekado_>hmm, this does work for me in a REPL. <rekado_>when you run this in the REPL, does it work fine? <roptat>civodul: ok, so what about "source location of the package form"? should I translate package and how to translate "form"? <rekado_>sahithi-ihtihas: you have to wrap this all up in parentheses :) <rekado_>sahithi-ihtihas: the output shows me that you just typed these three independent values <rekado_>core-updates has been merged into master <rekado_>sahithi-ihtihas: can you send me a patch of all your changes that I can apply to wip-sahithi to reproduce this error? <rekado_>now, how does core-updates-next become core-updates? Merge core-updates into core-updates-next, then merge core-updates-next into core-updates? <rekado_>I’m getting easily confused by merges… <civodul>and thanks to everyone who took care of that branch over so many months :-) <rekado_>I just merged core-updates-next into core-updates and pushed that as core-updates. <rekado_>I’ll send a message to guix-devel to inform people <bavier`>jackhill: I'd like to be :). Still studying for the license test. Someone submitted a gnuradio patch recently. 