Re: bitz-server: package is not in any development repository ...

2021-05-17 Thread Andrei POPESCU
On Lu, 17 mai 21, 23:30:33, Albretch Mueller wrote:
>  https://tracker.debian.org/pkg/bitz-server
> 
>  bitz-server: ICAP server (RFC 3507) implementation in C++
> 
>  package is gone: This package is not in any development repository.
> This probably means that the package has been removed (or has been
> renamed). Thus the information here is of little interest ... the
> package is going to disappear unless someone takes it over and
> reintroduces it.
> ~
>  It is not totally clear to me is this package is being actively
> maintained or not, since it is part of buster:
> 
>  https://packages.debian.org/source/stable/bitz-server

https://tracker.debian.org/pkg/bitz-server

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: bitz-server: package is not in any development repository ...

2021-05-17 Thread Albretch Mueller
 ... and my main interest would be then connecting it to java using
the JNI in order to do the deep content inspection and dynamic
customization from events happening in java programs.

 If I were to collaborate with the maintainers of this package, which
"prior art": blogs, books, ... would you recommend?

 If possible, in order to save/not waste time from other projects, I
need a thoroughgoing step-by-step guideline.

 lbrtchx



bitz-server: package is not in any development repository ...

2021-05-17 Thread Albretch Mueller
 https://tracker.debian.org/pkg/bitz-server

 bitz-server: ICAP server (RFC 3507) implementation in C++

 package is gone: This package is not in any development repository.
This probably means that the package has been removed (or has been
renamed). Thus the information here is of little interest ... the
package is going to disappear unless someone takes it over and
reintroduces it.
~
 It is not totally clear to me is this package is being actively
maintained or not, since it is part of buster:

 https://packages.debian.org/source/stable/bitz-server

 lbrtchx



Re: Has anybody [had] good/bad experiences with the Bose QuietComfort 35 II and Debian ?

2021-05-17 Thread F. Eugene Aumson
They work fine for me.  Debian Buster.

On Sun, May 16, 2021 at 8:16 AM Ottavio Caruso <
ottavio2006-usenet2...@yahoo.com> wrote:

> I recently bought some middle of the range wireless noise cancelling
> headphones, which I eventually had to return because they would randomly
> switch back and forth from A2DP to HSP/HFP profile. The manufacturer
> (Jabra) refused to troubleshoot the issue because (paraphrasing) that
> particular line of headphones was meant for smartphones only. I have
> contacted Bose and they replied that they " should work " with a Linux
> laptop.
>
> I am also aware that there are bug reports still open with Pulseaudio
> and profile mismatch with wireless headphones.
>
> Before investing almost £200, I wonder if I can have any feedback on
> this model. I am using Debian Buster.
>
> --
> Ottavio Caruso
>
>
>


Re: help ask microsoft to make eloquance tts open source.

2021-05-17 Thread deloptes
deloptes wrote:

> It resonates a lot - as I wrote thesis on dialogue systems and I got very
> disappointed by the facts I came across. IMO all technologies that were
> financed with public money (i.e. DARPA) should be made publicly available.
> In fact AFAIK there is only one engine (the mother of all) that was
> developed by Phillips and IBM - who knows who owns the pattents now ... I
> would be surprised if Google, Microsoft and Amazon funded research
> themselves.
> 
> In fact there was a Linux version of IBMs ViaVoice but was so bad and was
> killed later around 2005. We are in THE MIDDLE AGES right now. Only people
> got too stupid to understand.
> 
> I will no subscribed because it does not make any sense to request
> something from 2002 - you/we should request everything that was publicly
> funded to be available/benefitting the public or revolt.

I am sorry I was speaking about STT which is much more complicated. The TTS
(festival) has its roots also in publicly funded projects and programs and
had the same faith as the STTs. It is a shame what happened.




Re: help ask microsoft to make eloquance tts open source.

2021-05-17 Thread deloptes
Karen Lewellen wrote:

> Hi everyone,
> Sharing because while tts is indeed  part of adaptive technology for many,
> and Linux default speech synthesis is not always of the best quality, the
> use of tts across devices serving the general public is  becoming more
> extensive as well.
> There is an effort at change.org asking Microsoft to makes its tts engine
> eloquence, open source.
> 
> https://www.change.org/p/microsoft-open-source-eti-eloquence
> 
> 
> If this resonates, please sign and circulate. its one of those  situations
> where adaptive technology and general technology can intersect in a
> positive way.

It resonates a lot - as I wrote thesis on dialogue systems and I got very
disappointed by the facts I came across. IMO all technologies that were
financed with public money (i.e. DARPA) should be made publicly available.
In fact AFAIK there is only one engine (the mother of all) that was
developed by Phillips and IBM - who knows who owns the pattents now ... I
would be surprised if Google, Microsoft and Amazon funded research
themselves.

In fact there was a Linux version of IBMs ViaVoice but was so bad and was
killed later around 2005. We are in THE MIDDLE AGES right now. Only people
got too stupid to understand.

I will no subscribed because it does not make any sense to request something
from 2002 - you/we should request everything that was publicly funded to be
available/benefitting the public or revolt.





Re: How to capture composite video

2021-05-17 Thread Charlie Gibbs

On Mon May 17 10:56:10 2021 Dan Ritter  wrote:

> The subsystem you are looking for is V4L2, Video For Linux 2.
>
> Showing up as /dev/video0 is an extremely positive sign.
>
> https://www.linuxtv.org/wiki/index.php/V4L_capturing is what you
> want to read.

This looks like a possibility - v4l2-ctl identifies the tuner,
composite, and S-Video inputs on my card.  So far, though,
mpv just shows noise.  I'll continue puttering...

--
cgi...@surfnaked.ca (Charlie Gibbs)



help ask microsoft to make eloquance tts open source.

2021-05-17 Thread Karen Lewellen

Hi everyone,
Sharing because while tts is indeed  part of adaptive technology for many, 
and Linux default speech synthesis is not always of the best quality, the 
use of tts across devices serving the general public is  becoming more 
extensive as well.
There is an effort at change.org asking Microsoft to makes its tts engine 
eloquence, open source.


https://www.change.org/p/microsoft-open-source-eti-eloquence


If this resonates, please sign and circulate. its one of those  situations 
where adaptive technology and general technology can intersect in a 
positive way.

Link is not the best in lower graphics  but hopefully others can sign.
Thanks,
Karen





Re: ssh no conecta (Bullseye en ambos equipos) *** SOLUCIONADO *** era por el ufw

2021-05-17 Thread Walter Omar Dari
Hola gente, quedó SOLUCIONADO, era el ufw, no tenía idea que estaba 
instalado en ese equipo. Pero lo cierto es que comenzó a actuar a partir 
de la actualización a bullseye, con buster no bloqueaba nada. Es muy raro.


Gracias a OddieX por la ayuda y a todos los que respondieron, aprendí 
unas cuantas cosas para chequear que nunca había tenido que usar.


La solución: descubrí que había una interfaz gráfica para el ufw en el 
equipo en cuestión, ni bien la abrí vi que estaba todo denegado, así que 
cambié las opciones y ahora puedo ingresar.


La verdad que no recuerdo haber instalado ese firewall ni haberlo 
configurado nunca. Espero que no sean los años... ;-)


https://help.ubuntu.com/community/UFW

Saludos a todos y gracias nuevamente.



El 17/5/21 a las 15:16, OddieX escribió:

El lun, 17 may 2021 a las 15:04, Walter Omar Dari
() escribió:


Hola...

El 17/5/21 a las 12:51, OddieX escribió:



El lun., 17 de mayo de 2021 12:48, Walter Omar Dari mailto:wlin...@gmail.com>> escribió:

 Hola, lo que me faltaba probar...

 El 16/5/21 a las 03:52, Camaleón escribió:
  > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
  >
  > [...]
  >
  >
  > Si tienes otro equipo desde donde probar (p. j., otro sistema
 operativo
  > como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
  > guerra te la esté dando el cliente desde donde conectas.

 Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
 problemas.


  >
  > Saludos,
  >

 --




 Fijate en login.Defs q no encuentra iptables pq desde buster en
 adelante cambiaron los env path... Sino whereis iptables y ejecutalo
 con path completo...



Funcionó indicando la ruta completa, aquí va la salida, yo no veo
inconvenientes, pero no estoy muy ducho con estos (disculpas porque es
bastante larga)...


Chain INPUT (policy DROP)
target prot opt source   destination
ufw-before-logging-input  all  --  anywhere anywhere
ufw-before-input  all  --  anywhere anywhere
ufw-after-input  all  --  anywhere anywhere
ufw-after-logging-input  all  --  anywhere anywhere
ufw-reject-input  all  --  anywhere anywhere
ufw-track-input  all  --  anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source   destination
ufw-before-logging-forward  all  --  anywhere anywhere

ufw-before-forward  all  --  anywhere anywhere
ufw-after-forward  all  --  anywhere anywhere
ufw-after-logging-forward  all  --  anywhere anywhere

ufw-reject-forward  all  --  anywhere anywhere
ufw-track-forward  all  --  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ufw-before-logging-output  all  --  anywhere anywhere

ufw-before-output  all  --  anywhere anywhere
ufw-after-output  all  --  anywhere anywhere
ufw-after-logging-output  all  --  anywhere anywhere
ufw-reject-output  all  --  anywhere anywhere
ufw-track-output  all  --  anywhere anywhere

Chain ufw-after-forward (1 references)
target prot opt source   destination

Chain ufw-after-input (1 references)
target prot opt source   destination
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:netbios-ns
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:netbios-dgm
ufw-skip-to-policy-input  tcp  --  anywhere anywhere
   tcp dpt:netbios-ssn
ufw-skip-to-policy-input  tcp  --  anywhere anywhere
   tcp dpt:microsoft-ds
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:bootps
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:bootpc
ufw-skip-to-policy-input  all  --  anywhere anywhere
   ADDRTYPE match dst-type BROADCAST

Chain ufw-after-logging-forward (1 references)
target prot opt source   destination
LOGall  --  anywhere anywhere limit: avg
3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

Chain ufw-after-logging-input (1 references)
target prot opt source   destination

Chain ufw-after-logging-output (1 references)
target prot opt source   destination

Chain ufw-after-output (1 references)
target prot opt source   destination

Chain ufw-before-forward (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere ctstate
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere icmp
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp
time-exceeded
ACCEPT icmp --  anywhere anywhere 

Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread Brian
On Mon 17 May 2021 at 14:39:47 -0400, Greg Wooledge wrote:

> On Mon, May 17, 2021 at 07:25:38PM +0100, Brian wrote:
> > On Mon 17 May 2021 at 11:01:33 -0400, Greg Wooledge wrote:
> > 
> > [...]
> > 
> > > Done!  Now, let's try that with pinfo date.  I ran pinfo date from my
> > > shell, which took me to one of the pages within the tree of coreutils
> > > texinfo documentation corresponding to the date program.  This particular
> > > page is titled "21.1 ‘date’: Print or set system date and time".
> > > 
> > > I pressed /, typed %F, pressed Enter, and I got:
> > > 
> > > "Search string not found..."
> > > 
> > > That's because pinfo doesn't search beyond the current page, and the
> > > current page is just a menu of links to other pages.
> > 
> > As a longtime user of pinfo I appreciate your exposing it to a wider
> > audience.
> > 
> > Regarding seaching: does the s key do anything to cause you to modify
> > your observation?
> 
> Huh... that's interesting.  OK, these key bindings are *really* not ideal,
> and I think I found some kind of bug.

Ideal or not, I hope you are acknowledging that pinfo can search beyond
the current page.

Press s, type %F, press Enter; I got a description of the option at the
top of the page.

-- 
Brian.



Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Thread Walter Omar Dari




El 17/5/21 a las 15:16, OddieX escribió:

El lun, 17 may 2021 a las 15:04, Walter Omar Dari
() escribió:


Hola...

El 17/5/21 a las 12:51, OddieX escribió:



El lun., 17 de mayo de 2021 12:48, Walter Omar Dari mailto:wlin...@gmail.com>> escribió:

 Hola, lo que me faltaba probar...

 El 16/5/21 a las 03:52, Camaleón escribió:
  > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
  >
  > [...]
  >
  >
  > Si tienes otro equipo desde donde probar (p. j., otro sistema
 operativo
  > como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
  > guerra te la esté dando el cliente desde donde conectas.

 Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
 problemas.


  >
  > Saludos,
  >

 --




 Fijate en login.Defs q no encuentra iptables pq desde buster en
 adelante cambiaron los env path... Sino whereis iptables y ejecutalo
 con path completo...



Funcionó indicando la ruta completa, aquí va la salida, yo no veo
inconvenientes, pero no estoy muy ducho con estos (disculpas porque es
bastante larga)...


Chain INPUT (policy DROP)
target prot opt source   destination
ufw-before-logging-input  all  --  anywhere anywhere
ufw-before-input  all  --  anywhere anywhere
ufw-after-input  all  --  anywhere anywhere
ufw-after-logging-input  all  --  anywhere anywhere
ufw-reject-input  all  --  anywhere anywhere
ufw-track-input  all  --  anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source   destination
ufw-before-logging-forward  all  --  anywhere anywhere

ufw-before-forward  all  --  anywhere anywhere
ufw-after-forward  all  --  anywhere anywhere
ufw-after-logging-forward  all  --  anywhere anywhere

ufw-reject-forward  all  --  anywhere anywhere
ufw-track-forward  all  --  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ufw-before-logging-output  all  --  anywhere anywhere

ufw-before-output  all  --  anywhere anywhere
ufw-after-output  all  --  anywhere anywhere
ufw-after-logging-output  all  --  anywhere anywhere
ufw-reject-output  all  --  anywhere anywhere
ufw-track-output  all  --  anywhere anywhere

Chain ufw-after-forward (1 references)
target prot opt source   destination

Chain ufw-after-input (1 references)
target prot opt source   destination
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:netbios-ns
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:netbios-dgm
ufw-skip-to-policy-input  tcp  --  anywhere anywhere
   tcp dpt:netbios-ssn
ufw-skip-to-policy-input  tcp  --  anywhere anywhere
   tcp dpt:microsoft-ds
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:bootps
ufw-skip-to-policy-input  udp  --  anywhere anywhere
   udp dpt:bootpc
ufw-skip-to-policy-input  all  --  anywhere anywhere
   ADDRTYPE match dst-type BROADCAST

Chain ufw-after-logging-forward (1 references)
target prot opt source   destination
LOGall  --  anywhere anywhere limit: avg
3/min burst 10 LOG level warning prefix "[UFW BLOCK] "

Chain ufw-after-logging-input (1 references)
target prot opt source   destination

Chain ufw-after-logging-output (1 references)
target prot opt source   destination

Chain ufw-after-output (1 references)
target prot opt source   destination

Chain ufw-before-forward (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere ctstate
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere icmp
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp
time-exceeded
ACCEPT icmp --  anywhere anywhere icmp
parameter-problem
ACCEPT icmp --  anywhere anywhere icmp
echo-request
ufw-user-forward  all  --  anywhere anywhere

Chain ufw-before-input (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere ctstate
RELATED,ESTABLISHED
ufw-logging-deny  all  --  anywhere anywhere
ctstate INVALID
DROP   all  --  anywhere anywhere ctstate
INVALID
ACCEPT icmp --  anywhere anywhere icmp
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp
time-exceeded
ACCEPT icmp --  anywhere  

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Thread Walter Omar Dari

Hola...

El 17/5/21 a las 15:15, Ramses escribió:

El 17 de mayo de 2021 19:49:11 CEST, Walter Omar Dari  
escribió:



El 17/5/21 a las 13:12, Camaleón escribió:

El 2021-05-17 a las 12:37 -0300, Walter Omar Dari escribió:


El 16/5/21 a las 03:52, Camaleón escribió:

debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.

... después de un rato da un error de timeout.


Un error de timeout apunta a que el anfitrión (el equipo al que
conectas) corta la conexión por algún motivo (directiva de

seguridad,

etc.); si llegas con un ping al equipo, así a bote pronto el

cortafuegos

quedaría descartado.


El ping me responde inmediatamente...

$ ping 192.168.0.8
PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
^C


Hum... prueba con una traza, aunque me temo que no proporcionará

mucha más

información:

traceroute -T -O info -p 22 192.168.0.8


Te detallo algunas otras cosas que hice (sugerencias de Zeque), al

final

está la traza...

/home/sw/Uso_compartido/temp/ssh_noconecta2.txt   [BM--]  9 L:[

1+26 27/

56] *(775 /1070b) 0010 0x00A [*][X]
1)  en el equipo que no permite las conexiones (192.168.0.8)...

root@debbns:~# iptables -L
bash: iptables: orden no encontrada

root@debbns:~# dpkg -l | grep iptables
ii  iptables1.8.7-1  amd64administration tools for

packet

filtering and NAT


?

Prueba con:
#su - -c "iptables -L"


hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas

al

principio), no hay direcciones IP ni nombres de hosts.

Probé agregando la línea...

ALL : ALL : allow

... en hosts.allow, pero tampoco da resultados.


2) en cualquier equipo que se quiera conectar a 192.168.0.8...

dari@debwal:~$ nc -vvv 192.168.0.8 22
^C sent 0, rcvd 0

root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte

packets

   1  * * *
   2  * * *


(...)

No llega.


Si la conexión fuera entre redes distintas (remotas), pasando el
tráfico por distintos servidores y enrutadores que no están bajo tu
supervisión, podría entenderse el timeout por algún filtro de los

ISP,

el tamaño de los paquetes o cortafuegos, pero teniendo controlado

el

entorno de conexión (red local) el tiemout es todo un misterio :-?

Si tienes otro equipo desde donde probar (p. j., otro sistema

operativo

como Windows con Putty o MacOS), intenta a ver, no vaya a ser que

la

guerra te la esté dando el cliente desde donde conectas.


He probado desde otros equipos con Debian y el resultado es el

mismo.

El tema tiene que estar en el huraño 192.168.0.8 :-)

A ese equipo lo actualicé, no fue una instalación desde cero,

anteriormente

tenía Buster, así que le modifiqué el sources.list reemplazando

buster por

bullseye. La actualización no dio problemas.

Voy a ver si encuentro alguna portátil a la que le haya quedado un

dual boot

con Windows para probar con Putty

Gracias !


Sólo por curiosidad... ¿has probado a intentar conectarte a otro
servicio/puerto que no sea SSH? P. ej., servidor de correo sin

cifrado

(110/25) o cualquier otro que puedas tener configurado en ese equipo.

Lo digo para descartar un problema localizado en ese servicio/
aplicativo/puerto o para confirmar que se trata de un problema
generalizado que afecta a otra combinación de servicios y puertos.



Acabo de instalarle Apache y no responde, solamente funciona de modo
local.

Lo raro que responde al ping...




Saludos,



¿No tendrás duplicada la IP en la red y te está respondiendo otro equipo?

Un tcpdump a ver si está respondiendo ese equipo al Ping y miras si te llega 
tráfico cuando le tiras el SSH desde otro equipo.


No, no está duplicada, ya está comprobado. Gracias !





Saludos

.



--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)



Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread Greg Wooledge
On Mon, May 17, 2021 at 07:25:38PM +0100, Brian wrote:
> On Mon 17 May 2021 at 11:01:33 -0400, Greg Wooledge wrote:
> 
> [...]
> 
> > Done!  Now, let's try that with pinfo date.  I ran pinfo date from my
> > shell, which took me to one of the pages within the tree of coreutils
> > texinfo documentation corresponding to the date program.  This particular
> > page is titled "21.1 ‘date’: Print or set system date and time".
> > 
> > I pressed /, typed %F, pressed Enter, and I got:
> > 
> > "Search string not found..."
> > 
> > That's because pinfo doesn't search beyond the current page, and the
> > current page is just a menu of links to other pages.
> 
> As a longtime user of pinfo I appreciate your exposing it to a wider
> audience.
> 
> Regarding seaching: does the s key do anything to cause you to modify
> your observation?

Huh... that's interesting.  OK, these key bindings are *really* not ideal,
and I think I found some kind of bug.

According to the man page, there's no default key binding for "search again"
(KEY_SEARCH_AGAIN_1), but in Debian's /etc/pinforc, it's bound to 'f'.

OK, armed with that knowledge, I did "pinfo date", then "s" and "%F" to
search for the same word as before.  Then I pressed "f" which advanced me
to the next instance.  Then "f" a second time, and it says:

Tag table is corrupt, trying to fix... (press a key to continue)

Pressing space takes me back to the main page of coreutils.info.

I'm just gonna go ahead and report the bug.

And thanks for the tip.



Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread Brian
On Mon 17 May 2021 at 11:01:33 -0400, Greg Wooledge wrote:

[...]

> Done!  Now, let's try that with pinfo date.  I ran pinfo date from my
> shell, which took me to one of the pages within the tree of coreutils
> texinfo documentation corresponding to the date program.  This particular
> page is titled "21.1 ‘date’: Print or set system date and time".
> 
> I pressed /, typed %F, pressed Enter, and I got:
> 
> "Search string not found..."
> 
> That's because pinfo doesn't search beyond the current page, and the
> current page is just a menu of links to other pages.

As a longtime user of pinfo I appreciate your exposing it to a wider
audience.

Regarding seaching: does the s key do anything to cause you to modify
your observation?

-- 
Brian.



Re: How to capture composite video

2021-05-17 Thread deloptes
Dan Ritter wrote:

> The subsystem you are looking for is V4L2, Video For Linux 2.
> 
> Showing up as /dev/video0 is an extremely positive sign.
> 
> https://www.linuxtv.org/wiki/index.php/V4L_capturing is what you
> want to read.
> 

mencoder will give you different flavors and you could cook the soup that
tastes the best to you.
For example the Hauppauge card would provide a specific max quality of
output (the analog to digital converter). Thus here people suggest other
hardware. It could be the hauppauge is very low quality.

for example when analog TV was still popular I used with gl2 video out
driver following. Similar with mencoder except that it goes into a file

mplayer -tv
driver=v4l2:outfmt=yuy2:width=640:height=480:device=/dev/video0:input=0:forceaudio:immediatemode=0:adevice=/dev/dsp1:amode=1:forcechan=2:audiorate=44100:audioid=1:volume=75:norm=0:normid=0:chanlist=europe-west
 -vo
