Je viens de publier une nouvelle version de SeedboxSync. Pas de gros changements comme ça avait pu être le cas avec le v2.0.0. En effet, lessentiel des changements concerne : Migration vers les pages GitHub et mise en place d’une nouvelle documentation. Les fichiers avec une taille de 0 octet provoquaient un exit, c’est à […]

Cet article SeedboxSync 2.0.1, synchronisation de votre seedbox et de votre NAS est apparu en premier sur Guillaume Kulakowski's blog.

Histoire de garder ça sous le coude et de le partager, voici un pense bête sur comment uploader un package sur PyPi.org. Les prérequis Se créer un compte sur PyPi, mais également sur l’index de test. L’index de test permet de tester avant de pousser en production… Personnellement j’y ai le même login mais pas […]

Cet article Uploader un package sur PyPi est apparu en premier sur Guillaume Kulakowski's blog.

La version 2.0.0 de SeedboxSync vient d’être libérée ! C’est quoi SeedboxSync ? Imaginez que vous téléchargiez des fichiers via le protocole BitTorrent, des fichiers libres de droit, ça va de soi. Imaginez que pour une raison X ou Y vous ne puissiez pas le faire à partir de votre connexion (et donc votre IP) […]

Cet article SeedboxSync 2.0.0, synchronisation de votre seedbox et de votre NAS est apparu en premier sur Guillaume Kulakowski's blog.

Imaginons que vous soyez fan de distribution linux et que vous ayez des scripts maisons pour écouter toutes les dernières sorties de distributions Linux et pour les télécharger automatiquement sur votre NAS avec BitTorrent. Imaginez ensuite que vous ne souhaitiez pas télécharger ces fichiers par vous-même (pour une raison X ou Y…) mais que vous louiez une seedbox pour ça.

C'est alors que SeedboxSync entre en jeu ! Ce script Python permet :

• De synchroniser un répertoire local (celui contenant vos fichiers .torrent) avec un répertoire distant (le blackhole de votre seedbox par exemple).
• De lister tous les fichiers dans votre répertoire de téléchargements finis et de télécharger automatiquement ceux qui nont pas encore été téléchargés (utilisation dune base SQLite pour cela).

Le script est naturellement Open Source avec des sources disponibles sur GitHub, mais vous pouvez aussi linstaller directement via la commande pip :

pip install seedboxsync.

Pour le moment seul le protocole sFTP est géré, mais jai pour projet de rendre possible dautre méthode assez rapidement.

Pour finir, si vous préférez utiliser Sick Beard, Sick Rage et CouchPotato pour télécharger dautres types de torrents, seedboxsync marche aussi…

Imaginons que vous soyez fan de distribution linux et que vous ayez des scripts maisons pour écouter toutes les dernières sorties de distributions Linux et pour les télécharger automatiquement sur votre NAS avec BitTorrent. Imaginez ensuite que vous ne souhaitiez pas télécharger ces fichiers par vous-même (pour une raison X ou Y…) mais que vous louiez une seedbox pour ça.

C'est alors que SeedboxSync entre en jeu ! Ce script Python permet :

• De synchroniser un répertoire local (celui contenant vos fichiers .torrent) avec un répertoire distant (le blackhole de votre seedbox par exemple).
• De lister tous les fichiers dans votre répertoire de téléchargements finis et de télécharger automatiquement ceux qui nont pas encore été téléchargés (utilisation dune base SQLite pour cela).

Le script est naturellement Open Source avec des sources disponibles sur GitHub, mais vous pouvez aussi linstaller directement via la commande pip :

pip install seedboxsync.

Pour le moment seul le protocole sFTP est géré, mais jai pour projet de rendre possible dautre méthode assez rapidement.

Pour finir, si vous préférez utiliser Sick Beard, Sick Rage et CouchPotato pour télécharger dautres types de torrents, seedboxsync marche aussi…

