<yenda>ok it didn't make any sense because it was complaining about some things not being commited <yenda>so I stashed and it was the commited commit but they were also commited <yenda>whatever I deleted the stash <yenda>When people send multiple mails for patches, is it done manually ? <mark_weaver>git send-email is probably the better way, but I confess I just run "git format-patch -N" where N is the number of commits, and then attach them manually to an email. <sbidin`>Okay, reconfigure worked out fine now. Thanks for the help guys. <sbidin`>Completely unrelated: `w` doesn't show me as logged in. :) <yenda>it says git send-email doesn't exist <davexunit>ACTION sends new ruby-build-system patch to list <davexunit>there was some missing perl library that got added <yenda>but even with that it says it's not a git command <mark_weaver>I could imagine that if git is in the system profile and git:send-email is in the user profile, maybe it won't work, dunno. <yenda>is probably the reason because even after guix package -r git I still have git <yenda>is git in the base packages ? <mark_weaver>no, but it might be a propagated input for somethign else <mark_weaver>search for git in /run/current-system/profile/manifest <mark_weaver>did you run "git send-email" from the command line or via magit? <mark_weaver>did you have more than one profile-changing "guix package" commands running concurrently? <yenda>not that I am aware of but it is possible <yenda>My system has a double personality now ? <mark_weaver>it's just that one of the commands probably was a no-op <sbidin>Can guix build independent packages in parallel? <mark_weaver>however, if you try to run two commands that modify the same profile concurrently, one of the will end up winning, and the other will be a no-op effectively <yenda>which git returns /home/yenda/.guix-profile/bin/git <mark_weaver>you're running these commands as your normal user, right? <mark_weaver>well, I can't explain it. very strange, but I have to go now, sorry.. <yenda>ok I'll try to turn it off and on again <mark_weaver>yenda: all I can think of is that $HOME was not set to /home/yenda <yenda>echo $HOME returns /home/yenda <mark_weaver>if so, try "strace -o trace.out guix package -I git" <mark_weaver>yenda: what is the output of "ls -ld /home/yenda/.guix-profile" ? <yenda>lrwxrwxrwx 1 yenda users 54 Aug 16 21:33 /home/yenda/.guix-profile -> /var/guix/profiles/per-user/yenda/guix-profile-84-link <mark_weaver>why have you been messing with that symlink? it should have been set up for you automatically and then you never have to touch it! <yenda>I messed up my entire home earlier today <sbidin>I've imported several Haskell packages and installed them. Guix placed them into .guix-profile/lib/ghc-7.8.4, which is fine, but now ghc can't actually find them. Is that path wrong or do I have to manually tell ghc where to look? <sbidin>For instance, the packages aren't listed via ghc-pkg list. <sbidin>I think the default path is probably ~/.ghc/lib/ghc-7.8.4. ***sorpigal is now known as phogg
<sbidin>Ideally this should probably work out of the box, which is the reason why I'm reluctant to just place a symlink and call it a day -- it won't work for anyone else unless they do the same. <yenda>have you tried guix package -u ? <sbidin>yenda: Yes, nothing. Everything's up-to-date. <sbidin>ghc-pkg list shows packages that come with ghc (the core libs). <sbidin>but not the ones installed manually after that. <mark_weaver>sbidin: is ghc in your user profile, or only the system one? <mark_weaver>maybe the ghc package cache is not picking them up for some reason, see 'ghc-package-cache-file' in guix/profiles.scm for hints <mark_weaver>I would look at some of our existing ghc library packages and see where the stuff is installed there <sbidin>mark_weaver: I believe it's definitely in my profile. <sbidin>mark_weaver: I'll go ahead and do that! <sbidin>Yeah, getting the existing ghc-text from hydra places it in the same directory (which is fine, again), but ghc-pkg doesn't see it and it's not accesible via ghci. <mark_weaver>did your packages install anything into lib/ghc-7.8.4/package.conf.d/*.conf ? <mark_weaver>but the main person who worked on our ghc support is Federico Beffa, who isn't on IRC much. <mark_weaver>there might also be some environment variable you need to set <mark_weaver>does "guix package --search-paths" recommend anything ghc-related? <mark_weaver>anyway, sorry, I haven't used ghc in a very long while <sbidin>mark_weaver: No worries, you've helped me lots today, I'm sure I'll figure it out soon enough. <sbidin>mark_weaver: No, just PATH and PYTHONPATH. <sbidin>mark_weaver: Actually, you should probably get some rest, we've been badgering you the entire day. ;) <lfam>I'm working on packaging some software and I need some help. My package is in its own source tree apart from guix. I can build and install it by setting GUIX_PACKAGE_PATH but it seems like using ./pre-inst-env from the guix source tree is the preferred way to test a package before submitting it <sneek>Welcome back lfam, you have 1 message. <lfam>and that is the step that doesn't work for me <lfam>The "Packaging Guidelines" in docs say to use ./pre-inst-env to run guix commands on the guix source tree <lfam>But I have pre-inst-env.in instead, and it's not executable. So I chmod 744, and run it. Here is the output: <mark_weaver>lfam: you have to build guix before you can run it :) <lfam>okay, i won't submit my paste :P <lfam>So, after guix environment guix, I guix build guix? <yenda>try following that and if something doesn't work make a pull request <lfam>Is that for building the package manager or the distribution? I'm doing this on Debian <mark_weaver>asking for a pull request implies asking them to start using github, which is a bad idea <mark_weaver>it requires running non-free software, and also did you read the legalese they demand that you agree to before getting an account? <mark_weaver>I suppose no one does that anymore, they just click "agree" <lfam>I know guix is not on github, don't worry <mark_weaver>which is not to say that yenda's readme is not useful, maybe it is :) <yenda>mark_weaver: actually I just read the TOS and I don't find anything terrible <yenda>is there something about it that I missed ? <lfam>So, what is effect of running ./bootstrap when I already have guix installed with the build daemons running? <mark_weaver>lfam: if you don't run "make install" (and you shouldn't) then nothing outside of the build directory will be changed <yenda>I was about to ask if you were talking about that part. Well I guess it means you will pay big money if github get sued because of something you posted that was violating copyrights ? <lfam>I started on that contributing page in the past, but I got distracted by "Packaging Guidelines" and never made it back. Happens a lot with this manual... <mark_weaver>there's nothing in there that limits it to them being sued. <mark_weaver>if someone sends them a letter making a bogus claim and they decide to consult with a lawyer about it, they could ask you to pay for it and you've promised to do so. <mark_weaver>yenda: but actually, there's something *far* worse than that. <mark_weaver>yenda: do you re-read the github terms of service every day? <mark_weaver>because if they change it, and you keep using the service, you are bound to the new terms. they don't even have to notify you. <lfam>I'm just saying I've found it hard to figure out from the docs how to package something from soup to nuts. I don't know if it could be communicated more clearly or not though. Once I am good at this maybe I will help with the docs if they need it :) <mark_weaver>so, effectively, you gave them a blank contract with your signature at the bottom and they can fill out the agreement later. <mark_weaver>it's interesting, btw, that government customers get a different deal. github promises to notify them a few days in advance. <yenda>mark_weaver: Well I'll argue that there is some clause way worst than that in work contracts, companies are just covering their ass and it's not in their intrest to abuse this against few users otherwise they could lose their whole business <yenda>but I agree that it's better to be safe than sorry <yenda>and judges in the past have not always been really comprehensive on software / copyright matters <lfam>If you make the contract safe then you don't have to worry about being sorry ;) <mark_weaver>okay, so you gave them a blank contract with your signature at the bottom, and take it on faith that they won't abuse it. <davexunit>it's unfortunate that github's TOS are considered normal now. <davexunit>so far github has shown that they will censor anything <yenda>compared to some other they are even kind of good <mark_weaver>almost nobody reads these things, they just click "agree". <davexunit>if someone complains about it or a government wants it removed <mark_weaver>and so the number of people who make a fuss are insignificant to them and they can do whatever they want. <mark_weaver>but I, for one, refuse to give anyone a blank contract, and I find it insane that most people do it all the time. <davexunit>I have a github account, so I'm just as guilty of supporting this stuff as everyone else. <davexunit>you can host your own gitlab server at least <xentrac>I was pretty astonished at github censoring "WebGL for retards" the other week <yenda>I was reluctant to use it because it's php <yenda>xentrac: well political correctness is a big trend in the uS <lfam>My laptop is nice and hot now <lfam>Too bad it was already hot here <xentrac>hopefully we can get some kind of decentralized alternative up and running quickly <lfam>I know, it's so ironic what's happened to git <yenda>its basically the biggest svn server in history <lfam>I'm new again to irc after 15 years <yenda>best exemple of how to turn a decentralized technology into a centralized one <lfam>The way to send a message to a user is /msg User message, right? <yenda>and when you fail everybody gets to see it :) <yenda>ACTION (almost) never fails that <sbidin>lfam: About the manual: I agree it can get confusing and there's not a clear picture painted of a way to build a package from scratch. I'd like to see a separate section just showing the entire process from start to finish, tutorial-like. <sbidin>From pulling guix to sending a patch file. <sbidin>The documentation is great as a reference, though. <lfam>Yes, that is what I was looking for. You are right: as a reference, the docs are comprehensive. <sbidin>And before someone asks: of course I volonteer. Just as soon as I manage to test and send in a package. :) <lfam>Well I need to go afk for a while. Later I will try to finish testing this package out! <yenda>I could do such a tutorial, actually the content is already in my repo I just have to put it in order and in one file <sbidin>mark_weaver: About the GHC issue: setting GHC_PACKAGE_PATH works. It failed for me because my packages were broken for another reason, but that's fixed now. <sbidin>Is there a way for an installation of ghc to automatically somehow export this var so nobody has to set it? <sbidin>Or maybe GHC's searchpath is configurable during compilation... <davexunit>I think a step-by-step tutorial to complement the more in-depth reference sections would be awesome <mark_weaver>sbidin: environment variables are inherited from parent processes, and there's no way to modify the environment variables of a running process <mark_weaver>the way we handle this is to notify the user about what environment variables need to be set <mark_weaver>it may be that we should add a 'native-search-paths' field to the 'ghc' package. <mark_weaver>well, regarding my statement that there's "no way": the process that modify its own environment variables, and of course it is also possible to attach a debugger or equivalent to modify another processes address space, but this is not reasonable for us to do :) <sbidin>mark_weaver: I see. I think just using native-search-paths might just fix it. I'll try it out tomorrow. <sbidin>Ah, and such vars are automatically kept track of by guix. Very nice. <mark_weaver>sbidin: binutils, but you should instead install 'gcc-toolchain' <mark_weaver>it includes gcc, binutils, glibc, and also a special thing called ld-wrapper that ensures that rpaths are added to the programs and libraries you built, so that they can find the shared libraries they need in the non-standard places in guix. <sbidin>Since GHC uses GCC as part of its compilation step, it should probably have gcc-toolchain as a dependency then. <sbidin>(I'm keeping track of all this. :)) <yenda>I have a few depencies I had to package for I3 that I don't know where to put <yenda>there is libyajl, a json parser in C <yenda>that's where most json parsers are but it's not really a parser meant for the web though <davexunit>ACTION has a basic rubygems importer working <yenda>should I just submit everything in i3.scm and let the mailing list decide if some package should be moved ? <sbidin>I've gotten rid of slim and xfce, but otherwise have the desktop configuration. Running startx complains about a missing X, since xinit looks for X in its /gnu/store directory instead of my profile one. Anyone knows how to fix this? <sbidin>(xinit looks for X in /gnu/store/...-xinit/bin) <mark_weaver>in the meantime, I think there's probably a way to pass xinit and startx the filename of X <sbidin>mark_weaver: Yes, doing (xinit -- path/to/X) seems to work, but weirdly (startx -- path/to/X) uses the /gnu/store path again. <mark_weaver>however, it shouldn't look in your profile. the proper fix is to add xorg-server as an input to whatever packages contain xinit and startx, and arrange to have xinit and startx run /gnu/store/.../X by default <sbidin>Ah, good point. I'll try that out. <mark_weaver>I warn you, though, that fixing it will entail a rebuild of almost every graphical package <mark_weaver>that would happen if you modified xorg-server, but probably xinit and startx are in another package that is not an input to most other things. <sbidin>Correct, xinit and startx are in the xinit package. <yenda>I just refered to it as non-copyleft and linked to the file <yenda>same non-copyleft link to file <yenda>Ok so now I have 3 library left that are used only by i3 for now, should I just let them in i3.scm and maybe we move them later ? <yenda>libsn is an implementation of the startup notification protocol, libeb an event loop, and libconfuse a configuration file parser <yenda>did you notice that some file put 2 spaces between declarations and other only 1 ? <mark_weaver>libsn should probably go in xdisorg.scm with 'startup-notification' <yenda>libsn IS startup-notification :D <yenda>I disagree with the license choice though, the licence file is gpl2 not 2+ <yenda>and the files have a X11 style license header <mark_weaver>the license file is *always* for a single version of the license. <mark_weaver>it is in the source files themselves (which is what matters) that might say version N or later <mark_weaver>of course they cannot include a copy of a license that hasn't yet been made <yenda>well actually there is a comment "most of the code is provided under x11 licicense" in the package definition <mark_weaver>debian says that it's part "mit" (which may mean either expat or x11) and part gpl2+ <mark_weaver>I would tend to add 'expat' to the license list, but other significant contributors to guix have been of the opinion that if there's a mix of GPL and non-copyleft, we just say GPL since that's the effective license of the entire work. <sbidin>mark_weaver: I have xorg-server as an input to xinit, but not sure how to make xinit use the correct xorg-server path when run. Did you mean there's a way to force linking X directly to xinit's bin dir? <mark_weaver>sbidin: find the place in the code where it launches X, and use 'substitute*' to patch in an absolute file name. <sbidin>mark_weaver: Ah, so surgery it is. :) <mark_weaver>well, maybe there's a better way, that's for you to find out :) <mark_weaver>sometimes there's a configure flag to set such things, sometimes a Makefile variable can be overridden with #:make-flags, and sometimes you need to modify the source. <yenda>I made a separate commit for the packages that are in other files, I plan to do a single commit for libconfuse, i3-wm and i3-status with title add i3 and declaration of the 3 variables in the commit message <yenda>so what do I commit with the new file ? <mark_weaver>make a backup of the file, and then copy one piece of it into the repo at a time, committing the separately, please. <mark_weaver>I guess you need to start with something that doesn't depend on anything that isn't yet in the repo. <mark_weaver>sorry to be a pain; we try to keep our commit history to a higher standard than most projects. <mark_weaver>once you become accustomed to it, you can keep the packages in separate commits while you are working on them, instead of trying to separate things after the fact. <mark_weaver>here's what I do: I work in my own private branch 'mhw', and add one package at a time, committing each one as I go. <mark_weaver>and now suppose I've added commits A B and C, and now I find that I need to fix something in A. <yenda>well it's not really a pain with maggit it's easy to separate them <yenda>the pain is to name the commit <mark_weaver>I make that change, commit it as a 'fixup' commit, and then use magit's interactive-rebase to move that new commit just after A and label it a 'fixup' commit, and it squashes them together. <mark_weaver>you mean the commit log? just say "gnu: Add <package-name>." as is our convention. <yenda>I'll try to have that workflow at some point <yenda>* gnu/packages/i3.scm: New file. <yenda>* Makefile.am (MODULES): Add it. <yenda>* gnu/packages/i3.scm (i3-wm): New variable. <mark_weaver>yenda: add it to GNU_SYSTEM_MODULES in gnu-system.am, not Makefile.am <mark_weaver>in a commit that adds a new file, just say "New file." <mark_weaver>in this case, the summary line should say "gnu: Add i3-wm." I think, right? <yenda>so I don't say New variable, just new file and add it <yenda>it's nice it makes me practice git way more than any project I've made before :) <davexunit>my git workflow has greatly improved since working on guix <davexunit>I make much better commits than before. Too many projects are too lax about this stuff. <davexunit>taking a stroll through the guix commit log is pleasant and informative. <davexunit>ACTION sends patches for rubygems.org importer <yenda>ACTION yenda sends patches for i3 <yenda>ACTION doesn't even know how to use /me anymore, time to sleep <davexunit>with this importer, I am getting close to the point where I will be able to migrate Ruby projects from rvm + bundler to guix. <sprang>what's the difference between %output (no s) and (assoc-ref %outputs "out")? if any? <davexunit>without looking, %output is bound to the result of (assoc-ref %outputs "out") <mark_weaver>sprang: they are always the same; it's a matter of taste which to use I suppose. <yenda>mark_weaver: ty, I'm using git send-email I hope the bouncing problem is gone otherwise it means it has something to do with my provider rather than my webmail client <davexunit>sprang: packages may have more than 1 output, and the name "out" is the default output name. <mark_weaver>I believe civodul prefers (assoc-ref %outputs "out") because it makes it obvious how to get the other outputs, which makes sense <mark_weaver>yenda: I guess that 'git send-mail' probably needs a 'sendmail' program on your system that's configured properly <mark_weaver>I don't have that on my system; only emacs is configured to send email, so I guess I can't use git send-mail <davexunit>I have git send-email talk to my email provider's smtp server <yenda>I think it send mails itself, since you give it the config of your smtp server with git config <sprang>so they do resolve to the same thing <davexunit>I keep screwing up my emails because I actively use both my gnu.org address and my worcester.edu address, and I haven't yet figured out how to get emacs to work with both easily. <mark_weaver>sprang: within phase procedures, we prefer to not use %outputs or %build-inputs, but rather to accept the keyword arguments 'inputs' and 'outputs'. <mark_weaver>so %output, %outputs and %build-inputs are for use in things like #:configure-flags or #:make-flags <sprang>%output lets me avoid the rather hefty let block <sbidin>I can use %output to reference the package's /gnu/store dir, but how can I reference the dir of an input package? <sbidin>Whoops, I just realized you talked about that several lines above. <yenda>well I just realized after all the moving around I should have tested my patches, because licenses are imported differently in every file there is some unbound variables :( <mark_weaver>I've often been severely tempted to regularize all of that <yenda>I don't know what's wrong with non-copyleft in libevent though <yenda>because it worked fine that way with (guix licenses) in i3.scm and now it doesn't in libevent.scm <yenda> "See LICENSE in the distribution.")))) <yenda>it was ubound variable non-copyleft but it's gone after a second make <sprang>speaking of licenses, why do some packages add a "license:" prefix? <yenda>actually it's still there, I forgot I was trying to do guix envronment not make <yenda>here is the error it's actually a lot of things he complains about <mark_weaver>sprang: some package modules (files) import (guix licenses) with a license: prefix, which means that all imported bindings from that module have their names changed. <mark_weaver>this is often needed because some of the bindings in (guix licenses) conflict with bindings in (gnu packages ...) <mark_weaver>e.g. there's an 'expat' license and an 'expat' package. <mark_weaver>sometimes we import with a license: prefix, sometimes with an l: prefix, sometimes we select a subset of bindings to import, sometimes we provide a list of bindings to _not_ import, etc. <sprang>hmm, so there's no agreed best practice at the moment? <mark_weaver>I may propose at some point that we just standardize on one method, which, if it were up to me, would be to use license: as the prefix <yenda>it doesn't make sense the first error is guix environment: warning: failed to load '(gnu packages aarddict)': <yenda>ERROR: Unbound variable: non-copyleft <yenda>there isn't even a non-copyleft variable in aarddict <yenda>I posted it at 4:30 it's the bpaste.net link <yenda>when I do guix environment guix <yenda>the error message was non-sensical <yenda>it was actually in xorg that copyleft was unbound <mark_weaver>at some point you might want to just install everything needed to compile guix in your profile <mark_weaver>it's a bit dicey to use 'guix environment guix' every time you want to recompile guix, and where the 'guix' used in that command is the one you have to recompile. <davexunit>I just remove the ~/.config/guix/latest symlink temporarily when I get myself into that situation <yenda>I guess I already have it because I just did it out of lazyness <yenda>so there is 3 lines to change (add an import and 2 licenses needing a prefix) for my patches <yenda>should I send a patch patch ? or rebase and resend the patches ? <mark_weaver>yenda: send complete patches, always, never patches on your patches. <mark_weaver>yenda: to avoid running tests, we prefer to put #:tests? #f in arguments, with a comment explaining why, rather than deleting the 'check' phase. <mark_weaver>yenda: I would prefer for perl-pod-simple's version to be "3.30-1" and to change the dash into an underscore in the 'uri' expression. <mark_weaver>which you can do like this: (string-join (string-split version #\\-) "_") <mark_weaver>other than these little nits, the patches look very good to me! <yenda>I deleted the check phase because there is no such phase <yenda>so it doesn't build if I don't remove it <mark_weaver>and then put a comment with something like: ; no test suite <yenda>how many spaces between the comment and the instruction ? <yenda>it's hard to keep 80 colums with addresses <mark_weaver>yenda: you can put the string on the next line, underneath 'home-page' <mark_weaver>similarly, in uri fields, you can put the first argument to 'string-append' on the next line, if needed <yenda>since I already have string-append I just cut the first part <mark_weaver>also, you can break the string into multiple strings if needed <yenda>Ok I hope I didn't miss anything this time <codemac>hey, still having problems with locales on archlinux with guix as package manager :/ <codemac>I did the LOCPATH=$HOME/.guix-profile/lib/locale , and installed glibc-utf8-locales, but when I type `locale` it prints the failure about not being able to set LC_ALL <codemac>anything that tries to reach out to stuff on my home system (my profile didn't have perl, etc) messes everything up <codemac>yeah, so any time you run a program *not* from your .guix-profile, you're gonna wanna unset LOCPATH <taylanub>codemac: BTW I believe glibc-locales is the correct package. glibc-utf8-locales is a minimal locales package needed for some things, not meant for users AFAIUI. might benefit from a rename because I had the same confusion. <taylanub>maybe it doesn't matter for English though <codemac>taylanub: not too bad for english so far - but yeah, I should probably switch <marcus_>hi all. i am interested in guixsd and noticed that it's quite emacs related. I am not an emacs user (yet), so is it suggested to use emacs in order to get the most out of it? <taylanub>marcus_: Emacs is recommended to get the most out of life ;P <alezost>marcus_: surely you can use guix commands without emacs <taylanub>I don't really use Emacs for anything guix-related specifically (e.g. the guix.el front-end), but for editing lisp/scheme code Emacs is very good. <taylanub>I'm sure there's also good lisp/scheme editing modes for Vim though. <DusXMT>the % key is definitely incredibly useful <DusXMT>alezost: On Vi-compatible editors, the `%' key switches the cursor over to the bracket/parenthesie that opens/closes the one you're at <alezost>ok, sorry, I thought it's something about emacs at first <marcus_>I think I am going to try to install guixsd on my libreboot laptop <marcus_>have to check how to boot grub correctly but I guess it should work <rekado_>re % key on vim: on Emacs I use paredit and the sexp movement commands (C-M-{a,e,u,d,f,b}, etc). I find these generic commands much more useful than %. <rekado_>it wraps the executables in a minimal PERL5LIB path, unlike the previous version of the patch. <rekado_>I'd also be happy for a comment on the r-build-system and cran-importer patches, as I have quite a few packages in the queue that depend on the r-build-system. <joaojotta>Would you guys say GuixSD is a good distribution for a person using GNU Linux for... 6 months? <taylanub>jalle: GuixSD is yet alpha software. I wouldn't recommend it to someone who wants a fully-working system without much hassle, especially if they're not an advanced user. <rekado_>joaojotta: this depends a lot on how this person uses the GNU system and how many of the required applications have already been packaged. <rekado_>it works fine for me as someone who mostly just uses Emacs and a browser, but I've been in situations where I would have liked a couple of applications that have not been packaged yet. <rekado_>also, on laptops power management events don't work out of the box and you end up hacking around this (or not, like me). <rekado_>e.g. for suspending the system I manually issue a command on a terminal. Same for networking when switching network devices and after waking up from suspend. <rekado_>(I haven't yet tried software to simplify networking) <rekado_>none of these things just work out of the box, so someone who is looking for a system that just works out of the box, anticipating all use cases, will probably be disappointed. <sbidin>Hi. I've gotten rid of slim and want to start X manually. I get a "failed to load module ati", "module does not exist" error. Same goes for vesa. Hopefully I'm missing something elementary? <sbidin>AFAICT I've installed the ati drivers. <sbidin>Another detail: I'm not running X as root. <iyzsong>sbidin: I don't think the X (from guix) will run under a normal user, but you could try launch it with '-modulepath', '-logfile' etc. <sbidin>iyzsong: It seems running X as root encounters the same problem: it cannot find neither ati nor vesa. The logs for both root and non-root runs are almost identical. <alezost>sbidin: yes, you need to run X server with -modulepath or -configdir, because by default X server will look for modules somewhere in /gnu/store <alezost>sbidin: btw you might have a problem with your ati card not related to xf86-video-ati driver: linux-libre kernel does not include proprietary blobs <sbidin>alezost, iyzsong: Setting -modulepath manually works. Thanks! <sbidin>alezost: I'll worry about that as soon as I get X to start. I have other errors now... :) <sbidin>I guess vesa should always work at least. <sbidin>What do I need to install to get the glx module? <alezost>sbidin: do you mean Xorg complains about glx module? <alezost>you probably set -modulepath to "~/.guix-profile/lib/xorg/modules/drivers", right? <yenda>Are there some mu4e users here who managed to use the git apply mbox action on a message ? <sbidin>alezost: Correct. And installing mesa didn't fix the issue. :) <alezost>sbidin: it should be "~/.guix-profile/lib/xorg/modules/" and glx should be detected as it is a part of Xorg and is placed in …/modules/extensions <sbidin>Ah, I see, I'll try that out now. <sbidin>It doesn't work. Actually, I don't even have an xorg/modules/extensions. <sbidin>There is no 'glx' in my profile anywhere. <alezost>sbidin: for me ~/.guix-profile/lib/xorg/modules/extensions is a symlink to /gnu/store/spz4w57kpd7zxma79xrca8x5ixic01bg-xorg-server-1.16.4/lib/xorg/modules/extensions <alezost>oh, wait, you didn't install X server in your profile <sbidin>alezost: You're right, somehow I didn't do that. /puzzled <sbidin>I thought if, say, xinit has xorg-server an input, this means installing xinit automatically pulls xorg-server as well. Both of them into my profile <alezost>it doesn't, only propagated-inputs are automatically installed <yenda>ACTION succeeded by modifying mu4e-view source directly and removing the .elc file so that it recompiles <joaojotta>rekado I guess I use the computer as most people in the world do it: internet browsing, a few Libre Office documents here and there and so. The "not so usual" would be Steam. I do have a nice library. <joaojotta>rekado_: I guess I use the computer as most people in the world do it: internet browsing, a few Libre Office documents here and there and so. The "not so usual" would be Steam. I do have a nice library. <joaojotta>Beeing a GNU distribution I would say Steam is not exactly a priority or even on the "to do" list. <DusXMT>joaojotta: I don't know whether steam will work on GuixSD; it might make assumptions that are completely wrong about the system, since it doesn't do many things as most distros do <joaojotta>DusXMT: I'm not an expert so I tend to look for a Debian/Ubuntu based distro. As far as I can look Guix is none of thoese so I guess isntalling Steam would not be an easy thing for me. Plus, again, Steam support (I think) would have to be community driven. <DusXMT>A lot of people keep recommending Trisquel, so I'll pass the word on. I haven't tried it myself, but it's supposedly a very nice experience, based on Ubuntu, and it's FSF approved. You can then install Guix as a package manager to mess around with lips-based package management <joaojotta>DusXMT: I look at GNU as a "NO PROPRIATERY SOFTWARE WHAT SO EVER" kind of thing. <DusXMT>You can run guix on a non-GuixSD distro as your secondary package manager, it doesn't clash with the system's one's, since everything's in /gnu/store and simlinks pointing to it <joaojotta>Hope I can run it smoothly enough on my old machine and install XFCE on to it. <rekado_>I second this suggestion. Guix as a package manager works very well. You do not need to use GuixSD to benefit from the package manager. <davexunit>most of us developers first used guix as a package manager on top of whatever distro we were using at the time. <joaojotta>And this, ladies and gentlemen, is why I love IRC and the Linux/GNU/OpenSoftware community! <joaojotta>I can now see, getting closer and closer, the day I put my MacBook Air on the shelf. <davexunit>I got comfortable enough with guix that I felt confident in moving to guixsd and dealing with any issues along the way. <yenda>here I am, logged in my session via slime after typing the wrong password <yenda>I actually just didn't type the last few char, I will reboot and try with a totally wrong one <sbidin>yenda: I had the same issue, as if slim didn't care about my last *two* characters. <sbidin>incidentally, using both 44 or $$ as my last two chracters worked <sbidin>I assumed I was insane and ignored it <sbidin>it's even worse than I though: the bug is there in sudo as well <sbidin>try doing "sudo touch bla" and enter the last two characters of your password incorrectly <sbidin>omitting the last two characters entirely works as well <sbidin>note: my password ends with two digits, maybe related <DusXMT>I remember having a similar problem on Linux From Scratch; only the first 8 characters were considered. Turned out that I had shadow configured to use DES to encrypt the passwords, which only makes use of the first 8 letters and ignores everything else <sbidin>Though I didn't configure anything, so it's all defaults. <sbidin>Since X is only usable when run as root, do I run it as a service via deco? <sbidin>And then use startx with another user? <sbidin>I'm used to just running startx as a non-root user, so not sure how I should go about splitting X to be run as root... <taylanub>X.Org can be run without being root, normally. is this different under GuixSD perhaps? <yenda>I'm concerned about this password issue nobody noticed it before ? <sbidin>taylanub: I think it used to be the case it can only run as root. I'll try it out as non-root now, perhaps it has changed. <sbidin>taylanub: I get a "failed to set IOPL for I/O (op not permitted)" error. <DusXMT>yenda: It should be an easy fix, one just needs to add ENCRYPT_METHOD SHA512 to etc/login.defs of the shadow package <alezost>AFAIK support for rootless X server was added recently and it requires systemd <DusXMT>That will make use of SHA512 instead of the obsolete DES <yenda>DusXMT: I don't know what the shadow package is <taylanub>specifically the one called "X". e.g. 'ls -l /usr/bin/X' -> "-rwsr-sr-x 1 root root 10104 Apr 1 2014 /usr/bin/X" on Debian <taylanub>yenda: traditional unix library handling password encryption <taylanub>alezost: when you say rootless do you mean without suid 0? <yenda>shouldn't it changed in guix itself ? <alezost>the store doesn't contain setuid programs, but they may be still used: (info "(guix) Setuid Programs") <davexunit>the FSF's ED gave GuixSD a nice plug at DebConf <taylanub>sbidin: in the Info link alezost provided, it explains how you can declare setuid programs. after you declare (string-append #$xorg-server "/bin/X") as one such, it should work I believe <sbidin>taylanub: Sorry, had to run. No, it's just 555, no setuid. <sbidin>alezost, taylanub: Thanks! I'll go ahead and try that out. <bavier>davexunit: thanks for the setns fix. the tests/containers.scm test gets skipped now on my machine. <mark_weaver>marcus_: I run GuixSD on my Libreboot X200, and before that on a Libreboot X60. The only thing to do is to make /boot/grub/libreboot_grub.cfg a symlink to /boot/grub/grub.cfg <mark_weaver>that links makes the default menu item in the default grub.cfg burned in flash do the right thing <mark_weaver>(and without it, you can still boot GuixSD but must choose one of the other options) ***nully__ is now known as nullyu
***nullyu is now known as nully
<mark_weaver>yenda, DusXMT: wow, that password thing is terrible. bah. nice default behavior in the upstream shadow package :-( <yenda>mark_weaver: were you aware of this 8 char max length for passwords ? <mark_weaver>yenda: no, of course not, if I had been it would have been fixed already <mark_weaver>and I'm really unhappy that in 2015 this is the default behavior of the upstream 'shadow' package. <sbidin>Okay, so I've specified xorg-server's /bin/Xorg to be setuid, but it's only set like that within /run/setuid-programs, where it has been placed as a separate copy. Utilities like startx still reference the non-setuid Xorg, so the thing still fails. <sbidin>Maybe xorg-server should be setuid by default? And then xinit can reference its /run/setuid-programs location. <DusXMT>mark_weaver: I think the upstream's point is backwards compatibility <DusXMT>but yeah, it's a terrible choice in my opinion as well <mark_weaver>DusXMT: no doubt true, but I'm still unhappy about it. <mark_weaver>sbidin: I don't know, setuid programs are always potential security holes, makes me nervous. <sbidin>Actually, now that Xorg is setuid, startx fails when -modulepath is used (it "cannot be used with elevated privileges"). <mark_weaver>sbidin: out of curiosity, why do you want to run X in this way? <DusXMT>mark_weaver: the main reason is stack smashing; once a cracker finds a way to log into your computer and gets access to a setuid program, and knows of a buffer overflow bug, they can inject shellcodes into it and very easily get a root shell <sbidin>mark_weaver: It's how I do it on other systems, but I suppose it won't work as easily here. How do you run it? <DusXMT>I'm an idiot, misread your message <sbidin>mark_weaver: Yeah, I deleted that. :) Ideally, I'd like to just run startx and have it fire up the interface. <sbidin>So should I have xorg-run as a service? <mark_weaver>sbidin: you can add xorg to your setuid-programs list easily enough. I don't think we should do it by default. <mark_weaver>I would accept patches that make this work "out of the box" except for the setuid bit. <mark_weaver>so then, users who want this can just add it to setuid-programs and then it will work. what do you think? <sbidin>Sounds good to me, but currently I don't know how to make it work. Setting Xorg setuid disables using -modulepath, so ~/.guix-profile/lib/xorg doesn't get used and X crashes. <sbidin>Sorry, I meant just run Xorg as a service, but I guess that's not doable? <sbidin>Or possibly doesn't even make sense. <yenda>I admit that I wouldn't mind getting rid of slim too <yenda>I usually just connect to my session in tty on non-guix machines <mark_weaver>sbidin: you need to create an xorg configuration file, and I'd guess (hope) that it must be owned as root for X to accept it. <mark_weaver>one consequence of launching X from a text console is that your screen lock will be ineffective, because anyone can just switch to your text console. unless there's some trick for that I don't know. <mark_weaver>and of course it means another setuid program on the system <mark_weaver>sbidin: we have code in gnu/services/xorg.scm to create an xorg configuration <sbidin>mark_weaver: Thanks! I'll give it a shot. <mark_weaver>sbidin: you should be able to build that configuration file with a command like: guix build -e '((@ (gnu services xorg) xorg-configuration-file))' <mark_weaver>and/or find hints there about what needs to be done to start X on GuixSD <bavier>I've noticed that when building without chroot, some packages will put libraries in $out/lib64 rather than $out/lib, which breaks some assumptions in other package recipes <bavier>would passing "--libdir=$out/lib" to configure by default be appropriate <mark_weaver>bavier: perhaps, but I think you'll probably find a great deal more breakage from building outside of a chroot, and I'm not sure it's worth fixing all of those things, since there are other options for you. <mark_weaver>I think a better method to persue is to run the builds within a VM. <mark_weaver>user mode linux might be a good choice for this use case, dunno. <davexunit>we should really look into using user namespaces if we want to properly support this use-case. <mark_weaver>maybe we can make this the default "out of the box" when running guix-daemon as non-root. <mark_weaver>davexunit: I agree that we should do that where we can, but that won't work for bavier because the kernel is way too old. <bavier>mark_weaver: I hadn't come across user mode linux before <bavier>mark_weaver: I'm not sure I understand what you mean by "out of the box" <mark_weaver>bavier: well, guix-daemon could perhaps automatically run itself within user mode linux when appropriate <bavier>I might poke around with that a bit <mark_weaver>bavier: btw, do you know if there's some reason why we don't have a native-search-path specification for GHC_LIBRARY_PATH ? <bavier>mark_weaver: because profile creation is supposed to handle all that, I think <bavier>so that ghc finds it in the user's directory under the default location <mark_weaver>sbidin found that he had to set that variable in order for ghc to find the libraries he added. <bavier>I think we also wanted to be able to handle different haskell compilers, so using a GHC-specific option wasn't ideal <mark_weaver>bavier: so, our ghc package looks in ~/.guix-profile/... by default for its libraries? <mark_weaver>and what happens if ghc is installed in the system profile, or in an alternate user profile? <sbidin>If it looks in .guix-profile by default, then I must have done something very wrong. I don't think I did, however: ghc-pkg didn't know about the .guix-profile repository by default. <bavier>mark_weaver, sbidin; in guix/profiles.scm the ghc-package-cache-file procedure creates a new "package cache" amalgamation package and then asks ghc-pkg to recache using the packages therein <bavier>I think this is enough to let ghc know about the location of installed ghc modules, though tbh I've not worked with ghc much outside of guix's haskell-build-system <mark_weaver>bavier: the GHC package cache is done as part of profile creation, within the build container, so it cannot change anything outside of ~/.guix-profile <mark_weaver>so if ghc doesn't look there by default, it can't have any effect. <mark_weaver>so then there need to be either an environment variable setting, or else a symlink from wherever ghc looks for it into ~/.guix-profile/ <mark_weaver>(more precisely, the ghc package cache creation cannot affect anything outside of the /gnu/store/* directory where the user profile is built, and .guix-profile is a symlink that leads there) <sbidin`>ghc looks into its /gnu/store/...-ghc/lib (the core libs) and into ~/.ghc/lib (where cabal places packages by default), where the latter is user-writeable. <sbidin`>so I don't think a symlink is an option? <mark_weaver>sbidin`: you could make ~/.ghc/lib a symlink into a subdirectory in ~/.guix-profile, I guess. that's what I meant. <mark_weaver>but the environment variable is the better way to go, I think, or at least the way we usually do things. <bavier>mark_weaver: that appears to be necessary atm, yes <sbidin`>mark_weaver: ~/.ghc/lib is expected to be user-writeable, but ~/.guix-profile's subdirs are not <sbidin`>so you couldn't do something like "cabal install bla" as a non-root user <bavier>OTOH, adding GHC_PACKAGE_PATH as a native search path for our ghc package is making more sense to me <bavier>even if it's not used directly by haskell-build-system <ennoausberlin>mark_weaver: Hello. I installed guix sd on an old eeepc. Works so far. I saw, that you tried guile-emacs. I experienced the same problem. Only -Q is working. And startup is very slow. Is this the normal behaviour?? <mark_weaver>how does haskell-build-system arrange for ghc to find its libraries? <bavier>mark_weaver: similarly to how the profile hook works, by creating a fresh package database from all visible haskell modules. <mark_weaver>I don't know why -Q is needed, but the slowness is because compilation is disabled. <mark_weaver>at some point we should be able to enable compilation, and that's really the way that guile-2 is meant to be run. <mark_weaver>obviously it's a work-in-progress, at a fairly early stage. <mark_weaver>bavier: and then how does it tell ghc where to find them? <bavier>mark_weaver: --package-db=<tmp-db-file> <yenda>why is compilation disabled ? <davexunit>a bunch of people consider guile-emacs to be dead for some reason. <davexunit>I guess because there haven't been commits in awhile. but it's definitely not dead. <yenda>it's just classic #emacs non-sense :D <ennoausberlin>mark_weaver: How many contributors work on guix? Looks like it gains a strong momentum at the moment. I am a scheme beginner, but heavy emacs user for years. I want to dig into scheme and guile-emacs was my starting point <yenda>I would have loved to do a gsoc on guile-emacs, sadly I'm not a student anymore next year <mark_weaver>bipt seems to mostly work on it in the summer when he's supported by google summer of code projects. <davexunit>yeah, would be good to have some more hackers come aboard. <mark_weaver>but it continues to make progress, and at some point I'm confident that it will be a clear win over the existing elisp implementation in emacs. <davexunit>ennoausberlin: our latest release had commits from 25 contributors <yenda>you need to be a student to do a gsoc right ? <davexunit>when I didn't know how to get started contributing to free software <davexunit>4 new contributors in the past month (as of august 4th) <davexunit>the contributor graph continues to increase at a nice pace <yenda>I think we would greatly improve that by having more "tutorially" documentation and some more automated tooling <yenda>improved linter for instance <ennoausberlin>yenda: My english is quite limited, but I will compile a german FAQ about problems I ran into using guix sd. Installation instrutions, too <mark_weaver>yenda: no doubt it could be improved; do you have a specific idea of how to improve it? <yenda>various tasks include : enforcing 1 interline rule between declarations <yenda>interactive lint of packages press (y/n) to validate change <yenda>add the 80 columns check to the linter <yenda>I would be intrested in doing such thing but the next few weeks my free time will be limited as I have to write a masterthesis <davexunit>I don't really like interactive processes. goes against automation. <yenda>mark_weaver: I think I will do an emacs mode rather than change the linter <davexunit>but yeah, checking for 80 columns or fewer would be nice. <mark_weaver>honestly, I think at this point our efforts would be better spent adding packages <mark_weaver>I don't think we could reduce the effort to add a package much more than it is now. <davexunit>that's true, it is significantly easier to write a guix package than any other distro i know of. <mark_weaver>the main complication that sometimes arises is adapting packages to cope with our non-standard filesystem layout <mark_weaver>but I don't see how that could be automated much beyond what we have <mark_weaver>determining the licensing on packages is sometimes a pain. it would be nice to have a tool to help with that <bavier>everyone would probably want a tool to help with that ;) <mark_weaver>and it would also be great to have automated checking for newer versions of non-GNU packages. <bavier>mark_weaver: I kinda got started on that recently <davexunit>I'm not sure how to solve that problem generally, but for sites like pypi.python.org and rubygems.org it can be easily done <davexunit>since they have an JSON interface we can query <mark_weaver>I would expect that some heuristics that get a directory listing from the directory of the current source tarball would cover a lot of cases <bavier>davexunit: yes, I was hoping we could make use of web APIs where possible. e.g. cpan, hackage, pypi, etc <mark_weaver>and then it would be nice to be able to specify a custom freshness-checking procedure on a per-package basis. <bavier>mark_weaver: the 'spack' package manager works like that <mark_weaver>I'd also like to add fingerprints of upstream tarball signing keys to our package descriptions <davexunit>I'm just going to say "that would be ____" to all of your ideas, I guess. ;) <davexunit>so with the signing keys we can verify not only the hash of the tarball, but that it is in fact the tarball that the maintainer uploaded originally, right? <mark_weaver>well, it would only need to be used when we update the hash <davexunit>would such a 'signing-key' field be part of the <origin> record? <mark_weaver>I guess that would probably make the most sense, but honestly I haven't thought it through. <mark_weaver>for now, even just having the fingerprint(s) as comments would useful. making it an actual field won't matter until we have some associated tools. <mark_weaver>I try to be careful, but in practice when I update a package, I can't reliably remember whether I've already got the signing key on my keyring, or which key it is that's supposed to be signing this package. <mark_weaver>so, if the key is not on my ring, I just fetch the key that made the signature from a keyserver. <mark_weaver>but this is bad because it means that in practice, I could be getting a signature from a bogus key <mark_weaver>this is a hard problem until we have a much more complete web of trust that extends to the developers of all the important software <mark_weaver>but for now, at least we can keep some institutional memory of what signing keys we've seen before for a package, so that if a new version is not signed by the same key as before, it at least warrants our attention. <mark_weaver>and so that it's in our git repo where others can check it and raise an alarm if it's not the right key. <mark_weaver>and ideally, those of us who go to free software conferences should take the opportunity to meet the developers of our software in person and verify their fingerprints in person, and make sure it matches what we have in our repo. <mark_weaver>and also verify from them what set of keys we should expect to sign a given package. <mark_weaver>(and I'll try not to think about the fact that the NSA is probably capable of getting a copy of the private signing keys of almost any developer they choose to target) <mark_weaver>our computers are essentially our mind extensions. the consequences of having almost all of our mind extensions under the direct control of central authorities is too terrible to accept. <davexunit>I wish more people would think of computers that way. <sbidin`>So, I'm trying to build the xorg-configuration-file. <sbidin`>guix build -e "((@ (gnu services xorg) xorg-configuration-file) #:drivers '() #:resolutions '() #:extra-config '())" <sbidin`>I get a "wrong number of arguments" error somewhere deep in gexp. <sbidin`>mark_weaver: Does that conf ever get built by some other means? I thought I might have already had it on disk, but I don't. <sbidin`>Because it contains module paths to every module needed, so if I just use that very same conf + the setuid Xorg I think I'm set. <mark_weaver>(run-with-store (open-connection) (xorg-configuration-file)) <mark_weaver>sorry, that's suboptimal, the $1 assumes that that's the result of the 'run-with-store' expression. <mark_weaver>hmm, that got into a strange loop for me, I may need to debug this. <sbidin`>I skipped the $1 thing (joined everything into single expr) and used build-derivation*s*, and it seems to have worked. <mark_weaver>also it was suboptimal to open two connections to guix-daemon. I should have bound the result of (open-connection) to a variable and use that in both places <mark_weaver>if civodul were here, he's probably be able to show a nicer way <sbidin`>The only way to give Xorg a config at an absolute path is if you're root. If I run a setuid Xorg, it just tells me I have "elevated privileges", which isn't the same as being root. <sbidin`>And since a setuid Xorg is always in /run/setuid-programs, that would mean the conf would have to be there as well. <mark_weaver>a setuid xorg-server needs to make sure that it's using a configuration file that root intended to be one. <mark_weaver>I mean: a setuid xorg-server needs to make sure that it's using the configuration file that root intended. <mark_weaver>so, I think the only way to make this work is for the setuid xorg-server to expect its configuration file in a fixed place in /etc/ <mark_weaver>and that probably means modifying the xorg-server package which will entail rebuilding almost everything graphical. <mark_weaver>although you could make a modified xorg-server package <mark_weaver>i.e. a different one from the one that the other packages are built using. <mark_weaver>I guess you feel really strongly about running startx instead of using a display manager? <sbidin`>What if someone wanted to edit their xserver.conf within guixsd? It's not really allowed? <mark_weaver>again, I'm curious about your reasons for this. it seems inferior to me in many respects. <sbidin`>mark_weaver: Ah, by now it's inertia. Victory is close at hand. <mark_weaver>sbidin`: it's possible to override the xorg configuration file from the OS configuration. <mark_weaver>by passing a #:startx keyword argument to slim-service <mark_weaver>sbidin`: the thing is, by having the X configuration in a single mutable location, you lose roll-back support for that aspect of the system <alezost>sbidin`: I start X server "manually", I mean with a help of dmd <mark_weaver>so, (1) you will have an additional setuid program on your system, (2) your screen lock will be useless because anyone can just switch to the text console that you ran startx from, (3) your X configuration will not be in the store, so no roll-back support <alezost>sbidin`: I don't use setuid, instead I use sudo without password (which is allowed in my sudoers) <sbidin`>mark_weaver: I understand, it's an inferior choice within the context of guixsd <sbidin`>alezost: Ah, that's going too far for me. :) <sbidin`>I think that, for the moment, I'm giving up and enabling slim again. <alezost>I mean only "sudo X" without password, not any sudo command <sbidin`>alezost: How do you use dmd to do that? <sbidin`>And I assume you don't care much about X conf roll-back support. <alezost>what do you mean by "X conf roll-back support"? <alezost>oh, I get it. No, I absolutely don't care about it <sbidin`>Thanks for the config link, I'll have a look and probably steal parts. :) <alezost>sure! (I'm not sure if it is suitable for anyone but me though) <sbidin-borked>I'll fix this by reapplying grub, but am wondering if anyone knows of any clues as to why this happened. <davexunit>sbidin-borked: just boot the previous system config <sbidin-borked>davexunit: You mean from the grub menu? The error occurs before I get to that point. <sbidin-borked>davexunit: It's okay, my hope is running grub again will fix things. <lfam>If I want to mirror my guix development repo remotely, is it okay to gitignore test-tmp? <sbidin>Reinstalling grub fixed the issue. Not sure why it broke. <sbidin>I'm making an xmonad package and want it to provide a .desktop file. Could I embed the entire desktop file within the package definition? It's about seven short lines. <davexunit>sbidin: well, we normally try to minimize the changes we make to the upstream software, but this case sounds harmless. though, you could also propose adding a desktop file to the upstream maintainers. <davexunit>what reason is there for having a .desktop file for a window manager? <sbidin>It's not meant to, say, complement xfce, but rather to be run by itself. <sbidin>Now you have me worried. Let me check... <sbidin>"SLiM automatically looks for session types described by the .desktop files in /run/current-system/profile/share/xsessions and allows users to choose a session from the log-in screen using F1." <sbidin>Ideally, you'd install xmonad and have it available automagically. <davexunit>so I guess for our distro we'd want that file <davexunit>so writing that text to a file in the build script is probably fine. <sbidin>Ok. I just found how the ratpoison package does it: it fetches the file from gentoo's servers. Not sure if that's worth mimicking (but they do have an xmonad.desktop available). <sbidin>BTW, slim has been abandoned? Homepage is down and last commit is 2 years old. <davexunit>we use slim right now because it was the easiest display manager to get working <davexunit>I imagine we'll move on when a better one is packaged <davexunit>when we have gnome packages available, our default desktop will surely be gnome. <sbidin>I've actually grown rather fond of windowmaker(?). <yenda>maybe there is no more commits to it because the work is done <yenda>what more could a simple login manager do besides login you ? if there is no bug <sbidin>yenda: how about not resetting the session choice after entering the wrong password? :P <yenda>maybe it has never been reported ? <yenda>if you have "exec your-wm" in your bashrc it doesn't happen <sbidin>one more: it doesn't seem to respect the chosen keyboard layout (while both the console and xfce at the same time do) <yenda>ACTION check if mark is here <sbidin>(maybe this is a guixsd issue, okay :)) <yenda>ACTION about to link to github <yenda>sbidin (services (cons* (console-keymap-service "fr") <sbidin>yenda: yep, I'm using "croat" there, and it works fine for the console <sbidin>but not when entering text in slim <yenda>setxkbmap -layout fr -option grp:ctrl:swapcaps <sbidin>that I used to have in my .xinitrc, but I see your point: I'll add that <sbidin>okay, so it's not slim's fault ;) <sbidin>I'm basically assuming it will, but haven't checked yet. Will let you know. <sbidin>(Don't want to log out right now.) <sbidin>yenda: Yeah, it doesn't work. :) <sbidin>I think the .xsession only gets run when it's picked via slim. <sbidin>Anyway, after I defined .xsession, slim refuses to log me in. <sbidin>Gives me a short error message I forgot how it goes. <yenda>,sneek I have also exec i3 in .xsession ***sbidin is now known as Guest36765
<yenda>Guest36765: i use exec i3 as the last line of .xsession <Guest36765>yenda: Did you have to remove wmaker for this to work? <Guest36765>it doesn't seem to me that .xsession ever gets run <yenda>then use this, that's what probably gives me the right keymap in slim <Guest36765>for the moment i'm actually more interested in how exactly you run i3. so you have no xinitrc, just an xsession with "exec i3" as the last line. ***Guest36765 is now known as sbidin`
<sbidin`>no, I'm trying xmonad, but it should be the same thing <yenda>well I think you are right xsession is probably not run at all <yenda>So it's just the conf file for x11 that set the keymap and I assume i3 has a desktop file <sbidin`>i'll have a look at your gith-- repository :ahem: <yenda>puting i3.scm in your GUIX_PACKAGE_PATH should be enough before it's merged <ennoausberlin>Hello. I wonder, if it is possible to install guix sd in a Parallels Virtual Maschine on OS X <DusXMT>ennoausberlin: It's very possible; attach the USB image as a second hard drive, try booting from it, and see what happens <ennoausberlin>DusXMT: Yesterday I ran into some efi bios menu. But I made a mistake perhaps. I will try your suggestion tomorrow. Thanks. BTW: Great community here