IRC channel logs
2017-01-11.log
back to list of logs
<sturm>It looks as though `mysql-configuration-file` is the Guix function that I need to change <paroneayea>ACTION doesn't have a response but is happy to see sturm talking in here <ng0>palemoon is weird. or the mach build system. like, it *might* have been build succesfully now. I jus tdon't know. maybe I just add the phases after build to see if I created something functional <ng0>wow this is a stupid build system <ng0>I get to package the result and need to extract it again <ng0>go home mach, you're drunk <daviid>... autoreconf: running: /usr/bin/autoconf --force <daviid>configure.ac:73: error: possibly undefined macro: GUILE_MODULE_AVAILABLE <daviid>unbelievable, i'am using epiphany, browse guix/download, click on tarball and ... switch my desktop window to another, opens firfox ... whaaaaatt? <ng0>I want to write an mach build-system one day just to cover up the stupid things I have to do with the mach build system <ng0>this is far from "nice" <daviid>pfuut this is not my day! grabbed the tarball <daviid>./configure -prefix=/opt2 -> configure: checking for guile 2.0 <daviid>checking for guile... /opt2/bin/guile <daviid>configure: error: found development files for Guile 2.0, but /opt2/bin/guile has effective version 2.2 <daviid>both guile-2.2 comes before in my $PATH and /etc/ld.so.conf.d/ <daviid>which lists lib directries of course <daviid># we use /opt for manually installed packages and software <geemili>I'm looking for a cloud hoster that will let me upload GuixSD images. <OriansJ>well deploying guix on debian/ubuntu on digitalOcean/linode is trivial. However I don't know how to convert that to a full guixSD install <emyles`>How can I build a haskell package with ghc-8.0.1 instead of 7.10.2, I've tried various things including (arguments '(#:haskell 'ghc-8))? <OrangeShark>emyles`: I think you usually create a package that inherits the package you want built with ghc-8.0.1 and add ghc-8 as an input <emyles`>This would be a new package, the docs for haskell-build-system says: "Which Haskell compiler is used can be specified with the ‘#:haskell’ parameter which defaults to ‘ghc’" <emyles`>In gnu/packages/haskell.scm there is: (define-public ghc-8 (package (name "ghc") (version "8.0.1")...but I get this error: [my-package] has an invalid input: ("haskell" (quote ghc-8)) <emyles`>OrangeShark: I'll try your suggestion... <OrangeShark>ghc-8 has to be the haskell compiler package, not a 'ghc-8 or (quote ghc-8) <emyles`>Thanks a lot! That seems to be working better. <emyles`>mines still downloading, says it will be 1018.5MiB installed! <emyles`>/ghc-8.0.1/bin/ghc-pkg: error while loading shared libraries: libncursesw.so.6: cannot open shared object file: No such file or directory <emyles`>OrangeShark: thanks for the help but I have to go now, I'll check the IRC logs and write to the ML tomorrow if necessary <efraim>I'm like a week into building and rebuilding all of qt, and now I want to start all over again to not build examples or demos :/ <efraim>rebuilding all of qt again, this time with tests, without examples&demos <janneke>ACTION is having all kinds of troubles with GNOME -- so it seems <janneke>grmbl gsettings...what are they thinking... <janneke>i found why i cannot seem to switch to guile-wm yet <janneke>it crashes on my dvorak keyboard -- it runs fine with usual us/qwerty <civodul>i think there was a bunch of glitches for me <janneke>where has mwittmer gone?...it's so close! <janneke>i wrote a gsettings script some years ago to `sort-of-declaratively' push my settings <cehteh>oh .. fuu .. trying to install 0.12 on a old netbook, the usb image kernel panics <efraim>I had that on my P4 with an installed system, turned out it wasnt gettig enough power <cehteh>how can one scroll on a paniced console <civodul>cehteh: should can use shift-pageup in the console <civodul>would be great if you could find hints <cehteh>civodul: was somehow damaged installation medium, i dd'ed anew, works now <cehteh>but in kernel panic mode scrolling doesnt work that way, at least it didnt for me <cehteh>testing the new graphic installer cant be done with the 0.12 image yet? <civodul>(they are signed by jmd who made them) <efraim>did libgit get patched? I'm still on my qt branch <janneke>could it be that --upgrade will remove python2 and install python3? <efraim>oh, related to the "tell me what you're going to do first and then do it" bug that's related to grafting, --keep-going only works for me if I also pass --no-grafts <janneke>civodul: are there many scenarios where running python3 instead of p2 would work? <efraim>civodul: its the similar "grafting is the real building" and to prepare for that/get the source it has to build all the packages first <thomasd>I'm building a package, but it feels like Guix is an infinite loop after @build-succeeded <thomasd>when I look strace the guix process, i see it's opening a bunch of /gnu/store/*.drv files, with returnocde 13. It's re-opening the same drv files all the time <thomasd>any hints on how to start diagnosing the issue? <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 :) <jmd>Is it possible to boot GuixSD without /gnu/store mounted? <civodul>thomasd: which process keeps reopening .drv files? <civodul>would be great if you could pinpoint the code that's doing that <civodul>could it be the 'guix substitute' process? <civodul>thomasd: using strace (like you did already i guess?) <civodul>just: strace -p the-right-guix-daemon-child-process -o log <cehteh>ah .. civodul thanks .. trying the graphical installer image <thomasd>civodul: it's the guix client process which is opening all the .drv's. When I strace, I just see a lot of calls to open, fstat, lstat and the like... sorry if I'm slow to understand :) <civodul>and it keeps repeating the same sequence of open(2) calls? <civodul>is it reproducible if you C-c and start again? <thomasd>(hmm using ps aux, I just notice that my guix-daemon is still from guix-0.10.0 -- is that normal?) <civodul>'guix pull' doesn't upgrade the daemon (yet), that might be the reason <thomasd>civodul: it's not the exact same sequence of open calls all the time, sometimes a new drv is opened, but it's mostly opening the same ones: glibc, bash-static, gcc <thomasd>e.g. grep -e "open(\\"/gnu/store/626z09.*.drv" ~/Dev/guix/strace3.log | wc -l => 48583 <thomasd>I'll now check if it's the same sequence every time <thomasd>ok, let me try to be less confusing: 1) it looks like the sequence of drv's doesn't repeat exactly (sometimes, a new one is opened, but mostly it's always the same on <thomasd>2) i'm still trying to check if the sequence of open calls is deterministic <thomasd>as to 2: yes, the sequence is the same every time i start the process (at least the first 24848 calls to open("/gnu/store/....") are identical <thomasd>yes, at least I'd be surprised if the sequence started to differ later on <mark_weaver>civodul: I think staging is ready to merge. what do you think? <sneek>Welcome back mark_weaver, you have 1 message. <sneek>mark_weaver, lfam says: Are you able to look into this report of malicious files being distributed with Firefox and Icecat? See the preceding lines in the IRC log for some more detail. <mark_weaver>I've actually updated my primary system to staging, and it works well. <mark_weaver>more precisely, I've updated my system to a private 'gnome-updates' branch that's based on top of staging. I'm running GNOME 2.22 here. <mark_weaver>I'd like to push that branch, but I want to merge staing first :) <mark_weaver>(I cancelled the remaining mips/armhf jobs on master, to focus the limited build capacity on staging) <civodul>mark_weaver: i think it's ready to merge, indeed <mark_weaver>civodul: the commit hook is rejecting the push, because there are several unsigned commits on the staging branch, going way back. <mark_weaver>going back at least a month, with commit adbff6f3837528751a252ae6b32d2623359a62c9 from jmd <mark_weaver>efraim: the GPG key that you uploaded to savannah is malformed. it's missing the header and footer, "-----BEGIN PGP PUBLIC KEY BLOCK-----", etc. <civodul>they should have been rejected too no? <mark_weaver>civodul: I'm not sure why, but the message is: "remote: error: commit 'adbff6f3837528751a252ae6b32d2623359a62c9' lacks an OpenPGP signature; rejected" <mark_weaver>"remote: error: hook declined to update refs/heads/master" <mark_weaver>it might have been the very first commit of the staging branch <mark_weaver>I have a vague recollection that the commit check doesn't (or didn't) work properly with the first push of a branch? <civodul>oh and the hook doesn't check the first commit? <mark_weaver>that means we have to resign all of the commits that were made on top of it. <efraim>mark_weaver: I'll repost it later today when I get home <civodul>a loss more than a mess, but that sucks <civodul>Git has grafts, which describe object replacements <civodul>i think it's actually called "replacement" now <efraim>Like cherry-picking everything after it? <civodul>mark_weaver: i'd like to finish what i was doing before trying though <pareidolia>I'm installing GuixSD in a VirtualBox VM following the manual. herd start cow-store /mnt fails with an exception <civodul>pareidolia: hi! could you paste more details? <mark_weaver>civodul: another commit on the 'staging' branch apparently has a bad signature: 6a34f4ccc from tobias <mark_weaver>although its between two other commits signed correctly with the same key as the bad commit <mark_weaver>there's another bad signature from tobias: 7d162df8ce <civodul>mark_weaver: yes, we discussed those on the list <pareidolia>Can I get a prebuilt appliance for Virtualbox somewhere? <civodul>pareidolia: and running "herd start cow-store /mnt" again doesn't help? <mark_weaver>civodul: actually, I'll take care of rebasing 'staging' on master. it's easy, and there aren't many commits. <mark_weaver>and I can clean up the "revert revert revert nss update" <nliadm>revert "revert "revert "revert "nss update"""" <mark_weaver>it's only 13 commits, once the revert pairs are collapsed <civodul>lfam: i'm about to push a fix for --check <civodul>in other news mark_weaver was about to merge staging but there are problems with unsigned commits and commits with wrong signatures <lfam>civodul, mark_weaver: I have to disable that pre-push signature-checking hook when pushing new branches, or parts of branches that contain bad signatures. <lfam>And there are recent commits with bad signatures. I believe I pointed them out on that guix-devel thread recently. <mark_weaver>lfam: I don't know, I think maybe we should keep the strict checks. <lfam>I can't figure out another option to make these pushes <mark_weaver>once we get it air-tight, so no bad commits get in, then merges should be okay from then on. <lfam>We really need to do it on the server, IMO. The pre-push hook is only designed to prevent accidentally pushing unsigned commits <mark_weaver>I'm rebasing the 'staging' branch onto master, and also collapsing revert pairs where possible. <mark_weaver>honestly, in this case, I think the linear history is a lot nicer to look than all the merges and revert revert reverts :) <civodul>maybe we'll have to run our own Git server so we can have complex hooks <lfam>The revert revert reverts are something I'll try not to repeat :) <lfam>On the server, we need a keyring and a GnuPG installation, right? <mark_weaver>the server side hook doesn't have to be air-tight, because we shouldn't be trusting the server in any case. <mark_weaver>really, these checks should be done on our own machines, when we pull. <mark_weaver>the server hook only needs to prevent accidental mistakes, to prevent painful merges and things of that sort. <lfam>That's a good point about not trusting the server. I think it's worth doing it before pushing, before the server receives, and when pulling. <lfam>The reason to _try_ doing it on the server is to avoid the pain of rewriting history <lfam>I guess that it's more urgent, and potentially more possible, to do it while pulling <mark_weaver>that's the most important place to check from the security standpoint <mark_weaver>I just pushed the rebased patches from 'staging' to 'master'. <pareidolia>pareidolia: However I rebooted and now it works. Maybe strange interaction with partition creation <Helius>How do I compute the sh256/base32 for a git-fetch commit-version ? <lfam>Helius: Check out the commit you want to use, and use `guix hash --recursive --exclude-vcs path/to/git-repo` <lfam>The effect of --exclude-vcs is to ignore the .git directory. You can delete or move it to achieve the same effect <lfam>nliadm gave the best advice ;) <mark_weaver>nss-updates and imagemagick-updates should be rebased on current master <cehteh>herd start cow-store /mnt yields a Invalid argument in procedure 'mount' error, whats that? <cehteh>and by the way, instead fuse unionfs are there plans to use the kernels overlayfs? <lfam>mark_weaver: It also fails the test 'fastopen.sh' <mark_weaver>lfam: indeed, and the same failure happened on the first attempt as well. <lfam>I'm doing a --system=i686-linux build on my x86_64 machine to see if I can reproduce it and get at the log of failing test <Apteryx>I'm wondering how it would compare to a Logitech C920 or similar. <lfam>mark_weaver: I can't reproduce the failure with `./pre-inst-env guix build --system=i686-linux -e '(@@ (gnu packages tls) gnutls-3.5.8)' -K` <lfam>It's the same derivation, /gnu/store/frcs65v24qc9arh1j8jmqbj234z63w4y-gnutls-3.5.8.drv <Apteryx>Or, any other good webcam recommendation? <lfam>Apteryx: I think that webcam *must* work with linux-libre, considering it's sold by Think Penguin and they claim it's supported on distros using linux-libre. <lfam>I'm sure they'd be willing to confirm it for you <davexunit>I've yet to see a webcam that doesn't "just work" on linux-libre <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>I also have a Logitech webcam that has "just worked" on all of my libre systems, with no problems whatsoever. <mark_weaver>it was given to me a few years ago. if I were buying one now, I'd probably go with the ThinkPenguin. <davexunit>mark_weaver: I wonder if guile 2.2 will help or if most time is spent in IO with the daemon <mark_weaver>surely it will help, although not enough for the kind of performance I'd like to see in Guix. <davexunit>yeah, I don't expect it to be the only piece of the puzzle. <Apteryx>Just placed an order with them (ThinkPenguin). Looking forward trying it out. <efraim>looks like I need separate "QT_BUILD_PARTS+=tests" "QT_BUILD_PARTS-=examples" "QT_BUILD_PARTS-=demos" <lfam>mark_weaver: Is this a good time to start evaluating imagemagick-updates and to create new job and evaluation for nss-updates? <cehteh>oops, system init failed with "timestamp in future" blah, dont we want to set the hwclock on installation, either document that or even better include ntpdate in the installation procedure <efraim>iirc ntpdate is depreciated, I think the suggestion is "ntp -q" for the same functionality, but I could be wrong <ng0>I wonder what the problem with recent kernel versions is <ng0>2 computers already which need 4.4 version <pareidolia>I think the documentation is outdated. Grub doesn't want to be installed on an ext4 partition <lfam>pareidolia: Can you point us to the specific section? <pareidolia>Make sure the grub-configuration form refers to the device you want to install GRUB on. <janneke>ACTION comments-out all geiser and guix from .emacs.d/init.el <mark_weaver>lfam: have you done any local testing of those branches, e.g. building icecat using the new nss? <lfam>All the recent NSS update attempts built on my machine. But I didn't build icecat with this 3.28.1 release. I'll try it now <paroneayea>guix-repl-guile-program: Symbol’s value as variable is void: guix-scheme-directory <paroneayea>after the guix / guix.el separation, but I haven't figured out why yet <efraim>I think some of the tests in the qt modules rely on the examples <mark_weaver>lfam: I know of three separate changes that involve non-trivial rebuilding, and the question is how best to make use of hydra's resources. <lfam>The imagemagick-updates thing can be left for an idle moment. <mark_weaver>if we build out three separate branches all based on current master, the problem is that when they are all combined, that will be another set of rebuilds. <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>Ah, I didn't realize parts of it had run to completion. I'll look <mark_weaver>(I thought it likely that most of the problems related to the imagemagick update would be adequately revealed on those two platforms) <lfam>ZombieChicken: You can dig in with `guix graph vim` :) <efraim>tcsh ended up as a low-level dependency <ZombieChicken>ACTION ponders how to use the Guix version of vim instead of the version installed by Portage <lfam>Only synfig and perl-image-magick failed on that branch. But, I think we'll have to test packages manually as well. <mark_weaver>lfam: all of the x86_64 builds ran to completion or failure. some of the i686 jobs were cancelled, but not very many. I restarted a few of them just now. <mark_weaver>lfam: but overall, it looks to be like the imagemagick-updates branch is good enough to mix together with the nss-updates <lfam>mark_weaver: I wonder about ImageMagick's changed "shell API". I wonder how many packages use it and if they test it at build-time. <mark_weaver>lfam: remember, the jobset ran to completion on x86_64, so any undetected problems would also need to be platform-specific <ng0>I think I will ask tcsh upstream about the 2 failing tests, as we seem to have no t/csh experts among us <lfam>pareidolia: That section doesn't give line-by-line instructions that one must follow. You have to make the partition layout that you want to use. <lfam>It doesn't even suggest a partition layout, it just suggests using a tool like cfdisk <mark_weaver>if the problems don't cause failures at build time, then I guess we might not discover the problems until we update our own machines. <lfam>mark_weaver: Yeah, and that's what I was trying to avoid by reverting the ImageMagick 7 update on the master branch <mark_weaver>that's what I did to test the gnome-updates branch. I built it out on my own machine. <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 <adfeno>Hi #guix, I think I might have found a bug, particullarly when calling `emacs --daemon`. I'll see if I can reproduce it again. <janneke>and i don't know what I upgraded...tried to revert to all kind of things <janneke>the most ugly thing is that emacs crashes all the time on me -- it never ever did before <paroneayea>janneke: I just realized that if I removed the load-path from guix/emacs that it fixed the ones I was having <janneke>and now the latest thing is that (require 'geiser) does not work <janneke>i haven't really taken the time to look, things get weirder and weirder <paroneayea>janneke: are you installing geiser through guix? <adfeno>What is the issue, perhaps I might be able to help. <janneke>adfeno: i have gnome weirdness, emacs loadpath/geiser/guix install weirdness, but my main problem is finding an emacs that does not crash <janneke>it seems to be related to compilation buffer or some keystrokes there <janneke>i need to finish some work and i need emacs... <ZombieChicken>well, tcsh or not, gvim from guix already seems more stable than from Gentoo. Who'duv thunk it? <janneke>/gnu/store/3wkp4d7h1dlsyr552cw491ijf3p54272-emacs-25.1/bin/emacs-25.1[0x504142] <janneke>/gnu/store/3wkp4d7h1dlsyr552cw491ijf3p54272-emacs-25.1/bin/emacs-25.1[0x4ebec9] <janneke>/gnu/store/3wkp4d7h1dlsyr552cw491ijf3p54272-emacs-25.1/bin/emacs-25.1[0x5030ee] <janneke>/gnu/store/3wkp4d7h1dlsyr552cw491ijf3p54272-emacs-25.1/bin/emacs-25.1[0x5032f3] <janneke>/gnu/store/3wkp4d7h1dlsyr552cw491ijf3p54272-emacs-25.1/bin/emacs-25.1[0x50337c] <janneke>/gnu/store/iwgi9001dmmihrjg4rqhd6pa6788prjw-glibc-2.24/lib/libpthread.so.0(+0x110f0)[0x7ff1ec8e30f0] <janneke>/gnu/store/3wkp4d7h1dlsyr552cw491ijf3p54272-emacs-25.1/bin/emacs-25.1(re_search_2+0x3d8)[0x53a018] <ng0>hurgh. I'm getting CA cert issues for git on one new installation <ng0>all variables are exported <lfam>ng0: What's the error say? <ng0>the usual error you get when you have no GIT_CA exported <lfam>ng0: What's the result of `realpath $(echo $GIT_SSL_CAINFO)`? <ng0>that would be bash, but I can give the output in a minute <lfam>That should work in any POSIX shell, not just Bash <ng0>nah, csh rejects the $() thing <ng0>at least last time i tried <lfam>That's a defect in csh :) That syntax is in POSIX <lfam>Thankfully! The backticks are too hard to nest <ng0>the command gives me at the end of the PATH : No such file or directory <ng0>what I meant was after the PATH, the path is printed <ng0>but at the end I get the "no such file" <ng0>I just source the $HOME/.guix-profile/etc/profile in my bashrc <ng0>in addition to the profile one <lfam>ng0: I can reproduce it. GIT_SSL_CAINFO wants a single file, but GIT_SSL_CAINFO is being set like a search path <civodul>mark_weaver: not sure what to think of that 'guix offload' error <ng0>so I just set this variable to an old one I had, after the sourcing of the file <ng0>strange is though that it works here <ng0>but doesn't work on the other computer <ng0> export GIT_SSL_CAINFO="$SSL_CERT_FILE" <lfam>I think this used to work on GuixSD <ng0> I don't know, I've always used individual exports until recently <lfam>I noticed this yesterday on my foreign distro, where I export $HOME/.guix-profile/etc/profile <lfam>But, I don't know what changed. It's a bug <ng0>when I export this variable, I can clone again. <ng0>If I don't forget it, I will open a bug later <ng0>right now my head is don't at it <lfam>My Guix-generated shell profile now does this: <ng0>distratcted by multitasking :) <lfam>export GIT_SSL_CAINFO="${GUIX_PROFILE:-/gnu/store/b1cv3dgxx03ifn2lppn4kzf6cjlfli7l-profile}/etc/ssl/certs/ca-certificates.crt${GIT_SSL_CAINFO:+:}$GIT_SSL_CAINFO" <ng0>I'm starting to hate the mach build system. I'm very close to the point where palemoon actually gets installed, but this system... nope. <paroneayea>guess I need to update my gnutls-with-guile-next patch to handle the latest changes in master <ng0>okay, 2 days of joy of advancing with palemoon after months, now I'm sick of mach build-system again and I will work on this whenever <ng0>would be cool to see the qt patches to land soon, I've started packaging yet another browser which needs some more qt tools <nliadm>I think browsers were Alighieri's 8th circle? <ng0>We detected your operating system as: %PLATFORM% Recommended download: %FILENAME% .. good to know, Qt.io <ng0>were is qtwebengine? is that something we still need to package? <ng0>or am I just not searching well enough <ng0>for qtwebengine, i'll just search the qt servers <ng0>what module are qtwidgets, qtdbus, qtlinguist-tools, qtsql, qtprintsupport, qtnetwork, qtgui part of? <ng0>forgot one: qtconcurrent <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 <lfam>ACTION works on the BIND update