Re: Edita tu cron, por las dudas.
El día 28 de junio de 2015, 10:02, Fabián Bonetti mama21m...@riseup.net escribió: Si piensas hacer un backup, o algo importante echale una ojeada de nuevo a tu cron. El próximo 30 de junio al llegar las 23:59:59, el reloj marcará 23:59:60 antes de dar las 00:00:00. Mientras expertos en todo el mundo discuten el caos que puede sufrir Internet en consecuencia, la NASA decidió volver a explicar de dónde proviene este segundo extra. http://actualidad.rt.com/ciencias/178736-nasa-explica%D1%81ion-30-junio-segundo No veo ningún problema. Si no tienes activado ntp, tu reloj irá un segundo más desfasado de lo que fuera antes del cambio de hora oficial. Si tienes ntp activado, a esa hora se dará cuenta de que está un segundo desfasado e irá poco a poco ajustando el reloj hasta que la hora coincida. (Como esos ajustes son de milisegundos, no afectan para nada al cron). S2. -- To UNSUBSCRIBE, email to debian-devel-spanish-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAGw=rhgeu5p8iohrakh_e07cssozty7nhmhc1ex7qdb0ou7...@mail.gmail.com
Edita tu cron, por las dudas.
Si piensas hacer un backup, o algo importante echale una ojeada de nuevo a tu cron. El próximo 30 de junio al llegar las 23:59:59, el reloj marcará 23:59:60 antes de dar las 00:00:00. Mientras expertos en todo el mundo discuten el caos que puede sufrir Internet en consecuencia, la NASA decidió volver a explicar de dónde proviene este segundo extra. http://actualidad.rt.com/ciencias/178736-nasa-explica%D1%81ion-30-junio-segundo -- Servicios:. http://mamalibre.com.ar/plus MamaLibre, Casa en Lincoln, Ituzaingo 1085 CP6070, Buenos Aires, Argentina pgpqbCN4gKKQ2.pgp Description: PGP signature
Edita tu cron, por las dudas.
Si piensas hacer un backup, o algo importante echale una ojeada de nuevo a tu cron. El próximo 30 de junio al llegar las 23:59:59, el reloj marcará 23:59:60 antes de dar las 00:00:00. Mientras expertos en todo el mundo discuten el caos que puede sufrir Internet en consecuencia, la NASA decidió volver a explicar de dónde proviene este segundo extra. http://actualidad.rt.com/ciencias/178736-nasa-explica%D1%81ion-30-junio-segundo -- Servicios:. http://mamalibre.com.ar/plus MamaLibre, Casa en Lincoln, Ituzaingo 1085 CP6070, Buenos Aires, Argentina pgpCP3Z1QIh1G.pgp Description: PGP signature
Edita tu cron, por las dudas.
Si piensas hacer un backup, o algo importante echale una ojeada de nuevo a tu cron. El próximo 30 de junio al llegar las 23:59:59, el reloj marcará 23:59:60 antes de dar las 00:00:00. Mientras expertos en todo el mundo discuten el caos que puede sufrir Internet en consecuencia, la NASA decidió volver a explicar de dónde proviene este segundo extra. http://actualidad.rt.com/ciencias/178736-nasa-explica%D1%81ion-30-junio-segundo -- Servicios:. http://mamalibre.com.ar/plus MamaLibre, Casa en Lincoln, Ituzaingo 1085 CP6070, Buenos Aires, Argentina pgpd7wzCB9Nh9.pgp Description: PGP signature
Re: Dudas...
2008/4/17 Rudy Godoy Guillén [EMAIL PROTECTED]: No existe ningún criterio. Lo más recomendable, en todo caso, es que empieces con algo que ya utilices o te sea familiar. No se si existe algún criterio «oficial», pero el sentido común me dice que tiene más sentido adoptar un paquete huérfano antes que incluir un paquete nuevo habiendo ya otros que sufren abandono y te miran con carita de pena con la naricilla pegada a los barrotes :P -- --- Carlos Galisteo cgalisteo AT k-rolus.net http://blog.k-rolus.net PGP_key::http://k-rolus.net/~cgalisteo/cgalisteo.gpg Key_Fingerprint::F888 6FBA 9145 B5A2 C187 66D6 5B8C 027A 69AD BE65 ---
Re: Dudas...
On Thu, Apr 17, 2008 at 10:07:17AM +0200, Carlos wrote: No se si existe algún criterio «oficial», pero el sentido común me dice que tiene más sentido adoptar un paquete huérfano antes que incluir un paquete nuevo habiendo ya otros que sufren abandono y te miran con carita de pena con la naricilla pegada a los barrotes :P http://wiki.debian.org/AdoptarUnPaquete -- Red Rosa now has vanished too Bertolt Brecht signature.asc Description: Digital signature
Dudas...
Saludos. Estaba intentando empaquetar algo por ahí, y me fije en [1], para empezar con algo más en serio. Mi pregunta es, si es posible empaquetar cualquiera de esas solicitudes, o existe un criterio a tomar en cuenta como el tiempo de espera que tienen, u otras para poder echarle mano. Otra duda: Cuando se parcha un paquete lo hace por que tiene problemas de empaquetado, que involucran a Debian, o parcha problemas de funcionalidad que involucran a la aplicacion y su proyecto. (para los cuales, supongo que tienen sus propios voluntarios). Gracias de antemano. [1]http://www.debian.org/devel/wnpp/requested
Re: Par de dudas.
SilentBlue X dijo [Thu, Dec 13, 2007 at 10:23:35AM -0500]: Hola de nuevo, les agradesco por las respuestas a todos, si que me despejaron las dudas que les mencionaba. Sin embargo estuve leyendo y a ver si me ayudan nuevamente :) ¡Hola! Venga pues... - Cuando uno desea adoptar un paquete, tiene necesariamente que encargarse de su mantenimiento, en todas las arquitecturas que soporta Debian (x86, sparc, alpha, etc...)? Sí, te haces responsable de los paquetes. Si no tienes acceso a la máquina en cuestión, puedes pedir ayuda en alguno de los canales/listas, no falta quien te done un poco de tiempo y ciclos de reloj ;-) - Hace poco estaba experimentando con un juego y creo que esta como huerfano, y no se que funcionalidad agregarle, pues si le hago algunos arreglos derrepente igual pasa como desapercibido. Bueno, nuestro rol primario en Debian es empaquetar y corregir los bugs relativos al empaquetamiento. En segundo término, actuar de intermediarios entre los usuarios y el autor cuando hay bugs reales - ayudar a resolverlos, encontrar qué los puede estar causando, siempre que podamos incluso echar el código para corregirlos, pero _siempre_ intentar empujarlos hacia arriba, para que el desarrollo y las demás distribuciones se beneficien de lo que vamos haciendo. El desarrollar funcionalidad adicional, claro, no es malo... Pero eso debes hacerlo (en mi opinión) como parte de un involucramiento en _ese_ proyecto, no como parte de Debian. - La documentación de Ubuntu en el sentido de parchado de paquetes me puede servir?, Me parece que tiene mejor informacion en ese aspecto, en Debian no la encuentro :( Supongo que sí, en líneas generales al menos. Como sea, en http://www.debian.org/devel/ hay _bastante_ información. Comienza con el New Maintainers' Guide. - Los fallos tipo FTBFS, son los más faciles de corregir? Sí, excepto cuando no ;-) Saludos, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Par de dudas.
* SilentBlue X [Tue, 27 Nov 2007 13:54:56 -0500]: Hola a todos No saben si existe un HOWTO para el tema de parcheado de paquetes. Si se sigue alguna metodología, o solo basta tener encuenta la Debian Policy , conocer algun lenguaje, la funcionalidad del paquete y aplicarle patch. Pregunto para enviar como NMU. Para enviar como NMU, simplemente sigue el empaquetamiento existente en el paquete. Esto es, si el paquete tiene sus parches en debian/patches, separados por temática, crea uno nuevo alli (o actualiza uno existente si de eso se trata). Si el paquete no utiliza ningún sistema de parcheado como quilt o dpatch, y tiene todos los cambios directamente en el .diff.gz, ponlos allí. Otra duda, estaba observando algunos paquetes huerfanos, y parece que algunos no tienen bugs, en el sentido que se hayan reportado errores de funcionalidad en estos. Entonces, mi pregunta es como se puede colaborar con estos paquetes, y algunos tienen buen tiempo con falta de cariño. Gracias. Bueno, si no hay bugs reportados en el paquete, y no hay nuevas versiones que empaquetar, es verdad que habrá poco que hacer. No obstante, siempre puedes adoptarlo para avisar de que serás tú quien se encargue si al final se informa de un fallo, o de empaquetar una nueva versión. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org When it is not necessary to make a decision, it is necessary not to make a decision. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Par de dudas.
Hola a todos No saben si existe un HOWTO para el tema de parcheado de paquetes. Si se sigue alguna metodología, o solo basta tener encuenta la Debian Policy , conocer algun lenguaje, la funcionalidad del paquete y aplicarle patch. Pregunto para enviar como NMU. Otra duda, estaba observando algunos paquetes huerfanos, y parece que algunos no tienen bugs, en el sentido que se hayan reportado errores de funcionalidad en estos. Entonces, mi pregunta es como se puede colaborar con estos paquetes, y algunos tienen buen tiempo con falta de cariño. Gracias.
RFS: lshw libapache-mod-auth-kerb y una par de dudas
Buenos dias a todos, necesito algún alma caritativa para que me esponsorice un par de paquetes: * lshw - Hardware Lister. Como su propio nombre indica, sirve para listar todo el hw de una máquina, bien en texto plano, XML, html o a través de un GUI en GTK. EL antiguo mantenedor ya me lo subió en su día (aunque lleva más de un mes en New Queue a la espera de los ftp-masters.. ¿Alguien sabe como va esto o como los dan de paso?) * libapache-mod-auth-kerb. Módulos de apache para autenticarse usando los tickets de kerberos. El mantenedor hasta ahora no puede seguir dedicándose a ellos. Los he actualizado y ahora ya tiene soporte para apache2. (Amayita, no te preocupes, esta vez tengo permiso por escrito y firmado del mantenedor para hacer el NMU :P) Y ahora la dudilla: En tiempo de compilación, lshw descarga un fichero (pci.ids), donde está todo el listado de hw pci conocido. Sería recomendable dejarlo así. o incluir el fichero como un parche y que no se lo descarge? Ghe Rivero -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dudas sobre PGP
On Sat, 29 Jan 2005 19:20:04 +0100 Guillem Jover [EMAIL PROTECTED] wrote: On Sat, Jan 29, 2005 at 04:56:00PM +0100, Ricardo Mones wrote: On Sat, 29 Jan 2005 00:41:13 +0100 Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: Importarla no vale de nada, porque la clave privada (esa que se perdió al formatear sin backup) la has perdido pa siempre. Si tienes, por ejemplo, mensajes de correo encriptados para ti mismo con tu clave perdida probablemente necesitaras tu antigua clave pública para verlos. Entonces yo puedo descifrar los mensajes crifrados para terceros con sus claves publicas? :) Si no tienes limitaciones temporales y/o capacidad de procesamiento suficiente yo diría que si ;-) pero me imagino que no te refieres a ese método de resolver el problema. Como dije antes fue un lapsus. Saludos, -- Ricardo Mones Lastra - [EMAIL PROTECTED] Centro de Inteligencia Artificial, Universidad de Oviedo en Gijon 33271 Asturias, SPAIN. - http://www.aic.uniovi.es/mones
Re: Dudas sobre PGP
On Fri, 28 Jan 2005 16:49:10 +0100 Rafael Fernández López [EMAIL PROTECTED] wrote: Os escribo a vosotros ya que creo que en cierto modo la pregunta está fuera del lugar de usuarios. [...] Pues yo creo que no, pero bueno, ya que estamos... Sólo tengo una duda, si yo formateo (ya me ha pasado alguna vez) y vuelvo a instalar todo otra vez, ¿cómo podría volver a firmar con la clave que creé? No podrías, has formateado, te la has cargado :) ¿cómo puedo importarla? Pues igual que cualquier otra, siempre y cuando este en un servidor, pero solo importarás tu clave pública (que como su nombre indica es la que se publica). Siempre que lo he hecho me he vuelto a generar otro par de claves y lo he vuelto a subir al servidor, pero estoy seguro que eso no es lo que debo hacer. Si quieres mantenerla deberías hacer copia de seguridad de tu clave privada antes de formatear, evidente ¿no? Más información: http://www.gnupg.org/gph/es/manual.html -- Ricardo Mones Lastra - [EMAIL PROTECTED] Centro de Inteligencia Artificial, Universidad de Oviedo en Gijon 33271 Asturias, SPAIN. - http://www.aic.uniovi.es/mones
Re: Dudas sobre PGP
* Rafael Fernández López [Fri, 28 Jan 2005 16:49:10 +0100]: Siempre que lo he hecho me he vuelto a generar otro par de claves y lo he vuelto a subir al servidor, pero estoy seguro que eso no es lo que debo hacer. Efectivamente, no lo es. En el caso ideal, una persona sólo tiene una clave gpg a lo largo de su vida. What you want is called: backup. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 Hanlon's Razor: Never attribute to malice that which is adequately explained by stupidity. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dudas sobre PGP
On Fri, Jan 28, 2005 at 05:14:05PM +0100, Ricardo Mones wrote: ¿cómo puedo importarla? Pues igual que cualquier otra, siempre y cuando este en un servidor, pero solo importarás tu clave pública (que como su nombre indica es la que se publica). Importarla no vale de nada, porque la clave privada (esa que se perdió al formatear sin backup) la has perdido pa siempre. No se muy bien qué sentido tiene reformatear un equipo pero, si lo haces a menudo, quizás te merezca la pena tener tu /home/ en un disco USB... (suele ayudar por ejemplo para las distribuciones Live) aunque ojito con el disco, perder una clave privada PGP es un problema importante (quizás más que formatearla :-) Saludos Javi signature.asc Description: Digital signature
Re: Dudas sobre debconf/debhelper
On Wed, Jul 10, 2002 at 06:09:03PM +0200, Juan Manuel García Molina wrote: Hola. Entonces alguien ha sugerido usar debconf para preguntar al usuario si quiere borrar o no la base de datos al desinstalar con «--purge». Tal y como defines más adelante, y volviendo a analizar el asunto, me parece que debconf no tiene lugar, porque no se trata de una cuestión relativa a la configuración, sino a una orden del usuario. Mmmh... Podrías considerarlo como configuración del paquete, no como del software que viene en el paquete :-) Creo recordar haber visto ese tipo de preguntas en algún que otro paquete: Este paquete creará la base de datos blahblah... ¿Desea borrarla al eliminarlo con --purge?. No es tan poco común la pregunta como uno quisiera pensar. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dudas sobre debconf/debhelper
Juan Manuel García Molina wrote: Os escribo para ver si me aclaráis una duda que tengo. Es respecto al debconf y el debhelper. Se me ha planteado en el empaquetado de una aplicación la posibilidad de mostrar un diálogo de configuración con ncurses al estilo de debconf -creo- usando plantillas y demás. ¿Qué quieres decir con se me ha planteado? ¿Que alguien te lo ha planteado, o que te lo estás planteando tú? ¿Qué quiere decir al estilo de debconf? ¿Con debconf o sin debconf? Lo que no sé es si esto ya ha quedado obsoleto o no, y eso es lo que quiero que me aclaréis: ¿sería correcto/coherente empaquetar una aplicación a día de hoy y usar plantillas y diálogos de configuración y demás o sería mejor prescindir de estas plantillas? En el manual de la política de empaquetado de Debian no he visto nada refiriéndose explícitamente a esto, por lo que antes de meter la pata, prefiero preguntaros, que seguro que sabéis más que yo. Si vas a hacer algo que se parezca a debconf, hazlo con debconf, pues debconf existe precisamente para que la gente no tenga que reinventar la rueda. En cualquier caso debe ser posible configurar el programa cambiando lo que haga falta (a mano, con cualquier editor) en /etc. Si la duda consiste en usar debconf o no, pregúntate si el programa en cuestión tiene tantas posibilidades distintas para que sea necesario, o si por el contrario existe alguna configuración común que pueda satisfacer a todos los usuarios. Ejemplo de lo primero: Es bueno que los paquetes de X usen debconf para generar /etc/X11/XF86Config-4 porque si no lo hicieran sería imposible adivinar el tipo de tarjeta que tiene el usuario. Ejemplo de lo segundo: Es bueno que sysvinit no pregunte nada acerca de /etc/inittab porque ya hay un fichero de configuración genérico que más o menos puede servir para todo el mundo, y cuantas menos preguntas (innecesarias) haga un paquete durante la instalación, mejor. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dudas sobre debconf/debhelper
On Wed, Jul 10, 2002 at 05:48:37PM +0200, Santiago Vila wrote: Juan Manuel García Molina wrote: Os escribo para ver si me aclaráis una duda que tengo. Es respecto al debconf y el debhelper. Se me ha planteado en el empaquetado de una aplicación la posibilidad de mostrar un diálogo de configuración con ncurses al estilo de debconf -creo- usando plantillas y demás. ¿Qué quieres decir con se me ha planteado? ¿Que alguien te lo ha planteado, o que te lo estás planteando tú? Lo ha planteado el desarrolador del upstream :) De todas formas quizá se pueda simplificar el problema ya que me suena haber visto un hilo en algun sitio que planteaba esta cuestión. Si hago un apt-get remove paquete --purge y el paquete en cuestion ha creado una base de datos (postgres) ¿Se tiene que eliminar esta base de datos? Un saludo -- Celso González E-Mail: [EMAIL PROTECTED] Jabber ID: [EMAIL PROTECTED] GPG disponible en wwwkeys.pgp.net pgpvf7f12NFld.pgp Description: PGP signature
Re: Dudas sobre debconf/debhelper
Hola. El mié, 10-07-2002 a las 17:48, Santiago Vila escribió: Juan Manuel García Molina wrote: Os escribo para ver si me aclaráis una duda que tengo. Es respecto al debconf y el debhelper. Se me ha planteado en el empaquetado de una aplicación la posibilidad de mostrar un diálogo de configuración con ncurses al estilo de debconf -creo- usando plantillas y demás. ¿Qué quieres decir con se me ha planteado? ¿Que alguien te lo ha planteado, o que te lo estás planteando tú? Pues me la estoy planteando yo. Creo que he sido un poco abstracto en la definición anterior. Pondré el ejemplo exacto para no dejar cosas en el tintero. Se trata de un programa que para empezar a funcionar, necesita tener una base de datos y un usuario de Postgres. Por tanto, y aquí no hay problemas, el script de instalación se encarga de crear estos dos elementos. El problema ocurre al desinstalar el paquete. Tal y como está pensado, y para ser consecuente y coherente, al desinstalar con la opción «--purge» -y sólamente en ese caso-, se borran tanto el usuario de la base de datos como la propia base de datos. Y esto es lo que genera polémica. Hay gente que opina que la base de datos no debe borrarse en ningún caso y otros -entre los que me encuentro- que opinamos que si existe la creación en un momento, debe existir la operación inversa de la destrucción; si no existiera, dejaríamos basura en el sistema. Entonces alguien ha sugerido usar debconf para preguntar al usuario si quiere borrar o no la base de datos al desinstalar con «--purge». Tal y como defines más adelante, y volviendo a analizar el asunto, me parece que debconf no tiene lugar, porque no se trata de una cuestión relativa a la configuración, sino a una orden del usuario. ¿Qué quiere decir al estilo de debconf? ¿Con debconf o sin debconf? Quería decir usando debconf -por ahora, no lo he usado al no considerarlo necesario-. Lo que no sé es si esto ya ha quedado obsoleto o no, y eso es lo que quiero que me aclaréis: ¿sería correcto/coherente empaquetar una aplicación a día de hoy y usar plantillas y diálogos de configuración y demás o sería mejor prescindir de estas plantillas? En el manual de la política de empaquetado de Debian no he visto nada refiriéndose explícitamente a esto, por lo que antes de meter la pata, prefiero preguntaros, que seguro que sabéis más que yo. Si vas a hacer algo que se parezca a debconf, hazlo con debconf, pues debconf existe precisamente para que la gente no tenga que reinventar la rueda. No, no me planteaba hacer un «debconf» alternativo, sino usarlo o no -la verdad es que mi explicación no ha sido demasiado clara-. En cualquier caso debe ser posible configurar el programa cambiando lo que haga falta (a mano, con cualquier editor) en /etc. Si la duda consiste en usar debconf o no, pregúntate si el programa en cuestión tiene tantas posibilidades distintas para que sea necesario, o si por el contrario existe alguna configuración común que pueda satisfacer a todos los usuarios. Ejemplo de lo primero: Es bueno que los paquetes de X usen debconf para generar /etc/X11/XF86Config-4 porque si no lo hicieran sería imposible adivinar el tipo de tarjeta que tiene el usuario. Ejemplo de lo segundo: Es bueno que sysvinit no pregunte nada acerca de /etc/inittab porque ya hay un fichero de configuración genérico que más o menos puede servir para todo el mundo, y cuantas menos preguntas (innecesarias) haga un paquete durante la instalación, mejor. Pues muchas gracias por la respuesta, rápida y certera. Saludos y hasta la próxima. -- Juan Manuel García Molina [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dudas sobre debconf/debhelper
Juan Manuel García Molina wrote: Se trata de un programa que para empezar a funcionar, necesita tener una base de datos y un usuario de Postgres. Por tanto, y aquí no hay problemas, el script de instalación se encarga de crear estos dos elementos. El problema ocurre al desinstalar el paquete. Tal y como está pensado, y para ser consecuente y coherente, al desinstalar con la opción «--purge» -y sólamente en ese caso-, se borran tanto el usuario de la base de datos como la propia base de datos. Y esto es lo que genera polémica. Hay gente que opina que la base de datos no debe borrarse en ningún caso y otros -entre los que me encuentro- que opinamos que si existe la creación en un momento, debe existir la operación inversa de la destrucción; si no existiera, dejaríamos basura en el sistema. Efectivamente. Un problema muy parecido se me presentó con smartlist. Si uno hace dpkg --purge smartlist ¿deben borrarse las listas de correo que se crearon? No me acuerdo de si me lo sugirió alguien, pero parecía un poco bestia que se borraran las listas creadas, así que puse una pregunta en el postrm por si acaso. Puede que no sea muy elegante, pero por otro lado tampoco es que esté uno borrando paquetes como este todos los días. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]