<taylanub>So is DMD our init system ? Sure neat that it's written in Guile but I wonder if it would be more sane to go with OpenRC or so to be somewhat similar to other distros (not that there are many who use OpenRC yet but it seems to be "the better systemd", for some values of "better"). <Arne`>wish: Add to the manual: “You can normally setuid root for nix-setuid-helper by executing as root: `chmod +s /usr/local/libexec/nix-setuid-helper`” (section 2.2 of the guide, before the last paragraph). <Arne`>wish2: also 2.2 of the manual: /etc/nix-setuid.conf: Are the two words separated by a space or by a linebreak? <Arne`>$ guix-daemon --build-users-group=guix-builder <Arne`>error: creating directory `/usr/local/var': Permission denied <Arne`>(as unpriviledged user, I did not run guix-daemon as root before that) <Steap>the daemon should be run as root <Arne`>I’m now doing that, but the documentation says that this is not needed. <Steap>it's highly recommended though, because otherwise guix cannot use chroot <Arne`>the documentation said, nix-setuid-helper could fix that. <Arne`>Are there plans to make the package list more readable? guile package -A lists 445 packages without categories. If I now search for a game, how do I find it? <Arne`>Besides: The resilience against a power outage named in the GHM talk would already have saved me 3 days of work when my son found the power-button while I was updating my gentoo-box… <Arne`>guix installed wordnet (successfully), but to run it, I need to use /nix/store/ah5kxzx3wm1w9w6l6nq8ri681pnajirw-user-environment/./bin/wn. What am I missing? <Steap>you can use a regexp with -A, or use grep <Steap>you can use the symlink in ~/.guix-profile/bin <Steap>which I suggest you add to $PATH :) <Arne`>ah, nice! I did not see that in the manual. <Arne`>I had thought, that this would be listed by `guix package --search-paths` <Arne`>(that does not return anything here) <Arne`>For me, simple categories for packages would win out (I have that in Gentoo, and they are much easier to work with than i.e. packages in Debian) <Arne`>games-text/grue-hunter ← also allows nice filesystem optimizations like only checking the games directory when looking for games. <Arne`>Can I kill the guix-daemon with a simple command? Like guix-daemon --kill? <Steap>I think you can just ^C the daemon :) <Steap>yeah, it'd be nice to have tags, but well, it's not a top priority <Steap>We care more about adding packages, porting to other architectures... <youlysses>taylanub: What does OpenRC offer that is substantially better, or some-factor of "unreachable" in Dmd? *youlysses really needs to start packaging, but finds it so-hard to do -- when he has said software already setup on my host-box. That desperation to get his stuff working in an environment such-that his usual software stack is not-present -- Is what will really get him packaging some stuff. <youlysses>Have to maintain that 3rd-person perspective -- even in my over verboseness. :^) <taylanub>youlysses: Other distros are unlikely to adopt DMD over OpenRC, and duplicated effort (through NIH, in this case) is generally not nice, although I definitely also love the idea of a Guile-based init system, so no hard stance on my side ... <youlysses>taylanub: Is not the point of the continued work done on DmD though, a result of building the best-possible upstream experience? I mean, it's fine and great if others want to use it in their distros, but I think the focus should be on providing the greatest guile-centric tools, for developers and the distro itself. :^P <youlysses>taylanub: It's not like OpenRC is really providing what DmD is/does, right? I haven't looked into it, but I'm assuming it's not written and maintained in Scheme. NIH is mainly thrown out as a counter, when seemingly the same exact effort (or at least the changes are negligible between projects) is spent and "wasted" on one or the other of these said projects. The focus for GNU developers wanting primarily wanting their tools in Guile, <youlysses>now, is the differentiating factor and too something I'd be able to respect. <taylanub>youlysses: If "use Guile as much as possible" is an explicit goal of Guix, then fine, but I'd think that uniformity between Unix systems is a somewhat grander goal when it doesn't compromise the general distribution guidelines of GNU. It's obviously long lost in package management; I naively thought init systems could be saved, though when I think of it again now I realize there's already splintering everywehre so maybe it doesn't <taylanub>OpenRC is already stable and in use at least on Gentoo though and Debian will hopefully switch to it too, so it's not worthless to check it out and see if perhaps a Guile interface to OpenRC wouldn't be more sane than a full new init system. <taylanub>(Wow, I see DMD actually dates at least ten years back, being targeted at Guile 1.6 back then.) <taylanub>Oh well, if it ends up being the init system of Guix, I'm sure I'll love it, so if people are motivated to work on it, no discouragements here; just saying though, OpenRC should be worth some consideration. <youlysses>taylanub: Yeah -- I should have been more clear when I said "continued work". :^) <youlysses>taylanub: We already have a fair amount of Standards in-place on/in the general GNU+Linux ecosystem, but I would call GNU+Linux-libre and planned, just generally the GNU ecosystem to not have to work exclusively, not even as-much as possible in that realm. Though I see them as similar, I too see them as very different entities. <youlysses>civodul: Unrelated conversation to what we were having prior, but do you think we'll have a bootable image prior to Guix hitting 0.5? <civodul>we'll have a QEMU image by Sep. 28th *civodul is working on it <youlysses>That's the main detractor for me not packaging stuff -- having it on my host-machine. If I can live in a VW for awhile, I'll probably have the rest of my software stack packaged in a week or-two. :^D *youlysses might retrograde back to Ratpoison from Stumpwm though. :^) <civodul>well, i find it OK, because it's not really intrusive in that it uses different directories etc. <civodul>so you can just rm -rf /nix basically if you want to get rid of it <youlysses>civodul: Yeah. I just can't rationalize my mind into packaging something I use everyday, in a different environment that's currently not a first-class citizen. I'd say it's a failing much more-so in me, than in the current way it's organized. <youlysses>That being said, a tremendous amount of my current software stack is already packaged/working in guix. :^) <civodul>for me, this strategy has allowed a smooth transition <civodul>like i now have 90% of my daily needs covered, i'd say <youlysses>civodul: Different strokes, for different folks I suppose. :^) <youlysses>Just having GTK Emacs packaged covers probably 85% of my computing needs. I probably just need to get Conkeror or the like packaged and something that can read and export to .Doc formats and the like, so probably just Libreoffice. <youlysses>civodul: I'm curious, do you live in ratpoison, or? I'm interested in the prospect of a Guile based tiling WM -- but at this point, I think it might just be more worthwhile to eventually writing a Wayland Compositor for (guil)Emacs. :^P ***ae is now known as Guest34899
<mark_weaver>youlysses: civodul uses ratpoison, yes. do you know about the recently started Guile-WM project? <youlysses>mark_weaver: All I've seen was a mailing-list post about the possible beginnings of such-a thing, a general "I wrote bindings for some xorg-devel stuff, here's some sample code" -- I haven't seen anything past that point. Also I've heard someone trying to modernize scwm, some-time ago. <mark_weaver>well, afaict, Guile-WM already works, although it's a bit bare bones. <youlysses>mark_weaver: Besides the stacking windows, it looks pretty nice! :^) <mark_weaver>well, yeah, it would have to be redone to make it do tiling, and I'd also want to support better keyboard navigation. <mark_weaver>but since it already works as a WM, has full XCB bindings, and is written in Guile, it should be relatively easy to change it to a tiling WM. <mark_weaver>I expect I'll probably want to use it at some point, anyway. <youlysses>mark_weaver: It lists a tiling-algorithm, so that seems hopeful. Might be a nice transitional piece of software, until/if someone writes that mystic wayland compositor for Guile Emacs... :^) <ArneBab_>I just wrote an article about installing GNU Guix and my initial impressions: <ArneBab_>If I made errors in there, please tell me so I can fix them… <Steap>"nstallation is straightforward, except if you follow the docs," <- that's funny :D <Steap>Why would you run screen as root ? <ArneBab_>(please don’t take it personally: I know how hard it is to write good documentation) <ArneBab_>I run screen as root, because that instantly gives me an unlimited number of root shells :) <ArneBab_>and sudo screen -RR returns me to the running build process <Steap>yeah, I usually run screen as a normal user <ArneBab_>I’ll likely not need that with guix, though… <Steap>I think you could s/YOURUSER/$(whoami)/ <Steap>you forgot "-i" in the "install" command <ArneBab_>is there a way to add overlay package repositories? <ArneBab_>If for example I’d want to package my own small utilities to be able to take them everywhere <Steap>Hydra is slow, yes. The help could be better, I'll add that to my TODO list. <Steap>you could use aliases for "guix p" <Steap>well, if they are free software, just send us a patch <ArneBab_>but aliases are not the default workflow. <Steap>otherwise, you could just write Scheme modules and use them as you do with those that are provided <ArneBab_>So I could just have my Mercurial-managed tree with scheme modules which are used by guix? <Steap>they're just Scheme modules, really <ArneBab_>that sounds nice - then additional overlays should not be too hard to add. <Steap>the easiest thing to do would be to add them in gnu/packages/ <Steap>but you could probably use them from elsewhere <Steap>I'm no Schemer, though, so I'm not sure how <mark_weaver>there's a recent discussion on guix-devel about overlays. basically, it's not hard to do the equivalent of overlays right now, but it could probably use some polishing. it's just a matter of finding the right way to do it. *ArneBab_ wishes he had much, much more time. There are far too many far too interesting things… <mark_weaver>unfortunately the @ signs get munged to "<at>" in that web interface. <ArneBab_>mark_weaver: Aside from overlays I mostly missed the categories for package names. <ArneBab_>mark_weaver: does that mean that I could actually distribute several packages in one scheme file? <ArneBab_>For example if I wanted to distribute a game, just provide a guix scheme-file with all the dependencies? <mark_weaver>I agree that some kind of tagging system would be nice. <ArneBab_>guix package -e "(@ (game-dist) my-game)" <ArneBab_>mark_weaver: I don’t know whether tags are really an advantage. <ArneBab_>mark_weaver: if the number of packages rises, guix will eventually run into limits of the file-system just when listing all packages. <mark_weaver>well, if by categories you mean that each package can only be in one category, I think that's not flexible enough. often there are packages that belong in more than one category. <mark_weaver>so I'm not sure what the right approach, but I definitely agree that we could use a better way to browse and search for packages. <ArneBab_>the easiest way to fix that would be to have subfolders. And the most intuitive way to use the info from the folders would be categories. <ArneBab_>just do a performance test: run `ls` in a folder with 30k files. <ArneBab_>that’s a real bottleneck which no client-side code can fix. <civodul>the number of packages can be expected to be O(10K), so the number of files would be slightly less <civodul>we're far from the file system limits <ArneBab_>civodul: in Gentoo we have about 30k ebuilds and 200k files. <civodul>at any rate, if we eventually need to create subdirs in the source tree, we'll create them <civodul>that's not the main concern, i think ;-) <ArneBab_>as long as that can be done without breaking anything I agree <ArneBab_>Besides: I do not understand the difference between refresh and pull… <civodul>before or after reading the fine manual? :-) <Steap>civodul: subdirectories are not as flexibles as tags :/ <ArneBab_>after :) (though now I know that refresh should not be used by users, but not why) <ArneBab_>if pull updates my packages, why can’t I tell it to use 8 cores?