Mageia é um fork do Mandriva Linux, apoiada por uma organização sem fins lucrativos reconhecida e colaboradores eleitos. Mais do que apenas oferecer um sistema operacional livre, seguro, estável e sustentável, o objetivo é a criação de uma administração estável e confiável para orientar projetos colaborativos.

Este blog é alimentado pela comunidade aqui na rede SoftwareLivre.org e pelo feed do Planet Mageia English.

Mageia Blog (English) : The Long and Winding Road

12 de Novembro de 2014, por Desconhecido - 0sem comentários ainda

Well, it’s been a long road, longer than we anticipated, but we’re almost there! Mageia 5 Beta 1 is now validated!
What exactly does that mean? What took so long (a month and a half longer than originally planned)?

RPM 4.12 versus the Mageia buildsystem, a retrospective

The short explanation: Some stuff went wrong and other things got broken.

The long one: Back in September, we decided to update our package manager, RPM, to its latest upstream version 4.12. This was done shortly before our planned mass rebuild, a necessary step before the Beta where we rebuild all packages in the distribution to make sure that they are still compatible with the current state of our development stack. Usually, mass rebuilds show that a fair number of packages do not build anymore even if they did some months ago: the packagers’ task is then to patch them so that they can build against the new stack, or in some cases to patch the development tools to fix regressions.

But this time, the new RPM version introduced changes that were significant enough to break a lot of core packages during the mass rebuild, and lots of packages failed to build in a chain reaction. It took a couple of weeks to fix and we were already long past the planned deadline for Mageia 5 Beta 1 (originally scheduled for the end of September). So we decided to postpone it to mid October.

Still, while fixing our core tools during this first mass rebuild, some important changes were made to our RPM setup. As a consequence, half of the rebuilt packages (the ones built before our RPM setup changes) were lacking some important metadata. We then decided to do a second mass rebuild in October, which went quite fine apart from some issues with the Java stack. It was already late October when the first Beta 1 ISOs could be spun and delivered to the QA team for pre-release testing.

You may know that a Linux distribution release is basically an installer together with a set of packages. The latter were now starting to behave properly, but we were then faced with some issues in the installer regarding glibc (the GNU C library) and RPM. This delayed the beta for another week or so.

Then the QA team could finally get started with a fresh set of ISOs, and found the usual numbers of critical bugs (system doesn’t boot, stuff like that) that were fixed with the help of our developers. A big thanks to the QA team for their continued work on the ISOs while also testing update candidates for Mageia 3 and Mageia 4! This beta is far from perfect so don’t forget to check the errata, but you should be able to install it and to see the state of current cauldron. Please report any bugs, we will try to fix as many as we can for Mageia 5 Beta 2.

Consequence on the development roadmap

According to our original schedule, the second beta should have been released on October 31st… So we had to choose between skipping Beta 2 or postponing the Mageia 5 final release and the intermediate releases. Based on the input from the Beta 1 testing, we decided that we can’t afford to skip the second beta, since the current one still has some serious issues. As a consequence all planned dates for the future intermediate and finale releases have been postponed, and the new development roadmap reads as follows:

  • Beta 2: December 16th, 2014
  • Release Candidate: January 6th, 2015
  • Internal release: January 23rd, 2015
  • Final release: January 31st, 2015

Fine… Now, where is my Beta 1?

You all waited long enough for this release, so grab it with the first link, but don’t forget to check the following ones:

Test, enjoy, and report any bugs! Now is the time to polish this Mageia 5!



Mageia Blog (English) : Halloween the curse or buggy software?

14 de Outubro de 2014, por Desconhecido - 0sem comentários ainda

As explained in a previous post, lots of updates occured especially dealing with rpm. And here we go. We are facing at the moment some nasty issues in installer. The graphical part of the installer is just crashing due to a bug implying glibc and rpm. Both were recently updated.

Work is in progress and the issue was reported upstream. You can follow it here on the bug report. As soon as this bug is fixed, we will be able to release the Mageia 5 beta 1 isos. Stay tuned!



Juan Luis Baptiste : Official mageia docker images available

6 de Outubro de 2014, por Desconhecido - 0sem comentários ainda

We now have official docker images for mageia !!

After some weeks working with the docker team we managed to get mageia as an official docker image (the ones that have the blue whale icon). You can find them at the docker hub, and if you want to contribute to them you can go to mageia's docker brew project.

There are three images available:

  • Mageia 3
  • Mageia 4 (latest)
  • cauldron

Currently the cauldron image is outdated (probably more than a month), but I plan to automate the docker image update process so we can have an updated version at least once a week.


