<lfam>ng0: I just merged master into core-updates, so be sure to `git pull` to get the latest
<ng0>today was annoying, to find out about the elitism and arrogance of gentoo. i try to not look at it as wasted time but i learned a thing or two about debugging and it's still useful for people what i did and still is useful.
<lfam>ng0: Do you want to give any more details? Similar things were said about Guix recently, so I'm interested to hear your experience with another organization. But I understand if you'd rather let it go
<ng0>I wanted to give more positive outlet on the most recent thread on the mailing list
<ng0>i'll be away for some minutes, then i can give some quick details
<lfam>Okay, that's a good idea. Negativity breeds more negativity.
<Acou_Bass>lfam: youve heard that guix has elitism/arrogance in its community? ive never seen that, not in this IRC room anyway
<rekado>I disagree with the claims of “elitism” or “aloft standards” or “nitpicking”, but it’s hard to defend the mailing list workflow when we cannot effectively keep track of patches.
<rekado>lfam: yes, there should be a web page representation of the queue.
<ng0>I was not 'in' it, I never applied for official developer or proxy, but recently an overlay I am involved in for ~1 year now collaboratively was added to the official list, so I'm sort of in the position of providing software which I wanted to push into portage but backed down because of different reasons. One, there's #355355 bugs.gentoo.org bug which was the ultimate reason to cease communitication with the
<rekado>maybe that’s what github users are looking for.
<ng0>project completely. then they have 2 models for developers (well 3 since they are on github too, but there applies the proxied maintainer as well i think): 1 is applying for developer through a procedure which one can read into on their website, and 2 is as proxied maintainer. this still puts the pressure on 1 person to be responsible for this package alone. In my case I just had the packages i wanted to push
<ng0>to portage in an 99% finished state and they needed some QA done. guix being more accessible to develop for I eventually made gentoo less of a priority and more of a maintenance status thing (gnunet,guix,dependencies.. that's all where i am heading and merging all my ebuilds into guix master since i started in november). the problem is on how you communicate, how you approach people, how you do your "PR". you
<ng0>can not compare guix and gentoo at all at this point because they are over 12 years apart in age. i just find the collaborative way easier to deal with discussion then if you had a strict authority.. gentoo has the council, and I am mind-working on similar possibilities for guix (and in general for projects) which would enable some sort of base democracy with failure switches - gentoo at this point is a
<ng0>there's this one retired gnupg dev i never came back to in one local hackerspace who was interested in guix started with nix at the same time.. but i lack the time to prepare a talk for an upcoming annual convetion there
<lfam>If you thought software was unreliable, try some audio / visual hardware!
<ng0>i think i will talk to meskarune and others, get some more info on the mentors thing as i wasn't so involved in that so far. they also have classroom project (teach a topic in irc channel occassionally) and will continue to think about a fix for the current situation. more attention specifically aimed at people who are willing to review would be good.
<catonano>lfam: what can I say ? I'm really grateful. I can't be there and I'd LOVE a reasoned introduction to the Guix internals
<lfam>catonano: I can't be there either. I was just saying that I'd also LOVE that.
<lfam>It was discussed a little bit on the mailing list a month or two ago
<catonano>lfam: yes, I remember. In fact I think I suggested to try to record some video in that discussion
<lfam>Everybody should record it on their smartphones, if they have one. Strength in numbers :)
<ng0>there's an email i wrote adressing partial problems I see/got pointed out outside of our official channels.. maybe the persons which could respond need some time, but everybody else could give their 2cts :)
<mark_weaver>ng0: I just looked at the perldoc man page. never used it :)
<ng0>did you mean (system* "perldoc" "-oman" "lib/perl5/Net/PSYC.pm" "-d" (string-append man3 "/Net::PSYC.3")) ? because this seems to be wrong again
<lfam>mark_weaver, jlicht: `make clean-go && make` worked for me
<mark_weaver>ng0: it might be that the "lib/perl5/Net/PSYC.pm" needs to go at the end, dunno. what you wrote about should be equivalent to the following command at the shell: perldoc -oman lib/perl5/Net/PSYC.pm -d <man3>/Net::PSYC.3
<frerbst>Now, could somebody explain me how to sign commits in git? I don't want to start pushing (or submitting) anything immediatly, but I want to do it the right way from the beginning, so that I don't need to fix anything later.
<mark_weaver>ng0: so you probably need to move "lib/perl5/Net/PSYC.pm" to the end
<frerbst>According to what I've herd here you have to sign your commits using gpg, right?
<mark_weaver>ng0: also, the "no nroffer!?" might indicate that you need to add 'groff' to the native-inputs
<lfam>frerbst: Signed commits are only required for people who can push to the central repo in Savannah. They don't affect patches sent to the mailing list. For that case, signing the email can help authenticate you. Apologies if you have commit access and I didn't realize it :)
<ng0>but when you have no special config it should have none such
<koosha>lfam: I tryed to use lsh-make-see but I got some errors .
<ng0>Ciphers+MACs are limited, you do not have the UseRoaming setting, and you do not have (or i did exclude it for annoyance and quick start with lsh) the ability to set KexAlgorithms .. on the client side.
<ng0>i do not know enough about lsh to care to set it up.
<mark_weaver>ng0: the main reason why it's preferable to use the upstream makefile than to duplicate it in our own scheme code is that when upstream changes the makefile, we won't need to update our scheme code to match. ideally, updates should not require that kind of work.