Re: Aptitude back to neutral state of a package.
Hi, Le 16/06/2024, Dmitry a écrit: > if press `u` => iuA => Update > if pres `-` => idA => Delete > if press `_` => ipA => Purge > if press `=` => ihA => Hold > > But how to go back to `i A`? I believe you are looking for `:`, aka “keep”. This is less strong/persistent than `=` (Hold). Regards -- Florent
Re: After upgrade, what do you do about "removed" and "obsolete" packages ?
Le 01/06/2024, Florent Rougon a écrit: > FWIW, removal of “obsolete or local” packages is easily done > interactively in aptitude: you go the the corresponding section of the > main screen, hit Enter, etc. The [ key recursively unfolds a section > (use ] to fold it back). You ask to purge a package by typing _ > (removing with -, as in the venerable dselect). Forgot to say: one can perform the operation (remove with -, purge with _) on a whole section at once by pressing the key on the section title, where by “section” I mean: a foldable group of packages (e.g.: admin, kernel, libsdevel, libs, etc., plus actual Debian sections: main, contrib, nonfree, and presumably also the new non-free-firmware). So, for instance, a whole bunch of obsolete library pakages can be marked all at once for purge with a single _ keypress (this doesn't exempt one from _reading_ the list of packages marked with this keypress—make sure you didn't overlook something!). Regards -- Florent
Re: After upgrade, what do you do about "removed" and "obsolete" packages ?
Le 31/05/2024, "Thomas Schmitt" a écrit: > Then it offered me a list with slightly frightening wildcards: > > The following packages will be REMOVED: > fuse* libreoffice-avmedia-backend-gstreamer* linux-image-4.19.0-17-amd64* > linux-image-4.19.0-20-amd64* linux-image-4.19.0-9-amd64* python* > python-twisted-core* wicd-daemon* wicd-gtk* AFAIK, these are not wildcards; each star appended to a package name indicates that the package is going to be purged (no config files left afterwards), as opposed to simply removed (leaving configuration files in place). > I will probably run "apt autoremove" after verifying that the few > worthy local packages are not in the list proposed for autoremoval. tl;dr: aptitude praise ~~ FWIW, removal of “obsolete or local” packages is easily done interactively in aptitude: you go the the corresponding section of the main screen, hit Enter, etc. The [ key recursively unfolds a section (use ] to fold it back). You ask to purge a package by typing _ (removing with -, as in the venerable dselect). For actually obsolete packages, doing so will occasionally trigger a “dependency problem” because another package that depends on it hasn't been marked as “to be removed or purged” yet. But normally, that other package is also obsolete, so it *will* be marked shortly after when you get to it. So basically, once you've gone through all the obsolete packages marking each one as “to be purged”, having only left intact the local ones you do want to keep, there should be no dependency problem to resolve. ⇒ Hit g (for “go”), check the preview, hit g again if it looks fine, otherwise q. Note that the preview (of what is going to be done) is shown in a new tab (yes, these are tabs, you can switch between them with F6), and that tab gets closed if you cancel the operation with q. Also, you can act directly in the Preview tab to unmark an operation, etc. And you can undo with Ctrl-u, including outside the Preview tab. Generally and especially for this kind of use (removing obsolete packages that are still installed), I find that the following lines are a must-have in /etc/apt/apt.conf: // Similar to dselect Aptitude::UI::Advance-On-Action "true"; (I also like “Aptitude::Auto-Upgrade "true";” but it is irrelevant here.) apt and aptitude have different algorithms for handling upgrades, so: for stable-to-next-stable upgrades, I do stick to what the Release Notes recommend. In most other situations where there isn't a huge number of packages to upgrade, I find that aptitude does a great job: - interactive control over what is going to be done; - visualization of packages marked as auto-installed vs. those not marked as such (and you can flip this bit using m or M); - interactive, regexp-based search (with powerful features if you look up the syntax in the manual); - interactive package list limited by a user-defined filter (this is Limit Display in the Search menu); - interactive inspection of the (deps a package + other control fields) with Enter; of its reverse deps with the r key (and you can quicky recurse in order to find why you need to have this pkg installed); - works in a terminal; - etc. There is the occasional crash, fortunately I've never seen one happen while dpkg was installing, removing, etc., so the crashes I've seen were all rather harmless (restart aptitude and proceed again). The worst I had was on sid during the time_t transition: at some point, aptitude couldn't start without crashing; however, after upgrading a few packages with 'apt', it all went back into order. :-) Regards -- Florent
Re: After upgrade, what do you do about "removed" and "obsolete" packages ?
Le 30/05/2024, "Thomas Schmitt" a écrit: > So "local" would be just another word for "obsolete" ? My understanding is that “obsolete” and “local” may mean different things to the person who installed the packages (“obsolete” would correspond to the first item of the list at the end of my previous post, “local” to the second one); however, apt and aptitude can't distinguish between them: both categories are comprised of “packages that are installed but not available from the sources scanned during the last 'apt update' run (or 'aptitude update'). I believe someone already wrote something along these lines in this thread (maybe Max). In aptitude, the packages in question are all grouped in the category named “Obsolete and Locally Created Packages”, IMHO because there is no good way to programmatically distinguish between them. (A private package could very well be made available and installed from a private repository; or alternatively, installed with 'dpkg -i' without ever being put in an apt repository; therefore “has been installed in the past from an apt repository” is not a good criterion to distinguish between “obsolete packages” and “local” ones.) Note: I mentioned private packages to simplify wording, but the “Obsolete and Locally Created Packages” category would also contain packages that users sometimes download from third-party websites[1], installing them with 'dpkg -i' or the 'apt' command line tool, without adding any repository to their sources.list(.d). All these are “local packages” from my POV. Regards [1] Printer drivers in .deb form, libdvdcss stuff, etc. (make sure the source is trustworthy!) -- Florent
Re: After upgrade, what do you do about "removed" and "obsolete" packages ?
Hi Thomas, Le 30/05/2024, "Thomas Schmitt" a écrit: > Next documenation riddle is what the word "local" means in output lines > like > > linux-image-5.10.0-rc2-ts/now 5.10.0-rc2-ts-37 amd64 [installed,local] I don't use this but guess it is as in aptitude, where “obsolete/local packages” are packages that are installed (from dpkg's POV) but not available from any of the repositories scanned in the last 'apt update' run. This happens in particular with: - packages that used to be in a repo seen by 'apt update' (often, you installed said packages at that time), but are not included in your current apt sources (/etc/apt/sources.list, /etc/apt/sources.list.d/); this usually happens between Debian releases for some packages shipped by Debian; - packages that are not in any of the repos seen by 'apt update' and that you installed from .deb with 'dpkg -i' (I believe the apt command line tool can also do this); for instance, local packages you prepared yourself but didn't bother to put in an apt repository. Regards -- Florent
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
