IRC channel logs
2023-05-25.log
back to list of logs
<vagrantc>wow, "make -j5 check" is ... really taking a very long time. <vagrantc>seems very busily stuck on tests/guix-pack-relocatable.sh <mirai>that test always took a while <mirai>and I think it's not the only long test <vagrantc>it seems near the end ... e.g. all the *.scm tests are done <vagrantc>i haven't pushed many of my own patches since the changes to the contribution recommendations... mostly probably a good thing. :) <apteryx>mirai: i've force-merged them I think; I was experimenting with 'mumi send' <apteryx>ACTION is contemplating trying to fix the jami system tests, again <apteryx>they work fine when exercised in the %jami-os VM <apteryx>ice-9/eval.scm:159:9: no code for module (fibers) <apteryx>seems using blocking sleep stopped working inside shepherd 0.10.0 <neshamon[m]>I'm getting an error that says, duplicate rottlog entry for /etc I did a little research in the src code and it usually gives that error to prevent duplicate derivations from being built. <neshamon[m]>But how would I go about solving this? I already tried deleting the rottlog service in %base-services to prevent duplicate rottlogs being appended to %base-services. But when I do, it just says that rottlog-service-type is unbound <neshamon[m]>I also imported the admin service file with use-service-modules which is where rottlog-service-type is defined. But guix still says that rottlog is unbound <mirai>apteryx: what's the current issue with jami? <dcunit3d>i worked through bumping python-yubikey-manager, pyscard and python-libfido2 on my local machine, but then it still requires a newer version of poetry to build some of these... and i don't really know what i'm doing here anyways <sammm>hey - I'm trying to run cargo update after installing rust / rust-cargo and am getting a segmentation fault when libgit2.so is called - has anyone gotten this before? <civodul>sammm: hi! i don't use cargo, but as a first step, could you make sure LD_LIBRARY_PATH is unset? <civodul>(to make sure it's not loading "wrong" .so files, esp. if you're on a non-Guix distro) <sammm>sure, i'll give it a go civodul <sammm>same deal, `ldd` shows that the file has been linked to all guix store .so files too <civodul>ok, then i'm afraid i won't be of any help <civodul>might be worth asking on help-guix@gnu.org or reporting it on bug-guix <civodul>(preferably with a backtrace from gdb) <chomwitt>following the main website i dont find instrustions on how report bugs except an 'email bug-guix@gnu.org to submit a bug report.' <mekeor[m]>neshamon: maybe share your system's config.scm <mekeor[m]>ieugen: what do you mean by "meta-command"? could you maybe paste the buffer with the error? <chomwitt>the guix issue tracker (GIT :-) !) allows to use tag for searching. but how do we add tag to our bug report email ? <jpoiret>mumi is just a front-end to the venerable debbugs, specifically the gnu instance of it. To add tags, you can send a mail with `control@debbugs.gnu.org` as either the To: or in Cc:s, with the mail starting with `tags <ISSUE_NUMBER> + yourtag` then `thankyou` to end the commands <jpoiret>emacs-debbugs also has an interface for that <chomwitt>jpoiret, thanks. may i ask what mumi stand for ? <mekeor[m]>chomwitt: i.e. send a mail to control@debbugs.gnu.org with body "tags BUGNUMBER + TAGNAME" <chomwitt>reading the relevant info. Why to `control@debbugs.gnu.org` and not bug-guix@gnu.org ? <cbaines>any ideas to fix things on armhf-linux? substitute availability is ~79% and it would be nice to push it over the 80% line. <civodul>cbaines: hey! 79%, really? even for x86_64 i'd find it rather good, given the core-updates fallout :-) <cbaines>it is good, I just want guix weather to say so :) <cbaines>I currently see 96.0% substitute availability for x86_64-linux, although that's the data service number which I think can be higher than that reported by guix weather <jpoiret>cbaines: you're not going to like my solution then đ <cbaines>like tactical removing armhf-linux from the supported systems of some failing package <cbaines>"if you try to build less, less things can fail" <civodul>it's likely that some things are indeed not supported on armhf, just not marked as such <civodul>make mariadb unsupported and gain 1% :-) <cbaines>I do wonder why there's so many dependents, and maybe something can be done about that <cbaines>like I'd expect mariadb to be a leaf package <civodul>weird thing: if i do "guix build hello --check" on a live Rocky image, 'tar' gets EACCES while creating files in /tmp/guix-build* <civodul>since /tmp is on tmpfs, i wonder if there could be "something" going on <civodul>doing a brain dump in case someone has ideas <rekado>civodul: re 62487: it matters how a process is started <rekado>SELinux is all about context transitions <degauss>Hi! Semi-OT question: Does anybody see emojis having the "VARIATION SELECTOR-16" (like đď¸) in Emacs with a super-wide cursor (i.e. with a lot of whitespace after the character)? <rekado>processes launched by the init system all start in a certain context, and the rules must permit certain transitions <civodul>rekado: i think i got SELinux straight: "ausearch" doesn't report anything at this point <civodul>(i added a rule to allow guix-daemon to remount /gnu/store) <civodul>if it were an SELinux violation, it would show up in "ausearch", right? <rekado>is there still a difference between running guix-daemon manually and launching it via systemd as mentioned in the bug report? <civodul>i'm running it from systemd now, but i can try <civodul>substitutes and builds that don't touch /tmp/guix-build (like profile hooks) work fine <rekado>in the past I found that for unknown reasons Guix processes would appear in the SELinux logs under the wrong name <rekado>e.g. instead of âguix-daemonâ youâd get â(x-daemonâ or similar <rekado>so my recommendation is to not search the SELinux logs but tail them unfiltered <civodul>damnit, it works when i start guix-daemon "by hand" <rekado>that suggests a missing context transition <civodul>found "tar" in the audit log, with "openat" denied <civodul>rekado: found it: i had to duplicate the tmpfs_t rule we have (with create, open, etc.) but with tmp_t <civodul>obviously i don't know what i'm doing, but it works <phf>Hello Guix! I keep having this error =Error: Can't open display: :0= inside a Guix Shell Container even when built using this command: https://paste.debian.net/1281109/ . Can someone help me make it work? Thanks. <civodul>patched[m]: i was going to ask what you meant by "bold" but now i see :-) <andreas-e>Hello! A quick message for knowledgeable people from guix-sysadmin; I just sent an email wondering why cuirass seems to be stuck and not building things. Advice welcome! <civodul>phf: you may need to --expose=/tmp/.X11-unix too <dcunit3d>is there any order to the packages in emacs-xyz.scm? <civodul>andreas-e: hi! is it producing new evaluations? <dcunit3d>i see some categories bundled together but it's not clear <dcunit3d>i'm looking at submitting a patch for emacs-x509.el <phf>civodul: great, thank you! It works! <andreas-e>It produces evaluations, there are scheduled builds, but no actual builds. <dcunit3d>i have 'openssl' as a propagated input because it depends on that for some commands, but not to build AFAIK. i can check though. either way, there is a (defcustom openssl-cmd ...) <civodul>andreas-e: cuirass-remote-worker.log says the database worker refuse to answer calls <andreas-e>All of them? Trade unions would love to have such a following! <andreas-e>Okay, yes, I also see database problems for computing average build times. <civodul>i just restarted cuirass-remote-server, to no avail <civodul>after restarting the whole thing ("herd restart cuirass"), we're good, it seems <civodul>i have a difficult relationship with databases <andreas-e>I see no more database warnings. Maybe we need to wait a few minutes. <cbaines>In other news, the qa-frontpage now looks for issues about merging branches and submits the builds automatically, so some more builds are now happening for tex-team <andreas-e>Is there a special format for the merge request subject in the issues? Or does anything containing the word "merge" and a branch name will work? <andreas-e>cuirass-remove-server and cuirass-web were stopped, and I have just restarted them again. <andreas-e>Strangely enough, the log files are still being filled. So the services are stopped, but still running? <minima>i still seem to be experiencing weird and hardly debuggable network hiccups on my guix on foreign distro; i made sure nscd is installed and i restarted the service but the problem still seem to be there - anything else i might be thinking of / checking? <mekeor[m]>i think i just flooded the help-guix mailing-list a little. sorry for the noise! <civodul>andreas-e: i think there's an interesting shepherd bug on berlin (at last!) <civodul>looks like there are "shadow services" still acting in the background <civodul>like cuirass-remove-server is marked as stopped <andreas-e>Interesting bug, hm. I take it as a good excuse to do nothing and to be happy for you to get this unique occasion to debug shepherd further :) <civodul>but if you kill the cuirass-remove-server process, it gets respawned <rekado>shepherd says itâs stopped and disabled <rekado>but killing the process just leads to having it respawned <rekado>re bold: the CSS hasnât changed, so I guess the HTML is generated differently now <rekado>the cause is the rule .settitle, .top, .chapter, .section, .subsection, .subsubsection { <rekado>I suppose the assumption was that these classes would not be attached to divs <rekado>another problem seems to be that âfira sansâ is only provided in bold <next4th>cbaines: seems my risc-v agent always downloading guix-packages-base from bordeaux, and timeout :\ <cbaines>next4th, could you send me some log output? <cbaines>next4th, if you try to download that nar with wget/curl, does it finish downloading, and how long does it take? <next4th>it indeed slow/stuck, wget starts with 8KB/s, and now --.-, eta 90m.. <civodul>rekado: re shepherd, i'll investigate hopefully later today <civodul>has to do with replacements, which are used when one reconfigures <civodul>i guess i was lucky to not notice before <cbaines>next4th, I'm guessing this happens with all nars from bordeaux.guix.gnu.org, but it would be good to confirm <next4th>cbaines: yes, it happens with all, since I just have a very bad connection to bordeaux. <cbaines>next4th, if you don't mind me asking, where in the world is this machine connected to the internet? <dcunit3d>k, well i just sent in the patch for emacs-x509 without the propagated input, since it can be set in emacs <next4th>its ISP called CMCC, one of slowest, but cheap :\ <cbaines>maybe there's something we can do on the server end to speed things up though <cbaines>we have the software for running reverse caching proxies, which might help <cbaines>I'll send an email to guix-devel about download speeds <next4th>yes, a proxy should help, i'll beg some friends for one (i don't want to maintain one myself) :) <next4th>okay, thank you. i just feel a little guilt that my sbc agent will contribe negative to the build farm by stucking jobs :\ <cbaines>that's fine for now, there's no shortage of things to build for riscv64-linux :) <cbaines>I used to run a mirror in singapore, but shut it down as I didn't think it was that useful <next4th>yeah, i now asking in #guixcn, once there had one running mirror (but now use a university one for ci) <civodul>cbaines: does the Coordinator still deserve 0.0.1? :-) <cbaines>civodul, haha, I was looking at this yesterday as I want to better monitor the versions of the agents <cbaines>I think it's time to introduce some simple versioning, then have the guix package use that <davidl>civodul: what do you think of having a transform option --with-upstream-builder, that runs guix.scm from the package's upstream source, like this: guix build hello --with-git-url=hello=<someurl> --with-upstream-builder=hello ? <davidl>or maybe not directly runs, but makes use of it. <dcunit3d>i'm trying to build poetry-1.4.2 and i'm running into a "trove-classifier" error. does anyone know what that means? <apteryx>civodul: Hi! The first commit that broke the jami service tests is a09c7da8f8d8e732f969cf0a09aaa78f87032ab1 ("tests: Fork and exec a new Guile for the marionette REPL.") <apteryx>IIUC this makes each marionette instance start in a fresh environment, e.g. not sharing environment variables and such? <civodul>apteryx: hi! yes, that's plausible (i fixed some in f51888272558d98cf5c196b93fb6c499056fbf6c and related commits) <civodul>so yes, the marionette process no longer inherits env vars from PID 1 <civodul>(it's started with make-forkexec-constructor now) <apteryx>reverting it fixes one of the 3 failures, so it's one of the reasons <apteryx>(it makes sense, the first "test" is just setting up the environment for the rest) <mirai_>unrelated to apteryx comment, must the system tests always âblankâ the terminal? could they run on background (like the regular tests) <apteryx>mirai_: that's not the system tests fault, it's SeaBIOS sending a clear reset ASCII escape <civodul>mirai: also, you could do "guix build -v1 -m etc/system-tests.scm" or similar <mirai>It makes running the system tests in parallel tough <cbaines>next4th, maybe change your riscv board's configuration to try that mirror first then <civodul>apteryx: relevant differences compared to before that change could be PID 1 env vars no longer inherited and modules available in PID 1 no longer in scope <apteryx>I tried looking into it before, it's annoying to loose the beginning of teh test scroll back <mirai>I'd like to get a simple plaintext log a la regular tests (and if for some reason need the old behavior, to use something like `make check-system TESTS=foo HOOK_MONITOR=1` <apteryx>civodul: another clue that I got from lots of pk is that it's just the dbus querying procedures that fail in the marionette environment; e.g. (dbus-available-services) <next4th>cbaines: done, it seems works fine now, thank you! <cbaines>next4th, awesome, I'll try to message guix-devel later today about mirrors. We should try again to identify where people struggle accessing the european servers and if/where mirrors would help. <cbaines>next4th, it sounds like China has big access problems, but hosting mirrors in Singapore seems to be a big help <apteryx>civodul: I don't quite understand f51888272558d98cf5c196b93fb6c499056fbf6c; it removed with-imported-modules in favor of some test setting these up <civodul>apteryx: yes, i think there was some layering confusion: we need the dbus-related code loaded in the marionette process, not in the process that drives the VM <civodul>oh actually, the 'setenv' call is probably misplaced as well <civodul>we need DBUS_SESSION_BUS_ADDRESS to be set inside the marionette <apteryx>that'd explain the dbus only code failing <apteryx>it's a pity that error reporting is so opaque <civodul>yeah maybe guile-ac-d-bus swallows the actual error instead of throwing <civodul>rekado: did you eventually find out the reason for "boldness"? it's really ugly <apteryx>sometimes we have to use (flush-all-ports) to see the errors <mirai>perhaps that last line break for Copyright? <mirai>the last entry usually doesn't need @* <civodul>most likely as discussed earlier today, it has to do with newer Texinfo generating slightly different output <mirai>eeh, make doc/guix.html only gives me a very simple rendering of the doc <apteryx>inside doc/: guix build -f build.scm <mirai>the process takes quite a lot of time <mirai>I was expecting that it would be a relatively quick process (for postprocessing) <dcunit3d>so i recently reconfigured my system to use greetd for wayland/sway, but my /dev/ttyN devices are all owned by root (after login), except for the VTY where sway would run. so for example, emacsclient doesn't work unless the server was started in the same tty. <dcunit3d>however, the real problem is that the SCDaemon for GnuPG can't grab control of the tty to read input. so i can't use my yubikey GPG to sign commits or SSH to anything. if I chown the tty to `dc:tty` like a caveman, then suddenly the SCDaemon works as normal. is there some reason that greetd doesn't transfer ownership over the TTY? should it? <jpoiret>this should be handled by your seat manager, which is commonly elogind (or seatd if you want to go the experimental/minimalist road) <dcunit3d>jpoiret: yes, i removed the login-service-type and added an elogind-service-type <jpoiret>greetd is orthogonal to elogind, and is not a replacement for it <dcunit3d>ok, thanks! :) this was super confusing for me. i was trying to update some of the python packages in a manifest to see if that would fix it, but i remembered the problems with emacsclient. <jpoiret>dcunit3d: are you using the essential-services of your operating system? <jpoiret>rather, what does /etc/pam.d/greetd say? <jpoiret>it should mention pam_elogind.so on a session required line <mirai>civodul, apteryx: interesting, locally the documentation seems to be fine, even after the preprocessing step <civodul>mirai: built with "guix build -f doc/build.scm"? <dcunit3d>i guess i'll need to do a deep dive on it <jpoiret>ah, but hang on, why do you need another tty? <mirai>civodul: make -j8; make doc/guix.html; cd doc; ../pre-inst-env guix build -f build.scm <jpoiret>that's the whole point, only the tty you're logged into is owned by you <dcunit3d>i'm using that, screen and emacs for now. <jpoiret>even though elogind lists the other tty for the other session <dcunit3d>i went the paranoid route when setting up GPG (which i'm regretting). I change over to the TTY to enter the pin <dcunit3d>i was thinking about doing this in sway now anyways bc it's prone to too many problems. <jpoiret>wonder why you want to use a tty instead of sway for this though <jpoiret>my secondary display is now stuck on the tty2 login image now though <dcunit3d>do you have wlgreet set up on multiple terminals? <jpoiret>I only use agreety, didn't really want to use any shiny things for my greeter <dcunit3d>i may try to see if something like that can launch bash bc i think it will work <mirai>it looks like a âtoughâ situation <mirai>from what I'm understanding from the report, upon a reconfigure shepherd âupdates its pointersâ to the new values from the new configuration <mirai>it's an odd position to be in, since a config.scm doesn't really say what is to happen between a âconfiguration transitionâ <mirai>in shepherds case, perhaps you could synthesize config.scm into a list of âtasksâ that are sent to a shepherd queue <mirai>so a service replacement (or removal) would be interpreted as a sequence of commands to shepherd: (stop foo), (unregister foo), (register new-foo), (start new-foo) <mirai>huh, it looks like meson-build-system LIES when it comes to tests <mirai>phase `check' succeeded after 0.2 seconds <mirai>apologies for the trailing spaces <civodul>the boldness issue in the online manual should be fixed now, but be sure to hit Ctrl-F5 to clear your cache <civodul>symlinks on identifiers are gone though (post-processing issue) <apteryx>civodul: thanks for fixing the boldness issue! <MatoHota>I have a fresh installation of guix in a Rocky Linux 8 VM - may I ask a question about this setup ? <jackhill>MatoHota: sure! No promises of an anser though, but we can try :) <MatoHota>I'll try a fresh install with the latest guix-install <MatoHota>hopefully I have downloaded the git repo :) <MatoHota>after a fresh install I still have the following issue : guix substitute died unexpectedly <MatoHota>I have checked, the installer from this morning wasn't up to date <MatoHota>I have fetched the last version, I hope it will do the trick <civodul>the SELinux policy won't be up-to-date <civodul>that could create problems, unless you turned SELinux off <mirai>I'd so like to see substitutes via bittorrent <mirai>that day couldn't come any sooner <mirai>test-building for other arch is always a pain since it involves fetching loads of packages <apteryx>cbaines: hi! just checking; does QA run the system ("integration") tests as well as the regular "unit" tests? <spacecadet[m]>I'm trying to get initrd to bind the vfio-pci driver to some pcie devices on boot, but (initrd-modules) and (kernel-arguments) aren't doing it. I think the driver_override sysfs option needs to be set but I haven't found a way to add scripts to the initrd to test this, anyone have experience here? <dcunit3d>i'm trying to build sov, but there's something that's forcing wayland 1.20 in the derivation, how do i figure out what that is? i generated package & referrer graphs for what I could think of. <rdrg109>[Q] How to define a package that downloads multiple files from a website. So far I have only defined packages that download a single compressed file that contains multiple files. Is there any package in the Guix repositories that I could take as an exmaple? I want to download all the *.otf files shown in CTAN: https://ctan.org/tex-archive/fonts/fandol <ngz>rdrg109: guix shell subversion -- guix import texlive fandol should get you a working package for that. <ngz>rdrg109: Basically, texlive-origin is fetching files from multiple locations, specified as a list of sub-directories. <rdrg109>Ok, that printed the package definition which I was trying to write. That was like magic. How come I didn't know about this? Which of the commands is responsible of printing the Lisp expression? I suppose it's "guix import". I'm not familiar with this subcommand yet, I'm going to read its Info page. <ngz>rdrg109: See the `tlpdb->package' function in "guix/import/texlive.scm". <ngz>rdrg109: Note there is some work going one to alter the output, which is a bit baroque with the `simple-texlive-package' function. <mirai>lilyp: re #63721, the package is to be split into 3 outputs, am I reading it correctly? <mirai>if going with the second option <mirai>I think the manpages and the HTML manual are different (the HTML version contains additional info) <mirai>I didn't split the manpages from the main output but I could <spacecadet[m]>can anyone else boot with raw-initrd? I'm getting loadkey errors that drop me to the repl, do I need to completely configure the initrd if I'm using raw-initrd? <spacecadet[m]>kinda answering my own question, base-initrd uses raw-initrd, the latter is "unconfigured", the docs mention this but I neglected to read that paragraph. Now I'm just struggling to figure out how to best inject extra packages into base-initrd. <civodul>mirai: in hindsight, i think we should be using "@deffn {Procedure}" instead of "@defun", to use vocabulary consistently <rdrg109>ngz: Any ideas on how I can import simple-texlive-package? This is the package I've defined: http://0x0.st/Hqv9.scm This is the error I'm getting: http://0x0.st/Hqvp.org . Someone else asked the same question in January this year and he was told to use (@@ (gnu packages tex) simple-texlive-package) , but I don't know how to use that in my package definition. I've never used the "@@" structure in a <ngz>rdrg109: I think instead of (simple-texlive-package ...), you write ((@@ (gnu packages tex) simple-texlive-package) ...). <spacecadet[m]>can someone help me figure out how to spawn a shell from the guile repl in early boot? I thought (system "/bin/sh") would work but it returns 32512, so I assume the link isn't there yet <spacecadet[m]>never mind, (system) returns false so I guess that's not going to work