Tradução Livre do Artigo disponível em (http://ostatic.com/blog/one-package-manager-for-them-all)


Desenvolvedores da RedHat, Fedora, Debina, Ubuntu, OpenSUsE, Mandriva e Mageia reuniram-se num escritório da SUsE em Nürnberg para discutir como implementar esse instalador universal referindo-se a uma AppStore.

A ideia de um formato de pacotes para todas as distribuições linux não é nenhuma novidade. Um dos maiores exemplos é a idéia dos arquivos FatELF de Ryan C. Gordon. Foram várias as reações em contrátio. Contudo um time formado por representantes de várias as distribuições mais tradicionais pensam em implementar "uma API e infraestrutura comum de instalação de aplicações". Esta é uma resposta à crença de que os usuários finais não estão preocupados como bibliotecas, dependências, compatibilidade e outros detalhes técnicos. Eles pensam que usuários somente se interessam por screenshots, descrições básicas, avaliações etc. A ideia é definir como uma ferramenta pode encontrar e instalar aplicações.

A ideia de Ryan "icculus" Gordon para criar arquivos de pacotes de software precisava que módulos de kernel, dependências, bibliotecas e softwares fossem todos incluídos é um grande pacote.

Ryan "icculus" Gordon's idea was to package software archives so that needed kernel modules, dependencies, libraries, and software files were all included in one larger package. Sua ideia era fornecer todas as arquiteturas para todas as distribuições. Ele explica "ele adiciona algumas informações de contabilidade no início do arquivo e depois inclui os binários ELF. FatELF permite incluir os binários em um único arquivo separados por OS ABI, versão do OS ABI, ordem de byte, tamanho da palavra, e o mais importante, arquitetura da CPU". Uma das principais ideias é que os pacotes de software devem ser bem semelhantes, da mesma forma que os instaladores de software Windows. Não demorou muito para a oposição suspender o projeto.

Mas a ideia está sendo retomada, de forma bem diferente. AppStream se baseia no Projeto Bretzn, que produz os pacotes para as várias arquiteturas e distribuições após o desenvolvedor enviar o código, publicar o pacote e enviar os anúncios de lançamento.



A equipe do AppStream considera o Ubuntu Software Center a interface ideal para o projeto e planeja migrá-lo para o PackageKit. Pensam em usar os servidores do Xapian para fornecer as buscas e o Open Collaboration Services para permitir as avaliações e revisões dos usuários. Metadados serão armazenados em servidores com as informações do pacote, localização de ícones, tipo e local do repositório entre outros. Um servidor extrai as informações do pacote de um arquivo .desktop (que as distribuições suportadas deverão fornecer para cada pacote) e a saída de todas as informações para um arquivo XML. A interface do AppStream será um Front-End para o PackageKit, que irá instruir o gerenciador de pacote da distribuição usada a instalar o pacote solicitado.





A diferença entre o FatELF e o AppStream é que o primeiro inclui todos os arquivos necessários para o pacote universal, enquanto que o segundo compila somente os metadados necessários para popular o instalador universal. Ele pode ser o principal ou único gerente gráfico de pacotes da maioria das distribuições, se desejar substituir (ou somado a), por exemplo, Synaptic ou RpmDrake da Mandriva


A meta principal é possuir uma experiência única de software para Linux como um todo, ou nas palavras da equipe da AppStream "para instalar e remover software no Linux".

Most of the important stuff has been already said, so without much ado, let me share some pictures from LibreOffice release party we threw yesterday at 12 a.m. sharp in Prague Novell office.

Prague hacker crowd waiting for the fun to start:


Ready to rock!


Kendy waving the LibreOffice flag:


... and the final baptism of this baby of ours:

Many thanks to everyone who participated! Another round of thanks to Kobliha for photodocumentation. No animals were harmed and no hackers got drunk while producing those pics.

On behalf of Jean-Baptiste Lallement:

We are pleased to announce the new development release of Mago.

This release has seen a lot of changes and improvements to make Linux
automated desktop testing easier and enable more people to contribute
writing tests and aiming to high quality desktop applications.

Key features included in this version:
- Separation between the framework and the tests
- Support for standard gnome dialogs and authentication
- Easy configuration of the tests with configuration files
- Support for the latest version of LDTP
- Direct interaction with Window Manager via XLib
- Image matching testing with XPresser
- Easy and flexible collect and run with Nose
- Testtools to extend python unittest
- The documentation now uses Sphinx
- Magomatic to generate application map

You want to contribute to the effort?
You can download the source from bazaar at https://launchpad.net/mago

The testsuite is available from lp:~mago-contributors/mago/mago-testsuite

Note that this version is not compatible with the previous version of
mago which is still available from lp:~mago-contributors/mago/mago-1.0

Mailing List:
http://mail.gnome.org/mailman/listinfo/desktop-testing-list

IRC:
#ubuntu-testing in irc.freenode.org
#gnome-testing in irc.gnome.org


Thanks to all the people who contributed fixes, features and lot of tests.

I’m happy to announce that LibreOffice 3.3 rc4 packages are available for openSUSE in the Build Service LibreOffice:Unstable project. They are based on the libreoffice-3.3.0.4 release. Please, look for more details about the openSUSE LibreOffice build on the wiki page.

The packages are based on LibreOffice release candidate sources. Though, they include some addons from the old Go-oo project.  They have not passed full QA round yet and might include even serious bugs. Therefore they are not intended for data-critical usage. A good practice is to archive any important data before an use, …

As usual, we kindly ask any interested beta testers to try the package and report bugs against the product LibreOffice .

Known bugs

• some packages were not renamed, .e.g. OpenOffice_org-thesaurus, …; they are not built from the main LibO sources; I will do soon.
• SLED10 build is not available; need more love

More known bugs

• Free Desktop bugzilla
• Novell bugzilla

Other information and plans:

First, I am sorry that I did not announce two older builds. I published rc2 build just before Christmas and the announce was forgot in the hurry. There were problems with building rc3. It was ready only one day before rc4, so it did not make sense to announce it.

There still might be some openSUSE-specific bugs that would need to be fixed. I hope that they do not break the base function but… I will continue with producing newer builds with more fixes from the stable libreoffice-3-3 branch. I will move the packages to a stable project once we finish testing of all the SUSE-specific addons. It should happen within the next few weeks.

Please be patient and thanks for understanding.

As many know, I have a few Android devices, and I know a lot of other openSUSE fans out there also have robot powered devices. I decided the other day to try something during my lunch break – create a widget to show how many days left till 11.4′s release. Yeah I know it isn’t an earth shattering application, but I’m not a code monkey, so any working code I generate is a serious plus for me ;-)