Imaginons que vous soyez fan de distribution linux et que vous ayez des scripts maisons pour écouter toutes les dernières sorties de distributions Linux et pour les télécharger automatiquement sur votre NAS avec BitTorrent. Imaginez ensuite que vous ne souhaitiez pas télécharger ces fichiers par vous-même (pour une raison X ou Y…) mais que vous louiez une seedbox pour ça.

C'est alors que SeedboxSync entre en jeu ! Ce script Python permet :

• De synchroniser un répertoire local (celui contenant vos fichiers .torrent) avec un répertoire distant (le blackhole de votre seedbox par exemple).
• De lister tous les fichiers dans votre répertoire de téléchargements finis et de télécharger automatiquement ceux qui nont pas encore été téléchargés (utilisation dune base SQLite pour cela).

Le script est naturellement Open Source avec des sources disponibles sur GitHub, mais vous pouvez aussi linstaller directement via la commande pip :

pip install seedboxsync.

Pour le moment seul le protocole sFTP est géré, mais jai pour projet de rendre possible dautre méthode assez rapidement.

Pour finir, si vous préférez utiliser Sick Beard, Sick Rage et CouchPotato pour télécharger dautres types de torrents, seedboxsync marche aussi…

Un petit exemple basique de programmation parrallèle avec python

French version (English version)

L'autre jour je me suis penché sur la programmation asynchrone avec java et je suis tombé sur cet article : Asynchronous processing in Java applications – leveraging those multi-cores

Article vraiment clair et intéressant sur la programmation asynchrones avec Java.

Mais bon, mon langage de prédilection étant python, j'ai bien sûr cherché s'il était possible d'en faire autant avec.

Après quelques recherches sur internet je suis arrivé sur parallelpython, une petite bibliothèque python qui permet de faire de la programmation asynchrones facilement.

Revenons au début, quel est le but de la programmation asynchrones ? L'idée est de pouvoir faire plusieurs choses en même temps, de lancer plusieurs tâches en parallèles.

Commençons avec un script basique qui appelle deux fois une fonction qui attends 5 secondes avant de nous dire qu'elle a fini.

#!/usr/bin/python
 
"""
Exemple de programme python non-asynchrone.
"""
 
import time
 
def background_stuff(num):
  time.sleep(5) # wait 5 seconds
  return "%s J'ai fini" % num
 
if __name__ == "__main__":
    print "Commence a :" , time.asctime(time.localtime())
 
    print "Je commence"
    print background_stuff(1)
    print "Je fais quelque chose..."
    print " ... et autre chose..."
    print background_stuff(2)
 
    print "Fini a :", time.asctime(time.localtime())

L'idée est donc d'avoir une sortie comme ceci :

Commencé à : <date and time>
Je commence
Je fais quelque chose
 ... et autre chose...
1 J'ai fini
2 J'ai fini
Fini à: <date and time>

Mais c'est cette sortie que l'on obtient :

Commencé à : Fri Aug 19 13:35:15 2011
Je commence
1 J'ai fini
Je fais quelque chose
 ... et autre chose...
2 J'ai fini
Fini à: Fri Aug 19 13:35:25 2011

Donc python attend que la première fonction finisse avant de continuer. C'est le comportement par défaut, séquentiel et comme vous pouvez voir il faut 10 secondes pour éxécuter ce programme.

Mais bon on peux faire mieux que ça et on va re-écrire le programme pour faire appel aux fonctions en parallèle.

D'abord on installe la bibliothèque python voulue:

yum install python-pp

Et voici notre nouveau script

#!/usr/bin/python
 
"""
Exemple de programme python asynchrone.
"""
 
import pp
import time
 
def background_stuff(num):
  time.sleep(5)
  return "%s J'ai fini" % num
 
if __name__ == "__main__":
    print "Commence a :" , time.asctime(time.localtime())
    job_server = pp.Server()
 
    print "Je commence"
 
    f1 = job_server.submit(background_stuff, (1,) , modules=('time',))
    f2= job_server.submit(background_stuff, (2,), modules=('time',))
    print "Je fais quelque chose..."
    print " ... et autre chose..."
 
    print f1()
    print f2()
 
 
    print "Fini a :", time.asctime(time.localtime())

