Re: URLs in Mutt

[Paul M Foster]

On Sun, Dec 31, 2023 at 11:12:12PM -0500, Greg Wooledge wrote:

> On Sun, Dec 31, 2023 at 10:51:25PM -0500, Paul M Foster wrote:
> > Apparently, something was wrapping lines to
> > about 75 characters, and putting an equals sign at the end of every line
> > which had been wrapped.
> 
> This is "quoted-printable" encoding.  You need to use a properly decoded
> version of the file, rather than the raw text.[1]
> 
> > As a solution, I took that email from my mutt mail file and stripped out
> > all the headers and non-HTML content. Then I fed that to my browser.
> 
> If you received a correctly formatted email, it should contain one or more
> parts, each of which is identified by a MIME Content-Type.  Pressing 'v'
> while reading the message takes you to a page which shows you the parts
> in a tree form.
> 
> Use the arrow keys to select the part you want to save (in this case, the
> text/html one), and then save it to a file.  I use "foo.html" usually,
> and just overwrite foo.html every time.
> 
> Have your browser load THAT file.
> 
> [1] The SMTP standard requires all transmitted lines to be 1000 characters
> or less, and to contain only 7-bit ASCII characters.  Therefore, any
> content which doesn't conform to these restrictions has to be encoded.
> The two choices for encoding are quoted-printable, and base64.
> Quoted-printable is nearly human-readable, and is more efficient if
> there are relatively few 8-bit characters or long lines, so it's
> a common choice.  Some MUAs will use q-p even on files that don't
> *strictly* need it, just in case.
> 

This is an excellent reply, and explains the situation entirely. I tried
your method, and it worked. Thanks.

Of course, it doesn't fix the retarded way Mutt handles links. For those
familiar with Mutt, it allows you to view the file with numbers referring
to each link. Then you get a screen with just the numbered links. Here's
the fun part: if the link you want is, say, number 4, when you get to the
screen with only numbered links, the number 4 link is often some other
link. You have to push each link around the one you want to the browser
until you find the one you want. It's a pain.

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

[HS] LINUX ENTREPRISE

[Alex PADOLY]

Bonjour et bonne année 2024 à tous !

Je vais me former dans le but d'élargir mon savoir et mes compétences 
concernant LINUX en entreprise.
En complément d'un usage quotidien de DEBIAN en poste de travail et 
serveur, je souhaiterais installer une distribution
LINUX orientée entreprise sur un poste informatique puis sur serveur 
pour y faire un serveur FTP et un serveur de messagerie.


ORACLE LINUX, Red Hat Enterprise Linux, ou autres, que me 
conseillez-vous ?


Merci pour vos conseils.

Re: Monthly FAQ for Debian-user mailing list (modified 20240101)

[Andy Smith]

Hello,

On Mon, Jan 01, 2024 at 07:32:18PM -0700, Charles Curley wrote:
> If one changes subject, would it not be better to simply start a new
> thread? With most mail readers threading using the In-Reply-To header,
> the new subject would get buried in the old thread.

Personally I prefer that. I appreciate being able to break out
sub-threads that seem interesting, instead of having that decision
made for me.

But in any case, ~30% of the posters of this list (the largest
single constituency) use gmail which I recently learned will break
such emails out to appear to be in a different "conversation"
anyway.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Monthly FAQ for Debian-user mailing list (modified 20240101)

[Greg Wooledge]

On Mon, Jan 01, 2024 at 07:32:18PM -0700, Charles Curley wrote:
> If one changes subject, would it not be better to simply start a new
> thread? With most mail readers threading using the In-Reply-To header,
> the new subject would get buried in the old thread.

There's a difference between natural subject drift, or someone hijacking
a thread to ask their own question.  A judgment call may be needed in
some cases where it might be unclear, but most of the time it should
be obvious which one's happening.

Re: Monthly FAQ for Debian-user mailing list (modified 20240101)

[Charles Curley]

The refactoring and headers are an improvement, thank you.


On Mon, 1 Jan 2024 22:56:03 +
"Andrew M.A. Cater"  wrote:

> If you change subject or emphasis in mid-thread, please change the
> subject line on your email accordingly so that this can be clearly
> seen. 
> 
>   For example: New question [WAS Old topic]

If one changes subject, would it not be better to simply start a new
thread? With most mail readers threading using the In-Reply-To header,
the new subject would get buried in the old thread.

-- 
Does anybody read signatures any more?

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

Nettoyage du spam : décembre 2023

[Jean-Pierre Giraud]

Bonjour,
Comme nous sommes en janvier, il est désormais possible de traiter les
archives du mois de décembre 2023 des listes francophones.

Si vous disposez d'un peu de temps vous pouvez aussi traiter les mois de
mai 2021 à mars 2022 inclus où il manque en relecteur pour achever le
traitement des spams

N'oubliez bien sûr pas d'ajouter votre nom à la liste des relecteurs
pour que nous sachions où nous en sommes.

Détails du processus de nettoyage du spam sur :

https://wiki.debian.org/I18n/FrenchSpamClean

Jean-Pierre Giraud


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

Re: Monthly FAQ for Debian-user mailing list (modified 20240101)

[Andrew M.A. Cater]

Debian-user is a mailing list provided for support for Debian users,
and to facilitate discussion on relevant topics.

