<daviid>rekado_: no rush of course, if the debian paste i posted earlier today expires when you want to deal with the tiny correction i did ask for, the 3 paragrahs i recommend to use for the guix gule-cv synopsis/description 'fields' are on the front page of the guile-cv site ...
<olivuser>if I were to try to implement lxqt as desktop service, would I find help in the guix/guile manuals? Or do I need other resources
<olivuser>Also, which commands do I have to pass regularly to maintain guixsd as a user? I mean, is guix system reconfigure a component of user maintenance, or could a user change, p.x., the desktop service in an easier fashion?
<efraim>The first part for lxqt would be to upgrade the components and make sure all the parts are packaged
<olivuser>But I guess I would find the necessary components-"barebone" in guix/guile and the definitions of gnome-desktop-service and others, right?
<olivuser>That is, an overview of what is required for a desktop service to be properly defined.
<apteryx>efraim: I just answered to your comment about the openntpd-service-type
<apteryx>I will try to test openntpd more to get it to sync at least; I wonder if one of the oddities I spotted in the generated config may be at cause
<apteryx>efraim: ah, the sync problem stemmed from the use of constraints
<efraim>apteryx: I don't actually use the constraints with my setup, thanks for taking a look at it
<janneke_>do we have a --target option for guix environment yet?
***janneke_ is now known as janneke
***abbiya_ is now known as abbiya
*janneke digging in my old mingw cross patches for how to setup a cross environment with a mingw xgcc package
<olivuser>hello everyone. I just installed guixsd afresh from usb stick. guided installation went fine, it is only when I was asked to remove the usb stick and restart that the installation froze and I had to restart.
<olivuser>now that I am booting to the system for the first time, I cant guix pull. it says that building guix-symste.drv has failed, and guix pull is aborted
<olivuser>also, the build of profile.drv has failed. this "comes to light" only when I run guix pull with the --fallback option.
<olivuser>does anyone have an idea what might have gone wrong and how to fix it?
<rekado_>olivuser: it should also report the location of the log file corresponding to the failed build.
<rekado_>olivuser: could you paste this somewhere please so that we can see what’s wrong?
<rekado_>“--fallback” causes Guix to build things locally in case of network problems.
<rekado_>olivuser: to answer your earlier question about maintaining a Guix System: you just need “guix pull” to get a more recent Guix (that has access to updates and security fixes), and then reconfigure your system with “sudo guix system reconfigure /etc/config.scm”.
<rekado_>“guix system reconfigure” will build a new system as specified in the configuration file, and make it the default when booting.
<rekado_>on its own “guix system reconfigure” won’t give you anything new, though. Building with the same version of Guix will always give you the same system. You need “guix pull” before that to get access to changes, fixes, updates, etc.
<olivuser>rekado_, thanks for the replies, will reply in the next minutes/hours!
<olivuser>rekado_, also, it seems like the problem has mysteriously solved itself. Is it possible that this is related to the desktop environment that I chose? because it has not worked under mate but now works under gnome
<olivuser>and there is one difference I seem unable to understand: when I want to reproduce the same system (especially programs) in different computing environments, do I have to write that in the same configuration file that I instantiate using guix system reconfigure? and if I do, do all users have access to it?
<efraim>It was with the master branch, it was broken for about a half hour
*civodul founds that CI was not really happening for ARM on 'core-updates'
<Minall>Maybe the error is because the package is from emacs?
<joshuaBPMan>morning guix. I'm running nginx from /srv/http/, which is a symlink to my ~/prog/ (programming) directory. Trying visit the site at localhost:8080 and nignx is telling me "403 Forbidden". I'm not certain what I am doing wrong...
<Minall>When trying to install a package on emacs-guix, I got the messages: The process begins ... Then 'The following package will be installed: then the package... and then this message: guix/profiles.scm:292:22: Throw to key `srfi-34' with args `(#<condition &profile-collision-error [entry: #<<manifest-entry> name: "emacs-dash" version: "2.16.0" output: "out" item: "/gnu/store/qwm0zza4h8jfw15nqvla86z9yg6fw3yl-emacs-dash-2.16.0" dependencies:
<Minall>() search-paths: () parent: #<promise #<procedure 22bd320 at guix/profiles.scm:309:61 ()>> properties: ()> conflict: #<<manifest-entry> name: "emacs-dash" version: "2.16.0" output: "out" item: "/gnu/store/wd7pmrgb54skkkv2f3yiz9vwhsr5svpf-emacs-dash-2.16.0" dependencies: () search-paths: () parent: #<promise #<procedure 237ad60 at guix/profiles.scm:428:58 ()>> properties: ()>] 22a2420>)'. And no installation, the last message I get is
<Minall>'Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue
<dongcarl>mbakke: So I've been reading your gcc bump commits, mostly trying to understand implications around cross-compilation...
<dongcarl>From what I understand... We will no longer use `CROSS_*_PATH`, but rather `CROSS_CPATH`?
<vagrantc>so, diffoscope has a huge number of optional features that are enabled when additional packages are installed, and also runs the test suites ... should i add all the optional packages to native-inputs so all the functionality is tested?
<janneke>hey dongcarl, did anything come out of a discussion about something like guix environment --target/--cross?
<janneke>civodul had a vague recollection of something like that
<dongcarl>janneke: No I don't think so... I believe we agreed it should be done, but nothing came of it
<janneke>you don't really like small challenges eh? ;)
<vagrantc>to add all the possible tests, i'm wondering if diffoscope still belongs in package-management.scm or if somewhere else might be a better home ... still don't understand the implications of all the use-modules entries
<vagrantc>janneke: well, as i've been finding and adding additional optional packages for diffoscope, i realized that it was probably skipping most of the tests ... and that's not good
<vagrantc>since it only runs the tests if the tools are present
<janneke>ah, so you're finding-out new things each iteration...
<vagrantc>trying just to get the number of skipped tests down by adding additional tools to the native-inputs ... hope that's a reasonable way to approach it
<vagrantc>though it will make diffoscope builds have a lot of dependent packages
<vagrantc>also wondering if it would make sense to add a diffoscope-with-all-the-features-enabled package
<sebboh>Hm. I just created a new user and copied /etc/skel to make their home directory. But when I do `guix install foo` for them, I get some old version of foo. Now, I should just run `guix pull` first, I get that. But, how'd that even happen?
<sebboh>Actually I get an error when I guix pull with this new user. *deep breath* Ok, I'll create the user the guix way.
<civodul>sebboh: yes, you should create it the guix way :-)
<reepca>if you're on Guix System, the user's path most likely only includes /run/current-system/profile/... so they're basically running the "system" guix - the one that was used to create the current system generation. Which, does tend to be more out-of-date than the user ones.
<reepca>hmm, looking through (gnu packages java) it looks like although we have packages named openjdk, we don't have any of them bound to a symbol named openjdk. So yeah, ,opnjdk10 or whatever version will be necessary.