Re: Update CoC adapted from upstream 2.1 (instead of 1.4)
> This is very twisted and unfair to Taylan. Is it though? Arguably all of this blew up because of how twisted and unfair Taylan is about this issue generally, given the wiki they run and the fact that they’ve been banned from at least one site for this fixation. Everyone who has commented for the most part have already agreed that they’re ok with updating the CoC to match the upstream so why don’t we let this one go and change the CoC. -- Elais Player
Re: Documentation of what is appropriate for #guix?
> If we were to set up a separate relaxed Guix > community that accommodates all forms of corruption, one problem would be the > impediments that would exist in communication, especially if the original > Guix takes hostile and non-compromising attitude, I think. The discussion at hand is about clarifying what is on topic new channel users, not relaxing a commitment to not promote non free software. A few seconds of searching will almost definitely turn up alternatives if that’s what you’re looking for. That being said I think it would be helpful to add a few sentences to the chat on irc page[1] that clearly state that discussion of non free software is off topic and discouraged in the Channel. I think it will also help if we add the same message to the contacts page[2] as well. 1. https://guix.gnu.org/en/contact/irc/ 2. https://guix.gnu.org/contact/ -- Elais Player On Feb 22, 2022, 04:48 -0700, Yasuaki Kudo , wrote: > If we were to set up a separate relaxed Guix community that accommodates all > forms of corruption, one problem would be the impediments that would exist in > communication, especially if the original Guix takes hostile and > non-compromising attitude, I think. > > If a question arises from that downgraded community how to do this and that, > precisely to accommodate some unaccountable binary black box software, the > chances of getting helpful answers may not be so high from the original Guix > community. > > It is a difficult question - even in the real world the similarities abound. > While it is easy to ignore and isolate North Korea, a country that offers no > useful commodity for export (or maybe it does, but let's say, for the sake of > argument), countries like Japan have no problem importing Saudi Arabian oil. > Ethics and human rights are thrown out the window - oil is considered far > more important. > > I tend to take the position of strategically 'not caring' (e.g. > https://youtu.be/Blz_Eu00Kbw ) > > Maybe someone like me is called a Libertarian? I am not sure... (for the > record, my political philosophy seems to be called Anarcho-Syndicalism ) > > But I still think a parallel community might be in order > > -Yasu > > > > On Feb 22, 2022, at 07:36, Paul Jewell wrote: > > > > > > > > > On 21 Feb 2022, at 19:10, raingloom > > > > > By the way, I think it's kind of silly that that is completely banned > > > from discussion. When I wanted help on getting my GPU to work, I > > > mentioned for reference purposes that I tried the proprietary driver > > > from The Forbidden Channel - and was subsequently warned that I must > > > not do that. > > > > I understand that the position taken by guix is more nuanced than that. The > > project doesn’t seek to control what you run on your computer, but won’t > > support your choice to run non-free software in the official channels. > > > > > Which I find ridiculous. You can't even discuss results > > > obtained by running closed source drivers and firmware, so how do you > > > debug the libre firmwares and drivers, when you have nothing to compare > > > against? > > But you can discuss these results elsewhere. > > > > > Also, I think people who want to overwhelmingly use free software but > > > need proprietary drivers for their computer to function should be > > > offered better help than "buy a new computer". > > > > I kind of agree with you here. I don’t want to obsolete perfectly viable > > hardware, but instead want to use it for its whole life. Next time I am in > > the market for new hardware, then I will have the ability to run > > libre-software as a pre-condition for purchase. > > > > > I think The Forbidden Channel should be raised to a status similar to > > > the AUR: it's recognized and its existence is documented, but all > > > responsibility is very explicitly disclaimed and support is relegated > > > to special channels. > > > > Users will find it even the way it is configured today. I don’t think it > > needs any sort of official recognition or promotion, as that will go > > against the project goals/rules (as I understand it). We should always be > > aware of the insidious nature of proprietary firmware/software, and work to > > eliminate the need for it, rather than indicating that its use is > > acceptable as a first choice. > > > > > > Best regards, > > Paul
Re: packaging a golang package
Hey I just want to throw out there that I have a very WIP go module importer[1] sitting on my channel. It uses the proxy.golang.org[2] api to fetch the module's dependencies and source. The single module importer works for the most part but I need to fix it so that the recursive importer doesn't fail when it tries to fetch a dependency in a project's go.mod file that isn't proxied. There are a few problems that should be looked at for my importer. 1.) it does not include metadata or licensing information, so after importing this way a prudent packager will have to go through and add this information for everything that was pulled down. 2.) I don't think I'm doing a good job of filtering out similar versions of packages, i tried to follow the examples in the cargo importer but I'm not quite sure what all is going on in there. 3.) It uses a call to `guix environment --ad-hoc go -- go mod edit -json` to parse module dependencies from the go.mod file, maybe this can be done in a more idiomatic way? I think its a good start if anyone would like to help get it over the hump. [1] https://git.sr.ht/~elais/orange/tree/master/item/guix/import/go.scm [2] https://proxy.golang.org On Thu, Jan 28, 2021, at 21:10, adfeno--- via Development of GNU Guix and the GNU System distribution. wrote: > Em 28/01/2021 13:03, Ludovic Courtès escreveu: > > IMO, ‘guix import’ does not “steer users towards obtaining any nonfree > > information” any more than wget does. It’s a tool for packagers that > > returns a package definition or template thereof, and it’s up to the > > packager to decide what to do with it. > > I do agree with you, sorry if for some reason it sounded otherwise. My > intention is not to censor the user on that matter. Let me make it clear what > I meant in the previous message: > > From the bug report I referenced, one can see that what I find strange is > that the cargo provided by Guix (installable through `guix package -i > rust:cargo') has cargo's default repository enabled. The bug report > referenced has some ideas to try to solve this (although I didn't make > extensive test to see if they are all possible and doable). > > > -- > * Ativista do software livre > * https://libreplanet.org/wiki/User:Adfeno > * Membro dos grupos avaliadores de > * Software (Free Software Directory) > * Distribuições de sistemas (FreedSoftware) > * Sites (Free JavaScript Action Team) > * Não sou advogado e não fomento os não livres > * Sempre veja o spam/lixo eletrônico do teu e-mail > * Ou coloque todos os recebidos na caixa de entrada > * Sempre assino e-mails com OpenPGP > * Chave pública: vide endereço anterior > * Qualquer outro pode ser fraude > * Se não tens OpenPGP, ignore o anexo "signature.asc" > * Ao enviar anexos > * Docs., planilhas e apresentações: use OpenDocument > * Outros tipos: vide endereço anterior > * Use protocolos de comunicação federadas > * Vide endereço anterior > * Mensagens secretas somente via > * XMPP com OMEMO > * E-mail criptografado e assinado com OpenPGP > > > > *Attachments:* > * signature.asc
Declaring channel dependencies in the operating-system configuration
Hi Guix! One thing that I've often found to be annoying was manually adding a channels.scm file to systems, and I've come up with a solution that I'd like to share. For those interested in having their channels.scm be added as part of the system generation process, just do the following. Create an object representing a scheme file using the `scheme-file` procedure (define %guix-channels (scheme-file "channels.scm" #~(cons* (channel (name 'example) (url "https://example.org/channel.git;)) %default-channels))) Then add the file-like object to your system services using the extra-special-file procedure. It symlinks a file from the store to /etc/guix/channels.scm and makes the channels declared there available to all of your systems users. (operating-system ... (services (cons* (extra-special-file "/etc/guix/channels.scm" %guix-channels) %base-services))) I think this is a pretty neat solution for those of us who need to use custom channels, but I was wondering if this is something that can be improved on and added to the top level operating-system declaration. Just like we can declare hosts for the operating system would it be a good idea to declare (channels #~(cons* (channel ...))) too? Would it make sense to add it as a configuration in guix-service-type?