Les lignes importantes sont

import pp

On charge la bibliothèque parallel-python

job_server = pp.Server()

On crée un serveur de tâches.

f1 = job_server.submit(background_stuff, (1,) , modules=('time',))

On soumet une tâche au serveur.

Le premier argument est le nom de la fonction appelé, le second est un tuple des arguments à passer à la fonction et le troisième (dans cette exemple) est un tuple des bibliothèques python que la fonction doit avoir chargé. À noter que si la fonction background_stuff avait la ligne "import time" alors le troisième argument ne serait pas nécessaire.

Et maintenant la sortie est :

Commence a : Fri Aug 19 14:20:05 2011
Je commence
Je fais quelque chose...
 ... et autre chose...
1 J'ai fini
2 J'ai fini
Fini a : Fri Aug 19 14:20:10 2011

Comme vous pouvez voir, nous avons appelé deux fois la fonction background_stuff, fait quelque chose pendant qu'elle tournait, récupéré la sortie de la fonction et le tout en 5 secondes !

The new version of repoquery can do nice things.

English version (French version)

You might remember that sometime ago I played a bit with dependency tree, I have made it up to propose a patch to yum-utils to change repoquery directly.

This patch has been accepted and is now part of the latest version (v1.1.31) of yum-utils (currently in updates-testing).

There has therefore been quite some changes in repoquery. The old function --tree-* while still present and still working are no longer displayed in the --help.

In order to generate a similar output the command has changed to:

 for --tree-requires -> --requires --output=ascii-tree
 for --tree-conflicts -> --conflicts --output=ascii-tree
 for --tree-obsoletes -> --obsoletes --output=ascii-tree
 for --tree-whatrequires -> --whatrequires --output=ascii-tree

But you remember the last time you run --tree-requires R or something similar ? The output is really really big.

With this new version of repoquery comes the --level argument which enables you to specify how many levels you want to see (1,2,3..., all). So you can do

$ repoquery --requires R --output=ascii-tree --level=1
  R-2.13.1-1.fc15.x86_64 [cmd line]
   \_  R-devel-2.13.1-1.fc15.i686 [1: R-devel = 2.13.1-1.fc15]
   \_  R-devel-2.13.1-1.fc15.x86_64 [1: R-devel = 2.13.1-1.fc15]
   \_  libRmath-devel-2.13.1-1.fc15.i686 [1: libRmath-devel = 2.13.1-1.fc15]
   \_  libRmath-devel-2.13.1-1.fc15.x86_64 [1: libRmath-devel = 2.13.1-1.fc15]

or

$ repoquery --requires R --output=ascii-tree --level=2 
  R-2.13.1-1.fc15.x86_64 [cmd line]
   \_  R-devel-2.13.1-1.fc15.i686 [1: R-devel = 2.13.1-1.fc15]
   |   \_  R-core-2.13.1-1.fc15.i686 [1: R-core = 2.13.1-1.fc15]
   |   \_  R-core-2.13.1-1.fc15.x86_64 [1: R-core = 2.13.1-1.fc15]
   |   \_  bzip2-devel-1.0.6-3.fc15.i686 [1: bzip2-devel]
   |   \_  bzip2-devel-1.0.6-3.fc15.x86_64 [1: bzip2-devel]
   |   \_  gcc-c++-4.6.0-10.fc15.x86_64 [1: gcc-c++]
   |   \_  gcc-gfortran-4.6.0-10.fc15.i686 [1: gcc-gfortran]
   |   \_  gcc-gfortran-4.6.0-10.fc15.x86_64 [1: gcc-gfortran]
   |   \_  libX11-devel-1.4.3-1.fc15.i686 [1: libX11-devel]
   |   \_  libX11-devel-1.4.3-1.fc15.x86_64 [1: libX11-devel]
[...]
   \_  R-devel-2.13.1-1.fc15.x86_64 [1: R-devel = 2.13.1-1.fc15]
   |   \_  R-core-2.13.1-1.fc15.i686 [1: R-core = 2.13.1-1.fc15]
   |   \_  R-core-2.13.1-1.fc15.x86_64 [1: R-core = 2.13.1-1.fc15]
   |   \_  bzip2-devel-1.0.6-3.fc15.i686 [1: bzip2-devel]
