Question on 'dpkg --get-selections'

[Marc Shapiro]

Is there any option to have 'dpkg --get-selections' NOT include 
automatically installed packages?  Otherwise, all packages show as 
manually installed, including those that would otherwise have been 
automatically installed.



Marc

Re: spurious CR/LF on tty (was: how to remove GUI)

[David Wright]

On Fri 11 Sep 2020 at 15:18:10 (-0400), Felix Miata wrote:
> Greg Wooledge composed on 2020-09-11 11:42 (UTC-0400):
> > On Fri, Sep 11, 2020 at 10:35:46 -0500, David Wright wrote:
> 
> >> That's the first mention of this phenomenon I recall seeing since I posted
> >> https://lists.debian.org/debian-user/2018/03/msg01030.html
> >> (which dealt mainly with a more serious problem).
> 
> >> I never install a DE/DM and all that stuff, but I get the cursor
> >> movement nonetheless. Is that what you're saying?
> 
> > It's not as serious as what you reported in the 2018 thread.  It's just
> > an occasional glitch, not easily reproducible, with a trivial workaround.
> 
> > I only mention it because once in a while, someone sees something like
> > it and freaks out, thinking the computer is locked up or whatever.  They
> > don't realize they can just hit the Enter key and get a fresh login
> > prompt, and all is fine.
> 
> I have too many installations to keep track of which exhibit this nuisance or 
> not,
> but I'm guessing most if not all Buster and Bullseye do it, and maybe even 
> Stretch
> & Jessie, which I'm rarely booting any more.

For me, it started with stretch and continues with buster (not used
bullseye yet). I installed my first stretch on the lenovo with the
more serious problem—reporting that was the only reason I also
mentioned the spurious CR. (I first thought they might be related,
of course.) I hadn't realised anybody else saw them.

Apologies to Greg, I misuderstood the import of your posting,
thinking that the CR had something to do with configuring a
graphical.target without a DM. Duh. I guess you meant that
someone new to a VC login, after always having used a DM login
in the past, might hit this bug and freak out.

Cheers,
David.

Re: Create 3D text?

[Carl Fink]

On 9/11/20 4:55 PM, Cousin Stanley wrote:

   You might try gimp 

   $ apt show gimp


   Google-ize ...

 gimp 3d text

   There will be a learning curve
   but 3d text variations seem
   virtually endless


My original request was perhaps not clear. I meant text as a 3d object.
GIMP makes flat images showing rendered text, but does not obviously have
a way to export OBJ or GLB files.

I actually did it with Blender before anyone on this list answered. I am
confirmed in my opinion that Blender is enormously feature-rich and has
the usability of controlling a jet aircraft by sending human messengers
to adjust the control surfaces with a screwdriver.

Wow, that interface is nonsense.
--
Carl Fink   nitpick...@nitpicking.com

Read my blog at blog.nitpicking.com.  Reviews!  Observations!

Re: Create 3D text?

[Cousin Stanley]

Carl Fink wrote:

> Can anyone suggest a Debian repo-installable program 
> to create 3D text ?
> 

  You might try gimp  

  $ apt show gimp


  Google-ize ...

gimp 3d text

  There will be a learning curve
  but 3d text variations seem
  virtually endless  

 
-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

Re: LEAN Debian install: Exploring task selection menu

[Fabrice BAUZAC-STEHLY]

Marco Möller writes:

> On 10.09.20 18:43, David Wright wrote:

>> So what would your version of an installer do when presented with:
>>
>>│  [*] Debian desktop environment │
>>│  [ ] ... GNOME  │
>>│  [ ] ... Xfce   │
>>│  [ ] ... KDE│
>>│  [ ] ... Cinnamon   │
>>│  [ ] ... MATE   │
>>│  [ ] ... LXDE   │

> I agree with Richard's criticism and would suggest to not present that
> first line "Debian desktop environment" at all, because it is
> redundant with the second line "... GNOME". If someone deselects the
> second line because no wanting GNOME, but does not image what the
> first line might contain, then he will be surprised that GNOME became
> anyway fully installed after the first line was still selected, a
> behaviour which makes no sense after the second line was explicitly
> not selected. It is especially annoying if you did this selection
> "mistake" on slow or expensive bandwidth. When I first time did this
> mistake, I thought, hey, maybe for a desktop they will install already
> something like network manager and other network managing tools or a
> tiny collection of enhanced editors like vim instead of vi only, maybe
> some other cute utilities. But I ended up with looong time downloading
> and installing a full blown GNOME which I actually wanted to avoid and
> therefore did unselect the second line initially.
> Best regards, Marco.

I've also been bitten by this.  I think it is a UI issue, the options
are ambiguous.  Would it be possible to simply change the dialog box as
follows?  --

  Debian desktop environments:
  [ ] ... GNOME (default)
  [ ] ... Xfce
  [ ] ... KDE
  [ ] ... Cinnamon
  [ ] ... MATE
  [ ] ... LXDE

--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Re: qemu - some confusions

[Reco]

Hi.

On Fri, Sep 11, 2020 at 09:46:54PM +0200, Kamil Jońca wrote:
> Dan Ritter  writes:
> 
> > Kamil Jo?ca wrote: 
> >> Dan Ritter  writes:
> >> 
> >> 
> >> Sorry, I do not understand.
> >> If  LSI 53c810 / 53c895a is not supported, how output
> >> "qemu-system-x86_64 -device help" should be interpreted?
> >> 
> >> KJ
> >
> > Read Reco's message.
> 
> Sorry, still does not understand that: "LSI 53c810 / 53c895a is not
> supported by qemu"

