IRC channel logs

<tadni_>Hydra is stalling again.

<xjgrant>Yeah, Guix really needs a better system for hsting.

<xjgrant>If that's a better server or different build and host method. I dont know.

*jgrant_ needs to look into how one would write a (keyboard-layout 'whatever) for GSD.

<mark_weaver>jgrant_: yes, we need something like that. out of curiosity, what changes do you want to make?

<mark_weaver>(in my case, I want to change caps lock to control)

<jgrant_>mark_weaver: Generally, being able to set Dvorak, Colemak, etc; But yes, more fine-tuned thing would be great.

*jgrant_ is too a big caps-lock control keyyer.

<jgrant_>Also, Hydra is stalling for me again.

*mark_weaver just noticed that on his YeeLoong (custom built distro with guix on top), his log files were getting rather large. kern.log and messages are about 12 gigs each. never got around to installing a log rotator :)

<jgrant_>I mean, could we just store whatever in a var and deal with it there? Like (define keyboard-layout 'colemak '("Caps Lock" "Left Ctrl")) or somkething?

<mark_weaver>syslog too. wow, but cleaning this up, I'll quadruple my free space. and here I've been poking at /gnu/store :)

<mark_weaver>s/but/by/

<mark_weaver>jgrant_: questions for civodul

<mark_weaver>probably best raised on the mailing list

<mark_weaver>or maybe a [wishlist] ticket sent to bug-guix@gnu.org, so it won't be forgotten

*jgrant_ will probably wait ttill tomorrow for Hydra, because he's not having luck on this new and dedicated install right now...

<jgrant_>Do we have a feature wishlist on Libreplanet? I know we do for packages.

<jgrant_>Might be worth it.

<mark_weaver>I think our ticket tracker is a better place for this, I think.

*jgrant_ marked down a note.

<jgrant_>Okay, Hydra is making some progress now!

<jgrant_>Well ... on and off, but it certainly made progress.

<jgrant_>Are the problems with Hydra tied directly to hardware limitations on the instance's end?

<mark_weaver>it's an overloaded virtual machine

<jgrant_>Like, it's not something "guix publish" would magically cure right?

<mark_weaver>we're looking into dedicated hardware for it.

<jgrant_>Ah, okay.

<jgrant_>If y'all run a fundraising drive, I'd thrown in at least 20 USD.

<mark_weaver>however, right now it's not loaded at all.

<mark_weaver>what problem are you seeing?

<jgrant_>It is a lot better than an hour ago for me, but sometimes it'll be stagnant for like 10-20 mlinutes grabbing subs.

<mark_weaver>it's not loaded right now because the only builds in progress are on MIPS right now, and most of the time there is just spent waiting for the slow MIPS machine to build stuff

<mark_weaver>wow, I haven't seen that before.

<mark_weaver>well, what do you mean by "stagnant"?

<jgrant_>Like, it doesn't even say it's unresponsive -- just no movement with an arbitrary amount of bits downloaded.

<mark_weaver>you mean it stops in the middle of a transfer for 10-20 minutes before continuing?

<jgrant_>Sorry if I'm taking awhile to respond, it's messing with me using Qwerty again...

<jgrant_>mark_weaver: Yeah.

<mark_weaver>I don't know what "just no movement with an arbitrary amount of bits downloaded" means.

<mark_weaver>where do you live?

<jgrant_>Like Perl has been stuck at 9192.0 KiB for like 8 minutes now.

<jgrant_>mark_weaver: Saint Louis, MO, USA.

<mark_weaver>I don't remember that happening to me, ever.

<mark_weaver>strange.

<mark_weaver>what version of guile did you use to build guix?

<jgrant_>I would just build from source, but it'd take like 2-3 days to finish on this ol box.

<DusXMT>jgrant_: try pinging it, perhaps you have packet loss with it?

<mark_weaver>oh, it's a very old box. hmm.

<mark_weaver>8 minutes is quite extreme though.

<jgrant_>mark_weaver: I'm using Guix's 0.8 distro, so I'm assuming 2.0.11

<jgrant_>It wad low end, like 5 years ago.

<mark_weaver>jgrant_: oh, the standalone distro?

<jgrant_>Yeah.

<mark_weaver>okay

<mark_weaver>how much RAM in the machine?

