<nckx>PotentialUser-92: If the site is compromised (in order to upload malicious tarballs), then so are any checksums on it. The attacker would simply change them too. The key server thing is unfortunate, but this can be solved by updating the manual (it was simply an oversight) and Ludo' uploading the refreshed key.
<PotentialUser-92>He may have uploaded his refreshed key but that doesn't get it to a key server that doesn't work.
<rekado_>PotentialUser-18: if you want software to be installed system-wide is either has to be done in the operating-system configuration or for read-only access a single user can install software to a globally accessible location with “guix install -p /the/location …”
<PotentialUser-18>I'm used to apt-get/yum install gawk which provides it to the whole system. Is the OS config /etc/config.scm in this case?
<PotentialUser-18>I would recommend a section in the manual covering system wide package installation. It's the most basic of operations on the distros others are coming from so it should be made much more clear.
<rekado_>PotentialUser-18: it’s already in the manual
***civodul changes topic to 'GNU Guix | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs and patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel is logged: http://logs.guix.gnu.org/'
<quiliro>djaska: that would be great...i do not know if it is possible....the most i have been able to do is use emacs-guix to see in an easier way which does what
<quiliro>civodul: ĉu vi pensas ke la priskribo estas tro longa?
<quiliro>Dynamicmetaflow: si especificas en tu archivo de reconfiguración al otro sistema con grub-configuration y tomas en cuenta la definición correcta de las particiones, teoricamente no perderías tu otro sistema
<quiliro>Dynamicmetaflow: pero se me ocurre que puedes ejecutar qubeos en ua máquina virtual dentro de guix!
<samplet>mbakke: I’m leaning towards populating “/etc/timezone”, but that’s because reading the symlink seems really bad (even if it’s common). I imagine that the symlink approach would make us a little more like other major distros, which might mean avoiding issues in the future. What do you think?
<samplet>IIRC, there is a reason it is not a symlink already, too.
<samplet>I don’t recall correctly. It looks like “/etc/localtime” has been copied since forever.
<mbakke>/etc/localtime being a symlink could lead to issues in some container configurations, or in an initrd without access to /gnu/store.
<mbakke>*perhaps, I don't know of any discussions about it.
<mbakke>Populating /etc/timezone seems like a reasonable workaround.
<samplet>dongcarl: Usually quite a bit of manual testing in addition to fixing problems reported by the build farm. After a while, when the build farm has substitutes for most packages, we merge the changes into master, making them available to everyone by default.
<dongcarl>samplet: Understood! How long is the freeze-to-master period usually?
<dongcarl>Huh, what about donations to the Guix project?
<lfam_>dongcarl: At this point you'd better ask on the mailing list but I think it could be given to FSF under our care. The main "Guix" org from a legal perspective is Guix Europe which is obviously not USA
<lfam_>mbakke, nckx: Not a bad idea, although considering the frequency of releases I don't know if we would gain anything
<mbakke>It's a better experience for end users if they should ever want to verify git signatures :)
<lfam_>mbakke, nckx: It would be nice if it offered a path to verifying commit signatures but I don't see a future for PGP in Git... I don't know if anyone involved in Git development is thinking about the future of PGP but it seems rather bleak
<mbakke>OTOH, anyone could theoretically "forge" a tarball archive, so maybe not.
<nckx>Speaking only of release tarballs/isos etc.: I'm a bit hesitant to replace civodul's key with a full keyring. Is that worth a ‘stable’ URL?
<lfam_>It seems like the PGP community is ditching the web of trust. In that case, it doesn't offer much beyond signify for the purposes of signing things
<nckx>Interesting that your analysis confirms my gut feeling for a while now.
<mbakke>nckx: Dunno, it's probably not worth the effort considering the uncertain future of GPG.
<lfam_>It's a very amateur analysis :) Trust your own gut too
<dongcarl>signify seems simple and works pretty well 😊
*nckx wishes they could stay & chat but were actually just behind the keyboard to download a film. I'm definitely interested in discussing this further, since ‘trustable Guix pull’ has been on the to-do list for far too long. o/
<str1ngs>also guix can build containers if you are looking for process isolation
<Dynamicmetaflow>I'm trying to wrap my brain around xen and how qubes uses it and also realized that guix has a xen package, so trying to imagine if it would be possible to create a qubes like setup with guix
<str1ngs>I would try the guix way , before trying to adapt something to work with guix first.
<str1ngs>guix has containers and VM's try those primitives first see what the millage is first IMHO
<ng0>Dynamicmetaflow: back then I worked a bit on an initial xen package, but no usable endresult
<ng0>if you want to get your hands real dirty, it's out there. but presumable requires further porting once it builds
<Dynamicmetaflow>When searching guix packages, I found a xen package, pardon my ignorance but would I need additional packages or is there something I'm not seeing here, I'm new to xen etc, always heard of it but never tried it out https://hpc.guix.info/package/xen
<ng0>ah, interesting. then hpc guix worked on it too
<mbakke>lfam_: Speaking of golang, it would be neat to get rid of the GCC6 input on 'core-updates' :-)
<ng0>i haven't checked in guix for a long time, so it might as well be in guix master.. no idea.