Re: Paquetes snap sin snap.

[JavierDebian]

El 30/3/24 a las 19:50, Carlos Villiere escribió:

El sáb, 30 mar 2024 a las 15:02, Camaleón (<mailto:noela...@gmail.com>>) escribió:


El 2024-03-30 a las 09:23 -0300, JavierDebian escribió:
 >
 > El 30/3/24 a las 05:50, Camaleón escribió:
 > > El 2024-03-29 a las 09:07 -0300, JavierDebian escribió:
 > >
 > > > El 29/3/24 a las 06:49, Listas escribió:
 > > > > El jue, 28-03-2024 a las 14:59 -0300, JavierDebian escribió:
 > > > > > Buenas tardes.
 > > > > >
 > > > > > Proyecto para mi fin de semana:
 > > > > >
 > > > > > Instalar paquetes de SNAP sin instalar Snap.
 > > > > > Odio Snap.
 > > > >
 > > > > ¿Hay alguna razón para necesitar que sea un paquete snap?
 > > > > Quiero decir, ¿no está empaquetado en la distribución? ¿no se
 > > > > distribuye en otro formato?
 > > > >
 > > > > >
 > > > > > ¿Alguien tiene alguna idea o intentó algo?
 > > > >
 > > > > Nunca utilizé snap pero se podría buscar otro tipo de
contenedor, como
 > > > > un docker o similar, o simplemente compilarlo si está
disponible el
 > > > > código.
 > > > >
 > > > > Un saludo
 > > > >
 > > >
 > > > Buen día para todos y esperanza fundada para aquellos que
somos creyentes.
 > > >
 > > > El paquete en cuestión es Geogebra.
 > >
 > > (...)
 > >
 > > Parece que están reduciendo el soporte de la aplicación en Linux:
 > >
 > > 
 > > Can we expect an up-to-date Linux application package in the
near future?
 > >
https://www.reddit.com/r/geogebra/comments/17e0rpb/comment/k60gd50/
<https://www.reddit.com/r/geogebra/comments/17e0rpb/comment/k60gd50/>
 > >
 > > mike_geogebra / hace 5 m
 > >
 > > Sorry, the only official way to run GeoGebra on Linux is in the
Chrome
 > > browser, or
 > >

https://wiki.geogebra.org/en/Reference:GeoGebra_Installation#GeoGebra_Classic_5_for_Desktop
 
<https://wiki.geogebra.org/en/Reference:GeoGebra_Installation#GeoGebra_Classic_5_for_Desktop>
 > > 
 >
 >
 > Justamente lo que decía.
 > Es una API de Chrome.
 > Se puede correr "stand alone" si uno revuelve la página de
descarga, que
 > hasta ahora no la han bloqueado para un acceso de fuerza bruta.
 > El sitio es
 > https://download.geogebra.org/installers/6.0
<https://download.geogebra.org/installers/6.0> y el paquete es
 > GeoGebra-Linux64-Portable-6-0-804-0.zip
 > No es fácil llegar, dado que no hay enlace alguno.
 > Lo que está está en SNAP, justamente, lo que hace es bajar esa
API y al
 > hacerla correr en modo "independiente" (no se ve el navegador),
parece que
 > es un paquete autónomo.
 > No me molesta correrlo así, lo que me molesta es SNAP.

No veo dependencia estricta/directa con Snap :-?

Si hay .deb de la versión 6.0 clásica para la arquitectura armhf¹, y
está disponible en otras distribuciones (Gentoo, Archlinux...) el
problema entonces que que NO hay nadie que lo empaquete para amd64 en
Debian, pero no parece una limitación impuesta por el desarrollador.


¹https://download.geogebra.org/installers/6.0/geogebra-classic_6.0.609.0-202010060653_armhf.deb
 
<https://download.geogebra.org/installers/6.0/geogebra-classic_6.0.609.0-202010060653_armhf.deb>
²https://packages.gentoo.org/packages/sci-mathematics/geogebra-bin
<https://packages.gentoo.org/packages/sci-mathematics/geogebra-bin>
³https://archlinux.org/packages/extra/x86_64/geogebra/
<https://archlinux.org/packages/extra/x86_64/geogebra/>

Saludos,

-- 
Camaleón



> ¡Hola a todos!
> Tengo una versión para amd64 que corro en Debian 11 sin problemas y no
> tengo inconveniente en compartirla con ustedes. Lo que no sé,¿cómo
> hacerlas llegar?
> El archivo es geogebra-clasic_6.0.666.0-202109211234_amd64.deb
> Saludos
>

¿Dónde la bajaste?¿O la empaquetaste vos?

Saludos.

JAP

Re: Paquetes snap sin snap.

[Carlos Villiere]

¡Hola a todos!
Tengo una versión para amd64 que corro en Debian 11 sin problemas y no
tengo inconveniente en compartirla con ustedes. Lo que no sé,¿cómo hacerlas
llegar?
El archivo es geogebra-clasic_6.0.666.0-202109211234_amd64.deb
Saludos

El sáb, 30 mar 2024 a las 15:02, Camaleón () escribió:

> El 2024-03-30 a las 09:23 -0300, JavierDebian escribió:
> >
> > El 30/3/24 a las 05:50, Camaleón escribió:
> > > El 2024-03-29 a las 09:07 -0300, JavierDebian escribió:
> > >
> > > > El 29/3/24 a las 06:49, Listas escribió:
> > > > > El jue, 28-03-2024 a las 14:59 -0300, JavierDebian escribió:
> > > > > > Buenas tardes.
> > > > > >
> > > > > > Proyecto para mi fin de semana:
> > > > > >
> > > > > > Instalar paquetes de SNAP sin instalar Snap.
> > > > > > Odio Snap.
> > > > >
> > > > > ¿Hay alguna razón para necesitar que sea un paquete snap?
> > > > > Quiero decir, ¿no está empaquetado en la distribución? ¿no se
> > > > > distribuye en otro formato?
> > > > >
> > > > > >
> > > > > > ¿Alguien tiene alguna idea o intentó algo?
> > > > >
> > > > > Nunca utilizé snap pero se podría buscar otro tipo de contenedor,
> como
> > > > > un docker o similar, o simplemente compilarlo si está disponible el
> > > > > código.
> > > > >
> > > > > Un saludo
> > > > >
> > > >
> > > > Buen día para todos y esperanza fundada para aquellos que somos
> creyentes.
> > > >
> > > > El paquete en cuestión es Geogebra.
> > >
> > > (...)
> > >
> > > Parece que están reduciendo el soporte de la aplicación en Linux:
> > >
> > > 
> > > Can we expect an up-to-date Linux application package in the near
> future?
> > > https://www.reddit.com/r/geogebra/comments/17e0rpb/comment/k60gd50/
> > >
> > > mike_geogebra / hace 5 m
> > >
> > > Sorry, the only official way to run GeoGebra on Linux is in the Chrome
> > > browser, or
> > >
> https://wiki.geogebra.org/en/Reference:GeoGebra_Installation#GeoGebra_Classic_5_for_Desktop
> > > 
> >
> >
> > Justamente lo que decía.
> > Es una API de Chrome.
> > Se puede correr "stand alone" si uno revuelve la página de descarga, que
> > hasta ahora no la han bloqueado para un acceso de fuerza bruta.
> > El sitio es
> > https://download.geogebra.org/installers/6.0 y el paquete es
> > GeoGebra-Linux64-Portable-6-0-804-0.zip
> > No es fácil llegar, dado que no hay enlace alguno.
> > Lo que está está en SNAP, justamente, lo que hace es bajar esa API y al
> > hacerla correr en modo "independiente" (no se ve el navegador), parece
> que
> > es un paquete autónomo.
> > No me molesta correrlo así, lo que me molesta es SNAP.
>
> No veo dependencia estricta/directa con Snap :-?
>
> Si hay .deb de la versión 6.0 clásica para la arquitectura armhf¹, y
> está disponible en otras distribuciones (Gentoo, Archlinux...) el
> problema entonces que que NO hay nadie que lo empaquete para amd64 en
> Debian, pero no parece una limitación impuesta por el desarrollador.
>
> ¹
> https://download.geogebra.org/installers/6.0/geogebra-classic_6.0.609.0-202010060653_armhf.deb
> ²https://packages.gentoo.org/packages/sci-mathematics/geogebra-bin
> ³https://archlinux.org/packages/extra/x86_64/geogebra/
>
> Saludos,
>
> --
> Camaleón
>
>

Re: Paquetes snap sin snap.

[Camaleón]

El 2024-03-30 a las 09:23 -0300, JavierDebian escribió:
> 
> El 30/3/24 a las 05:50, Camaleón escribió:
> > El 2024-03-29 a las 09:07 -0300, JavierDebian escribió:
> > 
> > > El 29/3/24 a las 06:49, Listas escribió:
> > > > El jue, 28-03-2024 a las 14:59 -0300, JavierDebian escribió:
> > > > > Buenas tardes.
> > > > > 
> > > > > Proyecto para mi fin de semana:
> > > > > 
> > > > > Instalar paquetes de SNAP sin instalar Snap.
> > > > > Odio Snap.
> > > > 
> > > > ¿Hay alguna razón para necesitar que sea un paquete snap?
> > > > Quiero decir, ¿no está empaquetado en la distribución? ¿no se
> > > > distribuye en otro formato?
> > > > 
> > > > > 
> > > > > ¿Alguien tiene alguna idea o intentó algo?
> > > > 
> > > > Nunca utilizé snap pero se podría buscar otro tipo de contenedor, como
> > > > un docker o similar, o simplemente compilarlo si está disponible el
> > > > código.
> > > > 
> > > > Un saludo
> > > > 
> > > 
> > > Buen día para todos y esperanza fundada para aquellos que somos creyentes.
> > > 
> > > El paquete en cuestión es Geogebra.
> > 
> > (...)
> > 
> > Parece que están reduciendo el soporte de la aplicación en Linux:
> > 
> > 
> > Can we expect an up-to-date Linux application package in the near future?
> > https://www.reddit.com/r/geogebra/comments/17e0rpb/comment/k60gd50/
> > 
> > mike_geogebra / hace 5 m
> > 
> > Sorry, the only official way to run GeoGebra on Linux is in the Chrome
> > browser, or
> > https://wiki.geogebra.org/en/Reference:GeoGebra_Installation#GeoGebra_Classic_5_for_Desktop
> > 
> 
> 
> Justamente lo que decía.
> Es una API de Chrome.
> Se puede correr "stand alone" si uno revuelve la página de descarga, que
> hasta ahora no la han bloqueado para un acceso de fuerza bruta.
> El sitio es
> https://download.geogebra.org/installers/6.0 y el paquete es
> GeoGebra-Linux64-Portable-6-0-804-0.zip
> No es fácil llegar, dado que no hay enlace alguno.
> Lo que está está en SNAP, justamente, lo que hace es bajar esa API y al
> hacerla correr en modo "independiente" (no se ve el navegador), parece que
> es un paquete autónomo.
> No me molesta correrlo así, lo que me molesta es SNAP.

No veo dependencia estricta/directa con Snap :-?

Si hay .deb de la versión 6.0 clásica para la arquitectura armhf¹, y 
está disponible en otras distribuciones (Gentoo, Archlinux...) el 
problema entonces que que NO hay nadie que lo empaquete para amd64 en 
Debian, pero no parece una limitación impuesta por el desarrollador.

¹https://download.geogebra.org/installers/6.0/geogebra-classic_6.0.609.0-202010060653_armhf.deb
²https://packages.gentoo.org/packages/sci-mathematics/geogebra-bin
³https://archlinux.org/packages/extra/x86_64/geogebra/

Saludos,

-- 
Camaleón 

Re: Paquetes snap sin snap.

[JavierDebian]

El 30/3/24 a las 05:50, Camaleón escribió:

El 2024-03-29 a las 09:07 -0300, JavierDebian escribió:


El 29/3/24 a las 06:49, Listas escribió:

El jue, 28-03-2024 a las 14:59 -0300, JavierDebian escribió:

Buenas tardes.

Proyecto para mi fin de semana:

Instalar paquetes de SNAP sin instalar Snap.
Odio Snap.


¿Hay alguna razón para necesitar que sea un paquete snap?
Quiero decir, ¿no está empaquetado en la distribución? ¿no se
distribuye en otro formato?



¿Alguien tiene alguna idea o intentó algo?


Nunca utilizé snap pero se podría buscar otro tipo de contenedor, como
un docker o similar, o simplemente compilarlo si está disponible el
código.

Un saludo



Buen día para todos y esperanza fundada para aquellos que somos creyentes.

El paquete en cuestión es Geogebra.


(...)

Parece que están reduciendo el soporte de la aplicación en Linux:


Can we expect an up-to-date Linux application package in the near future?
https://www.reddit.com/r/geogebra/comments/17e0rpb/comment/k60gd50/

mike_geogebra / hace 5 m

Sorry, the only official way to run GeoGebra on Linux is in the Chrome
browser, or
https://wiki.geogebra.org/en/Reference:GeoGebra_Installation#GeoGebra_Classic_5_for_Desktop


Saludos,




Justamente lo que decía.
Es una API de Chrome.
Se puede correr "stand alone" si uno revuelve la página de descarga, que 
hasta ahora no la han bloqueado para un acceso de fuerza bruta.

El sitio es
https://download.geogebra.org/installers/6.0 y el paquete es
GeoGebra-Linux64-Portable-6-0-804-0.zip
No es fácil llegar, dado que no hay enlace alguno.
Lo que está está en SNAP, justamente, lo que hace es bajar esa API y al 
hacerla correr en modo "independiente" (no se ve el navegador), parece 
que es un paquete autónomo.

No me molesta correrlo así, lo que me molesta es SNAP.

Saludos.

Re: Paquetes snap sin snap.

[Camaleón]

El 2024-03-29 a las 09:07 -0300, JavierDebian escribió:

> El 29/3/24 a las 06:49, Listas escribió:
> > El jue, 28-03-2024 a las 14:59 -0300, JavierDebian escribió:
> > > Buenas tardes.
> > > 
> > > Proyecto para mi fin de semana:
> > > 
> > > Instalar paquetes de SNAP sin instalar Snap.
> > > Odio Snap.
> > 
> > ¿Hay alguna razón para necesitar que sea un paquete snap?
> > Quiero decir, ¿no está empaquetado en la distribución? ¿no se
> > distribuye en otro formato?
> > 
> > > 
> > > ¿Alguien tiene alguna idea o intentó algo?
> > 
> > Nunca utilizé snap pero se podría buscar otro tipo de contenedor, como
> > un docker o similar, o simplemente compilarlo si está disponible el
> > código.
> > 
> > Un saludo
> > 
> 
> Buen día para todos y esperanza fundada para aquellos que somos creyentes.
> 
> El paquete en cuestión es Geogebra.

(...)

Parece que están reduciendo el soporte de la aplicación en Linux:


Can we expect an up-to-date Linux application package in the near future? 
https://www.reddit.com/r/geogebra/comments/17e0rpb/comment/k60gd50/

mike_geogebra / hace 5 m

Sorry, the only official way to run GeoGebra on Linux is in the Chrome 
browser, or 
https://wiki.geogebra.org/en/Reference:GeoGebra_Installation#GeoGebra_Classic_5_for_Desktop


Saludos, 

-- 
Camaleón 

Re: Paquetes snap sin snap.

[JavierDebian]

El 29/3/24 a las 14:11, Listas escribió:

El vie, 29-03-2024 a las 09:07 -0300, JavierDebian escribió:




El paquete en cuestión es Geogebra.
Los repositorios están sólo hasta la versión 4.
En una distro de por ahí, creo que Arch, está empaquetada la 5.
Pero la actual 6 sólo por snap para instalar, o un "standalone" que
funciona como api autónoma de Chrome, que es la que estoy usando
ahora.
Pero no es algo que me guste.

Tenían un repositorio, www.geogebra.net, que desapareció.
Y encontrar la api, cuesta mucho dado que la página de descarga esta
hecha por un tuerto con glaucoma.
Si se pulsa la descarga, sólo aparece Windows.
Pero si se revuelve el sitio, hay otras opciones, como la api esta
que
mencioné.
https://download.geogebra.org/installers/6.0

Estaba viendo d cómo empaquetarla y subirla a algún lado, para uso
más
"natural".


Veo que tienen un repositorio en https://github.com/geogebra/geogebra
Siguiendo las instrucciones puedes hacerlo funcionar en local en
versión desktop o servidor web.

Un saludo



Sí, la versión 5.

JAP

Re: Paquetes snap sin snap.

[Listas]

El vie, 29-03-2024 a las 09:07 -0300, JavierDebian escribió:
> 
> 
> 
> El paquete en cuestión es Geogebra.
> Los repositorios están sólo hasta la versión 4.
> En una distro de por ahí, creo que Arch, está empaquetada la 5.
> Pero la actual 6 sólo por snap para instalar, o un "standalone" que 
> funciona como api autónoma de Chrome, que es la que estoy usando
> ahora.
> Pero no es algo que me guste.
> 
> Tenían un repositorio, www.geogebra.net, que desapareció.
> Y encontrar la api, cuesta mucho dado que la página de descarga esta 
> hecha por un tuerto con glaucoma.
> Si se pulsa la descarga, sólo aparece Windows.
> Pero si se revuelve el sitio, hay otras opciones, como la api esta
> que 
> mencioné.
> https://download.geogebra.org/installers/6.0
> 
> Estaba viendo d cómo empaquetarla y subirla a algún lado, para uso
> más 
> "natural".

Veo que tienen un repositorio en https://github.com/geogebra/geogebra
Siguiendo las instrucciones puedes hacerlo funcionar en local en
versión desktop o servidor web.

Un saludo

Re: Paquetes snap sin snap.

[JavierDebian]

El 29/3/24 a las 06:49, Listas escribió:

El jue, 28-03-2024 a las 14:59 -0300, JavierDebian escribió:

Buenas tardes.

Proyecto para mi fin de semana:

Instalar paquetes de SNAP sin instalar Snap.
Odio Snap.


¿Hay alguna razón para necesitar que sea un paquete snap?
Quiero decir, ¿no está empaquetado en la distribución? ¿no se
distribuye en otro formato?



¿Alguien tiene alguna idea o intentó algo?


Nunca utilizé snap pero se podría buscar otro tipo de contenedor, como
un docker o similar, o simplemente compilarlo si está disponible el
código.

Un saludo



Buen día para todos y esperanza fundada para aquellos que somos creyentes.

El paquete en cuestión es Geogebra.
Los repositorios están sólo hasta la versión 4.
En una distro de por ahí, creo que Arch, está empaquetada la 5.
Pero la actual 6 sólo por snap para instalar, o un "standalone" que 
funciona como api autónoma de Chrome, que es la que estoy usando ahora.

Pero no es algo que me guste.

Tenían un repositorio, www.geogebra.net, que desapareció.
Y encontrar la api, cuesta mucho dado que la página de descarga esta 
hecha por un tuerto con glaucoma.

Si se pulsa la descarga, sólo aparece Windows.
Pero si se revuelve el sitio, hay otras opciones, como la api esta que 
mencioné.

https://download.geogebra.org/installers/6.0

Estaba viendo d cómo empaquetarla y subirla a algún lado, para uso más 
"natural".


Saludos

JAP

Re: Paquetes snap sin snap.

[Listas]

El jue, 28-03-2024 a las 14:59 -0300, JavierDebian escribió:
> Buenas tardes.
> 
> Proyecto para mi fin de semana:
> 
> Instalar paquetes de SNAP sin instalar Snap.
> Odio Snap.

¿Hay alguna razón para necesitar que sea un paquete snap?
Quiero decir, ¿no está empaquetado en la distribución? ¿no se
distribuye en otro formato?

> 
> ¿Alguien tiene alguna idea o intentó algo?

Nunca utilizé snap pero se podría buscar otro tipo de contenedor, como
un docker o similar, o simplemente compilarlo si está disponible el
código.

Un saludo

Re: Paquetes snap sin snap.

[Camaleón]

El 2024-03-28 a las 14:59 -0300, JavierDebian escribió:

> Buenas tardes.
> 
> Proyecto para mi fin de semana:

Aquí en España tenemos un fin de semana «extendido» de 4 días (en 
algunas comunidades) por ser festivo de Pascua :-)
 
> Instalar paquetes de SNAP sin instalar Snap.
> Odio Snap.
> 
> ¿Alguien tiene alguna idea o intentó algo?

Se supone que la ventaja (ejem) de usar Snap es la facilidad (que la 
proporciona snapd) y la seguridad (que la proporciona squashfs y 
Apparmor).

De hecho, en Debian el paquete snapd depende¹ de squashfs, apparmour y 
systemd. 

Pero técnicamente debería ser posible ejecutar un paquete snap sin tener
la morralla instalada. Ahora bien... el resultado puede funcionar o no 
(apartado «Running snaps without snapd»):

Canonical shows how to use Snaps without the Snap Store
https://www.theregister.com/2023/11/10/snap_without_ubuntu_tools/

Sin tener instalado snapd auguro problemas habituales de dependencias 
no satisfechas y bibliotecas incompatibles, es decir, problemas mil 
dependiendo de cómo esté «esnapeada» (empaqueteda) cada aplicación.

En suma, que te espera una buena «penitencia» >:-)

¹https://packages.debian.org/bookworm/snapd

Saludos,

-- 
Camaleón 

Re: Paquetes snap sin snap.

[Aradenatorix Veckhôm Avecælus]

Hola:

Como tampoco me gusta snap ni flatpak, una solución para mí a esto, además
de lo que comenta N4ch0, ha sido usar AppImage. Tiene la bondad de que
solamente se ejecuta cuando hace falta, algunos se pueden actualizar y si
no quieres que ocupen espacio en disco duro, puedes tenerlos almacenados en
un pendrive USB.
Desafortunadamente, no todos los programas que encuentras en snap o flatpak
cuentan con versión en AppImage. Pero me parece una opción interesante a
contemplar.

Saludos

Re: Paquetes snap sin snap.

[N4ch0]

On Thu Mar 28, 2024 at 2:59 PM -03, JavierDebian wrote:
> Buenas tardes.
>
> Proyecto para mi fin de semana:
>
> Instalar paquetes de SNAP sin instalar Snap.
> Odio Snap.
>
> ¿Alguien tiene alguna idea o intentó algo?
>
> Saludos

Buenas!

La pregunta sería que aplicación es para que debas usar snap? por mi
parte evito al 100% snap y flatpack o como se llame, jamás lo usé ni pienso, 
sino
exite el .deb bajo las fuentes y lo compilo.

Paquetes snap sin snap.

[JavierDebian]

Buenas tardes.

Proyecto para mi fin de semana:

Instalar paquetes de SNAP sin instalar Snap.
Odio Snap.

¿Alguien tiene alguna idea o intentó algo?

Saludos

Re: Paquetes fuera de Distro

[Roberto José Blandino Cisneros]

