<DusXMT>Just making sure I understand this right, invoking guix pull will result in the same as if I updated my setup using git? <DusXMT>Or are there differences? (of course, there's the lack of easy-to-access sources, but are there any other?) <alezost>DusXMT: yes, the latest guix will be fetched (and can be found in "~/.config/guix/latest"); I recommend to use "guix pull --verbose" <alezost>civodul: about merging guix.el: I am reading autoconf/automake manuals, and I'm going to put *.el files into "lisp_DATA" construct, as it is recommended in (info "(automake) Emacs Lisp"). WDYT? <alezost>Also I think the whole patch will be rather big for ML, so what if I create a branch "emacs-ui" and put my changes there so that you could revise it? (I will probably ask some questions on ML before that). *civodul back from coffee :-) <Svetlana>civodul: are you aware of 'gnu-disk-image not found' sort of trouble? <alezost>civodul: ok, I think it will take me several days until I come up with something. What about that problem with unbound ‘process-package-actions’, do you still have it? <civodul>Svetlana: no, could you send more details to the list? <civodul>alezost: sorry i haven't yet taken the time to re-test, will do ASAP <Svetlana>I don't have any more detail, using the usb image, it gives that error <alezost>civodul: no problem, I admire of how you manage to find time for everything you do <civodul>Svetlana: oh that's when booting the USB key? <civodul>did you just prepare it with dd if=... of=/dev/foo ? <civodul>yes, but how did you initialize the USB key itself? <civodul>at the Scheme prompt, could you try this: <Svetlana>usually a usb has /dev/sdb and /dev/sdb1, this one only has /dev/sdb, something unusual, but I copied over onto /dev/sdb using dd anyway <civodul>(find-partition-by-label "gnu-disk-image") <Svetlana>yes I will try.. will need to reboot.. what should I do after these two lines? <Svetlana>before copying i didn't see it, but after copying i didn't look <civodul>can you plug in the USB key into your running system <civodul>and then run "blkid -L gnu-disk-image" <Svetlana>yes, i confirm i can see sdb1 now, and that it does print /dev/sdb1 <civodul>do you have Guix (the package manager) installed on this system? <Svetlana>as soon as I figure out where to clone it from, one moment <civodul>actually, could you take it to bug-guix@gnu.org? <civodul>that will be easier to handle for me <Svetlana>I haven't found myself very successful following interactive instructions by email but I could do that if that's easier for you <civodul>but i'm at work now, catching up with email and stuff <Svetlana>apparently downloading guix itself is a hard task with the current state of wifi so I'll have to return to it a bit later after the wifi stops crapping out <Svetlana>bugged out on 18% a couple times but it's on 69% now and I'll head to sleep if it fails on this try <civodul>Svetlana: maybe try a wired connection? :-) <Svetlana>don't have such option unless I'd like to talk with landlord <Steap>Svetlana: I can feel your pain. <Svetlana>cloned git://git.savannah.gnu.org/guix.git onto a running linux os (a debian derivative); what would you like to do after that? <Svetlana>I'm going to sleep. Will read in the morning - hope to see some pointers about getting more info. I could run the things civodul mentioned earlier in the scheme prompt, but I couldn't save them properly other than by taking a picture. :-) ***tschwing_ is now known as tschwinge_
***tschwinge_ is now known as tschwinge
<jmd>Can anyone suggest a better way to do this in a build phase: (if (equal? ,(%current-system) "x86_64-linux") "USE_64=1" "") <mark_weaver>jmd: better make it ,@(if (equal? (%current-system) "x86_64-linux") '("USE_64=1") '()) <mark_weaver>jmd: also, I saw you ask about accessing the source code of your package's inputs. You can't do that unless the make that source code an input. <mark_weaver>your package is built inside a chroot and container where only the inputs are available (bind mounted within the chroot) <mark_weaver>if you need the source code of a package, then you need to explicitly include that source code as an input to your package. <mark_weaver>which I guess would be something like (inputs `(("emacs-source" ,(package-source emacs)) ...)) <mark_weaver>and I guess that would be a tarball, so you'd have to unpack it yourself. <mark_weaver>out of curiosity, what package needs the emacs source code to build? <jmd>mark_weaver: emacs was just an example. <mark_weaver>jmd: also, I should mention that the "USE_64=1" thing should ideally go in the #:make-flags argument. <mark_weaver>e.g. #:make-flags `(<other flags here> ,@(if (equal? (%current-system) "x86_64-linux") '("USE_64=1") '())) <jmd>Yeah ideally. But that'll only work if the build system is sane. <jmd>But anyway, my question was more about how to know if the current-system was 64 bits. <jmd>x86_64 is not the only 64bit system. <mark_weaver>well, it partly depends on your definition of a 64-bit system. mips64el-linux uses 64-bit registers but pointers are 32 bits. anyway, this should be detected by the build system automatically. in leiu of a decent build system, I guess I would use 'match' for now. <mark_weaver>i.e. ,@(match (%current-system) (("x86_64-linux" '("USE_64=1")) ("i686-linux" '()) ("mips64el-linux" '()))) <mark_weaver>and then if (%current-system) is some other value, the 'match' will raise an error and call attention to the fact that another case needs to be added. <mark_weaver>a better solution would be to improve the build system to detect that automatically, perhaps by compiling a small program that looks at sizeof (void *) and outputs the needed extra flag(s). <mark_weaver>for now, I'm neglecting cross-compilation issues, since I guess that's not handled very easily by that build system. <jmd>Yeah if upstream would see sense I wouldn't have to do any of this. <jmd>Is it possible to access make-flags from the build phase definition?