Re: /etc/securetty

2020-11-12 Thread steve

Le 13-11-2020, à 08:29:07 +0100, Bernard Schoenacker a écrit :


voici une réponse qui devrait te satisfaire :

https://unix.stackexchange.com/questions/41840/effect-of-entries-in-etc-securetty#41939


Merci pour le lien.


et pour debian :

apt-file search pam_securetty

libpam-doc: /usr/share/doc/libpam-doc/html/sag-pam_securetty.html
libpam-modules: /lib/x86_64-linux-gnu/security/pam_securetty.so
libpam-modules: /usr/share/man/man8/pam_securetty.8.gz


J'ai aussi ça d'installé mais pas de fichier /etc/securetty. En as-tu un
chez toi ?



HDD for CCTV

2020-11-12 Thread mick crane

regarding earlier post with do not reply request.
There's loads of HDDs advertised as "for CCTV, like a PC disk"
Is there some difference between HDDs for video recording and regular PC 
HDDs ?


mick
--
Key ID4BFEBB31



Re: /etc/securetty

2020-11-12 Thread Bernard Schoenacker



- Mail original -
> De: "steve" 
> À: debian-user-french@lists.debian.org
> Envoyé: Vendredi 13 Novembre 2020 07:55:50
> Objet: Re: /etc/securetty
> 
> Le 12-11-2020, à 17:18:29 +0100, Belaïd a écrit :
> 
> 
> Non il n'existe pas.
> 
> Quel paquet aurait dû le créer et quel devrait être son contenu ?
> 

bonjour steve,

voici une réponse qui devrait te satisfaire :

https://unix.stackexchange.com/questions/41840/effect-of-entries-in-etc-securetty#41939

et pour debian :

apt-file search pam_securetty

libpam-doc: /usr/share/doc/libpam-doc/html/sag-pam_securetty.html
libpam-modules: /lib/x86_64-linux-gnu/security/pam_securetty.so
libpam-modules: /usr/share/man/man8/pam_securetty.8.gz


merci pour ton aimable attention

bien à toi

bernard



Re: /etc/securetty

2020-11-12 Thread steve

Le 12-11-2020, à 17:18:29 +0100, Belaïd a écrit :


  Bonjour,
  Le fichier est toujours utilisé de nos jours , c'est juste que les
  applications n'y accède pas directement mais a travers Pam. Donc ton
  fichier existe bien sur ta config ? Et que contient-il actuellement ?


Non il n'existe pas.

Quel paquet aurait dû le créer et quel devrait être son contenu ?



Nou tema per Debian 11 (resultat de la votació)

2020-11-12 Thread Àlex
https://www.phoronix.com/scan.php?page=news_item=Debian-11-Desktop-Theme



Re: An old box running Debian 8

2020-11-12 Thread Doug McGarrett




On 11/12/20 4:52 PM, Miroslav Skoric wrote:

On 11/11/20 7:42 PM, Felix Miata wrote:




I have an old comp (CPU Pentium II Celeron 400 MHz, 224 MB RAM) running
ham radio server in Debian 8. It works well in CLI, but very slow after
starting GUI. I wonder whether it would be worth to try (if possible at
all) to upgrade it to Debian 9. Any experience with such old boxes?


Which WM or DE is your GUI running? Some use/need a lot more RAM than 
others. If
you want a full DE you might wish to try TDE, a fork of KDE3 
initially created
when KDE went to version 4, 10 years ago. Its latest release is 
available for

Squeeze, Wheezy, Jesse, Stretch and Buster.
 





It is MATE (cannot remember the version). At first I removed all 
graphics, so it remained CLI-only Jesse. Then I installed Mate from 
the repository. Just for occasional use, not 24/7.


Btw, I did not even think of KDE or Gnome because they both were 
terribly slow even in Wheezy.


Did not much test MATE vs. Xfce or LXDE, regarding the speed.


Misko

I have been only cursorily following here, since I don't use debian, but 
I wonder if you might
consider upgrading your mother board to a new one the same size and 
shape, with
a faster processor and probably more ram. Then the latest version of deb 
would surely work
and well. It's a full afternoon's worth of work, more than likely, but 
you would have to see
if you think it's worth it. A lot cheaper than replacing the whole 
machine, surely.

--doug



Re: An old box running Debian 8

2020-11-12 Thread Charles Curley
On Thu, 12 Nov 2020 23:01:19 +0100
Miroslav Skoric  wrote:

> And when bootable, what GUI might be workable at best (Mate,
> Xfce, ...)? As I said, for nothing much more than occasional
> Thunderbird, or any other compatible mail client that can use the
> CLI-based ham email server (FBB), to process pop3/smtp mails by using
> copy/paste by mouse click etc.
> 
> At this stage (Debian 8) I do that in MATE + Thunderbird. It's slow
> but works. What is not known is whether that would work in Debian 9.

Ah. Consider a non-GUI mail user agent (MUA). Pine and elm are old
standards. heirloom-mailx is a very simple program. The most modern is
mutt. The main thing these will not do is handle HTML mail.

Of those, I would recommend mutt. It uses curses, so you get something
that acts something like a GUI. It is highly flexible and configurable.
Do, however, expect a learning curve.

-- 
Does anybody read signatures any more?

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



Re: An old box running Debian 8

2020-11-12 Thread Linux-Fan

Felix Miata writes:


Miroslav Skoric composed on 2020-11-12 23:01 (UTC+0100):

> At this stage (Debian 8) I do that in MATE + Thunderbird. It's slow but
> works. What is not known is whether that would work in Debian 9.

Possibly you could boot live media 9 to find out, or if you have enough disk  
space available, install a minimal 9 alongside 8.


The problem with a live system on limited hardware is often the amount of  
RAM.


I am impressed to read that Debian 8 + Mate + Thunderbird works anything  
near acceptable on the hardware. I am curious about a `free -h` output from  
that Pentium II-style Celeron machine :)


Just for comparison, on my old Acer Travelmate laptop (Debian 10), for GUI  
tasks, I run the i3 window manager. It performs acceptably. Starting urxvt  
also works. But whenever I run a "larger" GUI application like the zathura  
PDF viewer (which is pretty minimalistic compared to a full-blown  
Thunderbird), it gets very slow and uses swap. While I have occasionally run  
it this way, I would not consider it really "working" because basic features  
like scrolling become "unusably" slow.


On the other hand, if you are using Mate now and can consider switching to  
something lighter (Icewm and FVWM were good suggestions I saw in the  
thread), chances are it will continue to run slowly "as it used to" - the  
RAM and CPU saved from the DE may just be enough to compensate for the  
higher resource usage of newer software...