Codes of Conduct


* The list is a Debian communication forum. As such, it is subject to both
  the Debian mailing list Code of Conduct and the main Debian Code of Conduct
  https://www.debian.org/MailingLists/#codeofconduct
  https://www.debian.org/code_of_conduct
  
Guidelines for this list

Some guidelines which may help explain how the list should work:

Language


* The language on this mailing list is English. There may be other mailing
  lists that are language-specific, for example, debian-user-french or
  debian-user-cat

* It is common for users to be redirected here from other lists, for example,
  from debian-project. It is also common for people to be posting here when
  English is not their primary language. Please be considerate.

Answering questions and contributing to discussions constructively
==

* This is a fairly busy mailing list but even so you may have to wait some time 
  for an answer - please be patient.

* Help and advice on this list is provided by volunteers in their own time.
  It is common for there to be different opinions or answers provided.
  
* It is not necessary to answer every post on the mailing list.
  
* Be constructive in your responses. It may be that somebody else answers
  a question before you - if so, you should not reply simply in order to get
  the last word in, only reply if you can add useful information.

* Please try to stay on topic. Arguments for the sake of it are not
  welcome here. 

* Partisan political / religious / cultural arguments do not belong here 
either. 
  Debian's community is world wide; do not assume others will agree with your
  views or need to read them on a Debian list.
  
Editing and answering mailing list posts


* It is helpful to write meaningful subject lines. If you change subject
  or emphasis in mid-thread, please change the subject line on your email
  accordingly so that this can be clearly seen. 

  For example: New question [WAS Old topic]

* It may also be useful to for someone to post a summary email from time to
  time to explain long threads.
  
* Before posting, it may be useful to check your post for spelling mistakes
  and scan it for redundancy, duplicate words and redundancy.

* Clear replies and a short mailing list thread are much easier to
  read and follow than long threads.

* If you are replying to a post, please reply in-line if possible and cut extra
  text that is not relevant to your point.

Private replies and responding to posts off-list


* Please post answers back to the list so others can benefit: private
  conversations don't benefit people who may only be following
  along on the list or reading the archives later.

