<mark_weaver>jamesaxl: I don't claim to know for sure, but I would guess that the copyleft licensing on Linux is an important factor. without it, it is unlikely that so many companies would have contributed their fixes and drivers back to the community as free software.
<NiAsterisk>okay, so there was no reply on what's okay to delete for emacs builds. "I'm using the emacs-build-system without any changes so far. is this something okay for guix, or should I removed README.md, Cask, .gitignore, .git/, Makefile and travis.yml before installing? https://ptpb.pw/4rG3.txt" delete everything which is not .el, .elc, and image?
<NiAsterisk>I'm not familiar with emacs system builds, I did use emacs package manager or git checkouts for this so far.
<iyzsong>NiAsterisk: I think it's ok since current emacs packages did this way. But I don't like those useless files :-) Maybe talk to maillist?
<NiAsterisk>but it's the starting point I had, because I packaged this before.
<NiAsterisk>I can#t do updates in guix currently because some packages fail to build on hydra and here, otherwise I would try.
<NiAsterisk>ultimately, I see guix as a nice platform for gnunet software to come.. it can cover a nice range of platforms. I can imagine when the first public release of secushare is out, to get it to guix.
<calher>calher: But source and binary are one and the same, because it's all declared. There's no reason to separate them if the sources for everything is already pointed to in the recipe for making the binary.
<NiAsterisk>calher: i am waiting for either one of the bitmessage branches to get a setup.py. it's no tested (audited) software, but it works and gets improved. so gnunet 0.10.1 is not the state gnunet latest svn checkout has. if you want to try secushare current work state, you can't do with the gnunet-0.10.1 .. I can imagine -dev to be a nice thing to look into
<Jookia>Splitting out -dev packages will lighten space requirements if you're not a developer
<calher>I think the whole -dev business on Debian/Ubuntu is complex garbage.
<NiAsterisk>so -dev in that sense declares that it might break
<rekado>Jookia: is there a mailing list discussion on this?
<NiAsterisk>for example -9999 of gnunet has other requirements than -0.10.1
<Jookia>rekado: This is just what I've heard in IRC, so I'm not sure
<Jookia>calher: Oh ok, this will blow your mind a bit- the modules you added it to is for stuff run in the build environment- you want to add it to the top modules of the package
<Jookia>calher: Guix generally has two environments- the Guix environment and the build environment for packages, which makes sense if you think of things like cross-compiling or installing in a VM where you send the source to the builder and the builder doesn't have Guix there, only Guile modules
<fhmgufs>They often depend on the fact that most users already have a lot of things installed.
<NiAsterisk>I might be able to fix gnunet-gtk. But not this week, I'm applying for a job which has priority. went through the logs of the gnunet-gtk build, I'll compare it to gnunet-gtk on gentoo soon when I have time, but I see a couple of errors which shouldn't exist.
<achilles`>Will guixsd gain a larger userbase once 1.0.0 comes out? Will this distro be more beginner friendly later on? As of now, I have not been able to successfully install this on my machine and so I am worried this distro will be ultra niche, which is unfortunate because the idea behind it is revolutionary.
<NiAsterisk>what are your issues? maybe it can help to work towards a more useable state
<achilles`>well, I tried this around two weeks ago and addressed the problem to this channel. The problem was with the installation of guixsd.
<achilles`>I think it had to do with missing some file, I might try it again soon for fun.
<achilles`>A major problem was that it took awhile to install (what parts were able to install), but
<NiAsterisk>maybe you could collect and send it to guix-help list? It might help with the bigger list of improvements I want and write down at some point.
<achilles`>I heard this was due to the lack of servers and a large number of users
<NiAsterisk>yes, hydra is a problem currently, but will be replaced soon
<Jookia>achilles`: Hmm. Hopefully, yes. But that'd require more documentation than now, and some pre-configured images with GUIs
<achilles`>besides the package manager which is great, the direct connection to the GNU project and FSF endorsement is big plus for me.
<NiAsterisk>ideally, in my opinion, it should be a distro which makes itself as accessible as possible to beginners and experienced users
<Jookia>I can see it being a bit difficult given the lack of GUI configuration system but I think if people are okay with using the command line then it would be okay for them- it's probably easier than Arch Linux in this case since you don't configure things by hand
<NiAsterisk>which requires more documentation etc.. I'm not inexperienced myself and have issues getting started. I'm collecting notes and ideas and everything and will improve docu and other materials at some point
<achilles`>how can I directly suggest improvements to the docs?
<NiAsterisk>try the help list, and see what can be done with it :)
<NiAsterisk>achilles`: in october/november i'll do a guix packaging for beginners thing (hopefully can get it recorded) with my experience of the time from 0 (gentoo, arch packaging experience) up to that point.
<paroneayea>I can probably get gmg packaged well enough to go in guix this week, excepting that issue.
<mark_weaver>paroneayea: I updated sqlite to 3.10.2 in core-updates. it would be nice to know whether that version has problems with sqlalchemy
<Jookia>Does --check rebuild all dependencies too?
<kristofer>mark_weaver: I have a question about that! After building guix locally I ln -s ~/.config/guix/latest and also /root/.config/latest
<davexunit>roptat: guix doesn't have a "package repo" in the sense you may be used to from distributions like Debian or Fedora. for them, a "repo" is a server that hosts binaries. for us, the entire set of package *recipes* is stored on your machine. all of the package recipes are included with the rest of the guix code.
<kristofer>I notice after running ps aux|grep guix-daemon that the daemon is actually running from /gnu/store/someHash-guix/guix-daemon
<davexunit>so to add/update a package is to write some Scheme code and send us a patch.
<kristofer>do I need to update the path so guix-daemon runs from the git build in ~/guix
<davexunit>kristofer: the daemon protocol is stable, so you almost never need to update it.
<nckx>Is ‘gtk-doc’ known to be broken at the moment? Building it fails with ‘checking for DocBook XSL Stylesheets in XML catalog... not found’ here and I'm not sure if it's my installation or Guix proper that is wonky.
<Jookia>I should convert my scripts to use something like that
<dmarinoj>mordocai: I really just started writing the template according to the dependencies detailed in debian...I'm really green
<dmarinoj>mordocai: also I looked at the quicklisp importer for debian
<davexunit>we need asdf-build-system and 'guix import quicklisp' for CL stuff
<mordocai>zacts: dmarinoj: Yeah, we could use a similar importer to make the package definitions. One of the interesting things about lisp is generally people just ship the code and cache the fasls locally where as I think guix might want to actually ship the fasls. Not sure.
<Jookia>xd1le: I think the most constructive solution is to write a 'scripts2autotools' thing that replaces all scripts with '.in' files and changing /usr/bin/env X to @X@ and having autotools finding that
<mark_weaver>Jookia: we already have 'patch-shebang' in guix/build/utils.scm that we use automatically in gnu-build-system
<Jookia>Interesting- but I think this is more for retrofitting existing project trees
<mark_weaver>Jookia: you seem to be aiming to make upstream software buildable and installable on Guix *manually*, as opposed to building things in the build containers, putting things in profiles, etc.
<mordocai>I'm actually on the fence as to whether guix should ship fasls or not.
<mark_weaver>Jookia: and I'd like to know why you think that's better than importing things as packages
<mordocai>Usually lispers don't, but it seems more akin to the guix philosophy to do so...
<mark_weaver>Jookia: the gnu-build-system *automatically* scans the entire source tree for shebangs and converts them before building.
<Jookia>mark_weaver: Not installable, no. I don't think it's better than importing things as packages, but as a developer I don't want to package things all the time
<Jookia>mark_weaver: Imagine if I had to rebuild the entirety of Libreboot every time I change a source file