<lfam>All that and vdirsyncer doesn't even build a proper manpage. It doesn't even mention the comand-line options. <fps>what does the display manager tell me exactly when it mentions "failed to execute login program"? <fps>or whatever it flashes for a few seconds before failing to log me into bspwm ;) <lfam>Do you get to the login manager? Or does the login manager fail to load? I don't use one so I'm not sure how it works. <fps>what's a login manager? there's a display manager running though <lfam>Yeah, that's what I meant. Or something like it. Never used on <fps>hmm, how do you start your x-sessoin though. there's no "startx" :) <lfam>I'm on Debian and I use startx <fps>i could happily live without slim :) i wonder how to disable it and how to run x manually on guixsd <lfam>Did you search the ML and IRC logs? People have asked about similar issues before but I didn't read them closely because I don't use GuixSD or use a DE <fps>there's a slim.log in /var/log though. will take a look <fps>oh, it's superuninformative :) <lfam>I'm sure some other GuixSD users are using DEs <fps>i guess i can alist-delete slim from %desktop-services <fps>but i need mah tiling :) <fps>and xmonad is broken <fps>naah, too many titlebars <fps>more than one pixel is too much per border <Digit>xmonad with my config preferred, then scrotwm/spectrwm second place preference. <lfam>Sounds like you have some work to do, then! <fps>ok, i disabled slim :) <fps>let's see if i can get x to start manually and read e.g. .xinitrc <fps>ok, funky. the xorg service creates a little scheme program :) <fps>oh, there's an xinit package. ok <fps>Digit: both not packaged :( <fps>startx complains about not finding X ;) <fps>maybe i should read a book instead.. <Digit>i've been reading little bits of the guix manual. it's a good read. ;) i'm probably too sleepy though. will look at my first rough package definition creation when more awake tmro. <fps>Digit: jump right in :) <fps>found some irc logs from august <fps>starting x seems non trivial :) <fps>except for maybe some scheme magic. let's see <fps>xfce it is for now :( <lfam>How should I include log excerpts in bug reports? I see everyone else has the "--8<------------cut here[...]" thing. What tool creates that output? <fps>i wanted to try the --rounds=3 options for guix build.. <fps>but it's not there.. <fps>in my git clone after a git pull, a make -j8 and a ./pre-inst-env --rounds=3 redshift <fps>uh, probably my bad, i thought i had rebased, but it seems i didn't <fps>fps@cherry ~/src/guix/guix [env]$ ./pre-inst-env guix build --rounds=3 redshift <fps>/gnu/store/kpkz4vfqqg7snp8d2vkkv29igb9cfzl1-redshift-1.10 <fps>how can i force a rebuild anyways? <lfam>fps: If it doesn't rebuild, then nothing changed <fps>lfam: nothing in the derivation failed <fps>the package might have changed.. <fps>and even if it didn't change, i want to run a few rounds <Digit>g'mornin. *continues his investagations into packaging before breakfast* <fps>Digit: what are ya packaging? <Digit>i have a rudimentary beginning for cdrkit, based off the hello world in the docs. <fps>good. i was gonna suggest starting of hello, too <Digit>i still have much reading and sprucing up to do <fps>it cdrkit doesn't build yet? <Digit>i hadnt gotten that far before sleep <alezost>lfam: those "--8<------------cut here[...]" things are created by emacs: when you "M-x compose-mail" ("C-x m" by default), you can select a region and press "C-c M-m" on it <civodul>there was a problem in the setup before that prevented the cron job from doing its job <fps>yay, i'll have a new soul crushing android app dev job for a month or two which will pay some bills.. gain moneyz, lose soul. awesome.. <fps>civodul: good job. sorry for never advancing any with the js based hiding of packages with no issues at all ;) <fps>so much to do, so little time <civodul>we all know that feeling, i guess :-) <fps>once i'm done with that horrible horrible job i'll take half of the money to build my first 9 string electric headless ergonomic guitar <fps>the world needs those much more than pointless android app for big business wigs <Digit>er, replicant even. whatever the freedom respecting android thing is. <fps>did i mention corporate big wigs? <fps>they can choose to have it. they chose not to :) <Digit>"a choice made under duress is no choice at all, is it?" G'Kar <fps>good point. it applies to large parts of labour markets in general <fps>brb, gotta go get breakfast and another ssd <amz3>Regarding the issues I have, I think my box is broken. IIUC an automatic update was stopped in the middle of its work and now I can't use the latest kernel for instance <fps>amz3: on a guixsd system? <amz3>I must setup a dual boot or something, has anyone done this? <fps>dual boot is a pain :) <fps>much less work is installing a base system and then virtualize things <fps>only drawback is lack of multimonitor support :( <amz3>fps: thanks for the hint, I'll try it <fps>do you have a reasonably powerful box? <fps>for my current setup i'll move to an ubuntu base and virtualbox all the things i need <fps>sorry, guixsd, you won't touch bare metal for a couple of months ;) <fps>hmm, maybe on the laptop ;) <amz3>it will work, I only need a console <amz3>but switching is not ideal <amz3>my desk is no big enough for both keyboard <Digit>there are ways to use one keyboard across multiple machines... i forget the name... synergy? <anonymiss>or kvm or what it was, the physical device. if that's an option <anonymiss>or just an laptop holder thing. i would need some of those if i had nit enough desk space <anonymiss>or did i mean kmv switch ? i forget what those are called <alezost>amz3: I use dual boot; although I use GuixSD almost all the time (the second OS is "ArchLinux") <amz3>alezost: did you configure the dualboot in guixsd? <alezost>amz3: I just use my own grub.cfg, and always do "guix system --no-grub ..." <civodul>sneek: later tell alezost it would be good to see if anything's missing in our GRUB support that prevents you from using it and specifying the other OS to boot <efraim>debian uses an in-distro script called os-prober as part of updating grub <civodul>i think my laptop's SSD is 100x faster than hydra's hard disk <civodul>i'm running a gcc build, a gc, and a backup at the same time <civodul>and the thing remains just as reactive as when it's idle <roelj>civodul: What SSD do you have? <anonymiss>Are there plans to get grsec features into guixsd? i know the linux-libre kernel can get patched with grsec because i stsrted using the hardened-gentoo with deblob (libre) set on gentoo, but i imagine it to be, if doable, a long project and one i don't feel ready for contributing atm <civodul>roelj: dunno, just a "standard" 3-year old SSD, nothing fancy <civodul>roelj: could you try with --verbose? <civodul>anonymiss: i don't know exactly how difficult that is, but i'd be interested in it <roelj>civodul: Ok, well, I have a 3-year old Intel SSD, so I am looking around a bit for the day this one might fail. <anonymiss>civodul that would be a thing once i feel i understand more about guix and guile in general. <roelj>civodul: I ran 'guix pull --verbose' but it doesn't show any other output than just 'guix pull'. <roelj>civodul: (other than a different temporary path) <amz3>I'm trying to run a vm on top another distro using guix, with the following command `guix system vm gnu/system/examples/bare-bones.tmpl' <amz3>I get a KVM permission denied. I installed libvird and rebooted my box <amz3>which user is running qemu? the builder? <davexunit>ACTION thinks we should bail on lsh as default ssh service <bavier>amz3: the user runs qemu when it executes the script produced by `guix system vm` <bavier>amz3: do you have kvm enabled on your system? <amz3>kvm-ok command output is correct <rekado>is the kvm device owned by a group that includes your user account? <bavier>amz3: oh, I see, the failure is during the vm build. <bavier>sorry, I didn't look at your paste at first <bavier>so the build users will need to have access to the kvm device too <amz3>I added all guixbuilder0x users to kvm and libvirtd group <amz3>libvirtd group was not enough... <davexunit>so, here's a potentially crazy idea that I want to run past you folks: <davexunit>starting from a store item closure, find and replace all store item references to use non-absolute paths and provide a wrapper script to setup the necessary environment variables to make it work. <davexunit>there's a cool thing going down in January called the "Lisp Game Jam", and I'd like to use my game engine and provide binaries for those that just want to try my game without going through all the manual compilation. <davexunit>I can easily make a guix package for the game. <davexunit>but making a binary tarball that someone could just unpack in an arbitrary directory as an unprivileged user and run is an interesting challenge <avoine>that would be like a portable version of a guix environment? <davexunit>the idea is to ship someone a binary that will run even if they don't have guix. <lfam>That would change the whole game <bavier>davexunit: `guix environment --export` or such <davexunit>the binaries will be big, since it will be the full closure, complete with libc <lfam>Bonus points if you can `guix import` the closure into a Guix system later on <lfam>Yes, and I'm suggesting that continue to be true for your new super-closures <rekado>but not the rewritten thing with non-absolute paths. <lfam>Of course it wouldn't work. You haven't done it yet ;) <davexunit>this is a one-way road. take something out of guix, and mangle it to work without it <davexunit>I'm not sure how much trouble I'd get in if I simply grovelled for "/gnu/store" and replaced it with... something else? <bavier>you'd probably need to maintain the string length <avoine>davexunit: btw I really liked your idea for a "cd /tmp && tar xf $(guix build -S gparted) && cd gparted-XXX && guix environment --container gparted" command <civodul>davexunit: patching arbitrary files (notably ELF binaries) is unlikely to work <davexunit>yeah, this idea seems to just be a pipe dream. <civodul>if you want to provide binaries, you could use the same strategy as for the guix-binary tarball though <civodul>the only potential downside is that people would have to install it as /gnu/store <civodul>you could do that, *and* provide a program that uses a user name space <fps>ubuntu sucks so hard.. 5 minutes after installation the package manager has screwed up :) <fps>and i'm in the middle of a failed install <davexunit>maybe a new mount and user namespace would be enough to bind-mount to /gnu/store <davexunit>while still exposing the rest of the file system <amz3>How can I make the /gnu/store rw to be able to do `guix environment guile' inside the vm? <amz3>hm, so I can't use guix env inside the vm? <davexunit>if you want to mutate things, you'll need to use 'guix system vm-image' <davexunit>amz3: there's talks about how to make that work by using an overlayf <davexunit>the vm is ephemeral, so you'd lose it all after it shuts down <fps>got it sorted out, but only because i know .deb a little. maaaan. guixsd, i love you.. :) you're alpha but already work much more reliable!! :) <davexunit>the reliability is there, just need the convenience! <davexunit>if substitutes were fast to download, I could recommend guixsd to more people who are skeptical but could be swayed if the experience was a bit better <rekado>on GuixSD Emacs indents modify-phases stuff correctly, but in my Fedora Emacs on my workstation in the office it does not. <rekado>it also doesn't highlight "lambda*". <rekado>what do I need to do to fix this? <rekado>I thought the .dir-locals.el would take care of this. <Digit>hey fellow dmenu users, does your dmenu "just work" in guix, or need some extra trick to get it to show new package's exectuables? <civodul>rekado: these things come from the Guix Emacs modes <civodul>maybe they're not loaded on your machine? <fps>Digit: hmm, i think it should just work.. the new profile's bin directory is in $PATH i suppose, so it should just work <fps>Digit: unless dmenu tries to be smart.. <fps>and i think it worked for me after installing e.g. redshift <lfam>I have to apologize for the state of the bug report I filed on python-urwid (22137). In Mutt, the attachment is rendered as the body of the message but it looks like in other places it is just an attachment on an empty message. <lfam>Yeah, I know. But it looks like spam! <lfam>Maybe we can also figure out the bug <lfam>the python-tzlocal hompage (github) says it should work on "Any unix-like system with a /etc/localtime or /usr/local/etc/localtime". <civodul>lfam: you could add tzdata as an input and then set 'TZDIR' accordingly <lfam>I wonder if anyone is using the program "jrnl"? AFAICT that is the only user of python-tzlocal. <lfam>civodul: Thanks, I will try that <lfam>I suppose that given the nature of jrnl, the users may not want to declare themselves ;) <civodul>lfam: grep the tree, there's a couple of examples of doing what i suggested, i think <bavier>lfam: I use jrnl occasionally. I packaged it actually. <lfam>Yes I noticed :) Some people are private about their journals. Have you noticed any problems related to time zones? <alezost>rekado: lambda* is highlighted by Geiser 0.8; modify-phases is indented/highlighted by `guix-devel-mode' <sneek>alezost, you have 1 message. <sneek>alezost, civodul says: it would be good to see if anything's missing in our GRUB support that prevents you from using it and specifying the other OS to boot <alezost>sneek: later tell civodul: about grub and dual boot: I don't really know, I didn't try the default GuixSD way of using grub because I don't like that it reinstalls grub after each system reconfiguring <shao>I have a question, why can't I compile with `$ gcc hello.c` ? <lfam>That command won't work with the "$" in as $0 <shao>sure, I try it and the error says it can't find 'gas' <mark_weaver>gcc-toolchain includes 'gcc', 'binutils', 'glibc', and also something called 'ld-wrapper' which is needed to add the necessary rpaths so that the shared libraries can be found in their non-standard places. <shao>is there a point in keeping the 'gcc' package? <mark_weaver>sure, it's used to build almost everything in guix :) <mark_weaver>and it's not always the case that you want something like 'ld-wrapper' to automatically add those rpaths for you. <shao>ah okay. yeah now I remember reading something about using a chroot thing <Digit>i still have much docs to read to understanding, but time to stop [(for a break too)] n ask for pointers... how far away am i with this so far? first guix packaging attempt (first any packaging attempt), cdrkit http://dpaste.com/2NHVM84 am i even close? <davexunit>Digit: provided the build system doesn't need much massaging, it looks like you're on the right track! <fhmgufs>At the moment I'm building guix again (After I did a binary installation, I wanted to build it myself now. Is it normal, that it takes so long to build (or whatever it's doing) the package definitions (GUILEC: gnu/packages/*.go)? <lfam>fhmgufs: The first time will probably take a little while. Subsequent runs will only need to recompile the updated modules so it will go faster. <mark_weaver>fhmgufs: yes, it's normal. btw, make sure to pass --localstatedir=/var to configure when building guix from source code. <fhmgufs>Ok thanks. Now it's at the letter 'O'. <fhmgufs>Why do I need #:prefix license: if I use the module guix licenses? <fhmgufs>I read it in some package definitions. <lfam>fhmgufs: Sometimes the names of the licenses collide with other modules names. For example, OpenSSL <fhmgufs>Should I use this also, if this is not the case? <lfam>Probably not, because then you'd have to make a bunch of changes to all the packages in the module, and also where you import the license module itself. <roelj>Is there a make target to generate a PDF from the Guix docs? <roelj>Oh, I see.. simply running texi2pdf guix.texi from the doc directory works. <fhmgufs>If a package has multiple licenses, can I make a list of them in the definition? <bavier>fhmgufs: is it a "this *and* this" or "this *or* this" license? <fhmgufs>library = lgpl2+; there is a program included with gpl3+ <bavier>fhmgufs: in that case, yes, list the two licenses, and include a comment in the package definition explaining the situation <bavier>fhmgufs: look at other packages for examples <bavier>fhmgufs: does the iconv in glibc not work for your package? <fhmgufs>the package INSTALL file says that libiconv is required. <bavier>fhmgufs: libxcb might be what you're looking for ***ttuegel_ is now known as ttuegel
<fps>i added a new user to a machine <fps>and when he ran emacs [it's installed in the system profile] he couldn't start the guix repl <fps>then he did guix package -i emacs <fps>then it worked for him <fps>but it stopped working for me ;) <fps>might this be the first true multiuser guixsd installation? <fps>and now i try to guix package -i emacs as my own user <fps>but hydra takes too long ;) <amz3>if emacs is already installed on the machine, you don't need to download it again except if it's an update <fps>amz3: actually i was wrong <fps>it's just that either him XOR me can start the guix repl <amz3>I don't know about the guix repl? is it an emacs thing? <fps>yeeah, in guixsd emacs can be used to inspect packages <fps>but it seems it's limited to a single user :) <mark_weaver>I don't see how your setup could have been broken by another user changing his profile. <fps>Starting Guix REPL ... [2 times] <fps>error in process sentinel: sleep-for: Text is read-only <fps>error in process sentinel: Text is read-only <fps>geiser-repl--wait-for-prompt: No prompt found! <fps>no, it's not about changing the profile <fps>i was wrong about that <fps>it's just that no two users can have emacs open _and_ the guix repl started <fps>should be easy to reproduce <fps>start emacs for both <fps>and try guix-edit for both <alezost>fps: by default Guix repl is started as a server, so the second one is trying to be started on the same port. You can either (setq guix-use-guile-server nil) or change `guix-default-port' to another value for the second instance <alezost>fps: also look at the top commentary at "M-x find-library guix-backend" <fps>there must be a good reason for this ;) <alezost>yes, there is, it is explained in the commentary of "guix-backend.el" <alezost>fps: using (setq guix-use-guile-server nil) should work for you <civodul>alezost: re grub, you mean you don't like that it reruns 'grub-install' every time? <alezost>civodul: yes, also I just don't like to rely on a generated grub.cfg; it is too important for me to allow anything/anyone but me to touch it :-) <civodul>has anyone seen the "some font thing failed" message in Evince? <cehteh>mhm what if, with each change in in store a .torrent is generated along and served by some bittorrent daemon *thinking* <avoine>alezost: I'm having this concern too, maybe we could add a file importer that create the code to override the file with our own during the build/reconfigure phases? <civodul>by using your own, you most likely lose the ability to roll back, which seems a pity <civodul>we should find a better solution IMO <alezost>civodul: I can rollback with a bit of manual work: I have an entry in my grub.cfg with some system generation number, so if I want to switch to a previous generation, I just edit this number directly in grub, and boot to it <alezost>avoine: I'm happy with my current solution, I don't search for another option <fps>cehteh: i thought about the same thing.. davexunit or mark_weaver mentioned "it's not that simple" (paraphrased) <alezost>avoine: I don't mean it's a bad idea, I just don't need anything else; but if you want another solution, push civodul harder :-) <fps>cehteh: the more a package is installed the bigger the swarm for it is, the more it gets served.. <fps>cehteh: assuming you talk about serving substitutes <cehteh>sounds like a low hanging fruit to me, but i havent carefuly investigated that yet <cehteh>has the store some guile api? where one can hook when ever things gets added or removed? <fps>cehteh: i wondered about the same thing? <fps>btw: i have the build machine back, i'll guix pull and start another round of builds :) <civodul>cehteh: currently there's no simple way to be notified of new store items, but you could write a program that generates .torrent files for each store item, that's rather simple <fps>isn't there a protocol that asks the substitute server for a derivation result? <fps>instead of handing out the archive the server could hand out the .torrent file <cehteh>civodul: in think it would be nice to have a consistent store api where one can hook in <cehteh>anyway was just an idea .. i think it would be really cool when it works <cehteh>then any fetch tries bittorrent first <cehteh>further it may need some more work to paralellize fetches .. <cehteh>but ok i think more about it and may play with it <fps>hostname will change, but it might speed up some downloads already for some packages.. <fps>btw; is there a operating-system stanza to add a list of substitute urls? <wingo>so i have a dovecot service! <fps>civodul: oh ok.. right.. thanks :) <fps>civodul: eh ok, even simpler :) thanks for the patience with the non-doc-reading crowd ;) <wingo>how should i generate .pem files for dovecot <wingo>i think they generate a default .pem using openssl or so <davexunit>wingo: how about doing that during activation time? <wingo>davexunit: like, if there is no .pem file, generate one? that would be ok <wingo>so dovecot depends on openssl, so openssl should be built <wingo>but i don't know that the openssl that dovecot depends on is the same one from (gnu packages openssl) or whatever <wingo>it's interesting, because it's the *service* that needs to depend on the openssl *package* at openssl run-time <wingo>are g-exps sufficient to encode this dependency? <wingo>so #$openssl will dtrt, neat <davexunit>#~(system* (string-append #$openssl "/bin/openssl") "--generate-the-key") <wingo>we don't currently have other packages that generate tls certs afaiu <fps>does this have any chance of succeeding? [unsure because of the sudo]: fps@raksha ~/guix [env]$ sudo ./pre-inst-env guix system reconfigure /home/fps/guix-config/guix-config.scm <wingo>fps: that's exactly what i do fwiw <davexunit>fps: yes, because ./pre-inst-env will ensure the env vars are setup correctly <fps>wingo: ok. i'll give it a shot :) <fps>i guess i can leave the guix build environment first, but that shouldn't hurt either, right? <wingo>davexunit: is /etc the right place for the .pem? would an administrator be able to update the .pem in place or would they have to use the guix configuration mechanism, and if they had to use guix would it be ok? <wingo>i could put it in /var if that were the right thing <davexunit>wingo: for state like that, I think /var/lib might be better. <davexunit>to replace it they could use whatever they wanted, because this is stateful stuff that guix itself doesn't manage. <wingo>davexunit: you assume an administrator would like to manage this file outside of guix <davexunit>I see the service layer as the transition point between the stateless and the stateful. <wingo>the .pem file could be specified in the os-config <wingo>you have more experience here than i do :) <davexunit>the problem of secrets management is something I'm dealing with at work, where we use Chef, as well as with Guix. <wingo>ACTION reads a little about how nix does this <wingo>has the config looking into /root/ for the certs <wingo>which makes probably more sense than /var/lib, tho dunno <davexunit>I don't know where a dovecot user would expect this stuff to be <civodul>i guess secrets could be managed out-of-band and stored in /etc or whatever <davexunit>I'm still looking for a good tool that can handle secrets automatically <davexunit>placing credentials on servers by hand doesn't scale <civodul>were you able to come up with a user-file-service, BTW? <davexunit>there's a few implementation details that I'm unsure about <davexunit>do I recursively create the directory for a file? if so, who owns those directories? <davexunit>the simplest thing would be to do nothing and have the service fail if the needed directories aren't available <civodul>at least until we feel the need for something more fancy <civodul>anyway, that's going to be very useful <fps>hmmn, python's testcases fetch stuff from the net? <fps>[369/390] test_codecmaps_hk <fps>isn't that like supernondeterministic? <fps>python-3.4.3-minimal or something <davexunit>because, like you said, its supernondeterministic <fps>oh, i wonder about another thing <fps>let's say you have a derivation's input change <fps>but the derivation itself is invariant under this change <fps>will it be rebuilt nonetheless? <fps>and transitively all derivations that have it as input? <fps>e.g. libfoo depends on libbar, a function in libbar changes, but the change has no influence on the bits of libfoo <fps>two questions: a] is that the case and b] how often might this happen? <bavier>fps: a derivation's inputs cannot change without the derivation itself changing <fps>bavier: the bits of the derivation results might not change though? <fps>or is it always the case that those change, too? <fps>cause the hash of the input goes into the result? <fps>deliberately? cause this looks like an opportunity to safe cycles/diskspace <davexunit>there's no way to know that the change made is inconsequential <fps>well, you could diff the derivation result.. <fps>but the transitivity would be broken <fps>foo depends on bar depends on baz <davexunit>the derivation result will be different, always. <fps>baz changes, but bar doesn't <fps>so it's a design choice.. <fps>this is circular reasoning though, it is like it is because it is like it is :) <fps>yes, please elaborate <davexunit>if changing an input doesn't change the derivations hash, what good is guix? <davexunit>it's *extremely* unlikely that changing an input will yield the same result. <davexunit>and the inputs are a *very* important part of the store item's hash. <davexunit>along with the name, version, platform, and source code <fps>well one could have two hashes.. <bavier>even if the results are identical, the new derivation's store location is different <fps>it being extremely unlikely is a decent reason <fps>i'll have to ponder it a bit more <fps>which is cool. real learning is discovering, albeit guided <davexunit>for a potential optimization technique, see what the manual has to say about "grafts" <fps>ok, i wondered what that term referred to anyways when i saw it in some manpage