gl2 -ao alsa:noblock:audiorate=48000:device=duplex tv://





Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Thread OddieX
El lun, 17 may 2021 a las 15:04, Walter Omar Dari
() escribió:
>
> Hola...
>
> El 17/5/21 a las 12:51, OddieX escribió:
> >
> >
> > El lun., 17 de mayo de 2021 12:48, Walter Omar Dari  > > escribió:
> >
> > Hola, lo que me faltaba probar...
> >
> > El 16/5/21 a las 03:52, Camaleón escribió:
> >  > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
> >  >
> >  > [...]
> >  >
> >  >
> >  > Si tienes otro equipo desde donde probar (p. j., otro sistema
> > operativo
> >  > como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
> >  > guerra te la esté dando el cliente desde donde conectas.
> >
> > Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
> > problemas.
> >
> >
> >  >
> >  > Saludos,
> >  >
> >
> > --
> >
> >
> >
> >
> > Fijate en login.Defs q no encuentra iptables pq desde buster en
> > adelante cambiaron los env path... Sino whereis iptables y ejecutalo
> > con path completo...
> >
>
> Funcionó indicando la ruta completa, aquí va la salida, yo no veo
> inconvenientes, pero no estoy muy ducho con estos (disculpas porque es
> bastante larga)...
>
>
> Chain INPUT (policy DROP)
> target prot opt source   destination
> ufw-before-logging-input  all  --  anywhere anywhere
> ufw-before-input  all  --  anywhere anywhere
> ufw-after-input  all  --  anywhere anywhere
> ufw-after-logging-input  all  --  anywhere anywhere
> ufw-reject-input  all  --  anywhere anywhere
> ufw-track-input  all  --  anywhere anywhere
>
> Chain FORWARD (policy DROP)
> target prot opt source   destination
> ufw-before-logging-forward  all  --  anywhere anywhere
>
> ufw-before-forward  all  --  anywhere anywhere
> ufw-after-forward  all  --  anywhere anywhere
> ufw-after-logging-forward  all  --  anywhere anywhere
>
> ufw-reject-forward  all  --  anywhere anywhere
> ufw-track-forward  all  --  anywhere anywhere
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> ufw-before-logging-output  all  --  anywhere anywhere
>
> ufw-before-output  all  --  anywhere anywhere
> ufw-after-output  all  --  anywhere anywhere
> ufw-after-logging-output  all  --  anywhere anywhere
> ufw-reject-output  all  --  anywhere anywhere
> ufw-track-output  all  --  anywhere anywhere
>
> Chain ufw-after-forward (1 references)
> target prot opt source   destination
>
> Chain ufw-after-input (1 references)
> target prot opt source   destination
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:netbios-ns
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:netbios-dgm
> ufw-skip-to-policy-input  tcp  --  anywhere anywhere
>   tcp dpt:netbios-ssn
> ufw-skip-to-policy-input  tcp  --  anywhere anywhere
>   tcp dpt:microsoft-ds
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:bootps
> ufw-skip-to-policy-input  udp  --  anywhere anywhere
>   udp dpt:bootpc
> ufw-skip-to-policy-input  all  --  anywhere anywhere
>   ADDRTYPE match dst-type BROADCAST
>
> Chain ufw-after-logging-forward (1 references)
> target prot opt source   destination
> LOGall  --  anywhere anywhere limit: avg
> 3/min burst 10 LOG level warning prefix "[UFW BLOCK] "
>
> Chain ufw-after-logging-input (1 references)
> target prot opt source   destination
>
> Chain ufw-after-logging-output (1 references)
> target prot opt source   destination
>
> Chain ufw-after-output (1 references)
> target prot opt source   destination
>
> Chain ufw-before-forward (1 references)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywhere ctstate
> RELATED,ESTABLISHED
> ACCEPT icmp --  anywhere anywhere icmp
> destination-unreachable
> ACCEPT icmp --  anywhere anywhere icmp
> time-exceeded
> ACCEPT icmp --  anywhere anywhere icmp
> parameter-problem
> ACCEPT icmp --  anywhere anywhere icmp
> echo-request
> ufw-user-forward  all  --  anywhere anywhere
>
> Chain ufw-before-input (1 references)
> target prot opt source   destination
> ACCEPT all  --  anywhere anywhere
> ACCEPT all  --  anywhere anywhere ctstate
> RELATED,ESTABLISHED
> ufw-logging-deny  all  --  anywhere anywhere
> ctstate INVALID
> DROP   all  --  anywhere anywhere 

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Thread Ramses
El 17 de mayo de 2021 19:49:11 CEST, Walter Omar Dari  
escribió:
>
>
>El 17/5/21 a las 13:12, Camaleón escribió:
>> El 2021-05-17 a las 12:37 -0300, Walter Omar Dari escribió:
>> 
>>> El 16/5/21 a las 03:52, Camaleón escribió:
>>> debug2: ssh_connect_direct
>>> debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.
>>>
>>> ... después de un rato da un error de timeout.
>>
>> Un error de timeout apunta a que el anfitrión (el equipo al que
>> conectas) corta la conexión por algún motivo (directiva de
>seguridad,
>> etc.); si llegas con un ping al equipo, así a bote pronto el
>cortafuegos
>> quedaría descartado.
>
> El ping me responde inmediatamente...
>
> $ ping 192.168.0.8
> PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
> 64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
> 64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
> 64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
> 64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
> ^C

 Hum... prueba con una traza, aunque me temo que no proporcionará
>mucha más
 información:

 traceroute -T -O info -p 22 192.168.0.8
>>>
>>> Te detallo algunas otras cosas que hice (sugerencias de Zeque), al
>final
>>> está la traza...
>>>
>>> /home/sw/Uso_compartido/temp/ssh_noconecta2.txt   [BM--]  9 L:[ 
>1+26 27/
>>> 56] *(775 /1070b) 0010 0x00A [*][X]
>>> 1)  en el equipo que no permite las conexiones (192.168.0.8)...
>>>
>>> root@debbns:~# iptables -L
>>> bash: iptables: orden no encontrada
>>>
>>> root@debbns:~# dpkg -l | grep iptables
>>> ii  iptables1.8.7-1  amd64administration tools for
>packet
>>> filtering and NAT
>> 
>> ?
>> 
>> Prueba con:
>> #su - -c "iptables -L"
>> 
>>> hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas
>al
>>> principio), no hay direcciones IP ni nombres de hosts.
>>>
>>> Probé agregando la línea...
>>>
>>> ALL : ALL : allow
>>>
>>> ... en hosts.allow, pero tampoco da resultados.
>>>
>>>
>>> 2) en cualquier equipo que se quiera conectar a 192.168.0.8...
>>>
>>> dari@debwal:~$ nc -vvv 192.168.0.8 22
>>> ^C sent 0, rcvd 0
>>>
>>> root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
>>> traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte
>packets
>>>   1  * * *
>>>   2  * * *
>> 
>> (...)
>> 
>> No llega.
>> 
 Si la conexión fuera entre redes distintas (remotas), pasando el
 tráfico por distintos servidores y enrutadores que no están bajo tu
 supervisión, podría entenderse el timeout por algún filtro de los
>ISP,
 el tamaño de los paquetes o cortafuegos, pero teniendo controlado
>el
 entorno de conexión (red local) el tiemout es todo un misterio :-?

 Si tienes otro equipo desde donde probar (p. j., otro sistema
>operativo
 como Windows con Putty o MacOS), intenta a ver, no vaya a ser que
>la
 guerra te la esté dando el cliente desde donde conectas.
>>>
>>> He probado desde otros equipos con Debian y el resultado es el
>mismo.
>>> El tema tiene que estar en el huraño 192.168.0.8 :-)
>>>
>>> A ese equipo lo actualicé, no fue una instalación desde cero,
>anteriormente
>>> tenía Buster, así que le modifiqué el sources.list reemplazando
>buster por
>>> bullseye. La actualización no dio problemas.
>>>
>>> Voy a ver si encuentro alguna portátil a la que le haya quedado un
>dual boot
>>> con Windows para probar con Putty
>>>
>>> Gracias !
>> 
>> Sólo por curiosidad... ¿has probado a intentar conectarte a otro
>> servicio/puerto que no sea SSH? P. ej., servidor de correo sin
>cifrado
>> (110/25) o cualquier otro que puedas tener configurado en ese equipo.
>> 
>> Lo digo para descartar un problema localizado en ese servicio/
>> aplicativo/puerto o para confirmar que se trata de un problema
>> generalizado que afecta a otra combinación de servicios y puertos.
>
>
>Acabo de instalarle Apache y no responde, solamente funciona de modo
>local.
>
>Lo raro que responde al ping...
>
>
>> 
>> Saludos,
>> 

¿No tendrás duplicada la IP en la red y te está respondiendo otro equipo?

Un tcpdump a ver si está respondiendo ese equipo al Ping y miras si te llega 
tráfico cuando le tiras el SSH desde otro equipo.


Saludos



Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Thread Walter Omar Dari

Hola...

El 17/5/21 a las 12:51, OddieX escribió:



El lun., 17 de mayo de 2021 12:48, Walter Omar Dari > escribió:


Hola, lo que me faltaba probar...

El 16/5/21 a las 03:52, Camaleón escribió:
 > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
 >
 > [...]
 >
 >
 > Si tienes otro equipo desde donde probar (p. j., otro sistema
operativo
 > como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
 > guerra te la esté dando el cliente desde donde conectas.

Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
problemas.


 >
 > Saludos,
 >

-- 





Fijate en login.Defs q no encuentra iptables pq desde buster en
adelante cambiaron los env path... Sino whereis iptables y ejecutalo
con path completo...



Funcionó indicando la ruta completa, aquí va la salida, yo no veo 
inconvenientes, pero no estoy muy ducho con estos (disculpas porque es 
bastante larga)...



Chain INPUT (policy DROP)
target prot opt source   destination
ufw-before-logging-input  all  --  anywhere anywhere
ufw-before-input  all  --  anywhere anywhere
ufw-after-input  all  --  anywhere anywhere
ufw-after-logging-input  all  --  anywhere anywhere
ufw-reject-input  all  --  anywhere anywhere
ufw-track-input  all  --  anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source   destination
ufw-before-logging-forward  all  --  anywhere anywhere 


ufw-before-forward  all  --  anywhere anywhere
ufw-after-forward  all  --  anywhere anywhere
ufw-after-logging-forward  all  --  anywhere anywhere 


ufw-reject-forward  all  --  anywhere anywhere
ufw-track-forward  all  --  anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ufw-before-logging-output  all  --  anywhere anywhere 


ufw-before-output  all  --  anywhere anywhere
ufw-after-output  all  --  anywhere anywhere
ufw-after-logging-output  all  --  anywhere anywhere
ufw-reject-output  all  --  anywhere anywhere
ufw-track-output  all  --  anywhere anywhere

Chain ufw-after-forward (1 references)
target prot opt source   destination

Chain ufw-after-input (1 references)
target prot opt source   destination
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:netbios-ns
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:netbios-dgm
ufw-skip-to-policy-input  tcp  --  anywhere anywhere 
 tcp dpt:netbios-ssn
ufw-skip-to-policy-input  tcp  --  anywhere anywhere 
 tcp dpt:microsoft-ds
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:bootps
ufw-skip-to-policy-input  udp  --  anywhere anywhere 
 udp dpt:bootpc
ufw-skip-to-policy-input  all  --  anywhere anywhere 
 ADDRTYPE match dst-type BROADCAST


Chain ufw-after-logging-forward (1 references)
target prot opt source   destination
LOGall  --  anywhere anywhere limit: avg 
3/min burst 10 LOG level warning prefix "[UFW BLOCK] "


Chain ufw-after-logging-input (1 references)
target prot opt source   destination

Chain ufw-after-logging-output (1 references)
target prot opt source   destination

Chain ufw-after-output (1 references)
target prot opt source   destination

Chain ufw-before-forward (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED
ACCEPT icmp --  anywhere anywhere icmp 
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp 
time-exceeded
ACCEPT icmp --  anywhere anywhere icmp 
parameter-problem
ACCEPT icmp --  anywhere anywhere icmp 
echo-request

ufw-user-forward  all  --  anywhere anywhere

Chain ufw-before-input (1 references)
target prot opt source   destination
ACCEPT all  --  anywhere anywhere
ACCEPT all  --  anywhere anywhere ctstate 
RELATED,ESTABLISHED
ufw-logging-deny  all  --  anywhere anywhere 
ctstate INVALID
DROP   all  --  anywhere anywhere ctstate 
INVALID
ACCEPT icmp --  anywhere anywhere icmp 
destination-unreachable
ACCEPT icmp --  anywhere anywhere icmp 
time-exceeded
ACCEPT icmp --  anywhere anywhere icmp 
parameter-problem
ACCEPT icmp --  anywhere anywhere 

Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Thread Walter Omar Dari




El 17/5/21 a las 13:12, Camaleón escribió:

El 2021-05-17 a las 12:37 -0300, Walter Omar Dari escribió:


El 16/5/21 a las 03:52, Camaleón escribió:

debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.

... después de un rato da un error de timeout.


Un error de timeout apunta a que el anfitrión (el equipo al que
conectas) corta la conexión por algún motivo (directiva de seguridad,
etc.); si llegas con un ping al equipo, así a bote pronto el cortafuegos
quedaría descartado.


El ping me responde inmediatamente...

$ ping 192.168.0.8
PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
^C


Hum... prueba con una traza, aunque me temo que no proporcionará mucha más
información:

traceroute -T -O info -p 22 192.168.0.8


Te detallo algunas otras cosas que hice (sugerencias de Zeque), al final
está la traza...

/home/sw/Uso_compartido/temp/ssh_noconecta2.txt   [BM--]  9 L:[  1+26 27/
56] *(775 /1070b) 0010 0x00A [*][X]
1)  en el equipo que no permite las conexiones (192.168.0.8)...

root@debbns:~# iptables -L
bash: iptables: orden no encontrada

root@debbns:~# dpkg -l | grep iptables
ii  iptables1.8.7-1  amd64administration tools for packet
filtering and NAT


?

Prueba con:
#su - -c "iptables -L"


hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas al
principio), no hay direcciones IP ni nombres de hosts.