PS/OT: My previous message missed the important signature characters: öö.  
Thus its PGP-signature is unfortunately incorrect :(


HTH
Linux-Fan

öö


pgpUUS2DJ31ro.pgp
Description: PGP signature


Re: An old box running Debian 8

2020-11-12 Thread Linux-Fan

Miroslav Skoric writes:


On 11/11/20 7:09 PM, Linux-Fan wrote:


Pentium II is old indeed. Whenever using old processors, it is important to
test if the new kernel will still support them.


So maybe I shall try some newer kernel only?


If you have an easy means to do that: Yes, I would highly recommend doing
that.

YMMV
Linux-Fan


pgpeSWud6ifYf.pgp
Description: PGP signature


Re: An old box running Debian 8

2020-11-12 Thread Patrick Bartek
On Wed, 11 Nov 2020 17:40:50 +0100
Miroslav Skoric  wrote:

> I have an old comp (CPU Pentium II Celeron 400 MHz, 224 MB RAM)
> running ham radio server in Debian 8. It works well in CLI, but very
> slow after starting GUI. I wonder whether it would be worth to try
> (if possible at all) to upgrade it to Debian 9. Any experience with
> such old boxes?

You are trying to do what we call in the US, a Fool's Errand, that
is, a fruitless undertaking.  If you could upgrade the RAM to 512MB or
even 1 GB, you might get usable performance with Debian 8 and a
lightweight GUI environment or, better yet, a window manager, but
certainly not with GNOME or KDE. Let me give you an example:

About 10 years ago, I installed Debian 7 on an Asus EeePC 900 with a
900MHz Celeron and 512MB RAM. I tried GNOME first, but even then it was
too much a resources behemoth to even work. LXDE was lighter;
however, even with only a browser running, system performance was
slow, but usable, if you were patient. Upgrading RAM to 1GB made all
the difference in the world turning a barely usable system into one
that while not screaming fast was adequate for simple web browsing,
video streaming, email, etc. which was what it was intended for.

So, first, before changing anything else, see if upgrading RAM does any
good with 8.

B 



Re: An old box running Debian 8

2020-11-12 Thread Felix Miata
Miroslav Skoric composed on 2020-11-12 23:01 (UTC+0100):

> At this stage (Debian 8) I do that in MATE + Thunderbird. It's slow but 
> works. What is not known is whether that would work in Debian 9.

Possibly you could boot live media 9 to find out, or if you have enough disk 
space
available, install a minimal 9 alongside 8.
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/



Re: An old box running Debian 8

2020-11-12 Thread Miroslav Skoric

On 11/11/20 7:42 PM, Felix Miata wrote:




I have an old comp (CPU Pentium II Celeron 400 MHz, 224 MB RAM) running
ham radio server in Debian 8. It works well in CLI, but very slow after
starting GUI. I wonder whether it would be worth to try (if possible at
all) to upgrade it to Debian 9. Any experience with such old boxes?


Which WM or DE is your GUI running? Some use/need a lot more RAM than others. If
you want a full DE you might wish to try TDE, a fork of KDE3 initially created
when KDE went to version 4, 10 years ago. Its latest release is available for
Squeeze, Wheezy, Jesse, Stretch and Buster.




It is MATE (cannot remember the version). At first I removed all 
graphics, so it remained CLI-only Jesse. Then I installed Mate from the 
repository. Just for occasional use, not 24/7.


Btw, I did not even think of KDE or Gnome because they both were 
terribly slow even in Wheezy.


Did not much test MATE vs. Xfce or LXDE, regarding the speed.


Misko



Re: An old box running Debian 8

2020-11-12 Thread Miroslav Skoric

On 11/11/20 9:43 PM, Charles Curley wrote:




I have an old comp (CPU Pentium II Celeron 400 MHz, 224 MB RAM)
running ham radio server in Debian 8. It works well in CLI, but very
slow after starting GUI. I wonder whether it would be worth to try
(if possible at all) to upgrade it to Debian 9. Any experience with
such old boxes?


It is not clear whether you are merely observing that it is slow with a
GUI running, or whether you would like to have a GUI, and are asking
for advice specifically there.

Assuming the latter, what do you want out of a GUI? An absolute minimal
GUI such as FVWM might serve you well enough, but I would not expect
miracles. Also consider a lightweight desktop such as XFCE. But I would
be surprised if that solution helped.



At first, I wondered whether Pentium II Celeron 400 MHz, 224 MB RAM, 
would make it even bootable after upgrading 8 to 9. (Without any GUI, if 
needed to be removed before the upgrade).


And when bootable, what GUI might be workable at best (Mate, Xfce, ...)?
As I said, for nothing much more than occasional Thunderbird, or any 
other compatible mail client that can use the CLI-based ham email server 
(FBB), to process pop3/smtp mails by using copy/paste by mouse click etc.


At this stage (Debian 8) I do that in MATE + Thunderbird. It's slow but 
works. What is not known is whether that would work in Debian 9.




Re: An old box running Debian 8

2020-11-12 Thread Miroslav Skoric

On 11/11/20 7:09 PM, Greg Wooledge wrote:



Upgrading to a newer release is not likely to make it faster.  If anything,
it'll be slower (due to increased memory demands of newer software).



That's something I have already experienced with previous upgrades. But 
it was always in full GUI (either Gnome, KDE, LXDE, Mate, etc). While I 
examined that machine for a 'refurbished' CLI-based system, I removed 
all GUI. And it was not so bad. Then I re-installed Mate desktop again, 
just to run it for some specific tasks such as Thunderbird client. Of 
course the GUI + TB is terribly slow, but it is used only once in a while.



It's also worth noting that Debian 8->9 has a huge change to X and video
drivers.  Lots of chipsets are supported *differently* in Debian 9 than
they were in previous versions.  Whether that's good or bad will depend
on the chipset.  Some chipsets may have lost support altogether.



On another machine, a little bit better than the first one, I did have a 
big issue: After upgrading 8->9 and restart it did not want to open GUI 
at all, so the only solution was to boot in CLI, then 'startx' GUI. So I 
suppose than on this (older) box, GUI might be even more problematic. 
(It is Matrox MGA 400.)


On the other side, it makes me wonder if just CLI-only packages in 
Debian 9 would make it too slow after upgrade (if workable at all).



At this point, your system is quite old, and you should not expect it to
last forever.  Even if the software works perfectly, the hardware is
eventually going to fail.  You might want to get ahead of that by buying
something less ancient.  You might even save on electricity by doing this.




Yeah, I know. The point was to use it until the hardware dies :-)
Electricity? It is in the ham union's office, so nobody cares :-)



Re: An old box running Debian 8

2020-11-12 Thread Miroslav Skoric

On 11/11/20 7:09 PM, Linux-Fan wrote:



Pentium II is old indeed. Whenever using old processors, it is important 
to test if the new kernel will still support them.




So maybe I shall try some newer kernel only?



Re: GTK can't load images

2020-11-12 Thread Malte Marwedel

