<rekado>no such error in the French texi file, though, which also fails with a similar error <lechner>Hi, what is going on again between gettext and gnu-gettext, please? <vagrantc>depends on where you reference it from which you need to use <vagrantc>the package is named one, the variable represented in guile is the other ... i think. <lechner>vagrantc: yeah, thanks for helping to clarify! i was kind of looking for the reason <dthompson>lechner: gettext is a procedure in Guile, so the name gnu-gettext is used to avoid name collision. <lechner>Hi, should inputs used at runtime be in regular "inputs"? <lechner>I am so in love with Guix and Guile. It's a bit hard to wrap my head around sometimes, but it's the most logical, reliable and elegant thing I have seen in a long while <lechner>plus, the social environment is also one of the most pleasant of any technical community i have seen <kaelyn>I also agree! Well said, lechner :) <ric342[m]>is something automated like debootstrap available <ric342[m]>or any templates to look at for individual packages? <oriansj>ric342[m]: not without solving about 318 bootstrapping loops <oriansj>so entirely possible but about 6-9months worth of work <ric342[m]>Wow that's way more than I would have assumed <ric342[m]>Has anyone ever bootstrapped another OS from guix before? <oriansj>about 3-4 missing packages need to be bootstrapped but the package manager has already been bootstrapped. <oriansj>it even has a bootstrap path in Live-bootstrap if I remember correctly <ric342[m]>But is that really enough to start building the alpine packages? <ric342[m]>Great, do you happen to have any links to the relevant files? <oriansj>xbps 0.59.1 was bootstrapped in live-bootstrap <ric342[m]>I wonder why debian is so much harder than void <oriansj>if your package manager and distro was created yesterday, there just isn't any time for circular dependencies to creep in <ric342[m]>I couldnt find the info about gentoo stage 1 on guix, is there a list of what oses can be bootstrapped on guix? <oriansj>basically you just need to compile a list of packages needed to form the basis of an install of the distro and then see if they have guix packages of them at the correct versions. <ric342[m]>So I guess the packaging tools and the initial compilers? <ric342[m]>I suppose probably most distros wouldn't have much documentation for this <oriansj>nope and there can also be libraries that traditionally depend on the distro itself to build <oriansj>so you'll have to detangle that crap too <ric342[m]>Sounds like a mess.. Hopefully guix will help the wider ecosystem untangle this <oriansj>it isn't hard in the technical sense, just tedious and odds are the Distros themselves will reject the work you have done <ric342[m]>To me it sounds weird that this is so common <oriansj>kinda like how Guile rejected the work bootstrapping psyntax.pp <oriansj>we did the work (it literally took months) and they without a second thought went, no and broke the bootstrap on the very next release <ric342[m]>Do you think more distros will eventually care about this kind of stuff? <oriansj>ric342[m]: why would they? Most of them still allow developers to just upload binaries that are distributed without even checking the build is reproducible or corresponds to the source code. <ric342[m]>Maybe I am misunderstanding but it seems to me that if there is no reproducible way to bootstrap is limiting the point of open source and freedom in many ways <oriansj>ric342[m]: the bootstrap is 100% reproducible <ric342[m]>So for guix you can also reproduce the installation iso from a bootstrap? <oriansj>oh, the only 2 distros that are bootstrapped are Guix and Live-bootstrap <ric342[m]>Couldn't you just cross compile it from linux, like guix? <oriansj>ric342[m]: we don't even need a kernel to bootstrap these days <oriansj>we literally hand wrote a kernel in hex0 <oriansj>so you only need to trust the hardware and inspect a few hundred bytes <oriansj>and Guix's bootstrap has the Guile binary problem <oriansj>so if one was being 100% honest, only live-bootstrap is properly bootstrapped. <ric342[m]>Would it be possible to do from a very basic computer <oriansj>well you would only need a 486 and enough RAM a minimal IDE Drive <oriansj>if one wanted to do simpler, it would be possible to do the bootstrap steps up to M2-Planet and mescc-tools-extras <oriansj>which would be enough to validate other platforms <oriansj>as M2-Planet is a universal lambda and produces the exact same output given the same input and args; regardless of how architecture, OS, etc <ric342[m]>So I guess, even if you get to guix from live-bootstrap, you'll end up with an outdated guile unless you accept a binary? <oriansj>ric342[m]: no, because we know how to use the older guile to generate psyntax.pp for the new version of guile (so far) <oriansj>so assuming we don't have a repeat of Bison, we can just walk the version chain <ric342[m]>Oh okay, this is nice to know, I guess I have some reading to do but these links should be helpful <oriansj>well if this stuff interests you, check out #bootstrappable <apteryx>cool, I found a way to splite [env] into PS1 in any foreign distribution's .bashrc for when GUIX_ENVIRONMENT is set <apteryx>i'm integrating it to guix-install.sh <apteryx>to append to your foreign distro's ~/.bashrc <apteryx>tested on fedora: [user@localhost ~] [env]$ <oriansj>apteryx: don't forget to test it with strange PS1 values like: export PS1='┌─[\u@\h]-[\w] <apteryx>worst case it won't do anythin (if there's no $ prompt used) <apteryx>that'd leave \$ in the origin PS1; not sure how that'd be interpreted <apteryx>yeah, it'd look like: user@host:~$ [env] $ <apteryx>tested on ubuntu 20.04: user@host:~ [env]$ <apteryx>oriansj: sent the final integration to guix-install.sh as #58345 <podiki[m]>I've been meaning to make something like that in the fancy zsh ones I use <Franciman>can i specify services to run in each profile? <civodul>Franciman: hi! do you mean services for Guix Home? <Franciman>hm wait, maybe i'm doing things backwards. I wanted to create a guix shell development env <Franciman>in which an http server is running, to develop my webpage with php <civodul>'guix shell' doesn't take care of services <civodul>so it's up to you to start and stop them <civodul>(would be nice if it could help with that, though) <Franciman>well, one can fake it with a script run inside the development env ^^ *rekado_ fixed the French and German PDF manuals *rekado_ now tries new patches to build the Chinese PDF manual <mekeor[m]>do we hate linux for merging the rust-branch which is based on cargo? <nikolar>We hate the rust crowd for bullying kernel maintainers to do it <civodul>mekeor[m]: not sure who "we" is but there's no hatred to be had <rekado_>“bullying” is also quite the accusation to fling around without evidence <zpiro>Rust hate is loveable, while slightly beyhind the curve and a lot of work for things that matter. Keeping track of their stuff is as it were. <mekeor[m]>i dont hate rust. i like it. but guix has a lot of problems with cargo. and linux uses it now. <Franciman>if i wanted to contribute to an italian translation of the docs, who i should speak to? <zpiro>you should hate rust for stealing attention for core security concerns - if it is rust is fine? <zpiro>I mean, the lever of interest, from musl ans rust to families of compilers make you think it is fine if it compiles. <zpiro>rust especially is a huge time sink and compile time drain for guix. <rekado_>Franciman: you can sign up to weblate to contribute translations <zpiro>glibc support, ans all nice things that work and fly isn't bragged about enough, compared to rust issues. <rekado_>motivation is not fungible. It’s unlikely that people working on Rust for Linux would work on “core security concerns” or anything else if they were prevented from working with Rust. <rekado_>likewise you can imagine a Nix contributor shaking their head looking at all these Guix contributors. “If only they all worked on Nix instead!” <rekado_>so any disdain for other people working on free software is entirely misplaced <zpiro>rekado_: Rust is great, but at the end of the day it is a memory mangament problem you are working on - needing execution. <zpiro>Now, the kernel needs attention at this level. <rekado_>zpiro: I encourage you to spend as much attention to the kernel at this level as you can muster. <zpiro>but there inherently are no magic bullets, you care about compiles and central libraries, and some are more studied than others. <zpiro>rekado_: I am too lazy to build a minal persoal kernel setup for my use, but yes, it begins there. <zpiro>for the two questions: If the config doesn't enable a feature with a problem, and secondly if the code doesn't exist. <zpiro>nobody has ever built a kernel with floppy support last two decades, but there have been many CVE related to the feature. <zpiro>but yeah, "bug only relevant for those using the feature in a config", "bug only relevant for those compiling it in". <zpiro>many /dev/floppy issues last two decades, but always userspace issues. <zpiro>so always secure and supported outside of edge cases, but to be secure you probably hae a kernel that lacks it. <zpiro>close to a slogan, even freebsdf if is secure if you configure it right. <zpiro>or, if no port is open and offered, there is only kernel subsystems to interact with. <zpiro>and since 1995, all things have used the BSD stack for TCP/IP and it considered secure to a stellar level. ***wielaard is now known as mjw
<zpiro>for single core with ethernet overlap especially, but that is als the new and fancy problems possible in theory. <rekado_>got the zh_CN PDF manual to build with XeTeX… but it’s missing fonts <zpiro>so that is the core of concerns, but for all things great and www....... <nckhexen>mekeor[m]: No, we don't. It's probably a move for the better. ‘Interesting’ for Guix, sure, but the kernel has been historically self-contained so hopefully the Rust library hell won't apply. ***Dynom_ is now known as Guest2389
<nckhexen>bcachefs authors are chomping at the bit to rewrite it in Rust. At this rate, that might start before it's even merged. ☺ It's happening. <civodul>hi zpiro! i didn't know you had package "root", congrats on that one! <civodul>i'm not familiar with it but i heard it's tricky to package <civodul>re tutorials, there is material, but it's probably still lacking compared to more popular tools (unsurprisingly i guess) <civodul>if you have ideas of things to add there, please share! <tschilptschilp23>hi guix! what is the best way to check for which packages (service gnome-desktop-service-type) provides? I'm just looking through my home- and system-configs and suspect that my gnome-related rants might have their cause in overly fat configurations... <civodul>tschilptschilp23: hi! gnome-desktop-service-type provides a lot of packages, and that takes a lot of room indeed <civodul>try "guix system edit gnome-desktop" to see the code that adds those packages <efraim>I'm testing out mark's patch for the rust bootstrap, already seeing some nice improvements in speed compiling before and after in parallel <lechner>Hi, is it worthwhile to build a package from Git instead of a tarball, even if it means that additional inputs are needed? <mekeor[m]>nckhexen: what do they want to rewrite in rust? *mekeor[m] learns about bcachefs <mekeor[m]>lechner: iiuc, some build options for specifying branch and repo etc are only available if the original package declaration refers to a git-repo, too, right? i really love that feature, so i'd say, it's worth it :) <nckhexen>mekeor[m]: bcachefs itself (also, the tools, which has already started but Guix makes do with a klugy bash clone for now). <lechner>Hi, should #55762 show up in Emacs debbugs? ***maximed is now known as antipode
<lechner>actually, it does. i made a mistake. it's in guix-patches, not guix <nckhexen>(That is an emacs bug, but since issues. just sucks in all of GNU debbugs, it shows up on the ‘Guix’ issue tracker.) <lechner>nckhexen: yeah, i have ample experience manipulating bugs via email but am playing with M-x debbugs-gnu <lechner>nckhexen: sorry i have been pestering you about this bug. is there anything i can do to help it being included in core-updates? <rovanion>Anybody ever tried to run Papers Please on Guix? It seems to be dynamically linked to /lib/ld-linux.so.2, but it is not present on my linuxx system. I guess I will have to patch the binary? http://paste.debian.net/1256275/ <nckhexen>lechner: I've not managed to swallow the emacs-debbugs red pill yet, let me know if you love it and I'll add it to the ‘reasons to try again’ column. And yes, that looks good for c-u. What testing have you done (if any)? <nckhexen>rovanion: (1) Yes, or (2) use extra-special-file to manually create a /lib{64,} symlink for everything it needs, or (3) test out the --emulate-fhs option that is floating out there as a patch. ***maximed is now known as antipode
<lechner>nckhexen: not much testing, except i build guile-pam against it. i am now trying to include the proposed linux-pam in my system config (probably should do it for home, too) <rovanion>I've got ldd to list that I'm missing libstdc++ from my shell/environment. My guess at gcc-toolchain was not it :/ <tschilptschilp23>lilyp: turns out that it's most likely not evolution, but gnome-online-accounts, which I lazily used for setting up evolution :) <antipode>lechner: copy-paste the (search-patches ...)? <antipode>(and pull from core-updates instead of master). <antipode>If on master, you can copy the patch + use (patches (list (local-file "local-copy.patch"))) <tschilptschilp23>lilyp: gnome-maps launcher appears to work again, thanks for your hint at secrets <mtekman[m]>Hi all, thanks for the help earlier -- I managed to push out one patch. I now have an issue with a different package: it builds and installs fine, but for some reason it only works when invoked as sudo. This is different from the default behaviour. I've tried changing permissions of the output file via "chmod" but it errors out. Any thoughts, or obvious things I'm overlooking? <antipode>mtekman[m]: This sounds rather package-specific. <cbaines>some programs require root privileges mtekman[m], it could be that the program you're trying to run is one of the ones that does <civodul>the linux-libre-*-guix.tar.xz derivations take ~2h to build on aarch64-linux <antipode>'chmod', when run inside the build environment, should work (though I don't know whether it would actually achieve your intended goal), what's the error message <civodul>that exceeds the default max-silent-tmie <mtekman[m]>antipode: cbaines okay thanks, I'll dig a bit more <cbaines>civodul, do you have a specific derivation you're looking at? <antipode>civodul: maybe print progress information? <antipode>Then the fragility (system-dependent) of timeouts would be mostly avoided. <civodul>cbaines: actually i just built /gnu/store/y4xmd5lhc3px041zyvpy9r7v6p9frlp4-linux-libre-5.15.71-guix.tar.xz on overdrive1, which was idle, and it took less than 1h <cbaines>with that derivation you mentioned though, I don't see any deblobbing happening, which I think can be slow (and silent) <cbaines>my original thought though civodul was that I think the ci.guix.gnu.org connected Overdrives have hard drives, rather than SSDs, which will probably slow down builds like these ones which involve lots of bitty I/O <cbaines>I'm not sure how to quantify the benefit of replacing the hard drives with SSDs, but monokuma (the Overdrive connected to bordeaux.guix.) already has an SSD, so we could easily do some testing <cbaines>right, that derivation you mentioned above has an input /gnu/store/qinvmlkxk8kipgkk55wlhcj10f45m6pb-linux-libre-5.15.71-guix.tar.xz.drv which takes much longer to build <cbaines>and I see "Scanning the generated tarball for blobs..." at the bottom of the log <civodul>cbaines: yes, it's the part that takes time and doesn't produce any output <civodul>cbaines: the default is 1h, so 2h is already an improvement <JackFaller>Does anyone here have a package for gtk (and for glib) at verion 1.2? *apteryx has been meaning to rewrite the linux-libre deblob scripts in Guile *apteryx prepares to push the vncserver-service-type patch series <apteryx>are the honeycomb machines more capable than the overdrives? <minima>hi, i'm looking into emacs-cider for clojure programming; iiuc cider looks for an active nrepl but i'm not sure nrepl has been packaged in guix already? if not, any other recommended (and out-of-the-box guix-y) way of using cider? <rovanion>Can I define a channel URL to be on my local machine? I want to test package changes to an external channel. <minima>mekeor[m]: thanks for looking into this and getting back to me; i also understand it doesn't strictly depend on nrepl - but i was wondering whether there's a somewhat "established" way of doing this in guix, e.g. with an alternative repl <mekeor[m]>rovanion: yes, just use (url "/path/to/guix-channel") in your channel-list <rovanion>mekeor[m]: Tried that but got guix pull: error: Git error: unsupported URL protocol :/ <civodul>apteryx: i think they're a bit more powerful <mekeor[m]>rovanion: i might be mistaken then! wildly guessing, you could also try file:///path/to/channel, instead <mekeor[m]>rovanion: maybe also show us your channel-list? :) <rovanion>Just removed the introduction section to skip authentication. <minima>mekeor[m]: np! thanks for helping! <mekeor[m]>minima: "All popular Clojure build tools (Leiningen, Boot, Gradle, Maven) have the ability to run an nREPL server and most of the time you’ll probably simply use nREPL through them and end up using whatever nREPL version they happen to ship." https://nrepl.org/nrepl/installation.html <civodul>rovanion: "skipping authentication" should be a last resort :-) <minima>mekeor[m]: oh, this is cool! i suppose i can guix install maven then - let me see <mekeor[m]>rovanion: if so, i'd guess that guix assumes a protocol if auth is given <rovanion>mekeor[m]: Yes! I got it working now. Thank you! <mekeor[m]>rovanion: just for the record, did you keep the file:// protocol specifier, or not? :D <rovanion>Works without file:// too, when the introduction part is removed. <apteryx>civodul: did rekado_ push the fixes for the german and french doc pdf? <rovanion>So yeah, it was the introduction section of the record that made the code go into the SSH-case without inspecting the URL. <civodul>that may require synchronization with roptat <lechner>and this conversation probably belongs on #nonguix. Sorry! <apteryx>note to non-GNOME people wanting to experiment the GNOME desktop on Guix System at near-native speeds: you may be interested in trying the new xvnc-service-type (even as a local service) to "remote" to other graphical sessions via VNC. <apteryx>this works with any other graphical sessions too (thanks to VNC being desktop/WM agnostic) <apteryx>let's tackle these pesky desktop bugs! <shcv[m]>is there an NNTP bridge for any of the guix mailing lists? <rekado_>I fixed one of the problems in weblate, though <rekado_>(the other one had already been fixed) <mekeor[m]>shcv: iiuc, only the mailing list maintainers can enable that feature and know the url. i couldn't find it online :D <fennewald>Hey! I was doing an install of guix as a package manager on top of ubuntu, and my `guix pull` failed. I'm trying to view the build log, and am unsure if I'm missing something with how to view it. <fennewald>`bzcat <filename>` returns only `[ 35/ 74] loading... 94.6% of 37 files`. If I copy the file to a local dir, tar will refuse to extract it with `This does not look like a tar archive`. Is there some way to view the failure cause that I'm missing, or should I try to find alternative ways to debug <tricon>shcv[m]: now that you mention it, i want this. <shcv[m]>I guess it would be possible to set up a public-inbox mirror <shcv[m]>maybe I should try doing that; learn a bit about how to do things that way ***jesopo is now known as jess-o-lantern
<apteryx>none in guix. mono was also removed recently, due to bootstrapping itself from binaries <sneek>Welcome back gnucode, you have 1 message! <sneek>gnucode, GNUtoo says: I booted on Guix system on my laptop and I cound't install gnome-clocks: guix package: error: package gnome-clocks@42.0 does not support i686-linux <gnucode>GNUtoo: are you running a 32 laptop? <gnucode>Also, why does switching git branches make 'make' recompile everything? <gnucode>nckx`: I think I may be getting closer to getting opensmtpd-service to supporting proper filters. <gnucode>I am waiting on guix to recompile to test it out. <gnucode>I wonder if there is a way to make the guile compiler use the quick compiler when I am compiling guix locally. I feel like that would probably be ok with minor developing situations... <gnucode>I suppose that it does use the quick compiler for package definitions ... <apteryx>this-package-input cannot refer to particular outputs, can it? <apteryx>gnucode: if you had to go to an old branch before rebasing it to latest, many files will have their timestamp touched, triggering rebuilds <apteryx>you can avoid this by more efficiently rebasing/switching branches with 'git rebase HEAD branch-to-switch-to', to rebase the branch you're about to switch to on top of your current branch <podiki[m]>apteryx: in my experience this-package-input just uses the name of a package input, regardless of the output selected in the input list <apteryx>old NEWS "‘guix pull’ now embeds ‘glibc-utf8-locales’" -> perhaps we could go further and embed glibc-locales... for a better out-of-the-box experience for most of the world's citizens <apteryx>then we could quit with all this glibc-locales tips and other trippy details ***mark_ is now known as mjw
<rekado_>gnucode: that’s why I recommend using worktrees <apteryx>rekado_: yes, and it's not that big of a downside; compressed it's like 12 MiB <rekado_>oh…? I thought it was on the order of 900 MiB <gnucode>running ,build gexp in a repl gives me an error... <gnucode>I think I will try to reboot to see if that fixes it. <apteryx>900 -> 232 MiB. We should contribute compressed locales support for glibc. <tschilptschilp23>ouch, guix pull says build of /gnu/store/ygywhmyjlqazckpz6f1sgz545a15la14-guix-system-tests.drv failed <abrenon>same here ! (while trying a guix time-machine) <minima>the thread does indicate a possible solution but i'm not really able to make sense of it <minima>they say "Openjdk has two outputs: out and jdk." as if i could install one or the other <minima>am i missing any fundamental truth about guix that i'd never heard of? <gnucode>is anyone else having trouble using the ,build command that guix provides at the repl? <apteryx>minima: you can; the openjdk regular output provides just 'java', while the openjdk:jre provides the full devlopment environment, which includes javac, the java compiler <gnucode>specifically I can't seem to use it inside an emacs geiser repl <apteryx>minima: guix install openjdk:jre if you want the full thing <rekado_>JRE = Java Runtime Environment; JDK = Java Development Kit <minima>apteryx: oh... super, extremely helpful, but currently facepalming myself very hard for not... knowing this... <johnabs[m]>Can anybody point me in the direction of where the xorg-configuration(extra-config) form is written to modify the x-session? I didn't see what files were actually being modified in the manual when guix reconfigure was run, and I'm having some trouble getting my libinput touchpad configurations working :/ <tschilptschilp23>I might be overdoing it, I keep the system at e05e5342a0 as starting from 08d5152 gnome-online-accounts seems to have problems talking to gnome-keyring (or whatever happens in 'reality') <abrenon>aad4e4fc6bed seems to be working, it's only two commits ago and so I assume 1c528a95cb92b, which modifies the tests, is to blame ? <apteryx>I guess I forgot to register a module <unwox>johnabs[m]: xorg-configuration goes into according field of display manager service configuration *apteryx runs 'make as-derivation' <apteryx>[ 35/ 74] loading... 94.6% of 37 filesbuilder for `/gnu/store/ygywhmyjlqazckpz6f1sgz545a15la14-guix-system-tests.drv' failed with exit code 1 <apteryx>something I should have run before pushing ;-) it builds guix the way guix pull does <johnabs[m]>@unwox Sorry, that's not the issue I'm facing here I don't think. Do you mind if I send you a paste? <abrenon>(I guess this is a good practice whenever services are touched ? do you recommend it more generally than that ?) <apteryx>when adding or removing files, or variable I'd say <johnabs[m]>unwox: perfect, thank you! https://paste.debian.net/1256138 Basically, lines 41-45 work fine and fixed some screen tearing. But linex 47-60, when added, cause my display manager to fail to load, and my login prompt hangs at a black screen. <johnabs[m]>I understand that form accepts a list of strings, but I'm unsure if they're being placed in the appropriate xorg-config files when I reconfigure guix <johnabs[m]>Oh, and I can't input anything so I have to reboot. I'm assuming this is an xorg problem, but I'm unsure how to proceed to debugging from here, since I independently tested the libinput settings with xinput and it works fine. <apteryx>abrenon: perhaps not adding package variables, but renaming them. if you missed a reference it'd break guix pull <apteryx>that should be visible during a build though, if you're careful about its output <unwox>johnabs[m]: did you look at /var/log/Xorg.0.log? <unwox>it'll most probably have a full path to a config xorg tries to load <johnabs[m]>I've looked at parts for the libinput stuff, but I'll check it right now and report back momentarily <unwox>ah yes - you need to append \n at the end of every line with "EndSection" <unwox>otherwise guix outputs "EndSectionSection \"Device\"" to xorg config <johnabs[m]>Holy crap, let me try that. If that works, a) Bless you and <johnabs[m]>b) I didn't see that in the manual, did I miss it or can I propose an addendum to make that clearer? <unwox>or just remove " at the end of "EndSection" lines <johnabs[m]>unwox: Legitimately, thank you, I seriously appreciate it <johnabs[m]>I have been fighting with this thing for days, and I cannot believe that was it xD <unwox>yeah i had the same problem with this field 2 days ago :) <apteryx>abrenon: I've reverted the 'guix pull' breaking commit for the time being, the reason it breaks currently evades me <johnabs[m]>unwox: Yeah, can we add something to the manual/documentation for this per chance? I expected that macro would have "sanitized" the list entries in the form, hence me not considering it as an option. I don't see anything in the cookbook either that indicates this could be a potential issue <lechner>nckhexen: i did, of course, run 'guix build' for #55762 (linux-pam) but an attempt to use set! in my system config failed with this 'tracker' test, which seems to a timeout unrelated to linux-pam https://paste.debian.net/1256306/ <johnabs[m]>How did you figure it out? Was there a resource you used or was it a random "hail mary" sort of deal? <lechner>life can be better without strong language <unwox>johnabs[m]: i looked for logs then found path to config file and from there the problem turned out to be obvious <unwox>johnabs[m]: re manual/documentation improvements: you are welcome to send a patch <johnabs[m]>Ah, gotcha, that was going to be the next thing I tried (as per your suggestion) but originally I was grepping the logs to make sure I had the right entries and such. If I just read it, I may have caught it sooner...oof <unmatched-paren>I have this problem and another where when I try to do anything involving shepherd it refuses to let me connect to the socket <johnabs[m]>Okay, I think I may send that shortly, it's a minor change, but I think that it may be helpful for others in the future. <apteryx>abrenon: we can reproduce the failure by running the builder copied to a /tmp directory for debugging: env - out=/tmp/out PATH=$PATH GUILE_LOAD_COMPILED_PATH=/gnu/store/842yw56bqgirlxzd3fi63dbrr90i4yhr-guix-core-modules/lib/guile/3.0/site-ccache:/gnu/store/slshkll2jld1s6nkr6ylwj3bs5zqaad8-guix-extra guile /tmp/guix-system-tests-builder.scm <apteryx>removing the warning suppression in that code, we see: error: ratpoison: unknown package <apteryx>it occurs while loading gnu/tests/vnc.scm <abrenon>thanks for the follow up ! not sure how to understand the line where you describe how to reproduce the failure <rekado_>maybe you can break cycles by using module-ref <apteryx>perhaps expected given my command above lacks the /gnu/store/191knigzw11yypxr556vb248nsh818ki-guix-packages path <apteryx>my host /tmp; I copied the builder of the guix-system-tests.drv to be able to debug it <apteryx>perhaps build -K would have worked too :-) <abrenon>oohhh you mean a developper can actually directly use a .drv ? ^^ <abrenon>ok, so if I understand correctly you're editing the out field to control where the build is happening ? <johnabs[m]>Basically, I defined a backlight rule and I'm just doing a basic (cons (udev-rules-service 'backlight %backlight-rule %desktop-services)) as suggested in the docs. I placed it at the top of the (services ...) form, but this fails to compile. <jpoiret>johnabs[m]: can you paste the relevant part? <apteryx>abrenon: in the derivation builder (a guile script) the out part is gotten from the 'out' envionment variable <apteryx>so I set this to /tmp/out to satisfy it <abrenon>I didn't know $out could be used as an environment variable to override this <apteryx>got farther by simply setting GUILE_LOAD_PATH to the value passed to -L in the .drv <apteryx>this got rid of the unknown ratpoison variable error I had earlier <rekado_>got really close to building the zh_CN pdf manual, but for some reason it doesn’t like our use of @pxref{} <apteryx>I thought texinfo was technically preventing the use of non-latin encodings <rekado_>there are very fresh patches to add Chinese support <rekado_>I have created a texinfo variant with these patches, added missing fonts, changed a few minor things to select the new texinfo-zh.tex, etc <rekado_>spent a lot of time trying to figure out tex error messages… <rekado_>I’ll take ice-9 boot backtraces (due to a regression in Guile) any day over whatever TeX outputs. <rekado_>for example, it would print something like this: “TeX capacity exceeded, sorry [save size=80000].” <rekado_>turns out that this was due to a missing font, but you can’t tell by looking at the verbose error output. <apteryx>seems it fails to load /gnu/store/pyw7dawgfr1mw7djwijj89j9pniiiid9-guix-system/gnu/services/vnc.go <rekado_>I don’t think strace is going to help you here. <rekado_>does the Guile process die? Or is there some Guile error message? <apteryx>nothing, it seems to die, exit error is 1 <apteryx>I suspect an error while loading the .go, looking at strace <johnabs[m]>jpoiret Can do! Sorry about the delay, I was doing TA stuff :/ <rekado_>is it loading the .go? It says it’s loading a scm. <apteryx>I think so, it goes on to open the .go and starts doing stuff with it <rekado_>can you confirm that the scm is fine, though? <jpoiret>i suggest you remove that line and add "(udev-rules-service 'backlight %backlight-rule)" to the list given as the first argument to append <jpoiret>basically, the (append ...) part got outside of the (services ...) form in your code <apteryx>rekado_: ,load /gnu/store/2m9m9xd4v2dvqy7bpsrx7gzj1b67g1nm-guix-system-source/gnu/services/vnc.scm seems happy <rekado_>also a good idea to clear your guile cache <rekado_>when this works you can (load-compiled "the-file.go") <johnabs[m]>Just to make sure, I should put it in the (list) subform of the append statement, right? <apteryx>,load works on it, and (compile ...) also <rekado_>also in a fresh repl session and with .cache/guile removed? <rekado_>(just to be sure you’re not depending on any state) <apteryx>or removing gnu/services/vnc.go and gnu/tests/vnc.go and running make, it builds fine with no warning <apteryx>perhaps using specification->package is a bad idea in gnu/tests/vnc.scm? <apteryx>because it'll search its package collection, and I don't think it has the whole collection in scope <apteryx>so perhaps referencing the packages directly might pull them in <apteryx>just a guess, given I'm not seeing an actual error message <apteryx>yep, it's something to do with the packages field of the %xvnc-os <apteryx>if I comment it out 'make as-derivation' passes <apteryx>I'll try using explicit package variables instead of the specification->package <apteryx>tl;dr: never use specification->package as part of a system test OS declaration <apteryx>xvnc-service-type is back, without breaking 'guix pull' this time <rovanion>Update on grub not wanting to install: Apparently the UEFI entry is gonners, it has been deleted in some way. <tonos>Hello! Could somebody tell me if there is a way to call `guix pull' without compiling packages like python? (I do have substitutes enabled) <jab>tonos: you may need to wait a day or so. <jab>sounds like the substitute server has not compiled the recent changes. :) <tonos>that is what I thought, but the substitute for python 3.9 is available <tonos>I don't have anything against compiling, but my beaglebone does not appear to be capable <tonos>it gets stucked in the check phase <tonos>also, somehow the system ends up with many zombie processes ***maximed is now known as antipode
<reyman>i'm really interested to know why, perhaps a write something that break env <apteryx>tongong: it's "normal" to have zombie processes during builds, as the PID1 (guile script) doesn't reap them properly in the container <GNUtoo>gnucode: I'm running Guix i686 on my main laptop (X200) but I also have Guix on pure 32bit systems <GNUtoo>Though currently the build is broken for i686 (see bug #57931) + guix build -s i686-linux guix fails, though for that I still need to bugreport <GNUtoo>So I need review and help for some of my patches in that bug <GNUtoo>I also had some data loss so I also need to finish recovering from it to at least have a reliable mail system that doesn't block when you enter some folders <GNUtoo>for gnome-clocks I probably tried with x86_64 at some point though but I don't remember the result, I can retry if needed though <GNUtoo>Since it works in Parabola it's probably doable to fix it in Guix system somehow <GNUtoo>(X200 Parabola i686 + guix i686 => Works, guix system i686 => Fails)