00:48 <ccomb:#afpy> gawel: http://buildbot.afpy.org/formalchemy/waterfall?show=FormAlchemy%20Python2.7.2%2064bit%20Linux
00:48 <ccomb:#afpy> gawel: http://buildbot.afpy.org/formalchemy/waterfall?show=FormAlchemy%20Pypy1.6%202.7.1%2064bit%20Linux
00:48 <ccomb:#afpy> gawel: http://buildbot.afpy.org/formalchemy/builders/FormAlchemy%20Python3.2.2%2064bit%20Linux
02:11 <ogrisel:#afpy> ccomb: oui ca pete aussi sur scikit-learn
02:11 <ogrisel:#afpy> y a une merde dans le python due systeme je pense
02:12 <ccomb:#afpy> aie
02:15 <ogrisel:#afpy> je sais pas quelle est la cause mais clairement y a un truc qui deconne
02:15 <ccomb:#afpy> quand je lance make inplace directement depuis le slave ça démarre
02:16 <ogrisel:#afpy> le load est a 10
02:16 <ccomb:#afpy> oué, c'est monté à 14 tout à l'heure
02:16 <ogrisel:#afpy> c'est peut etre buildbot qui part en vrille
02:17 <ccomb:#afpy> y en a plein en meme temps
02:17 <ogrisel:#afpy> y a 12000 process buildbot
02:17 <ccomb:#afpy> pas 12000, mais ³0
02:17 <ccomb:#afpy> 10
02:17 <ccomb:#afpy> kgs3.4 autorelease bluebream restkit formalchemy ztk1.0 ztk1.0dev ztk1.1 ztk1.1dev scikit-learn
02:18 <ogrisel:#afpy> essaie peut etre d'eteindre tous les buildbots
02:18 <ccomb:#afpy> bah non je viens de les allumer
02:18 <ogrisel:#afpy> et de les relancer 1 par 1 pour voir si ca marche quand y en a peu
02:18 <ogrisel:#afpy> ah ok
02:18 <ccomb:#afpy> enfin y a 1h
02:18 <ccomb:#afpy> là le build marche, mais j'ai lancé en manuel
02:18 <ccomb:#afpy> j'ose pas l'arreter
02:19 <ccomb:#afpy> mais No module named numpy.distutils.core c pas normal
02:20 <ogrisel:#afpy> ogrisel@boa:~$ python
02:20 <ogrisel:#afpy> Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
02:20 <ogrisel:#afpy> [GCC 4.4.3] on linux2
02:20 <ogrisel:#afpy> Type "help", "copyright", "credits" or "license" for more information.
02:20 <ogrisel:#afpy> >>> from numpy.distutils.core import setup
02:20 <ogrisel:#afpy> >>>
02:20 <ogrisel:#afpy> fait chier
02:20 <ccomb:#afpy> pourtant PYTHON ?= python
02:20 <ogrisel:#afpy> ca va pas etre facile a debuguer :)
02:20 <ogrisel:#afpy> bas oui
02:21 <ccomb:#afpy> bon, je stoppe
02:22 <ccomb:#afpy> je starte
02:23 <ccomb:#afpy> force build
02:23 <ccomb:#afpy> pareil
02:23 <ccomb:#afpy> ah
02:24 <ccomb:#afpy> ok
02:24 <ogrisel:#afpy> oué
02:24 <ccomb:#afpy> mmmh
02:24 <ccomb:#afpy> source sandbox/bin/activate
02:24 <ccomb:#afpy> python
02:24 <ccomb:#afpy> Type "help", "copyright", "credits" or "license" for more information.
02:24 <ccomb:#afpy> >>> from numpy.distutils.core import setup
02:24 <ccomb:#afpy> Traceback (most recent call last):
02:24 <ccomb:#afpy> File "<stdin>", line 1, in <module>
02:24 <ccomb:#afpy> ImportError: No module named numpy.distutils.core
02:24 <ccomb:#afpy> >>>
02:25 <ccomb:#afpy> le buildbot est lancé depuis un virtualenv
02:25 <ogrisel:#afpy> ok y a un venv qui est passé en mode --no-site-package
02:25 <ogrisel:#afpy> ou un truc dans le genre
02:25 <ccomb:#afpy> donc quand il lance make il utilise celui-là
02:25 <ogrisel:#afpy> on a besoin du numpy du systeme
02:25 <ccomb:#afpy> faut changer le PYTHON ?=
02:26 <ccomb:#afpy> faut mettre le path complet
02:26 <ccomb:#afpy> dans le Makefile
02:27 <ccomb:#afpy> c'est fait comme ça pour les autres buildbots, j'utilise explicitement un /usr/share/python2.7.2/bin/python2.7
02:27 <ogrisel:#afpy> ca fait chier d'avoir a editer le makefile
02:28 <ogrisel:#afpy> si on fait un export PYTHON="/path/to/python" le makefile le prends peut etre en comtpe
02:28 <ogrisel:#afpy> je connais pas la syntaxe "?="
02:28 <ccomb:#afpy> on peut pas filer des options à make ?
02:28 <ccomb:#afpy> moi non plus
02:28 <ogrisel:#afpy> hehe
02:28 <ogrisel:#afpy> je vais le teste en local
02:29 <ogrisel:#afpy> ca marche: "PYTHON=/usr/share/python2.7.2/bin/python2.7 make"
02:29 <ccomb:#afpy> good
02:29 <ogrisel:#afpy> tu changes la conf du buildbot ?
02:29 <ogrisel:#afpy> t'as le bon user et je connais plus mon mdp sudoer :)
02:32 <ccomb:#afpy> ah
02:32 <ccomb:#afpy> faut faire avec env=
02:33 <ogrisel:#afpy> je vois pas de quoi tu parles
02:34 <ccomb:#afpy> pour filer PYTHON= au truc Command de buildbot
02:34 <ogrisel:#afpy> ca marche pas de faire un "PYTHON=/usr/share/python2.7.2/bin/python2.7 make" a la place de "make" tout court?
02:34 <ccomb:#afpy> je mets 2.6 d'ailleurs
02:34 <ccomb:#afpy> non
02:34 <ccomb:#afpy> enfin si
02:34 <ogrisel:#afpy> oui en effet
02:34 <ccomb:#afpy> mais pas comme ça
02:34 <ccomb:#afpy> f1.addStep(Compile(command=["PYTHON=/usr/share/python2.7.2/bin/python2.7", "make", "clean", "inplace"]
02:34 <ogrisel:#afpy> c'est 2.6
02:34 <ogrisel:#afpy> arf
02:35 <ccomb:#afpy> env={'PYTHON': '/usr/bin/python'}
02:35 <ogrisel:#afpy> ca marche aussi en 2.7 mais faudrait installer numpy et tout
02:35 <ccomb:#afpy> oui
02:35 <ccomb:#afpy> et pypy ?
02:35 <ogrisel:#afpy> nan scipy marchera pas avec pypy avant des annees
02:36 <ccomb:#afpy> ayé http://buildbot.afpy.org/scikit-learn/waterfall
02:36 <ogrisel:#afpy> y a 12000 dependances sur des libs d'algebre lineaire en fortran et tout
02:36 <ogrisel:#afpy> merci ccomb~
02:36 <ogrisel:#afpy> merci ccomb!
02:36 <ccomb:#afpy> suis explosé, vais me coucher, bonui
02:37 <ogrisel:#afpy> faut faire pareil pour les tests je pense
02:37 <ogrisel:#afpy> si tu l'as pas deja fait
02:37 <ogrisel:#afpy> hehe: http://buildbot.afpy.org/scikit-learn/builders/ubuntu-64bit/builds/7966/steps/test/logs/stdio
02:37 <ogrisel:#afpy> ccomb: reviens !
02:38 <ccomb:#afpy> ?!
02:38 <ogrisel:#afpy> meme pbm mais pour la commande test en plus du build
02:38 <ccomb:#afpy> vu
02:39 <ccomb:#afpy> ayé
02:45 <ccomb:#afpy> :'( ImportError: No module named numpy.distutils.core
02:46 <ogrisel:#afpy> fuck fuck fuck
02:46 <ogrisel:#afpy> bon on vera demain
02:46 <ogrisel:#afpy> je suis trop creve
02:47 <ogrisel:#afpy> t'as qu'a l'eteindre en attendant
11:33 <lothiraldan:#afpy> Salut tout le monde
12:37 <gawel:#afpy> ccomb: comment ça ce fait que tout est cassé ?
12:37 <gawel:#afpy> y a des eggs qui cherchent à se builder alors qu'ils sont la
12:38 <gawel:#afpy> c'est de la merde ça marche pas
12:54 <ccomb:#afpy> gawel: quel egss
12:55 <gawel:#afpy> bah plein apparement
12:55 <gawel:#afpy> http://buildbot.afpy.org/formalchemy/builders/fa.jquery%20Python2.6.5%2064bit%20Linux/builds/2/steps/compile_2/logs/stdio
12:55 <gawel:#afpy> et c'est pas le premier
12:58 <ccomb:#afpy> la conf buildbot doit pas etre bonne, elle isole pas assez
12:58 <ccomb:#afpy> si
12:59 <ccomb:#afpy> f.addStep(Compile(command=["virtualenv", "--distribute", "-p", python, "--no-site-packages", "sandbox"]))
13:02 <yota:#afpy> houla
13:02 <yota:#afpy> jamais vu cette erreur avec bb
13:02 <yota:#afpy> pas un pb de conf
13:02 <gawel:#afpy> t'as vu le path du egg ? il est dans ta home
13:02 <ccomb:#afpy> ben c bon
13:02 <ccomb:#afpy> ~/buildout-eggs/
13:02 <gawel:#afpy> sauf que ça marche pas visiblement
13:03 <yota:#afpy> il pense que le egg n'est pas installé, alors qu'il existe
13:03 <gawel:#afpy> c'est de la merde
13:03 <ccomb:#afpy> faut peut-etre purger un grand coup le slave
13:03 <gawel:#afpy> ouais va y!
13:04 <yota:#afpy> tu peux, mais bon, t'as conf buildout ne semble pas top, ou alors c'est un pb de permission
13:04 <ccomb:#afpy> buildslave process 8000 is dead
13:04 <gawel:#afpy> rm -Rf /home/ccomb
13:04 <ccomb:#afpy> méchant
13:05 <ccomb:#afpy> buildslave configured in /home/ccomb/formalchemy-slave
13:06 <ccomb:#afpy> The buildslave appears to have (re)started correctly.
13:07 <ccomb:#afpy> build started
13:08 <ccomb:#afpy> ça fait 18 builds en meme temps
13:08 <ccomb:#afpy> hier la charge était montée à 14
13:08 <ccomb:#afpy> d'ailleurs là load average: 11.23, 3.36, 1.30
13:08 <ccomb:#afpy> load average: 12.57, 3.91, 1.50
13:10 <ccomb:#afpy> load average: 17.58, 7.99, 3.19
13:11 <yota:#afpy> euh
13:12 <ccomb:#afpy> load average: 18.74, 11.08, 4.78
13:12 <kiorky:#afpy> ccomb: juste une connerie comme ca, vous aimez pas hudson ?
13:12 <ccomb:#afpy> la pauvre dedibox est pas assez surchargée, tu veux en plus foutre du java ? :P
13:12 <kiorky:#afpy> boah
13:12 <kiorky:#afpy> :p
13:13 <kiorky:#afpy> cest vrai qu'il nous bouffe pas mal
13:13 <ccomb:#afpy> c'est pas ça qui s'appelle jenkins maintenant ?
13:13 <kiorky:#afpy> ouai
13:13 <kiorky:#afpy> mais cest pas mal foutu
13:14 <kiorky:#afpy> apres, si tu as des ressources limitées, je comprends :)
13:14 <yota:#afpy> ca prends 1 Go de ram jenkins
13:14 <ccomb:#afpy> non mais faudrait surtout mettre un delai entre chaque builder
13:14 <yota:#afpy> et c'est chiant a programmer
13:14 <kiorky:#afpy> yota: pas tant que ca, je verifie
13:14 <ccomb:#afpy> ah bon
13:14 <yota:#afpy> mais y'a une interface ruby et groovy qui arrivent
13:15 <yota:#afpy> par contre bien mieux fini c'est clair coté ihm
13:15 <ccomb:#afpy> c'est bcps plus facile, mais pas aussi puissant que buildbot
13:15 <kiorky:#afpy> yota: uhm :p 1355872
13:15 <ccomb:#afpy> argh
13:15 <yota:#afpy> je l'ai utilisé plusieurs mois au taff
13:15 <yota:#afpy> je connais assez bien :)
13:16 <ccomb:#afpy> yota: tu veux pas faire un article comparatif sur ton blog ?
13:16 <yota:#afpy> tant qu'il faudra configurer en java, no way
13:16 <yota:#afpy> mais y'a des coté super positifs
13:16 <kiorky:#afpy> yota: disons quon a de la ressource, je metais pas trop posé la question
13:16 <yota:#afpy> comme naviguer dans le workspace, les graphes...
13:17 <yota:#afpy> kiorky: buildbot est programmable dans tout les sens
13:17 <yota:#afpy> c'est pour ca que je l'utilise
13:17 <kiorky:#afpy> ccomb: on en faisait ce que l'on en voulait facilement de hudson ... (monter un minitage, tester des choses basés sur buildout dedans ...)
13:17 <yota:#afpy> ccomb: j'ai déja 10 billets en attente + le blog gitfr :)
13:18 <yota:#afpy> le bon coté de jenkins, c'est qu'une personne qui ne connais *rien* te fais un job en 5mn
13:18 <yota:#afpy> c'est l'avantage n°&
13:18 <yota:#afpy> 1
13:18 <ccomb:#afpy> faut motiver du monde faire une ui en pyramid pour buildbot :)
13:18 <yota:#afpy> bof
13:19 <yota:#afpy> l'ui de bb doit etre dans...bb
13:26 <marmoute:#afpy> ccomb: discute avec boris à pyconfr. On arrive avec le renouveau du CI
13:27 <yota:#afpy> cubicweb le retour du fils de la vengeance
13:31 <gawel:#afpy> je suis ton père
13:32 <marmoute:#afpy> yota: qui te parle forcement cw
13:32 <yota:#afpy> je sais pas
13:32 <yota:#afpy> fout en fouter a toutes les sauces
13:32 <yota:#afpy> s/fout/vous/
13:32 <yota:#afpy> foutez
13:35 <marmoute:#afpy> hum, c'est puissant, ça se combine bien et on c'est s'en servir.
13:35 <marmoute:#afpy> bizarrement on à tendance à continuer à en faire…
16:18 <Maddingue:#afpy> nouvelle question ctypes (probablement pour haypo) : faut-il manuellement désallouer les chaines fournies par des fonctions externes ?
16:19 <Maddingue:#afpy> la doc de ctypes ne dit rien à ce sujet
16:19 <Maddingue:#afpy> mais valgrind me dit que mon programme fuit gentiment
16:19 <Maddingue:#afpy> et google a des réponses contradictoires
16:25 <haypo:#afpy> Maddingue: si tu écris un binding pour strdup(), tu devras libérer toi même la mémoire => appeler free() sur le résultat
16:25 <haypo:#afpy> après tu peux te débrouiller pour construire un objet python qui stocke le résultat en libérant la mémoire dans son destructeur, __del__()
16:36 <Maddingue:#afpy> j'ai vu des exemples avec strdup(), mais avec une signature de résultat POINTER(c_char) au lieu de c_char_p
16:38 <Maddingue:#afpy> parce que dans le cas de c_char_p, on a officiellement des chaines Python (str)
16:38 <Maddingue:#afpy> donc on pourrait s'attendre à ce qu'elles soient automatiquement libérées
16:48 <ogrisel:#afpy> c'est piegeux les pointeurs et le GC avec ctypes
16:48 <ogrisel:#afpy> je me fais avoir a chaque fois
16:50 <Maddingue:#afpy> ou alors il faut que j'appelle gc.collect() de temps en temps ?
16:53 <ogrisel:#afpy> si tu as alloues de la memoire avec l'API de la libc il faut que tu desalloues explicitement avec des appels a "free"
16:53 <ogrisel:#afpy> le gc ne va desallouer que la memoire allouée par le malloc de CPython
16:53 <Maddingue:#afpy> je n'utilise pas la libc mais la libxenstore
16:53 <ogrisel:#afpy> pareil
16:54 <Maddingue:#afpy> et la fonction xenstore_read(), qui me renvoie une chaine qu'elle a allouée
16:54 <Maddingue:#afpy> mais je peux faire un free() d'une chaine Python ?
16:55 <ogrisel:#afpy> par contre pour saovir quand desallouer le trick de haypo que j'ai utilisé c'est de garder le pointeur dans un objet python associé de faire l'appel a free dans le __del__ de ce companion object
16:55 <gawel:#afpy> def free(s): pass; free('chaine')
16:55 <ogrisel:#afpy> pour ne pas desallouer de la memoire qui est susceptible d'etre utilisé par une autre methode de cet objet par exemple
16:56 <Maddingue:#afpy> le principe de sous-classer les types de bsae pour définir sa propre gestion mémoire
16:56 <ogrisel:#afpy> tu appelles strdup ou pas ?
16:56 <Maddingue:#afpy> ben non
16:56 <ogrisel:#afpy> ah ok j'ai rien compris alors
16:57 <Maddingue:#afpy> le code en question est là : https://github.com/maddingue/xenballoond/blob/master/lib/xenballoond/xenstore_lite.py
16:57 <Maddingue:#afpy> et pour tester, je fais un while True: mode = xenstore_read("memory/mode")
17:01 <ogrisel:#afpy> je sais pas. xenstore_read dois allouer de la memoire a la main vu qu'il ne connait pas python
17:01 <ogrisel:#afpy> donc il doit falloir faire des free sur les pointeur qu'il retourne quand tu en a plus besoin
17:01 <Maddingue:#afpy> oui, c'est ce que je disais : xenstore_read() me renvoie une chaine qu'elle a allouée
17:02 <ogrisel:#afpy> ca renvoie pas une chaine, ca renvoie un pointeur
17:02 <Maddingue:#afpy> mais comme j'ai déclaré son type de retour comme un c_char_p, je reçoit une chaine Python
17:02 <ogrisel:#afpy> un pointeur sur une zone memoire qu'il a du allouer lors de l'appel
17:02 <ogrisel:#afpy> oui mais ca c'est juste un cast
17:03 <ogrisel:#afpy> je pense pas que ca attache une reference qui dit de faire un free sur la zone automatiquement: elle peut tres bien etre utilisée en // par d'autres fonctions C de la lib xen
17:04 <Maddingue:#afpy> bon, je vais essyer de faire un free() dessus
17:04 <ogrisel:#afpy> je suis plus trop sure de la semantique de des return types de python mais je pense pas qu'ils s'amusent a fair des free sur de la memoire qui n'a pas eté allouées par CPython
17:06 <Maddingue:#afpy> ça a du sens
17:06 <Maddingue:#afpy> mais la doc de ctypes est très silencieuses au sujet de la gestion mémoire
17:08 <Maddingue> *boum*
17:13 <haypo> Maddingue: "POINTER(c_char) au lieu de c_char_p" c'est pareil. pour avoir l'adresse de l'objet C sous-jacent, tu utilises byref(chaine) ou addressof(chaine)... enfin, à vérifier, ça fait qq. temps que je n'ai pas pratiqué ctypes :)
17:14 <haypo> pour avoir l'adresse de l'objet C sous-jacent *d'un c_char_p*
17:18 <ogrisel:#afpy> Maddingue: c'est vrai ctypes manque de doc (en tout la derniere fois que je l'ai lue)
17:19 <Maddingue:#afpy> d'après ce que je comprends, tant de la doc que de mes différents tests, une fonction externe dont on a indiqué qu'elle renvoie un c_char_p nous donne au final une chaine Python
17:19 <Maddingue:#afpy> ce n'est plus un objet ctypes sur lequel je peux faire byref()
17:19 <Maddingue:#afpy> TypeError: byref() argument must be a ctypes instance, not 'NoneType'
17:20 <Maddingue:#afpy> donc on dirait qu'il faut désactiver ce mécanisme en créant un nouveau type
17:22 <Maddingue:#afpy> quoique, essyons déjà avec c_void_p
17:22 <Maddingue:#afpy> pas mieux
17:26 <haypo:#afpy> Maddingue: pourquoi tu veux l'adresse de None ?
17:26 <haypo:#afpy> None n'est pas un objet ctypes
17:26 <haypo:#afpy> utilise au moins NULL = c_void_p(0)
17:26 <haypo:#afpy> Maddingue: si tu utilises strdup() qui renvoie un c_char_p, tu auras 2 copies de la chaîne (sans compter la chaine originale)
17:27 <haypo:#afpy> Maddingue: la version C (char*) et la version Python (str)
17:27 <haypo:#afpy> Maddingue: Python s'occupe de libérer ses objets (ici, str) avec la GC
17:27 <haypo:#afpy> Maddingue: par contre, pour la chaîne C, tu dois appeler free()
17:30 <Maddingue:#afpy> c'est marrant, vous me parlez tout le temps de strdup() :)
17:31 <haypo:#afpy> Maddingue: parce que tout le monde connait strdup, et personne ne connait ton API Xen
17:31 <Maddingue:#afpy> haypo: en effet, dans ce cas-là, il n'y avait pas de données, donc None. mais j'ai le même problème quand il y a des données : byref() argument must be a ctypes instance, not 'str'
17:32 <haypo:#afpy> Maddingue: strdup() te renvoie un str ?
17:32 <haypo:#afpy> hum, dans ce cas il ne faut pas utiliser c_char_p :)
17:32 <haypo:#afpy> mais POINTER(c_char)
17:32 <Maddingue:#afpy> tout à l'heure tu me disais que c'était pareil
17:33 <haypo:#afpy> ouio, mais j'ai ajouté que c'était à vérifier :)
17:33 <haypo:#afpy> je me suis trompé
17:33 <Maddingue:#afpy> :)
17:34 <Maddingue:#afpy> *** glibc detected *** python: free(): invalid pointer: 0x000000000094f5b0 ***
17:34 <Maddingue:#afpy> l'aime pas non plus
17:44 <Maddingue:#afpy> ok, donc libc.free() accepte un objet ctypes. pas un byref() d'un objet ctypes
17:45 <Maddingue:#afpy> par contre, accéder au contenu de la chaine devient moins simple
17:55 <Maddingue:#afpy> bon, ceci semble marcher : https://gist.github.com/1216938
17:57 <haypo:#afpy> Maddingue: je pensais à un truc du genre http://pastealacon.com/28568
17:57 <haypo:#afpy> while cstr[i] != '\0': <= waaah :-)
17:58 <haypo:#afpy> Maddingue: version simplifiée avec string_at() (plus simple qu'un while :-)) => http://pastealacon.com/28570
18:00 <Maddingue:#afpy> ah, je n'avais pas vu cette fonction string_at()
18:00 <haypo:#afpy> Maddingue: pratique comme fonction hein :)
18:01 <haypo:#afpy> avec ctypes, y'a plusieurs façon de faire
18:01 <haypo:#afpy> et ce n'est pas évident de savoir si ctype crée un objet Python par copie ou conserve une référence à l'objet C
18:01 <haypo:#afpy> il me semble que pointeur.contents crée une copie par exemple
18:01 <Maddingue:#afpy> oui
18:01 <Maddingue:#afpy> c'est documenté ainsi en tout cas
18:04 <Maddingue:#afpy> après, c'est normal que ce soit complexe : on joue avec des pointeurs, et ctypes n'a pas moyen de deviner qui joue avec en meme temps
18:05 <Maddingue:#afpy> mais dans le cas de c_char_p, j'ai l'impression que ctypes essaye d'être magique, mais ne le fait qu'à moitié
18:05 <Maddingue:#afpy> d'où les problèmes
18:06 <Maddingue:#afpy> à la limite, cela aurait aussi du sens de dire : si vous utilisez c_char_p, ctypes (et/ou Python) va gérer tout seul la désallocation de la chaine C sous-jacente. YHBW
18:07 <haypo:#afpy> Maddingue: bah non, parfois tu veux un str sans libérer la mémoire sous-jacente
18:07 <haypo:#afpy> genre pour strstr(), il ne faut pas appeler free() sur le résultat
18:08 <Maddingue:#afpy> certes
18:08 <Maddingue:#afpy> il pourrait sinon fournir un type qui le fait, en plus de c_char_p
18:09 <Maddingue:#afpy> genre, c_string ou py_string
18:10 <Maddingue:#afpy> qui derrière ferait ce que tu as codé
18:17 <haypo:#afpy> Maddingue: bah tu peux le coder toi-même :)
18:17 <haypo:#afpy> ctypes ne connait pas la libc
18:19 <Maddingue:#afpy> ai-je supposé le contraire ?
18:48 <gawel:#afpy> ccomb: ping
18:49 <gawel:#afpy> j'ai un client sans argent pour toi. t'es dispo un mercredi pour une réu ?
18:49 <ccomb:#afpy> haha
18:49 <gawel:#afpy> chez bearstech
18:49 <ccomb:#afpy> yes
18:49 <ccomb:#afpy> je lui donnerai une réponse sans solution :D
18:50 <gawel:#afpy> :)
18:50 <gawel:#afpy> mercredi 28; 14h, ça va ?
18:51 <ccomb:#afpy> gawel: ça va
18:51 <gawel:#afpy> ok, je transmets
18:59 <gawel:#afpy> ccomb: ccomb@anybox.com ?
19:00 <ccomb:#afpy> .fr
19:00 <gawel:#afpy> ok
19:04 <Maddingue:#afpy> bon, par contre, je n'arrive pas à comprendre comment tester si un pointeur renvoyé est NULL
19:04 <Maddingue:#afpy> ctypes me renvoie un objet, donc différent de None
19:05 <Maddingue:#afpy> pourtant il sait, ou du moins détecte que le pointeur derrière l'objet est NULL, puisqu'il m'envoie une exception à la gueule
19:07 <ccomb:#afpy> gawel: ça a l'air mieux les bots non ?
19:08 <gawel:#afpy> pas regardé
19:08 <ccomb:#afpy> http://buildbot.afpy.org/formalchemy/waterfall
19:08 <gawel:#afpy> je suis en réu h:D/bière
19:08 <ccomb:#afpy> 3 verts 3 rouges
19:08 <gawel:#afpy> ouais j'y ai touché un peu à midi
19:13 <Senethri1:#afpy> help
19:13 <Senethri1:#afpy> oops
19:46 <haypo:#afpy> jon1012: tu veux qu'on te ramène une galette ou un far ?
19:46 <jon1012:#afpy> haypo: ouais pour un afpyro :D lol
19:47 <jon1012:#afpy> (mais j'ai peur que ca soit trop sec apres)
19:49 <haypo:#afpy> tu peux le tremper dans la bière si c'est trop sec
20:02 <NelleV:#afpy> jpcw: y'a gmail qui me dit que tu tentes de faire du phishing :)
20:04 <haypo:#afpy> NelleV: alors, ça se passe bien les préparatifs ?
20:05 <NelleV:#afpy> préparatif pour pyconfr ?
20:05 <haypo:#afpy> oui
20:05 <NelleV:#afpy> je suis entrain de préparer une présentation de deux heures pour vendredi pour l'instant
20:06 <NelleV:#afpy> j'ai trié par ordre de priorité
20:06 <haypo:#afpy> pycon débute vendredi ?
20:06 <NelleV:#afpy> nope
20:07 <NelleV:#afpy> je fais une présentation de deux heures vendredi à Centrale Nantes
20:20 <jpcw:#afpy> NelleV: oh !
20:22 <jpcw:#afpy> hum tu peux me faire passer les infos si tu ne les pas cramées
20:22 <jpcw:#afpy> en fait aujurd'hui j'ai du nettoyer un serveur sur une ip suite à demande autorités touss
20:23 <jpcw:#afpy> c'était du pishing d'une banque en ligne espagnole
20:23 <jpcw:#afpy> je me demand s'il y a un lien
20:23 <NelleV:#afpy> jpcw: je suppose que tu n'arrives pas a voir le lien suivant: https://mail.google.com/support/bin/answer.py?hl=en-GB&ctx=mail&answer=185812
20:24 <jpcw:#afpy> NelleV: sis si
20:24 <haypo:#afpy> jpcw: tu avais un serveur verrolé ?
20:24 <jpcw:#afpy> merci
20:24 <jpcw:#afpy> pas moi
20:24 <jpcw:#afpy> un client du FAI pour lequel je gère les ip
20:24 <jpcw:#afpy> enfin j'interviens dessus
20:25 <cyp:#afpy> \o/ on m'a dit que j'étais un (petit) génie !
20:25 <jpcw:#afpy> y'avait une backdoor en perl
20:25 <cyp:#afpy> oups pas le bon chan
20:25 <jpcw:#afpy> cyp: clap clap, mais pourquoi tu es surpris ? :)
20:25 <jpcw:#afpy> haypo: d'ailleurs je me sers d'IPy
20:25 <jpcw:#afpy> je suis fan ce module
20:25 <cyp:#afpy> jpcw: réponse sur #paulla
20:25 <haypo:#afpy> jpcw: alors, c'est bien IPy ?
20:31 <haypo:#afpy> jpcw: j'ai fait qq. développements dessus récemment
20:31 <haypo:#afpy> j'continue à avoir des demandes de fonctionnalités
20:51 <jpcw:#afpy> haypo: désolé je prenais ma tôle aux milles bornes
20:52 <jpcw:#afpy> oui IPy est très bien
20:52 <haypo:#afpy> jpcw: tiens, j'avais commencé à coder un jeu de milles bornes, puis j'ai abandonné
20:52 <jpcw:#afpy> comme je t'avais déjà proposé, pour moi il manque IP.available_hosts()
20:52 <haypo:#afpy> alors qu'un ami avait dessin un plateau :-(
20:53 <haypo:#afpy> jpcw: c'est quoi available_hosts ?
20:53 <haypo:#afpy> j'accepte les patchs :)
20:53 <jpcw:#afpy> la liste des hôtes dispo sur un segment
20:53 <jpcw:#afpy> en clair IP - IP.net() et IPy.broadcast()
20:54 <jpcw:#afpy> bah je t'avais proposé sur #python-fr mais tu avais l'air surpris
20:54 <jpcw:#afpy> e tu m'avais dit que tu voulais pas le rajouter, que j'étais le seul à demander
20:54 <haypo:#afpy> je me souviens maintenant
20:55 <haypo:#afpy> bah écrit un patch avec des tests, ça devrait aller
20:56 <jpcw:#afpy> tu avais objecté sur les adresses réseau possible de type classe à l'intérieur d'un découpage cidr
20:57 <haypo:#afpy> jpcw: bah en fait, j'ai encore du mal à comprendre le réseau
20:57 <haypo:#afpy> dans 10.20.0.0/16, je ne sais pas si 10.20.30.0 et 10.20.30.255 peuvent être alloués à des machines
20:58 <haypo:#afpy> misc: une idée ?
20:58 <misc:#afpy> haypo: techniquement, oui
20:58 <haypo:#afpy> et en pratique ? :)
20:59 <misc:#afpy> en pratique, j'ai que des /24 et pas trop le temps tout de suite pour tester :/
20:59 <misc:#afpy> en fait, suffit de mettre un cable croisé et de tester
20:59 <jpcw:#afpy> haypo: tout est géré en cidr maintenant
20:59 <haypo:#afpy> en fait pareil, j'ai rarement utilisé des réseaux plus grand que /24 :-)
20:59 <jpcw:#afpy> donc je ne vois pas d'objection
20:59 <jpcw:#afpy> mais je ne peux t'affirmer
21:00 <jpcw:#afpy> haypo: moi je gère des /23
21:00 <jpcw:#afpy> mais bon au dessus y'a que les opérateurs :)
21:00 <misc:#afpy> bof, non
21:00 <jpcw:#afpy> et ils ont le machin qui va bien cissco ou autres
21:00 <haypo:#afpy> jpcw: je gère un /64, bon c'est pas trop saturé, j'ai juste deux équipements dans ce réseau :)
21:00 <misc:#afpy> moi, j'ai des vpns dans un réseau en classe A :)
21:01 <jpcw:#afpy> misc: je parlais de blocs gérés sur des AS
21:01 <haypo:#afpy> (en fait, c'est un /60 je crois, encore plus gros :-))
21:01 <haypo:#afpy> jpcw: alors, c'est quand la mort d'ipv4 ?
21:03 <jpcw:#afpy> haypo: dans 30 ans ?
21:03 <jpcw:#afpy> :)
21:03 <jpcw:#afpy> je crois qu'il n' ya que 3000 AS ipv6 sur les 40 0000 de la DFZ
21:03 <jpcw:#afpy> peut être un peu plus maintenant
21:04 <jpcw:#afpy> mais oui le ripe distribue dans les derniers /8 à sa dispo
21:04 <jpcw:#afpy> après tout n'est pas lloué
21:04 <jpcw:#afpy> il y aeu beaucoup de gaspillage
21:06 <haypo:#afpy> http://inetcore.com/project/ipv4ec/index_fr.html : APNIC, 0.96 réseau /8 dispo restant
21:07 <haypo:#afpy> tiens, ici j'ai pas d'ipv6. nul !
21:07 <haypo:#afpy> j'suis à l'hôtel, le FAI est SFR
21:09 <haypo:#afpy> jpcw: dans le doute, je te fais confiance pour .available_hosts()
21:10 <haypo:#afpy> jpcw: chaque fois qu'on me parler d'IPy, je me dis "pff, faudrait réécrire la bibliothèque" :-p
21:12 <haypo:#afpy> surtout quand je vois les bugs qu'on me remonte :-p
21:12 <jpcw:#afpy> haypo: je ne suis pas RFC compliant super fiable hein
21:13 <jpcw:#afpy> haypo: hum par contre ça manque de gestion d'erreur
21:13 <haypo:#afpy> jpcw: pas grave, tant que c'est documenté et testé
21:13 <jpcw:#afpy> haypo: mais dès que j'ai un peu de temps je te le code, avec les tests qui vont bien
21:14 <jpcw:#afpy> après par exemple broadcast dans l'absolu ce n'est pas obligatoirement la dernière ip du segment
21:14 <jpcw:#afpy> bien qu'en pratique ça le soit de fait la plupart du temps
21:14 <jpcw:#afpy> mais je crois que tu peux définir une autre ip pour le broadcast
21:15 <jpcw:#afpy> je ne suis pas sur à 100% hein
21:16 <lothiraldan:#afpy> Salut tout le monde
21:18 <haypo:#afpy> jpcw: ah ? j'doute qu'ipy gère _a
21:18 <haypo:#afpy> ça
21:18 <jpcw:#afpy> nope IPy l'a priori c'est que le broadcast c'est la dernière