Ir para o conteúdo
ou

Software livre Brasil

Minha rede

 Voltar a planetas
Tela cheia Sugerir um artigo
 Feed RSS

Planeta DebianBrasil.org

11 de Fevereiro de 2010, 0:00 , por Software Livre Brasil - | Ninguém está seguindo este artigo ainda.

Francisco Aparecido da Silva: Lançado o Debian 7.0 "Wheezy"

5 de Setembro de 2016, 19:30, por Planeta Debian Brasil - 0sem comentários ainda

Debian
Obrigado Projeto Debian por mais um lançamento tão esperado como o Wheezy; Para nós que mantemos nossos próprios sistema operacionais em computadores pessoais e em servidores, é uma satisfação muito grande contar com um projeto tão envolvido com qualidade, segurança e liberdade para seus usuários;

Vamos continuar incansávelmente divulgando o projeto para outras pessoas, não somente como alternativa de um sistema operacional, mas como o melhor Sistema Operacional Universal.


Notas de lançamento:
http://www.debian.org/News/2013/20130504
http://www.debian.org/News/2013/20130504.pt.html
http://bits.debian.org/



Manoel Aleksandre Filho: O Wheezy está entre nós.

4 de Setembro de 2016, 23:14, por Planeta Debian Brasil - 0sem comentários ainda


Finalmente saiu o tão esperado lançamento do ano! Debian 7.0, Wheezy foi liberado para stable às 22h30 min desta noite (4 de maio) - pelo menos aqui no Brasil, já dia 5 de maio pelo horário UTC.

Com relação ao Squeeze, muitas são as novidades e novos recursos. Muitos desses novos recursos do Debian 7.0 são itens que vieram para outras distribuições Linux há muito tempo, mas esse é simplesmente o ritmo em que Debian prefere jogar.

Para aqueles que ainda não estão a par sobre a atualização desta grande distribuição Linux, aqui vai uma lista de alguns dos principais recursos. 

  •  EXT4 agora é o sistema de arquivos padrão! O instalador do Debian GNU/Linux agora finalmente está fazendo uso do EXT4 por padrão para novas instalações; anteriormente o padrão era o EXT3. Obviamente, você ainda pode configurar as opções do sistema de arquivos manualmente a partir do instalador do Debian. Anos depois de todas as outras distribuições terem migrado para o EXT4, finalmente o Debian GNU/Linux está fazendo a migração. 
  • Systemd está disponível no Debian como uma opção. SysVinit ainda é o padrão, mas basta um "apt-get install systemd" para mudarmos para o systemd no Debian GNU/Linux. 
  • As  Opções de desktop incluem GNOME 3.4, KDE 4.8, e Xfce 4.8. Debian GNU/kFreeBSD e Debian GNU/Hurd estão usando o ambiente de trabalho Xfce por padrão. 
  • O fork do projeto libav media está substituindo o ffmpeg.
  • OpenStack e Xen Cloud Platform são novas opções de servidor para o servidor Debian. 
  • Debian GNU/Linux agora tem o kernel real-time (RT) kernel com a opção de instalar o linux-image-rt-amd64 ou pacotes do kernel linux-image-rt-686-pae. 
  • O Instalador Debian agora oferece suporte a UEFI para instalações em hardware x86_64. O Instalador Debian também tem suporte wireless WPA/WPA2. 
 Mais novidades para o Debian 7.0 "Wheezy" podem ser vistos na página de notícias do Debian.

Para download das imagens, acesse:

DVD i386 CD i386
DVD amd64  CD amd64




Manoel Aleksandre Filho: Usando endereço único para os repositórios Debian

4 de Setembro de 2016, 11:53, por Planeta Debian Brasil - 0sem comentários ainda


Para um usuário Linux a escolha dos repositórios para obtenção e manutenção do software que será instalado em seu sistema operacional é um assunto muito importante. Sendo o precursor dos sistemas de empacotamento e gerenciamento de software no Linux, o Debian sempre tem lançado tendências para os demais.

Como os desenvolvedores Debian trabalham simultaneamente com diferentes versões de seu sistema, o oferecimento de repositórios distintos a cada versão é uma prática comum. Oferece-se espelhos de seus repositórios por todos os continentes, e duplicação dos mesmos por vários países. 

