Re: LaTex Unicode entry issues

[tomas]

On Fri, Aug 25, 2023 at 06:23:00AM +0200, to...@tuxteam.de wrote:

[...]

> Here [1] [...]

Gah. The ref:

[1] 
https://tex.stackexchange.com/questions/377613/solve-unicode-char-is-not-set-up-for-use-with-latex-without-special-handling-o

-- 
t


signature.asc
Description: PGP signature

Re: LaTex Unicode entry issues

[tomas]

On Thu, Aug 24, 2023 at 04:24:06PM -0400, Haines Brown wrote:
> I'm necessarily  working with a pdfLaTeX document.
> 
> I seem to recall from long ago that I could enter Unicode  
> in this way:
> 
>   002B
> 
> Now it returns the error: "not set up for use with LaTeX." What does 
> this error imply?
> 
> This code works to produce an astrisk: 
> 
>   \char"002A
> 
> but \char"20AE fails although the character ₮ is accessible in my 
> font. The error I get is "Bad character code (8366)...  character 
> number must be between 0 and 255. Does "character number refer to 
> 002A? If so why does this sequence of characters not fall between 0 
> and 255?
> 
> My TexLive runs in emacs and automatically changes " to ``. This makes 
> it annoying to enter Unicode, for I have to paste it from the 
> terminal. Is there an easy way around this?

The short answer: use a Unicode capable TeX/LaTeX engine (LuaTex/LuaLaTeX
is said to be the currently most complete, perhaps also XeTeX). Enter
the characters as Unicode (most probably UTF-8 encoded).

Here [1] is a longer answer, which explains that the "classical" TeX input
engine (and PDFLaTeX is in that category) is not quite up to the task
of "doing" full Unicode. 

I'd go with LuaLaTex. And stop entering funny things like \char"
and use straight UTF-8 instead.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: git setup

[Russell L. Harris]

On Tue, Aug 22, 2023 at 12:59:18AM -0400, Karl Vogel wrote:

   me% cat try
   #!/bin/sh
   export PATH=/usr/local/bin:/bin:/usr/bin
   ssh -q -c aes128-...@openssh.com -i $HOME/.ssh/bkup_ed25519 \
   bkup "logger -t autopull git pull whatever"
   exit 0


I am grateful for the recommendations.  The backup works as expected
if I keep a terminal window open and logged via SSH into the remote
host, and execute ``git pull''.  But I still have not managed to get
the git hook script running.

I decided to document the system and to give the document a title so
that it can be found by others trying to put together a similar
system.  Kindly suggest improvements in the title or the content.

---

USE OF GIT POST-COMMIT HOOK TO AUTOMATE SSH PULL OF A GIT REPOSITORY
FOR DOCUMENT BACKUP

(1) This is a git system running on a pair of Debian computers (LOCAL
and REMOTE) and serving a single user.  All git activity involves only
the MASTER branch; there is no branching or merging.  Routine
operations consist of COMMITS to the production repository on the
local host and PULLS into the backup repository on the remote host.
Passwordless SSH is used for data transfer.

(2) The primary purpose of the git system is archival and backup of
text documents, which are composed in LaTeX markup.  As a document
takes shape during composition, from time to time it is committed.  A
secondary purpose of the git system is to allow reference or
regression to an earlier stage in the development of a particular
document.

(3) SSH is configured for passwordless login to the remote host by the
local host.

(4) The PRODUCTION repository is
``192.168.1.85:/home/rlh/git.production''.

(5) The BACKUP repository is ``192.168.1.35:/home/rlh/git.backup''.

(6) The backup repository was cloned (non-bare) from the production
repository.  The git remote was assigned the alias ``backup''.

(7) A git hook script on the local host named ``post-commit'' calls
SSH on the backup host to pull the latest document version from the
production repository.  The script, the path of which is,
``.git/hooks/post-commit'', follows.  Note that the shebang line
specifies ``bash'', which is appropriate for a Debian/GNU Linux
system:

