Problema no node-gyp ao preparar ambiente Angular no Linux Mint - "gyp err stack error make failed with exit code 2"

Uma das desvantagens de trabalhar em home office são essas situações que surgem ao configurar ambientes que fazem a gente perder um bom tempo.

Principalmente se você trabalha com desenvolvimento de sistemas, feito eu. Enquanto eu estava usando o Linux Mint, as máquinas do trabalho todas são Ubuntu 18.

O PROBLEMA

Um problema bem chato que levou um bom tempo para descobrir a solução, similar a esse que foi relatado no stackoverflow.

Ao preparar a máquina para trabalhar com um sistema desenvolvido em Angular me deparei com um erro pois sempre o node-gyp era chamado para compilar alguns módulos tais como o node-sass.

Verifiquei que na máquina de todos os colegas não ocorria, somente na minha. Tanto no meu desktop antigo (Mint 19.3), quanto no notebook (Mint 19.1). Versão node 12.18.3 e npm 6.14.6. A máquina de todos eles era Ubuntu. Por que não mudei pra ele então? Porque não queria ter que preparar ooooutro ambiente!

Ao final do npm install dá esse erro:

gyp ERR! build error 

gyp ERR! stack Error: `make` failed with exit code: 2

(...)

gyp ERR! System Linux 4.15.0-20-generic

gyp ERR! command "/home/windson-serpro/.nvm/versions/node/v12.18.3/bin/node" "/home/windson-serpro/git/serpro/editais/editais-suiterfb-frontend/node_modules/node-gyp/bin/node-gyp.js" "rebuild" "--verbose" "--libsass_ext=" "--libsass_cflags=" "--libsass_ldflags=" "--libsass_library="

gyp ERR! cwd /home/windson-serpro/git/serpro/editais/editais-suiterfb-frontend/node_modules/node-sass

gyp ERR! node -v v12.18.3

gyp ERR! node-gyp -v v3.8.0

gyp ERR! not ok 

Build failed with error code: 1

De tudo que pesquisei, se falava que eu tinha que instalar o build-essential para a compilação via make rodar. Sugeriam várias outras bibliotecas mas vi que não resolvia também.

Segui outra referência que apontava que eu deveria remover o package-lock.json, a pasta node_modules (se você realmente trabalha com node já fez isso milhares de vezes...) mas além disso a pasta oculta .node-gyp e então instalar de novo o node-gyp. Também não resolveu...

A SOLUÇÃO

Analisei o problema mais a fundo com um colega. Vimos que tinha um passo que ocorria na minha máquina mas nunca na dele: essa compilação do node-gyp. 

O node-gyp serve para compilar módulos nativos, mas isso não deveria ser necessário nesse caso, e ele parecia tentar compilar o node-sass e com isso sempre dava erro no meu ambiente.

Portanto toda vez que eu rodasse o npm install e surgisse uma pasta oculta .node-gyp na minha home, era sinal de problema.

Fomos tentando outras versões do node até que eu fui bater na versão de sistema do Mint 19.1: a 8.10.0, bem antiga.

E então pela primeira vez o npm install rodou sem os erros do node-gyp. 

Ou seja, quando está tudo OK ele encontra o binário da biblioteca, no meu caso o node-sass, e não precisa chamar o node-gyp.

Ao rodar o npm start, depois ainda deu um erro de dependência pois não achava a dependência quill.

Então foi só dar um npm install quill e depois o npm start que a aplicação rodou normalmente

Também publicado no medium

Emulador do Android SDK no Ubuntu 16 - Resolvido

Recentemente passei por alguns problemas para fazer funcionar o emulador do Android SDK instalado juntamente com o Android Studio 2.3.3 em máquinas Ubuntu de onde trabalho.

Configuração das máquinas:

Intel® Core™ i7 CPU 870 @ 2.93GHz × 8

8GB de RAM

Ubuntu 16.04 64bit

A princípio, uma configuração suficiente pra rodar o Android Studio, mais precisamente o emulador que dava problema. Tanto na minha como nas máquinas de 2 colegas.

Depois de muitas pesquisas na documentação do Android Studio, stackoverflow e outros sites relacionados chegamos à solução do problema.

Problema:

