IRC channel logs
2024-07-21.log
back to list of logs
<jfred>If you're using build offloading and a build fails, how can you see the logs from the failed build? <eikcaz>Are there uniform rules for linting services? I see a lot about package definitions, but nothing about services <adi-lb-phoenix>So I have a repository I want to build using "guix package -f installationation_program.scm", that repository has CMakeLists.txt, how do I utilize that in guix while building it up . Do I have to mention any of them in arguments or input keyword. The instructions used to install the repository is https://paste.debian.net/1323864/ , I am using <civodul>lilyp: hey! could you add the gnu/tests/emacs.scm to gnu/local.mk? <civodul>would be nice to have comments explaining what is being tested <civodul>(i should have payed attention to guix-patches earlier i guess) <lilyp>what would you like for a comment? <civodul>at first sight i see there’s something about checking ABI compatibility, but i don’t understand what the problem is <civodul>so maybe giving a bit of context would help <civodul>it may be that a couple of lines would suffice <lilyp>there are some lines in the emacs package, that explain things – should I also add some comments to the tests themselves? <attila_lendvai>in `make check-system TESTS="git-http"` nginx returns http code 500 (general error), and the error.log is empty. access.log contains a single line: ""GET /git/test/info/refs?service=git-upload-pack HTTP/1.1" 500 5 "-" "git/2.45.2"" <cbaines_>attila_lendvai, I suspect a git upgrade has broken this test <cbaines_>my Git server stopped working, and I had to hack some gitconfig thing in to mark the directory as safe <cbaines_>there might be some Git errors in the fcgiwrap.log file <attila_lendvai>yep, "fatal: detected dubious ownership in repository at '/srv/git/test'". now, this is a detached, or headless, or whatever its called .git directory, and the `git config --global --add safe.directory <Git folder>` solution doesn't seem to work <cbaines_>I've hacked around this by setting fastcgi_param GIT_CONFIG_SYSTEM in the NGinx config, but hopefully upstream will come up with an easier approach <attila_lendvai>i give up, i cannot make this work. i've added `git config --global --add safe.directory '*'`, `chown -R nginx:nginx /srv/git`, and git is still complaining about dubious ownership... <civodul>z572: ok but why would we need a different date on some platforms? <z572>Maybe the output of busybox's date and coreutils's date are different. <z572>or just disable libfaketime's test on 32bit platforms <z572>But you may encounter many mysterious errors later because of mixing abi <z572>For fast merging of core-updates the second one might be better <civodul>z572: “the second one might be better”, which one? <bdju>noticing btop visually freezing/breaking a lot lately and having to restart it. running it inside tmux if that matters, but that's what I've always done. <z572>civodul: disable libfaketime's test <z572>Because if you choose to modify coreutils, other packages that use gnulib also have corresponding problems, you may need to check all packages that use gnulib and force gl_cv_type_time_t_bits_macro=no. <civodul>z572: modifying coreutils is not an option (more generally, switching packages that do have _TIME_BITS=64 to 32 isn’t an option IMO) <civodul>does disabling libfaketime tests really help? <civodul>maybe we could for these tests to be built with _TIME_BITS=32? <civodul>i mean, if libfaketime’s tests fail, then there’s a possibility that everything that tries to use it won’t work either <z572>In fact, disabling libfaketime tests allows nss tests to pass <z572>The libfaketime test failed because coreutils used 64-bit time <cbaines_>I think libfaketime is ineffective though <civodul>what about having a libfaketime variant with _TIME_BITS=32, which we would use for nss? <cbaines>the test failure on i686-linux for libfaketime is because it doesn't work <z572>You can try libfaketime on busybox's date and it works <civodul>yes, because busybox is built with _TIME_BITS=32, unlike coreutils <z572>because ours coreutils use "bad" versions of gnulib <civodul>in that we should aim for building everything with 64-bit time_t <civodul>(unlike Fedora & co., we don’t run the risk of discovering ABI incompatibilities the hard way) <cbaines>what's required to make that change? I'm guessing it's not completely automatic <cbaines>ok, so the Debian page mentions gcc being changed to enable this by default, and build systems adding -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 <z572>Yes, are we going to do the migration to t64 in this core-update? <cbaines>z572, I don't know, I'm also not sure what state everything is in as it seems like coreutils is either partially or fully using 64bit time <z572>t64 is automatically enabled for some packages using gnulib (including coreutils), but others that do not use gnulib default to t32 <z572>Is a very bad state of mixed <z572>There will be a lot of mysterious mistakes <civodul>z572: well, the main issue is libraries: they should be consistently using 64-bit or 32-bit, not a mixture of both <civodul>independent programs like Coreutils or Busybox can be built with 64-bit time_t without problem <dgr>system init is installing only grub.cfg under /mnt/boot/grub how do I debug this? <cbaines>is nss being built for 32 or 64 bit time currently (on core-updates)? <civodul>i was looking into passing -D_TIME_BITS=64 <z572>"OPTIMIZER=-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64" <z572>but "starting phase `check'" "Caught Segmentation fault" <civodul>z572: did you get a backtrace with gdb or something? <civodul>i’m afraid i won’t have much more time today to investigate <z572>I'll try it tomorrow, it's already bedtime in my time zone <eikcaz>How long does it take for a patch set to get acknowledged? <z572>civodul: ./pre-inst-env guix shell libfaketime gdb bash-minimal -s i686-linux --with-debug-info=libfaketime -C -- gdb --args faketime 2024-01-23 bash <z572>"Caught Segmentation fault" is bash reporting an error <Guest67>Is there a tutorial to download guix packagemanager for macos (apple-silicon)? Thanks for any feedback <eikcaz>Guest67: I suggest trying "brew search guix" if you have homebrew installed, or the equivalent for some other macos package manager. <eikcaz>Oh wait, new mac has it's own system architecture. If you have a newer mac, I find it very unlikely that you will be able to get guix running outside some sort of virtualization. <z572>I don't think guix will run directly on macos <eikcaz>I see people get it working via qemu. <xerty>Re: <eikcaz>: There's some tutorial that can use guix to infect asahi fedora remix into guix system, but it would need the kernel with some nonfree code in it. So I would not post the link here. Though it is rather trivial to run guix package manager as a foreign package manager only on the Remix. <ohyllad>I would like to make my yubikey available to a browser running in guix shell --container, is there any simple way to pass it in? <eikcaz>It seems the patch email I sent 8 hours ago had an incorrect "From" header. I just resent it with the correct header. Is it posible for someone make sure that the corrected version is the one that makes it to the actual patch list? <msglm>Hello there, im having trouble writing a package definition for the following program <msglm>I'm able to get it to compile but it complains about missing libraries upon running. These libraries are .so files that end up compiled in the /source folder. I want to get them into the output's /lib folder and then have the python script (koboldcpp.py) recognize them. I can send code upon request for those who wish to help. <eikcaz>msglm: do the .so files come with the source, or are they generated as part of the build? <msglm>generated as apart of the build <eikcaz>weird. Ideally, you would modify the invocation that generates them to instead write them to lib/. Short of that, you could add a phase that just copies them over. <eikcaz>Something like #:phases #~(modify-phases %standard-phases (before 'check (lambda _ <forms to copy files here>))) <msglm>I think the reason why that it puts the .so files into the source tree is that the program expects you to run it from a python script (it's written in C, but called in python for a web server) and that reads the .so files from that dir. <msglm>what would the <forms to copy files here> be, i'm a scheme newbie and only really use it to make packages for guix. <eikcaz>In 7.2.3 of the Guile manual, I see (copy-file oldfile newfile). If the list of .so files is short, you could just have a few of those. <eikcaz>If it's a lot of files, I'm sure a higher level wizard here could suggest a way to itterate (I assume all .so files are in the same directory). <msglm>they are in the same dir. I could do a list by hand, but I want it so that the package is configurable with just flags so people can run their own variations (i.e, adding more dependencies for back-end support). having it move all .so files to the lib and then telling the python script to use it would be useful for that. I'll try the copy-file <msglm>method to see if it works for now. <eikcaz>newfile should be (string-append (assoc outputs "out") "/lib" <.so file name>) <msglm>ok, just tried as suggested and its not working, getting the following error: <msglm>source expression failed to match any pattern in form (%modify-phases phases* (add-after (quote build) (quote install-compiled) (string-append (assoc outputs "out") "/lib/" "koboldcpp_clblast.so") (string-append (assoc outputs "out") "/lib/" "koboldcpp_default.so") (string-append (assoc outputs "out") "/lib/" "koboldcpp_openblas.so") (string-append <msglm>(assoc outputs "out") "/lib/" "koboldcpp_vulkan.so"))) <ngz>msglm: It should be something like the following: #~(modify-phases %standard-phases (add-after 'build 'install-compiled (lambda _ ... (for-each (lambda (f) (copy-file f (string-append #$output "/lib"))) (find-files "." "\\.so$"))))) <ngz>%modify-phases would refer to a global variable, but it is a macro. Also, phases are functions, but you try to add a list of strings after 'build phase. <msglm>Ah I see. that makes sense. recompiling now to see if this works. <ngz>Thinking about it, `install-file' is better than `copy-file'. <msglm>I was going to ask about that. I did write a similar command before using install-file, but it broke due to me improperly using the lambda functions. <msglm>okay getting an annoying error with the suggested fix: <msglm>it's complaining that it can't find the file, tossing out "system-error "copy-file" "~A" ("No such file or directory")" <msglm>I did notice that this is the command it is running though: <msglm>(copy-file "source/./koboldcpp_clblast.so" "/gnu/store/…") <msglm>I can confirm that "koboldcpp_clblast.so" is under the source folder, but I do not know if the /./ is messing with guile in some way. <ngz>Have you tried with `install-file'? <msglm>yes, just did. I think install-file uses copy-file in some form since I had a similar problem when using it before. <ngz>It uses `copy-file' but also makes sure the destination exists. <ngz>msglm: So, you get the same error with `install-file'? <msglm>yes, that error with copy-file actually came from when I used install-file. it's odd. <ngz>Could you send your current package definition to a pastebin service? <msglm>sure, give me a moment to do that. <msglm>build kobold.cpp to get what im trying to do <ngz>msglm: Could you also paste the complete backtrace? <msglm>the version I sent you for some reason compiles properly, but running it gives an error with customtkinter <msglm>im currently trying to figure out why this is the case <msglm>actually, turns out I fixed it during one of my last changes. the .so files are in /lib. <msglm>Now I need to find a way to get the python script to recognize those lib files <attila_lendvai>how much disk space do i need to cross compile the kernel for arm on x86_64? <attila_lendvai>seems like 100GB may not be enough (including whatever needs to be downloaded into /gnu/store) <msglm>you might find your answer in the documentation for guix size. <msglm>Also I think you can set the TMPDIR environment variable to change the building location which may help on reducing size requirements. <dckc>How do I add magit to a running emacs in the guix way? <dckc>this emacs came from `guix shell emacs emacs-geiser-guile ` <dckc>yay: `guix search magit` works. (boy is that better than nix!!!) <dckc>guix install emacs-magit ... emacs-magit 3.3.0-7.dda332b ... <civodul>dckc: there’s emacs-guix, which lets you install/browse packages via M-x guix <civodul>and IIRC it loads .el files when the thing you install is an Emacs package <dckc>meanwhile, I now have emacs-magit installed; how to I get the running emacs to... um... grok it? <dckc>hm. I can't tell what M-x guix did. I don't see an error, but I don't see any effect either. <dckc>I guess I didn't have emacs-guix installed. I wonder why I got no error <dckc>maybe time to... (oh no!) restart emacs :-/