IRC channel logs
2023-01-27.log
back to list of logs
<Kabouik>Anyone else using the https://github.com/babariviere/guix-emacs channel in their Guix machine? I came across an issue whereby I am trying to install some emacs package that conflict with my existing ones, despite guix pull && guix package -u. I want to install guix-ement but it conflicts with guix-magit, and if I uninstall magit, it conflicts with another one <Kabouik>I suppose the conflicts are between packages already available in Guix and those coming from the channel, I'll ask the maintainer. <akirakyle>Kabouik: The question I asked above is partly related, since I'm trying to also put together a guix-emacs channel but with a different philosophy (essentially the idea form the "Reuse packages from guix channel" part of the readme <Kabouik>Oh I missed your question above, nice coincidence <akirakyle>Kabouik: This is essentially an issue due to the fact that emacs dependencies are propagated and so you can only have one unique version of a package, thus if you have packages A and B both depending on C, you cannot have A coming from (gnu packages emacs-xyz) and B coming from (emacs packages melpa) <Kabouik>I think I get the same issue with R packages too <akirakyle>Yeah all interpreted languages have this issue <Kabouik>I have some installed from Guix, some installed from guix.install (which essentially writes packages automatically from CRAN and puts them in a manifest if I remember correctly) <Kabouik>The conflicts are a bit of a pain to manage, especially as I haven't really found a good workflow to sole them or prevent them <akirakyle>As far as I know, guix has no way to choose one "automatically". In nix you can set a priority for packages so nix knows which one to prefer. <akirakyle>You'll have to use package-input-rewriting to tell guix which dependency to use (even if they have identical versions, the fact that these packages are defined in different places is enough for guix to treat them as being not identical) <PotentialUser-66>Hey, I was trying to install guix SD and while trying to build the linux-libre-6.1.8 kernel, it gives me this error saying: gnu/store/...linux-libre-6.1.8-guix.tar.xz.drv is not a fixed-output derivation. What is causing this and how do I go about fixing it? <elb>if you're writing a script on a guix system, how do you handle shebangs? <elb>like, not installed system packages, but something casual <acrow>elb: /usr/bin/env is conveniently there for you. <acrow>elb: to be explicit, eg, #!/usr/bin/env bash <surpador>Hey Guix- should the 'patch-shebangs phase patch #!/usr/bin/env shebangs too, or just full paths to interpreters? <elb>ok, that's what I'm currently doing, but it's ... ok <elb>and it doesn't work in guix container --pure <elb>(actually it doesn't work in guix container, --pure is about envionment variables, so irrelevant here) <elb>also this script is guile, not bash; /bin/sh _is_ there ;-) <acrow>elb: Well, env is provided by coreutils. Extra sauce may be necessary. <elb>`guix shell --container coreutils bash guile` does not provide /usr/bin/env <elb>so my script does not run <elb>it does provide env, just not in /usr/bin <elb>I have to use -F to get it in /usr/bin <acrow>elb: Yep. The principle of minimum availability in action. <elb>sure, great, but it's broken for this use case, and I'm looking for a workaround or fix <acrow>elb: So, not the simplest use case... <elb>I think writing and wanting to run a script is pretty simple, but if it's complicated in your opinion, that's fine <acrow>elb: I don't understand your 'casual' scenario. It works natively and you've made it work in a shell container... ?? <elb>is -F the expected solution? <elb>I was under the impression that -F was a hack, and I'm pretty sure it's only existed for literally a few weeks <acrow>elb: yes, that is what is needed in a container. The shell is only a few months old but, I believe, -F is now canonical and here to stay. <elb>then I misunderstood -F, the things I had read led me to believe that it was intended to be used only when programs couldn't cope without it, not for normal people doing normal things that they do absolutely every day and there's no other solution for them <acrow>elb: well, using a container is not everyday. At least not for me. I have a home environment in which I usually live. :) <elb>oh ... containers are one of the things that brought me to guix <elb>I run a lot of code that's not _distrusted_ but is more or less likely to do undesirable things <acrow>elb: A pure container is a pretty spartan environment. (Intentionally so.) <elb>I teach programming ;-) <acrow>elb: Cool!, then shell and -F will certainly be your friends. :) <elb>yeah I've been beating some containers into shape for running various types of programs <elb>but what I'm fighting the hardest is actually _my own scripts_ that I use to (e.g.) evaluate those programs <elb>they're written in a wide variety of languages, and there are ... many shebangs <elb>one limitation I'm having is that I can't create an on-disk profile with FHS compatibility, only shell takes -F, but you can't use -F and -p together <elb>using shell -F -m seems to be slower than shell -F -p <acrow>elb: It sounds like you need a well feathered environment, maybe a manifest would be helpful, no? <elb>yes, I have a manifest, that's what I'm saying <elb>if I have a profile ~/.guix-local/some-profile and a manifest ~/.guix-local/some-profile.scm, I can run `guix shell -C -p ~/.guix-local/some-profile` and it's faster than `guix shell -C -m ~/.guix-local/some-profile.scm` <elb>but -F is only compatible with the latter <elb>it's not _always_ faster, but sometimes (and I don't understand when or why, it doesn't seem to be due to gc or pull?) the manifest command has to do builds <acrow>elb: manifests use the -m option... See: info:(guix)'Writing Manifests' <elb>note that both of the last two times I have said that, I have given an example that includes -m <elb>I have a half dozen guix profiles in my environment right now, all of them with manifests, and several containers that run from manifests <elb>but containers that run from profiles are (more reliably) faster to start, sometimes by several seconds <elb>however, profiles cannot be created with an FHS compatibility layer (because the profile that is built is not used directly as the container root, I assume), and containers cannot use -F and -p simultaneously (likely becaus ethe set of packages built into the container is different with -F), which limits me to -F and -m <podiki[m]1>you know I was wondering about how to work around -F with -p <podiki[m]1>the issue is that -F adds glibc-for-fhs for compatibility, adding it directly to the packages requested in the guix shell call <podiki[m]1>elb: so I'm not sure how to reconcile that with giving a profile exactly, maybe the code can check if glibc-for-fhs is in the profile and continue, if not warn/error <podiki[m]1>elb: I had forgotten about this but it did cross my mind. feel free to open an issue report so we can discuss and especially if you are able to submit or start a patch. i don't think i can get to it on my own for a few weeks at least <lechner>surpador / i think 'patch-shebangs may work for 'env' but it definitely does not work for 'env -S' <podiki[m]1>sneek: later tell elb see log from when you asked about -F and -p options together: in short, I'm aware of it but haven't been able to fully work through a solution, discussion/patches welcome! <mroh>huh? "guix perform-download: error: /gnu/store/9x51vbc7zrh9jnvvsf9c0chlv6ayzjv9-linux-libre-6.1.8-guix.tar.xz.drv is not a fixed-output derivation" <akirakyle>So I've encountered something strange. In my store I have two identical versions of python with different store paths. I've narrowed it down to them being grafted versions of python, but the weird thing is they have identical grafts applied, the only difference is that the the grafted packages are listed in a different order in the "-builder" files <akirakyle>I found this because I was getting a "profile contains conflicting entries" message for two identical packages <akirakyle>I guess the question I have is whether this is know/expected behavior for grafts or if there's something to be improved or fixed here? <akirakyle>Anyways its way too late here and I should sleep but I thought I'd ask this for those experienced guixers who are just waking up <civodul>akirakyle: uh, interesting; that different-order thing looks like a problem <civodul>sneek: later tell akirakyle could you email bug-guix with details about grafts being applied in a different order? looks like a bug! <nckx>PotentialUser-62: Thanks for the report. A few others ran into the same problem & the root cause was fixed yesterday night. <nckx>I'll trigger a new build… <nckx>(Background: the ‘latest’ link, and a few others, are really just links to the CI system <https://ci.guix.gnu.org/jobset/images> and there's no way (AFAIK) to link to the ‘latest *successful*’ build, which would be more correct. <nckx>And the 502 is really a 404. <civodul>i thought it was just Cuirass being too slow to respond? <nckx>I'm not saying Cuirass is serving a 404, I mean it immediately ENOENTs the missing image, but does not report this properly to nginx. <nckx>‘really’ = ‘semantically’. <nckx>It does not time out, no. <civodul>so in a way it's less bad than i thought <nckx>PotentialUser-62: If and when things turn green, the links should start working. <nckx>civodul: There's still the ‘cannot build missing derivation’ mixed in, if you want to worry about something :) Although in this case I think it was a red herring; not sure. <nckx>Does that only happen on (and mask) failed builds, or could it cause successful builds not to be performed? Do you know? <nckx>I'm probably walking a well-trodden path, but: this derivation exists on berlin. <nckx>I'm building the x86_64 .iso image ‘by hand’ on berlin. Then to figure out how to tell Cuirass it exists, ideally without needing to remember SQL. <nckx>Do build nodes run the SSH ‘firewall’? I guess I locked myself out :) <nckx>There is no record of which build node built what, is there? <civodul>i don't think so, except in cuirass-remote-server.log <Kabouik>I am getting too many conflict issues when trying to use emacs package from the official Guix channel only, because I need/want other packages that can only be installed from Elpa/Melpa (or from the corresponding Guix channel by babariviere). This is a bit of a disappointment because I am not fully embracing the Guix philosophy with that, but I am not good and fast enough to package for Guix the Emacs packages I want, I'd spend too much time doing it <rekado>apteryx: my colleague says that the PXE stuff “works for them”™ <nckx>civodul: That's good enough (141.80.167.168), thanks. <Kabouik>So anyway, I now have concurrent versions of some packages that come both from Guix official channel and Elpa. In such a case (https://0x0.st/oFS9.txt), how do I remove the version from Guix channel? <rekado>you can’t expect a mix of packages to work well together <rekado>Emacs doesn’t care where something comes from <rekado>it just looks for things by name on the load path <rekado>whichever comes first gets loaded <nckx>Remove emacs-taxy? (Or use an emacs-taxy from the same non-Guix channel.) <PotentialUser-93>Does someone know how to change the effective gcc-toolchain for the build of a package ? <nckx>Simply adding the desired gcc-X.Y to the native-inputs often works (Guix packages aren't built with the ‘gcc-toolchain’ package). Not always, but a good first thing to try. <civodul>just time-machine'd to guix + guix-emacs + guix-cran: 45k packages! \o/ <civodul>building guix-cran takes forever though <zimoun>well, “./etc/teams.scm cc core“ returns --add-header="X-Debbugs-CC: joe@does.orf" but it does not work as expected, or do I miss something? civodul you already reported it, right? <simendsjo>Is there a way for me and other clients to automatically upload build artifacts to a substitute server? When I build something from scratch, I would like to share this with others. <nckx>You can use ‘guix copy --to=…’. <nckx>Oh, that probably doesn't satisfy ‘automatically’. <nckx>But it sounds better than ‘no’! I'm torn. <nckx>simendsjo: What's the trust model here, and what are you trying to save on? <nckx>I.e., why would anyone trust your binaries? <simendsjo>I was thinking collective trust ;) If several people have uploaded the same derivation, maybe it can be trusted? Seems a bit inefficient having only a build farm with a property like reproducible builds. <nckx>That sounds very succeptible to a 51% (or N%) attack. <nckx>Reproducible builds are very helpful for efficient distribution, but must still be computed by a trusted party first, hence the ‘what are you trying to save on’ question. <nckx>If it's ‘berlin's legendary not-great bandwidth to large parts of the world’, that's valid, and I'd recommend looking at <https://issues.guix.gnu.org/52555> if you haven't yet, and moving it forward if you like it. <zimoun>if we share n identical store items, then I accept to pull k other substitutes from you. <nckx>Sounds good. I'm only interested in compromising your glibc, so I'm happy to serve the rest! <zimoun>there is no trustable solution for distributing substitutes. We can only accept compromise. The question about trust is what you accept to trust. <zimoun>The centralized one we are using have a lot of weak too. :-) <zimoun>Basically, when using k-of-n, I accept to trust you in the first place, as I am trusting Berlin or Bordeaux, for instance. <nckx>That's all true, but it's not saying much (if anything) new. <nckx>And that's defining ‘distributing susbstitutes’ as more general than, e.g., #52555 does. <zimoun>yeah, we agree. I am not advocating about k-of-n. :-) Just mention an hypothetical solution for distributed susbstitutes. <nckx>The consensus so far seems to be ‘distributing’ the multi-MiB (or GiB ☺/☹) payload decentrally, and pulling signatures from a much smaller trusted set. <nckx>Using distribution in the narrow sense of moving bits. <nckx>Distributing builds, yeah, I agree, that's just chosing your favourite pitfall/trade-offs :) <nckx>(Trusting 11 people with berlin SSH access counts as decentralisation, right?) <nckx>ACTION adds a few more to increase decentralisation. <zimoun>I agree with “payload decentrally”. I was commenting: «When I build something from scratch, I would like to share this with others». <simendsjo>Decentralized distribution would also be great. I have lot's of bandwidth I don't use that much, but not a lot of computing power. I wouldn't mind having a service which distributes my packages to other people that I can turn off if I need to. <zimoun>For distributing your builds, maybe you could have a kind of task running “guix copy” from your build machine to your server running “guix publish”. Maybe Cuirass can be configured for that, I do not know. <zimoun>People would have to add your substitutes server (authorize your keys). So, as nckx mentioned: it depends if people trust you or not. <nckx>That's the distinction I was trying to draw: if you're just distributing reproducible toots, people do not need to trust your key, and it doesn't matter if you built them or downloaded them yourself. It matters only that a trusted party has signed them. <simendsjo>I think in practice a malicious user would be found pretty quickly. If some builds differ in checksum, only the build from the authorative source would be used, and the other users would be flagged for investigation. The safest thing is of course to vet all source and build everything from scratch, but I'm too lazy and naive :) <nckx>So someone could trust only berlin, and another person only bayfront, and they could still download from simendsjo. <Kabouik>rekado, nckx, civodul: sorry I had to leave my office and couldn't finish what I was saying or read your answers! I agree rekado, I don't expect it to work well when mixing elpa/guix, that's why I think I'll have to move completely to elpa if I need packages that are not in Guix yet and that I don't feel brevehearted enough to package. As you know I tend to have the same issue wiht R packages actually. <Kabouik>nckx: remove the emacs-magit from Guix channel. `guix remove emacs-guix@version` did not work. <nckx>zimoun: Except you can build your own mirrors if you like, yes. <nckx>Terrible metaphor sorry. <nckx>From memory, I don't think I typed emacs-magit today. <Kabouik>civodul: I use it, but actually that is not a solution but part of the problem because it facilitated installing Emacs package that are not in Guix, and therefore mixing dependencies and version when I didn't intend to (since I only use guix install xxx). But if I move to only using packages from this channel, this should solve my issues indeed. <zimoun>if I build say Emacs, you do not necessary sign the artificat (assuming you are the trusted party). We can only share what the trusted party build, no? Because the build of Emacs is not reproducible. <nckx>Yes. My reply was limited to reproducible toots. <zimoun>nckx: that’s because you use the keybinding C-c g ;-) <Kabouik>You asked if I wanted to remove emacs-taxy nckx, I wanted to remove the Guix channel's emacs-magit <nckx>But those should be rare and rarer still. <nckx>The non-reproducible ones like emacs ☝ <nckx>Kabouik: Ah, I was answering some paste you pasted, which mentioned emacs-taxy as problematic, not emacs-magit. <zimoun>it matches my understanding. :-) <nckx>I missed any emacs-magit messages. <Kabouik>But the paste also mentioned two concurrent versions of emacs-magit, or did I misread it? <nckx>I don't remember, I'll have to find it again :) Sec. <nckx>‘`guix remove emacs-guix@version` did not work.’ OK, pet peeve, but what ‘did not work’ here? <nckx>Kabouik: I don't see any indication that emacs-magit is installed. Is it? <Kabouik>Did I say that? Damn sorry. `guix remove emacs-magit@3.3.0-1.b908c79` did not remove anything. <nckx>No, because it doesn't appear to be installed. <nckx>It's propagated from two installed packages, emacs-ement and emacs-taxy. <Kabouik>Don't the two lines in the paste showing a /path/to/gnu/store/emacs-magit imply that it is installed, and in two different versions? <Kabouik>Oh, then I'm misreading the logs indeed. <nckx>IIRC you wanted to use emacs-ement from a non-Guix (!nonguix) channel, and my suggestion was to use emacs-taxy from that same channel, *if* possible. <nckx>I'm not sure what I'm looking at in that last paste. <Kabouik>But that is the version from the nonguix channel indeed. <Kabouik>You're looking at me installing emacs-magit successfully <nckx>Oh, non-Guix == nonguix? OK. Answer is the same. <nckx>That contradicts ‘`guix remove emacs-magit@3.3.0-1.b908c79` did not remove anything.’. Rather than working from a log of historical stateful actions, let's just look at ‘guix package -I’ 😉 <nckx>If it's (still) installed, it will show up. <nckx>It's not you making it confusing, it's the name ‘nonguix’ :) <Kabouik>`guix package -I`: emacs-magit 20230125.1440 out /gnu/store/98n1gcc82c0nq4iv3jnzvwzixyqhv9al-emacs-magit-20230125.1440 <Kabouik>That indeed shows that I "only" got the version from the babariviere channel, not the one from Guix that I was trying to remove. <nckx>OK, so emacs-magit@3.3.0-1.b908c79 is not installed. <Kabouik>Fromthe first past I posted here, I misinterpreted that both versions of emacs-magit were installed. I need to read a bit more what progagated packages are. <nckx>It's OK, it's confusing. <Kabouik>Pretty useful to see which of my emacs packages are installed from Guix or babariviere channel, actually, since versions are listed. <nckx>Propagated inputs are a (gross) hack: they reduce Guix to the level of a classical package manager (apt, pacman, …). If A propagates B, this tells Guix that if you install package A, it should also pull in package B as if it were installed. <nckx>This is very logical in a classical PM but it's very limiting in Guix, because there's only one ‘slot’ that can be filled that way. <Kabouik>"as if", I see. And does that start to be problematic when using different channels with packages named the same way? <nckx>Yes. (It can happen without third-party channels but we try to avoid that in Guix.) <nckx>So emacs-taxy and emacs-ement propagate (request) an older emacs-magit (3.3…) than the one you've requested with ‘guix install’ (2023…). <Kabouik>So if I look again at the first paste I posted (https://0x0.st/oFQa.txt), when I encounter this issue, what does it actually tell me the issue is? My initial, incorrect, impression was that I had two different magit versions installed and it did not know which one to take as a dependency. That's not my issue apparently, but I need to learn how to interpret this output. <nckx>Let's start with: why do you want emacs-magic@2023…? <nckx>Kabouik: I'll answer that later, I don't want to mix things :) <Kabouik>That's because if we look at conversions earlier here or in #emacs, we see that when I used Guix's emacs-magit, I got a number of other conflicts that made my init.el fail to load terribly. This was following a guix package -u yesterday, and also of course the fact that my emacs package are installed from different sources (which is a call for issues, I knew). <Kabouik>Reinstalling it from babariviere (i.e., the channel that pulls from Elpa directly), those conflicts vanished. Except for ement.el apparently, but at least now my init.el loads. <Kabouik>(I'll have to start a video conference in 5 min nckx, please excuse me if I get slower in that conversation.) <nckx>I'll take a look at #emacs, but oof, this sounds messy and there might not be a satisfactory answer. This is the problem of a global namespace like the one used for Emacs packages, which is why there's so much propagation in the first place (it's much less common in some other ‘ecosystems’). <nckx>Kabouik: That's OK, I'm also multitasking. Poorly. <nckx>I played around with this channel before and things mostly ‘worked’ (built correctly) but I never tried building a coherent configuration from it. My understanding is that it's auto-generated and warranty-free. <nckx>And it has no emacs-{taxy,ement} packages, so there goes the best suggestion ☹ <nckx>Kabouik: The errors you report in #emacs are beyond my (minimal!) Emacs knowledge, and indeed, probably a side-effect of the real problem, whatever it is. <nckx>Unfortunately, that leaves ‘krux02> I think you should stay with one method of installing packages, don't mix em’ and ‘Kabouik> I think I should just try to install all packages from Elpa instead of messing it up with Guix packages; but that is frustrating because it beats one of the main points of Guix’. <nckx>(I wouldn't define ‘installing from the guix-emacs channel’ as ‘installing from Elpa’ though; call it a third way.) <lechner>Kabouik / nckx / Hi, I have hydra 20220910.1206 installed from Melpa (but do not use it) and 'defhydra' does not show up as a defined function with C-h f. Hope that helps! <nckx>It's a defmacro. Would it? <gabber>i wanted to poke around (once again) to ask if there was a specific reason my patches had not been mainlined yet. It's #59867, #60732 and #60797 <lechner>bot testing #59867, #60732 and #60797 <gabber>yeah, i thought the bot would chime in here... <nckx>I forgot its latest nick, but I think it's offline? <lechner>bot testing #59867, #60732 and #60797 <lechner>bot testing #59867, #60732 and #60797 <nckx>No tasty-sandwiches here. <lechner>i need a little one-on-one with that fellow <nckx>Bot's on strike; demanding botsnacks. <nckx>sneek hoards the botsnacks. <lechner>bot testing #59867, #60732 and #60797 <lechner>gabber / sorry! i replaced the manifest file with a guix.scm while the process was running in guix shell, and that somehow broke it. please repost your original message <gabber>lechner: i don't understand... which manifest file/guix.scm? which original message? <nckx>gabber: About your patches: no, sorry, almost certainly no reason specific to you or your patches. Just general slowness and understaffing. <lechner>ACTION would love to see #60798 merged. Upstream accepted an essential patch for encrypted filesystems from me, and our QA succeeds <nckx>Kabouik: I've updated emacs-magit to the same commit, although I don't expect that to magically fix all your problems. Note that Guix will consider 20230125 → 3 a downgrade :) <gabber>i can't wait to have my 50 patches merged and the 2 people vouching for me so i can help more directly :) or are there other ways i could be of help? would it be of service if advanced-rookies (like myself) pre-reviewed patches? <apteryx>rekado: perhaps I'm doing something silly then. Would you be able to give it a try when you have a chance? (I added some instructions to doc/infra-handbook.org for a PXE boot if that helps) <nckx>There's this (understandable) assumption that reviewers == committers, but any competent review is helpful. People don't magically gain new insights with their commit bit. <apteryx>ACTION wishes RPMTAG_HEADERIMMUTABLE was documented <zimoun>gabber: I have commented about #59867. <lechner>gabber / and rookies like me will amend a patch series with input from any reviewer, even from one without commit privileges. please feel free to start with #58768, which requires #58658 <zimoun>gabber: I do not commit access. ;-) Without commit access, it is possible to review and make bug triage. There is many old bugs or patches that needs some love. ;-) <zimoun>gabber: and basically, your patches looks good but I am failing to apply them for testing. Next time, could you provide ’base-commit’ as explained by the manual? :-) <elb>podiki[m]1: ok, great, thanks for the update/suggestion; I will continue to prod at the situation and will look into filing an issue when time allows <sneek>elb, podiki[m]1 says: see log from when you asked about -F and -p options together: in short, I'm aware of it but haven't been able to fully work through a solution, discussion/patches welcome! <gabber>zimoun: yes, i will. thanks for the hint! they were based on current master commits at the time of submitting, but they have aged somewhat since. <zimoun>yeah… I agree. That’s annoying. :-) <gabber>what's an easy way to build all the packages output from `guix refresh -l somepackage`? <nckx>Argh: building of `/gnu/store/8x6xfy223qzdal05xqfmjzi31shd771b-image.iso.drv' timed out after 3600 seconds of silence <nckx>gabber: I run it through ‘guix build $(… | cut -d: -f2-)’. <civodul>uh, why is that? is it xorriso taking a long time? <nckx>The build log is an empty file. Hm. <nckx>This was ‘guix build’ (so using classic offloading), could that have bitrot on berlin? <nckx>‘guix build --no-offload’ → ‘copying 657 store items’ uh OK. <nckx>I've not seen that on my machine. Cache thing? <civodul>it could be that the SSH connection used for offloading went bad, and the thing just got stuck <civodul>no, that message is from populate-store or whatever it's called <nckx>I mentioned a(n interactive) SSH failure to an offload node earlier. It could have been a fluke, but who knows. <nckx>Well, xorriso's xorrisoing now. <nckx>(Which will keep my SSH connection to berlin from timing out, which is good.) <rekado>apteryx: I don’t think you’re doing something wrong. I always suspect the firewall or network settings to be at fault. <lechner>nckx / there is ServerAliveInterval 300 <rekado>for me PXE stuff here has *never* worked <rekado>I always lost patience eventually and shuffled USB thumb drives <nckx>lechner: I have that in my .ssh/config and… it's commented out. With no note explaining why. Hmm. <rekado>it’s incredibly frustrating not to have full control (and authority) over these infrastructure systems <nckx>What did you know, past nckx; what did you see?? <nckx>(Probably just ‘didn't work’, the berlin firewall is pretty brutish.) <gabber>lechner: i'd love to review your patches, but unfortunately i have not once touched anything in go -- neither packages nor code. so i guess my review wouldn't be of much use? <lechner>gabber / i am not sure about that. so far, all my holdups have been about the format of commit messages and, occasionally, commit grouping <bost`>I made a bunch of commits in my cloned guix repo and I want create an iso-image and test them out on a different machine, However the `./pre-inst-env guix system image -t iso9660 gnu/system/install.scm` reports: <bost`>[env] $ guix system: error: commit <my-commit-id> not signed by an authorized key "<my-public-key-fingerprint>" <bost`>(Which is the same error I get when running `make authenticate GUIX_GIT_KEYRING=keyring`, BTW). <bost`>So how can I create my own iso-image w/o having my fingerprint in the .guix-authorizations ? <gabber>lechner: for 58658 i'd write one comment explaining what "Source only package" implies (no tests, no build, etc) a little more verbosely than just the same comment multiple times. otherwise it looks good to me :) <gabber>lechner: yes, i see, you're right. so LGTM then ;) <lechner>ACTION thinks gabber is ready for commit access <apteryx>rekado: have you tried with the instructions I laid down in doc/infra-handbook.org? the one-time boot with PXE seems to be the most successful means to get it to work for me <apteryx>not a 100% success rate but perhaps 2/3 or something <neshamon[m]>Has anyone had any problems downloading the latest linux-libre kernel? <bost`>ACTION It seems like the solution is to my commits on top of the list in the ~/.cache/guix/authentication/channels/guix <ArneBab>currently Guix has Mesa 21, but Mesa 22 has been out for 9 months now. Is there a reason for not updating it? <nckx>ArneBab: You can help test it by reconfiguring your system on the ‘core-updates’ branch, and report any bugs you find, or send a ‘yay, it works, how about a merge soon? :-)’ report to guix-devel@. <nckx>neshamon[m]: *Which* problems? <nckx>I've not heard any recent reports. <nckx>But it was recently updated; maybe something less mainstream broke. <futurile>Q: I'm having a problem with `guix import crate <blah>`, I keep getting ";;; Failed to autoload string->semver-range in (semver ranges): <neshamon[m]>nckx: Every time guix tries building it, it gives me an error in the build log saying: "gnu/store/...linux-libre-6.1.8-guix.tar.xz.drv isn't a fixed-output derivation <nckx>Somebody did report that (mroh). <nckx>I haven't looked at the recent updates, I'll see if there's something that would break the ‘computed origin’ hack which seems like the most likely interpretation… <apteryx>futurile: it probably wants guile-semver in your working environment? <neshamon[m]>nckx: Okay thanks, because I'm at a loss at what I should do haha <nckx>mroh's report sounded so weird that I assumed local weirdness (sorry :), but if it's our bug, I doubt there's anything ‘you’ can do to fix it. <neshamon[m]>Haha, yea and I feel I don't really know a lot about Guix to know where to start anyway <nckx>I don't see any obvious mistakes in the recent commits. I've started a build here, but first, dinner calls. <mroh>neshamon[m]: I think, it has to do with another channel... I'm still in progress rewriting/debugging my kernel package... <apteryx>try 'guix system build' with your channel file removed <apteryx>(and the offending variables adjusted/removed) <mroh>neshamon[m]: you get this with a -libre kernel? <ssouth>ArneBab: So you're aware, I discovered recently there's a small bug in Mesa 22 that can cause sporadic test failures. <ssouth>I'll be submitting a patch against core-updates soon (waiting for builds to complete right now) but if you run into this, here is the upstream fix you need: <nckx>Linux-Libre 6.1.8 built fine. I suspect you might be using third-party channel(s)? <nckx>Oh, apteryx has usurped me. <nckx>neshamon[m]: Do you get this with ‘guix build linux-libre@6.1.8’ as well? <nckx>If so, add -d to that command and share the last line of output (the .drv file name). <neshamon[m]>nckx: Yes I tried building libre-linux-6.1.8 and it built fine when I used, `guix build libre-linux` <apteryx>how do I share expose the store inside a 'guix shell -CD igraph' container? <neshamon[m]>I think I was even able to build libre-linux-guix too <apteryx>I have no luck with 'guix shell -CD igraph strace -E /gnu' <apteryx>I have no luck with 'guix shell -CD igraph strace -E /gnu=/gnu' <neshamon[m]>But it's only when guix system init is building it, it gives me an error <nckx>neshamon[m]: Just checking: ‘linux-libre’, right? <nckx>neshamon[m]: IC. I'll try building an example system. <neshamon[m]>nckx: Yep, I'd like to screenshot it but I've been trying to install guix SD on that computer. <nckx>neshamon[m]: I don't see an explicit answer: can you reproduce this without any third-party channels (if you use any)? The error might be caused by one of many packages that use (package-source linux-libre), not linux-libre itself. <nckx>So that's a ‘yes, I use them’? OK. FWIW I succussfully build bare-bones.tmpl on commit 729eabc6ae8aae32584408f6bbd4526ad21e3476. Still pulling a newer guix. <neshamon[m]>nckx: Yes, I'm using a third party channel. But it's odd because I never ran into this issue before with it <nckx>Sure, but this might have been caused by (very) recent updates to Guix and assumptions in said channel. <apteryx>I guess it may have to do with the switch to gexps for make-linux-libre <nckx>The question was not meant to be dismissive, but it's infeasible for us to debug other channels, especially if they contain software we'd rather not download. <apteryx>fun: guix shell -CD igraph -E /gnu=/gnu strace doesn't work, but "guix shell -CD igraph --expose=/gnu=/gnu strace" does <civodul>apteryx: -E is for --preserve, not for --expose :-) <nckx>neshamon[m]: I've sent you whatever Matrix calls a PM. <nckx>I thought [=A] was always implied. <nckx>ACTION knows their Ayn Rand. <apteryx>nckx: it is, but I wasn't sure anymore :-) <Kabouik>nckx: thanks, catching up with your replies now! <nckx>Eh, don't expect too much, I'm afraid. I don't think there's a satisfying solution. <Kabouik>You're right, guix-emacs is kind of a third way. <mirai>(the predicate was hidden by mistake, disregard it) <nckx>Kabouik: You can at least try to pull and use Guix's emacs-magit, but I fear you'll just hit the next error. <mirai>the tests seem to pass, so I think there's no clashes but I'll run a clean-go && check to confirm <Kabouik>lechner: I'm not comfortable with what defhydra is, I just happened to have it in my init.el file after I adapted something from a Readme somewhere for my use, but it was working until now and wasn't after the upgrade, so something muse have changed between corresponding hydra versions I assume. <nckx>Kabouik: The ‘problem’ is also that guix-emacs uses unreleased git commits, which might be the Melpa way, I don't know, but is not the Guix way, so I can't simply update all those packages in Guix. <apteryx>civodul: I closed my PEBCAK issue, thanks! <Kabouik>Thanks for the update of emacs-magit nckx, I'll see if it helps with my issue (partly or fully). <Kabouik>Absolutely nckx, I fully understand that. That's part of my frustration. I'd prefer using only Guix packages, but then they're not all packaged, and while I am interested in packaging some things for Guix, I am not quick and good enough in Scheme (even with guix import) and the Guix patch workflow to submit everything I want to try as a Guix patch, so I'm leaning towards the non-Guix ways for Emacs packages. <nckx>Sure, that's totally OK, don't worry 😉 <nckx>The Guix Way works for me but I'm the opposite of an Emacs power user. <nckx>guix package -I ^emacs- | wc -l → 7, and that's including emacs-next-pgtk. <nckx>Uh, you're using things called ‘hydra’, that's too scary for me. <apteryx>weird... igraph 0.10.4 passes in a container environment (guix shell -CD igraph), even with 'rm /bin/sh', but fails in the build container <Kabouik>That shows that you are far more organized and sure of what you need than I am. :> <nckx>Flattery will get you more updates. <old>Hi I'm trying to use wayland with the gnome desktop. I've put (wayland? #t) in the gdm configuration but I still get a x11 session after reboot. Is there other things I need to do? <mirai>you could copy that service definition into your config.scm and use it in the meantime <old>should I keep the `set-xorg-configuration' in my services? <old>I will try with the x11-socket-directory-service-type <old>Also I was able to connect once. I get a x11 session. If I try to reconnect afting logging out, it justs keep asking for my password <old>Hope that fix this as well <mirai>old: though check time to time for that issue status <mirai>it might get revised or merged <mirai>no point in carrying unnecessary code <old>I've put a TODO in comment of the file <old>btw were you able to enable fractional scaling with wayland and gnome? <old>I have two monitor, one 4k and the other one 1080p. Trying to scale the 1080p to get less pixelate <old>With wayland thing are less terrible than x11 though <old>right that could be it <mirai>I haven't used the GUI mode much yet tbh <mirai>I've installed guix on a nuc and use X11 forwarding to develop on it <cbaines>sneek, later tell civodul regarding https://qa.guix.gnu.org/issue/61009 , I think the issue is in trying to extract the commits from the email. This is obviously a big problem, but I'm not sure what to do about it. Maybe it's possible to try and handle more ways of submitting patches, but in general I think extracting patches from emails will remain a hard problem. <old>ehh I don't have gsettings anymore. Is it in a specific package? <old>nvm I found it under glib <Maya[m]1>hey, i have found that dconf-editor crashes (when ran) because its missing schemas from glib:bin, should i send a patch? <old>I also get the crash <old>but it works if `guix shell dconf-editor glib:bin' <Maya[m]1>yes i know, i have found that it is indeed the issue <mirai>Maya[m]1: either patch or open bug issue <elevenkb>how do y'all's deal with scala projects? <Maya[m]1>mirai: it appears that glib:bin is a native imput, but that clearly doesnt work, so what should i do? :/ <mirai>post it to bug-guix if unsure <mirai>or try making it an input, but remember to try building it against multiple platforms to see if anything breaks <apteryx>Maya[m]1: a patch is even better than a bug :-) <Maya[m]1>is there an easy way to force total rebuild in pre-inst-env when the package is already in store? because —no-grafts —no-substitutes just doesnt work for me <elevenkb>i have a quick and dirty solution where i use `guix shell icecat` to bootstrap the JVM version of `coursier` then using direnv to manage `JAVA_HOME`, `PATH` etc. according to the output of `./coursier setup --env`. <nckx>Maya[m]1: --check will rebuild the package, compare it to what's in store, then throw away the new artefacts. <nckx>(Keep --no-grafts, or else you'll literally be testing the grafting derivation.) <Maya[m]1>nckx: thats not what i need, i need to throw away the old artifacts, since updating inputs to a package doesn’t make it rebuild or replace the store version <nckx>That's what I feared and not how Guix works. <nckx>It's very likely that you're not building what you think you're buildinf. <nckx>Any change in inputs changes the store hash. <nckx>Possibly, I don't think we have enough info to answer that question. <nckx>Have you run configure && make && friends? If so, if you want to be very cautious, you can use make clean-go and rebuild. <nckx>But this is not generally needed. <Maya[m]1>i have ran bootstrap and configure, i havent run make but i thought you dont need go files for scheme <nckx>Well, kind of, but not running make at all is rather extreme. <nckx>Let's stick to the standard build before investigating probably-not-bugs. <lfam>What's up with the reports of problems building the kernel source <nckx>Probably a non-Guix problem, lfam 😉 <lfam>How interesting! But I see <nckx>None that involve only Guix AFAIK. <Maya[m]1>nckx: already on it, i just didnt want to build the whole guix repo but if it cant be helped <nckx>At least once. I've never tried yolo'ing it without make but I doubt it's supported at all :) <nckx>If it's a clean checkout it certainly won't. <apteryx>Maya[m]1: at the size of Guix, you want the .go files. Just interpreting all the packages modules will take a while, and if you don't byte compile, you do it every time you run guix <nckx>I mean, I do that sometimes to 'save time' but it's beyond slow and frankly stupid. It's also a very dirty repo that was made before. <Maya[m]1>apteryx: i want my python-level of speed /j <Maya[m]1>i understand that you normally byte compile i just wanted to yolo it <lfam>Another vote for "run make or you'll be sad" <mroh>I fail to customize my kernel with "(customize-linux #:defconfig (local-file "myconfig"))". It fails in configure phase with "("Mismatching configurations in .config and arch/x86/configs/guix_defconfig" ...)". Does anyone have an example for using it? <apteryx>mroh: try not using #:configs if you get too much trouble <apteryx>it's geared toward the use case where you version your own defconfig after running 'make menuconfig' && 'make savedefconfig' <Maya[m]1>actually make made it work, sorry i doubted you </3 <apteryx>I think our default .config is breaking the verification itself <apteryx>because of the different GCC recorded in it for example <apteryx>perhaps sanitizing the various .config we have so that anyone running 'make defsaveconfig' from them get the same result would be a good starting point I think <apteryx>at least from a 'guix shell --pure -D linux-libre' environment <sneek>akirakyle, you have 1 message! <sneek>akirakyle, civodul says: could you email bug-guix with details about grafts being applied in a different order? looks like a bug! <akirakyle>civodul: Okay! I think I have a bit of a recipe for this now and yes it's looking to me more like a bug now <mroh>apteryx: yay, this works, thank you! My old "guix environment bash --ad-hoc gcc-toolchain bison ncurses pkg-config coreutils gawk flex -- make menuconfig" (which I use since years) seems to use another gcc etc. than "guix shell -D linux-libre ncurses". <apteryx>yes, it'd use the latest gcc-toolchain version available instead of the one used to build the linux-libre package <apteryx>glad you got it working! the benefit of the validation is that now you know that the defconfig you version is clean and reproducible <apteryx>by the way, c-intro-and-ref is a pretty interesting read for those wanting to learn a bit more about C <apteryx>I was reading into it some more, and I am impressed by the range of topics covered <mroh>I still love my (very) old K&R ;) <nckx>Maya[m]1: Glad to hear it, and thanks for letting us know. <cbaines>apteryx, regarding qa.guix.gnu.org taking a while to process things, I think data.qa.guix.gnu.org has been having problems recently, and I haven't had the time to sort/investigate things <mroh>Yes, compared to newer books, I guess its bad. But it's one of these books that were a life changer for me, because I realized that I could write assembler in a another (portable) language. (maybe we should change to #guix-offtopic ;) <nckx>Upgrading higan to 115 (and GTK3) reduces FPS from ~50 to <5. I'm on Wayland setting GDK_BACKEND=x11. Anybody seen similar behaviour before and have a clue where to start looking? <jgart[m]>mroh: Yuu Yin: Modern C is in the public domain now. Maybe we should get the author to also release the sources and then we package it for Guix as an info book... <ArneBab>Erstellung von /gnu/store/awl0wi0r7szvfz7nd8ql8yrw9m3y3z2r-tcsh-6.24.01.drv fehlgeschlagen <nckx>There should be a log file, or output. <nckx>‘error: in phase 'unpack': uncaught exception: system-error "copy-file" "~A" ("Success") (0)’ <nckx>The ghost of the murdered finalization thread has come to haunt us all. <ArneBab> Subject: [tcsh 6.24.01] testsuite: 68 failed <ArneBab>68. commands.at:897: 68. nice (commands.at:897): FAILED (commands.at:900) <ArneBab>from 68. commands.at:897: testing nice ... <ArneBab>./commands.at:900: tcsh -f -c 'nice set var=1; echo $?var' <ArneBab>--- /dev/null 2023-01-19 15:17:22.029485238 +0000 <ArneBab>+++ /tmp/guix-build-tcsh-6.24.01.drv-0/tcsh-6.24.01/testsuite.dir/at-groups/68/stderr 2023-01-27 21:53:27.492719539 +0000 <nckx>Thanks! Watch out with pasting more than about 3 lines, the bot might get you (and friendly grumpy people will complain). <nckx>This is just the upstream Guix tcsh package? <nckx>I'm guessing this is not a Guix System, but a differently configured kernel?