<usney>also it doesn't last as long and it is expensive
<butterypancake>but it's in theory the best compound out there I think. And LTT found a tiny difference if I remeber properly. Meaning that unless you're currently using toothpaste, I don't think you have much more improvment you can gain
<usney>yes but my thermal paste is an unknown age it is just a tube I have that I haven't used in a long time
<butterypancake>well the cpu tends to lose the ability to keep up with modern stuff anyways after 5 years so maybe I don't notice. Please don't convince me to run around repasting all my electronics every 3 years. You make a convincing argument but ignorance is bliss
<usney>but maybe it is good to not too also because I read if you don't clean it properly it can create even more problems of not reducing heat properly from microtears on the surface of the cpu.
<butterypancake>that sounds like houey. Just 99% alcohol + non-pilling cloth + time and care = perfect thermal job.
<usney>I guess it your computer ever has issues and it is old probably repasting the cpu or gpu would be a good step to try
<usney>yes that is how it is recommended butterypancake
<butterypancake>I would never do a gpu. first off they're cheap. second off they are a bitch to take apart with all their thermal pads and crap
<usney>however I didn't use a cloth I used cotton qtips dipped in rubbing alcohol to clean it off.
<butterypancake>i dunno if cotten qtips leave anything behind or not... I use coffee filters because they are made to not leave any particles behind
<usney>my gpu I think is soldered on the motherboard so I'd have to either buy a new motherboard or desolder and get a new one and resoldered it on.
<usney>but it runs at a very low temperature anyways so I am not concerned about that.
<butterypancake>meh, gpus are so finicky I make sure my laptops just don't have them :P
<butterypancake>although changing the thermal compound on a laptop gpu is probably not as bad as a dedicated gpu
<butterypancake>well you need graphics so yes i use integrated graphics. mainly I stay away from anything with a dedicated gpu because that usually means you now have 2 gpus and that is a mega pain in linux
<usney>I am not sure if my laptop is capable of a dedicated gpu but I never looked into it but probably one you connect to it from the outside would work though.
<butterypancake>they got fancy thunderbolt docks these days. they look pretty cool
<pkill9>sneek later tell butterypancake it's only necessary until you re-login, it just means it didn't detect that environment variable set to that profile, which it won't be if it's a new environment variable that didn't exist before, so guix warns you
<olivuser>So this morning I tried setting my login/session manager to slim. Is it necessary to manually remove (via (remove ...) in services)?
<olivuser>sorry, the remove-question is related to gdm: do I have to manually disable/remove gdm for it to be replaced by slim? Gdm eats just so much more ram...
<olivuser>Also, if I understand correctly, changing the keyboard configuration, the whole configuration form for slim is (service slim-service-type (slim-configuration (xorg-configuration (keyboard-layout ...)))). But when I input (keyboard-layout keyboard-layout) (as is specified in the beginning of the system config), it throws an error, even though it works fine for the bootloader. Why?
<olivuser>Also, for some reason I cant try sddm. When I place a minimal (service sddm-service-type), it asks whether I have forgotten a use-modules form, even though it is the same for slim and sddm. Why?
<lprndn>oliver: for gdm, yes you have to remove it if you use %desktop-services.
<lprndn>for sddm, the sddm service is defined in gnu/services/sddm.scm so you have to add sddm to the (use-service-modules ...) of your configuration
<lprndn>(slim and gdm *services* are defined in gnu/services/display-managers.scm , I think)
<rekado_>re string escape: (string-append "foo" "bar") is equivalent to "foobar". If you’re using string-append only for cosmetic reasons so that you can put ‘foo’ on one line and ‘bar’ on the next you could also write "foo\bar” with a line break after the \
<lprndn>rekado_: ok thanks! I'll do as much as I can (specially for comments). I might leave onething or two if i'm not sure how to deal with it and send a new set of patches. is it ok for you?
<apteryx>raghav-gururajan: my hands are caught in something else at the moment (inkscape 1.0), but I can try to take a look later. Guix lint looks good? Reproducible? No fat directory that should be move to doc/ elsewhere (I like to use du -sh (guix build package)/*) for that
<raghav-gururajan>apteryx Thanks so much! Yes, guix lint is good. Btw, I did not package Twinkle, I just made some tinkering. :-)
<civodul>mbakke: dunno, we can always restart Cuirass...
<apteryx>raghav-gururajan: ah, OK, I thought it was new :-) I've never tried it.
<apteryx>rekado_: how is the file system laid out? is there any smaller part of it that we could experiment migrating to a compressed Btrfs version? If there's no extraneous garbage root, and if 'guix gc' doesn't help much, I don't see another path (buying disks is one but it's slower to go through that path)
<apteryx>alternatively we could try finding really expensive store items and mark these as "non-substitutables", but that's sub-optimal.
<rekado_>yeah, I don’t want to mark anything as non-substitutable
<rekado_>37T ought to be enough with deduplication
<reepca`>is a server process gc'ing its own temproots file expected behavior?
<reepca`>it happens because readTempRoots thinks that "nonblocking write lock acquisition succeeded" means "temproots file is stale". But of course that's not true when considering its own temproots file.
<civodul>reepca`: BTW, if you're implementing temp roots, i'm interested in using them on master so we can remove with-store from (guix nar)
<civodul>raghavgururajan: the latest patch looks great, thanks!
<reepca`>civodul: aye, that sums it up exactly. Although the patch listed there would introduce another problem, namely that when the fd gets closed it will clobber any read lock it has on its own temproots file. So then it would be seen as stale by every other process.
<reepca`>I've got a I-think-it-works file-locking interface that *should* work with fibers, which I've used to implement add-temp-root. It comes with quite a few warts currently, though, so I'm debating whether to redesign it. For example, all i/o to ports corresponding to locked files has to be done with pread() and pwrite(), and since custom-binary-ports are implemented in C in guile 2.2 we can't suspend from them, so we have to use special
<reepca`>put-bytevector and get-bytevector procedures directly...
<civodul>janneke: you feel like feeling in the blanks? :-)
<reepca`>oh, and speaking of (guix nar), I've noticed a few issues in there. One is that the with-store form should be around the (let loop ...) instead of inside it, as it prevents the loop from being a tail call and opens a new connection for every retry (without closing the old one).
<janneke>(and for creating blanks, that's already helpful :)
<reepca`>The other is that finalize-store-file doesn't follow the proper store-file-lock-acquiring protocol. It doesn't check for the deletion token and retry when acquiring, and it doesn't write the deletion token or delete the file when releasing.
<sirmacik>did we just get an update to kernel 5.6?
<mbakke>sirmacik: the 'linux-libre' variable still refers to 5.4, but 5.6 is available as 'linux-libre-5.6'
<civodul>looks like there's a handful of people well versed into this
<reepca`>civodul: hmm, well the way that I've fixed finalize-store-file locally uses my 784-line (guix store locks) module, which also depends on guile-fibers and quite a few other changes. Would it be better to try getting that ready for merging or to just write some standalone inline code for finalize-store-file?
<mbakke>civodul: I guess we should bring the kernel maintenance issue to guix-devel for visibility
<civodul>i was hoping with-file-lock would be enough
<civodul>also, can we use Fibers in the daemon? the dameon should be single-threaded because it forks
<civodul>i guess we can tell Fibers to use a single thread
<civodul>or we could have a "safe" spawn primitive in C
<raghavgururajan>civodul: I have made a similar patch to fix fhs paths in claws-mail (#41111). If you could push that as well, that would be great. :-)
<reepca`>the 784 lines are part of a more general solution for multiplexing process-associated file locks across fibers/threads. Handling reuse of ports, synchronizing opening and closing of ports, etc.
<cyclopsian>Is there any interest in having signalfd/pidfd/timerfd support in shepherd? or would these be too linux-specific?
<krusnus>Whenever i do "sudo guix system reconfigure" i get the error "guix system: error: exception caught while executing 'eval' on service 'root': Unrecognized keyword: #:file-creation-mask" does anyone know how tofix this?
<mbakke>krusnus: can you file a bug report? multiple people have reported this on IRC, but there is no bug about it.
<mbakke>IIRC from earlier discussions it has to do with an incompatibility between old shepherd and new service definition
<mbakke>we should probably revert the commit, but it would be good to have an issue to refer to
<apteryx>mbakke: I can't see special patching to php's gd that'd fix those tests, but it's hard to track given they don't use a clean git submodule + separate patches for it.
<sneek>butterypancake, pkill9 says: it's only necessary until you re-login, it just means it didn't detect that environment variable set to that profile, which it won't be if it's a new environment variable that didn't exist before, so guix warns you
<raghavgururajan>bricewge Nah! I opened new branch just to re-create the first patch.
<sneek>Welcome back raghavgururajan, you have 1 message!
<sneek>raghavgururajan, bricewge says: So you managed to tame git rebase interactive?
<bricewge>raghavgururajan I encourage you to try again some time, this is really useful to edit commits.
<bricewge>Do I keep or revert the switches to url-fetch?
<jackhill>mbakke: I'm testing the webkitgtk patch now (thanks!). I too, am waiting on it to build :)
<mbakke>jackhill: great, thanks. I tested a popular video streaming site in Epiphany with those patches and it seemed fine. :-)
<mbakke>'herd stop cuirass' did not actually stop cuirass, hmm
<jackhill>mbakke: great, I optimistic it will good enough to not block the core-updates merge then. I think to improve on sharing the whole store, webkitgtk would have to be taught how to ask Guix for what its closure is.
<mbakke>rekado: Berlin's clock seems to be 10 minutes off.
<jackhill>I'll follow up on the issue once I've finished building/testing.
<jackhill>terpri: ^ it looks like I may not have to fix the webkit bug. At least in the short term :)
<NieDzejkob>I'm trying to run an aarch64-linux build on bayfront, it's 1. building everything starting from guile-bootstrap, 2. erroring with "while setting up the build environment: a `aarch64-linux' is required to build `/gnu/store/lnhrw8cwmb5qpfgldrfzbxcq8v8xskq9-guile-bootstrap-2.0.drv', but I am a `x86_64-linux'". A quick look at /etc/guix/machines.scm shows that there *are* aarch64-linux machines it could offload to. What gives?
<rekado>I should gift them eye drops to grease those ever rolling eyeballs.
<NieDzejkob>oh, the command I tried to use is "./pre-inst-env guix build --system=aarch64-linux unicorn", maybe there's something wrong with that
<cbaines>looking at guix processes, quite a few are Cuirass
<NieDzejkob>huh, I just realized that bayfront is not what runs the CI, and yet there's cuirass running on there. So, is it duplicating what berlin does? What is the goal here? Reproducibility checking?
<cbaines>at least one of the cuirass evaluate processes seems to have escaped
<civodul>NieDzejkob: yes, reproducibility testing mostly (see data.guix.gnu.org)
<lfam>NieDzejkob: Originally, Bayfront was supposed to run the build farm, so we made the effort of setting up Cuirass. But, the hardware was too unreliable, so we set it up as a secondary build farm while building the primary one at Berlin MDC
<cbaines>Cuirass looks to have multiple connections open to the daemon, all building things
<cbaines>Yeah, counting them all, the single cuirass process has 16 connections to the daemon
<rekado>hmm, commit c26146881ac826ec0f1a49d86bfe874be8d355e6 includes a patch that has a dubious justification.
<ik1>Sorry for interrupting guys. I`m in the middle of my first installation right now. And I stucked at "building /gnu/store/bla-bla-gcc-7.4.0.drv..." So does it *build* compiler right now? To be honest I thought it`s gonna be a *binary* installation. How long does it take to build x86-64 system on Core 2 Duo CPU? Where in the GNU Guix Reference Manual I could understand about this (binary vs building from source)? Section 2 says about making
<ik1> Guix in foreign distro and Section 3 has only "Once you’re done, the installer produces an operating system configuration and displays it (see Using the Configuration System). At that point you can hit “OK” and installation will proceed. On success, you can reboot into the new system and enjoy. See After System Installation, for what’s next! " I am aware of the project goals and written software, so you may not lecturing about
<ik1>this. I was not prepared for compiling from source every aspect of the system, that`s why I use Arch instead of Gentoo on a notebook (Thinkpad X200). And I wanted to switch to GuixSD. Thanks for replies.
<lfam>ik1: You shouldn't need to build things here
<lfam>ik1: What section of the manual are you following for your installation?
<lfam>ik1: Or, are you just using the guided installer to install Guix System?
<ik1>3 System Installation > 3.3 USB stick and DVD Installation > 3.5 Guided Graphical Installation
<bav[m]>rekado: the "I prefer the older interface"?
<lfam>ik1: Can you ping <ci.guix.gnu.org>? If you don't have the ping command (not sure if it's available in the installer image), you can try `guix download https://ci.guix.gnu.org` to test the connection
<lfam>It shouldn't give a sense of being "stuck" unless something is really wrong with the I/O
<ik1>Guys easy. I`m starring on the black screen of installation. Probably I can`t answer your questions. The package it tries to build is b1r8ij432dnn2qxm6xkg7kxyz2z6iyjr-gcc-7.4.0.drv
<lfam>ik1: To answer your question about whether or not Guix is a binary distro, it's actually a build-from-source distro with transparent binary substitution. So, Guix decides what must be built, then checks if those things have already been built on the build farm, and "substitutes" them if they have.
<katco>what's the recommendation for authoring packages with large numbers of configurable features specified at compile-time? compile them all in? multiple packages for each feature?
<NieDzejkob>katco: if there's something particularily, like vim with gtk support, you can split it into a basic and full package
<lfam>katco: In general, we aim to offer fully-featured packages. Sometimes it's convenient to split the built package into multiple "outputs", but that's only really worthwhile if the outputs don't contain store references to each other, or if it's typical to not want certain features
<NieDzejkob>ik1: FYI, there's a shell at alt+f3 and alt+f4, so you can check the output commands while the installer does stuff
<katco>lfam: ok. working on rsyslogd, and its modules explode the graph bringing in `inputs` like `postgresql`
<katco>NieDzejkob: that's an example, but more of a binary situation. this package has ~90 options
<lfam>I think it's okay to depend on multiple databases. Some packages are just really big
<katco>it's just not known at packaging time which of the ins/outs a user would want
<apteryx>lfam: I'm running a last build of (hopefully) succeeding Inkscape 1.0. I managed to clean up some things on the way, so the remaining effort will be to externalize more bundled libraries (there's 3 packages missing to do so).
<apteryx>I should be able to send the patches within the next 2 hours
<katco>what would be ideal is build once with outputs for each of the plug-ins, and then somehow associate inputs with the plug-ins
<katco>i enjoy `guix pack` so i am sensitive to a package's overall size.
<katco>lfam: re. rsyslogd, how do you feel about moving the module dependencies to `native-inputs` so that users would have to install packages relevant to the modules they're using? that way, postgres wouldn't come along for the ride if you want to install rsyslog for use with say, kafka.