<marusich>We use SH_LOG_COMPILER to define the thing that executes our .sh tests.
<marusich>It seems like it just sets up bash to run commands in a test file, e.g. ./tests/guix-build.sh, and fail when any of the commands in the .sh file fail...so, presumably, a LOG_COMPILER is expected to return an exit code to indicate success? And it isn't required to actually create the .trs and .log files (unlike drivers, which apparently *are* expected to do that)?
<marusich>I'm asking here because I thought since we wrote it, we must understand it, but if this is a question best suited for the automake email list, let me know and I'll just email there instead.
<orelozno1>A happy day, I succeeded the (classic) installation of GuixSD on a Laptop hp ProBook 6460b (without worrying about GPT or EFI).
<marusich>My best guess is that the documentation implies that a "log compiler" serves as a way to run a test script when that test script is not itself executable, and in all other respects it should follow the contract for test scripts as defined in "15.2.1 Scripts-based Testsuites".
<marusich>orelozno1, awesome! Another platform assimilated :)
<marusich>snape, yeah...I checked the email list but that's all I found. I don't know if I'm brave enough to dive into the automake source today. All I wanted was just to know the rules by which we run our tests.
<orelozno1>pkill9 : i have X11, the mouse, the keybOard and internet :)
<marusich>snape, since some of our *.sh tests explicitly "exit 77" in order to indicate that they should be skipped, I am 99% sure I'm right.
<marusich>exit code 77 is the one specified by automake in "15.2.1 Scripts-based Testsuites" for skipping tests.
<ng0>imo we should improve the opensmtpd service. right now when something not very obvious has changes (like: 1.5 years without changing and using the config) you just get the default herd message for when services are brøken
<marusich>snape, I checked the automake source, and it seems that this is in fact what happens. In bin/automake.in, in procedure handle_per_suffix_test, it looks like when no log driver is defined for the extension (.sh in this case), the default is used, which seems to be lib/test-driver, which appears to implement the protocol described in "15.2.1 Scripts-based Testsuites".
<OriansJ>umm, wtf? error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
<OriansJ>all of the binaries manually built stopped working after deleting a previous package generation. I am guessing I stumbled into the fact that gcc is probably hard linking to a specific folder for libc and guix is leveraging that to prevent libc conflicts. Which explains why all the old manual builds break upon the removal of the generation that contains the libc being used.
<marusich>OriansJ, sounds like maybe something (in the build logic, when you manually built stuff), dereferenced the symlinks.
<marusich>E.g. if it dereferenced ~/.guix-profile/foo to /gnu/store/.../foo, then later, when you delete an old generation and ask guix to GC the dead paths, /gnu/store/.../foo might have been removed, so the tool you built maually might not continue to work.
<marusich>In theory, the same kind of thing could happen, even if you don't run gc, if that "something" dereferenced ~/.guix-profile/foo to /var/guix/profiles/per-user/$USER/guix-profile-3-link/foo, and then you delete generation 3. But I doubt that would happen; I'd expect a tool to fully canonicalize the path to something in the store.
<marusich>Could be interesting to see how your stuff broke. Do you know more?
<pkill9>is there anyway to skip building manual database when using `guix environment`?
<atw>I am trying to use ghc-edit-distance but it appears to be failing on a version range ("QuickCheck >=2.4 && <2.9") that is not satisfied by our ghc-quickcheck (at version 2.10.1). How can I check on its status in hydra? I suspect that it is also failing there.
<atw>Is it bad manners to highlihgt Ricardo at this hour? I think his update of ghc-quickcheck caused this situation with ghc-edit-distance
<samplet>atw: You probably need "--allow-newer=QuckCheck" as a configure flag.
<atw>samplet: thanks, I will try that. Could that cause problems if the <2.9 constraint was set very carefully and explicitly on the part of edit-distance's author?
<samplet>AIUI, we try to follow LTSHaskell 9 at the moment, but for some reason some of the QuickCheck stuff is ahead. There are a handful of packages with that flag. It seems to work in general, but of course it could cause a problem in some cases.
<samplet>For instance, I just tried adding that flag to “ghc-uuid” to fix a similar error and it did the trick no problem.
<atw>samplet: I am still curious about where the upper limits of these version ranges come from. In edit-distance, for example, was 2.9 the most recent version of QuickCheck available? Does 2.9 then represent the author's anticipation of breaking changes in QuickCheck?
<samplet>atw: I don’t really know. They seem to be pretty pervasive. It doesn’t look like anybody is actually asserting that things are broken, though.
<samplet>I just learned that they sometimes get overridden on Hackage with “metadata updates” – new constraints for the same code.
<samplet>They don’t change the tarball or version number, just replace the Cabal file through a special interface.
<atw>Looks like I have the beginnings of an Agda package!
<pkill9>anyone have any idea where i can find libgnome-menu?
<marusich>pkill9, regarding your question about the manual database, I don't know of an easy way to disable the hook from the command line. However, in scheme code, you can simply pass a different list of hooks to the profile-derivation procedure.
<marusich>In addition, although each different profile might require slightly different derivations to build some of the profile hooks, I think that because it's done using derivations, they will also overlap a bit, so if you're building a lot of profiles with similar inputs, it might be faster?
<ng0>to provide more context, the dovecot service in the default configuration currently doesn't work anymore. I think it should be enough to add the value with a default.. I can try this but I'd rather spent time learning today.
<ng0>we also would nedd to generate the DH on activation so that the file exists if nocustom location is given
<ng0>I have a need for this, I think I'll give it a try
<ng0>question: is the dovecot-configuration like cups generated? or was it added and edited by hand?
<nckx>ng0: manual, I think. I hope, since I've mangled it by hand at least once. And its pretty docs, too.
<nckx>I hate answering questions with ‘I think’, but I guess no-one's here who knows for sure...
<ng0>would it be too much togenerate a DH key on frist activation? I have my keys, but is this too much delay for an activation?
<lmao_>I tried to create new xsession but the directory is write protected
<lmao_>Am I supposed to create it using the configuration file?
<nckx>ng0: It's only needed for older cypher suites (as implied above: I don't even have or need it), so I vote no. But you're the one writing code. Supporting (ssl-dh #f) would be nice if nothing else.
<ng0>string would #f be similar to an empty string in dovecot configs?
<pkill9>I don't think `guix import json` works when the json specifies an input that's in a module that's placed in $GUIX_PACKAGE_PATH, Guix fails with an error saying 'no code for module'. Is this known and can anyone reproduce it?
<lfam>nckx, ng0: I think that wingo knows for sure because he made the service originally
<nckx>ng0: It would simply not add a ssl_dh line at all (like in my .conf) and not bother generating the parameters, which aren't always useful.
<ng0>well right now this leads to my Dovecot not accepting connections
<nckx>lfam: I agree with the spirit of your ‘meaningless’ quip, but it's a bit broad. ‘Misunderstood’, ‘easily forged’: sure.
<nckx>efraim: Is that in reference to htop? Does it work there?
<pkill9>rekado: I can't really provide any because I'm kinda just doing it trial and error without understanding fully, maybe someday someone more experienced than me can help
<lfam>I wasn't careful with that statement. They don't provide a linear timeline, and so they can't really be used in the way a person would want to use them. But, the remote reflog is more useful in most cases
<lfam>They don't even get updated when you do `git commit --amend`, which I do constantly. It's really just a timestamp of the local time when I first started working on a patch, which I don't think anyone else really cares about.
<nckx>There are also multiple dates associated with a commit IIRC, which I never researched since I never needed to.
<mange>There is an example UEFI config.scm in the manual at "(guix) Using the Configuration System". It has a partition for /boot/efi instead of /boot, as wigust is suggesting.
<jayspeer>wigust: Thank you. It doesn't seem to be a problem with config.scm. I am unable to install grub outside of installation procedure. Grub seems to be missing some important tools to finish installation.
<wigust>jayspeer: What is they exact command you invoked to install Grub manually?
<davidl>i.e. only once after init. Not every reconfigure.
<mange>I don't understand what you just said about the relative path. Can you explain why this is a sensible for this to work?
<mange>I didn't do an EFI installation, because I frankensteined my debian installation into a GuixSD one, but that seems pretty strange to me.
<jayspeer>I don't agree with davidl. We should only specify mount point for efi partition single time
<davidl>jayspeer: what if you have your efi boot partition on a separate usb drive or a remote folder? would that work if target path is relative to /mnt such that /boot/efi is /mnt/boot/efi?
<davidl>i might be wrong. I was just trying to come up with an explanation for it yesterday.
<mange>It just seems really strange to me that saying "/boot/efi", which is an absolute filename, is re-interpreted relative to /mnt. I would have expected that if I specify "/boot/efi" in my config.scm then it will write to "/boot/efi", not "/mnt/boot/efi".
<jayspeer>still you should only provide the latter path - which should be the same in both cases. We operate on partitions, not some relations between paths. IMO guide should instruct us to mount partition at /boot/efi and not another location. If I recall gentoo install handbook they instruct you to do exactly that
<mange>If I have my boot partition on a USB or a remote folder then I can put in a different path, or I can mount the USB/remote folder in a different place.
<jayspeer>mange: In both cases boot partition is not part of the operating system - it mount point doesn't have anything to do with how system works. After booting you should be able to, without any remorse, umount /boot partition and system should remain as it was. Grub assumes that this exactly what we are doing during installation
<jayspeer>I think the manual doesn't say anything incorrectly, it is just not noob friendly
<davidl>mange: I guess you can always create a folder in /mnt/mydir and mount the efi-partition there with /mydir as the efi target. This new bootloader configuration syntax was recently changed and maybe there's a note about it in the Guix source code.
<davidl>jayspeer: definitely agree about it not being noob-friendly.
<jayspeer>Well, to sum it up. /boot exists to mount boot partition, end of story ;)
<Sleep_Walker>I finally compiled Guix package for openSUSE (yeah, it really took me that long) - but I got this error message for many commands, this one is generated by `guix package -i icecat' - https://ptpb.pw/k75S