Probé agregando la línea...

ALL : ALL : allow

... en hosts.allow, pero tampoco da resultados.


2) en cualquier equipo que se quiera conectar a 192.168.0.8...

dari@debwal:~$ nc -vvv 192.168.0.8 22
^C sent 0, rcvd 0

root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte packets
  1  * * *
  2  * * *


(...)

No llega.


Si la conexión fuera entre redes distintas (remotas), pasando el
tráfico por distintos servidores y enrutadores que no están bajo tu
supervisión, podría entenderse el timeout por algún filtro de los ISP,
el tamaño de los paquetes o cortafuegos, pero teniendo controlado el
entorno de conexión (red local) el tiemout es todo un misterio :-?

Si tienes otro equipo desde donde probar (p. j., otro sistema operativo
como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
guerra te la esté dando el cliente desde donde conectas.


He probado desde otros equipos con Debian y el resultado es el mismo.
El tema tiene que estar en el huraño 192.168.0.8 :-)

A ese equipo lo actualicé, no fue una instalación desde cero, anteriormente
tenía Buster, así que le modifiqué el sources.list reemplazando buster por
bullseye. La actualización no dio problemas.

Voy a ver si encuentro alguna portátil a la que le haya quedado un dual boot
con Windows para probar con Putty

Gracias !


Sólo por curiosidad... ¿has probado a intentar conectarte a otro
servicio/puerto que no sea SSH? P. ej., servidor de correo sin cifrado
(110/25) o cualquier otro que puedas tener configurado en ese equipo.

Lo digo para descartar un problema localizado en ese servicio/
aplicativo/puerto o para confirmar que se trata de un problema
generalizado que afecta a otra combinación de servicios y puertos.



Acabo de instalarle Apache y no responde, solamente funciona de modo local.

Lo raro que responde al ping...




Saludos,



--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)



Re: How to capture composite video

2021-05-17 Thread Dan Ritter
Charlie Gibbs wrote: 
> I have a number of VHS tapes which I'd like to digitize, and I'm
> trying to figure out where to start, hardware- and software-wise.
> I'm running Debian Buster (10.5), kernel 4.19.0-10-amd64.  I found a
> pcHDTV HD-5500, which I believe is basically a Hauppauge WinTV-PVR-150
> tweaked for Linux, and dropped it into my box, where it is found by
> lspci and shows up as /dev/video0.  The card has an extender cable
> which leads to a bracket with RCA connectors for audio and composite
> video, as well as an S-Video connector.  (For now, at least, I'm not
> interested in the TV tuner on the card.)
> 
> Presumably, with the proper software and configuration settings,
> I should be able to plug a VCR into the RCA connectors and have
> video come up on the computer's screen, and hopefully save it to
> disk in some sort of standard format.
> 
> What's a good starting point to find information on how to do this?

The subsystem you are looking for is V4L2, Video For Linux 2.

Showing up as /dev/video0 is an extremely positive sign.

https://www.linuxtv.org/wiki/index.php/V4L_capturing is what you
want to read.

-dsr-



Re: How to capture composite video

2021-05-17 Thread fxkl47BF
‐‐‐ Original Message ‐‐‐
On Monday, May 17, 2021 11:39 AM, Charlie Gibbs  wrote:

> I have a number of VHS tapes which I'd like to digitize, and I'm
> trying to figure out where to start, hardware- and software-wise.
> I'm running Debian Buster (10.5), kernel 4.19.0-10-amd64. I found a
> pcHDTV HD-5500, which I believe is basically a Hauppauge WinTV-PVR-150
> tweaked for Linux, and dropped it into my box, where it is found by
> lspci and shows up as /dev/video0. The card has an extender cable
> which leads to a bracket with RCA connectors for audio and composite
> video, as well as an S-Video connector. (For now, at least, I'm not
> interested in the TV tuner on the card.)
>
> Presumably, with the proper software and configuration settings,
> I should be able to plug a VCR into the RCA connectors and have
> video come up on the computer's screen, and hopefully save it to
> disk in some sort of standard format.
>
> What's a good starting point to find information on how to do this?

Canopus ADVC-300
i've used this device for many years
i works flawlessly
play the video
push a button on the advc-300
get a perfect digital copy



Re: How to capture composite video

2021-05-17 Thread James H. H. Lampert

On 5/17/21 9:39 AM, Charlie Gibbs wrote:

I have a number of VHS tapes which I'd like to digitize, and I'm
trying to figure out where to start, hardware- and software-wise.


Do you have a DVD-R video recorder? Simplest way I know is to dub the 
VHS to DVD, at which point accessing the video from your computer should 
be absurdly simple.


--
JHHL



How to capture composite video

2021-05-17 Thread Charlie Gibbs

I have a number of VHS tapes which I'd like to digitize, and I'm
trying to figure out where to start, hardware- and software-wise.
I'm running Debian Buster (10.5), kernel 4.19.0-10-amd64.  I found a
pcHDTV HD-5500, which I believe is basically a Hauppauge WinTV-PVR-150
tweaked for Linux, and dropped it into my box, where it is found by
lspci and shows up as /dev/video0.  The card has an extender cable
which leads to a bracket with RCA connectors for audio and composite
video, as well as an S-Video connector.  (For now, at least, I'm not
interested in the TV tuner on the card.)

Presumably, with the proper software and configuration settings,
I should be able to plug a VCR into the RCA connectors and have
video come up on the computer's screen, and hopefully save it to
disk in some sort of standard format.

What's a good starting point to find information on how to do this?

-- --
/~\  Charlie Gibbs  |  They don't understand Microsoft
\ /|  has stolen their car and parked
 X   I'm really at ac.dekanfrus |  a taxi in their driveway.
/ \  if you read it the right way.  |-- Mayayana



Re: Packages with upgradable origin but kept back: Debian testing: guile-2.2-libs

2021-05-17 Thread Charles Curley
On Mon, 17 May 2021 09:36:03 -0500
David Wright  wrote:

> So I'd look for any non-bullseye holdover packages, and
> particlarly any that depend directly or indirectly on
> libgc1c2, probably via guile 2.2.

Interesting, thank you. I ran

apt-cache rdepends guile-2.2-libs /bullseye

on orca (fresh install of Bullseye) and iorich (upgraded from Buster).
The difference is that on iorich, gnucash is in the output.

I have gnucash 1:3.4-1+b10 on iorich, gnucash 1:4.4-1 on orca.

Both versions of gnucash have the same dependency for guile:

...guile-3.0-libs,... guile-3.0 | guile-2.2 | guile-2.0,...


So why did the upgrade not upgrade gnucash? According to
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#upgrading-full,

["apt full-upgrade"] will perform a complete upgrade of the system,
installing the newest available versions of all packages, and
resolving all possible dependency changes between packages in
different releases. If necessary, it will install some new packages
(usually new library versions, or renamed packages), and remove any
conflicting obsoleted packages.

But the man page for apt says:

   upgrade (apt-get(8))
   upgrade is used to install available upgrades of all
   packages currently installed on the system from the sources
   configured via sources.list(5). New packages will be installed
   if required to satisfy dependencies, but existing packages will
   never be removed. *If an upgrade for a package requires the
   removal of an installed package the upgrade for this package
   isn't performed.*

   full-upgrade (apt-get(8))
   full-upgrade performs the function of upgrade but will
   remove currently installed packages if this is needed to upgrade
   the system as a whole.

(*emphasis added*)

With gnucash already installed, if I run "apt install gnucash" I get a
long list of packages to be installed, many of which are not already
installed in one form or another. It also reports:

The following packages will be REMOVED:
  libgc1c2

Indeed, upgrading gnucash solved that question.

So that explains why guile and gnucash weren't upgraded. I wonder how
many other programs weren't upgraded.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/



Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Thread Camaleón
El 2021-05-17 a las 12:37 -0300, Walter Omar Dari escribió:

> El 16/5/21 a las 03:52, Camaleón escribió:
> > > > > debug2: ssh_connect_direct
> > > > > debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.
> > > > > 
> > > > > ... después de un rato da un error de timeout.
> > > > 
> > > > Un error de timeout apunta a que el anfitrión (el equipo al que
> > > > conectas) corta la conexión por algún motivo (directiva de seguridad,
> > > > etc.); si llegas con un ping al equipo, así a bote pronto el cortafuegos
> > > > quedaría descartado.
> > > 
> > > El ping me responde inmediatamente...
> > > 
> > > $ ping 192.168.0.8
> > > PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
> > > 64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
> > > 64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
> > > 64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
> > > 64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
> > > ^C
> > 
> > Hum... prueba con una traza, aunque me temo que no proporcionará mucha más
> > información:
> > 
> > traceroute -T -O info -p 22 192.168.0.8
> 
> Te detallo algunas otras cosas que hice (sugerencias de Zeque), al final
> está la traza...
> 
> /home/sw/Uso_compartido/temp/ssh_noconecta2.txt   [BM--]  9 L:[  1+26 27/
> 56] *(775 /1070b) 0010 0x00A [*][X]
> 1)  en el equipo que no permite las conexiones (192.168.0.8)...
> 
> root@debbns:~# iptables -L
> bash: iptables: orden no encontrada
> 
> root@debbns:~# dpkg -l | grep iptables
> ii  iptables1.8.7-1  amd64administration tools for packet
> filtering and NAT

?

Prueba con:
#su - -c "iptables -L"

> hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas al
> principio), no hay direcciones IP ni nombres de hosts.
> 
> Probé agregando la línea...
> 
> ALL : ALL : allow
> 
> ... en hosts.allow, pero tampoco da resultados.
> 
> 
> 2) en cualquier equipo que se quiera conectar a 192.168.0.8...
> 
> dari@debwal:~$ nc -vvv 192.168.0.8 22
> ^C sent 0, rcvd 0
> 
> root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
> traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte packets
>  1  * * *
>  2  * * *

(...)

No llega.

> > Si la conexión fuera entre redes distintas (remotas), pasando el
> > tráfico por distintos servidores y enrutadores que no están bajo tu
> > supervisión, podría entenderse el timeout por algún filtro de los ISP,
> > el tamaño de los paquetes o cortafuegos, pero teniendo controlado el
> > entorno de conexión (red local) el tiemout es todo un misterio :-?
> > 
> > Si tienes otro equipo desde donde probar (p. j., otro sistema operativo
> > como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
> > guerra te la esté dando el cliente desde donde conectas.
> 
> He probado desde otros equipos con Debian y el resultado es el mismo.
> El tema tiene que estar en el huraño 192.168.0.8 :-)
> 
> A ese equipo lo actualicé, no fue una instalación desde cero, anteriormente
> tenía Buster, así que le modifiqué el sources.list reemplazando buster por
> bullseye. La actualización no dio problemas.
> 
> Voy a ver si encuentro alguna portátil a la que le haya quedado un dual boot
> con Windows para probar con Putty
> 
> Gracias !

Sólo por curiosidad... ¿has probado a intentar conectarte a otro 
servicio/puerto que no sea SSH? P. ej., servidor de correo sin cifrado 
(110/25) o cualquier otro que puedas tener configurado en ese equipo.

Lo digo para descartar un problema localizado en ese servicio/
aplicativo/puerto o para confirmar que se trata de un problema 
generalizado que afecta a otra combinación de servicios y puertos.

Saludos,

-- 
Camaleón 



Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread Thomas Schmitt
Hi,

Greg Wooledge wrote:
> That's in the info(1) tool.  I agree, info has a better search ability
> than pinfo(1).

Oops. I did not make the connection from your final statement to your
mentioning of pinfo. (I could make excuses that you mention "info and pinfo"
on the way to the end. But actually i did not make a connection to that
either.)


> Let's take date as an example, and let's say that we want to know what
> the %F does, because we saw someone use it.
> In the man page, which has everything all together, it's simple:
> unicorn:~$ man date | grep %F
>%F full date; like %+4Y-%m-%d

At least in this case, pinfo might not be a sincere contender. I read that
it aims to be like the web browser "lynx".
info is more rugged in respect to traditional shell use. As you already
demonstrated it would work fine with grep.

Paradoxly, i would blame the highly condensed information in "man date"
on the fact that man pages in many GNU packages are more or less formatted
versions of the program's help text:

  $ date --help | grep %F
