IRC channel logs


back to list of logs

<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
<Copenhagen_Bram>how do I add a second repo to guix?
<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'm considering getting the Librem5 though.
<buenouanq>I would love to put GuixSD on it aswell if I someday can.
<buenouanq>PureOS is indeed FSF endorsed though.
<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.
<Copenhagen_Bram>how do I add a second repo to guix?
<Apteryx_>Hello! How can I build the guix-daemon with debugging symbols?
<soundtoxin> getting this qtwebengine error starting qutebrowser... isn't it supposed to fall back to qtwebkit?
<Digit>if anyone's on M$ github still, this might be a worthwhile repo to star before you leave: :3
<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 moved my repos to Gilab just now.
<nckx>g_bor[m]: .com?
<nckx>Or self-hosted.
<g_bor[m]>.com for now.
<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 looking forward to #peers developments for a federated notabug2.0 and/or vervis and/or other innovations in this area
<buenouanq>how far away might v0.15 be you think?
<buenouanq>how close are we to a v1.0?
<g_bor[m]>buenouanq: I guess 0.15 is not too far, usually there is a release after core-updates merge.
<civodul>Hello Guix!
<civodul>rekado_: another reproducible-research-with-docker service:
<g_bor[m]>civodul: hello!
<rekado_>Hello Guix!
<rekado_>tonight we merge core-updates into master.
<efraim>i'm testing linux-libre on aarch64 again
<civodul>rekado_: yay!
<civodul>does vigra build now?
<civodul>(sorry for not being more active on this front...)
<efraim>linux-libre on aarch64 on core-updates still has the relocation issue:
<jonsger>Sleep_Walker: :)
<rekado_> civodul: vigra still fails.
<rekado_>I’m reporting this as a bug upstream.
<g_bor[m]>Hello guix!
<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 is likely going to be rebooted today
<jonsger>uh, thats bad
<soundtoxin>speaking of rebooting, do you need to reboot to use a new kernel on guixsd, or does it get around that issue somehow?
<efraim>Reboot, no kexec magic yet
<soundtoxin>alright. good to know
<rekado_>sorry for the short notice; will need to reboot 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
<g_bor[m]>hello guix!
<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:
<g_bor[m]>tests/base32.log Error 1
<g_bor[m]>make runs to completion without problem
<civodul>rekado_: re vigra, thank you!
<civodul>g_bor[m]: any clues in tests/base32.log?
<civodul>rekado_: also firewall` & i are moving to a new machine, so it's currently down
<civodul>the new machine is running GuixSD
<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?
<civodul>heya janneke!
<janneke>hey civodul!
<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>Hi all.
<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>heya htgoebel
<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?
<htgoebel>civodul: ACK.
<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
<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.
<pkill9_>dunno catonano
<catonano>I think that's good news anyway
<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 doesn’t say much, though.
<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>efraim: oh it's back?
<civodul>we need to re-add aarch64 then
<civodul>BTW i really don't know what to do with mine :-/
<efraim>could the drive be full?
<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"
<efraim>civodul: try
<rekado_>roptat: ISTR that we have something like “version<”
<efraim>that's what says
<rekado_>roptat: hmm, can’t find it.
<rekado_>roptat: ah, (guix utils)
<rekado_>version>?, and 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)
<rekado_>catonano: for core-updates?
<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
<rekado_>there’s no “db” file.
<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>perhaps i'm missing something
<civodul>could you see where the error comes from?
<rekado_>I’ll try to reconfigure.
<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>rekado_: oooh!
<civodul>got it
<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>hello u0_a461!
<civodul>u0_a461: i don't think anybody tried, but it may work
<apteryx>civodul: great! thank you.
<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
<Copenhagen_Bram>Hi! Whoohoo, I sucessfully installed GuixSD on a virtual machine.
<jonsger>Copenhagen_Bram: congrats :)
<Copenhagen_Bram>thanks :)
<mbakke>efraim: See for the linux-libre aarch64 build failure.
<mbakke>Not sure what to do about it.
<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, no comments yet
<atw>bavier`: small world, I recently met pushcx
<bavier`>atw: :)
<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>Need a bit help for C wide-characters
<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
<civodul>it's not very appealing to me ;-)
<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
<sahithi-ihtihas>how do i rebuild a package which is already built ??
<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
<sahithi-ihtihas>i thought of rebuilding the built one
<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
<sahithi-ihtihas>thanq :)
<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>ACTION yells at cloud.
<nckx>Hm. Pun not intended.
<nckx>$ cat NEWS
<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.
<bavier`>there's always ham radio
<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>g_bor[m]: No.
<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
<bavier`>but I could be wrong
<g_bor[m]>bavier`: Ok, that makes sense.
<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>We miss you.
<efraim>sneek: botsnack
<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>Got it.
<sneek>Welcome back nckx, you have 1 message.
<sneek>nckx, nckx says: all about your adventures.
<nckx>That's our sneek.
<roptat>civodul: how do you translate "quote", "unquote" and "quasiquote"?
<efraim>sneek: what is the cake
<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
<roptat>g_bor[m]: ok, makes sense
<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.
<g_bor[m]>Anyone else experiencing this?
<g_bor[m]>*and 3479 dependent packages...
<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>g_bor[m]: does resolve to a tarball for you?
<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_>Are there any last minute blockers?
<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>Otherwise I have no blockers
<vagrantc>what's up?
<efraim>Linux libre doesn't build on aarch64 on core updates, something about the linker
<vagrantc>ugh. just got that in. :/
<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
<g_bor[m]>rekado_: The jbig2dec homepage points to here:
<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.
<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.
<g_bor[m]>mbakke: Thanks for the clarification.
<g_bor[m]>rekado_: No blocker for me.
<rekado_>how’s youse “guix weather” numbers?
<rekado_>I get 73.5% of my substitutes from hydra.
<rekado_>46.3% from berlin.
<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.
<sahithi-ihtihas>(display message (current-error-port))
<rekado_>hmm, this does work for me in a REPL.
<sahithi-ihtihas>i used the above as diasplay message
<rekado_>when you run this in the REPL, does it work fine?
<rekado_>(replace “message” with a string)
<roptat>civodul: ok, so what about "source location of the package form"? should I translate package and how to translate "form"?
<sahithi-ihtihas>rekado_:$1 = #<procedure display (_ #:optional _)>
<sahithi-ihtihas>$2 = "message"
<sahithi-ihtihas>$3 = #<output: file /dev/pts/0>
<sahithi-ihtihas>i got this when i used REPL
<g_bor[m]>I have to go now. Bye!
<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
<sahithi-ihtihas>when i wrapped that gave me the string
<rekado_>core-updates has been merged into master
<rekado_>sahithi-ihtihas: good.
<rekado_>sahithi-ihtihas: can you send me a patch of all your changes that I can apply to wip-sahithi to reproduce this error?
<sahithi-ihtihas>sure :)
<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>rekado_: woohoo!
<civodul>Thank You!
<civodul>and thanks to everyone who took care of that branch over so many months :-)
<rekado_>ACTION nods and claps
<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.