VC4 (Glendale) ISO Build Procedures

This document describes how to build a Vyatta VC4 (Glendale) ISO image. The most recent version of this document is the top-level README file of the “glendale” branch of the “build-iso” source tree.

Prerequisites

The Vyatta ISO build uses the “live-helper” tool that is available in several distributions. However, we recommend build hosts based on either Debian “lenny” or Ubuntu “hardy”. The “build-iso” source is maintained as a GIT super-module that references several submodules that each build one or more self named Debian packages. The submodule feature was added to GIT v1.5.2.

Build Host Setup

To set up a build environment (e.g., system or VM), we recommend installing Debian “lenny” (i.e. “testing”) with either business-card or net-install image,


http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/is…
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/is…


The respective installation prompts for distribution mirror. To include Vyatta’s Debian miror, add this to /etc/apt/sources.list,


deb http://packages.vyatta.com/debian/ lenny main
deb http://packages.vyatta.com/debian-security/ lenny/updates main


You also need to add the Vyatta buildtools repository to sources.list,

deb http://packages.vyatta.com/vyatta-dev/ buildtools main


To install the Vyatta repository GPG key,

$ wget -O vyatta-pubkey.gpg \
http://packages.vyatta.com/vyatta-dev/vyatta-pubkey.gpg
$ sudo apt-key add vyatta-pubkey.gpg


To build an ISO with all pre-built, binary packages, we’ll need to install some tools on the build host. Before doing that, however, we’ll have to tell apt-get to use older versions of some tools because the latest versions are incompatible with the current livecd build system. Add the following lines to the build host’s /etc/apt/preferences file:

Package: fakechroot
Pin: version 2.5*
Pin-Priority: 1001


Package: live-helper
Pin: version 1.0~a37-2
Pin-Priority: 1001


Next, install these tools on the build host using apt-get:

automake autoconf bzip2 curl debhelper devscripts dpatch fakeroot fakechroot genisoimage git-core sysv-rc-conf live-helper lsb-release rsync sudo


To build submodules, each package should list all build dependencies. However, to save some iteration, install these packages using apt-get:

bison flex docbook-utils gcc g++ git-buildpackage groff gs
gs-gpl imagemagick libncurses5-dev libpam0g-dev
libpcap0.8-dev libreadline-dev libsablot0-dev libtool lintian
manpages-dev tetex-bin texi2html texinfo transfig xmlto
zlib1g-dev libatm1-dev libdb-dev linuxdoc-tools git2cl
kernel-package lynx libcap-dev


Getting Source

The Vyatta ISO builder consists of scripts and config files maintained as a GIT super-module named, “build-iso” that references several submodules within its “pkgs/” sub-directory. To clone the super-module,

$ git-clone http://git.vyatta.com/build-iso.git


To create and checkout a working glendale branch,

$ cd build-iso
build-iso$ git branch --track glendale origin/glendale
build-iso$ git checkout glendale


If you don’t want to build any submodules and just want to build an ISO with all pre-built packages, you can skip the following submodule instructions and go to the next section “Configuration”.

To register the submodules in the cloned repository config,

build-iso$ git-submodule init


It’s most efficient to selectively clone only the submodules needing for review or modifcation. The ISO build downloads the Vyatta pre-built, binary packages of any non-cloned sub-module. To clone a specific sub-module,

build-iso$ git-submodule update pkgs/SUBMODULE


This command clones the SUBMODULE repository in the “pkgs/SUBMODULE” directory, and you need to create and checkout a glendale tracking branch,

build-iso$ cd pkgs/SUBMODULE
build-iso/pkgs/SUBMODULE$ git branch --track glendale origin/glendale
build-iso/pkgs/SUBMODULE$ git checkout glendale


To clone all sub-modules for full verification build,

build-iso$ git-submodule update


Remember to create and checkout a glendale tracking branch for each updated submodule.

Configuration

The Vyatta ISO builder has GNU autotool configuration,

build-iso$ autoreconf -i
build-iso$ ./configure


To see all configure options,

build-iso$ ./configure --help


Build ISO

To build an ISO,

build-iso$ PATH=/sbin:/usr/sbin:$PATH
build-iso$ make


The end results is the following livecd,

livecd/binary.iso


Clean

The Vyatta ISO builder has these standard automake targets to
clean files generated:

