IRC channel logs
2023-10-17.log
back to list of logs
<VesselWave>VesselWave: I just don't like packages being declarative <snape>VesselWave: I think you can still use your ~/.guix-profile profile <snape>~/.guix-home can be declarative while ~/.guix-profile is not <VesselWa`>snape: You mean I can declare no packages in Guix Home definition and still have everything I installed via "guix install". If so, thank you! <snape>VesselWave: yes that's what I meant. You can check your $PATH to check ~/.guix-profile/bin is still there <bdju>anyone working on updating the qutebrowser package to use qt6 yet? some websites are misbehaving lately and it sounds like using qt6 might help (I'm not planning to try, to do it, just wondering) <gnucode>bdju: I think guix should package ladybird... <bdju>put it on the wishlist on libreplanet if it's not there yet <jaeme_>cargo-build-system is skipping test phase by default? <jaeme_>Is this going to be a permanent change going forward? <lilyp>jaeme: there's a saying that nothing's more permanent than a temporal solution; I think we'd all like to see cargo replaced by antioxidant like, any time now, but I have yet to hear an ETA on that <zeropoint>is anyone aware of a utility to import an entire directory into the store like local-file but for a directory? <lilyp>local-file has recursive? #t <attila_lendvai>so, i want to upgrade rocksdb, but the latest ceph doesn't compile with the latest rocksdb. ceph has a bundled rocksdb, and unbundling it from this complex piece of software takes over quite some headache from the cepth developers. <attila_lendvai>i'm wondering... is it worth it? what shall i do to resolve the headache? admit that bundling is reasonable for complex packages? have two versions of rocksdb? i'm not even sure they don't have their own patches in their rocksdb fork... <attila_lendvai>if they have local fixes to their rocksdb fork, then this is a good example that too eager unbundling can lead to broken software. sometimes subtly so that may lead to loss. <attila_lendvai>they have all kinds of branches, tag, and commits. i can't even easily check whether their fork contains crucial commits, or just an older state of upstream <attila_lendvai>ACTION gives up and creates an updated rocksdb package for his own package (not suitable for guix; in a separate channel) <apteryx>maybe worth reporting your pain packaging their stuff, and that it couldn't be included in Guix proper due to the messy bootstrap <mothacehe>I'm having a look to the system test failures now that the missing .drv errors are gone :) <efraim>on the other hand, I'm missing a bunch of drvs from the rust-team, had to go and re-create them :) <civodul>efraim: ah, that might be because the rust-team evaluation that produced them was a bit old, from before the recent fixes <efraim>once I got the hang of it I was able to re-create them with time-machine and 'build -d' <civodul>mothacehe: BTW, i think i’ll tag Cuirass as “1.2.0” soon <civodul>i think it improves legibility to have release tags every now and then <mothacehe>that justified given the amount of improvements :) <apteryx>the build system seems to have support for gexps <rekado>apteryx: what does the generated builder code look like? <civodul>or maybe (if (pair? …) …) to mirror the one below <rekado>does anyone know what steps I need to follow after adding nix-service-type to my system? <rekado>I really just want to look at a few nix derivations <apteryx>I think you need to put source /run/current-system/profile/etc/profile.d/nix.sh in your ~/.bash_profile or similar <rekado>our manual links to the general nixpkgs manual, which is not very useful <rekado>I followed the steps in our manual, but “nix-env --query --available” remains silent. <rekado>I guess I just picked the wrong channel. <TehBoss>also anyone have a packaging system for nerd fonts, i need the font "Cousine" which is one of the nerd fonts <civodul>ACTION thinks rekado is about to fall in love with Nix <TehBoss>i'm still new to guix and not sure how i should package it <civodul>TehBoss: hi! i’d suggest looking at an existing, similar font package and mimicking it <civodul>you can run “guix edit font-whatever” to look at its definition <TehBoss>i haven't seen a package for just one nerd font <efraim>civodul: encrypted-root-not-boot-os and lvm-separate-home-os both need their root filesystems expanded <civodul>either by actually expanding them, or by removing extra stuff that makes them too small <apteryx>hm, anyone familiar with Perl's 'Module::Build' ? I'm trying to invoke one of its action to generate doc, and it keeps saying: Too early to specify a build action 'info'. Do 'Build info' instead. <apteryx>then using the generated Build script as mentioned instead: ./Build info -> Configuration seems to be out of date, please re-run 'perl Build.PL' again. <avalenn>is there any "guix import npm" effort ? <civodul>avalenn: well, jlicht developed such an importer and there’s a plan to include it <civodul>… with the understanding that it only imports “binaries” <civodul>so the resulting packages won’t be acceptable for Guix proper but could be in a separate channel of course <graywolf>Hi! I am trying to make sure I understand service extensions correctly. Let's assume I extended my service multiple times. First, service-type-compose gets call with list of all values from the extensions and after that the resulting list is passed, together with initial config, to the service-type-extend procedure. <graywolf>Is that correct? What I am unsure is why the examples use (compose concatenate) instead of (compose identity)... <graywolf>For example, if I extend (simple-service 'foo bar-service-type 1) and (simple-service 'foo-2 bar-service-type 2), the service-type-compose will get called with (1 2) correct? <avalenn>cidovul: thanks for the tip, I will look at it (#62375) <efraim>does the 'down arrow'/'show all' option in ci.guix.gnu.org work for anyone for seeing all the builds in an evaluation? <civodul>efraim: what’s the URL of that page? <mothacehe>Uncaught TypeError: e is undefined in the console <weary-traveler>i'm trying to update a package definition. i've checked out guix repo locally and generated ./pre-inst-env. i've updated the package definition and updated the version info among other things within the guix checkout. however when i run ./pre-inst-env guix package --list-available for the package i don't see the updated version from the checkout. it only lists the upstream version <rekado>weary-traveler: what did you do to “generate ./pre-inst-env”? Have you compiled everything? <weary-traveler>so it seems there's something after ./configure i need to do as well? <snape>weary-traveler: you forget to run "make" <apteryx>efraim: I also see libstdc++-boot0-4.9.4 failing to build on core-updates <efraim>apteryx: I fixed it locally for make-libstdc++ but then I came across it in another spot, so I'm testing a fix in (guix build utils) <apteryx>ah, a match error; I guess from the recently introduced change that causes modify-phases to fail if it doesn't match a key? <apteryx>perhaps we should make the error more explicit <civodul>cbaines: i’d like to reconfigure bayfront, for the latest nginx changes <civodul>however that’ll require a ‘guix pull’ first, due to other changes in (sysadmin services) requiring a newer Guix <efraim>apteryx: the match error didn't give me any real clue what it was. Moving 'fix-rs6000-libdir from before 'chdir to after 'unpack was enough to fix libstdc++-boot0, but then something else broke later <efraim>I think it's either too eager to see if there's a matching phase to come before or it's checking them in the wrong order <efraim>since phases are 'evaluated' from last to first when multiple are before or after a specific phase <efraim>ACTION needs to write down this tribal knowledge somewhere <mirai>I wonder if substitute* should fail/throw if it doesn't do any substitution <civodul>yeah, it’s been proposed several times <podiki>it is an annoyance sometimes to have to quit a build early to then look through /tmp/guix... to see if it did something and what <mirai>It'd be interesting to discover how much obsolete substitution we got in the package definitionns <civodul>problem is that we don’t know what the impact would be <civodul>someone could try and do an x86_64-only build of the whole package set <podiki>warn first? but one has to then crawl through the log to see it <civodul>i would add a parameter to control the behavior <cbaines>this seems like the thing to do on core-updates <civodul>so one could always write: (parameterize ((%allow-substitution-failures? #t)) (substitute* …)) <podiki>or warn so no breakage and then look through all logs after a build of all? <cbaines>I don't really know how well it works, but QA should help with checking the changes on a branch <civodul>cbaines: well not on core-updates until the effect has been assessed, i’d say <civodul>yeah i’d just build the whole thing and then manually check for new failures <cbaines>civodul, just in case something happens that is not expected? I guess you can expect some things to fail to build <cbaines>I think we could also be better at picking packages to test changes against, like you probably don't gain much by attempting to build 100% of R/tex packages, and you could just sample 10% say <civodul>cbaines: yeah; by building all of or a large subset of the package set, we may find patterns where use of ‘substitute*’ purposefully assumes that the substitution may not happen but that it’s fine <civodul>but yeah first build the “core” subset of see if there are important issues, then try to build more <apteryx>efraim: if you are confident the new check added to modify-phases is erroneous, we can revert it for now <efraim>I know, I'm testing switching the match in alist-cons-before to 'match before' from 'match after' <cbaines>anyway, this is probably thinking too far in to the future. First QA needs to cope with patches to non-master branches, and it would also be helpful to highlight when patches impact lots of packages (as that's the case with quite a few issues) <apteryx>efraim: would you have a test case for it that fails? <efraim>apteryx: the two phases at the bottom of make-libstdc++, (add-before 'chdir 'fix-rs6000-libdir ...) and after it (add-before 'configure 'chdir ...) <efraim>the add-before 'chdir is tested before the 'chdir phase is added to the phases <efraim>in practice it doesn't matter which order they're listed in, they'll both be run <apteryx>ah, but it makes logical sense to have to list what appears first, first <apteryx>so maybe we can simply reorder the phase definitions <civodul>zimoun: if every call to ‘show-help’ is wrapped in ‘leave-on-EPIPE’, perhaps we should consider calling ‘leave-on-EPIPE’ directly from ‘show-help’? <efraim>I'm not in love with reordering a bunch of phases but I like the change in (guix build utils) too much to take it out <efraim>civodul: there were too many aarch64 packages to restart so I just told it to restart all the builds <zimoun>civodul: ’show-help’ is defined for each subcommand. So put leave-on-EPIPE at definition time or site-call does not change much. Well, here is one-line change but wrap ’show-help’ with ’leave-on-EPIPE’ makes harder to read the commit, IMHO. <zimoun>Or are you proposing something else? <zimoun>The elegant way would to have a macro, ’define-help’, and replace all “(define (show-help) …)’ with ‘(define-help …)’, but the effort is not worth the corner case, IMHO. <zimoun>*reword: «wrap ’show-help’ with ’leave-on-EPIPE’ makes harder to read the commit, IMHO»; I mean wrap at definition time = diff with several lines, compared to call time = diff with one line. <civodul>zimoun: oh yes, my bad! for a moment i thought there was a single ‘show-help’, but that doesn’t make sense <zimoun>yeah, I thought at the begining :-) <civodul>i caught the flu and it seems to make it even harder than usual for me to think <elevenkb>hello there, i need to run an electron app... (perhaps in a container)... where can I find libgcc_s.so.1? <efraim>I'm looking at bbcsdl to see why it doesn't build on aarch64 ... I think I either need to write a whole real Makefile for them or walk away <weary-traveler>okay seems in opensuse tumbleweed /etc/services is at /usr/etc/services. creating a symlink seems to have been sufficient <zimoun>civodul: Oh no, I hope it is “regular” flu. I also caught some virus past weeks and hopefully my grandma’ trick with Roquefort cheese did the jo. ;-) <jaeme-->elevenkb: is it a prebuilt electron app? <elevenkb>elevenkb: i can get it pre-built, but I want to convert it into an emacs package so I need to look at the source code. <elevenkb>if I can build it from source then I can more easily introspect it at run time. <podiki>elevenkb: I believe guix shell -e '(list (@@ (gnu packages commencement) gcc) "lib")' since the gcc:lib is hidden from cli <civodul>zimoun: at least it’s not covid, and it’s better than a few days ago <podiki>zimoun: did you have a chance to look at https://issues.guix.gnu.org/63393 again? or I could take a look at a revised patch soon (probably a simple version though, mostly just adding gcc:lib to the output) <zimoun>well, I do not remember well the details. I was proposing to have ’gcc-toolchain:lib’ but IIRC civodul proposed to just add the missing lib stuff directly to ’out’. <yaslam_>Hi everyone, why does virt manager not have a default interface, <zimoun>podiki: I think the fix should be with ’gcc-toolchain’ and not with ’gcc’, though. <podiki>Yes, I meant adding the gcc:lib output to toolchain <podiki>There was a message about static outputs that didn't go to everyone and I don't have an opinion on <snape>is it still required to add #t at the end of some phases after, say, substitute*? <zimoun>well, I will try to give a look later (next week), so feel free to send a revised patch :-) <yaslam_>Hello everyone, I am trying to setup a bridge network for my qemu VM using virt-manager. But it says the operation is not supported. Anyone know how to fix this problem, thanks. <lilyp>snape: nope, phase return values are completely ignored <snape>ACTION now has ublock-origin and passff packaged for Icecat <snape>I think Guix should be the source of Icecat extensions, instead of addons.mozilla.org <snape>even for Parabola and Trisquel <yaslam_>Hi everyone, is there a way to use Virtualbox on Guix. Thanks <cbaines>yaslam_, I'm not sure Virtualbox is usable without non-free software, which is perhaps why it's not available <cbaines>things like virt-manager and gnome-boxes might be alternatives <pastor>Guys. I'm trying to package a rust package which uses the meson build system. Could someone check if I'm going on the rigth path for merging both build systems? Here is the definition I have for now: https://paste.debian.net/1295350 <sneek>Welcome back pastor, you have 1 message! <pastor>thanks, efraim. I'm looking into those as a reference. <pastor>I'm getting this error on the configure phase: In procedure string-append: Wrong type (expecting string): #f <pastor>Probably is evident for someone with some extra experience. The error happens because the `--buildtype` flag passed to the build daemon is `#f`. <pastor>but I don't know why the appropriate build type is not passed as an argument <snape>pastor: you need something like <pastor>snape: Is there a place where I could look as a reference? <snape>you can grep it in the source <pastor>snape: What would the best place to go to understand how this more esoteric keywords work and what they do? <pastor>ups. I see this is from the meson build system. My bad <snape>yep, it's a keyword argument, see Guile reference, search for "define*" <pastor>yeah. That I understand. Thanks for the hint ^^ <pastor>snape: I'm having an issue adding the `#:build-type` keyword you suggested. The thins is that since I'm using the `cargo-build-system' as a base. Even if I have added the meson configure phase, the keyword is not recognized. <snape>well you shouldn't need this if you use the cargo-build-system <snape>the error comes from the meson-build-system <pastor>Yeah. The error is from the meson-build-system configure phase <snape>i've no idea, maybe some other thing you changed? <pastor>yeah. Probably is something I'm not configuring propperly <snape>pastor: #:imported-modules `(,@%meson-build-system-modules <snape>you can't do this with another build system <snape>it has to be meson-build-system <mirai>can you paste the whole definition? <snape>sounds like you are mixing build systems <pastor>snape: but in the example efraim suggested he does use that importing mechanism from other build systems <pastor>snape: Yeah. I need to mix the build systems. Is a cargo applications which uses meson as build system <mirai>pastor: what if you simply use meson-build-system as the build-system instead? <pastor>mirai: that was my initial attempt. But then I won't be able to feed modules to cargo <mirai>and what happens if you add #:configure-flags '("-Dbuildtype=debug") ? <snape>pastor: you can use a lambda that passes #:build-type to meson's configure <mirai>ah, you might get a unrecognized keyword error <pastor>mirai: the configure flag does not change the error. Which makes sense since the error happens when guile invokes the build daemon. Not when invoking meson <snape>pastor: maybe something like this: lambda args ((assoc-ref ... 'configure) args #:build-type "Release") <snape>although the syntax is not correcct <mirai> (apply (assoc-ref meson:%standard-phases 'configure) <mirai>btw, use "debugoptimized" instead <pastor>the syntax seems good. error: in phase 'meson-configure': uncaught exception: <pastor>keyword-argument-error #f "Invalid keyword" () ((#:build-type "debug")) <pastor>well the keyword is not accepted. No matter if the value is `debugoptimized` or `debug`. <mirai>and (apply (assoc …) #:build-type … args) ? <pastor>wrong-type-arg "append" "Wrong type argument in position ~A (expecting ~A): ~S" (1 "empty list" #f) (#f) <mirai>I mean the same lambda thing <mirai>but lose the quotes/list before the #:build-type … <pastor> (apply (assoc-ref meson:%standard-phases 'configure) <pastor>Seems the `apply' procedure appends the arguments so its expecting them to be lists <mirai>this works so the latter should be ok <mirai>you have this as (add-before 'build 'meson-configure (lambda args …)) right? <snape>pastor: (lambda args (apply (assoc-ref meson:%standard-phases 'configure) (append args '(#:build-type "release")))) <mirai>is it failing in 'meson-configure or is this on 'build ? <mirai>snape: it should do the same <pastor>mirai: with your changes is it failing in `mesen-configure` <pastor>phase `meson-configure' failed after 0.0 seconds <mirai>paste whole definition + log <snape>pastor: your version is not equivalent to mine <mirai>I don't see why it shouldn't be working <snape>ok try without append and without args <snape>(apply (...) '(#:build-type "blabla")) <pastor>this: (lambda args (apply (assoc-ref meson:%standard-phases 'configure) '(#:build-type "release"))) <pastor>goes back to: wrong-type-arg "string-append" "Wrong type (expecting ~A): ~S" ("string" #f) (#f) <pastor>In guix/build/meson-build-system.scm: <pastor> 50:18 3 (configure #:outputs _ #:configure-flags _ #:build-type _) <pastor> 2 (string-append "--prefix=" #f) <mirai>it has nothing to do with how you're using apply <mirai>it's another missing keyword argument <snape>configure #:key outputs configure-flags build-type <mirai>either mine or snape append will work <mirai>but you need more keyword arguments <snape>yep, indeed, there are other arguments to fill <pastor>so, mirai. With your example. Like this: <pastor>(lambda args (apply (assoc-ref meson:%standard-phases 'configure) '(#:build-type "debugoptimized") args)) <pastor>I get the Invalid keyword: (#:build-type "debugoptimized") <mirai>pastor: you can do (pk args) before the apply call <mirai>pastor: yeah, that's wrong. Lose the '( ) <pastor>but if I lose it I get: In procedure append: Wrong type argument in position 1 (expecting empty list): #f <mirai>what's missing is #:some-other-keyword somevalue that you need to find out <mirai>look at guix/build-system/meson.scm , etc. <pastor>okay. I will. Thanks for the insight <mirai>use (pk args) before (apply …) to inspect its value too <pastor>the `pk` is not printing anything <pastor>Well I see a lot of arguments. The inputs are in there <pastor>I will investigate further the meson build system. The conclusion then, is that I need to look for missing keywords to the configure phase? <apteryx>maybe emacs-substitute-variables should call make-file-writable itself <apteryx>or maybe there's a switch we can use to tell emacs to try writing anyway <apteryx>it doesn't seem to happen with substitute* <lilyp>apteryx: IIUC that's because substitute* writes to a temporary file first <Minall>Are there any blogs discussing Guix for any DFIR process pentesting?. I wonder if I could make small labs in guix shell with specific versions of versions that I can exploit and, link that with its own org mode file explaining the vulnerability, all of this for studying purposes. <Minall>I wonder if guix shell with the --container option would also be able to run databases?, I'm just thinking about the posibilities here to run test environments easier and better than any other system, since its byte by byte capabilities to make reproduceable environments and all <lilyp>Minall you can spawn entire system configurations in virtual machines and indeed also containers, though the command is guix system vm (or container) instead of guix shell <lilyp>that should at least get you started for pentesting <lilyp>for specific exploitable package versions, see package transformations; though note that you'd have to compile them on your own most of the time <Guest96>Since I was able to to get Synapse up and running (using unmerged patch from issues.guix.gnu.org), I am a bit more invested helping package the needful to get a matrix bridge up and running for this irc <Guest96>I assume if the right bridge can be packaged, that someone with the necessary privileges would be willing to enable it? <Guest96>Last I saw the discussion of bridges here, the talk was about Heisenbridge. Does anyone know why Heisenbridge might be preferrable to matrix-appservice-irc?