<str1ngs>I wish guile had some magic bit to detect at end of prompt!
<bt`>The closest I was able to get to a functioning Xorg on my Librebooted X60s was with acpi=off. What would happen is that my system would try to load slim hang with multi-color static over the screen or black screen and reboot but this time succeeding. I can't seem to get any further than this. The two messages that seem relevant in the logs are a ACPI warning about a SystemIO range overlapping with a Opregion and intelfb failing to
<bt`>reserve the FB region. https://arborescent.tk/messages.txthttps://arborescent.tk/config.scm As I mentioned this is probably the last thing I'll need assistance with, because I've already migrated my data and reinstalled my user applications and when I was able to login they seemed to function correctly. As always thanks for your time, and unlike other times I feel like I've tried everything I know to so I won't be rebooting to test
<bt`>okay that's it, the `:b' was me failing with evil mode, which happens sometimes.
<bt`>If that doesn't seem right or if you've not got any other ideas I setup a config without X to boot into after I try with the crash one to make sure the log isn't overwritten, what I've been doing is just setting modeset to zero in grub to boot.
<reepca>bt`: IIRC leaving the drivers field of xorg-configuration blank will cause xorg to automatically pick one. What happens if you change your config to not specify drivers?
<bt`>I get the same fault, also if I manually set it to vesa, I can get logs for these as well if they'd be helpful I remember there being a little more going on in the Xorg.log when the driver is unset.
<bt`>When I was booting with nomodeset the error with Xorg was that it couldn't find the fbcon module if that's helpful (I suspect it's no though)
<reepca>M4R10zM0113R: guix edit, somewhat contrary to the name, is mostly useful for locating and reading package definitions, not really for editing, because the package modules installed by, for example, 'guix pull' will all be in the immutable store.
<reepca>bt`: I'm no expert regarding kernel and xorg sort of things, what I personally would try is reconfiguring with a bog-standard config.scm, like the example desktop one, to see if it works / how it fails (assuming you haven't already).
<reepca>It might also be a good idea to check in other channels that are more specialized in these sorts of issues. For example, #xorg might be able to give you more feedback on the log file.
<bt`>The closest I got to that was the installer, which I also had to add nomodeset for to load (which is odd because it just looks like a curses application) I'll strip down my config (including the fs stuff) and see how it goes I might wait until the morning though. Thanks for your help, again.
<bt`>For sure, I'll check out #xorg, and #libreboot if stripping things down doesn't work.
<reepca>M4R10zM0113R: sort of depends on what you mean by "overriding". For example, if you want to override "gcc" in the entire package dependency graph, you'd want to use channels to specify a customized guix repository. If you just want installing gcc to install a tweaked version, you could put a module containing that tweaked version in GUIX_PACKAGE_PATH.
<reepca>see section 6.1 of the manual ("Package Modules") for more info
<M4R10zM0113R>Would it be monumental to do, say, make everything try not to use pulseaudio? would that be applicable on config.scm?
<M4R10zM0113R>Or would I have to make every single package in the entire dependency graph?
<reepca>'guix graph --type=reverse-bag pulseaudio | dot -Tpdf > pulseaudio-dependents.pdf' will give you everything that depends on pulseaudio in graph form. That should give you an idea of how much would need to be changed. Note, though, that it could be changed programmatically (see section 7.1.2 "Package Transformation Options" for an idea of what's possible).
<PotentialEnergy>is anyone aware of an existing map of guix package names to debian / ubuntu package names or vice-versa?
<reepca>section 14.4.2 of the manual, "Package Naming", gives guidelines for naming. Presumably debian and ubuntu have their own guidelines. I know it's possible to go from the upstream name to the guix name, but I don't think the inverse is true (guix lowercases the name). I'm not aware of any concrete mapping already made, though.
<PotentialEnergy>Yeah, from what I can tell guidelines won't do it, there's just enough inconsistency to still necessitate a curated map
<PotentialEnergy>e.g. `apr` in guix is `libapr1-dev` in ubuntu, but used to be `libapr` in guix a few years back
<PotentialEnergy>it's ok, I just thought I'd see if anyone who was around knew of something like that. thanks, reepca
<brendyyn>PotentialEnergy: i think it would be a good project to write a program that analysed guix and debian repositories to generate such a map
<roptat>you probably have something like (define-public ... (package ...)), you could add a line with the name of the package at the end of that file, so the file evaluates to the package, or you could remove the (define-public ...) wrapping around (package ...)
<roptat>manzerbredes, try to add "notmuch" at the end of that file (without quotes)
<reepca>sorry, forgot the package part. Should be 'guix package -L . --install <package-name>'
<roptat>define-public linked the package value to the variable 'notmuch', so to return that value you can simply return the variable
<civodul>reepca: not sure! i started integrated your patches for (guix store files) etc., and then stopped, because i realized that if we expose 'make-derivation' then we make it possible to create invalid <derivation> records
<puoxond>I was wondering why I had to build linux-libre even though it was updated 3 days ago. So I checked the build farm and it turns out the build failed (the log suggests the build machine ran out of space).
<puoxond>What's up with Cuirass failing to build substitutes for guix pull (guix-modular-master) on armhf-linux and aarch64-linux since around commit c2974d1 (12 days ago). It looks like they all say "Dependency failed".
<manzerbredes>In package definition, how can I tell gnu-build-system to use only the make phase ?
<roptat>manzerbredes, you can use (arguments `(#:phases (modify-phases %standard-phases (remove 'configure))) to remove the configure phase for instance
<kdtsh>thanks. I've been attempting a 'guix pull && guix system reconfigure /etc/config.scm' after having installed guix 1.0.0 to a VM and making a change to config.scm to include %base-packages in the packages list (after having used the graphical installer to install guix 1.0.0). I've been getting stuck at the stage when linux-libre-5.1.1 builds but nev
<kdtsh>er seems to complete. The spinning cursor turns over periodically so I'm not sure the process has stalled, but I've tried leaving it for a day and it hasn't been able to finish
<kdtsh>Is it normal that it should take this long? I've tried to find a way of turning on some extra logging for 'guix system reconfigure' but can't find a verbose or trace option. It never seems to fail either so it may just be taking a long time. My VM is running in qemu and I've apportioned it 2048M of memory
<manzerbredes>roptat: thx, but there is several phases that I don't need and I was wondering if it is not possible instead of deleting phases, to just specify the one I want to use
<roptat>manzerbredes, I don't know of any way, because you'll want more than that phase: decompressing, probably patching shebangs...
<roptat>maybe you want to use the trivial-build-system instead and define your own build procedure?
<rekado_>the x86_64 build also was a cached failure.
<rekado_>I cleared the failure and restarted the build.
<rekado_>kdtsh: what kind of things would you like to see logged?
<rekado_>kdtsh: all Guix commands used to be very noisy and we tried to make them less noisy by default.
<rekado_>you can get at all the noise with some verbosity options, though
<kdtsh>rekado_ I suppose in reality I'd be happy with some kind of noise as a sanity check. I can see how build logging would be fairly pointless - but if I can see that *something's* happening it'd be useful. Knowing that this is just part of the fact that the kernel takes a while to build is helpful though
<rekado_>FWIW linux-libre for x86_64 is now built. After requesting a binary it may take 5 minutes for the substitute to be “baked”.
<brendyyn>why does it take so long for it to do that
<g_bor[m]>I have an idea, but first I would like to check if you think it would. Can we use the grafting code to modify hardcoded self-references in our outputs? I believe yes, but I am not very familiar with it.
<g_bor[m]>I was thinking about making content addressable store a thing :)
<roptat>g_bor[m], it must be possible, but grafting creates a new derivation
<efraim>IIRC the grafting code looks for exactly /gnu/store/32-characters
<g_bor[m]>roptat: maybe we can... I belive this is just a composition of a build and this reference rewriting. The result is essentially a fixed output derivation. How would this look using a fixed otuput derivation?
<roptat>but in that scenario, the input is the same because it's a fixed-output derivation
<roptat>but it doesn't work because the old build is cached, so we need something slightly different
<g_bor[m]>Ok, so let me restate my points: if we are in the situation, that when we build a package, and then another variant of the package, and the relocation of the variant to the prefix of the original results in the same output, then we can content address the original package.
<roptat>I think the issue here, is how do we build dependents
<roptat>if their input is the non-content-addressed package, we didn't win anything
<roptat>but, unless we build the dependency, we have no way to know what the content-hash will be, so we cannot build a derivation for dependents...
<g_bor[m]>roptat: I would say to include the content-address in the package, so that we can still use way we do it right now. If a package does not provide a content address, we simply fall back to the current behavior. If it does, then we try to use that. It needs some logic, but I feel it might worth it. Wdyt?
<roptat>maybe nix people have already thought about that problem?
<g_bor[m]>roptat: maybe. One thing I was thinking about, if this is a trust problem, or more of just a workflow problem. If we say that the user using a channel trusts the channel, then this is not a security problem, so we don't need to worry about someone maliciously injecting values there. Then maybe we just need to come up with a good workflow and tooling, that makes sure that it gets updated.
<roptat>oh, and maybe that case: A is modified and has a new behavior. B depends on A, but its output has the same content as before. C depends on B, and B actually calls A's binaries using $PATH, resulting in a different content in C's output
<roptat>(using $PATH is the reason why there was no change in B)
<roptat>can we make sure that C is rebuilt if it doesn't directly depend on A?
<roptat>wait, that's stupid, because in that case A is not in the build environment of C... so no issue here
<sirmacik>It's cold and raining outside, seems like a perfect day to roll-out guix on my work machine (;
<mbakke>rekado: Actually, pbcore uses Sphinx for tests and fails with the Python 3 variant.
<mbakke>However the latest versions appear to have Python 3 support.. Could you try updating it?
<mbakke>I notice some of the python2 transformation packages are also failing... So I'll try to reinstate python2-sphinx for now.
<g_bor[m]>roptat: I believe that the issue is that a variant is pushed, it fails to build on the output check, and the dependent resolves to the old version.
<devilishtype>I just installed guixSD for the first time, I used the guided install and selected AwesomeWM. Everytime I go to restart awesomeWM while I mess with my config it knocks me back into GDM login screen.
<roptat>devilishtype, there's a known bug about that... I think the manual has a fix for it
<ruffni>because it will be overridden at reboot/reconfigure?
<rekado_>ruffni: the store should never be modified.
<rekado_>ruffni: Guix assumes that only the daemon changes the store.
<rekado_>by modifying things in the store you violate that assumption and things can go wrong.
<ruffni>makes sense :) so how do i change stuff in there? via config.scm definition?
<rekado_>ruffni: what is it you’re trying to change?
<rekado_>(not even the guix-daemon changes things in /gnu/store; it usually just adds new things or collects garbage)
<ruffni>i'm trying to figure out how all of this works. but for now, i'd like to start nethack in wizard mode from my user. my user has group "wizard" (already figured out that much). so i'd like to change the "WIZARDS" value to * or to include my username
<str1ngs>also do inputs automatically get added to runpath?
<str1ngs>and is it possible to manually add something to runpath?
<str1ngs>in regards to elf dynamic section runpath I mean
<efraim>mbakke: I haven't looked at it yet, I've been really busy
<efraim>With 5.11 the qt update got its own branch with 400(?) dependent packages
<mbakke>efraim: Right, no worries. I might try it out in a couple of days.
<boogerlad>" Note that there is no xorg-service procedure. Instead, the X server is started by the login manager, " What if I don't want to use a login manager? Unnecessary bloat for a single user machine
***marlon__ is now known as Marlin1113
<str1ngs>boogerlad easiest way would be to use %base-services instead of %desktop-services. alternatively you can modify %desktop-services, though I don't know how you would remove gdm that way
<str1ngs>if you use %base-services you'll have to specify what packages you install. like X11 etc
<PotentialUser-52>I couldn't get guix to boot. I successfully copied it to the usb disk. My laptop is librebooted. I get a menu whenever it starts up about booting a usb but when I try to I just get a lag and then nothing happens.
<sirgazil>nckx: Thanks :) And what would be a "certified system". This machine is from Dell and it came with Ubuntu 16.04 preinstalled. I bought it because most Dell machines I've used tend to work with libre distros too...
<g_bor[m]>I would like to extend the nignx-php-location procedure a bit. I would like to expose the uri, with the default it has right now, and add support for passing to tcp, as it now only works for unix sockets. Wdyt?
<nckx>I just got an ‘In execvp of bash: Operation not permitted’ error while toying with the installer; sounds familiar; this has been reported, right?
<lfam>Yes, there should be a per-domain file under /etc/letsencrypt/renewal
<lfam>I just pushed a commit that updates certbot to the latest
<rekado_>they all have different settings; for some it’s standalone via the v02 API, for the guixwl.org domains it’s standalone via the v01 API (which is not surprising, because that’s what I told it to use just now)
<lfam>Well, we just got ourselves 90 days to figure it out :)