IRC channel logs


back to list of logs

<quiliro>I want to read the parts of the manual that have changed since I last read it completely. I know the approximate date. Tested 'git diff commit1 commit2'. But it does not work. Please suggest command.
<quiliro>'git diff commit1 commit2 doc/'
<quiliro>on the pulled git repo
<rekado> is a generated file; it is not tracked in git.
<quiliro>dankon rekado !
<quiliro>it would be nice to have a generated guix manual every time I read it all
<quiliro>how can I do that?
<nckx>quiliro: Since you're in a git repository you can ‘guix environment guix -- make doc/’ but you can't genererate a nicely rendered info manual with only the differences.
<quiliro>nckx: thank you....on an installed distro, where is the manual?
<nckx>quiliro: You can use ‘info --where guix’ to find out.
<nckx>‘info --where --all guix’, even (here it prints 2).
<nckx>(/home/nckx/.config/guix/current/share/info/, /run/current-system/profile/share/info/, although I'm not sure why this matters.)
<quiliro>so i can make a local git repository with decompressed files every time I read the complete manual
<nckx>…nope, no idea what that means, sorry 😃
<quiliro>by decompressing /home/quiliro/.config/guix/current/share/info/
<quiliro>then i can have a snapshot of the info file
<quiliro>and can compare the different snapshots
<nckx>OK, I think I get it. I'd just read the guix.git commit history (as rekado already explained) but your method will produce diffs without @texinfo{markup}, which I guess can be nice if that bothers you.
<nckx>It doesn't bother me.
<nckx>Plus you can compare guix-level generations instead of git-level commits. OK, yeah, cool.
<quiliro>is it not the same?
<nckx>Is what not the same as what?
<ng0>quiliro: .info on its own will not be useful for diffs. also info readers will read gzip compressed info files
<quiliro>nckx: Is it not the same to compare guix-level generations and git-level commits?
<ng0>however you can dump info to mdoc or txt, or you could use texinfo2mdoc and use a man/mdoc pages reader to read it (with maybe some tweaks)
<ng0>generally texinfo2mdoc works, you just lose footnotes which is why I keep footnotes out of gnunet documentation to support this way to build the documentation when info is lacking.
<nckx>ng0: I thought so too, but it turns out the diffs look great.
<nckx>No conversion needed.
<ng0>ah, you are just at 1 file with guix right
<nckx>No, 4, I think.
<ng0>hm, ok
<nckx>So yeh, blindly diffing only the first .info will only get you the ToC differences.
<nckx>quiliro: Hm… I thought I understood what you were doing, but after that question I'm back to being pretty sure that I don't. So I can't answer. Sorry.
<nckx>At the end of all that I still recommend ‘git diff … doc/info.texi’.
<quiliro>‘git diff … doc/’
<quiliro> were right...sorry
<quiliro>‘git diff … doc/guix.texi’
<quiliro>Has anyone tested jami from guix?
<nckx>quiliro: Re: your git question: If you chmod the repo to 770 (rwxrwx---), did you add the git users to the group that has that rwx access?
<nckx>quiliro: Passwords have nothing to do with this, just have each user use their own username. Of course, if you hide the repo away in /home/$some_user (why not just in /srv/git, or so?) you have to make sure that all git users can access /home/$some_user. Are you sure this is the case?
<nckx>As a real-world example, my pushurl for Guix is ‘’. There's a reason it's not /home/ludo 🙂 (while that could be made to work, there's no reason to).
<nckx>git over ssh isn't special: if these user's aren't currently able to (for example) scp to that location, they won't be able to git either.
<nckx>s/user's/users/, obviously bed-time, good night o/
<quiliro>nckx: users is the group owner as per default in Guix System
<quiliro>and all users are members of users group
<nckx>…hum? And are these users members of that group?
<quiliro>as per default
<nckx>quiliro: So home/remote_user/git_test is owned by the ‘users’ group?
<quiliro>my user can even ssh without password because i added my ssh public to the server
<nckx>That doesn't matter.
<nckx>You noted in your mail that you chmod'd the repository to lock out all users.
<nckx>‘chmod 770 git_test’?
<quiliro>ls -l of the parent directory specifies git_test is owned by remote_user:users
<nckx>Is /home/remote_user?
<nckx>(That's an is, not an ls)
<quiliro>I don't unedrstand...
<quiliro>please explain
<nckx>Is /home/remote_user also readable by these users?
<nckx>If it isn't, they can never ‘get’ to git_test.
<quiliro>/home/remote_user/git_test is readable by those users. but not /home/remote_user
<quiliro>/home/remote_user is d-wx-wx---
<quiliro>i wonder why it is not readably by the owner
<nckx>If I don't have permission to read /a/b, then it doesn't matter that ‘ls’ says that I have permission to read /a/b/c — I don't.
<nckx>I'm afraid your permissions are grandly fucked up.
<nckx>You might want to start over, since not much makes sense (to me) 🙂
<quiliro>but no need to start over
<quiliro>just permissions
<nckx>Well, I meant mentally.
<quiliro>does the directory nee be x?
<nckx>‘x’ on a directory means ‘list’.
<quiliro>how about /home/remote_user drwxr-----
<nckx>quiliro: That's… confusing. The order is fixed, but I assume you mean drwxr-x-- (750)?
<quiliro>and /home/remote_user/git_test drwxrwx---
<nckx>That'll work as long as your users are in the owning group, which I think they were, so sure.
<nckx>You can easilly test whether sally can create files in /home/remote_user/git_test by using ‘sudo -u $sally touch /home/remote_user/git_test/foo’, without even involving SSH.
<nckx>Where sally=quiliro, I guess 🙂
<quiliro>so quiliro is member of users group and /home/remote_user is 750 and /home/remote_user/git_test is 770
<nckx>It's easy to test: can quiliro run touch /home/remote_user/git_test/foo?
<quiliro>it can
<quiliro>he can :-)
<nckx>If so, quiliro can git push to ssh://quiliro@funbox:/home/remote_user/git_test once there's a repo there.
<quiliro>cool nckx ! thanks will test now
<quiliro>by the way...why is the double slash after ssh:
<nckx>But if you want everyone to log in as remote_user@ (which you give as URL in your mail), then of course they need to use remote_user's password. It's not clear to me what else you were expecting?
<nckx>quiliro: It's to parallel ‘http://’, ‘ipp://’, etc.
<nckx>It means literally nothing. It could have just been ‘http:…’ instead of ‘http://’, and I've heard it said the inventor regrets the useless ‘//’.
<nckx>quiliro: Just so I know where we stand, does the above at least fix the ‘no users can push’ point?
<quiliro>! [remote rejected] master -> master (unpacker error)
<quiliro>nckx: cloned correctly then commited
<quiliro>but no push
<quiliro>should i branch first
<quiliro>i have never pushed on another user's rgit repo
<quiliro>just a single user
<quiliro>error: failed to push some refs to 'ssh://quiliro@remote_server:2222/home/remote_user/git_test'
<nckx>quiliro: No more details than that?
<quiliro>error: remote unpack failed: unable to create temporary object directory
<quiliro>the rest is normal
<nckx>That still sounds like a permissions error, but I'm not 100% sure (I've never had problem pushing to such a set-up). What happens when you run ‘ssh quiliro@remote_server touch /home/remote_user/git_test/foo’?
<nckx>…from the same machine from which you just tried to push.
<quiliro>file created
<quiliro>i previously removed it
<quiliro>do i have to make a new branch?
<nckx>quiliro: So on the remote host, first empty /home/remote_user/git_test (completely), then cd /home/remote_user/git_test && git init --bare .
<quiliro>or may i directly push to master?
<nckx>No, I think the problem is with your remote. It's probably a ‘regular’ (non-bare) repo.
<quiliro>i have an important file there
<quiliro> i could make another directory to git init
<nckx>Let me put it this way: if /home/remote_user/git_test/.git exists, your repository is in the wrong format to be a remote.
<nckx>And you'll have to start over anyway. But you can of course move your important repository somewhere safe first 🙂
<quiliro>i should not git init that directory?
<quiliro>that is what i did
<nckx>No! git init --bare.
<nckx> /home/remote_user/git_test should contain:
<nckx>branches/ config description HEAD hooks/ info/ objects/ packed-refs refs/
<quiliro>mv git_test git_test.backup
<quiliro>mkdir git_test
<nckx>(Don't forget chmod again.)
<quiliro>chmod 770 git_test
<quiliro>cd git_test
<quiliro>git init --bare
<nckx>It should work now.
<quiliro>i do not have packed-refs directory
<nckx>That's fine, that's because it's new.
<nckx>There are no refs to pack, yet.
<nckx>The beautiful thing is: git_test.backup is just a git repository… you can push it to the new one!
<quiliro> ! [remote rejected] master -> master (unpacker error)
<quiliro>i could pull
<quiliro>but not push
<quiliro>error: remote unpack failed: unable to create temporary object directory
<quiliro>and also
<quiliro>error: failed to push some refs to 'ssh://quiliro@remote_server:2222/home/remote_user/git_test'
*nckx makes a very ugly face.
<nckx>Your setup is now literally (well, apart from the slightly odd /home/… and permissions business) identical to mine.
<nckx>It has to work! 😠
<nckx>Ooh. I know what we missed.
<quiliro>a little kit-kat!
<quiliro>yes!, yes! it is a cute little kit-kat
<nckx>La malgranda kato.
<nckx>Who is not setting permissions on newly created files because nckx didn't think of that.
<quiliro>silvestre and tuiti in spanish!
<quiliro>how is that set?
<nckx>quiliro: Not setuid, umask.
<nckx>Ugh. So you'd basically set the sticky bit on everything (chmod -R g+swX git_testt), then set your umask to
<nckx>Well that's a flippin' pain.
<quiliro>so i can start over
<quiliro>but please tell me how
<nckx>This will need some thinking and some reading of docs and a cup of coffee because I'm not going to bed soon.
<nckx>quiliro: Don't despair, we're really almost there.
<quiliro> did it once
<quiliro>how did you?
<quiliro>or several times probably
<quiliro>i don't mind placing it on /svr/git_test
<quiliro>i just used /home/remote_user because it was the handiest
<nckx>By being an antisocial bastard without friends (with commit access, anyway). So I never ran into your permissions error. I have multiple pullers (readers), but I'm the only one who pushes (writes).
<nckx>quiliro: No, the location is unconventional but fine.
<nckx>I thought you'd actually created a ‘remote’ user, but now I realise it was probably just ‘you’ 🙂
<nckx>(If not, I still don't get it, but that's fine, you do you. It should work regardless.)
<quiliro>the remote user is just another name
<quiliro>on the other computer
<nckx>Yah, but you don't need a ‘neutral’ (or ‘service’ name like ‘git’), because there's no software running as that user. But it doesn't matter.
<quiliro>but i used remote_user in case i slipped the name of the server on the public network
<nckx>Got it.
<quiliro>i used the name git_test to make it clear it was my git repo :-)
<quiliro>sorry if i have made it harder :-(
<quiliro>to understand
<nckx> /srv/git (which is what savannah uses, and most sites actually) has the advantage that it's not tied to any user, so if remote_user ever quits your project you don't have to send everyone a new git URL.
<quiliro> it
<quiliro>remote_user was created by me
<quiliro>nice explanation, by the way
<nckx>quiliro: It's fine, I understand most of your situation now & it wasn't more confusing than the average Internet communication 🙂
<nckx>Oh boy, if we're lucky…
<nckx>Apparently ‘git init’ supports a ‘--shared’ option that helps take care of this umask mess for you.
<nckx>Shall we try it? I think we shall.
<nckx>So you'll have to re-create/chmod git_test and this time: git init --bare --shared.
<quiliro>ok 'git init --shared --bare
<nckx>Then I'd ‘chmod -R g+swX git_test’ for good measure.
<nckx>I really, really hope pushing now will just work.
<nckx>Oh shit, it was git init --bare --shared=group.
<nckx>Now you have to dance again.
<nckx>I'm sorry.
<nckx>(No trailing . )
<nckx>That will take care of the ‘chmod -R g+swX git_test’ for you, so *skip* that step.
<quiliro>it worked with the first command
<quiliro>rm -rf git_test/
<nckx>Thing is: will it keep working…
<quiliro>mkdir git_test
<quiliro>chmod -R g+swX git_test
<quiliro>cd git_test/
<quiliro>git init --shared --bare
<quiliro>git clone ssh://quliro@remote_server:2222/home/remote_user/git_test
<quiliro>cd git_test/
<quiliro>touch prueba
<quiliro>git add .
<quiliro>git commit -m "First touch"
<quiliro>git push
<nckx>According to the man page ‘--shared’ is equivalent to ‘--shared=<your current umask>’, which isn't really what we want here, I'd feel more comfortable if you did rm -rf git_test/ && mkdir git_test && cd git_test/ && git init --shared=group --bare
<nckx>one last time
<quiliro>since git clone it was on the workstation
<nckx>but it's up to you.
<nckx>I'm very happy it works, but this might lead to problems with multiple users pushing together.
<quiliro>done as you said
<quiliro>will test on the ws
<nckx>Sorry for that false start at the end, that's what you get for choosing Sleepy McSleepypants as your guide tonight.
<quiliro>great guide
<quiliro>even the mistakes were instructive
<quiliro>thank you for staying are really passionate! :-D
<nckx>Uh yeah that's why I totally made them on purpose.
<quiliro>everything works from remote
<quiliro>from the local user, no commits con be made
<quiliro>where are all the files in the server?
<nckx>In objects/.
<nckx>This is a bare repository, you can't use it as a development repository.
<nckx>It's for pushin'.
<quiliro>great...that is what i originally wanted
<nckx>(It's basically the contents of .git/ in your clone. So no checked out files, just the good git stuff.)
<nckx>Yep. Develop in your own clone, then push when you're ready to share.
<quiliro>what happens to the previous commits?
<quiliro>on the previous repo
<nckx>You can force-push them to the new bare repo from your work repo.
<quiliro>it is not indispensable to recover them...but would like it if it is easy to do
<nckx>Oh, no, they are quite easy to keep.
<quiliro>how do i do that?
<nckx>But that's ‘general git usage’ and not ‘setting up a server’ and you only paid for one lesson tonight 😛
<quiliro>copy all files from old repo to new repo
<nckx>(No, sorry, I really have to go. Need my sweet 2 hours of rest…)
<quiliro>2 hours!
<quiliro>thank you very much
<nckx>quiliro: No! Force-push! No copy!
<quiliro>i will investigate force-push
<quiliro>good sleep
<nckx>You're welcome 🙂 Thanks.
<quiliro>it has been fun
<nckx>Oh, one more thing (since it could have security implications): the group you used is the group that has write access to the repository! If this is a small private server that's fine, but you should think about creating a ‘git’ (or better: ‘<project>_git’) instead and chgrp'ing the repository to that. G'night.
<g_bor>hello guix!
<quiliro>g_bor: hey!
<quiliro>was going to is 1:30 am
<g_bor>quiliro: go, and have your sleep :)
<sirmacik1><rekado "sirmacik: I don’t know of anyone"> rekado: just now read about it. I'm just getting in to grips with making new packages.
<civodul>Hello Guix!
<g_bor>hello civodul!
<g_bor>I have seen you mail about nginx configuration limitations.
<g_bor>I also added some points where the nginx extensions could be improved.
<civodul>hi g_bor!
<civodul>cool, glad i'm not the only one ;-)
<g_bor>civodul: I will be afk for a while, we can discuss when I come back.
<civodul>efraim: in cargo-build-system, instead of (string-drop (basename path) 33), you can write (strip-store-file-name path)
<civodul>it's hopefully clearer and more future-proof
<reepca>should attempting to acquire an already-owned lock on a file be treated as an error or a no-op? Further complicated by the fact that it's sometimes necessary to upgrade or downgrade a lock that's already held.
<efraim>civodul: OK, I'll fix it when I'm next at my computer
<roptat>hi guix!
<civodul>efraim: sure, no rush, i was just going through guix-commits messages :-)
<civodul>howdy roptat & reepca!
<civodul>reepca: it depends on the context i guess
<civodul>sometimes you'll want to wait until the lock becomes available
<reepca>Perhaps I should just define separate procedures for acquiring a lock and for changing the type of lock, and any attempt to use one to do the other is an error
<civodul>yeah could be, i don't fully visualize it
<nckx>Mornin' Guix o/
<efraim>Ah, I see I'm not the only one who reads the commits
<civodul>i have a fix so that OpenBLAS can use more than 8 threads (!)
<civodul>i wonder if that should be a 'replacement'
<reepca>civodul: wow, I just realized how poorly I worded the original question. I should have written "attempting to acquire a lock that is already owned by the current process".
<civodul>ah ah! i guess the code should arrange so that it doesn't happen
<civodul>like it should know which locks it already has
<g_bor>hello guix!
<g_bor>I was wondering if there is a lightweight mechanism in guix to customize a disk-image. For example replacing the kernel, the initrd, or a given file.
<roptat>can't you do that in the operating-system declaration already?
<roptat>oh, and I still don't understand why I can't have a "guix home" subcommand from my channel. I know we talked about it and there was some kind of diagnosis, but I didn't really understand
<roptat>should I send an email to report it as a bug?
<janas>does anyone here have font-awesome installed with guix? It doesn't seem to work right out-of-the-box for me
<civodul>roptat: yes please, along with the diagnosis (which i should have turned into a bug report directly...)
<reepca>janas: have you tried 'fc-cache -rv'?
<sirmacik1>how would you approach building guix package that uses automake and autoconf?
<roptat>I think the gnu-build-system has everything you need for these kinds of packages
<sirmacik1>I've also tried to update ungoogled-chromium but node fails to build with exit-code 1 on check phase :o
<sirmacik1>it went well on my other machine with archlinux and guix installed as package manager
<roptat>civodul, setting GUILE_LOAD_PATH lets me use "guix home", so it's really just a search path issue
<roptat>I just found that out :)
<roptat>sirmacik1, oh so the tests fail undeterministically?
<roptat>sirmacik1, you could take a note of what tests failed and disable them individually
<sirmacik1>how can I see that info?
<roptat>from the log I guess
<roptat>don't look at the last error, try to find the first error instead
<sirmacik1>ok, where is it (;
<roptat>when it failed, guix should have told you (in red) where the logs are located
<sirmacik1>oh, I see it now
<roptat>not red, but bold actually
<roptat>they are bziped, so you can't open them directly, but you can use bzless on them for instance
<sirmacik1>ok, thx (:
<sirmacik1>opening it now
<civodul>roptat: yeah, see <>
<roptat>at least it's reported :)
<efraim>looks like the 'touch' function defined in cargo-build-system isn't actually used anywhere
<roptat>my client didn't keep enough logs
***aida is now known as tripleclopsnot
<sirmacik1>looks like test-ci-js failed
<sirmacik1>I'm hoping that prebuilt packages will showup soon on the servers (;
<roptat>the recent changes to the crates importer gave me some ideas for my npm importer
<civodul>we should use define-json-mapping for all these things
<roptat>what's that?
<civodul>i thought that's what you were referring to :-)
<civodul>it's from (guix json)
<civodul>allows you to map JSON objects to records
<roptat>I was referring to the fact that you can import a specific version
<civodul>so you don't have to splatter all your code with assoc-ref & co.
<roptat>I think I've already heard the question, but didn't see an answer: I'd like to use guile-semver in the importer, but that's not part of guix. Is it an issue?
<roptat>that's actually nice, I'll try to use it
<roptat>the idea is that some packages recursively depend on a previous version of themselves, so I'd like to solve constraints to find a suitable older version
<roptat>and that uses semver
<civodul>so the importer would depend on guile-semver, right?
<civodul>you could try
<civodul>though i don't think semver is followed all that closely
<civodul>in the end, these are still numbers maintained by humans
<civodul>one can get them wrong
<roptat>sure, but npm uses them too, so getting them wrong has some consequences outside of guix too
<roptat>anyway, I'll try that :)
<roptat>if that doesn't go well, we'll find another solution
<roptat>but always importing the latest version like we usually do is not going to work in the javascript world
<g_bor>hello guix!
<janneke>hi g_bor!
<g_bor>:) hi!
<g_bor>how is bootstrapping?
<roptat>hi :)
<janneke>g_bor we're doing great, exciting times as always!
<janneke>ARM is getting there, scheme-only is starting, mes-m2 is nearing completion
<g_bor>nice :)
<g_bor>roptat: I will have a closer look at emacs, but given the nature of it, it seems that it will have to be extended by a per-emacs-package confgi sometimes.
<g_bor>roptat: I created an ssh ticket, just for documentation. It is closed, but can be found fast if someone is looking at it.
<roptat>g_bor, I have an ssh-home configuration
<roptat>although indeed, it doesn't save know hosts and you need to create your key elsewhere
<g_bor>yes,I have written that into the recommendation, and I am also unsing that.
<g_bor>That's why I said it is a documentation only issue, and that's why I closed it.
<g_bor>Also, do you remember any details about the home command problem?
<roptat>I fixed it!
<roptat>you just have to set your GUILE_LOAD_PATH to add ~/.config/guix/current/...
<roptat>then you can run the guix home command
<roptat>unless you're talking about something else
<g_bor>roptat: that's nice.
<roptat>while I work on adding the command, I'd also like to move from using packages to using just a profile
<roptat>and maybe using the API for services too (with extensions, etc)
<g_bor>I was thinking about creating some shell support, like it is done on guix system, so we could simply configure the home to have bash support, and guix-home-support, and generate profile with the path adjustment.
<g_bor>I mean a bash_profile
<jlicht>hey guix!
<roptat>I have plans for a kind of extension that would be "shared": instead of extending a service, their would be extension points that can be implemented by services (home configs), and a service could have more than one extension point
<roptat>so you could have a (terminal-color-theme-home) that would extend any declared terminal configuration
<roptat>so if you have xfce-terminal and gnome-terminal, they would both be extend with that same color-theme
<jlicht>roptat: nice to see you are still working on guix home manager :-)
<roptat>but if you don't declare xterm configuration, then it's not extended and you don't have xterm
<roptat>xterm config, rather
<roptat>I still have a lot of things I want to do with it, even though I don't have a lot of free time lately
<roptat>that's actually something I wanted to implement already 2 months ago:
<joshuaBPMan>morning guix. I'm still really confused about what I'm doing wrong with ssdm...
<joshuaBPMan>I'm still getting a wrong type to apply, but I think I am following the info documentation accurately...
<roptat>can you show us the imports you have at the beginning?
<joshuaBPMan>sure i'll just post the whole config...ein moment.
<joshuaBPMan>the error I'm getting is:
<joshuaBPMan>/home/joshua/prog/guile/guix-config/sway.scm:137:32: Wrong type to apply: #<<keyboard-layout> name: "us" variant: "dvorak" model: #f options: ("ctrl:swapcaps")>
<joshuaBPMan>I don't know why line sddm is trying to use the keyboard-layout from the top of the file...
<roptat>the operating-system declaration redefines what keyboard-layout is bound to
<roptat>instead of a procedure, it's what's declared at the top of your file, line 48
<roptat>try to put that line 48 *after* your service declaration part
<joshuaBPMan>ok. I can do that.
<roptat>then it won't be defined as a <keyboard-layout> object, but as the procedure that produces one of these
<joshuaBPMan>roptat: I didn't realize that line 48 redefined what keyboard layout is...
<roptat>yeah, and the error message doesn't really help either
<g_bor>roptat: the same schema could be extended for shells.
<g_bor>that way one could have a simple flag for guix home command support, and have that in all configured shells.
<roptat>yep :)
<joshuaBPMan>hmmm I've got a new error:
<joshuaBPMan>I guess procedured xorg-wrapper tries to add my Xorg configuration stuff...
<joshuaBPMan>roptat: thanks for the help so far, I realize you probably have other stuff you want to do.
<joshuaBPMan>and guix-home directory is pretty awesome by the way!
<g_bor>joshuaBPMan: It seems you are trying to get sway working.
<joshuaBPMan>g_bor: that is correct
<joshuaBPMan>I am running sway right now, but I am trying to use a display manager. I was told that I need a display manager to use libnotify.
<g_bor>I have some working config, where sway is run from the command line by user. Does that cut the bill for you, or would you like to have it as a system package, with graphical login?
<joshuaBPMan>gdm didn't seem to register sway. sddm currently uses the qwerty layout, and I obviously prefer dvorak. :)
<joshuaBPMan>g_bar: I already do that. I currently just run sway from the command line, and it works great by the way.
<joshuaBPMan>If you really want to know, I would like sway to give me a visual indication of me pressing the volume up button...I know that this can be done via the status bar, but it would be cooler if I could get a gnome-like pop up when I press the volume up button.
<joshuaBPMan>And it would be cool if we could eventually have a (service sway-service-type).
<tune>I'm using sddm/sway/dvorak, but using dvorak built into the keyboard
<tune>I haven't gotten notifications working though
<joshuaBPMan>tune: ahh. That's smart.
<efraim>find /gnu/store/ -name '*\.desktop' -exec grep /usr/ {} +
<joshuaBPMan>I'm using a T400, and I've just moved the keys around, which wasn't easy be the way! The little red button in the middle of the laptop keyboard means some keys need to be painted instead of moved properly...
<tune>yeah I actually just switched to dvorak a few weeks ago because it was as simple as flicking a dipswitch on my pok3r
<g_bor>joshuaBPMan: I believe you could use mako getting notifications. Did you try that?
<joshuaBPMan>tune: awesome. I've been using it for a few years.
<roptat>joshuaBPMan, the object in the error message is weird
<tune>ah I am using a thinkpad also, but in a dock with keyboard and such plugged in
<roptat>its name is a keyboard-layout object
<tune>does anyone have mako confirmed working? never worked for me
<joshuaBPMan>g_bor: I did. $ mako outputs: Failed to connect to user bus: No such file or directory
<roptat>try (xorg-configuration (xorg-configuration (keyboard-layout (keyboard-layout "us" ...))))
<roptat>xorg-configuration is used only once in your config, and that's the name of a field, to which you associate a value
<joshuaBPMan>roptat: trying.
<roptat>which is the result of the keyboard-layout procedure applied to itself :)
<roptat>instead, you want to create a xorg-configuration object whose keyboard-layout field contains a keyboard-layout object that contains the right config :)
<roptat>does it make sense?
<joshuaBPMan>roptat: that does indeed work...
<g_bor>joshuaBPMan: mako needs the user dbus session up. I worked around that by staring it from one of my startup files.
<roptat>joshuaBPMan, cool :)
<joshuaBPMan>g_bor: ohh. ok. then. If you'd like to send me your setup, that would be much approved.
<g_bor>ok, I will have a look at that.
<joshuaBPMan>wait roptat: are you saying that xorg-configuration is a valid value under operating system?
<roptat>no, most ofthese configs are records that you declare with a syntax like (record-name (field-name field-value) (field-name field-value) ...)
<roptat>sddm-configuration is a record-name, and one of its fields is xorg-configuration
<roptat>that's the field-name
<roptat>and you used (keyboard-configuration ...) as its field value
<roptat>but instead, it expects a record of type xorg-configuration
<roptat>that's why I made you write it twice
<joshuaBPMan>roptat: ahhh. Now I understand. It just looks really odd to type (xorg-configuration (xorg-configuration ...)
<roptat>I agree :)
<joshuaBPMan>There's probably not a more visually appealing way to write that. Also roptat: thanks for your super awesome help. I'd like to offer you my formal friendship. P.S. I'm a mushy gushy guy. Thanks again for your help.
<joshuaBPMan>I bet you're the kind of guy that could learn how to fly a jet plane in 10 minutes.
<roptat>I would never get near a jet plane
<roptat>or a plane, or anything that requires coordination ;)
<g_bor>joshuaBPMan: you can find the info related to dbus in the mako docs, see the running part:
<g_bor>you could adjust one of your shell startup files to include the starting of the dbus session, if it does not already exists.
*janneke "enjoys" system roll-back
<g_bor>When you run sway from a login manager, this should not be needed, as mako should utilise the system dbus.
<janneke>gdm fails me again, i think it could be this
<janneke>Sep 13 15:54:52 localhost gdm: GLib: g_hash_table_find: assertion 'version == hash_table->version' failed
<g_bor>janneke: does not look to good...
<janneke>the weather seemed pretty bad already, weird
<tune>g_bor: I run sway from sddm and get that same error
<tune>from mako I mean
<demotri>Where does emacs-elixir-mode go into? emacs-xyz.scm or elixir.scm?
<g_bor>tune: there was a pull request from the guix community to fix that, which I believe made into upstream. I don't know if there was a release since then, and if the guix package has been updated to utilize the fix.
<g_bor>I will have a look at the issue tracker to get you updated.
<quiliro>efraim: multaj /usr/
<joshuaBP`>tune: you run sway via sddm? Do you use display manager "x11" or "wayland"?
<joshuaBP`>This is JoshuaBPMan by the way. I currently have sddm opened up in another tty, but I can't seem to log into anything...
<tune>if I had the choice I definitely chose wayland
<joshuaBP`>actually, maybe sddm works now...
<tune>can't recall that option for sure
<tune>oh yeah I have wayland set in my config.scm
<tune>(sddm-service (sddm-configuration (display-server "wayland")))
<g_bor>tnue:yes, mako should be update to version 1.4
<joshuaBPMan>tune: cool. I might give this a try, but I don't know if sddm will let me use dvorak layout on wayland.
<joshuaBPMan>at least I wouldn't know how to configure it.
<tune>g_bor: how do I check my installed version?
<g_bor>That would also close bug #34971
<g_bor>tune: the only version guix has is 1.3
<joshuaBPMan>I think I am going to try to restart my computer and see if my current sddm config lets me start sway.
<g_bor>it should be a trivial update. Are you willing to give it a try?
<janneke>ah, /me should try to delete /var/lib/gdm -- will try
<Minall>Hello guix!
<Minall>Is there a way to 'name' a reconfigure?
<joshuaBPMan>Minall: I believe so.
<joshuaBPMan>alias reconfigure='sudo guix system reconfigure ~/prog/guile/guix-config/sway.scm' is in my .bashrc
<tune>g_bor: mako works after trying the sway command mentioned in issue #34971! thanks for mentioning it
<joshuaBPMan>perhaps you mean that you want to store a copy of the configuration file in the store. I think that Ludo mentions that someone on guix devel...
<Minall>I mean, naming a reconfigure so in grub it appears with other name, not adding an alias to the commands...
<joshuaBPMan>minall: There might be a way to do that, but that is a little beyond my expertise.
<joshuaBPMan>you'd probably have to write some code to make that an option.
<tune>as for trying the update, I am inexperienced and going to sleep soon, so I will have to pass on that
<roptat>Minall, I don't think so
<Minall>roptat: Oh... sad, but it would be very good to have it
<roptat>actaully, a menu-entry object has a label
<Minall>Since I normally play around reconfigure and operating-system's configs, I would love to do that
<roptat>but I don't know how the menu is generated for old generations
<g_bor>I am having a bit of problem.
<g_bor>As I was trying to extend the guile ffi, to have some useful primitives for interacting with C I bumped my head into enum.
<g_bor>enum is usuaally int, but gets promoted by the biggest enum value into an integer type where the enum fits.
<bgardner>Good morning Guix! For packages like samba and geomyidae where it exists but has no matching service (yet), is there a 'standard' way to temporarily mock them up in config.scm so the daemon can be started?
<g_bor>Is there a reasonable way to find out the size using pure scheme?
<g_bor>bgardner: I believe that working around this is not easier than writing a simple service for it.
<bgardner>g_bor: Do you mean literally a simple-service? Or are you saying the best approach is to do the full service definition?
<g_bor>bgardner: I believe that writing a simple service definition, hardcoding the config and the flags is easiest.
<g_bor>you could do a simple-service, extending shepherd, but I don't believe it will be much simpler in this case.
<bgardner>g_bor: I understand, thanks - I'll wrangle with it and see what I can do.
<g_bor>bgardner: for a simple example you can see prometheus-node-exporter service in gnu/services/monitoring.scm
<bgardner>g_bor: Thank you, that is *very* helpful!
*g_bor afk
<roptat>bgardner, other examples include opensmtpd
<roptat>it's just a simple service that takes a configuration file as parameter
<roptat>as well as
<bgardner>roptat: Thanks, I had been looking around for just such a sample and didn't have success, so both are a big assist.
<roptat>which is the first version of the dkimproxy-out service I wrote
<roptat>which also reminds me that I should push the latest version now
*civodul made good progress on the Guix Jupyter kernel, at last
<roptat>the build failed because of two tests failures in tests/kernels.scm
<roptat>kernel_info_request and execute_request
***jonsger1 is now known as jonsger
<civodul>roptat: ah well, it seems these tests fail non-deterministically
<civodul>i said i made progress, i didn't say that i'm done ;-)
<civodul>hopefully if you try again it passes
<roptat>I disabled the tests and am trying the demo
<roptat>it seems to be working, it's really fun :)
<roptat>it's a bit weird how executions are numbered
<roptat>when I load a kernel, it's back to 1
<roptat>so I have multiple In [1] in the file
<civodul>ah yes, there might be a bug there
<civodul>glad it works for you!
<civodul>there are many things we could do
<civodul>like completion, pretty printing of an environment's packages, etc.
<civodul>also remembering what the last environment was, so you don't have to re-enter %guix every time
<demotri>Where does emacs-elixir-mode go into? emacs-xyz.scm or elixir.scm?
***jonsger1 is now known as jonsger
<g_bor>hello guix!
<pinoaffe>g_bor: hi!
<bluekeys>Hi guix. Is there a way to get documentation for guix related functions similar to how emacs produces docs for elisp but for guix scheme files?
<rekado_>bluekeys: it’s a little awkward, but in a Guile REPL you can use procedure-documentation to access the docstring of Guix procedures.
<g_bor>rekado_: Thanks for answering the Outreachy inquiry so fast :)
<rekado_>g_bor: sure!
<retropikzel>Any idea how to fix fonts in icecat? Numbers and symbols dont show at all
<bandali>try installing a font package through guix
<bandali>e.g. font-liberation
<bandali>on a foreign distro, you might have to set/change XDG_DATA_HOME (i think?) when launching icecat
<retropikzel>I'll try that
<retropikzel>It worked! Thank you very much :)
<bandali>alright. you could try launching icecat like: XDG_DATA_HOME=$HOME/.guix-profile/share icecat
<bandali>cool :)
<retropikzel>Just needed to install font-liberation. Weird how it showed something even without that
<bandali>are you on guix system?
<bandali>iirc on guix system you wouldn’t need to set XDG_DATA_HOME like that but on foreign systems you probably would
<retropikzel>Yes I am on guix
<quiliro>git clone
<quiliro>woops! it is contageuos....
<quiliro>finally could manage to use flyspell on emacs
<quiliro>i just needed to add dictionaries
<quiliro>guix install aspell-dict-es aspell-dict-eo aspell-dict-en aspell
<quiliro>and it worked off the shelf for ERC and everything else
<quiliro>the system-configuration on the above link looks promising
<quiliro>will read its docs
<quiliro>maybe it would be nice to have instructions for modifying it to personal need....although it explains what each part does
<quiliro>it would be nice to install a bare guix system and then git clone that repo
<quiliro>then have a step by step instruction to modify for certain tasks...for example email server
<quiliro>then run sudo guix system reconfigure system-configuration/mail.scm
<Pounce56>Whats the current status of guix on hurd? The latest update I can find is february 2017
<quiliro>or as it says on the docs -L [...]/modules
<quiliro>does only use and recommend free software?
<bandali>roptat, ^
<quiliro>Pounce56: gnu_srs1 or gnu_srs was interested also on the hurd
<rekado_>Pounce56: the short version is: it doesn’t work right now as the bootstrap binaries we cross-build for the Hurd are failing.
<bluekeys>rekado_ thank you.
<Formbi>couldn't you try to build them on Debian?
<bluekeys>Does the guix daemon have a repl running I can connect to from emacs, like swank for common lisp?
<atw>bluekeys: I could be wrong about this but I believe that the build daemon is inherited from Nix and is written in C++. I do not believe it offers a REPL directly. However, there are ways to interact with the daemon from a REPL, like (guix monad-repl)'s ,run-in-store
<bluekeys>atw By golly I think you're right, I'm just looking through the repo and there's a whole bunch of files from the nix software
<bluekeys>Bye guix
<rekado_>Formbi: that’s not the point. We have a mechanism to build bootstrap binaries in Guix. These are the foundation of the software graphs that Guix establishes. It makes sense to build them with Guix.
<Formbi>rekado_: ah, ok
<janneke>any cmake fans here? i'm trying to cross build mcrl2 and want to seed the cache in ../build/CMakeCache.txt, but the configure stage has (mkdir "../build")
<janneke>ah, it seems all cache values can be set on the command line, using -D... "great"!
<nickey>hi guys! should emacs daemon be a service in guix terms? I can't find it, so running it in .xsession, which is not so good
<atw>janneke: lol
<atw>nickey: the idea of "user services" has been discussed a few times on guix-devel. I wrote about my first try in and owe the mailing list a follow-up. I used basically the same approach since then, with one small difference being the use of emacs' newer --fg-dameon option.
<atw>a newer discussion of "user services":
<nickey>atw: thanks
<atw>np! I did not mention: my approach is not canonical. Any way you wish to start an emacs daemon is valid!
<janneke>it appears that cmake does not know the concept of cc_for_build, you have to take care of that all by yourself, entirely outside of cmake
*janneke again is flabberghasted why on earth someone would choose to use such a crippled system
<daviid>is it possible to 'dead easy' instll guix on ouindoze? asking because i would use it to run guile scripts themselves mainly epending on texlive
<daviid>i mean one of our lab customer, who's forced to use ouindoze, would use our work ... i would never ever do anything on ouindoze my self ...