<sneek>Apteryx, alezost says: re "emacs-dvc": Guix's Emacs find elisp files in "share/emacs/site-lisp" and "share/emacs/site-lisp/guix.d/<pkg-dir>" but not in "share/emacs/site-lisp/<pkg-dir>". In such cases we modify package recipes to move the files into one of those dirs
<efraim>i'm 6000 miles away and i think its stuck at fscking the external harddrive
<ryanwatkins>Anybody have any idea why my current system profile would still point to /run/current-system/.../guile/site/2.0 for a given guile of version 2.2?
<Apteryx>I'm thinking for remote admin of machines (which I don't do right now), I'd setup a 2nd mini device reachable by OpenSSH and which can then control the main machine via serial port for these times when we need to debug something in GRUB/BIOS.
<ryanwatkins>My latest guile packages don't seem to be symlinked accordingly
<ofosos1>simply symlinking .real-bluetooth in /gnu/store to `wifi', `bluetooth' and `wwan' make them work again
<ofosos1>also, tlp profiles are not applied at startup, is there a good way with shepherd to execute some action on system start?
<ofosos1>tlp is practically a neccessity, since power consumption on a laptop is 50% higher, compared to running without tlp
<ofosos1>also the tlp package lacks the /etc/tlp file, you can create this from scratch, but it should at least contain something like /etc/default/tlp, possibly in /gnu/store
<ofosos1>is there a way in guixsd to run a script on startup? i would like to build a shepherd unit (correct name?), which seems feasible, i.e. use the no respawn option and then run on startup to at least run tlp initially and maybe respawn it from time to time
<davexunit>I see that someone updated Kodi. that's awesome news.
<davexunit>glad to see someone besides myself make sense of that mess of a build system they have!
<civodul>BTW: never ever modify files in /gnu/store
<ofosos1>has anybody some debugging tips? i can't seem to get mcron running, the service crashes and shepherd disables it. no logs whatsoever
<IHateIRC>Hello, I am dual booting parabola and guixSD. They both share the shame /home, but have a different /. I'm making my two users (joshua) have the same id. (uid 2000). Is there any other groups that I should make sure have the same id?
<ilyaigpetrov>if guile is not purely functional, then how may be software updates be pure?
<catonano>ilyaigpetrov: software updates being pure doesn't depend on the language. A software package is given a unique hash and the compiled packages are managed by a daemon, not by the common programmer. That makes the software updates "pure"
<catonano>ilyaigpetrov: if you, or example, change something in the store, you'll see that it won't work anymore
<catonano>ilyaigpetrov: because the store is supposed to be managed by the daemon
<ilyaigpetrov>catonano: does guix package manager depend on systemd equivalent you use?
<ilyaigpetrov>ok, I think not, because you may run this package manager on other systems
<catonano>it doesn't depend on the services layer. In fact the pacage manager can work as a user software on top of other distributions. BUT in GuixSD the packkage manager works along with the services layer
<ilyaigpetrov>catonano: what is this only daemon guile interacts with?
<janneke>catonano: what exactly did you not understand, I think he made several points
<OriansJ>janneke: did you ever get around to forwarding our discussion?
<random-nick>is there a possibility of a hash collision in a guix store?
<OriansJ>random-nick: technically yes for every hashing method, however the question is one of probability aka using crc8 means highly likely, md5 rather lower, sha1 only if being actively attacked and sha512 if something hightly unlikely happens
<random-nick>so how does the store behave in a hash collision? does it overwrite the package which was there first with the colliding package?
<janneke>OriansJ: I think I suggested that you would just re-send your 2nd message `You missed my later work' to guile-user and I'd answer there
<janneke>ACTION notices that's a very verbose `no, not yet' ;-)
<catonano>janneke: thhey say that the current raccomandatiion of the fs community is to use approved distros thaht have some parts removed. But this makes the chain from upstream to the final uusers longer and more complex. But how would Guix help with security ? Guix distribuutes thhe libre kernel and Icecat. The whole distro is different but some important parts are still subject to that spell
<efraim>random-nick: guix uses sha256 for the hash by default, I haven't dug into the code to see if it'll overwrite the existing package but I assume it would
<janneke>catonano: Brett states that `GuixSD stands a chance', in that it differs from all the others by two significant factors