IRC channel logs


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
<VesselWave>snape: Thanks. (Now from correct nickname)
<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>yeah that would be cool
<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?
<adanska>Hi Guix!
<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
<zeropoint>nice, didn't notice that
<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
<apteryx> is very sluggish
<civodul>Hello Guix!
<civodul>Hello Guix!
<civodul>hey, mothacehe!
<civodul>how’s everything?
<mothacehe>I'm having a look to the system test failures now that the missing .drv errors are gone :)
<civodul>oh, that’s right!
<civodul>110 success, 9 failures:
<civodul>not bad
<mothacehe>I wonder what's the behaviour of `start-service` if the service is not yet started. It seems that we can receive a #f, that I cannot reproduce locally here:
<efraim>on the other hand, I'm missing a bunch of drvs from the rust-team, had to go and re-create them :)
<mothacehe>yeah I feared it would be worst :p
<civodul>lots of ENOSPC i guess
<civodul>like this one:
<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>hello! trying to package something to work with Perl; hitting this: seems it doesn't like the gexp?
<apteryx>the build system seems to have support for gexps
<rekado>apteryx: what does the generated builder code look like?
<civodul>apteryx: try
<civodul>or maybe (if (pair? …) …) to mirror the one below
<apteryx>civodul: ah, seems likely!
<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
<rekado>I ran “nix-channel --add” and “nix-channel --update nixpkgs”, but “nix-env --query --available” prints nothing.
<apteryx>I think you need to put source /run/current-system/profile/etc/profile.d/ in your ~/.bash_profile or similar
<apteryx>it's mentioned in the manual, IIRC
<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.
<rekado>works with nix-channel --add
<TehBoss>why are you mixing nix and guix
<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
<TehBoss>oh actually
<efraim>civodul: encrypted-root-not-boot-os and lvm-separate-home-os both need their root filesystems expanded
<civodul>yeah, we should fix that
<civodul>either by actually expanding them, or by removing extra stuff that makes them too small
<rekado>TehBoss: not mixing. Debugging.
<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 ?
<avalenn>Ok. I think we will not have it soon :
<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
<futurile>Morning all
<MysteriousSilver>good morning
<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>So I am probably missing something.
<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 work for anyone for seeing all the builds in an evaluation?
<mothacehe>efraim: no, looks like it is broken
<apteryx>nevermind, './Build info' worked
<civodul>efraim: what’s the URL of that page?
<mothacehe>civodul: for instance, the id=="paginate" button doesn't do anything
<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
<weary-traveler>how do i get list-available to display the newer version?
<rekado>weary-traveler: what did you do to “generate ./pre-inst-env”? Have you compiled everything?
<weary-traveler>rekado: i've only run ./bootstrap and ./configure
<weary-traveler>so it seems there's something after ./configure i need to do as well?
<weary-traveler>rekado: the commands i've run so far in order
<snape>weary-traveler: you forget to run "make"
<apteryx>efraim: I also see libstdc++-boot0-4.9.4 failing to build on core-updates
<weary-traveler>i see. i've only completed the steps for generating pre-inst-env. those aren't sufficient, however, and i need to complete all the steps in
<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
<civodul>sounds good to you?
<cbaines>yep +1
<civodul>alright, thanks!
<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
<podiki>i think it should
<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
<apteryx>that's ed1b2d0a86
<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
<weary-traveler>i've minimally modified a package definition within a guix checkout so i can confirm that i'm able to build it when not relying on a substitute. guix build complains of missing /etc/services
<efraim>civodul: there were too many aarch64 packages to restart so I just told it to restart all the builds
<weary-traveler>i'm using guix on opensuse tumbleweed fwiw
<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
<civodul>so: all is good!
<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
<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
<elevenkb>thanks podiki !
<podiki>speaking of, needs to be resolved
<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 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,
<yaslam_>I meant ?
<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 :-)
<zimoun>snape: no.
<snape>great thx
<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>yep ok thx
<snape>ACTION now has ublock-origin and passff packaged for Icecat
<snape>I think Guix should be the source of Icecat extensions, instead of
<snape>even for Parabola and  Trisquel
<roptat>hi guix!
<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
<snape>and qemu
<yaslam_>I will try gnome boxes, thanks.
<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:
<sneek>Welcome back pastor, you have 1 message!
<sneek>pastor, efraim says: python-orjson uses rust and python to build
<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>Happens in this line:
<pastor>but I don't know why the appropriate build type is not passed as an argument
<snape>pastor: you need something like
<snape>           #:build-type "Release"
<snape>above #:configure-flags
<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*"
<snape>pastor: ^
<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>This is the backtrace:
<pastor>yeah. Probably is something I'm not configuring propperly
<snape>pastor: #:imported-modules `(,@%meson-build-system-modules
<pastor>Is that not correct?
<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?
<pastor>mirai: is this one
<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?
<snape>I see
<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") ?
<pastor>Let's try
<mirai>or maybe
<mirai>#:build-type "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
<pastor>okay. Let me try
<mirai>(lambda args
<mirai> (apply (assoc-ref meson:%standard-phases 'configure)
<mirai> '(#:build-type "debug")
<mirai> args))
<mirai>or something similar
<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>I wrote it like this:
<pastor>(lambda args
<pastor> (apply (assoc-ref meson:%standard-phases 'configure)
<pastor> #:build-type
<pastor> "debugoptimized"
<pastor> args))
<pastor>Seems the `apply' procedure appends the arguments so its expecting them to be lists
<mirai>(apply + 1 2 3 '(4 5 6))
<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 ?
<pastor>I have this:
<mirai>snape: it should do the same
<pastor>snape: yeah, same error
<mirai>which phase is it dying on?
<mirai>right now
<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
<pastor>mirai: this is the definition
<pastor>and this is the log:
<snape>pastor: this is wrong
<snape>args should be last
<snape>well first
<snape>do like my version
<snape>orders matter
<pastor>snape: this is your version
<pastor>and this is the log:
<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>it really not liking this:
<pastor>In guix/build/meson-build-system.scm:
<pastor> 50:18 3 (configure #:outputs _ #:configure-flags _ #:build-type _)
<pastor>In unknown file:
<pastor> 2 (string-append "--prefix=" #f)
<mirai>simply put
<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
<snape>gotta go
<pastor>thanks snape. Good night
<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>yes, but that's correct
<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>ah. Over args
<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>Hello Guix Community!
<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
<Minall>I see.. I'll take a look
<Guest96>Hi guix!
<Guest96>Since I was able to to get Synapse up and running (using unmerged patch from, 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?