Antes de chegar na questão, passamos por outras situações, tais como a solicitação de instalação do Intel HAXM (Hardware Accelerated Execution Manager) ou KVM (Kernel-based Virtual Machine), configuração de BIOS para habilitar a virtualização do processador, entre outros.

Após pesquisas vimos que era algo bem comum. Com vários relatos, inclusive de casos que funcionavam antes, mas não após o upgrade pra versão 2 do Android Studio.

Após a resolução das configurações iniciais citadas, chegamos num ponto em que o emulador é iniciado, mas dá crash, às vezes logo de início, às vezes no início do carregamento do sistema operacional.

Um das causas do problema parece estar relacionada à interface gráfica Unity, já que vimos soluções em que a mudança para o Mate resolveria, mas não era algo aplicável ao nosso caso.

Cheguei a pensar se o fato de usar um processador Intel de 1ª geração poderia ser complicador também, já que no meu notebook com processador de 5ª geração (i5-5200U) e 8GB de RAM o emulador rodou normalmente.

Solução:

Inicialmente, a CPU precisa suportar uma das seguintes tecnologias de virtualização:

• Intel Virtualization Technology (VT, VT-x, vmx) extensions
• AMD Virtualization (AMD-V, SVM) extensions (Linux only)

A chave de tudo é fazer funcionar o processo de aceleração

1) Aceleração de hardware

Ao usar aceleração de hardware seu emulador deve rodar mais rapidamente, mas o problema que temos é que exatamente por tentar usar isso que o erro ocorre. Muito provavelmente você está usando o driver SL Nouveau. Ele acaba tornando a renderização gráfica mais lenta ou ocasiona o crash.

Solução: atualizar/modificar o driver da placa de vídeo. No meu caso a placa era uma GeForce 8400. Bastou reverter para o driver do fabricante nvidia-340 que já estava até instalado, mas não em uso.

2) Se ainda assim não der certo... usar Aceleração via software

Aceleração via software é útil somente se o computador não dispõe de drivers gráficos compatíveis com o emulador. A imagem do Android deve ser criada definindo a opção Emulated Performance: Graphics como 'Software' para assim não usar a GPU do host. Mesmo com esse procedimento só funcionou a versão Lollipop do Android no nosso caso.

Além disso foram necessários mais alguns comandos:

• Instalação de bibliotecas:

sudo apt-get install lib64stdc++6:i386

sudo apt-get install mesa-utils

• Copiar pastas lib, lib64 e qemu da pasta emulator para tools dentro de $ANDROID_SDK.

• Renomeia pasta:

Na pasta '$ANDROID_SDK/emulator/lib64': 

mv libstdc++/ libstdc++.bak

• Linca pasta do emulador pra pegar as bibliotecas do sistema

Na pasta '$ANDROID_SDK/emulator/lib64': 

ln -s /usr/lib64/libstdc++.so.6 libstdc++

• Para rodar o emulador via linha de comando:

Na pasta '$ANDROID_SDK/tools$:

 ./emulator -list-avds

Na pasta '$ANDROID_SDK/tools$:

 ./emulator -use-system-libs -avd Nexus_5X_API_22

Em alguns casos não precisa do -use-system-libs. Em outros dá pra rodar direto do Android Studio.

Em qualquer dos casos, se prepare que muita memória vai ser consumida. Nem 8GB é o bastante quando uma aplicação está rodando e com navegadores e outros programas abertos.

Observação: você não pode rodar uma VM dentro de outra VM como VirtualBox ou VMWare. Você deve rodar o emulador diretamente do seu hardware.

Bug no Moto G após atualização para Android 6

Há algumas semanas atrás, minha prima me pediu ajuda com um problema que o seu celular Android estava apresentando. Ela tem um Moto G (não lembro se 2ª ou 3ª geração). Após a atualização para o Android 6 ocorria o seguinte:

-Não exibia mais as notificações dos aplicativos. Por exemplo, as mensagens de whatsapp chegavam, mas não aparecia a notificação na parte superior da tela.
-Impossibilidade de restaurar padrões de fábrica (algo que tentamos fazer quando não vimos solução para o problema acima). O botão ficava desabilitado. Aliás, ainda bem que ficava desabilitado, pois evitaria um contratempo maior tendo em vista que a solução é bem rápida.