Long story short.
There was (and still is) QEMU. It does many things (and most of them
aren't restricted to x86), and it's a truly community project. Many
projects say "anyone can contribute", but in the case of the QEMU it's
actually true. That was a bright side, but there is a dark side of QEMU
- it says it can do many things, but quality of doing them varies.

On the other hand, there's libvirt, which is a Red Hat-controlled
project. These days people see it as a glorified QEMU wrapper, but
actually it can do more (but again, the quality of doing so varies).
Contrary to the QEMU, libvirt does best what Red Hat needs it to do, no
more, no less.

It's hardly surprising that Red Hat cherry-picks certain QEMU
capabilities and declares them "supported" (i.e. - "worked for our
paying customers"), and deems everything else as "not supported" (i.e. -
"you're on your own").

What (probably) Dan meant is "you're trying to use QEMU feature that is
not approved by Red Hat". By itself it does not mean that the feature in
question is somehow bad, or incomplete, or will corrupt your data or
whatever. It means exactly what's stated above, no more and no less.

Here, at this list, people are rarely using QEMU directly, without the
kludges like libvirt. The reason being - one of the few mature programs
to deal with QEMU is called virt-manager, and it's built on top of
libvirt. So, unless specified otherwise, here QEMU = libvirt, and
restrictions of the latter apply to the former.

Reco

Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

[David Christensen]

On 2020-09-11 07:21, David Wright wrote:

On Thu 10 Sep 2020 at 16:15:05 (-0700), David Christensen wrote:

On 2020-09-09 23:02, David wrote:

On Thu, 10 Sep 2020 at 11:26, David Christensen  
wrote:

On 2020-09-09 08:03, David Wright wrote:

... having been bitten by
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561



2020-09-10 14:01:58 root@tinkywinky ~
# parted /dev/disk/by-id/ata-ST3300622AS_ unit s print free
Error: The backup GPT table is corrupt, but the primary appears OK, so
that will be used.



I don't know what might have got your disk into this state, but
I'm happy that you got it fixed. My own strategy would have been
to use gdisk (my preferred partitioning program) to rewrite the
backup table from the main table (command r for the recovery menu,
then d).


Thank you for the pointer.  I will look at gdisk(8) the next time I have 
a need that I cannot figure out.




I don't think the bug affects ordinary 512/512 disks, but only
Advanced Format ones with larger block sizes, and then only if
"they" also supply an erroneous I/O value, eg:

Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes

It's possible that this only occurs with USB disks, too.
The partition can be 1MB aligned, but cryptsetup is fooled into
setting the wrong alignment, eg:

device-mapper: table: 254:1: adding target device sdb2 caused an alignment 
inconsistency:
physical_block_size=4096, logical_block_size=512, alignment_offset=0, 
start=33553920

which was produced by this partition:

/dev/sdb2  1302349824 1953521663  651171840 310.5G  c W95 FAT32 (LBA)


1302349824/2048

635913.0




So, as my notes show, for the simple life, I always create
partitions with 2MB alignment regardless of future use¹,
and always add  --align-payload 2048 to my cryptsetup
commands. This option is benign because it's the default
when the kernel doesn't supply a value. The man page says
to prefer --offset, but as I know nothing about what any
of these options actually do, I don't use --offset just
because there's no default value given for it. (I suspect
it may be the same as for --align-payload.)

¹ I don't worry about the initial BIOS boot partition.


That sounds like some hard-won knowledge.  I hope they fix the bug 
before I stumble into it.



David

Re: qemu - some confusions

[Kamil Jońca]

Dan Ritter  writes:

> Kamil Jo?ca wrote: 
>> Dan Ritter  writes:
>> 
>> 
>> Sorry, I do not understand.
>> If  LSI 53c810 / 53c895a is not supported, how output
>> "qemu-system-x86_64 -device help" should be interpreted?
>> 
>> KJ
>
> Read Reco's message.

Sorry, still does not understand that: "LSI 53c810 / 53c895a is not
supported by qemu"

