<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...
<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?
<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>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.
<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)...
<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
<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>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
<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.
<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,
<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
<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?
<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?