* We're only human: you may want to respond to someone off-list
  to make a point (or to wish them Happy Birthday / comment that you
  haven't seen them for a long time). We're also a community
  
  BUT

* Posting outside the list can be unhelpful: bad behaviour outside the lists 
  can't easily be dealt with and will be invisible. You may inadvertently leak
  personal information by posting a private reply back to the list.

  If you *do* want to post outside the list - make it clear that you have done
  so at the top of the message. If someone replies to you privately and you
  think that this should go back to the list - ask them to post it to the list
  do not just do so on their behalf without checking.

I can't see what I want here - help me!
===

* It is often useful to look through the archives to see whether the issue
  you wish to raise or a similar issue has been raised before by someone
  else. The top level link to the archives of this list is at
  https://lists.debian.org/debian-user/ organised by year, then month.

* Although there are only 20 or 30 regular contributors, there may
  be a couple of thousand readers in the background. Nobody is
  a mind reader, nobody can sit beside you. Please help by providing
  useful details if asked, especially which version of Debian you are
  running.
  
I'm not using Debian but ...


* Strictly, discussions of other distributions are off-topic here.
  Please note: advice on Linux distributions other than Debian will be
  only our best guess - other distributions may do things very differently.
  Any advice given accordingly  may be inaccurate but is given in good faith.

FAQ topics
==

* There is an FAQ on the Debian wiki derived from some questions asked on this
  list at https://wiki.debian.org/FAQsFromDebianUser

This is a public list, archived in many places
==

* One question that comes up on 

Filezilla werkt niet?

[Paul van der Vlis]

Hoi,

Raar probleem met Filezilla, ik kan er opeens niet meer mee connecten 
via SFTP. Ik krijg een "connection refused". Mijn klant krijgt een 
timeout. Een paar dagen geleden deed het het nog, zowel bij mij als bij 
klant.


En wat helemaal raar is: geen meldingen in de logs op de server, ook 
niet als het loglevel op debug staat. En nee, de IP's komen niet voor in 
de firewall of in hosts.deny.


Zelf gebruik ik FileZilla niet veel, maar ik raad het aan klanten aan 
omdat het voor allerlei OS-en beschikbaar is, en ik het kan supporten 
vanuit Debian. Klant draait het op Windows.


Als ik gFTP of sftp gebruik dan gaat het goed, en krijg ik ook meldingen 
in de logs. Het lijkt dus niet aan de server-kant te liggen.


Werkt het bij jullie wel?  Je krijgt automatisch SFTP als je poort 22 
gebruikt.  Ik doe dit op Debian 11.


Groet,
Paul

PS: weten jullie hoe je dat "snoopy" loggen uit kunt schakelen in 
auth.log? Heel irritant vind ik dat. Als je ergens op zoekt krijg je 
steeds je eigen vraag als resultaat van het grep-commando.



--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl/

Re: URLs in Mutt

[fxkl47BF]

On Mon, 1 Jan 2024, Nicolas George wrote:

> This was not a reply to the original mail. You might consider using a
> MUA with proper threading to better understand what is going on.

from the negative nature of your communications
every one understands what's going on

Re: URLs in Mutt

[Nicolas George]

fxkl4...@protonmail.com (12024-01-01):
> actually the question was
> " what is wrapping the lines on my incoming emails, and how do I fix it "
> please try to keep up

This was not a reply to the original mail. You might consider using a
MUA with proper threading to better understand what is going on.

-- 
  Nicolas George

Re: URLs in Mutt

[fxkl47BF]

On Mon, 1 Jan 2024, Nicolas George wrote:

> gene heskett (12024-01-01):
>> Most browsers to well with such as long as the link is surrounded by 
>> the left-right arrows delineate the links contents even if it is wrapped to
>> several lines on your screen.
>
> Please try to keep up with the context of the discussion, we were
> talking about links displayed by “lynx -dump”.

actually the question was
" what is wrapping the lines on my incoming emails, and how do I fix it "
please try to keep up

Re: URLs in Mutt

[Nicolas George]

gene heskett (12024-01-01):
> Most browsers to well with such as long as the link is surrounded by 
> the left-right arrows delineate the links contents even if it is wrapped to
> several lines on your screen.

Please try to keep up with the context of the discussion, we were
talking about links displayed by “lynx -dump”.

Regards,

-- 
  Nicolas George

Re: URLs in Mutt

[gene heskett]

On 1/1/24 11:52, Nicolas George wrote:

Greg Wooledge (12024-01-01):

It's been my experience that the hyperlinks I'm meant to click are so
long that they wrap around the terminal width multiple times.  This
makes copy/pasting them tedious at best, and even then it still
sometimes fails for me.


Surprising. The graphical web browsers I know are actually very tolerant
of spurious newline characters inserted in pasted URLs, and I suspect it
is on purpose. PDFs from magazines might also have wrapped links.

Regards,

Most browsers to well with such as long as the link is surrounded by 
 the left-right arrows delineate the links contents even if it is 
wrapped to several lines on your screen.


Take care all.

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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: Risque ou pas ?

[Yannick]

Le 01/01/2024 à 21:34, Étienne Mollier a écrit :

Bonsoir,

Yannick, on 2024-01-01:

Le 01/01/2024 à 19:31, Yannick a écrit :

Même chose avec .local/share


Ce répertoire ci est plus délicat.  En théorie, le ~/.local est
un préfixe spécifique à l'utilisateur pour y installer des
programmes sans toucher au système, et donc le ~/.local/share
serait à peu près équivalent au /usr/local/share ou /usr/share.
En pratique, j'y trouve pèle-mèle des journaux, des informations
de configuration pas vraiment éditables à la main, des fichiers
de sauvegardes, etc.  Il y a à boire et à manger.

À mon avis, il vaut mieux regarder de près ce qu'on y efface.

Mais j'avoue qu'y faire du ménage (ciblé) une fois de temps en
temps peut être salutaire.  Le tout est de s'assurer que ce
qu'on efface ne sert plus.  Une option peut être d'archiver les
données au lieu de les effacer, et de les restaurer le jour où
on a à nouveau besoin du programme correspondant, en admettant
que les données correspondantes (par exemple configuration,
greffons ou sauvegardes), soient encore utiles.

Bonne année !  :)


Re,

Celui là ne me plaisait pas beaucoup et tes explications me confortent 
dans mon opinion de ne pas y toucher pour le moment avant d'avoir 
vérifier mes logiciels.


Amitiés
--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris https://www.ancestris.org



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

On 01.01.24 21:20, Richard Rosner wrote:


On 01.01.24 20:30, David Wright wrote:

On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:

On 01.01.24 18:13, David Wright wrote:
I can boot by hand, but since this is all archived anyways and it's
uneccessarily difficult to find some sort of guide how to even do
this, it might as well be a documentation for users having such
troubles in the future.

Also, besides the way that I have no clue how it would have to look
like to set up a paragraph in the grub.cfg, I simply don't see
anything wrong with it anyways. So I can't even look at the grub
settings files grub.cfg is being generated from to check where the
error lies.

You append the commands that you used to boot manually with into
/etc/grub.d/40_custom, observing the comments there, and also into
grub.cfg itself at the appropriate place (near the bottom). The
former is so that Grub includes it in any new grub.cfg that you
create.

Good to know.
Edit:, never mind. Tried that, it still booted straight to the UEFI BIOS 
menu after entering my password. At this point, I'm seriously 
considering slapping rEFInd on it and pray that it picks up on 
everything automatically and fix the situation. But so should Grub have, 
besides the fact that I can't even be entirely sure Grub is to blame and 
not something else.

Re: Risque ou pas ?

[Étienne Mollier]

Bonsoir,

Yannick, on 2024-01-01:
> Le 01/01/2024 à 19:31, Yannick a écrit :
> > Y-a-t-il un risque à supprimer le contenu du répertoire .cache? Il est
> > plein de sous-répertoire avec des fichiers en grand nombre.
> > 
> > Je pense qu'il n'y a pas de risque mais j'aimerais l'avis des pros de
> > Debian avant de faire une connerie difficile à rattraper ensuite.
> > 
> > Meilleurs vœux à toutes et tous.
> > 
> > Amitiés
> 
> Même chose avec .local/share