Sentence: "qemu handles more cases than virt-manager" (from Reco's message) is
understandable.

KJ


-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Giving money and power to governments is like giving whiskey and
car keys to teenage boys.
-- P. J. O'Rourke

Re: [1/2 résolu] Erreur d'extraction de tarball

[Olivier Humbert]

Le 2020-09-11 20:18, l0f4r0 a écrit :

Bonjour,

11 sept. 2020 à 13:00 de Olivier Humbert :


- je décompresse l'archive créée
---> soucis

Il y a bel et bien un bogue car ce n'est pas du tout un comportement 
attendu de la part d'un utilisateur d'environnement de bureau.



J'ai regardé rapidement mais ça ressemble plus à une
fonctionnalité/sûreté qu'à un bogue pour moi...

Bien cordialement,
l0f4r0


Tu ne sembles pas parvenir à te mettre au niveau d'un utilisateur de 
base.


Je répète en détaillant :
- je compresse un dossier avec engrampa
---> aucun soucis
- je le décompresse 3 secondes plus tard avec le même engrampa sur le 
même système sur la même machine

---> engrampa ne parvient pas à extraire le dossier.

Alors, peut être qu'il y a une raison profonde, mais en attendant, ça 
n'est vraiment pas un comportement normal pour un utilisateur lambda.
Si je peux mettre des objets dans un carton et le fermer, il n'est pas 
normal que je ne puisse pas le ré-ouvrir pour récupérer mes objets 3 
secondes après.


Au minimum, il faudrait qu'engrampa donne un message d'erreur au moment 
de l'empaquetage du tarball du genre : "il n'est pas possible de 
tarballer ce répertoire à cause de x".


Ceci dit, ça ne serait qu'une solution temporaire.
En effet, puisqu'il est possible de réaliser l'opération à l'aide de la 
commande "tar -cJvf monarchive.tar.xz mondossier/", je ne vois pas ce 
qui pourrait empêcher un frontend (engrampa) de réaliser la même chose.


Voilà, j'espère que tu comprendras mieux ce message car je vais avoir du 
mal à expliquer mieux que ça je pense.


Cordialement
Olivier

Re: qemu - some confusions

[Dan Ritter]

Kamil Jo?ca wrote: 
> Dan Ritter  writes:
> 
> 
> Sorry, I do not understand.
> If  LSI 53c810 / 53c895a is not supported, how output
> "qemu-system-x86_64 -device help" should be interpreted?
> 
> KJ

Read Reco's message.

-dsr-

Re: qemu - some confusions

[Kamil Jońca]

Dan Ritter  writes:

> Kamil Jo?ca wrote: 
>> 
>> I try to migrate some my ancient virutal machines from virtualbox to
>> qemu, and some things are unclear for me.
>> 1. scsi devices:
>> 
>> --8<---cut here---start->8---
>> %qemu-system-x86_64 -device help|grep lsi  
>> name "lsi53c810", bus PCI   
>> name "lsi53c895a", bus PCI, alias "lsi"
>> --8<---cut here---end--->8---
>> 
>> but in  /usr/share/libvirt/schemas/domaincommon.rng
>> we have:
>> 
>> --8<---cut here---start->8---
>>   
>> 
>>   auto
>>   buslogic
>>   lsilogic
>>   lsisas1068
>>   vmpvscsi
>>   ibmvscsi
>>   virtio-scsi
>>   lsisas1078
>>   virtio-transitional
>>   virtio-non-transitional
>> 
>>   
>> --8<---cut here---end--->8---
>> what is relation between them?
>
> In your top cut, you have a specific SCSI adapter being selected
> for emulation.
>
> In the bottom, you have 9 different choices, of which you will
> pick one.
>
> The specific LSI 53c810 / 53c895a are not supported in qemu, but
> it's possibly that the lsilogic emulator will work.

Sorry, I do not understand.
If  LSI 53c810 / 53c895a is not supported, how output
"qemu-system-x86_64 -device help" should be interpreted?

KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
After any salary raise, you will have less money at the end of the
month than you did before.

Re: spurious CR/LF on tty (was: how to remove GUI)

[Felix Miata]

Greg Wooledge composed on 2020-09-11 11:42 (UTC-0400):

> On Fri, Sep 11, 2020 at 10:35:46 -0500, David Wright wrote:

>> That's the first mention of this phenomenon I recall seeing since I posted
>> https://lists.debian.org/debian-user/2018/03/msg01030.html
>> (which dealt mainly with a more serious problem).

>> I never install a DE/DM and all that stuff, but I get the cursor
>> movement nonetheless. Is that what you're saying?

> It's not as serious as what you reported in the 2018 thread.  It's just
> an occasional glitch, not easily reproducible, with a trivial workaround.

> I only mention it because once in a while, someone sees something like
> it and freaks out, thinking the computer is locked up or whatever.  They
> don't realize they can just hit the Enter key and get a fresh login
> prompt, and all is fine.

I have too many installations to keep track of which exhibit this nuisance or 
not,
but I'm guessing most if not all Buster and Bullseye do it, and maybe even 
Stretch
& Jessie, which I'm rarely booting any more.
-- 
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: équivalant de history -c en ZSH ?

[Fabrice BAUZAC-STEHLY]

benoit writes:

> Quant à  history -p pour zsh il arrête d'écrire après, mais ce n'est pas « 
> rétroactif ».

Pour arreter le logging, que ce soit avec bash ou zsh, on peut aussi
faire:

  unset HISTFILE

--
Fabrice BAUZAC-STEHLY
PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D

Re: qemu - some confusions

[Reco]

Hi.

On Fri, Sep 11, 2020 at 11:10:28AM +0200, Kamil Jońca wrote:
> 
> I try to migrate some my ancient virutal machines from virtualbox to
> qemu, and some things are unclear for me.
> 1. scsi devices:
> 
> --8<---cut here---start->8---
> %qemu-system-x86_64 -device help|grep lsi  
> name "lsi53c810", bus PCI   
> name "lsi53c895a", bus PCI, alias "lsi"
> --8<---cut here---end--->8---
> 
> but in  /usr/share/libvirt/schemas/domaincommon.rng
> we have:
> 
> --8<---cut here---start->8---
>   
> 
>   auto
>   buslogic
>   lsilogic
>   lsisas1068
>   vmpvscsi
>   ibmvscsi
>   virtio-scsi
>   lsisas1078
>   virtio-transitional
>   virtio-non-transitional
> 
>   
> --8<---cut here---end--->8---
> what is relation between them?

As usual, libvirt provides you only the subset of qemu true
possibilities. Discrepancies such as this are to be expected.


> I tried to edit machine via virsh and set "lsilogic" value. Machine
> started and in command line I can see:
> "[...] -device lsi,id=scsi0,bus=pci.4,addr=0x0 [..]"
> so it is seem to be translated "lsilogic -> lsi".
> Any hints about that? Point to proper doc?

In this particular case, qemu defines both lsi53c810 and lsi53c895a in a
single hw/scsi/lsi53c895a.c, and short of couple switches there is no
discernable difference between them.
As for the doc, qemu's documentation could definitely use some
improvement, and it's been like this for at least 10 years or so, so I
use [1].


> Another (OT) question:  does anybody knows about places from I can take 
> drivers
> for these ( lsi53c810 , lsi53c895a) controllers for windows NT 4 and
> windows 2000? 

Ask this guy - [2], seriously. He's *the* digital archeologist and a
Windows enthusiast at the same time.

Reco


[1] git://git.qemu.org/qemu.git
[2] https://virtuallyfun.com

Re: qemu - some confusions

[Dan Ritter]

Kamil Jo?ca wrote: 
> 
> I try to migrate some my ancient virutal machines from virtualbox to
> qemu, and some things are unclear for me.
> 1. scsi devices:
> 
> --8<---cut here---start->8---
> %qemu-system-x86_64 -device help|grep lsi  
> name "lsi53c810", bus PCI   
> name "lsi53c895a", bus PCI, alias "lsi"
> --8<---cut here---end--->8---
> 
> but in  /usr/share/libvirt/schemas/domaincommon.rng
> we have:
> 
> --8<---cut here---start->8---
>   
> 
>   auto
>   buslogic
>   lsilogic
>   lsisas1068
>   vmpvscsi
>   ibmvscsi
>   virtio-scsi
>   lsisas1078
>   virtio-transitional
>   virtio-non-transitional
> 
>   
> --8<---cut here---end--->8---
> what is relation between them?

In your top cut, you have a specific SCSI adapter being selected
for emulation.

In the bottom, you have 9 different choices, of which you will
pick one.

The specific LSI 53c810 / 53c895a are not supported in qemu, but
it's possibly that the lsilogic emulator will work.

-dsr-


> 
> I tried to edit machine via virsh and set "lsilogic" value. Machine
> started and in command line I can see:
> "[...] -device lsi,id=scsi0,bus=pci.4,addr=0x0 [..]"
> so it is seem to be translated "lsilogic -> lsi".
> Any hints about that? Point to proper doc?
> 
> Another (OT) question:  does anybody knows about places from I can take 
> drivers
> for these ( lsi53c810 , lsi53c895a) controllers for windows NT 4 and
> windows 2000? 
> 
> KJ
> 
> 
> -- 
> http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
> 

-- 
https://randomstring.org/~dsr/eula.html is hereby incorporated by reference.
there is no justice, there is just us.

Re: [1/2 résolu] Erreur d'extraction de tarball

[l0f4r0]

Bonjour,

11 sept. 2020 à 13:00 de Olivier Humbert :

> - je décompresse l'archive créée
> ---> soucis
>
> Il y a bel et bien un bogue car ce n'est pas du tout un comportement attendu 
> de la part d'un utilisateur d'environnement de bureau.
>
J'ai regardé rapidement mais ça ressemble plus à une fonctionnalité/sûreté qu'à 
un bogue pour moi...

Bien cordialement,
l0f4r0

qemu - some confusions

[Kamil Jońca]

I try to migrate some my ancient virutal machines from virtualbox to
qemu, and some things are unclear for me.
1. scsi devices:

--8<---cut here---start->8---
%qemu-system-x86_64 -device help|grep lsi  
name "lsi53c810", bus PCI   
name "lsi53c895a", bus PCI, alias "lsi"
--8<---cut here---end--->8---

but in  /usr/share/libvirt/schemas/domaincommon.rng
we have:

--8<---cut here---start->8---
  

  auto
  buslogic
  lsilogic
  lsisas1068
  vmpvscsi
  ibmvscsi
  virtio-scsi
  lsisas1078
  virtio-transitional
  virtio-non-transitional

  
--8<---cut here---end--->8---
what is relation between them?

I tried to edit machine via virsh and set "lsilogic" value. Machine
started and in command line I can see:
"[...] -device lsi,id=scsi0,bus=pci.4,addr=0x0 [..]"
so it is seem to be translated "lsilogic -> lsi".
Any hints about that? Point to proper doc?

Another (OT) question:  does anybody knows about places from I can take drivers
for these ( lsi53c810 , lsi53c895a) controllers for windows NT 4 and
windows 2000? 

KJ


-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Re: Mobian op de Pinephone

[Jaap van Wingerde]

Heel interessant. Zou je over een paar maanden nogmaals je ervaringen
willen delen?

Zijn er lijstgenoten met een pinetab?

Op 2020-07-25T20:37:15+0200 schreef Paul van der Vlis
 in bericht
, inzake:
 het volgende.

> Hoi,
> 
> Ik ben sinds kort de trotse bezitter van een Pinephone. Deze kwam met
> UBports (door ontwikkeling van Ubuntu Touch).  Ik had hem in China
> besteld, hij kostte 150 euro. Ik had gerekend op nog extra douane
> kosten en dergelijke, maar niemand die daar over begon.
> 
> Echter al na twee dagen deed hij het niet meer. Ik kreeg alleen kort
> een Pinephone logo in beeld, hoorde een zachte klik, en de boel zat
> vast. In eerste instantie dacht ik dat het hardware problemen waren,
> echter de zachte klik bleek van de camera te komen, toen ik de
> dipswitch uitzette was er geen klik meer. En die camera wordt vanuit
> het operating systeem geinitialiseerd, dus dit was geen hardware
> probleem.
> 
> Het operating systeem staat op eMMC (een soort flash), echter er kan
> ook een SD-kaartje in de telefoon. Een bootbaar SD-kaartje gaat dan
> voor eMMC. Uiteraard kun je dat eMMC ook flashen.
> 
> Ik heb een SD-kaartje gemaakt met Mobian, een soort Debian met Phone
> Shell (phosh), wat deels van Gnome en deels van Purism komt. En dit
> deed het wel. Een kwestie van een bestand kopieren met dd, en dan
> daarna de partitie vergroten zodat je het hele SD-kaartje kunt
> gebruiken.
> 
> Ik heb een beetje rondgekeken en dingen geprobeerd. Het meeste
> functioneerd. https://wiki.mobian-project.org/doku.php?id=pinephone
> In eerste instantie was ik niet zo blij met de userinterface, maar als
> je het eenmaal iets beter kent is het nog helemaal niet zo gek. De
> telefoon is vrijwel geheel Debian testing.
> 
> Wat ik mis is een applicatie om het adresboek te synchroniseren. Er is
> wel iets mogelijk maar dat is erg moeizaam volgens mij. Er is wel een
> agenda die met carddav werkt volgens mij (niet echt getest).
> 
> Verder mis ik een navigatie-programma zoals OSMand~.
> 
> Er zijn meer operating systemen voor deze telefoon, je kunt simpel
> wisselen door een SD-kaartje om te wisselen.
> 
> Ik zag dat er nu ook een experimentele Android-versie is. Het voordeel
> van deze telefoon is dan:
> 
> - Duidelijke scheiding tussen modem en hoofdsysteem (USB verbinding).
> - Boot proces is helemaal open.
> - De hardware is open source, maar uiteraard zitten er wel closed
> source onderdelen in zoals de SoC. De onderdelen kunnen los besteld
> worden.
> - Uiteraard simpel om een Google-vrije telefoon te maken.
> 
> De telefoon is niet reuze snel, maar het is wel acceptabel vind ik. De
> batterij gaat met Debian wellicht wat sneller leeg vergeleken met een
> andere telefoon, maar het lijkt me wel bruikbaar.
> 
> Groeten,
> Paul
> 
> 

Re: how to remove GUI

[Greg Wooledge]

On Fri, Sep 11, 2020 at 10:35:46AM -0500, David Wright wrote:
> That's the first mention of this phenomenon I recall seeing since I posted
> https://lists.debian.org/debian-user/2018/03/msg01030.html
> (which dealt mainly with a more serious problem).
> 
> I never install a DE/DM and all that stuff, but I get the cursor
> movement nonetheless. Is that what you're saying?

It's not as serious as what you reported in the 2018 thread.  It's just
an occasional glitch, not easily reproducible, with a trivial workaround.

I only mention it because once in a while, someone sees something like
it and freaks out, thinking the computer is locked up or whatever.  They
don't realize they can just hit the Enter key and get a fresh login
prompt, and all is fine.

Re: how to remove GUI

[David Wright]

On Fri 11 Sep 2020 at 10:35:19 (-0400), Greg Wooledge wrote:
> On Fri, Sep 11, 2020 at 09:02:30AM -0400, Kenneth Parker wrote:
> > I am actually curious, what SystemD does, if it expects graphical.target,
> > yet the tools (x11, desktop, etc) are no longer available?
> 
> It boots just as you would expect.  If there is no display manager
> installed, then none will be executed.  At that point, you can login
> on the console, and either work that way, or run "startx" to start
> an X session, exactly the way you did before systemd.
> 
> There are a few *minor* differences.  The biggest is that the X session
> stays running on the same tty where you ran startx, rather than switching
> to the first idle VT.

I don't use a DE so I can't check. Who owns the X server nowadays
when running a DM? (With no DM running, ownership changed from root
to the user some time ago.)

> It's also significantly harder to get the system
> to stop clearing the screen after booting, after you logout, and so on.

For booting, I use the file:

  $ cat /etc/systemd/system/getty@.service.d/noclear.conf 
  # /etc/systemd/system/getty@.service.d/noclear.conf 2019-07-15
  # https://wiki.archlinux.org/index.php/Disable_clearing_of_boot_messages

  # Parameter is documented in
  # /etc/systemd/system/getty.target.wants/getty@tty1.service
  # and
  # /lib/systemd/system/getty@.service

  # [Service]
  # the VT is cleared by TTYVTDisallocate
  # TTYVTDisallocate=yes

  # This file contradicts that default value.

  [Service]
  TTYVTDisallocate=no
  #

  $ 

For logout, just edit ~/.bash_logout or remove it.

> And every once in a while, the cursor moves to the start of the line a
> few seconds after the login prompt has been displayed, but hitting Enter
> fixes that.

That's the first mention of this phenomenon I recall seeing since I posted
https://lists.debian.org/debian-user/2018/03/msg01030.html
(which dealt mainly with a more serious problem).

I never install a DE/DM and all that stuff, but I get the cursor
movement nonetheless. Is that what you're saying?

As for the more serious problem reported in my post, I think it
only occurred when the laptop was running on the battery.
At the time, realising it was to do with that was hampered
because I didn't know that the PSU's captive cable entry
was iffy, and that it could still be on battery power when
connected to the PSU. Eventually the PSU gave out, and its
replacement made it obvious that nulls were typed only when
on battery power.

Since that time, buster has been released, which never showed
the phenomenon, the replacement PSU has its captive cable
lashed to a coat peg because it's coming off, the connection
plug is loose, and the laptop power control section has
packed up, so it will only run on the mains. It's not long
for this world.

> Other than that, it's pretty much the same.

Out of its original context, that comment looks somewhat ironic.

Cheers,
David.

Re: vi colorido

[Vitor Hugo]

Bom dia;

Acesso  o servidor pelo Putty.


Em 10/09/2020 09:44, Paulo escreveu:

Vitor,

Já notei que em alguns casos o vi puro não fica colorido, já tentou 
usar o vim?


O que quer dizer com "terminal pelo SSH"? (Explique melhor, o que está 
usando [Putty], Terminal remoto, ...)


Att,

Paulo Correia

Em 10/09/2020 09:18, Vitor Hugo escreveu:

Bom dia;

Eu fiz este procedimento porem não deu certo.

Talvez seja algum problema por esta utilizando o terminal pelo SSH ou 
talvez a versão do vi não aceite este recursos.


Obrigado.

Em 09/09/2020 18:09, Emerson dos Santos Queiroz escreveu:

Olá Vitor,
Edite o arquivo */etc/vim/vimrc*, descomente a linha(somente retirar a
aspas ):
*syntax on *
Depois adicione a linha
*set number*

Salva e sai.

Abraço
Emerson

On Wed, Sep 9, 2020 at 1:02 PM Vitor Hugo  
wrote:



Boa tarde;

Como eu faço para deixar o vi colorido e com numero de linhas como na
figura a abaixo:

https://www.dicas-l.com.br/imagens/20200908.png

Obrigado;

Linux debian 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) 
x86_64