%F   full date; same as %Y-%m-%d


> unicorn:~$ info date | less

Don't tell this Richard Stallman. :))


Whatever, neither info document nor man page really serve the needs of users
who want to learn how to use a program. At best they can give an introduction
of concepts and list all invocation details. This serves those who already
have a good idea of what they are looking for. Examples can help.

When i feel clueless then i ask the all-knowing seer g*.com in plain english.
It yields lots of rumors but in most cases it gives me better ideas what to
look for.
(Please don't tell this Richard Stallman either ...)


Have a nice day :)

Thomas



Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Thread OddieX
El lun., 17 de mayo de 2021 12:48, Walter Omar Dari 
escribió:

> Hola, lo que me faltaba probar...
>
> El 16/5/21 a las 03:52, Camaleón escribió:
> > El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:
> >
> > [...]
> >
> >
> > Si tienes otro equipo desde donde probar (p. j., otro sistema operativo
> > como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
> > guerra te la esté dando el cliente desde donde conectas.
>
> Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay
> problemas.
>
>
> >
> > Saludos,
> >
>
> --
>
> Walter O. Dari
>
> http://swcomputacion.com/
> http://swcomputacion.com/sistemas/
> https://facebook.com/swcomputacion/
> https://facebook.com/sistemasSW/
>
> Nuestros horarios:
> L a V 8 a 13 hs.
> S 11 a 14 hs.
>
> WhatsApp:
> 2396 577140 (no se atienden llamadas)
>
>
>
> Fijate en login.Defs q no encuentra iptables pq desde buster en adelante
> cambiaron los env path... Sino whereis iptables y ejecutalo con path
> completo...


Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Thread Walter Omar Dari

Hola, lo que me faltaba probar...

El 16/5/21 a las 03:52, Camaleón escribió:

El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:

[...] 



Si tienes otro equipo desde donde probar (p. j., otro sistema operativo
como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
guerra te la esté dando el cliente desde donde conectas.


Con Putty tampoco se conecta al equipo en cuestión, a los demás no hay 
problemas.





Saludos,



--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)



Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Thread Walter Omar Dari

Hola...

El 16/5/21 a las 03:52, Camaleón escribió:

El 2021-05-15 a las 19:56 -0300, Walter Omar Dari escribió:


Hola Camaleón, cómo va ?...


:-)


El 15/5/21 a las 14:27, Camaleón escribió:

Además d elo que te han comentado, revisa las opciones de configuración
de SSH en el sistema donde has puesto testing, quizá alguna opción te
esté dando guerra.



Los archivos de configuración, los contenidos en /etc/ssh/ son prácticamente
idénticos en los dos equipos, salvo los archivos .key


Ok...


debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.

... después de un rato da un error de timeout.


Un error de timeout apunta a que el anfitrión (el equipo al que
conectas) corta la conexión por algún motivo (directiva de seguridad,
etc.); si llegas con un ping al equipo, así a bote pronto el cortafuegos
quedaría descartado.


El ping me responde inmediatamente...

$ ping 192.168.0.8
PING 192.168.0.8 (192.168.0.8) 56(84) bytes of data.
64 bytes from 192.168.0.8: icmp_seq=1 ttl=64 time=0.344 ms
64 bytes from 192.168.0.8: icmp_seq=2 ttl=64 time=0.330 ms
64 bytes from 192.168.0.8: icmp_seq=3 ttl=64 time=0.338 ms
64 bytes from 192.168.0.8: icmp_seq=4 ttl=64 time=0.331 ms
^C


Hum... prueba con una traza, aunque me temo que no proporcionará mucha más
información:

traceroute -T -O info -p 22 192.168.0.8


Te detallo algunas otras cosas que hice (sugerencias de Zeque), al final 
está la traza...


/home/sw/Uso_compartido/temp/ssh_noconecta2.txt   [BM--]  9 L:[  1+26 
27/ 56] *(775 /1070b) 0010 0x00A 
[*][X]

1)  en el equipo que no permite las conexiones (192.168.0.8)...

root@debbns:~# iptables -L
bash: iptables: orden no encontrada

root@debbns:~# dpkg -l | grep iptables
ii  iptables1.8.7-1  amd64administration tools for 
packet filtering and NAT


hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas al 
principio), no hay direcciones IP ni nombres de hosts.


Probé agregando la línea...

ALL : ALL : allow

... en hosts.allow, pero tampoco da resultados.


2) en cualquier equipo que se quiera conectar a 192.168.0.8...

dari@debwal:~$ nc -vvv 192.168.0.8 22
^C sent 0, rcvd 0

root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
root@debwal:/home/dari#






Prueba a conectarte desde el propio equipo (ssh root@localhost).


Conecta perfectamente


Me desorienta que no me de algún mensaje más, alguna pista en el modo
"verbose"...


Si la conexión fuera entre redes distintas (remotas), pasando el
tráfico por distintos servidores y enrutadores que no están bajo tu
supervisión, podría entenderse el timeout por algún filtro de los ISP,
el tamaño de los paquetes o cortafuegos, pero teniendo controlado el
entorno de conexión (red local) el tiemout es todo un misterio :-?

Si tienes otro equipo desde donde probar (p. j., otro sistema operativo
como Windows con Putty o MacOS), intenta a ver, no vaya a ser que la
guerra te la esté dando el cliente desde donde conectas.


He probado desde otros equipos con Debian y el resultado es el mismo.
El tema tiene que estar en el huraño 192.168.0.8 :-)

A ese equipo lo actualicé, no fue una instalación desde cero, 
anteriormente tenía Buster, así que le modifiqué el sources.list 
reemplazando buster por bullseye. La actualización no dio problemas.


Voy a ver si encuentro alguna portátil a la que le haya quedado un dual 
boot con Windows para probar con Putty


Gracias !




Saludos,



Saludos,

--

Walter O. Dari

http://swcomputacion.com/
http://swcomputacion.com/sistemas/
https://facebook.com/swcomputacion/
https://facebook.com/sistemasSW/

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)



Re: ssh no conecta (Bullseye en ambos equipos)

2021-05-17 Thread Walter Omar Dari

Hola Zeque...

El 15/5/21 a las 20:53, Zeque escribió:

Walter,

Es raro lo del timeout, probaste hacer un telnet al puerto?
nc -v 192.168.0.8 22



Revistaste el archivo hosts.deny hosts.allow que nada haya cambiado?



Chequea también las reglas de firewall
iptables -L


Te dejo los resultados más uno que me sugirió Camaleon


1)  en el equipo que no permite las conexiones (192.168.0.8)...

root@debbns:~# iptables -L
bash: iptables: orden no encontrada

root@debbns:~# dpkg -l | grep iptables
ii  iptables1.8.7-1  amd64administration tools for 
packet filtering and NAT


hosts.allow y hosts.deny  están vacíos (salvo las lìneas comentadas al 
principio), no hay direcciones IP ni nombres de hosts.


Probé agregando la línea...

ALL : ALL : allow

... en hosts.allow, pero tampoco da resultados.


2) en cualquier equipo que se quiera conectar a 192.168.0.8...

dari@debwal:~$ nc -vvv 192.168.0.8 22
^C sent 0, rcvd 0

root@debwal:/home/dari# traceroute -T -O info -p 22 192.168.0.8
traceroute to 192.168.0.8 (192.168.0.8), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
root@debwal:/home/dari#


Saludos,



Saludos!
Zeque

El 15 de mayo de 2021 12:49:37 ART, Walter Omar Dari  
escribió:


Hola gente:

Me quiero conectar a un equipo de la red local que antes tenía Buster y
no había problemas, pero no puedo a partir de que le instalé Bullseye.
No se si será por Bullseye u otro motivo.

Cuando quiero conectar queda así...

dari@debwal:~$ ssh 192.168.0.8 -vvv
OpenSSH_8.4p1 Debian-5, OpenSSL 1.1.1k  25 Mar 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include
/etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.0.8 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
'/home/wodari/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' ->
'/home/wodari/.ssh/known_hosts2'
debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.8 [192.168.0.8] port 22.

... después de un rato da un error de timeout.


En el equipo al que me quiero conectar, el puerto 22 parece estar bien...

# netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address
State   PID/Program name
tcp0  0 127.0.0.1:530.0.0.0:*
LISTEN  652/connmand
tcp0  0 0.0.0.0:22  0.0.0.0:*
LISTEN  586057/sshd: /usr/s
tcp0  0 127.0.0.1:631   0.0.0.0:*
LISTEN  523630/cupsd
tcp0  0 0.0.0.0:44025   0.0.0.0:*
LISTEN  -
tcp0  0 127.0.0.1:250.0.0.0:*
LISTEN  1146/exim4
tcp0  0 0.0.0.0:17500   0.0.0.0:*
LISTEN  581546/dropbox
tcp0  0 127.0.0.1:17600 0.0.0.0:*
LISTEN  581546/dropbox
tcp0  0 127.0.0.1:17603 0.0.0.0:*
LISTEN  581546/dropbox
tcp0  0 0.0.0.0:111 0.0.0.0:*
LISTEN  1/init
tcp6   0  0 :::1716 :::*
LISTEN  580502/kdeconnectd
tcp6   0  0 ::1:53  :::*
LISTEN  652/connmand
tcp6   0  0 :::22   :::*
LISTEN  586057/sshd: /usr/s
tcp6   0  0 ::1:631 :::*
LISTEN  523630/cupsd
tcp6   0  0 :::41785:::*
LISTEN  -
tcp6   0  0 ::1:25  :::*
LISTEN  1146/exim4
tcp6   0  0 :::17500:::*
LISTEN  581546/dropbox
tcp6   0  0 :::111  :::*
LISTEN  1/init

Los archivos de configuración ssh_config y sshd_config están iguales en
los dos equipos, en directorios ssh_config.d y sshd_config.d estàn
vacìos en ambos equipos.

Desde el equipo al cual me quiero comunicar, al mío no tengo problemas,
ssh conecta sin problemas, el tema es cuando es al revés.

Alguien me puede dar alguna pista ?

Muchas gracias,
-- 


Walter O. Dari

http://swcomputacion.com/ 
http://swcomputacion.com/sistemas/ 
https://facebook.com/swcomputacion/

https://facebook.com/sistemasSW/ 

Nuestros horarios:
L a V 8 a 13 hs.
S 11 a 14 hs.

WhatsApp:
2396 577140 (no se atienden llamadas)



--

Walter O. 

Re: Downloading from lists.debian.org/debian-user in mbox format

2021-05-17 Thread davidson

On Mon, 17 May 2021 davidson wrote:
[dd]

It seems to me that this rationale depends on a couple of unstated
premises:

1. If published, each mbox would contain one month's worth of
messages, all of the messages in one file.

2. it is significantly easier for spammers to download a single file
containing one month's worth of debian-user addresses, than it is to
crawl through individual messages (using, presumably, the posted
monthly author-indices).

[dd]


If last month's author-to-subject ratio is representative, then
publishing monthly per-subject mboxes (instead of monthly messages
containing all messages) would invalidate premise 2 (and contradict
premise 1, obviously).


s/invalidate/make irrelevant/



So, can anyone see a reason not to propose publishing monthly
per-subject mboxes?


--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower



Re: Downloading from lists.debian.org/debian-user in mbox format

2021-05-17 Thread davidson

On Mon, 17 May 2021 Richard Owlett wrote:

On 05/17/2021 08:50 AM, Brian wrote:

On Mon 17 May 2021 at 04:58:42 -0500, Richard Owlett wrote:


Some mailing list save posts in mbox format.
Is there any way to download specific threads from
lists.debian.org/debian-user in mbox format?


I've wondered this for a long time.


No.


I suspected that.


https://lists.debian.org/debian-user/2003/02/msg02997.html

Bug #161440.


Thank you for this!



Only ~2 decades old. Wouldn't want to fix things too fast. :{


It is currently tagged wontfix. That means don't hold your breath.

But look at the rationale:

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=161440#49

One reads, "As to the rationale: Making mboxes available facilitates
harvesting of mail addresses even more than the web archives."

It seems to me that this rationale depends on a couple of unstated
premises:

 1. If published, each mbox would contain one month's worth of
 messages, all of the messages in one file.

 2. it is significantly easier for spammers to download a single file
 containing one month's worth of debian-user addresses, than it is to
 crawl through individual messages (using, presumably, the posted
 monthly author-indices).