#!/bin/bash
# post-commit
# 2023.08.24 2200gmt

ssh backup "git pull"
exit 0

Re: Bookworm VPS image and cron

[Steve Sobol]

On 2023-08-05 23:06, Geert Stappers wrote:



> Or you could ask your VPS provider why they aren't providing
> "important" packages in their default image.

This is the first time it's happened. Of the Linux images I've used 
there,
Ubuntu 14.04, 16.04, 18.04, 20.04, 22.04, and Debian bullseye all 
shipped
with cron properly installed. Come to think of it... I just checked a 
local
bookworm VM I'm running at home, and it has cron installed, too. I'll 
open a

ticket.


Response from the provider:

[ Hi Steve,

Thanks for reaching out to DigitalOcean.

I understand you ran into an issue where you found cron was not 
preinstalled on our Debian 12 images. I can confirm that in testing I 
was able to replicate this issue where it's not installed on Debian 12, 
but is on Debian 11 and our Ubuntu images. It sounds to me like a bug, 
so I've submitted a review to our engineering team that handles the 
images for the Droplets. If they determine this to be incorrect they 
will update the image accordingly.


We appreciate the bug report! For the time being, if you need to launch 
a new Droplet with Debian 12 you will want to manually install cron.


If you have any other questions or concerns please feel free reach back 
out at your convenience.


Thank you for being a customer and have a great day! ]

So, there you go... it was a problem with DO's Bookworm image. I'm 
assuming the omission wasn't intentional and if that is, in fact, the 
case, it will get fixed quickly.


Thanks
--Steve

Re: upgrade to bookworm broke phpmyadmin

[Rick Macdonald]

On 8/24/23 07:53, Stefan Monnier wrote:

So, given that I purged everything and re-installed and it still didn't
work, is this indeed a packaging error? I've been running Debian for well
over 25 years (I started with a pre-release before buzz was released) and
I don't remember anything that didn't work after installing.

I don't know the history of this precise thingy, but there can be valid
reasons to install both PHP and Apache, yet not to intend to run PHP
from Apache or not in the way that `a2enmod php8.2` does (especially
given the security risks it entails).

I have a vague recollection of having to explicitly enable/activate PHP
support in Apache's config many years ago, so I believe this is not
a new requirement.


Fair enough, but if somebody installs the phpmyadmin package, which 
requires both PHP and Apache, clearly the intention is to "run PHP from 
Apache in the way that `a2enmod php8.2` does".


So, I finally found the following in 
/usr/share/doc/phpmyadmin/README.Debian:



phpmyadmin for Debian
-


USAGE

  The application will be available at http://localhost/phpmyadmin/
  after install if you use one of supported web servers (Apache and 
Lighttpd

  at time of writing this). Please note that you need to have enabled PHP
  support in your webserver (for Apache you can do this by a2enmod 
php8.2, for

  Lighttpd by lighty-enable-mod fastcgi).


I've been running phpmyadmin for years, so I can't swear I didn't 
manually enable this back in the day. I've done other Debian releases 
along the way but it never broke before.


However, I'm perfectly happy to say it's "my bad": for not scouring 
through these doc files.


Thanks again to all, I REALLY do appreciate the help!

Rick

Re: LaTex Unicode entry issues

[David]

On Thu, 2023-08-24 at 16:24 -0400, Haines Brown wrote:
> I'm necessarily  working with a pdfLaTeX document.
> 
> I seem to recall from long ago that I could enter Unicode  
> in this way:
> 
>   002B
> 
> Now it returns the error: "not set up for use with LaTeX." What does 
> this error imply?
> 
> This code works to produce an astrisk: 
> 
> \char"002A
> 
> but \char"20AE fails although the character ₮ is accessible in my 
> font. The error I get is "Bad character code (8366)...  character 
> number must be between 0 and 255. Does "character number refer to 
> 002A? If so why does this sequence of characters not fall between 0 
> and 255?
> 
> My TexLive runs in emacs and automatically changes " to ``. This
> makes 
> it annoying to enter Unicode, for I have to paste it from the 
> terminal. Is there an easy way around this?