mostlyclean during ISO build (excludes package built files) clean during package builds along with ISO files distclean by autoreconf and configure plus all of the above


For example, to clean the ISO build files,

build-iso$ make mostlyclean


Build submodules

When you do a “make”, the build system will build the binary packages for all cloned submodules and include them in the ISO. If you want to work with specific submodules, you can use the commands listed below.

To build binary packages for cloned submodule(s),

build-iso$ tools/submod-mk { --all | SUBMODULE... }


To build binary and source packages for submodule(s),

build-iso$ tools/submod-mk --source { --all | SUBMODULE... }


To build signed binary and source packages for submodule(s),

build-iso$ tools/submod-mk --signed-source { --all | SUBMODULE... }


To clean files generated during submodule build,

build-iso$ tools/submod-clean SUBMODULE...


To clean files generated during all submodule builds,

build-iso# tools/submod-clean


To also clean the submodule build stage(s),

build-iso# tools/submod-clean -d [ SUBMODULE... ]


To clean the source tree of submodules to skip subsequent builds,

build-iso# tools/submod-clean -g [ SUBMODULE... ]


This retains the local bare git repository for quicker updates.

Changes

After making, testing, and commiting your changes to your local repos, publish them to the shared repos with,

build-iso/pkgs/SUBMODULE$ git-push suva.vyatta.com:/git/SUBMODULE.git


Then update and publish the super-module index to include the submodule(s) changes,

build-iso/pkgs/SUBMODULE$ cd ../..
build-iso$ git-update-index pkgs/SUBMODULE
build-iso$ git-commit -m 'update sub-module SUBMODULE'
build-iso$ git-push suva:/git/build-iso.git


Updates

Update the super-module with,

build-iso$ git-pull
or for the paranoid,
build-iso$ git-fetch origin
build-iso$ git-whatchanged HEAD..origin/glendale
build-iso$ git-merge origin/glendale


If new submodules were added, include these in the config,

build-iso$ git-submodule init


To see which checked-out submodules have upstream modifications,

build-iso$ git-status # search for changes in pkgs/


Get the “from” and “to” SHAs with,

build-iso$ git-diff pkgs/SUBMODULE


This will produce output something like,

diff --git a/pkgs/vyatta-cfg-quagga b/pkgs/vyatta-cfg-quagga
index 78124a9..fca1739 160000
--- a/pkgs/vyatta-cfg-quagga
+++ b/pkgs/vyatta-cfg-quagga
@@ -1 +1 @@
-Subproject commit 78124a9754efe0bda1d9c827c593c5e0635fec3c
+Subproject commit fca1739f1985c2ba8d6316b1882365f5e26245cd


To review what changed between these SHAs,

build-iso$ git --git-dir=pkgs/SUBMODULE/.git fetch
build-iso$ git --git-dir=pkgs/SUBMODULE/.git whatchanged FROM_SHA TO_SHA


To merge these submodule changes,

build-iso$ cd pkgs/SUBMODULE
build-iso/pkgs/SUBMODULE$ git checkout glendale
build-iso/pkgs/SUBMODULE$ git merge origin/glendale
build-iso/pkgs/SUBMODULE$ debuild -i -b -us -uc
build-iso/pkgs/SUBMODULE$ cd ../..


The “git-status” for pkgs/SUBMODULE should now be clean. Iterate through the other updated submodules, then rebuild the iso.

En definitiva, Microsoft cree que la comunidad de software libre le está robando las ideas y se está beneficiando de su propiedad intelectual. Además, considera que copia sus aplicaciones para después venderlas a un precio inferior.

¿Es esto una advertencia?

Fuente: TheInquirer.net

Hi,

We just edited our hint files, so that all packages now need human
review in order to go to testing. Hmm, that sounds too cryptic. Let's
try again:

  Lenny is now frozen! Wheeeeeee!!!

Thanks are due to everyone who has helped get us to this point.

For those maintainers whose packages were unprepared for a freeze at
this moment (the process has, after all, been a long one), you still
have one last opportunity to get things into shape if there are any
remaining important problems. Read on.

Now to explain what, exactly, we mean by "freeze".  The freeze
upload policy of uploading changes in through unstable if possible will
be continued to apply until the release.

All package versions that are at this moment already in unstable get
an automatic freeze exception (except those that are frozen for
reasons, of course).  This means that packages you've uploaded in the
past week will be able to go to testing (if they aren't hit by
other problems).