So why not just publish monthly *per-subject* mboxes?

I see about 180 distinct authors on last month's author index

 https://lists.debian.org/debian-user/2021/04/author.html
 https://lists.debian.org/debian-user/2021/04/author2.html

and about 160 distinct subjects on last month's subject index.

 https://lists.debian.org/debian-user/2021/04/subject.html
 https://lists.debian.org/debian-user/2021/04/subject2.html

If last month's author-to-subject ratio is representative, then
publishing monthly per-subject mboxes (instead of monthly messages
containing all messages) would invalidate premise 2 (and contradict
premise 1, obviously).

So, can anyone see a reason not to propose publishing monthly
per-subject mboxes?


--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower



Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread Greg Wooledge
On Mon, May 17, 2021 at 04:09:37PM +0200, Thomas Schmitt wrote:
> Hi,
> 
> Greg Wooledge wrote:
> > the inability to *search* within the
> > info page to find occurrences of your keyword can be maddening.
> 
> It's not _that_ terrible. Pressing in
>   info dd
> the "/" key, i get a prompt
>   Regexp search []:
> 
> The input "dsync" brings me to the ‘dsync’ explanation.
> Pressing "/" again and then the Enter key, brings me to its line in the
> Concept index. Doing it again brings me back to the first found occurence.

That's in the info(1) tool.  I agree, info has a better search ability
than pinfo(1).  Also, dd isn't the best choice to demonstrate the issue,
because it's basically a single page anyway.

Let's take date as an example, and let's say that we want to know what
the %F does, because we saw someone use it.

In the man page, which has everything all together, it's simple:

unicorn:~$ man date | grep %F
   %F full date; like %+4Y-%m-%d

Done!  Now, let's try that with pinfo date.  I ran pinfo date from my
shell, which took me to one of the pages within the tree of coreutils
texinfo documentation corresponding to the date program.  This particular
page is titled "21.1 ‘date’: Print or set system date and time".

I pressed /, typed %F, pressed Enter, and I got:

"Search string not found..."

That's because pinfo doesn't search beyond the current page, and the
current page is just a menu of links to other pages.

Now, to be fair, it's a different story in info(1).  I installed the
info package, and ran "info date" from my shell, which took me to the
same page (21.1).  I pressed /%FEnter and this time, it jumped me to
the description of %F on a different page (21.1.2).

The only problem is now I'm in the info(1) tool, which sucks. ;-)

Another approach is to attempt the search from the shell:

unicorn:~$ info date | grep %F
‘%F’
‘%F’, ‘%G’, and ‘%Y’ (all without modifiers), and requires a flag to be
  date -d @946684800 +"%F %T %z"

This is working as intended, but the issue is that the info page doesn't
have a concise one-line description of the %F format.  I could use something
like "grep -A10 %F" and hope.

Another workaround that I've found, which doesn't *always* work, but
works a good deal of the time, is:

unicorn:~$ info date | less

This dumps a flattened version of several of the texinfo pages into a
regular pager (less, in this case).  From here, I can use less's search
and navigation features, which are *far* easier for me.  In this particular
example, searching for %F within less takes me directly to the desired
section, and the 5-line description is prominently visible near the top
of the terminal.

Of course, doing this loses the ability to navigate the texinfo page tree
by following hyperlinks, but for quick searches that's a totally reasonable
trade-off.



Re: Packages with upgradable origin but kept back: Debian testing: guile-2.2-libs

2021-05-17 Thread David Wright
On Mon 17 May 2021 at 07:16:21 (-0600), Charles Curley wrote:
> I upgraded a laptop from Buster to Bullseye recently. I had unattended
> upgrades running, and have kept it running since. I have gotten the
> following in the unattended upgrades report since:
> 
> Packages with upgradable origin but kept back:
>  Debian testing:
>   guile-2.2-libs
> 
> root@iorich:/etc/apt# apt list --upgradable -a
> Listing... Done
> guile-2.2-libs/testing 2.2.7+1-5.4 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
> guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to: 
> 2.2.7+1-5.4]
> 
> root@iorich:/etc/apt#

Well, it wouldn't surprise me if you've still got some buster (or
foreign) software that depends on an old version of guile.
For example, I've a program, running on buster, that uses guile 1.8
and python 2.4 (but it does include their support in its tarball).

> Meanwhile, on another AMD64 machine with a fresh installation of
> Bullseye:
> 
> root@orca:~# pre guile
> guile-2.2-libs2.2.7+1-5.4 amd64
> guile-3.0 3.0.5-2 amd64
> guile-3.0-libs3.0.5-2 amd64
> root@orca:~# 
> 
> And on a i686 machine with a fresh installation of Bullseye:
> 
> root@grissom:~# pre guile
> guile-2.2-libs2.2.7+1-5.4 i386
> root@grissom:~# 
> 
> 
> If I try installing guile-3.0 on the first machine, iorich, I get:
> 
> root@iorich:/etc/apt# apt install guile-3.0
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> The following additional packages will be installed:
>   guile-2.2-libs guile-3.0-libs libgc1
> Suggested packages:
>   guile-3.0-doc
> The following packages will be REMOVED:
>   libgc1c2
> The following NEW packages will be installed:
>   guile-3.0 guile-3.0-libs libgc1
> The following packages will be upgraded:
>   guile-2.2-libs
> 1 upgraded, 3 newly installed, 1 to remove and 0 not upgraded.
> Need to get 6,431 kB/11.7 MB of archives.
> After this operation, 53.4 MB of additional disk space will be used.
> Do you want to continue? [Y/n] n
> Abort.
> root@iorich:/etc/apt# 

So I'd look for any non-bullseye holdover packages, and
particlarly any that depend directly or indirectly on
libgc1c2, probably via guile 2.2.

Cheers,
David.



Re: OT: minimum bs for dd?

2021-05-17 Thread Brian
On Mon 17 May 2021 at 08:59:43 +0300, Andrei POPESCU wrote:

[...]

> I'll raise you 'cp':
> 
> cp foo.iso /dev/sdb
> 
> 
> which is both fast and short to type (apparently it's smart about using 
> the correct block size).
> 
> Unfortunately it's missing dd's equivalent of status=progress.

As an aside:

  cat /dev/sdb

was originally recommended in the Installation Guide but was replaced
with

  cp foo.iso /dev/sdb

because the cat command gives problems when used with sudo.

-- 
Brian.



Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread Thomas Schmitt
Hi,

Greg Wooledge wrote:
> the inability to *search* within the
> info page to find occurrences of your keyword can be maddening.

It's not _that_ terrible. Pressing in
  info dd
the "/" key, i get a prompt
  Regexp search []:

The input "dsync" brings me to the ‘dsync’ explanation.
Pressing "/" again and then the Enter key, brings me to its line in the
Concept index. Doing it again brings me back to the first found occurence.

Said that, i agree that the form of man pages is more comfortable to me
than the form of info.


As maintainer of GNU xorriso i am obliged to provide an info document,
which must not contain less information than the man page.
My solution is to insert enough @c comments with man page entrails into
the .texi file which is the source of xorriso.info
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/xorriso/xorriso.texi
to be able to derive the man page
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/xorriso/xorriso.1
by help of a little C program
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/xorriso/make_xorriso_1.c

The GNU utiliy makeinfo ignores the comments and generates the .info document
from xorriso.texi
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/xorriso/xorriso.info
(My browser refuses to show it but only offers for download.)

The Debian package of xorriso installs xorriso.1.gz and xorriso.info.gz
alike. Both give the same information. I look up the man page when i need
to remember what i programmed ten years ago.


Have a nice day :)

Thomas



Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread tomas
On Mon, May 17, 2021 at 09:38:49AM -0400, Greg Wooledge wrote:

[...]

> Now, as for the info pages themselves: unlike traditional man pages,
> where all of the documentation is on one page, in which you can scroll
> up and down and search, info pages are chopped up into tiny little
> sections, and you only see one section at a time [...]

To be fair, info has links going across "pages" and you can search
across several pages.

Of course, tool usage is, above all else, habit. Changing from man
to info is almost as painful as the other way around.

There goes a missed chance for (more than one!) unified user interfaces,
alas.

Cheers
 - t


signature.asc
Description: Digital signature


Re: Downloading from lists.debian.org/debian-user in mbox format

2021-05-17 Thread Richard Owlett

On 05/17/2021 08:50 AM, Brian wrote:

On Mon 17 May 2021 at 04:58:42 -0500, Richard Owlett wrote:


Some mailing list save posts in mbox format.
Is there any way to download specific threads from
lists.debian.org/debian-user in mbox format?


No.

https://lists.debian.org/debian-user/2003/02/msg02997.html

Bug #161440.



Only ~2 decades old. Wouldn't want to fix things too fast. :{





Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread Richard Owlett

On 05/17/2021 08:21 AM, IL Ka wrote:

I got the impression from the search hits I got info pages were
available on the web complete with useful hyperlinks.

In a terminal "info dd" gives an annoying blob of text. Due to visual
limits I *MUCH* prefer HTML for large amounts of information.



All gnu info pages are available online:
https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html#dd-invocation
Along with debian man pages:
https://manpages.debian.org/buster/coreutils/dd.1.en.html



https://www.gnu.org/software/coreutils/manual/html_node/Concept-index.html#Concept-index
is now next to
https://manpages.debian.org/
in my bookmarks folder.
Thanks.





Re: Downloading from lists.debian.org/debian-user in mbox format

2021-05-17 Thread Brian
On Mon 17 May 2021 at 04:58:42 -0500, Richard Owlett wrote:

> Some mailing list save posts in mbox format.
> Is there any way to download specific threads from
> lists.debian.org/debian-user in mbox format?

No.

https://lists.debian.org/debian-user/2003/02/msg02997.html

Bug #161440.

-- 
Brian.



Packages with upgradable origin but kept back: Debian testing: guile-2.2-libs

2021-05-17 Thread Charles Curley
I upgraded a laptop from Buster to Bullseye recently. I had unattended
upgrades running, and have kept it running since. I have gotten the
following in the unattended upgrades report since:

Packages with upgradable origin but kept back:
 Debian testing:
  guile-2.2-libs

root@iorich:/etc/apt# apt list --upgradable -a
Listing... Done
guile-2.2-libs/testing 2.2.7+1-5.4 amd64 [upgradable from: 2.2.4+1-2+deb10u1]
guile-2.2-libs/now 2.2.4+1-2+deb10u1 amd64 [installed,upgradable to: 
2.2.7+1-5.4]

root@iorich:/etc/apt#

Meanwhile, on another AMD64 machine with a fresh installation of
Bullseye:

root@orca:~# pre guile
guile-2.2-libs  2.2.7+1-5.4 amd64
guile-3.0   3.0.5-2 amd64
guile-3.0-libs  3.0.5-2 amd64
root@orca:~# 

And on a i686 machine with a fresh installation of Bullseye:

root@grissom:~# pre guile
guile-2.2-libs  2.2.7+1-5.4 i386
root@grissom:~# 


If I try installing guile-3.0 on the first machine, iorich, I get:

root@iorich:/etc/apt# apt install guile-3.0
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  guile-2.2-libs guile-3.0-libs libgc1
Suggested packages:
  guile-3.0-doc
The following packages will be REMOVED:
  libgc1c2
The following NEW packages will be installed:
  guile-3.0 guile-3.0-libs libgc1
The following packages will be upgraded:
  guile-2.2-libs