I just use TexMaker - occasionally Texstudio - with unicode enabled in
the editor settings.
Every now and again I will get a bad character reference, but that is
always because of the lack of that character or character size being
supplied by the font foundry concerned.
Not anything to do with the editor or TexLive.
Cheers!

-- 
A Kiwi in Australia,
doing my bit toward raising the national standard.

LaTex Unicode entry issues

[Haines Brown]

I'm necessarily  working with a pdfLaTeX document.

I seem to recall from long ago that I could enter Unicode  
in this way:

  002B

Now it returns the error: "not set up for use with LaTeX." What does 
this error imply?

This code works to produce an astrisk: 

\char"002A

but \char"20AE fails although the character ₮ is accessible in my 
font. The error I get is "Bad character code (8366)...  character 
number must be between 0 and 255. Does "character number refer to 
002A? If so why does this sequence of characters not fall between 0 
and 255?

My TexLive runs in emacs and automatically changes " to ``. This makes 
it annoying to enter Unicode, for I have to paste it from the 
terminal. Is there an easy way around this?

-- 

 Haines Brown 

Re: Debian 30 anos! 14 a 18 de agosto de 2023

[Paulo Henrique de Lima Santana]

Olá,

Já estão disponóveis os vídeos das palestras que aconteceram durante o 
evento para celebrar os 30 anos do Debian.


Playlist no Peertube:
https://peertube.debian.social/w/p/r1gZyzq3anFaECh6QEmU4d

Playlist no YouTube:
https://www.youtube.com/playlist?list=PLU90bw3OpxLoiEUdWm7uyTi71ATGk6oXm

Abraços

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


OpenPGP_signature
Description: OpenPGP digital signature

Re: Looking for a good "default" font (small 'L' vs. capital 'i' problem)

[Christoph K.]

Hi Marco,
thanks for taking the time to reply.

Am Tue, 22 Aug 2023 20:24:39 +0200
schrieb Marco Möller :

> Having had the same problem to solve for myself I ended up to use:
> Noto sans for all my GUI
> Liberation Mono   for coding

The "Noto Sans" has an almost identical glyph for the capital 'i' and the
small 'L'. It's just a straight line and as such doesn't solve my problem.

Christoph

Re: Después de actualizar no arranca «entorno gráfico» de forma automática

[aa ag]

Pues no entiendo bien el porqué, pero al poner los drivers Radeon se ha 
solucionado el problema. Eso que llevaba años usando drivers genéricos...
Bueno, pues queda solucionado el problema.
Mil gracias por el apoyo. 
 
 

Enviar: miércoles 23 de agosto de 2023 a las 19:27
De: "Camaleón" 
Para: debian-user-spanish@lists.debian.org
Asunto: Re: Después de actualizar no arranca «entorno gráfico» de forma 
automática
El 2023-08-23 a las 19:04 +0200, aa ag escribió:

> Enviar: miércoles 23 de agosto de 2023 a las 17:50
> De: "Camaleón" 
> Para: debian-user-spanish@lists.debian.org
> Asunto: Re: Después de actualizar no arranca «entorno gráfico» de forma 
> automática
> El 2023-08-23 a las 17:18 +0200, aa ag escribió:
>
>> > Buenas.
>> > Pues este es el resultado de ~# grep -e "(EE)" -e "(WW)" /var/log/Xorg.*
>>
>> ¡Gracias! :-)
>>
>> > /var/log/Xorg.0.log: (WW) warning, (EE) error, (NI) not implemented, (??) 
>> > unknown.
>> > /var/log/Xorg.0.log:[ 15.181] (WW) The directory 
>> > "/usr/share/fonts/X11/cyrillic" does not exist.
>> > /var/log/Xorg.0.log:[ 15.265] (EE) open /dev/dri/card0: No such file or 
>> > directory
>> > /var/log/Xorg.0.log:[ 15.265] (WW) Falling back to old probe method for 
>> > modesetting
>> > /var/log/Xorg.0.log:[ 15.265] (EE) open /dev/dri/card0: No such file or 
>> > directory
>> > /var/log/Xorg.0.log:[ 15.266] (EE) Unable to find a valid framebuffer 
>> > device
>> > /var/log/Xorg.0.log:[ 15.266] (WW) Falling back to old probe method for 
>> > fbdev
>> > /var/log/Xorg.0.log:[ 15.266] (EE) open /dev/fb0: No such file or directory
>> > /var/log/Xorg.0.log:[ 15.266] (EE) Screen 0 deleted because of no matching 
>> > config section.
>> > /var/log/Xorg.0.log:[ 15.266] (EE) Screen 0 deleted because of no matching 
>> > config section.
>> > /var/log/Xorg.0.log:[ 15.266] (EE) Screen 0 deleted because of no matching 
>> > config section.
>> > /var/log/Xorg.0.log:[ 15.287] (WW) VESA(0): Unable to estimate virtual size
>
>> (...)
>
>> ¿Puedes subir el archivo completo «/var/log/Xorg.0.log» a pastebin o algún 
>> sitio similar
>> (p. ej., «https://paste.debian.net/»)?
>>
>> El archivo no contiene datos sensibles, puedes subirlo completo sin
>> problemas.

> Claro, ahí va: 
> https://paste.debian.net/1289829/[https://paste.debian.net/1289829/]
> Gracias y un saludo.

Hum... no veo errores PERO algo le pasa a tu servidor gráfico porque
*carga el driver VESA* y no creo que sea eso lo que quieras (tampoco
debería ser motivo para que no nicie LightDM pero desde luego algo no
marcha bien por es aparte), entiendo que tienes un adaptador ATI y
deberías cargar el driver libre (RADEON) o el propietario pero no el
genérico (framebuffer):

[ 15.264] (II) RADEON: Driver for ATI/AMD Radeon chipsets:
(...)
[ 15.265] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 15.265] (II) FBDEV: driver for framebuffer: fbdev
[ 15.265] (II) VESA: driver for VESA chipsets: vesa
[ 15.265] (II) [KMS] drm report modesetting isn't supported.
[ 15.265] (EE) open /dev/dri/card0: No such file or directory
[ 15.265] (WW) Falling back to old probe method for modesetting
[ 15.265] (EE) open /dev/dri/card0: No such file or directory
[ 15.265] (II) Loading sub module "fbdevhw"
[ 15.265] (II) LoadModule: "fbdevhw"
[ 15.265] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 15.266] (II) Module fbdevhw: vendor="X.Org Foundation"
(...)
[ 15.266] (II) UnloadModule: "radeon"
[ 15.266] (EE) Screen 0 deleted because of no matching config section.
[ 15.266] (II) UnloadModule: "modesetting"
[ 15.266] (EE) Screen 0 deleted because of no matching config section.
[ 15.266] (II) UnloadModule: "fbdev"
[ 15.266] (II) UnloadSubModule: "fbdevhw"
[ 15.266] (II) Loading sub module "vbe"
[ 15.266] (II) LoadModule: "vbe"
[ 15.266] (II) Loading /usr/lib/xorg/modules/libint10.so
[ 15.267] (II) Module int10: vendor="X.Org Foundation"
[ 15.267] compiled for 1.21.1.8, module version = 1.0.0
[ 15.267] ABI class: X.Org Video Driver, version 25.2
[ 15.267] (II) Loading sub module "int10"
[ 15.267] (II) LoadModule: "int10"
[ 15.268] (II) Loading /usr/lib/xorg/modules/libint10.so
[ 15.268] (II) Module int10: vendor="X.Org Foundation"
[ 15.268] compiled for 1.21.1.8, module version = 1.0.0
[ 15.268] ABI class: X.Org Video Driver, version 25.2
[ 15.268] (II) VESA(0): initializing int10
(...)

