IRC channel logs
2024-10-11.log
back to list of logs
<apteryx>so 'guix install openjdk:jdk' or 'guix shell openjdk:jdk' <apteryx>the CI throws a 502 error again; what's it up to? <apteryx>krascovict: 'guix shell openjdk:jdk -- javac --version' works for me, prints: javac 21.0.2 <apteryx>to install anything with Guix, the easiest/best path to is to creating a package for it <apteryx>then it's easily reproduced and can be contributed for others to benefit <krascovict>I understand, the javac version is: javac 21.0.2 <__cornflake__>I just ran a command and it said it was getting substitutes from there <apteryx>I've manually restarted cuirass, for anyone trying to work with it <bavier>I'm trying to fix/update our kodi package. not fun so far. <bavier>I didn't see any patches or branches for kodi update, has anyone mentioned it here? <bavier>I forgot how quiet this place usually is at this time of day :`) <mange>I just didn't have anything to say. :) I haven't seen kodi mentioned, sorry. <wickedshimmy>hi folks. I'm experiencing the dreaded segfault running most guix commands now (e.g. `guix --help` is fine. `guix repl` starts guile, but then `,use (guix)` dumps). foreign distro (fedora 38). no LD_LIBRARY_PATH shenanigans. trying to roll-back hasn't been successful yet -- generations that I know were previously working are now faulting; using some way way back generation to attempt to pull gets a little bit further (fetches from channels, start <wickedshimmy>hink) but eventually also segfaults trying to build a derivation. any ideas to attempt further debugging? <Guest79>So ci.guix.gnu.org and issues... are back and I see that the <Guest79>package guile-emacs is being removed(?) and is failing to build due to a missing file - latest x64_86 log shows this... Before I spend time on this, what is the reason for it's removal? lack of a maintainer? Also is there interest in eeping this package alive? <Guest79>I need a better irc client with friendlier editing, currenty using web.libera.chat - what do people here use? <jaft_r>Guest79: Circe with Emacs (considering you're discussing guile-emacs, I'm going to hazard the guess that might not be too far outside your use-cases; it's pretty neat/nifty) <Deltafire>Guest79: i've been using weechat for years, it's a terminal client with web and android front-ends <futurile>Guest79: where are you seeing that 'guile-emacs' is being removed? <futurile>rkazak: It looks the reason for removing it is that libusb is blocked by it. And since the project isn't active any more there's no reason to keep it. <futurile>rkazak: if something is broken in the build system and it's an old package that no-one cares about then it seems reasonable to remove it. Do you care about this package for some reason? <Guest79>futurile - I was interested from the pov that it is tryng to use Guile in preference to elisp <Guest0>is there a system-wide guix way of enforcing -march=native for all (bootstrapped) builds, so not with --tune but lets say with infectious gcc driver modification? <civodul>Guest0: no, there’s no way to do that <civodul>note that ‘--tune’ is purposefully restricted to packages with the ‘tunable?’ property <civodul>few packages can really benefit from ‘-march=native’ <Guest0>too restrictive. my problem is that this risc-v laptop I have is quite slow.. so bootstrapping should better use -march=rv64gcv or some such, but I don't want to deal with manual adaptation of every single package in a depth-first fashion <Rutherther>Guest0: adding a flag should be fine for most packages that use build system phases and not something custom. Then you would not have to deal with every package, but only with every build system. There is no way to do this "system-wide", as it depends on what channel you use and what expression you are building. But there are ways to map every package used by operating-system record for example. <Rutherther>but I don't really see why patching gcc would not be possible as well. Then you would have the benefit of not having to deal even with the build systems nor custom phases. Again, you could replace the gcc in operating-system record to apply it to all your packages coming from there. You can do the same for your home etc. <Guest0>I guess that would involve creating a custom triple, right? <Guest0>this patch would need to extend to all toolchains built from that compiler onwards <Guest0> riscv seems to seed with gcc-7.5.0 at this moment, do all gcc's boostrapped from that would need to have the -march added automatically <Rutherther>Guest0: right, I see, you were talking about patching gcc itself in that message. Yeah, then maybe that's the case. I am not that knowledgeable about gcc to say what the patch has to do specifically <Guest0>I suspect it should be possible to do without patching gcc (in a viral fashion), just adapting guix to invoke bootstrapping with an additional flag. <civodul>Guest0: i’m not familiar with RISC-V, but perhaps there’s a need for a system type other than riscv64-linux targeting this CPU variant? <Guest0>true. maybe I need to create a new seed with my variant.. <ekaitz_>Guest0: you need to make a custom gcc i think <ekaitz_>but only having the v extension is not going to change much <cbaines>Guest0, are you just trying to install guix packages? There should be some riscv substitutes at least <Guest0>the thing is the custom gcc needs to be using the RVV, and it needs to generated code using RVV. I think I'd be willing to reverse bootstrap gcc-7 with gcc-14 if need be.. <Guest0>cbaines yes there are substitutes, but I don't thing they use vector extension <futurile>Q: is there a way to set the the 'commit' that guix will use in the operating-system record? I've found guix-for-channels, which is working for adding other channels, but I'm trying to set the commit of the 'guix' channel <futurile>ACTION is a bit lost in guix/channels.scm <ekaitz_>Guest0: no, no packages use the vector extension, we do rv64gc <ekaitz_>Guest0: i don't know what's best for you right now... maybe replace the GCC of the gnu-build-system with your custom one? <Guest0>exactly my thinking. I'd say adding RVV everywhere should be a natural transformation which doesn't touch any recipes, system types <Guest0>it should basically affect only code generation inside any gcc <Rutherther>futurile: guix-for-channels takes all channels, even guix one. So it should work even with specifying guix commit <ekaitz_>Guest0: how are you working in RISC-V btw? (i'm one of the people that made the RISC-V full-source bootstrap) <Guest0>let's say for now I don't do full-source. would something like RVV be still possible? <Guest0>ekaitz_ did you do full-bootstrap on an RVV capable HW? <ekaitz_>idk if they have vector support, honestly <Guest0>how long did the deployment take? <ekaitz_>Guest0: the whole boostrap process until a gcc7/9 takes like several days <Guest0>so gcc7 in the seed is from the full-source bootstrap? <ekaitz_>soonish we'll start from source for riscv too <Guest0>for me right now it would be great just to do the experiment from gcc7 onwards <rovanion>Hi, I'm getting "guix substitute: error: TLS error in procedure 'write_to_session_record_port': Error in the push function." when I run guix upgrade. Seen it before? <Rutherther>rovanion: are you getting that repeatedly or just once? <rovanion>I've been getting it both when running `sudo guix system reconfigure` and `guix upgrade`. So at least twice. <galois`>Hi. For a few days now I get this error with C/C++ programs: _GLIBCXX_USE_BUILTIN_TRAIT is not defined. Not sure how to fix it.. <galois`>I have gcc-toolchain, clang-toolchain, clang all installed via guix install. It used to work that way.. <rovanion>galois`: Do you get the same issue if you run in a pure guix shell with only one of the toolchains? I.e. `guix shell --pure gcc-toolchain`. <rovanion>Rutherther: Just rerunning the upgrade seems to have worked. <Rutherther>rovanion: yeah, I suppose it was just a network issue, where a stream has closed when it shouldn't have. But not completely sure. <nckhexen>'Error in the push function' does tend to mean 'connection closed prematurely'. Guix (or how much of that is Guile?) largely assumes that your network is perfect. <civodul>nckhexen: howdy! it’s an error returned by GnuTLS, but it’s not very useful <civodul>normally, recent ‘guix substitute’ catches it and tries to reconnect <rovanion>Unrelated: My Xorg was going wild consuming 100% CPU, as well as every other process with a window. Turns out conky was the cause. It didn't answer to SIGTERM and after SIGKILLing it all usage went away. <nckhexen>Wait, seriously? Then I owe you an apology but I've never seen that. Ever. And I assume it's logged. <nckhexen>If we're seeing only a minority of failures that slip through, that's not exactly reassuring, but that's a different matter. <rovanion>Restarting conky from the terminal and now there's no problem /shrug. <futurile>Rutherther: I don't *think* guix-for-channels works for specifying the 'guix' channel - it looks like it removes the guix channel's definition <futurile>Rutherther: so I managed to add a channel - but for the guix channel - it went out and got the latest commit - didn't use the one I tried to specify <Rutherther>futurile: yes, it removes the guix channel definition because it puts it to source of the package. <futurile>Rutherther: OK, I'm probably being a bit slow here. So how can I specify a commit for the guix channel? I'm specifically trying to 'fix' the guix channel to a specific commit <futurile>ok, thanks - I must be doing something wrong - I'll play with it <Rutherther>futurile: so this is not working, and still gets you latest guix in your system profile? <futurile>Rutherther: just trying it again to see if I'm doing odd <futurile>I'm building a system image which I think is not the way to go - it's making each iteration very very long <futurile>Rutherther: that works - OK, so form of effort between keyboard and seat! <gabber>the mailing list archive is currently unavailable - is there anything someone here can do about it? <gabber>thank my data-hoarding self for getting those emails and being able to .. just read them through IMAP (: <nckhexen>There is zero correlation between our recent *.guix.gnu.org down times and those of *.gnu.org, improbable as that might seem. We're entirely at the mercy of gnu.org sysadmins here. <gabber>what's the easiest way to reconfigure my `guix home` now that one package (i.e. kodi-wayland) is broken? there's no roll-back for that, no? should i manually craft a channels.scm file? <ieure>gabber, Remove the broken package from your home config. <gabber>ieure: and go on living without kodi-wayland? <Rutherther>gabber: there is a rollback for that, guix pull has switch-generation. Or you can just use the older guix versions from "/var/guix/profiles/per-user/$USER/current-guix-X-link". Of course this works only if you are fine with downgrading everything <Rutherther>other than that if you wanted to have newest everything except kodi-wayland, you can take a look at inferiors <gabber>well, it isn't really downgrading, if the last pull has not successfully been applied to my home config, is it? <gabber>ieure, Rutherther: thanks for your hints! <gabber>and hooray, the fix for the build was just pushed - so a normal pull and a reconfiguration should work now, too (: <Franciman>hi, is there any reason to start from the GNU Guix System image version 1.4.0 rather than the latest one? <retropikzel>When using guix package manager there is the env var GUIX_PROFILE, is there something similar on guix system? <Rutherther>retropikzel: GUIX_PROFILE should not be a general env var, it should be set only when you are sourcing /etc/profile of a profile. And the same mechanism is used on guix system <retropikzel>Rutherther: Have I done incorrectly then when I have it in my bash and it points to ${HOME}/.guix_profile? <Rutherther>retropikzel: what it does is that the search paths of the profile will have the path to GUIX_PROFILE rather than to /gnu/store. That means you can change the profile, like using guix install and you will still reference the current version of the profile, rather than lagging behind. This also explains why you should not have it as an env var. Because if you do, and you source another profile, you will have wrong search paths. <retropikzel>The original problem is that I have a package that installs stuff into /usr/lib and I would need to get to it <retropikzel>I'm not quite sure how to do it properly in a way that works with the pm and system <Rutherther>retropikzel: the correct way of getting env vars to profiles is by making them search paths, and putting package that provides those search paths into the profile <Rutherther>other than that you would have to hard code it somewhere else <intermet>guix shell iputils --container --network -- ping guix.gnu.org <intermet>ping: socktype: SOCK_RAW; ping: socket: Operation not permitted; ping: => missing cap_net_raw+p capability or setuid? <intermet>Do I need to expose something to the container? <Rutherther>intermet: ping cannot be used like that. It has to have setuid flag, and gnu store cannot contain those. That is why there are privileged binaries in /run/privileged/bin. <ieure>Hmm, /usr/bin/ping isn't suid on my Debian box. <Rutherther>ieure: it is setuid on guix system. Not sure how Debian does it. <ieure>Yeah, I see it's suid on Guix System. And I understand why it needs & has traditionally had elevated privileges. <ieure>Would be nice it if wasn't suid. <Rutherther>I suppose it would suffice to add it the capability cap_net_raw via privileged-program-service-type instead of making it setuid <ieure>Rutherther, Nice! I'd submit it just to see what folks say. <luca>What is the minimum length a line should be in the guix repo? <guix-newbie-123>Hello, when i try to reconfigure or build my system I get this error message: guix system: error: failed to load 'sys-config.scm': Read-only file system <luca>Hi, how can I cleanup some of the guix generations and stuff? I'm in need of disk space :D <robin>luca, guix gc, e.g. guix gc -d 1m to delete generations more than a month old <robin>(info "(guix)Invoking guix gc") for all the options <nckhexen>Rutherther: Sorry, easier to respond here than through the mail: the spoke in the wheel of all this cap-all-the-things niceness is, I think, the Hurd. We probably need a simple setcap-unless-hurd-then-setuid helper. <Rutherther>nckhexen: I see. So there are no capabilities on hurd, only setuid/setgid? <nckhexen>luca: Er... the minimum length is 0? I'm sure I don't understand the question. :) <nckhexen>Rutherther: I'm no expert but that's what civodul always came along to add to my patches, yes. <luca>*maximum, I guess. Whatever makes guix lint shut up about line being too long :D <luca>I think it's 80, by trial and error <nckhexen>We configure emacs to wrap at 78 or so, and guix lint warns at around 82 or so, but the ideal is 80. But not at all costs; don't make your code hard to parse just to meet it. <luca>In this case it's just a description, so that's easy enough to wrap appropriately <llano>Is it possible to have a package definition with two input archives that need to be unpacked as part of the build process? <futurile>llano: yes I believe so, there's some in the existing archive I believe ... and now you're going to ask me which ones ... which I can't remember <llano>I'll keep browsing to see if I can find an example <ekaitz_>llano: look at the beginning of the commencement.scm <ekaitz_>llano: it was in the past, we changed that... let me search another example <llano>I see some (uri (list ...) examples, but that appears to define a backup path to the archive rather than for unpacking 2 distinct archives <ekaitz_>llano: tcc-boot0 in commencement does something similar to what you want with nyacc-source <ekaitz_>llano: what it does is to add an input as source and unpack it manually 