Ce répertoire ci est plus délicat.  En théorie, le ~/.local est
un préfixe spécifique à l'utilisateur pour y installer des
programmes sans toucher au système, et donc le ~/.local/share
serait à peu près équivalent au /usr/local/share ou /usr/share.
En pratique, j'y trouve pèle-mèle des journaux, des informations 
de configuration pas vraiment éditables à la main, des fichiers
de sauvegardes, etc.  Il y a à boire et à manger.

À mon avis, il vaut mieux regarder de près ce qu'on y efface.

Mais j'avoue qu'y faire du ménage (ciblé) une fois de temps en
temps peut être salutaire.  Le tout est de s'assurer que ce
qu'on efface ne sert plus.  Une option peut être d'archiver les
données au lieu de les effacer, et de les restaurer le jour où
on a à nouveau besoin du programme correspondant, en admettant
que les données correspondantes (par exemple configuration,
greffons ou sauvegardes), soient encore utiles.

Bonne année !  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-on air: Änglagård - Höstsejd


signature.asc
Description: PGP signature

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

On 01.01.24 20:30, David Wright wrote:

On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:

On 01.01.24 18:13, David Wright wrote:
I can boot by hand, but since this is all archived anyways and it's
uneccessarily difficult to find some sort of guide how to even do
this, it might as well be a documentation for users having such
troubles in the future.

Also, besides the way that I have no clue how it would have to look
like to set up a paragraph in the grub.cfg, I simply don't see
anything wrong with it anyways. So I can't even look at the grub
settings files grub.cfg is being generated from to check where the
error lies.

You append the commands that you used to boot manually with into
/etc/grub.d/40_custom, observing the comments there, and also into
grub.cfg itself at the appropriate place (near the bottom). The
former is so that Grub includes it in any new grub.cfg that you
create.

Good to know.



This is the current content of the grub.cfg: https://pastes.io/bwsmqtkxa4

The UUID of the first partition containing the EFI stuff is 3647-0C47,
the root partition has d602e92a-af2b-4c44-86db-4ea155fafd08 (LUKS1
with ext4 as it seems - why does Debian still not default to creating
LUKS2 by default anyways after 5 years?) and the swap partition has
b33971d1-3407-4d81-a9c2-74c69064aebe (also LUKS1).

Because it could lock people out of their preexisting LUKS partitions.
I meant when you use the automated installer and wipe the whole disk 
anyways. There wouldn't be any preexisting LUKS partitions left that 
could be broken. Or can there not be LUKS1 and LUKS2 at the same time in 
the event that e.g. the device with the system on is LUKS2 and another 
device just containing data was LUKS1?



For me it looks like the grub.cfg has everything it needs to work.

Why do your linux lines have two root= strings?

No idea. I never really touched anything related to grub, besides the 
earlier mentioned tries to get some logs. Also, since it looks like 
there is no grub rescue mode installed (at least it's not being entered 
when it should) I did remove the comment in front of 
GRUB_DISABLE_RECOVER and set it to "false", just in case that for some 
reason it would default to true, thus not installing grub rescue. 
There's only one root in the /etc/default/grub.

Re: Possibly broken Grub or initrd after updates on Testing

[David Wright]

On Mon 01 Jan 2024 at 19:04:20 (+0100), Richard Rosner wrote:
> On 01.01.24 18:13, David Wright wrote:
> > On Mon 01 Jan 2024 at 17:55:29 (+0100), Richard Rosner wrote:
> > > On January 1, 2024 5:43:12 PM GMT+01:00, David Wright wrote:
> > > 
> > > > Like this?
> > > > 
> > > >   └─sda6  8:60 406.2G  0 
> > > > part
> > > > └─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G  0 
> > > > crypt /home
> > > > 
> > > > That's groups of 8 4 4 4 12.
> > > Yes, exactly. Is there a way to show that from inside Grub? Lsblk and 
> > > blkid aren't available there?
> > I thought you could boot by hand. Then all the UUIDs are available
> > to you in lsblk, the /dev/disk/ symlinks, etc. I would then transcribe
> > them into a 40_custom paragraph in grub.cfg so you can boot easily.
> > Then I would work on getting Grub to write its grub.cfg correctly.
> > In the meantime, 40_custom would stay put.
> > 
> I can boot by hand, but since this is all archived anyways and it's
> uneccessarily difficult to find some sort of guide how to even do
> this, it might as well be a documentation for users having such
> troubles in the future.
> 
> Also, besides the way that I have no clue how it would have to look
> like to set up a paragraph in the grub.cfg, I simply don't see
> anything wrong with it anyways. So I can't even look at the grub
> settings files grub.cfg is being generated from to check where the
> error lies.

You append the commands that you used to boot manually with into
/etc/grub.d/40_custom, observing the comments there, and also into
grub.cfg itself at the appropriate place (near the bottom). The
former is so that Grub includes it in any new grub.cfg that you
create.

> This is the current content of the grub.cfg: https://pastes.io/bwsmqtkxa4
> 
> The UUID of the first partition containing the EFI stuff is 3647-0C47,
> the root partition has d602e92a-af2b-4c44-86db-4ea155fafd08 (LUKS1
> with ext4 as it seems - why does Debian still not default to creating
> LUKS2 by default anyways after 5 years?) and the swap partition has
> b33971d1-3407-4d81-a9c2-74c69064aebe (also LUKS1).