1 upgraded, 3 newly installed, 1 to remove and 0 not upgraded.
Need to get 6,431 kB/11.7 MB of archives.
After this operation, 53.4 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
root@iorich:/etc/apt# 


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/



Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread Greg Wooledge
On Mon, May 17, 2021 at 03:03:22PM +0200, to...@tuxteam.de wrote:
> Try typing in a terminal `info dd' and see what happens :)

unicorn:~$ info dd
bash: info: command not found

;-)

GNU's info pages are a highly debated thing, in some circles.  Many
people despise them, some people love them, and the vast majority are
simply confused.

The primary issue is the user interface for actually reading the damned
things.  You're supposed to be using emacs, and you're supposed to hit
some bizarre hand-mutilating key chord to invoke the info page reader
inside of emacs.

If you're *not* an emacs user, then there's a standalone tool called
"info" that they provide which is supposed to emulate the experience
for you, somewhat.  The problem here is that if you're not an emacs
user, then the experience is *completely alien* and makes no sense at all.

There's an alternative tool called "pinfo" that provides a different
interface for reading info pages, which is a bit more comfortable for
non-emacs users.  It resembles lynx.  But it has limitations and does
not reproduce all of the features of the official tool.

So, feel free to try both "info" and "pinfo" (some installation required)
and see which one you can tolerate better.  Or use the online web version
of the pages, if that works better for you.

Now, as for the info pages themselves: unlike traditional man pages,
where all of the documentation is on one page, in which you can scroll
up and down and search, info pages are chopped up into tiny little
sections, and you only see one section at a time.  This may be an
advantage if you're actually looking for a specific feature that you
suspect may exist, but you don't know what it's *called*.  Navigating
the hierarchical structure may lead you to a place that describes the
feature you're looking for, although you'll have to do a lot of reading
along the way.

On the other hand, if you *do* know what something is called, or at least
you have a few reasonable guesses, the inability to *search* within the
info page to find occurrences of your keyword can be maddening.



Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread IL Ka
> I got the impression from the search hits I got info pages were
> available on the web complete with useful hyperlinks.
>
> In a terminal "info dd" gives an annoying blob of text. Due to visual
> limits I *MUCH* prefer HTML for large amounts of information.
>

All gnu info pages are available online:
https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html#dd-invocation
Along with debian man pages:
https://manpages.debian.org/buster/coreutils/dd.1.en.html


Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread Richard Owlett

On 05/17/2021 08:03 AM, to...@tuxteam.de wrote:

On Mon, May 17, 2021 at 07:56:45AM -0500, Richard Owlett wrote:

On 05/17/2021 03:00 AM, to...@tuxteam.de wrote:

... (this is from the info page, which sometimes is more complete than the man 
page):



My web search turned up only compliments for info pages.
NOTHING on where to find :{
Help please.


If we are talking about `dd', this is part of coreutils, whose info file
comes as one big package, here:

   /usr/share/info/coreutils.info.gz

...which is part of the coreutils Debian package. So it got installed
alongside your `dd'.

Try typing in a terminal `info dd' and see what happens :)

Cheers
  - t



I got the impression from the search hits I got info pages were 
available on the web complete with useful hyperlinks.


In a terminal "info dd" gives an annoying blob of text. Due to visual 
limits I *MUCH* prefer HTML for large amounts of information.







