<thomasd>the problem only seems to appear after recent commits to master. If I rebase my update patches on top of 4d0a3d8 (before gpgme update to 1.8.0), I don't have the issue. On top of commit e10872c (which patches gpgme CMake files, necessary for KWallet to build), I have the loop issue.
<thomasd>well, actually I'm not sure it's a loop, but something is keeping guix busy for 40 minutes now :)
<davexunit>I have some logitech 720p camera that I bought ~4 years ago and I've never had problems
<Apteryx>I've used Logitech webcam C920 before with Ubuntu. It was OK, but sometimes failed to initialize and had to unplug/replug.
<Apteryx>Image quality/sound was suprisingly good though
<mark_weaver>on my X200, with nothing else happening on the machine, it takes about 11 minutes for "guix system build" to print an already-present output, for my GNOME desktop. I think it's time to think about how to make that faster. much faster.
<mark_weaver>and many of those intermediate builds will never be used, except as a test to make sure they compile.
<lfam>Right. The reason I separated the NSS updates is because it kept failing in ways that I can't reproduce locally. I don't want to hold up some other changes with it
<paroneayea>was still pointing at some stuff in the guix/emacs/ stuff that for some reason was lingering...
<lfam>I don't have any armhf hardware to test it with, mark_weaver
<mark_weaver>if it's not too onerous, I would suggest that we do some modest (but non-trivial) testing on our local machines of each of these branches, and then combine them together into a new 'staging' branch to be built by hydra.
<mark_weaver>ah, I see. the nss problem is specific to arm, right.
<mark_weaver>lfam: is that the main question, whether nss will build on arm?
<lfam>mark_weaver: nss 3.27.2 failed on armhf, repeatedly. It also had a problem with a test certificate that expired, breaking the build. In the meantime, 3.28.1 was released. But we haven't tried building that on armhf yet
<mark_weaver>I'll try building nss from the nss-branch on one of my arm boxes.
<lfam>pareidolia: It looks like an error in how the disk was partitioned, or in the (bootloader) and (file-systems) fields of the OS configuration.
<lfam>mark_weaver: Okay, I'm building icecat on x86_64. I'll let you know if it fails. If NSS builds for you on armhf, can you let me know or start an nss-updates evaluation?
<mark_weaver>lfam: I'd prefer to avoid separate jobsets for each of these changes.
<lfam>mark_weaver: I think we will see lots of failures on imagemagick-updates. If we can't use Hydra for "speculative" building, I think we should not try building that branch on Hydra at all.
<mark_weaver>the only reason I prefer it is because of the efficiency problems with the current hydra. (the new one is not yet ready)
<lfam>Those who are interested in testing the imagemagick update can do it on their own machines.
<lfam>Is there another branch you'd like to combine with nss-updates? I can try testing it locally if so
<mark_weaver>lfam: what happened with the existing evaluation of imagemagick-updates?
<mark_weaver>lfam: I cancelled the non-Intel jobs, but in the end I left the x86_64 and i686 jobs queued.
<lfam>Only a small number of packages refer directly to imagemagick. I'll make a list and try looking in their source code to see if they are ready. I'll also send the list to guix-devel and ask for help on this
<lfam>pareidolia: If you aren't sure about how to partition the disk, we can offer advice :)
<lfam>I love being able to use recutils: guix package -s . | recsel -e "dependencies ~ 'imagemagick'" -p name,location
<nliadm>is there a way to make a guile module span files?
<ng0>could we maybe make comments above the qt modules (or better: in the description of them) which modules they contain? Often it involves guessing and asking qt.io documentation for myself if the names are not 1:1 the same
<ng0>email archive helps... " qtcore, qtgui and qtwidgets are all outputs of qtbase."
<lfam>mark_weaver: I successfully built icecat on x86_64-linux from the nss-updates branch