Because it could lock people out of their preexisting LUKS partitions.

> For me it looks like the grub.cfg has everything it needs to work.

Why do your linux lines have two root= strings?

Cheers,
David.

Re: Risque ou pas ?

[Yannick]

Le 01/01/2024 à 19:57, Belaïd a écrit :

Bonjour et bonne année à vous tous.

Dans la majorité des cas, tu peux supprimer sans problème tout ce qui 
est dans le dossier .cache de ton home. Les applications le recréeront 
ce répertoire si besoin. Au pire tu le sauvegarde, tu le supprime et tu 
regarde si c'est ok. Tu peux également faire une recherche avec find des 
fichiers qui n'ont pas été accéder depuis longtemps (atome de fond) et 
tu les supprimes.


Le lun. 1 janv. 2024 à 19:42, Yannick > a écrit :


Bonsoir,

Y-a-t-il un risque à supprimer le contenu du répertoire .cache? Il est
plein de sous-répertoire avec des fichiers en grand nombre.

Je pense qu'il n'y a pas de risque mais j'aimerais l'avis des pros de
Debian avant de faire une connerie difficile à rattraper ensuite.

Meilleurs vœux à toutes et tous.

Amitiés


Re,

Merci, c'est après la sauvegarde que j'ai réagi donc on peut y aller 
sans risque.


Amitiés
--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris https://www.ancestris.org



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Risque ou pas ?

[Yannick]

Le 01/01/2024 à 19:57, ajh-valmer a écrit :

On Monday 01 January 2024 19:31:16 Yannick wrote:

Y-a-t-il un risque à supprimer le contenu du répertoire .cache? Il est
plein de sous-répertoire avec des fichiers en grand nombre.
Je pense qu'il n'y a pas de risque mais j'aimerais l'avis des pros de
Debian avant de faire une connerie difficile à rattraper ensuite.
Meilleurs vœux à toutes et tous.


Hello,
Meilleurs voeux 2024 également à tous,
surtout la santé, quand on l'a, tout va finalement.

.cache est comme /tmp, on peut l'effacer à un moment,
sinon, il devient trop volumineux et le système est régénéré.

Bonne soirée.
A. Valmer



Re,

Merci c'est un peu ce que je pensais mais mieux vaut être sûr avant de 
faire des bêtises quoique celle de Cambrai...


Amitiés
--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris https://www.ancestris.org



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Risque ou pas ?

[ajh-valmer]

On Monday 01 January 2024 19:31:16 Yannick wrote:
> Y-a-t-il un risque à supprimer le contenu du répertoire .cache? Il est 
> plein de sous-répertoire avec des fichiers en grand nombre.
> Je pense qu'il n'y a pas de risque mais j'aimerais l'avis des pros de 
> Debian avant de faire une connerie difficile à rattraper ensuite.
> Meilleurs vœux à toutes et tous.

Hello,
Meilleurs voeux 2024 également à tous,
surtout la santé, quand on l'a, tout va finalement.

.cache est comme /tmp, on peut l'effacer à un moment,
sinon, il devient trop volumineux et le système est régénéré.

Bonne soirée.
A. Valmer

Re: Risque ou pas ?

[Belaïd]

Bonjour et bonne année à vous tous.

Dans la majorité des cas, tu peux supprimer sans problème tout ce qui est
dans le dossier .cache de ton home. Les applications le recréeront ce
répertoire si besoin. Au pire tu le sauvegarde, tu le supprime et tu
regarde si c'est ok. Tu peux également faire une recherche avec find des
fichiers qui n'ont pas été accéder depuis longtemps (atome de fond) et tu
les supprimes.

Le lun. 1 janv. 2024 à 19:42, Yannick  a écrit :

> Bonsoir,
>
> Y-a-t-il un risque à supprimer le contenu du répertoire .cache? Il est
> plein de sous-répertoire avec des fichiers en grand nombre.
>
> Je pense qu'il n'y a pas de risque mais j'aimerais l'avis des pros de
> Debian avant de faire une connerie difficile à rattraper ensuite.
>
> Meilleurs vœux à toutes et tous.
>
> Amitiés
> --
> Yannick VOYEAUD
> Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
> (Camille JOUFFRAY 1841-1924, maire de Vienne)
> http://www.voyeaud.org
> Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
> Journées du Logiciel Libre: http://jdll.org
> Généalogie en liberté avec Ancestris https://www.ancestris.org
>
>

Re: kbrequest as in older /etc/inittab

[Greg Wooledge]

On Mon, Jan 01, 2024 at 10:36:41AM -0600, David Wright wrote:
> On Sun 31 Dec 2023 at 23:09:42 (-0600), Mike McClain wrote:
[...]
> Is the history of this issue relevant?
> 
>   https://forums.raspberrypi.com/viewtopic.php?t=282768

Oh, it's the same *name*.  Huh.  So, Mike, whatever you figured out in
2020, you entirely forgot, and now you're starting over in a new forum?

What are you actually trying to do?  If all you want are a bunch of
additional text consoles, you can simply increase the number of gettys
by editing the /etc/systemd/logind.conf file:

...
# See logind.conf(5) for details.

[Login]
#NAutoVTs=6
...