GNU/Linux

Re: how to remove GUI

[Greg Wooledge]

On Fri, Sep 11, 2020 at 09:02:30AM -0400, Kenneth Parker wrote:
> I am actually curious, what SystemD does, if it expects graphical.target,
> yet the tools (x11, desktop, etc) are no longer available?

It boots just as you would expect.  If there is no display manager
installed, then none will be executed.  At that point, you can login
on the console, and either work that way, or run "startx" to start
an X session, exactly the way you did before systemd.

There are a few *minor* differences.  The biggest is that the X session
stays running on the same tty where you ran startx, rather than switching
to the first idle VT.  It's also significantly harder to get the system
to stop clearing the screen after booting, after you logout, and so on.
And every once in a while, the cursor moves to the start of the line a
few seconds after the login prompt has been displayed, but hitting Enter
fixes that.

Other than that, it's pretty much the same.

Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

[David Wright]

On Fri 11 Sep 2020 at 13:03:44 (+1000), David wrote:
> On Fri, 11 Sep 2020 at 08:30, David Christensen  
> wrote:
> > On 2020-09-10 09:44, David Wright wrote:
> 
> > > I don't like parted particularly, and don't know what "free" does.
> > > Can you elucidate?
> 
> > > $ man parted | grep -i free
> > > $ info --output=/dev/stdout --subnodes parted | grep -i free
> 
> > I also am unable to find canonical documentation via RTFM, info, and
> > STFW.  GNU must have missed documenting it (?).
> 
> # parted --help | grep -A 1 free
>   print [devices|free|list,all|NUMBER] display the partition table,
> available devices, free space, all found partitions, or a particular
> partition