<jgrant_>DusXMT: 0% packet loss.

<jgrant_>mark_weaver: 1 gb.

<jgrant_>Also, I think a Celeron.

<DusXMT>Idon't think it's because of machine age, I've ran Guix(otic) on a Pentium 3 machive with 512M of ram, and substitutes worked no problems

<jgrant_>Yeah, I'm dubious that's the issue.

<jgrant_>Still on Perl though...

*jgrant_ is considering stopping and starting the config build again.

<mark_weaver>what does 'free' output?

<jgrant_>Ping?

<jgrant_>Hm?

<mark_weaver>?

<jgrant_>Oh, sorry -- tired.

<jgrant_>700 mb of 1GB used.

<mark_weaver>show me the -/+ buffers/cache line

<jgrant_>Sec, need to type. In Cli only.

<mark_weaver>well, nevermind, I need to sleep and am grasping at straws anyway. but fwiw, I've not had this problem, and I haven't heard anyone else report it either. strange

<jgrant_>mark_weaver: That's fine, ty though. I'm going to let it run and see if it's done when I wake up, and proceed from there.

<mark_weaver>it's possible that updating to a more recent guix will help.

<jgrant_>WOOOOOOOOOAH.

<mark_weaver>(i.e. after you "guix pull" and "guix system reconfigure")

<mark_weaver>jgrant_: what?

<jgrant_>I think the display was somehow frozen, I switched back to the tty, pressed enter and my display jumped to the bottom and was done/complteted...

<jgrant_>I did this before and this didn't happen, so...

<mark_weaver>ah, interesting.

<mark_weaver>well, good night and good luck.

*mark_weaver --> zzz

<jgrant_>mark_weaver: o/

*jgrant_ will probably in a few too.

<fchmmr> http://gleane.org/guix-gluglug.html

<fchmmr>The usability issues mentioned here with libreboot have now been fixed, and will be in the next release.

<fchmmr>Libreboot now automatically searches for /boot/grub/libreboot_grub.cfg on the HDD and switches to that if it exists (which guix could make happen, automatically, or the user can place their own config there).

<fchmmr>The "Search for local GRUB" menuentry now also looks in USB drives aswell as the main storage, so there is now an automated way to boot the Guix USB installer in libreboot

<fchmmr>The manual interventions listed on that page are no longer necessary.

<fchmmr>(or will no longer be necessary. I need to push my local git commits first).

<fchmmr>mark_weaver from this channel is the person who I worked with on this.

<fchmmr>Notes about this will be in http://libreboot.org/docs/gnulinux/grub_boot_installer.html and http://libreboot.org/docs/gnulinux/grub_cbfs.html#libreboot_grub_config_ondisk after the next release.

<civodul>Hello Guix!

<civodul>iyzsong: you here?

<mark_weaver>thank you, fchmmr!

<mark_weaver>hi civodul!

<civodul>hello, mark_weaver

<civodul>thanks to fchmmr & you for coming up with a pleasant solution for libreboot!

<mark_weaver>civodul: not long before you logged in this before, fchmmr sent some messages here about improved support for guix in the imminent release of libreboot

<mark_weaver>glad to help :)

<fchmmr>mark_weaver, he knows. I PM'd it to him.

<mark_weaver>excellent!

<civodul>hmm i have an util-linux here, but i realize 242 packages depend on it

<civodul>oh well, that's probably OK

<mark_weaver>there are also new versions of sharutils, bison, and patch

<mark_weaver>anyway, I have to go afk for most of the day. happy hacking!

<civodul>ttyl!

<bavier`>speaking of package updates: our perl is fairly out of date.

<civodul>bavier`: that's also a core thing, but we could provide a second perl in the meantime

<bavier`>civodul: I've been able to package separate up-to-date modules where necessary (I think only 4 or 5 so far), so not a real issue yet.

<bavier`>btw, last I counted, 145 new perl modules packaged for hydra.

<civodul>bah!

<civodul>you're going to flood us! ;-)

<civodul>maybe it'll be better to not even bother posting them to the list

<civodul>and with 145 modules, there are still some missing?

<bavier`>yeah, I didn't realize the scope of the work on outset

<civodul>:-)

<bavier`>yes, I'm guessing there's at least another 40-60 missing.