By default, there are 6 gettys available (tty1 through tty6), but you
can increase the number here.  Or decrease it, in theory, but I can't
imagine too many uses for that.

Re: Risque ou pas ?

[Yannick]

Le 01/01/2024 à 19:31, Yannick a écrit :

Bonsoir,

Y-a-t-il un risque à supprimer le contenu du répertoire .cache? Il est 
plein de sous-répertoire avec des fichiers en grand nombre.


Je pense qu'il n'y a pas de risque mais j'aimerais l'avis des pros de 
Debian avant de faire une connerie difficile à rattraper ensuite.


Meilleurs vœux à toutes et tous.

Amitiés


Même chose avec .local/share

Amitiés
--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris https://www.ancestris.org



OpenPGP_signature.asc
Description: OpenPGP digital signature

Risque ou pas ?

[Yannick]

Bonsoir,

Y-a-t-il un risque à supprimer le contenu du répertoire .cache? Il est 
plein de sous-répertoire avec des fichiers en grand nombre.


Je pense qu'il n'y a pas de risque mais j'aimerais l'avis des pros de 
Debian avant de faire une connerie difficile à rattraper ensuite.


Meilleurs vœux à toutes et tous.

Amitiés
--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris https://www.ancestris.org



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

I can boot by hand, but since this is all archived anyways and it's 
uneccessarily difficult to find some sort of guide how to even do this, 
it might as well be a documentation for users having such troubles in 
the future.


Also, besides the way that I have no clue how it would have to look like 
to set up a paragraph in the grub.cfg, I simply don't see anything wrong 
with it anyways. So I can't even look at the grub settings files 
grub.cfg is being generated from to check where the error lies.


This is the current content of the grub.cfg: https://pastes.io/bwsmqtkxa4

The UUID of the first partition containing the EFI stuff is 3647-0C47, 
the root partition has d602e92a-af2b-4c44-86db-4ea155fafd08 (LUKS1 with 
ext4 as it seems - why does Debian still not default to creating LUKS2 
by default anyways after 5 years?) and the swap partition has 
b33971d1-3407-4d81-a9c2-74c69064aebe (also LUKS1).


For me it looks like the grub.cfg has everything it needs to work.

On 01.01.24 18:13, David Wright wrote:

On Mon 01 Jan 2024 at 17:55:29 (+0100), Richard Rosner wrote:

On January 1, 2024 5:43:12 PM GMT+01:00, David Wright 
 wrote:


Like this?

  └─sda6  8:60 406.2G  0 part
└─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G  0 crypt /home

That's groups of 8 4 4 4 12.

Yes, exactly. Is there a way to show that from inside Grub? Lsblk and blkid 
aren't available there?

I thought you could boot by hand. Then all the UUIDs are available
to you in lsblk, the /dev/disk/ symlinks, etc. I would then transcribe
them into a 40_custom paragraph in grub.cfg so you can boot easily.
Then I would work on getting Grub to write its grub.cfg correctly.
In the meantime, 40_custom would stay put.

Cheers,
David.

Re: URLs in Mutt

[John Hasler]

Greg Wooledge:
> It's been my experience that the hyperlinks I'm meant to click are so
> long that they wrap around the terminal width multiple times.  This
> makes copy/pasting them tedious at best, and even then it still
> sometimes fails for me.

My wife has the same problem.
-- 
John Hasler 
j...@sugarbit.com
Elmwood, WI USA

Re: Possibly broken Grub or initrd after updates on Testing

[David Wright]

On Mon 01 Jan 2024 at 17:55:29 (+0100), Richard Rosner wrote:
> On January 1, 2024 5:43:12 PM GMT+01:00, David Wright 
>  wrote:
> 
> >Like this?
> >
> >  └─sda6  8:60 406.2G  0 part  
> >└─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G  0 crypt 
> > /home
> >
> >That's groups of 8 4 4 4 12.
> 
> Yes, exactly. Is there a way to show that from inside Grub? Lsblk and blkid 
> aren't available there?

I thought you could boot by hand. Then all the UUIDs are available
to you in lsblk, the /dev/disk/ symlinks, etc. I would then transcribe
them into a 40_custom paragraph in grub.cfg so you can boot easily.
Then I would work on getting Grub to write its grub.cfg correctly.
In the meantime, 40_custom would stay put.

Cheers,
David.

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

Yes, exactly. Is there a way to show that from inside Grub? Lsblk and blkid 
aren't available there?

On January 1, 2024 5:43:12 PM GMT+01:00, David Wright 
 wrote:

>Like this?
>
>  └─sda6  8:60 406.2G  0 part  
>└─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G  0 crypt 
> /home
>
>That's groups of 8 4 4 4 12.
>
>Cheers,
>David.
>

Re: URLs in Mutt

[Nicolas George]

Greg Wooledge (12024-01-01):
> It's been my experience that the hyperlinks I'm meant to click are so
> long that they wrap around the terminal width multiple times.  This
> makes copy/pasting them tedious at best, and even then it still
> sometimes fails for me.

Surprising. The graphical web browsers I know are actually very tolerant
of spurious newline characters inserted in pasted URLs, and I suspect it
is on purpose. PDFs from magazines might also have wrapped links.

Regards,

-- 
  Nicolas George

Re: Possibly broken Grub or initrd after updates on Testing

[David Wright]

On Mon 01 Jan 2024 at 17:37:44 (+0100), Richard Rosner wrote:
> So, I found a way to manually mount luks partition in Grub and boot from it.
> 
> What I did to get there:
> set root=(hd0,gpt2)
> cryptomount -a
> 
> This gave me the unencrypted version of the root partition as (crypto1)
> 
> set root=(crypto1)
> linux /vmlinuz root=/dev/mapper/luks-UUID
> initrd /initrd.img
> boot
> 
> The problem only is to get the UUID format right. When you're asked to enter 
> the decryption key in a normal boot, it's shown, but without any dashes. But 
> the format must be the same eg Disks shows it. But sure if a Grub tool can 
> show that, but worst case you'll be booted into a initrd BusyBox terminal 
> where you can just look inside /dev/mapper and see the true path that needs 
> to be entered.
> 
> Question is, how do I repair the boot process so I don't have to boot by hand 
> every time?

Like this?

  └─sda6  8:60 406.2G  0 part  
└─luks-f3fbb9ba-a556-406c-b276-555e3e8577bc 254:10 406.2G  0 crypt /home

That's groups of 8 4 4 4 12.

Cheers,
David.

Re: single quote "'" in bash xterm or lxterminal

[David Wright]

On Sun 31 Dec 2023 at 00:43:40 (-0600), Mike McClain wrote:
> I
> suspect logging into a system where you have no home for your primary
> user might get interesting.

