Re: migrating grub from BIOS to UEFI loses /etc/default/grub
Le 28/05/2024, Harald Dunkel a écrit: > Full thread is on debian-boot mailing list. I've read it now, thanks for the info, Harald! Regards -- Florent
Re: migrating grub from BIOS to UEFI loses /etc/default/grub
Hi, Le 24/05/2024, Harald Dunkel a écrit: > if I migrate from grub-pc to grub-uefi, then grub-pc.postrm > removes /etc/default/grub on the final purge. I confirm the behavior, have been bitten by this. IMHO, it is a nasty bug: suppose your rely on your kernel command line to disable, say, the IPv6 stack—because you don't need it and your firewall rules don't handle IPv6. When grub-pc is purged, the IPv6 stack gets silently activated on your box, even though you are still naked regarding the firewall. :( Regards -- Florent
Re: Quickemu Problem
Le 19/05/2024, Timothy M Butterworth a écrit: > sudo sync && sh -c "/usr/bin/echo 1 > /proc/sys/vm/drop_caches" --w--- 1 root root 0 19 mai 13:11 /proc/sys/vm/drop_caches The redirection won't work unless the person is already root—there was a thread about this here just a few days ago. :-) Regards -- Florent
Re: Dovecot correct ownership for logs
Le 14/05/2024, to...@tuxteam.de a écrit: > You might try > > ps -eo pid,user,group,comm | grep postfix > > or similar. Yep, and beware that the original message mentions a postfix program named 'local' (/usr/lib/postfix/sbin/local). > May 13 20:55:37 mail postfix/local[2824184]: (...) Regards -- Florent
Re: debian bookworm japanese kana input disabled
Hi, Le 09/05/2024, 冨澤守治 a écrit: > Hellow! > > Thanks you for your supprting everyday. > > Last night (JST) I did some apt update && apt upgade. > But all of sudden I can't input kana and even print any editer or calc cell. > (Roman alphabet has no problem on printing.) This may be due to a recent glib2.0 update: https://lists.debian.org/debian-security-announce/2024/msg00094.html “The update for glib2.0 released as DSA 5682-1 caused a regression in ibus affecting text entry with non-trivial input methods. Updated glib2.0 packages are available to correct this issue.” Hopefully, you just need to update again. Regards -- Florent
Re: Fwd: Debian 11 Xfce panel Network Manager applet has disappeared
Hi, Le 18/04/2024, David Christensen a écrit: > 2024-04-18 02:27:18 root@laalaa ~ > # df `which nm-applet` > Filesystem 1M-blocks Used Available Use% Mounted on > /dev/mapper/sdb3_crypt12084M 8927M 2522M 78% / Not sure this command is super-useful: % df $(which awk) Filesystem 1K-blocks Used Available Use% Mounted on /dev/md127 97399092 28350256 64055044 31% / % which awk /bin/awk % readlink -f /bin/awk /usr/bin/gawk Another thing: did you look into ~/.xsession-errors? (Sorry if this was already mentioned and I missed it.) More involved: if you can't find any trace of the applet doing something, maybe rebuilding the package after adding a few fprintf() calls would help. Regards -- Florent
Re: making Debian secure by default
Le 28/03/2024, Greg Wooledge a écrit: > You can't stop root from writing to your terminal. Root has write > privileges on all devices. > > The purpose of mesg is to allow *other regular users* to send you > messages, or not. (...) Indeed, I understood that after running 'ls -la $(tty)', as suggested elsewhere by Andy. Thanks for the complement and all your useful messages. Regards -- Florent
Re: making Debian secure by default
Le 28/03/2024, Florent Rougon a écrit: > Did I miss the point of 'mesg n'?.. Ugh, sorry. Thanks to the 'ls -la $(tty)' command Andy Smith wrote in another message, I understood: 'mesg n' does prevent users from writing to your terminal using e.g. 'wall', *except* if said users are either root or yourself. So I redid the above test but using 'wall' from *another* non-root account: 'mesg n' did prevent the messages from coming through, and 'mesg y' allowed them again. All good. :-) Regards -- Florent
Re: making Debian secure by default
Hi, Le 27/03/2024, Andy Smith a écrit: > You could put a call to "mesg n" into a file in /etc/profile.d so > that all users execute it. Did anyone try 'mesg n' here? I tried: $ mesg n $ mesg; echo $? is n 1 Broadcast message from root@hostname (pts/1) (Thu Mar 28 16:48:13 2024): pouet Broadcast message from simpleuser@hostname (pts/3) (Thu Mar 28 16:48:49 2024): a Did I miss the point of 'mesg n'?.. Thanks, regards -- Florent
Re: printing QR-codes on labels with 300dpi label printers with LaTeX
Florent Rougon wrote:
> - printer matrix alignment if printer resolution is low (more
> difficult; maybe try with some very small horizontal and veritical
> shifts to see if it helps...).
Thinking about it more, this is probably hopeless unless printer
resolution is *extremely* low. Typical printer dots are so small that
you can't realistically expect paper placement to have good enough
precision to align both grids (say, 1/4 of the printer dot size).
This is, I believe, what Jeremy meant when he wrote earlier in this
thread:
> Getting back to pixel registration, the latex CUPS route is very unlikely to
> work well. However a custom application that generates a pixel perfect bitmap
> that is printed at 100% scale through cups should work.
I agree with that if printer resolution is so low that the QR code and
printer dot grids have to be aligned. Even with perfect size in the PDF,
there is very little hope that paper will be every time correctly
aligned in the vertical and horizontal directions with the matrix of
dots managed by the printer—a dot at 300 dpi being approximately
0.08 mm. The only realistic hopes are:
- high enough resolution that grid alignment doesn't really matter (is
300 dpi enough? Maybe.);
- direct control over the printer bitmap (what Jeremy mentioned).
For the sake of completeness, the following LaTeX document (an inline
attachment) draws a QR code whose modules are correctly placed for some
“ideal” 300 dpi printer. This assumes that printer dots perfectly start
at a dot-size multiple from the top left corner of the physical page,
which probably can't be obtained in practice. So, this is mainly to show
how accurate placement and computations can be done (\fpeval is provided
by xfp; it is very accurate and expandable).
\documentclass{article}
\usepackage[papersize={50mm,35mm},margin=0cm]{geometry}
\usepackage{xfp}
\usepackage{qrcode}
\pagestyle{empty}
\newlength{\modulesize}
\setlength{\modulesize}{\fpeval{6/300}in}% assume 300 dpi, set 6 dots/module
\begin{document}
\noindent
\hspace{10\modulesize}% horizontal offset from paper edge: 10 modules
\raisebox{\dimexpr \topskip - \height - 10\modulesize}{% ditto in vert. direction
\qrcode[height=25\modulesize, version=2]{Hey Debian-user!}}%
% The modules will have the expected size only if the QR code is effectively
% doable at version=2 (check the LaTeX terminal output). Indeed, version=2
% means 25×25 modules.
\end{document}
Regards
--
Florent
Re: printing QR-codes on labels with 300dpi label printers with LaTeX
hw wrote:
>> That is quite likely: the pst- prefix means this is PSTricks, which is
>> an oldish way of doing vector graphics with LaTeX. I tend to avoid
>> PSTricks these days as it is generally awkward to use in PDF contexts,
>> although there are various workarounds that often allow to do so.
>
> Is that bad? It works great for what I'm doing.
Well, “bad” is a strong word in this context. ;-) First, PDF has been
replacing PostScript in the last 20+ years, so it is often easier to
find tools that do interesting things with PDF than with PostScript.
Second, regarding the existing workarounds that allow PSTricks code to
be used in PDF workflows: I haven't used many of them but AFAIK, most of
the times, if you want things to work automatically, you need to enable
\write18 which has security implications. In the most relaxed case, it
allows the compiled document, as well as any class or package it loads,
to run arbitrary shell commands. There is a restricted mode for \write18
(see -shell-restricted and “§5.5 Shell escapes” in `texdoc web2c`), but
it currently doesn't allow running ps2pdf:
,[ /usr/share/texmf/web2c/texmf.cnf ]
| shell_escape_commands = \
| bibtex,bibtex8,\
| extractbb,\
| gregorio,\
| kpsewhich,\
| makeindex,\
| memoize-extract.pl,\
| memoize-extract.py,\
| repstopdf,\
| r-mpost,\
| texosquery-jre8,\
|
| % we'd like to allow:
| % dvips - but external commands can be executed, need at least -R1.
| % epspdf, ps2pdf, pstopdf - need to respect openout_any,
| % and gs -dSAFER must be used and check for shell injection with filenames.
| ...
`
One of the problems with PostScript is that it is “too powerful” for
something that should only produce text and graphics—AIUI, security
concerns were not at the core of its design.
Finally, for a few things like transparency and “new” font formats
(e.g., TrueType, OpenType), PostScript is either a no-go or has
solutions that appeared very late, contrary to PDF.
>> The ubiquitous, powerful and modern way to do vector graphics in LaTeX
>> is PGF/TiKZ[1],
>
> That package has almost 1300 pages of documentation which doesn't seem
> to mention qr-codes or barcodes.
Right. Presumably, the qrcode package is good enough. BTW, since its
\qrcode command produces a TeX box without using any TikZ code, it can
be placed without restriction in a TikZ node (I say this because TikZ
nodes can't be nested—more precisely, doing so is not supported).
> I wonder why it uses different options for URLs and other data. What
> difference does that make?
I believe you misunderstood the manual here, or maybe I don't understand
what you meant. The \qrcode command can encode both URLs and other text.
What I see is simply options (and the starred variant \qrcode*) to
decide whether to turn the QR codes into PDF hyperlinks.
Global switch at \usepackage level: hyperlinks/nolinks
Local switch for each \qrcode command: link/nolink
\qrcode*{…} == \qrcode[nolink]{…}
These options are provided because when the hyperref package is loaded,
QR codes are output as hyperlinks by default; however, it is quite
possible to write QR codes that don't encode URLs, in which case making
them hyperlinks would be confusing and useless.
> It might be worth a try for when I need to experiment with qr-codes on
> small labels again. It might not work because I may need to place the
> qr-code in some way and it could conflict with other packages like the
> labels package ... I even might have already tried it; it's been a
> few years and I don't remember exactly.
Since \qrcode outputs a TeX box without using any TikZ code, it has
about the highest level of “compatibility” you can expect in a TeX
document.
> Now I'm wondering why the qr-codes I printed with the label printer
> couldn't be reliably scanned. When I look at [1] and [2], for the
> data I wanted to print (between 38 and 40 alphanumericals at L
> quality) I would have to use a version 2 qr code, i. e. 25x25 modules.
> I don't know how the modules transfer to dots, but assuming the
> minimum of 4 dots per module, it would take 25 x 4 dots, i. e. 100
> dots. Each module would be 0.33mm in size which would require 25 x
> 0.33mm, i. e. 8.25mm for the size of the qr-code.
>
> I printed the qr-code much larger than that, about 1x1". That is
> about three times as large as would be required, and the printer can
> print three times as many dots per inch as the 100 dots needed.
>
> So in theory, my theory that the resolution of the printer is too low
> can't be true.
>
> But why couldn't these qr-codes be scanned? It shouldn't have been a
> problem at all.
L quality is the worst; can't you use a better one? Also worth
considering:
- scanner limitation? Did you try to scan the codes with a smartphone?
- printer matrix alignment if printer resolution is low (more
difficult; maybe try with some very small horizontal and veritical
shifts to see if it helps...).
Regards
--
Florent
Re: printing QR-codes on labels with 300dpi label printers with LaTeX
Hi,
I haven't read the whole thread (sorry) but thought this might help.
hw wrote:
> When I zoom in on QR-codes in a PDF viewer, they don't get blurry.
> Perhaps the pst-barcode package uses vector graphics?
That is quite likely: the pst- prefix means this is PSTricks, which is
an oldish way of doing vector graphics with LaTeX. I tend to avoid
PSTricks these days as it is generally awkward to use in PDF contexts,
although there are various workarounds that often allow to do so.
The ubiquitous, powerful and modern way to do vector graphics in LaTeX
is PGF/TiKZ[1], however this is not even necessary for QR codes, because
these are made of perfect monochrome rectangles, which TeX can draw
natively using its \hrule and \vrule primitives.
> 'pdfimages -list' doesn't show any images for a PDF with QR-codes
> created with pdflatex.
AFAIK, 'pdfimages' would extract “actual images” embedded in a PDF file
(e.g., PNG or JPG), however here pst-barcode presumably uses PostScript
or PDF primitives for drawing and filling polygons, which in your case
probably end up as PDF primitives. Hence, 'pdfimages' can't see these QR
codes (AFAIUI).
I've played with a different package for producing QR codes in LaTeX,
which uses the aforementioned \hrule and \vrule primitives: qrcode. Its
manual is here (follow the “Package documentation” link):
https://ctan.org/pkg/qrcode
Here is a simple example you can compile with pdflatex:
\documentclass{article}
\usepackage{qrcode}
\pagestyle{empty}
\begin{document}
\noindent
% \qrset affects \qrcode commands in the current group. You can use it
% to factor out options used for several QR codes.
\qrset{nolinks, padding}% add padding to make sure the codes are
“legal”/readable
\qrcode[version=1]{Hey Debian-user!}% Can't do version=1 with level=M or more
\qrcode[level=L, version=1]{Hey Debian-user!}% Less redundancy but is doable
\end{document}
Note the terminal output:
There are several quality levels allowing error correction (see the
manual): Low, Medium, Quality, and High. They correspond to 'level'
values L, M, Q, H. Default is M but if the chosen 'version' (which maps
to a specific number of modules) allows for a better level, qrcode
automatically upgrades to the best level possible for the chosen
'version' (which the above log demonstrates for the first QR code).
My example tries to print two QR codes with version=1, which means
21×21 modules (see below). Using the default level (M), this is not
possible for the specified text, therefore the first QR code is drawn as
a version=2 one (i.e., it has 25×25 modules). For the second QR code, I
explicitly ask for level=L which has the worst redundancy for error
correction; this allows "Hey Debian-user!" to be QR-encoded with
version=1, i.e. as a square of 21×21 modules.
The length of what you are encoding obviously dictates which quality
parameters you can afford, so you need to play with actual text for your
application. You can control the size of the QR code with e.g.
\qrcode[height=1cm]{...}. Since the modules are stuck to each other,
once you've determined an appropriate 'version' parameter, you can
easily choose a height that causes the modules to have the exact size
you want in the resulting PDF file (printer driver issues are out of my
league).
Regarding the 'version' parameter:
version=1 → 21×21 modules
version=2 → 25×25 modules
version=3 → 29×29 modules
...
version=40 → 177×177 modules
(each version step adds 4 to the number of modules in each direction)
So, you may want to play with text of yours and these parameters.
Examine the terminal output or log file to make sure the qrcode package
didn't have to increase the 'version' in order to encode the text you
specified. Note that in my example, the second QR code scanned with a
smartphone from a computer screen display seems to be significantly
harder to recognize than the first one (IOW, using level=L is probably a
bad idea even though it allows one to reduce the number of modules. But
with low printer resolution constraints, who knows?).
Hope this helps!
Regards
[1] https://ctan.org/pkg/pgf
--
Florent
Re: Fix for missing gsettings desktop schemas on unstable
Ash Joubert wrote: > You are welcome. There is a bug report with much discussion: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065022 Thanks again Ash, that was quite informative. Regards -- Florent
Re: Fix for missing gsettings desktop schemas on unstable
Hi, Ash Joubert wrote: > There is a huge transition underway on unstable to migrate to 64-bit time_t. > After upgrading to the new libglib2.0-0t64, nothing could find gsettings > desktop schemas, breaking applications like rednotebook and reportbug (lol), > and after a reboot, stopping services like at-spi from starting, causing huge > timeouts at system and application start. > > A workaround that worked for me was to reinstall > gsettings-desktop-schemas: Same problem here and your workaround does help (before it, I couldn't even get Firefox to display a “File Open” dialog without crashing). Thanks a lot! Regards -- Florent
Re: what calculator do you use?
Eric S Fraga wrote: > Emacs Calc if using the computer, HP-48x simulator on my phone > otherwise. If you liked doing calculations as in the HP 48, try the orpie program in a terminal (Debian package of the same name)... or the x48 emulator on Linux (GUI, very impressive). More scripting-oriented, dc can be used to compute in Reverse Polish Notation: $ echo '3 5 + 2 / p' | dc 4 $ Regards -- Florent
Re: Sound issues on ThinkPad X220T (Lenovo)
Hi, For the record, I had the exact same problem on a computer running buster that I don't use very often. For sure, it was working fine even with timidity installed a few months ago. Many thanks to Andrei for the 'lsof | grep /dev/snd' command that pointed us in the right direction! Debugging these sound issues that appear spontaneously on a previously-working setup is not easy, especially now that PulseAudio is required everywhere. Regards -- Florent
