<plstohelp>yeah, it seems to work now after the fsck and the gc <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 <rekado>just opendir, while ((ent = readdir(dir))), closedir <rekado>civodul: I’m trying getdents now, but I expect it to be in the same ballpark <guix-ci>Problem: Too many processes on hydra-guix-119 Problem started at 00:31:03 on 2020.04.24 <guix-ci>Resolved: Too many processes on hydra-guix-119 Problem has been resolved at 00:38:03 on 2020.04.24 <civodul>rekado: uh, but readdir just translates to getdents calls <civodul>i wonder if deduplication could automatically turn itself off once .links is too big <civodul>problem is we can't tell how many entries a directory has <civodul>or we could create say /gnu/store/.links/count in the delete-unused-links phase <mbakke>so I added a "make-glibc-news-entry" procedure in ./etc/news.scm extracted from commit 2cf9798e1688c28d33d12d360e7869207eca18d7. Does that seem sensible? <civodul>mbakke: news.scm is not code, just data <mbakke>oh, derp (not finished pulling it yet) <civodul>so we'll have to duplicate it i guess <mbakke>that's what I did first, so no probs! :) <mbakke>happy that 'guix pull' copes with the broken news file: "error: invalid channel news file" <raghav-gururajan>While building, I get an error "cannot convert ‘bool’ to ‘boolean’ in return". <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. <ryanprior>I grepped in the appstream repo and this is the only place /usr/include is referenced: <xelxebar_>Can I combine multiple `origin's into a single `source'? <xelxebar_>Have a package that serves up its docs separately, but want to combine the two into a single package with multiple outputs. <xelxebar_>Better yet, how could I go about searching for this kind of thing in the repo? <guix-ci>Problem: Too many processes running on hydra-guix-105 Problem started at 03:55:46 on 2020.04.24 <guix-ci>Resolved: Too many processes running on hydra-guix-105 Problem has been resolved at 04:00:46 on 2020.04.24 <ryanprior>What's a function to just remove a single line <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? <janneke>reepca: possibly, unless you're cross-compiling <janneke>then you shove it onto the user who runs configure? <janneke>i suppose that "all" the platforms we support are: linux 32bit and linux64 bit? <reepca>well, hurd should be in there somewhere <janneke>i'm not sure where ffi comes in, maybe mwette knows more about your question (when they are around) <reepca>are headers often parameterized beyond just "number of bits in a word"? For example, could off_t be different on gnu/linux on 64-bit arm and gnu/linux on x86-64? <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. <xelxebar_>PlasmaStrike: While we're nitpicking, AFAIK, it's now officially "Guix System" instead of "GuixSD" <xelxebar_>I want the spiritual equivalent of QubesOS with a guix dom0 <asmodehn>xelxebar_, yes :) we could also have docker recipes in scheme as a guix config... <xelxebar_>Hrm, this seems doable with guix deploy and some appropriate `environment' <xelxebar_>How can I reference an item in `inputs' from within `arguments'? ***apteryx_ is now known as apteryx
<reepca>xelxebar_: I believe %build-inputs is globally bound in the build environment <xelxebar_>Looks like that's mentioned in the manual section about derivations. Thanks. I'll give it a try. <Kimapr>building /gnu/store/wbisms6lvy50v1gzswbl578mjg17gpa2-minetest-5.2.0.drv... <Kimapr>yay. my first edit of a package definition that gets to that stage <Kimapr>I edited the package definition of minetest to upgrade to latest release. also i removed the dependency on minetest-data <Kimapr>(which btw should be renamed to minetest-game or similar because that it's name) <Kimapr>i find weird that engine has a game as input and not vice-versa. <xelxebar>Oh, right... getting a hold of inputs is just like getting a hold of outputs... assoc-ref <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 <Kimapr>does git download works with git? <Kimapr>hmm, it seems that guix *does* store downloads with mismatched sums <Kimapr>because it doesn't download minetest again <civodul>Kimapr: there's no "hash mismatch" for "guix download": it downloads what you ask and stores it in the store <Kimapr>i'm not downloading with guix download <Kimapr>i'm just installing the package definition file <xelxebar>Okay, so looking at guix/build/utils.scm(install-file) it simply calls (mkdir-p directory) before (copy-file ...) <xelxebar>The funny thing is that directory is simply something like "/share/doc" which somehow gets correctly translated into the correct output directory... <xelxebar>Simply doing (mkdir-p "/share/doc") from within a build phase fails with "permission denied", since it tries to literally create /share/doc. <xelxebar>So, where is the magic translation happening? <rekado_>civodul: probably more than that because I also ran “guix gc” to delete disk images. <rekado_>civodul: do you know how I can tell what keeps a store item alive? <civodul>rekado_: there's no easy way to know <rekado_>“guix gc --referrers” returns nothing <civodul>but note that we're running with --gc-keep-outputs --gc-keep-derivations <rekado_>that’s a file from /gnu/big-stuff, which is added there after deleting the cuirass gc root. <rekado_>this happens for almost all *-installation items <civodul>what's that file, so i can have a look? <rekado_>it’s /gnu/store/5pspxldqih4rkhgsydjxwd7k22ki0gsq-installation <rekado_>I’m very worried about us running out of space in the next few days <rekado_>none of my past tricks seem to work anymore. <civodul>see: guix gc --referrers $(guix gc --derivers /gnu/store/5pspxldqih4rkhgsydjxwd7k22ki0gsq-installation) ***nagamalli is now known as nagamalli_
***nagamalli_ is now known as nagamalli
***nagamalli is now known as nagamalli_
***nagamalli_ is now known as nagamalli
<civodul>rekado_: look /var/guix/profiles/per-user/cuirass/cuirass/zz3qnyhp0127sy75bnc3jdlqyr5dk0bw-raid-root-os exists <rekado_>so… we should also delete the raid-root-os roots then <rekado_>I wonder if we could let Cuirass do this for us: put the gc roots for expensive stuff in a directory that we can empty at will <rekado_>then we don’t have to search by name <nagamalli>I have also tried to upgrade Evolution Data Server to 3.33.9 - THE <rekado_>I’ll add all *-os roots to the deletion cron job <civodul>rekado_: yes, that's the easiest way <civodul>otherwise i thought we could query the referrers <nagamalli>I have also tried to upgrade Evolution Data Server to 3.32.5, but build failed.please suggest <rekado_>nagamalli: why are you upgrading this? <rekado_>I wrote earlier that upgrading GNOME things piecemeal isn’t a good idea <rekado_>doing it right by upgrading all of GNOME together is difficult <xelxebar>Why is guix build --rounds=2 immediately returning successfully without building anything?? <rekado_>also: if the thing has already been built it won’t build it again <rekado_>only if it has been built zero times, --rounds has any effect <rekado_>to check a build use --check --no-grafts <rekado_>(because you don’t want to check the graft derivation but the actual build) <xelxebar>Okay. Is this still applicable if I'm just trying to sanity check my package? <xelxebar>Unless I'm misunderstanding something, that shouldn't pull in any grafts <cbaines>xelxebar, grafts are about what's referenced by the output generated by your package <cbaines>It'll be grafted if it references anything that's been replaced (or that's been grafted I think) <nagamalli>rekado_: Earlier I had asked here about the glib version...and i was suggested to update EDS <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 help-guix@gnu.org <rekado_>xelxebar: grafts are not very complicated. Your misunderstanding is in thinking that building a new package won’t use grafts. <rekado_>then your package will be built with references to the original openssl, followed by a graft that replaces the references to the old openssl with the replacement of openssl <xelxebar>Hrm. Naively, I'd have expected we could simply link against the new, grafted openssl <rekado_>xelxebar: then your package graph would have to reference the openssl replacement. <rekado_>but it doesn’t. It references just “openssl”. <xelxebar>For concreteness, what's the replacement look like? In principle, could it be something like libressl? <rekado_>you can, of course, use input transformations to recursively replace any openssl in the graph with its replacement <rekado_>it will be a patched version of openssl <xelxebar>Which is a new object in the store, right? <rekado_>the grafts mechanism operates under the assumption that the replacement is virtually identical to the thing it replaces. <rekado_>the patched version of openssl will be a package just like openssl; only difference is the application of a patch <rekado_>instead of rebuilding *every* package in the graph with that patched version we just recursively rewrite the hash in all packages <rekado_>this is generally much cheaper than rebuilding <xelxebar>So why doesn't a new package referencing "openssl" pick up the new graft? <xelxebar>Wait... Is this like grafts on top of an existing profile? <rekado_>let’s pay attention to words, please <rekado_>the variable name “openssl” names one exact package value . <rekado_>these inputs are specified by variable names that resolve to package values <rekado_>again, there is nothing ambiguous about what package value you get when you evaluate a variable name <rekado_>you’ll get one package value and that value isn’t going to change, grafts or not. <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 evolution-data-server@3.34.2, 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_>that package value will be almost the same as the value bound to the name “openssl”, except that it will have a patch applied <rekado_>then we add a field to “openssl” to indicate that “openssl/patched” is the replacement. <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. <xelxebar>Trying to check that I'm grokking your explanation. <xelxebar>rekado_: Thank you very much. You went way out of your way to spell this out very carefully for me. Much appreciated <rekado_>I’m glad my wall of words actually helped :) *civodul adds llvm@10, clang@10 <civodul>rekado_: i pushed a cosmetic change to the mcron job <rekado_>we usually undo the replacement on the core-updates branch and simply update the “openssl” package definition directly <civodul>should i add something that looks for referrers and deletes cuirass roots? <rekado_>civodul: that would be very welcomee <xelxebar>rekado_: The fact that you and many others readily offer up knowledge and friendly help is a big part of what makes this place feel so welcoming <xelxebar>Only been around here for a 2-3 weeks and this has been one of the better open-source community experiences I've had so far. <lprndn>is issues.guix.gnu.org down? I get 502 Bad gateway :/ <rekado_>woah: malloc(): unsorted double linked list corrupted <rekado_>(I’m guessing that this is a crash in Xapian) <rekado_>xelxebar: troubles with issues.guix.gnu.org should have ended <lprndn>rekado_: No problem. Just wanted to make sure the error was reported ;) <lprndn>hum font-gnu-freefont doesn't build on core-updates. At least for me. :/ <jboy>has anyone here ever used the uwsgi package from guix and successfully gotten it to load the python plugin? <janneke>i created a binary pack (-RR) with in it a script wrapped using "wrap-program", that seems to forget its exit status -- does that ring any bells? *janneke reads wrap-program and finds `wrap-script' -- that would be more suitable for sure <civodul>janneke: that doesn't ring a bell but it'd be worth stracing it! <rekado_>janneke: wrap-script has problems of its own; not sure if the reports are correct <civodul>janneke: check whether it happens in PRoot mode, or in user ns mode, or in "bare" mode <rekado_>janneke: wrap-script seems to do the wrong thing in some cases. IIRC it adds an argument when no arguments are given, or something like that. <janneke>civodul: ah, strace will give show me exit stati, probably *janneke is not such an experienced stracer <janneke>now that i recently learned strace can be asked not to abbreviate its logging, it has become much more useful <janneke>civodul: yes, i was vaguely thinking of those -- not sure how to test those "mode"s; other than building pack without, with -R, and with -RR <civodul>rekado_: i'll reconfigure from the same channel as the current generation, ok? <civodul>janneke: you can find out which mode is going to be used if you know (1) whether /gnu/store exists and (2) whether unprivileged user ns are supported <guix-ci>Problem: Too many processes on hydra-guix-127 Problem started at 11:50:47 on 2020.04.24 <janneke>civodul: ah, even a "-RR" pack/binary can run in different modes; good! that's very helpful to know <civodul>janneke: yup, it takes the "best" one: just run the thing if hey, it's actually in store, or try user namespaces, or use PRoot as a last resort <guix-ci>Resolved: Too many processes on hydra-guix-127 Problem has been resolved at 11:52:47 on 2020.04.24 <brendarn>guix pull: error: Git error: unexpected http status code: 504 <janneke>civodul: that sure explains why i was the worst person in our team to verify our binary packs <janneke>yes! (well, tbh i use "--relocatable --relocatable" because i really like long options) <civodul>brendarn: perhaps Savannah is overloaded a bit <janneke>they are somewhat big, but that's not a major problem right now <janneke>i saw efforts about that underway, we'll look at those later <civodul>janneke: i was asking because we didn't get bug reports or complaints or anything regarding -RR <civodul>rekado_: i've reconfigured & run cleanup-cuirass-roots <civodul>can you eventually tell me if you still stumble upon store items that remain live? <janneke>other than that: /very/ happy with it until now <civodul>hmm it's the outermost that returns 0 <janneke>someone's WAIT'ing for that? the processes surprise me a bit <civodul>does -e exit,execve tell you exactly which one is returning 0? <janneke>i see little difference, it still seems to be the last (i have no mental reference to compare it to) <civodul>could you maybe send the full log, with "strace -o log -f"? <janneke>yes; a guile script that i packaged in wrap-program -- could be pretty fu-bar'ed action from my side <rekado_>civodul: thanks, I’ll give it a try! <janneke>running `false' (non-wrapped) from a -RR pack'ed coreutils works fine <emys>So I created an environment using apache maven `guix environment --ad-hoc maven` <emys>was a bit surprised that this would pull in kafka as a dependency <emys>whats Guix' policy on dependencies, its not the first time that I have seen it pull in dependencies that I guess I could see them being pulled in in some way if optional dependenceis are enabled <civodul>janneke: silly unixry: (status:exit-val 256) => 1, but (exit 256) == (exit 0), because 256 & 0xff = 0 <str1ngs>hello civodul is it feasible to use GWL without wisp? <civodul>hi str1ngs! i'm not the right person :-), but i think so <str1ngs> possible to use GWL where I might have used ansible before? <str1ngs>I will do some hacking and figure this out :) <civodul>janneke: could you mail a rough description to bug-guix? <janneke>civodul: yes, i was working on a less-rough, runnable version <rekado_>GWL is meant for scientific workflows <civodul>rekado_: it's no longer possible to define a workflow in Scheme? <str1ngs>I see some scheme examples so it looks like I can use scheme. <rekado_>the docs just prefer to show Wisp examples <str1ngs>I think wisp is used here to be more user friendly. <rekado_>(because *potential* users don’t understand nuance and don’t read carefully, so I show what appeals to them by default.) <str1ngs>I like input and output model, reminds me of what a modern make would be. <ecbrown>rekado_: i just took a look at gwl. is this a "dataflow" type specification? in and out connectors, parallel execution perhaps <ecbrown>(i use knime a lot, for "connect the nodes" type work. would like to do that programmatically) *ecbrown thinks the answer is "yes" <ecbrown>yes, i just saw that and my jaw dropped. been looking for this very thing <ecbrown>i sometimes try to do this with makefiles <ecbrown>one thing i don't get is "complexity" -- does this allow e.g. to constrain the workflow? <rekado_>ecbrown: the complexity specification is used as a hint for a scheduler <rekado_>if you submit a GWL workflow to a Grid Engine cluster, for example, it will tell the Grid Engine scheduler to constrain memory and time etc <ecbrown>rekado_: sweet. one of my biggest problems is "hogs" that need to run quasi-sequentially, or at least less that all cpus <rekado_>unfortunately the GWL currently doesn’t have many execution backends <rekado_>it has a simple local execution backend and one for Grid Engine submission <rekado_>I wanted to add a DRMAA backend to replace the Grid Engine specific stuff <rekado_>and later add “cloud” submission via Guile-AWS <ecbrown>don't have a batch scheduler around anymore, so i look into Grid Engine at no loss <rekado_>it’s still in early development, but it seems to actually work already <rekado_>it compiles the AWS specs in JSON format to a Guile DSL. <rekado_>I’d like to enable people to build their environments with R 3.6, but AFAIK we can’t yet do transformations of build system inputs. <rekado_>the r-build-system allows me to override the R used to build a package, so it should be possible <rekado_>just not as convenient as just using the package transformation tools <str1ngs>thvk-ivgf: send to guix-patches. looks go tome. but others might have comments <ecbrown>rekado_: stringsAsFactors=FALSE by default. i wonder if there's breakage <xelxebar>Is there a nice, generic notation for denoting store paths? Ostensibly, it can reside somewhere else than /gnu/store, so I'd like to write something like $GNU_STORE/<hash>-foo/bar. <xelxebar>Also, is there a convention for denoting the <hash> part? I've noticed paths like /gnu/store/aaa…-bar here and there, but I have no idea how to type that. <Gamma02>Is there a way to create manual Guix iso ? <ecbrown>congratulations! now the nailbiting begins ;-) <xelxebar>Thanks! Curious what the turnover time is on average. <xelxebar>Daily guix pull has been introducing about ~10 new packages recently. That's a really decent throughput. Guix is crazy active! <str1ngs>my little arm machines can't handle it! lol <emys>on macos I referred to docbook xsl files via an abosulte path /usr/local/Cellar/docbook-xsl/1.79.2_1/docbook-xsl-ns/fo/docbook.xsl, how would I get that path on guix? ***amiloradovsky1 is now known as amiloradovsky
<civodul>looks like clang-tools-extra needs to be built as part of clang <rekado_>would be nice if “guix gc -D” would keep going if it couldn’t delete one of the many files that were given as arguments <jonsger>rekado_: it looks like the search at issues.g.g.o has some regression <rekado_>I search for “emacs-exwm-next” and it finds anything but emacs-exwm-next. <civodul>rekado_: were you able to GC more stuff? <rekado_>civodul: yes, a little bit here and there <zalox>Hi, how come I can't open files with nautilus? I'm pretty sure I've got the xdg_dirs correctly. <roelj>civodul: Is it possible to run the hpcguix-web daemon with a custom commit ID instead of the latest? <rekado_>roelj: you’d have to specify channels <mbakke>emacs-guix fails to build with Guile 3.0 because (@ (guix scripts package) search-path-environment-variables) is not exported [emacs-guix uses @@ to get it] <mbakke>does it make sense to export it, or perhaps it is better suited elsewhere? <roelj>rekado_: I guess I should do that in the configuration file that I pass to "run"? Do you have an example of this? <civodul>roelj: <hpcweb-configuration> has a 'channels' field :-) <rekado_>had to use my newly aqcuired guile-xapian foo <rekado_>results are limited to 100 right now and they are sorted the wrong way… but I leave the rest as an exercise for new contributors ;) <civodul>newcomers never know what to hack on ;-) <civodul>i really don't get texlive: i'm trying to package csquotes, but i can't find it in the svn repo <roelj>civodul, rekado_: Thanks! Should've read the source code better.. :) <civodul>"guix import texlive csquotes" has svn fail without a message <rekado_>texlive.tlpdb says that the files are in texmf-dist/tex/latex/csquotes/ <rekado_>even when it works it doesn’t produce usable code <rekado_>part of the reason is that texlive source files are littered across the SVN repo <rekado_>so the naive approach of just fetching one directory doesn’t cut it. <rekado_>hence the changes to fetch a subset from SVN based on a list of files. <rekado_>the importer should read the tlpdb to figure out what files to fetch <civodul>ok, this is what Pierre & you discussed before, right? <rekado_>it also uses texlive-ref from (guix build-system texlive) which assumes that all files are found under “source/” in the SVN repo <rekado_>but as you can see in the csquotes record in tlpdb the files for this package are under tex/, not source/ <rekado_>yes, we discussed this before. My position is that the importer is terrible, but that we also can’t exclusively trust the tlpdb <rekado_>because texlive doesn’t really distinguish between sources and generated files <rekado_>it will declare some files as “sources”, but they may not be sufficient to produce all output files <rekado_>it lists “runfiles”, which allows us to check if we’ve got all expected files, but we don’t know which of them are generated and which are to be copied. <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. *rekado_ packages texlive-csquotes <emys>roptat, from the #guix channel logs it seems you have been working on a maven-build-system, is that still ongoing? <rekado_>civodul: commit a1d369f139 adds texlive-csquotes ***rekado_ is now known as rekado
<elvirolo>Does anyone know if it is possible to install Guixsd on a ZFS root? <civodul>bah, i upgraded Biber because on master it fails to build, but now i get: "Error: Found biblatex control file version 3.4, expected version 3.7." <elvirolo>civodul: That's what I thought. Thank you :) <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? <rekado>is this the sound of you rolling up your sleeves…? <civodul>rekado: rather the sound of me backing up to a more reasonable solution :-) <jlicht>hey guix! Staying safe I hope :-) <jonsger>jlicht: and hacking on Guix, sure :) <jlicht>it keeps you off the streets, which is very much a good thing nowadays *rekado applies R package submissions ***wxie1 is now known as wxie
<cbaines>I was looking at your npm importer work recently jlicht :) <cbaines>jlicht, I'm optimistic that something can be worked out with the Javascript stuff <jlicht>cbaines: you've clearly not had a look at my work on CoffeeScript then ;-) <civodul>rekado: guess what: our current Biber *also* fails, this time with: Error: Found biblatex control file version 3.4, expected version 3.5. <jlicht>civodul: that might be my fault. woops! <cbaines>jlicht, I think I remember seeing something about Coffeescript being hard to bootstrap. <jlicht>cbaines: all of the X-to-JS languages seem to be. I'm also a bit more optimistic now than say 2 years ago, as there are starting to be more and more alternative implementations for most <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" <cbaines>jlicht, Yeah, I haven't got that far yet. Like you I think, I've been looking at trying to package some of the build tools like gulp <efraim>I don't know a lot about using and working with ZFS, I only added it because there was interest and I wanted to prove it was legal to do so :) <efraim>I should check if it was on the wishlist <civodul>jlicht: so i'll downgrade biber until i have something that works, fine with you? <civodul>AIUI, the current Biber has never been usable anyway, right? <jlicht>civodul: not for working with the rest of texlive as packaged on guix, no <civodul>"texdoc biblatex" gives me a compat matrix that suggests that even 2.7 didn't work <jlicht>texlive-related software feels extraterrestrial at times <buffet>hey, is there something like nix's stdenv? includes stuff like make, gcc <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 <buffet>ie not bound to a specific package <janneke>civodul: ooh, and a fix, beautiful! \o/ <mbakke>buffet: right, I don't think there is such a feature <rekado>it would be nice to do this with build systems as inputs <civodul>mbakke: it's correct, but now we'll rebuild guix-daemon.1 very often <civodul>the previous situation was ok: it first tries and fails to build guix-daemon.1, and retries later once guix-daemon has been built <civodul>buffet: "guix environment sed" (for instance) corresponds to what you have in mind <buffet>i agree it would be nice with buildsystems though <jonsger>mbakke: I reconfigured my Guix System in QEMU to core-updates, now the font is completly broken <mbakke>civodul: right, I noticed after running 'make update-guix-package' that guix-daemon.1 was created during the 'check' phase, so maybe the previous situation was okay <mbakke>I researched this patch to address a scary waring during the build phase <mbakke>let's revert it if it becomes cumbersome :-) <mbakke>for now I'm making a new Guix snapshot with this patch <cbaines>If you're using Gnome jonsger, maybe go in to the Tweak Tool and see what it says about fonts <jonsger>civodul: I guess statefull, installed via hand with iso. I have run master before just fine, pulling and reconfiguring from core-updates leads to this situation <civodul>jonsger: could you check if the problem occurs in "guix system vm"? <civodul>if not, then you can start "rm -rf" stateful thingies from your disk <cbaines>This is really good testing to do though jonsger as these will be the problems existing users hit when they update <jonsger>cbaines: I just hoped to get a fix from core-updates :P <jonsger>its only in X. in tty2 everything is fine <mbakke>jonsger: what fonts do you have installed? *jonsger goes afk for a while ***leoprikler_ is now known as leoprikler
<lispmacs[work]>is there a special flag you have to pass to gcc to have it hardcode the path to a library dependency in the executable? <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. <ecbrown>hello, having a hard time with guile-fibers which i need for cuirass. no substitute is available--wondering if anyone knows what's up <cbaines>ecbrown, I think there's an issue in Guile that means it often fails to build. It might eventually build successfully, so I'd perhaps try a few more times. <ecbrown>well i have gotten it to compile after repeated attempts, but then cuirass dies at runtime, errors about fibers <Bronzu>Hello, I'm having issues installing Guix (The OS) due to my computer overheating. The fan simply isn't spinning at optimal speeds... <lispmacs[work]>I have a long boot up delay where it waits like 20 seconds before reporting it was waiting for daemon to provide a return value. It just just after NTP service is started <lispmacs[work]>would there be something I could tweak for that in my old config.scm? <Bronzu>And echoing level 7 to /proc/acpi/ibm/fan doesn't work :/ <mbakke>jonsger: you probably just need to install a font then <mbakke>perhaps something used to propagate a font, dunno <cbaines>ecbrown, that doesn't look like a fibers issue to me. More likely an issue with what it's trying to evaluate. <cbaines>What are you trying to do with Cuirass? <rekado>lispmacs[work]: re ldd: try setting the RUNPATH when linking <ecbrown>cbaines: run cuirass as in documentation <ecbrown>i.e. the cuirass+cuirass-web service <cbaines>What specifications have you given it? <ecbrown>i'm trying to give it ~/src/guix/build-aux/cuirass/gnu-system.scm <cbaines>Ah, I see, it's in the paste you made: --specifications=build-aux/gnu-system.scm <cbaines>I think your missing the /cuirass/ bit in the middle, maybe try --specifications=build-aux/cuirass/gnu-system.scm <cbaines>Out of interest, what are you hoping to do with cuirass? <ecbrown>have my own channel build continuoulsy <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 <Bronzu>Would anyone know how I could control fan speed doing Guix' (the OS) installation? My poor T400 overheats during the installation process... <Bronzu>In my Parabola install I had thinkfan, but It seems it won't run until installation finishes. <thvk-ivgf>Bronzu: do you have any other computers? If so, see manual, `guix pack`. (i'm not an developer, btw) <cbaines>Bronzu, did you load the thinkpad_acpi linux module with the right fan_control=1 option? <Bronzu>but when i tried to test run thinkfan it said the package is not installed <Bronzu>shouldn't there be like a kernel level tool allowing me to directly access the fan and set it to max speed? <Bronzu>something embedded into the kernel of course *ecbrown chuckles at `-RR' really relocatable <lfam>Bronzu: Your fan should be managed automatically by the hardware. Considering the age of the computer, have you ever cleaned the fan? <Bronzu>yes I did, when I librebooted the thing 2 months ago <Bronzu>right now im reading documentation on thinkpad_acpi bit i cant get any leads... <Bronzu>I think I know how I can sort out the overheating issue <pkill9>is anyone else's teeworlds failing to load all the sound files? <pkill9>i bet it's due to recent update of sdl, i'll test with guix time-machine <g_bor[m]>The Outreachy intern accouncement deadline has been modified to May 4th. <raghavgururajan>Bronzu You can try appending `guix system init` command with `--cores=1`. <thvk-ivgf>Is that even safe to put electronics to the frigde, btw? Anyway. <g_bor[m]>The Organizers sent a communication to the mentor's list, that they move the intern announcements, so that they are in sync with GSoC. <g_bor[m]>I've sent a letter a to the ML already, detailing the situation. <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? <janneke>i think that's what danny suggested too <Bronzu>I found out how to make thinkfan work! <Bronzu>I think I'm blind because after you install a package, the isntaller tells you how to activate it. <raghavgururajan>janneke Hmm. I see the point now. Also, util-linux is better maintained than eject. So, I'll close #40752. <raghavgururajan>Bronzu You can try appending `guix system init` command with `--cores=1`. <janneke>raghavgururajan: thank you; sorry for all the trouble <TZander>I'm testing why the 'check' phase fails. So I installed with the -K option. Then go into the /tmp/guix* dir and source the environment there. <TZander>Where in the log of the build I see 3 lines printed of a test and then nothing (implicating it crashed) <TZander>in my shell it gives a very different output, an error and a core-dumped. <TZander>Anyone know if there is anything else I can do to simulate the environment of the build? <apteryx>hmm, emacs-guix seems broken: emacs-guix/actions.scm:118:8: In procedure process-package-actions: Unrecognized keyword: #:use-substitutes? <apteryx>(attempting to install something from the M-x guix-all-packages buffer) <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? <rekado>can you see what happened there? <civodul>apteryx: specifically, could it be build-and-use-profile? (commit 65ffb9388c1c3d870cb07e4cb3ef12c9ac06a161) <TZander>rekado: the tests are running and showing 3 or 4 lines of output in the build-log. And then the next starts. No mention of why the "I'm finished" line isn't printed. So I assume its crashed. <TZander>When I try to reproduce I get a completely different result, which indeed says core-dumped, but I don't really care about that failure. <TZander>I'm pretty sure that was due to an abort() <rekado>have you tried disabling parallel builds / tests? <TZander>still, would love an answer to my initial question <TZander>I don't like guessing and building with wild guesses ;) <civodul>no need to guess, check the manual & code :-) <TZander>well, its either expected or there is a bug. Why is the environment setup in /tmp/guix-* different from the actual building setup? <jonsger>mbakke: I added now font-dejavu and font-ubuntu, doesnt help *rekado just submitted a request for doubling storage on ci.guix.gnu.org <rekado>yes. Can’t promise anything, of course, but I think we have a good chance. <rekado>yeah, I’m working on freeing up stuff <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. <rekado>with the Guile daemon rewrite we will hopefully be able to recreate the build environment more easily <rekado>reepca: do you think it would be feasible to replace *parts* of the C++ daemon already? Letting it spawn Guile scripts for certain parts of the work? <TZander>rekado: to be clear, I doubt any of those differences are why this test app can't find its plugin while it did in the container. Any rewrite would not fix that. <rekado>the daemon currently is not accessible from Guile <TZander>rekado: I'm not debugging from guile, I'm debugging from a shell <rekado>so we can’t say “guix environment --build-container foo” <rekado>I can’t make myself understood, so I’ll stop trying. Never mind. <TZander>so, you think that I can start a debug session using “guix environment --build-container foo” ? <TZander>either way, thanks for the help. The package isn't used by anyone so I'm spending limited time on it. <lfam>Is anybody using Audacity from Guix on a foreign distro? Are you able to use with Pulseaudio? <lfam>This works for me when using Audacity from Debian but not from Guix <lfam>I think it's missing something related to alsa-plugins but sure how to resolve it <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) <civodul>though what you describe would be nice <civodul>in particular, we could use the same code for "guix environment" and for the daemon <civodul>thus there wouldn't be any discrepancies <mbakke>jonsger: and did you run fc-cache -rv after installing the fonts? <apteryx>are there emacs-helm users around here? <apteryx>I'm trying the package for the first time, and I can't get the 'recursively looking for files' feature (M-x helm-find-files -> then type '..some-file-name') to work. <emys>is send-email not distributed with Guix's git? <jackhill>emys: it's in a different output. It can be installed by `guix install git:send-email` for example <emys>jackhill, thanks, I guess now I understand what outputs are <TZander>anyone with push rights seeking an easy patch ? 40830 ;) <raghavgururajan>lfam Forgot to mention that I wrote the explanation as commit message. <TZander>civodul: here is a reason when those build-failure debug instructions don't work: a package var using 'cmake-build-system' would not get any cmake in its environment. <civodul>TZander: i don't think that's the case; for example, clang uses cmake-build-system, and "guix environment -C clang -- cmake --version" works <lfam>I wonder why ci.guix.gnu.org has not built ncmpcpp since February <TZander>civodul: hmm, I did speak too hasty. I can't get it to work, but cmake is indeed in the path