***Svetlana__ is now known as svetlana
<zacts>perhaps, I'll try putting guix on my server box again tonight. <zacts>I really would like to contribute to guix ***svetlana is now known as Svetlana
<Svetlana>I asked a grub question earlier, about finding what usb0 is. <Svetlana><Svetlana> <davexunit> try: set root=<pause-here> <davexunit> in the place I wrote <pause-here>, press TAB <davexunit> grub should print a list of devices <Svetlana><Svetlana> that lists the fs to me, the / ... like ihave no idea where to find usb0 there ... i only know it's /dev/sdb ... "configfile(0,/dev/sdb)/boot/grub/grub.cfg" ? i doubt that is right <invergo>I'm trying to package something but 'guix download' keeps throwing a "Bad date header" error. Anyone else encountered that? <phant0mas>what happened to our lovely bot sneek? I don't see it around <phant0mas>it think it crashed like 3 days ago so I thought it should have been brought back online by now <jxself>I'm not sure who is in charge of our venerable bot sneek. Perhaps they haven't noticed and need to be poked at to gain their attention? <Steap>Isn't mark_weaver "in charge" of sneek ? <Svetlana>if someone could please tell mark_weaver about my question when he comes here it would be adorable <ijp>you could use memoserv <Svetlana>I memoserved then; I think he's not appeared here for a few days for some reason <davexunit>Svetlana: he's been busy with a housing move. <jmd>Is it possible to specify two source tarballs for a package? <Steap>jmd: not sure, but we use mirrors to have multiple places todownload from if necessary <davexunit>I think you can specify multiple tarball locations <Steap>you have "(uri (list (...)))" <davexunit>yeah, that was the example I was looking for. good job, Steap. <jmd>Nah. I have a package which can only reasonably be built with the union of two tarballs. <davexunit>there's likely a way to modify the build system to do what you want, but I don't think it's been done yet. <jmd>colamd and suitesparse <jmd>They are "designed" so that to build the former, one has to unpack both into the same directory. <davexunit>ah, well I guess you could set the source field such that both origins are there. <davexunit>then you can modify whatever phase of the gnu-build-system downloads and unpacks the tarballs <jmd>I've never got so deeply into it before. <davexunit>I haven't tweaked those phases before, so I can't really be of much help. <jmd>It doesn't seem that a list of origins is valid. <jmd>I wonder how I could make a kindof "raw" package - input is copied straight to output? <zacts>davexunit: I was going to ask you how you configured fish + M-x ansi-term <zacts>but I'm using zsh with fish-like extensions now <davexunit>I must confess that I'm not good at using ansi-term <zacts>I've configured zsh to behave and look like fish <davexunit>I can never get term, eshell, or ansi-term to work well for me. <zacts>ah, so you use rxvt / xterm or something? <zacts>ok, so for guix.. can I port programs purely to the guix package manager, or must I test it out on guix OS? <davexunit>it's best to test with a shell that has it's environment variables set to only use things in your .guix-profile <tadni>davexunit: Well eshell is just a shell, not a termemu. :^P <zacts>tadni: I mean the guix as a distro <zacts>must I test my imported packages within a kvm guix vm for example.. <tadni>zacts: Guix as a distro, is still "GNU OS" according to Ludo. <tadni>Maybe if you are sharing your store with the host box it can/would be refered to something else, but I wouldn't think so. <tadni>I've heard a suprising amount of kickback of calling the dmd/guix powered distro just "GNU" though... <davexunit>zacts: it's not strictly required. if you test it there, great, but if you test it out on your host system, that is fine too. <tadni>davexunit: Like 3 in #emacs thought it was something along the lines of "stupid and confusing". <tadni>Basically it being a subset of the GNU project and not the GNU project itself, so it shouldn't have the same name. <davexunit>well they can bring that up with ludo, I guess. <tadni>I mean, I kind of had that same thought process when I heard about the seperate distro intially. In fact I believed I pitched "GNU Wave or Jitsu" or something ... but I mean, the more I thought about it, it's really not that confusing. And for like 90+% of users, I doubt they would care. <zacts>I put my vote in for calling it zactsOS <tadni>My Little GNU: Guile is Magic. <zacts>Gnu guix-gui-gu-g-gu-gui-guix <- a palindormatic OS <davexunit>the folks in #emacs can be a rude bunch, so I'm not surprised they said "stupid and confusing" <tadni>davexunit: Paraphrasing, but it certianly had that vibe. <tadni>I'm still shocked so little of the GNU community know about the distro -- though I guess, it's not being actively advertised, and for the time being, arguably for good measure. <davexunit>and tbh, a lot of GNU folks seem to be too resistant to new ideas. <tadni>I mean until me or someone else gets wicd or some system for wifi easily hatched and maybe openbox or the like, I can't see it being ready for even most "technical" users. <davexunit>I can imagine a lot of folks will say: why use the GNU system when we have Debian? <jxself>Why use Debian when we have GNU? :) <tadni>davexunit: That's people in general -- resistant to change in-terms of computing id a big hurdle. <davexunit>it's definitely a hard sell in some ways: let's repackage everything using our special package manager instead of using what's already out there! <tadni>I'm hoping with the systemd news in Debian and the effort to get the Hurd working with Guix, that we will at least get the developers of Debian Hurd to mostly transplant. I'd consider that a big win. <jxself>Perhaps a DEB/RPM importer thing could be helpful: Read such a package, spit out the appropriate stuff for Guix. <tadni>davexunit: I think the bigger sell, is to get individuals concerned with "stability" to try a rolling release distro. <davexunit>jxself: yeah, I think so. I cannot see a way to make a complete guix programmatically from them, but it could get the basic stuff out of the way. <davexunit>tadni: yeah, but guix isn't like any rolling release I've seen before. <zacts>that's why I use slackware, for now. it is rolling-release. I'll probably switch to Dragora 3 next, and then guix <zacts>I like the SlackBuilds way of doing things <jxself>Is Guix supposed to be rolling by the way? I've not been sure what the intention is now and/or in the future. <davexunit>I think we want to have the latest and greatest software packaged in master. <tadni>davexunit: True, but that perception that an "x is just an x" I think is going to deture people. Until the try it, which might be easier said than done. *zacts imagines guix as being analogous to git with release versions <davexunit>but I think it's very possible to have a "stable" guix version. <tadni>jxself: If the community gets big enough, I could imagine a "stable" repo could/would exist. <tadni>Wouldn't be that hard really, just needs someone commited to that task. <davexunit>the 1.0 branch would live on and only receive security patches or something <tadni>davexunit: Yeah-- that's an idea, have each /major/ releases have a frozen stable branch. <tadni>At this rate, unless we version jump up to 1.0 relatively soon, 1.x won't even be out till mid next-year, so we have plenty of time to figure these things out. <jxself>That's good, unlike Mozilla Firefox which will probably be up to version 40 by then. <davexunit>I need to investigate how to get guix running on ARM sometime <tadni>davexunit: Oh man, an Android/Replicant Chroot of Guix sounds AMAZING. <ijp>jxself: we're about a year away from that <ijp>firefox version numbers get bumped every six weeks, I think <tadni>Do on;y webbrowsers abuse version numbers. I fhkn that's all I've seen that haven't been around nearly as long as say Emacs, but are above version # 20. <ijp>it's not exactly an abuse <tadni>ijp: I meant abuse, more so as outwardly obnoxious, <ijp>equally you could claim that linux abused version numbers by having 39 2.6 releases, and then updating to 3 on a whim <jxself>ijp: Yep, so I did the math and arrived at that number. *jxself wonders why projects don't use hexadecimal <ijp>the FAIF podcast does that <jxself>Yes, that's where I got the idea from. *tadni wonders what version number GNU Icecat is on. <davexunit>oh really? guix has 24 packaged. we need to update. <jxself>Rubén Rodríguez, aka quidam of Trisquel fame, took over development. <tadni>davexunit: jxself: Just looked it up, it appears it's 24 still. <taylanub>davexunit: the problem might be that building FF is very costly, and Hydra might get overloaded? <jxself>I assume he'll start getting stuff onto ftp.gnu.org at some point. <tadni>jxself: Ah, yeah that's where I was checking. <jxself>8GB of RAM, Mozilla says, "or you may experience memory-related errors" <davexunit>eventually we'll have a real build farm and not a build silo. <davexunit>I think there are only 1 or 2 other machines that hydra offloads to right now. <jxself>I did donate an x86 machine with 16GB of RAM. <jxself>Not sure what the status is though. Last I heard civodul was installing stuff. <taylanub>I wonder if small and weak machines like my T61 that's already running Freenet, I2P, rtorrent, Emacs, and sometimes IceCat, could help too?.. to build lots of the smaller things maybe? <jxself>I wonder if Hydra takes the machine's specs into account when deciding who gets what? <davexunit>jxself: yeah, it does. for offload machines, you can set some metadata to tell which ones to prefer.