IRC channel logs


back to list of logs

<sturm>It looks as though `mysql-configuration-file` is the Guix function that I need to change
<paroneayea>hi sturm !
<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
<sturm>hi paroneayea :D
<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> 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?
<daviid>using gnome
<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>configure: found 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/
<daviid>which lists lib directries of course
<daviid>cat /etc/
<daviid># we use /opt for manually installed packages and software
<geemili>Does anyone use GuixSD on a server?
<geemili>I'm looking for a cloud hoster that will let me upload GuixSD images.
<emyles`>geemili: have you seen this thread?:
<geemili>emyles`: Nope. I'll look through it
<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>oh, then it a parameter to build system
<OrangeShark>let me see
<OrangeShark>it should be (arguments `(#:haskell ,ghc-8))
<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.
<OrangeShark>hmm, I seem to be getting an error from ghc-8
<emyles`>mines still downloading, says it will be 1018.5MiB installed!
<emyles`>/ghc-8.0.1/bin/ghc-pkg: error while loading shared libraries: cannot open shared object file: No such file or directory
<OrangeShark>I get the same error
<OrangeShark>oh hmm, just doing ghc --version causes it too
<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
<civodul>'lo Guix!
<janneke>ACTION is having all kinds of troubles with GNOME -- so it seems
<janneke>grmbl gsettings...what are they thinking...
<civodul>i can't believe it
<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>must be real silly thing...
<janneke>where has mwittmer gone?'s so close!
<janneke>i wrote a gsettings script some years ago to `sort-of-declaratively' push my settings
<janneke>now it seems things changed
<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>power shouldnt be an issue here
<cehteh>lemme try the 32bit version
<cehteh>some atom netbook
<cehteh>how can one scroll on a paniced console
<cehteh>mhm bonked usb flash
<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
<civodul>cehteh: oh, good!
<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>right, you need to grab one of the test images from
<civodul>(they are signed by jmd who made them)
<efraim>did libgit get patched? I'm still on my qt branch
<civodul>i updated libgit2 (security issues)
<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
<civodul>janneke: yes
<civodul>efraim: oh, really?
<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>hi Guix
<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?
<efraim>Which package?
<thomasd>kdevelop, but updated to 5.0.3
<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 :)
<roelj>Is it maybe grafting?
<thomasd>I don't know :-)
<thomasd>but why would it take so long?
<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?
<thomasd>civodul: how can I check?
<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
<civodul>seen on #nixos:
<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
<civodul>so it's reproducible?
<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>3.22, that is
<davexunit>cool :)
<mark_weaver>I'd like to push that branch, but I want to merge staing first :)
<mark_weaver>hi davexunit!
<davexunit>hey mark_weaver :)
<mark_weaver>see for the current status. it's fully built and with almost no regressions on x86_64. i686 is close, and the other ports are further behind as usual.
<mark_weaver>(I cancelled the remaining mips/armhf jobs on master, to focus the limited build capacity on staging)
<civodul>hey mark_weaver!
<civodul>mark_weaver: i think it's ready to merge, indeed
<civodul>mark_weaver: do you want to do it?
<mark_weaver>civodul: sure, I'll take care of it. thanks!
<thomasd>how can I upgrade the daemon?
<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>mark_weaver: how's that possible?
<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>and that commit is from jmd, about a month ago.
<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?
<civodul>it could be that
<civodul>well we have to rewrite that commit
<civodul>and have it signed by one of us
<mark_weaver>that means we have to resign all of the commits that were made on top of it.
<civodul>ah yes :-/
<mark_weaver>i.e. the entire branch, and all the merges, etc.
<efraim>mark_weaver: I'll repost it later today when I get home
<mark_weaver>that's going to be a mess :-(
<civodul>a loss more than a mess, but that sucks
<civodul>or would it work to use a graft?
<mark_weaver>huh? I don't know what a graft is in this context
<civodul>Git has grafts, which describe object replacements
<mark_weaver>would you like to try?
<civodul>i think it's actually called "replacement" now
<civodul>ACTION looks
<civodul>yeah, "git replace"
<efraim>Like cherry-picking everything after it?
<civodul>mark_weaver: i'd like to finish what i was doing before trying though
<davexunit>git has grafts? interesting!
<civodul>but i can try afterwards
<mark_weaver>okay, thanks
<mark_weaver>sounds fishy, though :)
<pareidolia>I'm installing GuixSD in a VirtualBox VM following the manual. herd start cow-store /mnt fails with an exception
<pareidolia>Stuck here, please help
<civodul>pareidolia: hi! could you paste more details?
<pareidolia>civodul: Thank you. Screenshot here
<mark_weaver>manolis didn't upload his gpg to savannah
<civodul>pareidolia: that's with 0.12 right?
<pareidolia>civodul: Yes
<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>ACTION imports all the keys :)
<pareidolia>civodul: I tried marching on, but apparently that doesn't work
<mark_weaver>there's another bad signature from tobias: 7d162df8ce
<civodul>mark_weaver: yes, we discussed those on the list
<civodul>i had forgotten
<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"
<mark_weaver>(unless you object)
<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>oh, hello!
<civodul>in other news mark_weaver was about to merge staging but there are problems with unsigned commits and commits with wrong signatures
<lfam>Hi civodul!
<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>it's only 13 commits after all that.
<civodul>not unreasonable
<mark_weaver>oh, I see. I don't know about the pre-push hook.
<mark_weaver>I was talking about the server-side hook
<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
<mark_weaver>*look at
<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.
<lfam>mark_weaver: Here's that pre-push hook I added:
<mark_weaver>the server hook only needs to prevent accidental mistakes, to prevent painful merges and things of that sort.
<mark_weaver>IMO, anyway.
<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
<mark_weaver>yes, exactly
<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>checking elsewhere is only to prevent inconvenience
<mark_weaver>I just pushed the rebased patches from 'staging' to 'master'.
<mark_weaver>and now I can push the 'gnome-updates' branch
<civodul>thanks mark_weaver!
<mark_weaver>which provides gnome 3.22, which I'm using now.
<civodul>oh, neat
<pareidolia>civodul: No same result
<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
<Helius>lfam: thanks
<lfam>nliadm gave the best advice ;)
<Helius>nliadm: thank too
<mark_weaver>ACTION pushed the 'gnome-updates' branch
<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?
<mark_weaver>gnutls-3.5.8 gets stuck during its test suite on i686, leading to a timeout after an hour without any output. it's happened twice in a row on hydra:
<mark_weaver>the build succeeds on x86_64, armhf, and mips64el
<lfam>mark_weaver: It also fails the test ''
<mark_weaver>civodul: guix-offload raised an exception here:
<mark_weaver> shows that the failure is surrounded by successful builds on the same slave, so I guess it's a non-deterministic error.
<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
<mark_weaver>thank you!
<Apteryx>Has anyone tried the "1080P HD Webcam with Stero Microphone" webcam from ThinkPenguin? (
<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
<mark_weaver>lfam: thanks for checking
<mark_weaver>I'll try on my machine
<mark_weaver>maybe it depends on the kernel
<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
<lfam>That's good to know
<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>IMO, anyway
<mark_weaver>I also have a Logitech webcam that has "just worked" on all of my libre systems, with no problems whatsoever.
<Apteryx>Looks like the 1080P camera that thinkpenguin sale is this:
<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>OK. Thanks for your comments :)
<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
<efraim>sorry, ntpd -q
<efraim>-g also if its really off
<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>janneke: ?
<paroneayea>janneke: have you been having problems?
<paroneayea>janneke: notably I've been hitting
<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.
<paroneayea>oh, I figured it out :)
<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?
<mark_weaver>was that the only problem to be solved here?
<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.
<mark_weaver>ACTION looks
<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)
<ZombieChicken>Uh, why does vim depend on tcsh?
<lfam>ZombieChicken: You can dig in with `guix graph vim` :)
<nliadm>I noteced that, also
<mark_weaver>is it a run-time dependency, or build-time only?
<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
<mark_weaver>*looks to me
<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
<pareidolia>lfam: The docs ask just to make an ext4 partition (or maybe swap)
<jmi2k>I'm trying to package DMZ cursors, but I can't find the original source. I'm thinking about, but I don't know if relying on sources from another distro is desirable.
<mark_weaver>lfam: good point
<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.
<mark_weaver>lfam: good call, thanks for your diligence!
<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
<janneke>paroneayea: lotsa weird problems
<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
<paroneayea>huh, I'm not having that..
<janneke>and now the latest thing is that (require 'geiser) does not work
<paroneayea>that's very strange
<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>paroneayea: yes...
<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>drives me mad :-)
<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?
<nliadm>> Gentoo
<janneke>Emacs says stuff like -- Backtrace:
<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
<ng0>fatal: unable to access '': Problem with the SSL CA cert (path? access rights?)
<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
<ng0>currently rebooting
<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
<lfam>Is $GIT_SSL_CAINFO set?
<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>ah, but here I do
<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>browsers are no joy
<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,
<ng0>were is qtwebengine? is that something we still need to package?
<ng0>or am I just not searching well enough
<ng0>can someone comment on this, if it didn't already happen:
<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 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