Re: No puedo compartir pantalla en Jitsi, sobre navegador.

[Camaleón]

El 2021-07-11 a las 20:02 -0400, Rubén Ibáñez escribió:

> Amigos: Tengo instalado Debian 10, con Firefox. Ahora instalé también
> Chromium, procurando solucionar el problema.
> Sin embargo, con ninguno de ambos navegadores puedo compartir pantalla
> cuando me comunico con Jitsi Meet.

(...)

Hay un informe de fallo abierto en Mozilla, mira a ver si se trata de 
tu situación:

Jitsi Meet Screen sharing doesn't work properly with Firefox 80-83 when 
presenter has a multi-monitor setup
https://bugzilla.mozilla.org/show_bug.cgi?id=1663286

> Desde un Lubuntu live en un pendrive funciona bien. Con Debian 9 (antes de
> actualizar al 10) también iba bien. En otro hilo menciono que el Grub no me
> muestra el segundo sistema (Lubuntu) cuando ya está instalado.
> Desde ya agradezco vuestra ayuda.
> Rubén.

A revisar:

- Versión de Firefox
- Extensiones instaladas en el navegador
- Servidor gráfico (Xorg o Wayland)
- Configuración con múltiples monitores
- Controlador de la tarjeta gráfica 

Saludos,

-- 
Camaleón 

Re: Failure to use 3840x2160 30hz with Intel 620 chipset

[Pierre Couderc]

On 7/11/21 12:29 AM, Felix Miata wrote:

Pierre Couderc composed on 2021-07-10 23:07 (UTC+0200):
  


Thank your for your precious help.

I quit this big 4k for a week of holidays without any monitor...

And come back to it nextweek !

Re: Mount Windows Partion says it is hybernating, but it isn't, surely it isn't!

[Richmond]

Richmond  writes:

> When I try to mount Windows 10 partition from Linux it says:
>
> "Windows is hibernated, refused to mount.
> Falling back to read-only mount because the NTFS partition is in an
> unsafe state. Please resume and shutdown Windows fully (no hibernation
> or fast restarting.)
> Could not mount read-write, trying read-only"
>
> But I have unchecked the "fast boot" in Windows 10, and also unchecked
> the hibernate (both from the administrator account), and I tried
> restarting, and shutting down with
>
> shutdown /s /f /t 0
>
> and
>
> shutdown /r /o
>
> Windows is up to date and there are no pending updates.
>
> But always the same error from debian.

I fixed this with:

mount -t ntfs-3g -o remove_hiberfile

but the file must have come back again after the next Windows restart.

So I just have to remember to do this every time.

Re: grub no muestra segunda instalación

[Rubén Ibáñez]

Muchas gracias por tu respuesta. Sin embargo, no sé como hacer lo que me
dices. Si puedes aclararme como se hace te lo agradeceré.
Rubén.


El dom, 11 jul 2021 a las 20:04, Raphael Verdugo P. (<
raphael.verd...@gmail.com>) escribió:

>
>
> El dom, 11 jul 2021 a las 19:54, Rubén Ibáñez (<
> ruben.mariano.iba...@gmail.com>) escribió:
>
>> Amigos de la lista: Acabo de instalar junto a Debian 10 -recientemente
>> instalado- Lubuntu. En otro mensaje digo por qué lo hice. Pero terminada la
>> instalación y reiniciada el selector Grub sólo me muestra Debian 10. ¿Como
>> puedo corregir esto? Ya probé a reinstalar Lubuntu, pero sigue el problema.
>> Gracias por adelantado.
>> Rubén.
>>
>>
> ¿que estructura de particiones tienes?
>
> ¿donde instalaste grub?
>
> ingresa a  Debian y  desde ahí agrega la entrada para lubuntu  en GRUB.
>
>
>
>
>
> --
> Raphael Verdugo P.
> BOFH
>

Re: Mount Windows Partion says it is hybernating, but it isn't, surely it isn't!

[Polyna-Maude Racicot-Summerside]

You can disable the Hibernate option in Windows (different from fast logon).


On 2021-07-11 6:24 p.m., Richmond wrote:
> Richmond  writes:
> 
>> When I try to mount Windows 10 partition from Linux it says:
>>
>> "Windows is hibernated, refused to mount.
>> Falling back to read-only mount because the NTFS partition is in an
>> unsafe state. Please resume and shutdown Windows fully (no hibernation
>> or fast restarting.)
>> Could not mount read-write, trying read-only"
>>
>> But I have unchecked the "fast boot" in Windows 10, and also unchecked
>> the hibernate (both from the administrator account), and I tried
>> restarting, and shutting down with
>>
>> shutdown /s /f /t 0
>>
>> and
>>
>> shutdown /r /o
>>
>> Windows is up to date and there are no pending updates.
>>
>> But always the same error from debian.
> 
> I fixed this with:
> 
> mount -t ntfs-3g -o remove_hiberfile
> 
> but the file must have come back again after the next Windows restart.
> 
> So I just have to remember to do this every time.
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: grub no muestra segunda instalación

[Raphael Verdugo P.]

El dom, 11 jul 2021 a las 19:54, Rubén Ibáñez (<
ruben.mariano.iba...@gmail.com>) escribió:

> Amigos de la lista: Acabo de instalar junto a Debian 10 -recientemente
> instalado- Lubuntu. En otro mensaje digo por qué lo hice. Pero terminada la
> instalación y reiniciada el selector Grub sólo me muestra Debian 10. ¿Como
> puedo corregir esto? Ya probé a reinstalar Lubuntu, pero sigue el problema.
> Gracias por adelantado.
> Rubén.
>
>
¿que estructura de particiones tienes?

¿donde instalaste grub?

ingresa a  Debian y  desde ahí agrega la entrada para lubuntu  en GRUB.





-- 
Raphael Verdugo P.
BOFH

No puedo compartir pantalla en Jitsi, sobre navegador.

[Rubén Ibáñez]

Amigos: Tengo instalado Debian 10, con Firefox. Ahora instalé también
Chromium, procurando solucionar el problema.
Sin embargo, con ninguno de ambos navegadores puedo compartir pantalla
cuando me comunico con Jitsi Meet.
Desde un Lubuntu live en un pendrive funciona bien. Con Debian 9 (antes de
actualizar al 10) también iba bien. En otro hilo menciono que el Grub no me
muestra el segundo sistema (Lubuntu) cuando ya está instalado.
Desde ya agradezco vuestra ayuda.
Rubén.

grub no muestra segunda instalación

[Rubén Ibáñez]

Amigos de la lista: Acabo de instalar junto a Debian 10 -recientemente
instalado- Lubuntu. En otro mensaje digo por qué lo hice. Pero terminada la
instalación y reiniciada el selector Grub sólo me muestra Debian 10. ¿Como
puedo corregir esto? Ya probé a reinstalar Lubuntu, pero sigue el problema.
Gracias por adelantado.
Rubén.

Re: Buster no release file

[Stefan Monnier]

> Revert the change or communicate with the edior. Maybe he has a
> persuasive argument?

In my experience, "communicate with the editor" is the second step, the
first step being "try to figure out how to communicate with the editor".


Stefan

Mount Windows Partion says it is hybernating, but it isn't, surely it isn't!

[Richmond]

When I try to mount Windows 10 partition from Linux it says:

"Windows is hibernated, refused to mount.
Falling back to read-only mount because the NTFS partition is in an
unsafe state. Please resume and shutdown Windows fully (no hibernation
or fast restarting.)
Could not mount read-write, trying read-only"

But I have unchecked the "fast boot" in Windows 10, and also unchecked
the hibernate (both from the administrator account), and I tried
restarting, and shutting down with

shutdown /s /f /t 0

and

shutdown /r /o

Windows is up to date and there are no pending updates.

But always the same error from debian.

Re: Offensive variable names [was: Cool down ...]

[jeremy ardley]

On 12/07/2021 4:32 am, to...@tuxteam.de wrote:

On Sun, Jul 11, 2021 at 08:25:22PM +, ghe2001 wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Master/slave my be less than optimal when describing humans, but they're very 
useful when working with DNS.

And blacklist is useful in SMTP, among others.  IIRC, the word refers to voting 
in classical Athens, not humans.

Offensive terms should, of course, be removed from public discourse, but 
programmers are free to use any string they want to name a variable in their 
code -- especially when released compiled.

The latter may be too simplistic if you're doing free software:
publishing the code becomes part of the game, and if you hope
that people from all over the world reads and enhances the source,
you're smack in the middle of public discourse.

Back to my preferred aphorism: "all generalisations suck" ;-)

Cheers
  - t



You can also run into problems with different languages. For instance a 
Swedish developer would have no problem using terms fart, prick, and 
fack, but some English speakers might take offense. The are actually in 
English fast, small dot, and small compartment.


(WRT fart I used to do fartlek training for orienteering without major 
problems)

Re: Offensive variable names [was: Cool down ...]

[Polyna-Maude Racicot-Summerside]

Hi,

> Whatever, the use of controversial words in publicly visible code is not
> an indication of a professional attitude. Overdoing juvenile enthusiasm
> for provocation might lead to a result like with the "weboob" package which
> got removed from Debian
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907199
> 
Just took a look at this.
It was a real time consuming job only to "try" fixing something done
because a kid had too much free time !

It's really childish to gratify oneself by putting offensive comments in
a software.
> 
> Have a nice day :)
> 
> Thomas
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: Offensive variable names [was: Cool down ...]

[tomas]

On Sun, Jul 11, 2021 at 08:25:22PM +, ghe2001 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> 
> Master/slave my be less than optimal when describing humans, but they're very 
> useful when working with DNS.
> 
> And blacklist is useful in SMTP, among others.  IIRC, the word refers to 
> voting in classical Athens, not humans.
> 
> Offensive terms should, of course, be removed from public discourse, but 
> programmers are free to use any string they want to name a variable in their 
> code -- especially when released compiled.

The latter may be too simplistic if you're doing free software:
publishing the code becomes part of the game, and if you hope
that people from all over the world reads and enhances the source,
you're smack in the middle of public discourse.

Back to my preferred aphorism: "all generalisations suck" ;-)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Offensive variable names [was: Cool down ...]

[ghe2001]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Master/slave my be less than optimal when describing humans, but they're very 
useful when working with DNS.

And blacklist is useful in SMTP, among others.  IIRC, the word refers to voting 
in classical Athens, not humans.

Offensive terms should, of course, be removed from public discourse, but 
programmers are free to use any string they want to name a variable in their 
code -- especially when released compiled.



