« TerminatorX: Linux nas discotecas para os DJs | Main | Install Fest no CEFET-RN »
segunda-feira, 6 de dezembro de 2004
Publicado o gerenciador de pacotes Smart
bruder (sergio@bruder.net) enviou este link do Smart e acrescentou: "O smart já mencionado aqui antes foi oficialmente ... (Ler na íntegra)Publicado por brain às 20:19
Comentários dos leitores
(Termos de Uso)
» Comentário de lilux- () em 07/12 00:49
quando eu estava com o slackware eu tinha na minha mão a simples e ótima slackpkg, não faz feio não. agora estou usando o fedora 3, que tem o up2date, que apesar de funcional, ainda precissa de várias melhorias, até para ficar no ótimo nível do synaptic. Vou baixar e testar este Smart.
» Comentário de Death Warlock () em 07/12 08:58
Por favor me corrijam se eu estiver errado (meu inglês me decepciona as vezes).
Se eu uso Conectiva, continuo amarrados aos mirros de pacotes para o Conectiva?
Não posso utilizar repositórios do Mandrake por exemplo?
» Comentário de liquidslave () em 07/12 09:04
Sim, vc continua amarrado aos repositórios conectiva. O smart é flexível e suporta quase todas as distros , mas essas misturas de pacotes entre distros diferentes não são possíveis... possíveis são, não são viáveis.
See Ya
» Comentário de Eu () em 07/12 10:01
Na prática, qual é a diferença entre o smart, ou os outros gerenciadores? Eu li o README, mas não entendi. Tudo bem, ele suporta diversos formatos, rpm, deb e tgz, mas os pacotes têm que ser para a distribuição específica.
Bom, todos os pacotes para Conectiva são RPM. Todos os pacotes para Debian são DEB, então esse suporte a múltiplos formatos não parece ser grande vantagem. Se ele não permite usar pacotes da distribuição X na distribuição Y, para que serve ele, então?
obs.: eu sou usuário do Debian, e gostaria de saber se existe alguma vantagem real em trocar o aptitude por esse smart.
» Comentário de mOOdy () em 07/12 10:16
Boa pergunta "EU"....
Também não vi as vantagens nesse ponto.
» Comentário de Death Warlock () em 07/12 10:29
Neste primeiro momento não vi nenhuma grande vantagem sobre o que já existe. Utilizar um mesmo programa em mais de uma distribuição (LCC) é uma vantagem tão grande assim?
Sendo humilde e sincero (acredito que é assim que se aprende alguma caisa), não entendi PN dos "Case Studies" do README.
Pelo menos comigo, o apt-get sempre atendeu as dependências sem erros semelhantes aos citados no README do Smart (deve ser por isso que eu não entendi).
» Comentário de carlinhos () em 07/12 10:34
Eu penso que apesar das distribuições específicas, um mesmo gerenciador de pacotes seja para rpm, deb ou tgz me parece grande vantagem, a não ser que queiramos um gerenciador para cada distribuição... Eu já uso o synaptic pros meus rpms e acho ótimo, mas vou baixar o smart e testar.
» Comentário de Jairo Duarte () em 07/12 10:37
no final do README, tem 4 casos de estudo
* Case 1 - APT
* Case 2 - APT & YUM
* Case 3 - APT & YUM
* Case 4 - APT
e neles mostram exemplos onde o smart resolveu as depedências de uma forma muito melhor que os outros. Tão boa quanto um ser humano "entendido" conseguiria fazer e isso sim é dificil de fazer.
Conseguir fazer downgrade, e update inteligênte do sistema, uso de midias diversas, suporte especial a midias removiveis e não forçar ao fix de depedências quebradas é algo fantastico, apesar de não acreditar que ele faça isso o tempo todo, já é um começo. Imagino como ele vai ficar em 2 anos e o synaptic passar a usar o smart ao inves do apt.
A noticia sobre o smart saiu em vários sites, vários no exterior, e em todos eu vi pessoas se perguntando o porque de usar um outro gerênciador, se o apt e yum já eram muito bons. Lendo este casos de uso, a vantagem do smart é evidente.
Outra idéia errada que vi com frequência foi a do smart permitir que se misturase pacotes de distribuições diferentes, até com flames ardentes. Mas se lermos com atenção, não é o caso.
O smart é um pirralho, acabou de sair da maternidade, e esta encarando os velhotes, ameaçando tirar eles do dominio, como sempre isso não acontece sem conflitos.
______________________________
Para os que usam o Mandrake Cooker, saiu ontem o rpm com patch e o smart no Cooker Contrib :)
» Comentário de Kid X () em 07/12 11:25
Sr Eu, pelo menos esse "smart" parece ser mais fácil de usar, além de mais "inteligente"!
Mas eu estou muito contente em haver softwares novos e evolutivos, não podemos de jeito nenhum ficar só naqueles programas "linha de comandos", os programas "primitivos" que falam que são "os melhores"! Enchem o saco!!!
» Comentário de Dona Nenê e Madame Gaspar () em 07/12 12:00
O benefício está na interface. Uma mesma interface para todas as distros.
Um pacote rpm do Conectiva nem sempre instala bem num SuSE ou vice-versa. Mas rpm é rpm. Tanto um usuário de Conectiva quanto um usuário de SuSE sabem manipulá-lo. Descontadas as idiossincrasias de cada distro, a curva de aprendizado é grandemente reduzida quando passeio entre Conectiva, SuSE, Red Hat ou Mandrake, no que tange à manipulação de pacotes. Quando vou para um Debian, tenho que reaprender outra interface, com talvez outros conceitos.
O Smart, pelo que entendi, abstrai o sistema de empacotamento de modo a dar independência ao administrador quando precisa lidar com pacotes. Se ele está num Conectiva, usa Smart. Se vai para um Debian, instala um Smart e manipula os pacotes, se pinta um Slack na frente, usa Smart e assim por diante.
Quando é que vale a pena usar o Smart? Quando você tem um ambiente multi-distro. Ou mesmo que não tenha, quando quer estar preparado para encarar qualquer sistema de empacotamento de qualquer distro.
A proposta é interessante.
» Comentário de anom () em 07/12 12:29
Se a resolução de dependencia for tão experta quanto os cases dão a entender vale a pena o esforço dos caras. Tem outra coisinha legal nele tambem. No apt, se há um pacote quebrado ele fica te enchendo o saco a cada vez que v. vai instalar/remover alguma coisa. Parece que o smart so se preocupa com os pacotes envolvidos numa determinada tarefa. Isso me parece bom.
» Comentário de Daniel Fonseca Alves () em 07/12 12:32
Parece bom.
Como sou fã do APT fico com inveja ;-).
Conheço muito bem os problemas do APT citados acima (principalmente quando usava o kurumin) mas na maioria dos casos este tipo de situação ocorre quando se usa repositórios não oficiais(com as oficiais nunca tive problema).
Creio que seja por isso que o APT não trata destas bem das situações do README.
Mas fica a pergunta, não será mais fácil aplicar correções ao apt do que usar o smart como gerenciador de pacotes do Debian ou outra distribuição?
Estendendo mais a pergunta, qual a vantagem de se usar um gerenciador de pacotes na sua distribuição para tratar de dependências não-oficiais ? Será que a distribuições se importam com isto ?
Para mim o smart fica bem como gerenciador da Conectiva pois trata bem a política de uso de pacotes que a Conectiva traçou, outras distribuições podem nem se importar com as situações de conflito que foram expostas no exemplo pois a causa do problema é a estrutura de dependências que a própria distribuição delineou e no qual este tipo de situação pode nunca ocorrer.
Agora para o usuário as vantagens são boas, principalmente a "não-dependência" de um reposítório oficial, talvez um passo para a tão sonhada unificação de pacotes para linux(ainda que isto dependa muito de padrão bem definido de empacotamento).
» Comentário de Daniel () em 07/12 12:35
Eu já tive vários problemas de dependências quebradas com o apt-get. Espero que esse smart consiga resolver esses problemas pra mim.
Acho que muita gente q usa o apt-get já deve ter tido que rodar apt-get -f install alguma vez para "tentar" resolver esses problemas de pacotes com dependências quebradas.
» Comentário de Daniel () em 07/12 12:37
Ah completando ....
Isso acontece bastante quando você usa repositórios não oficiais para sua distro.
» Comentário de Death Warlock () em 07/12 12:48
É realmente o tratamento das dependências pelo Smart é mais "inteligente".
Talvez no mundo atual não seja muito relevante essa inteligência, mas olhem para a Conectiva como membro do LCC, talvez no futuro seja possivel misturar os repositórios das distribuições deste consórcio, ai neste caso um gerenciador comum seria a melhor solução. E se isso acontecesse e este gerenciador for o da Conectiva, ponto para o Brasil.
» Comentário de Patola () em 07/12 13:59
Agora um contraponto que imagino ser possível: a proposta do Smart é muito interessante. E, realmente, o apt tem deficiências quanto à resolução de pacotes por ser "fresquinho" demais pra certas situações. Mas não é isso o que o torna tão robusto pra atualizações? Quer dizer, quanto mais birrento com as dependências o gerenciador de pacotes for, maior me parece a chance de manter o sistema consistente. De repente pode acontecer de o Smart tentar ser esperto demais na resolução de pacotes e acabar deixando o sistema quebrado. Ou não?
» Comentário de anom () em 07/12 14:11
Olha, pelo o que eu vi dos cases, eu diria que o smart so é menos birrento com relação a não encher o saco quanto a pacotes quebrados que não afetam sua tarefa atual. No mais, ele é birrento, com a diferença de que busca caminhos para resolver o problema não tomado por outros. Por exempplo, aquele historia de ele pegar uma versao intermediaria que resolve o problema ou quando faz um downgrade, eu diria que ele está fazendo o que o usuário faria na mão se ele não existisse. Resta saber se esta esperteza funciona mesmo. Quanto mais se usar, provavelmente alguns cases não muito favoráveis aparecerão, mas diria que o começo é promissor. Logico, tou me baseando pelos exemplos, o que não é la grandes coisas, visto que não sei até que ponto o smart foi testado em outras situações limites ou mesmo se ele fuinciona bem no dia-a-dia de instalações corriqueiras, mas que é bem vindo é.
» Comentário de Eu () em 07/12 14:13
"O benefício está na interface. Uma mesma interface para todas as distros."
Eu pensei que esse problema tivesse sido resolvido com o apt-rpm desenvolvido pela conectiva. Eu uso o apt-get (ou o aptitude, ou o synaptic) no Debian, no Fedora e no Ubuntu, sempre com a mesma interface, que, convenhamos, não é tão complicada assim.
A diferença é a metodologia. O apt-rpm é como um back-end, que adapta a interface existente (apt) ao tipo de empacotamento (rpm). Já o Smart, é como se fosse um front-end. Ele cria uma interface única, que usa os diversos tipos de empacotamento existentes.
Na prática, não faz diferença. Você termina com uma única ferramente, que consegue instalar os pacotes feitos para a sua distribuição, seja qual for o tipo de empacotamento utilizado. Isso o apt já faz, junto com o apt-rpm.
Os exemplos do README mostram que o Smart é útil quando você usa diversos repositórios com versões não correspondentes de bibliotecas. Por exemplo, você tem o repositório A, que tem o programa X que depende da biblioteca L-1.2.2, e você já tem a biblioteca L-1.2.3 instalada do repositório B. Nesse caso, o smart faz o downgrade da biblioteca L, da versão L-1.2.3 do repositório B, para a versão L-1.2.2 do repositório A.
Certo, mas e se você tiver um programa Y do repositório B que depende da biblioteca L na versão L-1.2.3. O que o smart vai fazer? Fazer o downgrade de L da mesma forma, e quebrar o programa Y? Aqui não existe solução mágica. O downgrade só funciona se você não tiver nenhum programa instalado que dependa da versão atual da biblioteca. Embora isso seja fácil de conseguir em testes "de laboratório", na prática se você tem a versão L-1.2.3 da biblioteca instalada é por que você tem algum programa que depende dessa versão.
Como o Smart se comporta nessa situação?
E para quem só usa os repositórios oficiais da distribuição, onde o versionamento das bibliotecas é coerente? O smart apresenta algum comportamente mais inteligente que as ferramentas tradicionais? (mais uma vez, como exemplo, vale a pena trocar o aptitude do Debian pelo smart?)
» Comentário de flipe () em 07/12 14:21
tirando os comentarios sobre o programa, excelente atitude da conectiva em lançar a pagina toda em ingles....
afinal, vamos prestigiar os estrangeiros e escurraçar o nosso povo brasileiro!!!
PARABÉNS CONECTIVA!!!!
CONTINUE MENOSPREZANDO O NOSSO IDIOMA!!
» Comentário de CWagner () em 07/12 14:35
Estou usando o CL10, vou baixar o smart e testá-lo para ver como se comporta.
Se ficar satisfeito, farei dele o meu gerenciador padrão. Se não, ficará de lado caso haj alguma necessidade.
Por que os usuários de outras distribuições não fazem o teste e repassam a sua impressão do programa aqui no site?
Concordo, em parte, com o filipe. Acho que deveria haver uma preocupação em lança o site, pelo menos, nas duas línguas, mas creio que foi resolvido ficar em inglês devido o maior alcance que teria. Mas não fico chateado com os caras por causa disso (sem flames, por favor :)
Abraços a todos.
Carlos Wagner - São Luís/MA.
» Comentário de Leandro () em 07/12 14:41
O fato de estar em inglês é para internacionalizar a página, e o programa. O inglês é a língua da informática.
Já vi programas com páginas e código em alemão, francês e italiano. Simplesmente passei adiante. Nem tentei ler. Já inglês eu consigo ler (e muita gente também consegue). Essa é a diferença. Vc quer atingir só brasileiros ou quer atingir o mundo todo?
Agora, bem que podiam ter uma versão toda em pt_BR da página e do programa(README,etc.). Vamos esperar um pouco mais. Logo deve estar disponível na nossa língua. Vamos dar tempo ao autor.
» Comentário de Death Warlock () em 07/12 15:10
flipe, quantos usuários de linux existem no Brasil e quantos no resto do mundo?
Dos programadores no mundo que estão tem conhecimento suficiente para contribuir com o projeto são brasileiros e quantos são extrangeiros?
Na boa, porque você já não faz uma tradução do README e do site e envia para a Conectiva?
Além de prestigiar o Brasil como você quer, seu nome vai para os créditos...
...prestígio para você também.
» Comentário de Patola () em 07/12 15:17
flipe, o tempo deles é limitado, melhor que eles empreguem na popularização do programa (em que o inglês é essencial) e deixem detalhes menores pra depois mesmo.
No entanto, você pode ajudar e ter acesso de escrita no Wiki deles. A página que explica como ter conta lá - http://moin.conectiva.com.br/ComoTerConta - está em português. Assim, você, se tiver habilidades de tradução, pode ajudar a colocar a página em nossa língua, editando-a diretamente pelo Wiki.
» Comentário de Eu () em 07/12 16:31
Outra dúvida é se o smart tem um dos recursos mais úteis do Aptitude: memorizar os pacotes que foram instalados automaticamente, para apagá-los quando não forem mais necessários.
Exemplo: eu instalo o pacote X, que depende dos pacotes L, M e N. Essas três dependências são instalados, e o Aptitude memoriza que elas foram instaladas automaticamente. Outro dia, eu apago o pacote X, e o Aptitude se encarrega de também apagar os pacotes L, M e N, caso nenhum outro pacote dependa deles.
Assim o Aptitude evita que pacotes inúteis sejam mantidos instalados, ocupando espaço desnecessário. Esse é um dos recursos mais interessantes do Aptitude. Se o Smart não tiver um igual, seria interessante adicionar.
» Comentário de anom () em 07/12 16:41
Concordo com o "Eu" com o caso colocado, mas seguindo o pensamento dele eu poderia acrescentar: e se houvesse um pacote do programa Y num repositorio C dependente da versao intermediaria L-1.2.2 utilizada no downgrade? O smart entao poderia fazer o downgrade de Y e tudo continuaria funcionando.
Observe que o programa Y do respositorio C nao necessariamente é um versao mais antiga que a anterior. Ele pode ter como requerimento de compilação a biblioteca L >= 1.2.2, de modo seria um versao com L-1.2.2.
Não estou querendo brincar de criar repositorios de modo a favorecer o smart, até por que nem sei se ele faria isto que eu porpus, embora imagino que faça. O que eu quero estabelecer, assim como o "Eu", é onde o smart faz diferença. O que eu diria é que o smart é bom quando o sujeito acrescenta muitos repositorios não-oficiais para a sua distribuição, pois se o sistema hipotetico do "Eu" contivesse algum repositorio contendo o programa Y compilado com a versao L-1.2.2 o problema estaria resolvido. Ora, isso não é verdade para outras ferramentas. Mesmo v. tendo todos os pacotes necessários para deixar seu sistema "sem quebra" estas outras não sabem resolver o problema.
No caso do Debian, este problema pode aparecer se o sujeito usa a stable, por exemplo, e começa a instalar varios pacotes backportados para esta versao de repositorios não-oficias e, algum tempo depois, resolve atualizar para a testing. Há uma certa chance de isso "babar".
Se o "Eu" so usa a unstable e seu enorme acervo auto-contido, diria que não vale a pena, afora por curiosidade. Por outro lado, se funcionar pelo menos igual ... :)
» Comentário de anom () em 07/12 16:44
Tratar pacote orfaos é uma boa mesmo. Como o codigo-fonte do apt tá por aí, não deve ser dificil pro pesoal do smart pegar pelo menos a ideia. :)
» Comentário de henrique paiva () em 07/12 17:09
Bom, tenho usado o mandrake ultimamente (2 anos), e nunca tive problemas com dependecias quebradas desde que comecei usar o URPMI.
Talvez fosse interessante um case com o urpmi no README.
» Comentário de Luís Vaz de Camões () em 07/12 18:10
Há uma tradução no endereço abaixo para quem quer conhecer melhor a ferramenta, lusofonamente falando.
http://www.pontobr.org/article.php?sid=828
» Comentário de Luís Vaz de Camões () em 07/12 19:04
> Isso o apt já faz, junto com o apt-rpm.
É mesmo. O smart é um passo à frente no conceito do apt-rpm da Conectiva. Foi justamente a experiência de mantê-lo que inspirou o Niemeyer a escrever o Smart. Veja na seção de créditos do README:
"APT-RPM e Debian: A experiência com pacotes e as idéias para um framework melhor foram desenvolvidas enquanto o autor do Smart trabalhou como mantenedor do APT-RPM."
O smart é um apt-rpm melhorado, resolvendo automaticamente alguns becos sem-saída deixados para trás pelos sistemas de empacotamento que engloba, e expandido, ao incluir Slackware.
» Comentário de Eu () em 07/12 19:23
"APT-RPM e Debian: A experiência com pacotes e as idéias para um framework melhor foram desenvolvidas enquanto o autor do Smart trabalhou como mantenedor do APT-RPM."
Eu sempre fico com um pé atrás quando eu vejo palavras como "framework".
» Comentário de Luís Vaz de Camões () em 07/12 19:39
> Eu sempre fico com um pé atrás quando eu vejo palavras como "framework".
OK.
"APT-RPM e Debian: A experiência com pacotes e as idéias para uma ESTRUTURA CONCEITUAL melhorada foram desenvolvidas enquanto o autor do Smart trabalhou como mantenedor do APT-RPM."
Se você não gostar de "estrutura conceitual", também temos a opção de cortar fora seu pé.
» Comentário de ? () em 07/12 20:03
Smart instalado num Debian/testing e invocado com smart --gui:
Traceback (most recent call last):
File "/usr/bin/smart", line 179, in ?
main(sys.argv[1:])
File "/usr/bin/smart", line 162, in main
iface.error(str(e))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 17-18: ordinal not in range(128)
Alguma idéia?
» Comentário de Luís Vaz de Camões () em 07/12 20:50
Verifique as dependências
Dependências
------------
Núcleo:
O núcleo do sistema Smart depende do Python 2.3 ou superior e um compilador C para construir as extensões.
Interface Gráfica:
A interface gráfica depende do pygtk 2.4 ou superior.
» Comentário de HAmc () em 08/12 09:54
O "Eu" fez uma pergunta que também gostaria da resposta. Sucintamente repito a pergunta dele: resolver depêndencias com downgrades não poderia causar outros problemas no sistema?
» Comentário de HAmc () em 08/12 09:54
O "Eu" fez uma pergunta que também gostaria da resposta. Sucintamente repito a pergunta dele: resolver dependências com downgrades não poderia causar outros problemas no sistema?
» Comentário de Gustavo Niemeyer () em 08/12 18:29
HAmc, "Eu", anom, uma única operação não é considerada de forma isolada pelo Smart. Se o downgrade não for afetar os demais pacotes do sistema, ele será sugerido. Se o downgrade for afetar outros pacotes, mas for a única forma de realizar o que o usuário solicitou, ele será sugerido juntamente com as demais mudanças necessárias para efetuá-lo. Resumindo, uma única operação não será considerada isoladamente.
--
Sobre o traceback obtido no Debian/testing, esse problema (assim como muitos outros) foi resolvido na versão 0.28 que foi liberada hoje. Se houverem outros problemas semelhantes, por favor, entre em contato comigo diretamente através do email publicado na página.
--
"Eu", anom, a idéia de tratar pacotes orfãos é bastante interessante de fato. Isso ainda não é suportado, mas é uma excelente idéia a ser implementada. Note que isso é algo específico do aptitude, e não é suportado pelo próprio APT.
--
CWagner, o Smart ainda não é suportado no CL10. Certamente é possível fazê-lo funcionar, mas isso não é uma prioridade no momento, já que ainda estamos estabilizando o software.
--
"Eu", quanto a adotar o Smart ou não, mesmo quando usando um repositório perfeito com atualizações "suaves", note que existem uma série de outras características no Smart que o tornam interessante, inclusive nessa situação. Óbvio que sempre existirão questões de preferência pessoal, e eu certamente não tenho em mente tentar obrigar ninguém a usar um software ou outro.
--
Patola, o fato principal não é ele não ser birrento. O fato é ele ter algoritmos que tem a capacidade de considerar uma gama de opções maior quando calculando qualquer tipo de transação. Nem o APT, nem o Smart, nem qualquer outro programa dessa natureza, irá "quebrar" as relações de pacotes no sistema inadvertidamente (a menos que tenha um bug, claro). A diferença é realmente na habilidade de encontrar boas soluções para as relações sempre que necessário. Usuários com muito tempo de "casa" das mais diversas distribuições (temos contato com desenvolvedores do Debian, como Michael Vogt e Matt Zimmerman; da RedHat, como Jeff Johnson; e outras) sabem que atualizações não triviais eventualmente ocorrem. Atualizações entre distribuições inteiras também estão na lista negra dos gerenciadores de pacotes em geral. :-)
--
Death Warlock, sim, é possível usar repositórios da Mandrake com o Conectiva Linux. Nós mesmos fizemos testes usando os repositórios URPMI do jpackage.org. Para isso, claro, é necessário que os pacotes não conflitem com pacotes nativos da distribuição que estejam instalados.
--
Daniel Fonseca, a possibilidade de aplicar correções no APT ao invés de desenvolver um novo produto foi mais do que considerada. Ela foi efetivamente realizada durante um longo tempo, através do projeto APT-RPM. Inclusive, nos últimos anos de desenvolvimento, muitas das mudanças realizadas no APT-RPM foram "portadas" de volta para o APT original. Infelizmente, determinados melhoramentos sempre foram deixados para depois devido ao modelo de representação das informações adotado pelo APT. Chegou um determinado ponto em que o custo de modificar o APT para implementar certas características era alto demais, e a opção de uma nova ferramenta não parecia mais tão absurda.
--
Ufa.. quanta coisa. :-)
Bom, obrigado por todas as sugestões e críticas, e também pelos testes com o produto. Se houverem outros comentários importantes, favor direciona-los ao meu email.
» Comentário de ? () em 09/12 08:43
"» Comentário de Luís Vaz de Camões (201.1.203.xxx) em 07/12 20:50
Verifique as dependências
Dependências
------------
Núcleo:
O núcleo do sistema Smart depende do Python 2.3 ou superior e um compilador C para construir as extensões.
Interface Gráfica:
A interface gráfica depende do pygtk 2.4 ou superior."
$ dpkg -l python python-gtk2{,-dev} gcc
Desejado=U=Desconhecido/Instalar/Remover/aPagar/H=Manter
| status=Não/Instalado/arquiv.-Config./U=Descomp./Falhou-config/H=semi-inst.
|/ Erro?=(nenhum)/H=Mantido/precisa-Reinst./X=os dois problemas (status,Erro: maiúsculas=ruim)
||/ Nome Versão Descrição
+++-===============-==============-============================================
||/ Nome Versão Descrição
+++-================-================-================================================
ii python 2.3.4-4 An interactive high-level object-oriented langua
ii python-gtk2 2.4.1-2 Python bindings for the GTK+ widget set
ii python-gtk2-dev 2.4.1-2 GTK+ bindings: devel files
ii gcc 3.3.4-2 The GNU C compiler
???
» Comentário de ? () em 09/12 08:47
"Sobre o traceback obtido no Debian/testing, esse problema (assim como muitos outros) foi resolvido na versão 0.28 que foi liberada hoje. Se houverem outros problemas semelhantes, por favor, entre em contato comigo diretamente através do email publicado na página.
"
valeu Gustavo!
» Comentário de ? () em 09/12 08:57
Agora não dá mais o erro (v0.28) mas também não roda :-( (sem qquer mensagem de erro)
O formulário de comentários está desativado devido à mudança de sistema de gerenciamento de conteúdo.