Hoje Debian está sendo servido, via http, por cerca de 370 espelhos em todo o mundo, e também está disponível, via ftp, a partir de 330 espelhos. São ao todo 76 países que nos servem com espelhos por todo o mundo. Isso só foi possível graças aos sponsors hosting the mirrors. Somos muitíssimo gratos por todos esses patrocinadores, tantos os atuais como os do passado.

O arquivo /etc/apt/sources.list é o responsável por informar ao gerenciador de pacotes os repositórios que serão utilizados pela distribuição. Essa pode não ser uma tarefa muito fácil para um novato. Mesmo para os "macacos velhos" do Debian, faz-se necessário recorrer a repositórios que estejam mais ágeis para aquele período. Foi com essa intenção que Raphael Geissert disponibilizou o redirecionador de mirros. Esse serviço pretende "resolver o problema da escolha de um espelho Debian, entre outras questões. O redirecionador usa a localização geográfica e a rede do usuário e os espelhos, a arquitetura dos arquivos solicitados, a família de endereços IP, a disponibilidade e a atualização dos espelhos, entre algumas outras coisas. Ele é constantemente melhorado. O resultado: ele seleciona o melhor espelho que pode servir a arquivo".

Isso facilitará bastante na hora de você construir sua sources.list. à até uma boa para quem vai atualizar do Squeeze para o Wheezy, ou mesmo instalar o Wheezy do zero. 

Como usar o redirecionador

Para utilizar o redirecionador, basta substituir as fontes de pacotes configuradas no seu sources.list com o endereço http://http.debian.net/debian. Você pode usá-lo como se fosse um espelho primário Debian: binários, fontes, estável, teste, experimental, etc, são todos suportados. 

Se sua sources.list, por exemplo, está com a seguinte fonte:

deb http://ftp.br.debian.org/debian/ stable main 
deb-src http://ftp.br.debian.org/debian/ stable main

Deixe-a assim:

deb http://http.debian.net/debian stable main
deb-src http://http.debian.net/debian stable main

Para os backports, seria:

http://http.debian.net/debian-backports

E para o Archived releases (archive.debian.org):

http://http.debian.net/debian-archive

Como, provavelmente, você agora instalará o Wheezy, pode deixá-lo com uma única linha mesmo:

deb http://http.debian.net/debian wheezy main

Já durante o processo de instalação do Wheezy, você também pode optar por usá-lo, inserindo manualmente http.debian.net como um espelho HTTP e /debian/ como o caminho.



Antonio Terceiro (terceiro): testing build reprodubility with debrepro

3 de Setembro de 2016, 16:58, por Planeta Debian Brasil - 0sem comentários ainda

Earlier today I was handling a reproducibility bug and decided I had to try a reproducibility test by myself. I tried reprotest, but I was being hit by a disorderfs issue and I was not sure whether the problem was with reprotest or not (at this point I cannot reproduce that anymore).

So I decided to hack a simple script to that, and it works. I even included it in devscripts after writing a manpage. Of course reprotest is more complete, extensible, and supports arbitrary virtualization backends for doing the more dangerous/destructive variations (such as changing the hostname and other things that require root) but for quick tests debrepro does the job.

Usage examples:


$ debrepro                                 # builds current directory
$ debrepro /path/to/sourcepackage          # builds package there
$ gbp-buildpackage --git-builder=debrepro  # can be used with vcs wrappers as well

debrepro will do two builds with a few variations between them, including $USER, $PATH, timezone, locale, umask, current time, and will even build under disorderfs if available. Build path variation is also performed because by definition the builds are done in different directories. If diffoscope is installed, it will be used for deep comparison of non-matching binaries.

If you are interested and don’t want to build devscripts from source or wait for the next release, you can just grab the script, save it as “debrepro” somewhere on your $PATH and make it executable.



João Eriberto Mota Filho: Debian: GnuPG 2, chroot and debsign

19 de Agosto de 2016, 1:38, por Planeta Debian Brasil - 0sem comentários ainda

Since GPG 2 was set as default for Debian (Sid, August 2016), an error message appeared inside jails triggered by chroot, when using debuild/debsign commands:

clearsign failed: Inappropriate ioctl for device

The problem is that GPG 2 uses a dialog window to ask for a passphrase. This dialog window needs a tty (from /dev/pts/ directory). To solve the problem, you can use the following command (inside the jail):

# mount devpts -t devpts /dev/pts

Alternatively, you can add to /etc/fstab file in jail:

devpts /dev/pts devpts defaults 0 0

