Re: entorno grafico en wheezy
si instalas por primera vez con el escritorio por defecto (Gnome 3). este primero intenta instalar gnome-shell pero si tu PC no tiene muchos recursos te intalará "gnome classic" , lo que te/nos pasa cuando no instala ni gnome-shell, ni gnome-classic y nos deja modo texto ya es demaciado extremo de gnome. Yo lo considero un BUG ami tambien me ha pasado lo mismo que con el mismo disco en unas makinas falle y enotras no, apesar de tener graficos de nueva generacion en el caso de las makinas virtuales ; posiblemente no le diste la suficiente RAM -- ** software libre no significa gratis: richard m. stallman http://wiki.debian.org/es/NormasLista#resumen http://wiki.debian.org/es/NormasLista/Gmail http://es.wikipedia.org/wiki/Top-posting -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54952517.9070...@gmail.com
Re: fallo al inciar sistema, systemd y kernel 3.16.0.4 - jessie
El Wed, 17 Dec 2014 18:46:50 -0300 libreydivagante escribió: > > > El 17/12/14 a las 18:28, Angel Claudio Alvarez escribió: > > El Tue, 16 Dec 2014 22:15:31 -0300 > > libreydivagante escribió: > > > >> La verdad es muy dificil dar algun detalle mas. > >> Cuando se prende el pc logra cargar systemd para luego ejecutar > >> aparentemente un "xserver" color negro y alli queda. Tampoco es posible > >> accecer a las ttys desde ctrl + alt + f1,2, etc. No estan, o bien son > >> bloqueados. > >>El modo recuperacion no sirve y el sistema termina decantando en la ya > >> mensionada situacion. > >>Por suerte habia instalado por equivocacion una .iso de "wheezy" desde > >> la cual actualize y cuyo kernel es el 3.2. Es con este si funciona bien > >> systemd y puedo llegar al escritorio y plena funcionalidad. > >> el comando systemctl --failed me arroja un resutaldo de cero fallas. > >>Se podra pesar que es un problema de actualizacion, pero lo dudo > >> mucho, ya que esto mismo me sucedia habiendo instalado una imagen > >> testing "jessie" semanal con escritorio xfce y mismo kernel -3.16.0.4-. > >> Algunas veces lograba hacer que el sistema funcione, increiblemente > >> tipeando cualquier tecla apenas terminada la seleccion del kernel en el > >> grub, cuando comienza a cargar systemd. > >>Quizas como dato sirva que mi pc no posee pila, asi que el tiempo > >> nunca es el correcto, pero no parece ser un fallo de fechas de archivos > >> y logs... > >> > >> P.D.: Se pueden imaginar como estoy putenado a red hat y systemd no? > >> > > > > estas en jessie, no es stable > > > > > Si es nomas lo que te dije en otro mensaje. Pero para niños como tu no > aqui no hay mas escuela. > > "Lo que naturaleza no da, salamanca no presta!" > Lo mismo digo, http://www.sindominio.net/ayuda/preguntas-inteligentes.html > >>Saludos desde el sur. > >> > >> P.D.2.: perdi mi correo "unciegobailando", si alguien sabe como > >> desuscribirlo sin entrar en el mismo... > >> > >> > >> > >> > >> -- > >> To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > >> with a subject of "unsubscribe". Trouble? Contact > >> listmas...@lists.debian.org > >> Archive: https://lists.debian.org/5490d933.6050...@gmail.com > >> > > > > > > > -- > To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: https://lists.debian.org/5491f9ca.1090...@gmail.com > -- Angel Claudio Alvarez -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141219202650.547256ed0e552f63121cf...@angel-alvarez.com.ar
Re: ¿gdebi y shotwell autodesinstalables?
El 19/12/14 a las 17:33, Camaleón escribió: El Fri, 19 Dec 2014 17:20:42 +0100, Manolo Díaz escribió: El viernes, 19 dic 2014, a las 16:11 horas (UTC+1), Camaleón escribió: (...) Sí que es raro, porque al menos gdebi y shotwell los tengo por aplicaciones autónomas, no dependientes de otros paquetes :-? $ apt-cache rdepends gdebi shotwell gdebi Reverse Depends: python-vte python-apt education-common cinnamon-desktop-environment aptoncd Ninguno de esos paquetes depende de gdebi. Se le habrá ido la pinza al "rdepends". shotwell Reverse Depends: shotwell-dbg shotwell-common shotwell-common shotwell-common libgexiv2-2 cinnamon-desktop-environment Lo mismo pasa aquí. Es posible que lo que muestre sean paquetes recomendados por lo que no afecta en este caso (salvo que se tenga habilitada esa opción). Contaba con los recomendados, Aún así. Ninguno de los paquetes python ni aptoncd instalan gdebi. Y no creo que Eduardo tenga instalados "education-common" ni cinnamon-desktop- environment". Exacto. No tengo instalados education-common ni cinnamon-desktop-environment. Si tengo phyton-vte y phyton-apt. y tambíen tenía instalados (ahora ya no) shotwell y shotwell-common. -- www.LinuxCounter.net Registered user #558467 has 2 linux machines -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/m720b1$cc6$1...@ger.gmane.org
Re: sparkweb y openfire
bueno acabo de chequear en http://www.igniterealtime.org/ y la ultima version disponible es la Openfire 3.9.3, donde es que esta disponible la version 3.10.0?? gracias de antemano? El 19/12/2014 13:49, Camaleón escribió: El Fri, 19 Dec 2014 13:32:12 -0500, Ariel escribió: Hola lista tengo un problemita quizas me puedan ayudar, tengo un openfire funcionando correctamente, implemente spaekweb que no es mas que una aplicacion que permite el acceso a este servicio via web y usa flash player, ya yo habia hecho esto antes en otras instituciones y me habia funcionado, resulta que al tratar de conectarme al sparkweb me envia el siguiente error en los logs: org.jivesoftware.openfire.net.StanzaHandler - Closing session due to invalid_namespace in stream header. Namespace: http://www.jabber.com/streams/flash. Connection: org.jivesoftware.openfire.nio.NIOConnection@d944e1 MINA Session: (SOCKET, R: /xxx.xxx.xxx.xxx:58033, L: /xxx.xxx.xxx.xxx:5222, S: 0.0.0.0/0.0.0.0:5222) (...) Parece este bug marcado como resuelto en una versión superior (3.10.0): Flash client connection closing with invalid_namespace error https://igniterealtime.org/issues/browse/OF-806 Saludos, -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/549477d9.6050...@cncc.cult.cu
Re: sparkweb y openfire
El Fri, 19 Dec 2014 13:32:12 -0500, Ariel escribió: > Hola lista tengo un problemita quizas me puedan ayudar, tengo un > openfire funcionando correctamente, implemente spaekweb que no es mas > que una aplicacion que permite el acceso a este servicio via web y usa > flash player, ya yo habia hecho esto antes en otras instituciones y me > habia funcionado, resulta que al tratar de conectarme al sparkweb me > envia el siguiente error en los logs: > > > org.jivesoftware.openfire.net.StanzaHandler - Closing session due to > invalid_namespace in stream header. Namespace: > http://www.jabber.com/streams/flash. Connection: > org.jivesoftware.openfire.nio.NIOConnection@d944e1 MINA Session: > (SOCKET, R: /xxx.xxx.xxx.xxx:58033, L: /xxx.xxx.xxx.xxx:5222, S: > 0.0.0.0/0.0.0.0:5222) (...) Parece este bug marcado como resuelto en una versión superior (3.10.0): Flash client connection closing with invalid_namespace error https://igniterealtime.org/issues/browse/OF-806 Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.19.18.49...@gmail.com
sparkweb y openfire
Hola lista tengo un problemita quizas me puedan ayudar, tengo un openfire funcionando correctamente, implemente spaekweb que no es mas que una aplicacion que permite el acceso a este servicio via web y usa flash player, ya yo habia hecho esto antes en otras instituciones y me habia funcionado, resulta que al tratar de conectarme al sparkweb me envia el siguiente error en los logs: org.jivesoftware.openfire.net.StanzaHandler - Closing session due to invalid_namespace in stream header. Namespace: http://www.jabber.com/streams/flash. Connection: org.jivesoftware.openfire.nio.NIOConnection@d944e1 MINA Session: (SOCKET, R: /xxx.xxx.xxx.xxx:58033, L: /xxx.xxx.xxx.xxx:5222, S: 0.0.0.0/0.0.0.0:5222) no se conecta, de antemano aclaro que ya desabilitar el contrafuegos donde estan corectamente permitidos los puertos eferente a openfire, me puedo conectar con clientes al estilo pidgin sin problemas, y en el apartado de openfire donde se setean los clientes permitidos le puse que permitiera todos, la verdad ni idea de lo que sucede, alguna solucion? o alguien ha pasado ya por esto? gracias de antemano por su acostumbrada ayuda. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54946f2c.8000...@cncc.cult.cu
Re: cgroup y lxc
El Tue, 16 de Dec de 2014, a las 03:58:23PM +, Camaleón dijo: > Bueno, en Debian (y el resto de distribuciones) tienen especial interés > en el uso de LXC, así que no me extrañaría que lo corrigieran antes de > que salga Jessie, siempre y cuando se trate de un bug y el parche no sea > excesivamente intrusivo para que no trastoque nada más. > > Ya nos contarás lo que te vayan diciendo. Bueno, pues no contestaron nada. Pero no me extraña. Estuve curioseando y ahora mismo hay al menos tres modos de gestionar los cgroup: 1. La librería libcg (los paquetes de debian libcgroup1 y cgroup-tools) pertenecen a ella. 2. cgmanager que desarrolla la gente de lxc. 3. systemd. La tercera opción creo que aún no está madura para manegar los cgroups que necesita lxc. Al menos eso es lo que he leído en esta entrada: https://github.com/lxc/lxc/issues/323 No sé si systemd-218 ha solucionado esto o no, según se puede leer al final de los comentarios. En cualquier caso en jessie viene systemd-215. La segunda opción es la que he visto usada para lo que quiero en todas las guías. La primera fue la que se me antojó utilizar, porque me permitía más elegantemente automatizar todo, pero al meterme en su página de sourceforge he visto que no se ha desarrollado nada desde enero de 2014. Además he visto que cgrulesengd tiene un problema: se tarda un minúsculo tiempo entre que se crea el proceso y cgrulengd lo pasa al cgroup que indican las reglas. Si durante este pequeño tiempo la aplicación en cuestión lanza un proceso hijo, resulta que este proceso hijo no pertenecerá al cgroup en donde aún estará el padre y no se mudará con él. En fedora 21, por ejemplo, que me bajé para comprobar si me encontraba con los mismos problemas que en debian, ha desaparecido parcialmente (aún se puede instalar cgconfigparser, pero no cgrulesengd). Y el futuro es que desaparezca totalmente en favor de la gestión con systemd. Total, que me sospecho que el futuro es utilizar bien systemd o, como alternativa para el systémdfobo, cgmanager. Como mi intención es montar todo esto en una jessie, voy a tirar por la calle de enmedio y usaré cgconfigparser para crear un cgroup inicial (lxc), el script para pam para crear con cgcreate el cgroup de cada usuario, y "cgexec" para lanzar lxc-start en este cgroup particular de usuario. Lo último es un tanto engorroso, pero como todo estará incluido en un script, no se tendrá que hacer manualmente. Saludos. -- Dejemos metafísicas quimeras; vuesas mercedes garlen en chacota: que no está el mundo para hablar de veras. --- Tomé de Burguillos --- -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141219174812.ga6...@cubo.casa
Re: ¿gdebi y shotwell autodesinstalables?
El Fri, 19 Dec 2014 17:20:42 +0100, Manolo Díaz escribió: > El viernes, 19 dic 2014, a las 16:11 horas (UTC+1), > Camaleón escribió: (...) Sí que es raro, porque al menos gdebi y shotwell los tengo por aplicaciones autónomas, no dependientes de otros paquetes :-? >>> >>> $ apt-cache rdepends gdebi shotwell gdebi Reverse Depends: >>> python-vte python-apt education-common cinnamon-desktop-environment >>> aptoncd >> >>Ninguno de esos paquetes depende de gdebi. Se le habrá ido la pinza al >>"rdepends". >> >>> shotwell Reverse Depends: >>> shotwell-dbg shotwell-common shotwell-common shotwell-common >>> libgexiv2-2 cinnamon-desktop-environment >> >>Lo mismo pasa aquí. >> >>Es posible que lo que muestre sean paquetes recomendados por lo que no >>afecta en este caso (salvo que se tenga habilitada esa opción). > > Contaba con los recomendados, Aún así. Ninguno de los paquetes python ni aptoncd instalan gdebi. Y no creo que Eduardo tenga instalados "education-common" ni cinnamon-desktop- environment". > con los que no contaba son los incompatibles: así que si python-apt > rompe a gdebi, las dependencias inversas de este último muestra al > primero. Vaya chasco. Sin más parece significar "cualquier paquete que > lo muestre en alguna de sus cabeceras", lo que es algo vago. (...) Exacto. No sé dónde me pareció leer (¿sería en un bug? :-?) que el parámetro "rdepends" iba un poco a su bola, vamos, que no era fiable al 100% precisamente por eso, porque generaba unos resultados demasiado amplios. > Nadie depende ya de gdebi, por lo que solo quedará instalado si se marca > manualmente. Ni tampoco "shotwell", son dos paquetes demasiado específicos como para que alguien los instale por dependencias indirectas. Quizá, en todo caso, algún metapaquete de entorno de escritorio. > Por cierto, es al contrario: de forma predeterminada se instalan también > los paquetes recomendados salvo que el administrador decida lo > contrario, ya sea puntualmente o de forma general. Cierto, aunque es habitual desactivarlo. Bueno, vale... digamos que yo siempre lo desactivo y eso no cuenta O:-) Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.19.16.33...@gmail.com
Re: ¿gdebi y shotwell autodesinstalables?
El viernes, 19 dic 2014, a las 16:11 horas (UTC+1), Camaleón escribió: >El Tue, 16 Dec 2014 19:35:34 +0100, Manolo Díaz escribió: > >> El martes, 16 dic 2014, a las 19:23 horas (UTC+1), >> Camaleón escribió: > >(...) > >>>Sí que es raro, porque al menos gdebi y shotwell los tengo por >>>aplicaciones autónomas, no dependientes de otros paquetes :-? >> >> $ apt-cache rdepends gdebi shotwell >> gdebi >> Reverse Depends: >> python-vte python-apt education-common cinnamon-desktop-environment >> aptoncd > >Ninguno de esos paquetes depende de gdebi. Se le habrá ido la pinza al >"rdepends". > >> shotwell >> Reverse Depends: >> shotwell-dbg shotwell-common shotwell-common shotwell-common >> libgexiv2-2 cinnamon-desktop-environment > >Lo mismo pasa aquí. > >Es posible que lo que muestre sean paquetes recomendados por lo que no >afecta en este caso (salvo que se tenga habilitada esa opción). Contaba con los recomendados, con los que no contaba son los incompatibles: así que si python-apt rompe a gdebi, las dependencias inversas de este último muestra al primero. Vaya chasco. Sin más parece significar "cualquier paquete que lo muestre en alguna de sus cabeceras", lo que es algo vago. Por supuesto existen parámetros modificadores, pero son negativos, excluyen, y poner todos los necesarios se hace incómodo. apt-cache rdepends --no-recommends --no-suggests --no-conflicts \ --no-breaks --no-replaces --no-enhances gdebi shotwell gdebi Reverse Depends: shotwell Reverse Depends: shotwell-dbg Nadie depende ya de gdebi, por lo que solo quedará instalado si se marca manualmente. Por cierto, es al contrario: de forma predeterminada se instalan también los paquetes recomendados salvo que el administrador decida lo contrario, ya sea puntualmente o de forma general. >Saludos, Saludos. -- Manolo Díaz -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141219172042.347c5...@gmail.com
Re: Servidores ejabberd que no se comunican
El Fri, 19 Dec 2014 10:40:46 -0500, Richard Díaz Rodríguez escribió: > Hola a todos los amigos de la lista tengo 2 servers jabber montados, > configurados y pinchando con sus users pero uno esta en un dominio > pepe.cuba.america.cu y el otro es un server que esta en un subdominio de > cuba.america.cu ejemplo subdominio.cuba.america.cu "pepe.cuba.america.cu" también es un subdominio, es decir, es igual que "subdominio.cuba.america.cu". > no logro que los dos servidores se comuniquen los dos server estan en > redes diferentes y tras servidores Firewall pero ya los puertos de > comunicacion 5222,5269 entre estos dos servers estan abiertos > simplemente cuando intentas agrgar un amigo de un server en el otro da > Error:404: No se encontró el servidor remoto En el registro de ejabberd tendrás más información del problema, además del error 404. En cualquier caso, comprueba que el cliente desde el que quieres añadir un contacto puede resolver correctamente el dominio del servidor ejabberd: host subdominio.cuba.america.cu Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.19.16.20...@gmail.com
de Alberto Cabrejas Pérez
El 19/12/2014 10:40, Richard Díaz Rodríguez escribió: Hola a todos los amigos de la lista tengo 2 servers jabber montados, configurados y pinchando con sus users pero uno esta en un dominio pepe.cuba.america.cu y el otro es un server que esta en un subdominio de cuba.america.cu ejemplo subdominio.cuba.america.cu no logro que los dos servidores se comuniquen los dos server estan en redes diferentes y tras servidores Firewall pero ya los puertos de comunicacion 5222,5269 entre estos dos servers estan abiertos simplemente cuando intentas agrgar un amigo de un server en el otro da Error:404: No se encontró el servidor remoto Muchas gracias de antemano - Has telnet a los puertos que describes desde la estacion y desde los servidores a ver si se ven entre ellos y ven tu dns, revisa los certificados tls-ssl si tienes. -- Saludos, *Alberto Cabrejas Pérez* Administrador de Redes Informáticas ARTex S.A. Sucursal Granma http://www.artexsa.com http://www.scgra.artex.sa Linux Usuario Registrado # 31 666 Teléf.(0123) 48-1956, 48-1912, 48-1934 (Ext 107) Las autoridades sanitarias advierten: "El uso prolongado de Microsoft Windows provoca dependencia..."
Servidores ejabberd que no se comunican
Hola a todos los amigos de la lista tengo 2 servers jabber montados, configurados y pinchando con sus users pero uno esta en un dominio pepe.cuba.america.cu y el otro es un server que esta en un subdominio de cuba.america.cu ejemplo subdominio.cuba.america.cu no logro que los dos servidores se comuniquen los dos server estan en redes diferentes y tras servidores Firewall pero ya los puertos de comunicacion 5222,5269 entre estos dos servers estan abiertos simplemente cuando intentas agrgar un amigo de un server en el otro da Error:404: No se encontró el servidor remoto Muchas gracias de antemano -- Tec.Richard Diaz Rodriguez Administrador de Red UEB Fibrocementos Sancti Spiritus Grupo de Usuarios de Tecnologías Libres en Cuba -»http://gutl.jovenclub.cu/ http://counter.li.org/ -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/35687d75368430e5335dbafda94da...@ss.perdurit.com.cu
Re: ¿gdebi y shotwell autodesinstalables?
El Tue, 16 Dec 2014 19:35:34 +0100, Manolo Díaz escribió: > El martes, 16 dic 2014, a las 19:23 horas (UTC+1), > Camaleón escribió: (...) >>Sí que es raro, porque al menos gdebi y shotwell los tengo por >>aplicaciones autónomas, no dependientes de otros paquetes :-? > > $ apt-cache rdepends gdebi shotwell > gdebi > Reverse Depends: > python-vte python-apt education-common cinnamon-desktop-environment > aptoncd Ninguno de esos paquetes depende de gdebi. Se le habrá ido la pinza al "rdepends". > shotwell > Reverse Depends: > shotwell-dbg shotwell-common shotwell-common shotwell-common > libgexiv2-2 cinnamon-desktop-environment Lo mismo pasa aquí. Es posible que lo que muestre sean paquetes recomendados por lo que no afecta en este caso (salvo que se tenga habilitada esa opción). Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.19.15.11...@gmail.com
Re: ¿gdebi y shotwell autodesinstalables?
El Thu, 18 Dec 2014 20:12:47 +0100, Eduardo Rios escribió: > El 18/12/14 a las 19:52, Camaleón escribió: (...) >>> Resumiendo, que efectivamente, prescinden de gdebi. Y lo mismo debe >>> pasar con shotwell. >> >> Yo tengo ambos instalados en Jessie con GNOME y ningún gestor de >> paquetes me ha pedido que los elimine por lo que siguen ahí. > > Pues no entiendo nada... Alguna actualización habré hecho con inestable > o experimental sin darme cuenta o algo (aunque solo los activo para > actualizar iceweasel/icedove y luego los vuelvo a desactivar)... Seguramente algún paquete que hayas instalado necesitaba gdebi y shotwell, los instaló en su momento y ahora ese paquete ya no existe (porque se haya reemplazado por una versión superior que no dependa de gedbi ni shotwell) y de ahí que ahora te los marcara para eliminar automáticamente. >> De todas formas, a simple vista no veo reemplazo para ninguno de los >> dos: gdebi sigue estando disponible en los repos (entiendo que sigue >> siendo útil en entornos donde no esté instalado gnome) y shotwell sigue >> siendo el gestor de fotos predeterminado. > > Bueno, a mi las imágenes por defecto se me abren con eog (Eye of > GNOME)... El ojo de GNOME es un visor de imágenes no un gestor de fotos ;-) > No sé, curioso es un rato... Atribuimos a la magia las cosas que no recordamos. Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pan.2014.12.19.14.56...@gmail.com
