<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.
<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
<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.
<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.
<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 :)
<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'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
<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.
<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
<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
<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
<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.
<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>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?
<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>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.
<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 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?
<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 ?
<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.
<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-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>"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.