Now, so as not to have everyone contact us at once about packages we
know we won't approve, here are the guidelines for changes that will be
accepted into testing during the freeze:

  - fixes for release critical bugs (i.e., bugs of severity critical,
    grave, and serious) in all packages;

  - changes for release goals, if they are not invasive;

  - fixes for severity: important bugs in packages of priority: optional
    or extra, only when this can be done via unstable;

  - translation updates and

  - documentation fixes.

  - pre-approved fixes.

If you have such a change and want to update your package in Lenny, the
rules are as follows:

  - In all cases, when preparing an upload, please do not make changes to
    the package that are not related to fixing the bugs in question.
    Doing so makes it more time consuming for the release team to review
    and approve such requests, delaying the release.  It also delays the
    fix for your package, because you will be asked to reupload. Always
	document every change verbosely in the changelog.

  - If in doubt, first contact debian-release.

  - When contacting the release team, please explain why you are
    requesting an update.  Bug numbers are a must.  Attach the proposed
	(or uploaded patch.  The more we can figure out from your first email
	and your changelog (if any), the more quickly we can get your update
	in.

  - If your package needs to be updated for Lenny, and the version in
    unstable doesn't contain extraneous changes (e.g, the version is the
    same between testing and unstable), please upload your fix to
    unstable and contact debian-release@lists.debian.org.

  - If the version in unstable already includes significant changes not
    related to the bug to be fixed, contact debian-release about
    uploading to testing-proposed-updates.  Changed dependencies, new
    upstream versions, changed library names, and completely rewriting
    the packaging are "significant changes".  So are lots of other
    things.

  - If the version in unstable won't reach testing because of new
    library dependencies, contact debian-release about uploading to
    testing-proposed-updates.

  - If you have a package that needs a freeze exception, *please* don't
    forget to contact us.  *Don't expect us to find out about it on our
	own*.  Putting a comment in the changelog is not contacting the
	release team.  

  - If your package has been removed recently (i.e. in the last 20 days)
    due to an RC bug, and you have an bugfix-only update uploaded,
    you can contact the release team about letting your package back in.
    Same as above: Do not expect us to find it out ourself. You need to
    push that.

As always, it is the release team's goal to get as much good software
into Lenny as possible.  However, a freeze does not mean that your
package is ensured a spot in the release.  Please continue to stay on
top of release-critical bugs in packages that you maintain; RC bugs in
optional or extra packages that remain unfixed after a week will still
be grounds for removal from testing, just as they have been up to this
point.

Please also note that since many updates (hopefully, the vast majority)
will still be going in through unstable, major changes in unstable right
now can disrupt efforts to get RC bugs fixed.  We don't ask you not to
make changes in unstable, but we do ask that you be aware of the effects
your changes can have -- especially if you maintain a library. Please
continue to keep disruptive changes out of unstable, and continue making
use of experimental where appropriate.  Note once again that you can
stage NEW uploads in experimental to avoid disruption in unstable.

Also, in case you need release team's help to fix RC bugs (e.g. to remove
an old package), please feel free to contact us.

For packages which missed the freeze only for reasons outside of the
control of the maintainers, we might be generous, but you need to contact
us on your own, and you need to contact us soon.

What needs to happen before release
===================================
There is a short list of things that need to happen, though.

Fixing of release critical bugs
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For the release, we need to get rid of all release critical bugs. Please
don't hesitate, pick any bug from
http://bts.turmzimmer.net/details.php?bydist=lenny and fix it. Or send in a
patch in case there is none yet. And of course, follow our permanent BSP
policy for your NMUs. Uploading works as you are used to -- just remember to
send an e-mail to debian-release@lists.debian.org to get your fix through.

Security support
~~~~~~~~~~~~~~~~
Final preparations for security support will be done during the general
freeze, that is now. We hope being able to announce start of security
support soon, but obviously, it is a pre-condition for release.

Cheers,
Marc

Un sysadmin instala los routers, tira el cableado estructurado, configura la red, prepara los firewalls y guía el trafico de la red por cada uno de los saltos, atravesando cobre, fibra e incluso el aire para llevar internet a tu computador, todo para estar seguros de que esta pagina web sea visible por tu computador.

