<lfam>The codec / container support situation is so sad
<lfam>mkv is a royalty-free format, but poorly supported. I guess the vendors prefer to pay
<lfam>I'm curious, do you have any gst-plugins-* or gstreamer packages installed in your profile, roptat? I've always been under the impression that users have to install them "by hand" to get support for the patented codecs
<leoprikler>lfam: for the record, it also works if you put gstreamer + plugins + target application into an environment (possibly containerized)
<ryanprior>Also insert-input performance is greatly improved. It uses a cache of available Guix packages to cut down on I/O, which you can refresh using the guix-packaging-refresh-packages command if you've just changed packages.
<ryanprior>Plus, for those of us who modify our Guile load path for Guix commands, you can customize guix-packaging-extra-load-paths and it'll account for those.
<ngz>The thing that puzzles me, however, is that we have two talks for two competing futures for Cuirass.
<cbaines>ngz, what do you see as the two different futures?
<ngz>If I get it right, in your video, you explain the design of Guix Build Coordinator, and how it will solve current Cuirass issues. That's the first one.
<ngz>Then, Mathieu explains in another video that Guix Build Coordinator will probably face the same issues as the current Cuirass design, and suggest a different design.
<ngz>Admittedly, I may have missed the point, tho.
<cbaines>So, I think it's true to say that I and Mathieu both said things about building packages for substitutes. But I didn't say anything about Cuirass specifically, and Mathieu was talking about a related thing he's working on to use in conjunction with Cuirass.
<leoprikler>brown121407: do you have all of the dependencies in your programming environment? I don't have much experience with ccls, but I do from time to time use emacs in one environment while compiling/running in another
<leoprikler>of course were I to use some more advanced features of emacs like some repl or gdb that would fail
<brown121407>leoprikler, I don't use environments for this. I have all the things installed in my user profile (gcc-toolchain, ccls, emacs, emacs-ccls, emacs-lsp etc)
<roptat>I remember there were some discussions about providing substitutes to Chinese users recently. I'd like to contact the person who sent us this message, to see if we can setup a mirror for the videos of the Guix Day, but I can't find their message anymore...
<roptat>because right now they're outside of China, so I expect them to be incredibly slow for Chinese viewers
<civodul>i guess your setup could be interesting to a wide scientific audience
<ngz>Recutils project now provides its Emacs major mode for editing recutils files as a GNU ELPA package named "rec-mode". At the moment, Guix extract this library from the whole Recutils source tree, as the "emacs-recutils" package. Would it make sense to deprecate this "emacs-recutils" package in favor of the new "emacs-rec-mode" from GNU ELPA?
<roptat>alright, I have QmbyvyiKEP1d7GNrcmLLrwodBN6X9oiibN5CJG8KSSZVX1, QmPsWu9QZec4SanvDKV2kghfUk2VLAXgay9EX3Vnt9SL1a, QmVqFw9xxoMAT4NGccrxDoDgrguBK3mPvjhwDhAkmnVLzh, QmWWubjA2JJR9t7HiAerEYGMf3cD3a8sQAgW8Ex9ZC1iZo, Qmao7SDaDEBUBXQM9S8YTRmVVVqQMC9RuGMdhEvkZCTNib, Qme9zQy6UrANh6uSE1zAKtKWBHUaLZYTJwFEiNN5eRB3uQ and QmPxASuLDYVhqPDVPRvh6noBpkvn67FD3hvx29woYYY58s
<roptat>missing one because lfam haven't transcoded Andrew's talk to webm yet
<seeg123>hello, i'm trying `guix import crates bottom`, the generated piece of code is quite raw, i need to add '(define-module` etc and packages are missing because the version is not there, eg. there is no 'rust-backtrace' in guix but there is 'rust-backtrace-0.3'. Any tips on how to make this import more self-contained?
<roptat>or maybe I should configure my /etc/hosts somehow to say *.localhost -> 127.0.0.1?
<wehlutyk>roptat: that's possible. I'll rebuild locally to see. What I don't understand is that the log says it does look for Qt5Svg cmake files in `/gnu/store/7f809f0bhirn1vad1rr3srxk2c7qqang-qtsvg-5.14.2/lib/cmake/Qt5Svg`, which on my system is present and has cmake files (I'm assuming it's the output created by `qtsvg` on the ci machine)
<seeg123>ok --recursive did help a bit roptat however I still have bunch of undefined 'rust-bottom' entries, I guess this is because (use (guix packages crates-io)) imports them with version: rust-bottom-0.3. Any idea how can I provide an alias to the latest version?
<roptat>add --keep-failed and cancel the build after the configure phase, and you'll get the content of the sources and build files in /tmp
<seeg123>I did (define rust-bottom rust-bottom-0.3) by hand but it's tedious
<roptat>seeg123, that's what I was about to suggest
<seeg123>and seems that guix import can smartly figure out what's needed from what not (defines package for rust-cargo-husky which is not there, but doesn't define one for rust-backtrace)
<roptat>though "rust-bottom" on the cli (with guix build, guix install, etc) should already refer to rust-bottom-0.3 if that's the latest
<seeg123>i don't know if it's wrong, but when it is run with --recursive, it correctly adds only crates which aren't in guix, so 'rust-backtrace' isn't added as a package, however it still doesn't have the version
<seeg123>well, ok then, so another question: since i have this all set up with --recursive, can i somehow list all the guix packages without the version in one go? it takes couple of seconds to report an error via guix build, with 4k lines I won't finish fixing versions too fast :)
<roptat>ok, there's a patch series that's under review, it's related to versions and stuff already, so maybe it'll help, or maybe you found something that could be added to the series
<roptat>I would create a module from that file and let guile load it to tell me which variables are undefined
<roptat>you could move your file to something like modules/myfile.scm, and start it with (define-module (myfile)) (same as the filename)
<roptat>then use something like guix build -L modules rust-bottom
<roptat>I think you'll see some warnings the first time, including some "potentially undefined variable" warnings
<zimoun>rekado_: Thanks. Roel is also working on the Bioconductor update.
<zzappie>roptat: ipfs daemon does same thing for me (: only workd with 127.0.0.1
<zimoun>rekado_: hum? the failure seems a IO failure of Berlin because the last line of the log is “DelayedArray/man/extra” at the unpack phase I guess.
<wehlutyk>so, rebuilding `python-pyside-2` with `"-DCMAKE_FIND_DEBUG_MODE=ON"` now says `Checking file [/gnu/store/7f809f0bhirn1vad1rr3srxk2c7qqang-qtsvg-5.14.2/lib/cmake/Qt5Svg/Qt5SvgConfig.cmake]` (which exists), then `- optional module Qt5Svg skipped. Looked in: /gnu/store/7f809f0bhirn1vad1rr3srxk2c7qqang-qtsvg-5.14.2/lib/cmake/Qt5Svg`. Any hints for troubleshooting this?
<dustyweb>civodul: also! thank you for taking the time to reply
<zimoun>civodul: the package Gmsh is not available (for version-1.2.0) but it builds, for example on Bayfront, or my laptop. I guess it comes from a Berlin IO troubles. Is it possible to re-launch the build?
<maav>zimoun, roptat: could you take a look at #44709? it's a patch for the banner, as it currently cannot be fully translated :-)
<maav>it's pretty trivial, but i want your ok beforehand
<zimoun>roptat: cool! Yesterday I did some experiments to distribute the video via “guix install” :-) As we talked about on Sunday. Then I thought about the recent “Community“ webpages… Well, it could be worth to add a build-system and a schannel… I will send an email to discuss such weirdness. ;-)
<nckx>The ‘a’ is for ‘all the stuff you don't need’ though.
<luis-felipe>Both commands, build and serve, fail with the -C option. Both work without it.
*luis-felipe now can test a patch for the info banner.
<zimoun>luis-felipe: ah it is because on Guix System, the locales are different, I guess.
<zimoun>the --share= and -E is probably different than on Guix-on-foreign.
<zimoun>roptat: I will not send a fix because I do not see what to fix. :-) 4 lines below: «The term BoF means open discussion to address prospects.» Aside the accronym, I do not see how to improve. And following this argument of accronym: “Fixing the CI“ is problematic too (that’s why the term «continuous integration» appears in the description). Anyway. :-)
<luis-felipe>zimoun: Since guile-markdown does not support HTML, I think it is OK to leave it as it is right now. But I still think it is a good practice to add the meanind to the first occurrence of an acronym in every page of the website.
<luis-felipe>The current explanations for both BoF and CI are found only if you are reading the whole text, not when you are skimming through.
<zimoun>luis-felipe: I agree. No one did the remark of CI because it is well-known in the community. I thought that BoF was too. It is used in Debian for example. And even in really formal conferences (ACM SIGGRAPH for instance).
<luis-felipe>Honestly, when I read BoF, I thought it was that those videos were not complete/available yet. Since I didn't see the abbreviation explained, I didn't bother to look it up.
<luis-felipe>Haunt supports other formats for posts though, just in case some future post requires more complex HTML.
<zimoun>nckx: just to get your point for the next time. :-) You propose to write something like: BoF stands for Birds of a Feathers flock together, which said to mean that people from the same group or with the same interests like to be with each other, then here the term BoF means open discussion to address prospects.
<cbaines_>I have strong thoughts on CI, I think it means something different to what I think that talk is about.
<cbaines_>To me, CI and Guix means looking at how we merge patches, and treat branches like staging and core-updates, it's about how we continuously integrate changes (hence CI)
<cbaines_>I think CI for Guix can be improved, and to me that would look like staging/core-updates being less effort to handle
***cbaines_ is now known as cbaines
<zimoun>cbaines_: I will not talk instead of mothacehe. I think CI refers to ci.guix.gnu.org.
<cbaines>You're right, that's a Guix specific meaning where CI -> ci.guix.gnu.org
<luis-felipe>Serving it using the instructions in the website/README
<nckx>zimoun`: Something like that. By the way, if you were implying that I had a different opinion about ‘CI’, I don't. It could also use some explanation, especially since we use it in a very Guix-specific way. (Or if the talk is about doing ‘real CI’ instead, that's interesting enough to note too.)
<samplet>Aha! “EXP evaluation is deferred and will only be run once the worker evaluation queue [is] full.” It looks like the update is being deferred.
<samplet>Yup. Using “with-db-writer-worker-thread/force” in “db-update-build-status!” makes it work. I’m not sure what the trade-offs are there.
<zimoun`>nckx: I am not implying :-) Just noting that no one raises about CI at first read AFAIK and only about BoF. Well, I am trying to understand the other points of view to improve. At least for future rounds. :-) And I get yours. Thanks for the explanations.
<samplet>I guess my CI server building one derivation is insufficiently busy. :)
<cbaines>samplet, this is you trying to build fixed output derivations, so you can store the resulting tarballs, right?
<lfam>mbakke: Thanks for asking that question on oss-sec. It's useful to read the responses
<mbakke>civodul: I'm not comfortable adding #:log-file to the elogind service so late in the release cycle, so I'll instead just make SDDM depend on elogind
<mbakke>lfam: yes, that thread exceeded my expectations :)
<samplet>cbaines: Not quite. I will extract metadata from the tarballs and then store that.
<cbaines>samplet, OK. Have you considered using the Guix Build Coordinator for this? You can run some arbitrary Guile code when builds succeed, which might be useful to do that metadata extraction
<lfam>Thanks for taking care of the old wireguard tools nckx
<mbakke>jonsger: #44669 (harmless, but can look scary)
<nckx>If it doesn't become a maintenance burden it should be relevant for a long time. When was it merged? 5.7?
<civodul>mbakke: sounds good; for version-1.2.0 it's definitely more reasonable to do it that way
<samplet>I was hoping to find the source tarballs from packages (similar to how our “sources.json” is made), and then create Cuirass jobs based on that.
<cbaines>samplet, it's a service for building derivations, and doing useful stuff around that.
<cbaines>samplet, getting it to build things should be easier than Cuirass (at least in my experience), and I think it'll set you up well for doing stuff with the build results (providing you can work with nar files)
<lfam>nckx: It was added in 5.6. I believe the first long-term supported kernel that contains it will be 5.10
<samplet>cbaines: I’ll take a closer look at it. Nothing is set in stone yet. Thanks!
<nckx>lfam: All right. No, I don't plan on removing it before it breaks or not a single Guix kernel can use it.
<brettgilio>Before GCC 8, filesystem is <experimental/filesystem>
<brettgilio>however, when I explicitly set GCC 8 (to see what happens) the linker gets angry, std::filesystem::__cxx11::operator==(std::filesystem::__cxx11::path const&, std::filesystem::__cxx11::path const&)
<zimoun`>cbaines: following my message 1 minutes ago about dates and Data Service, I am checking the code to try to fix. The correct file dealing with guix-commits is branch-updated-emails.scm right?
<cbaines>zimoun`, yeah, that's what does the insert-git-branch-entry bit
<cbaines>zimoun`, I'm still not quite sure what issue you're facing though?
<cbaines>(ah, I'm just reading you're email now...)
<zimoun`>my last email which you have not received yet exposes the issue, I hope.
<zimoun`>and the issue is (x-git-newrev (assq-ref headers 'x-git-newrev)))
<zimoun`>which should be (x-git-rev (assq-ref headers 'x-git-rev)))
<clone11>When I try to install rust it tries to build the whole chain from 1.41. Is this an issue on my end? Other substitutions seem to be working
<lfam>If other substitutions are working, I think it's not a problem on your end
<zimoun`>so it is just processing emails, instead of the X-Git-Revenew, it should be X-Git-Rev
<zimoun`>I will try to give a look. But the point is that enqueue-job-for-email is not doing the correct job to select the commits. And I think a bit more logic could be added to this function.
<cbaines>The intent when I wrote it is just to track changes to a branch, and I think it's doing that correctly.
<cbaines>The bit at the top where it does (string? x-git-newrev) means it only looks at emails which describe the branch changing from one revision to another
<zimoun`>yep, I understand the logic. That’s just a bit more work but it is doable and then the commit will be the correct ones. I am enough annoyed to want to fix fix it. :-)
<cbaines>Again, processing each commit, rather than each state the branch is in is theoretically possible, but it would massively increase the work the Guix Data Service has to do. If someone pushes 100 commits all at once, then rather than the Guix Data Service just processing the one new revision, it would have to load 100 new revisions!
<cbaines>When processing a commit, the Guix Data Service does something similar to guix pull for that commit, for each architecture it's capable of, it then runs a Guix repl in that revision of Guix and extracts information from it. It generates derivations for every package, for every architecutre, as well as derivations for the system tests for each architecture. It extracts all the lint warnings. It also extracts lots of package metadata. It then does some work
<cbaines>to store the state of that revision in the database.
<zimoun`>what is for example “guix-data-service: computing derivation for docker system test”?
<cbaines>I think the reason why that bit is slow is something to do with the database and loading the package metadata
<cbaines>Package metadata in the context of the Guix Data Service means home page, location, licenses, description and synopsis
<cbaines>There are ~14,000 packages in recent revisions, so you have ~14,000 of the above
<cbaines>That bit of code is trying to match up the data it got from the inferior, with the data in the database, and insert new entries for any missing bits.
<cbaines>It was much slower, and I'm hoping it's possible to make it even faster, but I haven't got around to looking at it yet
<lfam>I suspect that all the pyqt users have this problem of missing icons
<zimoun`>cbaines: ok, normally there is a package.cache really fast to load but it does not contain what you need. With Arun and I did experimental stuff it to speed up “guix search”, see http://issues.guix.gnu.org/39258#89 for example
<zimoun`>the idea was to add home, license, synopsis, description, etc to this package.cache. Maybe it could be revisited :-)