It looks as if that just got left out of the man page
which, in other respects, has been condensed to yield
$ /sbin/parted --help

Cheers,
David.

Re: Why start the first partition at 2 MIB, why not at any multiple of 4096 bytes ...

[David Wright]

On Thu 10 Sep 2020 at 16:15:05 (-0700), David Christensen wrote:
> On 2020-09-09 23:02, David wrote:
> > On Thu, 10 Sep 2020 at 11:26, David Christensen  
> > wrote:
> > > On 2020-09-09 08:03, David Wright wrote:
> > 
> > > > ... having been bitten by
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923561
> > 
> > > I have a 300 GB drive that has been causing me some confusion.  Did I
> > > elicity the bug when I partitioned the disk as follows?
> > 
> > I have not read all relevant messages, but in case it helps you can
> > check your exact device partition boundaries by running:
> > 
> > parted /dev/disk/by-id/ata-ST3300622AS_ 'unit compact print
> > free unit s print free unit b print free'
> 
> That parted(8) incantation has issues, as does the disk:

[…]

> This is how I invoke parted(8):
> 
> 2020-09-10 14:01:58 root@tinkywinky ~
> # parted /dev/disk/by-id/ata-ST3300622AS_ unit s print free
> Error: The backup GPT table is corrupt, but the primary appears OK, so
> that will be used.
> OK/Cancel? ok
> Model: ATA ST3300622AS (scsi)
> Disk /dev/sdb: 586072368s
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
> 
> Number  Start   End SizeFile system  Name  Flags
> 34s 2047s   2014s   Free Space
>  1  2048s   586072063s  586070016s  ext2 
> 586072064s  586072334s  271sFree Space

I don't know what might have got your disk into this state, but
I'm happy that you got it fixed. My own strategy would have been
to use gdisk (my preferred partitioning program) to rewrite the
backup table from the main table (command r for the recovery menu,
then d).

