<axd-v>ngz: ok, just didn't want to pollute the mailing list with little issues like small libraries and other packages not compiling properly or having some other problem.
<marusich>axd-v, it's worth checking to see if the package was fixed on one of the other branches - staging or core-updates - but yes, that's the general practice.
<axd-v>marusich: how would I go about that? Haven't messed around with other branch as of yet.
<marusich>I don't know of a generic way to accomplish the task. But, if I were going to do it, I'd search bug-guix and guix-patches (two Guix Debbugs projects for bug tracking and patch tracking, respectively). I'd search the email lists for any recent mention of the package in question, using the Namazu web search page for them. And I'd get a local copy of the Guix Git repository and use "git log origin/master" or "git log origin/staging" or "git log
<marusich>origin/core-updates" to search for possibly related commits. There are a lot of commits, so it might be helpful to parse the output for likely keywords, or to limit the "git log" to the file in question (e.g., "git log origin/core-updates -- gnu/packages/sync.scm").
<marusich>However, in this case, I think it's unlikely that changes to the package itself will show up on those branches. This is because the owncloud-client package has no dependents, and packages with no dependents are usually updated directly on the master branch.
<marusich>We put changes that cause lots of rebuilds onto other branches (see (guix) Submitting Patches).
<marusich>You can see the count of dependents by running "guix refresh -l owncloud-client", and it reports that there are none except itself.
<marusich>So in this case, I think you're best bet is to search the email lists for keywords related to your problem, such as the error message itself.
<marusich>If nothing shows up, it's probably the case that nobody has worked oni t.
<marusich>That might have been more info than you needed, but I hope it helps.
<axd-v>marusich: thank you very much for the detailed explanation. I'm gonna explore what you've provided me with.
<marusich>OK! Don't stress too much about it, though. It's nice to avoid duplicate work if you can find that somebody worked on it already, but if you've got a problem, asking here, on the mailing list, or reporting a bug are the right ways to go.
<axd-v>rekado_: question about your .xsession file. You have `exec exwm` as your last line. You also said that you still use slim. Does having exwm in the .xsession file interfere with slim's selection of a wm? Because at the moment I use slim to select either i3 or exwm as my wm. How would `exec exwm` play out if I choose a session using slim?
<axd-v>Do you still choose exwm in slim when loggin into your session?
<marusich>I think if you choose a session at the SLiM login screen, but your ~/.xsession ends with "exec exwm", your choice at the SLiM login screen will be ignored.
<marusich>That's because when you select a desktop session from the SLiM login screen, Guix will call your ~/.xsession file (if it exists) with arguments. Those arguments are the command line invocation that will start up your selected desktop session. If in your ~/.xsession you choose to ignore those arguments, then the desktop session you selected will be ignored.
<axd-v>marusich: I see, makes sense. Would you by any chance know where wms put their xsession files by default?
<marusich>If I recall correctly, the way it's done in GuixSD is by extending some service...
<marusich>Let me see if I can find something helpful.
<rekado>FWIW, the locale problems I had were limited to building a project that was configured with tools from an environment that was made with Guix from “master”, while the rest of my system is on “core-updates”
<rekado>so there really isn’t anything wrong after all.
<axd-v>Hey everyone. I'm trying to configure my custom xkb layout. I have two ways of approaching it: 1. Generate my whole layout or 2. Add my layout as a varient of `us` layouts. Let's focus on option 2 right now, since 1 entails more steps. Since I can't modify system dirs, I found out that I can just recreate the whole ../share/X11/xkb dir in my $home @ ~/.config/xkb. Then I use option -I to setxkbmap to specify my alternative directory.
<axd-v>However, I'm testing it with just modifying slightly any layouts already in place at symbols/us and none of my changes to their definitions is evident. The internet suggested that there is a cache that I need to deal with. Well it's supposed to be located at /var/lib/xkb. It's obviously not there but I can't find it anywhere so that I could delete it. Can anyone help?
<axd-v>I'm supposed to find files that end in .xkm, but it's non-obvious where they might be.
<mbakke>sneek: Later tell CornBurglar there is a bug in the Guix 0.14 installer where the ESP needs to actually be mounted at `/boot/efi`, not e.g. `/mnt/boot/efi`. :/