IRC channel logs
2014-08-22.log
back to list of logs
<davexunit>does anyone know how to work with profiles that aren't the default profile for a user? <davexunit>I'm interested in using guix for setting up project development environments. <mark_weaver>Svetlana: to boot from usb, I think you should type (at grub command prompt): set root=(<TAB> <mark_weaver>I think you need the open parenthesis for grub to auto-complete on device names. <mark_weaver>and then I think you should do something like this: set root=(usb0,0) <mark_weaver>and then as a separate command: configfile /boot/grub/grub.cfg <mark_weaver>I think I was mistaken before when I suggested that "configfile (usb0,0)/boot/grub/grub.cfg" would be sufficient. I think setting the 'root' variable is important. <davexunit>hmm, I guess I'm not sure how to create a new profile. I tried running `mkdir new-profile; guix package -p .new-profile -i guile-json` but guix package throws an error: guix package: error: rename-file: Not a directory <mark_weaver>well, I installed bash instead of guile-json, but otherwise identical <mark_weaver>it will also need to make symlinks of the form .new-profile-*-link <davexunit>oh, maybe the problem was that I created the directory beforehand? <davexunit>yeah, it worked when the directory didn't exist. <davexunit>however, it also created a .new-profile-1-link directory <Svetlana>in grub, ``set root=(<TAB>`` lists hd0 and hd1 which are totally new names to me and I'd ideally like to see information on them to choose <alezost>Svetlana: I think you can "ls (hd0<TAB>" and continue TABbing to recognize your drive <alezost>Svetlana: also look at (info "(grub) Naming convention") <Svetlana>I'm trying to boot from a usb drive, would it also be hd0? what is hd1? <alezost>I think USB would not be called hd0 or hd1 <Svetlana>like it might be useful to see its size probably <Svetlana>I do have a usb plugged in and I'm not sure where to head if only hd1 and hd0 show up in grub <alezost>Svetlana: do you have 2 hard drives? perhaps grub does not recognize your usb0 <alezost>Svetlana: that's strange, but anyway you can "ls" those hd0/hd1 (use TAB extensively) to see what those drives are. <Svetlana>ok, rebooting to peek at it, be back in a few minutes <alezost>Svetlana: Perhaps some grub module should be loaded to make USB work <jmd>Is there a way to make the unpack stage unpack to a different directory? <Svetlana>internet suggests hd1 is likely a usb; will go `ls` it and see where i get <Svetlana>yes it is hd1, i dont know what to do after running ``configfile (hd1,0)/boot/grub/grub.cfg`` tho <Svetlana>it remains at the prompt, ``boot`` says that i should boot a kernel first <alezost>Svetlana: does it start a new grub after "configfile ..." or does it stay in the same prompt? <alezost>Svetlana: you could run a kernel with "linux ..." and "initrd ..." commands but that's probably not what you want, you may try to ask #grub also <alezost>Svetlana: btw did you try "set root='(hd1)'" and "chainloader +1" ? <Svetlana>configfile (hd1,0)/boot/grub/grub.cfg && set root='(hd1,0) && chainloader +1 && boot ? <alezost>Svetlana: if hd1 is bootable, then "set root='(hd1)'" and "chainloader +1" should work <Svetlana>worked but said 'could not <some verb> gnu-system-image' and the message went away quickly as it gave some more output <Svetlana>and it took me to a guile-sheme-something prompt (guile@scheme-user) but I don't remember exact name <Svetlana>some of the 'more output' was about logitech mouse, it did not appear to have more errors in it <alezost>Svetlana: sorry, I don't know what to do with all that, I have not tried a GNU Guix system yet; you may ask at guix-devel@gnu.org as well <Svetlana>I'll stick around and wait for someone to come here. I doubt non-real-chat means of solving this are appropriate (although I will try them if I exhaust this channel potential). :-) <davexunit>has anyone else checked out ludo's slides from GHM? they're really cool. *alezost saw the slides too :) <mark_weaver>Svetlana: try "set root=(hd1,0)" and then "configfile /boot/grub/grub.cfg" <mark_weaver>davexunit: yes, I just looked at the slides. very cool stuff, and nice screenshots of your web client :) <davexunit>mark_weaver: yeah I can't wait to see the video. <davexunit>I liked the slides about integration testing pre-release GNU packages. <mark_weaver>Svetlana: what version of grub are you using? I'm using 2.00 here. <mark_weaver>it's possible that if you're using an older version, there may be problems. <mark_weaver>Svetlana: though actually, based on what you wrote above, it sounds like the system started to boot but something went wrong in the early bootstrap. <Svetlana>after running the configfile line what do I do? "chainloader +1" and wait? <mark_weaver>assuming that you did "set root=(hd1,0)" first, configfile should present the new menu. I'm surprised that's not happening. <mark_weaver>alezost's suggestion to do "set root=(hd1)" and then "chainloader +1" sounds like it might be better than what I suggested anyway. <Svetlana>I followed alezost's suggestion, I didn't use configfile thing with hd1 <mark_weaver>if you do it that way, you probably don't need configfile at all. <Svetlana>it did boot a second grub with gnu system bla bla line in it, then some messages, the error I mentioned, and the prompt I mentioned <mark_weaver>Svetlana: might the error message have said "gnu-disk-image" instead of "gnu-system-image" ? <mark_weaver>I think the problem is that the initrd on the USB stick lacks some kernel module needed to mount the root filesystem from the USB stick. <mark_weaver>we include the "usb-storage.ko" module on the stick, but in your case that may not be enough. <mark_weaver>it tries to mount the filesystem using its label "gnu-disk-image", but the kernel will only be able to find it if it has the modules needed to access that device. <jxself>Perhaps all fs kernel modules should be thrown in when the initrd is created? As opposed to selectively including specific ones? <mark_weaver>jxself: well, we know the filesystem that we used to make the stick, so it's not a lack of a filesystem module. i guess it's lacking some block-level device module. <mark_weaver>we give users a way to add their own modules to their initrd when they have an installed system. I think that including every fs module on the initrd might be a bit much. <jxself>You never know what hardware someone might have. :) <mark_weaver>well, right, I think that adding block-level device drivers to the usb stick makes sense. <mark_weaver>actually, all of the modules are on the stick's root partition. <jxself>Although I've noticed that bigger distros such as Ubuntu do put a lot in there. <mark_weaver>we don't need all of kernel/fs, but the rest of those might make sense. <mark_weaver>we only need enough to mount the usb stick's root partition. we already know its partition scheme and filesystem type, so those are fixed. <mark_weaver>so the things we need a lot of are the drivers needed to access the block-level devices. <mark_weaver>all other kernel modules will be on the usb stick's root partition, iiuc. <jxself>If we're talking of the stuff necessary just to boot the USB stick and continue on (and not what goes on the installed system), sure. <jxself>For the installed system I think most distros don't require their users to go enumerate which additional things they might need. IIRC Debian provides two options when running their installer in Expert mode: A more generic one or a more minimal one, with just enough for the one system you're installing on in that moment. IIRC, the generic one is the default in non-expert mode. <tadni`>jxself: In the base debian-installer? <tadni`>Maybe, I haven't seen it though. <jxself>Yeah, IIRC you have to use Expert mode to get the prompt. <mark_weaver>jxself: sure, the initrd on the installed system is another question. it would be useful to know how large out initrd will be if it includes all of that. <tadni`>jxself: I'll be darned, never must have digged into the more "advanced" options of that installer. :^P *jxself checks his of initrd <jxself>-rw-r--r-- 1 root root 19M Aug 5 20:44 initrd.img-3.2.0-67-generic <jxself>er; that /me comment didn't come out very well.... <saul>I am interested in running dmd on Slackware. Any advice (tutorials, links, etc) on incorporating dmd on a non-guix system? <jxself>I have no firsthand knowledge of anyone that's done that. Could be interesting. Please do share results. :) <davexunit>saul: don't have anything to recommend besides reading the dmd manual and running dmd as an unprivileged user first to test things. <saul>Thanks, I imagine it will be slow going then. <saul>I often have a hard time figuring out how to do things until I understand the whole system. <saul>(one of the reasons I like Scheme) <jxself>Just remember that the bleeding edge is called that because it is stained by the blood of the users. :) <saul>Well, if I don't fall completely flat, I will be sure to share what I learn. <davexunit>saul: feel free to write to the guix-devel mailing list, too. ludovic might be able to offer some tips when you're stuck. <Svetlana>mark_weaver, probably it said that, i will check again in a few hours <Svetlana>mark_weaver, if it is 'gnu-disk-image', then how to i fix? <jmd>This channel is environmentally unfriendly. It contributes to global warming and deforestation. <tadni`>A week and 3:30 hours away till my all night, Guix hackathon. :^) <tadni`>I might have my first and possibly last "Redbull". They are one of the sponsor. :^I *jxself turns ups the CO2 emissions in preparation for tadni`'s hacking session and in response to jmd. :) *tadni` is actually pretty excited. It will not only be his first formal hackathon, but too even independently, he's never set 6+ hours dedicated to anything exclusively hack-centric. <davexunit>tadni`: are you going somewhere for this hackaton? <mark_weaver>jmd: I've seen in the logs that you've asked many questions that went unanswered. I remember knowing the answers to most of those questions, but you were never around at the time. If you remind me of the questions, I may have answers. <RISCi_ATOM>tadni`: I wish that I was capable of contributing to guix :\\ <jmd>mark_weaver: Most of the questions are probably moot now. <tadni`>RISCi_ATOM: I barely know basic programming concepts and I'm fairly compotent to at least aid in packages. <tadni`>The DSL for package definitions is fairly self explanatory. <jmd>I thought it was Digital Subscriber Line <davexunit>RISCi_ATOM: I don't think that is much of a hindrance for basic packaging work. <tadni`>davexunit: Unrelated, but I forgot to tell you how cool it is Sly might be getting somewhat proper 3D support soon...! :^) <jmd>I think I nearly have a package for libreoffice, but it will need a LOT of tidying up. <davexunit>RISCi_ATOM: after all, we do want to appeal to people that don't know Guile. So, you could be a valuable usability tester. :D <davexunit>tadni`: thanks :) it's horribly slow, but working. <jmd>mark_weaver: One question was how to make a package that required two sources. <jmd>I ended up turning one source into a patch. <jmd>But it was rather nasty. <tadni`>RISCi_ATOM: I'm pretty sure I will. Really I'm hoping that such an event will inspire me to study harder, so I can do something "cool" each month to close it off. :^) <davexunit>mark_weaver: note that *both* sources need to be download and extracted to the same place. it's a strange situation. <tadni`>davexunit: Well I doubt anyone is going to be using Sly for the next COD or something.... but really such a thing is very exciting. <mark_weaver>jmd: if you search gnu/packages/*.scm for ",(origin" you'll find a few examples. <mark_weaver>davexunit, jmd: so either the unpack phase can be replaced, or a new phase can be added after the standard 'unpack' that unpacks the other one in the right place. <mark_weaver>jmd: the default 'unpack' phase is in guix/build/gnu-build-system.scm <davexunit>yeah, that was essentially my suggestion when I first heard about this problem. <mark_weaver>note that one of the things the 'unpack' phase is responsible for is 'chdir'ing into the directory. the later phases assume that's already been done. <mark_weaver>one thing I should mention though: the 'source' field of the package is what will be produced by "guix build -S" <mark_weaver>so if the source code is really the union of two tarballs, then it might be better to create a separate "source" package that combines the two tarballs together, and make that the 'source'. <jmd>I thought about that too. <jmd>In the end no solution I came up with was particularly nice.