--
Glenn English


-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAGBQJg61OWACEJEJ/XhjGCrIwyFiEELKJzD0JScCVjQA2Xn9eG
MYKsjDL9Pgf/bYw9jSTRbVfGebf/bqjeqsOtIIA4+lgXC9tKxKa5FJZ0KBuT
7rrms5Y7Lt95U4e/Mw2ciatvBGWIP410PdsvkecOAAdks5WVdXP5KA6us7Ks
+1evTKN1qblJbwFrRtv8MILIHeY0EqSNDNSRikEOopzhpTs1ZczeDde+st6j
JByIv3Zax4R6HQZ1+sFuyHtneGXo3HPP1GgjO+SN/WUKnbxJu+E1xE/Ob1+k
7VBl+DwfccTR7wq2D0NCHA84sxXb+CcTrR1xXYeZN/WhKrTOJs11FTjH/1b1
MJlZN+bmyMuqzsr4QEugQtkszK6uQJDDK+rLaMZmNdX1Aip4GiQYUA==
=ph4F
-END PGP SIGNATURE-

Re: Offensive variable names [was: Cool down ...]

[Andrew M.A. Cater]

On Sun, Jul 11, 2021 at 10:05:39PM +0200, Thomas Schmitt wrote:
> Hi,
> 
> Brian wrote:
> > Variable change? A link from either of you, please.
> 
> After googling "offensive variable name" i got to:
> 
>   "Fix use of offensive word in kafka receiver factory_test"
>   https://github.com/open-telemetry/opentelemetry-collector/issues/2286
> 
> which led to
> 
>   "changed variable name in kafka receiver"
>   
> https://github.com/open-telemetry/opentelemetry-collector/pull/2288/files/c16ff3d61ac966534590585477934eddaeb6b129
> 
> 
> Above Github issue indicates that there are blacklists maintained:
> 
>   "Automated security scanners flag the use of this variable name as
>a potentially offensive word"
> 
> But of course the use of a blacklist is a problem too:
> 
>   
> https://en.wikipedia.org/wiki/Blacklist_%28computing%29#Controversy_over_use_of_the_term
>   https://www.theregister.com/2019/09/03/chromium_microsoft_offensive/
> 

I've found deny_list and allow_list or similar to be quite useful.
Everything can go too far but actually sometimes things do end
up being more clear.

> 
> Whatever, the use of controversial words in publicly visible code is not
> an indication of a professional attitude. Overdoing juvenile enthusiasm
> for provocation might lead to a result like with the "weboob" package which
> got removed from Debian
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907199
> 
> 
> Have a nice day :)
> 

You too

Andy Cater
> Thomas
> 

Re: Offensive variable names [was: Cool down ...]

[Thomas Schmitt]

Hi,

Brian wrote:
> Variable change? A link from either of you, please.

After googling "offensive variable name" i got to:

  "Fix use of offensive word in kafka receiver factory_test"
  https://github.com/open-telemetry/opentelemetry-collector/issues/2286

which led to

  "changed variable name in kafka receiver"
  
https://github.com/open-telemetry/opentelemetry-collector/pull/2288/files/c16ff3d61ac966534590585477934eddaeb6b129


Above Github issue indicates that there are blacklists maintained:

  "Automated security scanners flag the use of this variable name as
   a potentially offensive word"

But of course the use of a blacklist is a problem too:

  
https://en.wikipedia.org/wiki/Blacklist_%28computing%29#Controversy_over_use_of_the_term
  https://www.theregister.com/2019/09/03/chromium_microsoft_offensive/


Whatever, the use of controversial words in publicly visible code is not
an indication of a professional attitude. Overdoing juvenile enthusiasm
for provocation might lead to a result like with the "weboob" package which
got removed from Debian
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907199


Have a nice day :)

Thomas

Re: Cool down... [was: Buster no release file]

[tomas]

On Sun, Jul 11, 2021 at 07:44:07PM +0100, Brian wrote:
> On Sun 11 Jul 2021 at 20:27:23 +0200, to...@tuxteam.de wrote:
> 
> > On Sun, Jul 11, 2021 at 12:32:35PM -0400, Gene Heskett wrote:
> > 
> > [...]
> > 
> > > > > Next we will be banning variable names for being inappropriate.
> > > 
> > > Already happening, sorry to say.
> > 
> > Why sorry? [...]

> I'm lost. Variable change? A link from either of you, please.

The "master" and "slave" terms come to mind, see [1] for an example.
My take? I think it's irrelevant, but feel free to open a new thread
if you're (still) curious. But I don't think my take is that interesting,
anyway :)

> > Electrical code changes, too [...]

> Talk about a change of subject!

πάντα ρέι [1] ;-)

Cheers
[1] https://en.wikipedia.org/wiki/Panta_rhei_(Heraclitus)
 - tomás


signature.asc
Description: Digital signature

Re: Buster no release file

[tomas]

On Sun, Jul 11, 2021 at 02:57:24PM -0400, Stefan Monnier wrote:
> > Revert the change or communicate with the edior. Maybe he has a
> > persuasive argument?
> 
> In my experience, "communicate with the editor" is the second step, the
> first step being "try to figure out how to communicate with the editor".

I think this was settled: he's a well-known Debian maintainer, after all.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Thanks for help!

[Georgi Naplatanov]

On 7/11/21 9:18 PM, Gunnar Gervin wrote:
> 
> How repaired hdd in old osx 8.6 mac i386.
> A live usb with debian 10.9 buster did it asked to change from Bios boot
> to Uefi boot & reinstalled hdd. Laptop works. So now can put distro in
> usb, & try which debian based distro works best on Mac osx 10.13.6. MX,
> PsychOS, Manjaro, Debian?
> I liked the software setup in Psychos; many writing tools in it.
> Gunnar

Hi Gunnar,

what is the hardware you want to use with GNU/Linux?

At the beginning you mentioned macOS 8.6 and after that macOS 10.13.6 ???

What do you want to do with GNU/Linux? You mentioned writing software
but what does this mean - software for writers like LibreOffice or
anything else?

if you are looking for high quality software then I would recommend
Debian, Ubuntu LTS releases or something based on them. Rolling release
distributions often are low quality software - they usually have more bugs.

Kind regards
Georgi

Re: Cool down... [was: Buster no release file]

[Brian]

On Sun 11 Jul 2021 at 20:27:23 +0200, to...@tuxteam.de wrote:

> On Sun, Jul 11, 2021 at 12:32:35PM -0400, Gene Heskett wrote:
> 
> [...]
> 
> > > > Next we will be banning variable names for being inappropriate.
> > 
> > Already happening, sorry to say.
> 
> Why sorry? That was the point of my "missive". There are much worse
> things around us happening right now. Perhaps there /is/ a reason for
> that variable change, after all. Argue with the folks proposing the
> change (but be open and prepared to be convinced... otherwise you have
> no right to expect convincing others ;-D

I'm lost. Variable change? A link from either of you, please.
> 
> [...]
> 
> > Most of the above is mans own inhumanity to man [...]
> 
> > but being forced to work is not necessarily abuse [...]
> 
> I meant abuse *and* child labour; views on the latter change, as
> everything else.

OK.

> Electrical code changes, too -- you can't wire
> a house nowadays as if it were 1923. You might get in hot water
> for that ;-)

Talk about a change of subject!

-- 
Brian.

Re: Cool down... [was: Buster no release file]

[tomas]

On Sun, Jul 11, 2021 at 12:32:35PM -0400, Gene Heskett wrote:

[...]

> > > Next we will be banning variable names for being inappropriate.
> 
> Already happening, sorry to say.

Why sorry? That was the point of my "missive". There are much worse
things around us happening right now. Perhaps there /is/ a reason for
that variable change, after all. Argue with the folks proposing the
change (but be open and prepared to be convinced... otherwise you have
no right to expect convincing others ;-D

[...]

> Most of the above is mans own inhumanity to man [...]

> but being forced to work is not necessarily abuse [...]

I meant abuse *and* child labour; views on the latter change, as
everything else. Electrical code changes, too -- you can't wire
a house nowadays as if it were 1923. You might get in hot water
for that ;-)

P.S: You have over two decades on me, BTW :)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Vulkan with Radeon RX 5700 XT

[The Wanderer]

On 2021-07-11 at 13:20, The Wanderer wrote:

> On 2021-07-10 at 17:36, idiotei...@gmail.com wrote:
> 
>> Le 10/07/2021 à 17:41, The Wanderer a écrit :

>>> That's excellent news; it means that, at least in principle, this
>>> can work in (relatively-)clean Debian as currently constituted.
>>> (It also confirms that RADV is the relevant thing here; my
>>> reading wasn't conclusive as to whether or not that was
>>> specifically something for older card models.)
>>> 
>>> Can you indicate exactly which Vulkan-related packages you're
>>> running from experimental? For that matter, a list of
>>> Vulkan-related packages and package versions from unstable too
>>> would probably be appropriate, since I track testing and am
>>> *highly* hesitant to upgrade against sid wholesale.
>> 
>> There you go, some packages are at the same version in Testing and
>>  Unstable, so you will see them in both.
>> 
>> "aptitude search '?narrow(?installed,?archive(experimental))' |
>> egrep '(mesa|vulkan)'



> I now have all of these (except the dummy packages, which I skipped
> as irrelevant) installed from experimental. All the ones you listed
> from unstable seem to be at the same version in testing, and have no 
> available version in experimental, so there's nothing to upgrade
> there.
> 
> I've also gone so far as to upgrade my kernel to the one in
> experimental (it was only a Debian-packaging version upgrade:
> 5.10.0-7 to 5.10.0-8).
> 
> The results, so far, are exactly the same as before: vulkaninfo
> reports only one "device", llvmpipe / lavapipe.

> I've at least managed to confirm even more strongly than before that 
> amdgpu does seem to be in use; not only is it referenced as loaded
> in dmesg, it appears prominently in /var/log/Xorg.0.log (where
> several other video drivers are tried, including radeon, and all the
> others seem to get unloaded while AMDGPU references continue to
> appear afterwards).
> 
> Yet for some reason, Vulkan is still failing to detect the presence
> of any physical GPU.

> I think at this point I probably need to report an issue with Mesa 
> upstream, and see if they can at least advise me on how to
> troubleshoot it further. Hopefully the fact that I'm now mixing
> package versions between Mesa 20.x (a few -dev packages, at least,
> are still on that) and 21.x (the ones listed above) won't be an
> issue...