Am 12.11.20 um 09:35 schrieb to...@tuxteam.de:

On Wed, Nov 11, 2020 at 11:57:08PM +0100, mmdebmail2...@marwedels.de wrote:



I don't know (not sure I'd want to) where Gtk keeps its MIME types
database these days. But, as a shot in the dark: have you checked
that your /etc/mime.types is sane? What does 'grep png /etc/mime.types'
say?

The file comes with Debian package mime-support, in case you need
a new one.


I fixed the error.
After figuring out, that glib2.0 had no data to compare the png data to 
in cache_get_mime_type_for_data, I stepped through 
xdg_mime_init_from_directory and discovered only a few data for 
mimetypes were added from my ~/.local/share directory. Stepping through 
the same code on a different computer, most data came from 
/usr/share/mime/mime.cache, but the file was missing on my computer.
Running update-mime-database /usr/share/mime/ as root solved the 
problem. Took me ~7 hours to figure this out ;) Maybe this was the 
result of an upgrade. Because this was when the error occurred the first 
time.




Re: Git n'arrive pas à contacter certains sites IPv6 en SSH.

2020-11-12 Thread Étienne Mollier
Bonjour Charles,

Charles Plessy, on 2020-11-13 05:22:08 +0900:
> j'ai à nouveau la fibre.  Et en IPv6 en plus.  Mais Git n'arrive plus à
> contacter des sites distants en SSH.
> 
> Curieusement, les sessions SSH interactives ont l'air de s'établir
> normalement.  Example:
> 
> $ ssh -6 g...@salsa.debian.org
> PTY allocation request failed on channel 1
> Welcome to GitLab, @plessy!
> Connection to salsa.debian.org closed.
> 
> (C'est la réponse attendue).
> 
> Par contre:
> 
> $ git clone --verbose g...@salsa.debian.org:med-team/perlprimer.git
> Clonage dans 'perlprimer'...
> 
> … et ensuite plus rien.

Je n'ai pas rencontré de problèmes de mon côté.  En grattant un
peu, la variable d'environnement GIT_SSH_COMMAND peut être
exploitée pour augmenter le verbiage de ssh:

$ export GIT_SSH_COMMAND='ssh -vvv'
$ git clone g...@salsa.debian.org:med-team/perlprimer.git

Peut-être qu'il en sortira quelque chose d'intéressant ?

> Si je désactive IPv6 pour les connections SSH dans ~/.ssh/config:
> 
> Host *
>AddressFamily inet
> 
> Tout rentre dans l'ordre.  Mais ce n'est pas satisfaisant :)
> 
> Le problème n'est pas spécifique au réseau Debian; j'ai la même chose
> avec branchable.com et gitlab.com.  Par contre, ça fonctionne avec
> GitHub...

De mon point de vue, Github n'est pas accessible en IPv6, ou du
moins, n'en fait pas la publicité :

$ host github.com
github.com has address 140.82.113.3
github.com mail is handled by 10 alt3.aspmx.l.google.com.
github.com mail is handled by 10 alt4.aspmx.l.google.com.
github.com mail is handled by 1 aspmx.l.google.com.
github.com mail is handled by 5 alt1.aspmx.l.google.com.
github.com mail is handled by 5 alt2.aspmx.l.google.com.

Ceci pourrait expliquer cela...

Bonne journée,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/7, please excuse my verbosity.


signature.asc
Description: PGP signature


Git n'arrive pas à contacter certains sites IPv6 en SSH.

2020-11-12 Thread Charles Plessy
Bonjour à tous,

j'ai à nouveau la fibre.  Et en IPv6 en plus.  Mais Git n'arrive plus à
contacter des sites distants en SSH.

Curieusement, les sessions SSH interactives ont l'air de s'établir
normalement.  Example:

$ ssh -6 g...@salsa.debian.org
PTY allocation request failed on channel 1
Welcome to GitLab, @plessy!
Connection to salsa.debian.org closed.

(C'est la réponse attendue).

Par contre:

$ git clone --verbose g...@salsa.debian.org:med-team/perlprimer.git
Clonage dans 'perlprimer'...

… et ensuite plus rien.

Si je désactive IPv6 pour les connections SSH dans ~/.ssh/config:

Host *
   AddressFamily inet

Tout rentre dans l'ordre.  Mais ce n'est pas satisfaisant :)

Le problème n'est pas spécifique au réseau Debian; j'ai la même chose
avec branchable.com et gitlab.com.  Par contre, ça fonctionne avec
GitHub...

Quelqu'un aurait-il une piste ?

Charles

