<lfam>ERROR: invalid replacement "/gnu/store/3szw4bvhlm0pv9fm6vhmzzdj64d7gvr6-python2-libxml2-2.9.3" "/gnu/store/5pp4pv6k8hhx2fgx62d40c028lszr8ga-libxml2-2.9.3" <lfam>That's what I get while trying to build gnome-settings-daemon from 007c20b61c, although was happening before that too, at least after 493e9a5a8f <lfam>Trying it with (replacement #f) in python-libxml2 <lfam>So much grafting... it brings to mind our other metaphor, the hydra :) <lfam>That worked. Now to check its references <lfam>It refers to the grafted libxml2 <notadrop>it was you I was talking to last night, right? <notadrop>I'm going to attempt installing guix tonight. <Emacsite>you could have just done it last night if you're going to do it this night lol <Emacsite>oh yeah notadrop , and i will NOT respond if u just type. i have a huge amount of channels open and can't keep track of them all, so mention me if u want me to respond <notadrop>Emacsite: GRUB can't identify the fs on the GuixSD installer image. did it do that to you? <Emacsite>you could try booting into it several times <brainiarc7>Has anyone here succeeded installing GuixSD in UEFI boot mode from USB installation media? <efraim>I don't think we support uefi yet <efraim>which is a pity because I was gifted some old macbooks I want to upgrade <roelj>Most parts should be in.. The linux-libre configuration seems to support UEFI. <roelj>I wonder if the GRUB in Guix support UEFI.. <notadrop>Hi! Is it fairly easy to get some kind of WM like Openbox up and running on GuixSD? <roelj>notadrop: There's even an example operating-system recipe that includes openbox in gnu/system/examples/desktop.tmpl <civodul>alternately, you can provide ~/.xsession <roelj>It's so nice to have a properly working Dia.. No more disappearing shapes.. Thanks to Guix! <notadrop>The GuixSD install process, from what I can see, does not install GRUB (if I am remembering right... I read the installation guide last night.) So I do that myself? <notadrop>I am reading the GRUB manual anyway, so I can easily write my own config file and all of that if needed <mark_weaver>notadrop: "guix system init" installs grub by default <roelj>Where do collisions come from in a profile? <roelj>(Or where could they come from) <rekado_>roelj: all packages are installed in their own namespace in /gnu/store. Since it's inconvenient to use programs like that they are usually linked into profiles. <rekado_>what happens is that the union of all these directories has to be computed. <rekado_>if two packages both provide $out/lib/bla.so Guix has to pick one. <rekado_>although the packages are independent and they may both provide files of the same name, having the same name is problematic in profiles <roelj>Oh ofcourse.. Thanks a lot for the clear explanation! ***ifur_ is now known as ifur
<davexunit>yesterday was another one of those days at work where using guix was by far easier than using something else. <rekado_>I'd like to make the CRAN importer more robust, but I cannot find any example of catching HTTP errors in our code. <rekado_>what is this error "condition" stuff? <FNTM-U3>If I install guix could I install nvidia-binary blob? <brainiarc7>It would be best to install that from your system's package manager. <brainiarc7>That is a system package that may have quirks set up for both your distribution (Debian) and your kernel version( for things such as DKMS) <davexunit>trying to run pre-built binaries built for FHS distros (Debian, Fedora, etc.) on GuixSD systems will most definitely result in failure. <brainiarc7>The reason I held off deploying GuixSD on my UEFI only system is because it wouldnt boot. <brainiarc7>If anyone here knows how to set up GuixSD to boot up in UEFI mode <lfam>brainiarc7: Did you search the mailing list archives? There might have been some discussion on guix-devel, bug-guix, or help-guix. <bavier>rekado_: can julia not build with a system suitesparse? <davexunit>brainiarc7: sorry, I've never owned a computer that uses UEFI <lfam>brainiarc7: I don't know much about how booting works, so I can't offer much advice. But I guess the first step would be to read about how GRUB interacts with UEFI. Then, you could look at how we use GRUB, and figure out how to adapt it to work on UEFI. <lfam>It would probably go faster if you virtualized it. Guix and QEMU are well-integrated, and it looks like QEMU can emulate UEFI, so that would probably be a friendly place to start experimenting. <lfam>And, that's 100% of what I know on this subject ;) A few guesses and a sprinkling of speculation <efraim>maybe one of the pre-release versions of grub would help <bavier>I'm working on packaging libmesh, which bundles a lot of dependencies. I'm considering patching their build system to use system libraries instead. At the same time I'm rereading wingo's blog post about conway's law ;) <davexunit>I don't think conway's law is any excuse for bundling :) <bavier>in libmesh's case I don't think so either, since most of the bundles only have trivial changes or none at all <davexunit>yeah, bundling is when you just include upstream software without changing it <bavier>sure, with patches would be forking I guess <davexunit>trivial changes are also annoying because people make changes to software that make new versions incompatible, leaving it vulnerable. <GNUtoo-irssi>let's say a user (me) forgott to enable binaries at the beginnings <GNUtoo-irssi>now, as soon as that user wants to install a package (like hello), it'll build it <GNUtoo-irssi>However if that user later enables binaries packages after having built hello and all its dependencies (that includes the toolchain), it might not give the same exact packages (because I built from parabola) <GNUtoo-irssi>So since some derivations are not the same (hash differs) it would build what depends on them, right <GNUtoo-irssi>or am I totally off track? That's the only explanation that still last right now (for the issue I have) <bavier>GNUtoo-irssi: what matters is the derivation, not the contents of the resulting store item <bavier>in your case, the pre- and post-substitutes hello package both come from the same derivation <bavier>of course, we're trying for reproducible builds, so some packages will have a one-to-one correspondence between the derivation and the store contents <GNUtoo-irssi>(I remember it as beeing the output, being identified by its hash) <GNUtoo-irssi>bavier: what happens when the "derivation -> store content" has a one to may result? <GNUtoo-irssi>could it result in it triggering builds instead of installing binary packages <bavier>GNUtoo-irssi: if the build is not reproducible <GNUtoo-irssi>What could explain the fact that it builds packages when I do: guix package -i hello, or guix system vm ./default.scm # <- example.scm has the content of the example in the manual <GNUtoo-irssi>If I reinstall it from scratch, would it have a better chance to work (assuming I screwed up somewhere, or triggered some bug) <catonano>I was mumbling about the recipe for Emacs Cider, the clojure equivalent for Slime. CIder depends on pkg-info and pkg-info depends on epl. These are package management packages. Does it make sense to make them Guix packages ? <davexunit>catonano: yeah, it's fine. it helps people in transitioning to guix, if nothing else. <davexunit>at work I use a hybrid environment for ruby development <davexunit>and we otherwise don't impose many restrictions on software here <davexunit>pretty much as long as it's free software we'd gladly accept a package <GNUtoo-irssi>OK, I did that: I booted a vm with the install image/cd, setup the network and mounts, herd start cow-store /mnt. Then guix pull and guix system init /mnt/install-data/example.scm /mnt <GNUtoo-irssi>I'll wait for it to finish, maybe the builds are minimal <GNUtoo-irssi>In that case I'll probably bootstrap the systems from that vm <roelj>What could cause the font rendering in Emacs (from Guix) to not do anti-aliasing? <roelj>Other GUI applications seem to be unaffected. <davexunit>and how does he know how to play it pretty much perfectly on the recorder of all things? <roelj>Exactly. I thought I spent most of the time responding to e-mail, but apparently he has time left :D <GNUtoo-irssi>He's also a journalist (he writes articles), a singer(guantanamera), a programmer, an activist, he was a dancer too etc... <roelj>I would really like to have proper font rendering in Emacs.. <civodul>roelj: are you sure it's not proper :-) <roelj>Yes, it's not smooth :) It's the same as if I set "Antialiasing" to "none" and "Hinting" to "none" in gnome-tweak-tool. <roelj>The funny thing is that it only happens with Emacs, and not with other programs like Dia.. <mthl>roelj: I know that Emacs is not affected by .Xresources on Debian too <mthl>And if I remember correctly not by gnome-tweak-tool either <mthl>I mean the Emacs installed with APT not Guix. <mthl>is it on GuixSD or on a foreign distro? <civodul>maybe you need to run "fc-cache -fv" <roelj>Hmm, that didn't seem to change things. I even rebooted.. <civodul>an you have fonts installed in ~/.guix-profile? <civodul>i think there was the exact same discussion on help-guix some time ago <roelj>I tried to find it in my mail archive, but couldn't.. <roelj>Hmm. I am kind of getting used to this ultra-sharp font rendering.. <civodul>perhaps you could strace it to see which font files it's picking up <roelj>I found the topic on the mailing list <roelj>When zooming in a lot, the font looks fine <roelj>It reads the fonts from the store, so that's good <roelj>It seems some fonts look good, while others dont.. Heh.. 