<pushcx>I think by histility they are referring to stuff like "Please do NOT promote this repository on any official Guix communication channels, such as their mailing lists or IRC channel, even in response to support requests" on the repo that shall not be named.
<mbkamble>yes. I understand that -- guix documentation mentions that third-party channels can be outdated due to guix API changes. Raising the question here did help me learn about finding package versioning. Thanks. I will notify the third party channel maintainer about this issue.
<nckx>TBC it's not an API change, if that's what you mean.
<nckx>I can't easily pull the latest guix here to check (unrelated build failure) but I'd be surprised if the info page had vanished.
<nckx>pushcx: What a vicious attack on that poor commenter.
<nckx>Wait until they learn of this thing called Arch.
<pushcx>I didn't think Arch was bothered by people asking for help with device drivers.
<silicius[m]>I... I added a print statement to the test and it now magically works 50% of the time
<monadam>i'm having issues logging into my user account, I think because of a "guix install xmonad". I can log into root just fine, so the system config is probably fine. The problem is when I "su - user" or "sudo -u user bash" i get permission errors such as "cannot load ~/.bashrc." this prevents me from doing "guix remove xmonad"
<monadam>is this even possible or is it probably a system config issue? thx
<lszl>Hello, I am trying install guix on a foreign distro (Debian) and when starting the installation script I get the following error:
<lszl>[1656657919.315]: Starting installation (Fri Jul 1 08:45:19 AM CEST 2022)
<jpoiret>there's no support for base-commit though afaik
<jpoiret>and MIME-attached patches get mangled because b4 doesn't really handle them properly
<jpoiret>but theoretically (ie for patch series that are sent inline), i just (in Emacs) search it up with piem-lei-q, and then do C-z i a (that's my own key), which asks me for the base, and the name of the new branch
<jpoiret>but it's definitely time to work on `guix review` and `guix contribute`
<jpoiret>i was planning to do that but i saw that mumi wasn't up to date on berlin and was missing the latest commits pertaining to graphql iirc
<rekado>i don’t think there have been graphql changes, but the message-id indexing isn’t deployed on berlin
<jpoiret>finalizers from what i understand can run in two different ways: either via the finalization thread (but it's dead since we forked), or through guile asyncs, but since we do not go back to Guile they won't run
<maximed>K, though if we do that, I recommend a source code comment explaining why it's safe.
<maximed>For signals: I was thinking that a C program might register a signal handler that when run, tries to access a fd (that move->fdes has replaced with something else).
<maximed>(and someone else might send that signal -> oops)
<maximed>(OTOH, we could maybe remove the signal handlers first)
<maximed>(OTOOH, from what I've heard, libraries aren't supposed to register signal handlers unless requested by the app)
<jpoiret>it's too bad Guile doesn't complain about the unknown hash object first
<maximed>So I'd expect you are getting a warning about unbound variable: gexp, or such (not sure though, error messaging not always great)
<maximed>jpoiret: OTOH, the library could do things like 'register a signal handler from within the signal handler', so then you might need to disable signal handlers in a loop or something until none are left though that might become too implausible ...
<PotentialUser-30>maximed : yes know I got a more classical error probably because of my bad use of `install-file`. Thanks you unlocked me my next phase of debug
<GNUtoo>hi, I'm not sure how to debug that: I've replaced the build function of a package with my own code that accepts make-flags as arguments, and I'd like to print make-flags to know what inside, and it gives me that error:
<nckx>Since you don't seem to be filtering or modifying them (?), you could just capture all arguments to your phase (as a single 'args' argument) and (apply (assoc-ref %standard-phases 'install) args).
<maximed>If you are reinstalling anyway, you might want to use the latest automated graphical installer instead for the automatedness.
<sughosha>Hi guix, I am adding new variables to Guix, but I want to know if there is any such rule that I should place it in alphabatic order (or something else like that). I am confused because in some `.scm` (for example, `music.scm`) files there is no order I am able to find.
<nckx>Boot loader installation & (re)starting services at the very end is the only thing that 'uses' the root privileges you give it, p4r4D0xum. You can 'guix system build' an entire system without them.
<nckx>I also do not recommend the 'in place conversion'. Yes, it 'works', but it is messy and the left-overs can always cause bugs now or much later.
<GNUtoo>With that I can run some graphical applications from Parabola but not everything (some applications depends on daemons being launched)
<GNUtoo>I've not yet managed to make a script that launch applications from Parabola, so I need to (1) chroot and (2) launch them in the shell
<nckx>GNUtoo: It does no such things (loop files).
<GNUtoo>oh ok, too bad. booting on loop files would be very convenient
<nckx>Otherwise the installer would use squashfs by now, not the wonderful but quirky zisofs.
<GNUtoo>GRUB also supports getting stuff form loop files, so we'd need to add support in bootloaders configuration and the initramfs, but if it's done one day that would be easy to integrate in existing distributions boot systems
<GNUtoo>Though there might be limitations with loop files, wubi didn't catch up because of that
<GNUtoo>I think the limitations were related to suspend/resume or suspend-to disk, I don't remember well
<GNUtoo>And there were limitations related to NTFS as well: Linux could write to NTFS files but cound't change the file size, so that worked well for loops, but it also meant that you cound't increase the file size from GNU/Linux that easily
<GNUtoo>(it relied on the ntfs kernel driver for that)
<GNUtoo>+ using NTFS in general is risky since last time I checked we didn't have free software fsck software that is so experimental that it's not shipped by distributions
<nckx>Actually that sounds like the one use case where the kernel driver shined :-p
<GNUtoo>oh ok, so I guess we should stick with ntfs-3g for the utilities
<efraim>curl-7.84.0 is failing on powerpc-linux and riscv64-linux, both at the same spot
*GNUtoo is very interested in that kind of interoperability to enable people to switch to GNU/Linux more easily, though I don't have use of it myself
<rekado>civodul: turning the error into a warning (as it used to be IIUC) would solve the problem, yes.
<nckx>Oh I agree, I'm talking solely about a very Windows-specific kinda-VM that stays trapped inside Windows and doesn't encourage escaping it. Interop is... fine.
*GNUtoo participates a lot in install parties to help people progress on the freedom ladder
<GNUtoo>Sometimes people that want to install GNU/Linux also want to keep a dual boot just in case, or not to have to reformat, but the issue is that ntfs is risky (we don't have good free software fsck)
<sughosha>rekado: fabla and luppp I didn't check the releases, but the releases are very old. The recent commits works fine. But with distrho-ports, there is no specific release version, since they port different plugins with outside sources but make successful builds with JUCE.
<rekado>the code includes generated C++ code; the previous version of the package would rebuild this from Faust sources.
<rekado>I’ll try to make that happen in the new version as well.
<sughosha>rekado: I don't remember why I removed the `faust` (maybe that failed to build when I tried). I made this change quite long ago but I didn't know much about sending patches in proper way. Without invoking `faust` the packages builds fine and also the program runs.
<rekado>yes, without invoking faust it uses the generated main.cpp file.
<johnjaye>also i have no idea what you mean by the latest image. i thought the 1.3 one was the only one.
<johnjaye>aha. i see it. it was hiding in a menu at the top of the page
<sughosha>rekado: I also am not sure whether the same licenses of the original plugins apply to their ports with changes in distrho-ports package. So I just followed the licenses in `doc` folder ignoring the licenses of their original (different) packages.
<rekado>sughosha: we also distinguish between GPLv3+ (i.e. “or later”) and GPLv3 (only)
<rekado>yewscion: consider using package transformations
<johnjaye>jpoiret: i'll try the latest iso image. hopefully it succeeds. i'm installing from scratch, there is no config.scm to speak of
<johnjaye>unless you mean when i start the installer i manually load a config.scm with the packages i want? as opposed to doing it post-install?
<sughosha>rekado: the `+` only applies if it is specifically mentioned in README.txt, right?
<yewscion>abcdw: Thanks for the link! I will try this inside my config file; Was unaware of the `package-without-tests` procedure.
<jpoiret>johnjaye: there is the graphical installer (likely what you're using) and a manual method
<yewscion>rekado: I wanted to, but it seemed as though the transformation options weren't available for `guix home` (I tried `--without-tests=package`). Is that what You meant, or are there other transformation vectors I'm missing?
<johnjaye>i didn't pick the manual method. is that just you have a command prompt and type into it?
<vivien>I tried with texlive-bin and texlive-tex-texinfo (I get the same feeling as org-org-export-to-org writing that down) and still get the not-so-helpful "TeX neither supports -recorder nor outputs \openout lines in its log file" error message
<rekado>the error message is indeed not helpful. Never seen it before, though.
<rekado>maybe you can keep the failed build output and look around for more information?
<vivien>I’ll try the packages used in your examples first
<nckx>p4r4D0xum: ...present only on Guix System *by default*, that is; you can still 'guix install shepherd' and use herd to manage 'user services'. But if the manual tells you to run it, you might be in a Guix-System-only section, yes.
<rekado>vivien: phew! I was going to explicitly suggest it, but I thought that maybe you’ll find other clues in the examples I posted.
<yewscion>I've still been unsuccessful working around this, so I'll broach the problem I am trying to work around instead: curl is not currently able to build on my amd64 system, failing when it gets to the 'check' phase (which I've tried to skip, but I've not been able to get it to do that).
<nckx>Can you not use a substitute, even if just this once?
<yewscion>I usually do, but it isn't pulling one. Let me check the weather
<nckx>You can build curl without tests but it won't have an effect on dependent packages. Untested packages don't share the hash.
<nckx>I'm guessing you're interested in wine and not curl, or you share this problem with someone on the ML.
<yewscion>Oh, I haven't seen that mail yet. I'll try removing wine from the profile, as I rarely use it anyway.
<yewscion>Aside: lilyp: So if I was to take my list of packages and feed the entire thing into the procedure created by `options->transformation`, would that apply the transformation to the entire profile for the specified package?
<lilyp>certificates are time bombs when it comes to tests :)
<yewscion>Can confirm that removing wine from my guix home declaration allowed me to successfully use a transform on curl to skip tests, as my reconfigure just completed successfully. (Thanks nckx, lilyp, everyone for Your help!)
<lilyp>uhm, wouldn't you also be able to transform wine to a working state?
<yewscion>lilyp: I discovered that's possible from what You clarified earlier, but I don't need wine to do the work I need to get done today, so I had removed it before I learned You could (and don't have time to rebuild it right now).
<johnjaye>i didn't want my email full of 1000s of guix messages every second
<podiki[m]>lilyp: well the library it complains can't be found when checking what was built is just not in one of those directories of runpath; but you're saying if dependencies of that library are missing it would also have same error?
<nckx>*Most people* reply-all which means you don't need to be subscribed. I consider that the correct method, but this is another holy war.
<lilyp>johnjaye: nah, you're probably just stuck in the mod queue
<johnjaye>i mean somebody already replied to it though. i can see the message on the actual webp age
<nckx>Hence 'please CC me I'm not subscribed' pleas.
<johnjaye>so shouldn't i see that in my email? or no?
<emacsomancer[m]><yewscion> "Can confirm that removing wine..." <- (Do you have a snippet showing how you did this? I've been trying a few things, but the ones which compile yield `transformation 'without-tests' had no effect on....` everywhere.)
<lilyp>emacsomancer[m]: note that it only affects the packages you explicitly apply it on. If you use this in your system config for example, there are many packages hidden from plain sight unaccounted for.
<lilyp>we should probably make it easier to apply transformations to operating-system and whatever guix home uses
<emacsomancer[m]>lilyp: I tried mapping it over the entire list of packages in my Guix Home configuration, but it reports `transformation 'without-tests' had no effect on....` for all of them, as far as I can tell; at least, it definitely reports it for the `curl` package itself, so I imagine I'm doing something wrong.
<podiki[m]>ugh...how to match $ ...how many backslashes....
<yewscion>emacsomancer: Also worth mentioning I had to append the output of that function to the output of my original package declarations. I originally was using (map (compose list specification->package+output) my-spec-list) to turn my list of strings specifying packages `(list "openjdk:jdk")` into the packages for my declaration. But when using the `options->transform` procedure it already renders packages, not strings, so I ended up doing
<yewscion>(append my-transformed-packages (map (compose list specification->package+output) my-spec-list)) after (define my-transformed-packages (map my-transformation my-packages-to-transform)).
<podiki[m]>lilyp: so I changed the cmake option CMAKE_INSTALL_RPATH which was set to $ORIGIN to be #$output/lib, seems reasonable right?
<podiki[m]>(and it works now, both the build and the package)
<yewscion>emacsomancer: I also specified the package itself beforehand, not a string. So, for `my-packages-to-transform` above, I used the curl symbol, not "curl". If I was to apply it to my whole profile, the output of my original declaration should probably be fed in instead, so it would be
<yewscion>(packages (map my-transformation (map (compose list specification->package+output) my-spec-list))) I believe