and use the command:

# mount /dev/pts

Enjoy!



Antonio Terceiro (terceiro): Adopting pristine-tar

22 de Maio de 2016, 14:02, por Planeta Debian Brasil - 0sem comentários ainda

As of yesterday, I am the new maintainer of pristine-tar. As it is the case for most of Joey Hess’ creations, it is an extremely useful tool, and used in a very large number of Debian packages which are maintained in git.

My first upload was most of a terrain recognition nature: I did some housekeeping tasks, such as making the build idempotent and making sure all binaries are built with security hardening flags, and wrote a few automated test cases to serve as build-time and run-time regression test suite. No functional changes have been made.

As Joey explained when he orphaned it, there are a few technical challenges involved in making sure pristine-tar stays useful in the future. Although I did read some of the code, I am not particularly familiar with the internals yet, and will be more than happy to get co-maintainers. If you are interested, please get in touch. The source git repository is right there.



Antonio Terceiro (terceiro): DebConf15, testing debian packages, and packaging the free software web

30 de Abril de 2016, 19:12, por Planeta Debian Brasil - 0sem comentários ainda

This is my August update, and by the far the coolest thing in it is Debconf.

Debconf15

I don’t get tired of saying it is the best conference I ever attended. First it’s a mix of meeting both new people and old friends, having the chance to chat with people whose work you admire but never had a chance to meet before. Second, it’s always quality time: an informal environment, interesting and constructive presentations and discussions.

This year the venue was again very nice. Another thing that was very nice was having so many kids and families. This was no coincidence, since this was the first DebConf in which there was organized childcare. As the community gets older, this a very good way of keeping those who start having kids from being alienated from the community. Of course, not being a parent yet I have no idea how actually hard is to bring small kids to a conference like DebConf. ;-)

I presented two talks:

  • Tutorial: Functional Testing of Debian packages, where I introduced the basic concepts of DEP-8/autopkgtest, and went over several examples from my packages giving tips and tricks on how to write functional tests for Debian packages.
  • Packaging the Free Software Web for the end user, where I presented the motivation for, and the current state of shak, a project I am working on to make it trivial for end users to install server side applications in Debian. I spent quite some hacking time during DebConf finishing a prototype of the shak web interface, which was demonstrated live in the talk (of course, as usual with live demos, not everything worked :-)).

There was also the now traditional Ruby BoF, where discussed the state and future of the Ruby ecosystem in Debian; and an in promptu Ruby packaging workshop where we introduced the basics of packaging in general, and Ruby packaging specifically.

Besides shak, I was able to hack on a few cool things during DebConf:

  • debci has been updated with a first version of the code to produce britney hints files that block packages that fail their tests from migrating to testing. There are some issues to be sorted out together with the release team to make sure we don’t block packages unecessarily, e.g. we don’t want to block packages that never passed their test suite — most the test suite, and not the package, is broken.
  • while hacking I ended up updating jquery to the newest version in the 1.x series, and in fact adopting it I guess. This allowed me to drop the embedded jquery copy I used to have in the shak repository, and since then I was able to improve the build to produce an output that is identical, except for a build timestamp inside a comment and a few empty lines, to the one produced by upstream, without using grunt (.

Miscellaneous updates



Antonio Terceiro (terceiro): Debian Ruby Sprint 2016 - day 1

29 de Abril de 2016, 20:44, por Planeta Debian Brasil - 0sem comentários ainda

This year’s Debian Ruby team sprint started today here at Curitiba. Everyone arrived fine, and we started working at the meeting room we have booked for the week at Curitiba campus of the Federal Technical University of Paraná. The room is at the “Department of Business and Community Relations”, what makes a lot of sense! :-)

The day started with a quick setup, with a simple 8-port switch, and a couple of power strips. It tooks us a few minutes to figure what was blocked or not on the corporate network, and almost everyone who needs connections that are usually blocked in such environments already had their VPN setups so we were able to get started right after that.

We are taking notes live on mozilla’s piblic etherpad site