Salvo que quieras cargar el driver VESA por algo en concreto (?) yo
intentaría resolver ese problema con el servidor gráfico antes que nada:

https://wiki.debian.org/AtiHowTo[https://wiki.debian.org/AtiHowTo]

Saludos,

--
Camaleón
 

cups blowed up again, when do we get a print system that Just Works?

[gene heskett]

Greeting all;
bookworm, upto date, cups 2.4.2 installed.

I goto print a doc on a 3d printer control card, and can't print a pdf 
from firefox.


So I goto localhost:631, no printers! I had 4 the day before yesterday, 
and used 2 of them.


So I goto add printers, get asked for my passwd, and then all of them 
show up but can't do a test page, no response, so I reconfigure the big 
one for lowwr tray, duplex on duplex copy paper.  Print a test page, 
works, so I configure this same printer a second time for foto paper 
from tray 1, print test page works to expen$ive paper, go back to first 
and resend another test page to see if it still draws paper from tray 2, 
it does.


So since I'm on a roll. configure the b duplex laser printer, send a 
test page, works. 2 copies of that printer so I send a test to it. 
doesn't respond so I delete it. Go back to firefox, select print the 27 
page pdf I'm looking at, no response. Goto journalctl and see it say:

==
Aug 24 12:55:29 coyote firefox-esr[141594]: g_object_ref: assertion 
'G_IS_OBJECT (object)' failed
Aug 24 12:55:35 coyote plasmashell[2495]: libkcups: 
Get-Printer-Attributes last error: 0 successful-ok
Aug 24 12:55:35 coyote plasmashell[2495]: libkcups: 3 
"Brother_MFC_J6920DW_duplex_lowertray_coyote"
Aug 24 12:55:42 coyote kwin_x11[2453]: qt.qpa.xcb: QXcbConnection: XCB 
error: 3 (BadWindow), sequence: 10153, resource id: 90188401, major 
code: 15 (QueryTree), minor code: 0

===

I even added myself to the lp user in /etc/group, still no response.

Where do I look next?

Thanks.

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

Re: upgrade to bookworm broke phpmyadmin

[Stefan Monnier]

> So, given that I purged everything and re-installed and it still didn't
> work, is this indeed a packaging error? I've been running Debian for well
> over 25 years (I started with a pre-release before buzz was released) and
> I don't remember anything that didn't work after installing.

I don't know the history of this precise thingy, but there can be valid
reasons to install both PHP and Apache, yet not to intend to run PHP
from Apache or not in the way that `a2enmod php8.2` does (especially
given the security risks it entails).

I have a vague recollection of having to explicitly enable/activate PHP
support in Apache's config many years ago, so I believe this is not
a new requirement.


Stefan

Re: "locate" easier to use than "find"

[Greg Wooledge]

> > to...@tuxteam.de (12023-08-24):
> > > Dunno. I use find nearly every day. Seeing it as "just a recursive
> > > grep" doesn't cover a fraction of its usefulness.
> > >
> > > A couple of days ago I was searching for dangling symlinks.
> > >
> > >   find . -follow -lname "*"

Wow... what a cryptic pair of options this is.  From the man page:

   -L Follow symbolic links.  When find examines or prints information
[...]
Using  -L  causes the -lname and -ilname
predicates always to return false.

And:

   The -follow option has a similar effect to -L, though it  takes  effect
   at  the  point where it appears (that is, if -L is not used but -follow
   is, any symbolic links appearing after -follow on the command line will
   be dereferenced, and those before it will not).

And:

   -follow
  Deprecated; use the -L  option  instead.   Dereference  symbolic
  links.   Implies -noleaf.  The -follow option affects only those
  tests which appear after it on the command line.  Unless the  -H
  or -L option has been specified, the position of the -follow op‐
  tion changes the behaviour of the -newer  predicate;  any  files
  listed  as  the  argument of -newer will be dereferenced if they
  are symbolic links.  The same consideration applies to -newerXY,
  -anewer and -cnewer.  Similarly, the -type predicate will always
  match against the type of the file that a symbolic  link  points
  to rather than the link itself.  Using -follow causes the -lname
  and -ilname predicates always to return false.