Un sysadmin se asegura que tu conexión de red es segura, abierta y funcionando, Un sysadmin se asegura que tu computador funcione de una sana manera en una red segura, Un sysadmin toma respaldos de toda la información para cuando rompas algo, no pierdas nada, se asegura de que las gateways estén seguras para evitar la intromisión de crackers y otro tipo de plasta informática, y sin importar cuantos miles de copias se envíen a la impresora desde el departamento de contabilidad, esta sigue imprimiendo sin problemas.

Un sysadmin se preocupa del spam, virus, spyware y codigos dañinos, pero tambien de los cores de luz, de los incendios y de las inundaciones.

Cuando el servidor de correos se cae a las 2 AM del domingo, Tu sysadmin mas cercano se levantara e ira a trabajar!

Un sysadmin es un profesional, quien planea, se preocupa, hackea, repara, parcha, soluciona, protege y crea exelentes redes de computadores, todo para llevar la data a ti y ayudarte a cumplir tu trabajo - para llevar el potencial de los computadores aun mas seca de la realidad.

Así que si puedes leer esto, GRACIAS SYSADMIN — y siempre ten en cuenta que el o ella hacen posible de que el trabajo llegue a nuestras casillas de correo desde el otro lado del mundo, de que tengamos mensajería instantánea, de las llamadas telefónicas gratuitas a nuestros amigos en Australia, DE ESTA PAGINA WEB!

Demuestrales tu Aprecio

Viernes, 25 de Julio del 2008 ( o el Ultimo Viernes de Julio ), System Adminitrator Apprecioation Day. En este dia internacional tan especia, dale a tu Administrador de sistemas algo que le demuestre cuanto realmente lo aprecias por su duro trabajo y dedicacion.

Porque enfrentemos lo, los Administradores de Sistema no tienen respeto por los 365 días del año. Este es el día donde todos los Administradores de Sistemas alrededor del mundo, serán mimados con Lujosos autos deportivos, montañas de dinero ( en efectivo por favor ), en demostración de todo lo que apreciamos su diligente labor y trabajo duro. Ahora en serio, solo pedimos un pequeño simbólico regalo o un simple agradecimiento publico, sabemos que puedes hacerlo.

P.D.: Feliz Dia para MI, Feliz dia jill-9!  Y feliz Dia a todos los Administradores de Sistema!

1
2
3
4
5
6
7
8
9

public class Hello {
 
  public static void main(String[] args) {
 
    System.out.println("Hello World!");
 
  }
 
}

18 19 20 21 22 23 24 25 26

class Example     def example(arg1)     return "Hello: " + arg1.to_s     end   end

3 4 5 6 7 8 9 10 11 12 13 14 15

function foo() {     echo "Hello World!\\n";     }     for (\$i = 0; \$i < 10 $i++) {     foo();     }   ?>

Steve McIntyre es el miembro más adulto de los tres, habiendo ingresado en 1996.Raphael Hertzog, quien también fue candidato el 2002 y 2007, ha sido parte del proyecto desde 1998 mientras que Marc Brockschmidt, el más joven de los tres, comenzó su participación en Debian el año 2004.

Dicho período de campaña se realiza entre el día 9 de Marzo al 30 de Marzo; se organiza un debate online (irc.debian.org - /join #debian-dpl-debate - lista de correo)durante dicho periodo. Las votaciones se realizan entre el 30 de Marzo y el 13 de Abril, mientras que el nuevo DPL comienza su mandato el 17 de Abril.

El proyecto Debian usa el método Condorcet para determinar un ganador; citando su propia explicación, uno tiene que “considerar todas las competencias posibles de doble dirección entre candidatos. El ganador Condorcet, si es que hay uno, es quien pudo vencer a cada uno de los candidatos en estas competencias” Manoj Srivastava, senior Debian developer, quien es secretario del proyecto, es el equivalente a un comisionado de elección.

Cada candidato coincidió en una plataforma cuando fueron nominados: el deseo común de hacer Debian mejor conocido. Hertzog ha propuesto una mesa DPL y mencionó que los otros dos que tendría en dicha mesa - su idea es que teniendo tres personas más con ideas en común se puede lograr más que solo existiendo una.

McIntyre, quien trabajó como asistente no-oficial del project leader 2006, ayudando al Australiano Anthony Towns, ha dicho que le gustaría mejorar las comunicaciones al interior del proyecto: algo que ha sido generalmente un problema durante estos años.

Brockschmidt, sin embargo, concuerda que mejorando las comunicaciones - las cuales dice que quedan mejor expresadas como stopping flames - no es posible, debido a que los desarrolladores no son muñecos de peluche.

Parece muy probable que el nuevo lider presidirá Lenny cuando sea liberado,siguiente release estable, cuya versión es 5.0. Han habido algunas conversaciones sobre la liberación de éste en Septiembre o en cualquier caso antes de fin de año.

Informacion sobre el debate de IRC luego del salto.

No lo olvides, el debate DPL será en IRC en #debian-dpl-debate irc.debian.org (OFTC) a las 20:30 UTC (17:30 hora chilena) este miércoles 26 de Marzo 2008, terminando a las 23:30 del mismo día. Las discusiones acerca del debate se harán en #debian-dpl-discuss en la misma red (irc.debian.org)

Resumen: Comienza a las 20:30 UTC

0. Introducciones

1. Debate Moderado (3 minutos/10 lineas respondidas, preguntas enviadas previamente)

–5 minutos descanso–

2. Debate Moderado (3 minutos/10 lineas respondidas, preguntas hechas por la audiencia)

–5 minutos descanso–

3. Sin reglas (45 minutos de insanidad)

4. Comentarios de cierre

Llamado para panelistas:

MJ (slef) y yo (dondelelcaro) actualmente somos los únicos panelistas. Necesitamos al menos 4 o 5 más para seleccionar preguntas -discute y ayúdanos para representar de forma efectiva los problemas que afectan al proyecto. Por favor envia un mail a don_at_debian_dot_org si quieres participar-

Para las preguntas: Si tienes alguna pregunta para ver como responden los distintos candidatos en tiempo real, por favor enviala a don_at_debian_dot_org_dot_ Usaremos estas preguntas en la primera mitad del debate. Nuestros panelistas estaran solicitando preguntas, asi que no olvides la tuya incluso en el caso que no hayas enviado mail.

Las reglas:

El debate de este año estará dividido en tres secciones separadas, en un intento de tener opiniones improvisadas de cada candidato. El debate comenzará tan pronto como los canditatos esten presentes, o no más tarde que las 20:45UTC. Cada sección se extenderá aproximadamente 45 minutos, con un descanso de 5 minutos entre cada sección. El debate oficial terminará no más tarde de las 23:30UTC.

Las primeras dos secciones consistirán de series de 5-6 preguntas; candidatos responderan escribiendo directamente en el canal. El primer período de 45 minutos serán preguntas previamente enviadas, mientras que la segunda parte consistirá de preguntas de la audiencia durante el debate. Cada candidato tendrá 3 minutos o 10 líneas para responder.

Cada candidato tendrá 1.5 minutos o 5 lineas para refutar ciertas preguntas.

La última y final sección será libre. Moderadores intentarán tomar preguntas desde la audiencia y hacer que cada candidato se enfrente. Habrán múltiples conversaciones al mismo tiempo, y múltiples preguntas serán hechas al mismo tiempo en un ataque masivo de caos. Espero ver eso!

Luego de 45 minutos de caos, el moderador cerrará dicho debate. Candidatos postearán cualquier comentario de cierre en debian-vote_at_lists_dot_debian_dot_org_dot_

Se hará público todo registro luego del debate para referencia de votantes y otros interesados.

Fuentes: DebianChile.cl, DebianChile.cl

Me puse a buscar por ahi, y encontre la pagina del BCM43xx Project ahi pueden encontrar mucha info con respecto a los diversos rev. de los chip’s aqui de pasaita les dejo la tabla de versiones de los chips segun modelo de laptop.

No se si algunos recuerdan el Exloit Local que aparecio hace ya un par de semanas atras, con el cual se permitia a un usuario normal, obtener privilegios de root. Bueno ahora paseando por la web, me encuentro con un pequeño informe realizado por DistroWatch que revela el tiempo de respuesta de las diferentes distros frente a este bug, y cuanto tardaron en repararlo:

1. Debian (0+ horas)
2. Fedora (8+ horas)
3. Slackware (12+ horas)
4. Mandriva (19+ horas)
5. Frugalware (21+ horas)
6. OpenSUSE (23+ horas)
7. rPath (26+ horas)
8. Red Hat Enterprise Linux (27+ horas)
9. Ubuntu (27+ horas)
10. CentOS (37+ horas)

Fuente: VivaLinux