'apt-get update' fica preso por horas em “100% [Working]” para PPA específico

Question

Quando executo sudo apt-get update no Ubuntu 15.04, recebo a seguinte saída (abreviada):

$ LANG=C sudo apt-get update
[sudo] password for ipc-admin: 
Ign http://ftp.uni-stuttgart.de vivid InRelease
Ign http://ftp.uni-stuttgart.de vivid-updates InRelease
.
.
.
Hit http://ftp.uni-stuttgart.de vivid-proposed/universe Translation-en
Hit http://ftp.uni-stuttgart.de vivid-proposed/universe Translation-de
100% [Working]

Em seguida, ele fica preso e não continuará até que eu o interrompa com Ctrl + C .

Quando eu faço sudo aptitude update , ele também fica na mesma posição.

Após excluir o cache com sudo rm -rf /var/lib/apt/lists e executar sudo apt-get update novamente, ainda recebo os mesmos resultados.

No entanto, parece ter atualizado com êxito os arquivos de índice de pacotes depois de executar sudo apt-get update e interrompê-los quando fica preso, pois ainda posso executar apt-get upgrade e receber novas atualizações ou apt-get install . Apenas não termina a tarefa apt-get update ...

Uma reinstalação de apt com sudo aptitude reinstall apt e uma reinicialização posterior também não alterou minha situação.

Qual pode ser o problema aqui e como posso corrigi-lo?

PS: A saída total de apt-get update registrada com script que também mostra essas linhas dinâmicas pode ser encontrada em pastebin .

UPDATE

Depois de deixá-lo funcionar por horas, ele realmente termina! Os repositórios que causam o problema são vários https://repo.tox.im linhas. Aqui, o que aparece depois de muitas horas de espera entre cada linha:

Ign https://repo.tox.im nightly InRelease
Ign https://repo.tox.im nightly Release.gpg
Ign https://repo.tox.im nightly Release
Err https://repo.tox.im nightly/main i386 Packages
  Connection timed out after 120000 milliseconds
Ign https://repo.tox.im nightly/main Translation-en
Ign https://repo.tox.im nightly/main Translation-de
Fetched 69,8 kB in 36min 0s (32 B/s)
W: Failed to fetch https://repo.tox.im/dists/nightly/main/binary-i386/Packages  Connection timed out after 120000 milliseconds

E: Some index files failed to download. They have been ignored, or old ones used instead.

Depois disso, o processo termina corretamente sem ter que interrompê-lo. Então, qual pode ser o problema com esse repositório e como posso corrigi-lo?

    

Answer 1

Depois de esperar que o comando seja concluído por horas, vi que ele fica pendurado em todos os repositórios tóxicos.

Eu verifiquei sua página principal e descobri que toda a infraestrutura, incluindo repositórios, wiki e site principal, mudou para um domínio diferente. É por isso que o URL antigo não está mais ativo e por que apt-get update está expirando.

Em seu novo wiki , eles deram o seguinte script (ligeiramente modificado) para instalar o repositório atualizado:

#!/bin/bash
sudo apt-key del 0C2E03A0
sudo sh -c 'echo "deb https://pkg.tox.chat/debian nightly main" > /etc/apt/sources.list.d/tox.list'
wget -qO - https://pkg.tox.chat/debian/pub.gpg.key | sudo apt-key add -
sudo apt-get install apt-transport-https
sudo apt-get update
echo "Tox Repository Installed. You can now install qtox"

Eu executei essas linhas e agora todos os problemas com apt-get update acabaram!

Infelizmente, o novo repositório contém apenas 64bits de qTox, então eu terei que conviver com esse pacote por um tempo, até que eles também compilem para máquinas de 32bits!

ATENÇÃO: Se você tem 32bit qTox instalado, não instale o novo repositório! Ele contém um pacoteqtox de 32bit% com um número de versão superior ao último disponível, portanto apt-get upgrade irá instalá-lo e substituir sua instalação atual do qTox por essa, assim que você executar as atualizações. Mas não é um pacote de 32 bits, apenas parece um! Dentro dele contém executáveis de 64 bits!

Para mais informações e um script para verificar a verdadeira arquitetura do pacote sem precisar instalá-lo, consulte minhas perguntas e respostas aqui !

A última atualização do repositório corrigiu isso e o qTox está agora disponível para as duas arquiteturas novamente! :)

    

Answer 2

Eu reconheci esse problema de tempos em tempos e de uma máquina para outra. Eu me livrei dele simplesmente mudando o servidor espelho principal - chamado na versão alemã que você está usando "Haupt-Server"

Desdequemudeide"German Servers" para "Main Server", tudo está bem ...

    

Answer 3

Antes de mais nada, verifique se você escolheu fontes adequadas em

/etc/apt/sources.list

Em seguida, você pode tentar o que funciona para mim:

cd /etc/apt

Neste dicionário, pode haver uma pasta chamada

sources.list.d

e contém alguns arquivos de configuração que você não precisa.

Eu editei esse arquivo de configuração adicionando # na frente de cada linha, e faz sentido.