How to use these images


You can pull them on the command line (as root):

          # docker pull mageia:latest
          Pulling repository mageia
          147b6e8a8cbd: Download complete 
          511136ea3c5a: Download complete 
          e65cc271e617: Download complete 
          
          # docker start -ti --name mymageia_4 mageia:latest


Or create a Dockerfile file to build your own custom mageia-based image:
FROM mageia:4
MAINTAINER  "Foo Bar" 
CMD [ "bash" ]
Installed packages

All mageia docker images install the following packages:
  • basesystem-minimal
  • urpmi
  • locales
  • locales-en

Please test these images, and if you find any issues or have suggestions don't forget to report them here. Also I'm thinking of adding some other custom images for specific applications and uses, like:


Ready to run server application-oriented containers


We could have several application oriented containers: mariaDB, nginx, wordpress, Apache+php/{cakephp,zend,codeigniter}, Apache+python/{django,codegears,flask}, tomcat preconfigured to use an apache container as front end, etc, the possibilities are endless. All these containers could be linked, packaged and orchestrated using fig for an easier application control and management.

Another example could be FPS game servers (Urban Terror,  OpenArena, Warsow, World of Padman, Smokin' Guns), with their server package, some license-redistributable maps, a web admin panel, mumblebigbrotherbot (already working on a package) and anything else needed to have a kinda of "one click" game server setup. This could be very useful for example, to quickly launch game servers at a LAN party, or to provision game servers at a game hosting company.

Docker for distribution development


At the very least I see a couple of uses for docker within mageia development. First, as a quick and easy way to use iurt for local package building. We could have a custom docker image for package development that comes with a preconfigured iurt binary, package build tools like bm, rpmbuild, rpmlint, mgarepo, etc, all preinstalled, this could be a build/packaging environment with one command:

          # docker pull mageia:devenv
          Pulling image...
          # docker run --rm -ti --name mageia_dev -v /home/juancho/iurt:/opt/iurt/ mageia:devenv iurt SRPMS/foo-1.0-1mga5.src.rpm

That command would launch a docker container using our custom development image, launch iurt to build a source package, leave the binary packages in /home/juancho/iurt/RPMS/{i586,x86_64,noarch} and delete it self when it finishes. This is a clean way to locally build packages in a fresh environment. Remove the --rm parameter if you want to use the container later, for example to work on package version updates:

          # docker run -ti --name mageia_dev -v /home/juancho/.ssh:/home/juancho/.ssh -v /home/juancho/iurt:/opt/iurt/ mageia:devenv bash
         
Also by mapping your .ssh directory to a docker volume, mgarepo can be used within the container.

The other important use for docker within mageia could be to help with QA testing. The reproducible nature of docker makes it very interesting from a QA point of view, the repeatability of tests could be of great help for application testing and bug triaging.

We could teach bug reporters how to create their own images or write their own Dockerfiles with the needed packages and configuration changes to reproduce a bug. The reporter would point QA back to an image that they can download and test (for example, from our own docker repository). The creation of those containers could ease and speed the testing process. As these custom images would be based on our official images, there wouldn't be the need for QA to setup the same test case to reproduce the bug in another environment, the reporter image should be enough for them to test and validate it. In some way, we could be making the bug reporters also contribute the test case.

Docker application containers


What about preconfigured docker containers for software development environments, like images that have Netbeans/Eclipse for python/java/php, git/mercurial/svn/bazaar, any development libs and tools needed depending on the platform, etc, all preinstalled and preconfigured. This could be a good idea as sometimes these tools are difficult to install and update, having these ready to use containers could be cool. Probably it also could be used to package nonfree applications or 32bits applications on x86_64.

I don't know, there are many ideas that come to my mind about stuff that can be done with docker in different areas, like these ones on linux distribution development and such.





Liberdade na Fronteira : Cantor: new features in KDE 4.14

1 de Outubro de 2014, por Desconhecido - 0sem comentários ainda

KDE 4.14 was released in August 2014 but I did not have time to write about new features in Cantor for that release.

So, let’s fix it now!

New backend: Lua

Cantor family of backends have a new member: Lua, using luajit implementation.

This backend have a lot of features: syntax highlighting, tab complete, figures in worksheet, script editor, and more.

Cantor + Lua in action

Lua backend was developed by Lucas Negri, a Brazilian guy, and this is a reason for me to be very happy. Welcome aboard Lucas!

You can read more about this backend in a text of Lucas blog.

Use utf8 on LaTeX entries

When you to export the worksheet to LaTeX, utf8 will be used as default. This improvement was developed by Lucas.

Support to packaging extension in Sage and Octave backends

Now these backends have an assistant to import packages/modules/libraries.

Support to auto run scripts

python2_autorun

Auto run scripts/commands in Python 2 backend

Now Python 2, Scilab, Octave, Sage, Maxima, Qalculate, and KAlgebra backends have support to auto run scripts. You can configure a set of scripts or commands and they will run automatically after the worksheet launch!

Add CTRL+Space as alternative default code completion to worksheet

Default code completion command in worksheet is TAB key, but now we have an alternative command too: CTRL + Space. It will maintain consistence between script editor (where the default code completion is CTRL + Space) and worksheet.

Initial support to linear algebra and plot assistants in Python 2

I developed the initial support to 2 amazing plugins in Python 2 backend: the linear algebra plugin and the plot plugin.

First, let’s see the linear algebra plugin. In menu bar go to Linear Algebra > Create Matrix. A window to matrix creation will be open, as below. You must to put the values in the cells.

python3_linearalgebraMatrix creation assistant

After push ‘Ok’ button, the matrix command from numpy  module will be loaded in the worksheet, automatically.

python2_linearalgebra_resultNew matrix created

For now this plugin have implemented just the matrix creation.

Let’s see the plot plugin now. You can use it to create 2D and 3D plot. Let’s to do x = numpy.arange(0.0, 2.0, 0.01) and, in menu bar, go to Graphics > Graphics 2D. The window below will be open.

python2_graphicPloting 2D assistant

You can set some expression to be the Y axis (in this case I am using numpy.sin) and a variable name to X axis (this case, 2 * x * numpy.pi). You could to put just x in variable name to do a plot with the values of x.

After push ‘Ok’ button, the command using pylab will be load in worksheet to make the graphic.

python2_graphic_result3D plotting assistant have a similar way to create the pictures.

How you can see, to use this assistants we need to have some python modules in the workspace, and they must to have the same name used in the plugins. There are a lot of ways to import modules in python environment (import foo; import foo as [anyname]; from foo import *; etc), so to do a generic way to use it is impossible (well, if you have some idea I would like to hear it).

My choice was to import numpy, scipy, matplotlib and pylab when Python 2 backend is loaded by Cantor. Well, I intent to change it because that modules will be mandatory to use Python 2 backend correctly, and pylab is not longer recommended in recent matplotlib version. So, wait for some changes in this plugin soon.

In any case, I would like to hear the opinions of scientific python community about this features.

Future

For now we are working in Cantor port to Qt5/KF5. You can follow the work in ‘frameworks‘ branch on Cantor repository.

Donations

If you use or appreciate my work in Cantor or another free software project, please consider to make a donation for me, then I can to continue my contributions to improve Cantor.

You can consider make a donation to KDE too, and help with the maintenance of this great free software community and their products.



Mageia Blog (English) : Time time time, see what’s become of me?

29 de Setembro de 2014, por Desconhecido - 0sem comentários ainda

As you may or may not know, we are scheduled to release the first beta for Mageia 5 on September 30th. Well… it looks like we’re not going to make it.

Here at Mageia HQ, we try to provide a balance between tried-and-tested software and cutting edge developments. That means that we try to ship Mageia releases with the newest software that we are comfortable using. We take into account all sorts of things, from stability to security and passing through usability on the way.

The practical upshot is that we are planning to release Mageia 5 with the new version of RPM 4.12. RPM is Mageia’s package manager, that we share with other major distros such as Fedora and OpenSuSE. This new version brings in a lot of interesting features, so we decided to include it in Mageia as soon as it was released, so that we can fine tune our usage of it before Mageia 5′s release. The new version was included just before the mass rebuild, an important phase of the release cycle where we rebuild all packages of Mageia 5 to make sure they compile properly against the new development stack.

Technobabble aside, the RPM version update is a good thing. It makes it easier for the packagers to find common errors and fix them, thus allowing for more reliability of our packages. That means that more time can be devoted to adding more packages for you, the user.

The problem is, well… the new RPM version broke some stuff. Not much, just a few packages needed to be rebuilt. Something like 7000 packages (now down to about 2000).
But have no fear! Our development and packagers teams are on it! They just need a little more time. So we are postponing the Mageia 5 Beta 1 release by two weeks. That means October 14th.

Let’s recap: we try to make the best Linux distribution that we can, and sometimes things don’t go according to plan. But we are flexible enough to handle it! So if you were counting down the days to Mageia 5 Beta 1, just move your clock back by 14 days.

And, as always, we welcome volunteers. So if you want to help, have a look here and start contributing today!