<brendyn>Afterwards, you can use that version of guix to setup an environment to build the latest git version
<brendyn>reepca-laptop: Can you explain how you are trying to install Guix? On what distro?
<reepca-laptop>Lubuntu 32-bit 16.04, recently trying to install from git, downloading tarball now.
<Apteryx>rekado: Is it me or most of the patch never apply? I'm experimenting with 'M-x cd ~/src/guix-review', followed by | git am in Gnus on emacs patches, and it doesn't work so far (patches fail to apply).
<Apteryx>I guess for files which change often and where people add stuff at the end (emacs.scm), it might trigger this scenario (merge problems) ?
***j-r is now known as james-richardson
***james-richardson is now known as j-r
<j-r>emacs packages? Guess the best plan would be to package the ones I use from melpa and send in a patch to the list so it becomes an actual guix emacs package...
<j-r>I can ask a similar question for perl, but then to package perl things, I'll probably have learn about inputs vs propagated-inputs vs native-inputs.
<brendyn>j-r: native-inputs are programs that need to in the buid environment, but not installed with the package, like autotools, gcc, etc
<brendyn>inputs j-r inputs are including with a package and are refered to by an absolute path. like lua might be included as an input, and use by a program by pointing to /gnu/store/…lua.…/bin/lua, but installing that program will not put lua in your PATH
<brendyn>I think the manual explains it better than me anyway
<j-r>I see the descriptions in the manual. I'll just build a package using each and see what happens.
<Apteryx>CharlieBrown: the file containing the emacs package definitions
<Apteryx>It's located at guix/gnu/packages/emacs.scm
<brendyn>My install failed after 50 hours of building packages. It seems that it built some dependencies which were not reproducible, and so now nothing can use substitues anymore as all the hashes are different
<reepca-laptop>Doesn't seem to be possible to get package "hello" from hydra (404)
<rekado>reepca-laptop: it’s normal that GNU software does not have a configure script when you build it from a source checkout.
<rekado>reepca-laptop: the configure script is only included in release tarballs, because it is generated code.
<rekado>reepca-laptop: so the manual is still right
<rekado>reepca-laptop: if you want to build from source, you need to first generate the configure script by bootstrapping with autotools
<rekado>Apteryx: depends on the files the patch touches. Rebased patches usually apply just fine for me.
<rekado>brendyn: the manual should be up-to-date and it is constantly updated. The last change I see is from May 1.
***cal is now known as CharlieBrown
<reepca-laptop>rekado: thanks for the explanation. I tried running ./bootstrap, but got an error about "possibly undefined macro". At brendyn's suggestion I installed from (binary) tarball, and am currently in the several-hour-long process of attempting to test it by installing the "hello package" using --fallback because hydra doesn't seem to want to give me that package, interrupted twice due to running out of disk space since I didn't realize it
<rekado>I had the same problem with i686; looks like Hydra hasn’t built anything new for i686 in a while; at least not since after my glibc patch for i686.
<reepca-laptop>yeah, my laptop technically supports x86_64 but I didn't know that at the time I installed Lubuntu on it several years ago, and it would be difficult to migrate now, and I don't have my desktop set up yet (moved home on Saturday)
<reepca-laptop>Even compiling from source, it seems a bit strange to use up 2GB just to get the infrastructure for hello world...
<rekado>reepca-laptop: well, it’s not surprising if it’s building GCC and its dependencies from source.
<rekado>reepca-laptop: it’s not *just* building the “hello” package, but it instantiates the package graph that Guix specifies at this particular version.
<reepca-laptop>Does it have to do the full bootstrap process of building GCC from older GCCs from older GCCs all the way down?
<rekado>reepca-laptop: Guix comes with a handful of bootstrap binaries.
<rekado>reepca-laptop: this includes one binary of GCC
<rekado>but we’re building it a couple of times in a pseudo cross compilation to get rid of any references to the bootstrap GCC.
<catonano>There's only the manual, as far as I know
<catonano>The manual has a paragraph about importers
<guix-user>guide or tutorial. Now, after "import" I see some ((ackage ...) definition, then I save is to something.scm, and add (define-module, by analogy with other packages.scm... But where is complete guide?
<guix-user>I have many questions, for example: how to update emacs load-path after "emacs-" guix-package installation?
<j-r>civodul: I know, $WORK forces me to do such things *sigh*. That help me install it, the guest additions are problematic. I didn't really expect anyone really does this, but I thought I'd ask anyway.
<brendyn>Building my own install image seems to have been a terrible mistake. I'm building p11-kit on a new laptop from an install image with the same version and dependency versions but the hashes are all different from the laptop I generated the image on. p11-kit builds fine on the first laptop but fails two tests on the one running the install image
<j-r>guix-user: no. I have to run $WORKS official windows image on my (actually their) laptop, that severely limits me.
<j-r>otherwise I would run kvm or run guixsd on the bare metal.
<efraim>after 'compress-documentation the daemon frees all the used space in /tmp? It sometimes takes a very long time on my aarch64 board with /tmp on an sd card
<civodul>efraim: after the build completes, the daemon scans the resulting directories for store references, and then removes /tmp/guix-build-foo
<Apteryx>Still, maybe a nifty elisp script that would automatically 1) apply git am on the body of the message or 2) apply git am on the individual MIME attachments would be a nice automation touch IMHO.
<ng0>nice idea… I think I will propose a similar idea for neomutt
<ng0>are there some special conditions with the perl license, that someone has to just state on a couple of files that it is licensed as this and not on all of them? I'm packaging this for my own use, but I could try and convice the author that some files need licese specifications
<ng0>the binary states "copyright since 1993 <name>". the .pm states "licensed under the same license as perl" and for the rest I haven't located relevant files yet
<ng0>okay, the license is alright on all relevant files
<ng0>but I'm not sure if the statement in the binary works out
<ng0>oh, is bayfront now operational officially and stable? create mode 100644 bayfront.guixsd.org.pub
<ng0>not good. ice-9/boot-9.scm:2903:6: no code for module (ng0 packages personalized) … this used to work (included in the /etc/config.scm to load custom packages) just yesterday. GUIX_PACKAGE_PATH is exported in the shell.
<ng0>snape: 0ad-data: just a matter of style and saving 1 line: move the "http://…" part of the string one line up indent the version … part of the string. description of 0ad-data: this is my error so maybe use "0ad-data provides the data files required by the game 0ad." 0ad: same for the (uri … part, I'd move the http:// one line up. synopsis: maybe explain "RTS" and the "3d, " at the beginning looks odd.
<ng0>"3D, historically-based RTS game of ancient warfare" --> maybe: 3D Realtimestrategy game with historic elements?
<ng0>regarding "more expressions"… do we have a policy on what's applicable to master in terms of pentesting software? I know I added one or two packages, but I have more "dormant" in my wild repository because my views might not be true for what everyone agrees upon
<rekado>the first is easy: we’ll just patch the Makefile
<ng0>I basically started porting whatever Blackarch, Kali etc have
<rekado>DoublePlusGood23: the script makes assumptions about where it has been installed.
<rekado>DoublePlusGood23: it assumes that there will be either ‘/etc/neofetch’ or ‘/usr/local/etc/neofetch’
<rekado>that’s why it’s always good to have a configure script
<ng0>inxis ignorance on having any other release method than the git checkozt is bothering me… their small bashscript repository has grown to 70MB now because they don't understand that it's silly to include the tarball in it, but they are well aware of it. if they would put a version number to it… but no, what a revolutionary idea. let's just update it in place and grow MB by MB
<ng0>ah, I wasn't finished, that's why it was sleeping in my packages repo
<ng0>"it's difficult" but doable with some dedication
<ng0>we have musl… and if someone wants to debug it, we have uclibc-ng. in my imagination it can be a systemwide switch, but it depends on the depth you want.
<ng0>I think the better reply would be, ask on the mailinglist and someone who put more thought into that matter or relevant parts of Guix will reply. irc is a bit sporadic for good async conversations