Re: info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread tomas
On Mon, May 17, 2021 at 07:56:45AM -0500, Richard Owlett wrote:
> On 05/17/2021 03:00 AM, to...@tuxteam.de wrote:
> >... (this is from the info page, which sometimes is more complete than the 
> >man page):
> >
> 
> My web search turned up only compliments for info pages.
> NOTHING on where to find :{
> Help please.

If we are talking about `dd', this is part of coreutils, whose info file
comes as one big package, here:

  /usr/share/info/coreutils.info.gz

...which is part of the coreutils Debian package. So it got installed
alongside your `dd'.

Try typing in a terminal `info dd' and see what happens :)

Cheers
 - t


signature.asc
Description: Digital signature


Re: OT: minimum bs for dd?

2021-05-17 Thread tomas
On Mon, May 17, 2021 at 03:21:20PM +0300, Andrei POPESCU wrote:

[...]

> If my understanding from your quotes and David's links is correct 
> oflag=sync may be slower in specific circumstances, but it depends on so 
> many factors (hardware, caches, block size used, etc.) that it is hard 
> to predict.

The proof would be in the pudding, of course.

> Quite likely it won't make a significant difference for "regular" use.

For regular use, the oflag is (as I tried to explain) invaluable to me.

See, I bought myself a refurbished notebook, but I didn't skimp on
RAM: 16GB.

My main dd use is to write some image onto a flash removable (stick,
SD card). The write channel is slow, the available buffer big.

Once the write is done (if I do cp or forget the sync), not much
is actually written to the drive. Then I say "sync", and... the
sync goes shopping, without telling me when it plans to be back :-)

With "oflags=sync status=progress" (or by sending SIGHUP to the
dd process) I can get a rough idea when I'll be able to pull out
that stick.

Needless to say, I don't mind the copy being some, say, 10% slower
(totally making that up, but for a seq writing with some biggish
block size, I'd expect even that to be an outrageous exaggeration).

Cheers
 - t


signature.asc
Description: Digital signature


info pages WHERE? -- was [Re: OT: minimum bs for dd?]

2021-05-17 Thread Richard Owlett

On 05/17/2021 03:00 AM, to...@tuxteam.de wrote:

... (this is from the info page, which sometimes is more complete than the man 
page):



My web search turned up only compliments for info pages.
NOTHING on where to find :{
Help please.





Re: audacity on Buster - qui est 'input?'

2021-05-17 Thread didier gaumet

Le 17/05/2021 à 13:45, Bob Bernstein a écrit :
[...]
Much of the focus of the above is setting PulseAudio to launch as a 
system-wide service, for all users,

[...]

pulseaudio --daemonize


It's not my impression. I agree with the reply of Greg Wooledge: to me, 
Pulseaudio is automatically started on a per_user basis,


didier@hp-notebook14:~$ systemctl --user | grep -i pulse
pulseaudio.service 
 loaded active running   Sound Service 

pulseaudio.socket 
 loaded active running   Sound System




Re: audacity on Buster - qui est 'input?'

2021-05-17 Thread Andrei POPESCU
On Lu, 17 mai 21, 08:16:39, Greg Wooledge wrote:
> On Mon, May 17, 2021 at 07:45:34AM -0400, Bob Bernstein wrote:
> > I can take a hint. It seems to me I have to place the statement
> > 
> > pulseaudio --daemonize
> > 
> > in some user file or other but nowhere can I find in that doc (coulda missed
> > it; I'm an old guy) a suggestion as to what file to use. I'm thinking what's
> > wrong with just putting that into my .xsession file?
> 
> I assumed this at first, too.  It seems right, doesn't it?  Sure.
> 
> But it doesn't work.  Pulseaudio is supposed to start *itself* automatically
> upon demand.  It's supposed to "just work", and you're not supposed to
> have to do anything to make it work.
> 
> When I tried putting a pulseaudio start-up command in my .xsession file,
> I had problems.  Every single time -- and I mean 100% of the time, literally
> *every* single time -- that I started an X session, I was left with a
> nonresponsive pulseaudio daemon.  But if I stopped and restarted the
> pulseaudio daemon, then it would work fine.
> 
> So, every time I started X, I had to manually stop pulseaudio, and
> then manually restart it.
> 
> Eventually I figured out that the solution was *not* to start pulseaudio
> myself.  Just let it autostart itself on demand.
> 
> For some reason, this works, but starting it myself does not work.
> 
> I have no idea why.  But there you go.  That's the answer, apparently.
 
As far as I can tell pulseaudio ships with .socket user unit that is 
activated by default, so your "manually" started pulseaudio instance 
might conflict with that.

This should be easy to test with

systemctl --user stop pulseaudio.socket
pulseaudio --daemonize

If that works and you prefer it you can just 'mask' the .socket unit to 
prevent it from starting[1].

On the other hand you might achieve the desired outcome simply be 
enabling the pulseaudio.service unit as it shouldn't conflict with the 
the .socket unit.

systemctl --user enable --now pulseaudio.service


[1] because it's shipped enabled at system level a simple 'disable' 
won't work.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: OT: minimum bs for dd?

2021-05-17 Thread Andrei POPESCU
On Lu, 17 mai 21, 10:00:22, to...@tuxteam.de wrote:
> On Mon, May 17, 2021 at 10:29:06AM +0300, Andrei POPESCU wrote:
> > 
> > Hmm, would you (or anyone else) know what is the difference between 
> > oflags=sync and conv=fsync?
> 
> Let me put the docs next to each other (this is from the info page,
> which sometimes is more complete than the man page):

[snip informative quote from info page]

Ugh, forgot about the info/man distinction fro GNU software.
 
> I'd say "conv=fsync" does a sync at the end of the whole thing, while
> "oflag=sync" open(2)s the file with O_SYNC (likewise "oflag=dsync"
> translates to an open(2) with O_DSYNC), so the sync happens after each
> block write. That's what I want, since it gives me much more predictability
> as to when I can plop out my usb stick :)

If my understanding from your quotes and David's links is correct 
oflag=sync may be slower in specific circumstances, but it depends on so 
many factors (hardware, caches, block size used, etc.) that it is hard 
to predict.

Quite likely it won't make a significant difference for "regular" use.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: audacity on Buster - qui est 'input?'

2021-05-17 Thread Greg Wooledge
On Mon, May 17, 2021 at 07:45:34AM -0400, Bob Bernstein wrote:
> I can take a hint. It seems to me I have to place the statement
> 
> pulseaudio --daemonize
> 
> in some user file or other but nowhere can I find in that doc (coulda missed
> it; I'm an old guy) a suggestion as to what file to use. I'm thinking what's
> wrong with just putting that into my .xsession file?

I assumed this at first, too.  It seems right, doesn't it?  Sure.

But it doesn't work.  Pulseaudio is supposed to start *itself* automatically
upon demand.  It's supposed to "just work", and you're not supposed to
have to do anything to make it work.

When I tried putting a pulseaudio start-up command in my .xsession file,
I had problems.  Every single time -- and I mean 100% of the time, literally
*every* single time -- that I started an X session, I was left with a
nonresponsive pulseaudio daemon.  But if I stopped and restarted the
pulseaudio daemon, then it would work fine.

So, every time I started X, I had to manually stop pulseaudio, and
then manually restart it.

Eventually I figured out that the solution was *not* to start pulseaudio
myself.  Just let it autostart itself on demand.

For some reason, this works, but starting it myself does not work.

I have no idea why.  But there you go.  That's the answer, apparently.



Re: OT: minimum bs for dd?

2021-05-17 Thread Andrei POPESCU
On Lu, 17 mai 21, 17:50:24, David wrote:
> On Mon, 17 May 2021 at 17:29, Andrei POPESCU  wrote:
> 
> > Hmm, would you (or anyone else) know what is the difference between
> > oflags=sync and conv=fsync?
> 
> https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html
> 
> https://unix.stackexchange.com/questions/508701/dd-command-oflag-direct-and-sync-flags
> 
> https://abbbi.github.io/dd/
 


Thank you, I should have guessed there is answer on StackExchange.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: audacity on Buster - qui est 'input?'

2021-05-17 Thread Bob Bernstein

On Mon, 17 May 2021, didier gaumet wrote:


https://manual.audacityteam.org/man/tutorial_recording_computer_playback_on_linux.html


Much of the focus of the above is setting PulseAudio to launch 
as a system-wide service, for all users, but it goes on to say 
that if you make that choice, rather than launching it on a 
per-user basis, that you are "on your own."


I can take a hint. It seems to me I have to place the statement

pulseaudio --daemonize

in some user file or other but nowhere can I find in that doc 
(coulda missed it; I'm an old guy) a suggestion as to what file 
to use. I'm thinking what's wrong with just putting that into my 
.xsession file?


At some point, being an impulsive sonofagun, and a life-long 
subscriber to "don't read the manual; wing that sucker," I will 
try .xsession.


Comments, absent outright opprobrium, are welcome.

--
"No matter how big the problem is, you can always run away from it."
Dom Irrera



Re: OT: minimum bs for dd?

2021-05-17 Thread Richard Hector

On 17/05/21 6:30 pm, to...@tuxteam.de wrote:

This is one point. The other, which adds more convenience is that
dd has an explicit argument for (input and) output file name, whereas
cat relies on redirection. This becomes relevant when you try to

   sudo cat thing > that_other_thing

and realise that the ">" is *not* in the sudo context (and what
you would have to do to "fix" that).

Instead,

   sudo dd if=thing of=this_other_thing

Just Works out of the box. More relevant when doing ">>" (use
dd's oflag=append then).


And if you already have a long pipeline in your command history, that 
didn't work because of the above issue, you can use:


... |sudo dd of=this_other_thing

Note: I'm not sure what the difference is between that_other_thing and 
this_other_thing :-)


Richard



Re: OT: minimum bs for dd?

2021-05-17 Thread Greg Wooledge
On Sun, May 16, 2021 at 06:43:54PM -0400, The Wanderer wrote:
> > cat /dev/sdb
> > 
> > dd /dev/sdb

> Is there really no functional difference between the baseline trivial
> functionalities of cat and dd?

There are two differences:

1) dd is specified to use default input and output block sizes of 512 bytes.

2) dd is specified to write a summary to stderr upon completion.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html



Re: OT: minimum bs for dd?

2021-05-17 Thread The Wanderer
On 2021-05-17 at 02:57, Thomas Schmitt wrote:

> Hi,
> 
> Andrew M.A. Cater wrote:
> 
>>> When copying a file and writing it to another medium, perhaps eg
>>> when writing a DVD .iso file directly to a USB stick, it's
>>> ideal.
> 
> The Wanderer wrote:
> 
>> Is there really no functional difference between the baseline
>> trivial functionalities of cat and dd?
> 
> cat and cp cannot do the following:
> 
>   # Remove possible GPT backup header from the end of the USB stick
>   dd if=/dev/zero of=/dev/sdc bs=512 seek=3915775 count=1 status=none

True, but that's not the baseline trivial functionality, which is what
Stefan had given in the example I was responding to; it includes a lot
of extra behavior-modifying flags.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature


Downloading from lists.debian.org/debian-user in mbox format

2021-05-17 Thread Richard Owlett

Some mailing list save posts in mbox format.
Is there any way to download specific threads from 
lists.debian.org/debian-user in mbox format?





Re: KDE and Pulseaudio; swapping users

2021-05-17 Thread deloptes
James Allsopp wrote:

> Hi,
> Does anyone have a solution for the problem that when I switch users, to
> have any sound as the new user, I have to su to root to kill the other
> users Pulseaudio. If I don't do this I'm left with a dummy sound card.

>From what I read recently but couldn't test because of time constrains is
that ConsoleKit/PolicyKit should manage this



KDE and Pulseaudio; swapping users

2021-05-17 Thread James Allsopp
Hi,
Does anyone have a solution for the problem that when I switch users, to
have any sound as the new user, I have to su to root to kill the other
users Pulseaudio. If I don't do this I'm left with a dummy sound card.

Thanks
James


Re: audacity on Buster - qui est 'input?'

2021-05-17 Thread didier gaumet

Hello,

This chapter of the on-line Audacity doc could be of interest to you:
https://manual.audacityteam.org/man/tutorial_recording_computer_playback_on_linux.html



Re: OT: minimum bs for dd?

2021-05-17 Thread tomas
On Mon, May 17, 2021 at 10:29:06AM +0300, Andrei POPESCU wrote:
> On Lu, 17 mai 21, 08:32:28, to...@tuxteam.de wrote:
> > On Mon, May 17, 2021 at 08:59:43AM +0300, Andrei POPESCU wrote:
> > 
> > [...]
> > 
> > > I'll raise you 'cp':
> > > 
> > > cp foo.iso /dev/sdb
> > > 
> > > 
> > > which is both fast and short to type (apparently it's smart about using 
> > > the correct block size).
> > 
> > I'll be sure to try that some day :)
> > 
> > > Unfortunately it's missing dd's equivalent of status=progress.
> > 
> > and oflags=sync.
> 
> Hmm, would you (or anyone else) know what is the difference between 
> oflags=sync and conv=fsync?

Let me put the docs next to each other (this is from the info page,
which sometimes is more complete than the man page):

* conv=fsync:

  ‘conv=CONVERSION[,CONVERSION]...’
 Convert the file as specified by the CONVERSION argument(s).  (No
 spaces around any comma(s).)

 [...]

 The following “conversions” are really file flags and don’t affect
 internal processing:

 [...]

 ‘fsync’
Synchronize output data and metadata just before finishing.
This forces a physical write of output data and metadata.

* oflag=sync:

  ‘oflag=FLAG[,FLAG]...’
 Access the output file using the flags specified by the FLAG
 argument(s).  (No spaces around any comma(s).)

 [...]

 ‘dsync’
Use synchronized I/O for data.  For the output file, this
forces a physical write of output data on each write.  For the
input file, this flag can matter when reading from a remote
file that has been written to synchronously by some other
process.  Metadata (e.g., last-access and last-modified time)
is not necessarily synchronized.

 ‘sync’
Use synchronized I/O for both data and metadata.

I'd say "conv=fsync" does a sync at the end of the whole thing, while
"oflag=sync" open(2)s the file with O_SYNC (likewise "oflag=dsync"
translates to an open(2) with O_DSYNC), so the sync happens after each
block write. That's what I want, since it gives me much more predictability
as to when I can plop out my usb stick :)

Cheers
 - t


signature.asc
Description: Digital signature


Re: OT: minimum bs for dd?

2021-05-17 Thread David
On Mon, 17 May 2021 at 17:29, Andrei POPESCU  wrote:

> Hmm, would you (or anyone else) know what is the difference between
> oflags=sync and conv=fsync?

https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html

https://unix.stackexchange.com/questions/508701/dd-command-oflag-direct-and-sync-flags

https://abbbi.github.io/dd/



audacity on Buster - qui est 'input?'

2021-05-17 Thread Bob Bernstein

Buster amd64:
$ uname -a
Linux debian.localdomain 4.19.0-14-amd64 #1 SMP Debian 
4.19.171-2 (2021-01-30) x86_64 GNU/Linux


$ dpkg -l |grep audacity
ii  audacity 2.2.2-1+b1 
amd64fast, cross-platform audio editor
ii  audacity-data2.2.2-1 
all  fast, cross-platform audio editor (data)


On audacity's main screen the input device is set at ALSA with 
no other choices available.


If I hit Generate->Tone I can record and play back said tone.

But if I turn on a favorite internet radio station ("Your 
Classical") the signal does not find it's way into audacity, 
although I can listen to my machine's headphone jack with great 
pleasure.


This regardless of whether I select an input of 'default', 
'sysdefault', or any of the other half dozen or choices I tested 
but alas did not make a note of.


Question: given this hardware and underlying linux, what do 
others find works as 'input' for audacity?


Thank you.


--
RSB



Re: OT: minimum bs for dd?

2021-05-17 Thread Andrei POPESCU
On Lu, 17 mai 21, 08:32:28, to...@tuxteam.de wrote:
> On Mon, May 17, 2021 at 08:59:43AM +0300, Andrei POPESCU wrote:
> 
> [...]
> 
> > I'll raise you 'cp':
> > 
> > cp foo.iso /dev/sdb
> > 
> > 
> > which is both fast and short to type (apparently it's smart about using 
> > the correct block size).
> 
> I'll be sure to try that some day :)
> 
> > Unfortunately it's missing dd's equivalent of status=progress.
> 
> and oflags=sync.

Hmm, would you (or anyone else) know what is the difference between 
oflags=sync and conv=fsync?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature


Re: OT: minimum bs for dd?

2021-05-17 Thread Thomas Schmitt
Hi,

Andrew M.A. Cater wrote:
> > When copying a file and writing it to another medium, perhaps eg when
> > writing a DVD .iso file directly to a USB stick, it's ideal.

The Wanderer wrote:
> Is there really no functional difference between the baseline trivial
> functionalities of cat and dd?

cat and cp cannot do the following:

  # Remove possible GPT backup header from the end of the USB stick
  dd if=/dev/zero of=/dev/sdc bs=512 seek=3915775 count=1 status=none

  # Copy the ISO with its built-in partition table to the USB stick.
  # Show realistic progress messages by curbing the i/o buffering.
  ISO=debian-10.6.0-amd64-netinst.iso
  dd if="$ISO" of=/dev/'sdc' bs=1M status=progress oflag=dsync

With all copy methods one should do before unplugging the stick:

  sync


It should be noted that dd has its special pitfalls. E.g. if the input file
is not a data file or block device, then one should use
  iflag=fullblock
because with some versions of dd there is the risk to get partially read
blocks written as full output blocks.
(I cannot reproduce it right now by
   (echo hello ; sleep 1 ; echo hello) | dd of=dd_target_file obs=512
but i had undesirable results in the past.)


Whatever, the main risk with a short copy command performed by the superuser
is to pick the wrong device file name and thus to overwrite a disk with
valuable content.
I made a cautious (or paranoid) helper script for the task of copying ISOs
to USB sticks:
  https://wiki.debian.org/XorrisoDdTarget

It came too late for the freeze of Debian 11 but is planned to be
available as package in Debian 12. Up to then it can be downloaded from
upstream and verified by its corresponding .sig file:
  gpg --verify xorriso-dd-target.sig xorriso-dd-target


Have a nice day :)

Thomas



Re: OT: minimum bs for dd?

2021-05-17 Thread tomas
On Mon, May 17, 2021 at 08:59:43AM +0300, Andrei POPESCU wrote:

[...]

> I'll raise you 'cp':
> 
> cp foo.iso /dev/sdb
> 
> 
> which is both fast and short to type (apparently it's smart about using 
> the correct block size).

I'll be sure to try that some day :)

> Unfortunately it's missing dd's equivalent of status=progress.

and oflags=sync.

Cheers
 - t


signature.asc
Description: Digital signature


Re: OT: minimum bs for dd?

2021-05-17 Thread tomas
On Sun, May 16, 2021 at 06:33:57PM -0400, Stefan Monnier wrote:
> >> On Sun, May 16, 2021 at 01:31:49PM -0500, Richard Owlett wrote:
> >> > I'll bite ;}
> >> > When is it the right tool?
> >> 
> >> When you're using it to convert ebcdic to ascii, while swapping bytes and
> >> reblocking an ancient file from a barely readable archival tape.
> >> 
> >> > When is it not?
> >> 
> >> When copying a file.
> >> 
> > When copying a file and writing it to another medium, perhaps eg when 
> > writing
> > a DVD .iso file directly to a USB stick, it's ideal.
> 
> Not sure about ideal:
> 
> cat /dev/sdb
> 
> is one char longer than
> 
> dd /dev/sdb
> 
> but it's often faster (you can speed up `dd` by providing a larger
> `bs=` argument, but then you've lost the length advantage ;-)

Agreed. When writing to USB flash media I've the impression that
there's a sweet spot somewhere between 64K and 1M block size.

The maximum is pretty flat, so I just use 1M (easier to remember),
but it's significant wrt the default 512B. It possibly depends on
the rest of the hardware.

This is one point. The other, which adds more convenience is that
dd has an explicit argument for (input and) output file name, whereas
cat relies on redirection. This becomes relevant when you try to

  sudo cat thing > that_other_thing

and realise that the ">" is *not* in the sudo context (and what
you would have to do to "fix" that).

Instead,

  sudo dd if=thing of=this_other_thing

Just Works out of the box. More relevant when doing ">>" (use
dd's oflag=append then).

Another nice thing is oflag=sync: when writing to big media, it
makes sure that data doesn't end up in the buffer cache making
you wait during the final sync.

And oh, 'status=progress' in combination with the above.

So... yay, dd.

Cheers
 - t


signature.asc
Description: Digital signature


Re: OT: minimum bs for dd?

2021-05-17 Thread Andrei POPESCU
On Du, 16 mai 21, 18:33:57, Stefan Monnier wrote:
> >> On Sun, May 16, 2021 at 01:31:49PM -0500, Richard Owlett wrote:
> >> > I'll bite ;}
> >> > When is it the right tool?
> >> 
> >> When you're using it to convert ebcdic to ascii, while swapping bytes and
> >> reblocking an ancient file from a barely readable archival tape.
> >> 
> >> > When is it not?
> >> 
> >> When copying a file.
> >> 
> > When copying a file and writing it to another medium, perhaps eg when 
> > writing
> > a DVD .iso file directly to a USB stick, it's ideal.
> 
> Not sure about ideal:
> 
> cat /dev/sdb
> 
> is one char longer than
> 
> dd /dev/sdb
> 
> but it's often faster (you can speed up `dd` by providing a larger
> `bs=` argument, but then you've lost the length advantage ;-)

I'll raise you 'cp':

cp foo.iso /dev/sdb


which is both fast and short to type (apparently it's smart about using 
the correct block size).

Unfortunately it's missing dd's equivalent of status=progress.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature