Y si quisiera la versión más moderna de squid? la 3.1.19 en vez de la 3.1.18?
Ah, la idea es la siguiente: me voy a basar en el squid.spec que viene en la versión anterior (3.1.18) de la cual ya bajé el src.rpm y le modificaré este squid.spec para que compile la 3.1.19
ah sí, tendré que bajar la 3.1.19 desde tar.gz
Me bajo la nueva versión:
[mock@acer ~]$ wget http://www.squid-cache.org/Versions/v3/3.1/squid-3.1.19.tar.gz
--2012-03-12 16:44:22-- http://www.squid-cache.org/Versions/v3/3.1/squid-3.1.19.tar.gz
Resolving www.squid-cache.org... 209.169.10.131, 198.186.193.234
Connecting to www.squid-cache.org|209.169.10.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3403110 (3.2M) [application/x-gzip]
Saving to: “squid-3.1.19.tar.gz”
100%[======================================>] 3,403,110 205K/s in 17s
2012-03-12 16:44:44 (195 KB/s) - “squid-3.1.19.tar.gz” saved [3403110/3403110]
Ahora abro el viejo src.rpm, se abre hacia rpmbuild/
[mock@acer ~]$ rpm -Uvh squid-3.1.18-1.el5.src.rpm
(te dará unos errores de que no existe el usuaro mockbuild, ignorale)
Ahora verifico que el src.rpm anterior se abrió hacia el directorio rpmbuild:
[mock@acer ~]$ ls rpmbuild/SPECS/
squid.spec
[mock@acer ~]$ ls rpmbuild/SOURCES/
perl-requires-squid.sh
squid-3.0.STABLE1-perlpath.patch
squid-3.0.STABLE7-from_manpg.patch
squid-3.1.0.9-config.patch
squid-3.1.0.9-location.patch
squid-3.1-10415.patch
squid-3.1.18.tar.bz2
squid-3.1.18.tar.bz2.asc
squid-3.1.9-ltdl.patch
squid.init
squid.logrotate
squid.nm
squid.pam
squid.sysconfig
ah sí! te fijas? Ahi está el squid.spec (que modificaré para que compile la versión 3.1.19 y no la 3.1.18 y también están ciertos parches y además el squid-3.1.18.tar.bz2 que es el anterior fuente del squid.
Bueno, ahora muevo hacia rpmbuild/SOURCES el nuevo tar.gz del squid:
[mock@acer ~]$ mv squid-3.1.19.tar.gz rpmbuild/SOURCES/
Bien, la idea será decirle al squid.spec que compile la 3.1.19.. para esto, edito squid.spec:
vi rpmbuild/SPECS/squid.spec
y le modifico lo siguiente, arriba arriba dice: Version 3.1.18, le cambio a la nueva que bajé:
Version: 3.1.19
Ahora me voy al final, donde dice: %changelog y le pongo la info de lo que cambié:
%changelog
* Mon Mar 12 2012 Ernesto "Epe" Perez
- update to latest upstream 3.1.19
(esto lo agregué justo debajo de %changelog).
Perfecto, ahora me toca crear el src.rpm, recuerda que tengo un squid.spec modificado y un squid-3.1.19.tar.gz debo combinarles a ambos y obtener un src.rpm:
[mock@acer ~]$ rpmbuild -bs rpmbuild/SPECS/squid.spec
error: File /home/mock/rpmbuild/SOURCES/squid-3.1.19.tar.bz2: No such file or directory
ah caramba! Es que busca un tar.bz2, y yo bajé el tar.gz, podría bajarle el tar.bz2, pero mejor le convierto:
[mock@acer ~]$ gunzip -c /home/mock/rpmbuild/SOURCES/squid-3.1.19.tar.gz|bzip2 -c - > /home/mock/rpmbuild/SOURCES/squid-3.1.19.tar.bz2
Listo, convertido de gz a bz2, repito:
[mock@acer ~]$ rpmbuild -bs rpmbuild/SPECS/squid.spec
Ahora me dice que no encuentra: squid-3.1.18.tar.gz.asc, no sé de dónde salió y la verdad no me interesa, así que edito nuevamente el squid.spec y comento una sección que dice:
Source1
Que es la que hablaba de un tal .asc que no me hace falta.
Ahora sí pude crear el src.rpm
[mock@acer ~]$ rpmbuild -bs rpmbuild/SPECS/squid.spec
warning: Could not canonicalize hostname: acer.local
Wrote: /home/mock/rpmbuild/SRPMS/squid-3.1.19-1.el6.src.rpm
Bien! Ya que tengo el src.rpm, vamos a "mockearle" (qué feo suena):
mock -v -r epel-6-i386 /home/mock/rpmbuild/SRPMS/squid-3.1.19-1.el6.src.rpm
Bien, le estoy compilando para centos-6 de 32bits, podría ser para otra cosa.... esperamos y ....me ha fallado la compilación!
ERROR: Exception(/home/mock/rpmbuild/SRPMS/squid-3.1.19-1.el6.src.rpm) Config(epel-6-i386) 0 minutes 30 seconds
INFO: Results and/or logs in: /var/lib/mock/epel-6-i386/result
ERROR: Command failed. See logs for output.
# ['bash', '--login', '-c', 'rpmbuild -bb --target i686 --nodeps builddir/build/SPECS/squid.spec']
DEBUG: kill orphans
me dice que vea los logs, veamos:
[mock@acer ~]$ less /var/lib/mock/epel-6-i386/result/build.log
Al final me dice:
Patch #300 (squid-3.1-10415.patch):
+ echo 'Patch #300 (squid-3.1-10415.patch):'
+ /bin/cat /builddir/build/SOURCES/squid-3.1-10415.patch
+ /usr/bin/patch -s -p0 --fuzz=0
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
1 out of 1 hunk ignored -- saving rejects to file src/Store.h.rej
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
1 out of 1 hunk ignored -- saving rejects to file src/store.cc.rej
Ahh el patch 300 parece que o se ha movido de lugar, o ya no va en esta versión, particularmente, editaré el rpmbuild/SPECS/squid.conf y comentaré el parche 300, luego reharé el src.rpm de nuevo (podría arreglar el parche si tuviera tiempo):
Edito:
vi rpmbuild/SPECS/squid.spec
y comento ambas referencias al parche 300:
#Patch300: squid-3.1-10415.patch
#%patch300 -p0
Lo malo es que como he modificado el .spec, me toca re-crear el src.rpm:
[mock@acer ~]$ rpmbuild -bs rpmbuild/SPECS/squid.spec
warning: Could not canonicalize hostname: acer.local
Wrote: /home/mock/rpmbuild/SRPMS/squid-3.1.19-1.el6.src.rpm
Ahora sí, vuelvo a correr el mock:
mock -v -r epel-6-i386 /home/mock/rpmbuild/SRPMS/squid-3.1.19-1.el6.src.rpm
Y bueno ya está el rpm listo
Resumen:
Este es un caso bastante trágico, en el que tuve que remover un parche del src.rpm, normalmente se compila todo sin inconvenientes, pero qué bueno que sucedió, ya tengo el rpm compilado. Sólo tuve que repetir dos veces la creación del src.rpm
Comentarios
Re:
;) muy buen manual pero no es más rápido, ya que veo que utilizas el rpmbuild, utilizas;
rpmbuild -v -bb /root/rpmbuild/SPECS/nombredelarchivospec.spec
lo digo porque con rpmbuild tu descomprimes el src original, luego colocas los archivos en la carpeta SOURCES y luego el fichero modificado *.spec en la carpeta spec y así no tienes que ir creando archivos src cada vez que modificas, puedes hacer las pruebas directamente modificando el archivo de texto *.spec y te lo compila bien!
Lo que no consigo compilar es la nueva versión de wine ya que tiene archivos i686 en sus dependencias y si los creo tanto en x86_64 y con i686 me da conflicto a la hora de instalar... tu podrías compilar con mock a ver si te compila y te instala todo el wine al completo??
te acuerdas cuando lo compilé
te acuerdas cuando lo compilé para que lo tuvieras? lo hice con mock si mal no recuerdo.
cuando comprendas el uso de mock, lo agradecerás, no está en poder abrir el .src.rpm sino en poder compilar varias arquitecturas y para varias versiones lo mismo una vez obtenido el src.rpm
más info aquí
http://fedoraproject.org/wiki/Extras/MockTricks
si tuviera tiempo, le compilaba el wine, con mock para que satisfaciera todas las dependencias y me quedara en un ambiente limpio para cada compilación... pero no lo tengo ahora.
Saludos
epe
EcuaLinux.com
+(593) 9 9924 6504
Servicios en Software Libre
Re:
pues are la prueba a ver que tal ya que me interesa tener, por ejemplo el gcc 2.6 y el python 2.7 que la mayoría de aplicaciones para compilar el6 me lo pide! :)
para que me entere entonces, yo hago el proceso de bajar el codigo fuente, lo moldeo a mi manera y luego creo el archivo src con rpmbuild, luego desde mock compilo el paquete src que yo he creado y entonces me lo compilara para x86_64 y para i686 o tengo que especificar de alguna manera que me lo compile para estas dos arquitecturas!?
Re:
pues si, con este puedo crear los paquetes para i686 y x86_64 sin problemas! :) muchas gracias por tu aportación!
Ventajas sobre rpmbuild:
en rpmbuild se queja de que faltan rpm que instalar para poder compilar, mock directamente te las instala
en rpmbuild no he encontrado la manera de que me compile el x86_64 y i686 del mismo src y que no de conflictos a la hora de instalar porque intenta instalar el mismo archivo.
Igualmente continuare con rpmbuild ya que lo veo mucho más manejable al tener los directorios en una misma carpeta y se puede moldear mejor que con mock.. va a gustos pero para los paquetes que tenga que tener i686 y x86_64 me ira perfecto mock :)
bien, todo poco a poco, yo ya
bien, todo poco a poco, yo ya casi no uso rpmbuild sino que me moví completamente a mock, pero sé que es un problema de costumbre, de mantener ambientes aislados y no contaminados pues el mock te instala las dependencias para cada cosa que compila, el rpmbuild usa lo que ahi haya y si estás usando algún paquete que luego no reportas a los repo, fallarán posiblemente algunas cosas
y oh sí, mock tiene otra ventaja, que es qe te baja del repo que confiugres, por lo que puedes ir creando tu propio repo y poniendo ahí todo lo que se requiere para compilar otros paquetes y así ir avanzando, realmente es super super
Saludos
epe
EcuaLinux.com
+(593) 9 9924 6504
Servicios en Software Libre
re:
Eso te queria preguntar, todas las dependencias que instala no te las instala realmente sino que es virtualmente no?? así tu equipo no tiene cargado miles de paquetes... si que me esta empezando a gustar... es lo que tu dices.. cuestión de gustos... gracias por tu miniguia!! :) ahora podre subir muchas versiónes de aplicaciones que tengo en el repo de ServOS! :)
Firmar paquetes
oye y como se hace para firmar paquetes?? hay alguna guiá?? se hace desde rpmbuild o desde mock hay alguna manera de hacerlo???
llégate aquí te va a
llégate aquí te va a gustar!
http://fedoranews.org/tchung/gpg/
Saludos
epe
EcuaLinux.com
+(593) 9 9924 6504
Servicios en Software Libre
exactamente eso, por cada
exactamente eso, por cada compilación él arma una jaula donde instala los requisitos para compilar el paquete, los baja de los repos que tú definas....
cuando acaba de compilar, limpia esa jaula..
y en efecto! no tienes que tener miles de paquetes que pueden no tener sentido para una compilación pero para otra sí, esto te puede causar paquetes desactualizados o no publicados pues tú asumes que todo está bien pues es tu equipo pero no el del clifente... por eso mejor compilar en la jaulita del mock.
pero eso sí! Hace una caché de lo que va bajando, de forma tal que cuando le toca bajar de nuevo para otra compilación, usa lo que tiene en la caché para armar la jaula y solamente baja lo que le falte que no hubiera todavía en caché.
Y aparte de eso... el tema de la multiplataforma, puedes compilar en varias plataformas.. o en varias versiones, pues todo va en su jaulita.
Y recuerda, todo se soluciona, el mock tiene un shell (yo no le uso casi) desde el cual puedes incorporar paquetes o .specs abiertos y de ahi mandar a compilar, etc...
Saludos
epe
EcuaLinux.com
+(593) 9 9924 6504
Servicios en Software Libre