Nas primeiras semanas da disciplina de Software Livre, fomos introduzidos aos fundamentos essenciais deste campo tão importante e dinâmico da computação.
O professor e os palestrantes compartilharam uma riqueza de conhecimento sobre os princípios e práticas do software livre. Foi uma experiência fascinante mergulhar nos conceitos fundamentais que norteiam esse universo.
Entre os diversos tópicos abordados, destacam-se o envio de patches e as licenças, que são pilares fundamentais no contexto do software livre. Aprendemos de forma detalhada como funciona o processo de envio de patches, uma prática essencial para contribuir com projetos de código aberto. Além disso, exploramos as diferentes licenças que regem o uso e distribuição do software livre, entendendo sua importância e impacto na comunidade.
Esses conceitos nos proporcionaram uma base sólida para compreender e participar ativamente no mundo do software livre, e mal podemos esperar para continuar explorando e contribuindo com esse ecossistema vibrante e colaborativo.
No segundo artigo deste blog, vou compartilhar minha experiência sobre a mudança de setup e todo o processo de reinicialização e instalação de diversas dependências para alcançar o objetivo final de compilar o kernel do Linux.
Esse desafio foi repleto de obstáculos, e enfrentei diversos problemas ao longo do caminho. No entanto, com perseverança e a ajuda do meu professor e dos demais monitores da disciplina de Software Livre, consegui superar todas as dificuldades.
Para alcançar meu objetivo, segui passo a passo as instruções e tutoriais disponíveis nos seguintes links:
Esses materiais foram essenciais para entender todo o processo e superar os desafios encontrados ao longo do caminho.
Após a instalação de todas as dependências e a configuração do ambiente, iniciei o processo de compilação do kernel do Linux. No entanto, me deparei com diversos erros inesperados que dificultaram o avanço do processo.
Um deles foi relacionado aos comandos de mount e unmount. Basicamente era criado um binário que não era executável, e isso gerava um erro no processo de compilação.
Mas não obstante, O arquivo também não poderia ser deletado, alterado, ou movido.
O primeiro Pach (que não foi propriamente enviado) foi feito em conjunto com o Fernando Yang, e foi um desafio interessante para começar a entender o processo de envio de patches.
Basicamente o patch foi feito para resolver um erro BEM simples, Basicamente relacionado a um erro de digitação.
Um espaço em branco a mais no código, que foi corrigido.
No terceiro artigo deste blog, Fernando Yang e eu fizemos um envio de patch para o seguinte código:
[PATCH] Replaced code
Co-developed-by: Eduardo Figueredo <eduardofp@usp.br>
Signed-off-by: Eduardo Figueredo <eduardofp@usp.br>
Signed-off-by: Fernando Yang <hagisf@usp.br>
---
drivers/iio/adc/ad7266.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/adc/ad7266.c b/drivers/iio/adc/ad7266.c
index 468c2656d..8b03d4469 100644
--- a/drivers/iio/adc/ad7266.c
+++ b/drivers/iio/adc/ad7266.c
@@ -151,18 +151,16 @@ static int ad7266_read_raw(struct iio_dev *indio_dev,
switch (m) {
case IIO_CHAN_INFO_RAW:
ret = iio_device_claim_direct_mode(indio_dev);
if (ret)
return ret;
ret = ad7266_read_single(st, val, chan->address);
iio_device_release_direct_mode(indio_dev);
*val = (*val >> 2) & 0xfff;
if (chan->scan_type.sign == 's')
*val = sign_extend32(*val,
chan->scan_type.realbits - 1);
return IIO_VAL_INT;
unreachable();
case IIO_CHAN_INFO_SCALE:
scale_mv = st->vref_mv;
if (st->mode == AD7266_MODE_DIFF)
No quarto artigo deste blog, Fernando Yang e eu fizemos um envio de patch para o Kw, e nele foi feita a alteração de um código que estava sem erros, mas com o objetivo de otimização, foi feita uma alteração.
- distro=$(cat /etc/*-release | grep -w 'ID\(_LIKE\)\?' | cut -d = -f 2 | xargs echo)
+ distro=$(grep < /etc/*-release --word-regexp 'ID\(_LIKE\)\?' | cut --delimiter = --fields 2 | xargs printf)
Basicamente foi seguido o tutorial 1 utilizando o podman, que é uma ferramenta que fornece uma maneira de gerenciar contêineres e imagens de contêineres.
O tutorial foi seguido passo a passo e tudo deu certo...
Até o final que no comando: pbuilder create
O erro era grande e não foi possível resolver das N tentativas e conversando com moniotres e professor.
O jeito de resolver foi criando um dockerfile e fazendo o build da imagem.
Mas ainda assim, outro erro persistiu, tornando bem dificil realizar essa parte.
Contudo, com ajuda de alunos e monitores, foi possível resolver o problema ao recomeçar do zero o tutorial.
Exploradas novas opções de projetos de software livre com diferentes tipos de codigos de open source (talvez ainda seja uma opção), mas também olhado no Kworkflow que tem centenas de issues e uma das que eu apresentei a minha dupla foi:
Make checkpatch and get_maintainers options rely in a configuration file.
Contudo não tenho certeza da complexidade e decidi conversar com minha dupla sobre essa issue e ver se é uma boa opção.
Talvez também seja uma boa opção olhar outros tipos de codigo open source e considerar ideias diferentes.
Além disso também foram analizadas outras issues em outros projetos, como: Gnome
Para isso, foi feito um fork do projeto e analisado as issues e os projetos que estão sendo feitos.
A ideia principal é de executar os codigos, e verificar as issues presentes no projeto, com a finalidade de escolher uma para ser feita.
O gnome tem um builder, que é um app - linux que promete facilitar o download de pacotes e a instalação de programas GNOME.
Baixando os projetos de clima, de tradução e de visualizador de fontes, foi possível analisar as issues e ver o que está sendo feito.
A melhor que eu encontrei foi uma issua que parecia relativamente fácil de ser feita, e que era relacionada ao app de WeatherGNOME.
Issue Feels like -0º
Contudo, por ser um codigo em javascript, e por não ter muita experiência com a linguagem, decidi não fazer essa issue.
No fim das contas houve uma mudança de planos grande relacionada a escolha do projeto
Decidi fazer o projeto relacionado ao KW - Kworkflow, e a issue escolhida foi:
Padronização da função
A issue foi escolhida por ser uma issue que não é muito complexa, mas que requer um pouco de conhecimento sobre o código e sobre o que está sendo feito.
A ideia principal é de mudar a ordem dos argumentos da função cmd_remotely, que é uma função que é chamada em diversos lugares do código (cerca de 50 vezes em diferentes ocasiões).
A ideia é de mudar a ordem dos argumentos para que a função fique mais legível e mais fácil de entender.
Além disso padronizada em relação a função cmd_manager, que é outra função que está presente junto à anterior em grande parte do codigo
Na imagem acima é possivel visualizar o que foi feito, e a ordem dos argumentos foi mudada para que fique mais legível e mais fácil de entender.
O codigo acabou dando certo e funcionando, passando por todos os testes sem muitos problemas.
A issue foi fechada e o pull request foi aceito.
As alterações realizadas foram diversas, mas principalmente a mudança da ordem dos argumentos e a padronização do código.
Cerca de 60 linhas de código foram alteradas, e o código foi testado e funcionou sem problemas.
A issue foi fechada e o pull request foi aceito.
