Fedora user group

Fedora Summer Coding continues

Fedora Project and JBoss.org were not accepted by Google as an umbrella mentoring organization for their Summer of Code this year.  We’ve been involved since the beginning with many successes. This year we decided to embrace the umbrella organization that Google stitched together from separate JBoss.org and Fedora Project applications a few years ago and made a strong joint application.  My team at Red Hat has included our summer coding efforts along with very successful programs such as POSSE in our education work.

You may feel disappointed we didn’t get in, I am, but this is hardly the end of our efforts.  Read on to learn more.

1. Fedora Summer Coding is already working with RIT and Olin, which gives our mentors some students to potentially work with.  For more information read here.
2. Red Hat cares deeply about involving students in our free software/open source work. We are going to fund a pool of students who work on Fedora or JBoss.org related projects this summer.  Read here for more information.  (That section is under construction, we did not expect to fill this need this year, and I’ve asked Max Spevack to figure it out and we’ll let you all know soon.)
3. If you are a student who was looking to do your Summer of Code project idea in Fedora or JBoss.org, we’d like to help you find the best place to apply instead.  It may be a different organization that is mentoring for Google Summer of Code, or it may be through Fedora Summer Coding.  Reach us through our communication channels.
4. If you are a mentor and/or a sub-project who wants to work with students, even beyond code such as documentation or marketing, join the Summer Coding SIG mailing list.  That’s where we work out exactly what is going on and when.
5. If you are interested in being a sponsoring organization or individual, read up on what we are doing with the summer coding model and how you might help.

If you care about any of this, be at the next Summer Coding SIG meeting on Wednesday 24 March at 1500 UTC in #fedora-meeting (you can use Freenode’s webchat interface.)  If you are a student, a mentor, a sub-project, or any project member, you are invited.  We are going to talk in more detail about our plans for this year, make some decisions, and get on with another great summer.

Eclipse Linux Tools 0.5.0 Release

The Eclipse Linux Tools team is proud to announce our 0.5.0 release. This
release is compatible with the Galileo releases of the Eclipse SDK (version
3.5.x) and CDT (version 6.0.x). It is available now from our update site:

http://download.eclipse.org/technology/linuxtools/update

Installation instructions are available. 70 bugs were closed as part of this release including bug fixes and new features. Highlights include:

• tools for the analysis and visualization of LTTng traces
  
• GCov integration
  
• a Dashboard perspective for visualising system activities
  
• many improvements to the scripts to build the Eclipse SDK for Linux distributions, now supporting Eclipse SDK version 3.5.2
• callgraphs of multi-threaded programs are now supported

The full list of highlights can be see on our new and noteworthy page. That page also contains a list of community contributions to our 0.5 release from the following excellent individuals: Niels Thykier, Benjamin Drung, and Jens Seidel. Thanks to all for their hard work and contributions. As usual, we very much appreciate feedback, be it bugs, on IRC (Freenode #eclipse-linux), or on our mailing list.

Committers participating in this release include:

• William Bourque
• Francois Chouinard
• Roland Grunberg
• Anithra P Janakiraman
• Jeff Johnston
• Alexander Kurtakov
• Andrew Overholt
• Xavier Raynaud
• Alvaro Sanchez-Leon
• Charley Wang

Thanks to everyone and looking forward to 0.6 which will be a part of the Helios release train.

Astronomy
I’ve recently started to tag along to my local Astronomical Society, Beds Astro http://bedsastro.org.uk . The Piazzi Smyth observatory at Bedford School is amazing – A powerful Meade LX200 that is computer-controlled gives some amazing pictures that are just amazing. Here is one that the BAS Chairman, Dave Eagle, Took: Now, that is something that I would [...]

xdg-user-dirs-gtk related ‘bug’

The other day I was playing around my Fedora 12 box to check some widget alignments and came across this interesting ‘bug’ related to the updation of the default directories in the user’s home. The directories ‘Desktop’, ‘Downloads’, ‘Templates’, ‘Public’, ‘Documents’, ‘Music’ and ‘Pictures’ are automatically present in the user’s home directory and these names can be translated in the xdg-user-dirs module. If the xdg-user-dirs-gtk module is installed, everytime a user logs into a new language interface from the gdm a dialog is presented prompting the user if she would like to rename these directories to the translated version. If she chooses to rename, then after logging in she would get these folders in the language she chose for the current session. Next time, when the same or another user chooses a different language while logging into another session, the prompt reappears and the user can again choose to rename the folders into their choice of language for the session. Rinse repeat.

The catch here is that the translation of these folders have to be present for this dialog prompt to be displayed. In the earlier example, if there were no translations of these folders in user2’s choice of language, the dialog prompt would not have been displayed. This would result in user2 being stuck with (in all probability) incomprehensible folder names from user1’s session. The solution here is to revert back to the more conventionally accepted standard English names. The process of reverting involves, logging out from the session and logging into the English session, choose to rename the folders into English from the displayed dialog prompt and then logging back again into a session with the preferred choice of language.

A probable solution to avoid this situation, is perhaps to display the dialog prompt for languages that do not have translations, with an option to rename them back to English. The other probable solution can be, to automatically rename them to English if there are no translations. The latter is the standard procedure for untranslated portions of UI messages.

This is particularly important for languages that are written in non-latin scripts like the CJKI languages. Since the folders are actually moved, writing their names would become difficult from the console. On the other hand, if they choose to not translate then renaming them back to English would require an user to go through the hoops mentioned earlier.

Since blog is not a bug, so one exists here (would have helped around if I had the skills). I hope I am not missing any existing solutions that are already present for this issue. Thoughts?

CHM en Linux
Los archivos CHM (Microsoft Compiled HTML Help) es un formato propietario (obvio, no?) desarrollador por Microsoft. Fue introducido con Microsoft Windows 98, y es (lamentablemente) aún usado y distribuido en las plataformas actuales de dicha compañía. Lo habitual es encontrar la Ayuda de los productos de software en este formato, ahora bien, de un tiempo acá CHM ha empezado a ser utilizado para la creación de libros electrónicos (e-books) (Shame on You!)

Si tienes suerte, mucha, podrás visualizar el contenido del CHM desde tu navegador en Linux, en la mayoría de los casos deberás recurrir a alguna artimaña para visualizarlo.

En Linux, aún?, no existe soporte nativo para los archivos CHM, sin embargo con un par de simples pasos podrás transformarlos a formato PDF y de ahí en adelante es un chiste!

El utilitario que hace toda la magia es chm2pdf. Para instalarlo basta con un


yum -y install chm2pdf


Una vez instalado lo usas así


chm2pdf (--book / --webpage) [optiones (muchas!)] archivo_entrada [archivo_salida]


Ya sea '--book' or '--webpage' DEBE ser dado! --book le indica que el CHM es algo estructurado, con caítulos y esas cosas. Al contrario --webpage indica contenido "libre"

chm2pdf soporta la mayoría de las opciones de htmldoc, si quieres complicarte la vida puedes revisar las, numerosas, opciones con


chm2pdf --help


Si no indicaste el archivo_salida al invocar a chm2pdf tendrás un archivo que se llama igual a tu CHM, pero ahora con extensión PDF