Problème installation LM17.3 32bits

La 32 bits c'est une VM. Au boulot je me traine encore que des portables 32 bits !

Ce PPA marche nickel ! Merci.

Classe

Est-ce que cela veut dire que je pourrais rester sur la prochaine LTS (16.04) jusqu'à la sortie de la prochaine (18.04 ?) pour toujours pouvoir éxécuter la dernière version de devel QET ?

Avant d'utiliser QET, je n'installais que des LTS sur ma machine. Mais depuis que je suis le devel de QET, je suis plus ou moins contraint d'installer les versions intermédiaires d'Ubuntu (à cause des versions de Qt).

Bravo Laurent, c'est une bonne nouvelle

Je passerai à la nouvelle PPA à la fin du printemps, début de l'été, soit quand j'aurai upgradé mon système vers la nouvelle LTS 16.04. En attendant, je reste sur l'ancien pinning.

Sinon, je trouve l'idée des paquets snaps vraiment super, aussi bien pour les développeurs que pour les utilisateurs. Fini les sources externes, les dépendances insolubles, les systèmes flingués...
Reste à voir si c'est techniquement bien réalisé et comment tous les dérivés d'Ubuntu ainsi que les distributions en rpm vont accepter la chose.
Les paquets snaps, c'est aussi peut-être, à terme, le début d'Ubuntu en rolling release.
La cerise sur le gateau étant des paquets snaps qui se déploiraient aussi bien sur GNU/Linux, MS Windows que Mac OS X... Mais là je m'égare...

Toutefois, cette innovation me pose une question de fond. A partir du moment où un debianeux fait :

$ apt-get install snapcraft

Est-ce qu'on peut alors dire que Debian est basé sur Ubuntu, qui est basé sur Debian, qui est basé sur Ubuntu...?

Ok Laurent, merci pour ton avis un peu plus averti que le mien sur l'empaquetage snap.
J'avais pas vu les choses sous cet angle - transformer Ubuntu en Windows - et effectivement, je suis déjà moins festif...
On peut donc considérer que les paquets snap seront mal accueillis par les distribs deb et rpm. Ce qui me pousse à penser que Canonical a besoin de cette technologie pour lancer son Phone (pour faire tourner plus d'app sur Ubuntu Phone ?) et pas pour le Desktop.

Après, c'est clair que fournir 800MB de libraries Qt pour faire tourner QET.. c'est pas pensable...

Donc je comprends mieux ton intérêts pour le dépôt Lauchpad.net. Merci du travail effectué !

J'ai lu le fil sur linuxfr.org. J'ai l'impression de mieux comprendre

En fait, la technologie snap est à double-tranchant. C'est bien et c'est pas bien...

Si j'ai bien compris, tant qu'un logiciel est libre (sources, empaquetage, distribution...) il vaut mieux rester sur du paquetage deb car le paquet est plus compact. Et surtout, apt-get garanti la cohérence et la sécurité du système et des librairies, justement en utilisant les dépendances.
C'est un des grands avantages à utiliser des distribs GNU/Linux en deb ou rpm et c'est pour ca qu'on les aime.

Toutefois, l'empaquetage snappy peut faciliter le travail des développeurs de logiciels propriétaires et je pense que c'est la véritable finalité de snapcraft. De cette manière, ils pourront faire comme sous Windows : fournir un binaire éxécutable avec toutes ses dépendances et donc fonctionnel "out of the box". Ainsi, le support et la maintenance de l'application sont clairement plus faciles qu'avec un système deb, ce qui ouvre la porte au business sur Linux.
Snappy va favoriser les applications propriétaires car les développeurs n'auront plus d'excuses du genre :
"on peut pas développer pour Linux car il y a trop de versions différentes. C'est un travail qui ne sera jamais rentable."
"la maintenance est impossible car les systèmes Linux sont trop hétérogènes"
"on peut pas vous proposer de support car votre problème vient de cette librairie que nous n'avons pas créée"
etc...

Revers de la médaille avec snappy : le système finira par devenir vulnérable et l'anti-virus sera obligatoire, et là, ca me plaît déjà beaucoup moins

Par contre, pour certaines applications "pro" ou "semi-pro", snappy offrira de gros avantages, notamment pour réaliser des pilotes (drivers) pour du matériel spécifique, ce qui, jusqu'à aujourd'hui, est LE GROS TALONT D'ACHILLE de GNU/Linux.

Perso, je suis bassiste amateur et j'essaie depuis 2008 de faire de la MAO sous Linux. Mission impossible
J'ai une carte son RME multicanaux (http://www.rme-audio.de/en/products/fireface_800.php) qui tourne sur une interface Firewire.
Tiens d'ailleurs le forum de la société RME m'en rappelle un autre :
 https://www.forum.rme-audio.de/
Bref, pas moyen d'en faire quelque chose sous Linux. Y'a bien le projet FFADO (http://www.ffado.org/) mais c'est pas encore au point... et vraisemblablement, ca ne le sera jamais...
Je fini donc toujours les nerfs à vif et puis vient la phase de déprime : installer Windows sur une machine dédiée à la MAO.
Donc pour ce genre de trucs, snappy, pourquoi pas ?...

plop Laurent, merci pour le lien !
Je sais déjà que certains arrivent à faire marcher cette carte son. Mais après, faut passer à la pratique et c'est là que la perte de cheveux s'accelère...
La dernière fois que j'avais essayé, c'était il y a 2 ans avec la distri KXStudio qui donnait des résultat pas mal mais tout n'était pas fonctionnel. Faudrait que je réessaie à l'occasion.
Bon allez, j'arrête là avec mon hors-sujet caractérisé

Pour les projets développés par une communauté, comme QElectroTech, je vois pas trop quels pourraient être les avantages de snap.

Je pense vraiment que la finalité de snap est le business. Les éditeurs de logiciels privatifs pourront alors limiter leur responsabilité au maintien du seul paquet snap, ce qui leur rendra la vie plus facile ! Comme sous Windows en fait.