Uma vez fiz um deploy de um projeto no Apache. Não gostei. Provavelmente foi por causa das inúmeras opções de configuração do Apache (leia-se "eu não tenho paciência e nem tempo p/ descobrir p/ que serve aquele mundo de módulos e diretivas e ainda combinar com wsgi"). Algum tempo depois, numa conversa de IM, alguém cantou a bola do NGinx depois de eu comentar sobre o Cherokee. Agora resolvi

I’m blatantly abusing GSoC for a project that I would like to see in openSUSE but that I’ve never had time to work on. But really it’s a worthwhile thing to have: a set of Plasma widgets that users and developers can add to their workspace to make it easy to see what’s going on in OBS in the projects that matter to them. If you want to work on a fun project with cutting edge technologies such as Qt, QML, Plasma then head on over to the GSoC 2011 Ideas Page.

I really look for the perfect gsoc student: someone who has a brilliant idea, noone else thought of how to improve linux in general or openSUSE in specific and just needs my guidance.

But for those that need some ideas, my best bet is really to rewrite clicfs to make it even better. Right now clicfs is a FUSE filesystem hosting a loop image. So a page read goes from ext4->loop->fuse->clicfs->CD->clicfs->fuse->loop->ext4.
If it lived in the kernel, it could offer a block device you mount your ext4 on, leaving aside loop and fuse:


modprobe clicfs packfile=/read-only/openSUSE-kde.i586 cowfile=/read-write/.COWfile cowlog=/dev/ttyS0
mount /dev/clicfs/0 /mnt
chroot /mnt /bin/init


Great idea, no? For someone who wants to become famous, it would be the perfect target!

OSC is a powerful tool for packaging experts, exposing all the latest and greats features of the Build Service. It’s written on python and easy in studying and using. However there are situations when its functionality is not enough; sometimes we need something special. In this case to us will help plug-in mechanism, which in osc is realised very simply.
Plugin can use all of the features, which already implemented osc, as well as provide an output in a convenient format for you. For example, if I want to check changes in kdelibs4 between openSUSE:11.3 and openSUSE:11.4, I can do something like this:

> osc rdiff openSUSE:11.3 kdelibs4 openSUSE:Factory kdelibs4

After that I will receive a detailed output about all changes. Yes, that’s great… but not always it’s convenient. For example, in this case output will contain more than 2000 strings, and I need time to find, say, a *.changes file if I want quickly to understand that has been changed. In case if I want to transfer output to processing to another program (as often happens in practice), I have to shape this data. Unfortunately osc is not as intelligent and can’t show changes from one file (from *.changes, for example) only…

Hello world

Let’s me show how we can create a very simple osc-plugin. In the derectory /var/lib/osc-plugins/ we create a new file tell_me_something.py with such content:

@cmdln.alias('say')
def do_say_something(self, subcmd, opts, *args):
    if sys.argv[2] == "something":
        print "openSUSE rulezzz"
    else:
        print sys.argv[2]

At start, osc will check this directory and will register all found there plugins. In that case, if in the plugin’s content there are errors, osc will report about it immediately. If now we run

> osc help

we will see in the list our function say_something and the key to start it – say. Let’s test:

> osc say "hello"
hello
> osc say GNU/Linux
GNU/Linux
> osc say something
openSUSE rulezzz
>

As you can see, it’s very easy – just python and nothing else. Let’s go back to the output of the function rdiff(), which we mentioned at the beginning.

show me changes

In output of rdiff() nothing wrong, but I would like to immediately get information about what exactly has been done and, for example, which bugzilla-reports (related to this package) have been closed, etc. All what I need, are in rdiff’s output. It means that all what I have to do is just to shape this output.

In 40 minutes of hacking I got such output:

> osc changes kdelibs4 openSUSE:11.3 openSUSE:11.4
PACKAGE: kdelibs4
BUGZILLA_NOVELL: 668185, 670426, 644236, 596021
BUGZILLA_OTHER: 246652, 170806, 149991, 221989, 252280, 253387, 253294, 193364, 253414
CHANGES:

- work around random error on first startup, bnc#668185,
  kubuntu has a similiar patch applied
