Re: {hors sujet] à propos d'une vidéo sur une recette de cuisine (Louis de Funès)

[fab]

'lut,


voici le lien de la vidéo :
https://www.youtube.com/watch?v=zcsi3PDHKRI

remarque :
c'est à partir de 54" que c'est intéressant

https://www.youtube.com/watch?v=zcsi3PDHKRI#t=0m54s

f.

Re: udev being an ass

[David Wright]

On Tue 27 Aug 2019 at 19:51:21 (-0400), Gene Heskett wrote:
> On Tuesday 27 August 2019 17:44:18 David Wright wrote:
> > On Tue 27 Aug 2019 at 21:39:52 (+0100), Brian wrote:
> > > On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:
> > > > On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> > > > > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett  
> > > > > wrote:
> > > > > > I've just swapped machines because that failed one got nailed
> > > > > > by a lightning surge while I was in the shop with a heart
> > > > > > attack.  3 different psu's didn't restore the green led in a
> > > > > > decade old dell, so I swapped the whole box except for the HD.
> > > > > >
> > > > > > But udevs UN-persistent rules have apparently run out of eth0
> > > > > > names, renaming the only ethernet port it has to eth2.  So I
> > > > > > either rename it to eth2 in /e/n/i, or kill the rule that
> > > > > > advances the name. Since those old dells only come with one
> > > > > > port, I'd much druther have a fixed name.
> > > > > >
> > > > > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0
> > > > > > remains eth0 regardless of which box I put that drive in?
> > > > > >
> > > > > > Thanks.
> > > > >
> > > > > I usually just blow away
> > > > > /etc/udev/rules.d/70-persistent-net.rules to solve stuff like
> > > > > that... I'm not absolutely sure that's the same in Wheezy
> > > > > though.
> > > >
> > > > I'll do it, but the date on it is today, so I suspect something
> > > > in /lib/udev/rules.d is behind the re-write.  And thats probably
> > > > where to apply the nuclear option.  They really should have
> > > > renamed it 70-un-persistent-net. T'would have been a much more
> > > > accurate description.
> > >
> > > In spite of posts about it in -user, you are just about clueless
> > > about status of /etc/udev/rules.d/70-persistent-net.rules, aren't
> > > you?
> > >
> > > As for wheezy - deary me; we are living in the past.
> >
> > Evidently, Gene never got round to writing the script mentioned in:
> > https://lists.debian.org/debian-user/2016/05/msg00707.html
> > which would have cleaned /etc/udev/rules.d/70-persistent-net.rules
> > already.
> 
> one must have a working network before any such script can be posted.
> next fictitious request?

I didn't ask you to post a script. Three years ago I suggested
you write one that would erase the contents of
/etc/udev/rules.d/70-persistent-net.rules and you replied:

"Now thats a jolly good idea, so next time it has to start
from scratch."

I guess you've forgotten that you had exactly the same problem
with the persistence of /etc/udev/rules.d/70-persistent-net.rules
three years ago. If you'd implemented the script, you wouldn't have
had the same problem today.

Cheers,
David.

Re: udev being an ass

[David Wright]

On Tue 27 Aug 2019 at 19:41:41 (-0400), Gene Heskett wrote:
> On Tuesday 27 August 2019 17:38:34 David Wright wrote:
> > On Tue 27 Aug 2019 at 16:13:25 (-0400), Greg Wooledge wrote:
> > > On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote:
> > > > I'll do it, but the date on it is today, so I suspect something
> > > > in /lib/udev/rules.d is behind the re-write.
> > >
> > > If that file exists, it's used.  Quotes in the file are ignored. 
> > > Valid content in the file is used to map various interfaces
> > > (typically identified by their MAC addresses) to interface names.
> > >
> > > If the file does not exist, it will be (re)created.
> > >
> > > If the file exists, but your interface isn't in it (as determined by
> > > whatever criteria are being used to identify the interface,
> > > typically the MAC address), then a new name will be assigned for it
> > > (skipping the names that are already in use), and this will be
> > > written to the file.
> > >
> > > So, the suggestion was to remove the file from the system before
> > > replacing all your interfaces (or moving the hard drive to a new
> > > computer, which from the hard drive's point of view is equivalent to
> > > "you replaced all the interfaces").  In that situation, the file
> > > doesn't exist, so it will be created from scratch.  You've got one
> > > or more interfaces that don't (yet) have assigned names, so names
> > > will be assigned to them.  One of them will become eth0, one of them
> > > will become eth1, and so on, depending on how many interfaces there
> > > are in the new machine.
> > >
> > > If you have exactly one interface, it will become eth0, and you will
> > > be happy.
> > >
> > > If you have more than one interface, you have no way of knowing
> > > which one will become eth0.  That's the situation the newfangled
> > > thing was intended to remedy, but it doesn't really succeed at that
> > > either.
> >
> > I think you're being oblique. There's a race. The udev method was not
> > designed to eliminate that, but to make sure that the resulting names
> > would forever be the same, once the race has been run the first time.
> >
> > In the past, when I have had a mobo fail and moved everything into
> > a spare box, I've found that the new machine (I assume it's the CMOS
> > sensu lato) is happiest when you add one card at a time, run the
> > POST and let the CMOS deal with it; then add the next.
> > In a similar manner, you *could* fix the race by booting up linux
> > with one new interface at a time …
> >
> > > In almost every situation, you need to let the computer ASSIGN the
> > > names first, then login to it and see what interface got what name,
> > > and then adjust your configs accordingly.
> >
> > … but really there's no need, because it's obvious from the rules file
> > what is going on.
> >
> >   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> >   ATTR{address}=="00:a0:24:93:4d:8e", ATTR{dev_id}=="0x0", \
> >   ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> >
> >   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> >   ATTR{address}=="00:a0:24:b8:63:b5", ATTR{dev_id}=="0x0", \
> >   ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
> >
> Add another stanza that ends with eth2.
> 
> And normally, one expects to see discovery someplace in dmesg.
> but /dev/eth2 is not created. No /dev/eth nor is there a /dev/eth* 
> anyplace in the dmesg.  Nor have I found a 6 doublet MAC address.

Why? Here's an entry from one of my laptops:

# USB device 0x:0x (ndiswrapper)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
ATTR{address}=="c4:3d:c7:bf:8d:0e", ATTR{dev_id}=="0x0", \
ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

That entry is over five years old, from when I briefly used a Netgear
wifi stick in it. Why should dmesg know anything about it today?

Lastly, I've never seen a /dev/eth* or /dev/wlan* and have no idea
who would create them or what they would be used for.

> > There's a machine with two 3Com NICs. If you don't like the
> > allocation, you just switch eth0 and eth1. (One assumes that the
> > backplanes have been physically marked so that the connectors
> > themselves can be distinguished.) So you don't need to touch
> > your configuration, by which I assume you mean /e/n/i and suchlike.
> >
> yes.
> 
> > > I do not know of any way around this, other than only ever having
> > > one interface per computer, which may work OK in some situations,
> > > but definitely not in others.

Cheers,
David.

Re: {hors sujet] à propos d'une vidéo sur une recette de cuisine (Louis de Funès)

[Bernard Schoenacker]

> Bonjour
> 
> 
> youtube-dl
> 
> À+
> 

bonjour,

c'est pas youtube-dl qui m'intéresse, mais simplement le fait de
pouvoir récupérer le lien qui débute à 54", à une époque c'était
possible, mais maintenant je n'ai pas compris la raison pour que
ça ne le sois plus ...

désolé de n'avoir pas tout indiqué 

merci pour votre aimable attention