Mere minutes after filing a bug report with the Mesa tracker, I thought
of something new (of course), and checked it.

Sure enough: if I run vulkaninfo as root, it detects the GPU just fine.

The issue turns out to have been that /dev/dri/renderD128 is owned by
group render, and my user was not a member of that group. I don't know
of anything which should have told me that it needed to be.

I've added myself to that group, shut down to the (console) login
prompt, and brought things back up, and now vulkaninfo detects the GPU
as my ordinary user as well.

There was no need for me to have pulled in packages from sid and
experimental, but it doesn't seem to have done any harm in this
instance, especially as testing is due to be released as stable (which
should free up packages to migrate from sid to testing, and let packages
in experimental which have non-release-safe changes safely enter sid) in
the fairly near future.

-- 
   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

Re: Buster no release file

[Brian]

On Sun 11 Jul 2021 at 14:08:24 -0400, Greg Wooledge wrote:

> On Sun, Jul 11, 2021 at 07:01:39PM +0100, Brian wrote:
> >  * I do not understand what the issue is.
> 
> The issue is that there is a self-appointed "wiki-owners' association"
> that will undo any efforts one may make to try to improve the wiki.
> Certain pages are "sacred" and must be kept in a specific form, because
> that's the status quo, and the status quo is more important than
> usefulness.
> 
> It's never worth getting into an edit war against these cabals, because
> you (the outsider) will always lose.  The status quo will prevail.  All
> hail the status quo.

There isn't any cabal; just interested, concerned and active users
of the wiki.

Revert the change or communicate with the edior. Maybe he has a
persuasive argument?

-- 
Brian.

Thanks for help!

[Gunnar Gervin]

How repaired hdd in old osx 8.6 mac i386.
A live usb with debian 10.9 buster did it asked to change from Bios boot to
Uefi boot & reinstalled hdd. Laptop works. So now can put distro in usb, &
try which debian based distro works best on Mac osx 10.13.6. MX, PsychOS,
Manjaro, Debian?
I liked the software setup in Psychos; many writing tools in it.
Gunnar

Re: Buster no release file

[Greg Wooledge]

On Sun, Jul 11, 2021 at 07:01:39PM +0100, Brian wrote:
>  * I do not understand what the issue is.

The issue is that there is a self-appointed "wiki-owners' association"
that will undo any efforts one may make to try to improve the wiki.
Certain pages are "sacred" and must be kept in a specific form, because
that's the status quo, and the status quo is more important than
usefulness.

It's never worth getting into an edit war against these cabals, because
you (the outsider) will always lose.  The status quo will prevail.  All
hail the status quo.

Re: Buster no release file

[Brian]

On Sat 10 Jul 2021 at 18:44:47 -0400, Greg Wooledge wrote:

[...]

> I was going to link you to the DebianBuster wiki page where I had put
> the standard sources.list for buster, but it appears someone doesn't
> want you to have that information.
> 
> https://wiki.debian.org/DebianBuster?action=diff=23=22
> 
> You can thank the person who goes by the name PaulWise for making your
> Debian wiki a less informative and less useful place.
> 
> I *REALLY* and truly hate assholes like that.

I considered re-editing the wiki to meet your concerns but

 * I could end up being put in the same category as another editor.
 * The edit was made almost two years ago and was unnoticed.
 * I do not understand what the issue is.
 * It's a wiki. Sympathisers with your cause may have their own plans.
 * I have trouble with posts containing threatening language.
 * Ruffled feathers can be preened.
 * Why me?

-- 
Brian.

Re: GPS, logiciels libres et Debian

[Polyna-Maude Racicot-Summerside]

Salut,

On 2021-07-11 10:31 a.m., sebastien.di...@free.fr wrote:
> Le 2021-07-09 18:11, Polyna-Maude Racicot-Summerside a écrit :
>> Il y a quelques temps j'ai eu besoin d'un GPS pour mon appareil photo.
>> Comme c'est un vieux modèle, il fonctionnait via port série.
> 
> Il n'est pas nécessaire d'avoir un GPS couplé à l'appareil photo. Il est
> aussi possible de :
> 
> 1. Photographier à un moment quelconque de la balade l'écran du GPS
> montrant l'heure à la seconde près, puis de retour à la maison, de
> comparer l'heure affichée par le GPS sur la photo et l'heure indiquée
> dans les métadonnées de la photo pour déterminer le décalage horaire
> entre le GPS et l'appareil photo.
> 
> 2. Une fois cet écart déterminé, il est possible de recaler l'heure de
> création enregistrée dans les photographies avec exiftool. Par exemple,
> si on découvre que l'horloge de l'appareil photo avait un retard de
> 4m12s, on exécute la commande : exiftool "-alldates+=0:4:12" *.jpg
> 
> 3. L'injection des coordonnées GPS dans les photographies est alors
> possible en s'appuyant sur la trace GPX du GPS (l'outil calculant la
> position par interpolation horaire des positions enregistrées dans la
> trace). La dernière fois que j'ai fait cette manipulation, j'ai utilisé
> gpscorrelate, mais la même opération semble désormais possible avec
> exiftool, en utilisant l'option « -geotag ». D'après ce que j'ai compris
> en lisant la page de manuel d'exiftool, le décalage horaire entre
> l'heure locale stockée dans les photographies et l'heure UTC du GPS est
> automatiquement prise en compte. Avec gpscorrelate, il faut préciser ce
> décalage via l'option « -z ».
> 
Je sais pas d'où tu vas chercher tout ça mais oui c'est possible à faire.
Par contre, quand tu as un Nikon D2X qui est un appareil pro et que tu
sors 200-300 photos en une séance alors je doute que ce soit approprié
ton histoire.

> Cf. https://exiftool.org/geotag.html
> 
> Sébastien
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

HS: Re: GPS, logiciels libres et Debian

[didier gaumet]

Le 11/07/2021 à 15:55, Gaëtan Perrier a écrit :


Ayant eu un Tomtom One V1 (sortie en 2005 de mémoire) les mises à jours de
cartes n'ont pris fin qu'il y a environ 2 ans. Soit bien après la fin de vie
commerciale du produit ...

Gaëtan


Je viens de chercher un peu sur internet, Tomtom ne me semble plus faire 
aujourd'hui mention nulle part de mises à jour à vie. J'ai retrouvé des 
communiqués vers les années 2012 à 2016 puis plus rien. C'était bien la 
vie commerciale de l'appareil qui était mentionnée.
Etant un peu caustique, je me demande si ils ne se sont pas faits taper 
sur les doigts en justice (genre pub mensongère ou clauses abusives)...


Par contre on trouve toujours chez Garmin sur leur site  cette notion de 
mises à jour à vie. Auparavant, il me semblait bien que c'était la vie 
commerciale de l'appareil qui était citée. Aujourd'hui c'est la "Useful 
Life" moins restrictive qui est mise en avant (pour ce point légal; le 
site FR renvoie vers le site US)

https://www.garmin.com/en-US/legal/lmdisclaimer/