Solução:

Algo bem simples, mas meio difícil de descobrir. Basta ir em Configurar -> Usuários. Entrar como o usuário Convidado, o que vai fazer imediatamente as notificações surgirem. Depois basta voltar para a sua conta de usuário principal que a exibição de notificações estará normalizada.
Ainda não sei ao certo quais modelos podem apresentar esse problema. No Moto G 2ª geração da minha esposa e no meu Moto X conseguir atualizar para o Android 6 sem problemas.

Internet Wi-Fi muito lenta no Moto X e/ou Android Lollipop - Resolvido

No mês de julho de 2015, tive um problema com a minha internet wi-fi, que será detalhado neste post. Tenho internet GVT 25Mb que me atende muito bem em todos os dispositivos, inclusive simultaneamente:

• CPU
• Notebook
• Tablet
• Celular Moto X [Lollipop] e Moto G[Kitkat] (meu e da minha esposa)
• PlayStation3
• 2 TVs Smart (Samsung e LG)

Em resumo, simples navegações, downloads, YouTube, Netflix, games online, enfim tudo funciona perfeitamente bem de forma que poucas vezes tive algum problema.

O Problema

Há pouco mais de uma semana, passei por um dos problemas mais estranhos que já vi na rede local da minha residência.
Ao conectar o meu Moto X de 2ª geração à rede Wi-Fi, percebi que em alguns momentos a internet ficava muito lenta. Cheguei a fazer testes em que alguma páginas chegavam a demorar cerca de 60 a 90 segundos para ser carregadas, exatamente como mostrado no vídeo abaixo:

http://www.stevenf.com/downloads/iphone-6-moto-x.mp4

Ao receber uma visita de parentes, pude perceber que todos os celulares do pessoal, tais como Samsung Galaxy e Iphones não apresentavam este problema. Juntando todas as peças cheguei a seguinte conclusão: o problema não podia ser atribuído somente a minha rede, já que todos os dispositivos citados até agora não apresentavam lentidão, exceto os nossos celulares Motorola; mas também deveria haver alguma mudança recente ocorrida na rede ou na configuração do meu roteador, visto que meu Moto X não apresenta este problema ao conectar em outras redes Wi-Fi.

A Solução

Depois de muitas pesquisas e muitos testes e mudanças de configuração no celular e no roteador, este artigo resolveu os meus problemas:

http://forums.androidcentral.com/lg-g4/542447-slow-wifi-fixed.html
Que nos remete a este outro link
http://phandroid.com/2015/05/13/comcast-wireless-gateway-lollipop-bug/

Em resumo, o problema parece ocorrer não só nos celulares da Motorola mas também em outros modelos com a versão Lollipop do Android (e pelo que vi depois, versões anteriores também). A causa do problema é que o celular tenta solicitar um endereço IPV6 do roteador e nesse momento ele não consegue conversar com ele por algum motivo. Logo, ou você desabilita o ipv6 no seu roteador (opção que não tenho, pois não desbloqueei meu roteador) ou desabilita o ipv6 no Android, o que me pareceu mais simples e rápido do que mexer em toda uma infraestrutura já funcional.

Atualizado dia 07/08/2016:
O problema não ocorre somente em celulares Motorola. Foi reportado que até o momento o bug já ocorreu em outras modelos de outros fabricantes também: Positivo S480, Zen Fone, XPeria Z2, Galaxy J5, Galaxy S7.

A solução dada pelos links acima foi instalar o DNSET, que cria uma VPN que vai forçar o celular Android a conectar usando IPV4. Não necessita nem rootar o seu aparelho. Na descrição do aplicativo, ele afirma que configura o seu aparelho pra usar os servidores DNS do Google (8.8.8.8, 8.8.4.4) e o app desliga após a VPN ser estabelecida. Eu cheguei a tentar configurar manualmente meu DNS pros do Google, mas o problema de lentidão persistiu, sendo resolvido somente com o DNSET mesmo.

