<mange>Is there any way that I can use guix system to build a VM in which I can run guix system commands? (In particular, reconfigure.) I get an error about changing ownership of /gnu/store when it's a read-only file system.
<thomassgn>mange: sound like a permission problem, do you have guix installed on a foreign distro?
<buenouanq>thomassgn: well, I'm now able to at least see/find the print - But getting the error ./base/gsicc_manage.c:1863: gsicc_verify_device_profiles(): Mismatch of ICC profiles and device color model
<EternalZenith>thomassgn: I was using substitute* earlier, the build was failing at 50% and with using (substitute*) to fix the paths it managed to get it to build to 66%
<EternalZenith>The issue was that the build would fail when the header files that I had to change the path to would themselves look for another file in the wrong path
<EternalZenith>If I would try to do the same thing again I would have to build the dependency, libevdev, using substitute* to change the paths it uses to refer to its own files in the #include's
<AlishbaKabeer>I can't start X guys. can someone help me? I'm new to guixsd
<sneek>Welcome back AlishbaKabeer, you have 1 message.
<sneek>AlishbaKabeer, thomassgn says: Hope the setup and reboot works. I am sleep. but ping me if you like - I check in almost daily. Happy hacking :)
<EternalZenith>xorg-start-command - "Return a startx script in which modules, a list of X module packages, and fonts, a list of X font directories, are available. See xorg-wrapper for more details on the arguments. The result should be used in place of startx."
<EternalZenith>I'm going to have to figure out how exactly to do this, though
<EternalZenith>Two things though: in order for the lock screen to work, you'll need to install i3lock-color, and secondly, x11-socket-directory-service should probably have parentheses around it, but I'm not entirely sure it's necessary with the %desktop-services
<AlishbaKabeer>so I can recofnigure it now or I have to chroot into? I'm rebooted from installed system now
<AlishbaKabeer>EternalZenith: I once did reconfigure it and got virtual consoles stopped working
<EternalZenith>I think "guix system reconfigure /etc/config.scm" should work
<EternalZenith>AlishbaKabeer: The reason the ttys stopped working was probably because you removed the %desktop-services
<EternalZenith> "(service slim-service-type)" and "x11-socket-directory-service" should be commented out
<EternalZenith>One thing to note about parentheses: whenever you have something surrounded by parentheses, that tells the lisp interpreter to evaluate that like a procedure (the lispy word for a function)
<g_bor>One problem janneke was facing using the npm importer is that hundreds of packages were generated, this amount is not acceptable if we want to include them in the repository, it just results in too big commits, and a bloat in code.
<g_bor>This is actually a type of package generator, like we already have for example for python2.
<rekado>I’m still not understanding how one would define a package that happens to depend on a large number of node packages.
<g_bor>rekado: I am not sure, but if it does, then this could work for other language specific package managers.
<g_bor>I think this only depends on the code on our side, if we use the exact commits.
<rekado>g_bor: I’m a little uncomfortable with this as we would throw away the package and build system abstractions, even though we still have to build things.
<rekado>unless you only want to use this for producing source code.
<g_bor>rekado: Actually I don't think we have to. Another possible interface would be to create a package (the description on how to generate the packages), and a build system to specify the steps to get this going.
<rekado>so the “npm-importer” thing would fetch the complete source code bundle, which would then be ready for compilation *at once*.
<g_bor>I've been also thinking about how can we automate upgrading jdk as much as possible.
<g_bor>We could do something like: bootstrap latest jdk, then recursively walk form the leafs of the dag until we have packages with ant-build-system, specifiying the latest jdk, check if it builds. If not, try to set source and target to the previous jdk in make-flags. If after that it still does not build, we can mark it as needing inspection.
<g_bor>I expect there is only a few of this. (Like it was when Map got an incompatible signature in java8, or when we use the in repo build.xml, and we need to patch the javac tasks there)
<g_bor>Once we resolve all these, we can flip the default jdk, and remove the jdk specifications from the packages.
<EternalZenith>Alright, so, when you have a package that looks for C header files in the wrong path, should you patch it using "substitute*"?
<EternalZenith>I tried doing that, but then the library that those header files were part of themselves started looking in the wrong path
<EternalZenith>In file included from /tmp/guix-build-interception-tools-0.1.1.drv-0/source/uinput.cpp:14:0: /gnu/store/a66ld37hcwj5gv69g1pgwi84wg3ydgdw-libevdev-1.5.9/include/libevdev-1.0/libevdev/libevdev-uinput.h:30:31: fatal error: libevdev/libevdev.h: No such file or directory
<EternalZenith>I must be doing something wrong, since if I tried fixing this error how I tried to fix the other, I'd have to tell libevdev where to find its own header files
<EternalZenith>Using those "substitute*"s I managed to get interception-tools to compile to 66%, where before it was failing around 50% when it couldn't find the location lf libevdev.h and libevdev-uinput.h
<ajjlmau>guix pull: error: You found a bug: the program '/gnu/store/mz6xlwswxcjcb5qmyygqk9qfvna45wks-compute-guix-derivation' failed to compute the derivation for Guix (version: "e7b2937d1907ad1fa11b6237bbda9da303160c41"; system: "x86_64-linux"; host version: "0.15.0"; pull-version: 1). Please report it by email to <firstname.lastname@example.org>.
<ajjlmau>there are some messages about data being corrupted
***happy is now known as Guest97141
<EternalZenith>ajjlmau: I'm probably not qualified to provide help, but I'd try "guix package --roll-back" and then try "guix pull" again?
<ajjlmau>I'm trying to run guix pull. I have installed some packages. I haven't done anything special I think.
<EternalZenith>Pacman needs to do that because it directly changes the system
<AlishbaKabeer>sorry, ajjlmau I cna't help with it. I installed today yes. had some problem with pull too. my advice just don't pull if you just installed
<EternalZenith>But guix doesn't actually change anything until the build and install finishes
<kristofer>I'm trying to investigate this PAM authentication stuff, it is not well documented. I thought by extending pam-root-service-type with (unix-pam-service "name") I would get a pam configuration for the service in /etc/pam.d/name -- any help or guidance on this?
<h4ppy>sorry to kind of hijack, but does anyone else experience problems with running conkeror? I have installed and instantly fell in love, but subsequent pulls "destroyed" it. now, whenever I want to start it, it throws a gtk error and doesnt start
<EternalZenith>I somehow figured it out right after I finally decide to ask
<EternalZenith>I somehow figured out how to do it right after I decided to ask
<ajjlmau>I would love to learn more about guile and guix but there isn't too much documentation about them so it's little hard to approach them. Is there really any other good resources than the manuals?
<apteryx>how can I update my emacs-guix with a custom build using its latest sources? I've cloned it under ~/src/emacs-guix, and trying with the command `guix package -u emacs-guix --with-source=/home/mcournoyer/src/emacs-guix'; is this the right incantation?
<civodul>EternalZenith: there are uses of trivial-build-system in the code that you could look at, but no real doc