C'est pas une charge anti-GPS que je mène, hein: le marché des 
smartphones est adepte de pratiques peu reluisantes, du genre le "so 
trendy" super flagship sorti y a 2 ans, bradé moitié prix 'une affaire, 
vous pouvez pas louper ça!"), dont le constructeur n'assure les MAJ que 
pendant un peu plus de 2 ans. Sauf si t'as pas peur de la vérole, tu 
peux t'en servir 6 mois, quoi... Donc personnellement quand j'achète un 
nouveau smartphone, je cherche sur XDA-developpers un modèle qui possède 
déjà une ROM (OS) alternative ou qui est bien parti pour en bénéficier 
dans un délai raisonnable, ça permet de faire durer ledit smartphone 
plus longtemps dans des conditions de sécurité acceptables.
Sinon t'achètes à leur sortie des smartphones "rugged" bénéficiant de 5 
ans de MAJ pour un prix astronomique :-(

Re: Audacity [was Re: Logiciel pour enregistrer du son]

[Polyna-Maude Racicot-Summerside]

Bonjour,

On 2021-07-11 9:50 a.m., Gaëtan Perrier wrote:
> Le dimanche 11 juillet 2021 à 10:21 +0200, Raphaël POITEVIN a écrit :
>> Audacity, dans sa version encore éthique.
>>
On va rester logique...
Il y a pas de version "non éthique" de Audacity.
Les données de télémétries collectés sont à peu près les mêmes que
celles qu'un site web ramasse via des "cookies".
Puis elles peuvent être éteinte aisément.

En plus, ça concerne une possible version à venir alors rien ne touche
au présent.

On se calme un peu le ponpon.
> 
> Peux-tu préciser, stp ?
> 
> Gaëtan
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: Audacity [was Re: Logiciel pour enregistrer du son]

[Gaëtan Perrier]

Le dimanche 11 juillet 2021 à 18:32 +0200, Jean-Marc a écrit :
> 
> 
> Le 11/07/21 à 15:50, Gaëtan Perrier a écrit :
> > Le dimanche 11 juillet 2021 à 10:21 +0200, Raphaël POITEVIN a écrit :
> > > Audacity, dans sa version encore éthique.
> > > 
> > 
> > Peux-tu préciser, stp ?
> 
> Je suppose que Raphaël parle de ceci :
> https://www.phonandroid.com/audacity-open-source-espionne-utilisateurs.html
> 
> Mais la version Debian est encore "éthique" :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990737
> 
> 

Merci pour l'info. Je n'étais pas au courant. Heureusement que grâce aux
sources on peut retirer la partie incriminée.

Gaëtan


signature.asc
Description: This is a digitally signed message part

Re: GPS, logiciels libres et Debian

[François LE GAD]

Le 11/07/2021 à 16:31, sebastien.di...@free.fr a écrit :

Avec gpscorrelate, il faut préciser ce décalage via l'option « -z ».


On peut aussi utiliser son interface graphique gpscorrelategui.

--
François

Re: Vulkan with Radeon RX 5700 XT

[The Wanderer]

On 2021-07-10 at 17:36, idiotei...@gmail.com wrote:

> Le 10/07/2021 à 17:41, The Wanderer a écrit :
> 
>> On 2021-07-10 at 07:43, tv.deb...@googlemail.com wrote:

>>> Hi, Debian unstable with bits of experimental here (because of the
>>> freeze I pull some newer packages from experimental). Same graphic
>>> card (5700XT), mesa drivers (21.1.4 at this precise moment, from
>>> experimental). Here vulkan works afaik.
>> 
>> For comparison, I have mesa-vulkan-drivers 20.3.4-1, from testing.
>> 
>>> vulkaninfo reports my card as:
>>> "Group 1:
>>>Properties:
>>>  physicalDevices: count = 1
>>>  AMD RADV NAVI10 (ACO) (ID: 0)
>>>  subsetAllocation = 0
>>>Present Capabilities:
>>>  AMD RADV NAVI10 (ACO) (ID: 0):
>>>  Can present images from the following devices: count = 1
>>>  AMD RADV NAVI10 (ACO) (ID: 0)
>>> "
>> 
>> That's excellent news; it means that, at least in principle, this can
>> work in (relatively-)clean Debian as currently constituted. (It also
>> confirms that RADV is the relevant thing here; my reading wasn't
>> conclusive as to whether or not that was specifically something for
>> older card models.)
>> 
>> Can you indicate exactly which Vulkan-related packages you're running
>> from experimental? For that matter, a list of Vulkan-related packages
>> and package versions from unstable too would probably be appropriate,
>> since I track testing and am *highly* hesitant to upgrade against sid
>> wholesale.
> 
> There you go, some packages are at the same version in Testing and 
> Unstable, so you will see them in both.
> 
> "aptitude search '?narrow(?installed,?archive(experimental))' | egrep 
> '(mesa|vulkan)'
> 
> i A libegl-mesa0 - free implementation of the EGL API -- Mesa vendor library
> i  libegl-mesa0:i386 - free implementation of the EGL API -- Mesa vendor 
> library
> i  libegl1-mesa:i386 - transitional dummy package
> i A libgl1-mesa-dri - free implementation of the OpenGL API -- DRI modules
> i A libgl1-mesa-dri:i386 - free implementation of the OpenGL API -- DRI 
> modules
> i A libgl1-mesa-glx - transitional dummy package
> i A libglapi-mesa - free implementation of the GL API -- shared library
> i A libglapi-mesa:i386 - free implementation of the GL API -- shared library
> i A libglx-mesa0 - free implementation of the OpenGL API -- GLX vendor 
> library
> i A libglx-mesa0:i386 - free implementation of the OpenGL API -- GLX 
> vendor library
> i A libosmesa6 - Mesa Off-screen rendering extension
> i A libosmesa6:i386 - Mesa Off-screen rendering extension
> i  mesa-opencl-icd - free implementation of the OpenCL API -- ICD runtime
> i A mesa-va-drivers - Mesa VA-API video acceleration drivers
> i A mesa-vdpau-drivers - Mesa VDPAU video acceleration drivers
> i  mesa-vulkan-drivers - Mesa Vulkan graphics drivers
> i  mesa-vulkan-drivers:i386 - Mesa Vulkan graphics drivers

I now have all of these (except the dummy packages, which I skipped as
irrelevant) installed from experimental. All the ones you listed from
unstable seem to be at the same version in testing, and have no
available version in experimental, so there's nothing to upgrade there.

I've also gone so far as to upgrade my kernel to the one in experimental
(it was only a Debian-packaging version upgrade: 5.10.0-7 to 5.10.0-8).

The results, so far, are exactly the same as before: vulkaninfo reports
only one "device", llvmpipe / lavapipe.

I haven't gone so far as to upgrade the firmware-amd-graphics package to
the one in experimental; the version number indicates that it's only one
week newer than the one in testing (March 22nd rather than March 15th),
which seems unlikely to make a difference. I'd be curious to know which
of the two you've got installed, regardless.

I've at least managed to confirm even more strongly than before that
amdgpu does seem to be in use; not only is it referenced as loaded in
dmesg, it appears prominently in /var/log/Xorg.0.log (where several
other video drivers are tried, including radeon, and all the others seem
to get unloaded while AMDGPU references continue to appear afterwards).

Yet for sone reason, Vulkan is still failing to detect the presence of
any physical GPU.


I've gone so far as to build vulkaninfo locally, and have gone digging
through the sources looking to figure out how it does detection. What
seems to happen is that it calls vkEnumeratePhysicalDevices() on an
instance of AppInstance; I've tracked that back through the mesa sources
as far as device_select_layer.c, but been unable to identify where the
relevant code in the tangle of that file gets the data from.

I think at this point I probably need to report an issue with Mesa
upstream, and see if they can at least advise me on how to troubleshoot
it further. Hopefully the fact that I'm now mixing package versions
between Mesa 20.x (a few -dev packages, at least, are still on that) and
21.x (the ones listed above) won't be an issue...

I'm unhappy about having to 

Re: Audacity [was Re: Logiciel pour enregistrer du son]

[Jean-Marc]

Le 11/07/21 à 15:50, Gaëtan Perrier a écrit :

Le dimanche 11 juillet 2021 à 10:21 +0200, Raphaël POITEVIN a écrit :

Audacity, dans sa version encore éthique.



Peux-tu préciser, stp ?


Je suppose que Raphaël parle de ceci :
https://www.phonandroid.com/audacity-open-source-espionne-utilisateurs.html

Mais la version Debian est encore "éthique" :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990737


Gaëtan



--
Jean-Marc



OpenPGP_signature
Description: OpenPGP digital signature

Re: Cool down... [was: Buster no release file]

[Gene Heskett]

On Sunday 11 July 2021 08:29:52 to...@tuxteam.de wrote:

> On Sun, Jul 11, 2021 at 01:05:44PM +0100, mick crane wrote:
> > On 2021-07-11 12:01, to...@tuxteam.de wrote:
>
> [...]
>
> > >So please, pretty please: calm down :)
> >
> > You are correct, I have no idea of the individuals.
>
> Thanks :)
>
> > Guess I am overwhelmed by the turn society has taken.
>
> Who is not. Life's always beeen outrageous (I'm an old guy, believe me
> :)
>
> I think the art is to use that ourtrage to try to change things,
> instead of slinging it at one's co-humans (who might themselves be
> outraged, but from a different POV and thusly for different reasons).
> Not that *I* manage as I wish I did...

Me too Tomas, and I think I have at least a decade on you, if I don't get 
shot for refusing the shot, I'll be 87 in early October. I found a daily 
St. Johns Wort in my pilltainer helps to tame the raging bull in me. But 
not enough to make me take back what I didn't sell. :)

> > Next we will be banning variable names for being inappropriate.

Already happening, sorry to say.

> I'm sure that happens somewhere, some time. OTOH, worse things happen,
> too. Someone is being murdered right now. Kids are starving, deprived
> of schooling, being abused of or forced to work. Lotsa things to do!

Most of the above is mans own inhumanity to man, but being forced to work 
is not necessarily abuse, it was the rule in the house I grew up in with 
a stepfather, who was first an honest man and taught me by example in 
that dept, so one of the rules was I went to school or I got a job. I 
helped him build a house on a cut off corner of a field my grandfather 
gave us in the aftermath of WW_II in 1946, and at 12 years old, I wired 
that house for electricity.  And when I turned 21 and could, I thought 
enough of the man who raised me to change my name to match his. That is 
respect. And it didn't cost an arm and leg for the adoption papers which 
in Iowa, are a legal racket for the lawyers.

> Cheers

Back at-cha Tomas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: apache2-doc update enables disabled conf

[David Wright]

On Sat 10 Jul 2021 at 23:46:32 (+0200), Michael wrote:
> On Saturday, July 10, 2021 10:26:03 PM CEST, David Wright wrote:
> > I can't yet understand what you have done here.
> 
> all i did was an apt-get -V dist-upgrade
> 
> 
> > AIUI a2disconf
> > removes symlinks in /etc/apache2/conf-enabled/ that were previously
> > created there by a2enconf.
> 
> that's correct
> 
> 
> > OTOH, apache2-doc.conf is a pkg-provided conffile in
> > /etc/apache2/conf-available/. During an upgrade, it will be
> > automatically upgraded if it hasn't been altered. If you've
> > altered it, then there's usually a dialogue presented about
> > what to do¹.
> 
> afaik this applies only to 'real' config files, like the ones like
> /etc/apache/apache2.conf. apache2 configuration files in /etc/conf-*
> are probably considered different.

My post is out-of-date, in that /var/lib/dpkg/info/apache2-doc.conffiles
is now ignored in favour of debhelper commands, which I'm not
conversant with. However, AFAIK there is only one category of
conffile as far as APT is concerned.