- call update-mime-database in pre/post install scripts
- don't show synthetic volume label when none is really available,
  allow kio_sysinfo to fall back to device path (bnc#670426)
- update to KDE Platform 4.6.0
  * Plasma applets can be written in QML
  * Plasma data engines can be written in Javascript
  * Plasma data engines can use generic cache for offline mode
  * udev, udisks, upower replace HAL in Solid
  * For more details, see http://kde.org/announcements/4.6
- add patch from 4.6 branch to fix plasma crash on exit
- Add dependencies on udisks and upower for 11.3 and up for Solid
- update to 4.5.95
  * KDE 4.6 RC2
  * no upstream changelog available.
- update to 4.5.90
  * KDE 4.6 RC1
  * no upstream changelog available.
- For 11.2 and 11.3 only : Will build now with polkit-qt-1
  v 0.99.1, which is an official requirement of KDE 4.6
- update to 4.5.85
  * KDE 4.6 Beta2
  * Final Beta before RC, various fixes from Beta1
  * no upstream changelog available.
- For 11.2 and 11.3 only : Added patch to revert changes that
  requires a higher version of polkit-qt-1
- update to 4.5.80
  * KDE 4.6 Beta1
  * no upstream changelog available.
-  Closing the shell via CTRL+D crashes [bko#246652]
- fix build with gcc 4.6
- tighten qt4 dependencies
- update to 4.5.3
  * see http://kde.org/announcements/changelogs/changelog4_5_2to4_5_3.php for details
- update branch diff for various bugs in 4.5:
  * Crash on configure toolbars (bko#170806)
  * KCookieJar can't read cookies from another port (bko#149991)
  * Fix oversized number input widgets (bko#221989)
  * CSS conformance issue (bko#252280)
  * Fix helper protocols such as mailto: and telnet:
  * Plasma crash on comic applet switch (bko#253387)
  * HTTPS urls in KMail do not open properly in browser (bko#253294)
  * Mailto: links in FireFox started by kmailservice fail (bnc#644236)
  * Crash in directory listings when toggling
    show hidden files flag (bko#193364)
- Upstream patch added for kmail issue (bko#253414)
- update to 4.5.2
  * see http://kde.org/announcements/changelogs/changelog4_5_1to4_5_2.php for details
- build apidocs separately to reduce build time
- BuildRequire utempter-devel
- update to 4.5.1
  * see http://kde.org/announcements/changelogs/changelog4_5_0to4_5_1.php for details
- new package: kdelibs4-apidocs (bnc#596021)
- update to 4.5.0
  * KDE 4.5.0 final (version bump over RC3)
- update to 4.4.95
  * KDE 4.5 RC3 (not announced)
  * critical fixes for 4.5.0 release
- Add libsoprano-devel Require to libkde4-devel
- update to 4.4.93svn1149349
- update to 4.4.5
  * bugfixes over 4.4.4
  * see http://kde.org/announcements/changelogs/changelog4_4_4to4_4_5.php for details

and between 11.4 and factory:

> osc changes kdelibs4 openSUSE:11.4 openSUSE:Factory
PACKAGE: kdelibs4
CHANGES:

- update to 4.6.1
  * Bugfixes over KDE 4.6.0
  *  see http://kde.org/announcements/changelogs/changelog4_6_0to4_6_1.php for details
- remove upstreamed patches

aha… and what’s about vim between 11.2 and 11.3?

> osc changes vim openSUSE:11.2 openSUSE:11.3
PACKAGE: vim
BUGZILLA_NOVELL: 598903
CHANGES:

- Add screen control sequences to inputrc (bnc#598903)
- Use the icon from the tarball instead of our custom icon. It
  looks much better.
- Drop gvim.png from the source package.
- build data subpackage as noarch
- updated patches to apply with fuzz=0

Now we can see exactly what was has been done and which bugzilla-reports was fixed/closed. Yes, we have bnc# and bko# reports: reports from bugzilla.novell.com and bugs.kde.org (it cut be also bugs.kernel.org). Second group will be always different (KDE/Gnome/Mozilla/Kernel…).

Source code of plugin is here, and I hope this post will be useful for you if you’ve never written a plugin before.

I like to suggest a general policy for openSUSE:Factory project to document from where a tar ball (or any other file from upstream) is comming from. Why that ? It makes it much easier to review version updates and it guarantees that no one can inject some mal code via a modifed tar ball.

So far I added the source services “download_url” and “tar_scm” to our OBS instance, which downloads the files and stores them as files via a commit. Some people use them already, some others don’t like them because they store the files with _service: prefix.

In last hackweek, I added another way to handle this, which I would like to request as setup and policy for openSUSE:Factory project. You can add a project wide source service, for example the new “download_files” service. That would mean that no needs to add a _service file to the sources anymore. It is enough to add an URL to the spec file Source: tags. The service will automatically download it from there.

But that does mean we still have have _service:download_files:osc-0.1.tar.bz2 file names ? Not when we also add the new “trylocal” parameter and use latest osc versions. This parameter will let act osc to execute the services, but name the files without prefix and commit them together with the other files.

Where is the advantage then ? The server is still validating that this is an identical file. It downloads it again and compares it. In case it is the same file, nothing will happen.

What will happen, when the file differes ? We basically have two options, either we can let the service mark the source as broken or we would store the file with _service: prefix again.

The later mode has the advantage that you can still do version upgrades via slow connections and let the server download the files.

Please find some more details about new possibilities with the source services here.

An example setup for this can be tested via

osc bco home:adrianSuSE:FactoryTest bc

and do for example a version downgrade to 1.05 version to see how it works. Please note that you need the osc from openSUSE:Tools:Unstable project for this.

We can also apply the still suse-internal spec formater and validator scripts via this way later one.

Another advantage of this setup would be the new “update_source” service, which could run in some openSUSE:Factory:AutoUpdate project and tries automatic version upgrades when upstream releases a new version. They could be reviewed and just picked (directly or with additional manual fixes).

As always, another week, another release, aka 0.1.1

This week release is a polish release :

• very few package changes
• many services are disabled when booting live CD, improving its loading speed
• password is no longer asked at all in live CD for root or standard (tux) user
• when installing the image on a system (add liveinstall parameter on bootloader), some services are enabled back (apparmor, preload, firewall), thanks to Chris comments

Another service announcement :
my GNOME3 openSUSE 11.3 repository will soon be removed ; packages will be only available for openSUSE 11.4 (same OBS project). Therefore, I strongly suggest to upgrading your system to openSUSE 11.4.

You know the url to fetch the latest release :  http://gnome3.org/tryit.html

Enjoy !

Software Livre, segundo a definição criada pela Free Software Foundation é qualquer programa de computador que pode ser usado, copiado, estudado e redistribuído sem restrições. O conceito de livre se opõe ao conceito de software restritivo (software proprietário), mas não ao software que é vendido almejando lucro (software comercial). A maneira usual de distribuição de software livre é anexar a este uma licença de software livre, e tornar o código fonte do programa disponível.


Fonte e mais informações: http://pt.wikipedia.org/wiki/Software_livre



Principais Softwares Livres:



- Linux


O Linux é um Software Livre.

Linux é o termo geralmente usado para designar qualquer sistema operativo ^{(português europeu)} ou sistema operacional ^{(português brasileiro)} que utilize o núcleo Linux. Foi desenvolvido pelo finlandês Linus Torvalds, inspirado no sistema Minix. O seu código fonte está disponível sob licença GPL para qualquer pessoa que utilizar, estudar, modificar e distribuir de acordo com os termos da licença.


Fonte e mais informações: http://pt.wikipedia.org/wiki/Linux





Distribuição Linux:

Uma Distribuição Linux (ou simplesmente distro) é composta do núcleo Linux e um conjunto variável de software, dependendo de seus propósitos. Essa coleção de software livre e não-livre, é criada e mantida por indivíduos, grupos e organizações de todo o mundo, incluindo o grupo Linux.


Fonte e mais informações: http://pt.wikipedia.org/wiki/Distribui%C3%A7%C3%B5es_Linux






Principais Distribuições livres:



openSUSE Linux


Gentoo Linux


Slackware Linux


Debian Linux


Ubuntu Linux


Mandriva Linux


Distribuições Derivadas:



São as que derivaram das principais:




Parted Magic (Slackware)



Resulinux Linux (Debian)



linuxacessivel.org





- Principais Programas livres:

GIMP

Hi,
today I must solve issue with not well structured code. Problem is that one method return last correct version, but in one specific case it needs to return newest version (even incorrect). There is many calls between top level method which know what needs to call and target method which is called from generic code. Now I need to fix it and code is not well tested and quite sensitive to changes ( this fix is fix of another fix :). So what is the safest way to change it?
I decide that the best solution which doesn’t change almost nothing ( but is suitable just for maintenance update, for trunk I create better solution ) is temporary overwrite of target method to change its behavior. Now how to do it?
There is simple example:

class T
  def test
    puts "test"
  end

  def lest
    puts "lest"
  end

  def m
    test
  end
end


T.new.m
T.send(:define_method,:m_a) { lest }
T.send(:alias_method, :m_old, :m)
T.send(:alias_method, :m, :m_a)
T.new.m
T.send(:alias_method, :m, :m_old)
T.send(:undef_method, :m_a)
T.send(:undef_method, :m_old)
T.new.m

as you can see after modification class is exact same as before ( except if there is method a, but it is possible to handle it via introspection and dynamic choose of method). I don’t need to change whole stack of calls to add parameter or introduce new singleton class which can have flag.
I hope it help someone with his fix of not so well written piece of software.

Following my last blog post on “how to name the distribution release“, I’ve opened up a public survey and look forward to your votes. There is also a good discussion going on on the opensuse-project mailing list.

This is the first iteration. Coolo and myself discussed to use a second survey with the group of winners on connect.opensuse.org.

We are planning a community release party this coming Thursday, March 17, 2011 to celebrate the 11.4 release.  We are planning on having some media and usb thumb drives for anyone that would like to install 11.4.

This time we are changing the location a little.  We are still having the party on Novell’s Provo campus, but in one of the executive briefing rooms building H which is the tall south most building.

Everyone is welcome.  If you are planning on coming please let us know by sending me an email sshaw ]at[ decriptor ]dot[ com.  We are hoping to have food and swag to give away.

Details:

March 17, 2011

6:30 to 8:00 pm

Executive Briefing Center, Building H

Novell Provo Campus

 

Here is the poster we threw together.  The artwork was provided by someone in the community and the poster was put together by my awesome wife.