> Looking at the above information, my first partition starts at sector
> 2048 and ends at sector 586072063 (inclusive).  Both of these values
> represent 1 MiB alignment, so it appears that the partition has not
> been affected by bug 923561.

I don't think the bug affects ordinary 512/512 disks, but only
Advanced Format ones with larger block sizes, and then only if
"they" also supply an erroneous I/O value, eg:

Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes

It's possible that this only occurs with USB disks, too.
The partition can be 1MB aligned, but cryptsetup is fooled into
setting the wrong alignment, eg:

device-mapper: table: 254:1: adding target device sdb2 caused an alignment 
inconsistency:
physical_block_size=4096, logical_block_size=512, alignment_offset=0, 
start=33553920

which was produced by this partition:

/dev/sdb2  1302349824 1953521663  651171840 310.5G  c W95 FAT32 (LBA)

>>> 1302349824/2048
635913.0
>>> 

So, as my notes show, for the simple life, I always create
partitions with 2MB alignment regardless of future use¹,
and always add  --align-payload 2048 to my cryptsetup
commands. This option is benign because it's the default
when the kernel doesn't supply a value. The man page says
to prefer --offset, but as I know nothing about what any
of these options actually do, I don't use --offset just
because there's no default value given for it. (I suspect
it may be the same as for --align-payload.)

¹ I don't worry about the initial BIOS boot partition.

Cheers,
David.

Re: Create 3D text?

[Cindy Sue Causey]

On 9/9/20, Ben Caradoc-Davies  wrote:
> On 10/09/2020 13:53, Carl Fink wrote:
>> Can anyone suggest a Debian repo-installable program to create 3D text?
>
> Blender.
>
> Kind regards,


Which always instantly makes me think of Inkscape. Openshot
(openshot-qt) brings in both Blender AND Inkscape as a one-two punch.
Thank you, Developers! They're an interesting set.

For rendering 3D text, I just tried this query:

https://www.youtube.com/results?search_query=inkscape+3d+text

Some of those videos are aurally hard to understand *for me*. I've
never done so, but I've read about downloading Youtube videos. One
could do that then slow the videos WAY down to more easily see what's
being clicked for each step. I'm not sure of copyright in going that
route, though...

This video stood out in the few I watched this morning. Very cool
stacking with hints for fast aesthetic repairs, too:

https://www.youtube.com/watch?v=ZYbHh3A0VNQ

It might be worthwhile to view quite a few because I'm seeing single
tips in each that aren't in others. Like this one for block text 3D:

https://www.youtube.com/watch?v=axStBxie-vo

GIMP was mentioned as an alternative a couple times in what I sampled.
A similar search might bring up some fun stuff there, too.

AND for Blender, too!

https://www.youtube.com/watch?v=4GR0takbq2s

WOW, COOL on this one!

https://www.youtube.com/watch?v=cS3aRmcohn8

I'm personally going to try that one next. I'm seeing even more new,
very handy looking tips there, specifically about alignment..

Hope this helps.. someone. :)

PS THANK YOU for asking this question. I've been looking for a way to
turn a real image into a more generic line drawing. This morning's
search incidentally also suggested a video that teaches just that via
the PhotoAdvanced channel (separate sibling to PhotoAdvanced2).

Additional note that just came to mind for newbies, newcomers: I THINK
I remember Inkscape occasionally not being available for installation.
That might have been about Unstable installs. That happens, is just
part of the game plan when packages aren't quite ready yet. We just
have to wait or find an alternative method for installation, then.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: how to remove GUI

[Kenneth Parker]

On Fri, Sep 11, 2020, 7:56 AM Henning Follmann 
wrote:

> On Thu, Sep 10, 2020 at 11:33:21PM -0500, Michael Morgan wrote:
> > Dear friend,
> >
> >
> >
> > I recently installed Debian 9.13 on my machine. I was planning to use it
> for
> > scientific computation so GUI is not necessary. For some reason, I
> installed
> > the desktop environment with LXDE desktop during installation. Later I
> > decided to remove them. These two commands were executed:
> >
> [...]
>
> Hello,
>
> may I interject here.
> First, is there a particular reason why you installed an older version of
> debian?
>
> And second, there is no real reason to go through all of this.
> You can make the non gui the default.
> With systemd:
> systemctl set-default multi-user.target
>

+1

I am actually curious, what SystemD does, if it expects graphical.target,
yet the tools (x11, desktop, etc) are no longer available?

One note:  My preference, is to set multi-user.target on my current
systems, boot them into Text, sign into root in Console 2, and do the
apt-get "ritual".  If it includes a new Kernel (or is, in my opinion,
complex), reboot.  And then, as the next step, enter the "systemctl start
graphical.target" command to get to the Desktop.

Good luck!

Kenneth Parker

Re: how to remove GUI

[rhkramer]