> i never altered this config file (or any other of those)! why should
> i? if i need this file to be changed, i disable it with a2disconf (or
> remove the symlink in /etc/conf-enabled/ myself), copy the source in
> /etc/apache2/conf-available/ and change the copy. i never touch
> original package files if there is a way to circumvent it.
> 
> > But in any case, that's nothing to do with
> > symlinks in /etc/apache2/conf-enabled/.
> 
> agreed.
> 
> > A more specific description of the symptoms might help.
> 
> well, here is what '/var/log/apt/term.log' sais:
> Log started: 2021-07-09  09:01:44
> (Reading database ... ^M(Reading database ... 5%^M(Reading database
> ... 10%^M(Reading database ... 15%^M(Reading database ...
> 20%^M(Reading database ... 25%^M(Reading database ... 30%^M(Reading
> database ... 35%^M(Reading database ... 40%^M(Reading database ...
> 45%^M(Reading database ... 50%^M(Reading database ... 55%^M(Reading
> database ... 60%^M(Reading database ... 65%^M(Reading database ...
> 70%^M(Reading database ... 75%^M(Reading database ... 80%^M(Reading
> database ... 85%^M(Reading database ... 90%^M(Reading database ...
> 95%^M(Reading database ... 100%^M(Reading database ... 41615 files and
> directories currently installed.)
> Preparing to unpack .../apache2_2.4.38-3+deb10u5_amd64.deb ...
> Unpacking apache2 (2.4.38-3+deb10u5) over (2.4.38-3+deb10u4) ...
> Preparing to unpack .../apache2-bin_2.4.38-3+deb10u5_amd64.deb ...
> Unpacking apache2-bin (2.4.38-3+deb10u5) over (2.4.38-3+deb10u4) ...
> Preparing to unpack .../apache2-data_2.4.38-3+deb10u5_all.deb ...
> Unpacking apache2-data (2.4.38-3+deb10u5) over (2.4.38-3+deb10u4) ...
> Preparing to unpack .../apache2-utils_2.4.38-3+deb10u5_amd64.deb ...
> Unpacking apache2-utils (2.4.38-3+deb10u5) over (2.4.38-3+deb10u4) ...
> Preparing to unpack .../apache2-doc_2.4.38-3+deb10u5_all.deb ...
> Unpacking apache2-doc (2.4.38-3+deb10u5) over (2.4.38-3+deb10u4) ...
> Setting up apache2-bin (2.4.38-3+deb10u5) ...
> Setting up apache2-doc (2.4.38-3+deb10u5) ...
> Package apache2 is not configured yet. Will defer actions by package
> apache2-doc.
> Setting up apache2-data (2.4.38-3+deb10u5) ...
> Setting up apache2-utils (2.4.38-3+deb10u5) ...
> Setting up apache2 (2.4.38-3+deb10u5) ...
> info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc
> Enabling conf apache2-doc.
> Processing triggers for man-db (2.8.5-2) ...
> Processing triggers for systemd (241-7~deb10u7) ...
> Log ended: 2021-07-09  09:02:06
> 
> please recognize the lines that say:
> 
>  info: Executing deferred 'a2enconf apache2-doc' for package apache2-doc
>  Enabling conf apache2-doc.
> 
> this tells me that apt-get enables the configuration file although i
> disabled it on purpose.

Yes. Glancing at the scripts in /var/lib/dpkg/info/apache2-doc*,
it's not clear to me where the current enabled-state is retained.
I would've thought it necessary to run a2query before upgrading,
to find out whether to run a2enconf on each element. AFAICT
the deferred 'a2enconf apache2-doc' should not be run unless there's
a symlink in conf-enabled/ (and on fresh installation, of course).
It looks like a bug that resembles #977014, but which should be
at normal level rather than wishlist.

> fwiw: i think 'configuration files' in apache2 are not the same as the
> configuration files of packages you probably thought of (and are right
> about).

Logically, I'd agree that they operate in different ways, but AFAICT
APT sees them as the one category: conffiles.

And that suggests a workaround: Put # at the beginning of each line
in /etc/apache2/conf-available/apache2-doc.conf. Having done this,
'a2enconf apache2-doc' is effectively impotent, and any upgrade
should invoke the dialogue I posted earlier, to which you can reply
N (keep your installed version).

[Note to self: read up on debhelper, and treat
/var/lib/dpkg/info/*conffiles with due circumspection.]

Re: How do I get back the GRUB menu with the blue background?

[David Wright]

On Sat 10 Jul 2021 at 11:13:31 (+0200), Stella Ashburne wrote:
> Sent: Monday, July 05, 2021 at 4:52 AM
> From: "David Wright" 
> > 
> > I find the Grub installation prompts in the d-i very confusing.
> > I'm wondering whether your process incorrectly updated grub.cfg
> > in the ESP on the SSD.
> > 
> 
> I suspected it too because when I installed Debian Testing, I didn't delete 
> both the ESP and /boot partitions that were created by Debian Buster. As a 
> result, after installing Debian Testing successfully and rebooting my 
> machine, there was no blue GRUB menu.
> 
> > Bear in mind there are two grub.cfg files.
> 
> Where are their locations?

They were in the command lines, viz:

# cat /boot/efi/EFI/debian/grub.cfg

# head /boot/grub/grub.cfg

These are the locations as seen by root in a running system (mine).

> > The
> > second one is the familiar one, so I just give the head:
> > 
> > # cat /boot/efi/EFI/debian/grub.cfg
 ↑ this is the first one ↑ (your snipping is somewhat brutal)
> 
> When I issued the above command at the grub> prompt, the response was 'file 
> /boot/efi/EFI/debian/grub.cfg' not found.

That's because you have to tell Grub where to look. A running system
has the /boot partition mounted (obviously) at →/boot←, and the ESP
partition mounted (less obviously) at →/boot/efi←. But Grub has
to be told to look in the appropriate →partition← for each file,
so you'd need something like:

grub> cat (hd0,gpt1)/efi/debian/grub.cfg

and

grub> cat (hd0,gpt2)/grub/grub.cfg

So you have to navigate to it yourself, like:

grub> ls (hd0,gpt2)/
efi/

grub> ls (hd0,gpt2)/efi/
debian/

grub> ls (hd0,gpt2)/efi/debian/
grub.cfg

grub> cat (hd0,gpt2)/efi/debian/grub.cfg
search.fs_uuid f3bf6eef-3c26-4070-b180-fd1914377253 root hd0,gpt4
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

grub> 

and this is what I called the "first" grub.cfg, exactly equivalent to:

# cat /boot/efi/EFI/debian/grub.cfg
search.fs_uuid f3bf6eef-3c26-4070-b180-fd1914377253 root hd0,gpt4
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
# 

on the running system. (AIUI the change in case of efi/EFI is caused
by the options chosen for mounting the vfat filesystem.)

> > (I only encrypt /[h]ome and swap.) I'm wondering whether your first
> > grub.cfg is pointing to the USB stick that you used in the
> > installation. That would be simple to check.
> 
> No.

If you /know/ the answer is "no", then you must know where it /does/ point.

> If you're using UEFI and the partition table scheme is gpt, Debian 10's 
> installer detects that your SSD is using EFI, there's a message on the screen 
> that asks "Force EFI installation to a removable media? Yes or No". My 
> response is always "No".

"If A, then B" does not show "If B, then A". One of the bizarre things
about the d-i is that it still presents that screen when BIOS/MBR
installing on a Pentium III built in 2000. That particular screen is
part of the reason I wrote earlier:
  > > I find the Grub installation prompts in the d-i very confusing.

> > If this guess, is correct, it might be possible to confirm it
> > if you get these symptoms:
> > 
> > . Booting with the internal drive only: GRUB> prompt.
> > . Booting with the USB stick inserted: something else appears,
> >   a blue Grub menu, or a Debian installer splash screen,
> >   or even Windows.
> 
> I did what you suggested by first inserting the USB stick that contains 
> Debian 10's installer and booting up my machine. There's no blue GRUB menu, 
> whatsoever
> 
> > 
> > Of course, the second scenario can only work if the USB's UUID
> > hasn't been recreated by further uses.
> 
> Yes, I'm aware of that fact

I mentioned it only because /you/ know what's been done with your
system, sticks, and everything else in your universe, whereas every
other reader of this post does not. So when you eventually use Grub's
introspective abilities to find out which ESP was used and where it
pointed, that's a factor in interpreting the result: it might point
to nowhere now.

> > ¹ With encrypted systems, you have to bear in mind what can be seen
> >   outside and inside the container. This is easy to distinguish
> >   with only /home encrypted, as you can inspect things with the
> >   normal system tools.
> 
> My LUKS-encrypted partition consists of / and swap area. I assume the / 
> contains /home, /var, /usr, etc...

It would be nice to give you a set of Grub commands to manually
boot your system with, so that you could fix up the Grub
configuration.

However, two things put that beyond my capabilities: encrypted
root, and "logical volumes".

As you $prefix was correct, I would start with:

grub> insmod part_gpt
grub> insmod ext2

but I'd guess you also require at least:

grub> insmod crypto
grub> insmod cryptodisk
grub> insmod luks
grub> insmod lvm

Grub needs to find the kernel and initrd, and this should work
as they're on a simple unencypted partition:

grub> set root=(hd0,gpt2)

Now /I/ would be 

Re: Didn't mean to derail (Vulkan with Radeon RX 5700 XT)

[Nicholas Geovanis]

On Sat, Jul 10, 2021, 9:53 AM Eike Lantzsch ZP6CGE  wrote:

> On Samstag, 10. Juli 2021 09:13:57 -04 Brian Thompson wrote:
> > On Sat, 2021-07-10 at 14:57 +0200, tv.deb...@googlemail.com wrote:
> > > This is not the point of the OP message, so let's not derail
> >
> > I apologize for accidentally derailing.  I should have started a new
> > thread. I'm still relatively new to the Debian community.
>
> No problem - AMTRAK always derails and still runs. If it is a matter of
> tracks or a matter of running stock or a matter of cars or trucks
> passing level passings with lights flashing is a moot question.
>

Moot :-)
Amtrak derails because it doesn't own the rails it runs on. Except in the
northeast corridor.
And the major railroads favor their traffic over Amtrak's.

People here on debian-user use to derail all the time.
> q.e.d.
> Eike
>
> --
> Eike Lantzsch ZP6CGE
>
>
>
>

Re: GPS, logiciels libres et Debian

[sebastien . dinot]

Le 2021-07-09 18:11, Polyna-Maude Racicot-Summerside a écrit :

Il y a quelques temps j'ai eu besoin d'un GPS pour mon appareil photo.
Comme c'est un vieux modèle, il fonctionnait via port série.


Il n'est pas nécessaire d'avoir un GPS couplé à l'appareil photo. Il est 
aussi possible de :


1. Photographier à un moment quelconque de la balade l'écran du GPS 
montrant l'heure à la seconde près, puis de retour à la maison, de 
comparer l'heure affichée par le GPS sur la photo et l'heure indiquée 
dans les métadonnées de la photo pour déterminer le décalage horaire 
entre le GPS et l'appareil photo.


2. Une fois cet écart déterminé, il est possible de recaler l'heure de 
création enregistrée dans les photographies avec exiftool. Par exemple, 
si on découvre que l'horloge de l'appareil photo avait un retard de 
4m12s, on exécute la commande : exiftool "-alldates+=0:4:12" *.jpg


3. L'injection des coordonnées GPS dans les photographies est alors 
possible en s'appuyant sur la trace GPX du GPS (l'outil calculant la 
position par interpolation horaire des positions enregistrées dans la 
trace). La dernière fois que j'ai fait cette manipulation, j'ai utilisé 
gpscorrelate, mais la même opération semble désormais possible avec 
exiftool, en utilisant l'option « -geotag ». D'après ce que j'ai compris 
en lisant la page de manuel d'exiftool, le décalage horaire entre 
l'heure locale stockée dans les photographies et l'heure UTC du GPS est 
automatiquement prise en compte. Avec gpscorrelate, il faut préciser ce 
décalage via l'option « -z ».


Cf. https://exiftool.org/geotag.html

Sébastien

Re: GPS, logiciels libres et Debian

[Gaëtan Perrier]

Le vendredi 09 juillet 2021 à 21:05 +0200, sebastien.di...@free.fr a écrit :
> 
> Quant à moi, je préfère conserver à mon smartphone ses fonctions de 
> téléphone et de point d'accès wifi. En randonnée, il est au fond de nom 
> sac, à l'abri des éléments. Et mon Etrex 30 a une autonomie bien plus 
> importante que mon smartphone quand j'active le GPS et je lance Osmand.
> 

Je partage ton avis. Le smartphone a l'avantage de son grand écran pour la
consultation des cartes mais pour le reste je préfère un GPS de rando dédié qui
est bien plus pratique à l'usage:
- tenue en main très supérieure, un smartphone glisse trop facilement de la
main (l'écran d'un de mes smartphones n'y a pas survécu),
- le smartphone contenant beaucoup de données sensibles le mien est toujours
verrouillé. Très pénible quand on veut consulter rapidement.
- l'autonomie avec le GPS actif en permanence est supérieure sur les GPS
dédiés,
- les écrans des GPS dédiés sont plus lisibles en plein soleil

Perso j'utilise un Twonav Cross qui malgré sa compacité a un écran sublime.

Gaëtan



signature.asc
Description: This is a digitally signed message part

Re: GPS, logiciels libres et Debian

[Gaëtan Perrier]

Le vendredi 09 juillet 2021 à 15:09 +0200, didier gaumet a écrit :
> 
> Inconvénient supplémentaire du GPS dédié, au moins chez Tomtom mais je 
> pense que c'est pareil ailleurs: les "mises à jour à vie" sont une 
> tromperie sémantique car il s'agit de la vie commerciale de l'appareil 
> (t'achètes ton GPS aujourd'hui? Si dans 6 mois le constructeur arrête la 
> vente de ce modèle, t'es refait)
> 

Ayant eu un Tomtom One V1 (sortie en 2005 de mémoire) les mises à jours de
cartes n'ont pris fin qu'il y a environ 2 ans. Soit bien après la fin de vie
commerciale du produit ...

Gaëtan


signature.asc
Description: This is a digitally signed message part

Audacity [was Re: Logiciel pour enregistrer du son]

[Gaëtan Perrier]

Le dimanche 11 juillet 2021 à 10:21 +0200, Raphaël POITEVIN a écrit :
> Audacity, dans sa version encore éthique.
> 

Peux-tu préciser, stp ?

Gaëtan


signature.asc
Description: This is a digitally signed message part

[Résolu] Logiciel pour enregistrer du son

[benoit]

Un tout grand merci pour vos réponses.

Je viens de tester gnome-sound-recorder, il fait très simplement ce que j'en 
attends.

--
Benoit

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

Le dimanche 11 juillet 2021 à 12:22, didier gaumet  a 
écrit :

> Bonjour,
>
> *
>
> quelques éléments auquels je pense:
>
> comme suggéré par Hamster, gnome-sound-recorder est un logiciel très
>
> simple qui devrait correspondre à ce que tu cherches
>
> "Interneal Mic boost" n'est pas une fonction de coupure du micro interne
>
> mais est une fonction de sur-amplification du signal du micro interne
>
> (souvent de qualité médiocre, donc qui demande à être sur-amplifié).
>
> Quand tu mets cette fonction à zéro, tu désactives donc uniquement la
>
> sur-amplification de ce microphone intégré, pas le micro lui-même.
>
> Assure-toi préalablement à l'enregistrement que ton microphone externe
>
> est compatible avec ta carte son intégrée (en termes de prises et de
>
> niveau et impédance). Il est parfois nécessaire de recourir à une
>
> "interface audio" comportant un préamplificateur microphone de meilleure
>
> qualité que ce qu'on trouve dans un PC. Un microphone de type
>
> omnidirectionnel (qui capte le son dans toutes les directions, sinon
>
> seuls seront audibles les sons émis en face du micro) me semble
>
> nécessaire pour ce que tu veux faire
>
> D'autre part, si tu utilises un environnement de bureau (
>
> Gnome, KDE (plasma), Xfce, LXQT, LXDE et autres), il y a des chances que
>
> celui-ci utilise Pulseaudio et non Alsa directement: utilise alors le
>
> mixer (mélangeur audio) de ton environnement de bureau plutôt qu'un
>
> outil Alsa séparé.
>
> Je te suggère de faire des essais avant ta réunion :-)
>
> PS: pour Audacity, 2 articles qui illustrent l'apparition du problème
>
> puis le dégonflement de la crise:
>
> https://www.01net.com/actualites/comment-audacity-logiciel-audio-open-source-repute-est-devenu-un-possible-spyware-2045643.html
>
> https://www.futura-sciences.com/tech/actualites/informatique-audacity-il-devenu-spyware-92385/

Re: Cool down... [was: Buster no release file]

[tomas]

On Sun, Jul 11, 2021 at 01:05:44PM +0100, mick crane wrote:
> On 2021-07-11 12:01, to...@tuxteam.de wrote:

[...]

> >So please, pretty please: calm down :)
> 
> You are correct, I have no idea of the individuals.

Thanks :)

> Guess I am overwhelmed by the turn society has taken.

Who is not. Life's always beeen outrageous (I'm an old guy, believe me :)

I think the art is to use that ourtrage to try to change things, instead
of slinging it at one's co-humans (who might themselves be outraged, but
from a different POV and thusly for different reasons). Not that *I*
manage as I wish I did...

> Next we will be banning variable names for being inappropriate.

I'm sure that happens somewhere, some time. OTOH, worse things happen,
too. Someone is being murdered right now. Kids are starving, deprived
of schooling, being abused of or forced to work. Lotsa things to do!

Cheers
 - t


signature.asc
Description: Digital signature

Re: servidor em notebook e desligamento da tela

[Thiago Pezzo (tico)]

Humberto, já tive que lidar com isso e a solução que encontrei foi alterar as
opções do kernel na inicialização::

 1. Como root, editar: /etc/default/grub

 2. Inserir a opção para desligar a tela (em segundos):
GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=600″

 3. Atualizar o grub: update-grub

Abraços,
Thiago Pezzo (Tico)

July 10, 2021 5:25 PM, "Humberto A. Sousa"  wrote:

> José,
> 
> Essas configurações estão normalmente no setup do notebook.
> Frequentemente há também a opção de desabilitar o vídeo com uma combinação de 
> teclas, daí você
> desliga e liga quando precisar.
> 
> Saudações,
> 
> Humberto Araujo de Sousa
> humbe...@dontec.com.br
> https://mars.nasa.gov/layout/embed/send-your-name/mars2020/certificate/?cn=57592057281
> 
> Em 06/07/2021 23:51, José Figueiredo escreveu:
> 
>> Pessoal, boa noite.
>> Fiz um servidor, usando Debian 10 em um notebook antigo que tenho - a > 
>> instalação está ultra limpa
>> - apenas a instalação do netinstall com um > acesso SSH.
>> A dificuldade está em que a tela fica 100% do tempo ligada, o que é > inútil 
>> pois faço todo acesso
>> remotamente. Gostaria de dicas de como > desativar a tela - tipo descanso de 
>> tela em modo texto.
>> Não tenho servidor X instalado nessa máquina.
>> Estou pesquisando há alguns dias e não consegui encontrar uma solução.
>> Grato.
>> -- > José de Figueiredo
>> Seja Livre, use GNU/Linux. Use Debian !!!
>> 
>> Antes de autorizar um aborto, pense que poderia ser vc lá dentro,
>> esperando alguém decidir se vc morre ou não...
>> http://www.brasilsemaborto.com.br 
>> 
>> Venha estudar no IFSul - é público, federal e de qualidade.

Re: Cool down... [was: Buster no release file]

[mick crane]

On 2021-07-11 12:01, to...@tuxteam.de wrote:

On Sun, Jul 11, 2021 at 10:18:37AM +0100, mick crane wrote:

On 2021-07-10 23:44, Greg Wooledge wrote:

>I *REALLY* and truly hate assholes like that.
control freaks are the biggest problem facing society today.


Now calling someone "asshole" in public is rather extreme; I can fully
understand Greg's anger, but still.

Mass-jumping on someone without having even tried to contact him 
(perhaps
it was a stupid misunderstanding, a brain fart, a fat finger or 
something

my fantasy fails to come up with right now)... well, I hope that's not
the style around here. Perhaps Twwatty or Fakebook (or whatsitiscalled)
provide that kind of thrill.

So please, pretty please: calm down :)


You are correct, I have no idea of the individuals.
Guess I am overwhelmed by the turn society has taken.
Next we will be banning variable names for being inappropriate.
mick
--
Key ID4BFEBB31

Re: Buster no release file

[Andrew M.A. Cater]

On Sun, Jul 11, 2021 at 10:18:37AM +0100, mick crane wrote:
> On 2021-07-10 23:44, Greg Wooledge wrote:
> 
> > I *REALLY* and truly hate assholes like that.
> control freaks are the biggest problem facing society today.
> mick
> -- 
> Key ID4BFEBB31
> 

Folks,

Rather than call people assholes and control freaks: please look at the local
context. Bullseye - Debian 11 - is potentially to be released in three weeks.

There's an amount of wiki gardening going on to tidy up, get translations
sorted, update pages.  When Bullseye comes along, Buster drops to oldstable 
and another year or so of support, Stretch drops to oldoldstable and support 
by the LTS team and so it goes. The wiki is always in flux, some of it out 
of date, much of it needing revision: if you wanted, you could get an account 
yourselves. 

Elsewhere in the Debin wiki - under SourcesList - which is a logical place,
maybe, https://wiki.debian.org/SourcesList i a complete sources list for 
buster which also explains clearly how to add contrib and non-free if you
need them. I'm guessing that will be replaced in due course for one for
Bullseye. NOTE WELL: There is a change in format for the security sources
in Bullseye which is well covered in the draft release notes and elsewhere.

Respect goes all around - easily upwards to some people who have been around 
longer/may know more/ are helpful/give good advice, are friendly, downwards 
to people who may know less than you/whom you can help and sideways to your 
peers. At any given time, each of you occupies one or more of those positions 
for the others around you on this list and inside/outside Debian.

Try to be maybe a bit more thoughtful as to the effect such posts have?

All the very best, as ever,

Andy Cater

Cool down... [was: Buster no release file]

[tomas]

On Sun, Jul 11, 2021 at 10:18:37AM +0100, mick crane wrote:
> On 2021-07-10 23:44, Greg Wooledge wrote:
> 
> >I *REALLY* and truly hate assholes like that.
> control freaks are the biggest problem facing society today.

Now calling someone "asshole" in public is rather extreme; I can fully
understand Greg's anger, but still.

Mass-jumping on someone without having even tried to contact him (perhaps
it was a stupid misunderstanding, a brain fart, a fat finger or something
my fantasy fails to come up with right now)... well, I hope that's not
the style around here. Perhaps Twwatty or Fakebook (or whatsitiscalled)
provide that kind of thrill.

So please, pretty please: calm down :)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[The Wanderer]

On 2021-07-11 at 03:31, Andrei POPESCU wrote:

> On Sb, 10 iul 21, 14:38:39, The Wanderer wrote:
> 
>> On 2021-07-10 at 14:18, Andrei POPESCU wrote:

>>> It depends :)
>>> 
>>> In my opinion I'd say the order from less to more dangerous
>>> would be:
>>> 
>>> 1. stable + select packages from stable-backports
>> 
>>> 2. oldstable + select packages from oldstable-backports-sloppy
>> 
>>> 3. testing + select packages from unstable
>> 
>>> 4. unstable + select packages from experimental
>> 
>> I'm a little surprised to see that you don't even mention the mix
>> which I've been running for the last decade-plus: stable + testing,
>> which works out to testing + select packages from stable (the ones
>> which are no longer available in testing).
>> 
>> Do you consider that to be so dangerous as to not even be worth
>> mentioning?
> 
> What I forgot to mention was that outside the common scenarios above
> you are pretty much on your own and you should have a good
> understanding of APT priorities and pinning (or be prepared to deal
> with problems).
> 
> The danger level also varies greatly on which is your "main"
> release.
> 
> While your testing + stable as needed mix is pretty simple[1] the 
> reverse mix stable + select packages from testing requires adequate 
> pinning and can quickly become problematic for anything but the
> simplest packages packages (no or very few dependencies) pulled from
> testing.

I can see how it could become an issue for someone who's trying to stick
mainly with stable, but that's never been my goal. As soon as you
dist-upgrade against the combination of testing and stable, you're
primarily on testing, with stable present only as an "in case of
removal" backstop.

> You should be using -backports instead or backport packages yourself
> if necessary[2].

I hope this is general/generic "you", and not directed at me
specifically. I first read this as chiding me against running this mix,
and that came across as mildly offensive.

> [1] No pinning required, unless you want to have *very* good control
>  over what you install from stable. A similar reasonably safe and
> easy setup is unstable + testing as needed, which is probably a good
> idea anyway, even if not well documented.

I used to track testing + unstable, which worked out to unstable +
select packages from testing.

That's the setup which blew up under my feet into an inconsistent,
unrepairable Debian installation, as I've mentioned elsewhere in this
thread.

However, I do not blame that on the fact of running a combination of
suites. I blame it on the fact of tracking unstable at all.

I absolutely do not recommend tracking sid on a production system, ever.
Installing specific packages from sid, carefully and only as needed, is
one thing; dist-upgrade against sid is something I very strongly
recommend against.

-- 
   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

Re: Vulkan with Radeon RX 5700 XT

[The Wanderer]

On 2021-07-11 at 04:45, Alexander V. Makartsev wrote:

> On 10.07.2021 20:54, The Wanderer wrote:
> 
>> I had enough times when I couldn't launch X (at least not with any 
>> acceleration at all, even 2D acceleration) because an updated
>> NVIDIA driver which was compatible with the new X or kernel version
>> hadn't been released yet, and enough troubles trying to switch
>> drivers etc. and remnants left over on the computer afterwards,
>> that it left me with an antipathy towards using NVIDIA products.
>> 
>> The fact that NVIDIA's Linux support implementation is proprietary
>> is both the reason for those problems, and an entirely separate
>> reason why I decided that until that fact changes, I will never
>> voluntarily buy an NVIDIA card for a Linux system.
> 
> I often read about problems with nvidia drivers others are having,
> but personally I haven't experienced anything like you described.
> 
> Probably because these kinds of problems only surface on platforms
> with Nvidia-Optimus technology, which every OEM out there making it
> in their unique way.

If I recall correctly,the time when I used an NVIDIA card was before the
name "Optimus" had been coined. It certainly wasn't involved in the
platform I was using at the time.

> The only thing I do after installing an updated kernel is rebuild
> DKMS module by reinstalling "nvidia-kernel-dkms" package, to ensure
> it would be build using current kernel sources.

What about an updated X?

I suppose that problem could just not happen anymore, because X is
seeing so much slower a pace of development (to the point where I think
I understand that it's basically considered end-of-life, or at least
minimal maintenance-only, by X.org)...

>> As I understand matters, this is another consequence of the fact
>> that the NVIDIA driver (stack) is proprietary - or rather, the only
>> reason why there's an nvidia-driver package is because it's not
>> practical (or necessarily even possible) to provide that
>> functionality in a more integrated way, because of the proprietary
>> and opaque way the NVIDIA drivers etc. are provided. In an ideal
>> world, no such explicit separate package(s) would be needed.
> 
> It is the matter of convenience, because nvidia drivers, even legacy
>  ones, are in official Debian repos.

You're still talking about the proprietary binary driver and its related
software (e.g. the GL/GLX stack), right?

Yes, of course those are in Debian repos (though last I checked they
were all, or nearly all, in non-free). The fact that they're
proprietary, however, means that they *have* to be packaged separately
et cetera, rather than being able to be integrated; that naturally leads
to a separate install-it-all-at-once metapackage. With a non-proprietary
driver and stack, AMDGPU (and, to perhaps a lesser extent, the legacy
Radeon drivers) are susceptible of being better integrated, so the need
for such a metapackage is less.

I'm not looking at that, however. I'm not interested in using the
proprietary implementation unless there's absolutely no other option. If
I were to fall back on the official download-from-AMD driver stack, I
would be using the "All Open" one, not the "Pro" version, specifically
because the "Pro" version is apparently at least partly proprietary.

If that version wouldn't get me Vulkan support after all, then there's
even less reason for me to try using it.

> And installation of them is as easy as "apt install nvidia-driver",
> plus supplementary libraries like GL/GLX, EGL, GLES, OpenCL, VA,
> VDPAU, Vulkan, etc, all could be found by searching "nvidia-*"
> 
> Internally, by the looks of it, AMD drivers and Nvidia drivers look
> the same. Both of them consist of DKMS kernel module building suite,

The AMDGPU kernel drivers don't need DKMS, because they're open; they
can be, and are, built and shipped with the kernel.

> XOrg modules\extensions and all necessary libraries I've already
> mentioned. I don't see any complications or barriers (other than
> maybe licensing) that prevent creation of "amdgpu-driver" metapackage
> and naming all other necessary packages "something-amdgpu-something"
> and "amdgpu-driver-something", in the same way nvidia drivers are
> made in Debian repos.

Certainly, nothing prevents it. There's just less need for it, so
apparently no one has bothered to do it yet.

>> I'll take this under advisement; at the very least, it's my
>> fallback if other investigations don't produce any usable results.
>> The examination of those packages and the results they provide is
>> appreciated.
> 
> I should've mentioned about official instructions for amdgpu driver. 
> They seem to distinguish between two stacks of drivers [1] and 
> "All-Open" doesn't have Vulkan in it.

As I understand matters, that's not necessarily correct. If you look at
the page you linked to, the "Pro" stack includes "Pro Vulkan"; that does
*not* necessarily mean that the open stack does not include Vulkan at
all, just that it doesn't have 

Re: Vulkan with Radeon RX 5700 XT

[tv.deb...@googlemail.com]

Le 11/07/2021 à 01:10, The Wanderer a écrit :

On 2021-07-10 at 19:08, The Wanderer wrote:


On 2021-07-10 at 17:36, idiotei...@gmail.com wrote:



There you go, some packages are at the same version in Testing and
  Unstable, so you will see them in both.


(Just to confirm, are you the person who responded above under the
name Brian Thompson and with the E-mail address
tv.deb...@googlemail.com? Because the E-mail address is different,
and I don't want to make assumptions in either direction.)


Argh. I checked this three times, and still managed to misread my
previous-mails list. The above name and E-mail address correspond to
different people; they're clearly not both you.

Sorry, my bad, I answered from a different device and screwed-up the 
"from" field. It's an old address I retired when some unsavory (to my 
taste) people adopted close enough aliases that I started getting 
abusive or threatening messages that even gmail spam filter couldn't 
parse...

But Brian is a completely different person.

Re: Logiciel pour enregistrer du son

[didier gaumet]

Bonjour,
*
quelques éléments auquels je pense:

comme suggéré par Hamster, gnome-sound-recorder est un logiciel très 
simple qui devrait correspondre à ce que tu cherches


"Interneal Mic boost" n'est pas une fonction de coupure du micro interne 
mais est une fonction de sur-amplification du signal du micro interne 
(souvent de qualité médiocre, donc qui demande à être sur-amplifié). 
Quand tu mets cette fonction à zéro, tu désactives donc uniquement la 
sur-amplification de ce microphone intégré, pas le micro lui-même.


Assure-toi préalablement à l'enregistrement que ton microphone externe 
est compatible avec ta carte son intégrée (en termes de prises et de 
niveau et impédance). Il est parfois nécessaire de recourir à une 
"interface audio" comportant un préamplificateur microphone de meilleure 
qualité que ce qu'on trouve dans un PC. Un microphone de type 
omnidirectionnel (qui capte le son dans toutes les directions, sinon 
seuls seront audibles les sons émis en face du micro) me semble 
nécessaire pour ce que tu veux faire


D'autre part, si tu utilises un environnement de bureau (
Gnome, KDE (plasma), Xfce, LXQT, LXDE et autres), il y a des chances que 
celui-ci utilise Pulseaudio et non Alsa directement: utilise alors le 
mixer (mélangeur audio) de ton environnement de bureau plutôt qu'un 
outil Alsa séparé.


Je te suggère de faire des essais avant ta réunion :-)

PS: pour Audacity, 2 articles qui illustrent l'apparition du problème 
puis le dégonflement de la crise:

https://www.01net.com/actualites/comment-audacity-logiciel-audio-open-source-repute-est-devenu-un-possible-spyware-2045643.html
https://www.futura-sciences.com/tech/actualites/informatique-audacity-il-devenu-spyware-92385/

Re: ASTM Lab equipment protocol

[Rob van der Putten]

Hi


On 09/07/2021 20:43, Markos wrote:


Em 09-07-2021 10:21, Rob van der Putten escreveu:


Which Debian packages support the ASTM lab equipment (over TCP) 
protocol? An overview would be nice.
Please, explain with more detail, and some example, what exactly are you 
looking for?


The sister of a friend is a vet. She has blood analyses equipment which 
sends analysis results to a serial port. Each brand and model has it's 
own protocol.
Recently she acquired Skyla VB1. This device has both a serial port and 
Ethernet. It sends a ^A to the serial port, expects a ^F and then sends 
the data followed by a ^D, after which it expects an other ^F.

I did manage to get data from the device this way.

The device can also use the ASTM protocol. With ASTM it can also use 
Ethernet. Which is more practical.
I could not find a free version of the ASTM standard. Apparently, there 
is some Linux software which supports ASTM, but what I could not find is 
a nice overview.



Regards,
Rob

Re: Logiciel pour enregistrer du son

[hamster]

Le 11/07/2021 à 10:21, Raphaël POITEVIN a écrit :

Bonjour,

benoit  writes:


Je vais rédiger un PV de réunion, mais j’ai peur de ne pas dactylographier
assez vite, du coup j’aimerais l’enregistrer.

Je recherche un logiciel avec interface graphique pour enregistrer le son de
la prise micro.


Audacity, dans sa version encore éthique.


Audacity genere des fichiers temporaires très volumineux, ce qui pose 2 
problèmes :
- Si la réunion a enregistrer dure plusieurs heures, il faut un gros 
disque dur avec plusieurs dizaines de Go de place libre.
- Les fichiers temporaires sont par defaut stockés dans la partition 
racine, donc si on a une partition /home séparée il faut modifier le 
lieu de stockage des fichiers temporaires dans la configuration d'audacity.


C'est pourquoi quand je veux simplement enregistrer j'utilise plutot 
celui la :

https://wiki.gnome.org/Apps/SoundRecorder
disponible dans les dépots debian sous le nom gnome-sound-recorder

PS : je suis pas au courant des soucis éthiques d'audacity, tu peux m'en 
dire un peu plus ?

Re: Buster no release file

[mick crane]

On 2021-07-10 23:44, Greg Wooledge wrote:


I *REALLY* and truly hate assholes like that.

control freaks are the biggest problem facing society today.
mick
--
Key ID4BFEBB31

Re: Vulkan with Radeon RX 5700 XT

[Alexander V. Makartsev]

On 10.07.2021 20:54, The Wanderer wrote:

I had enough times when I couldn't launch X (at least not with any
acceleration at all, even 2D acceleration) because an updated NVIDIA
driver which was compatible with the new X or kernel version hadn't been
released yet, and enough troubles trying to switch drivers etc. and
remnants left over on the computer afterwards, that it left me with an
antipathy towards using NVIDIA products.

The fact that NVIDIA's Linux support implementation is proprietary is
both the reason for those problems, and an entirely separate reason why
I decided that until that fact changes, I will never voluntarily buy an
NVIDIA card for a Linux system.
I often read about problems with nvidia drivers others are having, but 
personally I haven't experienced anything like you described.
Probably because these kinds of problems only surface on platforms with 
Nvidia-Optimus technology, which every OEM out there making it in their 
unique way.
The only thing I do after installing an updated kernel is rebuild DKMS 
module by reinstalling "nvidia-kernel-dkms" package, to ensure it would 
be build using current kernel sources.



As I understand matters, this is another consequence of the fact that
the NVIDIA driver (stack) is proprietary - or rather, the only reason
why there's an nvidia-driver package is because it's not practical (or
necessarily even possible) to provide that functionality in a more
integrated way, because of the proprietary and opaque way the NVIDIA
drivers etc. are provided. In an ideal world, no such explicit separate
package(s) would be needed.
It is the matter of convenience, because nvidia drivers, even legacy 
ones, are in official Debian repos.
And installation of them is as easy as "apt install nvidia-driver", plus 
supplementary libraries like GL/GLX, EGL, GLES, OpenCL, VA, VDPAU, 
Vulkan, etc, all could be found by searching "nvidia-*"
Internally, by the looks of it, AMD drivers and Nvidia drivers look the 
same. Both of them consist of DKMS kernel module building suite, XOrg 
modules\extensions and all necessary libraries I've already mentioned.
I don't see any complications or barriers (other than maybe licensing) 
that prevent creation of "amdgpu-driver" metapackage and naming all 
other necessary packages "something-amdgpu-something" and 
"amdgpu-driver-something", in the same way nvidia drivers are made in 
Debian repos.



I'll take this under advisement; at the very least, it's my fallback if
other investigations don't produce any usable results. The examination
of those packages and the results they provide is appreciated.

I should've mentioned about official instructions for amdgpu driver.
They seem to distinguish between two stacks of drivers [1] and 
"All-Open" doesn't have Vulkan in it.
It is just a thought, but maybe only a truncated version of "All-Open" 
stack is available in Debian repos, which rely on Mesa Vulkan 
implementation instead of more recent variant from "Pro" stack.

Even looking through files from Mesa Vulkan package there is a difference:
    apt-file list mesa-vulkan-drivers | grep ".so"
    mesa-vulkan-drivers: /usr/lib/x86_64-linux-gnu/libvulkan_intel.so
    mesa-vulkan-drivers: /usr/lib/x86_64-linux-gnu/libvulkan_radeon.so
    mesa-vulkan-drivers: /usr/share/vulkan/icd.d/intel_icd.x86_64.json
    mesa-vulkan-drivers: /usr/share/vulkan/icd.d/radeon_icd.x86_64.json
And "amdvlk64.so" library file, along with ".json" files from 
"./vulkan-amdgpu*_amd64.deb" packages don't exist inside Debian repos:

    apt-file find amdvlk64.so
    apt-file find amd_icd64.json
Also file sizes of "libvulkan_radeon.so" and "amdvlk64.so" are far too 
different.




[1] https://amdgpu-install.readthedocs.io/en/latest/install-overview.html

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Logiciel pour enregistrer du son

[Raphaël POITEVIN]

Bonjour,

benoit  writes:

> Je vais rédiger un PV de réunion, mais j’ai peur de ne pas dactylographier
> assez vite, du coup j’aimerais l’enregistrer.
>
> Je recherche un logiciel avec interface graphique pour enregistrer le son de
> la prise micro.

Audacity, dans sa version encore éthique.
>
> Est-ce que le fait de brancher un micro externe sur la prise, désactive le
> micro interne du portable ?

Je pense qu’il faudra choisir dans le logiciel l’entrée micro.
-- 
Raphaël
www.leclavierquibave.fr

Logiciel pour enregistrer du son

[benoit]

Bonjour à toutes et tous,

Je vais rédiger un PV de réunion, mais j’ai peur de ne pas dactylographier 
assez vite, du coup j’aimerais l’enregistrer.

Je recherche un logiciel avec interface graphique pour enregistrer le son de la 
prise micro.

Est-ce que le fait de brancher un micro externe sur la prise, désactive le 
micro interne du portable ?

Dans alsamixer il y a un curseur « Internal Mic Boost », même sur 0 le son 
passe.

Merci d'avance.
--
Benoît

Re: Un/Safe mixtures for Debian releases and suites [was: Re: Vulkan with Radeon RX 5700 XT]

[Andrei POPESCU]

On Sb, 10 iul 21, 14:38:39, The Wanderer wrote:
> On 2021-07-10 at 14:18, Andrei POPESCU wrote:
> 
> > On Sb, 10 iul 21, 06:51:43, Brian Thompson wrote:
> > 
> >> On Sat, 2021-07-10 at 13:43 +0200, tv.deb...@googlemail.com wrote:
> >> 
> >>> Hi, Debian unstable with bits of experimental here
> >> 
> >> Is it (usually) wise to intermix different suites?
> > 
> > It depends :)
> > 
> > In my opinion I'd say the order from less to more dangerous would
> > be:
> > 
> > 1. stable + select packages from stable-backports
> 
> > 2. oldstable + select packages from oldstable-backports-sloppy
> 
> > 3. testing + select packages from unstable
> 
> > 4. unstable + select packages from experimental
> 
> I'm a little surprised to see that you don't even mention the mix which
> I've been running for the last decade-plus: stable + testing, which
> works out to testing + select packages from stable (the ones which are
> no longer available in testing).
> 
> Do you consider that to be so dangerous as to not even be worth mentioning?

What I forgot to mention was that outside the common scenarios above you 
are pretty much on your own and you should have a good understanding of 
APT priorities and pinning (or be prepared to deal with problems).

The danger level also varies greatly on which is your "main" release.

While your testing + stable as needed mix is pretty simple[1] the 
reverse mix stable + select packages from testing requires adequate 
pinning and can quickly become problematic for anything but the simplest 
packages packages (no or very few dependencies) pulled from testing.

You should be using -backports instead or backport packages yourself if 
necessary[2].


[1] No pinning required, unless you want to have *very* good control 
over what you install from stable. A similar reasonably safe and easy 
setup is unstable + testing as needed, which is probably a good idea 
anyway, even if not well documented.

[2] If you do that you might as well consider providing them via 
-backports, with the help of a sponsor.

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


signature.asc
Description: PGP signature

Re: Buster no release file

[Tixy]

On Sat, 2021-07-10 at 21:40 -0400, Greg Wooledge wrote:
> On Sat, Jul 10, 2021 at 09:25:51PM -0400, rhkra...@gmail.com wrote:
> > On Saturday, July 10, 2021 06:44:47 PM Greg Wooledge wrote:
> > > I was going to link you to the DebianBuster wiki page where I had put
> > > the standard sources.list for buster, but it appears someone doesn't
> > > want you to have that information.
> > > 
> > > https://wiki.debian.org/DebianBuster?action=diff=23=22
> > > 
> > > You can thank the person who goes by the name PaulWise for making your
> > > Debian wiki a less informative and less useful place.
> > > 
> > > I *REALLY* and truly hate assholes like that.
> > 
> > +1
> > 
> > Do you know him or have had any contact with him (other than by virtue of 
> > the 
> > change he made to the wiki)?
> 
> No, I've never heard of him before.

I've seen his name on various Debian lists and official contexts. If
you follow the link on the wiki diff [1] you'll see he's a Debian
project member and part of the wiki admin team.

[1] https://wiki.debian.org/PaulWise

If you look at the wiki page for GregWooledge there is no contact info
only a link to a page that starts with American political messages.

Fortunately, my first impressions of this Greg person were from
postings to this list, so to me he's this Bash expert and generally
technically sound guy who's worth listening to.

-- 
Tixy

Re: badblocks

[mick crane]

On 2021-07-07 19:59, Andrei POPESCU wrote:


The error is indeed quite suspicious and I'd be weary of making any
permanent changes to the drive, unless it's 100% reproducible with a
known good connection (preferably pure SATA).


I got another USB/SATA adapter and badblocks reports no problems.

mick
--
Key ID4BFEBB31