El 20/1/24 a las 11:19, JA CM escribió:
Hace poco actualicé a Debian 12 y ahora me salta una actualización de 
VisualCode desde el propio programa, pero no desde los repositorios. 
No es que necesite actualizar de la 1.85.1 a la 1.85.2 pero me planteo 
la siguiente pregunta.
Si quisiera actualizar ese programa según la página del propio 
programa y sus propios lanzamientos ¿cómo podría hacerlo? ¿dpkg? ¿apt? 
Synaptic? ¿cómo afectaría eso a futuras actualizaciones del SO?
¿Seríais tan amables de facilitarme links para aprender acerca de las 
actualizaciones de paquetes fuera de las fuentes de la distribución y 
sus consecuencias?


Si son paquetes fuera de distro, sigue las indicaciones del autor del 
paquete. La actualización se hace fuera de distro, igual que el dbeaver, 
necesitas bajarlo desde su página oficial si usas el programa fuera de 
distro, si usas el compilado propio de la distro, tendrás que aguantar 
siempre el mensaje de que hay una nueva versión disponible.

Muchas gracias y un saludo


Saludos.

Re: listar paquetes desinstalados con configuración residual

[Gonzalo Rivero]

El 30/1/24 a las 12:30, Alfonso Camacho escribió:

Saludos:

- Mensaje original -

De: "Gonzalo Rivero" 
Para: "debian-user-spanish" 
Enviados: Martes, 30 de Enero 2024 16:15:36
Asunto: listar paquetes desinstalados con configuración residual
gu mornin todos,

lo que quiero averiguar es como debería buscar con apt los paquetes que
fueron desinstalados con

apt-get remove 

así puedo sacarlos con apt-get --purge remove 

normalmente hacía esto con synaptic, hacía click con el mouse y sabía
que paquetes me habían dejado "basura" en el disco, pero esta
instalación no estoy usando nada gráfico y no se me ocurre como hacer el
apt-cache search

# apt purge $(dpkg --get-selections | grep deinstall | awk '{ print $1 }')



genial, no se me había ocurrido bajar a dpkg, pero mostró (y purgó) el 
paquete que acababa de desinstalar para probar.



Gracias

Re: listar paquetes desinstalados con configuración residual

[Alfonso Camacho]

Saludos:

- Mensaje original -
> De: "Gonzalo Rivero" 
> Para: "debian-user-spanish" 
> Enviados: Martes, 30 de Enero 2024 16:15:36
> Asunto: listar paquetes desinstalados con configuración residual

> gu mornin todos,
> 
> lo que quiero averiguar es como debería buscar con apt los paquetes que
> fueron desinstalados con
> 
> apt-get remove 
> 
> así puedo sacarlos con apt-get --purge remove 
> 
> normalmente hacía esto con synaptic, hacía click con el mouse y sabía
> que paquetes me habían dejado "basura" en el disco, pero esta
> instalación no estoy usando nada gráfico y no se me ocurre como hacer el
> apt-cache search

# apt purge $(dpkg --get-selections | grep deinstall | awk '{ print $1 }')




-- 
Alfonso 

listar paquetes desinstalados con configuración residual

[Gonzalo Rivero]

gu mornin todos,

lo que quiero averiguar es como debería buscar con apt los paquetes que 
fueron desinstalados con


apt-get remove 

así puedo sacarlos con apt-get --purge remove 

normalmente hacía esto con synaptic, hacía click con el mouse y sabía 
que paquetes me habían dejado "basura" en el disco, pero esta 
instalación no estoy usando nada gráfico y no se me ocurre como hacer el 
apt-cache search

Re: Paquetes fuera de Distro

[Juan carlos Rebate]

Yo descargo los deb desde la web y los instalo con apt install
./paquete.deb y no se me rompe el so, funciona bien

El sáb., 20 ene. 2024 21:57, JA CM 
escribió:

> Hace poco actualicé a Debian 12 y ahora me salta una actualización de
> VisualCode desde el propio programa, pero no desde los repositorios. No es
> que necesite actualizar de la 1.85.1 a la 1.85.2 pero me planteo la
> siguiente pregunta.
> Si quisiera actualizar ese programa según la página del propio programa y
> sus propios lanzamientos ¿cómo podría hacerlo? ¿dpkg? ¿apt? Synaptic? ¿cómo
> afectaría eso a futuras actualizaciones del SO?
> ¿Seríais tan amables de facilitarme links para aprender acerca de las
> actualizaciones de paquetes fuera de las fuentes de la distribución y sus
> consecuencias?
>
> Muchas gracias y un saludo
>
>

Paquetes fuera de Distro

[JA CM]

Hace poco actualicé a Debian 12 y ahora me salta una actualización de
VisualCode desde el propio programa, pero no desde los repositorios. No es
que necesite actualizar de la 1.85.1 a la 1.85.2 pero me planteo la
siguiente pregunta.
Si quisiera actualizar ese programa según la página del propio programa y
sus propios lanzamientos ¿cómo podría hacerlo? ¿dpkg? ¿apt? Synaptic? ¿cómo
afectaría eso a futuras actualizaciones del SO?
¿Seríais tan amables de facilitarme links para aprender acerca de las
actualizaciones de paquetes fuera de las fuentes de la distribución y sus
consecuencias?

Muchas gracias y un saludo

Paquetes fuera de distro

[JA CM]

Buenos días
Hace poco actualicé a Debian 12 y ahora me salta una actualización de
Visual Code desde el propio programa, pero no desde los repositorios. No es
que necesite actualizar de la 1.85.1 a la 1.85.2

Re: Limpieza de paquetes que corren como servicio en segundo plano - [HILO CERRADO]

[JavierDebian]

Bueno.

Resumiendo, toca hacer tres cosas:

1 - Modificar /etc/apt/apt.conf y poner la línea
Install-Recommends "false";

2 - Listar todos los paquetes instalados como recomendados y sugeridos, 
y empezar a limpiar a mano.


dpkg-query -W -f='${Package} (status: ${Status}) recommends: 
${Recommends}\n'   | grep 'status: install ok installed' | grep -v 
'recommends: $'



dpkg-query -W -f='${Package} (status: ${Status}) suggests: 
${Suggests}\n'   | grep 'status: install ok installed' | grep -v 
'suggests: $'


3 - Subir un reporte de "bug" pidiendo que no instale minidnla y 
modemmanager en forma tal que no se inicie como servicio, salvo que se 
active manualmente.


Gracias a todos, cierro el hilo.

JAP

Re: Limpieza de paquetes que corren como servicio en segundo plano

[JavierDebian]

El 12/8/23 a las 18:23, Javier Barroso escribió:

Buenas noches,

El sáb., 12 ago. 2023 22:49, JavierDebian <mailto:javier.debian.bb...@gmail.com>> escribió:




El 12/8/23 a las 14:28, Camaleón escribió:
 > El 2023-08-12 a las 12:58 -0300, JavierDebian escribió:
 >
 >> Buen día.
 >>
 >> Estuve haciendo limpieza en una de las computadoras de casa.
     >> Es decir, eliminar paquetes que alguna vez instalé para probar o
hacer
 >> pruebas, sobre todo, aquellos que inician como servicios y que
se que no
 >> necesito.
 >> Y me vuelvo a encontrar con dos "perlas" de las instalaciones
estándares de
 >> paquetes de Debian, que nunca entendí por qué:
 >>
 >> ...
 >> 2 - Un paquete, que si bien es útil, muy pocos lo usan y sólo en
equipos
 >> puntuales para UNA tarea muy específica: minidlna.


¿Qué escritorio tienes instalado?

¿Qué te dice aptitude why minidlna?

A veces al instalar algún paquete aparecen sorpresas [1] como dice 
Camaleón sin las recomendaciones ni las sugerencias no pasaría


En Debian intentan cuidar el sistema base sobre todo la gente que quería 
meter la instalación normal en un CD. Puedes ver el tema de los paquetes 
esenciales[2]


Saludos

[1] https://bugs.kde.org/show_bug.cgi?id=429995 
<https://bugs.kde.org/show_bug.cgi?id=429995>
https://wiki.debian.org/Proposals/EssentialOnDiet 
<https://wiki.debian.org/Proposals/EssentialOnDiet>




# aptitude why minidlna
i   kipi-plugins Recomienda minidlna

# aptitude why modemmanager
i   stellarium Dependelibqt5positioning5 (>= 5.6.0)
i A libqt5positioning5 Recomienda geoclue-2.0
i A geoclue-2.0Recomienda modemmanager


Siempre se aprende algo nuevo; no conocía la llave "why" de aptitude.
En realidad, casi nunca usé o uso aptitude, simpre preferí apt-get/apt 
"a pulmón".


Y sí, kipi-plugins y geoclue son cosas que instalé yo.

Por lo que veo, tendré que bloquear los "recomendados".
No me molestaría si instalase paquetes solamente; hay mucho disco y 
lugar de sobra; me molesta que instale paquetes que se transformen en 
servicios corriendo en segundo plano.


Saludos.

JAP

Re: Limpieza de paquetes que corren como servicio en segundo plano

[Javier Barroso]

Buenas noches,

El sáb., 12 ago. 2023 22:49, JavierDebian 
escribió:

>
>
> El 12/8/23 a las 14:28, Camaleón escribió:
> > El 2023-08-12 a las 12:58 -0300, JavierDebian escribió:
> >
> >> Buen día.
> >>
> >> Estuve haciendo limpieza en una de las computadoras de casa.
> >> Es decir, eliminar paquetes que alguna vez instalé para probar o hacer
> >> pruebas, sobre todo, aquellos que inician como servicios y que se que no
> >> necesito.
> >> Y me vuelvo a encontrar con dos "perlas" de las instalaciones
> estándares de
> >> paquetes de Debian, que nunca entendí por qué:
> >>
> >> ...
> >> 2 - Un paquete, que si bien es útil, muy pocos lo usan y sólo en equipos
> >> puntuales para UNA tarea muy específica: minidlna.
>
>
> ¿Qué escritorio tienes instalado?

> ¿Qué te dice aptitude why minidlna?

A veces al instalar algún paquete aparecen sorpresas [1] como dice Camaleón
sin las recomendaciones ni las sugerencias no pasaría

En Debian intentan cuidar el sistema base sobre todo la gente que quería
meter la instalación normal en un CD. Puedes ver el tema de los paquetes
esenciales[2]

Saludos

[1] https://bugs.kde.org/show_bug.cgi?id=429995
https://wiki.debian.org/Proposals/EssentialOnDiet



>
>
>

Re: Limpieza de paquetes que corren como servicio en segundo plano

[JavierDebian]

El 12/8/23 a las 14:28, Camaleón escribió:

El 2023-08-12 a las 12:58 -0300, JavierDebian escribió:


Buen día.

Estuve haciendo limpieza en una de las computadoras de casa.
Es decir, eliminar paquetes que alguna vez instalé para probar o hacer
pruebas, sobre todo, aquellos que inician como servicios y que se que no
necesito.
Y me vuelvo a encontrar con dos "perlas" de las instalaciones estándares de
paquetes de Debian, que nunca entendí por qué:

1 - Un paquete, al día de hoy lo sigue instalando, y corriendo en segundo
plano, cuando el "hardware" que debería controlar es prácticamente obsoleto:
modemmanager.

2 - Un paquete, que si bien es útil, muy pocos lo usan y sólo en equipos
puntuales para UNA tarea muy específica: minidlna.


Va la pregunta:

¿Hay alguna forma de reportar a Debian que no los instalen por defecto?


Los paquetes que se instalan en Debian de manera predeterminada
dependen del tipo de instalación que hagas, del medio seleccionado,
etc.

Normalmente, se instalan por dependencias flojas, esto es, están
marcados como paquetes recomendados o sugeridos de otrso paquetes que
sí instalas de mansera consciente.

Yo no tengo esos dos paquetes en mis sistemas porque:

1. Elijo como medio de instalación la imagen mini-ISO.
2. Selecciono el modo avanzado de instalación.
3. Instalo sólo los paquetes base sin entorno gráfico ni gaitas.
4. No hago ni caso del Popcon.
5. Tras instalar Debian, lo primerito que hago es configrar APT para
que NO instale paquetes recomendados ni sugeridos.


Porque están en un círculo vicioso: popularity-contest los informa como que
todo el mundo los instala, pero la realidad es que no se necesitan, y están
instalados por defecto, y son paquetes que corren como servicio, y,
personalmente, no me gusta tener cosas corriendo que no necesito ni uso, por
tema de puertos abiertos y esas cosas.


Puedes enviar un informe de fallo de tipo «deseo» contra los paquetes
que «arrastran» a modemmanager y minidlna, pero los mantenedores de los
paquetes suelen ser reacios a cambiar las dependencias, salvo que
realmente se justifique que no aportan nada y la dependencia es
indebida.

Saludos,




Justamente, esos dos no son dependencia de nada.
Por eso no entiendo por qué los sigue instalando.
Y encima son servicios en segundo plano.
Si me dijeras que es algo como, por ejemplo (inventado), mc, que se 
instale pero no se sube al sistema en marcha, pero está disponible para 
ejecución si uno lo necesita, bien.
Es más, cualquiera de los que usamos la consola, mc es más que 
bienvenido que se instale solo. Y no que haya que hacerlo a mano todas 
las veces. Personalmente, prefiero mcedit sobre nano :/
Por lo que minidlna, que es para algo MUY específico... no le encuentro 
la lógica.


"> Puedes enviar un informe de fallo de tipo «deseo» "
¿Cómo o dónde se hace?

Saludos

JAP

Re: Limpieza de paquetes que corren como servicio en segundo plano

[JavierDebian]

El 12/8/23 a las 16:44, Gerardo Braica escribió:


El 12/8/23 a las 14:28, Camaleón escribió:

El 2023-08-12 a las 12:58 -0300, JavierDebian escribió:


Buen día.

Estuve haciendo limpieza en una de las computadoras de casa.
Es decir, eliminar paquetes que alguna vez instalé para probar o hacer
pruebas, sobre todo, aquellos que inician como servicios y que se que no
necesito.
Y me vuelvo a encontrar con dos "perlas" de las instalaciones estándares de
paquetes de Debian, que nunca entendí por qué:

1 - Un paquete, al día de hoy lo sigue instalando, y corriendo en segundo
plano, cuando el "hardware" que debería controlar es prácticamente obsoleto:
modemmanager.

2 - Un paquete, que si bien es útil, muy pocos lo usan y sólo en equipos
puntuales para UNA tarea muy específica: minidlna.


Va la pregunta:

¿Hay alguna forma de reportar a Debian que no los instalen por defecto?

Los paquetes que se instalan en Debian de manera predeterminada
dependen del tipo de instalación que hagas, del medio seleccionado,
etc.

Normalmente, se instalan por dependencias flojas, esto es, están
marcados como paquetes recomendados o sugeridos de otrso paquetes que
sí instalas de mansera consciente.

Yo no tengo esos dos paquetes en mis sistemas porque:

1. Elijo como medio de instalación la imagen mini-ISO.
2. Selecciono el modo avanzado de instalación.
3. Instalo sólo los paquetes base sin entorno gráfico ni gaitas.
4. No hago ni caso del Popcon.
5. Tras instalar Debian, lo primerito que hago es configrar APT para
que NO instale paquetes recomendados ni sugeridos.


Porque están en un círculo vicioso: popularity-contest los informa como que
todo el mundo los instala, pero la realidad es que no se necesitan, y están
instalados por defecto, y son paquetes que corren como servicio, y,
personalmente, no me gusta tener cosas corriendo que no necesito ni uso, por
tema de puertos abiertos y esas cosas.

Puedes enviar un informe de fallo de tipo «deseo» contra los paquetes
que «arrastran» a modemmanager y minidlna, pero los mantenedores de los
paquetes suelen ser reacios a cambiar las dependencias, salvo que
realmente se justifique que no aportan nada y la dependencia es
indebida.

Saludos,