-- 
Charles Plessy
Nagahama, Yomitan, Okinawa, Japon



Fwd: Just scheduled: #011 Alfred Blokland - SaltStack

2020-11-12 Thread Geert Stappers

Hoi,


- Forwarded message from Linux & Open Source Tilburg -

Date: Thu, 12 Nov 2020 15:41:11 + (UTC)
From: Linux & Open Source Tilburg
To: Me etup
Subject:  Just scheduled: #011 Alfred Blokland - SaltStack



Er is een nieuw evenement in Linux & Open Source Tilburg. Bekijk de info.

Linux & Open Source Tilburg

dinsdag 17 november 2020
20:00 tot 10:00 PM CET

Online event
Link zichtbaar voor deelnemers


Details
SaltStack is open-source software voor het beheren en configureren
van IT infrastructuur op iedere schaal. Door infrastructuur
als code te beschrijven is het mogelijk efficiënt servers te
brengen naar een gewenste staat.  Alfred is CTO bij Hendrikx ITC.

Ontdek meer https://lostilburg.nl/post/011/



- End redacted forwarded message -


Doe er je voordeel mee.
Dan wel laat anderen er hun voordeel mee doen   :-)



Groeten
Geert Stappers
-- 
Silence is hard to parse


signature.asc
Description: PGP signature


Re: /etc/securetty

2020-11-12 Thread Belaïd
Bonjour,

Le fichier est toujours utilisé de nos jours , c'est juste que les
applications n'y accède pas directement mais a travers Pam. Donc ton
fichier existe bien sur ta config ? Et que contient-il actuellement ?

Le jeu. 12 nov. 2020 17:09, steve  a écrit :

> Bonjour,
>
> Depuis quelques jours j'ai le message suivant qui pollue les logs:
>
> cupsd: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or
> directory
>
> Après quelques recherches, il semble que ce fichier est un reliquat d'un
> passé pas trop lointain qui devait spécifier à root sur quel tty il
> pouvait se connecter. Or je ne vois pas pourquoi cups en parle et
> surtout, je n'arrive plus à imprimer depuis quelques jours. Pas sûr que
> ce soit lié mais sait-on jamais.
>
> Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip à
> faire ?
>
> Merci
>
> Steve
>
>


Re: Arrière fond noir dans KDE Plasma

2020-11-12 Thread steve

Le 12-11-2020, à 10:35:46 +0100, Francois Mescam a écrit :

Voir le bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974019 
qui parle de l'instabilité de kde.


J'ai été confronté à ce problème et j'ai bloqué les paquets suivants 
aux versions indiquées ci-après :


libkdecorations2-5v5:amd64 4:5.17.5-2
libkf5screen-bin:amd64 4:5.17.5-3
libkf5screen7:amd64 4:5.17.5-3


Merci pour l'info et le lien, mais malheureusement ça n'a pas fonctionné
sur mon système quelque peu hybride.



/etc/securetty

2020-11-12 Thread steve

Bonjour,

Depuis quelques jours j'ai le message suivant qui pollue les logs:

cupsd: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or 
directory

Après quelques recherches, il semble que ce fichier est un reliquat d'un
passé pas trop lointain qui devait spécifier à root sur quel tty il
pouvait se connecter. Or je ne vois pas pourquoi cups en parle et
surtout, je n'arrive plus à imprimer depuis quelques jours. Pas sûr que
ce soit lié mais sait-on jamais.

Est-ce que je peux supprimer ce fichier ou y a-t-il une autre manip à
faire ?

Merci

Steve



Conciliacion y Arbitraje, Contratos Colectivos, Negociaciones Sindicales

2020-11-12 Thread Miguel Angel Ruiz Caballero
A partir de este mes en algunos estados de la república nace el Centro Federal 
de Conciliación y Registro Laboral (CFCRL)...

Especialista en
RELACIONES LABORALES:
Contratos, Sindicatos y el Nuevo Sistema de Justicia Laboral en México
Entrenamiento Online en Vivo
Fecha de inicio: 27 de Noviembre 2020

CONOCE LOS PRINCIPIOS FUNDAMENTALES DE LAS RELACIONES INDIVIDUALES Y CONTRATOS 
COLECTIVOS DE TRABAJO, CÓMO HACER NEGOCIACIONES SINDICALES EXITOSAS Y TODO LO 
QUE DEBEMOS SABER DEL NUEVO SISTEMA DE JUSTICIA LABORAL QUE ENTRÓ EN VIGOR EN 
MÉXICO A PARTIR DE ESTE MES DE NOVIEMBRE.
 
DESCARGAR INFORMACIÓN COMPLETA

 Mayor información a través de WhatsApp