[...]

But I promised repoquery could make us some pictures so check this:

$ repoquery --requires fedora-packager --output=dot-tree --level=2 > fedora-packager.dot
$ twopi -Tpng fedora-packager.dot -o fedora-packager-twopi.png

This gives you this nice pictures:

Another example:

$ repoquery --requires --output=dot-tree --level=1 R-Biobase R-tkWidgets R-DynDoc R-widgetTools > Rtree.dot
$ dot -Tpng Rtree.dot -o Rtree-dot.png

Which gives you this nice graph showing nicely the order in which this packages can be built:

La nouvelle version de repoquery permet de faire des choses amusantes.

French version (English version)

La nouvelle version de repoquery (v1.1.31, dans updates-testing) inclut un patch que j'ai soumis suite à mes essais sur les graph de dépendances.

Avec cette version les commandes changent un petit peu puisque même si toutes les commandes --tree* sont encore disponible et fonctionnelles, elles ne sont plus affiché dans le --help.

À la place, vous devez maintenant spécifier le format de sorti:

 for --tree-requires -> --requires --output=ascii-tree
 for --tree-conflicts -> --conflicts --output=ascii-tree
 for --tree-obsoletes -> --obsoletes --output=ascii-tree
 for --tree-whatrequires -> --whatrequires --output=ascii-tree

De même, vous pouvez en limiter la taille:

$ repoquery --requires R --output=ascii-tree --level=1
  R-2.13.1-1.fc15.x86_64 [cmd line]
   \_  R-devel-2.13.1-1.fc15.i686 [1: R-devel = 2.13.1-1.fc15]
   \_  R-devel-2.13.1-1.fc15.x86_64 [1: R-devel = 2.13.1-1.fc15]
   \_  libRmath-devel-2.13.1-1.fc15.i686 [1: libRmath-devel = 2.13.1-1.fc15]
   \_  libRmath-devel-2.13.1-1.fc15.x86_64 [1: libRmath-devel = 2.13.1-1.fc15]

Enfin vous pouvez en faire des image:

$ repoquery --requires fedora-packager --output=dot-tree --level=2 > fedora-packager.dot
$ twopi -Tpng fedora-packager.dot -o fedora-packager-twopi.png

Ce qui vous donne:

Un autre exemple:

$ repoquery --requires --output=dot-tree --level=1 R-Biobase R-tkWidgets R-DynDoc R-widgetTools > Rtree.dot
$ dot -Tpng Rtree.dot -o Rtree-dot.png

Ce qui retourne cette image, montrant les dépendances entre les paquets:

Version 1.1.0 du client text pour pkgdb.

Release 1.1.0 of the command-line interface for pkgdb.

English version (no French)

I have pushed to testing few days ago a new version of packagedb-cli (aka pkgdb-cli).

With this new version:

• You can adopt an orphaned package
• The user name if not specified can be retrieved from the fedora_cert file (if presents)
• If the package is orphaned, it is now highlighted
• Approve all the request for someone but only the requested ACLs (not all ACLs)

There has also been some bugs fixed thanks to sochotni and ppisar who reported them on the trac.

Feel free to test and comment the updates:

• F16 https://admin.fedoraproject.org/updates/packagedb-cli-1.1.0-1.fc16
• F15 https://admin.fedoraproject.org/updates/packagedb-cli-1.1.0-1.fc15
• F14 https://admin.fedoraproject.org/updates/packagedb-cli-1.1.0-1.fc14

• EL6 https://admin.fedoraproject.org/updates/packagedb-cli-1.1.0-1.el6
• EL5 https://admin.fedoraproject.org/updates/packagedb-cli-1.1.0-1.el5

Version 1.0.0 du client text pour pkgdb.

Release 1.0.0 of the command-line interface for pkgdb.

English version (no French)

This morning has just been reviewed and approved the rpm for packagedb-cli (Thanks Elad!).