<civodul>woow

<bavier`>there are a few patches I'll submit to the list, but the majority could probably just be pushed.

<civodul>yes

<bavier`>e.g. I modified the perl-build-system so that it'll build modules that don't use MakeMaker.

<civodul>we'll be able to market it as the distro of Perl hackers :-)

<civodul>ok

<bavier`>ha

<bavier`>and I feel uneasy about the way module dependencies are handled.

<bavier`>it seems in most cases that inputs have to be propagated in order for a module to find those inputs at runtime

<bavier`>python has a method we've used where a package can add directories to python's search path

<civodul>i think it's the same pattern for both Perl and Python no?

<bavier`>I'm not much of a perl hacker, and the only method I've seen for perl to accomplish the same is to embed statement in the module source files.

<bavier`>'use lib </path/to/input/modules/...>'

<bavier`>if that's the only available method, we might be able to safely inject such statements into the module source

<bavier`>not ideal, really, because it would make store compression useless for perl packages.

<civodul>but for Python packages, we don't do anything special, do we?

<bavier`>I don't think so

<bavier`>but there are many cases where inputs are propagated

<civodul>right, so the problem is not Perl-specific

<bavier`>well, no, easy-install creates the pth files.

<civodul>i think it's the same story for all "source-oriented" languages

<civodul>ok

<civodul>but do pth files record dependencies?

<bavier`>and those pth files tell python how to augment the search path for a package

<civodul>ah ok

<civodul>so that's some sort of a RUNPATH-like mechanism

<bavier`>yes

<civodul>for Guile and probably Perl, there's no RUNPATH-like mechanism

<bavier`>so the only method for guix to deliver those dependencies at the moment is to have the inputs propagated.

<civodul>yes, i think so

<civodul>i agree it's not great

<civodul>you're building foo, so you're like "let's update bar while waiting"

<civodul>and then "oh, but let's update baz while it compile"

<civodul>and so on

