<nckx>I thought guix show would show only the 'selected' package, I was wrong. <nckx>I thought guix show would show only the 'selected' package, I was wrong. <nckx>I thought guix show would show only the 'selected' package, I was wrong. <nckx>Day boundaries: my IRC client's nemesis, apparently. <nckx>mbkamble: No problem, but third-party channels have complete freedom in how they define and install packages. People here will assume and investigate only the 'Guix unless told otherwise. <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 <nckx>pushcx: I don't think they are, if packaged in Arch. <silicius[m]>good thing python supports semicolons because fuck me if I had to replicate idents for each statement <nckx>(...) capturing can help with that but agreed that it's more fun to avoid when possible. <silicius[m]>More prints didn't work. And each time this test passes a test further down the line loses connection to x <silicius[m]>no, I was wrong. IT IS this test that loses connection to X <nckx>...that could have been much worse. Night all. <mlan>Sorry, yesterday my place was at night. ***the_tubular93 is now known as the_tubular
<horizoninnovatio>A query: Installed the xfce4-whiskermenu-plugin but it's missing from the panel perferences. Any clues? <florhizome[m]>I Had to Install it in the same Profile with the Panel (system) <blake2b>reading that lobster.rs thread and I can't help but feel like such laments wind up making us seem cool <horizoninnovatio>florhizome[m]: So if I (re)install whisker & panel together it should be good? or how do find out which profile? <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) <lszl>[1656657919.323]: [ FAIL ] Missing commands: xz. <lszl>Could anyone help to find a way to resolve it? Thank you\ <sneek>Welcome back PurpleSym, you have 1 message! <PurpleSym>podiki: I’m on a foreign distribution and that config setting is enabled. <lszl>PurpleSym thank you, the installation script works now <unmatched-paren>people saying "guix is hostile"?! this is why lobste.rs gets a special place in my /etc/hosts <rekado>is there an automated way to apply a patch while respecting its base-commit? <rekado>it seems like a lot of work to “git checkout -b <issue-id> <base-commit>”, then apply the patch, then rebase, then checkout the master branch, then merge, then delete the branch <rekado>especially when working on a lot of patches, this workflow is pretty tedious <cbaines>I usually cherry pick from those branches <cbaines>but you could also just check it out, rebase, then merge in to master <cbaines>there was a conversation about making the branch names the debbugs id, rather than the patchwork series id <cbaines>which I am planning to do, I just haven't got around to it yet <rekado>is there a *local* workflow to apply while respecting the base-commit? <rekado>I see that “git am” has a three-way-merge option that I’ve never used. <jpoiret>rekado: the base-commit is just an indication <rekado>yes, but I’d like to make use of it to simplify my workflow <jpoiret>iiuc, you should checkout a new branch at that commit, apply, then merge origin/master and resolve conflicts <rekado>yes, that’s what I’m doing already, and I think that’s rather tedious <jpoiret>using piem, most of that is automated <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 <rekado>I guess I should just reconfigure it. <jpoiret>also, the graphql types aren't appropriate IMO, issue shouldn't be non-nullable. That combined with kolam not handling errors leads to empty responses for queries with non-existent issues <jpoiret>should mumi and kolam patches be sent to guix-patches? <cbaines>jpoiret, guix-devel is probably better <jpoiret>(not handling errors according to graphql spec) <cbaines>that way, it can be assumed that patches in guix-patches are meant for guix <jpoiret>I could work on mumi/kolam today maybe <jpoiret>also, the local dev setup for mumi isn't really spelled out in the README but it's pretty easy to figure out looking at the scripts <jpoiret>cbaines: arun's graphql guile library <jpoiret>unfortunately any error stops the graphql evaluation <rekado>jpoiret: patches for mumi are most welcome! <rekado>I don’t really have enough time to hack on it, but I’ll make an effort to review contributions to mumi. <jpoiret>i think what needs the most work would be kolam ***attila_lendvai_ is now known as attila_lendvai
<jpoiret>we'd need to make the server follow the spec more closely, and add a client library so that the potential `guix contribute` and `guix review` could use them to query the status of bugs <jpoiret>then it's not MIT and certainly not free software according to the FSF <jpoiret>IANAL but they've made it clear that anything restricting the basic freedoms make licenses non-free <jpoiret>well, I think some recent discussions on the MLs really outlined the "we follow the FSF's definition, period" pov that guix takes <jpoiret>it's a matter of drawing the line somewhere, and the FSF's has the advantage of being quite clear <rekado>jpoiret: for patches to kolam you should coordinate with Arun. <rekado>jpoiret: is graphql essential for “guix review” / “guix contribute”? (I thought of it as a fun extra API.) <jpoiret>since upstream won't merge those fixes any time soon, and having a more general interface to rewire fds would be better <jpoiret>attila_lendvai: not sure they'll change their mind :p <maximed>attila_lendvai: According to some interpretations of 'state organisation', that would forbid its use by public schools and libraries and good state organisations in general. <jpoiret>rekado: we'd need it to be able to translate bug-id to msgid and back <cbaines>jpoiret, unfortunately I'm not that well informed on all this starting processes stuff, but I would like to fix the #:error-port behaviour sooner rather than later <cbaines>maybe I can test and send a v2 patch for that today <jpoiret>i'll review your patch in the meantime <maximed>jpoiret: Do you know about move->fdes? <attila_lendvai>jpoiret, well, i've presented the situation. that sentence will block updating trezor support in Guix... the ball is on his side, and i'll proceed based on his response <jpoiret>the thing is, i'm always worried that there are some fds that aren't managed by ports <jpoiret>since on my machine, just starting Guile opens a lot of fds <maximed>This seems to be after-fork though, so does it matter? <jpoiret>i'd rather handle everything from the C-side <maximed>(Though I think I've a bug report about Guile's finalisation port not being tracked?) <jpoiret>since after fork, Guile can still do a bunch of things on its own <jpoiret>it's ok to close the finalization port after fork though <jpoiret>since the finalization thread doesn't exist there <attila_lendvai>hrm... that modified MIT package is only needed for running the tests. maybe i should just disable them with a comment? <maximed>jpoiret: Which discussion were you referring to? <rekado>attila_lendvai: delete them in a snippet <maximed>Does someone know any downsides of more RAM? (besides money) <jpoiret>cbaines: unfortunately i don't think your patch would fly, it has the same problems as Guile's handling of fds when using system* and friends <jpoiret>if your (current-error-port) is a port tied to fd 2, you'll have closed its fd preemptively! <cbaines>jpoiret, that's not what I'm trying to fix <maximed>TBC: I guess I'd consider that license free (meeting the free software criteria), but at the same time I was thinking there are other important aspects too, not strictly free-ness related. <jpoiret>i'm just saying this is the same issue that the Guile code has <jpoiret>also, i don't think we should rely on ports accounting for all the fds <jpoiret>we link to C libraries (libgit2) that might open fds <maximed>jpoiret: What I meant is that, sure, a C library might open fds, but why would these fds be used between fork and exec? <maximed>(Though there might be problems with system-async-mark, fd finalizers, and maybe signals ...) <jpoiret>finalizers should be ok since we're in C code <jpoiret>but yeah, signals, or we might keep some fds open in a forked process that might block something else <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) <maximed>plain-file lives on the non-build side <maximed>Write #:phases as a G-exp, not a G-exp, such that you can do #$: <maximed>(arguments (list #:phases #~(modify-phases %standard-phases [etc]))) <maximed>And put a #$ in front of the (plain-file ...). <maximed>While there are still some uses of #t at the end of a phase in guix, it hasn't been needed anymore for a long time. <maximed>I suppose you could name packages as "--brlaser", but it might be confused with a CLI option when doing things like "guix shell --brlaser". <maximed>So I'd suggest a more conventional name like "brlaser-hl2370dn" <maximed>How much RAM do people need maximally for compiling things? <maximed>Though I was wondering if 16GiB->32GiB would be worth it. <unmatched-paren>Well, I could compile Rust and Icecat just fine with 16GiB, though it might speed up with 32? not sure. <unmatched-paren>Not keen to run `guix build rust --check` at the moment, to be honest :) <jpoiret>unmatched-paren: yeah, it's possible that more RAM could let the build system allocate more parallel tasks <jpoiret>you'd have to see if RAM's the limiting factor here <unmatched-paren>I can say that it was stretched to its limits when compiling Rust though <maximed>I'd also be interested in maximal memory usage for non-compiling things. <maximed>jpoiret: Maybe the signal stuff can be ignored for now? (As in, gradual improvement, the old code seems to ignore signals too from what I can see from here?) <nerthus>I upgraded from 16GB to 32GB because I consistently ran out of memory compiling various applications/game engines <nerthus>and Linux just tends to die if you run out of mem <unmatched-paren>If you run out of memory during a compilation, you could just add more swap, couldn't you? <maximed>maximed: That is good usage -- also, G-exps don't care about modify-phases. <maximed>My guess is that you forgot to quote the modify-phases code. <jpoiret>PotentialUser-30: can you paste your new definition? <maximed>As we are using G-exps, that would be #~(modify-phases ...) <jpoiret>maximed: i'd like to fix this once and for all. We have too many spurious CI bugs <nerthus>when it comes to swap, I still live in a decade old mindset of not wanting your SSDs thrashed with writes, especially if you are compiling the same template over and over again <maximed>jpoiret: OK, so you are looking into making it robust w.r.t. signal handlers as well? *civodul just spent 30mn debugging non-existent bugs because they had (sanitizer xyz) instead of (sanitize xyz) 🤦 <jpoiret>yes, although i didn't consider that part <jpoiret>there shouldn't be any reason for a newly-forked process to receive a signal though, no? <maximed>¨PotentialUser-30: looks good from here (not at a Guix computer at the moment, so can't test it) -- does that still have the same issue? <jpoiret>maybe kernel-sent signals, OOM and the like <maximed>jpoiret: Consider the case where a program automatically sends every PID a certain signal. <maximed>Or: wasn't there a signal that is sent when the terminal size changes? <maximed>If it's really unlucky timing, then maybe that signal? <jpoiret>i don't think you can atomically fork+unregister signal handlers <jpoiret>but we could make those as close as possible <maximed>PotentialUser-30: Do you have any warnings or error messages beside that replace thing? <maximed>jpoiret: FWIW, for the 'library wants to use fd in a signal handler', maybe doing the disable signal handler before the close fds would be sufficient? <jpoiret>PotentialUser-30: does that happen while building or before? <PotentialUser-30>no, just that the because of the error, the defeinition does not exists, and thus, guix install: error: mine-brlaser: unknown package <maximed>PotentialUser-30: You are not importing (guix gexp). <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 ***wielaard is now known as mjw
<maximed>nckx: Turns out I misread things and 'btw' was included after all already. <unmatched-paren>civodul: I mean, that _is_ the site that says PHP and MySQL are more popular than the Linux kernel itself. <ardon>Hi guix! Apologies if I missed it in the manual or elsewhere, but what's the equivalent of guix build on the REPL? I'd like to build my package definitions without having to use the shell <unmatched-paren>ardon: Seems like (package-output STORE PACKAGE #:optional OUTPUT SYSTEM) <cbaines>package-output is for computing the output of a package <unmatched-paren>Ohh, I thought it meant "build this package then return the output path of the package" <cbaines>a combination of package-derivation and build-derivations should build it I believe <ardon>cbaines unmatched-paren Thanks! Will give it a crack <silicius[m]>Ok, I gave up on that test in python-mpv and just made a comment explaining the stuff. <silicius[m]>time to finish the hydrus-network package. It's going to be even harder since it was meant to be used from its own directory `/opt` kind of deal <jpoiret>we don't have `man 3 posix_spawn_file_actions_init` <rekado>civodul: commit 53b9c27aa59bebf955f0aa24fef60a101480ef5c makes mass updates with “guix refresh” difficult. We have a few packages for which the updater can’t determine a new release. <rekado>this now results in immediate failure, so the updaters for other packages don’t get a chance to run. <rekado>for the ongoing CRAN mass update I had to locally revert the commit. <civodul>rekado: for mass updates, you run "guix refresh -t cran", right? <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: <GNUtoo>wrong-type-arg "string-append" "Wrong type (expecting ~A): ~S" ("string" ("-f" "/gnu/store/ba027a7l9x2997p9wm8q2f12s8p5s2n4-android-make-stub-0.6.0/share/android/build/core/main.mk")) (("-f" "/gnu/store/ba027a7l9x2997p9wm8q2f12s8p5s2n4-android-make-stub-0.6.0/share/android/build/core/main.mk")) <rekado>with the commit it fails because “googlesheets” has been archived on CRAN. <GNUtoo>I've similar errors with ((assoc-ref %standard-phases 'build) make-flags) <rekado>GNUtoo: the error says you got a list of strings instead of a string. <GNUtoo>rekado: can I somehow print a list of strings? <jpoiret>you can directly (format #t "~a" list-of-strings) <civodul>indeed, "./pre-inst-env guix refresh -t cran r-a3 r-googlesheets r-a4 -u" stops at r-googlesheets <jpoiret>first time i'm hearing of pk, its doc seems great for debugging! :) <GNUtoo>hmmm I start to understand the issue, pk prints (("-f" "/gnu/store/ba027a7l9x2997p9wm8q2f12s8p5s2n4-android-make-stub-0.6.0/share/android/build/core/main.mk")) <GNUtoo>So that's a list of list? or does it try to execute the list? <jpoiret>can you share a snippet of your code? <nckx>GNUtoo: I just came in, but maybe you want (apply string-append LIST) or so? <GNUtoo>I'll cleanup a bit the code and do that <nckx>sneek: later tell maximed: Aha. That sounds like it makes the decision clear, assuming they are less obstinate about excluding Windows. <civodul>rekado: actually i can just turn that error into a warning and be done with it, WDYT? <maximed>nckx,other people: In case anyone is interested, it's a customised 'ThinkPad E15 Gen 3 (20YGCTO1WW)'. Let's see how that goes ... <sneek>Welcome back maximed, you have 1 message! <sneek>maximed, nckx says: Aha. That sounds like it makes the decision clear, assuming they are less obstinate about excluding Windows. <GNUtoo>(my usual pastebin doesn't work due to https issues but I'll fix it later on) <nckx>Shouldn't there be a #:make-flags keyword before make-flags in the last phase call? *GNUtoo was focussed on trying to understand why it didn't print and didn't see the obvious <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). <GNUtoo>I want to run make multiple times once with "LOCAL_MODULE=https-send-sms", once with "LOCAL_MODULE=libsamsung-ipc", etc <nckx>I remember this now. Clean approach. <p4r4D0xum>Is there any way to switch from application to system? <maximed>p4r4D0Xum: what application are you referring to, and what do you mean with system and switching here? <maximed>Or do you mean user profile vs. system profile? <p4r4D0xum>maximed: I'm talking about application setup. Using guix on foreign distro. <maximed>If you are using it on a foreign distro, I don't see what you mean with 'switch to system'. <p4r4D0xum>How can I put this? I would like to 'convert' guix on my foreign distro to be entirely guixsd without reinstalling the whole thing. That include init from guix <maximed>Yes, but though then you don't need Application-Setup.html <jpoiret>i'd suggest creating a new partition for the new system, and guix init'ing to there, then removing your old system partition <maximed>That's reinstalling the whole thing though? <jpoiret>i did it that way myself, alhough I used btrfs subvolumes and not partitions <jpoiret>it's a very manual process though, and you need to know what you're doing <jpoiret>no, guix init initializes the guix system on a specific mount point <jpoiret>it'll copy the relevant parts of the store though, so it might need some space at first <jpoiret>once the guix system is installed, you can remove the old partition with your old distro on it (and likely the foreign distro's /gnu/store if it doesn't live on another partition) <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. <maximed>Some files like xorg.scm have some other order. <maximed>For some files, we have forgotten do things orderly. <cbaines>sughosha, different modules may be different, the only important thing is to avoid adding new packages always at the bottom <jpoiret>I personally insert it in the first place that would make sense for lexicographical order <jpoiret>so that in the distant future, all files are properly sorted :p <sughosha>maximed: Thanks. As I am packaging new things in `music.scm`, there is no alphabetic order, so I don't know where to place my new package called `luppp`. <maximed>sughosha: Maybe jpoiret's suggestion? <Michal_Atlas[m]>It should install the bootloader and everything so, shouldn't the system boot into guixsd afterwards? <jpoiret>Michal_Atlas[m]: yes, but you'll still have a bunch of files from the old distro lying around <maximed>p4r4D0xum: if you install it as root, only root will have access <maximed>if you install it as your normal user, your normal user will have access. <p4r4D0xum>maximed: That was my initial thought as well, login as root ain't cutting it tough <jpoiret>if you're on foreign, it's likely that you haven't sourced root's profile <sughosha>jpoiret: There is already a package of the same developer of the new packages. So I am packaging it above that package. I hope this is fine. <Michal_Atlas[m]>yeah, foreign distro installs sometimes have a hard time getting all the variables in order other than manually sourcing <maximed>(E.g., sourcing profiles doesn't seem to be done automatically on Debian when starting a graphical session.) <jpoiret>Michal_Atlas[m]: on guix system, /etc/profile does in fact source them manually <maximed>if ~/.guix-profile/bin isn't in there, you'll need to source ~/.guix-profile/etc/profile yourself IIRC. <maximed>(or bash --login, that works for me on Debian) <jpoiret>ideally, you need to do `GUIX_PROFILE=~/.config/guix/current/; . $GUIX_PROFILE/etc/profile; GUIX_PROFILE=~/.guix-profile/; . $GUIX_PROFILE/etc/profile; unset GUIX_PROFILE` <p4r4D0xum>jpoiret: Worked perfectly, after I refreshed my midocre knowledge on bash substitution. :) <p4r4D0xum>jpoiret: What's the point of running guix as root? Privilidge? <Michal_Atlas[m]>System reconfigure will fail to install the bootloader properly (last time i checked) unless run as root otherwise i think you can always use regular user <GNUtoo>p4r4D0xum: as for converting a foreign distribution to Guix, I tried it once on a vm but even if it worked, it would be messy as the older distro files would stay around <GNUtoo>What might be better would be to create a new partition somehow (if that's possible) and probably mount what you need from the older distribution <GNUtoo>If you can't create new partitions I wonder if guix somehow supports booting on loop files? <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>s/catch up/wasn't widely adopted/ <nckx>Relevant/should I bother looking it up? <nckx>Yes, GRUB supports loop files better than Guix. <GNUtoo>It's an installer to install Ubuntu from Windows, There was a fork of it for Debian at some point <GNUtoo>The key difference with other installation methods was that the GNU/Linux distributions were installed in a file <GNUtoo>So what is most interesting with that approach is to learn about their limitations <nckx>So when you switched to Ubuntu it was running from a loop file on NTFS? That's one long-term sacrifice for a one-time installation. <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 <nckx>Does the ntfs3 project also work on providing new user-space tooling? <GNUtoo>ntfs3g has tooling, and that's where we have the experimental fsck that isn't shipped by any distros <nckx>Right, I meant the new sans-g kernel one. <nckx>Also going off-topic, my bad. <GNUtoo>I think it's interesting, for instance do we need to package it in Guix? <nckx>If we do want to provide Guix to people trapped in Windows (and I have serious qualms about doing that in a way not clearly intended to *replace* Windows) we'd use WSL now, I guess. <nckx>GNUtoo: It's a Linux kernel driver, there is no package. <nckx>I think we enable it but didn't check. <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) <nckx>I resize their partitions with gparted. <nckx>I'm hoppy to say some people who insist on dual-boot hardly use it after a year. <nckx>Booting into it after 3 months only to see a mandatory 'update' break their stuff helps. <GNUtoo>+ people like when computers last way longer <efraim>looks like curl-7.84.0 also fails on armhf-linux *GNUtoo is even still on i686 with a more than 10 years old laptop... <GNUtoo>i686 is a bit hardcore indeed, but the good side is that I help a bit keeping it alive <nerthus>one of the few devices that probably cant run Crysis <GNUtoo>The biggest issue I ran into is the 3GiB memory limit per process <GNUtoo>The rest usually can be dealt with <jpoiret>GNUtoo: aren't there some x86_64-only programs? <GNUtoo>for the rest I don't know. Though darktable could probably be fixed somehow <GNUtoo>In Guix specifically the biggest issue is that we need to make the rust bootstrap fit witin 3GiB <GNUtoo>I managed to make it fit in 4GiB at some point but not yet 3GiB <johnjaye>hmm. will guix install work if i completely wipe the hard drive first? <GNUtoo>jpoiret: we probably need a bit more context to understand the question, what did you try to do? <GNUtoo>(using a single partition and wipe the hard drive looks to be 2 unrelated things to me) <johnjaye>GNUtoo: i assume you mean me. i reported a bug because the guix installer failed <johnjaye>some uuid problem. so i suspect perhaps if i wipe the drive completely maybe that would resolve it? <johnjaye>i don't know where the installer script is so i can't check what the problem is atm <GNUtoo>There is also something faster: wipefs -a can only wipe the metadata <GNUtoo>for instance wipefs -a /dev/sda1 # this will remove the filesystem metadata <GNUtoo>for instance wipefs -a /dev/sda # this will remove the partition table but not filesystem metadata <GNUtoo>but I advise to do a backup of the important metadata first as it might be needed to reproduce the bug <johnjaye>i didn't know that command existed. looks like it's from bsd maybe. <johnjaye>i have 2 drives i use daily, one for windows one for linux. i tried to install to the last partition on the linux drive /dev/sdc6 <johnjaye>sdc1 = efi, sdc2 = swap, and 3-5 are ubuntu deb deb <rekado>sughosha: thanks for the patches! Can you please tell me why you picked this particular commit of sorcer? <sughosha>rekado: I have already mentioned this in the changelog, the latest commit builds successfully whereas the release doesn't build. <rekado>last release was in 2016, so I guess it’s just to get some build fixes. It’s good to add a comment whenever we use arbitrary commits. <rekado>I can add a comment on your behalf when I apply the patch. <sughosha>I will check your commit messages and then improve my next patches. <rekado>it will take me a little while, though, because I’m in the middle of some other package upgrades. But I’ll get to it right after I’m done. <rekado>sughosha: I suppose with fabla, luppp, and distrho-ports it’s the same story? <rekado>or are there other reasons for these commits? <rekado>oh, and what’s up with the high number of revisions? <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>sughosha: for sorcer I’ll have to make a few more changes. <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. <rekado>but we’d like to build from source <rekado>you probably removed it because faust 0.9.90 doesn’t understand the code in main.dsp <rekado>we need to use fauts 0.9.67 for that <rekado>I’ll add a commit before yours that adds this variant of faust <sughosha>Cool! If it will build successfully it would be great. <sughosha>rekado: I also don't know why cpu flags from CMakeLists.txt had been removed. <rekado>sughosha: the CPU flags have been removed to ensure that binaries will work on *all* x86_64 machines. <rekado>this will lead to poorer performance if your CPU is more recent. <sughosha>Ok, so while building I should locally make change and then set the flags again and build (for me with the flags it works perfectly). <sughosha>I don't know if I can globally set my cpu flags like in Gentoo. <rekado>this has been discussed on the mailing list multiple times. <rekado>there’s no clear proposal for this yet. <rekado>but there are ways to build packages with CPU tuning <rekado>(I don’t know how easy it is to use tuning in this case) <rekado>sughosha: I’ve pushed all patches up to distrho-ports. <rekado>I’m not sure about what to do with distrho-ports. <rekado>it bundles a bunch of other libraries and the license situation is not clear <rekado>I just spot checked one or two plugins and their licenses do not appear in the license field <rekado>so I’d prefer to have some more eyes on this and see if things can be unbundled some more. <jpoiret>johnjaye: oh, and you didn't receive my reply because hotmail blocks my email address <yewscion>Is there a way to skip tests with guix home, currently? Other than creating a derivative package that specifies `#tests? :f`? <johnjaye>jpoiret: apparently not. i've heard this is more and more a common problem. what's your domain? <podiki[m]>anyone familiar with ocaml packaging in guix? <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? <jpoiret>If you use the latest installer, you'll likely a) not encounter the bug b) encounter the bug but get more debugging information <p4r4D0xum>Maunal states I need to run `herd' command but command not found. <jpoiret>p4r4D0xum: herd is present only on guix system ***kitzman_ is now known as kitzman
<podiki[m]>anyone know about dune-build-system and dependency finding? <rekado>podiki[m]: roptat probably knows <sneek>roptat was in #guix 6 days ago, saying: ah right, I didn't follow the issue, I just came back. ***mark_ is now known as mjw
<vivien>Dear guix, what package should I have as native inputs in order to build the PDF version of a texinfo manual? <rekado>vivien: probably some texlive-* packages <vivien>That’s aligned with what I thought, yes! <vivien>However I don’t know which ones, and texinfo isn’t very helpful to help me <rekado>you’ll probably need texlive-texinfo, but the set of packages you need can differ wildly <rekado>examples: mit-scheme, optionmatrix, hypre, discrover <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 <vivien>Well adding texlive-epsf is sufficient <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. <nckx>Oh, I really thought it was you, sorry. <nckx>Hm, so this failure's not a total fluke. Interesting. <nckx>Unfortunately, quite a lot depends on curl, perhaps more than wine on your machine. <yewscion>No worries. I usually try to solve things myself first, then IRC, then if all else fails ML or Issue Tracker. Just like to keep the queues clear if possible, especially when I am learning. <lilyp>For the record specifying --without-tests=curl should recursively apply the "fix", but failing curl tests are probably a bigger problem <yewscion>See, I'm able to `guix build curl --without-tests=curl` successfully, but for some reason it's still building in guix home with tests enabled. <lilyp>see (guix transformations) for the declarative package transformations <nckx>Can that easily be made recursive lilyp? <yewscion>lilyp: I agree, just have some work to do today before I can address those issues. Also, I tried `--without-tests=curl` with `guix home reconfigure`, but it seems to not be respected there. <nckx>lilyp: I didn't read the ML post attentively but I thought it built fine there, hence substitute question. <lilyp>you just map the package-transformation over your packages, same as when using manifests <nckx>zimoun said it works for them & CI builds fine. <yewscion>FWIW, removing wine from my guix home declaration /seems/ to have solved the issue, as curl is no longer queued for build. Blast radius may be limited to the wine package, at least. <lilyp>Though you're right in that "hidden" packages in guix home could also pull in curl, so you'd have to configure those too <nckx>8735fkohxr.fsf@gmail.com <nckx>(I know they are unrelated, but ...fsf@gmail.com is always jarring.) <lilyp>how do I search for message IDs in the web frontend? 😅️ <nckx>If I knew I wouldn't have just dumped the ID on you, tee hee. <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? <yewscion>`(map (options->transformation '((without-tests . "curl"))) my-packages)`? <lilyp>to all transitive inputs of my-packages to be exact <yewscion>Copy that, interesting. I will remember that for the future. *nckx will try to, which is something. <emacsomancer[m]>curl seems to be failing to complete successfully, failing a SMB server check? <rekado>curl fails its tests for i686-linux on my machine <rekado>lib3026 returned 255, when expecting 0 <nckx>Starting to wonder if zimoun's successful report is for the right curl. <nckx>The actual error doesn't seem to be logged in the Guix build log, or at least I didn't spot it. Maybe -K will reveal more detailed logs. <nckx> curl being very c-u makes a sudden failure odd. <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? <nckx>It's a bit of a build if you don't need it. <nckx>You could (evil voice) graft it... <nckx>...now I'm surprised that nobody's made (or admitted to) an evil-without-tests transformer that does just that. <mitchell>cryptsetup fails when cross compiling to aarch64-linux-gnu. It says libgcrypt is not available despite it being listed as an input. Any ideas? <lilyp>nckx: wouldn't you need the tested curl to graft tho? <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). *nckx puts fake goatee back in the box for now. <podiki[m]>question about validate-runpath at the end of a build: I'm getting an error on not finding a library in the store path of the project of /lib/<packagename> but the library is in just /lib <lilyp>if so, well there's your problem <podiki[m]>so #$output/lib/libneeded.so but validate-runpath wants #$output/lib/pkgname/libneeded.so ...is this something I should fix in install, or cmake? <podiki[m]>I'm just not sure if this is something indicating a build option should change or just a tweak of where things are installed <johnjaye>jpoiret: wait your email is self-hosted? can you talk to gmail or is that all blocked as well <podiki[m]>looking at Arch, it just has the lib in usr/lib ...is this something indicating I should adjust runpath? (since that's where validate-runpaths looks) <nckx>I've never had trouble talking to Hotmail. <lilyp>podiki[m]: you might actually be lacking stuff in runpath, i.e. the libraries libneeded.so itself needs <lilyp>those will also be reported as file not found <johnjaye>well. maybe i need to be subscribed to the guix deb bugs list? <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? <nckx>johnjaye: But did they CC yeu? <johnjaye>yes i believe so. it says me and deb bugs in the To: field <nckx>Then subscribing wouldn't help, don't worry. <lilyp>yep, just the mail servers slow in delivering it to your door *nckx *is* the mod queue. <johnjaye>i'm surprised anybody replied at all. my expectation in open source is usually nobody replies or the owner of the github repo replies and then closes the issue without fixing it <nckx>johnjaye: Glad we've at least exceeded that expectatiot. <johnjaye>well.. when expectations are low, that's pretty easy. the one plus side i guess *johnjaye doesn't know much about the history of guix <lilyp>i just had the weirdest abi bug <lilyp>it didn't complain when I ran make, but when I ran ./pre-inst-env guix system <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. *podiki[m] plays the regex matching game with \s <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 *podiki[m] may have just packaged neko and haxe...time to test <nckx>podiki[m]: That would be 4, not 3. <nckx>Please don't say 3 worked. <podiki[m]>nckx: the expression was backslash$, and needed in total 6backslash$ to match ***civodul` is now known as civodul
<podiki[m]>(I know we've discussed this madness before) <nckx>Nothing else would make sense. <podiki[m]>3backslash + original backslash + 2 backslash + original $ <nckx>By that logic it's 5 backslashes + original backslash, but I don't think looking for logic works when including an 'original backslash' in the story. <podiki[m]>5 total backslash: "invalid character in escape sequence: (#\$)" <podiki[m]>am I wrong that you need 2 backslash to escape $ in matching? <nckx>That's where I came in (your 3 + 2 message) and my brain almost broke. <podiki[m]>I feel like I've done this exact matching before, hopefully quicker this time since I knew it was many *podiki[m] brain is broken <podiki[m]>so looks like haxe is working, did the hello world for heaps.io (minus vscode, just manually) and I got a hello world webpage <nckx>You just double backslashes when writing regexps, as is tradition, then add one because $ is magic too, then you double them again when putting it in a Guile string. <nckx>OK, 'just', but I promise I didn't need to think twice about it so Stockh^Winternalising it is possible. <nckx>Your '3 + original' phrasing is not hom I would look at it, although I guess it's valid, but dump it if all it does is confuse you. <podiki[m]>I don't have a method beyond adding backslashes until 1. guix doesn't complain, and 2. it fixes the problem <nckx>podiki[m]: Now write a substitute* that patches this .scm file to replace '\\\\\\$' with 'I love regexes so #$?)ing much'. <podiki[m]>if I have to do this again and forget where I did it, I'll try your formula <nckx>Please promise you'll use grep on the logs to find it. <podiki[m]>just let no one else say "nckx-ify" again unless discussing this special formula *podiki[m] just tried to grep for many backslashes and spun further into madness <nckx>(By the way, you'd write \\\\\\$ on the shell command line too *if* you didn't use quotes, so it's not unique to Guile and please god stop calling it 'mine', I am innocent, you have no proof.) <nckx>In all seriousness I hoped to help, but if all you remember is a magical 'formula' then I guess I'm okay with having failed. <podiki[m]>the real question is if I'll remember when/if I need it again <podiki[m]>usually I try to remember what package I had to do special things for and look at that source <nckx>Hence my doomed (because regexps) attempt at insight. <nckx>My nick matches itself as a regexp. Yours doesn't (on IRC anyway). Nominative determinism. <podiki[m]>back to guix: so I have a working haxe (package manager for haxe language I guess? i'm new) <podiki[m]>anything I should be checking for such a thing in guix? when you try to run it you need to initialize, but with any directory you give it (obviously default /usr/... doesn't work) <podiki[m]>it builds to e.g. javascript and ran in my browser <nckx>Would patching it to default to $HOME be too intrusive IYO? <nckx>Or change the error message, which I presume is '/usr: permission denied' with something more explicit ('please supply a writable directory this way'). <podiki[m]>well it asks explicitly, with a default of /usr/... <nckx>I'm mainly looking for excuses to force you to use substitute* again for my own amusement but I'm also serious. <podiki[m]>but yes, could patch to default to something like $HOME/.haxe <nckx>Right, I meant patch the default, because it's weird to suggest something that is almost guaranteed not to work. <podiki[m]>I also have the neko vm (no idea how to test yet), and I see there's another vm for this ecosystem, hashlink, let me try that too <nckx>That's a lot of 'ecosystem' for a language I just learnt exists. Interesting. <podiki[m]>I don't know yet, but saw it in discussions about open source game libraries/engines (heaps which is built in haxe) <podiki[m]>some very successful (non opensource) games built with it <podiki[m]>seems pretty flexible in targeting mobile, web, desktop, etc. from a high level language without fussing on those details? <nckx>I have no idea what the buzzwords 'mobile, web, desktop' mean but I guess that's deliberate. <p4r4D0xum>nckx: You have never heard of hexe? It's around for a while. <nckx>I've never heard of many things that have. <podiki[m]>yes, haxe seems to run, is built on top of ocaml <podiki[m]>haxe seems happy to do it's haxe package managing, downloading, sample code I tried works <p4r4D0xum>podiki[m]: The compiler is written in ocaml actually. <podiki[m]>you now know at least as much as I do about haxe (and ocaml for that matter) <nckx>'What'"'"'s good' — bash. <podiki[m]>0 is definitely an acceptable number of backslashes <nckx>Did... did you not see my bash. <jpoiret>nckx, johnjaye: the hotmail postmaster sent back the mail because they didn't accept it <jpoiret>and since you're not subscribed to the ML either, you didn't get the mail <jpoiret>I don't think i've had these issues with gmail (some maintainers use gmail and they get my emails fine) <jpoiret>and yes, I self-host my mail because I prefer self-hosted services, and I love maintaining servers for technologies that require a bunch of moving parts just for me to send bug reports <johnjaye>i've heard stories of microsoft and google screening emails. but didn't experience it yet <lilyp>let them screen messages towards a public mailing list all day long 😎️ <johnjaye>well. it's a pain to have to maintain multiple emails