Thanks for the explanation of the autoremove intent (I had never seen that 
explanation before (never looked for it, didn't think I needed it (so far), 
but the understanding is helpful).

Nothing new below this line.

On Friday, September 11, 2020 07:53:26 AM Greg Wooledge wrote:
> In the more general case, there are two strategies to remove a whole
> bunch of packages that have a dependency tree relationship.  The first
> strategy, which is relatively new, is to count on "apt autoremove",
> which is a relatively new feature and has a lot of quirky behavior.
> The concept here is that, when you installed the top-level package of
> the large dependency tree (whether that's "gnome-core" or
> "task-something"), apt will have marked that one package as "manually
> installed", and anything else that was brought in at the same time, would
> not be so marked.  Then, when you want to remove all of them, you first
> remove the same top-level package.  This doesn't do much on its own, but
> now all of the dependent packages have nothing anchoring them.  So if you
> follow up with an "apt autoremove", it should, in theory, remove all of
> the dependent packages.
> 
> In my experience, that doesn't work very well, so I've disabled autoremove
> on my system.

Re: how to remove GUI

[Henning Follmann]

On Thu, Sep 10, 2020 at 11:33:21PM -0500, Michael Morgan wrote:
> Dear friend, 
> 
>  
> 
> I recently installed Debian 9.13 on my machine. I was planning to use it for
> scientific computation so GUI is not necessary. For some reason, I installed
> the desktop environment with LXDE desktop during installation. Later I
> decided to remove them. These two commands were executed:
> 
[...]

Hello,

may I interject here.
First, is there a particular reason why you installed an older version of
debian?

And second, there is no real reason to go through all of this.
You can make the non gui the default.
With systemd:
systemctl set-default multi-user.target

At that point also disable hibernate and suspend:
systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target


And last, debian has pure blends for specific fields:
https://www.debian.org/blends/

May I suggest Debian Science here?


-H



-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: how to remove GUI

[Greg Wooledge]

On Thu, Sep 10, 2020 at 11:33:21PM -0500, Michael Morgan wrote:
> I recently installed Debian 9.13 on my machine.

So, not the current stable release

> What is the correct way to
> completely remove GUI?

Well, in this *particular* case, your best course of action would probably
be a clean install of Debian 10.  Select only "Standard" (or maybe add
the OpenSSH server) during the initial task selection.

In the more general case, there are two strategies to remove a whole
bunch of packages that have a dependency tree relationship.  The first
strategy, which is relatively new, is to count on "apt autoremove",
which is a relatively new feature and has a lot of quirky behavior.
The concept here is that, when you installed the top-level package of
the large dependency tree (whether that's "gnome-core" or "task-something"),
apt will have marked that one package as "manually installed", and
anything else that was brought in at the same time, would not be so
marked.  Then, when you want to remove all of them, you first remove
the same top-level package.  This doesn't do much on its own, but now
all of the dependent packages have nothing anchoring them.  So if you
follow up with an "apt autoremove", it should, in theory, remove all
of the dependent packages.

In my experience, that doesn't work very well, so I've disabled autoremove
on my system.

The other strategy, which is a much older one, relies on you performing
a light analysis of the dependency tree and finding some lynchpin
package that is holding the whole thing up.  E.g. with GNOME 2.x, there
was some package like "libgnome-common" or something.  If you removed
that, it would remove everything else, because everything in GNOME
depended (directly or indirectly) on this one package.

In the case of a desktop environment, you really have two different
dependency trees to worry about.  There's the X server (xorg), and
there's the desktop environment (task-gnome-or-whatever).  You can
perform a separate analysis on each of these trees, identify which
low-level libraries or "common" packages are necessary to hold them
up, and remove those.

Or, as we've said a few times now, you can just leave the packages in
place and ignore them.  Or do a clean install.

Bug in Clamav Package

[Volker Bäurer]

Hello,

I use the Clamav/Buster. When restarting the service I get:

"... mkdir[17696]: /bin/mkdir: cannot create directory '/run/clamav': File 
exists"

This message is useless because the directory exists and I have seen it since 
Btretch. Perhaps it was current already bevore.

To get rid o fit, I changed in 
/etc/systemd/system/clamav-daemon.service.d/extend.conf

Edit:ExecStartPre=-/bin/mkdir /run/clamav
to
Edit:ExecStartPre=-/bin/mkdir -p /run/clamav

because the /etc/init.d/clamav-daemon already contains "mkdir -p".

Best regards

Volker Bäurer
IT-Specialist

Mitutoyo CTL Germany GmbH
Von-Gunzert-Straße 17
D-78727 Oberndorf
GERMANY
T +49-7423-8776-0
volker.baeu...@mitutoyo-ctl.de
www.mitutoyo-ctl.de

Registered Company: Mitutoyo CTL Germany GmbH
Registered Office: Von Gunzert Straße 17, D-78727 Oberndorf am Neckar
Commercial register of the local court: Amtsgericht Stuttgart, HRB 734157
VAT number: DE272400711
Managing Director: Hans-Peter Klein

Re: [1/2 résolu] Erreur d'extraction de tarball

[Olivier Humbert]

Le 2020-09-10 00:44, l0f4r0 a écrit :


[...zip...]
je suis pas certain qu'il s'agisse d'un bug...
[...zap...]



Du point de vue utilisateur :
- je compresse un dossier
---> pas de soucis
- je décompresse l'archive créée
---> soucis

Il y a bel et bien un bogue car ce n'est pas du tout un comportement 
attendu de la part d'un utilisateur d'environnement de bureau.


Cordialement
Olivier

Re: Zones d'agrandissement des fenêtres minuscules

[Stephane Ascoet]

Le 10/09/2020 à 20:55, Étienne Mollier a écrit :

Si je reste appuyé sur cette touche, alors en faisant un clic
gauche glissé sur une fenêtre, je la déplace, et en faisant un
clic droit glissé, je la redimensionne par rapport au rebord le
plus proche.  Depuis que j'ai pris le pli d'utiliser ce
mécanisme, je n'ai jamais réussi à revenir en arrière.



Bonjour, encore un truc que j'apprends en lisant cette liste sans etre 
pourtant a priori directement concerne par le sujet: grace a toi je 
decouvre que ce comportement avec le clic droit est actif dans mon 
Blackbox! J'utilise depuis toujours celui avec le clic-gauche, notamment 
pour recuperer des fenetres qui parfois sont positionnees n'importe 
comment, je pense que c'est implante directement dans Xorg(ou dans des 
bibliotheques communes a tous les gestionnaires de fenetres?) et que du 
coup c'est sans doute pareil pour le alt+clic droit


--
Cordialement, Stephane Ascoet

Re: Zones d'agrandissement des fenêtres minuscules

[Kohler Gerard]

Le 10/09/2020 à 08:12, steve a écrit :

Salut,

Sur Plasma de Buster.

Les bords des fenêtres où l'on peut venir avec la souris sont si fins
que je mets souvent plus de 30 secondes à positionner correctement la
souris pour agrandir la fenêtre. J'ai cherché, cherché mais pas trouvé
où je pourrais régler cela.

Une idée ?

Merci


dans le menu, configuration/configuration du système/

gestion des fenêtres onglet window actions :

inner window, title bar and frame action :

modificateur : méta ou alt

click droit : redimensionner

lorsque l'on appuis sur la touche méta avec le bouton droit de la souris 
on redimensionne la fenêtre

Re: Bug in Clamav Package

[Andrei POPESCU]

On Vi, 11 sep 20, 07:26:21, Volker Bäurer wrote:
> Hello,
> 
> I use the Clamav/Buster. When restarting the service I get:
> 
> "... mkdir[17696]: /bin/mkdir: cannot create directory '/run/clamav': File 
> exists"
> 
> This message is useless because the directory exists and I have seen it since 
> Btretch. Perhaps it was current already bevore.
> 
> To get rid o fit, I changed in 
> /etc/systemd/system/clamav-daemon.service.d/extend.conf
> 
> Edit:ExecStartPre=-/bin/mkdir /run/clamav
> to
> Edit:ExecStartPre=-/bin/mkdir -p /run/clamav
> 
> because the /etc/init.d/clamav-daemon already contains "mkdir -p".

Hello,

This is the user support list, which is the recommended contact point in 
case you are not sure if a bug exists and/or where it belongs.

In this particular case you seem to have diagnosed the issue and found a 
fix for it. I would recommend you use 'reportbug' to report this against 
the appropriate package ('clamav-daemon'?).

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


signature.asc
Description: PGP signature

[SOLVED] Re: Zones d'agrandissement des fenêtres minuscules

[steve]

Un colistier a donné la solution que je me permets de retranscrire ici:

dans le menu, configuration/configuration du système/

gestion des fenêtres onglet window actions :

inner window, title bar and frame action :

modificateur : méta ou alt

click droit : redimensionner

lorsque l'on appuis sur la touche méta avec le bouton droit de la souris on
redimensionne la fenêtre


Merci à lui.

Re: OT: Virtualbox - ISO or VDI?

[Hans]

Dear Reco and Linux-Fan,

thanks for the fast response. Well, space is really a thing, that is 
important. I intend using virtualbox for teaching purposes. The goal is, to 
have very easy and fast a kali-linux and metasploitable available, without 
changing the running system and independent of the running system.

Thus my idea is, to start virtualbox portable (no installation, can later be 
removed), then boot kali and metasploitable.

Hower, virtualbox can boot ISO as well as import VDI or OVA. As not all of my 
students might own a decent computer, space is important as well as 32-bit or 
64-bit (I am building my own kali and debian livefiles, so I have 32-bit and 
64-bit available).

Here I am running kali on my EEEPC from SD-Card (1,6GHz, 2GB RAM), which is 
still fast enough and it is 32-bit. 

So my idea is, that my students shall be able to run it on also on their older 
computers. 

Thios was the background of my question, what might be better, ISO or VDI or 
OVA - size and performance are here the most important points.

Thanks for making some things clearer now.


Best regards

Hans
 


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

Re: Can one install packages from Parrot or Kali on Debian testing? (Was: Re: Hi :))

