IRC channel logs
2023-08-31.log
back to list of logs
<unmatched-paren>so, with cross-libc, does that package have to be built for the host? <vagrantc>in case of memory shortages ... --cores= some smaller number of cores can sometimes help :) <vagrantc>guix time-machine does not appear to be caching the results very well... or does it still need to "Computing guix derivation for ..." <apteryx>seems fetching substitutes from berlin at this time is super slow <xelxebar>attila_lendvai: pk stands for "peek", IIRC. <vagrantc>when one process in the build can use 1.3GB of ram ... do not use all four cores on a 4GB of ram system :) <attila_lendvai>xelxebar, another one of those pointless abbreviations that plagues parts of IT... 'peek' i would have remembered. pk? less so. (thanks!) <apteryx>vagrantc: it'd be nice to have a property like: peek-memory-per-core in the package properties <apteryx>then the number of core could be scaled automatically <vagrantc>that would be nice ... but probably hard to get right <apteryx>right. we'd need to instrument builds to record such information automatically <apteryx>are powerpc64le shared libraries ending with .a, or is aalib just strange? <apteryx>it builds a .so on x86_64 and a .a on powerpc64le <apteryx>which is probably what breaks the link of gst-plugins-good <mirai>.a files are archives right? (using ar) <mirai>sounds strange to me that the file extension would change depending on the architecture even though its still the same platform <mirai>fwiw it looks like a bug to me though I never played with ppc <mirai>I wonder how feasible it is to grab a (obviously used) PS3 and repurpose it either via OtherOS support or possibly through some homebrew hoops <apteryx>mirai: yes, archives (also called static libraries) <apteryx>PotentialUser-32: fwiw -> for what it's worth, ppc -> powerpc (some CPU arch) <apteryx>mirai: I had my eyes on a raptor computing systems' blackbird but it'll have to wait (it'd cost me more than 4000 $) <apteryx>I'd expect PS3 is powerpc and not powerpc64le <mirai>wiki page says its 64bit so I assume it would be powerpc64le <mirai>unless there's a powerpc 64 bit that means an entirely different thing <mirai>I've heard of the raptor systems as well <apteryx>I think the aalib problem on ppc64le has to do with the configure script or libtool: checking dynamic linker characteristics... no \n checking if libtool supports shared libraries... no \n checking whether to build shared libraries... no \n checking whether to build static libraries... yes <mirai>but oh my… its hard to justify that price tag to just fool around with a different piece of silicon (which I don't think would translate in any improved productivity, in fact I'm inclined to think that the opposite might be likely 😅 since broken packages) <mirai>apteryx: a very dead package from the looks of it <apteryx>yes the initial "getting comfortable" phase would involve patching and fixing a few packages <apteryx>but a lot of work has already been done <apteryx>Power9 seems very powerful, could probably boost productivety at least compared to my old desktop <mirai>get yourself 8 (or more?) intel nucs for the same price, use one as the desktop and the remainder for guix offloading <mirai>at least 700% productivity increase vs single intel nuc <mirai>multiply by <arbitrary-factor> to get % increase vs <your-current-setup> <mirai>how can power9 recover from this? 😂 <apteryx>nah, I'd like a Power9 with 32 threads and 128 GiB of RAM for builds ;-) <mirai>oh yeah, forgot about the ram part <mirai>unrelated but I managed to OOM a 64GB RAM system when test-building (max 3 parallel builds) for the XML&Docbook followup series <mirai>idk if it was cups or rust that required outrageous amounts of mem <apteryx>aalib fixed by rebootstrapping build scripts <mirai>but there sure are some packages that are very memory hungry <apteryx>mirai: all the C++ stuff is very memory intensive <apteryx>the browsers such as webkitgtk, chromium and icecat are among the worst offenders <makads>What architecture does the Power9 use ？ <apteryx>Its own (Power9, which is a RISC); it's a totally free specification managed by the OpenPOWER foundation <apteryx>so anyone in theory can produce a compatible silicon <makads>What architecture does the Power9 CPU use <makads>That sounds pretty free, and I love it <apteryx>is edk2-tools supposed to be buildable on anything else than x86_64? <makads>If I want to buy a Power9 processor, where can I buy it？ <makads>It seems that I can't afford it for this price :') <dan>So guys, given the nature of Guix if I wanna build a "sway devel" linked against bleeding edge wlroots and mesa , all I have to do is create a channel on my github with modified papckages, and the system will naturally handle the proper libs, no ? <dan>meaning I still get to use "sway" linked against tested libs and sway-devel linked against what i want <unwox>dan: probably "guix build --with-branch=wlroots=master sway" will do the trick <dan>nice. Thank you. ill try today ! Even simpler than I expected <unwox>and you don't really have to push the channel to github, you can subscribe to it locally <dan>Another good to know thing ! <dan>If you have multiple channels installed, you get different stores for each channel ? l <unwox>no, there is only one store for each guix daemon instance afaik <makads>Is sway available on any desktop, like GNOME or Xfce? <nckx>You can run most GNOME or XFCE applications under Sway and they'll generally work. Sometimes they'll look silly, or a menu bar will be missing until you do something to the window. <bumble>I tried to submit my first ever patch today and made a mistake. I hope my patch will be acknowledged soon :) so that I can finish everything <dan>multimonitor setups are great with sway <dan>tring to get different monitors with different DPI to look the same in X is almost doomed <dan>and slowly, more and more software works ok in Wayland <janneke>finish everything, that has an ominous ring to it... <nckx>A set of protocols that aim to replace X11, but unlike X11 there's no 'Wayland server', but things called 'compositors' like Sway that implement the protocols. They are like combination servers + window managers, roughly. <nckx>You do not need to know this to use it. <nckx>bumble: What kind of mistake, what kind of ack! <bumble>I left a commented-out line of code in a new font package definition I added <bumble>I amended the commit locally but since I'm not achknowledged yet my patch doesn't appear in the issues list <nckx>There is no patch pending human moderation so like all of us you are lost in the machine. Only time will tell. <dan>Arcan guys is pretty smart <bumble>maybe I should try again by sending the patch _again_ but I should send the amended version next? <nckx>I sympathise. Rather than merely touching the grass, try rubbing it over your entire body and try to forget computer. <nckx>bumble: Uh, I'd wait at least a bit. When did you send the first copy? <bumble>jgart and others in the matrix group helped me to send the patch <unmatched-paren>ACTION still doesn't really get why TARGET-INPUTS exists in <BAG>... <iyzsong>bumble: i think you can forget the old and just send a new patch, also one way to know if a mail sent successful is CC to yourself <unmatched-paren>> cross-gcc is a native package, so it would end up using a native version of cross-libc <unmatched-paren>cross-libc isn't as far as I can see included as a native input in gnu-build-system's lower <unmatched-paren>even if it did, surely that doesn't mean it'd 'end up using it'? it's not propagated, after all. <bumble>iyzsong: earlier I sent my patch this way `git send-email --to="guix-patches@gnu.org" HEAD^` do you think it would be "safer", this time, if I tried creating an issue first, then sent the patch to the issue link? <bumble>or should I send the patch using the same git send-email to guix-patches@gnu.org? <unmatched-paren>bumble: btw it's better to use `git send-email -1` than `git send-email ^HEAD` <bumble>I did get a cc'd copy of the patch that was sent earlier today <unmatched-paren>you should also do `--base=master` which makes it easier to see whether the commit is autdated <iyzsong>okay, that's fine. your smtp server is working if you got the cc'd mail. <bumble>the command: `git send-email --base=master --to="guix-patches@gnu.org" -1` <unmatched-paren>i still don't see how that means cross-gcc will use cross-libc when compiling <unmatched-paren>i still don't see how that means cross-gcc will use cross-libc when compiling <iyzsong>unmatched-paren: i see 'cross-libc' was pulled-in by standard-cross-packages <unmatched-paren>target-inputs is like build-inputs (built for host) except regular search paths rather than native are applied to it <nckx>bumble: <jgart and others> Nice. <Wurt>Could someone check my patch (https://issues.guix.gnu.org/65538)? I think that I sent it wrong, it is the second version of another patch, but I did not reply to the original thread... sorry. I sent it 6 days ago. What should I do? <iyzsong>Wurt: you can close the old one, by send a mail to xxx-done@debbugs.gnu.org <bienjensu>Joined to ask which package `file` was in, had tried `binutils` &c but not just `file` itself.. <bumble>nckx: respectfully, would you be able to tell me if my patch "made it" to moderation? <bumble>its past midnight here in California it will help me sleep better :) <iyzsong>bumble: according to my friends, the first mail can be delayed for more than 1 week, better don't let that bother you.. <bumble>ah okay I have no idea how this works <bumble>if you think all is normal here I'll rest easy and wait <bumble>nckx: nevermind me all seems to be well. thank you and see you later <xelxebar>unmatched-paren: I'm jumping in the middle of the discussion here so not exactly sure what the topic is. However, when building compilers, you generally need to think about *three* different levels: 1) the build platform, i.e. the one on which you're compiling the compiler, 2) the host platform, i.e. the machine on which the built compiler will run, and 3) the target platform, i.e. the platform for <xelxebar>which the built compiler generates code. <bienjensu>How would I include a different system's version of openal within a container? That is, without changing the system of the entire container. <xelxebar>bienjensu: --with-input? guix shell also accepts pretty much all the args that guix build offers. <bienjensu>xelxebar: I'm not sure that package specifications allow you to specify the architecture of a package. The nasty way to do it using non-guix-shell utils is something like 'guix package -i `guix build -s [system] openal`'. This errors on guix shell, however, as it doesn't accept store paths <bienjensu>I can see why it shouldn't work like this, but it is a little frustrating not just being able to `guix shell openal.i686-linux` <aldum>Rovanion: 401 Syntax: EHLO hostname <xelxebar>bienjensu: guix shell takes the --sytem argument just fine. Can't really spec that just for a single package, AFAIU, though. <xelxebar>Could probably get some dirty guile expression to do it, though. <bienjensu>nested guix-shell'ing doesn't even work because the root container is in FHS emulation mode and a subshell doesn't link the new libs to /lib <gabber`>i set my PS1 env var in my home-bash-service-type's environment-variables field but it remains set to the value set in /etc/bashrc. it works (as expected) when i add a file-like to the bashrc clause. is that intended and to be expected? <MatoHota-work2>I've done a fresh install off guix on a Rocky 8 linux without too much problems (wget to be replaced by curl...) <MatoHota-work2>but when I try to install any package I get the following error : "In procedure verify: gcrypt: Not supported" <Rovanion>Wild guess: Perhaps installing libgcrypt with yum would help? <MatoHota-work2>I'd like to but no repo available on the machine, thanks for the clue. I will compare my running system with this one <apteryx>rekado: it's strange that it doesn't report it as a dependency failure <apteryx>cuirass then never reattempts the same derivation <apteryx>it seems cancelling builds is a no no in Cuirass at this point in time <apteryx>unless for old irrevelant branches/versions, perhaps, but even then it's risky <apteryx>lieserl and kreuzberg also aren't building much, so is sjd-p9 (0 build in last 24 hours) <andreas-e>At the time being, cuirass has too severe problems in the way it works. Maybe this is not too difficult to fix, but someone would have to do it... <andreas-e>And this with a fraction of the build power for x86. <andreas-e>I wonder, for instance, if we should not attach one of the powerpc machines to QA rather than CI. <andreas-e>Looking at https://ci.guix.gnu.org/workers most of the aarch64 machines have dropped out of the build farm actually: overdrive1, dover and lieserl; kreuzberg needed repair work and might not be up again yet. <apteryx>I don`t think the picture is as bad as it looks for Cuirass; most problems seems to have to do with it fetching substitutes from nginx <-> guix publish <apteryx>causing spurious build "failures" and making the weather look bad <apteryx>as for aarch64, QA has more machines, I think <andreas-e>apteryx: 3 in QA (which also do armhf), 5 in CI (plus kreuzberg) <andreas-e>I really think the main problem is not being able to restart builds, and them not being executed in topological order. <andreas-e>Plus the bug about missing derivations, indeed. Three things to fix! <apteryx>maybe we should do a cuirass bug fix spree! <apteryx>do we have issues reported to all of these? <andreas-e>Without any reaction so far... I am afraid we may have only two persons competent for working on it. <andreas-e>But this is mainly a guess. We need documentation! <andreas-e>I just did a wc on this ci projects. 12000 lines in cuirass, 14000 in build coordinator, 22000 in data service. This is frightening! <cbaines>there are design things that the build coordinator does differently to Cuirass, like problems substituting derivations being tracked as setup failures rather than build failures, and the ability to build derivations more than once <cbaines>I think we're getting there with canceling builds as well, as QA does this regularly now <aitzkora>Hi, somebody had this kind of error trying to build a recipe : guix build: error: corrupt input while restoring archive from #<closed: file ...> <cbaines>on connecting more powerpc64 machines to the bordeaux build farm, assuming they're always on, that would really help as then we'd be able to start QA testing with powerpc64le-linux <andreas-e>cbaines, apteryx: From what I have heard, I am indeed more convinced by the QA design decisions. But tens of thousands of lines of Guile code are too frightening to start looking at them... <andreas-e>There are two powerpc machines at CI, one of them could be "moved", I would say. None of them are physically in berlin. <apteryx>aitzkora: I think these are network related crashes... already reported on the issue tracker <andreas-e>apteryx: It would be nice to get the current core-updates branch out of the way. I have new gmp and mpfr versions in the wip-gmp branch. And right now I am trying to add the coreutils version released two days ago. <cbaines>andreas-e, I have been slowly working on reducing the amount of code, but it's quite a slow job to push things upstream or pull bits out in to other libraries <andreas-e>cbaines: I am mystified by how you were able to write so much code :) <cbaines>there's still code in the data service that was copied from Mumi <cbaines>e.g. sxml->html should live somewhere else and be shared <andreas-e>Is this not already part of some library? It is needed by haunt if I remember well. <andreas-e>Well, haunt defines a function with the same name. <cbaines>I don't know, but if you find a place, please let me know! <dthompson>I think I wrote one for haunt that handles some of the special html tags <andreas-e>In haunt, html.scm. But the full module has only 130 lines. <dthompson>it's mostly the usual sxml->xml process but some html tags aren't self-closing if they don't have any child nodes <mirai>why not simply output XHTML5? :-) <mirai>you get to use modern HTML and its valid XML <andreas-e>dthompson: I am surprised you jumped out of them so quickly. Have you put an alarm on the word "haunt"? <dthompson>andreas-e: just happened to be looking at the right time... I usually miss this stuff <rekado>andreas-e: I don’t know anything about any repairs pending for the three aarch64 systems that I maintain <andreas-e>rekado: Okay, then kreuzberg should work, but I think I have not seen it for a while. <andreas-e>I have just started the cuirass-remote-worker on kreuzberg. <andreas-e>Hopefully that was it, it is building things now. <andreas-e>overdrive1, dover and lieserl have apparently disappeared from the wireguard network. cbaines, roptat? <andreas-e>And I have restarted the remote worker on sjd9. <andreas-e>That reminds me, cbaines: The powerpc do not run Guix system. So one would need to launch build clients via systemd if they were to be moved. <cbaines>andreas-e, that's fine, the machine connected to bordeaux doesn't use Guix either (unfortuantely) <andreas-e>cbaines: For the patches in QA, I see messaged "Yet to process revision". Is this done at full power, or only when there are not enough build jobs to keep the machines busy? <andreas-e>Actually, the aarch64 machines are far from busy. <cbaines>it's done as fast as possible, but beid (the machine that data.qa.guix.gnu.org) is low on resources, and the software could do with improving as well <andreas-e>cbaines: Okay! So far it does not seem to be the bottleneck yet. <andreas-e>janneke: The update to coreutils@9.4 makes coreutils-mesboot-9.4 fail with this message: <andreas-e>configure: error: could not enable timestamps after mid-January 2038. <andreas-e>This package recommends support for these later <andreas-e>timestamps. However, to proceed with signed 32-bit <andreas-e>time_t even though it will fail then, configure with <andreas-e>Already in the configure phase already. It looks like we need the additional sign bit 15 years from now. Maybe it would be okay to just use this configure flag? <janneke>i hope that using '--disable-year2038' would be ok for now <andreas-e>janneke: I do not understand the problem. There is already this configure flag in coreutils when target-64bit? is false. Is this not inherited by coreutils-mesboot? <janneke>yeah, at first glance configure stage with it's flags should be inherited <andreas-e>Hm, what is really weird is that I am in 64bits! <andreas-e>sneek: later tell ngz: texlive-team has been built successfully on QA, I let you the pleasure to merge and delete the branch. Congratulations! <RavenJoad>Why does cuirass's evaluation of a specification's channels take so long? I have a spec for building an empty common lisp project, and evaluation has not finished in >10 minutes. <janneke>oh wait, could be that coreutils-mesboot is built in 64bit <janneke>yeah, on 64bit, target is 64bit even if the lower packages in the mes boot sequence are built for 32bit <apteryx>what do we do with packages supporting only newer x86_64 instructions such as avx2? <apteryx>RavenJoad: it has to build Guix first <andreas-e>janneke: So do I just unconditionally add this configure flag to coreutils-mesboot? Where exactly? It is strange that the problem occurs only now while the configure flag was already added before. <janneke>andreas-e: yes, that's strange -- could it be that the check has changed? <andreas-e>janneke: It is possible that it was a warning and has become an error. But I am still surprised the flag would be added for a non-error. <janneke>it wouldn't hurt to try, but yeah, it's possible that adding the flag won't help... <RavenJoad>Ahh. Then does it make sense to change the fetch interval to something higher? I had it set to fetch sources every 3 minutes. Does that just overwhelm Cuirass with tasks? (I also get OOM messages). <apteryx>I think the build farms use 15 minutes, that is, derivations group all the commits in that time window <andreas-e>janneke: Could you tell me how to add it without overwriting the complete "arguments" field? <apteryx>and IIRC it often takes 30 minutes or more for an evaluation, so if master is busy it could accumulate a backlog <janneke>andreas-e: the release notes for 9.3 has: <janneke>+ Coreutils programs no longer fail for timestamps past the year 2038 <janneke>+ on obsolete configurations with 32-bit signed time_t, because the <janneke>+ build procedure now rejects these configurations. <janneke>andreas-e: look at gnu-make-mesboot0, e.g, do something like <janneke> ,@(substitute-keyword-arguments (package-arguments coreutils) <janneke> ((#:configure-flags flags ''("--disable-year2038)) ...)) <RavenJoad>apteryx: Since this is for a CI server for my personal projects, it does not have a huge number of jobs/builds (right now each project has just 1 build job). So 15 minutes makes sense as a fetch interval? <apteryx>do we have a way to check if a x86-64 target supports avx2 at build time? <andreas-e>apteryx: This does not make sense. I think there are x86_64 machines with or without avx2. <janneke>andreas-e: err, i meant, look at eg gnu-make-boot0 <apteryx>andreas-e: it means we can offer the package, but not use it anywhere, else it could break usages on older x86_64 CPUs <apteryx>it at least breaks the test suite of gst-plugins-bad on my Core 2 Duo <RavenJoad>apteryx: Would it make sense to add that to the interval field for the cuirass-configuration documentation? The default value is just 60 seconds. Saying something like "Cuirass has to build Guix before handling the build jobs, which can take several minutes. Consider setting this to <insert-threshold> minutes?" <andreas-e>apteryx: Yes, we should not use it as input to anything else then. And users will be confused if they install it on too old a machine. <bumble>In the process of trying to submit a patch and have made a mess (I'm sorry). First, I sent two patches because of worry when the first patch did not appear. This morning both patches appeared and I sent a "close" email to one of them which never appeared in the issue page, in the mean time someone else closed the remaining issue that I did not close... <apteryx>RavenJoad: if that is confirmed, yes <apteryx>it could be that if the commit only touches one area of Guix, rebuilding Guix could be cheap, but I doubt it can really be that cheap at the moment <apteryx>perhaps what you could do is check in top what is going on on the build machine <bumble>somehow when I encounter every possible mishap... <mirai>bumble: it can be reopened if needed so I wouldn't worry much <RavenJoad>I will submit a patch about the documentation, but I imagine building Guix is eating up all the time, since I am not actively working on the projects right now. <bumble>mirai: do you know why my emails don't appear at debbugs.gnu.org? is there a long delay usually, or is there something I have done wrong? <andreas-e>janneke: I do not manage... I get "source expression failed to match any pattern". If you could try and send me the right patch by email, I would be much obliged. <unmatched-paren>xelxebar: i get that, what I'm trying to understand is the `<bag>` record that packages compile to :) <andreas-e>It needs to take everything from the pkg variable from which it inherits, and just add this one configure flag. <mirai>bumble: perhaps you used the wrong address? or it could just be debbugs moderation <unmatched-paren>xelxebar: specifically: why is cross-libc put in the TARGET-INPUTS section, which is like a hybrid of BUILD-INPUTS and HOST-INPUTS? <RavenJoad>Does guix count deleted store items correctly? My last guix gc collected 240ish GiB on a 256GiB disk, where only 95GiB is used now. Is it double-counting hard links? <mirai>apteryx: is this a library or a standard application? <RavenJoad>unmatched-paren: You just mentioned the <bag> record. Since you wrote the Gexp posts, were you planning on doing a bag post too? <mirai>hmmm… if this is within the context of GST, I guess it would be fine as a package by itself (not a part of any of the big gst-* plugin bundles) <mirai>but the ffmpeg case is tricky since it has to be present at ffmpeg compile time <ulfvonbelow>I'm trying to do some rather in-depth package transformations in my manifest, and finding that it's causing a lot of breakage. Namely, when I try to transform all the way down to (gnu packages commencement)-level packages, I get errors about allowed references, for example in glibc-final. It seems that package-mapping doesn't make an effort to recurse into the package arguments. Can anything be done about that? <mirai>apteryx: I was thinking on doing something somewhat related on that matter, this is the plan I've come up with though I haven't tried it yet <andreas-e>RavenJoad: I think it counts hard links multiple times when determining how much to free, so in reality it frees less. <mirai>perhaps you might find some value in it? (i.e. build variants of ffmpeg and use an interposer that is responsible for calling them?) <mirai>no idea what will happen with the libav** libraries tho <mirai>or simply provide ffmpeg and ffmpeg-avx2, where the avx2 variant is inherited from ffmpeg with appended inputs, etc. <andreas-e>mirai: The really elegant solution would be to write what is known as a "fat binary". It is more or less the same thing, but the function dispatching is done directly inside the C library without an additional Guile wrapper. <apteryx>mirai: I think the core packages should either be fat binaries supported by upstream or otherwise ones that runs everywhere <andreas-e>apteryx: Do you know documentation on fat binaries? I would like to convince a colleague to use this technique, but do not know how it is done... <apteryx>maybe the gcc, glibc or ld manuals have some info about it? <andreas-e>I try to look it up in the gmp sources, but do not find it easily. <mirai>I'm interested in this as well <janneke>andreas-e: sent a working patch now, i believe <janneke>not tested with the actual upgrade, but the flag is now there <andreas-e>In gmp, as far as I can tell from quickly browsing the code, it is all handmade: a table of function pointers, which are initialised depending on the architecture the code is run on. And then I think that every function call uses an additional indirection. <lilyp>Guest6 you would have to rewrite it to use grafts instead or alternatively wait for substitutes to kick in <andreas-e>janneke: Thanks a lot! Almost there. With the tiny change I sent back to you, I get indeed a list of "standard" configure flags coming from the build system plus the one more we want. <janneke>andreas-e: glad my goof-ups helped you enough to get it right :) <andreas-e>janneke: Oh no, it still fails! But somewhere else now. Right after checking for traditional French locale. (But nothing to do with it.) Anyway I learnt something new. <andreas-e>core-updates does not really exist any more, so I do not know. I started to update gmp and mpfr, and saw that there was also a new coreutils and thought this would be a good occasion to break things. <andreas-e>Will send you the error message. We do not *have* to update coreutils. <janneke>ok; yeah i figure that proper locales are one of the things we least care about in the bootstrap phase... <andreas-e>But traditional French! That certainly deserves attention, even in a bootstrap phase, janneke. <gnucode>bumble: if you have email set up in emacs, and you have set up debbugs...you could open it with emacs... <gnucode>I always have to look up the debbugs commands <andreas-e>If I understand correctly, you send a message to control@debbugs.gnu.org with two lines in the message body: <bumble>andreas-e: thank you I will do it <ulfvonbelow>um... is it normal to have 'guix build' give a list of "The following derivations will be built:" that has duplicates in it? <ulfvonbelow>and I don't just mean duplicate package names, but full, hash-and-everything exact match duplicates <bumble>andreas-e: it is sent thank you! <bumble>andreas-e: a message was sent to me from control@debbugs.gnu.org essentially saying that the command was processed. but the issue is still closed when viewed from the url. Did I do something wrong or do I just need to wait a bit? <mirai>bumble: why is that package not built from source? <mirai>or is it? That release page lists multiple archives <bumble>I think it builds from source using ./configure && make && make install <ulfvonbelow>it seems that package-mapping with #:deep? #t still doesn't get all of the implicit inputs due to how build systems pass packages as arguments to their bag->derivation builders. <mirai>bumble: ok, maybe it really is building from source <mirai>seeing that platitude of archives in the releases page threw me off a bit <bumble>I hope the issue will reopen. I have been using this package locally for about 6 months and it works great <bumble>I'm also super excited to think my patch might be accepted <bumble>thank you! my browser must have been showing me a cached result <mirai>andreas-e, apteryx: I believe you meant “function multi-versioning” when you were talking about fat-binaries? <apteryx>no, I think that's somethig else; that's for tagging symbols with versions, I think <mirai>“… to specify multiple versions of a function, each catered to a specific target ISA feature.” <apteryx>then that reads like what you're after <andreas-e>mirai: Indeed, this is what I was looking for. Thanks a lot! <andreas-e>It does not seem to be what gmp does, who I think dispatch by hand. <RavenJoad>Does Guix's "top" have a special config file or something? It looks different than every other top I have seen. <andreas-e>I think it is just a newer version, without being really sure. <dissoc>when i run guix pull it gets stuck on Computing Guix derivation for 'x86_64-linux'. any ideas how to resolve this? <RavenJoad>andreas-e: Ahh... That might be it. I knew about htop, but I always forget I do not have it installed and tend to default to top for quick things. It does not help I have too many cores for top to display correctly. <andreas-e>Yes, the old top was more friendly with many cores. <andreas-e>There must be a way to toggle what it displays. <RavenJoad>Does guix have the xen guest tools packaged? I could not find them with some "guix search"s, but I may have missed them. <Guest96> https://paste.debian.net/1290624/ everytime I reconfigure my system, my system isn't booting anymore since it changes stuff in the 1. partition. The first partition has rpi4-uefi files. Did I do something wrong? Since I doubt that this is how it is intended <Guest96>I have those labels since I did a guix system image, and flashed the sd card with it. I don't know how else I could have installed the system, since there is no aarm64 install image <apteryx>RavenJoad: it's just the other distributions ship a default config to keep the legacy black and white look <apteryx>if you don't like it, press 'z' then 'W' in top <ulfvonbelow>I actually just tried that and now it feels like watching an old film; the red is still burned in to my brain <RavenJoad>apteryx: I like the red too. But when the %Cpuxxx bars fill the entire screen, that kind of defeats the point of top. <mirai>how can I get the build log of a _successful_ build? <iyzsong>mirai: same as a failed one? guix build PKG --log-file <mirai>cool, I didn't knew about that one <apteryx>a Qt developer experiments with Guix! #65665 <RavenJoad>apteryx: Amazing! Now I can finally read my process table! <RavenJoad>Does guix have the xen guest tools packaged? I want a well-behaved guest VM on an xcp-ng host. <mirai>apteryx: do you have an example of a gexp in a snippet causing trouble? <iyzsong>i failed to use gexp (copy-file) in snippet to update catch2 in chaiscript/paint2d <RavenJoad>makads: A set of guest utilities (and daemon?) to run inside a guest on the Xen hypervisor family. Similar to virtualbox guest additions. <apteryx>oh, libgit2 1.7 supports shallow clones <apteryx>and I have a package update to 1.7.1 for it <apteryx>mirai: I had one minutes ago but I've trashed it, eh <apteryx>it was attempting to use copy-file to copy a package source file into another package <apteryx>both packages were in the same module <mirai>Authenticating commits 9edb3f6 to f5c4db4 (1,290 new commits)... <apteryx>we're closing in on freebsd next ^^' <the_tubular>Is there a guile shell that exist like bash but a bit more guix ? I know about scsh but looking for something maintained <lilyp>there is gash, but it's rather low-level <lilyp>not sure what you mean re substitution, it ought to comply to posix <lilyp>by low level i mean bare-bones, not many bells and whistles <apteryx>oh, patman was broken since the u-boot update, now fixed