:hello:
Te voila donc membre du club… :paf:
:hello:
Pas encore complétement, je n’avais pas encore lancé la compil. :ane:
Petit joueur ! Tu retournes à la case départ, tu touches pas 20000 bitcoins ! :paf:
Pas de ma faute s’il y a une autre version dispo entre temps. :ane:
Bon. :paf:
La compil a planté. :nexath
Je me suis tapé un vieux « out of memory ». :heink:
Ok, c’est sur le netbook, mais il a quand même 2 GO de ram [:paysan] (et de mémoire 512 MO de swap je crois).
Il va falloir que j’enquête. :ane:
Edité le 09/07/2014 à 19:52
Quelqu’un se souvient il de la peine encourue par la bleuzaille qui plante un compiling ? :ane:
Stune Debian ? une Ubuntu ?
Tu compiles depuis ton bureau (serveur X démarré) ?
Une option exotique ?
C’est une Mint LMDE, compilation avec Cinamon lancé, mais depuis le mode console (le bon vieux ALT + F1 quoi 
).
Niveau option, tu parles de la commande pour lancer la compilation ?
Si oui, je me suis contenté de reprendre la ligne de commande donné par fabkill.
Un petit « init 3 » des familles apres ton « ALT + F1 » devrait stopper l’interface graphique et donc libérer des ressources.
Fakbill a donné un lien pour Ubuntu, avec des commandes qui diffèrent un chouia (l’histoire des threads si c’est un Atom, chui pas certain que ça va coller…)
Ce qui suit le « -J » peut être tout simplement le nombre de threads à utiliser, soit par exemple « -J 1 » ou « -J 2 » selon que tu aies un simple ou un double coeur…
Soit donc, avec la commande de fakbill et un seul coeur :
make -j 1 deb-pkg LOCALVERSION=-foobar
Tu adaptes à ta convenance. Attention ça peut être un peu long… Mais ça devrait pas aboutir à un « out of memory »…
Edité le 09/07/2014 à 22:16
Je testerai ça demain, merci. 
Compilation lancée depuis un moment, ça suit son cours, pas de message d’erreur pour le moment. :ane:
J'ai la 3.15.4 en compil ...
Le .5 est dispo. [:yeoh]
[:superguipom]
Ubuntu compile en gros tous les driverrs aui exsitent dans son noyau…et c’est pourquoi,même sur une machine récente, ca prend du temps de compiler un tel noyau.
Si on est joueur, on peur partir d’une config minimale et ne rajouter que ce qui est nécessaire.Dans ce cas, on peut compiler un noyo bcp bcp plus vite.
oui mes noyaux opti compilait en moins de 20mn y a 10 ans, et les b inaires occupaient genre 50Mo, noyau et modules (sans initrd) ^^
« Un petit « init 3 » des familles »
c’pas init 2 ? il me semble que X est démarré aux niveaux 3, 4, 5, et ça marche encore avec les sysV/upstart/systemd récents « à dépendances » ?
Mais c’est curieux le out of memory, Linux en impose un peu mais c’est plein de petites pièces plutot légères à compiler.
Pour avoir ce genre d’erreur de mon experience fallait compiler un gros projet C++ genre KDE, sans swap.
Bon, la compile est terminée mais j’ai des erreurs. 
make[2]: *** [vmlinux] Erreur 1
make[1]: *** [deb-pkg] Erreur 2
make: *** [deb-pkg] Erreur 2
[:kurdent]
Edité le 10/07/2014 à 18:29
Bon, je verrai ça plus tard, tant pis. :ane:
@ juju251 : T’as pas plus d’infos sur tes erreurs ? Un fichier make.log ou quelquechose du genre ?
@ Lithium : J’ai toujours pensé que les niveaux 2 et 4 n’etaient pas utilisés. Sous Redhat/Centos, pour l’instant en tous cas, ça fonctionne avec « init 3 » pour un mode non graphique (et 1 en mono utilisateur ou debbug)…
Si ça pouvait rester comme ça jusqu’à la prochaine génération de Linuxiens… :peur:
Dans ma mémoire c’est init 1 : root mono utilisateur
init 2 = texte multi utilisateurs
et 3,4,5 librement configurables.
Je viens de vérifier ma wheezy, elle boot au niveau 2 par défaut, et update-rc.d par défaut ajoute les daemons aux runlevels 2,3,4,5 (arret aux 0,1,6)
Mais depuis longtemps si je veux arreter le serveur X je me contente de service gdm stop.
Bon bin tant pis pour mewa… je note tout ça, on ne sait jamais… :jap:
Note pour plus tard… Rester sous redhat… :nexath
:ane:
3.16 out avec rien de nouveau qui m’intéresse vraiment (plein de patchs btrfs mais ça marchait déjà pour moi donc…).
Par contre, un support du branchement à chaud des périphérriques thunderbolt a été mergé dans le 3.17-rcX donc il sera dans le 3.17 sauf si qlqn trouve qu’il est bugé à mort (je teste ce driver depuis le 3.15 et il fonctionne sans problème. Par contre, il est toujours possible qu’il interagisse mal avec je ne sais quoi dans la couche PCIe et/ou l’ACPI et qu’on doive le sortir du noyau avant la sortie du 3.17.
m,sieur ! j’ai des questions sur btrfs !
j’essaye la bete et je suis tombé inlove des snapshots et je me demande à quel point c’est souple.
genre si j’en ai deux, y0 et y1, y1 est le dernier, est-ce que je peux remonter à y0 modifier un fichier puis retourner a y1 retrouver tout ce qui s’est passé depuis ainsi que la modification récente dans y0 ?
Heu… si j’ai bien compris ta phrase (et ce n’est pas certain) je crois que tu en demandes trop…
Si tu remontes à Y0 tu auras l’état YO…
Y1 c’est l’état YO + les modifs opérées jusqu’ à Y1…
mais Y1 ne s’aligne pas sur tes modifs récup YO + changements depuis le snapshot YO (effectué après snapshot Y1 au sens temporel du terme)…
Stun peu confus… :pt1cable: Bref, c’est pas rétro actif, enfin je crois pas…