The German company rh-tec offers free IPv6 internet connections for people that already have T-DSL. Configuring such a connection on openSUSE 11.3 is not as straight forward as with IPv4. It’s not hard either if you know where to put the settings though.

1. start the yast2 DSL module
2. follow the instructions of the wizard to set up a new PPPoE device. Enter your user name and password at the provider screen.
3. At the “Connection Parameters” screen uncheck “Automatically Retrieve DNS”. Enter an arbitrary IPv4 address as first DNS server (yast doesn’t accept IPv6 there yet, bug 665516).
4. finish the wizard and leave yast
5. open /etc/sysconfig/network/providers/provider0 (or whatever name was chosen by yast) in an editor
6. change DNS1 and DNS2 to the actual IPv6 addresses of your provider’s name servers
7. add the following line to the file:
   PPPD_OPTIONS="noip +ipv6 ipv6cp-accept-local"
8. save and quit
9. Done! You may now use cinternet or qinternet to dial in and enjoy the (rather empty) IPv6 internet.

En el principio de los tiempos, las sesiones de administración remota por vnc creaban una sesión gráfica nueva y no era posible controlar, por ejemplo, la sesión de usuario que actualmente estaba abierta. Hoy los tiempos han cambiado y ya es posible realizarlo en unos muy sencillos pasos:

1. Instalar el servidor de administración remota. Vamos a la administración de paquetes de YaST y en el campo de búsqueda ponemos: x11vnc. Seleccionamos ese paquete y le damos a instalar (aceptamos sus dependencias si es que las hay).

2. Habilitar el servidor para la administración remota. En openSUSE es muy fácil, basta con ir a YaST->Servicios de Red->Administración Remota. Marcamos la opción "Permitir administración remota" y chequeamos en "Puerto abierto en el cortafuegos". Al aceptar se instalarán los paquetes necesarios.

3. Opcionalmente y si fuera necesario abriremos el puerto 5900 de nuestro computador: YaST->Seguridad y Usuarios->Cortafuegos.  Seleccionamos "Servicios autorizados" y luego "Opciones Avanzadas". En la ventana agregamos el puerto TCP 5900.

4. Ya casi estamos listos. Ejecutamos el servidor de vnc en un terminal y como usuario normal de la siguiente forma:

 x11vnc -usepw

Eso nos pedirá el ingreso de una clave para el control de acceso; ponemos la clave que queramos y la volvemos a ingresar.

5. Ahora podemos probar desde otro computador en la red local. Por ejemplo si la máquina que queremos controlar tiene la IP 192.168.0.40 presionamos Alt+F2 y ponemos el siguiente comando (o en una terminal):

vncviewer 192.168.0.40

Al dar enter nos pedirá la clave que ingresamos en el otro equipo y ya deberíamos estar controlando nuestro computador.

6. Al cerrar la sesión de VNC no podremos volver a conectarnos a nuestro equipo a menos que nuevamente ejecutemos el comando x11vnc... para evitar esto y habilitar la administración remota permanentemente haremos lo siguiente en KDE: Preferencias del Sistema->Autoarranque->Añadir programa.  En el campo de texto ingresaremos:

x11vnc -usepw -forever -bg

Aceptamos y ya hemos terminado. Ahora podemos controlar nuestra sesión activa de KDE desde cualquier otro computador.

No, I’m not talking about this board – I’m talking about the cool project by GNOME afficianado Lucas Rocha – The Board. There is a little gotcha with the packages – it is for openSUSE Factory/11.4 only at the moment. I need to work on backporting some of the shiny dependencies to 11.3. Things aren’t 100%, as I need to do a tiny bit of cleaning up with the packages, but it works pretty well for a 0.