Archivos Translation de los repos
Mi repositorio > http://repo.mamalibre.com.ar/Readme.txt Andaba bien mi repo hasta hoy que un colega con una distro-híbrida intento usar el synaptic. Ahí me di cuenta que tuve que actualizar mi repositorio... Hasta ahí todo bien. Pero... me esta pidiendo estos archivos Translation-es_AR.gz Translation-es.gz Translation-en.gz No doy como generar sos archivos en el repositorio. Se que son de texto plano Package: paquete1 Description-md5: Description-es: Package: paquete12 Description-md5: Description-es: aqui la 2da descripcion contenido en Translation-es.2.bz2 he generado el archivo en blanco, y luego comprimirlo para si ver si me sigue saliendo este error W: Fallo al obtener gzip:/var/lib/apt/lists/partial/mamalibre.no-ip.org_dists_karmic_main_i18n_Translation-es%5fAR.gz Formato inválido de fichero W: Fallo al obtener gzip:/var/lib/apt/lists/partial/mamalibre.no-ip.org_dists_karmic_main_i18n_Translation-es.gz Formato inválido de fichero W: Fallo al obtener gzip:/var/lib/apt/lists/partial/mamalibre.no-ip.org_dists_karmic_main_i18n_Translation-en.gz Formato inválido de fichero Pero sale de nuevo. -- Servicios:. http://mamalibre.com.ar/plus MamaLibre, Casa en Lincoln, Ituzaingo 1085 CP6070, Buenos Aires, Argentina pgpL2h4446xQo.pgp Description: PGP signature
Re: Debian-Live se va... Debian CD se queda
El Tue, 10 Nov 2015 17:38:11 +0100, Javier Barroso escribió: > 2015-11-10 17:07 GMT+01:00 Altair Linux : (...) >> En serio, parece que el ambiente es "zona de guerra" y los ataques >> personales (cuanto mas salvaje, mejor) estan a la orden del dia. Una >> leve muestra parecen ser algunos videos de Torvalds diciendo lo que >> piensa, a su estilo, y lei hace tiempo en algun articulo que ningun >> relaciones publicas queria trabajar con Torwalds precisamente por su >> comportamiento. > > El último hilo que leí de Linus fue bastante fuerte: > > https://lkml.org/lkml/2015/10/28/215 > > No sé si es bueno que se hable así, pero en este caso de momento el tema > sigue para adelante Bueno, más allá de la palabrería que usa al menos explica técnicamente por qué es mejor una opción que otra, o simplemente por qué él quiere una opción antes que otra, que también se trata de preferencias personales. Y eso se puede rebatir. Pero que alguien te diga, "no voy a seguir con este tema y marco este bug como cerrado" es una cosa muy distinta. Sin argumentos, sin debate, sin opciones... si te pilla en un momento de debilidad o bajo de defensas sólo puedes batirte en retirada. Saludos, -- Camaleón
Re: Debian-Live se va... Debian CD se queda
Buenas, 2015-11-10 17:07 GMT+01:00 Altair Linux : > > Hola, > > desde mi desconocimiento sobre el tema: parece que el salvajismo en los > proyectos relacionados con los desarrollos en Linux es bastante comun (que > conste que no estoy respaldandolo) y segun parece ese nivel de hostilidades > produce un nivel de calidad mas elevado (segun ellos, repito). > > Recuerdo que no hace mucho se produjeron dos dimisiones de peso en uno de > los desarrollos, una se produjo por ser persona directamente relacionada que > dijo (entre otras cosas) no soportar la situacion y el ambiente; la segunda > dimision parece que fue por solidaridad y apoyo a la primera persona. > > En serio, parece que el ambiente es "zona de guerra" y los ataques > personales (cuanto mas salvaje, mejor) estan a la orden del dia. Una leve > muestra parecen ser algunos videos de Torvalds diciendo lo que piensa, a su > estilo, y lei hace tiempo en algun articulo que ningun relaciones publicas > queria trabajar con Torwalds precisamente por su comportamiento. El último hilo que leí de Linus fue bastante fuerte: https://lkml.org/lkml/2015/10/28/215 No sé si es bueno que se hable así, pero en este caso de momento el tema sigue para adelante Saludos
Re: [OT] Sobre manejo de releases de dos Proyectos separados con GIT
El Mon, 09 Nov 2015 11:07:13 -0300, David Helmut Reese Molinas escribió: > Buen Dia > > Sé que el tema es bastante OT, pero tomando en cuenta que la mayoria de > los que están en esta lista tienen experiencia en desarrollo con > proyectos grandes me parece que podriamos compartir algunas experiencias > de manera a poder solucionar un dilema que estoy teniendo. > No es precisamente un problema, sino más bien un tema de organización. > Me interesa saber cómo lo hacen (o lo harían si aún no tuvieron la > experiencia) en un panorama como el siguiente. (...) > Actualmente estamos manejando el esquema recomendado por GIT para los > branches (las explicaciones están resumidas, pero espero que se > entiendan): (...) Ah, Git... ese gran desconocido: http://xkcd.com/1597/ A ver si alguien que lo use te puede echar una mano con los esquemas que tienes en mente o te da alguna idea mejor. Yo sólo te puedo decir que cuando alguien me dice: "puedes descargar los paquetes desde git en esta dirección..." me pongo a temblar porque no tengo ni idea de qué, dónde ni cómo descargar nada de esas páginas (:-P Saludos, -- Camaleón
Re: Debian-Live se va... Debian CD se queda
Hola, desde mi desconocimiento sobre el tema: parece que el salvajismo en los proyectos relacionados con los desarrollos en Linux es bastante comun (que conste que no estoy respaldandolo) y segun parece ese nivel de hostilidades produce un nivel de calidad mas elevado (segun ellos, repito). Recuerdo que no hace mucho se produjeron dos dimisiones de peso en uno de los desarrollos, una se produjo por ser persona directamente relacionada que dijo (entre otras cosas) no soportar la situacion y el ambiente; la segunda dimision parece que fue por solidaridad y apoyo a la primera persona. En serio, parece que el ambiente es "zona de guerra" y los ataques personales (cuanto mas salvaje, mejor) estan a la orden del dia. Una leve muestra parecen ser algunos videos de Torvalds diciendo lo que piensa, a su estilo, y lei hace tiempo en algun articulo que ningun relaciones publicas queria trabajar con Torwalds precisamente por su comportamiento. Y todo esto, repito, dicen que es porque la calidad del codigo es lo primero. Sorprendente. El 10 de noviembre de 2015, 16:54, Camaleón escribió: > El Tue, 10 Nov 2015 16:27:43 +0100, Javier Barroso escribió: > > >> Acabo de leer este mensaje sobre el cierre del proyecto Debian Live en > >> la lista de desarrolladores: > >> > >> An abrupt End to Debian Live > >> https://lists.debian.org/debian-devel/2015/11/msg00110.html > > (...) > > >> Sinceramente, creo que las cosas se pueden hacer mejor: muy mal Debian > >> :-( > > > > Espero que se arregle, parece que han rectificado y han admitido el > > cambio de nombre, probablemente demasiado tarde para el bien de Debian: > > > > https://lists.debian.org/debian-live/2015/11/msg00053.html > > > > Aunque sinceramente, siempre que alguién dice que lo deja, casi nunca > > vuelve :(. Realmente una pena > > Este tipo de actuaciones hay que cortarlas de raíz y no esperar a que > quien te da una puñalada después reconozca el "error" y te pida perdón, > no resulta creíble (los ataques directos al proyecto Debian Live en los > bugs son cuanto menos hirientes). > > Echo en falta una voz que esté por encima de desarrolladores/mantenedores/ > empaquetadores, velando por los intereses generales de Debian y no por > los particulares de cada uno pero sobre todo que sepa reconocer los > méritos y el esfuerzo individual de quien ha dedicado tiempo en hacer > mejor y más accesible Debian. > > Saludos, > > -- > Camaleón > >
Re: Debian-Live se va... Debian CD se queda
Buenas de nuevo, 2015-11-10 16:54 GMT+01:00 Camaleón : > El Tue, 10 Nov 2015 16:27:43 +0100, Javier Barroso escribió: > >>> Acabo de leer este mensaje sobre el cierre del proyecto Debian Live en >>> la lista de desarrolladores: >>> >>> An abrupt End to Debian Live >>> https://lists.debian.org/debian-devel/2015/11/msg00110.html > > (...) > >>> Sinceramente, creo que las cosas se pueden hacer mejor: muy mal Debian >>> :-( >> >> Espero que se arregle, parece que han rectificado y han admitido el >> cambio de nombre, probablemente demasiado tarde para el bien de Debian: >> >> https://lists.debian.org/debian-live/2015/11/msg00053.html >> >> Aunque sinceramente, siempre que alguién dice que lo deja, casi nunca >> vuelve :(. Realmente una pena > > Este tipo de actuaciones hay que cortarlas de raíz y no esperar a que > quien te da una puñalada después reconozca el "error" y te pida perdón, > no resulta creíble (los ataques directos al proyecto Debian Live en los > bugs son cuanto menos hirientes). > > Echo en falta una voz que esté por encima de desarrolladores/mantenedores/ > empaquetadores, velando por los intereses generales de Debian y no por > los particulares de cada uno pero sobre todo que sepa reconocer los > méritos y el esfuerzo individual de quien ha dedicado tiempo en hacer > mejor y más accesible Debian. También le han pedido al lider de Debian que tome cartas en el asunto: https://lists.debian.org/debian-live/2015/11/msg00050.html A ver como acaba este tema. Estar en Debian y no querer colaborar, tiene cosa el asunto Saludos!
Re: Debian-Live se va... Debian CD se queda
El Tue, 10 Nov 2015 16:27:43 +0100, Javier Barroso escribió: >> Acabo de leer este mensaje sobre el cierre del proyecto Debian Live en >> la lista de desarrolladores: >> >> An abrupt End to Debian Live >> https://lists.debian.org/debian-devel/2015/11/msg00110.html (...) >> Sinceramente, creo que las cosas se pueden hacer mejor: muy mal Debian >> :-( > > Espero que se arregle, parece que han rectificado y han admitido el > cambio de nombre, probablemente demasiado tarde para el bien de Debian: > > https://lists.debian.org/debian-live/2015/11/msg00053.html > > Aunque sinceramente, siempre que alguién dice que lo deja, casi nunca > vuelve :(. Realmente una pena Este tipo de actuaciones hay que cortarlas de raíz y no esperar a que quien te da una puñalada después reconozca el "error" y te pida perdón, no resulta creíble (los ataques directos al proyecto Debian Live en los bugs son cuanto menos hirientes). Echo en falta una voz que esté por encima de desarrolladores/mantenedores/ empaquetadores, velando por los intereses generales de Debian y no por los particulares de cada uno pero sobre todo que sepa reconocer los méritos y el esfuerzo individual de quien ha dedicado tiempo en hacer mejor y más accesible Debian. Saludos, -- Camaleón
Re: Debian-Live se va... Debian CD se queda
Hola, 2015-11-10 16:21 GMT+01:00 Camaleón : > Hola, > > Acabo de leer este mensaje sobre el cierre del proyecto Debian Live en la > lista de desarrolladores: > > An abrupt End to Debian Live > https://lists.debian.org/debian-devel/2015/11/msg00110.html > > En resumen: el "origen" del conflicto parece ser una solicitud de cambio > de nombre de los paquetes para que no haya colisiones entre distintos > proyectos pero la cosa deriva en acusaciones feas y una falta de tacto > inquietante por parte de los encargados de los proyectos en cuita (debian- > cd). El encargado del proyecto Debian Live se harta (normal) y cierra. > > Sinceramente, creo que las cosas se pueden hacer mejor: muy mal Debian :-( Espero que se arregle, parece que han rectificado y han admitido el cambio de nombre, probablemente demasiado tarde para el bien de Debian: https://lists.debian.org/debian-live/2015/11/msg00053.html Aunque sinceramente, siempre que alguién dice que lo deja, casi nunca vuelve :(. Realmente una pena Saludos
Debian-Live se va... Debian CD se queda
Hola, Acabo de leer este mensaje sobre el cierre del proyecto Debian Live en la lista de desarrolladores: An abrupt End to Debian Live https://lists.debian.org/debian-devel/2015/11/msg00110.html En resumen: el "origen" del conflicto parece ser una solicitud de cambio de nombre de los paquetes para que no haya colisiones entre distintos proyectos pero la cosa deriva en acusaciones feas y una falta de tacto inquietante por parte de los encargados de los proyectos en cuita (debian- cd). El encargado del proyecto Debian Live se harta (normal) y cierra. Sinceramente, creo que las cosas se pueden hacer mejor: muy mal Debian :-( Saludos, -- Camaleón
Re: fslint ui
El Tue, 10 Nov 2015 09:16:17 +, franiortiz hotmail escribió: (...) >>¿Has probado a ejecutarlo desde una consola? > Si y findup funciona correctamente, pero echo de menos la ui (...) Me refería a ejecutar desde una consola la interfaz gráfica, por si te saltara algún mensaje o error :-) Saludos, -- Camaleón
Re: Permisos para crear fichero PID
El Mon, 09 Nov 2015 17:26:04 +0100, Josu Lazkano escribió: > Hola a todos, > > Estoy configurando el servico de transmission-daemon para poder > compartir contenido en internet. Estoy viendo en los logs que el > servicio no puede crear el fichero PID en /var/run/ > > Nov 9 14:47:28 servidor transmission-daemon[3663]: [2015-11-09 > 14:47:28.087 CET] Unable to save pidfile > "/var/run/transmission-daemon.pid": Permission denied (daemon.c:573) > > El usuario con que se ejecuta el servicio es "debian-transmission": > > # id debian-transmission uid=108(debian-transmission) > gid=114(debian-transmission) groups=114(debian-transmission) > > Originalmente el PID se gaurdaba en > "/var/run/transmission/transmission-daemon.pid", he cambiado la ruta, > no se si importa. > > ¿Como puedo hacer para que se pueda crear ese fichero? Hum... ¿dices que lo has cambiado de motu propio? ¿Por qué motivo? Vuelve a dejarlo como estaba y si funciona seguramente sea porque el directorio donde se guardaba el PID del servicio tenía los permisos adecuados para que el usuario "debian-transmission" tuviera acceso de escritura en él. Por otra parte no dices si usas sysvinit o systemd y eso puede marcar una diferencia. Saludos, -- Camaleón
Re: [OT] Sobre manejo de releases de dos Proyectos separados con GIT
Perfecto. Gracias El 9 de noviembre de 2015, 21:22, Angel Claudio Alvarez < an...@angel-alvarez.com.ar> escribió: > El Mon, 9 Nov 2015 11:07:13 -0300 > David Helmut Reese Molinas escribió: > > > Buen Dia > > > > Sé que el tema es bastante OT, pero tomando en cuenta que la mayoria de > los > > que están en esta lista tienen experiencia en desarrollo con proyectos > > grandes me parece que podriamos compartir algunas experiencias de manera > a > > poder solucionar un dilema que estoy teniendo. > > No es precisamente un problema, sino más bien un tema de organización. Me > > interesa saber cómo lo hacen (o lo harían si aún no tuvieron la > > experiencia) en un panorama como el siguiente. > > > > Ni siquiera califica como OT > > > Estamos trabajando en un proyecto de sistema web basado en servicios. > > Tenemos el proyecto de la capa backend y el de la capa front-end en dos > > proyectos separados, por tanto también repositorios separados, dentro del > > GitLab institucional. > > > > Como nuestro backend aún no es una rama estable, los servicios podrían > > sufrir cambios en cuanto los datos que reciben tanto como los que > devuelven. > > Lo mismo sucede con la capa del front-end, con la diferencia de que el > > front-end obviamente depende de los servicios para funcionar. > > > > Actualmente estamos manejando el esquema recomendado por GIT para los > > branches (las explicaciones están resumidas, pero espero que se > entiendan): > > - Master: El release de produccion > > - Develop: El release de testing, utilizado para pruebas de integración > > antes del paso a producción > > - Hot-fixes: Para corrección de errores > > - Features: Para las nuevas funcionalidades o actualizaciones sobre > > funcionalidades existentes. > > > > El tema es que cada capa (front-end y back-end), al tratarse cada uno de > un > > proyecto "independiente", tiene su propio numero de version y release. > > Por ahora lo que hacemos es separar los pasos a producción (actualmente > en > > beta) de ambos proyectos en dos partes: > > > > -- La primera es el lanzamiento del release de cada proyecto conteniendo > > modificaciones que no afecten al otro proyecto: > > - Por ejemplo: Corrección de un error en el back-end, cambio de > una > > etiqueta en el front-end, etc. > > > > -- La segunda es el lanzamiento de releases conteniendo modificaciones > que > > afecten al otro proyecto, o sea que el paso a producción se hace de ambos > > proyectos a la vez: > > - Por ejemplo: > > - Se elimina un campo en algún servicio en el back-end, > > - el front-end necesita consumir ese servicio y al no encontrar > un > > campo, la aplicación lanza un error hasta que sea corregido el codigo en > el > > front-end > > > > El problema que estamos teniendo es con la segundo tipo de paso a > > producción mencionado; y aquí me explico mejor: > > Cuando se lanza una modificacion a un servicio (proyecto backend) se > > verifica que todo funcione en el proyecto y se pasa a develop. > > Se trabaja entonces con las modificaciones en el front-end para consumir > el > > servicio con esta modificación. > > > > ¿Cómo nos organizaríamos o deberíamos organizarnos con los releases de > cada > > proyecto como para no lanzar una version que pueda romper algo en el otro > > proyecto? > > > > Me recomendaron crear dos numeraciones de releases en los milestones... > > - un número de versión sería la de cada proyecto individual, o sea, > > backend-1.0.4 o frontend-1.2.3... > > - otra numeración de sería la de el proyecto completo... Proyecto-1.3 > > > > O sea que si se crea un milestone (sería para identificar todo lo que > > debería entrar en una versión específica) backend-1.0.5 entendemos que > > todavia no se lanzará a producción, pero si se crea un milestone > > proyecto-1.0.6 corresponde a lo que se lanzará a producción en conjunto > con > > el frontend, y espera a que en el otro proyecto alcance el mismo > milestone > > proyecto-1.0.6 para lanzar ambos al mismo tiempo... > > > > La idea es saber siempre cuando estoy "habilitado" a lanzar una > > modificación a producción del backend sin que esto afecte negativamente > al > > frontend... es bastante trivial hasta cierto punto, pero igualmente > siempre > > tenemos problemas, y si bien estoy recibiendo bastantes consejos de otros > > colegas me gustaría conocer la opinión de la comunidad. > > > > Siento mucho si no se entiende correctamente, estoy haciendo un esfuerzo > > por explicarlo bien. > > Igualmente gracias por si se tomaron el tiempo de leerlo y tratar de > > entenderlo, y perdonen si les parece una pérdida de tiempo. > > > > Gracias de antemano para todos > > > > -- > > > > David H. Reese M. > > Investigación y Desarrollo > > Dirección Nacional de Contrataciones Públicas > > Asunción - Paraguay > > Teléfono: 595 971 351390 > > > > > -- > Angel Claudio Alvarez > > -- -
Re: fslint ui
>https://www.debian.org/Bugs/Reporting gracias, lo comunicare >error que se debe de notar nada más ejecutarlo y seleccionar los archivos ¿no? totalmente correcto >¿Recibes algún mensaje de error? Ninguno >¿Has probado a ejecutarlo desde una consola? Si y findup funciona correctamente, pero echo de menos la ui >¿Has intentando ejecutarlo desde otro usuario? No, aunque me pasa lo miso en 1pc y 2 portatiles recien actualizados a jessie y en los que antes fslint funcionaba sin problemas Saludos
