IRC channel logs


back to list of logs

<jgrant`>Okay, back.
<jgrant`>Okay, so I have a git clone compiled and have the file edited to it's past incarnation.
<jgrant`>Now, do I log in as root then "./pre-inst-env guile -c '(use-modules (gnu system linux-initrd))'" followed by "./pre-inst-env guix system reconfigure config.scm"?
<mark_weaver>jgrant`: run 'make' as your normal user in the git checkout. then run the system reconfigure command as root.
<mark_weaver>well, run 'make' as whatever user you built the git checkout under.
<mark_weaver>(ideally that would be your normal user, but whatevs)
<mark_weaver>jgrant`: well, I assumed that you built that git checkout, but now I'm not so sure.
<jgrant`>Not make install?
<mark_weaver>jgrant`: no, do not make install
<mark_weaver>just checkout the git repo as your normal user, make the change (revert the offending commit, ideally), then "./bootstrap && ./configure --prefix= --with-libgcrypt-prefix=$(guix build libgcrypt | head -1) && make"
<mark_weaver>(as your normal user)
<mark_weaver>the only thing done as root will be the system reconfigure command
*jgrant` will brb.
<mark_weaver>you'll need a bunch of packages installed to do that build
*jgrant` is suspicious that he did this right ... but will reboot to check.
<jxself>Oh joy - This new kernel update will require a config update too.
<jxself>New symbols.
*jxself aborts the update effort until he gets home and can look into it better
<jgrant`>Yeah, nope.
<jgrant`>mark_weaver: I just thought of this, are you aware I installed from a bootstrap and not a GSD usb install?
<jgrant`>So I created a small Parabola partition, installed Guix there. Used the guix on that parition, to "guix system init config.scm /mnt" on this partition.
<jgrant`>So, I don't know if that changes the methodology at all or not.
<jgrant`>If I don't figure it out tonight, I'll bugger with it and send a bug report possibly. :^P
<jgrant`>sometime tomorrow*
<mark_weaver>jgrant: to view pdfs in emacs, you need a pdf rendered. I recommend "mupdf"
<civodul>Hello Guix!
<ams> morning
*civodul updates NEWS
<aurelien>'lo #guix
<rekado_>hello aurelien!
<aurelien>hello rekado!
<aurelien>hello rekado_!
<aurelien>sorry ... you are multiply -_-'
<rekado_>yeah, have to use the web interface here in the office because of a restrictive firewall...
<ams>hmph, can't figure out why nfs ain't working
<ams>what type follows the packages argument in the operating-system type?
<ams>the ref manual says little on that .. the example is a cons ... but how can one have multiple packages in that case?
<ams>"the set" can be read as a list, but that causes a crash ...
<ams>a better example of how to install x11 would be useful .. it is not clear at all how one does that
*taylanub didn't notice the discussion on gnu-system-discuss yesterday while talking about it here
<ams>civodul: you wanna take over gsd?
<taylanub>ams: "take over"?
<ams>become dictator of said list
<taylanub>a GSD list separate from Guix?
<ams>the gsd list has no relation to guix
<taylanub>we're talking about a mailing list?
<ams>i started it many many many moons ago as a dicussion fora for gnu system related work
<taylanub>I thought development of Guix and GSD would continue to be closely tied together
<ams>who said that they wouldn't
<ams>would rather bring things together a bit more, i am not interested in gnu system work anymore and haven't been for many years, ludo is.
<rekado_>taylanub: "gsd" here means "gnu-system-discuss", not "GSD" which means "Guix System Distribution" ;)
<taylanub>oh haha, that was confusing
<ams>ah, yes .. that is confusing :-)
<aurelien>nor Graduate School of Design
<ams>thought it was clear since you had just mentioned gnu-system-discuss!
<ams>i think gsd is a immensly stupid name, guix being much nicer ..
<aurelien>it have something funny in front BSD
<ams>renaming the package manager to something like, guix's manager of packages - gmop would make more sense, or even guix is not guix - ging ..
<ams>ging is not guix ...
<aurelien>best should to name it for what it is. (you should by the way know the response certainly better than me)
<aurelien>but for the fun ... GSD sounds good
<ams>not really
<rekado_>We're already past discussing names at this point.
<ams>i am happy that it is not my problem :-)
<rekado_>Is there a built-in alternative to using (system* "grep" "something" "somewhere") in a build phase?
<ams>rekado_: string-match?
<rekado_>ams: that would work when wrapped with call-with-input-file, thanks. I was actually hoping for something a little more concise.
<ams>dunno .. i'm a cl hacker not scheme..
<civodul>rekado_: yeah you would have to iterate over the lines of the file (assuming it's a text file) and regexp-exec them
<civodul>ams: you're talking about the admin of gnu-system-discuss?
<toothbrush0>hello everyone! question about lsh...
<toothbrush0>does one normally have to generate /etc/lsh/host-key manually?
<civodul>hey, toothbrush0
<civodul>toothbrush0: yes, either that or use (lsh-service #:initialize? #t)
<toothbrush0>Ah! Okay, thanks! I didn't see that when looking at the manual for lsh-service :/
<taylanub>hm, does the g-s-d ML reject non-subscribed address' mails?
<ams>no, it punts them until they get moderated
<toothbrush0>ah, is there a new mailing list i should subscribe to?
<civodul>not really, it's rather a mailing list to avoid
<toothbrush0>dare i ask why?
<ams>non-essential discussions about useless topics
<toothbrush0>i see.
<civodul>see to get an idea
<toothbrush0>ah right, i assumed it was a new guix-related ML after the guix name discussion
<toothbrush0>but i see what you mean.
<toothbrush0>unrelated: i'm still having some annoyances with $PATH: for example, i cannot do `sudo dhclient ..`, but i have to call `sudo /gnu/store/*-whatever/sbin/dhclient ..`
<toothbrush0>is this expected behaviour or did i do something stupid?
<civodul>toothbrush0: you probably need to install it in your profile
<civodul>with "guix package -i isc-dhcp"
<civodul>or to the global profile, via the 'packages' field of 'operating-system'
<toothbrush0>civodul: AH! thanks. i keep missing that bit :/
<toothbrush0>i was too much in the habit of doing `guix pack -i $thing`
*davexunit thinks about how to package web apps
<toothbrush0>also, is it not a good idea to make the #:initialize? thing default for lsh-server?
<civodul>not necessarily, because it's quite slow (needs entropy, etc.)
<civodul>people, you're welcome to help fix some of the remaining failures at :-)
*civodul plans to tag 0.8.1 tonight
<jxself>Sounds exciting.
*civodul makes suggestions, then goes afk for a while :-)
<rekado_>civodul: a "grep" helper that runs over a file line by line and returns #t when found seems generally useful. Instead of adding this to my IcedTea package as a local function could I add it to build/utils.scm instead?
<bavier`>rekado_: there's fold-port-matches in (guix build utils), does that do what you need?
<bavier`>hmmm, maybe not.
<rekado_>bavier`: it would be nice if there was a fold over lines in guile. Iterating manually and checking for eof-object is not pretty.
<davexunit>rekado_: does it make sense to fold over lines though? it's an imperative process.
<bavier`>davexunit: any more imperative that a regular fold?
<rekado_>davexunit: you mean because the cursor in the port is advanced?
<ijp>davexunit: directory fold
<davexunit>ijp: good point
*davexunit stands corrected
<ijp>I have a port-fold written, but I make the reader optional (defaulting to read-char)
<davexunit>an optional reader is good.
<davexunit>could you also specify when to terminate reading, defaulting to eof-object?
<ijp>bavier`: whether folds are "imperative" or not depends on what you mean by a fold
<bavier`>ijp: of course
<bavier`>we could probably use something like port-fold, or fold-port, in a number of places in guix
<ijp>what haskellers call a Traversable is more obviously imperative than a catamorphism
<civodul>rekado_: would be good in (guix build utils), but that's for core-updates
<civodul>ijp: speaking of fold, i'm in search of a combinator for DAG traversal, any idea?
<civodul>i've found a couple of papers on it, but nothing obviously appropriate
<ijp>well, I don't think there is a right answer in general, but in (pfds bbtrees) I wrote this overkill bbtree-traverse function
<ijp>in OO they call it "the strategy pattern"
<ijp>civodul: do you need to handle multiple connected components?
<ijp>the obvious idea is to do a topological sort and fold on that
<DusXMT>"We don't use the term "GSD"." seems like rms is going to have a lot of headaches if he decides to read this channel's log
*bavier` had to go off-network for a bit to test source prefetching.
<civodul>ijp: yes, there can be multiple connected components
<civodul>i'm not sure folding over the topological sort would work for what i wanted to do
<civodul>not sure
<DusXMT>I''m trying to build a very simple initrd for my system: No modules, only ext2fs tools, and only mount the root drive and boot from that... but I'm failing for some reason. I don't understand where the error is now...
<DusXMT>Here's my system definition: ; and here's the error log:
<DusXMT>It claims `wrong number of arguments', but it seems right to me... I just copied and trimmed down the default code of base-initrd
<davexunit>civodul: hilarious response to the ongoing g-s-d thread
<davexunit>I'm in favor of such a tax.
<civodul>it seems that all else failed, so...
<civodul>DusXMT: the 'initrd' field must be a procedure with the same signature as 'base-initrd'
<civodul>roughly: (lambda (file-systems #:key (mapped-devices '()) qemu-networking? virtio? volatile-root? (extra-modules '())) ...)
<DusXMT>civodul: hmm, I thought base-initrd returned the same thing as expression->initrd
<DusXMT>the same kind of object
<jxself>civodul: I like your tobin tax idea.
*DusXMT does too
<DusXMT>Oh, oh, now I see...
<civodul>yeah base-initrd is a procedure itself
<DusXMT>I thought it was an object field, I wouldn't have thought it was a function field... well, good to know
<civodul>eventually we'll have static type-checking in records
<mark_weaver>suggestion: rename 'dbus-system' -> 'dbus', 'xorg-server' -> 'xorg', 'avahi-daemon' -> 'avahi'.
<DusXMT>Excelent, it works! :)
<DusXMT>civodul: thanks for the help :) This makes me happy
<mark_weaver>for a long time, I had to sit there and think "is this one a daemon, system, server, service" ?
<mark_weaver>and it just seems silly that I should have to think about that. what do other people think?
*DusXMT agrees, although he's inexperienced
<civodul>DusXMT: glad to help :-) you can even remove the 'mlet'
<civodul>mark_weaver: you're probably right
<civodul>each time i'm like: what am i going to call it this time? let's make sure it's different from last time
<mark_weaver>haha :)
<civodul>the only downside with your proposal is a risk of name clash
<mark_weaver>hmm. not sure what other 'dbus', 'xorg', or 'avahi' services there would be.
<mark_weaver>but it seems to me that the short names would be given to the common ones. (not even sure what other ones to anticipate)
<civodul>there are packages with those names
<civodul>and i think it's common to have both the package and the service in scope
<mark_weaver>oh, I see. yeah, that's a drag
<mark_weaver>but I'm talking about the names passed to "deco".
<civodul>then yes, that's a different story
<civodul>we can changes those
<mark_weaver>cool :)
<davexunit>what's the story behind the name 'deco'?
<davexunit>maybe it's in the dmd docs and I missed it
<toothbrush0>hey, did anyone else have the problem where running Guix in Qemu with -vga std gives a colourful/garbled screen when Xorg launches? I'm still getting that...
<toothbrush0>davexunit: was also wondering about that, incidentally ;)
<civodul>see the section "deco and dmd"
<davexunit>civodul: thanks, I guess I just overlooked last time I read it.
<civodul>feel free to start a thread on g-s-d about the name of that command
<civodul>now that the tax applies :-)
<toothbrush0>civodul: hey, i didn't realise the tax applied to ANY naming discussion!! :p
*taylanub promises to pay the tax soon :P
<taylanub>leaving aside the whole 'promoting "GNU systems" over "Linux distros"' talk though, I'm worried about RMS's apparently firm stance against the "GSD" acronym :\\
<civodul>toothbrush0: it's like all taxes: once it starts working, you can't resist and end up extending it!
<jgrant>I mean, I don't get the fear. Mention "GNU GSD" en massse. Don't give people the chance to misassociate.
<jgrant>It's like people who think the G in the GPL is GNU, when if someone said the "GNU GPL" (which is it's proper and formal title) it eliminates this possiblility practically.
*jgrant will brb, feel free to respond he'll check the log. Wants to see if the kernel revisions in master fixed his issue to boot because of USB -- yesterday, or he still needs to file a formal bug report. o/
<jgrant>Yeah, same issue.
<jgrant>THe issue is too, I don't know if this is just something to do with my hardware or something tied to other factors/people as well. BUt since the actual GSD install base is so small currently, who knows? I certainly don't.
<jgrant>Like I don't know if I should file a formal bug for this, or revert a patch locally and leave it be.
<DusXMT>what's the issue?
<DusXMT>jgrant: ^
<jgrant>DusXMT: Since the USB autoloading patch yesterday for initd, I have rebuilt my config and all revisionary configurations past that of my initial working config -- now have an issue where at boot it says a systemlink is missing, tries to open a guile prompt, and then I get a whole bunch of calltraces for USB stuff.
<jgrant>After all the calltraces, it dies.
<jgrant>As in, no progress and essentially "freezes".
<DusXMT>jgrant: Do you have the system split on several partitions? (eg. independent /var partition)
<jgrant>DusXMT: Nope, I have a "bootscraps", "gsd", and "swap" partition. All GSD files are in "gsd" only.
<DusXMT>jgrant: What is in `bootscraps'?
<jgrant>DusXMT: It's my parabola partition I used to effectively bootstrap GSD from, using "guix system init etc etc".
*jgrant might just wait till 0.8.1 is released and reinstall from there.
<jgrant>Oh, it looks like 0.8.1 might get released tomorrow! :^)
*jgrant still needs to find away to tell his system not to have to have a CD that loads grub in it's diskdrive to boot GSD or any non-efi supporting distro on this box...
<jgrant>It's very obnoxious that I have to boot up, wait for the parabola disk to load, go to the "boot from existing OS" option, then start to deal with GSD.
<DusXMT>jgrant: this brings up a good question: How exactly do you boot GSD?
<DusXMT>(with exactly being a keyword)
<jgrant>DusXMT: Currently, via the method I mentioned. I assume I don't have sda2 set as "boot" and that's whyI've been doing this way. Have parabola install cd in drive, use parabola's grub from said cd to boot from the existing os, then it takes you to GSD's grub and it's "all good" from there.
*jgrant will brb.
<jgrant>Okay, the good news is that enabling the boot partition -- as I suspected, works now without having a cd in my diskdrive! The eh news, is it's still the same in that any reivison of my config past the initially provided, doesn't work still. :^P
<jgrant>So, guessing it has nothing to do with the boot method, but has something to do with either my device and/or the patch itself.
<jgrant>I'm probally not going to bugger much with it today, since assumingly based on the ML it lookt like 0.8.1 is going to get released tommorow at some point -- and I'll just go from there. :^P
<civodul>jgrant: do you still have the USB problem?
<civodul>could you post precise details of what's going on at boot time?
<civodul>i tested the change with those USB machines on two machines, FWIW
<jgrant>civodul: The only thing that I can see during boottime, is that there's a complaint of a missing syslink, then the prompt for guile tries to open, then a whole bunch of usb calltraces come back. Is there a way to store this bootup phase, somewhere? That's a lot to transcribe. Most of it is general calltrace complaints though (after guile's prompt attempts to load). Right before said prompt, is that missing symlink e
<civodul>jgrant: could you at least transcribe the "complaint"?
<civodul>to see which symlink is missing, etc.
<jgrant>civodul: I posted yesterday, let me pull it up on the logs. It was not clear, at all. Sec.
<jgrant> "ERROR: In procedure symlink: " followed by "ERROR: In procedure symlink: File exists".
<civodul>and you got a prompt there?
<civodul>could you try ",bt" at the prompt or ",locals"?
<civodul>that should show you the arguments to 'symlink'
<jgrant>civodul: I'm not sure if it was interactive or not. It seemingly didn't take any input.
*jgrant will try again.
<jgrant>Feel free to keep throwing suggestions, will check logs.
<jgrant> o/
<civodul>looking at activation.scm, there are just a few possibilities, i think
<xjgrant>Okay, on phone. Had to press enter before I could see any input but prompt works.
<xjgrant>,bt manifests... 0 (symlink "/proc/self/mounts" "/root/etc/mtab")
<xjgrant>,locals yields nothing.
<xjgrant>Is it possible this is due to being pointed to the wrong partition in my config?
<civodul>xjgrant: could you type: (stat "/root/etc/mtab")
<civodul>and (readlink "/root/etc/mtab")
<xjgrant>Thats the only thing I can thing I changed besides adding packages.
<xjgrant>No such file on first.
<mark_weaver>hmm, won't /root/etc/mtab exist after the first boot? seems like we ought to remove it first.
<civodul>mark_weaver: that's what happens, see linux-boot.scm
<civodul>xjgrant: and (stat "/root/etc")?
<civodul>i guess that could be the problem: this is not your root partition, and it has no /etc, hence the failure
<xjgrant>On the second, $1 = "../proc/self/mounts"
<mark_weaver>civodul: 'file-exists?' returns #false for dangling symlinks
<civodul>but you said (stat "/root/etc/mtab") raise a "No such file" exception
<civodul>xjgrant: ↑
<mark_weaver>(i just tested it)
<civodul>yes, right
<xjgrant>I am going to boot up on first working config, and ask if the disk pointing stuff looks alrighrt
<civodul>xjgrant: wait
<civodul>xjgrant: did (readlink ...) return "/proc/self/mounts" literally, or did it return "/foo/bar/proc/self/mounts"?
<mark_weaver>(false-if-exception (delete-file "/root/etc/mtab")) would be more robust
*civodul changes to false-if-exception
<civodul>still i'd like to know what that dangling symlink was
<xjgrant>readlink returned ../proc/self/mounts and stat on "/root/etc/mtab" said no such file or directory.
<xjgrant>Sorry, very hard for me to type on this phone...
<civodul>xjgrant: you wrote "../proc/self/mounts"
<civodul>do you mean that literally?
<civodul>ok, so that was the dangling symlink
<civodul>thank you, xjgrant!
<civodul>in summary: the problem is on your side :-)
<civodul>probably because you used the wrong partition or something
<civodul>you can work around that by typing 'e' on the GRUB menu entry and changing the --root value
<xjgrant>Okay, np. Will check config then in a few.
<mark_weaver>civodul: what do you suppose w
<mark_weaver>happened here?
<mark_weaver>same failure on x86_64 as well
*mark_weaver looks over the build failures
<civodul>mark_weaver: no idea, it definitely builds here
<jgrant>civodul: I mean, preferablly it's something that I want to handle on my end and not allocate grub to overwrite my probably poor configuration. :^P
<mark_weaver>civodul: the guix snapshot builds successfully, but not 0.8
<civodul>mark_weaver: ah yes, i see
<mark_weaver>I suppose it doesn't matter at this point, just curious
<civodul>that's because 0.8 didn't have the armhf-linux directory
<jgrant>SON OF A ....
<jgrant>That's what I get for using an old config.
<civodul>anyway that'll be fixed very soon as 0.8 is replaced by 0.8.1
<mark_weaver>ah, okay. I'm a bit confused why a change made after 0.8 would break the 0.8 build, but it's not important that I understand now :)
<mark_weaver>civodul: I see no mention of armhf in NEWS
<jgrant>Okay, it all works! Yup, all me; Sorry about that...
<jgrant>Pointed to the wrong parition, due to using an older config after the inital install.
<jgrant>Is there an easy way to list and delete these old configuration profiles?
*jgrant checks manual.
<mark_weaver>we don't yet have a command to list/delete the system-level profiles
<mark_weaver>but the relevant symlinks are in /var/guix/profiles/
<jgrant>Hm, a general "guix profile" set of modules might be handy then.
<mark_weaver>for now, I guess you could probably delete those symlinks by hand, and then the next time grub.cfg is generated it should remove them.
<jgrant>mark_weaver: Ah, okay.
<mark_weaver>but I haven't tried it myself
<mark_weaver>actually, I'm running low on disk space, so I might try that myself soon.
<mark_weaver>civodul: btw, in general, 'autoconf' phases should be put after 'unpack' instead of before 'configure', becuase otherwise the 'patch-usr-bin-file' phase doesn't fix the problems in configure and things will fail on MIPS and ARM.
*jgrant just did so, going to reboot and check what happened.
*mark_weaver fixes that problem in the guile-ssh package
<civodul>mark_weaver: oh right
<civodul>mark_weaver, jgrant: yes, the current "user interface" is to remove old 'system-N-link' symlinks by hand, and then 'guix system reconfigure' will notice
*civodul tries out guix-web master
<civodul>davexunit: is the "install" button phony?
<xjgrant>Mark, you bastard. :-) Not only did it not remove the entries, but I acidently selected a non valide entry and the whole system had a kernel panic!
<xjgrant>Cant even shut down, manually.
<DusXMT>xjgrant: Did you `guix system reconfigure' before rebooting?
<xjgrant>Ah, true.
<DusXMT>If not, it's your fault, grub.cfg won't just magically change on some disc activity :)
<xjgrant>Thats not very ideal then, because it still creates a new profile.
<DusXMT>2 identical profiles - all containing simlinks to the same, not that terrible
<civodul>davexunit: there are incorrect "/package/foo" links in some places (should be "/packages/foo", plural)
<DusXMT>s/same/same packages/
<davexunit>civodul: sorry, I haven't hacked on that in awhile.
<xjgrant>In any case, have to wait for this laptop to die now... Its deaigned so idioically that you cant remove the battery without taking off the whole case...
<davexunit>the install button might be phony now on the latest guix.
<xjgrant>Not worth it, to search for this special screw bit.
<davexunit>I haven't updated and fixed any API breakage.
<DusXMT>xjgrant: how about CTRL+ALT+Delete ?
<davexunit>civodul: sorry that guix-web sucks right now.
<xjgrant>In a kernel panic?
<DusXMT>Can't you hold the power button for 6 seconds?
<civodul>davexunit: it doesn't "suck", it's promising!
<xjgrant>I held it for a minute. Nothing.
<DusXMT>Then that's one awkward laptop...
<xjgrant>I hate this laptop, for a number of reason... But I try not to punch gift horses that much.
<xjgrant>As in, it was literally a 700$ gift from my parents.
<davexunit>civodul: thanks, I hope to revisit it some day and make the package list work more like guix.el
<davexunit>so you can mark many things for installation/upgrade/removal
<xjgrant>Worse comes to worst, Ill go forward with my inital plan to reinstall GSD as of the release of 0.8.1. In any case, this has been a helpful excercise to get me a bit more familiar with some general workings of Guix.
<xjgrant>Also, typing on a software keyboard. :-)
<zacts>hi guix geeks
<mark_weaver>hi zacts
<mark_weaver>civodul: fwiw, in general, I don't think we should remove a platform from 'supported-systems' just because it doesn't build currently, unless it seems almost hopeless. (racket comes to mind)
<civodul>mark_weaver: i agree
<mark_weaver>actually, racket would likely build just fine on a MIPS box with 16K pages, as is commonly done.
<civodul>for Racket, it's an upstream problem
<civodul>well, dunno, but it looks like something is wrong upstream
<mark_weaver>I decided to take on the task of trying to support page sizes up to 64K on MIPS.
<mark_weaver>but it seems like all the other distros just use 16K pages because it avoids such problems.
<mark_weaver>and actually, since I'm losing interest in MIPS, I might give up on 64K pages for now at least.
<mark_weaver>but yes, it is an upstream problem
<zacts>hum.. that sucks. I hope they fix racket, as I use it
<mark_weaver>well, it only affects MIPS boxes
<zacts>oh I see, ok
<mark_weaver>and probably only MIPS boxes running with 64K page sizes (a kernel compile-time option)
<zacts>so an esoteric upstream issue
<mark_weaver>almost everyone uses 16K page sizes on MIPS
<mark_weaver>bavier`: the python-pillow package has been broken on all platforms for a long time, and it's causing several other dependency failures as well. could you take a look?
<mark_weaver>lots of test failures
*civodul wonders about the number of people using Racket, installed from Guix, on a 64k-page MIPS box
<civodul>and how many among these speak Esperanto and contribute to the Hurd?
<civodul>(it may well be that the answer is more than one!)
<bavier`>mark_weaver: sure
<mark_weaver>civodul: haha
*mark_weaver wonders if anyone actually uses MIPS on guix at all, other than me. and I'm about to phase it out.
<civodul>i know of a few free software supporters who still have a Lemote laptop
<civodul>but it seems it won't last long
<mark_weaver>That xorg-server actually builds on MIPS, it might not be hard to make a variant that works on the YeeLoong, but I'm kind of unmotivated.
<mark_weaver>*Now that
<mark_weaver>I tried applying the relevant patches I had around, but xorg-server has changed so much since then, it was not obvious to me how to adapt it.
<mark_weaver>but the parabola folks might have fresh patches
<rekado>Compiling JACK2 with dbus support I get this warning about the dbus session services directory.
<rekado>The service uses /gnu/store/xxx-dbus-xxx/share/dbus-1/services
<rekado>but JACK2 installs its service file in /gnu/store/xxx-jack-xxx/share/dbus-1/services
<rekado>Is dbus configured such that it can find these service files?
<mark_weaver>rekado: in your OS config, 'dbus-service' takes as an argument a list of packages that contain service files.
<mark_weaver>if you need it to be accessible from the system dbus, that's where you need to put it.
<mark_weaver>not sure off-hand about per-user dbus
<rekado>IIUC JACK2 provides a service that listens for JACK clients and starts up jackd automatically while these clients are running.
<rekado>I don't have an installation of GNU GSD to test this, though.
<rekado>not important; just a warning I didn't want to ignore immediately.
<mark_weaver>rekado: the warning is expected, so I wouldn't worry about it for now. at some point we'll have to test it though.
<civodul>rekado: i noticed problems with the session bus as well
<civodul>the .service files not found, namely
<civodul>i think we need to have /etc/dbus/session.conf, we can't avoid that
<civodul>that's doable but i didn't feel like doing it before the release
<jgrant>Okay... everything up, running, and to my liking. \\o/
<jgrant>Ty everyone.
<civodul>good to hear!
<toothbrush0>jgrant: i'm a bit of a voyeur; do you mind posting your config file? I'm still struggling to get a happily usable system running ;)
<jgrant>toothbrush0: Yeah, sec.
*jgrant plans to formally have this and all his other configs up on his gitlab by the 1st of Feb, but yeah, fully willing to share what I have thusfar. :^)
<toothbrush0>hehe, i understand
<toothbrush0>mine's on github, but it's embarrassingly close to the doc-example
<jgrant>toothbrush0: Mines actually pretty close to the doc's too. Most of the actual work I've done formally, has been trying to get my packages to line up to what I was used to on my Fedora install. It's probably going to morph to into something relatively different relatively fast as this is now my day-to-day driver (GSD is on my main laptop) ... but, this is what I have thusfar.
<toothbrush0>thanks, jgrant
<toothbrush0>i'll have a look at that then..
<toothbrush0>i haven't taken the step from VM -> real machine, but i'd kind of like to
<toothbrush0>i'm just afraid it'll be too difficult :p
<jgrant>toothbrush0: I do reccomend you use my macros or use-module in yor config file if you aren't already.
<jgrant>It's a /lot/ nicer and more condensed than going a (use-modules (gnu packages whatever)) a thousand times.
*mark_weaver puts very few packages in his system config, preferring instead to put most of them in his per-user profile.
<toothbrush0>you mean the `(use-package-modules ...)` bit?
<mark_weaver>so I don't end up having to add many packages there at all
<toothbrush0>mark_weaver: but isn't it nice to have a VC'able config?
<toothbrush0>or how do you deal with that?
<mark_weaver>VC ?
<toothbrush0>sorry, version control
<jgrant>mark_weaver: I mean, until we get a "guix user" it's just easier for me to put it all in one config.
<jgrant>toothbrush0: The install really isn't that bad, just make sure the hardware you need is supported and too the software stack you need/want is there.
<mark_weaver>I don't mean to imply it's wrong to put everything in the system profile. to each his or her own :)
<mark_weaver>it's just not what I do.
<toothbrush0>mark_weaver: fair enough.
<mark_weaver>I agree that having the set of user packages in some kind of configuration file would be a nice option to have.
<toothbrush0>i like the idea of having my installed software trackable somehow... as in, should i ever need to do a fresh install i won't find myself going "oh yeah i still need that package" a week later
<toothbrush0>mark_weaver: yeah that's all i'd want
<toothbrush0>jgrant: wifi is the huge stumbling block there... :/
<toothbrush0>maybe i should buy a usb dongle.
<mark_weaver>toothbrush0: your current wifi requires a blob?
<toothbrush0>yeah it's broadcom filth
<toothbrush0>boss's decision
<jgrant>mark_weaver: Yeah, I think your perefered method is better -- I just don't think it's worth the effort until we get somefactor of "guix user" system in place to split my config/workflow in such a way.
<toothbrush0>what would guix user do, if i might ask a silly Q?
<jgrant>You can get a thinkpenguin, Wireless-G extrenal card for like 50$. That's what I have.
<toothbrush0>*`guix user`
<jgrant>toothbrush0: Instead of "guix system reconfigure" that deals with the whole store and system config -- you'd be able to do per-user configurations in the same way you'd be able to manage the system's config.
<toothbrush0>i see
<toothbrush0>sounds nice in principle!
<jgrant>So "guix user reconfigure .guix.d/jgrant-config.scm" would update your config not system wide, but specific to that user.
<jgrant>Or similar.
<toothbrush0>but (naive question warning) isn't it reasonable to have userland packages (emacs and texlive come to mind) available for any account on a box?
<mark_weaver>I agree there is room for improvement here, but I don't find it very difficult in practice to copy my user profile to another machine, and I don't do it very often.
<toothbrush0>ah yeah and then the manifest takes care of the rest, right?
<mark_weaver>'guix package -I
<jgrant>toothbrush0: It wouldn't replace the option for the root user to manifest whatever in their config for the system. You could still include emacs, texlive, whatever provided by the system/.
<mark_weaver>"guix package -I | cut -f1" will give you the list of installed packages, although it omits version numbers and output names.
<mark_weaver>but that picks up the vast majority of packages I've installed, suitable for passing to "guix package -i" on the other machine.
<toothbrush0>vast majority → exceptions exist?
<mark_weaver>not ideal, but it works well enough that improving it is low on my priority list :)
<toothbrush0>sure, i can imagine :)
<mark_weaver>well, the "cut -f1" chops off the version number, so if I deliberately wanted an older version of something, that gets lost.
<jgrant>How long has GSD been bootable now, around 6 months?
<mark_weaver>and it also chops of the specific output that I want, so e.g. if I install "guile:debug" then it will just come through as "guile" on the other end.
<jgrant>I think it was 0.6, right?
<jgrant>In any case, it's came a pretty long way in a pretty short period of time -- from what I can tell.
<mark_weaver>civodul: maybe not important, but did you notice that we picked up a bunch of tags from Nix's git repo? shown in
<civodul>mark_weaver: yup, sorry about that
<civodul>i just removed them
<civodul>i keep learning about Git ;-)
<mark_weaver>okay :)
<jgrant>Oh yeah, regarding Nix. Isn't there a way that it's supposed to be possible to install Nix pkgs via Guix?
<mark_weaver>learning git is a long process :)
<jgrant>I want to circumvent Ratpoison for now, and "cheat" to get to Stumpwm.
<toothbrush0>jgrant: apparently we're not allowed to say GSD
<jgrant>toothbrush0: Link?
<toothbrush0>ok, sec.
<toothbrush0>also, i should add: ":p"
<jgrant>Wait, are you talking about the bit from like a week ago from RMS?
<mark_weaver>I love RMS and respect him very much, but I don't think he really has a right to dictate this, especially since the reasons he gave were rather weak.
<jgrant>Or is there somethnig new.
<mark_weaver>IMO anyway
<jgrant>mark_weaver: They were, the G in GSD could be confused with GNU and that the name GSD might be seen as a slight against BSD right?
<jgrant>That's what I remember.
<toothbrush0>perhaps the subject is too sensitive and the discussion too recent for me to poke fun, sorry about that.
<mark_weaver>jgrant: right, and I think calling it GNU GSD takes care of the first one.
<toothbrush0>it's just so _tempting_
<jgrant>mark_weaver: Agreede.
<mark_weaver>ah, 0.8.1 is tagged
<jgrant>mark_weaver: Wasn't it for several days?
<jgrant>Oh, evidently I don't know terminology.
<jgrant>I meant the snapshot image or similar was updated to 0.8.1 a few days ago.
<jgrant>mark_weaver: Yeah, just read over the linked ML post toothbrush0 sent and it looks like RMS is relatively steadfast on this though...
<jgrant>mark_weaver: Secs.
<mark_weaver>look at what it was changed from and to
<jgrant>My mistake.
<jgrant>Explains why Guix --version was pooping out 0.9 the other day.
<jgrant>Yup, 0.8.1 now on my end.
*mark_weaver goes afk
<toothbrush0>DusXMT: mind me asking which flags you use to start qemu-system-x86_64?
<toothbrush0>(i'm currently staring at your config)
<mark_weaver>toothbrush0: guix system vm creates a script you can just run to start the VM
<toothbrush0>i'm mainly curious about the argument -vga ..
<toothbrush0>since i'm having video troubles.
<civodul>rekado: on the logo, i think we should actually keep the same alignment as before--i.e., remove the baseline without changing the relative position of the "spiral" and the text, WDYT?