And:

   -lname pattern
  File is a symbolic link whose contents match shell pattern  pat‐
  tern.  The metacharacters do not treat `/' or `.' specially.  If
  the -L option or the -follow option is in effect, this test  re‐
  turns false unless the symbolic link is broken.

So that's two votes for "this can't possibly work" and one vote for
the opposite.  From within the same manual.  Yikes.

(And the POSIX manual doesn't help here, because -lname is a GNU extension.)

Re: "locate" easier to use than "find"

[Nicolas George]

Stanislav Vlasov (12023-08-24):
> Sometimes it's unexpected :-)

Then the shell prints an error and I try again. Still less time wasted
than these two mails.

Regards,

-- 
  Nicolas George

Re: "locate" easier to use than "find"

[Stanislav Vlasov]

чт, 24 авг. 2023 г. в 18:17, Nicolas George :

> > With a really large amount of files there will be overflow of process
> > environment (or too large cmdline).

> If I expect a very large amount of files, I can use it another way.

Sometimes it's unexpected :-)

-- 
Stanislav

Re: "locate" easier to use than "find"

[tomas]

On Thu, Aug 24, 2023 at 02:05:48PM +0200, Nicolas George wrote:
> to...@tuxteam.de (12023-08-24):
> > Dunno. I use find nearly every day. Seeing it as "just a recursive
> > grep" doesn't cover a fraction of its usefulness.
> > 
> > A couple of days ago I was searching for dangling symlinks.
> > 
> >   find . -follow -lname "*"
> 
> ls **/*(N@-@)
> 
> Zsh rulz.

Definitely. My point was rather to illustrate the kind of things
find can do that locate can't.

There is more than one way to do it (TM).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: "locate" easier to use than "find"

[Nicolas George]

Stanislav Vlasov (12023-08-24):
> With a really large amount of files there will be overflow of process
> environment (or too large cmdline).

If I expect a very large amount of files, I can use it another way.

-- 
  Nicolas George

Re: "locate" easier to use than "find"

[Stanislav Vlasov]

чт, 24 авг. 2023 г. в 17:06, Nicolas George :
>
> to...@tuxteam.de (12023-08-24):
> > Dunno. I use find nearly every day. Seeing it as "just a recursive
> > grep" doesn't cover a fraction of its usefulness.
> >
> > A couple of days ago I was searching for dangling symlinks.
> >
> >   find . -follow -lname "*"
>
> ls **/*(N@-@)

With a really large amount of files there will be overflow of process
environment (or too large cmdline).
locate and find does not store filenames in memory.

-- 
Stanislav

Re: "locate" easier to use than "find"

[Nicolas George]

to...@tuxteam.de (12023-08-24):
> Dunno. I use find nearly every day. Seeing it as "just a recursive
> grep" doesn't cover a fraction of its usefulness.
> 
> A couple of days ago I was searching for dangling symlinks.
> 
>   find . -follow -lname "*"

ls **/*(N@-@)

Zsh rulz.

Regards,

-- 
  Nicolas George

Re: "locate" easier to use than "find"

[tomas]

On Thu, Aug 24, 2023 at 01:52:28PM +0200, Oliver Schoede wrote:

[...]

> Have basically stopped using traditional 'find' outside of scripts, as
> always thought I was about the last one [...]

Dunno. I use find nearly every day. Seeing it as "just a recursive
grep" doesn't cover a fraction of its usefulness.

A couple of days ago I was searching for dangling symlinks.

  find . -follow -lname "*"

did the trick.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: "locate" easier to use than "find"

[Oliver Schoede]

On Mon, 21 Aug 2023 15:56:11 +0200
 wrote:

>On Mon, Aug 21, 2023 at 03:19:19PM +0200, Roger Price wrote:
>> On Mon, 21 Aug 2023, Hans wrote:
>> 
>> > find .mozilla -name favicons.sqlite -ls
>> >  1512492   2144 -rw-r--r--   1 myusername myusernama  2195456 Aug
>> > 21 13:29 .mozilla/firefox/gs0gkgv2.default/favicons.sqlite 1515049
>> >    260 -rw-r--r--   1 myusername myusername   262144 Aug 18 22:36
>> > .mozilla/firefox/th3dv2jy.default-1461749950404/favicons.sqlite
>> 
>> For me command "locate" is easier to use than "find":
>
>They do different things. Locate is much faster, but it only looks
>into file names. Find can do nearly everything, like looking into
>file metadata ("show me all files younger than 12 days" or "owned
>by www-data"), running external programs (e.g. grep), yadda, yadda.
>
>To each job its tool.
>
>Cheers

Have basically stopped using traditional 'find' outside of scripts, as
always thought I was about the last one. Replaced with 'fd-find' which
really is simpler/more intuitive, sometimes actually faster. Quite
typical case where ~20% of the functionality will be doing the trick
90% of the time, in less time, and to me that already looks more like
99%. Especially on single user systems. I'm feeling rather more sorry
to say it's the same with 'ag', better known as the silversearcher,
another one of those long-serving workhorses that by the way is slated
for being dropped from Debian in just a couple of days: no longer
maintained, long dead upstream. I've used it for heavy grepping about
everywhere and for so many years. Most obvious replacement in this case
apparently 'ripgrep', also Rust of course. Has a few more edges I find
a little weird but got comfortable in a matter of a days anyhow. It's
all similar enough, about the hardest part is getting the actual
commands right: never a big fan of aliases I still regularly type
'find' instead of 'fd', it's muscle memory. ;)

Meanwhile traditional (m)locate got itself replaced with plocate, it
wasn't always that fast! Old things go, new arrive, I'm still using
bash though. Sorry for going off on another tangent. If anyone is still
using 'ag', just consider the options. And yes, GNU 'find' is
overcomplicated, I've long made do with a couple of shell functions
just to fight the repetition.


Oliver

Re: VM using Debian cloud image does not connect to virtual network.

[Cristian Capsuna]

Hello,

I have found the solution to this and want to drop it here in case
someone finds this and has the same problem. The solution is described in
this

section of the Debian documentation.

Kind regards,
Cristian Căpșună


On Wed, 16 Aug 2023 at 07:35, Michael Kjörling <2695bd53d...@ewoof.net>
wrote:

> On 16 Aug 2023 07:26 +0100, from cristian.caps...@gmail.com (Cristian
> Capsuna):
> > Also I really like your website design. I've got it as a personal
> goal
> > to create one for myself at some point.
>
> Thank you. It's a ready-made Wordpress theme (Lovecraft) which I have
> tweaked with some custom CSS, so for most of the design I can't claim
> credit.
>
> --
> Michael Kjörling  https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”
>
>

Re: kernel 6.4.0-3 (testing) cannot be installed with virtualbox-dkms

[Tixy]

On Thu, 2023-08-24 at 10:06 +0200, Erwan David wrote:
> I had an upgrade failure today, when upgrading kernel to 6.4.0-3 : 
> virtualbox-dkms needs a function which disappeared from kernel headers.
> 
> I opened the bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050406
> 

Which has been marked as a duplicate of another bug [1] which includes
a link to the Virtualbox bug tracker [2] where it looks like they have
committed a fix a couple of days ago. So perhaps you want to get the
latest Virtualbox code?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050096
[2] https://www.virtualbox.org/ticket/21796

-- 
Tixy

kernel 6.4.0-3 (testing) cannot be installed with virtualbox-dkms

[Erwan David]

I had an upgrade failure today, when upgrading kernel to 6.4.0-3 : 
virtualbox-dkms needs a function which disappeared from kernel headers.


I opened the bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050406

--
Erwan David