Re: branch master updated: services: Add transmission-daemon service.
Apologies for the delayed response; Gnus directed this away from my inbox and I am just seeing it now. (I've fixed my gnus.el.) Ludovic Courtès writes: > IWBN to have a system test for this service, under (gnu tests …), to > test at least basic functionality. > Do you think it would be possible? Yes, definitely; that's still on my list. I've been busy with another project but will take another look at this tomorrow and see if I can get something put together quickly. -- Simon South si...@simonsouth.net
Re: Getting the Guix Build Coordinator agent working on the Hurd
Ludovic Courtès writes: >> The second issue is that I'm not sure capturing the build time >> GUILE_LOAD_COMPILED_PATH doesn't seem to work, at least file says that >> the .go files this contains are built for a 64-bit architecture. I >> worked around this by constructing the GUILE_LOAD_COMPILED_PATH from the >> inputs I knew should be on it. Maybe it should always have been done >> this way, any ideas? > > Instead of capturing the build-time ‘GUILE_LOAD_COMPILED_PATH’, which > doesn’t contain the target .go files, you should explicitly list the > inputs as is done in the ‘guix’ package for example. That’ll ensure the > binary refers to the cross-compiled .go files. This has now happened [1], so the guix-build-coordinator package should now cross compile in a useable way. 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=eec127822a74c6a1a6100b07d94c8fb275d571bf >> There's also one problem probably within the Guix Build Coordinator >> itself, after doing a few builds, it will just stop. I've only seen this >> behaviour on the Hurd, but I'm unsure how to debug it, any suggestions? >> My only idea is add more logging. > > No idea, but I guess that could just be a crash. Can you still log in > afterwards? Not through SSH at least. Someone on IRC mentioned they'd had issues running Hurd VMs without swap, so getting swap in childhurds might be something to try. I started looking at this [2]. 2: https://issues.guix.gnu.org/46726 > BTW, note that builds on GNU/Hurd are currently not isolated, and thus > it’s the wild west in terms of reproducibility: > > https://issues.guix.gnu.org/43857 > > There are open questions as to what to include in the build environment: > > https://guix.gnu.org/en/blog/2020/childhurds-and-substitutes/ Isolation would be nice of course, although I'm not sure how much this will affect reproducibility, unless things are poking around in the store directly. signature.asc Description: PGP signature
Re: TOCTTOU race
Hi, Maxime Devos skribis: > Is all addressed now? (Aside from the TOCTTOU.) Yes, thank you! Ludo’.
Re: Will 2021 be the year of build systems on gexps?
Hi! Ludovic Courtès skribis: > I’ve made progress identifying and mitigating what seems to be the main > cause of this (the fact that it’s possible to ungexp a list and that > list will be scanned in its entirety in search of file-like > objects—convenient but expensive) but as you can see, there’s still a > lot to do. I cherry-picked to ‘master’ the gexp optimizations I made on ‘wip-build-systems-gexp’. The good news is that it pays off on system compilations, going from (commit 3c548c3e0eade12d3e86b1201dbd95863ca64ea7): --8<---cut here---start->8--- $ GUIX_PROFILING="gc object-cache" ./pre-inst-env guix system build -d --no-grafts gnu/system/examples/desktop.tmpl /gnu/store/g6kd2blajq6yja80516m85zv07d4ysb3-system.drv Store object cache: fresh caches: 2 lookups: 119282 hits: 116225 (97.4%) Garbage collection statistics: heap size:119.43 MiB allocated:649.07 MiB GC times: 26 time spent in GC: 2.15 seconds (37% of user time) --8<---cut here---end--->8--- to (commit 0a912b3a434c9ff9515f9036feae4d3a7075fb2f): --8<---cut here---start->8--- $ GUIX_PROFILING="gc object-cache" ./pre-inst-env guix system build -d --no-grafts gnu/system/examples/desktop.tmpl /gnu/store/f63c8rk8rwrfr5cl4s74hnx25l3z1hrp-system.drv Store object cache: fresh caches: 2 lookups: 119285 hits: 116227 (97.4%) cache size:3058 entries Garbage collection statistics: heap size:111.43 MiB allocated:608.01 MiB GC times: 25 time spent in GC: 2.00 seconds (37% of user time) --8<---cut here---end--->8--- Reduced heap allocations (-6%), reduce heap size (-7%), and reduced run time (ditto). Getting better! Ludo’.
Rust packages and performance impact on Guix
Hi! Ludovic Courtès skribis: > but on ‘wip-build-systems-gexp’ I get: > > $ GUIX_PROFILING=gc time ./pre-inst-env guix build qemu -d --no-grafts > /gnu/store/5n44l8cmrmkr747nsqbxpm4764jdsl3l-qemu-5.1.0.drv > Garbage collection statistics: > heap size:80.52 MiB > allocated:249.89 MiB > GC times: 16 > time spent in GC: 0.75 seconds (34% of user time) > 2.22user 0.13system 0:02.06elapsed 114%CPU (0avgtext+0avgdata > 243532maxresident)k > 0inputs+0outputs (0major+34304minor)pagefaults 0swaps > > In short, 30% more garbage allocated and an 8% slowdown. In the meantime, librsvg on core-updates switched to the version that depends on Rust. As a result, the above command, on core-updates, went to ~2.25s on my laptop (+10–20%!). Would be nice to investigate. One issue is that ‘cargo-build-system’ traverses packages. The ‘crate-closure’ call in there certainly adds a fair bit of overhead. Could we avoid it? Thanks, Ludo’.
Re: Upgrading SIP.
> On 02/22/2021 6:50 PM Ludovic Courtès wrote: > > > Hi, > > Brendan Tildesley skribis: > > > Building python-pyqtwebengine, it is unable to find the .sip files needed > > since it only searches one global path: > > > > openat(AT_FDCWD, "QtCore/QtCoremod.sip", O_RDONLY) = -1 ENOENT (No such > > file or directory) > > openat(AT_FDCWD, > > "/tmp/guix-build-python-pyqtwebengine-5.15.2.drv-0/PyQtWebEngine-5.15.2/sip/QtWebEngineCore/QtCore/QtCoremod.sip", > > O_RDONLY) = -1 ENOENT (No such file or directory) > > openat(AT_FDCWD, > > "/tmp/guix-build-python-pyqtwebengine-5.15.2.drv-0/PyQtWebEngine-5.15.2/sip/QtCore/QtCoremod.sip", > > O_RDONLY) = -1 ENOENT (No such file or directory) > > openat(AT_FDCWD, > > "/tmp/guix-build-python-pyqtwebengine-5.15.2.drv-0/PyQtWebEngine-5.15.2/build/bindings/QtCore/QtCoremod.sip", > > O_RDONLY) = -1 ENOENT (No such file or directory) > > openat(AT_FDCWD, > > "/lib/python3.8/site-packages/PyQt5/PyQt5/bindings/QtCore/QtCoremod.sip", > > O_RDONLY) = -1 ENOENT (No such file or directory) > > write(2, ".sip-build-real: Unable to find "..., 61.sip-build-real: Unable > > to find file "QtCore/QtCoremod.sip" > > Do you know how Qt (or whatever component is involved) searches for .sip > files? > > Most of the time, there’s a “search path” typically associated with an > environment variable that we need to set accordingly (like PYTHONPATH, > GUILE_LOAD_PATH, etc.). > > Sometimes, that mechanism doesn’t exist upstream so we end up patching > the software to add it. This is what was done with OBS for instance, > and that patch is now upstream. > > HTH! > > Ludo’. https://www.riverbankcomputing.com/hg/sip/file/tip/sipbuild/builder.py#l273 There is a sip_include_dirs, but the bit that looks for bindings from other packages does so by looking in the target directory specified with --target-dir: # Add any bindings from previously installed packages. sip_include_dirs.append( os.path.join(project.target_dir, project.get_bindings_dir())) Besides that it looks in current build directory. Currently I'm looking at updating sip and going back to the configure.py script to see if i can get that working first.