*/Gerardo Braica
*/gbra...@gmail.com.ar
/*/*


(Corrijo "top-posting")

> Buenas tardes. Entro en el hilo porque me resulta muy interesante el 
tema.

> El hecho de setear como APT::Install-Recommends "false" no puede
> traer problemas de dependencias faltantes?
> Pregunto porque realmente no lo se.
>
> Saludos
>
>

No, porque los "recomendados" y "sugeridos", no son "dependencias".
Estas últimas se instalan sí o sí, pues si no, el paquete padre no 
funcionaría.
De hecho, mi sistema instala recomendados, pero no sugeridos; no soy tan 
purista como Camaleón.


JAP

Re: Limpieza de paquetes que corren como servicio en segundo plano

[Camaleón]

El 2023-08-12 a las 12:58 -0300, JavierDebian escribió:

> Buen día.
> 
> Estuve haciendo limpieza en una de las computadoras de casa.
> Es decir, eliminar paquetes que alguna vez instalé para probar o hacer
> pruebas, sobre todo, aquellos que inician como servicios y que se que no
> necesito.
> Y me vuelvo a encontrar con dos "perlas" de las instalaciones estándares de
> paquetes de Debian, que nunca entendí por qué:
> 
> 1 - Un paquete, al día de hoy lo sigue instalando, y corriendo en segundo
> plano, cuando el "hardware" que debería controlar es prácticamente obsoleto:
> modemmanager.
> 
> 2 - Un paquete, que si bien es útil, muy pocos lo usan y sólo en equipos
> puntuales para UNA tarea muy específica: minidlna.
> 
> 
> Va la pregunta:
> 
> ¿Hay alguna forma de reportar a Debian que no los instalen por defecto?

Los paquetes que se instalan en Debian de manera predeterminada 
dependen del tipo de instalación que hagas, del medio seleccionado, 
etc.

Normalmente, se instalan por dependencias flojas, esto es, están 
marcados como paquetes recomendados o sugeridos de otrso paquetes que 
sí instalas de mansera consciente.

Yo no tengo esos dos paquetes en mis sistemas porque:

1. Elijo como medio de instalación la imagen mini-ISO.
2. Selecciono el modo avanzado de instalación.
3. Instalo sólo los paquetes base sin entorno gráfico ni gaitas.
4. No hago ni caso del Popcon.
5. Tras instalar Debian, lo primerito que hago es configrar APT para 
que NO instale paquetes recomendados ni sugeridos.

> Porque están en un círculo vicioso: popularity-contest los informa como que
> todo el mundo los instala, pero la realidad es que no se necesitan, y están
> instalados por defecto, y son paquetes que corren como servicio, y,
> personalmente, no me gusta tener cosas corriendo que no necesito ni uso, por
> tema de puertos abiertos y esas cosas.

Puedes enviar un informe de fallo de tipo «deseo» contra los paquetes 
que «arrastran» a modemmanager y minidlna, pero los mantenedores de los 
paquetes suelen ser reacios a cambiar las dependencias, salvo que 
realmente se justifique que no aportan nada y la dependencia es 
indebida.

Saludos,

-- 
Camaleón 

Limpieza de paquetes que corren como servicio en segundo plano

[JavierDebian]

Buen día.

Estuve haciendo limpieza en una de las computadoras de casa.
Es decir, eliminar paquetes que alguna vez instalé para probar o hacer 
pruebas, sobre todo, aquellos que inician como servicios y que se que no 
necesito.
Y me vuelvo a encontrar con dos "perlas" de las instalaciones estándares 
de paquetes de Debian, que nunca entendí por qué:


1 - Un paquete, al día de hoy lo sigue instalando, y corriendo en 
segundo plano, cuando el "hardware" que debería controlar es 
prácticamente obsoleto: modemmanager.


2 - Un paquete, que si bien es útil, muy pocos lo usan y sólo en equipos 
puntuales para UNA tarea muy específica: minidlna.



Va la pregunta:

¿Hay alguna forma de reportar a Debian que no los instalen por defecto?

Porque están en un círculo vicioso: popularity-contest los informa como 
que todo el mundo los instala, pero la realidad es que no se necesitan, 
y están instalados por defecto, y son paquetes que corren como servicio, 
y, personalmente, no me gusta tener cosas corriendo que no necesito ni 
uso, por tema de puertos abiertos y esas cosas.


Saludos.

Re: Crear paquetes debian

[Ismael L. Donis Garcia]

- Original Message - 
From: "Camaleón" 

To: 
Sent: Tuesday, January 10, 2023 1:55 PM
Subject: Re: Crear paquetes debian



El 2023-01-10 a las 13:18 -0500, Ismael L. Donis Garcia escribió:

Estoy incursionando en la creación de paquetes .deb y tengo una duda que 
no

he podido solucionar

Cuando instalo el paquete una vez creado tengo que reiniciar la sección
gráfica porque no me refresca los disparadores en la sección que tengo
abierta, alguien me podría explicar como solventar este error?

Por ejemplo uso Mate como escritorio. Al instalar el paquete no me 
actualiza

el menú con el programa que instale. Y cual debe salir en
Aplicaciones->Programación->Programa Instalado

Una vez reiniciada la sección del usuario si aparece. Pero lo que quiero 
es

que aparezca sin tener que reiniciar la sección.

Como lograr esto?


No tengo experiencia con la creación de paquetes, pero cuando instalas
alguno o actualizas el sistema, se pueden leer mensajes del tipo «Debian
pkg triggering...» que siempre me he preguntando por qué no estarán
traducidos el español, pero bueno, eso es otro tema :-P

En cuanto a tu pregunta, te puede interesar esto, concretamente
«update-menus»:

https://wiki.debian.org/DpkgTriggers

Saludos,

--
Camaleón




Gracias por el enlace.

Revisaré y veremos si encuentro como realizarlo. Al final comento 
resultados.

--
Ismael

Crear paquetes debian

[Ismael L. Donis Garcia]

Estoy incursionando en la creación de paquetes .deb y tengo una duda que no 
he podido solucionar


Cuando instalo el paquete una vez creado tengo que reiniciar la sección 
gráfica porque no me refresca los disparadores en la sección que tengo 
abierta, alguien me podría explicar como solventar este error?


Por ejemplo uso Mate como escritorio. Al instalar el paquete no me actualiza 
el menú con el programa que instale. Y cual debe salir en 
Aplicaciones->Programación->Programa Instalado


Una vez reiniciada la sección del usuario si aparece. Pero lo que quiero es 
que aparezca sin tener que reiniciar la sección.


Como lograr esto?

Toda ayuda será bien venida.

Saludos Cordiales
--
Ismael

Re: Ya hay decisión (era: [OT] Debian decide sobre su política de paquetes firmware «non-free»)

[Roberto J. Blandino Cisneros]

Yo estaba muy de acuerdo con la política anterior de que sea el usuario 
quien decida agregar al repositorio el "non-free" aunque sea un poco 
molesto para quien siempre los desea utilizar pero tambien tienen la 
versión del instalador con los non-free incluidos.


Pienso que la libertad viene con la libertad de decisión y oferta.

A como pueden haber quienes nunca usen los non-free del todo, de igual 
forma como hay quienes no pueden vivir sin ellos en sus repositorios.



Saludos.

On 29/10/22 05:44, Jose Ab bA wrote:

Efectivamente Camaleon!

A estas alturas cambiar la politica de paquetes y de instalacion... Es 
una manipulacion pretenciosa por parte de elementos oscuros... seguro!


Debian no necesita mas usuarios de los que ya tiene...

Y los usuarios que no sepan tratar con estos asuntos seguro que no se 
merecen usar una distro basada en software libre... porque seguro que 
ni aprecian ni saben que es el software libre.


Ya hay distros que hacen esto de manera predeterminada... que usen 
esas, que para eso estan...

Re: Ya hay decisión (era: [OT] Debian decide sobre su política de paquetes firmware «non-free»)

[Jose Ab bA]

Efectivamente Camaleon!

A estas alturas cambiar la politica de paquetes y de instalacion... Es una
manipulacion pretenciosa por parte de elementos oscuros... seguro!

Debian no necesita mas usuarios de los que ya tiene...

Y los usuarios que no sepan tratar con estos asuntos seguro que no se
merecen usar una distro basada en software libre... porque seguro que ni
aprecian ni saben que es el software libre.

Ya hay distros que hacen esto de manera predeterminada... que usen esas,
que para eso estan...

Re: Ya hay decisión (era: [OT] Debian decide sobre su política de paquetes firmware «non-free»)

[alfon]

> En resumen:
>
> 1. Se cambia el Contrato Social (un párrafo pequeño) para
> adecuarlo a la nueva realidad, que es que el medio de instalación
> oficial de Debian podrá contener paquetes privativos.
>
> 2. Sólo habrá un medio de instalación oficial de Debian, con paquetes
> libres y no libres mezclados, pero en teoría el usuario podrá desactivar
> la instalación de paquetes propietarios antes de iniciar el proceso de
> instalación (queda por ver cómo de efectivo resultará la pretensión y
> cómo lo expondrá el instalador sencillo dirigido a usuarios noveles).
> ...
>
> En fin... qué se le va a hacer.
>
> Ceder a estar alturas no me complace lo más mínimo.
>

Parece que el lema de: <> ya no es tan cierto como se afirma en la filosofía de Debian
(https://www.debian.org/intro/philosophy)

Re: Ya hay decisión (era: [OT] Debian decide sobre su política de paquetes firmware «non-free»)

[Parodper]

O 16/10/22 ás 16:25, Camaleón escribiu:

2. Sólo habrá un medio de instalación oficial de Debian, con paquetes
libres y no libres mezclados, pero en teoría el usuario podrá desactivar
la instalación de paquetes propietarios antes de iniciar el proceso de
instalación (queda por ver cómo de efectivo resultará la pretensión y
cómo lo expondrá el instalador sencillo dirigido a usuarios noveles).


Me gustaría pensar que no sería difícil crear un instalador 
"semioficial" sin los paquetes privativos. Pero también es lo que dice 
Simon McVittie 
(https://lists.debian.org/debian-vote/2022/10/msg00013.html), alguien se 
tiene que encargar de eso.



3. El instalador informará de los paquetes propietarios que se van a
instalar (en tiempo rela) y una vez instalado el sistema, se podrá
consultar posteriormente alguna especie de archivo de registro o
similar con los paquetes que se hayan instalado desde «non-free».


También piensan sacar el firmware hacia una sección «non-free-firmware» 
nueva. Sigo manteniendo la idea de que se deberían aprovechar las 
categorías, y hacer que APT pueda filtrar la lista de paquetes según la 
configuración.



Si al menos la opción predeterminada hubiera sido que el instalador no
instalara paquetes propietarios SALVO que el usuario lo seleccionara a
conciencia, ESPECÍFICAMENTE, pues hubiera sido una transición un poco
más entendible.


Como la opción estará en el GRUB, no veo mucho problema. Se puede 
discutir si descargar, pero no instalar, código no libre va en contra de 
la filosofía del software libre. A efectos prácticos, yo diría que no 
hay problema.



Pero no, ahora de manera predeterminada si el kernel necesita algún
binario propietario se instalará, salvo que el usuario diga
EXPRESAMENTE que no.


Juraría haber oído que algún firmware, como el de los dispositivos de 
audio, se va a incluir sí o sí, para los invidentes.



En fin... qué se le va a hacer.

Ceder a estar alturas no me complace lo más mínimo.

:-(

¹https://www.debian.org/vote/2022/vote_003#outcome

Saludos,

Ya hay decisión (era: [OT] Debian decide sobre su política de paquetes firmware «non-free»)

[Camaleón]

El 2022-08-28 a las 10:11 +0200, Camaleón escribió:

> Hola,
> 
> A través de Phoronix¹ leo que en Debian² se está llevando a cabo una 
> consulta sobre la política a seguir con los paquetes de firmware 
> non-free, que actualmente se tienen que instalar por separado y de 
> manera plenamente consciente, con el consiguiente perjuicio que causa 
> en las instalaciones, principalmente a los nuevos usuarios.

(...)

> ¹https://www.phoronix.com/news/Debian-Non-Free-Firmware-GR
> ²https://www.debian.org/vote/2022/vote_003

Bueno, pues ya hay ganador para esta cuestión¹.

En resumen: 

1. Se cambia el Contrato Social (un párrafo pequeño) para 
adecuarlo a la nueva realidad, que es que el medio de instalación 
oficial de Debian podrá contener paquetes privativos.

2. Sólo habrá un medio de instalación oficial de Debian, con paquetes 
libres y no libres mezclados, pero en teoría el usuario podrá desactivar 
la instalación de paquetes propietarios antes de iniciar el proceso de 
instalación (queda por ver cómo de efectivo resultará la pretensión y 
cómo lo expondrá el instalador sencillo dirigido a usuarios noveles).

3. El instalador informará de los paquetes propietarios que se van a 
instalar (en tiempo rela) y una vez instalado el sistema, se podrá 
consultar posteriormente alguna especie de archivo de registro o 
similar con los paquetes que se hayan instalado desde «non-free».

Si al menos la opción predeterminada hubiera sido que el instalador no 
instalara paquetes propietarios SALVO que el usuario lo seleccionara a 
conciencia, ESPECÍFICAMENTE, pues hubiera sido una transición un poco 
más entendible.

Pero no, ahora de manera predeterminada si el kernel necesita algún 
binario propietario se instalará, salvo que el usuario diga 
EXPRESAMENTE que no.

En fin... qué se le va a hacer. 

Ceder a estar alturas no me complace lo más mínimo.

:-(

¹https://www.debian.org/vote/2022/vote_003#outcome

Saludos,

-- 
Camaleón 

Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[fernando sainz]

El mar, 30 ago 2022 a las 10:22, Eduardo Jorge Gil Michelena (<
egi...@yahoo.com.ar>) escribió:

> El lunes, 29 de agosto de 2022 04:10:01 ART, Camaleón 
> escribió:
>
> > Me cuesta ver algo bueno en recomendar y promover software propietario,
> > la verdad :-/
> >
> > ¹Lo que se debate ahora en Debian está relacionado exclusivamente con
> > el código firmware, no con programas o controladores propietarios.
> > Camaleón
>
> A ver...
> Tal parece que como LINUX viene de una larga tradición de "licencia
> pública" suele preferirse que todo sea de "licencia pública" y si se puede
> gratuita cosa que a mi me parece MUY bien y muy popular pero... que yo y
> unos cuantos más creamos en ciertas filosofías eso no implica que todos se
> adscriban a ella.
>
> El universo LINUX (que va más allá de Debian) es magnífico. Linux tiene
> muchas ventajas sobre otros SO, en especial en lo que refiere a la
> seguridad y estabilidad del sistema pero... lamentablemente tiene una gran
> falta en cuanto al software aplicativo disponible que en verdad y en
> ciertas áreas es extremadamente limitado.
>
> Supongo que tales limitaciones se deben justamente a las condiciones de
> "licencia pública" las que hacen que no haya tanto hard ni soft de calidad
> profesional disponible en ciertas áreas como por ejemplo la de edición de
> video en donde tanto las placas de video profesionales como el sofware de
> edición de video es inexistente. De hecho en Linux NO hay un buen software
> de edición profesional de video que llegue siquiera a igualar al SONY VEGAS
> de hace una década (en video, Linux retrasa más de 10 años) y en
> convertidores multimedia NO hay en Linux algo que se asemeje al Format
> Factory para Windows que convierte cualquier formato de audio, video y
> gráfico a cualquier otro con una facilidad de uso y una velocidad de
> ejecución varias veces más alta que cualquier conversor de video para Linux
> que además son MUY limitados.
>
> Supongo que en problema esta justamente en que Linux ha tenido una
> política de defensa a lo free que le ha jugado en contra para su evolución.
>
> No hace falta más que darse una vuelta por los repositorios de las APP
> para ANdroid para dar cuenta que hay muchas más aplicaciones para Android
> que para Linux.
>
> Linux debería cambiar sus políticas para que las empresas productoras de
> soft y harrd le sea beneficioso producir productos para Linux. Sino...
> Linux quedará rezagado... y en pocos años su entorno quedará sólo relegado
> a los servidores.
>





Hola.
Creo que mezclas churras con merinas.

Claro que hay software más avanzado en algunos campos para Windows que para
Linux, pero en otros es al revés.
Por supuesto nos olvidamos de que más del 99% de los supercomputadores del
mundo corren bajo versiones de Linux.

Aquí el tema es que el hardware lleva un firmware que antiguamente venía
incorporado en memorias "ROM" en el propio dispositivo y desde hace tiempo
eso cambió, primero pasando a memorias flash que permitían su actualización
y ahora ya directamente se carga desde el driver del mismo al arrancar el
equipo.

Antiguamente no había mucho dilema ya que el hardware y el firmware eran
todo uno y no había opción ni probablemente estas discusiones.

Ahora se complica un poco. La cuestión es que necesitamos un firmware para
cada dispositivo y si no existe una versión libre no podemos utilizarlo sin
cargar el firmware cerrado.

Que opciones tenemos en la instalación.
   - si existiera un firmware libre, debería cargarse por defecto y dar la
opción de usar el propietario si existiera.
   - Si no existe un firmware libre, avisar y dar la opción de cargar el
propietario o quedarnos sin el dispositivo en cuestión disponible.
  En ningún caso una pregunta genérica de cargar todos los firmware
propietarios, sino uno por uno.

En cuanto a las opciones que dan no se si la "B" es la que se adaptaría más
a esto, porque claro entra en juego el hecho de distribuir software
que no es libre, lo que no se si conlleva alguna limitación. (Cuando venia
en las memorias flash, no se daban estas cuestiones)
Tal vez el problema de la situación actual, (digamos la C) es que puedas
quedarte por ejemplo sin poder usar la wifi y complicarse un poco el tema
de la instalación del firmware propietario al no tener conexión para una
actualización fácil.

Por supuesto que lo ideal es que el firmware fuera completamente software
libre y hay que trabajar en ello y tal vez el no ponerlo muy fácil ayude a
que los fabricantes se decidan a liberarlos.


S2.

Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[Eduardo Jorge Gil Michelena]

 El lunes, 29 de agosto de 2022 04:10:01 ART, Camaleón  
escribió:

> Me cuesta ver algo bueno en recomendar y promover software propietario,
> la verdad :-/
> 
> ¹Lo que se debate ahora en Debian está relacionado exclusivamente con
> el código firmware, no con programas o controladores propietarios.
> Camaleón

A ver...
Tal parece que como LINUX viene de una larga tradición de "licencia pública" 
suele preferirse que todo sea de "licencia pública" y si se puede gratuita cosa 
que a mi me parece MUY bien y muy popular pero... que yo y unos cuantos más 
creamos en ciertas filosofías eso no implica que todos se adscriban a ella.

El universo LINUX (que va más allá de Debian) es magnífico. Linux tiene muchas 
ventajas sobre otros SO, en especial en lo que refiere a la seguridad y 
estabilidad del sistema pero... lamentablemente tiene una gran falta en cuanto 
al software aplicativo disponible que en verdad y en ciertas áreas es 
extremadamente limitado.

Supongo que tales limitaciones se deben justamente a las condiciones de 
"licencia pública" las que hacen que no haya tanto hard ni soft de calidad 
profesional disponible en ciertas áreas como por ejemplo la de edición de video 
en donde tanto las placas de video profesionales como el sofware de edición de 
video es inexistente. De hecho en Linux NO hay un buen software de edición 
profesional de video que llegue siquiera a igualar al SONY VEGAS de hace una 
década (en video, Linux retrasa más de 10 años) y en convertidores multimedia 
NO hay en Linux algo que se asemeje al Format Factory para Windows que 
convierte cualquier formato de audio, video y gráfico a cualquier otro con una 
facilidad de uso y una velocidad de ejecución varias veces más alta que 
cualquier conversor de video para Linux que además son MUY limitados. 

Supongo que en problema esta justamente en que Linux ha tenido una política de 
defensa a lo free que le ha jugado en contra para su evolución.

No hace falta más que darse una vuelta por los repositorios de las APP para 
ANdroid para dar cuenta que hay muchas más aplicaciones para Android que para 
Linux.

 Linux debería cambiar sus políticas para que las empresas productoras de soft 
y harrd le sea beneficioso producir productos para Linux. Sino... Linux quedará 
rezagado... y en pocos años su entorno quedará sólo relegado a los servidores.  

Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[hubble]

On Sun, 28 Aug 2022 10:11:03 +0200
Camaleón  wrote:

> Hola,
> 
> A través de Phoronix¹ leo que en Debian² se está llevando a cabo una 
> consulta sobre la política a seguir con los paquetes de firmware 
> non-free, que actualmente se tienen que instalar por separado y de 
> manera plenamente consciente, con el consiguiente perjuicio que causa 
> en las instalaciones, principalmente a los nuevos usuarios.
> 
> En fin, la habitual dicotomía entre hacer lo correcto y sufrir un poco 
> las consecuencias o pasarse al lado oscuro (lo que yo llamo «el 
> modo vago»).
> 
> Las alternativas que hay sobre la mesa son:
> 
> A. Meter los paquetes de firmware non-free dentro del medio de 
> instalación, como si fueran uno más, sin que sea obligatoio informar al 
> usuario de esto.
> 
> B. Meter los paquetes non-free en el medio de instalación oficial pero 
> sólo cargarlos / instalarlos si son necesarios, informando al usuario y 
> permitiendo desactivar previamente esta opción.
> 
> Se mantienen dos medios por separado, dando preeminencia al medio de 
> instalación que contienen los paquetes de non-free.
> 
> C. Un poco como la situación actual, dos medios de instalación separados
> para que el usuario elija cuál descargar e instalar.
> 
> Desde mi punto de vista, la opción A no me convence en absoluto, 
> significa claudicar.
> 
> De la opción B no me fío, porque el kernel recomienda paquetes non-free 
> que no son necesarios así que el automatismo no funciona.
> 
> La opción C es la menos mala y la más sincera con los usuarios, pero 
> perjudica a los nuevos o a los más novatos que tienen que buscar e 
> informarse... lo que tampoco es malo >:-)
> 
> ¿Qué pensáis?
> 
> ¹https://www.phoronix.com/news/Debian-Non-Free-Firmware-GR
> ²https://www.debian.org/vote/2022/vote_003
> 
> Saludos,
> 
> -- 
> Camaleón 
> 


Yo me quedo con la C que es más o menos como estamos. Así yo elijo a qué nivel 
de desvenguenza quiero trabajar.
Quien quiera comodidad a cambio de libertad que se vaya a otro sistema 
operativo. O sinó, ¿qué narices hacen usando debian?

Pobres binarios, no los quieren en debian, no los quieren los del LGTBI...

hubble, 8-)

-- 

Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[Camaleón]

El 2022-08-29 a las 10:33 +0200, Javier Barroso escribió:

> Hola,
> 
> El lun., 29 ago. 2022 9:10, Camaleón  escribió:
> 
> > El 2022-08-29 a las 07:35 +0200, Javier Barroso escribió:
> >
> > Hola Javier,
> >
> > > El dom., 28 ago. 2022 10:11, Camaleón  escribió:
> > >
> > > > Hola,
> > > >
> > > > A través de Phoronix¹ leo que en Debian² se está llevando a cabo una
> > > > consulta sobre la política a seguir con los paquetes de firmware
> > > > non-free, que actualmente se tienen que instalar por separado y de
> > > > manera plenamente consciente, con el consiguiente perjuicio que causa
> > > > en las instalaciones, principalmente a los nuevos usuarios.
> >
> > (...)
> >
> > > >  ...
> > > >
> > > > ¿Qué pensáis?
> > >
> > >
> > > La opción A sí informa de qué se instala (al menos lo interpreto así),
> >
> > No me queda claro este punto.
> >
> > Si el usuario va a descargar la ISO de Debian para instalar y sólo ve
> > una opción (porque con la opción A sólo hay una imagen oficial que
> > contiene firmware non-free) pocas alternativas tiene ese usuario.

(...)

> > > Aún con un instalador libre vas a estar corriendo tu equipo con firmwares
> > > no libres (los que van integrados en la tarjeta gráfica, de red, etc),
> >
> > No, no... eso no es así, Javier.
> >
> > Yo ahora mismo no tengo habilitado el repo «non-free» y espero que mi
> > equipo no tenga ninguna pieza de software de código cerrado, faltaría
> > más.
> >
> 
> Ese es el tema da igual que tengas habilitado o no el repo non-free, las
> tarjetas gráficas y demás ya tienen incorporados su propio firmware antes
> de que el SO ponga nada. Ese firmware no es libre en el 99.9% de las veces
> 
> ¿Ahora me explico mejor?

La BIOS/UEFI tampoco es libre pero no es algo sobre lo que tengamos el 
control, ni nosotros ni Debian.

De lo que se trata en la decisión que tenga que tomar Debian es, 
primero de carácter técnico (¿quién y cómo se determina si debo/tengo 
que instalar cierto firmaware propietario o no?) y luego de carácter 
vocacional (¿hacia dónde queremos dirigirnos, debemos fomentar el uso de 
códígo porpietario?).

La opción A pretende «automatizar» y «simplificar» en exceso esa 
decisión, yo prefiero que sea el usuario quien decida lo que quiere 
hacer y que sea consecuente y plenamente consciente de sus actos, y que
de manera predeterminada se fomente desde Debian las opciones libres, 
obviamente.

Para que decidan por mi ya están Windows o Android :-)

Saludos,

-- 
Camaleón 

Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[Javier Barroso]

Hola,

El lun., 29 ago. 2022 9:10, Camaleón  escribió:

> El 2022-08-29 a las 07:35 +0200, Javier Barroso escribió:
>
> Hola Javier,
>
> > El dom., 28 ago. 2022 10:11, Camaleón  escribió:
> >
> > > Hola,
> > >
> > > A través de Phoronix¹ leo que en Debian² se está llevando a cabo una
> > > consulta sobre la política a seguir con los paquetes de firmware
> > > non-free, que actualmente se tienen que instalar por separado y de
> > > manera plenamente consciente, con el consiguiente perjuicio que causa
> > > en las instalaciones, principalmente a los nuevos usuarios.
>
> (...)
>
> > >  ...
> > >
> > > ¿Qué pensáis?
> >
> >
> > La opción A sí informa de qué se instala (al menos lo interpreto así),
>
> No me queda claro este punto.
>
> Si el usuario va a descargar la ISO de Debian para instalar y sólo ve
> una opción (porque con la opción A sólo hay una imagen oficial que
> contiene firmware non-free) pocas alternativas tiene ese usuario.
>
> Porque una vez que el instalador está en ejecución, poco margen de
> maniobra tienes. Es decir, con la opción A facilitas las cosas al lado
> oscuro y se las complicas a los caballeros Jedi.
>
> Es como darle un sable de luz a Vader y una ramita a Skywalker... y que
> luchen :-)
>
> No me parece justo, además de con esa acción fomentas el uso de
> firmware non-free en lugar de hacer pensar al usuario sobre las
> consecuencias de su uso, instruirle sobre el hardware que compra o las
> opciones que tiene.
>
> > lo que yo creo que sería deseable es que te dijera el instalador ,
> > "se va a instalar los componentes non free que te proporcionan la
> > siguientes funcionalidades:
> >
> > - 
> > - 
> >
> > Aceptar / instalar sin esos componentes (o incluso, (de)seleccione los
> > componentes non free y pulsa siguiente)
> >
> > Donde  e  son tanto los nombres de los componentes como su
> > descripción corta
>
> Ojalá fuera tan sencillo.
>
> Me temo que simplemente si el kernel «piensa» que necesita cierto
> código para funcionar, lo instalará, sin más, pero queda por resolver
> la cuestión técnica de si realmente el sistema necesita ese chorro de
> software binario cerrado para funcionar sin problemas.
>
> La parte técnica NO es está resuelta.
>
> > En la lista de debian-vote daban el argumento de la accesibilidad (para
> > ciegos por ejemplo) como algo fundamental para el instalador.
>
> Desconozco qué tipo de software-hardware gestiona esto, pero supongo
> que será como en todo: lo habrá cerrado y lo habrá libre. Y los
> usuarios que necesiten usarlo están en la misma tesitura que los demás:
> decidir qué usar y con pleno conocimiento de lo que hacen.
>
> > Aún con un instalador libre vas a estar corriendo tu equipo con firmwares
> > no libres (los que van integrados en la tarjeta gráfica, de red, etc),
>
> No, no... eso no es así, Javier.
>
> Yo ahora mismo no tengo habilitado el repo «non-free» y espero que mi
> equipo no tenga ninguna pieza de software de código cerrado, faltaría
> más.
>

Ese es el tema da igual que tengas habilitado o no el repo non-free, las
tarjetas gráficas y demás ya tienen incorporados su propio firmware antes
de que el SO ponga nada. Ese firmware no es libre en el 99.9% de las veces

¿Ahora me explico mejor?

Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[Camaleón]

El 2022-08-29 a las 07:35 +0200, Javier Barroso escribió:

Hola Javier,

> El dom., 28 ago. 2022 10:11, Camaleón  escribió:
> 
> > Hola,
> >
> > A través de Phoronix¹ leo que en Debian² se está llevando a cabo una
> > consulta sobre la política a seguir con los paquetes de firmware
> > non-free, que actualmente se tienen que instalar por separado y de
> > manera plenamente consciente, con el consiguiente perjuicio que causa
> > en las instalaciones, principalmente a los nuevos usuarios.

(...)

> >  ...
> >
> > ¿Qué pensáis?
> 
> 
> La opción A sí informa de qué se instala (al menos lo interpreto así), 

No me queda claro este punto.

Si el usuario va a descargar la ISO de Debian para instalar y sólo ve 
una opción (porque con la opción A sólo hay una imagen oficial que 
contiene firmware non-free) pocas alternativas tiene ese usuario.

Porque una vez que el instalador está en ejecución, poco margen de 
maniobra tienes. Es decir, con la opción A facilitas las cosas al lado 
oscuro y se las complicas a los caballeros Jedi.

Es como darle un sable de luz a Vader y una ramita a Skywalker... y que 
luchen :-)

No me parece justo, además de con esa acción fomentas el uso de 
firmware non-free en lugar de hacer pensar al usuario sobre las 
consecuencias de su uso, instruirle sobre el hardware que compra o las 
opciones que tiene.

> lo que yo creo que sería deseable es que te dijera el instalador , 
> "se va a instalar los componentes non free que te proporcionan la 
> siguientes funcionalidades:
> 
> - 
> - 
> 
> Aceptar / instalar sin esos componentes (o incluso, (de)seleccione los
> componentes non free y pulsa siguiente)
> 
> Donde  e  son tanto los nombres de los componentes como su
> descripción corta

Ojalá fuera tan sencillo.

Me temo que simplemente si el kernel «piensa» que necesita cierto 
código para funcionar, lo instalará, sin más, pero queda por resolver 
la cuestión técnica de si realmente el sistema necesita ese chorro de 
software binario cerrado para funcionar sin problemas.

La parte técnica NO es está resuelta.
 
> En la lista de debian-vote daban el argumento de la accesibilidad (para
> ciegos por ejemplo) como algo fundamental para el instalador.

Desconozco qué tipo de software-hardware gestiona esto, pero supongo 
que será como en todo: lo habrá cerrado y lo habrá libre. Y los 
usuarios que necesiten usarlo están en la misma tesitura que los demás: 
decidir qué usar y con pleno conocimiento de lo que hacen.

> Aún con un instalador libre vas a estar corriendo tu equipo con firmwares
> no libres (los que van integrados en la tarjeta gráfica, de red, etc), 

No, no... eso no es así, Javier.

Yo ahora mismo no tengo habilitado el repo «non-free» y espero que mi 
equipo no tenga ninguna pieza de software de código cerrado, faltaría 
más.

Aunque se trata de algo distinto¹, hubo un momento en que sí instalaba 
el controlador propiedario de nvidia, pero ahora, aún y todo lo mal que 
está nouveau, me vale con el libre.

> en mi opinión facilitar al usuario el mejor rendimiento del equipo es lo
> deseable. Los firmwares llevan "toda la vida" en los repositorios, esto es
> ponerlos en el instalador al alcance de cualquiera.

Llevan toda la vida en repos separados y no habilitados de manera 
predeterninada, que no es lo mismo. 

Creo, sinceramente, que la base de Debian, y de cualquier sistema Linux 
debe ser la educación consciente del usuario, en hacer bien las cosas y 
no en atender a una necesidad o capricho puntual del usuario (eso 
significa pan para hoy y hambre para mañana).

Uno de los fines últimos de un sistema operativo libre debe ser hacer 
pensar. Si perdemos eso, perderemos nuestra esencia.
 
> Para los puristas con activar el modo libre al arrancar (igual que hemos
> estado usando el modo experto mucho tiempo) les tendría que ser suficiente

Yo quiero más ;-)

Quiero poder indentificarme con los valores que promueve mi sistema 
operativo, que el sistema operativo que elijo esté en mi misma línea de 
acción y de pensamiento. Y con este paso que dan se aleja más de lo que 
espero de una distribución como Debian.

De RedHat o Ubuntu lo puedo esperar; de Debian, no.

> Cualquiera de las tres opciones será buena para Debian y sus usuarios

Me cuesta ver algo bueno en recomendar y promover software propietario, 
la verdad :-/

¹Lo que se debate ahora en Debian está relacionado exclusivamente con 
el código firmware, no con programas o controladores propietarios.

Saludos,

-- 
Camaleón 

Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[Javier Barroso]

Buenas,

El dom., 28 ago. 2022 10:11, Camaleón  escribió:

> Hola,
>
> A través de Phoronix¹ leo que en Debian² se está llevando a cabo una
> consulta sobre la política a seguir con los paquetes de firmware
> non-free, que actualmente se tienen que instalar por separado y de
> manera plenamente consciente, con el consiguiente perjuicio que causa
> en las instalaciones, principalmente a los nuevos usuarios.
>
> En fin, la habitual dicotomía entre hacer lo correcto y sufrir un poco
> las consecuencias o pasarse al lado oscuro (lo que yo llamo «el
> modo vago»).
>
> Las alternativas que hay sobre la mesa son:
>
> A. Meter los paquetes de firmware non-free dentro del medio de
> instalación, como si fueran uno más, sin que sea obligatoio informar al
> usuario de esto.
>
> B. Meter los paquetes non-free en el medio de instalación oficial pero
> sólo cargarlos / instalarlos si son necesarios, informando al usuario y
> permitiendo desactivar previamente esta opción.
>
> Se mantienen dos medios por separado, dando preeminencia al medio de
> instalación que contienen los paquetes de non-free.
>
> C. Un poco como la situación actual, dos medios de instalación separados
> para que el usuario elija cuál descargar e instalar.
>
>  ...
>
> ¿Qué pensáis?


La opción A sí informa de qué se instala (al menos lo interpreto así), lo
que yo creo que sería deseable es que te dijera el instalador , "se va a
instalar los componentes non free que te proporcionan la siguientes
funcionalidades:

- 
- 

Aceptar / instalar sin esos componentes (o incluso, (de)seleccione los
componentes non free y pulsa siguiente)

Donde  e  son tanto los nombres de los componentes como su
descripción corta

En la lista de debian-vote daban el argumento de la accesibilidad (para
ciegos por ejemplo) como algo fundamental para el instalador.

Aún con un instalador libre vas a estar corriendo tu equipo con firmwares
no libres (los que van integrados en la tarjeta gráfica, de red, etc), en
mi opinión facilitar al usuario el mejor rendimiento del equipo es lo
deseable. Los firmwares llevan "toda la vida" en los repositorios, esto es
ponerlos en el instalador al alcance de cualquiera.

Para los puristas con activar el modo libre al arrancar (igual que hemos
estado usando el modo experto mucho tiempo) les tendría que ser suficiente

Cualquiera de las tres opciones será buena para Debian y sus usuarios

Saludos

Re: Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[Alejandro Liv]

Disculpen mis faltas de ortografía, mandé el correo sin revisarlo antes.

Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[Alejandro Liv]

; la escuela. No veo a la gente común fabricando estetoscopios, marcapasos,
> medicamentos, vacunas, el último chip que hace que sus vehículos se manejen
> solos, aviones, etc. en sus casas, porque se debe de saber lo que se hace y
> eso tiene su dificultad. Por eso Linux no será un sistema súper familiar y
> reconocido, porque la mejor herramienta es la que el experto domina. Es
> verdad que todo es mejorable, pero por favor, en verdad crees que los miles
> o millones de desarrolladores, que por defecto requieren tener cierto nivel
> intelectual, hacen las aplicaciones libres como las hacen porque son
> torpes, ¿crees que si fabrican un pincel más fácil y cómo de utilizar
> podrás pintar como DaVinci? o ¿con un mejor martillo y un cincel podrás
> hacer una mejor pieza que Miguel Angel con sus primitivas herramientas? (No
> te menosprecio, puede que seas un erudito en dichas artes o cualquier tema,
> solo hago hincapié en el hecho de que "La herramienta no hace al hombre, el
> hombre hace a la herramienta").
>
> Al igual que ustedes me desvié del tema, porque creo que nada de lo que
> comentamos tiene que ver con la pregunta de Camaleón y en cómo puede
> beneficiarnos o perjudicarnos, realmente, los cambios en el instalador de
> Debian, dándonos la oportunidad de elegir si instala software, o no, que ya
> existe en los repositorios o es accesible de manera "oficial" desde siempre
> por el sistema.
>
>
> El dom, 28 ago 2022 a las 3:11, Camaleón () escribió:
>
>> Hola,
>>
>> A través de Phoronix¹ leo que en Debian² se está llevando a cabo una
>> consulta sobre la política a seguir con los paquetes de firmware
>> non-free, que actualmente se tienen que instalar por separado y de
>> manera plenamente consciente, con el consiguiente perjuicio que causa
>> en las instalaciones, principalmente a los nuevos usuarios.
>>
>> En fin, la habitual dicotomía entre hacer lo correcto y sufrir un poco
>> las consecuencias o pasarse al lado oscuro (lo que yo llamo «el
>> modo vago»).
>>
>> Las alternativas que hay sobre la mesa son:
>>
>> A. Meter los paquetes de firmware non-free dentro del medio de
>> instalación, como si fueran uno más, sin que sea obligatoio informar al
>> usuario de esto.
>>
>> B. Meter los paquetes non-free en el medio de instalación oficial pero
>> sólo cargarlos / instalarlos si son necesarios, informando al usuario y
>> permitiendo desactivar previamente esta opción.
>>
>> Se mantienen dos medios por separado, dando preeminencia al medio de
>> instalación que contienen los paquetes de non-free.
>>
>> C. Un poco como la situación actual, dos medios de instalación separados
>> para que el usuario elija cuál descargar e instalar.
>>
>> Desde mi punto de vista, la opción A no me convence en absoluto,
>> significa claudicar.
>>
>> De la opción B no me fío, porque el kernel recomienda paquetes non-free
>> que no son necesarios así que el automatismo no funciona.
>>
>> La opción C es la menos mala y la más sincera con los usuarios, pero
>> perjudica a los nuevos o a los más novatos que tienen que buscar e
>> informarse... lo que tampoco es malo >:-)
>>
>> ¿Qué pensáis?
>>
>> ¹https://www.phoronix.com/news/Debian-Non-Free-Firmware-GR
>> ²https://www.debian.org/vote/2022/vote_003
>>
>> Saludos,
>>
>> --
>> Camaleón
>>
>>

Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[Alejandro Liv]

o requieren tener cierto nivel
intelectual, hacen las aplicaciones libres como las hacen porque son
torpes, ¿crees que si fabrican un pincel más fácil y cómo de utilizar
podrás pintar como DaVinci? o ¿con un mejor martillo y un cincel podrás
hacer una mejor pieza que Miguel Angel con sus primitivas herramientas? (No
te menosprecio, puede que seas un erudito en dichas artes o cualquier tema,
solo hago hincapié en el hecho de que "La herramienta no hace al hombre, el
hombre hace a la herramienta").

Al igual que ustedes me desvié del tema, porque creo que nada de lo que
comentamos tiene que ver con la pregunta de Camaleón y en cómo puede
beneficiarnos o perjudicarnos, realmente, los cambios en el instalador de
Debian, dándonos la oportunidad de elegir si instala software, o no, que ya
existe en los repositorios o es accesible de manera "oficial" desde siempre
por el sistema.


El dom, 28 ago 2022 a las 3:11, Camaleón () escribió:

> Hola,
>
> A través de Phoronix¹ leo que en Debian² se está llevando a cabo una
> consulta sobre la política a seguir con los paquetes de firmware
> non-free, que actualmente se tienen que instalar por separado y de
> manera plenamente consciente, con el consiguiente perjuicio que causa
> en las instalaciones, principalmente a los nuevos usuarios.
>
> En fin, la habitual dicotomía entre hacer lo correcto y sufrir un poco
> las consecuencias o pasarse al lado oscuro (lo que yo llamo «el
> modo vago»).
>
> Las alternativas que hay sobre la mesa son:
>
> A. Meter los paquetes de firmware non-free dentro del medio de
> instalación, como si fueran uno más, sin que sea obligatoio informar al
> usuario de esto.
>
> B. Meter los paquetes non-free en el medio de instalación oficial pero
> sólo cargarlos / instalarlos si son necesarios, informando al usuario y
> permitiendo desactivar previamente esta opción.
>
> Se mantienen dos medios por separado, dando preeminencia al medio de
> instalación que contienen los paquetes de non-free.
>
> C. Un poco como la situación actual, dos medios de instalación separados
> para que el usuario elija cuál descargar e instalar.
>
> Desde mi punto de vista, la opción A no me convence en absoluto,
> significa claudicar.
>
> De la opción B no me fío, porque el kernel recomienda paquetes non-free
> que no son necesarios así que el automatismo no funciona.
>
> La opción C es la menos mala y la más sincera con los usuarios, pero
> perjudica a los nuevos o a los más novatos que tienen que buscar e
> informarse... lo que tampoco es malo >:-)
>
> ¿Qué pensáis?
>
> ¹https://www.phoronix.com/news/Debian-Non-Free-Firmware-GR
> ²https://www.debian.org/vote/2022/vote_003
>
> Saludos,
>
> --
> Camaleón
>
>

Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[Marcelo Eduardo Giordano]

Me parece que linux tiene que ser algo simple para que cualquier pueda 
usarlo. Estamos muy bajos en participación en el mercado, por eso tantos 
problemas con drivers y aplicaciones.


Imaginemos como sería si Linux fuera el SO del 20% de las PCs del mundo.

Saludos amigos de la lista

Re: [OT] Debian decide sobre su política de paquetes firmware «non-free»

[Parodper]

O 28/08/22 ás 10:11, Camaleón escribiu:
En fin, la habitual dicotomía entre hacer lo correcto y sufrir un 
poco las consecuencias o pasarse al lado oscuro (lo que yo llamo «el

modo vago»).


En verdad, a la mayoría de la gente eso de la libertad no le importa
demasiado. Los usuarios siempre buscan la comodidad (y no les culpo,
ellos compran el ordenador para usarlo, no para andar trasteando en él).

Desde mi punto de vista, la opción A no me convence en absoluto, 
significa claudicar.


Me preocupa un poco que esa sea la que tenga más apoyos. No creo que sea
tanto problema tener dos medios de instalación. Además que, a mi
parecer, el único caso en el que son imprescindibles los controladores
no libres es cuándo se use el netboot en ordenadores sin conexión
cableada. El resto de casos se pueden instalar a posteriori.

De la opción B no me fío, porque el kernel recomienda paquetes 
non-free que no son necesarios así que el automatismo no funciona.


Por lo que entiendo, la B es como la C, pero con cambios extra al
instalador, para que muestre más información y le pregunte al usuario si
necesita y quiere instalar los controladores no libres. Sea cuál fuere
la opción que gane, se debería mejorar la sección de controladores del
instalador, con los controladores que necesita cada dispositivo y la
opción de instalarlos.


La opción C es la menos mala y la más sincera con los usuarios, pero
 perjudica a los nuevos o a los más novatos que tienen que buscar e 
informarse... lo que tampoco es malo >:-)


También es la más sencilla: Solo habría que hacer que el botón de
descargar te lleve a una página con las dos opciones, y una pequeña
explicación.

Yo, si pudiera, votaría C > B > NA > A. Me gusta que Debian sea una
distribución libre, a pesar de que la FSF no la incluya en su lista.

También se hablaba de sacar los controladores no libres y meterlos en
una sección propia. En lugar de eso, se deberían mejorar el 
sources.list, para que de una cierta fuente solo se pudieran instalar 
los paquetes que coincidan con el filtro. Algo como:


deb [ tags=use::driver ] https://deb.debian.org/debian stable non-free

o, más avanzado:

deb [ match=?tag(use::driver) ] https://deb.debian.org/debian stable 
3non-free

[OT] Debian decide sobre su política de paquetes firmware «non-free»

[Camaleón]

Hola,

A través de Phoronix¹ leo que en Debian² se está llevando a cabo una 
consulta sobre la política a seguir con los paquetes de firmware 
non-free, que actualmente se tienen que instalar por separado y de 
manera plenamente consciente, con el consiguiente perjuicio que causa 
en las instalaciones, principalmente a los nuevos usuarios.

En fin, la habitual dicotomía entre hacer lo correcto y sufrir un poco 
las consecuencias o pasarse al lado oscuro (lo que yo llamo «el 
modo vago»).

Las alternativas que hay sobre la mesa son:

A. Meter los paquetes de firmware non-free dentro del medio de 
instalación, como si fueran uno más, sin que sea obligatoio informar al 
usuario de esto.

B. Meter los paquetes non-free en el medio de instalación oficial pero 
sólo cargarlos / instalarlos si son necesarios, informando al usuario y 
permitiendo desactivar previamente esta opción.

Se mantienen dos medios por separado, dando preeminencia al medio de 
instalación que contienen los paquetes de non-free.

C. Un poco como la situación actual, dos medios de instalación separados
para que el usuario elija cuál descargar e instalar.

Desde mi punto de vista, la opción A no me convence en absoluto, 
significa claudicar.

De la opción B no me fío, porque el kernel recomienda paquetes non-free 
que no son necesarios así que el automatismo no funciona.

La opción C es la menos mala y la más sincera con los usuarios, pero 
perjudica a los nuevos o a los más novatos que tienen que buscar e 
informarse... lo que tampoco es malo >:-)

¿Qué pensáis?

¹https://www.phoronix.com/news/Debian-Non-Free-Firmware-GR
²https://www.debian.org/vote/2022/vote_003

Saludos,

-- 
Camaleón 

Re: Posible hackeo en los mirros de Rusia y en los servidores rusos que distribuyen las imágenes y gestor de paquetes

[Camaleón]

El 2022-03-07 a las 07:34 +0100, Parodper escribió:

> O 07/03/22 ás 01:30, Jose Andres Valarezo Valarezo escribiu:
> > Posible hackeo en los mirrors de Rusia y en los servidores rusos  que
> > distribuyen las imágenes y gestor de paquetes .
> > 

No he localizado ninguna noticia relacionada con este asunto, ¿tienes 
alguna fuente que podamos consultar?

> No pasaría nada. Todos los paquetes están firmados por claves
> criptográficas.

Desconociendo el alcance de la intrusión, seguiría siendo peligroso. 

Hay mucha gente que no lee los avisos y responden a todo que «sí» sin 
pararse a pensar lo que están haciendo.

Saludos,

-- 
Camaleón 

Re: Posible hackeo en los mirros de Rusia y en los servidores rusos que distribuyen las imágenes y gestor de paquetes

[Parodper]

O 07/03/22 ás 01:30, Jose Andres Valarezo Valarezo escribiu:

Posible hackeo en los mirrors de Rusia y en los servidores rusos  que
distribuyen las imágenes y gestor de paquetes .



No pasaría nada. Todos los paquetes están firmados por claves 
criptográficas.

Posible hackeo en los mirros de Rusia y en los servidores rusos que distribuyen las imágenes y gestor de paquetes

[Jose Andres Valarezo Valarezo]

Posible hackeo en los mirrors de Rusia y en los servidores rusos  que
distribuyen las imágenes y gestor de paquetes .

Re: OT: Crear paquetes deb

[Antonio Galicia]

Para publicarlo en repositorios públicos deberás contactar a otros
desarrolladores para que te firmen tu llave. Es parte del proceso de
confianza hasta donde recuerdo

 Saludos,
 Antonio Galicia

Eram quod es, eris quod sum
--

El mié., 28 de oct. de 2020 a la(s) 13:39, Ismael L. Donis Garcia
(sli...@natio.co.cu) escribió:
>
> - Original Message -
> From: "Gonzalo Rivero" 
> To: 
> Sent: Wednesday, October 28, 2020 1:51 PM
> Subject: Re: OT: Crear paquetes deb
>
>
> > El mié, 28-10-2020 a las 13:20 -0500, Ismael L. Donis Garcia escribió:
> >> - Original Message -
> >> From: "Gonzalo Rivero" 
> >> To: 
> >> Sent: Tuesday, October 27, 2020 11:08 AM
> >> Subject: Re: OT: Crear paquetes deb
> >>
> >>
> >> > El mar, 27-10-2020 a las 10:43 -0500, Ismael L. Donis Garcia
> >> > escribió:
> >> > > Ante todo disculpen el off topic.
> >> > >
> >> > > He realizado unos pequeños programas con Lazarus, y quisiera
> >> > > empaquetarlos
> >> > > para que puedan ser instalados tanto en debian como en ubuntu,
> >> > > pero
> >> > > no tengo
> >> > > la más mínima idea de como realizar esta tarea.
> >> > >
> >> > > Alguien me podría dar una pequeña ayuda en este tema?
> >> > >
> >> > > Como link o donde buscar tutoriales o cosas por el estilo.
> >> > >
> >> > http://www.debian.org/doc
> >> > en particular:
> >> > https://www.debian.org/doc/devel-manuals#packaging-tutorial
> >> >
> >>
> >> 1 Millón de gracias
> >>
> >> Me ha servido de mucho, solo me falta el como asignar los iconos a
> >> las
> >> opciones del menú ya que me crea una cuadrito negro con la opción
> >> cuando
> >> instalo el .deb
> >>
> >>
> >
> > para eso podés copiarte el archivo de menu de cualquier otro programa,
> > y cambiarlo a gusto. Supongo que en algún lugar de www.freedesktop.org
> > estará la documentación, pero no se ni por donde empezar a buscar
> >
> >
>
>
> Ya lo solucione, creando una carpeta con los iconos de la aplicación en:
> /usr/share/icons/carpeta_xxx
>
> donde carpeta_xxx es el nombre de la aplicacion 'el nombre puede ser
> cualquiera'
> Y haciendo referencia a esos iconos, por supuesto se puede hacer referencia
> a cualquier icono existente, pero eso no da la personalización que yo quería
> obtener.
>
> Ahora me falta estudiar lo referente al versionado de los paquetes, va que
> uno empieza y como que la cosa sigue con más cosas por aprender.
>
> Muchas gracias reiteradas.
> --
> Ismael
>
>

Re: OT: Crear paquetes deb

[Ismael L. Donis Garcia]

- Original Message - 
From: "Gonzalo Rivero" 

To: 
Sent: Wednesday, October 28, 2020 1:51 PM
Subject: Re: OT: Crear paquetes deb



El mié, 28-10-2020 a las 13:20 -0500, Ismael L. Donis Garcia escribió:
- Original Message - 
From: "Gonzalo Rivero" 

To: 
Sent: Tuesday, October 27, 2020 11:08 AM
Subject: Re: OT: Crear paquetes deb


> El mar, 27-10-2020 a las 10:43 -0500, Ismael L. Donis Garcia
> escribió:
> > Ante todo disculpen el off topic.
> >
> > He realizado unos pequeños programas con Lazarus, y quisiera
> > empaquetarlos
> > para que puedan ser instalados tanto en debian como en ubuntu,
> > pero
> > no tengo
> > la más mínima idea de como realizar esta tarea.
> >
> > Alguien me podría dar una pequeña ayuda en este tema?
> >
> > Como link o donde buscar tutoriales o cosas por el estilo.
> >
> http://www.debian.org/doc
> en particular:
> https://www.debian.org/doc/devel-manuals#packaging-tutorial
>

1 Millón de gracias

Me ha servido de mucho, solo me falta el como asignar los iconos a
las
opciones del menú ya que me crea una cuadrito negro con la opción
cuando
instalo el .deb




para eso podés copiarte el archivo de menu de cualquier otro programa,
y cambiarlo a gusto. Supongo que en algún lugar de www.freedesktop.org
estará la documentación, pero no se ni por donde empezar a buscar





Ya lo solucione, creando una carpeta con los iconos de la aplicación en:
/usr/share/icons/carpeta_xxx

donde carpeta_xxx es el nombre de la aplicacion 'el nombre puede ser 
cualquiera'
Y haciendo referencia a esos iconos, por supuesto se puede hacer referencia 
a cualquier icono existente, pero eso no da la personalización que yo quería 
obtener.


Ahora me falta estudiar lo referente al versionado de los paquetes, va que 
uno empieza y como que la cosa sigue con más cosas por aprender.


Muchas gracias reiteradas.
--
Ismael

Re: OT: Crear paquetes deb

[Gonzalo Rivero]

El mié, 28-10-2020 a las 13:20 -0500, Ismael L. Donis Garcia escribió:
> - Original Message - 
> From: "Gonzalo Rivero" 
> To: 
> Sent: Tuesday, October 27, 2020 11:08 AM
> Subject: Re: OT: Crear paquetes deb
> 
> 
> > El mar, 27-10-2020 a las 10:43 -0500, Ismael L. Donis Garcia
> > escribió:
> > > Ante todo disculpen el off topic.
> > > 
> > > He realizado unos pequeños programas con Lazarus, y quisiera
> > > empaquetarlos
> > > para que puedan ser instalados tanto en debian como en ubuntu,
> > > pero
> > > no tengo
> > > la más mínima idea de como realizar esta tarea.
> > > 
> > > Alguien me podría dar una pequeña ayuda en este tema?
> > > 
> > > Como link o donde buscar tutoriales o cosas por el estilo.
> > > 
> > http://www.debian.org/doc
> > en particular:
> > https://www.debian.org/doc/devel-manuals#packaging-tutorial
> > 
> 
> 1 Millón de gracias
> 
> Me ha servido de mucho, solo me falta el como asignar los iconos a
> las 
> opciones del menú ya que me crea una cuadrito negro con la opción
> cuando 
> instalo el .deb
> 
> 

para eso podés copiarte el archivo de menu de cualquier otro programa,
y cambiarlo a gusto. Supongo que en algún lugar de www.freedesktop.org 
estará la documentación, pero no se ni por donde empezar a buscar

Re: OT: Crear paquetes deb

[Ismael L. Donis Garcia]

- Original Message - 
From: "Gonzalo Rivero" 

To: 
Sent: Tuesday, October 27, 2020 11:08 AM
Subject: Re: OT: Crear paquetes deb



El mar, 27-10-2020 a las 10:43 -0500, Ismael L. Donis Garcia escribió:

Ante todo disculpen el off topic.

He realizado unos pequeños programas con Lazarus, y quisiera
empaquetarlos
para que puedan ser instalados tanto en debian como en ubuntu, pero
no tengo
la más mínima idea de como realizar esta tarea.

Alguien me podría dar una pequeña ayuda en este tema?

Como link o donde buscar tutoriales o cosas por el estilo.


http://www.debian.org/doc
en particular:
https://www.debian.org/doc/devel-manuals#packaging-tutorial



1 Millón de gracias

Me ha servido de mucho, solo me falta el como asignar los iconos a las 
opciones del menú ya que me crea una cuadrito negro con la opción cuando 
instalo el .deb


Gracias Reiteradas
--
Ismael

Re: OT: Crear paquetes deb

[Gonzalo Rivero]

El mar, 27-10-2020 a las 10:43 -0500, Ismael L. Donis Garcia escribió:
> Ante todo disculpen el off topic.
> 
> He realizado unos pequeños programas con Lazarus, y quisiera
> empaquetarlos 
> para que puedan ser instalados tanto en debian como en ubuntu, pero
> no tengo 
> la más mínima idea de como realizar esta tarea.
> 
> Alguien me podría dar una pequeña ayuda en este tema?
> 
> Como link o donde buscar tutoriales o cosas por el estilo.
> 
http://www.debian.org/doc
en particular: 
https://www.debian.org/doc/devel-manuals#packaging-tutorial

OT: Crear paquetes deb

[Ismael L. Donis Garcia]

Ante todo disculpen el off topic.

He realizado unos pequeños programas con Lazarus, y quisiera empaquetarlos 
para que puedan ser instalados tanto en debian como en ubuntu, pero no tengo 
la más mínima idea de como realizar esta tarea.


Alguien me podría dar una pequeña ayuda en este tema?

Como link o donde buscar tutoriales o cosas por el estilo.

Saludos
--
Ismael 

Re: paquetes retenidos

[Juan Lavieri]

Hola.

El 15/4/2020 a las 9:34 a. m., diego leon giraldo garcia escribió:
gracias a todos por responder. pues con dist-upgrade tendría una nueva 
versión del sistema creo aunque funciona bien por el momento. y respecto 
a la respuesta de Javier pues no utilizo google porque se supone que es 
la primera opción preguntar a los que saben y no informaciones de pronto 
demasiado extensas. 


Creo que tienes un concepto distorsionado del propósito de la lista, sus 
integrantes y lo que hay que hacer en nuestro trabajo diario.


La primera opción es leer detenidamente la información, ejecutar las 
acciones, si se encuentran mensajes (de cualquier tipo) intentar 
comprende qué está sucediendo o ha sucedido (google).


Si hay problemas, investigar las posibles soluciones (google).

Si todo esto no produce resultados, se consulta a la lista y las 
consultas aquí, deberían ser algo como:


Estoy intentando realizar x; para ejecuto las acciones  y el 
sistema hace z.  Además aparecen los mensajes aaa.
He investigado y realizados las acciones b y sigue sin resolverse mi 
problema.


Con algo como eso, "los que saben" pueden ayudarte mejor.

Se que leer esas respuestas tan largas que aparecen en google es muy 
fastidioso, pero los que saben, saben porque leen.



Saludos.


aunque veo que sera mejor utilizar a mister google

primero sobre todo para los que somos neofilos en el tema.
gracias

El mié., 15 abr. 2020 a las 8:12, Marco Möller 
(<mailto:ta...@debianlists.mobilxpress.net>>) escribió:


On 15.04.20 14:23, diego leon giraldo garcia wrote:
 > buenos días lista.
 >
 > pregunto porque en Debian 10 luego de ejecutar apt update
aparecen dos
 > paquetes para actualizar, ejecuto apt  upgrade y dice paquetes
retenidos
 > (dos) . trato de instalar paquete por paquete con install pero
sigue los
 > paquetes retenidos.
 >
 >
 > gracias
 >

(antes de todo, por favor perdoname fallos en el idioma no es mi lengua
nativa)

apt  no borra archivos, solo hace upgrades de archivos o instalaciones
de paquetes nuevos. Probablemente un upgrade tuyo necesitaría a borrar
un paquete viejo - lo que no está permitido. Este problema al veces
ocurre si un paquete NO tiene nombre "ABCD" acompañado por un numero de
versión "1.2.3" guardado en otro lugar, pero esta llamado directamente
con el numero como parte del nombre, por ejemplo "ABCD-1.2.3". Si la
instalación tuya ahora requiere substituir "ABCD-1.2.3" por
"ABCD-4.1.0"
hay un problema, por que no se trata de un update del mismo paquete
"ABCD" con distintos números de versión, pero el sistema lo trata como
dos paquetes distintas llamadas "ABCD-1.2.3" y "ABCD-4.1.0".

Deberías seguir las informaciones que aparecen por (utilizando "-s"
para
solo hacer simulación pero no cambiar tu sistema de verdad)
"apt upgrade -s nombre-de-un-paquete-que-es-parte-del-problema"
o
"apt install -s nombre-de-un-paquete-que-es-parte-del-problema"

leer y buscar si es el problema del tipo que sospecho, podría estar
necesario entrar a más detalle y estudiar lo que dice
"apt show nombre-de-un-paquete-que-es-parte-del-problema"

Con las informaciones tendrías que evaluar si querías tomar el riesgo y
borrar un paquete manualmente antes de instalar el otro. Esto solo sea
recomendado si sabes muy bien que el paquete que borras no sea
necesario
ya no para ninguna otra dependencia en el sistema! Probablemente que no
sepas esto y no podrías tomar una decisión segura.

Entonces de quedas con una opción más: cruzando dedos que el
problema ya
es conocido y por eso que ya hay una solución automática, lo que para
Debian "stable" debería ser como eso: No hagas simplemente en upgrade,
pero todo un dist-upgrade! La función dist-upgrade permite borrar
archivos si esto soluciona un problema sin romper otras dependencias.
Prueba con "-s" primero:
"apt dist-upgrade -s"



--
Errar es de humanos, pero es mas humano culpar a los demás

Re: paquetes retenidos

[Marco Möller]

On 15.04.20 15:34, diego leon giraldo garcia wrote:
con dist-upgrade tendría una nueva versión del sistema 
Simplemente recibirías el upgrade de 10 o de 10.1 o de 10.2, depende de 
lo que por el momento tienes, al más actual 10.3, de todas formas te 
quedarías en la rama del Debian "Buster" (stable, Debian 10) y esto no 
debería cambiar tu sistema aparte de instalar todas las upgrades de 
seguridad y solucionar problemas justo como (probablemente) el que tienes.


Quizás hacer un backup, tipo image completo, y probarlo solo después. 
Recuerda que con la opción "-s" en el "apt dist-upgrade -s" simplemente 
te va ha informar al detalle de lo que pasaría, que cambios se tendría, 
sin de verdad aplicarlos.


Como ya estas en Debian "stable" puedes confiar que no te cambiaría el 
sistema a algo ya no conocido. Más hay a esperar que ni vas a notar como 
usuario ningún cambio. Los cambios dentro de la rama "stable" 
normalmente solo son correcciones de fallos conocidos o parches de 
seguridad, pero no cambios generales en el diseño del sistema.

Re: paquetes retenidos

[diego leon giraldo garcia]

gracias a todos por responder. pues con dist-upgrade tendría una nueva
versión del sistema creo aunque funciona bien por el momento. y respecto a
la respuesta de Javier pues no utilizo google porque se supone que es la
primera opción preguntar a los que saben y no informaciones de pronto
demasiado extensas. aunque veo que sera mejor utilizar a mister google
primero sobre todo para los que somos neofilos en el tema.
gracias

El mié., 15 abr. 2020 a las 8:12, Marco Möller (<
ta...@debianlists.mobilxpress.net>) escribió:

> On 15.04.20 14:23, diego leon giraldo garcia wrote:
> > buenos días lista.
> >
> > pregunto porque en Debian 10 luego de ejecutar apt update aparecen dos
> > paquetes para actualizar, ejecuto apt  upgrade y dice paquetes retenidos
> > (dos) . trato de instalar paquete por paquete con install pero sigue los
> > paquetes retenidos.
> >
> >
> > gracias
> >
>
> (antes de todo, por favor perdoname fallos en el idioma no es mi lengua
> nativa)
>
> apt  no borra archivos, solo hace upgrades de archivos o instalaciones
> de paquetes nuevos. Probablemente un upgrade tuyo necesitaría a borrar
> un paquete viejo - lo que no está permitido. Este problema al veces
> ocurre si un paquete NO tiene nombre "ABCD" acompañado por un numero de
> versión "1.2.3" guardado en otro lugar, pero esta llamado directamente
> con el numero como parte del nombre, por ejemplo "ABCD-1.2.3". Si la
> instalación tuya ahora requiere substituir "ABCD-1.2.3" por "ABCD-4.1.0"
> hay un problema, por que no se trata de un update del mismo paquete
> "ABCD" con distintos números de versión, pero el sistema lo trata como
> dos paquetes distintas llamadas "ABCD-1.2.3" y "ABCD-4.1.0".
>
> Deberías seguir las informaciones que aparecen por (utilizando "-s" para
> solo hacer simulación pero no cambiar tu sistema de verdad)
> "apt upgrade -s nombre-de-un-paquete-que-es-parte-del-problema"
> o
> "apt install -s nombre-de-un-paquete-que-es-parte-del-problema"
>
> leer y buscar si es el problema del tipo que sospecho, podría estar
> necesario entrar a más detalle y estudiar lo que dice
> "apt show nombre-de-un-paquete-que-es-parte-del-problema"
>
> Con las informaciones tendrías que evaluar si querías tomar el riesgo y
> borrar un paquete manualmente antes de instalar el otro. Esto solo sea
> recomendado si sabes muy bien que el paquete que borras no sea necesario
> ya no para ninguna otra dependencia en el sistema! Probablemente que no
> sepas esto y no podrías tomar una decisión segura.
>
> Entonces de quedas con una opción más: cruzando dedos que el problema ya
> es conocido y por eso que ya hay una solución automática, lo que para
> Debian "stable" debería ser como eso: No hagas simplemente en upgrade,
> pero todo un dist-upgrade! La función dist-upgrade permite borrar
> archivos si esto soluciona un problema sin romper otras dependencias.
> Prueba con "-s" primero:
> "apt dist-upgrade -s"
>
>

Re: paquetes retenidos

[Marco Möller]

On 15.04.20 14:23, diego leon giraldo garcia wrote:

buenos días lista.

pregunto porque en Debian 10 luego de ejecutar apt update aparecen dos
paquetes para actualizar, ejecuto apt  upgrade y dice paquetes retenidos
(dos) . trato de instalar paquete por paquete con install pero sigue los
paquetes retenidos.


gracias



(antes de todo, por favor perdoname fallos en el idioma no es mi lengua 
nativa)


apt  no borra archivos, solo hace upgrades de archivos o instalaciones 
de paquetes nuevos. Probablemente un upgrade tuyo necesitaría a borrar 
un paquete viejo - lo que no está permitido. Este problema al veces 
ocurre si un paquete NO tiene nombre "ABCD" acompañado por un numero de 
versión "1.2.3" guardado en otro lugar, pero esta llamado directamente 
con el numero como parte del nombre, por ejemplo "ABCD-1.2.3". Si la 
instalación tuya ahora requiere substituir "ABCD-1.2.3" por "ABCD-4.1.0" 
hay un problema, por que no se trata de un update del mismo paquete 
"ABCD" con distintos números de versión, pero el sistema lo trata como 
dos paquetes distintas llamadas "ABCD-1.2.3" y "ABCD-4.1.0".


Deberías seguir las informaciones que aparecen por (utilizando "-s" para 
solo hacer simulación pero no cambiar tu sistema de verdad)

"apt upgrade -s nombre-de-un-paquete-que-es-parte-del-problema"
o
"apt install -s nombre-de-un-paquete-que-es-parte-del-problema"

leer y buscar si es el problema del tipo que sospecho, podría estar 
necesario entrar a más detalle y estudiar lo que dice

"apt show nombre-de-un-paquete-que-es-parte-del-problema"

Con las informaciones tendrías que evaluar si querías tomar el riesgo y 
borrar un paquete manualmente antes de instalar el otro. Esto solo sea 
recomendado si sabes muy bien que el paquete que borras no sea necesario 
ya no para ninguna otra dependencia en el sistema! Probablemente que no 
sepas esto y no podrías tomar una decisión segura.


Entonces de quedas con una opción más: cruzando dedos que el problema ya 
es conocido y por eso que ya hay una solución automática, lo que para 
Debian "stable" debería ser como eso: No hagas simplemente en upgrade, 
pero todo un dist-upgrade! La función dist-upgrade permite borrar 
archivos si esto soluciona un problema sin romper otras dependencias. 
Prueba con "-s" primero:

"apt dist-upgrade -s"

Re: paquetes retenidos

[JAP Debian]

El 15/4/20 a las 09:23, diego leon giraldo garcia escribió:

buenos días lista.

pregunto porque en Debian 10 luego de ejecutar apt update aparecen dos 
paquetes para actualizar, ejecuto apt  upgrade y dice paquetes retenidos 
(dos) . trato de instalar paquete por paquete con install pero sigue los 
paquetes retenidos.



gracias


STFW

https://lmgtfy.com/?q=debian+%C2%BFque+es+un+paquete+retenido%3F&iie=1

JAP

Re: paquetes retenidos

[Roberto C . Sánchez]

On Wed, Apr 15, 2020 at 07:23:48AM -0500, diego leon giraldo garcia wrote:
>buenos días lista.
>pregunto porque en Debian 10 luego de ejecutar apt update aparecen dos
>    paquetes para actualizar, ejecuto apt  upgrade y dice paquetes retenidos
>(dos) . trato de instalar paquete por paquete con install pero sigue los
>paquetes retenidos.
>gracias

¿Y que pasa si usas 'update' en lugar de 'install'?

Saludos,

-Roberto

-- 
Roberto C. Sánchez

paquetes retenidos

[diego leon giraldo garcia]

buenos días lista.

pregunto porque en Debian 10 luego de ejecutar apt update aparecen dos
paquetes para actualizar, ejecuto apt  upgrade y dice paquetes retenidos
(dos) . trato de instalar paquete por paquete con install pero sigue los
paquetes retenidos.


gracias

Re: ¿Hasta donde se desarrollan los paquetes Debian?

[Alberto Luaces]

Miguel de Dios Matias writes:

> El sáb., 9 nov. 2019 20:35, Roberto C. Sánchez  escribió:
>
>  On Sat, Nov 09, 2019 at 08:29:23PM +0100, Miguel de Dios Matias wrote:
>  >Buenas.
>  >Tengo otra pregunta "un poco rara".
>  >Cuándo un paquete el upstream este muerto. ¿Qué se hace el paquete 
> Debian?
>  >¿Se le abre un git en salsa y se sigue avanzando el paquete? ¿Sólo se
>  >mantiene los fallos de seguridad?¿Se elimina de Debian?
>  >Saludos.
>
>  Eso todo depende de la inclinación del que mantiene el paquete.  Hay
>  ejemplos de todas las tres posibilidades que mencionas.  ¿Tienes un
>  paquete específico que te interesa con respeto a tu pregunta?
>
> Tengo varios en mente, juegos viejitos que conocí en Debian Woody y que en 
> Sourceforge están muertos.
>
> Por ejemplo "Pachi el marciano".
>
> Me gustaría hacer algún arreglo a los bugs abiertos (...que creo que
> eso es es bastante asequible sin ser DD o DM) y después darle un poco
> de vida (...pero supongo que primero tengo que hacer todo el proceso
> de convertirse de DD o DM).

Los paquetes se mantienen indefinidamente hasta que los saque un fallo:
fallo al compilar, dependencias incumplidas o bien fallos de seguridad.
He visto paquetes muy viejos, sin que nadie se ocupe de ellos, perdurar
en el directorio simplemente porque no daban problemas.

Si estás interesado en ese paquete en particular, podrías buscar el
fallo que hizo que lo sacasen automáticamente de la distribución,
arreglarlo y después pedir a alguien que lo suba (no hace falta ser DD
ni DM, simplemente seguir las instrucciones en
https://mentors.debian.net/sponsors/rfs-howto) o solicitarlo a algún DD
que conozcas.

Un saludo,

-- 
Alberto

Re: ¿Hasta donde se desarrollan los paquetes Debian?

[eduardo gil]

 Vaya uno a saber que hacen los paquetes muertos.
Hay muchos de ellos, algunos con programas similares a otros que también se han 
dejado de desarrollar.
En su tiempo hubo cientos de editores de notas, la mayoría similares mientras 
faltaban programas para hacer otras cosas.
Hay áreas en donde LINUX (no sólo Debian) hace "agua", por ejemplo la edición 
multimedia de calidad profesional (Kenlive es lo mejorcito pero está a años luz 
de un SONY VEGAS), los juegos, los buenos clientes de correo (el Thunder es muy 
básico) e incluso de un paquete de oficina que esté a la altura del Office (el 
LibreOffice se quedó en el tiempo y es muy pesado).
Linux está bárbaro para servers o para clientes sin muchas necesidades pero... 
faltan programas, muchos programas en algunas áreas específicas y sobran muchos 
otros que son similares a otros.

 El sábado, 9 de noviembre de 2019 16:29:52 ART, Miguel de Dios Matias 
 escribió:  
 
 Buenas.
Tengo otra pregunta "un poco rara".
Cuándo un paquete el upstream este muerto. ¿Qué se hace el paquete Debian?
¿Se le abre un git en salsa y se sigue avanzando el paquete? ¿Sólo se mantiene 
los fallos de seguridad?¿Se elimina de Debian?
Saludos.  

Re: ¿Hasta donde se desarrollan los paquetes Debian?

[Miguel de Dios Matias]

El sáb., 9 nov. 2019 20:35, Roberto C. Sánchez 
escribió:

> On Sat, Nov 09, 2019 at 08:29:23PM +0100, Miguel de Dios Matias wrote:
> >Buenas.
> >Tengo otra pregunta "un poco rara".
> >Cuándo un paquete el upstream este muerto. ¿Qué se hace el paquete
> Debian?
> >¿Se le abre un git en salsa y se sigue avanzando el paquete? ¿Sólo se
> >mantiene los fallos de seguridad?¿Se elimina de Debian?
> >Saludos.
>
> Eso todo depende de la inclinación del que mantiene el paquete.  Hay
> ejemplos de todas las tres posibilidades que mencionas.  ¿Tienes un
> paquete específico que te interesa con respeto a tu pregunta?
>

Tengo varios en mente, juegos viejitos que conocí en Debian Woody y que en
Sourceforge están muertos.

Por ejemplo "Pachi el marciano".

Me gustaría hacer algún arreglo a los bugs abiertos (...que creo que eso es
es bastante asequible sin ser DD o DM) y después darle un poco de vida
(...pero supongo que primero tengo que hacer todo el proceso de convertirse
de DD o DM).

Saludos.


> Saludos,
>
> -Roberto
> --
> Roberto C. Sánchez
>
>

Re: ¿Hasta donde se desarrollan los paquetes Debian?

[Roberto C . Sánchez]

On Sat, Nov 09, 2019 at 08:29:23PM +0100, Miguel de Dios Matias wrote:
>Buenas.
>Tengo otra pregunta "un poco rara".
>Cuándo un paquete el upstream este muerto. ¿Qué se hace el paquete Debian?
>¿Se le abre un git en salsa y se sigue avanzando el paquete? ¿Sólo se
>mantiene los fallos de seguridad?¿Se elimina de Debian?
>Saludos.

Eso todo depende de la inclinación del que mantiene el paquete.  Hay
ejemplos de todas las tres posibilidades que mencionas.  ¿Tienes un
paquete específico que te interesa con respeto a tu pregunta?

Saludos,

-Roberto
-- 
Roberto C. Sánchez

¿Hasta donde se desarrollan los paquetes Debian?

[Miguel de Dios Matias]

Buenas.

Tengo otra pregunta "un poco rara".

Cuándo un paquete el upstream este muerto. ¿Qué se hace el paquete Debian?

¿Se le abre un git en salsa y se sigue avanzando el paquete? ¿Sólo se
mantiene los fallos de seguridad?¿Se elimina de Debian?

Saludos.

Re: Buscador de paquetes: estén fuera de la distribución y o el upstream este muerto

[Miguel de Dios Matias]

Buenas pregunte por stackoverflow (bueno el de sistemas operativos) y
me respondieron rápido con una posible forma de sacar los paquetes que
tienen el upstream muerto usando uud.debian.org :

https://unix.stackexchange.com/questions/549318/in-debian-is-there-a-list-of-packages-with-dead-parent-project

El mar., 29 oct. 2019 a las 16:24, Miguel de Dios Matias
() escribió:
>
> El mar., 29 oct. 2019 a las 15:41, Paynalton () 
> escribió:
> >
> >
> > Si un ave no rompe su huevo morirá antes de nacer.
> > Nosotros somos el ave y el mundo es nuestro huevo.
> > POR LA REVOLUCIÓN DEL MUNDO
> >
> > Ciudad de México
> >
> >
> > El mar., 29 oct. 2019 a las 5:18, Debian () 
> > escribió:
> >>
> >> El 28/10/19 a las 19:49, Miguel de Dios Matias escribió:
> >> > Buenas.
> >> >
> >> > Es más por curiosidad y ver como se gestiona las situaciones.
> >> >
> >> > TL;DR, ¿Existe algún servicio web de Debian que busque paquetes
> >> > eliminados de la última versión? ¿Existe alguna forma de ver que
> >> > paquetes ya no tienen upstream?
> >> >
> >
> >
> > Puedes hacer lo siguiente:
> >
> > Primero:
> >
> > apt update
> >
> > apt-cache search . > repo1
>
> Oye pues la idea es simple pero yo creo que puede funcionar muy bien,
> voy a ver si puedo afinar para sacar los paquetes por arquitectura y
> tal. Gracias.
>
> Me queda la otra duda, de como sacar los paquetes que "están activos"
> en Debian pese a que haya muerto el proyecto original...porque me
> huelo que hay muchos...
>
> >
> > Luego cambia tu sources.list a otro repositorio y repite los mismos pasos 
> > para crear un archivo por cada repositorio que quieras revisar.
> >
> > Por último usa DIFF para comparar los archivos y ver las diferencias entre 
> > ellos.
> >
> >>
> >> > He estado buscando por la web algún buscador o listado de los paquetes
> >> > que se han sacado de los repositorios, porque recuerdo en Debian Woody
> >> > había un par de juegos hechos con una librería llamada clanlib, no
> >> > recuerdo el nombre.
> >> >
> >> > He intentado meter en el source.list debian woody de
> >> > archive.debian.org pero falla porque en esos años no había la
> >> > arquitectura amd64.
> >> >
> >> > Ahora estoy bajando las isos de cd de aquella época y las voy a poner
> >> > en una maquina virtual.
> >> >
> >> > Saludos.
> >> >
> >>
> >>
> >> ¿Esto te sirve?
> >>
> >> Debian Package Tracking System
> >>
> >> https://packages.qa.debian.org/common/index.html
> >>
> >>
> >> JAP
> >>

Re: Buscador de paquetes: estén fuera de la distribución y o el upstream este muerto

[Miguel de Dios Matias]

El mar., 29 oct. 2019 a las 15:41, Paynalton () escribió:
>
>
> Si un ave no rompe su huevo morirá antes de nacer.
> Nosotros somos el ave y el mundo es nuestro huevo.
> POR LA REVOLUCIÓN DEL MUNDO
>
> Ciudad de México
>
>
> El mar., 29 oct. 2019 a las 5:18, Debian () 
> escribió:
>>
>> El 28/10/19 a las 19:49, Miguel de Dios Matias escribió:
>> > Buenas.
>> >
>> > Es más por curiosidad y ver como se gestiona las situaciones.
>> >
>> > TL;DR, ¿Existe algún servicio web de Debian que busque paquetes
>> > eliminados de la última versión? ¿Existe alguna forma de ver que
>> > paquetes ya no tienen upstream?
>> >
>
>
> Puedes hacer lo siguiente:
>
> Primero:
>
> apt update
>
> apt-cache search . > repo1

Oye pues la idea es simple pero yo creo que puede funcionar muy bien,
voy a ver si puedo afinar para sacar los paquetes por arquitectura y
tal. Gracias.

Me queda la otra duda, de como sacar los paquetes que "están activos"
en Debian pese a que haya muerto el proyecto original...porque me
huelo que hay muchos...

>
> Luego cambia tu sources.list a otro repositorio y repite los mismos pasos 
> para crear un archivo por cada repositorio que quieras revisar.
>
> Por último usa DIFF para comparar los archivos y ver las diferencias entre 
> ellos.
>
>>
>> > He estado buscando por la web algún buscador o listado de los paquetes
>> > que se han sacado de los repositorios, porque recuerdo en Debian Woody
>> > había un par de juegos hechos con una librería llamada clanlib, no
>> > recuerdo el nombre.
>> >
>> > He intentado meter en el source.list debian woody de
>> > archive.debian.org pero falla porque en esos años no había la
>> > arquitectura amd64.
>> >
>> > Ahora estoy bajando las isos de cd de aquella época y las voy a poner
>> > en una maquina virtual.
>> >
>> > Saludos.
>> >
>>
>>
>> ¿Esto te sirve?
>>
>> Debian Package Tracking System
>>
>> https://packages.qa.debian.org/common/index.html
>>
>>
>> JAP
>>

Re: Buscador de paquetes: estén fuera de la distribución y o el upstream este muerto

[Paynalton]

Si un ave no rompe su huevo morirá antes de nacer.
Nosotros somos el ave y el mundo es nuestro huevo.
POR LA REVOLUCIÓN DEL MUNDO

Ciudad de México


El mar., 29 oct. 2019 a las 5:18, Debian ()
escribió:

> El 28/10/19 a las 19:49, Miguel de Dios Matias escribió:
> > Buenas.
> >
> > Es más por curiosidad y ver como se gestiona las situaciones.
> >
> > TL;DR, ¿Existe algún servicio web de Debian que busque paquetes
> > eliminados de la última versión? ¿Existe alguna forma de ver que
> > paquetes ya no tienen upstream?
> >
>

Puedes hacer lo siguiente:

Primero:

apt update

apt-cache search . > repo1

Luego cambia tu sources.list a otro repositorio y repite los mismos pasos
para crear un archivo por cada repositorio que quieras revisar.

Por último usa DIFF para comparar los archivos y ver las diferencias entre
ellos.


> > He estado buscando por la web algún buscador o listado de los paquetes
> > que se han sacado de los repositorios, porque recuerdo en Debian Woody
> > había un par de juegos hechos con una librería llamada clanlib, no
> > recuerdo el nombre.
> >
> > He intentado meter en el source.list debian woody de
> > archive.debian.org pero falla porque en esos años no había la
> > arquitectura amd64.
> >
> > Ahora estoy bajando las isos de cd de aquella época y las voy a poner
> > en una maquina virtual.
> >
> > Saludos.
> >
>
>
> ¿Esto te sirve?
>
> Debian Package Tracking System
>
> https://packages.qa.debian.org/common/index.html
>
>
> JAP
>
>

Re: Buscador de paquetes: estén fuera de la distribución y o el upstream este muerto

[Debian]

El 28/10/19 a las 19:49, Miguel de Dios Matias escribió:

Buenas.

Es más por curiosidad y ver como se gestiona las situaciones.

TL;DR, ¿Existe algún servicio web de Debian que busque paquetes
eliminados de la última versión? ¿Existe alguna forma de ver que
paquetes ya no tienen upstream?

He estado buscando por la web algún buscador o listado de los paquetes
que se han sacado de los repositorios, porque recuerdo en Debian Woody
había un par de juegos hechos con una librería llamada clanlib, no
recuerdo el nombre.

He intentado meter en el source.list debian woody de
archive.debian.org pero falla porque en esos años no había la
arquitectura amd64.

Ahora estoy bajando las isos de cd de aquella época y las voy a poner
en una maquina virtual.

Saludos.




¿Esto te sirve?

Debian Package Tracking System

https://packages.qa.debian.org/common/index.html


JAP

Buscador de paquetes: estén fuera de la distribución y o el upstream este muerto

[Miguel de Dios Matias]

Buenas.

Es más por curiosidad y ver como se gestiona las situaciones.

TL;DR, ¿Existe algún servicio web de Debian que busque paquetes
eliminados de la última versión? ¿Existe alguna forma de ver que
paquetes ya no tienen upstream?

He estado buscando por la web algún buscador o listado de los paquetes
que se han sacado de los repositorios, porque recuerdo en Debian Woody
había un par de juegos hechos con una librería llamada clanlib, no
recuerdo el nombre.

He intentado meter en el source.list debian woody de
archive.debian.org pero falla porque en esos años no había la
arquitectura amd64.

Ahora estoy bajando las isos de cd de aquella época y las voy a poner
en una maquina virtual.

Saludos.

paquetes que no aparecen en debian 10.0

[Daniel Villalpando]

Synaptic y menu libre no aparecen en debian 10.0 en la instalación experta con 
1 dvd o con 3

Re: ¿Cómo instalar los paquetes de mi debian 9 en otra máquina?

[ziprasidone146939...@gmail.com]

On Fri, 2019-05-17 at 15:36 -0600, Roberto José Blandino Cisneros
wrote:
> Hay dos formas para lo que quieres, la primera tratando de hacer la
> solicitud de descargar las dependencias:
> 
> 1.- Primero solo hagamos un echo para ver que el script busca todos
> los paquetes que necesitamos y las dependencias de cada uno:
> 
> while read app; do for subapp in $(apt-cache depends $app | grep
> "Depende:\|Depends:"| awk -F: '{print $2}' | sed "s/ "s/>//g");do echo "$app -> $subapp";done; echo
> "===" ;done < <(ls /var/cache/apt/archives/*.deb
> |
> awk -F_ '{print $1}' | awk -F"/" '{print $NF}')
> 
> 2.- Si al ejecutarlo hace lo que necesitamos entonces ahora vamos a
> indicarle que descargue esas dependencias.
> mkdir debpkg
> cd debpkg
> while read app; do for subapp in $(apt-cache depends $app | grep
> "Depende:\|Depends:"| awk -F: '{print $2}' | sed "s/ "s/>//g");do aptitude download $subapp;done; echo
> "===" ;done < <(ls /var/cache/apt/archives/*.deb
> |
> awk -F_ '{print $1}' | awk -F"/" '{print $NF}')
> 
> La segunda forma de respaldar los paquetes de la maquina A es de la
> siguiente forma:
> 
> mkdir debpkg
> cd debpkg
> while read app; do aptitude download $app;done < <(dpkg -l | grep
> "^ii\|^rc" | awk '{print $2}')
> 
> Luego seria con un scp mandar todos los paquetes de A hacia B
> 
> NOTA: En caso de no tener aptitude y querer usar apt sustituir
> "aptitude download" con "apt-get install --download-only"
> 
> Saludos, espero te sirva.
> 
> On Fri, May 17, 2019 at 8:31 AM Centro Patrimonio Pinar del Río
>  wrote:
> > 
> > Hola lista. Tengo solamente una PC con internet ... Hace un tiempo
> > leí
> > sobre cómo instalar todos los paquetes de mi debian 9 en otra
> > máquina
> > que tenga debian 9 igual. Que recuerde explicaban una serie de
> > comandos
> > para por ejemplo obtener la instalación de cierto software
> > incluyendo
> > sus dependencias ... Sé que todos estos *.deb se guardan en
> > /var/cache/apt/archives ... Pero quiero, especificamente obtener el
> > software, ej. samba con sus dependencias y llevarlos e instalarlos
> > en la
> > otra PC ... Si pueden pongan links de webs donde expliquen esto.
> > 
> > Gracias
> > 
> 
> 

(si los esquipo estan en red)

Por qué no hacer que la PC con internet se convierta en un
repositorio local (dentro de la red donde se encuentra el equipo sin
internet)? 

Una vez listo ese servidor, hara en el equipo sin internet apt install
, configurando como repositorio el equipo que ahora es un
repositorio local.

Es una idea..

Saludos

Re: ¿Cómo instalar los paquetes de mi debian 9 en otra máquina?

[Roberto José Blandino Cisneros]

Hay dos formas para lo que quieres, la primera tratando de hacer la
solicitud de descargar las dependencias:

1.- Primero solo hagamos un echo para ver que el script busca todos
los paquetes que necesitamos y las dependencias de cada uno:

while read app; do for subapp in $(apt-cache depends $app | grep
"Depende:\|Depends:"| awk -F: '{print $2}' | sed "s///g");do echo "$app -> $subapp";done; echo
"===" ;done < <(ls /var/cache/apt/archives/*.deb |
awk -F_ '{print $1}' | awk -F"/" '{print $NF}')

2.- Si al ejecutarlo hace lo que necesitamos entonces ahora vamos a
indicarle que descargue esas dependencias.
mkdir debpkg
cd debpkg
while read app; do for subapp in $(apt-cache depends $app | grep
"Depende:\|Depends:"| awk -F: '{print $2}' | sed "s///g");do aptitude download $subapp;done; echo
"===" ;done < <(ls /var/cache/apt/archives/*.deb |
awk -F_ '{print $1}' | awk -F"/" '{print $NF}')

La segunda forma de respaldar los paquetes de la maquina A es de la
siguiente forma:

mkdir debpkg
cd debpkg
while read app; do aptitude download $app;done < <(dpkg -l | grep
"^ii\|^rc" | awk '{print $2}')

Luego seria con un scp mandar todos los paquetes de A hacia B

NOTA: En caso de no tener aptitude y querer usar apt sustituir
"aptitude download" con "apt-get install --download-only"

Saludos, espero te sirva.

On Fri, May 17, 2019 at 8:31 AM Centro Patrimonio Pinar del Río
 wrote:
>
> Hola lista. Tengo solamente una PC con internet ... Hace un tiempo leí
> sobre cómo instalar todos los paquetes de mi debian 9 en otra máquina
> que tenga debian 9 igual. Que recuerde explicaban una serie de comandos
> para por ejemplo obtener la instalación de cierto software incluyendo
> sus dependencias ... Sé que todos estos *.deb se guardan en
> /var/cache/apt/archives ... Pero quiero, especificamente obtener el
> software, ej. samba con sus dependencias y llevarlos e instalarlos en la
> otra PC ... Si pueden pongan links de webs donde expliquen esto.
>
> Gracias
>


-- 

¿Cómo instalar los paquetes de mi debian 9 en otra máquina?

[Centro Patrimonio Pinar del Río]

Hola lista. Tengo solamente una PC con internet ... Hace un tiempo leí 
sobre cómo instalar todos los paquetes de mi debian 9 en otra máquina 
que tenga debian 9 igual. Que recuerde explicaban una serie de comandos 
para por ejemplo obtener la instalación de cierto software incluyendo 
sus dependencias ... Sé que todos estos *.deb se guardan en 
/var/cache/apt/archives ... Pero quiero, especificamente obtener el 
software, ej. samba con sus dependencias y llevarlos e instalarlos en la 
otra PC ... Si pueden pongan links de webs donde expliquen esto.


Gracias

Re: ¿Qué significa los teams como mantenedor de paquetes Debian?

[Hector Colina]

El 30/4/18, Alberto Luaces  escribió:
> Miguel de Dios Matias writes:
>
>> Buenas.
>>
>> Mirando el paquete Bless (que es un editor hexadecimal en GTK)
>> https://tracker.debian.org/pkg/bless .
>>
>> He visto que de mantenedor está el "Debian CLI Applications Team" y de
>> uploader (¿Qué no se qué función cumple?) si está una persona.
>>
>> ¿Eso qué significa? ¿Qué el paquete está huérfano?
>>
> Todo lo contrario; un equipo está formado por un grupo de
> desarrolladores con interés en programas similares, de tal manera que
> cualquiera de ellos puede trabajar sobre cualquier paquete del grupo,
> haciendo el desarrollo más ágil.  Los casos más paradigmáticos podrían
> ser los equipos de Perl o Python, que mantienen miles de paquetes.
>
> El que figura en «uploaders» puede ser generalmente el que empezó el
> paquete, aunque bien podría ser cualquier otra persona (incluso externa
> al grupo).
>
> --
> Alberto
>
>

Para conocer más sobre los teams en Debian, puedes visitar el siguiente enlace:

https://wiki.debian.org/Teams

Saludos.

Re: ¿Qué significa los teams como mantenedor de paquetes Debian?

[Alberto Luaces]

Miguel de Dios Matias writes:

> Buenas.
>
> Mirando el paquete Bless (que es un editor hexadecimal en GTK) 
> https://tracker.debian.org/pkg/bless .
>
> He visto que de mantenedor está el "Debian CLI Applications Team" y de 
> uploader (¿Qué no se qué función cumple?) si está una persona.
>
> ¿Eso qué significa? ¿Qué el paquete está huérfano?
>
Todo lo contrario; un equipo está formado por un grupo de
desarrolladores con interés en programas similares, de tal manera que
cualquiera de ellos puede trabajar sobre cualquier paquete del grupo,
haciendo el desarrollo más ágil.  Los casos más paradigmáticos podrían
ser los equipos de Perl o Python, que mantienen miles de paquetes.

El que figura en «uploaders» puede ser generalmente el que empezó el
paquete, aunque bien podría ser cualquier otra persona (incluso externa
al grupo).

-- 
Alberto

¿Qué significa los teams como mantenedor de paquetes Debian?

[Miguel de Dios Matias]

Buenas.

Mirando el paquete Bless (que es un editor hexadecimal en GTK)
https://tracker.debian.org/pkg/bless .

He visto que de mantenedor está el "Debian CLI Applications Team" y de
uploader (¿Qué no se qué función cumple?) si está una persona.

¿Eso qué significa? ¿Qué el paquete está huérfano?

Saludos.

Re: Paquetes retenidos y aplicaciones rotas tras actualizar a Debian 9

[Iván]

On 04/07/17 06:22, José María wrote:





Buenas,



Hola Iván, intenta no hacer top-posting ni escribir en HTML por favor, 
son normas de la lista [1]


(Te corrijo el top-posting)




On 27/06/17 22:53, José María wrote:

El 26/06/17 a las 13:42, JAP escribió:

El 26/06/17 a las 05:57, Iván Hernández Cazorla escribió:

Buenas,
Creo que no es la primera vez que me suscribo a esta lista de correo,
pero nunca está de más agradecer a todos aquellos que atienden los
correos de antemano. Gracias. Bueno, les comento mi problema.

Últimamente ando un poco desactualizado de las novedades de todo,
inclusive de Debian. Fue ayer cuando me enteré de que el 17 de 
junio de

2017 se lanzó Debian 9 Stretch
<https://www.debian.org/News/2017/20170617>. Con la emoción fui un 
poco
a la desesperada y busqué rápidamente "how to upgrade debian 8 to 
9" y

me encontré con este tutorial
<https://www.linuxbabe.com/debian/upgrade-debian-8-jessie-to-debian-9-stretch>. 



Lo seguí al pie de la letra. Pero, cuando el ordenador se reinició 
tras
ejecutar *shutdown -r now*, comprobé que algo no había ido bien 
por dos

razones:

 1. Al ejecutar *lsb_release -a *me mostraba (y sigue mostrando este
mensaje):
No LSB modules are available.
Distributor ID:Debian
Description:Debian GNU/Linux 9.0 (n/a)
Release:9.0
Codename:n/a
Donde debería indicar el codename "Stretch", no indica nada, 
solo n/a.

 2. Hay programas que se han roto. Por ej. el navegador de archivos
"nemo" y VLC.

Como no atinaba con que podía ser la razón de este fallo, ejecuté un
*apt-get update *y luego un *upgrade* para comprobar que todos los
paquetes se habían actualizado. Sin embargo, para mi sorpresa, a 
estas

horas de la mañana que he vuelto a intentarlo, me dice que:

1 actualizados, 0 nuevos se instalarán, 0 para eliminar y 748 no
actualizados.

Al revisar los 748 paquetes no actualizados por encima, me 
encuentro con
la sorpresa de que VLC y sus dependencias, de la misma manera que 
muchos

otros, no se han actualizado, razón por la que creo que en estos
momentos no funciona.

Quitando esto, creo además que el comportamiento del cargador ha
comenzado a hacer cosas extrañas, pero esto ya es otra cuestión 
que iré

analizando con el tiempo de uso de Stretch.

Les adjunto una imagen con la información del sistema por si fuese de
alguna utilidad.

Muchas gracias de antemano.

Saludos, Iván



El cambio de nombre en cada equipo, siempre es algo que a veces, 
tarda.

Por ejemplo, yo estoy en "testing", y aún sigue como Debian 9 Stretch.

Recomendación: luego de

# apt-get upgrade

haz un

# apt-get dist-upgrade

Probablemente tengas paquetes que se estén reteniendo.

Esto va a hacer una actualización más completa y va a solucionar 
cosas que una actualización normal no hace, por tema de seguridad 
del sistema.


dist-upgrade in addition to performing the function of upgrade, 
also intelligently handles changing dependencies with new versions 
of packages; apt-get has a "smart" conflict resolution system, and 
it will attempt to upgrade the most important packages at the 
expense of less important ones if necessary. The dist-upgrade 
command may therefore remove some packages. The 
/etc/apt/sources.list file contains a list of locations from which 
to retrieve desired package files. See also apt_preferences(5) for 
a mechanism for overriding the general settings for individual 
packages.


JAP




Y también las "Notas de publicación", punto 4 completo.

https://www.debian.org/releases/stable/releasenotes




Primero, darles las gracias a cada uno de los que me han respondido. 
Les comento:


  * *JAP*. Cuando actualicé realicé el apt-get dist-upgrade después del
apt-get upgrade, pero cuando se reinició el ordenador apareció el
problema comentado. Volví a intentar hacer el apt-get dist-upgrade y
muestra cómo lo hace pero cómo que nunca termina de actualizarse.
  * *José María*. Gracias por las notas de publicación, debí haberles
echado un vistazo antes de actualizar. Fallo mío. Lo tendré en
cuenta para la próxima.

¿Hay alguna forma de restaurar Debian 8.8 para luego intentar 
realizar la actualización y comprobar si funciona correctamente?




Uff!.. Es complicado responderte a esa pregunta, depende de lo que 
hayas hecho con tu sistema.


Según lo que pone en el enlace que aportaste y lo que te ha dicho JAP 
sería suficiente para actualizar tu Debian, pero si has hecho algo de 
lo que pone aquí [2], ni lo intentaba.


Personalmente reinstalaba Debian para no tener dolores de cabeza.


[1] https://wiki.debian.org/es/NormasLista
[2] https://wiki.debian.org/es/DontBreakDebian



Buenas José María,
Por una parte, agradecerte que hayas corregido el top-posting. Las 
listas en las que he participado siempre sea respondido por encima. Me 
lo apunto para que no se me escape más.


Por otra parte, siento haber respondido tras má

Re: descarcar dependencias de paquetes

[juan carlos]

El 29/06/17 a las 18:58, claudio menet escribió:

Hola Carlos,

No se que características tiene el dispositivo en el cuál vas a
descargar los paquetes.

Cómo idea se me ocurre que instales una máquina virtual con el mismo
sistema operativo y características de hardware que el que tiene
problema de red y lo utilices para descargar los paquetes.

Por otro lado no se si el dispositivo que no tiene red si tiene
lectora de DVD, si la tiene podrías descargarte la ISO de debian 8.5 y
quemarla en un dvd para luego activar el repositorio de DVD en el
source.list o gráficamente desde origenes de software y utilizarlo
como repositorio.

Por último si no dispones de DVD puedes intentar utilizar un pen drive
como repositorio de software pero con esto último no sabría como
ayudarte.

Saludos!

El día 29 de junio de 2017, 14:53, juan carlos  escribió:

On 29/06/17 17:50, claudio menet wrote:

Hola Juan,

Podes utilizar el siguiente comando para obtener una lista de las
dependencias del paquete, luego utilizar esa lista para descargar los
paquetes.

apt-cache depends openjdk-8-jdk

De todas maneras no se si los paquetes que descargues y copies al otro
dispositivo te vallan a funcionar si este no dispone del mismo sistema
operativo y arquitectura de hardware.

Saludos!

El día 29 de junio de 2017, 14:35, juan carlos 
escribió:

On 29/06/17 17:28, Eduardo Visbal wrote:

Y porque no lo instalas asi: apt install firefox (ejemplo)
puedes utilizar aptitude, apt-get o apt

Eduardo Visbal
Linuxero #440451
http://esdebianfritto.blogspot.com/

El 29 de junio de 2017, 13:01, juan carlos  escribió:

buenas me gustaia saber como podria descargar las dependencias de un
paquete, osea hago por ejemplo sudo apt-get download firefox y se me
baja
solo el paquete firefox pero no sus dependencias, no se si se me
entiende


porque el paquete firefox es solo un ejemplo lo que necesito es instalar
java en un pc el cual se me rompio la tarjeta de red por eso bajarme las
dependencias de todo el paquete openjdk-8-jdk

el que no tiene red usa debian 8.5 habra problemas?

hola siento haber tardado en contestar, el que no tiene red usa la 8.5 y 
el que si la tiene usa la 8.7 ambos de 64 bits, lo de la iso esta 
descartado porque debian no ofrece isos anteriores lo que si ofrece son 
los repos para cada version asi que descartado, el tema de ver las 
dependecias ese comando show no existe almenos no en la 8.5 pero gracias 
a gdebi puedo verlas e ir bajandolas de una en una, ahora tengo otro 
poblemon, odio tener que ir compilando cada vez que quiera instalar algo 
y me propuse crear un paquete pero.
la info oficial solo me indica como crearlo con un paquete fuente ya 
debianiado pero no como compilarlo y debianizarlo desde cero, osea 
compilar compila perfecto pero se tarda 30 minutos y claro por eso lo 
del paquete, los blogs que hablan de como crearlos desde cero dan pasos 
erroneos o incompetos, no quiero dar links por si me baneais por spam 
pero voy a dar el ultimo donde lo vi que es erroneo

http://culturacion.com/como-crear-un-paquete-deb/

este blog hace el ejemplo con un editor de texto pero yo para que quepa 
todos los errores que me da lo probe con un programita c++ tonto que 
hice para la prueba


 dpkg-buildpackage -rfakeroot -D -us -uc
dpkg-buildpackage: paquete fuente hola
dpkg-buildpackage: versión de las fuentes 1.0-1
dpkg-buildpackage: distribución de las fuentes stable
dpkg-buildpackage: fuentes modificadas por juancar 
 dpkg-source --before-build hola-1.0
dpkg-buildpackage: arquitectura del sistema amd64
 fakeroot debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
   dh_clean
 dpkg-source -b hola-1.0
dpkg-source: información: usando el formato de fuente «3.0 (quilt)»
dpkg-source: información: construyendo «hola» usando 
«./hola_1.0.orig.tar.xz», que está presente en el sistema
dpkg-source: fallo: no se puede representar el cambio de 
hola-1.0.tar.xz: el contenido del archivo binario ha cambiado
dpkg-source: fallo: añada «hola-1.0.tar.xz» en 
«debian/source/include-binaries» si desea guardar el binario modificado 
en el archivo tar de Debian
dpkg-source: fallo: no se pueden representar los cambios hechos a las 
fuentes
dpkg-buildpackage: fallo: dpkg-source -b hola-1.0 devolvió un estado de 
salida de error 2

debuild: fatal error at line 1376:
dpkg-buildpackage -rfakeroot -D -us -uc failed

los pasos que hice son los que pone en la web lo unico que cambia es la 
aplicacion usada, lo curioso esque me dice que añada el tar en 
include-binaries pero si lo hago luego me dice que se detecta archivo no 
deseado, puede alguien decirme como crear realmente los paquetes desde 
cero? (no debianizados) que esa es la unica informacion oficial que hay 
gracias

Re: Paquetes retenidos y aplicaciones rotas tras actualizar a Debian 9

[José María]

Buenas,



Hola Iván, intenta no hacer top-posting ni escribir en HTML por favor, 
son normas de la lista [1]


(Te corrijo el top-posting)




On 27/06/17 22:53, José María wrote:

El 26/06/17 a las 13:42, JAP escribió:

El 26/06/17 a las 05:57, Iván Hernández Cazorla escribió:

Buenas,
Creo que no es la primera vez que me suscribo a esta lista de correo,
pero nunca está de más agradecer a todos aquellos que atienden los
correos de antemano. Gracias. Bueno, les comento mi problema.

Últimamente ando un poco desactualizado de las novedades de todo,
inclusive de Debian. Fue ayer cuando me enteré de que el 17 de junio de
2017 se lanzó Debian 9 Stretch
<https://www.debian.org/News/2017/20170617>. Con la emoción fui un poco
a la desesperada y busqué rápidamente "how to upgrade debian 8 to 9" y
me encontré con este tutorial
<https://www.linuxbabe.com/debian/upgrade-debian-8-jessie-to-debian-9-stretch>. 



Lo seguí al pie de la letra. Pero, cuando el ordenador se reinició tras
ejecutar *shutdown -r now*, comprobé que algo no había ido bien por dos
razones:

 1. Al ejecutar *lsb_release -a *me mostraba (y sigue mostrando este
mensaje):
No LSB modules are available.
Distributor ID:Debian
Description:Debian GNU/Linux 9.0 (n/a)
Release:9.0
Codename:n/a
Donde debería indicar el codename "Stretch", no indica nada, 
solo n/a.

 2. Hay programas que se han roto. Por ej. el navegador de archivos
"nemo" y VLC.

Como no atinaba con que podía ser la razón de este fallo, ejecuté un
*apt-get update *y luego un *upgrade* para comprobar que todos los
paquetes se habían actualizado. Sin embargo, para mi sorpresa, a estas
horas de la mañana que he vuelto a intentarlo, me dice que:

1 actualizados, 0 nuevos se instalarán, 0 para eliminar y 748 no
actualizados.

Al revisar los 748 paquetes no actualizados por encima, me encuentro 
con
la sorpresa de que VLC y sus dependencias, de la misma manera que 
muchos

otros, no se han actualizado, razón por la que creo que en estos
momentos no funciona.

Quitando esto, creo además que el comportamiento del cargador ha
comenzado a hacer cosas extrañas, pero esto ya es otra cuestión que iré
analizando con el tiempo de uso de Stretch.

Les adjunto una imagen con la información del sistema por si fuese de
alguna utilidad.

Muchas gracias de antemano.

Saludos, Iván



El cambio de nombre en cada equipo, siempre es algo que a veces, tarda.
Por ejemplo, yo estoy en "testing", y aún sigue como Debian 9 Stretch.

Recomendación: luego de

# apt-get upgrade

haz un

# apt-get dist-upgrade

Probablemente tengas paquetes que se estén reteniendo.

Esto va a hacer una actualización más completa y va a solucionar 
cosas que una actualización normal no hace, por tema de seguridad del 
sistema.


dist-upgrade in addition to performing the function of upgrade, also 
intelligently handles changing dependencies with new versions of 
packages; apt-get has a "smart" conflict resolution system, and it 
will attempt to upgrade the most important packages at the expense of 
less important ones if necessary. The dist-upgrade command may 
therefore remove some packages. The /etc/apt/sources.list file 
contains a list of locations from which to retrieve desired package 
files. See also apt_preferences(5) for a mechanism for overriding the 
general settings for individual packages.


JAP




Y también las "Notas de publicación", punto 4 completo.

https://www.debian.org/releases/stable/releasenotes




Primero, darles las gracias a cada uno de los que me han respondido. Les 
comento:


  * *JAP*. Cuando actualicé realicé el apt-get dist-upgrade después del
apt-get upgrade, pero cuando se reinició el ordenador apareció el
problema comentado. Volví a intentar hacer el apt-get dist-upgrade y
muestra cómo lo hace pero cómo que nunca termina de actualizarse.
  * *José María*. Gracias por las notas de publicación, debí haberles
echado un vistazo antes de actualizar. Fallo mío. Lo tendré en
cuenta para la próxima.

¿Hay alguna forma de restaurar Debian 8.8 para luego intentar realizar 
la actualización y comprobar si funciona correctamente?




Uff!.. Es complicado responderte a esa pregunta, depende de lo que hayas 
hecho con tu sistema.


Según lo que pone en el enlace que aportaste y lo que te ha dicho JAP 
sería suficiente para actualizar tu Debian, pero si has hecho algo de lo 
que pone aquí [2], ni lo intentaba.


Personalmente reinstalaba Debian para no tener dolores de cabeza.


[1] https://wiki.debian.org/es/NormasLista
[2] https://wiki.debian.org/es/DontBreakDebian

Re: Paquetes retenidos y aplicaciones rotas tras actualizar a Debian 9

[Iván Hernández Cazorla]

Buenas,

Primero, darles las gracias a cada uno de los que me han respondido. Les 
comento:


 * *JAP*. Cuando actualicé realicé el apt-get dist-upgrade después del
   apt-get upgrade, pero cuando se reinició el ordenador apareció el
   problema comentado. Volví a intentar hacer el apt-get dist-upgrade y
   muestra cómo lo hace pero cómo que nunca termina de actualizarse.
 * *José María*. Gracias por las notas de publicación, debí haberles
   echado un vistazo antes de actualizar. Fallo mío. Lo tendré en
   cuenta para la próxima.

¿Hay alguna forma de restaurar Debian 8.8 para luego intentar realizar 
la actualización y comprobar si funciona correctamente?


Saludos, Iván


On 27/06/17 22:53, José María wrote:

El 26/06/17 a las 13:42, JAP escribió:

El 26/06/17 a las 05:57, Iván Hernández Cazorla escribió:

Buenas,
Creo que no es la primera vez que me suscribo a esta lista de correo,
pero nunca está de más agradecer a todos aquellos que atienden los
correos de antemano. Gracias. Bueno, les comento mi problema.

Últimamente ando un poco desactualizado de las novedades de todo,
inclusive de Debian. Fue ayer cuando me enteré de que el 17 de junio de
2017 se lanzó Debian 9 Stretch
<https://www.debian.org/News/2017/20170617>. Con la emoción fui un poco
a la desesperada y busqué rápidamente "how to upgrade debian 8 to 9" y
me encontré con este tutorial
<https://www.linuxbabe.com/debian/upgrade-debian-8-jessie-to-debian-9-stretch>. 



Lo seguí al pie de la letra. Pero, cuando el ordenador se reinició tras
ejecutar *shutdown -r now*, comprobé que algo no había ido bien por dos
razones:

 1. Al ejecutar *lsb_release -a *me mostraba (y sigue mostrando este
mensaje):
No LSB modules are available.
Distributor ID:Debian
Description:Debian GNU/Linux 9.0 (n/a)
Release:9.0
Codename:n/a
Donde debería indicar el codename "Stretch", no indica nada, 
solo n/a.

 2. Hay programas que se han roto. Por ej. el navegador de archivos
"nemo" y VLC.

Como no atinaba con que podía ser la razón de este fallo, ejecuté un
*apt-get update *y luego un *upgrade* para comprobar que todos los
paquetes se habían actualizado. Sin embargo, para mi sorpresa, a estas
horas de la mañana que he vuelto a intentarlo, me dice que:

1 actualizados, 0 nuevos se instalarán, 0 para eliminar y 748 no
actualizados.

Al revisar los 748 paquetes no actualizados por encima, me encuentro 
con
la sorpresa de que VLC y sus dependencias, de la misma manera que 
muchos

otros, no se han actualizado, razón por la que creo que en estos
momentos no funciona.

Quitando esto, creo además que el comportamiento del cargador ha
comenzado a hacer cosas extrañas, pero esto ya es otra cuestión que iré
analizando con el tiempo de uso de Stretch.

Les adjunto una imagen con la información del sistema por si fuese de
alguna utilidad.

Muchas gracias de antemano.

Saludos, Iván



El cambio de nombre en cada equipo, siempre es algo que a veces, tarda.
Por ejemplo, yo estoy en "testing", y aún sigue como Debian 9 Stretch.

Recomendación: luego de

# apt-get upgrade

haz un

# apt-get dist-upgrade

Probablemente tengas paquetes que se estén reteniendo.

Esto va a hacer una actualización más completa y va a solucionar 
cosas que una actualización normal no hace, por tema de seguridad del 
sistema.


dist-upgrade in addition to performing the function of upgrade, also 
intelligently handles changing dependencies with new versions of 
packages; apt-get has a "smart" conflict resolution system, and it 
will attempt to upgrade the most important packages at the expense of 
less important ones if necessary. The dist-upgrade command may 
therefore remove some packages. The /etc/apt/sources.list file 
contains a list of locations from which to retrieve desired package 
files. See also apt_preferences(5) for a mechanism for overriding the 
general settings for individual packages.


JAP




Y también las "Notas de publicación", punto 4 completo.

https://www.debian.org/releases/stable/releasenotes


Saludos




--
Iván Hernández Cazorla.
Estudiante del Grado de Historia en la *Universidad de Las Palmas de 
Gran Canaria*.

Socio de *Wikimedia España*.
Sitio web personal <http://distriker.com>.

Re: descarcar dependencias de paquetes

[Juan Lavieri]

  
  
Hola Juan Carlos.


El 29-06-2017 a las 01:01 p.m., juan
  carlos escribió:

buenas
  me gustaia saber como podria descargar las dependencias de un
  paquete, osea hago por ejemplo sudo apt-get download firefox y se
  me baja solo el paquete firefox pero no sus dependencias, no se si
  se me entiende
  
  


En realidad no he probado si para hacer solo download sirve;  lo que
si se es que si deseas instalar un paque con todas sus dependencias
es preferible usar:

#aptitude install firefox

Está documentado en la debian reference que es el método preferido
para ese tipo de tareas.

De hecho yo uso 

#aptitude 

y una vez que abre la interfaz busco el paque te que necesito (con /
firerox) y desde allí controlo lo que se instala y lo que no.  

Saludos.
-- 
Juan M Lavieri

Errar es de humanos, pero es mas humano culpar a los demás.
  

Re: descarcar dependencias de paquetes

[José María]

El 29/06/17 a las 20:58, claudio menet escribió:

Hola Carlos,

No se que características tiene el dispositivo en el cuál vas a
descargar los paquetes.

Cómo idea se me ocurre que instales una máquina virtual con el mismo
sistema operativo y características de hardware que el que tiene
problema de red y lo utilices para descargar los paquetes.

Por otro lado no se si el dispositivo que no tiene red si tiene
lectora de DVD, si la tiene podrías descargarte la ISO de debian 8.5 y
quemarla en un dvd para luego activar el repositorio de DVD en el
source.list o gráficamente desde origenes de software y utilizarlo
como repositorio.

Por último si no dispones de DVD puedes intentar utilizar un pen drive
como repositorio de software pero con esto último no sabría como
ayudarte.

Saludos!

El día 29 de junio de 2017, 14:53, juan carlos  escribió:


On 29/06/17 17:50, claudio menet wrote:


Hola Juan,

Podes utilizar el siguiente comando para obtener una lista de las
dependencias del paquete, luego utilizar esa lista para descargar los
paquetes.

apt-cache depends openjdk-8-jdk

De todas maneras no se si los paquetes que descargues y copies al otro
dispositivo te vallan a funcionar si este no dispone del mismo sistema
operativo y arquitectura de hardware.

Saludos!

El día 29 de junio de 2017, 14:35, juan carlos 
escribió:


On 29/06/17 17:28, Eduardo Visbal wrote:

Y porque no lo instalas asi: apt install firefox (ejemplo)
puedes utilizar aptitude, apt-get o apt

Eduardo Visbal
Linuxero #440451
http://esdebianfritto.blogspot.com/

El 29 de junio de 2017, 13:01, juan carlos  escribió:


buenas me gustaia saber como podria descargar las dependencias de un
paquete, osea hago por ejemplo sudo apt-get download firefox y se me
baja
solo el paquete firefox pero no sus dependencias, no se si se me
entiende


porque el paquete firefox es solo un ejemplo lo que necesito es instalar
java en un pc el cual se me rompio la tarjeta de red por eso bajarme las
dependencias de todo el paquete openjdk-8-jdk


el que no tiene red usa debian 8.5 habra problemas?



Instalar algo de Debian_9 en Debian_8.5 seguramente te de problemas, 
pero por probar no pierdes nada... aunque también le podrías instalar el 
propio Java de Oracle que éste seguramente no te de problemas de 
dependencias.


Y ya puestos ¿no es mejor que le instales Debian Stretch a tu amigo? 
Pero que te quede claro que si se empeña en el openjdk-8-jdk te tendrás 
que bajar el DVD1 para la instalación de Debian y el DVD2 para 
openjdk-8-jdk... o el BD1 donde se encuentran los dos... Buah! que lío jaja


Después, como te han comentado, puedes usar la iso para instalar los 
paquetes que necesites... básicamente solo tendrías que montar la iso y 
añadir una línea en el sources.list.


Saludos

Re: descarcar dependencias de paquetes

[remgasis remgasis]

Con wget HTTP://RUTA/ARCHIVO.DEB lo puedes hacer. Verifica la sintaxis.

El 29 de junio de 2017, 13:01, juan carlos  escribió:

> buenas me gustaia saber como podria descargar las dependencias de un
> paquete, osea hago por ejemplo sudo apt-get download firefox y se me baja
> solo el paquete firefox pero no sus dependencias, no se si se me entiende
>
>

Re: descarcar dependencias de paquetes

[claudio menet]

Hola Carlos,

No se que características tiene el dispositivo en el cuál vas a
descargar los paquetes.

Cómo idea se me ocurre que instales una máquina virtual con el mismo
sistema operativo y características de hardware que el que tiene
problema de red y lo utilices para descargar los paquetes.

Por otro lado no se si el dispositivo que no tiene red si tiene
lectora de DVD, si la tiene podrías descargarte la ISO de debian 8.5 y
quemarla en un dvd para luego activar el repositorio de DVD en el
source.list o gráficamente desde origenes de software y utilizarlo
como repositorio.

Por último si no dispones de DVD puedes intentar utilizar un pen drive
como repositorio de software pero con esto último no sabría como
ayudarte.

Saludos!

El día 29 de junio de 2017, 14:53, juan carlos  escribió:
>
> On 29/06/17 17:50, claudio menet wrote:
>>
>> Hola Juan,
>>
>> Podes utilizar el siguiente comando para obtener una lista de las
>> dependencias del paquete, luego utilizar esa lista para descargar los
>> paquetes.
>>
>> apt-cache depends openjdk-8-jdk
>>
>> De todas maneras no se si los paquetes que descargues y copies al otro
>> dispositivo te vallan a funcionar si este no dispone del mismo sistema
>> operativo y arquitectura de hardware.
>>
>> Saludos!
>>
>> El día 29 de junio de 2017, 14:35, juan carlos 
>> escribió:
>>>
>>> On 29/06/17 17:28, Eduardo Visbal wrote:
>>>
>>> Y porque no lo instalas asi: apt install firefox (ejemplo)
>>> puedes utilizar aptitude, apt-get o apt
>>>
>>> Eduardo Visbal
>>> Linuxero #440451
>>> http://esdebianfritto.blogspot.com/
>>>
>>> El 29 de junio de 2017, 13:01, juan carlos  escribió:
>>>>
>>>> buenas me gustaia saber como podria descargar las dependencias de un
>>>> paquete, osea hago por ejemplo sudo apt-get download firefox y se me
>>>> baja
>>>> solo el paquete firefox pero no sus dependencias, no se si se me
>>>> entiende
>>>>
>>> porque el paquete firefox es solo un ejemplo lo que necesito es instalar
>>> java en un pc el cual se me rompio la tarjeta de red por eso bajarme las
>>> dependencias de todo el paquete openjdk-8-jdk
>
> el que no tiene red usa debian 8.5 habra problemas?
>

Re: descarcar dependencias de paquetes

[juan carlos]

On 29/06/17 17:50, claudio menet wrote:

Hola Juan,

Podes utilizar el siguiente comando para obtener una lista de las
dependencias del paquete, luego utilizar esa lista para descargar los
paquetes.

apt-cache depends openjdk-8-jdk

De todas maneras no se si los paquetes que descargues y copies al otro
dispositivo te vallan a funcionar si este no dispone del mismo sistema
operativo y arquitectura de hardware.

Saludos!

El día 29 de junio de 2017, 14:35, juan carlos  escribió:

On 29/06/17 17:28, Eduardo Visbal wrote:

Y porque no lo instalas asi: apt install firefox (ejemplo)
puedes utilizar aptitude, apt-get o apt

Eduardo Visbal
Linuxero #440451
http://esdebianfritto.blogspot.com/

El 29 de junio de 2017, 13:01, juan carlos  escribió:

buenas me gustaia saber como podria descargar las dependencias de un
paquete, osea hago por ejemplo sudo apt-get download firefox y se me baja
solo el paquete firefox pero no sus dependencias, no se si se me entiende


porque el paquete firefox es solo un ejemplo lo que necesito es instalar
java en un pc el cual se me rompio la tarjeta de red por eso bajarme las
dependencias de todo el paquete openjdk-8-jdk

el que no tiene red usa debian 8.5 habra problemas?

Re: descarcar dependencias de paquetes

[claudio menet]

Hola Juan,

Podes utilizar el siguiente comando para obtener una lista de las
dependencias del paquete, luego utilizar esa lista para descargar los
paquetes.

apt-cache depends openjdk-8-jdk

De todas maneras no se si los paquetes que descargues y copies al otro
dispositivo te vallan a funcionar si este no dispone del mismo sistema
operativo y arquitectura de hardware.

Saludos!

El día 29 de junio de 2017, 14:35, juan carlos  escribió:
>
> On 29/06/17 17:28, Eduardo Visbal wrote:
>
> Y porque no lo instalas asi: apt install firefox (ejemplo)
> puedes utilizar aptitude, apt-get o apt
>
> Eduardo Visbal
> Linuxero #440451
> http://esdebianfritto.blogspot.com/
>
> El 29 de junio de 2017, 13:01, juan carlos  escribió:
>>
>> buenas me gustaia saber como podria descargar las dependencias de un
>> paquete, osea hago por ejemplo sudo apt-get download firefox y se me baja
>> solo el paquete firefox pero no sus dependencias, no se si se me entiende
>>
>
> porque el paquete firefox es solo un ejemplo lo que necesito es instalar
> java en un pc el cual se me rompio la tarjeta de red por eso bajarme las
> dependencias de todo el paquete openjdk-8-jdk

Re: descarcar dependencias de paquetes

[juan carlos]

On 29/06/17 17:47, Eduardo Visbal wrote:
Si tienes un disco externo con mas de 500 GB te puedes crear un mirror 
local de los paquetes de Debian, eso suele salvar para este tipo de 
eventualidades


Saludos

*Eduardo Visbal
Linuxero #440451
http://esdebianfritto.blogspot.com/*

El 29 de junio de 2017, 13:43, juan carlos <mailto:nerus...@gmail.com>> escribió:



On 29/06/17 17:39, Eduardo Visbal wrote:

Ok ya entendi, seria cuestion de realizar esto:

aptitude show openjdk-8-jdk

el te muestra las dependencia que utiliza, entonces solo seria de
descargarlas de la pagina oficial de debian, osea descargar cada
paquete

*Eduardo Visbal
Linuxero #440451
http://esdebianfritto.blogspot.com/
<http://esdebianfritto.blogspot.com/>*

El 29 de junio de 2017, 13:35, juan carlos mailto:nerus...@gmail.com>> escribió:


On 29/06/17 17:28, Eduardo Visbal wrote:

Y porque no lo instalas asi: apt install firefox (ejemplo)
puedes utilizar aptitude, apt-get o apt

*Eduardo Visbal
Linuxero #440451
http://esdebianfritto.blogspot.com/
<http://esdebianfritto.blogspot.com/>*

El 29 de junio de 2017, 13:01, juan carlos
mailto:nerus...@gmail.com>> escribió:

buenas me gustaia saber como podria descargar las
dependencias de un paquete, osea hago por ejemplo sudo
apt-get download firefox y se me baja solo el paquete
firefox pero no sus dependencias, no se si se me entiende



porque el paquete firefox es solo un ejemplo lo que necesito
es instalar java en un pc el cual se me rompio la tarjeta de
red por eso bajarme las dependencias de todo el paquete
openjdk-8-jdk



ok gracias luego seria hacer un script que lo baje todo gracias me
salvaste de un apuro


con dpkg-scanpackages si pero no lo hago porque si lo hago luego me dice 
que son paquetes sin firmar y no puedo firmarlos de uno en uno

Re: descarcar dependencias de paquetes

[petrohs el compa obrero]

Buenas tardes

Encontre esto
https://stackoverflow.com/questions/13756800/how-to-download-all-dependencies-and-packages-to-directory

2017-06-29 12:43 GMT-05:00 juan carlos :

>
> On 29/06/17 17:39, Eduardo Visbal wrote:
>
> Ok ya entendi, seria cuestion de realizar esto:
>
> aptitude show openjdk-8-jdk
>
> el te muestra las dependencia que utiliza, entonces solo seria de
> descargarlas de la pagina oficial de debian, osea descargar cada paquete
>
>
>
> *Eduardo Visbal Linuxero #440451 http://esdebianfritto.blogspot.com/
> *
>
> El 29 de junio de 2017, 13:35, juan carlos  escribió:
>
>>
>> On 29/06/17 17:28, Eduardo Visbal wrote:
>>
>> Y porque no lo instalas asi: apt install firefox (ejemplo)
>> puedes utilizar aptitude, apt-get o apt
>>
>>
>>
>> *Eduardo Visbal Linuxero #440451 http://esdebianfritto.blogspot.com/
>> *
>>
>> El 29 de junio de 2017, 13:01, juan carlos  escribió:
>>
>>> buenas me gustaia saber como podria descargar las dependencias de un
>>> paquete, osea hago por ejemplo sudo apt-get download firefox y se me baja
>>> solo el paquete firefox pero no sus dependencias, no se si se me entiende
>>>
>>>
>> porque el paquete firefox es solo un ejemplo lo que necesito es instalar
>> java en un pc el cual se me rompio la tarjeta de red por eso bajarme las
>> dependencias de todo el paquete openjdk-8-jdk
>>
>
> ok gracias luego seria hacer un script que lo baje todo gracias me
> salvaste de un apuro
>



-- 
"Cada cual según sus fuerzas, cada quien según sus necesidades..."

Re: descarcar dependencias de paquetes

[juan carlos]

On 29/06/17 17:39, Eduardo Visbal wrote:

Ok ya entendi, seria cuestion de realizar esto:

aptitude show openjdk-8-jdk

el te muestra las dependencia que utiliza, entonces solo seria de 
descargarlas de la pagina oficial de debian, osea descargar cada paquete


*Eduardo Visbal
Linuxero #440451
http://esdebianfritto.blogspot.com/*

El 29 de junio de 2017, 13:35, juan carlos > escribió:



On 29/06/17 17:28, Eduardo Visbal wrote:

Y porque no lo instalas asi: apt install firefox (ejemplo)
puedes utilizar aptitude, apt-get o apt

*Eduardo Visbal
Linuxero #440451
http://esdebianfritto.blogspot.com/
*

El 29 de junio de 2017, 13:01, juan carlos mailto:nerus...@gmail.com>> escribió:

buenas me gustaia saber como podria descargar las
dependencias de un paquete, osea hago por ejemplo sudo
apt-get download firefox y se me baja solo el paquete firefox
pero no sus dependencias, no se si se me entiende



porque el paquete firefox es solo un ejemplo lo que necesito es
instalar java en un pc el cual se me rompio la tarjeta de red por
eso bajarme las dependencias de todo el paquete openjdk-8-jdk


ok gracias luego seria hacer un script que lo baje todo gracias me 
salvaste de un apuro

Re: descarcar dependencias de paquetes

[juan carlos]

On 29/06/17 17:28, Eduardo Visbal wrote:

Y porque no lo instalas asi: apt install firefox (ejemplo)
puedes utilizar aptitude, apt-get o apt

*Eduardo Visbal
Linuxero #440451
http://esdebianfritto.blogspot.com/*

El 29 de junio de 2017, 13:01, juan carlos > escribió:


buenas me gustaia saber como podria descargar las dependencias de
un paquete, osea hago por ejemplo sudo apt-get download firefox y
se me baja solo el paquete firefox pero no sus dependencias, no se
si se me entiende


porque el paquete firefox es solo un ejemplo lo que necesito es instalar 
java en un pc el cual se me rompio la tarjeta de red por eso bajarme las 
dependencias de todo el paquete openjdk-8-jdk

descarcar dependencias de paquetes

[juan carlos]

buenas me gustaia saber como podria descargar las dependencias de un 
paquete, osea hago por ejemplo sudo apt-get download firefox y se me 
baja solo el paquete firefox pero no sus dependencias, no se si se me 
entiende

Re: Paquetes retenidos y aplicaciones rotas tras actualizar a Debian 9

[José María]

El 26/06/17 a las 13:42, JAP escribió:

El 26/06/17 a las 05:57, Iván Hernández Cazorla escribió:

Buenas,
Creo que no es la primera vez que me suscribo a esta lista de correo,
pero nunca está de más agradecer a todos aquellos que atienden los
correos de antemano. Gracias. Bueno, les comento mi problema.

Últimamente ando un poco desactualizado de las novedades de todo,
inclusive de Debian. Fue ayer cuando me enteré de que el 17 de junio de
2017 se lanzó Debian 9 Stretch
<https://www.debian.org/News/2017/20170617>. Con la emoción fui un poco
a la desesperada y busqué rápidamente "how to upgrade debian 8 to 9" y
me encontré con este tutorial
<https://www.linuxbabe.com/debian/upgrade-debian-8-jessie-to-debian-9-stretch>. 



Lo seguí al pie de la letra. Pero, cuando el ordenador se reinició tras
ejecutar *shutdown -r now*, comprobé que algo no había ido bien por dos
razones:

 1. Al ejecutar *lsb_release -a *me mostraba (y sigue mostrando este
mensaje):
No LSB modules are available.
Distributor ID:Debian
Description:Debian GNU/Linux 9.0 (n/a)
Release:9.0
Codename:n/a
Donde debería indicar el codename "Stretch", no indica nada, solo 
n/a.

 2. Hay programas que se han roto. Por ej. el navegador de archivos
"nemo" y VLC.

Como no atinaba con que podía ser la razón de este fallo, ejecuté un
*apt-get update *y luego un *upgrade* para comprobar que todos los
paquetes se habían actualizado. Sin embargo, para mi sorpresa, a estas
horas de la mañana que he vuelto a intentarlo, me dice que:

1 actualizados, 0 nuevos se instalarán, 0 para eliminar y 748 no
actualizados.

Al revisar los 748 paquetes no actualizados por encima, me encuentro con
la sorpresa de que VLC y sus dependencias, de la misma manera que muchos
otros, no se han actualizado, razón por la que creo que en estos
momentos no funciona.

Quitando esto, creo además que el comportamiento del cargador ha
comenzado a hacer cosas extrañas, pero esto ya es otra cuestión que iré
analizando con el tiempo de uso de Stretch.

Les adjunto una imagen con la información del sistema por si fuese de
alguna utilidad.

Muchas gracias de antemano.

Saludos, Iván



El cambio de nombre en cada equipo, siempre es algo que a veces, tarda.
Por ejemplo, yo estoy en "testing", y aún sigue como Debian 9 Stretch.

Recomendación: luego de

# apt-get upgrade

haz un

# apt-get dist-upgrade

Probablemente tengas paquetes que se estén reteniendo.

Esto va a hacer una actualización más completa y va a solucionar cosas 
que una actualización normal no hace, por tema de seguridad del sistema.


dist-upgrade in addition to performing the function of upgrade, also 
intelligently handles changing dependencies with new versions of 
packages; apt-get has a "smart" conflict resolution system, and it will 
attempt to upgrade the most important packages at the expense of less 
important ones if necessary. The dist-upgrade command may therefore 
remove some packages. The /etc/apt/sources.list file contains a list of 
locations from which to retrieve desired package files. See also 
apt_preferences(5) for a mechanism for overriding the general settings 
for individual packages.


JAP




Y también las "Notas de publicación", punto 4 completo.

https://www.debian.org/releases/stable/releasenotes


Saludos

Re: Paquetes retenidos y aplicaciones rotas tras actualizar a Debian 9

[claudio menet]

Hola!

Yo ejecutaría un comando more sobre  /etc/apt/sources.list para verificar
si efectivamente el comando sed remplazo todas las palabras jessie por
stretch y en caso de que no esté modificado ingresaria en una terminal como
robot y lo modificaria a mano con un editor de texto que puede ser ví,
gedit o cualquier otro.

Podes saber más de los comandos more, sed, vi y gedit utilizando el comando
man

man more
man sed
man vi
man gedit

Luego de que finalmente el archivo sources.lis este actualizado ejecutaria

apt-get update
apt-get dist-upgrade
apt-get autoclean
apt-get autoremove

Saludos!


El 26 jun. 2017 14:24, "hector rodriguez"  escribió:

> El 26/6/17, JAP  escribió:
> > El 26/06/17 a las 05:57, Iván Hernández Cazorla escribió:
> >> Buenas,
> >> Creo que no es la primera vez que me suscribo a esta lista de correo,
> >> pero nunca está de más agradecer a todos aquellos que atienden los
> >> correos de antemano. Gracias. Bueno, les comento mi problema.
> >>
> >> Últimamente ando un poco desactualizado de las novedades de todo,
> >> inclusive de Debian. Fue ayer cuando me enteré de que el 17 de junio de
> >> 2017 se lanzó Debian 9 Stretch
> >> <https://www.debian.org/News/2017/20170617>. Con la emoción fui un poco
> >> a la desesperada y busqué rápidamente "how to upgrade debian 8 to 9" y
> >> me encontré con este tutorial
> >> <https://www.linuxbabe.com/debian/upgrade-debian-8-
> jessie-to-debian-9-stretch>.
> >>
> >> Lo seguí al pie de la letra. Pero, cuando el ordenador se reinició tras
> >> ejecutar *shutdown -r now*, comprobé que algo no había ido bien por dos
> >> razones:
> >>
> >>  1. Al ejecutar *lsb_release -a *me mostraba (y sigue mostrando este
> >> mensaje):
> >> No LSB modules are available.
> >> Distributor ID:Debian
> >> Description:Debian GNU/Linux 9.0 (n/a)
> >> Release:9.0
> >> Codename:n/a
> >> Donde debería indicar el codename "Stretch", no indica nada, solo
> >> n/a.
> >>  2. Hay programas que se han roto. Por ej. el navegador de archivos
> >> "nemo" y VLC.
> >>
> >> Como no atinaba con que podía ser la razón de este fallo, ejecuté un
> >> *apt-get update *y luego un *upgrade* para comprobar que todos los
> >> paquetes se habían actualizado. Sin embargo, para mi sorpresa, a estas
> >> horas de la mañana que he vuelto a intentarlo, me dice que:
> >>
> >> 1 actualizados, 0 nuevos se instalarán, 0 para eliminar y 748 no
> >> actualizados.
> >>
> >> Al revisar los 748 paquetes no actualizados por encima, me encuentro con
> >> la sorpresa de que VLC y sus dependencias, de la misma manera que muchos
> >> otros, no se han actualizado, razón por la que creo que en estos
> >> momentos no funciona.
> >>
> >> Quitando esto, creo además que el comportamiento del cargador ha
> >> comenzado a hacer cosas extrañas, pero esto ya es otra cuestión que iré
> >> analizando con el tiempo de uso de Stretch.
> >>
> >> Les adjunto una imagen con la información del sistema por si fuese de
> >> alguna utilidad.
> >>
> >> Muchas gracias de antemano.
> >>
> >> Saludos, Iván
> >
> >
> > El cambio de nombre en cada equipo, siempre es algo que a veces, tarda.
> > Por ejemplo, yo estoy en "testing", y aún sigue como Debian 9 Stretch.
> >
> > Recomendación: luego de
> >
> > # apt-get upgrade
> >
> > haz un
> >
> > # apt-get dist-upgrade
> >
> > Probablemente tengas paquetes que se estén reteniendo.
> >
> > Esto va a hacer una actualización más completa y va a solucionar cosas
> > que una actualización normal no hace, por tema de seguridad del sistema.
> >
> > dist-upgrade in addition to performing the function of upgrade, also
> > intelligently handles changing dependencies with new versions of
> > packages; apt-get has a "smart" conflict resolution system, and it will
> > attempt to upgrade the most important packages at the expense of less
> > important ones if necessary. The dist-upgrade command may therefore
> > remove some packages. The /etc/apt/sources.list file contains a list of
> > locations from which to retrieve desired package files. See also
> > apt_preferences(5) for a mechanism for overriding the general settings
> > for individual packages.
> >
> > JAP
> >
> >
>
>
> --
> Cuando hables, procura que tus palabras sean mejores que tu silencio.
>
>

Re: Paquetes retenidos y aplicaciones rotas tras actualizar a Debian 9

[hector rodriguez]

El 26/6/17, JAP  escribió:
> El 26/06/17 a las 05:57, Iván Hernández Cazorla escribió:
>> Buenas,
>> Creo que no es la primera vez que me suscribo a esta lista de correo,
>> pero nunca está de más agradecer a todos aquellos que atienden los
>> correos de antemano. Gracias. Bueno, les comento mi problema.
>>
>> Últimamente ando un poco desactualizado de las novedades de todo,
>> inclusive de Debian. Fue ayer cuando me enteré de que el 17 de junio de
>> 2017 se lanzó Debian 9 Stretch
>> <https://www.debian.org/News/2017/20170617>. Con la emoción fui un poco
>> a la desesperada y busqué rápidamente "how to upgrade debian 8 to 9" y
>> me encontré con este tutorial
>> <https://www.linuxbabe.com/debian/upgrade-debian-8-jessie-to-debian-9-stretch>.
>>
>> Lo seguí al pie de la letra. Pero, cuando el ordenador se reinició tras
>> ejecutar *shutdown -r now*, comprobé que algo no había ido bien por dos
>> razones:
>>
>>  1. Al ejecutar *lsb_release -a *me mostraba (y sigue mostrando este
>> mensaje):
>> No LSB modules are available.
>> Distributor ID:Debian
>> Description:Debian GNU/Linux 9.0 (n/a)
>> Release:9.0
>> Codename:n/a
>> Donde debería indicar el codename "Stretch", no indica nada, solo
>> n/a.
>>  2. Hay programas que se han roto. Por ej. el navegador de archivos
>> "nemo" y VLC.
>>
>> Como no atinaba con que podía ser la razón de este fallo, ejecuté un
>> *apt-get update *y luego un *upgrade* para comprobar que todos los
>> paquetes se habían actualizado. Sin embargo, para mi sorpresa, a estas
>> horas de la mañana que he vuelto a intentarlo, me dice que:
>>
>> 1 actualizados, 0 nuevos se instalarán, 0 para eliminar y 748 no
>> actualizados.
>>
>> Al revisar los 748 paquetes no actualizados por encima, me encuentro con
>> la sorpresa de que VLC y sus dependencias, de la misma manera que muchos
>> otros, no se han actualizado, razón por la que creo que en estos
>> momentos no funciona.
>>
>> Quitando esto, creo además que el comportamiento del cargador ha
>> comenzado a hacer cosas extrañas, pero esto ya es otra cuestión que iré
>> analizando con el tiempo de uso de Stretch.
>>
>> Les adjunto una imagen con la información del sistema por si fuese de
>> alguna utilidad.
>>
>> Muchas gracias de antemano.
>>
>> Saludos, Iván
>
>
> El cambio de nombre en cada equipo, siempre es algo que a veces, tarda.
> Por ejemplo, yo estoy en "testing", y aún sigue como Debian 9 Stretch.
>
> Recomendación: luego de
>
> # apt-get upgrade
>
> haz un
>
> # apt-get dist-upgrade
>
> Probablemente tengas paquetes que se estén reteniendo.
>
> Esto va a hacer una actualización más completa y va a solucionar cosas
> que una actualización normal no hace, por tema de seguridad del sistema.
>
> dist-upgrade in addition to performing the function of upgrade, also
> intelligently handles changing dependencies with new versions of
> packages; apt-get has a "smart" conflict resolution system, and it will
> attempt to upgrade the most important packages at the expense of less
> important ones if necessary. The dist-upgrade command may therefore
> remove some packages. The /etc/apt/sources.list file contains a list of
> locations from which to retrieve desired package files. See also
> apt_preferences(5) for a mechanism for overriding the general settings
> for individual packages.
>
> JAP
>
>


-- 
Cuando hables, procura que tus palabras sean mejores que tu silencio.

Re: Paquetes retenidos y aplicaciones rotas tras actualizar a Debian 9

[JAP]

El 26/06/17 a las 05:57, Iván Hernández Cazorla escribió:

Buenas,
Creo que no es la primera vez que me suscribo a esta lista de correo,
pero nunca está de más agradecer a todos aquellos que atienden los
correos de antemano. Gracias. Bueno, les comento mi problema.

Últimamente ando un poco desactualizado de las novedades de todo,
inclusive de Debian. Fue ayer cuando me enteré de que el 17 de junio de
2017 se lanzó Debian 9 Stretch
<https://www.debian.org/News/2017/20170617>. Con la emoción fui un poco
a la desesperada y busqué rápidamente "how to upgrade debian 8 to 9" y
me encontré con este tutorial
<https://www.linuxbabe.com/debian/upgrade-debian-8-jessie-to-debian-9-stretch>.

Lo seguí al pie de la letra. Pero, cuando el ordenador se reinició tras
ejecutar *shutdown -r now*, comprobé que algo no había ido bien por dos
razones:

 1. Al ejecutar *lsb_release -a *me mostraba (y sigue mostrando este
mensaje):
No LSB modules are available.
Distributor ID:Debian
Description:Debian GNU/Linux 9.0 (n/a)
Release:9.0
Codename:n/a
Donde debería indicar el codename "Stretch", no indica nada, solo n/a.
 2. Hay programas que se han roto. Por ej. el navegador de archivos
"nemo" y VLC.

Como no atinaba con que podía ser la razón de este fallo, ejecuté un
*apt-get update *y luego un *upgrade* para comprobar que todos los
paquetes se habían actualizado. Sin embargo, para mi sorpresa, a estas
horas de la mañana que he vuelto a intentarlo, me dice que:

1 actualizados, 0 nuevos se instalarán, 0 para eliminar y 748 no
actualizados.

Al revisar los 748 paquetes no actualizados por encima, me encuentro con
la sorpresa de que VLC y sus dependencias, de la misma manera que muchos
otros, no se han actualizado, razón por la que creo que en estos
momentos no funciona.

Quitando esto, creo además que el comportamiento del cargador ha
comenzado a hacer cosas extrañas, pero esto ya es otra cuestión que iré
analizando con el tiempo de uso de Stretch.

Les adjunto una imagen con la información del sistema por si fuese de
alguna utilidad.

Muchas gracias de antemano.

Saludos, Iván



El cambio de nombre en cada equipo, siempre es algo que a veces, tarda.
Por ejemplo, yo estoy en "testing", y aún sigue como Debian 9 Stretch.

Recomendación: luego de

# apt-get upgrade

haz un

# apt-get dist-upgrade

Probablemente tengas paquetes que se estén reteniendo.

Esto va a hacer una actualización más completa y va a solucionar cosas 
que una actualización normal no hace, por tema de seguridad del sistema.


dist-upgrade in addition to performing the function of upgrade, also 
intelligently handles changing dependencies with new versions of 
packages; apt-get has a "smart" conflict resolution system, and it will 
attempt to upgrade the most important packages at the expense of less 
important ones if necessary. The dist-upgrade command may therefore 
remove some packages. The /etc/apt/sources.list file contains a list of 
locations from which to retrieve desired package files. See also 
apt_preferences(5) for a mechanism for overriding the general settings 
for individual packages.


JAP

Paquetes retenidos y aplicaciones rotas tras actualizar a Debian 9

[Iván Hernández Cazorla]

Buenas,
Creo que no es la primera vez que me suscribo a esta lista de correo, pero
nunca está de más agradecer a todos aquellos que atienden los correos de
antemano. Gracias. Bueno, les comento mi problema.

Últimamente ando un poco desactualizado de las novedades de todo, inclusive
de Debian. Fue ayer cuando me enteré de que el 17 de junio de 2017 se lanzó
Debian 9 Stretch <https://www.debian.org/News/2017/20170617>. Con la
emoción fui un poco a la desesperada y busqué rápidamente "how to upgrade
debian 8 to 9" y me encontré con este tutorial
<https://www.linuxbabe.com/debian/upgrade-debian-8-jessie-to-debian-9-stretch>
.

Lo seguí al pie de la letra. Pero, cuando el ordenador se reinició tras
ejecutar *shutdown -r now*, comprobé que algo no había ido bien por dos
razones:

   1. Al ejecutar *lsb_release -a *me mostraba (y sigue mostrando este
   mensaje):
   No LSB modules are available.
   Distributor ID:Debian
   Description:Debian GNU/Linux 9.0 (n/a)
   Release:9.0
   Codename:n/a
   Donde debería indicar el codename "Stretch", no indica nada, solo n/a.
   2. Hay programas que se han roto. Por ej. el navegador de archivos
   "nemo" y VLC.

Como no atinaba con que podía ser la razón de este fallo, ejecuté un *apt-get
update *y luego un *upgrade* para comprobar que todos los paquetes se
habían actualizado. Sin embargo, para mi sorpresa, a estas horas de la
mañana que he vuelto a intentarlo, me dice que:

> 1 actualizados, 0 nuevos se instalarán, 0 para eliminar y 748 no
> actualizados.
>
Al revisar los 748 paquetes no actualizados por encima, me encuentro con la
sorpresa de que VLC y sus dependencias, de la misma manera que muchos
otros, no se han actualizado, razón por la que creo que en estos momentos
no funciona.

Quitando esto, creo además que el comportamiento del cargador ha comenzado
a hacer cosas extrañas, pero esto ya es otra cuestión que iré analizando
con el tiempo de uso de Stretch.

Les adjunto una imagen con la información del sistema por si fuese de
alguna utilidad.

Muchas gracias de antemano.

Saludos, Iván