IRC channel logs


back to list of logs

<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>enderby: guix pull
<quiliro>did you do that first?
<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
<quiliro>cannot open file 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
<enderby>quiliro: okies. thanks
<quiliro>that is a critical error because it is not just a cannot use guix package any more for what it was made
<quiliro>enderby: ^
<enderby>yes, agreed
<quiliro>gotta go...good luck people
<enderby>thanks, peace
<quiliro>o/ peace to you too \\/
<adfeno>quiliro: I wonder if root can use loadkeys as expected.
<adfeno>Sorry... You already did it. :(
<adfeno>Is dvorak-es required in the configuration?
<quiliro>adfeno: YEP
<adfeno>s/in the/ in the system/
<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.
<quiliro>adfeno: i will search in the manual
<quiliro>thank you for the idea
<quiliro>i will investigate
<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
<fr33domlover>Now I want to `guix pull` for root user too
<fr33domlover>Tried many times, it gets stuck like that every time
<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.
<rain1>check my 2 posts here if you like I think they will shed some light on exactly what is happening
<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
<efraim>Gccgo is kicking my butt still
<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
<catern>does guix have a solution for this use-case and problem with Nix?
<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
<rekado_>bavier: same here!
<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
<rekado_>civodul: more power to you!
<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
<civodul>something like that
<bavier>hm, interesting
<bavier>idk, I'm seeing comments in nix/libstore/ 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...