<enderby>i asked a few days ago, but didn't get a response. i'm getting 'guix package: error: profile contains conflicting entries for <insert package name>' errors when I do try to upgrade packages. any idea what I need to do? <adfeno>enderby: I'm not a GNU Guix expert, but I would first try to remove both packages. <enderby>adfeno: yeah, i have tried doing that. I think it actually gave me another one of those errors on the second removal command I did... <quiliro>quiliro@portkomputilo ~/guix$ loadkeys dvorak-es <quiliro>Couldn't get a file descriptor referring to the console <enderby>quiliro: yeah i had just done a 'guix pull', then a 'guix package -u guix' and that's when I got the error. I have also seen similar errors when I tried to upgrade other packages. <quiliro>enderby: did you report it to the mailing list? <quiliro>root@portkomputilo ~# loadkeys dvorak-es <enderby>quiliro: i haven't, although I had seen someone report similar in the mailing list, and they'd been given the same "try removing the packages" advice <quiliro>adfeno: you still think it is for each user? i think it is a global thing <quiliro>enderby: try supplementing the report the other person has made so there is more information to solve it <quiliro>that is a critical error because it is not just a feature....you cannot use guix package any more for what it was made <adfeno>quiliro: I wonder if root can use loadkeys as expected. <adfeno>Is dvorak-es required in the configuration? <adfeno>I mean, the "system.scm" file (generally at "/etc", if I'm not mistaken). <quiliro>adfeno: i will not die....but i would be more confirtable <quiliro>you mean that if i included it....but what keywork? <adfeno>I mean, if I'm understanding how GuixSD's "system generations" work, then I suppose it has to "know" what to put in the place where loadkeys expects dvorak-es. <adfeno>I think we are looking for the "kbd" package... although I wonder if it isn't included already. <fr33domlover>I'm trying to `guix pull`. After some guile-ssh tests, Guile is running, `top` says 10% CPU usage, no input is being printed, --verbose doesn't help <fr33domlover>It happened a few times for another user, and then magically somehow once it worked <kyamashita>Apparently the recent poppler graft is causing an issue with Inkscape. <kyamashita>Inkscape is still looking for the old shared library. The two shared library versions have different version numbers in their name, which is probably the root of the issue. <kyamashita>It looks like the issue might be specific to Inkscape. <rain1>it was raised here that youtube-dl may be executing nonfree javascript <rain1>i have been looking into that a bit <rain1>I am a bit curious if these special "signature" videos can be watched in icecat/librejs browser <kyamashita>rain1: I am as well. I haven't been following the discussion closely, so I'm not sure how to tell if a video requires the nonfree JS execution or not. <kyamashita>thanks again rain1, definitely an interesting issue. <rain1>yes id love to hear what you and others think <rain1>and if you have any question I can look into it more <reepca>Trying to understand pivot_root is proving a frustrating task. As far as I can tell, the man page explicitly states that there's no guarantee that it will do what it says it should - it says it will "change the root filesystem", but it "may or may not change the current root". Is there supposed to be a distinction between "root filesystem" and "current root"? ***jonsger1 is now known as jonsger
***kelsoo2 is now known as kelsoo
<rain1>what are you doing with it and what goes wrong? <efraim>Trying to compile go or syncthing with it, I have a recipe for gccgo7 but I think there's something wrong with the C linker <rain1>hm, the golang go implementation has its own linker <rain1>i assume gccgo uses the normal linker (gold) <rain1>it would be very awesome if we can build gccgo then golang with it <rain1>so gccgo7 builds, but is not usable? <rain1>can it even compile a simple helloworld.go? <efraim>I need to test it not on aarch64, I think my issue now is gccgo links to /gnu/store/gccgo/lib/libgcc_s and everything else links to /gnu/store/GCC-lib/libgcc_s ***kelsoo1 is now known as kelsoo
<bavier>I'm sitting here with a poor internet connection thinking that it would be nice if the daemon first downloaded everything that had substitutes available before moving on to building stuff <bavier>then I wouldn't have to worry about mainting the connection for as llong <bavier>I'm currently trying to grok some more of the libstore code <rekado_>ACTION builds python-numpy-documentation with texlive-union <rekado_>I’d also like to see a clear distinction between graft derivations and other derivations. <rekado_>sometimes I’m afraid to see that I’ll have to build a lot of things just to see that they are all grafts <efraim>We have the --no-grafts flag, it should be possible <rekado_>I suppose we could also attach some more data to derivations, e.g. labels <civodul>i'm thinking of giving another stab at that "build continuation" idea <civodul>that could perhaps fix all these graft-related issues <bavier>civodul: forgive me, what's the idea? <civodul>catern: re private repos, it's been discussed notably in the context of the potluck; there are ways to reduce coupling between external repos and the Guix repo <civodul>bavier: it's about how we represent grafting <civodul>currently it's "transparent" API-wise, meaning that you ask for a package derivation and you get it, possibly grafted <civodul>the idea was that we'd register the "grafting" derivation as a continuation of the normal continuation <civodul>which could in theory allows us to do a first pass, then call the continuations unless --no-grafts is passed <bavier>idk, I'm seeing comments in nix/libstore/build.cc like "ensure substitution goals happen before derivation goals" <bavier>but that's not what I'm seeing happen in practice <bavier>oh, I think the ordering is only maintained within a particular "goal"'s dependencies, not globally <catern>civodul: hmm do you have a specific thread in mind? definitely it seems related but I don't see much discussion of this in the potluck threads <catern>the whole question of "where do sources come from?" is really tricky <catern>though I feel like I'm missing some obvious solution...