[Andrew Cater]

Parrot and Kali both have their own support lists. Kali, in particular, use
a modified Debian testing as the basis of their rolling release but modify
kernels and other packages. In general, people would suggest not mixing
Debian stable and Debian testing. Using packages from another
Debian-derived distribution risks creating a "FrankenDebian" that you can't
control and can't readily fix without removing significant numbers of
packages: this also applies to Ubuntu and, especially, Ubuntu PPAs mixed
with Debian.

All the very best

Andy C

https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwiczpvn0-DrAhWTA2MBHUrsDXwQFjAAegQIARAB=https%3A%2F%2Fwiki.debian.org%2FDontBreakDebian=AOvVaw2uYNQvEqW0ju-bH_QNSw08


On Fri, Sep 11, 2020 at 5:35 AM Andy Smith  wrote:

> Hi Richard,
>
> Your question is one of user support but you've sent it to the
> debian-project list, which is about the Debian project itself and
> not for asking user questions. So, I have directed replies to the
> correct place which is debian-user.
>
> On Thu, Sep 10, 2020 at 04:14:35PM -0400, richard loomis wrote:
> > I have a question using debian 10 i noticed ive upgraded till theres no
> > more using testing,
>
> Use "testing" is probably for advanced users, but the question you
> ask below about mixing in things that aren't Debian suggests you are
> maybe not that familiar with Debian. Be careful!
>
> > when i add parrot os repos and kali linux repos theres tons of
> > upgrades knowing there using testing also, Is it safe to upgrade
> > debian 10 with there repos?
>
> No. You should not mix in things that aren't Debian into Debian
> without knowing exactly what you are doing. None of those things
> (Parrot, Kali) are designed to be installed on a Debian system. You
> will very likely break your entire system doing this. It may even
> appear to work for a while, but will break later in mysterious ways.
>
> See https://wiki.debian.org/DontBreakDebian for more details.
>
> In general, upgrading to newer versions of packages for no reason
> other than that they exist is not a good practice. You should have a
> reason for wanting a newer package than what exists in Debian
> testing. I recommend that if you do have such a need for specific
> newer packages, you install them individually from upstream
> following upstream's instructions.
>
> Cheers,
> Andy
>
>

Re: how to remove GUI

[Joe]

On Thu, 10 Sep 2020 23:33:21 -0500
"Michael Morgan"  wrote:

> Dear friend, 
> 
>  
> 
> I recently installed Debian 9.13 on my machine. I was planning to use
> it for scientific computation so GUI is not necessary. For some
> reason, I installed the desktop environment with LXDE desktop during
> installation. Later I decided to remove them. 


As Andrei has said, 'if I was going there then I wouldn't start from
here..'.

It really would be a lot quicker to reinstall than to spend days trying
to identify what you need to remove. When the time comes in the
installer, don't select anything at all, remove all the ticks, and you
will get a fairly minimal console-only installation.

Alternatively, remove the Display Manager (gdm, xdm, etc.) and whatever
GUI you have remaining should never start, you should boot into just a
console. Only if you have a really tiny hard drive will the wasted
space be a problem.

-- 
Joe

Re: how to remove GUI

[Andrei POPESCU]

On Vi, 11 sep 20, 09:32:23, Andrei POPESCU wrote:
> 
> When removing them you might need to add
> 
> -o APT::Autoremove::SuggestsImportant=no
> 
> and even
> 
> -o APT::Autoremove::RecommendsImportant=no
 
Err, these won't do much on removing the package, they work only in 
combination with 'autoremove'.
 
> Note: the second one in combination with 'autoremove' may remove much 
> more than actually intended.

This is still very much valid.

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


signature.asc
Description: PGP signature

Re: how to remove GUI

[Andrei POPESCU]

On Jo, 10 sep 20, 23:33:21, Michael Morgan wrote:
> 
> So it seems the desktop package was removed. But why it still has GUI?

As you found out, removing collections of packages is more difficult 
than installing them.

Try running this:

apt -o APT::Autoremove::SuggestsImportant=no autoremove --purge


Do check carefully the list of packages to be removed, in case it 
removes packages that are still needed.

If this doesn't work you might still have some LXDE related package 
installed. You can find them with

apt list --installed '*lxde*'


When removing them you might need to add

-o APT::Autoremove::SuggestsImportant=no

and even

-o APT::Autoremove::RecommendsImportant=no


Note: the second one in combination with 'autoremove' may remove much 
more than actually intended.

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


signature.asc
Description: PGP signature