O para información mucho más detallada comuníquese al:

Ciudad de México / 55 2450 6187
Monterrey, N.L. / 81 2974 7731
Guadalajara, Jal. / 33 2005 0994



Este boletín informativo tiene como objetivo generar valor en usted y su 
Organización. Para darse de baja de este tipo de información conteste con la 
palabra BAJALABORAL737.
O en su defecto haga click en el siguiente enlace: unsubscribe from this list


Re: drives spin 100% of the time, idle down?

2020-11-12 Thread Stefan Monnier
> That makes sense.These WD drives I got to sleep automatically after 10m are
> 2013 Blue desktop drives.

There's a chance that you just got lucky and the time that the drive
decides to use is similar to the time you set.  In any case this
behavior was not really documented anywhere so it might have only
applied to some drives, but I remember finding some website that made me
think it probably affected most WD drives (and that it was not
considered as a bug).

> The firmware on new ones may behave differently.

My info is pretty old, so it should apply to 2013 drives.

> The Seagate Barracudas in the NAS do respond to a sleep command
> (hdparm -y) but

Indeed `hdparm -y` has worked fairly reliably for me for all drives.


Stefan



Re: drives spin 100% of the time, idle down?

2020-11-12 Thread James B
That makes sense.These WD drives I got to sleep automatically after 10m are 
2013 Blue desktop drives.The firmware on new ones may behave differently.The 
Seagate Barracudas in the NAS do respond to a sleep command (hdparm -y) but not 
any command to change the auto sleep time - they stay spinning forever unless 
you tell them to stop.I have two brand new 1TB Blue turning up today so will 
see how they work.

-- 
  James B
  portoteache...@fastmail.com

Em Qui, 12 Nov ʼ20, às 14:47, Stefan Monnier escreveu:
> > You can set the sleep time in the firmware of most drives, although some
> > respond better than others. I've been able to set the sleep time in WD
> > drives but not Seagate, but both go to sleep when instructed.
> 
> FWIW, the `hdparm -S` doesn't really work for WD drives last I checked.
> More specifically, IIUC WD drives will mostly disregard the "time to spin
> down" you specify and instead they'll use their own idea of what the
> time to spin down should be based on the power-management level
> you specified.
> 
> 
> Stefan
> 
>



Re: drives spin 100% of the time, idle down?

2020-11-12 Thread Stefan Monnier
> You can set the sleep time in the firmware of most drives, although some
> respond better than others. I've been able to set the sleep time in WD
> drives but not Seagate, but both go to sleep when instructed.

FWIW, the `hdparm -S` doesn't really work for WD drives last I checked.
More specifically, IIUC WD drives will mostly disregard the "time to spin
down" you specify and instead they'll use their own idea of what the
time to spin down should be based on the power-management level
you specified.


Stefan



Re: drives spin 100% of the time, idle down?

2020-11-12 Thread Alex Mestiashvili

Hi,

another option is hd-idle package available via backports for stable and 
oldstable.



On 11/12/20 1:18 PM, Thomas Anderson wrote:

Hello List,

I have two drives (setup in a RAID 1 array).

The drives are mostly for archive purposes, and accessible via SMB on my
local network.

They are not constantly accessed, and performance/speed is irrelevant.

I would rather they idle/sleep when not being directly accessed. I know
they are supposed to spin, and spinning them up and down is not good for
them. But, in my particular use case, it seems acceptable.

Am I off base?

Can anyone recommend a way to do this in debian? Is there a program that
will allow me to set this?





Re: drives spin 100% of the time, idle down?

2020-11-12 Thread James B
Sorry  it's 'hdparm -S' to set sleep time, not small s!

-- 
  James B
  portoteache...@fastmail.com

Em Qui, 12 Nov ʼ20, às 12:25, James B escreveu:
> You can set the sleep time in the firmware of most drives, although 
> some respond better than others. I've been able to set the sleep time 
> in WD drives but not Seagate, but both go to sleep when instructed. I 
> have an old Iomega ix2-200 running Arch ARM.I use 'hdparm' to instruct 
> the drives to sleep for exactly the same reasons as you.
> 
> The package is 'hdparm' in Debian.Simply (as root) enter 'hdparm -y 
> /dev/sdx to manually put the drive to sleep.
> 
> I believe 'hdparm -s ' allows you to set the sleep time, but the 
> options will be shown to you if you enter 'hdparm -h'
> 
> Hope that helps!
> 
> 
> -- 
>   James B
>   portoteache...@fastmail.com
> 
> Em Qui, 12 Nov ʼ20, às 12:18, Thomas Anderson escreveu:
> > Hello List,
> > 
> > I have two drives (setup in a RAID 1 array).
> > 
> > The drives are mostly for archive purposes, and accessible via SMB on my
> > local network.
> > 
> > They are not constantly accessed, and performance/speed is irrelevant.
> > 
> > I would rather they idle/sleep when not being directly accessed. I know
> > they are supposed to spin, and spinning them up and down is not good for
> > them. But, in my particular use case, it seems acceptable.
> > 
> > Am I off base?
> > 
> > Can anyone recommend a way to do this in debian? Is there a program that
> > will allow me to set this?
> > 
> >
> 
>



Re: drives spin 100% of the time, idle down?

2020-11-12 Thread James B
You can set the sleep time in the firmware of most drives, although some 
respond better than others. I've been able to set the sleep time in WD drives 
but not Seagate, but both go to sleep when instructed. I have an old Iomega 
ix2-200 running Arch ARM.I use 'hdparm' to instruct the drives to sleep for 
exactly the same reasons as you.

The package is 'hdparm' in Debian.Simply (as root) enter 'hdparm -y /dev/sdx to 
manually put the drive to sleep.

I believe 'hdparm -s ' allows you to set the sleep time, but the options will 
be shown to you if you enter 'hdparm -h'

Hope that helps!


-- 
  James B
  portoteache...@fastmail.com

Em Qui, 12 Nov ʼ20, às 12:18, Thomas Anderson escreveu:
> Hello List,
> 
> I have two drives (setup in a RAID 1 array).
> 
> The drives are mostly for archive purposes, and accessible via SMB on my
> local network.
> 
> They are not constantly accessed, and performance/speed is irrelevant.
> 
> I would rather they idle/sleep when not being directly accessed. I know
> they are supposed to spin, and spinning them up and down is not good for
> them. But, in my particular use case, it seems acceptable.
> 
> Am I off base?
> 
> Can anyone recommend a way to do this in debian? Is there a program that
> will allow me to set this?
> 
>



drives spin 100% of the time, idle down?

2020-11-12 Thread Thomas Anderson
Hello List,

I have two drives (setup in a RAID 1 array).

The drives are mostly for archive purposes, and accessible via SMB on my
local network.

They are not constantly accessed, and performance/speed is irrelevant.

I would rather they idle/sleep when not being directly accessed. I know
they are supposed to spin, and spinning them up and down is not good for
them. But, in my particular use case, it seems acceptable.

Am I off base?

Can anyone recommend a way to do this in debian? Is there a program that
will allow me to set this?



Re: Arrière fond noir dans KDE Plasma

2020-11-12 Thread Francois Mescam
Complément à ma réponse : je suis en 5.9.0-1 pour le kernel et le kernel 
a l'air de ne pas être en cause dans ce problème.


Francois Mescam

Le 12/11/2020 à 10:11, Kohler Gerard a écrit :

bonjour,


je suis dans le même cas, depuis la mise à jour du kernel et de kde 
j'ai une grande instabilité du systeme avec une impossibilité de m'en 
servir,

je suis également sous bullseye,
question subsidiaire : je ne me rappelle plus la commande pour 
installer un nouveau systeme avec un kernel antérieur


gerard

Le 11/11/2020 à 17:05, steve a écrit :

Salut,

Voir

https://justpaste.it/76t6y

Je suis sous Debian testing et depuis quelques jours j'ai cet arrière
plan complètement noir tant dans les champs texte des applications que
dans les icônes de la barre de tâche.