Algumas pessoas não confiam muito nesse aplicativo pelo tráfego ter que passar por uma VPN, apesar de segundo o desenvolvedor, e até onde pude analisar com o traceroute, o tunelamento é feito localmente. Na verdade, não deu pra entender por completo o funcionamento, mas caso não queria usar o aplicativo existe uma outra forma de se resolver o problema seria editando um arquivo de configuração para desabilitar o IPV6, conforme explicado neste link:
http://www.reddit.com/r/Android/comments/2z1gyo/fix_lollipop_wifi_issues_and_coincidentally_the/

Concluindo, comecei a utilizar o DNSET em casa e não tive mais problema de lentidão. Em outras redes Wi-Fi que não tenham esse problema (a grande maioria) basta desabilitar o mesmo. Em 27/09/2015, percebi que Acredito que a GVT modificou alguma configuração na sua rede, pois já faz mais de 1 semana que o problema não mais ocorre.

Estas são outras soluções mais completas, conforme dicas recentemente dada nos comentários [Atualizado dia 29/08/2016]: 
1) O aplicativo Disable IPV6, mas seu aparelho precisa de root
2) Se tiver um roteador Wi-Fi antigo, conecte esse roteador na saída do roteador principal. Crie uma segunda rede Wi-Fi (sem IPV6) com outro nome e conecte nesta os dispositivos Android que possuem a falha. A rede principal ficaria para os outros dispositivos. Esse roteador secundário fica em modo roteador e não em modo access point.

Análise técnica do problema [Atualizado dia 24/08/2016]:
Após alguns ótimos comentários do André Lange, resolvi atualizar o post com uma análise mais detalhada do problema feita por ele, além das novas soluções já listadas acima. Pra quem quiser uma análise ainda mais apurada, sugiro que confiram os comentários dele nesse post. O fato é que o Android tem um bug no IPV6, mas especificamente no seu protocolo da camada de enlace NDP. É incrível como até hoje esse bug do Android ainda não foi corrigido, o que tem prejudicado bastante a migração para IPV6.
"No momento em que você conecta o smartphone em uma rede WiFi com IPv6, a navegação em IPv6 funciona normalmente durante alguns minutos. Passados esses minutos, o celular para de responder ao protocolo NDP, mesmo o roteador enviando inúmeras requisições de Neighbor Solicitation para o endereço IPv6 do celular. Isso faz com que o roteador WiFi pense que o celular não está mais presente na rede e assim os pacotes que chegam para o endereço IPv6 dele não tem para onde ir (o roteador não sabe qual o MAC associado àquele endereço IPv6 ou essa informaçao já expirou) e são descartados. Os pacotes IPv6 gerados pelo celular continuam indo para a internet. São as respostas que não retornam ao celular pq ele deixa de responder o protocolo NDP, que é fundamental." Uma das soluções apontadas pelo André (veja nos comentários) é setar o MAC do smartphone manualmente através de um script.
E qual a real importância da adoção do IPV6? "O acesso IPv4 com NAT (tradução de endereços no roteador para permitir compartilhamento de um endereço IP entre várias máquinas) já criou inúmeros problemas e dificuldades para os usuários. Por exemplo, a necessidade de configurar port forwarding nos roteadores para jogar online, baixar torrent, fazer acesso remoto ou simplesmente pra obter a qualidade total nas chamadas de audio/vido em apps como o Skype. Acontece que com a exaustão dos endereços v4 públicos (a internet cresceu e os números acabaram) isso já está piorando, pois os provedores não tem alternativa senão implantar mais uma camada NAT no próprio provedor (CG-NAT) e amontoar diversos clientes atrás de um único endereço IP. Como nós usuários (mesmo os mais avançados) não temos acesso administrativo a esse NAT do provedor, não temos mais como fazer port forwarding e os programas que faziam automaticamente isso por nós (via UPnP) também não conseguem mais fazer. A qualidade do acesso em v4 vai piorar cada vez mais com esse CG-NAT, ficando muitos usuários bloqueados em algum site porque o endereço IP que eles compartilham no provedor teria sido alguma vez utilizado de forma maliciosa/fraudulenta no acesso à esse site. A única solução de longo prazo para tudo isso é a implantação do IPv6, que por ter uma quantidade muito maior de endereços disponível elimina a necessidade de compartilhamento de endereços (NAT)."