IRC channel logs
2016-01-16.log
back to list of logs
<tsyesika>So, i need to somehow to find a way to disable usbkbd despite it being loaded <jacey>what needs to be done for an ARM port of guixsd? is there a roadmap, anyone willing to mentor? <jacey>does this apply to guixsd too <lfam>I think there are also some messages on the guix-devel mailing list. If you are interested you should send an email to the list. <jacey>i have a port of nixos to my current board but upstream isn't that helpful since im not on github <lfam>I'm not sure how much that does or doesn't apply to GuixSD <lfam>Does NixOS not have an ARM port? I'm surprised <jacey>well, it seems to be neglected <lfam>We do build packages for ARM on our hydra, and I'm sure there's interesting in getting GuixSD on ARM too <jacey>the mailing list is also not used for patches so my code isn't likely to be upstreamed <lfam>Well, I can't speak for everyone but I don't think you have to worry about us jumping to github. <jacey>i have time and enough patience to perhaps get an arm port happening <jacey>there's also some larger issues with nixos that aren't really talked about but i think guix does have some focus on- local builds, for example <lfam>It would be so rough to run NixOS on the Raspberry Pi if they aren't building substitutes for it. I can't imagine how long it would take to bootstrap the system. <lfam>What do you mean by 'local builds'? <jacey>lfam: well, i've built a full GUI nixos on ARM all using local builds- builds done without substitutes <lfam>Are you saying they don't properly support that use case? <jacey>nixpkgs is focused on hydra building it, so things that make sense done locally are disabled <jacey>for instance, gtk support in qt is disabled because it adds more dependencies to hydra. parallel builds of qt are also disabled, which isn't fun on ARM <lfam>Hm, I'm not sure I understand why you'd disable a feature to save the time of the build farm / CI server. The point of the "build farm" part is to save human time, right? ;) <jacey>I think parallel builds break on the build farm <lfam>How long did it take you to build the system on ARM? What board is it? <lfam>Some software just can't be built in parallel <jacey>Qt can, but not on Hydra appraently <lfam>Looks like our qt builds in parallel on hydra <lfam>At least, the package definition doesn't disable parallel building, which is our default <jacey>lfam: i.MX6, base is around 8 hours, Qt takes around 11 (this includes webkit) <lfam>I can't believe it's so fast! Does that include building things like GCC? <jacey>full rebuild including firefox, GTK, two versions of Qt, devel stuff is a few days but it's not that bad since you can still use the system while it builds the new revision <lfam>So, you can build a complete free software system in 8 hours, and then the GUI takes another 11. Groan <lfam>I guess NixOS isn't really a "free software" system since they package so <lfam>package so much non-free software <jacey>i'm a patient person, but not patient enough to have my own nixos fork for the forseeable future <kmicu>lfam: NixOS ≠ Nixpkgs, only free packages are available on vanilla NixOS. <jacey>support both free software and proprietary software <kmicu>You need to opt–in for a non-free licenses and non–free firmware from Linux kernel. <jacey>actually nonfree firmware is default <jacey>did they change it since october 6? <lfam>How do they strip it out? Do they use linux-libre? <kmicu>A user need to set system.enableAllFirmware in configuration.nix for a non–free firmware. <jacey>interesting- i wonder why there's a separate license 'unfreeRedistributableFirmware' that's enabled by default <jacey>bittorrent sync is marked as that license too <jacey>oh oops, not unfreeRedistributableFirmware, just unfreeRedistributable <lfam>Looking forward to having Go in Guix so we can package Syncthing <jacey>how's KDE/Gnome/Xfce packaging? <lfam>I know we have Xfce. We got a package for gnome-shell in recently. I don't know GNOME so I don't know how significant that is. We don't have KDE yet AFAIK <jacey>My primary concern is lack of packages- though I'm fine with packaging things. <jacey>so i guess my primary concern is whether i can contribute <lfam>Well, only you can answer that :) <jacey>guess i'll just have to install guix on my t400 and see how much it satisfies me <lfam>Good luck! I have to leave <fhmgufs>It seems to be linked to the non-existing dmd project repository. <Vaelund>greetings, is there an easy way to change the keyboard layout in the guix sd install image? <Vaelund>nope, just temporary, didnt think of loadkeys, thanks <tsyesika>civodul: hey, so you said last night that the usbkbd was loaded in the inird, just wondering if you know what my next step would be to disabling it and testing if that effects the keyboard <tsyesika>I'm guessing i'm going to have to rebuild the package though i can't find a initrd package and i'm not sure how i'd then build an identical 0.9 image except with that package switched out (I can't see anything in the docs to build ISO's) <rekado>tsyesika: I think the image was created with "guix system disk-image config.scm" <rekado>so, you'd have to remove "usbkbd" from "linux-modules" in the definition of "base-initrd" in gnu/system/linux-initrd.scm and then rebuild the disk image. <tsyesika>rekado: thanks for the advice, i'll try and build and image and let you know how it goes <tsyesika>rekado: do you know if the config used to build 0.9.0 is anywhere that i can grab <tsyesika>would be useful to stay as close to that as possible so other packages don't get introduced <rekado>I don't know. We have these example configurations in the manual. <rekado>I don't know if one of them was used. <tsyesika>yeah, well i can use mine that i use on my desktop OS but that has xorg, window managers, emacs, a bunch of other packages <civodul>tsyesika: following the discussion you were having yesterday, i implemented support for 'modprobe.blacklist' in our Linux module stuff <fhmgufs>civodul: But I think people *should* be able to view the git repository. It's also not clonable. <fhmgufs>Did you add the former dmd git repository to the shepherd project? <civodul>tsyesika: i realized that was easy and useful <civodul>fhmgufs: the migration was performed by the Savannah folks <fhmgufs>Ok, so they deleted the dmd repository. <fhmgufs>And then linked to it from the shepherd page. <civodul>but that's not what the main page redirects to <fhmgufs>civodul: The ?group links work for every project wether it has a git repository or not. <civodul>ssh://civodul@git.sv.gnu.org/srv/git/shepherd.git definitely works for me <fhmgufs>Before I tried to clone the dmd repo because the link made me thinking that there's no new shepherd repo. <fhmgufs>So there's a git repo - that's good. <fhmgufs>Ok. Git cloning is working for me, too. <fhmgufs>civodul: But why does the web interface say that no repository is found? <fhmgufs>civodul: They just have to change the *two* links. <fhmgufs>Now I know what's the problem with the git web interfaces except from the wrong links: <fhmgufs>I had problems sometimes acessing them. <fhmgufs>That was beacause you have to add a / add the end <fhmgufs>That's strange: No it works also without the / at the end. <fhmgufs>But a few minutes ago only the first one worked. <fhmgufs>And another few minutes ago nothing worked. <fhmgufs>Will the shepherd executable be named "dmd" in the future, too? <civodul>fhmgufs: re Savannah, feel free to complement the support request above if you notice other issues <civodul>the shepherd executable has been renamed to 'shepherd' a couple of days ago <civodul>but i'm thinking of optionally keeping symlinks with the old names <civodul>and do that by default for the next few releases <fhmgufs>civodul: And what about deco? You mentioned that it could be renamed to herd. <fhmgufs>I think if that's done it should be done now. <fhmgufs>Because we don't need another revolution ;) <civodul>this will be done before the release i guess <civodul>there are other issues, such as config file names, etc. <civodul>my current inclination is to not bother about compatibility, except for command names <davexunit>(doing my daily twitter search for "gnu guix") <civodul>he doesn't know that neither the FSF nor GNU funds Guix ;-) <davexunit>civodul: yeah, I want to point that out, but I also don't want to get involved in an internet argument right now. <civodul>also, he doesn't know that the SFC does fund a GitHub replacement <davexunit>does anyone know how I can get the Beamer LaTeX package on Guix? <davexunit>I installed texlive but it doesn't seem to be there <davexunit>I think there's a bug in our texlive-bin build script <davexunit>well, maybe not... I have no idea what's going on. <davexunit>but I can't find the texlive-extra stuff anywhere. <fhmgufs>How do I make the shepherd git repository buildable? <mthl>fhmgufs: with 'autoreconf -vfi' ? <fhmgufs>Thanks, works. I tried it without the options. <davexunit>I got past my first beamer issue, which was an Emacs issue. <davexunit>grrr I just can't get latex to see all the texmf stuff <mark_weaver>davexunit: this is not my area, but I know there's a TEXINPUTS environment variable <davexunit>the odd thing is that it should be configured to work with our texmf out of the box <davexunit>mktexlsr: /gnu/store/0wkmf926dv9ck8y1pk5p2lxw95kf7z9d-texlive-texmf-2015/share/texmf-dist: directory not writable. Skipping... <davexunit>so it knows about the texmf directory, but perhaps because the directory is not writable it cannot use them? <mark_weaver>I get the impression that mktexlsr "makes" something, probably some kind of index, and thus needs to write it somewhere <mark_weaver>I would ask on the ML. there are definitely guixers who use latex a lot, but maybe none of them are here now. <mark_weaver>note the trailing colon that they add to the end of the TEXINPUTS setting <davexunit>mark_weaver: adding a colon to the end seemed to work <davexunit>which is great! but not a long-term solution. <davexunit>I installed texlive-texmf directly into my profile, which takes ages to do because it's so big. I wonder if there's a better way... <lfam>When I package a user-facing program, I like to email the maintainers to let them know, and I like to include the output of `guix graph` as well. Sometimes there are scary things in the dependency graph and they don't realize it. My question is, how can I characterize the output of `guix graph` for them? <lfam>The default graph type "package" is described in the manual: "It shows the DAG of package objects, excluding implicit dependencies." <lfam>Can I say, "This is the dependency graph of foo, excluding implicit dependencies like GCC and the tar used to unpack the source tarball." <lfam>Is there a better pithy way to describe the meaning of the graph? <lfam>Now if all these upstreams would not force me to open a github issue just to notify them of the packaging :p <rekado>is there no way to open a github issue via email? <rekado>or does one need to have an account? <rekado>(that would be great if all these services accepted email) <davexunit>if you have a github account, you can reply to their email notifications to reply to issues. <lfam>I just mean, it's lame that I have to basically file a bug report just to communicate with the upstream. Either that or a private email. There is no general discussion platform. <lfam>You can reply to github issues directly from email, but almost nobody does. You can tell because the lines are never wrapped. <rekado>I always feel so helpless when I don't know how to talk to an upstream project <rekado>some have these weird google groups <lfam>I tried to email a project recently and the google group was private unless you had a google account. Why? <xd1le>lfam: nah i see a *lot* of people do <davexunit>Linus Torvald's rant against github tools, while very rude, is correct on a technical level. <lfam>Line wrapping of emails isn't a huge issue on its own but it does indicate a general lack of care. Reading git logs of github hosted projects is usually a total waste of time. The commit messages are just one word, or just a merge message <xd1le>wait maybe you were talking about something else... i agree with "reading <xd1le>i was responding to "but almost nobody does." <lfam>And I found that if you have a feature branch, it's impossible to submit github pull requests of subsets of the branch. You can only request a pull of the entire branch. It's such a crappy subset of the git tools <lfam>A lot of people do in projects like this one :) <xd1le>lfam: no i mean even on github hosted projects <davexunit>lfam: yeah, github has destroyed patch quality. <lfam>xd1le: Oh that's good. I haven't noticed it. <xd1le>(including owners and stuff, i guess it just depends on which projects obv) <lfam>Some are better than others of course. <xd1le>like i watch a lot of emacs projects, so i guess that's why <lfam>Heh, I think emacs users are generally more fastidious than a github user picked at random. <rekado>github makes it easy to fork, but then you're on your own and have to deal with two clones, really: the local clone of your fork, and the fork on github, which will not be up-to-date with upstream. <xd1le>lfam: what do you mean "subsets of the branch"? <rekado>but you need a fork to submit patches ("pull requests") <xd1le>rekado: yeah it's bc pull requests have to be done via the web interface <xd1le>(does github even use librejs?) <rekado>I know people who don't understand git enough to add a remote for the upstream repo and instead refork the original repo from scratch. <lfam>xd1le: I had a feature branch that should have been submitted as multiple commits. I couldn't figure out how to do that and I couldn't get an answer on #github. I ended up splitting the branch into multiple branches and requesting a pull of each branch. <xd1le>rekado: yeah in fact i see that all the time <lfam>rekado: Exactly, it's so annoying! Why do I have to maintain TWO forks <rekado>lfam: you can have your feature branch, make a pull request, and then add commits to the branch (and they'll be added automatically to the pull request) <xd1le>yeah that's totally doable, i believe <xd1le>you should be able to just do as rekado says <xd1le>open the PR on the feature branch <efraim>yeah that's happened to me before too <xd1le>and the commits for that branch should all come up there <lfam>Yes, but I wanted multiple pull requests because some of the commits could be applied independently of each other. They shouldn't have to be pulled as one. <xd1le>lfam: oh i've never seen that <rekado>it's possible for upstream to just use git and cherry pick from your fork <rekado>not through the web interface, though. <xd1le>generally one feature branch maps to one PR <xd1le>like people sometimes have huge PRs with 100 or so commits <xd1le>which they work on over a few weeks or so <rekado>I find it dangerous how the PR thing encourages force-pushing --- or having an ugly history. <xd1le>yeah cherry picking is always available <rekado>when someone reviews your PR you can either pile on new commits or overwrite it all. <fhmgufs>I think the worst thing is that you can't change things in your fork without addind them to your PR <rekado>what I like about github is something to do with the fact that everybody uses it; it's easy to discover projects this way. But that's nothing to do with github services, really. <lfam>Like, I recently had a feature branch to add the Khal program to Guix. I ended up working on related leaf programs in the branch. But there's no reason to pull in all those programs in one action if you don't want to. I could have submitted them as separate patch sets. <xd1le>fhmgufs: that's because github "forks" are not even first class repos <lfam>rekado: Yeah, the network effect is awesome. Too bad it's a trap. <xd1le>mostly their purpose is only to contribute to the original repo <xd1le>or at least that's what i've seen <xd1le>if you want an actual 'fork' <xd1le>then you would just create a new repo normally, and make that your origin <fhmgufs>xd1le: But then I could do my change and send a patch much easier. <lfam>I want to have a free software github alternative as a service in Guix. It will be really powerful if people don't have to struggle to set up and maintain a service like that. <xd1le>wait i'm not sure what i was responding to.. <xd1le>fhmgufs: hmm i don't know why i said that <xd1le>although i was being honest, it's not really relevant, sorry <fhmgufs>I don't want to have multiple forks of one project until it's maintainer decides to include them. <xd1le>fhmgufs: well i don't think you need to if you could just create a new branch? <fhmgufs>But I also don't want to have thousands ;) of branches. <xd1le>as an aside, how do people 'track' threads/issues on mailing lists? <xd1le>fhmgufs: ah but branches are nice! <xd1le>as in, with some sort of issue tracking system <xd1le>and come back to them even years later <rekado>xd1le: my mail client (mu4e) keeps emails together in threads. When a new email is added to a thread the whole thread moves to the top. <xd1le>i've seen jwiegly use a good gnus setup <rekado>I don't have the patience to set up gnus. <xd1le>if i want to search through the entire history of the ML <rekado>I'd love to be able to use gnus, but ... meh. <xd1le>can i just download it and search trhough it or something? <rekado>I asked a question like that on emacs.stackexchange a while ago <rekado>the answer was to use gnus with gmane. <fhmgufs>lfam: the github principle is not good. If you *want* to contribute to a project, you should be able to join it's mailing list and use git yourself. And if you just want to show how much you contributed in the last year and how many many projects you contributed to, also if it just were typo fixes, you can create an own mailing list for that (I think nobody would join). <xd1le>rekado: ah nice, so people *do* do that <xd1le>because i'm thinking a ML serves all the needs of an issue tracking system <lfam>fhmgufs: I'm not sure why you directed that to me. I agree wholeheartedly that it's not difficult to join a project using infrastructure like that used by Guix! <fhmgufs>lfam: Because you said that you want a github for/in guix above. <rekado>fhmgufs: in my opinion, Savannah is not pretty, unfortunately. <zch>what other things does GuixSD provide that other distrobutions dont beside having yet another package manager? is there anything else exciting about it (I dont mean this in a negative way) <zch>Hope this is the right channel to ask? <davexunit>zch: transactional upgrades and rollbacks of system configurations <xd1le>zch: declarative system configuration <fhmgufs>rekado: But it's the right direction. <rekado>I wanted to send some patches, but then noticed that savannah uses a custom fork of the savane software, and it's written in PHP ... and then I lost interest :-/ <rekado>(I only recently found out that it has a couple of alternative stylesheets, but they don't fix the layout and organisation issues the web interface has) <lfam>Savannah's not pretty but I never need to look at it. It's all in my mail client and local Guix source tree. <zch>would you guys say guixsd is ready to be a daily driver (your main os)? <zch>i dont mind tweaking and learning guixsd <lfam>fhmgufs: Since it seems that almost all computer programmers want to use something like github, we should try to accomodate them. Even if I prefer the mailing list system. <rekado>lfam: that's right. I'd still like to have a prettier Savannah to find new projects etc <zch>fhmgufs: i dont use a DE <zch>Which there is a package for ;) <rekado>zch: GuixSD works really well for me, but I'm no longer certain if my use case for computers matches that of others. <zch>rekado: what is your use case, if you dont mind expanding on that <rekado>zch: I don't want to use any other system any more. <lfam>You use GuixSD as an Emacs host? ;) <zch>I'm looking to center everything around emacs <zch>But emacs doesnt have a good irc client :/ <lfam>zch: This is the right place for you <zch>ERC doesnt even have proxy support :/ <zch>I'm so used to weechat haha <rekado>ERC connects to ZNC on my server. <zch>ill look into that setup <zch>and thanks lfam, missed your message <rekado>instead of "M-x erc" you just do "M-x znc-all" to have all ERC buffers recreated, with history and everything <rekado>there was nothing for me to set up, really. <zch>the thing with erc, is i want to specify certain proxies for some networks <zch>for example, i want to use Tor for oftc <rekado>except maybe username and freenode as a server; I just started it months ago as a regular user on the server and then use znc-all to connect to it from Emacs. <zch>I can easily do that with weechat <zch>But I dont see an easy solution for any emacs irc client <lfam>rekado: Is your server GuixSD? If so, how do you start ZNC? Do you have a dmd/shepherd service for it? <rekado>oh, I think because we don't have a prosody package yet. <rekado>I think that's the last thing I'm missing. <lfam>Heh, I haven't made much progress on that recently. <lfam>I just got some new hardware for a home server. I'm wondering about starting daemons at boot. Is there a simple method analogous to (package), or will it require something more... lengthy, like the other services I see in gnu/services? <cehteh>even my wife using it now, gnome got too annoying <rekado>I used to use Xmonad some years ago, but that was when I had so many terminal windows open and still used vim. <rekado>now I really don't care much about the window manager anymore <rekado>(I want to have the browser embedded in an Emacs buffer) <fhmgufs>Even my most favorite de (MATE) is to graphical for me now... <xd1le>rekado: what wm do you use now? <xd1le>cehteh: what de/wm does your wife use then? <rekado>xd1le: erm, whatever comes with Xfce. But I don't see any of it because Emacs fills the screen. <cehteh>whatever gnome provided that time <xd1le>fhmgufs: also see: bspwm, herbstluftwm, stumpwm, ratpoison.. if you haven't <xd1le>although probably i3 is the easiest to use out of these <rekado>hmm, arabic input method doesn't work. <rekado>Gamayun: I'm waiting for it to become a little more mature. <xd1le>Gamayun: what's the advantage? <davexunit>I basically only ever want emacs, web browser, or terminal taking up the entire screen <cehteh>emacs rarely crashed on me .. i3wm never :D <cehteh>how far is guile-emacs meanwhile? --- useable? <Gamayun>xd1le: If you're comfortable with emacs, you can avoid other things (with potentially overlapping keychains etc.) <cehteh>useable as in performance in par or better than normal emacs <xd1le>Gamayun: oh I hadn't thought of that <xd1le>Gamayun: for example, most of my wm keybindings are bound to super <xd1le>are you saying i could use super keybindings in emacs too? <xd1le>davexunit: wait guile support ecmascript 2015?! <davexunit>xd1le: there's been experiments in implementing ecmascript on Guile <xd1le>ah, the website is slightly misleading then <davexunit>but there's no full, standards compliant implementation available <davexunit>xd1le: when you say ECMAScript 2015, do you mean ECMAScript 6? <xd1le>davexunit: yeah, that's what the guile website links to if i'm not <xd1le>when you can just use scheme... <davexunit>xd1le: running other languages on the Guile VM is a big selling point. <davexunit>hopefully Emacs will use the Guile VM as the elisp runtime in the future <xd1le>davexunit: the only thing i can think about is running other languages via <xd1le>but that seems overly complicated/brittle <xd1le>davexunit: yeah that would be great <xd1le>in fact, why not just guile-emacs right now? <xd1le>doesn't guile-emacs use guile vm? <rekado>guile-emacs doesn't work with the many extensions I use. <rekado>one that I cannot do without crashes guile-emacs: desktop-save-mode <lfam>Do you emacs lovers use emacs-w3m? I'm wondering if it bundles w3m or uses an external package. <davexunit>xd1le: yeah I wrote a rant about that yesterday <xd1le>davexunit: wait wasn't that *dear* github? <davexunit>no this for "thank you, github" which was a made as a response to "dear github" <lfam>"Please sir, may I have some more?" <taylan>huh, so even just asking them for features is too much now? talk about Stockholm Syndrome. <fhmgufs>I would like to learn guile/scheme. Is there a good tutorial or not too big (german) book? <xd1le>ACTION puts on conspiracy hat <xd1le>what if these are just people with monetary incentive to keep github <xd1le>and they're actually scared about the response to the "dear github" thing? <efraim>I've been told the little/reasoned/seasoned schemer are good books, haven't looked looked at them yet <xd1le>except, money probably isn't really a factor. <taylan>xd1le: "never ascribe to ill will what can be explained equally well through simple stupidity" :P <davexunit>ACTION tries to put together slides for presentation <xd1le>taylan: yeah but no way they don't understand the pits of centralization <davexunit>I have so many things I want to talk about, but it's hard to find order <xd1le>davexunit: you should and just ignore me <xd1le>davexunit: i've just found this thank you github thing right now <alezost>lfam: I use emacs-w3m, it is just an elisp code and it doesn't bundle w3m <lfam>davexunit: Feel free to share your work in progress if you want some feedback <lfam>xd1le: LOL, the closing note called it OSS instead of FOSS. Groan :P <taylan>that's fairly widespread among, well, OSS people. <xd1le>lfam: well duh! you can just feel the passive aggression <taylan>I'm afraid "open source" is quite more popular than "free software" nowadays <lfam>Yes, it's true. I think it's better than nothing. <xd1le>taylan: yeah, but OP put FOSS in title <lfam>Although you see the pitfall in totally closed-source Android-based "Remix OS" making the rounds on tech news sites lately <xd1le>it it just a rom/distribution of android? <xd1le>there's lots of nonfree android roms <lfam>Yeah, I don't really know. I saw there was no source code and people complaining in the comments and closed the window. But there was discussion about how this was made possible by permissive open-source licenses. <lfam>I think it is supposed to support the sales of some specific hardware <xd1le>lfam: also irony about the "remix" name <Gamayun>I actually think 'free software' has been gaining ground versus 'open source' for some time.. <paron_remote>I think I'm going to start a thread on devel about what our general plan will be for developing config file writers <paron_remote>it seems to me like using format and string-append everywhere is not going to be long term a nice thing to maintain <paron_remote>one possible route that's been discussed has been to use fmt <rekado>(on a somewhat related note: I packaged augeas) <calher>How does security work when noraml users can install programs? <rekado>calher: depends on the attack scenario you have in mind <paron_remote>rekado: it might help making writing out the huge mess of config writers we're going to have to build more readable / maintainable <calher>rekado: Well, normally users aren't allowed to install programs. <rekado>calher: when software is built by the daemon it doesn't affect anything else; <rekado>each build result gets its own directory in /gnu/store <rekado>unless it's exactly identical to something that was previously built <rekado>"installing" software in Guix terms is just adding it to a user profile. <rekado>user profiles do not affect one another. <davexunit>furthermore, there are *no* setuid binaries in the global binary store. <rekado>when Eve somehow builds and installs a malicious version of bash it doesn't affect Alice's version of bash. <fhmgufs>This makes guix *more* secure than other package managing systems. <rekado>calher: users installing packages does not affect any of the "global" directories such as /usr or /lib. <paron_remote>it's come up before, especially in reaction to "what direction could we go that's more sane than ansible style jinja2/string template config file formatting" <rekado>paron_remote: thanks for the link <calher>I hate typing "guix package" before stuff. <davexunit>calher: guix is a whole suite of tools, managing package profiles is just one thing that it does. <calher><troll>but i thot gnu was a suite of toolz</troll> <rekado>davexunit: will you make a new release of haunt with skribe support some time? <paron_remote>maybe I should package so that we can better see whether something like this is useful for guix system definitions <rekado>latest release tarball is for 0.1 <paron_remote>ACTION sitting next to people in a coffee shop talking about monetizing an "apps for drones" space ;< <calher>paron_remote: There's a Scheme version of fmt? <calher>Ew, drones running non-free SW. /That/ is scary! <rekado>I really like how easy it is to create package variants with Guix. <rekado>this stuff is pretty difficult with any other distribution/package manager I've used before. <calher>rekado: Do you have a perspective of Nix? <rekado>I never used it, but I'm glad I picked Guix over Nix. <paron_remote>I wish the fmt docs gave better examples of building larger things out of the pieces <paron_remote>having a hard time determining if this would reallly help us or is just cruft <paron_remote>which might be a good place to look to understand how to use its combinator power <rekado>with the latest haunt I can no longer use my custom tags that are defined in my haunt.scm. It seems that only the things defined in (haunt skribe utils) are considered valid. <calher>rekado: Why would you be glad to pick Guix over Nix? <rekado>davexunit: how can I make sure my own definitions are available when the skribe documents are read? <calher>(Other than ideological reasons.) <rekado>calher: over time I've looked into package definitions in Nixpkgs and I didn't like what I saw. <calher>ACTION renames himself to WhyKid <rekado>I also prefer Scheme over a mix of languages, and I'm glad Guix isn't using bash anywhere. <calher>Yeah, mixed language sounds bad. <calher>Having everything in a persistent language must be an improvement (unless you hate Lisp). <rekado>I looked at packages to see how they solved certain problems (e.g. bootstrapping issues or circular dependecies etc) and repeatedly I would find ... no solutions. <rekado>it's like people chose the easy way out on multiple occasions. <davexunit>rekado: make-skribe-reader has a #:modules keyword argument. Add in the modules that you'd like. <calher>I just see raw HTML when I do this. <davexunit>rekado: for example, I have a (skribe-utils) module in the root of my haunt site that has some procedures for syntax highlighting. <paron_remote>something's wrong with the way they're serving the content type I'm guessing <paron_remote>and reusing stuff from the C writer library pretty clearly and readably... <fhmgufs>Should GuixSD include as much services as possible when it grows or just the most used ones? <paron_remote>fhmgufs: I think that's a serious question we're going to have to answer :) <paron_remote>probably many will be included, but I'm thinking about this very issue! <calher>At install, the first question is: "Are you a nontechnical user?" If you select "Yes", it installs everything necessary to have a decent GUI desktop. <davexunit>fhmgufs: I'd like to include as many as possible. <fhmgufs>Couldn't the service stuff be handled by shepherd itself? <calher>I wish Guix could be called GNU. <davexunit>fhmgufs: a Guix service may or may not translate into a shepherd service. <calher>Weren't they going to call the system GNU? <paron_remote>it will be nice when you can say "I run GNU" and mean Guix + GNU + Hurd though ;) <paron_remote>yeah guix services can also write out /etc/ type files or etc too <fhmgufs>But shepherd has it's one scheme configuration system to define services, right? <fhmgufs>So the os definition could include a list of custom service definitions which is then handled by shepherd. <davexunit>fhmgufs: for that you'd write a guix service that extends the shepherd service. <fhmgufs>I am not sure wether you unterstood me right. <fhmgufs>I don't know why we need services defined by guix if shepherd has its own guile configuration system. <fhmgufs>Shepherd is the init system of guix. <davexunit>you are misunderstanding the GuixSD service API <davexunit>fhmgufs: there are many types of services, one of which is a shepherd service. <calher>fhmgufs: That's different from dmd, right? <davexunit>dmd's name was changed due to a conflict with the developers of the Digital Mars D (DMD) compiler <calher>I'm glad the GuixSD logo looks like a hip GNU. <calher>It still looks like GNU and it would look cool on a backlit logo on a MacBook lid. <davexunit>fhmgufs: in GuixSD, the relationship among different service types is a directed acyclic graph, much like packages. <fhmgufs>If I define a service for a webserver for example. <fhmgufs>So why do I need a service definition mechanism in guix? <davexunit>fhmgufs: alright, so how does that service know which webserver binary to run? <fhmgufs>Well, could you explain that in detail, please? <davexunit>to do things like translate say, the nginx package, into the associated path in /gnu/store so that you can specify the exact path to the nginx binary. <calher>Why can't GuixSD use WiFi on the installer?? <davexunit>in the case of our nginx service, we actually want to do things beyond what is handled by shepherd.