J'ai essayé beaucoup de choses dont la création d'un nouvel utilisateur
(d'où sont prises ces captures d'écran). Toujours le même problème. J'ai
aussi installé kde plasma 5.20 depuis le dépôt de Norbert Preining
(https://www.preining.info/blog/2020/11/debian-kde-plasma-status-2020-11-04/). 
Même problème.


Il me semble me souvenir d'avoir déjà eu ce problème il y a quelques
années mais aucun souvenir de la manière de le résoudre.

Si quelqu'un a un début d'idée, ce serait génial.

Merci d'avance.

Steve







Re: Arrière fond noir dans KDE Plasma

2020-11-12 Thread Francois Mescam
Voir le bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974019 qui 
parle de l'instabilité de kde.


J'ai été confronté à ce problème et j'ai bloqué les paquets suivants aux 
versions indiquées ci-après :


libkdecorations2-5v5:amd64 4:5.17.5-2
libkf5screen-bin:amd64 4:5.17.5-3
libkf5screen7:amd64 4:5.17.5-3

Francois Mescam

Le 12/11/2020 à 10:11, Kohler Gerard a écrit :

bonjour,


je suis dans le même cas, depuis la mise à jour du kernel et de kde 
j'ai une grande instabilité du systeme avec une impossibilité de m'en 
servir,

je suis également sous bullseye,
question subsidiaire : je ne me rappelle plus la commande pour 
installer un nouveau systeme avec un kernel antérieur


gerard

Le 11/11/2020 à 17:05, steve a écrit :

Salut,

Voir

https://justpaste.it/76t6y

Je suis sous Debian testing et depuis quelques jours j'ai cet arrière
plan complètement noir tant dans les champs texte des applications que
dans les icônes de la barre de tâche.

J'ai essayé beaucoup de choses dont la création d'un nouvel utilisateur
(d'où sont prises ces captures d'écran). Toujours le même problème. J'ai
aussi installé kde plasma 5.20 depuis le dépôt de Norbert Preining
(https://www.preining.info/blog/2020/11/debian-kde-plasma-status-2020-11-04/). 
Même problème.


Il me semble me souvenir d'avoir déjà eu ce problème il y a quelques
années mais aucun souvenir de la manière de le résoudre.

Si quelqu'un a un début d'idée, ce serait génial.

Merci d'avance.

Steve







Re: Arrière fond noir dans KDE Plasma

2020-11-12 Thread Kohler Gerard

bonjour,


je suis dans le même cas, depuis la mise à jour du kernel et de kde j'ai 
une grande instabilité du systeme avec une impossibilité de m'en servir,

je suis également sous bullseye,
question subsidiaire : je ne me rappelle plus la commande pour installer 
un nouveau systeme avec un kernel antérieur


gerard

Le 11/11/2020 à 17:05, steve a écrit :

Salut,

Voir

https://justpaste.it/76t6y

Je suis sous Debian testing et depuis quelques jours j'ai cet arrière
plan complètement noir tant dans les champs texte des applications que
dans les icônes de la barre de tâche.

J'ai essayé beaucoup de choses dont la création d'un nouvel utilisateur
(d'où sont prises ces captures d'écran). Toujours le même problème. J'ai
aussi installé kde plasma 5.20 depuis le dépôt de Norbert Preining
(https://www.preining.info/blog/2020/11/debian-kde-plasma-status-2020-11-04/). 
Même problème.


Il me semble me souvenir d'avoir déjà eu ce problème il y a quelques
années mais aucun souvenir de la manière de le résoudre.

Si quelqu'un a un début d'idée, ce serait génial.

Merci d'avance.

Steve





Re: An old box running Debian 8

2020-11-12 Thread Michael Lange
Hi,

On Wed, 11 Nov 2020 23:36:07 -0300
riveravaldez  wrote:

> On 11/11/20, Felix Miata  wrote:
> > Charles Curley composed on 2020-11-11 13:43 (UTC-0700):
> >
> >> Also consider a lightweight desktop such as XFCE. But I would
> >> be surprised if that solution helped.
> >
> > Why do people keep claiming XFCE is a lightweight?
> > https://www.youtube.com/watch?v=RrvJOXypAbk
> 
> A really good option in this field is IceWM. It has everything a typical
> user needs out-of-the-box and is extremely lightweight (and themeable).
> 

>From my own experience I agree about that.
Still, the tricky part will be to choose other gui programs that are
still usable with the OP's hardware. For example, if they need a gui text
editor, nedit may be light enough for such a machine (that is, if one can
live without proper unicode support) and maybe xfe may still be a usable
gui file manager for them. The display command provides probably a usable
image viewer.
Web browsers will be especially tricky.
If dillo is good enough it will probably behave more or less smoothly.
Using firefox would very likely be not much fun.

Regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

Madness has no purpose.  Or reason.  But it may have a goal.
-- Spock, "The Alternative Factor", stardate 3088.7



Re: GTK can't load images

2020-11-12 Thread tomas
On Wed, Nov 11, 2020 at 11:57:08PM +0100, mmdebmail2...@marwedels.de wrote:

[...]

> I think is clearly png [...]

[...]

> I got so far as cache_get_mime_type_for_data in glib2.0-2.58.3 in
> xdgmimecache.c not finding a proper entry [...]

I don't know (not sure I'd want to) where Gtk keeps its MIME types
database these days. But, as a shot in the dark: have you checked
that your /etc/mime.types is sane? What does 'grep png /etc/mime.types'
say?

The file comes with Debian package mime-support, in case you need
a new one.

Cheers
 - t


signature.asc
Description: Digital signature