Tuesday, January 5 2016
By Pierre-Yves on Tuesday, January 5 2016, 18:59 - Général
Friday, December 11 2015
By Pierre-Yves on Friday, December 11 2015, 12:24 - Général
Every once in a while we make changes to dist-git in the Fedora infrastructure. This means, we need to test our changes to make sure they do not break (ideally, at all).
These days, we are working on adding namespacing to our git repos so that we can support delivering something else than rpms (the first use-case being, docker). So with the current set-up we have, we added namespacing to pkgdb which remains our main endpoint to manage who has access to which git repo (pkgdb being in a way a glorified interface to manage our gitolite). The next step there is to teach gitolite about this namespacing.
The idea is to move from:
/srv/git/repositories/<pkg1>.git /srv/git/repositories/<pkg2>.git /srv/git/repositories/<pkg3>.git /srv/git/repositories/<pkg4>.git
To something like:
/srv/git/repositories/rpms/<pkg1>.git /srv/git/repositories/rpms/<pkg2>.git /srv/git/repositories/rpms/<pkg3>.git /srv/git/repositories/rpms/<pkg4>.git /srv/git/repositories/docker/<pkg2>.git /srv/git/repositories/docker/<pkg5>.git
But, in order to keep things working with the current clone out there, we'll symlink the rpms namespace to one level higher in the hierarchy which should basically keep things running as they are currently.
So the question at hand is, now that we have adjusted our staging pkgdb and dist-git, how do we test that fedpkg still works.
This is a recipe from bochecha to make it easy to test fedpkg in staging while not breaking it for regular use.
It goes in three steps:
1. Edit the file /etc/rpkg/fedpkg.conf and add to it:
[fedpkgstg] lookaside = http://pkgs.stg.fedoraproject.org/repo/pkgs lookasidehash = md5 lookaside_cgi = https://pkgs.stg.fedoraproject.org/repo/pkgs/upload.cgi gitbaseurl = ssh://%(user)email@example.com/%(module)s anongiturl = git://pkgs.stg.fedoraproject.org/%(module)s tracbaseurl = https://%(user)s:%(password)firstname.lastname@example.org/rel-eng/login/xmlrpc branchre = f\d$|f\d\d$|el\d$|olpc\d$|master$ kojiconfig = /etc/koji.conf build_client = koji
2. Create a fedpkgstg (the name of the cli must be the same as the title of the section entered in the config file above)
sudo ln -s /usr/bin/fedpkg /usr/bin/fedpkgstg
3. call fedpkgstg to test staging and fedpkg to do your regular operation against the production instances
Thursday, July 23 2015
By Pierre-Yves on Thursday, July 23 2015, 08:43 - Général
flask is a micro-web-framework in python. I have been using it for different projects for a couple of years now and I am quite happy with it.
I have been using it for some of the applications ran by the Fedora Infrastructure. Some of these applications could be re-used outside Fedora and this is of course something I would like to encourage.
One of the problem currently is that all those apps are branded for Fedora, so re-using them elsewhere can become complicated, this can be solved by theming. Theming means adjusting two components: templates and static files (images, css...).
jinja2 the template engine in flask already supports loading templates from two different directories. This allows to ask the application to load your own template first and if it does not find them, then it looks for it in the directory of the default theme.
Code wise it could look like this:
# Use the templates # First we test the core templates directory # (contains stuff that users won't see) # Then we use the configured template directory import jinja2 templ_loaders =  templ_loaders.append(APP.jinja_loader) # First load the templates from the THEME_FOLDER defined in the configuration templ_loaders.append(jinja2.FileSystemLoader(os.path.join( APP.root_path, APP.template_folder, APP.config['THEME_FOLDER']))) # Then load the other templates from the `default` theme folder templ_loaders.append(jinja2.FileSystemLoader(os.path.join( APP.root_path, APP.template_folder, 'default'))) APP.jinja_loader = jinja2.ChoiceLoader(templ_loaders)
Adjusting static files
This is a little more tricky as static files are not templates and there is no logic in flask to allow overriding one or another depending on where it is located.
To solve this challenge, I wrote a small flask extension: flask-multistatic that basically allows flask to have the same behavior for static files as it does for templates.
Getting it to work is easy, at the top of your flask application do the imports:
import flask from flask_multistatic import MultiStaticFlask
And make your flask flask application multistatic
APP = flask.Flask(__name__) APP = MultiStaticFlask(APP)
You can then specify multiple folders where static files are located, for example:
APP.static_folder = [ os.path.join(APP.root_path, 'static', APP.config['THEME_FOLDER']), os.path.join(APP.root_path, 'static', 'default') ]
Note: The order the the folder matters, the last one should be the folder with all the usual files (ie: the default theme), the other ones are the folders for your specific theme(s).
Patrick Uiterwijk pointed to me that this method, although working is not ideal for production as it means that all the static files are served by the application instead of being served by the web-server. He therefore contributed an example apache configuration allowing to obtain the same behavior (override static files) but this time directly in apache!
So using flask-multistatic I will finally be able to make my apps entirely theme-able, allowing other projects to re-use them under their own brand.
Thursday, June 25 2015
By Pierre-Yves on Thursday, June 25 2015, 10:49 - Général
Recently I have been looking into Server-sent events, also known as SSE or eventsource.
The idea of server-sent events is to push notification to the browser, in a way it could be seen as a read-only web-socket (from the browser's view).
Implementing SSE is fairly easy code-wise, this article from html5rocks pretty much covers all the basics, but the principle is:
Server-side, things are also fairly easy but also need a little consideration:
- You need to create basically a streaming server, broadcasting messages as they occurs or whenever you want.
- The format is fairly simple:
data: <your data> \n\n
- You cannot run this server behind apache. The reason is simple, the browser keeps the connection open which means apache will keep the worker process running. So after opening a few pages, apache will reach its maximum number of worker processes running, thus ending up in a situation where it is waiting forever for an available worker process (ie: your apache server is not responding anymore).
So after running into the third point listed above, I moved the SSE server out of my flask application and into its own application, based on trollius (which is a backport of asyncio to python2), but any other async libraries would do (such as twisted or gevent).
After splitting the code out and testing it some more, I found that there is a limitation on the number of permanent connection a browser can make to the same domain. I found a couple of pages mentioning this issue, but the most useful resource for me was this old blog post from 2008: Roundup on Parallel Connections, which also provides the solution on how to go around this limitation: the limit is per domain, so if you set-up a bunch of CNAME sub-domain redirecting to the main domain, it will work for as many connection as you like :-) (note: this is also what github and facebook are using to implement web-socket support on as many tabs as you want).
The final step in this work is to not forget to set the HTTP Cross-Origin access control (CORS) policy in the response sent by your SSE server to control cross-site HTTP requests (which are known security risks).
So in the end, I went for the following architecture:
Two users are viewing the same page. One of them edits it (ie: sends a POST requests to the flask application), the web-application (here flask) processes the request as usual (changes something, updates the database...) and also queue a message in Redis information about the changes (and depending on what you want to do, specifying what has changed).
This way, the first user updated the page and the second user had the changes displayed automatically and without having to reload the page.
Wednesday, June 17 2015
By Pierre-Yves on Wednesday, June 17 2015, 10:04 - Général
How to get started with contributing to pkgdb2.
Thursday, May 7 2015
By Pierre-Yves on Thursday, May 7 2015, 12:26 - Général
A little while ago I presented a script allowing to search for the packages of a specified user and see which are missing from either anitya or are not being monitored in pkgdb2.
This script however, only check someone's packages and someone time we want to check a number of packages at once, eventually, all the packages matching a given template.
This new script does just that:
$ python pkgs_not_in_anitya_2.py 'drupal-*' drupal-service_links Monitor=False Anitya=False drupal-calendar Monitor=False Anitya=False drupal-cck Monitor=False Anitya=False drupal-date Monitor=False Anitya=False drupal-workspace Monitor=False Anitya=False drupal-views Monitor=False Anitya=False
If you are interested, feel free to use the script
Friday, April 3 2015
By Pierre-Yves on Friday, April 3 2015, 16:22 - Général
One of the earliest feature request of pkgdb2 (that was present in pkgdb1) is the browser search integration.
This integration is based on the OpenSearch specifications and basically allows to use pkgdb as one of the search engine of your web browser just like you can use google, duckduckgo or wikipedia.
I recently found out this feature is not so well known, so I thought I would present it and explain how to set it up (screenshot are on Firefox).
1/ Go to https://admin.fedoraproject.org/pkgdb and click on the list of search engines at the top right.
2/ Select the entry Add "Fedora PkgDB2: Packages"
That's it you are done for the most important step :)
Now something which I do and find most useful is:
3/ Go to Manage Search Engines...
There, with the search engine pkgdb packages associate the keyword pkgdb
Now, you can use your url bar as usual but when you enter pkgdb <something> it will search this <something> in pkgdb directly. So for example, if you want to search for guake in pkgdb, you would type in your url bar pkgdb guake.
The bonus point is that since there is only one package with this name, you will be immediately redirected to its page.
This way, when you want to quickly find information about a package in pkgdb, you can get it from your browser in one simple step (eventually two if several package match the keyword you entered).
Final bonus point? To access pkgdb directly, enter in the url bar: "pkgdb " (with a space at the end), without a keyword, Firefox will bring you directly to the front page of the application.
Tuesday, March 24 2015
By Pierre-Yves on Tuesday, March 24 2015, 14:35 - Général
A little while ago, I blogged about the new package and new branch request processes.
These changes have been pushed to production yesterday.
What does this change for you, packager?
From there admins will review the package review on bugzilla and create the package in pkgdb (or refuse with an explanation).
If your package is already in Fedora, you can now directly request a new branch in pkgdb. Here there are multiple options
- You have approveacls on the package (thus you are a package admin) and the request is regarding a new Fedora branch: The branch will be created automatically
- You have approveacls on the package (thus you are a package admin) and the request is regarding a new EPEL branch: The request will be submitted to the pkgdb admins who will process it in their next run
- You do not have approveacls on the package, then your request will be marked as: `Pending`, this means that the admins of the package have one week to react. They can either approve your request and by setting it to Awaiting Review, or they can decline the request (for which they must specify a reason). After this one week (or sooner if the package admin set the request to Awaiting Review) the pkgdb admin will process the request like they do with the other.
Note: Even with this new workflow, requests are still manually reviewed, so the requests will not necessarily be processed faster (but if it is easier for the admins, they may run it more often!).
What does this change for you, admins?
Hopefully, the process will be much simpler for you. In short
- no need to log onto any system, you can do everything from your own machine and it should work out of the box
- much more automated testing (including checking if a package is present in RHEL and on which arch for EPEL requests)
- one tool to process the requests: pkgdb-admin distributed as part of packagedb-cli (aka: pkgdb-cli)
I hope this process makes sense to you and will make your life easier.
You are welcome to already use these processes, just let us know if you run into some problems, but for the time being both the old and the new processes are supported :-)
Wednesday, February 25 2015
By Pierre-Yves on Wednesday, February 25 2015, 13:21 - Général
The question was asked on the devel list earlier if there was a way to check all one's packages for their status in pkgdb and whether they are in anitya.
So I just cooked up quickly a small script to do just that, it retrieves all the packages in pkgdb that you are point of contact or co-maintainer and tells you if its monitoring flag is on or off in pkgdb and if it could be found in anitya.
For example for me (partial output):
$ python pkgs_not_in_anitya.py pingou * point of contact R-ALL Monitor=False Anitya=False R-AnnotationDbi Monitor=False Anitya=False ... guake Monitor=True Anitya=True igraph Monitor=False Anitya=False jdependency Monitor=True Anitya=True libdivecomputer Monitor=True Anitya=True metamorphose2 Monitor=False Anitya=False packagedb-cli Monitor=False Anitya=False ... * co-maintained R-qtl Monitor=False Anitya=False fedora-review Monitor=True Anitya=True geany Monitor=True Anitya=True geany-plugins Monitor=True Anitya=True homebank Monitor=True Anitya=True libfprint Monitor=True Anitya=True ...
If you are interested, feel free to use the script
Tuesday, December 30 2014
By Pierre-Yves on Tuesday, December 30 2014, 10:18 - Général
I use the private mode of firefox quite often, for example when I want to test an application while being authenticated in one windown and not authenticated in another window.
I also use this mode when I want to browse some commercial websites that I know do a lot of tracking (hey there amazon!).
Finally, my firefox always have few windows and a bunch of tabs open and when traveling quite often I want to open firefox quickly to check something but I do not want to have it coming with all its windows and tabs.
Until now, I used either different browser or midori that allows starting it directly in private mode in these situations.
So this morning I took myself by the hand and looked closer at fixing my system for my use-case:
The recipe turned out to be pretty simple:
1/ Get the firefox.desktop file:
cp /usr/share/applications/firefox.desktop ~/firefox-private.desktop
2/ Adjust it as follow:
-Name=Firefox +Name=Firefox (private browsing) [...] -Exec=firefox %u +Exec=firefox -private-window %u
3/ Install the new desktop file:
/usr/share/applications/ for every users on the system
sudo cp ~/firefox-private.desktop /usr/share/applications/
~/.local/share/applications/ for your user only
With this trick, you can now start firefox in private browsing mode directly from the menu.
Wednesday, October 15 2014
By Pierre-Yves on Wednesday, October 15 2014, 09:39 - Général
The package database pkgdb2 is the place where is managed the permission on the git repositories.
In simple words, it is the place managing the "who is allowed to do what on which package".
For each package, when they are created, the summary, the description and the upstream URL from the spec file are added to the database, which allow us to display the information on the page concerning the package. However, until two weeks ago, this information was never updated. That means that if you had an old package whose description had changed over time, pkgdb would present the one from the time the package was created in the database.
Nowadays, we have a script running on a weekly basis and updating the database. Currently, this script relies on the information provided by yum's metadata on the rawhide repo. This means that packages that are only present in EPEL or that are retired on rawhide but present in F21, will not have their information updated. This is likely something we will fix in the future though.
In the mean-time, you can now enjoy a pkgdb with summary and description information for almost all packages!
As an example, checkout the fedocal page, you can now see a link to the upstream website, a short summary and a little longer description of the project.
Also, to give you a little hint on the amount of updates we did:
The first time we ran the script:
16638 packages checked 15723 packages updated
Last week's run:
16690 packages checked 50 packages updated
Tuesday, December 10 2013
By Pierre-Yves on Tuesday, December 10 2013, 12:30 - Général
Fooling around with RDFa and some projects
Tuesday, May 22 2012
By Pierre-Yves on Tuesday, May 22 2012, 15:20 - Général
A bit of fooling around with the pyRdfa library
Friday, August 19 2011
By Pierre-Yves on Friday, August 19 2011, 13:52 - Général
A small example on basic parallel programming in python
By Pierre-Yves on Friday, August 19 2011, 13:47 - Général
Un petit exemple basique de programmation parrallèle avec python
Sunday, April 25 2010
By Pierre-Yves on Sunday, April 25 2010, 20:07 - Général
How to configure your trackpoint to emulate mouse wheel on Fedora 13
Comment configurer le troisième bouton de votre trackpoint pour émuler la roulette de la souris sous Fedora 13
Friday, September 11 2009
By Pierre-Yves on Friday, September 11 2009, 00:17 - Général
Configurer un trackpoint pour remplacer la molette de la souris
Configure a trackpoint to emulate a mouse wheel
Thursday, August 14 2008
By Pierre-Yves on Thursday, August 14 2008, 14:03 - Général
Presentation of the French Community Documentation on Fedora
Présentation de la documentation Fedora en français -- (pas de version française de cet article).