bien à vous
bernard

Re: debian et UEFI

[Haricophile]

Le mardi 27 août 2019 à 20:20 +0200, Basile Starynkevitch a écrit :
> Bonjour,
> 
> 
> 
> J'ai une carte mère MSI X399
> SLI Plus avec un processeur AMD 2970WX sous Debian/Testing
>   (et bien sûr, aucun système microsoftien), plusieurs disques,
> 64Go
>   de RAM.
> 
> 
> Je connais mal (à cause de mon âge, 60 ans) le UEFI
>   (dont j'ai pourtant parcouru quelques spécifications
> programmatiques). Je
>   lis et écris
>   l'anglais technique sans souci.
> Puis-je configurer cet UEFI depuis Debian en ligne de commande?
>   Par exemple, l'ordre de boot, l'overclocking léger, le
> redémarrage
>   automatique, etc. Si oui, comment?
> 
> 
> L'interface clickodromatique de mon BIOS/UEFI (au démarrage) est
>   très urticante, car j'ai tendance à être allergique à la souris.
>   Dans mes rêves les plus fous, je souhaiterais même avoir un
> CoreBoot,
>   mais je ne veux pas risquer de briquer ma belle machine, donc je
>   reste raisonnablement avec mon UEFI.
> 
> 
> Que faire?
> 
> 
> 
> Cordialement
> 
> 
> 

Je ne connais pas la carte, mais il y a souvent un mode de compatibilité
BIOS. Sinon perso, avec grub-efi-amd64 installé je ne me pose pas trop
de question pour la config que je ne change pas tout les jours. 

Re: {hors sujet] à propos d'une vidéo sur une recette de cuisine (Louis de Funès)

[Francois Lafont]

Bonjourn

On 8/28/19 2:29 AM, Bernard Schoenacker wrote:


je souhaiterai pouvoir récupérer une séquence
vidéo culte sur une recette de cuisine
  (Louis de Funès dans le grand restaurant) ...

voici le lien de la vidéo :
https://www.youtube.com/watch?v=zcsi3PDHKRI

remarque :
c'est à partir de 54" que c'est intéressant


youtube-dl

À+


--
François Lafont

{hors sujet] à propos d'une vidéo sur une recette de cuisine (Louis de Funès)

[Bernard Schoenacker]

bonjour,

je souhaiterai pouvoir récupérer une séquence 
vidéo culte sur une recette de cuisine 
 (Louis de Funès dans le grand restaurant) ...

voici le lien de la vidéo :
https://www.youtube.com/watch?v=zcsi3PDHKRI

remarque :
c'est à partir de 54" que c'est intéressant 


merci pour votre aimable attention

bien à vous
bernard

Re: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 17:44:18 David Wright wrote:

> On Tue 27 Aug 2019 at 21:39:52 (+0100), Brian wrote:
> > On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:
> > > On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> > > > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett 
 wrote:
> > > > > I've just swapped machines because that failed one got nailed
> > > > > by a lightning surge while I was in the shop with a heart
> > > > > attack.  3 different psu's didn't restore the green led in a
> > > > > decade old dell, so I swapped the whole box except for the HD.
> > > > >
> > > > > But udevs UN-persistent rules have apparently run out of eth0
> > > > > names, renaming the only ethernet port it has to eth2.  So I
> > > > > either rename it to eth2 in /e/n/i, or kill the rule that
> > > > > advances the name. Since those old dells only come with one
> > > > > port, I'd much druther have a fixed name.
> > > > >
> > > > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0
> > > > > remains eth0 regardless of which box I put that drive in?
> > > > >
> > > > > Thanks.
> > > >
> > > > I usually just blow away
> > > > /etc/udev/rules.d/70-persistent-net.rules to solve stuff like
> > > > that... I'm not absolutely sure that's the same in Wheezy
> > > > though.
> > >
> > > I'll do it, but the date on it is today, so I suspect something
> > > in /lib/udev/rules.d is behind the re-write.  And thats probably
> > > where to apply the nuclear option.  They really should have
> > > renamed it 70-un-persistent-net. T'would have been a much more
> > > accurate description.
> >
> > In spite of posts about it in -user, you are just about clueless
> > about status of /etc/udev/rules.d/70-persistent-net.rules, aren't
> > you?
> >
> > As for wheezy - deary me; we are living in the past.
>
> Evidently, Gene never got round to writing the script mentioned in:
> https://lists.debian.org/debian-user/2016/05/msg00707.html
> which would have cleaned /etc/udev/rules.d/70-persistent-net.rules
> already.

one must have a working network before any such script can be posted.
next fictitious request?

> Cheers,
> David.


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: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 17:38:34 David Wright wrote:

> On Tue 27 Aug 2019 at 16:13:25 (-0400), Greg Wooledge wrote:
> > On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote:
> > > I'll do it, but the date on it is today, so I suspect something
> > > in /lib/udev/rules.d is behind the re-write.
> >
> > If that file exists, it's used.  Quotes in the file are ignored. 
> > Valid content in the file is used to map various interfaces
> > (typically identified by their MAC addresses) to interface names.
> >
> > If the file does not exist, it will be (re)created.
> >
> > If the file exists, but your interface isn't in it (as determined by
> > whatever criteria are being used to identify the interface,
> > typically the MAC address), then a new name will be assigned for it
> > (skipping the names that are already in use), and this will be
> > written to the file.
> >
> > So, the suggestion was to remove the file from the system before
> > replacing all your interfaces (or moving the hard drive to a new
> > computer, which from the hard drive's point of view is equivalent to
> > "you replaced all the interfaces").  In that situation, the file
> > doesn't exist, so it will be created from scratch.  You've got one
> > or more interfaces that don't (yet) have assigned names, so names
> > will be assigned to them.  One of them will become eth0, one of them
> > will become eth1, and so on, depending on how many interfaces there
> > are in the new machine.
> >
> > If you have exactly one interface, it will become eth0, and you will
> > be happy.
> >
> > If you have more than one interface, you have no way of knowing
> > which one will become eth0.  That's the situation the newfangled
> > thing was intended to remedy, but it doesn't really succeed at that
> > either.
>
> I think you're being oblique. There's a race. The udev method was not
> designed to eliminate that, but to make sure that the resulting names
> would forever be the same, once the race has been run the first time.
>
> In the past, when I have had a mobo fail and moved everything into
> a spare box, I've found that the new machine (I assume it's the CMOS
> sensu lato) is happiest when you add one card at a time, run the
> POST and let the CMOS deal with it; then add the next.
> In a similar manner, you *could* fix the race by booting up linux
> with one new interface at a time …
>
> > In almost every situation, you need to let the computer ASSIGN the
> > names first, then login to it and see what interface got what name,
> > and then adjust your configs accordingly.
>
> … but really there's no need, because it's obvious from the rules file
> what is going on.
>
>   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
>   ATTR{address}=="00:a0:24:93:4d:8e", ATTR{dev_id}=="0x0", \
>   ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>
>   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
>   ATTR{address}=="00:a0:24:b8:63:b5", ATTR{dev_id}=="0x0", \
>   ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
>
Add another stanza that ends with eth2.

And normally, one expects to see discovery someplace in dmesg.
but /dev/eth2 is not created. No /dev/eth nor is there a /dev/eth* 
anyplace in the dmesg.  Nor have I found a 6 doublet MAC address.
 
> There's a machine with two 3Com NICs. If you don't like the
> allocation, you just switch eth0 and eth1. (One assumes that the
> backplanes have been physically marked so that the connectors
> themselves can be distinguished.) So you don't need to touch
> your configuration, by which I assume you mean /e/n/i and suchlike.
>
yes.