I am waiting for the SCM to be validated and I will upload and build this first release.

I am looking forward to hear your suggestions, comments and bug reports on the trac of the project

PS: If you rebuild the src.rpm from the review, I was pointed out that the USAGE in --help is not quite accurate, this is already fixed in git and will fixed at import.

Un client text pour pkgdb.

A command-line interface for pkgdb.

English version (no French)

With the help and advices from abadger1999 I have recently been working on pkgdb-cli, a command line version of the famous tool pkgdb.

The idea behind this tool is to allow you to do everything you do on pkgdb without having to use the website. Using it, you can therefore:

• request ACL for a package
• approve/deny ACL to someone's ACL request
• orphan a package
• check the ACL for a package
• list the package for a user
• list all the package in pkgdb
• and some more :-)

The code is now in a decent shape, nothing fancy but it should work and for now what it needs is testers.

So if you have to request/approve/deny acl, if you want to see the list of packages owned by someone, if you what to check the ACL for your packages and if you feel like, feel free to test it.

And of course, if you run into bugs please report them !

PS: Also Thanks to Haikel for his help

Amélioration du script pour pkgdb.

Improvement of the script to query pkgdb.

English version

I made some changes to my script to query pkgdb. It now returns the group which can commit, the comaintainers (with their rights) and this for all branches or just one.

The script

French version

J'ai fait quelques modifications à mon script qui récupère les informations de pkgdb. Maintenant, les comainteneurs (avec leur droits) et les groupes qui peuvent commiter sur le paquet sont affichés et ce pour toutes les branches ou juste pour une.

Le script

Output/Sortie:

$ ./pkgdb.py R-qtl f14
Fedora Package Database -- R-qtl
Tools for analyzing QTL experiments
f14   Owner:          ellert
     Group:          provenpackager
     Comaintainer(s):
       pingou        watchbugzilla watchcommits  commit        
     Last build:     2011-01-20 by ellert for R-qtl-1.19.20-1.fc14 in Updates

$ ./pkgdb.py guake devel
Fedora Package Database -- guake
Drop-down terminal for GNOME
devel Owner:          pingou
     Group:          packager        provenpackager
     Comaintainer(s):
       maxamillion   watchbugzilla watchcommits                
     Last build:     2011-02-09 by ausil for guake-0.4.2-3.fc15 in Updates

Un petit script pour interroger pkgdb

A small script to query pkgdb.

English version

Yesterday I worked a little bit on how to retrieve information for a given package from pkgdb. I found out that python-fedora contains a xmlrpc client which can call pkgdb.

Combining this client with Koji's client I could retrieve easily the owner of the package on each branch and the lastest version of the package in updates and updates-testing repository.

Below are some examples.

The script

French version

Hier, je me suis amusé à récupérer des informations sur un package par pkgdb. J'ai trouvé que python-fedora contient un client xmlrpc qui peut interroger pkgdb.

En combinant ce client avec Koji, on peut récupérer facilement le mainteneur d'un paquet ainsi que la dernière version disponible dans les dépôts updates et updates-testing.

Ci-dessous, quelques exemples.

Le script

The examples / Les exemples:

$ ./pkgdb.py guake
Fedora Package Database -- guake
devel   pingou
         last build: 2011-02-09 by ausil for guake-0.4.2-3.fc15 in Updates
f15     pingou
         last build: 2011-02-09 by ausil for guake-0.4.2-3.fc15 in Updates
f14     pingou
         last build: 2010-08-24 by pingou for guake-0.4.2-2.fc14 in Updates
F-13    pingou
         last build: 2010-08-24 by pingou for guake-0.4.2-2.fc13 in Updates

$ ./pkgdb.py kernel
Fedora Package Database -- kernel
devel   kernel-maint
         last build: 2011-05-09 by kyle for kernel-2.6.39-0.rc6.git6.0.fc16 in Updates
f15     kernel-maint
         last build: 2011-05-06 by airlied for kernel-2.6.38.5-24.fc15 in Updates