That problem is simple to resolve. I have encrypted /home partitions
on all my systems, but the root filesystem has a /home/primaryUser
containing the /etc/skel/* files, in case I should login before
remembering to unock/mount the real /home. (The uncoloured default
prompt makes the mistake obvious.)

What struck me as odd about your narrative was that you place
a configuration file under /mc rather than in the company of
your dotfiles under /home.

Cheers,
David.

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

So, I found a way to manually mount luks partition in Grub and boot from it.

What I did to get there:
set root=(hd0,gpt2)
cryptomount -a

This gave me the unencrypted version of the root partition as (crypto1)

set root=(crypto1)
linux /vmlinuz root=/dev/mapper/luks-UUID
initrd /initrd.img
boot

The problem only is to get the UUID format right. When you're asked to enter 
the decryption key in a normal boot, it's shown, but without any dashes. But 
the format must be the same eg Disks shows it. But sure if a Grub tool can show 
that, but worst case you'll be booted into a initrd BusyBox terminal where you 
can just look inside /dev/mapper and see the true path that needs to be entered.

Question is, how do I repair the boot process so I don't have to boot by hand 
every time?


On January 1, 2024 12:52:40 PM GMT+01:00, Richard Rosner 
 wrote:
>I do not see an answer to my questions.

Re: kbrequest as in older /etc/inittab

[David Wright]

On Sun 31 Dec 2023 at 23:09:42 (-0600), Mike McClain wrote:
> Prior to the introduction of systemd /etc/inittab had this line in it:
> kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this 
> work."
> and I found it useful to tie a call to openvt to Alt Up which went
> well with ALT Right or Left arrow to move between VTs.
> .
> Has anyone knowledge of how to do this under systemd?

Is the history of this issue relevant?

  https://forums.raspberrypi.com/viewtopic.php?t=282768

Cheers,
David.

Re: kbrequest as in older /etc/inittab

[Curt]

On 2024-01-01, Greg Wooledge  wrote:
>
> unicorn:~$ locate kbrequest.target
> unicorn:~$ locate kbrequest
> unicorn:~$ man -k kbrequest
> kbrequest: nothing appropriate.
> unicorn:~$ apt-cache search kbrequest
> unicorn:~$ 
>
> I can't find this in Debian 12.  Do you have more details about it?
>
>


I think it's in systemd.special.

Re: URLs in Mutt

[Andy Smith]

Hello,

On Mon, Jan 01, 2024 at 09:23:03AM -0500, Greg Wooledge wrote:
> Passing the entire text/html part to an actual web browser has been
> what works best for me.

Me too. I'll do the mailcap thing to visually skim the text/html
part with w3m, but there are so many broken HTML messes that I'm
obliged to read that I also have a hotkey to send that text/html
part to Firefox for proper viewing when necessary.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: kbrequest as in older /etc/inittab

[Greg Wooledge]

On Mon, Jan 01, 2024 at 01:53:56PM +0200, Anssi Saari wrote:
> Mike McClain  writes:
> 
> > Prior to the introduction of systemd /etc/inittab had this line in it:
> > kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this 
> > work."
> > and I found it useful to tie a call to openvt to Alt Up which went
> > well with ALT Right or Left arrow to move between VTs.
> > .
> > Has anyone knowledge of how to do this under systemd?
> 
> Looks like there's a special target, kbrequest.target, which is started
> by alt-up. Some more systemd knowledge than I currently have is needed
> to tie openvt into that.

unicorn:~$ locate kbrequest.target
unicorn:~$ locate kbrequest
unicorn:~$ man -k kbrequest
kbrequest: nothing appropriate.
unicorn:~$ apt-cache search kbrequest
unicorn:~$ 

I can't find this in Debian 12.  Do you have more details about it?

Re: URLs in Mutt

[Greg Wooledge]

On Mon, Jan 01, 2024 at 11:42:59AM +0100, Nicolas George wrote:
> Greg Wooledge (12023-12-31):
> > Have your browser load THAT file.
> 
> Or just have this:
> 
> text/html; lynx -force_html -dump %s; copiousoutput
> 
> in your .mailcap file. Possibly along with:
> 
> auto_view text/html
> 
> in the .muttrc.

It's been my experience that the hyperlinks I'm meant to click are so
long that they wrap around the terminal width multiple times.  This
makes copy/pasting them tedious at best, and even then it still
sometimes fails for me.  (Either because I can't actually tell which
one I'm supposed to click, just from reading the lynx-dumped source,
or because there's some Javascript that has to be loaded first?)

Passing the entire text/html part to an actual web browser has been
what works best for me.

On the other hand, if I *don't* want to click anything, the lynx-dumped
source code usually gives me a nice synopsis of what the email is
trying to tell me.  So, it's still worth having, even if I don't
try to copy the URLs out of it manually.

Re: kbrequest as in older /etc/inittab

[Anssi Saari]

Mike McClain  writes:

> Prior to the introduction of systemd /etc/inittab had this line in it:
> kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this 
> work."
> and I found it useful to tie a call to openvt to Alt Up which went
> well with ALT Right or Left arrow to move between VTs.
> .
> Has anyone knowledge of how to do this under systemd?

Looks like there's a special target, kbrequest.target, which is started
by alt-up. Some more systemd knowledge than I currently have is needed
to tie openvt into that.

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

I do not see an answer to my questions.

> On Jan 1, 2024, at 11:52, Michael Kjörling <2695bd53d...@ewoof.net> wrote:
> 
> On 1 Jan 2024 11:46 +0100, from rich...@rosner-online.de (Richard Rosner):
>> I'm not sure what you meant with "rescue mode", but I've reinstalled
>> grub anyways. The log of it doesn't look good though. Quite a bunch
>> of errors. The result also is the same.
> 
> Please review the posts in the thread starting on Dec 21 2023 14:25:26
> UTC, 
> https://lists.debian.org/msgid-search/254ebb90-9a49-4b5a-b1d6-e41b51d8a...@columbus.rr.com
> 
> --
> Michael Kjörling  https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”
> 

Re: Monthly FAQ for Debian-user mailing list (modified 20231216)

[Michael Kjörling]

Could we perchance add something to the FAQ about the
inappropriateness of reposting private replies to the list without
first confirming with the people involved that doing so is acceptable?

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Possibly broken Grub or initrd after updates on Testing

[Michael Kjörling]

On 1 Jan 2024 11:46 +0100, from rich...@rosner-online.de (Richard Rosner):
> I'm not sure what you meant with "rescue mode", but I've reinstalled
> grub anyways. The log of it doesn't look good though. Quite a bunch
> of errors. The result also is the same.

Please review the posts in the thread starting on Dec 21 2023 14:25:26
UTC, 
https://lists.debian.org/msgid-search/254ebb90-9a49-4b5a-b1d6-e41b51d8a...@columbus.rr.com

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: Possibly broken Grub or initrd after updates on Testing

[Richard Rosner]

I'm not sure what you meant with "rescue mode", but I've reinstalled grub 
anyways. The log of it doesn't look good though. Quite a bunch of errors. The 
result also is the same.

https://pastes.io/nvmlsxghlm


> On Jan 1, 2024, at 11:03, Michael Kjörling <2695bd53d...@ewoof.net> wrote:
> 
> On 1 Jan 2024 09:16 +0100, from rich...@rosner-online.de (Richard Rosner):
>> could you please check if you received either of my two tries to get
>> this answer through the mailing list?
> 
> I did not. Maybe they are held for moderation due to size?
> 
> Next time, you can check for yourself at either
> https://lists.debian.org/debian-user/recent or at
> https://lists.debian.org/debian-user/ under the "archives" heading.
> There's also a search there. If a message is not in the archive after
> one or two archive refreshes, it probably didn't make it through the
> list for whatever reason there may be.
> 
> --
> Michael Kjörling  https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”
> 

Re: URLs in Mutt

[Nicolas George]

Greg Wooledge (12023-12-31):
> Have your browser load THAT file.

Or just have this:

text/html; lynx -force_html -dump %s; copiousoutput

in your .mailcap file. Possibly along with:

auto_view text/html

in the .muttrc.

Regards,

-- 
  Nicolas George

Re: URLs in Mutt

[Michael Kjörling]

On 31 Dec 2023 22:51 -0500, from pa...@quillandmouse.com (Paul M Foster):
> As a solution, I took that email from my mutt mail file and stripped out
> all the headers and non-HTML content. Then I fed that to my browser. Sorta
> worked. However, the button I was supposed to click didn't work properly.
> It attempted to retrieve a page it couldn't find. Digging deeper, I looked
> into the actual HTML file. Apparently, something was wrapping lines to
> about 75 characters, and putting an equals sign at the end of every line
> which had been wrapped. This apparently interfered with the browser
> correctly interpreting the HTML.

Install the urlview package, and then pass the mail text/html part to
urlview. (I think it'll accept a simple pipe input.) See urlview(1)
for details.

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”