> > I do not know of any way around this, other than only ever having
> > one interface per computer, which may work OK in some situations,
> > but definitely not in others.
>
> Cheers,
> David.


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: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 16:39:52 Brian wrote:

> On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:
> > On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> > > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett
> > > 
> >
> > wrote:
> > > > Greetings all;
> > > >
> > > > I've just swapped machines because that failed one got nailed by
> > > > a lightning surge while I was in the shop with a heart attack. 
> > > > 3 different psu's didn't restore the green led in a decade old
> > > > dell, so I swapped the whole box except for the HD.
> > > >
> > > > But udevs UN-persistent rules have apparently run out of eth0
> > > > names, renaming the only ethernet port it has to eth2.  So I
> > > > either rename it to eth2 in /e/n/i, or kill the rule that
> > > > advances the name. Since those old dells only come with one
> > > > port, I'd much druther have a fixed name.
> > > >
> > > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0
> > > > remains eth0 regardless of which box I put that drive in?
> > > >
> > > > Thanks.
> > > >
> > > > 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 
> > >
> > > I usually just blow away /etc/udev/rules.d/70-persistent-net.rules
> > > to solve stuff like that... I'm not absolutely sure that's the
> > > same in Wheezy though.
> >
> > I'll do it, but the date on it is today, so I suspect something
> > in /lib/udev/rules.d is behind the re-write.  And thats probably
> > where to apply the nuclear option.  They really should have renamed
> > it 70-un-persistent-net. T'would have been a much more accurate
> > description.
>
> In spite of posts about it in -user, you are just about clueless about
> status of /etc/udev/rules.d/70-persistent-net.rules, aren't you?
>
I can read them just fine. But when written in swahili, they aren't that 
easy to understand. But first, make them do as they should do.  And 
write them in English so they can be understood.
 
> As for wheezy - deary me; we are living in the past.

Get me an rtai patched kernel for buster, running on amd64 or armhf/64, 
and I'll be running buster this time two weeks down the log. On all 5 
machines here.  If not willing to help, then don't throw stones from 
your glass house.

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: udev being an ass

[Brian]

On Tue 27 Aug 2019 at 17:22:27 -0400, Gene Heskett wrote:

> On Tuesday 27 August 2019 16:01:30 Brian wrote:
> 
> > On Tue 27 Aug 2019 at 14:27:02 -0400, Gene Heskett wrote:
> > > Greetings all;
> > >
> > > I've just swapped machines because that failed one got nailed by a
> > > lightning surge while I was in the shop with a heart attack.  3
> > > different psu's didn't restore the green led in a decade old dell,
> > > so I swapped the whole box except for the HD.
> > >
> > > But udevs UN-persistent rules have apparently run out of eth0 names,
> > > renaming the only ethernet port it has to eth2.  So I either rename
> > > it to eth2 in /e/n/i, or kill the rule that advances the name. 
> > > Since those old dells only come with one port, I'd much druther have
> > > a fixed name.
> > >
> > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains
> > > eth0 regardless of which box I put that drive in?
> >
> > The subject header is completely uninformative. The subject body is
> > unformative but unintellible.
> 
> Oh, I'd argue the point. udev has been accused of being uptight and 
> cantankerous many times before. Surely I am not the first to call it an 
> ass.
> 
> Supposedly invented to make things more stable, but here it has never 
> been in a same building with the word stable.

I would urge all users, particularly new ones, to take little notice
of this opinion. The OP has a track record of lacing his posts with
criticism of core components of the Debian system. Generally without
evidence and, nearly always, obscuring the point he wants to make.

> OTOH, Brian, since I actually do use computers to do useful work, 
> something that seems well beyond your ability to comprehend why I should 
> want them to do real work, I will continue asking them to Just Do It. 
> Sharpening fingers pointed in my direction will generally be ignored, 
> once I have ascertained the source.
> 
> > (P.S.
> > Could we have posts without medical details. They make me feel quesy).
> 
> Life, fully lived, can and will have its queasy moments.  Perhaps you are 
> overdue of an annual physical?

I leave my family and personal matters behind when I post here. I
do not expect to encounter those from others. Taking a hint is not
your strong point, is it?

-- 
Brian.

Re: udev being an ass

[David Wright]

On Tue 27 Aug 2019 at 21:39:52 (+0100), Brian wrote:
> On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:
> > On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> > > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett  wrote:
> > > >
> > > > I've just swapped machines because that failed one got nailed by a
> > > > lightning surge while I was in the shop with a heart attack.  3
> > > > different psu's didn't restore the green led in a decade old dell,
> > > > so I swapped the whole box except for the HD.
> > > >
> > > > But udevs UN-persistent rules have apparently run out of eth0 names,
> > > > renaming the only ethernet port it has to eth2.  So I either rename
> > > > it to eth2 in /e/n/i, or kill the rule that advances the name. 
> > > > Since those old dells only come with one port, I'd much druther have
> > > > a fixed name.
> > > >
> > > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains
> > > > eth0 regardless of which box I put that drive in?
> > > >
> > > > Thanks.
> > >
> > > I usually just blow away /etc/udev/rules.d/70-persistent-net.rules to
> > > solve stuff like that... I'm not absolutely sure that's the same in
> > > Wheezy though.
> > 
> > I'll do it, but the date on it is today, so I suspect something 
> > in /lib/udev/rules.d is behind the re-write.  And thats probably where 
> > to apply the nuclear option.  They really should have renamed it 
> > 70-un-persistent-net. T'would have been a much more accurate 
> > description.
> 
> In spite of posts about it in -user, you are just about clueless about
> status of /etc/udev/rules.d/70-persistent-net.rules, aren't you?
> 
> As for wheezy - deary me; we are living in the past.

Evidently, Gene never got round to writing the script mentioned in:
https://lists.debian.org/debian-user/2016/05/msg00707.html
which would have cleaned /etc/udev/rules.d/70-persistent-net.rules
already.

Cheers,
David.

Re: udev being an ass

[David Wright]

On Tue 27 Aug 2019 at 16:13:25 (-0400), Greg Wooledge wrote:
> On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote:
> > I'll do it, but the date on it is today, so I suspect something 
> > in /lib/udev/rules.d is behind the re-write.
> 
> If that file exists, it's used.  Quotes in the file are ignored.  Valid
> content in the file is used to map various interfaces (typically identified
> by their MAC addresses) to interface names.
> 
> If the file does not exist, it will be (re)created.
> 
> If the file exists, but your interface isn't in it (as determined by
> whatever criteria are being used to identify the interface, typically the
> MAC address), then a new name will be assigned for it (skipping the
> names that are already in use), and this will be written to the file.
> 
> So, the suggestion was to remove the file from the system before
> replacing all your interfaces (or moving the hard drive to a new
> computer, which from the hard drive's point of view is equivalent to
> "you replaced all the interfaces").  In that situation, the file doesn't
> exist, so it will be created from scratch.  You've got one or more
> interfaces that don't (yet) have assigned names, so names will be
> assigned to them.  One of them will become eth0, one of them will become
> eth1, and so on, depending on how many interfaces there are in the new
> machine.
> 
> If you have exactly one interface, it will become eth0, and you will be
> happy.
> 
> If you have more than one interface, you have no way of knowing which
> one will become eth0.  That's the situation the newfangled thing was
> intended to remedy, but it doesn't really succeed at that either.

I think you're being oblique. There's a race. The udev method was not
designed to eliminate that, but to make sure that the resulting names
would forever be the same, once the race has been run the first time.

