Topic: Problème installation LM17.3 32bits

Bonjour,
je viens de réaliser 2 installations neuve de LM17.3: une en version 64bits et une en version 32 bits.
Pas de soucis avec la version 64 bits pour l'installation de Qt5.3 et qelectrotech.


sudo apt-add-repository 'deb http://ppa.launchpad.net/packetlost/qt-opensource/ubuntu trusty main'

Ajout de la clé du dépôt :

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 5858D2CE

Ajout du Depot QET
sudo apt-add-repository 'deb http://debian.qelectrotech.org/qet/debian/ stable main'

Clé du dépôt apt QET

$ gpg --keyserver pgpkeys.mit.edu --recv-key 1D4FB6C1
$ gpg -a --export 1D4FB6C1 | sudo apt-key add -

Ou

wget -q -O - https://download.qelectrotech.org/qet/debian/Qelectrotech_Repository.asc | sudo apt-key add -

Avec la version 32 bits, je n'arrive pas à installer qelectrotech : libqt5svg5 n'est pas installé et ne peut être installé car qtbase-abi-5-2-1 manque et n'est pas dans les dépots.

Dans la version 64 bits aucun soucis, libqt5svg5 est de base installé malgré que qtbase-abi ne soit pas installé.

Comment m'en sortir ?
Merci.
Cordialement.
Alexis

Re: Problème installation LM17.3 32bits

Essayes avec ce PPA:

deb http://ppa.launchpad.net/packetlost/qt-opensource-trusty/ubuntu trusty main 

https://launchpad.net/~packetlost/+archive/ubuntu/qt-opensource-trusty

l'autre en https://launchpad.net/~packetlost/+archive/ubuntu/qt-opensource semble mélanger les versions de Qt...

Pourquoi installer à neuf une distrib en 32 bits en 2016, processeur 32 bits?

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Problème installation LM17.3 32bits

scorpio810 wrote:

Pourquoi installer à neuf une distrib en 32 bits en 2016, processeur 32 bits?

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

Ce PPA marche nickel ! Merci.

Re: Problème installation LM17.3 32bits

Bonjour,

il a été mis en place un PPA sur launchpad.net, vous y trouverez les derniers builds devel de la version 0.51 pour Trusty, Wily, et aussi Xenial la prochaine LTS.
Inutile donc de s’embêter avec des librairies venues d'ailleurs, ces paquets sont compilés par les serveurs Ubuntu avec les bonnes librairies de chaque distribution en 32 et 64 bits.

https://launchpad.net/~scorpio/+archive/ubuntu/ppa


Exemple pour ajouter le PPA sur une Ubuntu Trusty :


sudo apt-add-repository 'deb http://ppa.launchpad.net/scorpio/ppa/ubuntu trusty main'
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 20D47986

Enjoy ! nomicons/smile

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Problème installation LM17.3 32bits

Classe nomicons/cool

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).

Re: Problème installation LM17.3 32bits

Oui, tu pourras rester sur les versions LTS, sauf si t'as un écran HDPI.. à moins de faire des paquets Snaps nomicons/blink

D'ici une dizaine de jours Qt 5.6.1 devrait être releaser, les dev Debian Qt-kde attendent ce moment d’après ce que j'ai pu lire sur leur ML pour recompiler la dernière version de kde5/plasma avec et envoyer le tout dans Unstable.

De l'autre coté, la prochaine LTS va arriver avec Qt 5.5.1, ce qui encore une fois t'obligerais à te servir sur le dépôt Debian Qet dans la branche stable avec des paquets compilés avec les vieilles libs Qt 5.3, car ceux du dépôt unstable seront compilés bientôt avec Qt 5.6.1...

Voila pourquoi j'ai mis en place ce second dépôt de paquets Ubuntu, reste encore du travail pour automatiser ça.
Et de l'autre, regarder comment je peut mettre en place un nightly auto builder sur un clone de la branche trunk du Subversion pour empaqueter automatiquement et journalièrement des Nightly builds pour deux ou trois versions Ubuntu en même temps.

Il va de soit que le dépôt de paquets Debian actuel reste en place et conseillé pour ceux sous Debian stable et Sid.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Problème installation LM17.3 32bits

Bravo Laurent, c'est une bonne nouvelle nomicons/wink

Développeur QElectroTech

Re: Problème installation LM17.3 32bits

Merci, Joshua. nomicons/wink

J'attends des retours de votre pars pour ce nouveau dépôt PPA, merci d'avance.
L'ancien pinning devrait être toujours valable.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

9 (edited by Nuri 2016-04-19 11:05:10)

Re: Problème installation LM17.3 32bits

scorpio810 wrote:

J'attends des retours de votre pars pour ce nouveau dépôt PPA, merci d'avance.

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.

scorpio810 wrote:

Oui, tu pourras rester sur les versions LTS, sauf si t'as un écran HDPI.. à moins de faire des paquets Snaps !

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...nomicons/laughing
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...nomicons/rolleyes

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...?

10 (edited by scorpio810 2016-04-19 14:40:28)

Re: Problème installation LM17.3 32bits