Today we accomplished quite a lot:

  • analyzed the pending issues for the ruby2.3 transition issues, categorizing the missing packages into “needs a binNMU now”, “needs a binNMU after switching the default to ruby2.3”, and “broken”.
  • ruby-defaults uploaded to experimental switching to ruby2.3 as default, and dropping support for ruby2.2
  • ruby-gsl fixed to build against GSL 2.x (was blocking ruby2.3 transition)
  • #816253: ruby-fast-gettext: fix FTBFS issue and import a new upstream
  • ruby-aws: several issues fixed
  • ruby-binding-of-caller: fixed rubygems-integration
  • fixed ruby-kakasi-ffi (again)
  • made ruby-blockenspiel arch:any again
  • ruby-fast-gettext 1.0.0-1 (fix ftbfs 816253)
  • ruby-aws-sdk: new upstream, debcheck fix and several bumps
  • ruby-fcgi – dropped transitional packages + refreshed packaging with -w
  • ruby-sshkit 1.8.0
  • ruby-beautify: new upstream and few minor fixes
  • asciidoctor (new version sponsored)
  • capistrano 3.4.0 (ftbfs #795724, #802734)
  • #816254: ruby-packetfu: FTBFS: expected NameError with “uninitialized constant PacketFu::FakePacket”, got #
  • updated rake to 10.5.0; making it not include -I/usr/lib/ruby/vendor_ruby when running tests
  • triaged an closed open bugs on ruby-httpclient that do not apply anymore.
  • updated ruby-httpclient to get rid of warnings in apt-listbugs under Ruby 2.3
  • ruby-packetfu (fix ftbfs #816254) by @kanashiro
  • investigated extension/rdepends build failing with ruby2.3-only
  • applied upstream patch to ruby to fix extension ftbfs when extension uses c++
  • ruby-albino 1.3.3-4 (#813644)
  • basic user-level testing using ruby2.3 as default:
    • chef WORKS mostly; it seems ohai segfaults some times
    • rails autopkgtest FIXED Could not find gem ‘binding_of_caller (>= 0.7.2)’, which is required by gem ‘web-console (~> 2.0)’, in any of the sources.
    • vagrant WORKS
    • redmine autopkgtest WORKS
    • apt-listbugs FIXED warnings (e.g. try `apt-listbugs list $pkg`); caused by ruby-httpclient
    • nanoc WORKS
  • capistrano 3.4.0-1 (#795724, #802734) by @sbadia + @terceiro


Gustavo Noronha Silva (kov): Entenda o systemd vs upstart

15 de Abril de 2016, 1:29, por Planeta Debian Brasil - 0sem comentários ainda

Originalmente publicado no PoliGNU.

Por quê mudar?

Recentemente o projeto Debian passou por um intenso debate para decidir que sistema de inicialização deveria substituir o venerável (porém antiquado) system v como padrão do sistema para a próxima release, codename jessie.
A razão para mudar pode não parecer óbvia, especialmente para os muito apegados à ideia de “UNIX” ou que simplesmente estão acostumados a como as coisas funcionam hoje, mas fica clara quando se analisa os principais problemas enfrentados por sistemas que ainda usam sistemas de init system v. Pra começo de conversa, o init não conhece muitas das novidades tecnológicas que apareceram nas últimas décadas.
Peguemos como exemplo o controle de hardware: um daemon que precise ser iniciado quando um determinado tipo de hardware é plugado não será executado automaticamente pelo init se for plugado, o que exige que além de ter lógica para tratar o caso no boot, também se tenha que ter outros mecanismos para reagir ao hot-plugging.
Ser um conjunto de scripts shell também causa uma infinidade de problemas. Como cada script deve reinventar a inicialização do daemon que controla, é bastante comum que eles não sejam 100% resilientes a problemas como deixar processos (principais ou filhos) para trás quando quem administra o servidor pede que o serviço seja parado. Isso acaba exigindo intervenção de quem administra, matando manualmente os processos.
O desempenho também é um problema que passou muito tempo sem solução. Com o aparecimento de computadores com múltiplas CPUs e com espera de rede se tornando um problema foi inventado um sistema de paralelizar a execução dos scripts de inicialização, o que trouxe consigo a enorme complexidade de ter que estabelecer dependências entre os scripts, para garantir que só sejam executados em paralelo scripts que possam sê-lo. Mas isso também é muito mais complexo do que parece – as dependências em sistemas modernos são muito mais sutis e variáveis do que pode parecer em primeira análise. Além disso, executar cada script desse gera um overhead não desprezível.
Por último, o diagnóstico de falhas de inicialização de serviços é absurdamente complexo; raramente se sabe em que arquivo de log estarão as mensagens relevantes e com alguma frequência sequer haverá logs da falha propriamente dita em algum lugar, restando a quem administra executar o serviço manualmente e ver o que acontece.
Para resolver alguns ou todos esses problemas vieram os novos sistemas de init. Na verdade o Mac OS X saiu na frente com o launchd, mas essa é história pra uma outra oportunidade, comecemos pelo upstart, que nasceu no Ubuntu há alguns anos atrás.

Upstart

O upstart surgiu quando a principal preocupação das pessoas estava em melhorar o desempenho do boot através de paralelismo. A ideia é substituir a necessidade de estabelecer dependência entre os serviços de forma declarativa e ao invés disso estabelecer condições para que um serviço esteja “pronto” para ser executado.
No sistema de dependências inventado para o system v começa pelo objetivo: preciso rodar rodar o procedimento que monta sistemas de arquivo remotos, pra isso preciso rodar as dependências dele que são montar os sistemas de arquivo locais e estabelecer conexão de rede. O upstart inverte essa lógica e começa dos procedimentos que tem nenhuma dependência, o que vai tornando outros procedimentos “prontos” e os executa a partir daí.
A ideia é que o sistema de init reage a eventos, que podem ser um serviço estar estabelecido mas também podem ser de outra natureza: um hardware ser plugado, por exemplo. Isso resolve o problema do desempenho, em certa medida e cria um framework que permite ao sistema de init continuar cuidando do sistema enquanto ele estiver ligado, iniciando e parando serviços conforme as condições do sistema mudam.
Há alguns poréns a respeito dessa estratégia, que quem tiver curiosidade achará com facilidade nos frequentes debates travados entre Lennart Poettering e os proponentes do upstart, mas eu queria chamar a atenção para um em particular: usando eventos não existe garantia de que um serviço esteja de fato em execução plena quando o seu procedimento de inicialização conhecido pelo upstart termina – anote isso mentalmente.
Finalmente, o upstart acaba não resolvendo os problemas de diagnóstico, nem de processos perdidos sendo deixados pelo sistema (embora uma solução que adota a ideia do systemd para isso esteja sendo criada), principalmente por as receitas de init usadas pelo upstart serem ainda scripts shell customizados.

Systemd

O systemd é criação de Lennart Poettering, que é funcionário da Red Hat e contribuidor do Fedora. Daí muita gente atribuir o systemd à Red Hat, no que se enganam: embora hoje a Red Hat tenha inúmeros projetos com o systemd no centro, a ideia original e o esforço original foram feitos por Lennart em seu próprio tempo e não como um projeto da empresa.
A motivação para sua criação é bem mais ambiciosa que a que originou o upstart: a ideia é que há inúmeras funcionalidades que o kernel Linux que são incríveis e extremamente avançadas e que acabam não sendo usadas a não ser em ambientes muito específicos, porque não há infra-estrutura comum no espaço de usuário para fazer uso da funcionalidade e disponibilizá-la para o resto do sistema.
Um exemplo: cgroups. Os Control Groups são formas de juntar processos em uma embalagem que permite tratar esse grupo de processos como um todo. Esses grupos podem ser usados por exemplo para limitar que partes do sistema os processos que o compõe podem ver, criando uma visão virtual mais limitada do sistema de arquivos, por exemplo, ou limitando as interfaces de rede que os processos podem ver. Também podem ser usados para tornar o agendamento de tempo das tarefas no processador mais adequado ao sistema, ou impor limites de uso de memória, de operações de I/O e assim por diante.
Uma das primeiras funcionalidades trazidas pelo systemd foi exatamente o uso de Control Groups. Cada serviço iniciado pelo systemd o é dentro de um cgroup próprio, o que significa por exemplo que todos os processos criados por aquele serviço podem ser – com certeza – terminados quando o serviço é parado. Também significa que apesar de seu apache estar consumindo muito CPU ou memória, seu servidor SSH ainda tem um naco suficiente do tempo de CPU para aceitar sua conexão que será usada para tratar do problema, já que o Linux tenta ser justo com os diferentes cgroups.
Além de tudo isso, o uso de cgroups ainda dá ao systemd a capacidade de garantir que não fiquem processos pra trás quando um serviço é parada: como processos criados por processos que foram colocados num control group também são colocados nesse control group, basta terminar todos os processos do control group para que não sobre nenhum. O pessoal do upstart pensou em adotar essa ideia.
Mas o systemd também atacou o problema do desempenho, de duas formas: a primeira foi a ideia de remover completamente scripts shell da jogada. Cada serviço é especificados num arquivo de configuração chamado “unit”, que descreve todas as informações que o init precisa para iniciar e cuidar do processo. Isso retira da equação a necessidade de iniciar um interpretador shell e de executar os complexos scripts usados atualmente com system v.
A segunda foi dando uma solução um pouco mais inusitada à questão das dependências. A ideia é simples: a maioria dos serviços abre sockets de algum tipo para receber pedidos de seus clientes. O X, por exemplo, cria um socket UNIX em forma de arquivo no /tmp. O que o systemd faz é criar todos os sockets dos serviços que controla (eles estão descritos nos arquivos unit) e, quando recebe uma conexão, inicia o serviço e passa pra ele o socket.
O interessante dessa solução é que ela 1) estabelece a relação de dependência na vida real: o serviço é iniciado quando alguém pede e 2) garante que os clientes que forem iniciados vão ter seu primeiro request atendido, não há mais o problema de não saber quando o serviço está plenamente ativo (lembra da nota mental no caso do upstart?).
Para completar, o systemd controla as saídas padrão e de erro dos serviços que inicia e pode facilmente mostrar as últimas linhas de log de um serviço quando sua execução falha, tornando muito simples o diagnóstico:
kov@melancia ~> systemctl status mariadb.service
mariadb.service - MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled)
Active: active (running) since Seg 2014-02-03 23:00:59 BRST; 1 weeks 3 days ago
Process: 6461 ExecStartPost=/usr/libexec/mariadb-wait-ready $MAINPID (code=exited, status=0/SUCCESS)
Process: 6431 ExecStartPre=/usr/libexec/mariadb-prepare-db-dir %n (code=exited, status=0/SUCCESS)
Main PID: 6460 (mysqld_safe)
CGroup: /system.slice/mariadb.service
        ├─6460 /bin/sh /usr/bin/mysqld_safe --basedir=/usr
        └─6650 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plug...
	Fev 03 23:00:57 melancia mysqld_safe[6460]: 140203 23:00:57 mysqld_safe Logging to /var/log/mariadb/mariadb.log.
	Fev 03 23:00:57 melancia mysqld_safe[6460]: 140203 23:00:57 mysqld_safe Starting mysqld daemon with databas...mysql
	Fev 03 23:00:59 melancia systemd[1]: Started MariaDB database server.
	Hint: Some lines were ellipsized, use -l to show in full.

A questão de licenciamento

De extrema importância quando falamos de Software Livre são a questão de licença e de copyright do código. O systemd é licenciado sob a LGPL versão 2.1 ou superior, o que permite que programas proprietários sejam linkados com suas bibliotecas. O copyright das contribuições feitas ao código é mantido pelos colaboradores. Um projeto de software livre bastante comum desse ponto de vista.
Já o Upstart, sendo criação da Canonical segue o que tem sido sua política há algum tempo: usa uma licença GPL (versão 2) e exige que contribuidores assinem um Contributor License Agreement compartilhando os direitos de copyright com a Canonical. Com isso, a Canonical fica sendo a única dona do copyright do conjunto e pode fazer por exemplo alterações de licença, ou lançar uma versão proprietária se entender que deve.
Em primeira análise isso não parece ser um problema: de fato, há várias licenças mais permissivas usadas por outros softwares, como as licenças BSD, que permitem às pessoas fecharem o código. A grande questão aqui é que com esse modelo não é qualquer pessoa que pode fazer isso, só a Canonical pode. Essa acaba sendo uma forma de desnivelar as oportunidades artificialmente, criando um monopólio do privilégio de lançar versões proprietárias.

Futuro

Atualmente dois sistemas importantes usam upstart: Ubuntu e Red Hat Enterprise Linux 6, que é a versão atual suportada da Red Hat. O systemd foi adotado inicialmente pelo Fedora, o que significa que a futura RHEL 7 também estará usando systemd. Algumas outras distribuições passaram a usar systemd ou como padrão ou como opção bem suportada, como o SuSE e o Arch Linux, por exemplo.
Com a adoção dele pelo Debian como padrão, todas as grandes distribuições base passarão a ser baseadas no systemd. Para surpresa de muitos (minha inclusive), Mark Shuttleworth anunciou que dada a decisão do projeto Debian, o Ubuntu também passaria a adotar systemd por padrão, aceitando graciosamente a derrota, em suas próprias palavras.
Com essa mudança é muito improvável que o upstart tenha um futuro depois de sua aposentadoria nas versões estáveis do RHEL e Ubuntu LTS, a menos que alguma outra distribuição se apresente para assumir sua manutenção.
Vida longa ao systemd!

 

Nota: ao tratar do CLA exigido pela Canonical o texto anteriormente usava a expressão “transferindo o copyright” , que dá a entender que o autor original da contribuição perdia os direitos, o que não é verdade e foi corrigido.



Antonio Terceiro (terceiro): Bits from the Debian Continuous Integration project

11 de Abril de 2016, 18:58, por Planeta Debian Brasil - 0sem comentários ainda

It’s been almost 2 years since the Debian Continuous Integration project has been launched, and it has proven to be a useful resource for the development of Debian.

I have previously made a an introductory post, and this this is an update on the latest developments.

Infrastructure upgrade

Back in early 2014 when Debian CI was launched, there were less than 200 source packages with declared test suite metadata, and using a single worker machine polling the archive for updates and running tests sequentially in an infinite loop (“the simplest thing that could possibly work”) was OK-ish.

Then our community started an incredible, slow and persistent effort to prepare source packages for automated testing, and we now have almost 5,000 of them. The original, over-simplistic design had to be replaced.

The effort of transforming debci in a distributed system was started by Martin Pitt, who did an huge amount of work. In the latest months I was able to complete that work, to a point where I am confident in letting it run (mostly) unatended. We also had lots of contributions to the web UI from Brandon Fairchild, who was a GSOC intern in 2014, and continues to contribute to this date.

All this work culminated in the migration from a single-worker model to a master/workers setup, currently with 10 worker nodes. On busy periods all of those worker nodes will go on for days with full utilization, but even then the turnaround between package upload and a test run is now a lot faster than it used to.

Debian members can inspect the resource usage on those systems, as well as the length of the processing queue, by browsing to the corresponding munin instance (requires authentication via a SSL client certificated issued by sso.debian.org).

The system is currenly being hosted on a Amazon EC2 account sponsored by Amazon.

The setup is fully automated and reproducible. It is not fully (or at all) documented yet, but those interested should feel free to get in touch on IRC (OFTC, #debci)

Testing backend changed from schroot to lxc

Together with the infrastructure updates, we also switched to using lxc instead of schroot as backend. Most test suites should not be affected by this, but the default lxc settings might cause some very specific issues in a few packages. See for example #806542 (“liblinux-prctl-perl: autopkgtest failures: seccomp, capbset”)

Adding support for KVM is also in the plans, and we will get to that at some point.

Learn more

If you want to learn more on how you can add tests for your package, a good first start is the debci online documentation (which is also available locally if you install `debci`).

You might also be interested in watching the live tutorial (WebM, 469 MB!) that has been presented at Debconf 15 earlier this year, full of tips and real examples from the archive. It would be awesome if someone wanted to transcribe that into a text tutorial ;-)

How to get involved

There are a few ways you can contribute:

autodep8. if you are knowledgeable on a subset of packages that are very similar and can have their tests executed in a similar way, such as “$Language libraries”, you might consider writing a test metadata generator so that each package does not need to declare a debian/tests/control file explicitly, requiring only The `Testsuite:` header in debian/control.

Ruby and Perl are already covered, and there is initial support for NodeJS. Adding support for new types of packages is very easy. See the source repository.

If you manage to add support for your favorite language, please get in touch so we can discuss whitelisting the relavant packages in ci.debian.net so that they will get their tests executed even before being uploaded with the proper `Testsuite:` control field.

autopkgtest. autopkgtest is responsible for actually running your tests, and you can use it to reproduce test runs locally.

debci. debci is the system running in ci.debian.net (version 1.0, currently in testing, is exactly what is running up there, minus a version number and a changelog entry).

It can also be used to have private clones of ci.debian.net, e.g. for derivatives or internal Debian-related development. See for example the Ubuntu autopkgtest site.

Getting in touch

For maintainer queries and general discussion:

  • mailing list: debian-qa@lists.debian.org
  • IRC: #debian-qa on OFTC. Feel free to highlight `terceiro`

For the development of debci/autopkgtest/autodep8

  • mailing list: autopkgtest-devel@lists.alioth.debian.org
  • IRC: #debci on OFTC


Tags deste artigo: debian planet planeta blogs