<ng0>I discussed bugtrackers somewhere else with a contact of mine, and the general idea from their side was that all bugtrackers integrated into git-forge solution out there suck, and freestanding bugtrackers are rare and no one ever got it right. To get this right, or at least improve the interface to default debbugs would be great work. (I'm okay with it as it is)
<fusion809>Hi folks I have another query, hopefully my last, how can one set SLiM to autologin? The Arch Wiki has an article on this but it's not exactly applicable as is to GuixSD as /etc is regenerated on boot and their method involves editing /etc/slim.conf.
<fusion809>What are paths relative to in /etc/config.scm? I'd like to specify a sudoers file but placing it in /etc/guix/sudoers and specifying that exact path in config.scm causes the build to fail as it can't find that file.
<fusion809>Specifying guix/sudoers in it too also fails
<Apteryx_>You need to wrap the file path into a file-like object as can be obtained by using local-file or plain-file (see 6.2.2 in the info manual).
<Apteryx_>In your case you'd want local-file since you have the file on disk
<dfens>I'm just using the default minimal desktop install but with ratpoison removed.
<dfens>I am using the guixsd-usb-install-0.13.0.x86_64-linux image too
<fusion809>Hey folks Guix is meant to be cross-distribution right? On Arch Linux running guix package -i icecat returns: `guix package: error: build failed: failed to get list of supplementary groups for ‘fusion809’`. Any ideas why?
<fusion809>Aha it works. Sorry should have read the manual, thanks for your patience. There is one thing, however, that I know the manual can't help me with as I have looked for this in it. How do I set slim to autologin on boot on GuixSD? The manual mentions it briefly but it gives no examples so I am rather stymied as to what to do
<fusion809>I've never used one before except for i3 where I used a feh command. So I tried to model it after what the Arch Wiki says xinitrc should look like for GNOME but it's failing to launch. What should be in it for GNOME?
<ng0>which is tiny (91MB) compared to mate-terminal (~600MB)
<civodul>ng0: yeah looks like st doesn't fit the bill
<Apteryx_>civodul: In the continuous integration world (such as hydra is providing), is there a strong case against reusing previous build artefacts to speed things up? I know it introduces complexity at handling determinism, but it's doesn't seem unmanagable to me.
<Apteryx_>Seems wasteful to start from scratch every time when we have the means to only rebuild files affected by the latest diff.
<civodul>Apteryx_: in the purely functional model, we don't want to reuse a handle of prebuilt files to speed things up
<civodul>or, put it differently, the granularity is that of derivations
<htgoebel1>civodul: I checked all this without success.
<htgoebel1>unionfs is only used twice in the whole code:
<htgoebel1>1) In gnu/build/linux-boot.scm (mount-root-files-ystem) to make a unionfs root
<htgoebel1>2) in gnu/system/install.scm (make-cow-store)
<htgoebel1>So I thought it may be a file-system defined in install.scm, but there is only %immutable-store, which does a ro-bind-mount, not a unionfs.
<htgoebel1>And in the disk-image's initrd's init-script I could not even find this.
<civodul>Apteryx_: so if you make derivations smaller, you can reuse more
<htgoebel1>civodul: The actual question is: Which test (-case) to run after replacing unionfs with overlayfs
<civodul>if you can run "make check-system TESTS=basic", then you'll probably good
<htgoebel1>(The otehr stuff is just curious (un-explainabel) things I found when trying to test manually)
<htgoebel1>civodul: "make check-system TESTS=basic" on my development machine? Or in some VM?
<Apteryx_>civodul: I see. Yeah, it would introduce the requirement to track a state, such as the closure that built the previous build. A change of that closure (say we updated Guile) would trigger a fresh build. Not ideal. But it'd reduce the build time phenomenally and save electricity ;)
<Apteryx_>By the way, I've gleaned from the Debbugs UG info manual that there is some function already there to apply patches easily; whether they come as attachments or in the message body: '(debbugs-ug)Applying Patches'
<ng0>I've recently felt I need a bugtracker for my work… and (once more) I've been reading the Debian work and crash on Gitlab (just for git interface though) https://anarc.at/blog/2017-06-26-alioth-moving-pagure/ and they have worked 5 years on Gitlab… hardcore. I'm just thinking of getting more RAM and use pagure.. they might not be good at bugs, but it's a compromise
<fusion809>It turns out that those Perl packages weren't downloading as the source files no longer exist on the server. Only newer versions of those packages exist on that server. So, for example, for Test-Deep 126 and 127 versions exist on the server. Guessing filing a bug at https://bugs.gnu.org/guix is the appropriate way for me to inform Guix developers of this problem?
<efraim>tig seems to have moved the release tarballs to github
<rekado>looks like it would not be enough to subscribe a bot to the mailing list
<fusion809>I think I'm going to uninstall Guix with my package manager, and install it from the binary. In case my package manager deletes /gnu/store I'm compressing it to back it up. Would decompressing it after I've installed it using the binary successfully restore my packages installed with Guix?
<rekado>maybe I’m just missing control messages that are the result of using the emacs interface to debbugs.
<rekado>fusion809: that wouldn’t help as Guix will ignore items in /gnu/store that are not registered in the database (which you would overwrite)
<civodul>rekado: yeah i think it's safer to have a SOAP client like debbugs.el does
<civodul>then, if the mu Guile bindings are good enough, we could use them to send control messages when someone clicks
<rekado>the mu bindings only give you read-only access to mails in the database