f14     kernel-maint
         last build: 2011-05-03 by cebbert for kernel-2.6.35.13-91.fc14 in Updates
F-13    kernel-maint
         last build: 2011-02-17 by kyle for kernel-2.6.34.8-68.fc13 in Updates
         last build: 2011-05-03 by cebbert for kernel-2.6.34.9-69.fc13 in Updates-testing
OLPC-2  johnp
         last build: 2007-11-01 by cebbert for kernel-2.6.23.1-21.fc7 in Updates

The ideas I would like to do/see.

Une petite liste d'idées que je voudrais faire/voir.

English format

The good point of spending 2 weeks without touching a keyboard is that it gives you ideas on what you want to do or see done.

There is what I have been thinking of:

• R2spec is a tool to create spec file, and now rpm, for R packages. It has quite evolve since I first write it and my python knowledge for sure has changed. I therefore would like to clean it and rewrite it to a more logical and hopefully cleaner code.

• cran2rpm, this is a tool to generate the order in which the R packages should be built for a given repo. This would be used with R2spec to generate RPMs for the whole CRAN or Bioconductor. There has been some thoughts about it on the Fedora-R-devel mailing-list and it is something I would like to help as I don't think I'd have time to do it myself.

• Revelation is a password management tool. If I had time I would like to remove its warnings and even implement a pgp encryption for the database. At some point I started to rewrite it but it would be simpler to just work on revelation rather than rewrite everything.

• pkgdb-cli would be a tool to query the package database of Fedora. It would give you the version of the package in the different repo, the owner of the package on the different branches and if possible maybe it could also handle ACL request. So basically a CLI version of pkgdb.

• Make yum-utils a python library. At the moment most of yum-utils' code are simple python file, I was thinking that making it a python library would be nice as it would allow people to import yumutils and use the code easily.

• ABRT report upstream. This is something I have been thinking about but I never shared it nor did I check if the discussion already happened, but I was thinking that there cases were one would like ABRT to report its bug to the bug tracker of the project rather than Fedora's bugzilla. I was thinking that there could be a plugin system on ABRT with a plugin for each bug tracker system (trac, bugzilla, google code...) and a small database containing for each packages concerned the url of the bug tracker, its system and username and password. When a bug would be detected, ABRT would check if the package is present in the database, if it is, then the bug is opened against this bug tracker otherwise it is opened in Fedora's bugzilla.

So there are my few ideas. I don't know whether they are good nor if I will have time to work on them. But what do you think about them?

If there are people interested about them, maybe I could make some time ;-)

A simple pygtk R console with callback

Une petite interface en pygtk pour R avec affichage des sorties de R dans la fenêtre

English version

Yesterday with the help of Haikel I have made a small interface for R using pygtk. The Window was design with glade, it is a really simple interface:

User can enter their command in the input field, press the button and the given command will be run in R.

The interface between R and python is made using the rpy2 library.

The tricky part was to actually output the results from R directly in the gtk window as their are generated, in other word, showing the output of the function before the end of the function as some R commande can take a little while.

For this Haikel pointed me to the rpy2 documentation which allows callback from the R terminal. This way one can redirect the output from R into the gtk window. So here is the magic:

def callbackFunction(self, x):
    """ Function which redirect the output from R to the gtk window """
    if self.gtkbuffer is None:
        print x
    else:
        self.gtkbuffer.insert(self.gtkbuffer.get_end_iter(), x)
        while gtk.events_pending():
            gtk.main_iteration()

 def runR(self, cmd):
     """ 
     Function runs in R the given command and set the redirection 
     of the output 
     """
     if len(cmd) > 0:
         self.addToText("> %s" %cmd)
         rinterface.set_writeconsole(self.callbackFunction)
         robjects.r("%s" %cmd )
         # restore default function
         rinterface.set_writeconsole(rinterface.consolePrint)

The glade file and the full python code are available there:

• glade file
• python file

Results ? See:

Distribution des lettres de l'alphabet

Distribution of the alphabet

English version (French below)