In the past, when I have had a mobo fail and moved everything into
a spare box, I've found that the new machine (I assume it's the CMOS
sensu lato) is happiest when you add one card at a time, run the
POST and let the CMOS deal with it; then add the next.
In a similar manner, you *could* fix the race by booting up linux
with one new interface at a time …

> In almost every situation, you need to let the computer ASSIGN the names
> first, then login to it and see what interface got what name, and then
> adjust your configs accordingly.

… but really there's no need, because it's obvious from the rules file
what is going on.

  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
  ATTR{address}=="00:a0:24:93:4d:8e", ATTR{dev_id}=="0x0", \
  ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
  ATTR{address}=="00:a0:24:b8:63:b5", ATTR{dev_id}=="0x0", \
  ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

There's a machine with two 3Com NICs. If you don't like the
allocation, you just switch eth0 and eth1. (One assumes that the
backplanes have been physically marked so that the connectors
themselves can be distinguished.) So you don't need to touch
your configuration, by which I assume you mean /e/n/i and suchlike.

> I do not know of any way around this, other than only ever having one
> interface per computer, which may work OK in some situations, but
> definitely not in others.

Cheers,
David.

Re: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 16:01:30 Brian wrote:

> On Tue 27 Aug 2019 at 14:27:02 -0400, Gene Heskett wrote:
> > Greetings all;
> >
> > I've just swapped machines because that failed one got nailed by a
> > lightning surge while I was in the shop with a heart attack.  3
> > different psu's didn't restore the green led in a decade old dell,
> > so I swapped the whole box except for the HD.
> >
> > But udevs UN-persistent rules have apparently run out of eth0 names,
> > renaming the only ethernet port it has to eth2.  So I either rename
> > it to eth2 in /e/n/i, or kill the rule that advances the name. 
> > Since those old dells only come with one port, I'd much druther have
> > a fixed name.
> >
> > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains
> > eth0 regardless of which box I put that drive in?
>
> The subject header is completely uninformative. The subject body is
> unformative but unintellible.

Oh, I'd argue the point. udev has been accused of being uptight and 
cantankerous many times before. Surely I am not the first to call it an 
ass.

Supposedly invented to make things more stable, but here it has never 
been in a same building with the word stable.

OTOH, Brian, since I actually do use computers to do useful work, 
something that seems well beyond your ability to comprehend why I should 
want them to do real work, I will continue asking them to Just Do It. 
Sharpening fingers pointed in my direction will generally be ignored, 
once I have ascertained the source.

> (P.S.
> Could we have posts without medical details. They make me feel quesy).

Life, fully lived, can and will have its queasy moments.  Perhaps you are 
overdue of an annual physical?

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: udev being an ass

[Brian]

On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:

> On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> 
> > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett  
> wrote:
> > > Greetings all;
> > >
> > > I've just swapped machines because that failed one got nailed by a
> > > lightning surge while I was in the shop with a heart attack.  3
> > > different psu's didn't restore the green led in a decade old dell,
> > > so I swapped the whole box except for the HD.
> > >
> > > But udevs UN-persistent rules have apparently run out of eth0 names,
> > > renaming the only ethernet port it has to eth2.  So I either rename
> > > it to eth2 in /e/n/i, or kill the rule that advances the name. 
> > > Since those old dells only come with one port, I'd much druther have
> > > a fixed name.
> > >
> > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains
> > > eth0 regardless of which box I put that drive in?
> > >
> > > Thanks.
> > >
> > > 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 
> >
> > I usually just blow away /etc/udev/rules.d/70-persistent-net.rules to
> > solve stuff like that... I'm not absolutely sure that's the same in
> > Wheezy though.
> 
> I'll do it, but the date on it is today, so I suspect something 
> in /lib/udev/rules.d is behind the re-write.  And thats probably where 
> to apply the nuclear option.  They really should have renamed it 
> 70-un-persistent-net. T'would have been a much more accurate 
> description.

In spite of posts about it in -user, you are just about clueless about
status of /etc/udev/rules.d/70-persistent-net.rules, aren't you?

As for wheezy - deary me; we are living in the past.

-- 
Brian.

Re: udev being an ass

[Greg Wooledge]

On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote:
> I'll do it, but the date on it is today, so I suspect something 
> in /lib/udev/rules.d is behind the re-write.

If that file exists, it's used.  Quotes in the file are ignored.  Valid
content in the file is used to map various interfaces (typically identified
by their MAC addresses) to interface names.

If the file does not exist, it will be (re)created.

If the file exists, but your interface isn't in it (as determined by
whatever criteria are being used to identify the interface, typically the
MAC address), then a new name will be assigned for it (skipping the
names that are already in use), and this will be written to the file.

So, the suggestion was to remove the file from the system before
replacing all your interfaces (or moving the hard drive to a new
computer, which from the hard drive's point of view is equivalent to
"you replaced all the interfaces").  In that situation, the file doesn't
exist, so it will be created from scratch.  You've got one or more
interfaces that don't (yet) have assigned names, so names will be
assigned to them.  One of them will become eth0, one of them will become
eth1, and so on, depending on how many interfaces there are in the new
machine.

If you have exactly one interface, it will become eth0, and you will be
happy.

If you have more than one interface, you have no way of knowing which
one will become eth0.  That's the situation the newfangled thing was
intended to remedy, but it doesn't really succeed at that either.

In almost every situation, you need to let the computer ASSIGN the names
first, then login to it and see what interface got what name, and then
adjust your configs accordingly.

I do not know of any way around this, other than only ever having one
interface per computer, which may work OK in some situations, but
definitely not in others.

Re: Xfce 4.12 to 4.14: high Xorg CPU usage

[Ben Caradoc-Davies]

On 28/08/2019 01:01, Stefan Pietsch wrote:

I upgraded Xfce to 4.14 recently (Debian unstable) and noticed slightly
delayed rendering of UI elements.
Firefox and Thunderbird behave sluggishly and CPU usage by Xorg is
significantly higher as compared to Xfce 4.12.
Did anyone who is using Xfce 4.14 observe similar effects?


Does top/htop show any process burning CPU?

I mask the colord service because I do not need it, and after upgrading 
from Xfce 4.12 to Xfce 4.14, my session acquired an xiccd process that 
sat burning 100% of one CPU (unhappy about not being able to contact 
colord?). I disabled it from my Xfce session in Settings / Session and 
Startup / Application Autostart, logged in and out, and the problem went 
away. I do not save my sessions.


Other than needing to use ~/.config/gtk-3.0/settings.ini to force all 
Xfce GTK 3 elements to use the correct font size (the setting is ignored 
for some elements), everything else works for me as well as in 4.12 and 
performance is satisfactory.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: X11 desktops on buster without systemd

[Dan Ritter]

Greg Wooledge wrote: 
> On Tue, Aug 27, 2019 at 12:54:19PM -0400, Dan Ritter wrote:
> > 6. apt install sysvinit-core elogind
> > 
> > Ideally, at this point nothing except systemd would be uninstalled. In
> > practice, currently, an awful lot of things that you might actually want
> > get uninstalled.
> 
> Like what?
> 
> wooledg:~$ apt -s install sysvinit-core elogind
> NOTE: This is only a simulation!
> [...]
> The following packages will be REMOVED:
>   colord libnss-systemd libpam-systemd policykit-1 systemd systemd-sysv
> The following NEW packages will be installed:
>   elogind initscripts insserv libelogind0 startpar sysv-rc sysvinit-core
> 0 upgraded, 7 newly installed, 6 to remove and 1 not upgraded.
> [...]

Start-Date: 2019-08-27  11:57:30

Commandline: apt install sysvinit-core elogind  

Install: startpar:amd64 (0.61-1, automatic), insserv:amd64
(1.18.0-2, automatic), elogind:amd64 (239.3+20190131-1+debian1),
sysvinit-core:amd64 (2.93-8), initscripts:amd64 (2.93-8,
automatic), libelogind0:amd64 (239.3+20190131-1+debian1,
automatic), sysv-rc:amd64 (2.93-8, automatic)
Remove: gnome-color-manager:amd64 (3.30.0-2),
gnome-session:amd64 (3.30.1-2), gvfs-backends:amd64 (1.38.1-5),
gnome-control-center:amd64 (1:3.30.3-1), brasero:amd64
(3.12.2-5), chrome-gnome-shell:amd64 (10.1-5), rtkit:amd64
(0.11-6), gnome-software:amd64 (3.30.6-5),
gnome-settings-daemon:amd64 (3.30.2-3), plymouth-label:amd64
(0.9.4-1.1), light-locker:amd64 (1.8.0-3),
network-manager-gnome:amd64 (1.8.20-1.1), gnome-sushi:amd64
(3.30.0-2), gdm3:amd64 (3.30.2-3), iio-sensor-proxy:amd64
(2.4-2), network-manager:amd64 (1.14.6-2),
packagekit-tools:amd64 (1.1.12-5), gnome-tweak-tool:amd64
(3.30.2-1), gnome-disk-utility:amd64 (3.30.2-3),
gnome-tweaks:amd64 (3.30.2-1), gnome-music:amd64 (3.30.2-1),
udisks2:amd64 (2.8.1-4), gvfs-fuse:amd64 (1.38.1-5),
nautilus:amd64 (3.30.5-2), task-gnome-desktop:amd64 (3.53),
systemd-sysv:amd64 (241-5), libpam-systemd:amd64 (241-5),
packagekit:amd64 (1.1.12-5), systemd:amd64 (241-5),
gnome-core:amd64 (1:3.30+1), libnss-systemd:amd64 (241-5),
gnome:amd64 (1:3.30+1), gnome-shell-extensions:amd64 (3.30.1-1),
plymouth:amd64 (0.9.4-1.1), policykit-1:amd64 (0.105-25),
gvfs:amd64 (1.38.1-5), gnome-shell:amd64 (3.30.2-9),
dbus-user-session:amd64 (1.12.16-1),
nautilus-extension-brasero:amd64 (3.12.2-5), synaptic:amd64
(0.84.6), gstreamer1.0-packagekit:amd64 (1.1.12-5),
gvfs-daemons:amd64 (1.38.1-5), lightdm:amd64 (1.26.0-4),
colord:amd64 (1.4.3-4)
End-Date: 2019-08-27  11:59:02

Re: udev being an ass

[Brian]

On Tue 27 Aug 2019 at 14:27:02 -0400, Gene Heskett wrote:

> Greetings all;
> 
> I've just swapped machines because that failed one got nailed by a 
> lightning surge while I was in the shop with a heart attack.  3 
> different psu's didn't restore the green led in a decade old dell, so I 
> swapped the whole box except for the HD.
> 
> But udevs UN-persistent rules have apparently run out of eth0 names, 
> renaming the only ethernet port it has to eth2.  So I either rename it 
> to eth2 in /e/n/i, or kill the rule that advances the name.  Since those 
> old dells only come with one port, I'd much druther have a fixed name.
> 
> What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains eth0 
> regardless of which box I put that drive in?

The subject header is completely uninformative. The subject body is
unformative but unintellible.

(P.S.
Could we have posts without medical details. They make me feel quesy).

-- 
Brian

Re: comando com timecount

[jmhenrique]

$ sleep 20 ; comando 
#executa comando depois de 20 segundos

$sleep 1m ; comando 
#executa comando depois de 1 minuto 

#e por aí vai. 

Tem quem questione o ";" ao invés de "&&" . Vai depender do que você pretende 
obter. 





--
Enviado do meu BlackBerry



  Mensagem Original  



De: vitorhug...@hotmail.com
Enviados: 27 de agosto de 2019 12:02
Para: debian-user-portuguese@lists.debian.org
Assunto: comando com timecount


Como eu faço para um comando ser executado depois de um determinado
período de tempo.

Re: MY EXPERIENCE WITH BUSTER

[Dan Ritter]

bcciv wrote: 
> I have used Debian for over 16 years (started with kernel 2.4). I recently 
> downloaded Buster to update my machines which are currently running Stretch.  
> I like to keep one of my machines offline - always - for added security.  So 
> I downloaded the first 3 iso's and used jigdo for the remaining iso's.  
> (jigdo takes hours while an iso takes minutes but I like saving your 
> bandwidth)  I like LXDE even though I used KDE for most of the first 15 
> years.  I love konqueror as my GUI file manager.  So I installed it as usual. 
>  It will not invoke. Reinstalled. Still not able to use it.  I went to a 
> different machine still using stretch and looked to see what dependencies 
> synaptic listed for konqueror and compared the dependencies listed for 
> konqueror on Buster.  I ended up installing kde-baseapps and kde-runtime from 
> my dvd's.  Konqueror invoked on the first try, then refused to invoke again.  
> Dolphin requests I send a bug report when I invoke it, and Abiword crashes 
> when I try to click on preferences.  Out of desperation I put the machine 
> online, and used Berkley.edu repositories to update anything.  It did not 
> change any of the problems.  I will now probably trash all 16 dvd's since I 
> no longer trust them (all sha256sums were correct).  What a waste of time and 
> bandwidth.  Apparently I have to go back to Debian 9 to work with the 
> programs I like.  Also to work without fears of more hidden problems.  I will 
> probably hang on to the dvd's for a short time since I do not like to act 
> impulsively.  But how long I am not sure since I see no way to trust them 
> again.
> bc
> 

Have you considered:

1. Using linebreaks?

2. Asking questions?

3. Refraining from panic?

-dsr-

Re: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 14:58:37 Tyler D wrote:

> On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett  
wrote:
> > Greetings all;
> >
> > I've just swapped machines because that failed one got nailed by a
> > lightning surge while I was in the shop with a heart attack.  3
> > different psu's didn't restore the green led in a decade old dell,
> > so I swapped the whole box except for the HD.
> >
> > But udevs UN-persistent rules have apparently run out of eth0 names,
> > renaming the only ethernet port it has to eth2.  So I either rename
> > it to eth2 in /e/n/i, or kill the rule that advances the name. 
> > Since those old dells only come with one port, I'd much druther have
> > a fixed name.
> >
> > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains
> > eth0 regardless of which box I put that drive in?
> >
> > Thanks.
> >
> > 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 
>
> I usually just blow away /etc/udev/rules.d/70-persistent-net.rules to
> solve stuff like that... I'm not absolutely sure that's the same in
> Wheezy though.

I'll do it, but the date on it is today, so I suspect something 
in /lib/udev/rules.d is behind the re-write.  And thats probably where 
to apply the nuclear option.  They really should have renamed it 
70-un-persistent-net. T'would have been a much more accurate 
description.

Thanks.

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: debian et UEFI

[Étienne Mollier]

On 27/08/2019 20.20, Basile Starynkevitch wrote:
> Puis-je configurer cet UEFI depuis Debian en ligne de commande? Par exemple, 
> l'ordre de boot, l'overclocking léger, le redémarrage automatique, etc. Si 
> oui, comment?

Bonsoir Basile,

Sans avoir creusé dans les arcanes de cette commande (et sans
machine UEFI à portée de main à l'instant /t/), je dirais que
efibootmgr est censé savoir gérer au moins une fraction de ce
cahier des charges :

$ apt show efibootmgr
[...]
Description: Interact with the EFI Boot Manager
 This is a Linux user-space application to modify the Intel Extensible
 Firmware Interface (EFI) Boot Manager configuration. This application 
can
 create and destroy boot entries, change the boot order, change the next
 running boot option, and more.

Amicalement,
-- 
Étienne Mollier 
  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d



signature.asc
Description: OpenPGP digital signature

Re: udev being an ass

[Tyler D]

On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett  wrote:
>
> Greetings all;
>
> I've just swapped machines because that failed one got nailed by a
> lightning surge while I was in the shop with a heart attack.  3
> different psu's didn't restore the green led in a decade old dell, so I
> swapped the whole box except for the HD.
>
> But udevs UN-persistent rules have apparently run out of eth0 names,
> renaming the only ethernet port it has to eth2.  So I either rename it
> to eth2 in /e/n/i, or kill the rule that advances the name.  Since those
> old dells only come with one port, I'd much druther have a fixed name.
>
> What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains eth0
> regardless of which box I put that drive in?
>
> Thanks.
>
> 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 
>

I usually just blow away /etc/udev/rules.d/70-persistent-net.rules to
solve stuff like that... I'm not absolutely sure that's the same in
Wheezy though.

udev being an ass

[Gene Heskett]

Greetings all;

I've just swapped machines because that failed one got nailed by a 
lightning surge while I was in the shop with a heart attack.  3 
different psu's didn't restore the green led in a decade old dell, so I 
swapped the whole box except for the HD.

But udevs UN-persistent rules have apparently run out of eth0 names, 
renaming the only ethernet port it has to eth2.  So I either rename it 
to eth2 in /e/n/i, or kill the rule that advances the name.  Since those 
old dells only come with one port, I'd much druther have a fixed name.

What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains eth0 
regardless of which box I put that drive in?

Thanks. 

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 

debian et UEFI

[Basile Starynkevitch]

Bonjour,


J'ai une carte mère MSI X399 SLI Plus 
 avec un processeur AMD 
2970WX sous Debian/Testing (et bien sûr, aucun système microsoftien), 
plusieurs disques, 64Go de RAM.


Je connais mal (à cause de mon âge, 60 ans) le UEFI 
 
(dont j'ai pourtant parcouru quelques spécifications  
programmatiques). Je lis et écris 
 l'anglais 
technique sans souci.


Puis-je configurer cet UEFI depuis Debian en ligne de commande? Par 
exemple, l'ordre de boot, l'overclocking léger, le redémarrage 
automatique, etc. Si oui, comment?


L'interface clickodromatique de mon BIOS/UEFI (au démarrage) est très 
urticante, car j'ai tendance à être allergique à la souris. Dans mes 
rêves les plus fous, je souhaiterais même avoir un CoreBoot 
, mais je ne veux pas risquer de briquer ma 
belle machine, donc je reste raisonnablement avec mon UEFI.


Que faire?


Cordialement


--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France; 
(mobile phone: cf my web page / voir ma page web...)

Re: X11 desktops on buster without systemd

[Greg Wooledge]

On Tue, Aug 27, 2019 at 12:54:19PM -0400, Dan Ritter wrote:
> 6. apt install sysvinit-core elogind
> 
> Ideally, at this point nothing except systemd would be uninstalled. In
> practice, currently, an awful lot of things that you might actually want
> get uninstalled.

Like what?

wooledg:~$ apt -s install sysvinit-core elogind
NOTE: This is only a simulation!
[...]
The following packages will be REMOVED:
  colord libnss-systemd libpam-systemd policykit-1 systemd systemd-sysv
The following NEW packages will be installed:
  elogind initscripts insserv libelogind0 startpar sysv-rc sysvinit-core
0 upgraded, 7 newly installed, 6 to remove and 1 not upgraded.
[...]

MY EXPERIENCE WITH BUSTER

[bcciv]

I have used Debian for over 16 years (started with kernel 2.4). I recently 
downloaded Buster to update my machines which are currently running Stretch.  I 
like to keep one of my machines offline - always - for added security.  So I 
downloaded the first 3 iso's and used jigdo for the remaining iso's.  (jigdo 
takes hours while an iso takes minutes but I like saving your bandwidth)  I 
like LXDE even though I used KDE for most of the first 15 years.  I love 
konqueror as my GUI file manager.  So I installed it as usual.  It will not 
invoke. Reinstalled. Still not able to use it.  I went to a different machine 
still using stretch and looked to see what dependencies synaptic listed for 
konqueror and compared the dependencies listed for konqueror on Buster.  I 
ended up installing kde-baseapps and kde-runtime from my dvd's.  Konqueror 
invoked on the first try, then refused to invoke again.  Dolphin requests I 
send a bug report when I invoke it, and Abiword crashes when I try to click on 
preferences.  Out of desperation I put the machine online, and used Berkley.edu 
repositories to update anything.  It did not change any of the problems.  I 
will now probably trash all 16 dvd's since I no longer trust them (all 
sha256sums were correct).  What a waste of time and bandwidth.  Apparently I 
have to go back to Debian 9 to work with the programs I like.  Also to work 
without fears of more hidden problems.  I will probably hang on to the dvd's 
for a short time since I do not like to act impulsively.  But how long I am not 
sure since I see no way to trust them again.
bc

Sent with [ProtonMail](https://protonmail.com) Secure Email.

X11 desktops on buster without systemd

[Dan Ritter]

Thanks largely to posts on the debian-init-diversity mailing list,
I have a VM running with buster and XFCE4 without systemd.

The process is not great, but it is doable:

I started with a fresh stretch VM (since I wanted to test upgrading
into buster.)

1. Change /etc/apt/sources.list entries to point to buster
2. apt update && apt dist-upgrade
3. shutdown -r now

The system is now buster and systemd.
You might want to dump a list of packages now:
dpkg --get-selections > packagelist

4. apt install -d sysvinit-core elogind

5. shutdown -r now

reboot, but pause the bootloader to make your init=/bin/sh

6. apt install sysvinit-core elogind

Ideally, at this point nothing except systemd would be uninstalled. In
practice, currently, an awful lot of things that you might actually want
get uninstalled.

7. echo needs_root_rights=yes >> /etc/X11/Xwrapper.config

8. shutdown -r now

9. re-install packages that you wanted. Good thing you have that
list, right?

At some point in the future I will try this on a laptop, and if
successful, on my main desktop.

-dsr-

Re: Re : Re : Debian sur clé USB

[hamster]

Le 27/08/2019 à 17:36, nicolas.patr...@gmail.com a écrit :
> Le 27/08/2019 15:07:49, hamster a écrit :
>> Le 27/08/2019 à 16:48, nicolas.patr...@gmail.com a écrit :
>>> J’ai trouvé le fil mais je ne suis pas sûr que le système lui-même
>>> soit modifiable, c’est-à-dire que la mise à jour ou l’installation de
>>> paquets soient elles aussi persistantes.
>> Si si.
> L’étiquette live-rw fait donc tout, pas seulement office de /home ?
> Quand j’ai créé la clé avec gnome-disks, lui voit deux partitions plus un 
> espace libre, gparted ne voit qu’une image en iso9660, cfdisk ne voit rien du 
> tout.

Une partition contient le système en lecture seule tel qu'il a été
installé (y compris home) et n'est jamais modifiée. Quand on utilise la
clef comme ca, les changements par rapport a ce qui a été installé sont
stockés dans un système de fichiers en mémoire vive, raison pour
laquelle tous les changements sont perdus après redémarrage.

Quand on rajoute l'option "persistance" ca rajoute une partition appelée
"casper" qui stocke les changements par rapport a ce qui a été installé.
Cette partition ne stocke que les changements, autant pour le système
que pour /home. De l'interieur du système ca ne se voit pas. Quand on
demande un fichier, si il a pas été modifié il est pris dans la
partition en lecture seule, si il a été modifié il est pris dans la
partition casper.

Re: comando com timecount

[Leandro Guimarães Faria Corcete DUTRA]

Le mardi 27 août 2019 à 12:29 +, Vitor Hugo a écrit :
> Como eu faço para um comando ser executado depois de um determinado 
> período de tempo.

Não tenho certeza, mas dê um man time ou time --help.



-- 
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 99302 2691   http://en.dutras.org/
BRAZIL GMT−3
https://useplaintext.email/#why-plaintext

Re: trying to grab video of screen on a Thinkpad x130e netbook . . .

[Albretch Mueller]

On 8/24/19, Pétùr  wrote:
> ffmpeg -f x11grab -s 1280x720 -r 25 -i :0.0 screencast.mp4

 but where did the audio go?

 it worked but not always. base on its logs ffmpeg seems to be making
a video, but vlc doesn't show to me the actual video even though the
file is there.

 Why is it that the video is recorded and displayed in some cases onle?

 lbrtchx

Re : Re : Debian sur clé USB

[nicolas . patrois]

Le 27/08/2019 15:07:49, hamster a écrit :
> Le 27/08/2019 à 16:48, nicolas.patr...@gmail.com a écrit :

>> J’ai trouvé le fil mais je ne suis pas sûr que le système lui-même
>> soit modifiable, c’est-à-dire que la mise à jour ou l’installation de
>> paquets soient elles aussi persistantes.

> Si si.

L’étiquette live-rw fait donc tout, pas seulement office de /home ?
Quand j’ai créé la clé avec gnome-disks, lui voit deux partitions plus un 
espace libre, gparted ne voit qu’une image en iso9660, cfdisk ne voit rien du 
tout.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: Re : Debian sur clé USB

[hamster]

Le 27/08/2019 à 16:48, nicolas.patr...@gmail.com a écrit :
> Le 27/08/2019 14:12:03, hamster a écrit :
>
>> Cette question a déjà été posée sur cette même liste le 02/08/2019 à
>> 18:45. Il y a eu 4 réponses qui expliquent la marche a suivre. Plutôt
>> que de répéter, je te laisse aller lire ces messages.
> J’ai trouvé le fil mais je ne suis pas sûr que le système lui-même soit 
> modifiable, c’est-à-dire que la mise à jour ou l’installation de paquets 
> soient elles aussi persistantes.

Si si.

Re: Xfce 4.12 to 4.14: high Xorg CPU usage

[Sven Hartge]

Stefan Pietsch  wrote:

> I upgraded Xfce to 4.14 recently (Debian unstable) and noticed
> slightly delayed rendering of UI elements.

> Firefox and Thunderbird behave sluggishly and CPU usage by Xorg is
> significantly higher as compared to Xfce 4.12.

> Did anyone who is using Xfce 4.14 observe similar effects?

Have you tried switching off compositing via Window Manager Tweaks in
the XFCE settings?

Grüße,
Sven.

-- 
Sigmentation fault. Core dumped.

comando com timecount

[Vitor Hugo]

Como eu faço para um comando ser executado depois de um determinado 
período de tempo.

Re: why won't ff look at this url?

[mett]

On 2019年8月27日 8:09:16 JST, Doug McGarrett  wrote:
>
>
>On 08/26/2019 03:22 PM, Andrei POPESCU wrote:
>> On Sb, 24 aug 19, 10:21:59, Gene Heskett wrote:
>>> Greetings folks;
>>>
>>>
>https://abcnews4.com/news/nation-world/w-va-ambulance-ems-director-arrested-accused-of-missing-and-tampering-with-narcotics
>>>
>>> All I get for clicking on it is a blank screen.
>>
>> Two things you could try:
>>
>>  1. firefox --safe-mode
>>  2. stop Firefox, rename ~/.mozilla (i.e. where your profile is)
>and
>>  start Firefox
>>
>> Hope this helps,
>> Andrei
>>
>I don't know what this means, but in OpenSuse Tumbleweed with FossaMail
>
>and Thunderbird, the URL opens perfectly.
>--doug

Not opening in android foss browser.
Opening in android zirco browser.

Re : Debian sur clé USB

[nicolas . patrois]

Le 27/08/2019 14:12:03, hamster a écrit :

> Cette question a déjà été posée sur cette même liste le 02/08/2019 à
> 18:45. Il y a eu 4 réponses qui expliquent la marche a suivre. Plutôt
> que de répéter, je te laisse aller lire ces messages.

J’ai trouvé le fil mais je ne suis pas sûr que le système lui-même soit 
modifiable, c’est-à-dire que la mise à jour ou l’installation de paquets soient 
elles aussi persistantes.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: lenteur maladive

[Basile Starynkevitch]

On 8/27/19 4:17 PM, hamster wrote:

Le 09/08/2019 à 02:09, hamster a écrit :

Le 07/08/2019 à 13:16, Daniel Caillibaud a écrit :

Le 05/08/19 à 19:59, hamster  a écrit :

De temps en temps, le processeur se bloque a 800 MHz, c'est dans ces
moments la qu'il est particulièrement lent. Pourtant toutes les
températures sont en dessous de 60 °C.

Alors tu as peut-être qqchose qui fait passer ton processeur en mode économe en 
énergie,
regarde dans les réglages d'énergie.

Ou alors c'est un réglage bios ou OS qui le fait passer dans ce mode quand la 
batterie est
faible…

J'ai flashé le BIOS et après quelques redémarrages l'horloge s'est
décalée d'une heure et les problèmes de lenteur ont disparu. Reste a
voir si ca tiendra dans la durée.

Ca n'a pas tenu. J'ai aussi essayé de changer la pile du BIOS mais ca
n'améliore pas.

Ce problème de lenteur se manifeste de temps en temps de facon
aléatoire, mais quand il se manifeste j'ai remarqué que c'est lié a la
présence de la prise secteur. Sur batterie il tourne impeccable, quand
je branche son alim secteur il se met immédiatement a ramer de facon
rhédibitoire et quand je débranche l'alim il se remet immédiatement a
tourner a sa vitesse normale.

Et puis il y a aussi des moments ou il tourne bien meme branché sur le
secteur.



Ca évoque un problème matériel, qui ne dépendrait pas du système 
d'exploitation. J'irais voir un réparateur, ou bien j'envisagerais (si 
la machine est vieille donc amortie) le remplacement de l'ordinateur 
portable (ou peut-être de son alimentation secteur ou de sa batterie).


Librement

--
Basile STARYNKEVITCH   == http://starynkevitch.net/Basile
opinions are mine only - les opinions sont seulement miennes
Bourg La Reine, France; 
(mobile phone: cf my web page / voir ma page web...)

Re: lenteur maladive

[hamster]

Le 09/08/2019 à 02:09, hamster a écrit :
> Le 07/08/2019 à 13:16, Daniel Caillibaud a écrit :
>> Le 05/08/19 à 19:59, hamster  a écrit :
>>> De temps en temps, le processeur se bloque a 800 MHz, c'est dans ces
>>> moments la qu'il est particulièrement lent. Pourtant toutes les
>>> températures sont en dessous de 60 °C.
>> Alors tu as peut-être qqchose qui fait passer ton processeur en mode économe 
>> en énergie,
>> regarde dans les réglages d'énergie.
>>
>> Ou alors c'est un réglage bios ou OS qui le fait passer dans ce mode quand 
>> la batterie est
>> faible…
> J'ai flashé le BIOS et après quelques redémarrages l'horloge s'est
> décalée d'une heure et les problèmes de lenteur ont disparu. Reste a
> voir si ca tiendra dans la durée.

Ca n'a pas tenu. J'ai aussi essayé de changer la pile du BIOS mais ca
n'améliore pas.

Ce problème de lenteur se manifeste de temps en temps de facon
aléatoire, mais quand il se manifeste j'ai remarqué que c'est lié a la
présence de la prise secteur. Sur batterie il tourne impeccable, quand
je branche son alim secteur il se met immédiatement a ramer de facon
rhédibitoire et quand je débranche l'alim il se remet immédiatement a
tourner a sa vitesse normale.

Et puis il y a aussi des moments ou il tourne bien meme branché sur le
secteur.

Re : Debian sur clé USB

[nicolas . patrois]

Le 27/08/2019 14:12:03, hamster a écrit :

> Cette question a déjà été posée sur cette même liste le 02/08/2019 à
> 18:45. Il y a eu 4 réponses qui expliquent la marche a suivre. Plutôt
> que de répéter, je te laisse aller lire ces messages.

Je n’ai pas eu internet pendant un mois dont ce jour-là donc je n’ai pas vu 
passer ce fil.
Merci quand même du tuyau.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: Debian sur clé USB

[hamster]

Le 27/08/2019 à 15:07, nicolas.patr...@gmail.com a écrit :
> Bonjour,
>
> J’ai installé Debian sur une clé USB pour un EEEPC 900 (la clé est sur la 
> prise USB de gauche).
> Je n’ai pas trouvé comment la rendre persistante, c’est-à-dire comment 
> conserver ce que je fais.

Cette question a déjà été posée sur cette meme liste le 02/08/2019 à
18:45. Il y a eu 4 réponses qui expliquent la marche a suivre. Plutot
que de répeter, je te laisse aller lire ces messages.

Re : Debian sur clé USB

[nicolas . patrois]

Le 27/08/2019 13:21:07, Daniel Huhardeaux a écrit :

> Lorsqu'elle est montée, elle est bien en rw ?

> Ex mount:
> /dev/sdXN on / type  
> (rw,relatime,discard,errors=remount-ro,data=ordered)

Non et j’ai une partition /dev/sdc1 vide selon cfdisk, montée en iso9660 selon 
mount sur /run/live/medium et sur /usr/lib/live/mount/medium.
La clé contient une deuxième partition /dev/sdc2 en FAT32 mais elle n’est pas 
montée.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: Debian sur clé USB

[Daniel Huhardeaux]

Le 27/08/2019 à 15:07, nicolas.patr...@gmail.com a écrit :

Bonjour,


Bonjour



J’ai installé Debian sur une clé USB pour un EEEPC 900 (la clé est sur la prise 
USB de gauche).
Je n’ai pas trouvé comment la rendre persistante, c’est-à-dire comment 
conserver ce que je fais.


Lorsqu'elle est montée, elle est bien en rw ?

Ex mount:
/dev/sdXN on / type  
(rw,relatime,discard,errors=remount-ro,data=ordered)


--
Daniel

Re: Debian sur clé USB

[fab]

'lut,

Je ne réponds pas directement à la question. Mais, depuis quelques mois, 
j'utilise une clé tails (basée sur debian donc) avec un espace chiffré 
sur la clé pour conserver les infos perso.


https://tails.boum.org/

a+

f.


Le 27/08/2019 à 15:07, nicolas.patr...@gmail.com a écrit :

Bonjour,

J’ai installé Debian sur une clé USB pour un EEEPC 900 (la clé est sur la prise 
USB de gauche).
Je n’ai pas trouvé comment la rendre persistante, c’est-à-dire comment 
conserver ce que je fais.

nicolas patrois : pts noir asocial

Xfce 4.12 to 4.14: high Xorg CPU usage

[Stefan Pietsch]

Dear list,

I upgraded Xfce to 4.14 recently (Debian unstable) and noticed slightly
delayed rendering of UI elements.

Firefox and Thunderbird behave sluggishly and CPU usage by Xorg is
significantly higher as compared to Xfce 4.12.

Did anyone who is using Xfce 4.14 observe similar effects?


Regards,
Stefan

Debian sur clé USB

[nicolas . patrois]

Bonjour,

J’ai installé Debian sur une clé USB pour un EEEPC 900 (la clé est sur la prise 
USB de gauche).
Je n’ai pas trouvé comment la rendre persistante, c’est-à-dire comment 
conserver ce que je fais.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? 
Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Re: OT: AI

[rhkramer]

Ok, I'm going to try to restrain myself after this:

It is possible though, that in one of the other universes, some of us are 
real.  (Wouldn't that be something to see!)  

(Aside: Are there multiverses of multiverses?)

On Monday, August 26, 2019 07:27:00 AM rhkra...@gmail.com wrote:
> Oh, wait, never mind, it turns out we're all just a simulation, so it
> really doesn't matter.

Re: (deb-cat) Obrir-enfocar mes documents amb Nautilus/Gnome

[Narcis Garcia]

__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 27/8/19 a les 0:26, Alex Muntada ha escrit:
> Hola Narcis,
> 
>>> De forma gràfica, es pot jugar amb diferents combinacions
>>> d'efectes de focus a les finestres a l'apartat "Finestres"
>>> de l'aplicació "Ajustaments" que es troba dins del grup
>>> "Eines del sistema" al menú de Gnome. Des de consola:
>>> /usr/bin/gnome-tweaks
>>>
>>> En concret, hi ha una opció que diu: "Eleva les finestres
>>> quan tinguin el focus". Falta saber si obrir un nou document
>>> des de Nautilus > transfereix el focus a l'aplicació que ha
>>> de gestionar el document.
>>>
>>
>> No trobo aquest «Eleva les finestres...» al gnome tweaks.
>> A quina secció exactament?
> 
> Tal com deia en Robert, a l'apartat «Finestres». És un botó
> que surt al final de tot.
> 
> Utilitzant el «dconf watch /» que vas esmentar l'altre dia diu:
> 
>   /org/gnome/desktop/wm/preferences/auto-raise
> true

Ara ho he trobat; ho tenia atenuat perquè està deshabilitat i no m'ho
deixa habilitar.
He provat de formçar-ho via Terminal:
$ gsettings set org.gnome.desktop.wm.preferences auto-raise true
i, si bé canvia la posició del llisquet, segueix atenuat i no té efecte.

Gràcies.

Heads-up for bullseye users: systemd 242-4 migrated to testing

[Andrei POPESCU]

On Jo, 22 aug 19, 09:55:07, Andrei POPESCU wrote:
> systemd 242-1 contains also this change:
> 
>* Drop Revert-udev-network-device-renaming-immediately-give.patch.
>  This patch needs ongoing maintenance work to be adapted to new 
>  releases and fails to apply with v242. Instead of investing more 
>  time into it we are going to drop the patch as it was a hack 
>  anyway.
> 
> In case you rely on the udev renaming mechanism now would be a good time 
> to switch to the new scheme.

This is now in testing/bullseye.

https://tracker.debian.org/news/1057675/systemd-242-4-migrated-to-testing/

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


signature.asc
Description: PGP signature