<guix-ci>Problem: Too many processes on hydra-guix-127 Problem started at 23:56:47 on 2020.04.23
<rekado>plstohelp: this isn’t really a Guix problem AIUI. Your filesystem decided to truncate a file to zero. There’s nothing Guix can do at this point.
<guix-ci>Resolved: Too many processes on hydra-guix-127 Problem has been resolved at 00:03:47 on 2020.04.24
<reepca-laptop>is there a concise way to just say "update this package and any packages that would conflict with it"? Repeatedly running "guix package -u a b", then seeing "a conflicts with c", then running "guix package -u a b c", then seeing "a conflicts with d", and so on, is a bit tedious
<rekado>civodul: I think at this store size hardlink deduplication just isn’t feasible
<rekado>just advancing the position in the readdir stream of /gnu/store/.links takes more than 50 minutes
<reepca-laptop>so I've got an xorg-server-for-debugging package that I've configured slim with in my /etc/config.scm. It just adds a debug output and adds CFLAGS=-ggdb to the #:configure-flags. But when I attach gdb to the X server (/gnu/store/...-xorg-server-for-debugging-1.20.7/bin/X) and run "info shared", I see that it's apparently using /gnu/store/...-xorg-server-1.20.7/lib/xorg/modules/libexa.so, for example. Any idea where this is coming from?
<guix-ci>Problem: Too many processes on hydra-guix-125 Problem started at 01:44:21 on 2020.04.24
<guix-ci>Resolved: Too many processes on hydra-guix-125 Problem has been resolved at 01:51:21 on 2020.04.24
<ryanprior>I'm working on packaging appstream. Its configure script is telling me "Dependency lmdb found: NO" but simultaneously "Library lmdb found: YES"
<ryanprior>I included the lmdb package in native-inputs, and clearly it can find the "library." I checked out the lmdb package in guix to see if it had multiple components, or any inputs that maybe need to be propagated etc, but no it's a really simple package.
<ryanprior>I also grepped through existing guix packages to see if anybody's treating lmdb specially, and there's a bunch of packages that depend on lmdb without anything unusual.
<guix-ci>Problem: Too many processes on hydra-guix-107 Problem started at 02:00:10 on 2020.04.24
<guix-ci>Resolved: Too many processes on hydra-guix-107 Problem has been resolved at 02:08:10 on 2020.04.24
<reepca-laptop>it looks to me like xorg-configuration->file doesn't honor xorg-configuration-server
<lfam>Sounds frustrating ryanprior. No particular advice but I've seen this kind of thing before. Sadly had to go spelunking in the upstream build scripts
<terpri>slightly off-topic question: i'm trying to run a non-free program (unity editor) under guix, which contains a huge number of library dependencies (both internal, and things like libstdc++)
<terpri>is there some semi-automated way to patch rpaths and program interpreters for programs like this? other than manually using patchelf to fix every single dependency?
<terpri>on debian i'd probably whip up a script using apt-file to find the missing libs, but that doesn't exist for guix, i think
<terpri>nix has autopatchelf, which doesn't work out-of-the-box on guix
<terpri>(i know the right answer is "don't use non-free programs", but this is for $work and, while i am promoting godot and other free alternatives, it will take some time to get other people to switch)
<reepca-laptop>we don't have apt-file proper, but if the dependencies are things you'd expect to already be in the store somewhere - standard libraries and such - 'find /gnu/store ...' works decently for me. If you could batch together all the libraries you're looking for into one command you could even do it in a single pass.
<terpri>reepca-laptop, thanks, i think that will work, with some find/ldd/sed magic :)
<terpri>also just now persuaded the ceo to sponsor a godot port, so hopefully i won't have to deal with this much longer :)
<ryanprior>Woah, a godot port. That sounds like a big deal.
***catonano_ is now known as catonano
<guix-ci>Problem: Too many processes on hydra-guix-115 Problem started at 03:11:11 on 2020.04.24
<guix-ci__>Resolved: Too many processes on hydra-guix-115 Problem has been resolved at 03:20:11 on 2020.04.24
<ryanprior>Okay so I have a new theory, which is that my build is failing not because of lmdb at all (since it is finding the library) but because right after that the meson.build references /usr/include (for a config option that I'm not even using)
<ryanprior>So I'm thinking I ought to just delete that line from the meson.build file. I'm trying to figure out right now how to do that.
<reepca-laptop>xelxebar_: origin objects can be used as inputs in addition to as sources. Regarding whether you can combine multiple into one origin object, the object bound to the source field must end up being represented by a single store item, but aside from that it would in theory be possible, I just don't think there's any code for doing that right now (I may be wrong)
<reepca-laptop>ryanprior: if that's the only occurrence of /usr/include, it should only remove that line. Is it not removing that line? Methinks there may be some regular-expression quoting issues
<ryanprior>Is there a function for escaping regex chars?
<ryanprior>I didn't realize substitute* took a regex (I can't find the docs for it)
<reepca-laptop>ryanprior: when in doubt, we can read the source. Which sounds intimidating, except that usually for frequently-used tools like that there's a big ol' docstring at the definition that gives a decent enough explanation
<reepca-laptop>so for example, if you look at ~/.config/guix/current/share/guile/site/3.0/guix/build/utils.scm at line 791 you'll see the definition and its docstring
<ryanprior>I don't know where the source for substitute* is and haven't looked too hard yet because I assumed up to this point it just took a string. Thanks for pointing that location out =D
<reepca-laptop>when in doubt: grep -R 'substitute\*' ~/.config/guix/current/share/guile/site/3.0/guix
<ryanprior>Escaping regex chars brought me over this hurdle. Now on to investigate the next one 😅️
<ryanprior>But first, a break, because I've been concentrating a long time
<reepca>so I've got a syscall I want to add to (guix build syscalls), but, uh-oh, it's got an argument of type off_t, the size of which is not defined by the standard - it's just "a signed integer type". What's the proper protocol to follow there?
<guix-ci>Problem: Too many processes on hydra-guix-106 Problem started at 05:38:27 on 2020.04.24
<guix-ci>Resolved: Too many processes on hydra-guix-106 Problem has been resolved at 05:42:27 on 2020.04.24
<guix-ci>Problem: Too many processes on hydra-guix-127 Problem started at 05:55:47 on 2020.04.24
<guix-ci>Resolved: Too many processes on hydra-guix-127 Problem has been resolved at 05:56:47 on 2020.04.24
<olivuser>Hej #guix! Is anyone else having problems with getting sway to work? I included it in my os config file (just as I would do for dwm or stumpwm), but after reconfig, it doesnt show up in gdm.
<janneke>reepca: what "standard" are you talking about? could you make the size explicit, alike "sizeof-dirent-header/hurd"?
<reepca>janneke: "the standard" here meaning "posix". I'm not sure what you mean by "make the size explicit". It's a direct parameter, so I couldn't just say "4 bytes" or "8 bytes", I'd have to give one of the types predefined by guile's FFI (int, long, etc).
<rekado_>olivuser: you need to start it manually AFAIK
<janneke>reepca: ah...without too much understanding, i was wondering if you could hardcode it
<reepca>and either way I can't portably say what the size is. I guess I could start enumerating the values for the various platforms we support, but it feels like wasting some of the portability C gets us. Getting this kind of information seems like the sort of thing that a configure script should be good at, no?
<PlasmaStrike>Guix has linux support, getting herd support. What about others like sel4 linux microkernel, the BSD's, minux?
<olivuser>Does anyone else have problems getting gitlab-related channels to work? When I try to pull, I get an error like "too many authentication redirects". First I thought this was because of tor, but the situation remained the same after deactivating tor.
<Kimapr>i found a way to get hashes for package downloads. you just put in placeholder hashes in package definition, try to install it and wait when it founds a mismatch. then you just take the actual hash
<thvk-ivgf>Kimapr: rekado told me that guix doesn't store the downloads with mismatched summs
<nagamalli>but i got know anyone of version is failing to build..!
<xelxebar>cbaines: Hrm. I must not grok grafts correctly. My understanding was that they provided a way to update dependencies without requiring a full rebuild. So I assumed that a *newly* build package would simply link against the updated library, obviating the need for a graft
<rekado_>nagamalli: you cannot upgrade glib either
<cbaines>xelxebar, I don't particularly understand grafts either, but consider that a input to an input to your package may have a replacement. With grafts, you're building without the replacements, then grafting so that the replacements are used.
<rekado_>nagamalli: please post details about what you are trying to achieve, what problems you encountered, and what you plan to do to overcome them
<rekado_>nagamalli: please post to firstname.lastname@example.org
<rekado_>xelxebar: grafts are not very complicated. Your misunderstanding is in thinking that building a new package won’t use grafts.
<kmicu>(but local guix build complains about locale issues, and .go files)
<rekado_>xelxebar: so when you have a package that has “openssl” among its inputs it will be one particular package value
<rekado_>when your package has an input that has “openssl” among its inputs, that’s still the same unique package value.
<rekado_>your package = “foo”, its input = “bar”; “bar” has “openssl” among its inputs.
<rekado_>now let’s say openssl needs to be patched
<cbaines>kmicu, nagamalli I think the first thing to do here is try on core-updates. The integration of version updates for Gnome isn't continuous, but happens on a different branch. core-updates has email@example.com, which might work with gnome-todo
<rekado_>we don’t want to rebuild all packages that depend on it.
<rekado_>so we just define a new variable “openssl/patched” and bind a new package value to it.
<rekado_>when grafts are disabled openssl/patched is ignored – we don’t care about replacements
<rekado_>with grafts enabled “openssl/patched” is built, so we get a new hash for this variant of openssl
<xelxebar>rekado_: Oh! I think I get it. So "openssl" has to refer to the ungrafted thing because *existing packages* that built before the graft refer to that exact package value. So new packages also must refer to the same package value, even if we are building in the post-graft era.
<rekado_>when we ask Guix to build “foo” without grafts, we don’t need to do anything because we have built it in the past already.
<rekado_>when we ask Guix to build “foo” with grafts, however, we copy the output of “bar” and replace all references to /gnu/store/aaa…-openssl (the original hash) with /gnu/store/bbb…-openssl (the hash of the replacement)
<rekado_>since the output is now slightly different, our grafted version of “bar” will have a new hash
<rekado_>so we copy the output of “foo” and replace all embedded references to /gnu/store/aaa…-bar with /gnu/store/bbb…-bar
<rekado_>this gives us a slightly different copy of “foo” that no longer depends on the ungrafted bar, so it also no longer depends on the ungrafted openssl
<rekado_>graft = copy output and replace references of A with B
<rekado_>do this recursively for all recorded replacements
<rekado_>for packages that are sufficiently close to the root of the dependency graph using grafts is *much* faster than rebuilding everything up from the patched package
<rekado_>because all that’s needed is to copy the output, search for references to the old store item and replace them with a reference to the new store item.
<rekado_>then compute the new hash and move up the graph until we hit the target package
<xelxebar>Is this correct? Even after foo/patched exists, new packages referencing "foo" have to be grafted because "foo" refers to the original, ungrafted version. We cannot update "foo" to refer to foo/patched without also breaking what "foo" means for packages built pre-graft.
<rekado_>this doesn’t mean that all of our texlive stuff is broken; I managed to improve a lot of packages by checking the “runfiles” list. But it does mean that the naive importer has outlived its usefulness.
<civodul>rekado: i guess biber has to be upgraded in lockstep with something else?
<jonsger>elvirolo: but we have good btrfs support, if you are into modern file systems :P
<elvirolo>jonsger: I have never really used btrfs. Would be a good reason to try :) The thing is I already run my current system from a ZFS root, and would very much like to experiment with guixsd, and ZFS pools cannot be (easily) shrunk.
<jonsger>elvirolo: though we have already a zfs package, you "only" need to add support for Guix System to use it :P
<elvirolo>Yes I saw that ZFS had been added (do you happen to know how the licensing issue was dealt with?). I'm afraid I am no programmer and thus can't be of much help.
<jonsger>elvirolo: the zfs package is excluded from building on our build farm. So you only download the source code from Guix servers and have to built it locally
<rekado>civodul: I think it must be updated together with texlive-bin
<civodul>rekado: and updating texlive-bin means updating all of texlive, right?
<civodul>IWBN if we could import "a few" core npm packages so we can package things like Grafana, Jupyter Lab, etc.
<jlicht>cbaines: so realistically, something akin to mrustc, but for CoffeeScript, TypeScript etc etc would at least allow us to start packaging newer version of NodeJs (as that needs TypeScript to generate C, yaaaaay)
<jlicht>civodul: I updated biber quite a while back, without the entire "update the rest of texlive as well"
<mbakke>buffet: 'guix environment package' will drop you into a shell with everything you need to build 'package'
<buffet>mbakke, im talking about a general thing. liek if i just want to play around with something or write a short thing i usually just `nix-shell -p stdenv` (equiv would be `guix environment --ad-hoc stdenv`) and can start hacking
<lispmacs[work]>I'm trying to build some code that runs command gcc -o mconf mconf.o zconf.tab.o lxdialog/checklist.o lxdialog/util.o lxdialog/inputbox.o lxdialog/textbox.o lxdialog/yesno.o lxdialog/menubox.o -L/gnu/store/gzp4ig4rdb1qf4i5dy1d9nl0zmj5q09y-ncurses-6.1-20190609/lib -lncursesw
<rowhit>Hi all. I have installed scons and gnu-toolchain using guix. And I am now trying to build a simple program. But the "scons" is not able to find the "gcc". Though it is there in my PATH already. How do I force "scons" to recognized that?
<lispmacs[work]>but afterwards I run ldd on the executable and get libncursesw.so.6 => not found
<jonsger>mbakke: I have no fonts installed, so like manually
<anadon>Could I get some traction on "Possibly incorrect dependency in go-1.4 package"?
<cbaines>rowhit, sounds like more of a scons question. I don't think scons respects the $PATH, and sets its own value.
<cbaines>Hmm, I have even less of an idea about that new error...
<cbaines>Given that Guile is being very unhelpful about the location of the error (your problem isn't in ice-9/eval.scm or ice-9/boot.scm) probably means that there's an issue evaluating the specification
<raghavgururajan>janneke Regarding #40752, SpaceFM works with util-linux for 'eject'. But I am wondering why to use 'util-linux' package just for one utility. This 'eject' package will be smaller dependency than 'util-linux' package. What do you think?
<janneke>raghavgururajan: I very much prefer util-linux; every linux system already has that in the store; why add an extra package that does the same thing?
<TZander>rekado: I'm trying to get a patch to upgrade Qt, its in #40791, and there I disabled the qtwayland build because tests were crashing (or at least not finishing). I can't debug the reason they are crashing.
<civodul>apteryx: it's possible that there've been API changes in this area
<rekado>TZander: you said you got a core dump, right?
<reepca>TZander: builds are run in a container, so for example /bin/sh isn't available there. There's also no network access other than to itself. The builder is also in a PID namespace, so it thinks it's PID 0. There are other differences. Source'ing the exported environment doesn't reproduce that.
<reepca>another question would be exactly "when" in the build environment we want to drop the user in. For example, if we drop them in prior to the builder being run at all, environment variables wouldn't be set up yet, so poking around would be a bit difficult
<reepca>personally I like the idea of generating a slightly-modified builder that drops the user into a REPL (or shell of their choice) once a phase fails. That way they have the very precise environment it failed in.
<reepca>(said slightly-modified builder would of course only be used for debugging environments)