It is one of the basic principle of cryptography which tries to replace characters by letters using statistics to break secret messages. The statistics relies on the fact that for each language the distribution of the letter used change.

I therefore wrote a small script to verify it :-)

There are the output for the wikipedia page about the GPL in English, French and German.

I have to say, that I was expecting higher differences (I am showing in the plot the percentage to correct for the difference in length of the pages).

French version

C'est un des principes de bases de la cryptographie que se base sur la répartition des lettres de l'alphabet dans chaque langues pour décrypter des messages codés. Cette répartition varie en effet pour chaque langue.

J'ai donc écris un petit script pour vérifier ça :-)

Voici donc la distribution des lettres de l'alphabet pour la page de wikipedia à propos de la GPL en Anglais, Français et Allemand.

Je dois dire que j'attendais des différences plus prononcés (les graphs montrent les pourcentages pour palier à la différence de contenu entre les pages).

En Fr De

Small update about the dependency graph story.

Quelques nouvelles sur cette histoire de graphique de dépendances.

English version (Pas de française)

Few days ago (one week to be precise), I was presenting a small python script to generate dependency graph.

I was then pointed that, it is similar to rpmorphan, that it does not deal with Provides and that the story was anyway more complicated than what I was doing. So it was nice but unfinished business.

Yesterday, akurtakov asks me if I could have a look at

repoquery --tree-requires <package>

and see if I could make a dot file out of it.

So I gave it a shot and wrote generateDependencyList2.py. This script takes a folder with spec files or a given package name, runs repoquery --tree-requires <package> and parse the output to generate a SVG picture of the first level dependencies.

This was nice and looked nice until sochotni asked this morning if we could get the same picture but for the command:

repoquery --tree-whatrequires <package>

Of course, the script works in the same way, but it is kinda quick and dirty solution. So I decided that the best would actually to try to get this within repoquery.

After speaking with Seth I therefore wrote another small python script (package-graph.py) which I have submitted for comments on yum-devel. If this work out, we should be able to quickly and simply get the graph of packages depending / requiring the given package.

Feel free to test this new version and make RFE :-)

To use it:

• Download the script from http://pingou.fedorapeople.org/package-graph.py
• Put it in /usr/bin (it needs repoquery's code)
• package-graph.py --package=foo > foo.dot
• twopi -Tsvg -O foo.dot
• eog foo.dot.svg

A small script to generate the dependency graph from spec file

Un petit script pour générer le graph des dépendances à partir de fichier spec

English version

I maintain some R packages which have a quite nice dependency graph. Every time I fight to find back the order in which I should build them. So yesterday I started a small script which would give me the dependencies in a graph so that I could see the information I am looking for.

I came up with a small python script relying on pydot.

The last version is available there: http://project.pingoured.fr/misc/file/12447ca38f25/generateDependencyList.py

You run it as:

$ python generateDependencyList.py -f ~/GIT/
dependencygraph.svg has been generated

The output can look like this or (These pictures has been converted from svg to png and reduced)

sochotni pointed out that it actually does a similar job than rpmorphan, too bad, it was fun to do :-)

Automate some of the step needed for a review

Automatiser quelques unes des étapes pour la revue d'un paquet RPM

English format

One month ago I was presenting a small script to automate to a certain point R review.

Since then, I have quickly been working on re-factoring the code to make it hopefully cleaner and more flexible.

The script works really simply, give it a src.rpm or a url and it will download the src.rpm, download the sources of the package, compare the sha1sum with upstream, install the srpm, build it locally and if the local build worked, start a scratch build on koji and run rpmlint on the generated rpm.

This is made for any package, but according to the name of the package more functionality can be added. I already added the function specific for R reviews, but I would like to know if person from PHP-Pear/Pcl or from Perl would also be interesting to add their own method in this script.

Again the goal is not to replace to reviewer but more to make his task easier also by automating some of the mandatory steps (such as the local build, the sha1sum of the srpm vs the upstream sources or running rpmling). It is not meant to replace a human reviewer but more to assist him.

The script is available at: http://pingou.fedorapeople.org/reviewHelper.py

Let me know if you find it interesting.