Au départ j'avais plutôt ajouté ce smiley ->  :'(  et nomicons/sick  après le lien Snaps, comme j'ai pas essayé je me suis ravisé !
Mais j'en pense pas moins, et crois moi je suis loin d’être le seul.
Mon avis pour l'instant, est tout le contraire de toi, je vois venir un OS en état de pagaille chez certains utilisateurs, rempli de failles et troués jusqu’à la moelle sans parler du remplissage des FS à la Windows si on généralise ce système de paquet à la place de nos chers dépôts surveillés, sécurisés et à jour de nos distributions (.deb, .RPM).

Prend juste en exemple le paquet Qet que je fourni pour Windows, et regarde sa taille : 95% du paquet c'est juste les librairies pour le faire fonctionner ... 

Autre exemple : si je ne met pas régulièrement à jour les librairies fournies avec, et qu'elles contiennent des failles déjà connues et exploitées?

On en revient au même problème que les utilisateurs Windows, qui ... passe en revue tous les softs installés sur la machine et va voir chez chaque éditeurs et non pas sur les sites de download/crapware, si une version plus récente existe et comble pas des failles de sécurités !?

Sur nos distributions, qui entre autres sont très bien conçues, tu installes qu'une seule brique de ta librairie et elle sert a tous les logiciels installés qui en dépendent, sur Windows chaque logiciel amène avec lui toutes les librairies dont il a besoin.

Prenons l'exemple de Qet, je peut pas demander à nos utilisateurs d'installer les 800 Mio de libs du framework Qt pour faire tourner le soft !


nuri wrote:

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...?

Tout comme la poule et l’œuf, qui est arrivé en premier, hein. nomicons/tongue

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Problème installation LM17.3 32bits

Ok Laurent, merci pour ton avis un peu plus averti que le mien sur l'empaquetage snap. nomicons/shocked
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... nomicons/dizzy

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

Re: Problème installation LM17.3 32bits

Pour un ou deux paquets importants pour l'utilisateur ça peut avoir son intérêt, mais ça existe déjà pour certains softs ou les libs sont fournies avec le programme en statiques.
De la à vouloir remplacer nos dépôts et paquets deb et rpm par snap sur du desktop, c'est reproduire ce qui se fait déjà sur Windows, là ça serais un désastre, AMHA.


Edit : ajouts de liens pour t’éclairer. 

Avis simple de korben :

http://korben.info/ubuntu-snap-snappy-paquet.html

Des avis plus éclairés :

https://linuxfr.org/users/bassiste/jour … ans-ubuntu

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

13 (edited by Nuri 2016-04-20 13:13:57)

Re: Problème installation LM17.3 32bits

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

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 nomicons/pinch

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 nomicons/angry
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 nomicons/whistling :
 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 ?...

Re: Problème installation LM17.3 32bits

Hs: regarde ici : http://linuxmao.org/forumthread53318

Complément d'information pour Snaps :
https://docs.google.com/presentation/d/16TkgRXp3BgtFO9GSvpb497oC1RpwwBvBYWMJF1vMKvg/edit?usp=docslist_api
https://blog.karolak.fr/2016/04/13/snap-de-ubuntu-bonne-ou-mauvaise-nouvelle/

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Problème installation LM17.3 32bits

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é nomicons/blush

Re: Problème installation LM17.3 32bits

http://linuxfr.org/users/vejmarie/journ … sur-xenial


Au bout d'un mois d'essai ça marche complétement.

Vous vous en passerez nomicons/grin !

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."

Re: Problème installation LM17.3 32bits

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.

Re: Problème installation LM17.3 32bits

Le seul avantage de snap pour QET se trouvera être dans le futur et sur les prochaines LTS Ubuntu seulement.
Les autres se penchant d'avantage pour http://flatpak.org/faq.html  http://flatpak.org/index.html#about
D'ici là, on trouvera plus de documentations, j'ai clairement pas le temps n'y l'envie de perdre une semaine ou plus de mon temps libre pour faire fonctionner ce nouveau paquet snap !

Pour l'instant comme tu le sais je fais aussi des paquets backports Debian Jessie, Ubuntu LTS 14.04 trusty, il s’avère parfois que des méthodes dernièrement ajoutées dans le code provoque un FTBFS sur Jessie ou trusty, et compile très bien sur les autres distributions récentes, la faute aux vielles bibliothèques Qt 5.3 qui ne connaissent pas ces nouvelles méthodes apparues plus tard au fils des versions Qt.
https://launchpadlibrarian.net/26366255 … ING.txt.gz

Il faut donc soit se passer de ses nouvelles fonctions, ou en trouver une compatible même si ça nous arrangent moins ou adapter le code suivant la version trouvée : si le code à la compilation trouve que la version de Qt <= 4.5 cette fonction sera codé différemment que si la version Qt trouvée est supérieure, t'en fini plus !

C'etais déjà très fréquents sur le vieux code Qet et de l’évolution des libs Qt 4 en parallèles, il fallait ajuster le code suivant les versions Qt trouvées : positionnement des textes différents, impression, etc pouvaient différer suivant la version Qt.


Avec snap, tu fais comme je fais pour tous les paquets Windows : c'est la dernière version embarquée de Qt, GCC pour tout le monde, point barre.

Je parle pas des compilos GCC, etc, mais c'est souvent le même problème.

"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."