<mark_weaver>davexunit: go to http://packages.debian.org/gcc-avr, and then select a specific package, and then in the right column of the package page, see the "Download Source Package" section. in the tarball, you'll see a 'debian' directory and within that a 'rules' file which is a makefile.
<mark_weaver>fps: if you want to work on a concrete proposal to improve things here, I would suggest trying to think through all the consequences, come up with a proposed patch, and post about it to the ML :)
<mark_weaver>but honestly, changing the home directory of an existing user seems like a rather rare and strange thing to do, and there's a million more important things for us to work on :)
<fps>mark_weaver: i do agree with that sentiment.. but it's an interesting problem nonetheless.
<davexunit>I would expect that /etc/passwd would be changed to point to the directory specificed by the OS config
<fps>it feels kinda itchy in this declarative way of setting up a system
<davexunit>and the directory be created if it doesn't exsit
<alezost>ajgrf: nope, as switching to a global generation means booting a kernel; you can't do it without reboot
<MatthewAllan93>alezost: no, mark_weaver checked my config.scm file and he said it looks fine
<ajgrf>alezost: how does it work when you run `guix system reconfigure`?
<fps>now, a different question: why do i only get an X mode of 640x480 in qemu on another machine? :) trying to centralize my guixsd installs on a root server with vnc access..
<mark_weaver>fps, davexunit: actually, I guess that 'usermod' probably has no ability to create the home directory if it doesn't exist, at least if --move-home is not specified.
<davexunit>fps: my technique is to fix the thing I want fixed, propose the patch, and let the ML debate with actual code.
<fps>mark_weaver: i suppose there are other ways than usermod, like patching up the passwd.. is /etc/passwd also not part of the system generations? is it considered mutable?
<mark_weaver>usermod can definitely change the /etc/passwd entry, but we currently rely on useradd to create the home directories from the skeleton, and I'm not sure that usermod can do that part.
<alezost>ajgrf: when you run "guix system reconfigure", it builds a new system and links "/run/current-system" to it. So if you mean that new commands become available, it happens because "/run/current-system/profile/bin" is in your PATH
<mark_weaver>actually, I confess I don't remember clearly whether anyone has used GPT successfully with GuixSD.
<MatthewAllan93>mark_weaver: after going into the liveusb and doing that "e2label" or something like that for the root partition. i then restart and it boots up correctly but every time i reboot it does it again saying about finding the root parition.
<mark_weaver>is that just a delay, or does it prevent the boot from proceeding?
<mark_weaver>oh, well, I guess your message makes that clear enough. it's just a delay?
<mark_weaver>if so, it's nothing to worry about. it just shows that our boot process currently uses polling to wait for devices to be ready, whereas there is surely a better way to do it that has yet to be implemented.
<MatthewAllan93>oh ok, i think it prevents the boot from proceeding but i will reboot in a minute and see if it is just a delay
<civodul>mark_weaver: i have a GPT and that's fine
<sebboh>I'm very new, so please pardon me. The hash for a given build takes into account the source, config, etc, yes? About the config.. is it hashed on the file level or after parsing? So, whitespace: does it change a hash?
<mark_weaver>what do you mean by the "config"? the OS configuration? or something else?
<Steap>sebboh: a trailing whitespace in the package definition, for instance ?
<sebboh>Hm, I guess I do mean OS config. That's all I've provided... some /etc/config.scm in which I defined a user and specified some packages. Now I'm watching guix create packages locally with hashes in the filename.
<mark_weaver>ditto for whitespace, formatting and comments in package descriptions.
<mark_weaver>package definitions and OS descriptions are used to generate what are called "derivations", which are relatively low-level descriptions of how to build the package and what 'inputs' should be made available in the container where the build is performed. the derivation and the inputs all contribute to the hash. however, the derivation is unaffected by things like whitespace and comments in the original descriptions.
<mark_weaver>and guix-daemon, which performs the builds, only sees the derivation.
<sebboh>ah, right. So... did you guys take the "chose some specific date/time" strategy?
<sebboh>or the "remove anything that tries to figure out what time it is" strategy?
<sebboh>Hey, suppose I run out of filesystem space or tempfs space or something during the `guix system init ...` stage. I'm running the 0.9.0 usb installer in a VM. Can I just grow whatever resource ran out and then pick up where I left off? Do I need to provide some additional command line argument?
<bavier>sebboh: the install should start up where it left off
<lfam>Yeah, whatever got built in your /gnu/store will still be there
<bavier>roelj: btw, did you read the previous discussion on the ML about build-status icons?
<lfam>I'm trying to make a program wrapper but struggling to make it work. Where does the "prefix" in the wrapper for bioper-minimal come from?
<lfam>The build succeeds but the program is not properly wrapped.
<lfam>There are two layers of wrapping: the python-build-system's PYTHONPATH wrapper, and the wrapper that I want to make. However, my wrapper is not applied properly. I get two layers of wrappers, but they both include PYTHONPATH and neither include PATH
<mark_weaver>roelj: remember that there are multiple supported architectures, and often builds fail on some architectures and work on others.
<mark_weaver>but I agree that it would be nice to see that information more easily.
<lfam>That wrapper is largely cribbed from bioperl-minimal
<roelj>mark_weaver: I am aware of the four architectures. I have to draw up some UI for how this can be displayed nicely. Once I've got that I'll send a mail on the mailing list with the concrete plan.
<bavier>have you tried adding your 'wrap-programs phase after the python-build-system's phase where it wraps programs (I don't know the name off-hand)
<lfam>My wrapper happens add-after 'install. I'm not sure when the build-system applies its wrapper.
<roelj>One more question, how can I generate output from the packages.scm file?
<lfam>bavier: I'm not even sure if this is the right approach. I'm copying the approach taken by nixpkgs. The output executables need to be able to use the `dialog` executable. I am trying to put `dialog` on the path of each of the output executables.
<sebboh>uh, while booted in the 0.9.0 usb installer.. I guess /gnu is in / and / is unionfs... And I guess that is some sort of tmpfs or ramfs? Can I just activate swap, or do I need to do something else to increase space available to /gnu?
<bavier>I'm not sure the situation could be improved either, since python-build-system can't have intimate knowledge of which programs to wrap
<bavier>except to maybe to keep an eye out for programs that look like they've already been wrapped
<lfam>I spent so much time reading the manual at the beginning, before I tried anything. Now I don't read it anymore. If I had I would have seen the section for python-build-system that would have saved me a lot of time.
<karhunguixi>mark_weaver, regarding root encryption. With your help i was able to encrypt everything (root, home and boot) on my Libreboot system. At work (using 0.9.0) i have encrypted root and home, but not boot. (This system does not have Libreboot.)
<fps>hm hm, ludo's comment on the git nar download vs installed size made me reconsider current distributed data store systems for distributing substitutions
<fps>he mentioned content adressable storage in his remark and the referenced ML message.
<fps>it made me lookup up CAS and the similarity to DDSs like morphis or ipfs directly sprang into mind. but there's an important difference in the requirements which would make a DDS for this purpose easier to implement than morphis or ipfs
<fps>there's no need for confidentiality as it's all about distributing free software
<fps>this rips away several layers of complexity afaict. the essence of kademlia's XOR metric routing could still stay inplace, but instead of routing all traffic through several hops through a cryptographic protocol to ensure confidentiality, the routing could just be a transparent lookup operation..
<fps>so in essence such a dCAS (distributed content adressable storage) node could just be a good ole HTTP server (or HTTPs for a little bit of confidentiality) supporting a select few operations and maintaining a small routing table..
<civodul>what i was suggesting was even simpler than a full p2p thing
<civodul>but yeah, the ideal would be a p2p-ish network
<fps>oh, you're around. my malfunctioning tab completion fooled me ;)
<mark_weaver>but the biggest problem is likely the braindead RAID setup, by a previous generation of FSF sysadmins who will go unnamed.
<mark_weaver>the details have been spelled out to me in the past, and I've forgotten most of them, but the basic problem is that there are RAID arrays where the underlying devices are not spread across multiple physical disks, but rather across multiple partitions on the same disk.
<mark_weaver>so a single write turns into multiple writes to several parts of the same disk, far apart from each other.
<fps>um, ok, that, if true, doesn't make too much sense :)
<mark_weaver>yeah, it's pretty bad, and our I/O bandwidth is almost unbelievably low.