<ng0>hi. I submitted my soon-finished work in progress of rust.scm to the list. I won't have time to work on this any time soon, but I'm sure someone here might have more time to put finishing touches to it.
<iyzsong>civodul: I just rebase it upon master, and have build and test locally the 'gnome' meta package before the rebase :-)
<iyzsong>civodul: i'd like to add the xdg profile hooks too, it will fix some issues for GNOME. will report back when I finish the build (and test with gnome-desktop-service).
<ng0>civodul: if I build the website from the repository of guix artwork, how many external static sources are there if there are some at all? I'm thinking of cloning it and providing a mirror in onionland.
<jlicht>Am I correct in assuming that guix-specific patches for software should ideally be submitted and integrated upstream, but otherwise included in the guix git repo?
<taylan>jlicht: if it's a generic fix for the build system of the software or such, then yeah, ideally it should go upstream
<taylan>there may also be instances where there's a really guix-specific patch, such as gnu/packages/patches/mupen64plus-ui-console-notice.patch, which don't belong upstream
<jlicht>taylan: In this case, it _is_ actually already accepted by upstream, but not released yet. So until the next release it can go into the guix repo, I assume?
<taylan>I would say yes, together with a comment within the package recipe that says the patch should be removed when the version is updated
<jmd>I want to build/install a package with complete debug information and without optimisation. Is there an easy way to do that or do I need to write a custom package definition?
<jmd>WTF!? Has bootstrap-binaries changed recently??
<ngz>Hello. I packaged thinkfan, a fan control program. The compilation is successful. However, there are two issues: 1. the thinkfan program must be run as root, and think_fan acpi kernel module has to be loaded with a specific option. What would be the proper way to handle this at the package level?
<ngz>I guess the first issue can be solved by adding thinkfan to %setuid-programs.
<ngz>Also it is not much of an issue on a foreign distribution.
<ngz>I assume the second point could be solved by creating a service, although I have no clue about what service to extend to load kernel modules.
<taylan>packages themselves can't declare that they need setuid root AFAIK. (automatically making them suid 0 when they request it would be insecure since users can arbitrarily command the daemon to build packages in a guix system.) so it needs to be done at the OS configuration level.
<df_>assuming the server serving www.gnu.org is owned by the fsf
<random-nick>"For a program to be GNU software does not require transferring copyright to the FSF; that is a separate question. If you transfer the copyright to the FSF, the FSF will enforce the GPL for the program if someone violates it; if you keep the copyright, enforcement will be up to you."
<cpjjl>but free software do not have owners, the copyright assignment is only a legal thing. IMHO authorship counts more, and based on authorship, GUIX would be more a World/France thing than a Boston thing.
<df_>*shrug* if I were to define it at all I'd define it by the primary distributor
<df_>but then I don't see much reason to want to define it
<cpjjl>usually, free softwares are attached to animals, rather than countries :)
<davexunit>there's precendent for accepting blobs for compiler bootstrapping.
<ADFENO>davexunit: Yeah... That was the first thing I though about that guy when he told me so.
<jlicht>davexunit: sure. If the binary is only used for bootstrapping, would it make sense to even decompress it, or could I just as well have the 'rustc-stage0' package only be an archive that gets linked to the right place when building 'rust'
<ADFENO>I don't have GuixSD installed here (I don't even have Guix here), but I plan to install it alongside my copy of Trisquel.
<rain1>it woul be nice to at least have a complete list of packages that make use of bootstrap binaries
<davexunit>jlicht: you would just drop the file wherever it needed to be. if the rust build system does the decompression, then you don't need to do it yourself.
<jlicht>davexunit: cool. Is there anything special about packages that are only internally used? E.g., naming conventions, guile-isms that make the symbols private-yet-usable?
<davexunit>jlicht: for this you would make an origin record that is an input to the rust package
<jlicht>ACTION quickly opens up the guix manual again...
<ajgrf>sietedosfede: yes, run something like `guix system reconfigure /etc/config.scm`
<hade>ACTION I'm confuse what next step after using command `herd start cow-store /mnt
<ajgrf>hade: next step is copying a sample config file to the system, customize if you want, and run the rest of the installer with `guix system init`. it's a bit confusing because the documentation for what to put in the config file is in another chapter of the manual
<hade>ajgrf: ok, now processing 'accepted connection from.......'
<adfeno>Just a quick question: Suppose I'm installing GuixSD alongside my Trisquel system, and I want to keep my current booltoader (GRUB from Trisquel) which command should I use to tell Guix to use the GRUB already installed?
<rain1>there is danger it wil overwrite your bootloader
<adfeno>I mean, I want to be able to use the bootloder. (I'm not talking about the package). :D
<ajgrf>adfeno: in the operating-system section of your system config, put (bootloader (grub-configuration (device #f))). you will get an error when you reconfigure but it's safe to ignore, i do this on my system
<adfeno>So, when I finish installing GuixSD, I have to take my Trisquel live media, boot it, prepare a chroot envirnment to install the GRUB from the installed Trisquel on the disk?