IRC channel logs


back to list of logs

<davexunit>darn. the new geiser has a bug. going to need to backport a patch.
<davexunit>in case anyone beats me to that
<davexunit>I won't be able to do it tonight
<xd1le>alezost: so say now i want to use the latest git version of bspwm, how
<xd1le>would i do that?
<xd1le>as in, how would i get the sha256 of a git checkout?
<iyzsong>xd1le: you can install 'nix-prefetch-scripts' and then use 'nix-prefetch-git'.
<iyzsong>oops, wrong channel!
<xd1le>nws, i can see how to use git-reference
<xd1le>as shown in the manual
<xd1le>but i don't know how to get the hash
<iyzsong>I don't know too :-
<xd1le>iyzsong: actually, i think it might be `guix hash -r <dir>` where <dir> is the
<xd1le>directory with the source code checked out to the particular commit/tag
<xd1le>not sure though..
<alezost>xd1le: in theory it should be "guix hash -r" on a git directory without ".git" subdir. But it didn't work for me last time I tried. So what I do: after making an inherited package with git-fetch origin method, I just "guix build" it, and it fails giving me the proper hash
<iyzsong>ok, thanks. I used to checkout multiple times too :-)
<xd1le>alezost: woah i don't understand what you mean..
<alezost>xd1le: just make "bspwm-git" package with a fake hash and build it
<xd1le>alezost: also i was wondering if a bare repo would then have a different
<xd1le>hash even though it maybe shouldn't compared to a normal one?
<xd1le>ahh okay
<alezost>the build will fail, and you will find the right hash in the output
<xd1le>yep. so guix git clones it and then discards .git before calculating the hash?
<alezost>yes (at least I think so)
<xd1le>cool thanks!
<xd1le>wait, does it have to have -git suffix?
<xd1le>(because would that stuff up inputs and things?)
<alezost>xd1le: the name can be name whatever you want, but I would name it "bspwm-git" to distinguish it from the original bspwm.
<alezost>sorry, I don't understand what "stuff up inputs and things" means
<iyzsong>no, the '-git' suffix is for package name, I think you can just name it 'bspwm'. for source, the 'git-fetch' method should do the right thing.
<xd1le>no i mean like with dependencies
<alezost>xd1le: here is how I made my "sxiv-git" package based on "sxiv" package from guix:
<xd1le>ahh makes sense then.
<xd1le>i don't know any scheme
<xd1le>so basically what that means is it would all be the same as sxhkd
<xd1le>except the source
<alezost>xd1le: yes, you just inherit from bspwm and change the source
<alezost>(and name, and commit, and version)
<xd1le>alezost: thanks. i have another question.
<alezost>what is it?
<xd1le>with emacs packages/elisp, the problem is if package A depends on package X
<xd1le>1.5, but package B depends on package X 1.6, we can't have both package X
<xd1le>versions to satisfy both packages A and B.
<xd1le>does using guix to manage emacs packages solve this?
<xd1le>or is it just impossible because that's how elisp is?
<xd1le>(say that package X is some library)
<xd1le>this isn't really a problem in practise, just thinking about it theoretically
<iyzsong>I don't think Emacs can load different version of the same library into different namespaces.
<xd1le>iyzsong: yeah that's i think too, but i'm quite new to emacs, so just confirming.
<alezost>exactly, and currently all dependencies of a package A are also installed (they are so-called propagated-inputs)
<alezost>for example, when you install "magit", "emacs-dash" library is also installed
<xd1le>thanks alezost and iyzsong
<alezost>no problem, you are welcome to ask if you have questions
***pksadiq` is now known as pksadiq
***pksadiq` is now known as pksadiq
<iyzsong>it seems my laptop can't run the tests of gdk-pixbuf, which use too much memory.
<civodul>iyzsong: oh, is that a new issue?
<sneek>civodul, you have 1 message.
<sneek>civodul, davexunit says: thanks for helping me get to the bottom of the container issue!
<civodul>iyzsong: any more changes needed in dbus-update? i'd like to merge it ASAP
<iyzsong>civodul: I have make the tests of libsoup and librsvg passed. but gdk-pixbuf use too much memory for me, so I don't know the status of gtk+.
<civodul>how much RAM do you have?
<iyzsong>I have about 3.5G
<iyzsong>and there is a test take very long time, but it looks upstream has change that:
<iyzsong>sorry for the mess, when have some time to update packages, I just can't stop (I used to ArchLinux) :-
<civodul>maybe we should try that patch, then
<civodul>if 3.5G aren't enough, we'll run into troubles anyway
<civodul>ACTION has to go
<davexunit>alezost: thanks for letting me know!
<davexunit>re: geiser
<rekado>I just noticed that adding to /etc/pam.d/login only affects console logins. To affect logins via slim we'd need to add the limits pam entry to its pam service as well.
<rekado>would it make sense to let all login managers extend the pam service for "login"?
<rekado>or should we just remember to also add an entry for for all other login managers we might add?
***orly_owl_ is now known as orly_owl
<rekado>I don't understand the errors produced when building Ant on MIPS.
<rekado>says that "QSORT_STACK_SIZE cannot be resolved to a variable"
<rekado>it's defined less than ten lines before that line:
<rekado>private static final int QSORT_STACK_SIZE = 1000;
<rekado>wrote an email to the GCJ mailing list.
<rekado>guix download
<rekado>gives me this error:
<rekado>ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum A TLS warning alert has been received.> handshake)'.
<rekado>can anyone else reproduce this?
<rekado>ACTION goes offline now
<a_e>sneek: later tell rakado I can reproduce it. Try to open the file in a web browser. It redirects to, which breaks tls.
<sneek>Will do.
<a_e>sneek: later tell rekado I can reproduce it. Try to open the file in a web browser. It redirects to, which breaks tls.
<sneek>Got it.