<bavier`>civodul: that's a familiar feel

<jgrant_>Are the certs needed for git now packaged/working? I just cloned into it from git, on GSD and it didn't prompt me and started transfering. Almost done cloning too.

<jgrant_>Yeah, just suceeded.

<jgrant>Yeah, even with "guix environment guix" -- setting up a guix based development environment in GSD is /far/ too bothersome.

<davexunit>how? that literally takes care of all the dependencies

<jgrant>davexunit: Issues with autoconf, gettext, etc, not being grabbed.

<davexunit>it grabs autoconf

<davexunit>unless the 'guix' package is not the development guix package anymore

<jgrant>Well, when I tried to grab guix from the shell environment -- it complained about autoreconf, then gettext, then some pkgconfig variable missing.

<davexunit>something is broken, then. it shouldn't.

<jgrant>Also, I'm considering saying bork off on a separate machine till I get some of the remaining bits of my software stack handled. Lack of Stumpwm, is a huge pain for me.

<davexunit>ratpoison :)

*jgrant is probably going to go full vm for now.

<jgrant>davexunit: I can't, it drives me nuts. My Stumpwm config is fairly far from default ratpoison and I don't have enough effort to reimplement everything in bash, C, or whatever ratpoison uses for simple keybindings. :^P

<davexunit>yeah I hear ya

<jgrant>I mean, maybe if I were to expect to use Ratpoison anywhere/when else than early GSD ... I just don't see it.

<jgrant>:^P

<davexunit>gotta get clisp and/or sbcl packaged

<jgrant>davexunit: Yeah, I was looking into libffcall for CLisp the other day, we ran into a build issue (me and mark_weaver) and it's something to do with how old the last release was...

<jgrant>And SBCL, would need to do some GCC like bootstrapping of itself to build itself from binary.

<jgrant>from a binary*

<davexunit>yeah

<davexunit>SBCL is an interesting monster.

<davexunit>same issue as freepascal

*jgrant still thinks there could be a case to be made for a "guix develop" or similar; For development on GSD. Having a separate profile you can pollute, would be nice for hacking on Guix I think. Too, being able to go from a brand new install to "guix develop new guixdev-stumpwm" and go from there, without having to work via ./pre-inst-env might be nice.

<jgrant>:^P

<jgrant>I don't know, I'll look into it more when either Guix gets closer to 1.X and/or when I get a lot more familiar with Guix.

<davexunit>jgrant: I plan to extend guix environment to build VMs and such for development

<davexunit>you'd have to work ./pre-inst-env no matter what

<davexunit>if you're developing in the tree, you need it.

<davexunit>this only applies to guix, of course.

<davexunit>I don't have any plans to use profiles

<jgrant>davexunit: Eh, ./pre-inst-env is mostly irrelevant I guess.

<jgrant>Just trying to brain store what would be generalities that could be simplified, developing for Guix against on/in Guix (or GSD (or whatever)).

<jgrant>brainstorm. *

<davexunit>profiles seem like unnecessary complexity, because there's no real reason to protect things from the GC or do rollbacks.

<jgrant>davexunit: I was thinking, more-so, that it'd be trivial to get rid of a whole profile when someone was done with it, etc. Or you have an "origin" guixdev profile, and you make copies from where you modify it. Again, conceptualizing when I probably don't have enough background to do so tactfully... :^)

<davexunit>the nice thing about the way it is now, is that when you exit the shell that's created, you're done with it :)

<davexunit>and creating the environment should get faster with time. civodul improved the speed a bunch recently, but I bet we can make it faster still.

<jgrant>Like, once you close the environment via the shell you used to call it -- such things are gone from your profile?

<davexunit>they are never in your profile to begin with.

<davexunit>it doesn't use profiles at all, like nix-shell.

<davexunit>sorry, that was confusing. nix-shell also does not do this, and 'guix environment' is our version of nix-shell.

<jgrant>It's just somewhere in the ether, and doesn't ever get stored anywhere definitively?

<davexunit>it just modifies your $PATH and such to point to all of the /bin, etc. directories of the depencies in the store.

<davexunit>dependencies*

<jgrant>Ah, okay.

<davexunit>I want to extend this to create temporary VMs

<davexunit>that share the hosts /gnu/store and the source tree you're working with.

<davexunit>and maybe other things like databases. not sure how that will work.

<jgrant>Going afk for now, going to attempt the VM build.

<davexunit>good luck

<jgrant>Right when I was going to send civ a query.

<jgrant>Should, http://git.savannah.gnu.org/cgit/guix.git/commit/?id=de71cc4f83977000addf7cacf47bcc26f16725c6 of been "GSD-usb-install" not "Guix-usb-install"?

<jgrant>Well, obviously it should be whatever the actual image is ... I mean, shouldn't the image it is referencing be GSD or whatever said system would be, not to confute people?

<jgrant>GSD has more information anyway, saying explicitly it is the distribution.

<jgrant>Oh, cool, sneek's back.

<jgrant>sneek: help

<jgrant>sneek: later tell civodul: Hey, just saw the commit updating the location of the new image of the distribution "guix-usb-install". Shouldn't it be "GSD-usb-install", so it doesn't confuse people? GSD explicitly says it's a system distribution and is more/or less the decided on or "good enough" name. :^P

<sneek>Will do.

<jgrant>I am excited that Guix is starting to go to X.X.X styled releases, to give us more time till we hit 1.0. :^) Heard about that plan on the ML, glad to see it's starting to be put into action.

<jgrant>Anyways, enough chanspam from me. Going afk again; probably till this vm pass or fails. o/

<jgrant>Okay, VM built and runs. The vm says my store is read-only though. Should I have made a disk-image instead, if I wanted to do devel in it?

<grasshopprWhoppr>jgrant, did you see that the acronym is not "good enough"? neither should /gpl/ since everyone confuses /general/ with /gnu/

<jgrant>grasshopprWhoppr: Link?

<grasshopprWhoppr> http://lists.gnu.org/archive/html/gnu-system-discuss/2015-01/msg00047.html

<jgrant>Also, I don't think that should be an active concern. It's actively stated as "GNU GSD", just like the GPL should be refered to the the "GNU GPL".

<jgrant>This is just bordering insane and inane at this point.

<jgrant>Also, GNU is not Unix is a playful Jab at Unix; I don't think if GSD could be taken as a jab -- that it'd be anything but playful too. So the second bit, I see completly unfounded.

<jgrant>The first bit, then, basically we aren't allowed to use acronyms that start with G because it may be associated to mean GNU?

IRC channel logs

2015-01-23.log