Re: Apt configuration - As Stable As Possible

[Sven Joachim]

On 2024-04-07 04:48 +0300, Cyprus Socialite wrote:

> I am trying to configure Apt to follow a "stable where we can, unstable
> where we must" logic.
>
> On the "Stable+Backports - Testing - Unstable - Experimental" stencil, I
> would like to
>
> - install left-to-right (the stablest version available),
>
> - upgrade right-to-left (the stablest newer version available, but never
> less stable than the one currently installed).
>
> I have already achieved the desired Install behaviour with Pin-Priorities,
> but upgrade is more challenging.
>
> For example, if I have foo=2 installed from testing, and the newer versions
> available are foo=3 in stable and foo=4 in testing, apt seems to go for
> testing, whereas I would prefer the stabler though not-so-much-newer
> version by default.

This would be rather strange and does not match my experience.  Can you
please show the output of "apt policy"?

> Furthermore, I would like to keep the aforementioned stencil fixed on my
> current release until and unless I'm ready for an upgrade.
>
> I imagine this can be achieved by sticking explicit names (e.g.
> bookworm/trixie in place of stable/testing) everywhere, but maybe there is
> a nicer, DRY-compliant method? Perhaps, something involving
> APT::Default-Release or similar, though I will admit I have no clue how
> this setting actually works...

Using the codename (i.e. bookworm/trixie) is the way to go.  When
upgrading to a newer release you need to adjust the pinning preferences
along with the apt sources, but this only needs to be done every two
years.

Cheers,
   Sven

Re: [Sid] Nouveau: only one monitor after 6.6.15 to 6.7.9 upgrade

[Sven Joachim]

On 2024-04-03 21:39 +0200, Greg wrote:

> I have two HP Z30i connected to Nvidia GeForce GTX 670. After last
> upgrade I'm able to use only one monitor.
>
> When running linux-image-6.7.9:
>
> # dmesg | grep nouveau | cut -b 16-
> nouveau :01:00.0: vgaarb: deactivate vga console
> nouveau :01:00.0: NVIDIA GK104 (0e4090a2)
> nouveau :01:00.0: bios: version 80.04.19.00.0f
> nouveau :01:00.0: fb: 2048 MiB GDDR5
> nouveau :01:00.0: DRM: VRAM: 2048 MiB
> nouveau :01:00.0: DRM: GART: 1048576 MiB
> nouveau :01:00.0: DRM: TMDS table version 2.0
> nouveau :01:00.0: DRM: MM: using COPY for buffer copies
> snd_hda_intel :01:00.1: bound :01:00.0 (ops
> nv50_audio_component_bind_ops [nouveau])
> [drm] Initialized nouveau 1.4.0 20120801 for :01:00.0 on minor 0
> fbcon: nouveaudrmfb (fb0) is primary device
> nouveau :01:00.0: vgaarb: VGA decodes changed:
> olddecodes=io+mem,decodes=io+mem:owns=io+mem
> nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame buffer device
> # xrandr
> Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 16384 x 16384
> DVI-I-1 connected 2560x1600+0+0 (normal left inverted right x axis y
> axis) 641mm x 400mm
>2560x1600 59.97*+
>1920x1200 59.95
>1920x1080 60.00
>1600x1200 60.00
>1680x1050 59.88
>1280x1024 60.02
>1440x900  59.90
>1280x800  59.91
>1280x720  60.00
>1024x768  60.00
>800x600   60.32
>640x480   59.94
>720x400   70.08
> DVI-D-1 disconnected (normal left inverted right x axis y axis)
> HDMI-1 disconnected (normal left inverted right x axis y axis)
> DP-1 disconnected (normal left inverted right x axis y axis)
>
> When running linux-image-6.6.15:
>
> # dmesg | grep nouveau | cut -b 16-
> nouveau :01:00.0: vgaarb: deactivate vga console
> nouveau :01:00.0: NVIDIA GK104 (0e4090a2)
> nouveau :01:00.0: bios: version 80.04.19.00.0f
> nouveau :01:00.0: fb: 2048 MiB GDDR5
> nouveau :01:00.0: DRM: VRAM: 2048 MiB
> nouveau :01:00.0: DRM: GART: 1048576 MiB
> nouveau :01:00.0: DRM: TMDS table version 2.0
> nouveau :01:00.0: DRM: DCB version 4.0
> nouveau :01:00.0: DRM: DCB outp 00: 01000f02 00020030
> nouveau :01:00.0: DRM: DCB outp 01: 02000f00 
> nouveau :01:00.0: DRM: DCB outp 02: 08011f82 00020030
> nouveau :01:00.0: DRM: DCB outp 03: 02022f62 00020010
> nouveau :01:00.0: DRM: DCB outp 04: 04833fb6 0f420010
> nouveau :01:00.0: DRM: DCB outp 05: 04033f72 00020010
> nouveau :01:00.0: DRM: DCB conn 00: 1030
> nouveau :01:00.0: DRM: DCB conn 01: 00020131
> nouveau :01:00.0: DRM: DCB conn 02: 00010261
> nouveau :01:00.0: DRM: DCB conn 03: 2346
> nouveau :01:00.0: DRM: MM: using COPY for buffer copies
> snd_hda_intel :01:00.1: bound :01:00.0 (ops
> nv50_audio_component_bind_ops [nouveau])
> [drm] Initialized nouveau 1.4.0 20120801 for :01:00.0 on minor 0
> nouveau :01:00.0: vgaarb: VGA decodes changed:
> olddecodes=io+mem,decodes=io+mem:owns=io+mem
> fbcon: nouveaudrmfb (fb0) is primary device
> nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame buffer device
> # xrandr
> Screen 0: minimum 320 x 200, current 5120 x 1600, maximum 16384 x 16384
> DVI-I-1 connected 2560x1600+2560+0 (normal left inverted right x axis
> y axis) 641mm x 400mm
>2560x1600 59.97*+
>1920x1200 59.95
>1920x1080 60.00
>1600x1200 60.00
>1680x1050 59.88
>1280x1024 60.02
>1440x900  59.90
>1280x800  59.91
>1280x720  60.00
>1024x768  60.00
>800x600   60.32
>640x480   59.94
>720x400   70.08
> DVI-D-1 connected 2560x1600+0+0 (normal left inverted right x axis y
> axis) 641mm x 400mm
>2560x1600 59.97*+
>1920x1200 59.95
>1920x1080 60.00
>1600x1200 60.00
>1680x1050 59.88
>1280x1024 60.02
>1440x900  59.90
>1280x800  59.91
>1280x720  60.00
>1024x768  60.00
>800x600   60.32
>640x480   59.94
>720x400   70.08
> HDMI-1 disconnected (normal left inverted right x axis y axis)
> DP-1 disconnected (normal left inverted right x axis y axis)
>
> Any suggestions?

File a bug against the kernel: reboot to the 6.7 kernel if it is not
currently running, install the reportbug package if it is not installed
already, then run

$ reportbug linux-image-$(uname -r)

Good luck,
Sven

Re: Dependency meaning

[Sven Joachim]

On 2024-03-21 10:02 +0100, Detlef Vollmann wrote:

> This is essentially a follow-up on my question about the
> 64bit time_t transition.
> I'm trying to upgrade some packages manually.
> For this, I'm trying to understand the dependencies.
>
> 'apt-cache showpkg libssl3t64' gives me this:
>> Dependencies: 3.1.5-1.1 - libc6 (2 2.34) libssl3 (3 3.1.5-1.1)
>> openssh-client (3 1:9.4p1) openssh-server (3 1:9.4p1)
>> python3-m2crypto (3 0.38.0-4) libssl3 (0 (null)) libssl3:i386 (3
>> 3.1.5-1.1) libssl3:i386 (0 (null)) openssh-client:i386 (3 1:9.4p1)
>> openssh-server:i386 (3 1:9.4p1) python3-m2crypto:i386 (3 0.38.0-4)
>> libssl3t64:i386 (35 3.1.5-1.1) libssl3t64:i386 (38 3.1.5-1.1)
>
> I'm trying to understand, what the numbers in parentheses mean.
> The second numbers are obviously version numbers.
> I guess the first numbers are dependency types, but I have no idea,
> what they mean.
> The man page says "For the specific meaning of the remainder of the
> output it is best to consult the apt source code."
> I'd like to avoid this. Can anybody point me to a list what these
> numbers mean?

No, but I can point you to the source code.  In cmdline/apt-cache.cc we
can find this passage where "Dependencies:" is printed:

,
|   cout << "Dependencies: " << endl;
|   for (pkgCache::VerIterator Cur = Pkg.VersionList(); Cur.end() != true; 
++Cur)
|   {
|cout << Cur.VerStr() << " - ";
|for (pkgCache::DepIterator Dep = Cur.DependsList(); Dep.end() != true; 
++Dep)
|   cout << Dep.TargetPkg().FullName(true) << " (" << 
(int)Dep->CompareOp << " " << DeNull(Dep.TargetVer()) << ") ";
|cout << endl;
|   }
`

Don't worry if you do not understand everything, neither do I.  The
mysterious first number is (int)Dep->CompareOp, so we need to figure out
what that is.  The "Dep" structure is declared in apt-pkg/pkgcache.h:

,
|// These are all the constants used in the cache structures
|
|// WARNING - if you change these lists you must also edit
|// the stringification in pkgcache.cc and also consider whether
|// the cache file will become incompatible.
|struct Dep
|{
|   enum DepType {Depends=1,PreDepends=2,Suggests=3,Recommends=4,
|Conflicts=5,Replaces=6,Obsoletes=7,DpkgBreaks=8,Enhances=9};
|   /** \brief available compare operators
|
|   The lower 4 bits are used to indicate what operator is being 
specified and
|   the upper 4 bits are flags. OR indicates that the next package is
|   or'd with the current package. */
|   enum DepCompareOp {NoOp=0,LessEq=0x1,GreaterEq=0x2,Less=0x3,
|Greater=0x4,Equals=0x5,NotEquals=0x6,
|Or=0x10, /*!< or'ed with the next dependency */
|MultiArchImplicit=0x20, /*!< generated internally, not spelled out in 
the index */
|ArchSpecific=0x40 /*!< was decorated with an explicit architecture in 
index */
|   };
|};
`

Using that information it is possible to decipher the numbers.  For
example, "libc6 (2 2.34)" means that libssl3t64 has a relationship with
libc6 (>= 2.34), "libssl3 (3 3.1.5-1.1)" means a relationship with
libssl3 (<< 3.1.5-1.1), and the strange numbers 35 and 38 for
libssl3t64:i386 appear because 0x20 (==32) is added (the
MultiArchImplicit flag).

How useful is all that?  Probably not much, considering that we cannot
even tell the type of relation.  It is probably better to just use
"apt-cache show".

Cheers,
   Sven

Re: cruft report: The new kid on the block

[Sven Joachim]

On 2024-02-16 09:06 -0500, Gremlin wrote:

> cruft report: Fri Feb 16 08:54:01 2024
>  missing: dpkg 
> /etc/network/if-post-down.d/wireless-tools
> /etc/network/if-pre-up.d/ethtool
> /etc/network/if-pre-up.d/wireless-tools
> /etc/network/if-up.d/ethtool
>
> wireless-tools and ethtool owns these files but are missing from the
> system, ie MIA

That is not supposed to happen, but it is hard to tell who removed these
files, when and why.  The etckeeper tool can help to track down such
changes.

> Doing a reinstall does not recreate them, why?

Because these files are conffiles, and the admin is free to edit or
delete them; dpkg will respect these changes and not reinstate missing
conffiles, unless given the "--force-confmiss" option.

Cheers,
   Sven

Re: Possible cifs stuck in stable kernel (linux-image-6.1.0-17-amd64)

[Sven Joachim]

On 2024-01-30 10:52 -0800, Xiyue Deng wrote:

> (Please keep me in CC as I'm not subscribed to the users ML.)
>
> Hi,
>
> TL;DR I've been experience stuck file system operations on cifs mount on
> latest stable kernel (linux-image-6.1.0-17-amd64, 6.1.69-1), and would
> like to see if other people are seeing similar issue before actually
> filing a bug.

It has been seen by other people: https://bugs.debian.org/1060005.

The Linux kernel 6.1.73 contains a fix, but I don't know when it will
reach the archive.

Cheers,
   Sven

Re: Can't view videos in firefox: VA-API test failed

[Sven Joachim]

On 2024-01-20 18:51 -0500, Stefan Monnier wrote:

> Whenever I try to view videos in Firefox in my trusty Thinkpad T61,
> Firefox just eats up the CPU but doesn't actually show the video.
>
> At startup I get the following message:
>
> [GFX1-]: vaapitest: VA-API test failed: failed to initialise VAAPI 
> connection.
>
> So, IIUC the problem is that the hardware video decoder drivers aren't
> found for some reason.  I checked my VA-related packages and they seem
> to be installed:
>
> # aptitude search '\' | grep '^i'
> i A i965-va-driver - VAAPI driver for Intel G45 & HD Graphics family
> i  intel-media-va-driver - VAAPI driver for the Intel GEN8+ Graphics 
> family
> i A libvdpau-va-gl1 - VDPAU driver with OpenGL/VAAPI backend
> i A mesa-va-drivers - Mesa VA-API video acceleration drivers
> i  va-driver-all - API de Video Acceleration (VA) – métapaquet de pilotes
> i A vdpau-va-driver - VDPAU-based backend for VA API
> #
>
> I tried to install `intel-media-va-driver-non-free` to see if that's the
> problem, but it did not make any difference.
>
> I understand that my machine is fairly old, but it used to be able to
> play youtube videos just fine without eating all my CPU time (i.e. using
> hardware video decoding from its GM965/GL960 Intel integrated graphcs).
>
> Any idea what might be going on?

It is probably due to the removal of old drivers, including i915 and
i965, in Mesa 22.0.  There is a separate branch for the old drivers
called "Mesa Amber" but unfortunately no packages have appeared in
Debian yet[1,2,3], and honestly I do not think they ever will. :-(

> Any hint how I could diagnose the problem?

Look for "swrast" in ~/.local/share/xorg/Xorg.0.log.  If it is mentioned
there, you are likely using software rendering.

Cheers,
   Sven


1. https://bugs.debian.org/1006202
2. https://lists.debian.org/debian-x/2022/06/msg00041.html
3. https://lists.debian.org/debian-x/2023/08/msg00138.html

Re: Probable bug in mc shell link when reading non-ASCII file names

[Sven Joachim]

On 2024-01-20 08:44 +0100, Sven Joachim wrote:

> On 2024-01-20 00:20 +0100, ju...@op.pl wrote:
>
>> I'm not sure if this is actually a bug in the mc package or maybe
>> somewhere in sshd or in some library that uses ssh. That's why I
>> didn't report it via reportbug. Anyway, I noticed the effects only in
>> Shell Link in mc. SSH in the terminal works fine. FTP Link in mc also
>> works properly.
>> The bug appeared today and is visible on all computers connecting to
>> remote Debian Testing systems regardless of MC version (I tested it
>> with mc from Ubuntu 18 and from the current Mint). File and directory
>> names on the remote Debian Testing computer containing UTF-8 Non-ASCII
>> characters are displayed incorrectly and the files and directories
>> cannot be read.
>> For example, instead of a file with a name containing the Polish
>> letters "AąCćEę", Shell Link mc sees a file named
>> "A304205C304207E304231".
>
> Interesting.  I can reproduce that, it has apparently been triggered by
> the Perl upgrade from 5.36 to 5.38.
>
>> Can anyone advise me which package this error should be reported for?
>
> The mc package.  You can tag the bug as forwarded to
> https://midnight-commander.org/ticket/4507, which has already been
> closed.  The fix will be part of mc 4.8.31, if you are lucky the Debian
> maintainers cherry-pick it earlier.

I have attached the patch which fixes the bug.  You can apply it
directly to /usr/lib/mc/fish/ls, if you do not mind that tools like
debsums and "dpkg --verify" might complain about the changed file.

Cheers,
   Sven

diff --git a/src/vfs/shell/helpers/ls b/src/vfs/shell/helpers/ls
index 4c8ca21137..c7701d644f 100644
--- a/src/vfs/shell/helpers/ls
+++ b/src/vfs/shell/helpers/ls
@@ -122,9 +122,8 @@ SHELL_DIR=$1
 perl -e '
 use strict;
 use POSIX;
-use Fcntl;
-use POSIX ":fcntl_h"; #S_ISLNK was here until 5.6
-import Fcntl ":mode" unless defined _ISLNK; #and is now here
+use Fcntl ":mode";  # S_ISLNK, S_IFMT, S_IMODE are here
+use POSIX ":fcntl_h";   # S_ISLNK might be here as well
 my $dirname = $ARGV[0];
 if (opendir (DIR, $dirname)) {
 while((my $filename = readdir (DIR))){

Re: Probable bug in mc shell link when reading non-ASCII file names

[Sven Joachim]

On 2024-01-20 00:20 +0100, ju...@op.pl wrote:

> I'm not sure if this is actually a bug in the mc package or maybe
> somewhere in sshd or in some library that uses ssh. That's why I
> didn't report it via reportbug. Anyway, I noticed the effects only in
> Shell Link in mc. SSH in the terminal works fine. FTP Link in mc also
> works properly.
> The bug appeared today and is visible on all computers connecting to
> remote Debian Testing systems regardless of MC version (I tested it
> with mc from Ubuntu 18 and from the current Mint). File and directory
> names on the remote Debian Testing computer containing UTF-8 Non-ASCII
> characters are displayed incorrectly and the files and directories
> cannot be read.
> For example, instead of a file with a name containing the Polish
> letters "AąCćEę", Shell Link mc sees a file named
> "A304205C304207E304231".

Interesting.  I can reproduce that, it has apparently been triggered by
the Perl upgrade from 5.36 to 5.38.

> Can anyone advise me which package this error should be reported for?

The mc package.  You can tag the bug as forwarded to
https://midnight-commander.org/ticket/4507, which has already been
closed.  The fix will be part of mc 4.8.31, if you are lucky the Debian
maintainers cherry-pick it earlier.

Cheers,
   Sven

Re: removing gdb-minimal removed plasma-desktop?

[Sven Joachim]

On 2024-01-14 08:54 +0100, Morten Hauke Solvang wrote:

> Short version: "apt remove gdb-minimal" seems to have also removed
> plasma-desktop + a bunch of related packages.
>
> Curious if there are any good debugging tips for figuring out what
> happened here.
> Or maybe I'm missing something obvious about how apt works, and this
> is expected behavior?
>
> Yesterday, I was trying to use gdb, and realized I had gdb-minimal
> installed instead of the regular gdb package.
>
> To fix this, I first ran "apt remove gdb-minimal".
> My assumption was that I then would have to run "apt install gdb".

That assumption was a bit misguided.  The correct way would have been to
"apt install gdb" _without_ first removing gdb-minimal, that would have
avoided the removal of reverse dependencies.

> But turns out that invoking "gdb" after running "apt remove
> gdb-minimal", I had the full version of gdb installed.
> I didn't think more about it, went on using gdb and later shut down
> the computer.
>
> When I booted it today, a different display manager than what I
> usually have was shown. Switching to a different pseudoterminal and
> checking "/var/log/apt/history.log" showed that when I had removed
> gdb-minimal, for some reason plasma-desktop and some other packages
> had also been removed.
>
> This is the entry I saw:
>
> Start-Date: 2024-01-13  15:52:49
> Commandline: apt remove gdb-minimal
> Requested-By: morten (1000)
> Install: gdb:amd64 (13.1-3, automatic),
> libsource-highlight-common:amd64 (3.1.9-4.2, automatic),
> libboost-regex1.74.0:amd64 (1.74.0+ds1-21, automatic), libc6-dbg:amd64
> (2.36-9+deb12u3, automatic), libbabeltrace1:amd64 (1.5.11-1+b2,
> automatic), libsource-highlight4v5:amd64 (3.1.9-4.2+b3, automatic)
> Remove: kinfocenter:amd64 (4:5.27.5-2), plasma-workspace:amd64
> (4:5.27.5-2+deb12u1), plasma-widgets-addons:amd64 (4:5.27.5-2),
> plasma-workspace-wayland:amd64 (4:5.27.5-2+deb12u1),
> sddm-theme-breeze:amd64 (4:5.27.5-2+deb12u1),
> sddm-theme-debian-breeze:amd64 (4:5.27.5-2+deb12u1), gdb-minimal:amd64
> (13.1-3), kde-plasma-desktop:amd64 (5:142), plasma-desktop:amd64
> (4:5.27.5-2)
> End-Date: 2024-01-13  15:52:52
>
> (Looks like this is where regular gdb got installed too, so I didn't
> actually have it, it just got autoinstalled when I removed
> gdb-minimal?)

Apparently, although it is not clear why because apt also went on to
remove plasma-workspace and its reverse dependencies.  The
plasma-workspace package depends on gdb-minimal | gdb, that is why
gdb-minimal was installed in the first place.

> (Also, probably this info got printed when I ran "apt remove
> gdb-minimal", and I was not paying attention.)

Pretty sure not only was this information printed, apt also asks for
confirmation if it has to install or remove more packages than
requested.  But it did what you told it to do, although the outcome
might not have been what you desired.

> To fix it, I ran this command and rebooted with "systemctl reboot",
> which seems to have worked fine. Now I'm back in the expected desktop
> environment.
> apt install kinfocenter plasma-workspace plasma-widgets-addons
> plasma-workspace-wayland sddm-theme-breeze sddm-theme-debian-breeze
> kde-plasma-desktop plasma-desktop

Good you sorted it out.  The only question is why apt installed gdb even
though it removed plasma-workspace anyway.  When I tried to replicate
your situation in a bookworm chroot, "apt remove gdb-minimal" removes
plasma-workspace but does not install gdb.

Cheers,
   Sven

Re: Where to report CVEs missing from the security tracker ?

[Sven Joachim]

On 2024-01-09 16:57 +0100, Jorropo wrote:

> Hello, there are 6 CVEs on the golang-go package which are not on
> https://security-tracker.debian.org/tracker/status/release/stable

They are there, just not shown by default.  Toggle the "include issues
tagged no-dsa" checkbox to see them.

> I couldn't find them either there
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=golang-go

Not every CVE has a bug report in the Debian BTS, and there are multiple
golang versions packaged.

> The list is:
> - CVE-2023-29409 https://pkg.go.dev/vuln/GO-2023-1987
> - CVE-2023-29403 https://pkg.go.dev/vuln/GO-2023-1840
> - CVE-2023-29402 https://pkg.go.dev/vuln/GO-2023-1839
> - CVE-2023-39325 https://pkg.go.dev/vuln/GO-2023-2102
> - CVE-2023-39323 https://pkg.go.dev/vuln/GO-2023-2095
> - CVE-2023-39326 https://pkg.go.dev/vuln/GO-2023-2382
>
> This has been grabbed from the public golang vulnerability database
> searching for anything affecting 1.19.8 (what bookworm ships).
> I also checked that no patches have been backported by diffing the std
> from golang-go and the upstream 1.19.8 sources.

The CVEs are all in the security tracker for the golang-1.19 package:
https://security-tracker.debian.org/tracker/source-package/golang-1.19.

> Most of them could be fixed by updating to 1.19.12 however the 1.19
> branch is no longer supported. https://endoflife.date/go

It is up to the package maintainers to provide updates for stable or
not, and upgrading to a newer version might be risky.  Version 1.19.13
is in bookworm-backports, however.

Cheers,
   Sven

Re: systemd and timezone

[Sven Joachim]

On 2023-12-22 11:11 -0500, Greg Wooledge wrote:

> On Fri, Dec 22, 2023 at 09:30:23AM -0600, David Wright wrote:
>>   https://wiki.debian.org/TimeZoneChanges
>>
>> still says:
>>
>>  "In Debian releases Etch and later, /etc/localtime is a copy of the
>>   original data file. Check the contents of /etc/timezone to see the
>>   name of the timezone. If the system is configured normally, you
>>   should find that the zoneinfo file referenced by this name is
>>   identical to /etc/localtime."
>
> I'd change it immediately, but I don't want to make a change that isn't
> correct.
>
> Was this paragraph actually correct for Etch?  Was /etc/localtime a
> literal *copy* of a file instead of symlink?

Yes.

> If so, when did it change?

In tzdata 2016a-1[1].

> Or, was this wrong for Etch, and /etc/localtime was always a symlink?

Initially /etc/localtime was a symlink, but in Etch it had been
converted to a file[2].

Cheers,
   Sven


1. https://bugs.debian.org/803144
2. https://bugs.debian.org/346342

Re: Upgrade to 12.3 fails due to missing nvidia firmware package

[Sven Joachim]

On 2023-12-06 15:24 +0100, Harald Dunkel wrote:

> I have tried to upgrade to 12.3, but apparently the dependencies
> of the new nvidia-kernel-dkms version cannot be fulfilled.
> firmware-nvidia-gsp (= 525.147.05) is missing. I tried several
> repositories.

Note that Debian 12.3 has not been released yet.

> Hopefully I am not too blind to find the bug report (the new
> version fixes a CVE, ie details might not have been disclosed),
> so I wonder what is the story here?

Maintainer uploads to (old)stable are staged in proposed-updates, so you
would have to enable bookworm-proposed-updates to install the new
version of firmware-nvidia-gsp.

Or wait until the actual release of Debian 12.3 next weekend.

Cheers,
   Sven

Re: Help ! No syslog anymore

[Sven Joachim]

On 2023-11-08 08:26 +, Bhasker C V wrote:

>  I moved my syslog to a different location  '/tmp/server.log'

A rather strange decision, since /tmp is usually pruned on reboot.

> This was working all fine until I moved to selinux in enforcing mode.
>
> I have tried putting selinux in permissive state and that too did not help

Most likely your problem has nothing to do with selinux, but is rather
due to the hardening features implemented in rsyslog 8.2310.0-1.  Among
other things, rsyslogd now gets its own /tmp directory (PrivateTmp=yes
in rsyslog.service) which is not shared with other processes.

> Please could someone help ? Or if there is a procedure to move syslog file
> /var/log/syslog to a different location, I am happy to follow ...

If you insist on moving it to /tmp, one possibility is to use a bind
mount for /tmp/server.log.  Run "systemctl edit rsyslog.service" and put
the following two lines in the file:

[Service]
BindPaths=-/tmp/server.log

You may also need a tmpfiles.d(5) snippet to create /tmp/server.log on
reboot if it does not exist.

Good luck,
Sven

Re: Understanding package dependencies

[Sven Joachim]

On 2023-10-07 19:24 +0200, Steve Keller wrote:

> Greg Wooledge  writes:
>
>> Package: sysvinit-utils
>> [...]
>> Provides: lsb-base (= 11.1.0)
>>
>> When you remove the physical lsb-base package, the virtual package
>> provided by sysvinit-utils remains, to satisfy the dependencies of
>> ntpsec, rsync, etc.
>
> OK, that explains, why lsb-base can be removed without ntpsec. Is there
> a way to search for "Provides" in packages? I.e. show me all packages
> (installed or all) that provide some feature "foobar"?

Yes, aptitude can do that.   Quoting the manual[1]:

,
| ?provides(pattern), ~Ppattern
| 
| Matches package versions which provide a package that matches the
| pattern. For instance, “?provides(mail-transport-agent)” will match
| all the packages that provide “mail-transport-agent”.
`

In the current case, "aptitude search '~Plsb-base'" does the trick.

Cheers,
   Sven


1. https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html#searchProvides

Re: usrmerge in bookworm

[Sven Joachim]

On 2023-10-06 22:32 +, Andy Smith wrote:

> On Fri, Oct 06, 2023 at 04:42:56PM +0200, Urs Thuermann wrote:
>> Greg Wooledge  writes:
>>
>> > Yeah, usrmerge is a bit wonky in these early stages.
>>
>> $ apt-get changelog usrmerge | tail -n2
>>  -- Marco d'Itri   Tue, 04 Nov 2014 22:42:44 +0100
>> Fetched 11.0 kB in 0s (58.9 kB/s)
>>
>> Not what I'd call 'early' stages.
>
> It is for Debian, when the maintainer of dpkg is strongly opposed
> to, and refuses to co-operate with, anything related to usrmerge.
>
> It got done years ago in Ubuntu, and their dpkg doesn't have this
> issue, as they've carried patches for that for all those years.

Ubuntu may have patched out the dpkg complaints about usrmerge, but they
have _not_ added proper support for it.  For instance, the problem
mentioned by the OP is present in Ubuntu's dpkg.

Cheers,
   Sven

Re: Same Debian, different hardware = different OpenGL version?

[Sven Joachim]

On 2023-10-03 02:43 +0200, Anders Andersson wrote:

> I recently installed Debian stable on my old desktop and my trusty old
> Thinkpad X200, without messing with any driver settings. Both are
> running the default gnome desktop with the same kernel.
>
> I installed the terminal emulator 'kitty' from the main repository on
> both machines but it only works on my desktop.
>
> The relevant bug report for kitty
> (https://github.com/kovidgoyal/kitty/issues/2536) tells me that kitty
> requires OpenGL 3.3, and to check with "glxinfo | grep OpenGL
> version".
>
> On my desktop I get: OpenGL version string: 4.6 (Compatibility
> Profile) Mesa 22.3.6
> On my thinkpad: OpenGL version string: 2.1 Mesa 22.3.6
>
> Is there anything I can do about this using open source drivers?

The only option, already mentioned in the above bug report, is to use
the llvmpipe renderer by setting LIBGL_ALWAYS_SOFTWARE=1 which makes
kitty start at the cost of high CPU load and bad performance.

> I don't know enough about OpenGL, if it's a software issue or if it's
> simply that the old intel GPU in the Thinkpad X200 can not work with
> new OpenGL, while the AMD RX460 in my desktop can?

That's it, the GPU in your Thinkpad most likely only supports OpenGL
2.1.  Intel provides a table at [1], and while I could not find the
Thinkpad's GMA 4500M HD listed there, its age makes a maximum OpenGL
version of 2.1 plausible.

Cheers,
   Sven


1. 
https://www.intel.com/content/www/us/en/support/articles/05524/graphics.html

Re: git setup

[Sven Joachim]

On 2023-08-22 03:00 +, Russell L. Harris wrote:

> After much searching and reading, I have not discovered how to set up
> a pair of git repositories to work together.
>
> I write articles for publication.  I typically spend anywhere from
> several hours to many days on each article.  It is frustrating to work
> for an hour or two on a paragraph or a page and then accidentally to
> erase what I have written.
>
> In the past, I have found git to be a very good solution.  But now I
> am moving to a new computer, and I an having difficulty replicating
> the previous setup.
>
> My needs are simple.  I need two git repositories.
>
> The first is my work space, into which periodically I commit the
> article on which I am working.
>
> The second repository is my backup; it resides on another machine.
> Several times a day, I SSH into the backup machine and pull the
> working repository.  It would be nice to be able to push from WORKING
> to BACKUP, eliminating the need to SSH.

Git supports pushing via the ssh protocol, and since you have already
set up the ssh connection, the rest is rather simple.

> I cloned the WORKING repository from the old host, and the WORKING
> repository appears to function correctly.  But I do not know how to
> configure the BACKUP repository.  I tried the BARE option, but I am not
> able to push from WORKING to BACKUP.

On the backup machine, create a bare repository:

$ mkdir -p /path/to/backup-repo.git
$ cd /path/to/backup-repo.git
$ git init --bare

Then you can push from your work machine:

$ git push --all ssh://[user@]/path/to/backup-repo.git
$ git push --tags ssh://[user@]/path/to/backup-repo.git

where "" is the hostname of your backup machine, and "user" is
your login name there (which you can usually omit).  You probably also
want to add the backup repository as a remote, so that you do not have
to write the long URL every time you push.

Cheers,
   Sven

Re: apt policy / listing packages from repo

[Sven Joachim]

On 2023-08-10 09:30 -0500, David Wright wrote:

>> I was looking for a way to list packages installed from a particular
>> repo and/or sub-repo or whatever it's called (eg. main, non-free).
>> 
>> Does anyone know of a way to do this, with apt policy or otherwise?
>
> What I do in this situation is to type "apt" and press TAB twice.
> Look at the resulting list of commands and check the man page for
> the most likely looking, in this case apt-cache.
>
> An alternative method of course is to type   apt policy   into any
> search engine. This will typically tell you not only how to invoke
> the command, but also more about what it produces.
>
> As for your listing, I've done this in the past with a script that
> runs apt-cache dump, grepping the Package/Version/File lines,
> concatenating and sorting them, then filtering that list against
> the output of dpkg-query -W -f to include only installed packages.
> This yields a list like:
>
>   Package: acl Version: 2.2.53-10 File: 
> /var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_binary-amd64_Packages
>   Package: adduser Version: 3.118 File: 
> /var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_binary-amd64_Packages
>   [ … … ]
>   Package: xtoolwait Version: 1.3-6.2 File: /var/lib/dpkg/status
>   [ … … ]
>   Package: yt-dlp Version: 2023.03.04-1~bpo11+1 File: /var/lib/dpkg/status
>
> which you can grep for particular subsets, though I'm usually more
> interested in grep -v for packages originating from elsewhere,
> like xtoolwait (squeeze) and yt-dlp (backports) there.
>
> There may well be better ways.

I would probably use "apt list" with a search pattern described in
apt-patterns(7), e.g. the following command lists all installed packages
from non-free:

$ apt list '~i ~snon-free/'

Lots of interesting possibilities one can toy with. :-)

Cheers,
   Sven

Re: Determine packages made obsolete in Bookworm

[Sven Joachim]

On 2023-07-20 14:31 -0500, kjohn...@eclypse.org wrote:

> I would like to discover which currently installed packages in
> Bullseye (11) will be obsolete (no longer available from a Debian
> repository) in Bookworm (12) _before starting the upgrade process_.
>
> It might be that there is a list of the more than 6,296 packages
> removed as obsolete (source: Debian press release), and I could
> compare to that list for matches.  Or, perhaps there is a list of the
> 64,419 packages in Bookworm and I could find which ones are missing.
>
> How can I get thoses lists?  Or is there another way to discover what I want 
> to know?

There is a way to find the obsolete packages installed on _your_ system,
which is probably what you really care about.  After preparing your
sources.list to add the bookworm repositories and remove the bullseye
ones[1], run "apt update".  Then "apt list '~o'" lists all the packages
which are no longer available.  See apt-patterns(7).

Good luck,
Sven


1. 
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html

Re: Raspberry Pi Debian after upgrade Bullseye => Bookworm -- problem Setting up ca-certificates-java

[Sven Joachim]

On 2023-06-22 03:12 -0700, Rick Thomas wrote:

> On Thu, Jun 22, 2023, at 12:04 AM, Jeffrey Walton wrote:
>> On Thu, Jun 22, 2023 at 2:49 AM Rick Thomas  wrote:
>  snip 
>>> In this case, the package is already installed.
>>> Unfortunately when I try to reinstall it, I get:
>>>
>>> rbthomas@pi:~$ sudo -i  apt-get install --reinstall ca-certificates-java
>>> Reading package lists... Done
>>> Building dependency tree... Done
>>> Reading state information... Done
>>> 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not 
>>> upgraded.
>>> 4 not fully installed or removed.
>>> After this operation, 0 B of additional disk space will be used.
>>> E: Internal Error, No file name for ca-certificates-java:arm64
>>> rbthomas@pi:~$
>>>
>>> Any idea that that even means?
>>
>> I would probably try this next:
>> sudo apt-get -f install && sudo dpkg -a --configure
>> If that doesn't help, then I am out of ideas.
>
> Sadly, that didn't work.
> Do you (or anyone else on the list) have any idea what this message means?
> "E: Internal Error, No file name for ca-certificates-java:arm64"

It is the apt way of saying "this package cannot be reinstalled, because
it is not fully installed in the first place" (since it failed to
configure).

See https://bugs.debian.org/670920 and its siblings.

> In particular, what directory might contain the file
> ca-certificates-java:arm64.

None, because that is a package name and not a file.

> And what does "no filename for..." mean in this context?

You probably have to ask the apt developers.  I would like to know that
as well.

Cheers,
   Sven

Re: debchange still wants to build for bullseye-backports after upgrade to Bookworm

[Sven Joachim]

On 2023-06-20 19:05 +0500, Alexander V. Makartsev wrote:

> Hello.
>
> I've successfully upgraded to Bookworm recently and trying to build a
> backport package.
> But the usual "$ debchange --bpo" still wants to build for
> "bullseye-backports" and modifies "debian/changelog" by adding
> "~bpo11+1" and "bullseye-backports;"
> instead of expected "~bpo12+1" and "bookworm-backports;"
> Is there anything to check on my system or this is a bug in "dch"
> and/or "devscripts" package?

The latter, namely https://bugs.debian.org/1037336.

Cheers,
   Sven

Re: Removing i386 architecture

[Sven Joachim]

On 2023-06-12 06:32 +0200, to...@tuxteam.de wrote:

> On Sun, Jun 11, 2023 at 09:27:11PM -0400, pa...@quillandmouse.com wrote:
>
> [...]
>
>> Nice try. However, this isn't allowed, as it would apparently remove
>> libcrypt1:i386, which is apparently a "system-critical" package. I'm
>> not sure how this could be system critical, since my original
>> installation was 64 bit. This begins to look like a reinstall, in order
>> to get my system "clean". Unless anyone has other ideas.
>
> This has even made it into a bug report [1]. It seems that just adding
> the --allow-remove-essential option is what you need.

The real bug is that removing libcrypt1 requires this option in the
first place[1].  I have just sent a reminder to fix that, but do not
assume it will make it into a Bookworm point release.

Cheers,
   Sven


1. https://bugs.debian.org/1024616

Re: Bookworm upgrade, usrmerge failure

[Sven Joachim]

On 2023-06-12 10:24 -0400, Greg Wooledge wrote:

> On Mon, Jun 12, 2023 at 09:45:15AM -0400, Greg Wooledge wrote:
>> I think I might try grabbing an older-than-buster version of debootstrap
>> out of snapshot.debian.org and see if I can manage to reproduce something.
>> But don't count on my success.
>
> I've succeeded in *partially* reproducing this error, but not fully.
> My resulting state simply has usrmerge failing with the OP's error
> message, and each subsequent instance of /usr/lib/usrmerge/convert-usrmerge
> giving the same error again.  I do not get the GLIBC errors, nor do I
> get an unusable system.
>
> Here's what I did:
>
> 1) Start from my bookworm amd64 system.
> 2) Install bullseye using debootstrap into /stuff/bullseye-base.
> 3) Copy that directory to /stuff/bullseye-with-old-debootstrap.
> 4) Chroot into bullseye-with-old-debootstrap and apt-get install debootstrap.
> 5) Download 
> http://snapshot.debian.org/archive/debian/20180603T165432Z/pool/main/d/debootstrap/debootstrap_1.0.101_all.deb
>  from outside the chroot.
> 6) Chroot into bullseye-with-old-debootstrap and dpkg -i 
> debootstrap_1.0.101_all.deb
> 7) Chroot into bullseye-with-old-debootstrap and debootstrap bullseye into 
> /bullseye2.
> 8) Move bullseye-with-old-debootstrap/bullseye2 to /stuff/bullseye-unmerged.
> 9) Verify that bullseye-unmerged has separate /bin and /lib directories.
> 10) Copy /stuff/bullseye-unmerged to /stuff/bullseye-upgrade-test.
> 11) Chroot into bullseye-upgrade-test and copy 
> /lib/x86_64-linux-gnu/libz.so.1.2.11 to /usr/lib/x86_64-linux-gnu/ and make 
> /usr/lib/x86_64-linux-gnu/libz.so.1 -> libz.so.1.2.11
> 12) Chroot into bullseye-upgrade-test and edit sources.list and apt-get 
> update and apt-get install usrmerge.
>
> And the resulting output:
>
> ===
> [...]
> Setting up usrmerge (35) ...
>
> FATAL ERROR:
> Both /lib/x86_64-linux-gnu/libz.so.1.2.11 and 
> /usr/lib/x86_64-linux-gnu/libz.so.1.2.11 exist.
>
> You can try correcting the errors reported and running again
> /usr/lib/usrmerge/convert-usrmerge until it will complete without errors.
> Do not install or update other Debian packages until the program
> has been run successfully.

I guess the error message here could be improved, since to the many
users it is probably not obvious *how* to fix the problem.  Assume
convert-usrmerge reports something like this:

,
| Both /lib/x86_64-linux-gnu/foo and /usr/lib/x86_64-linux-gnu/foo exist.
`

Then run

$ dpkg -S /lib/x86_64-linux-gnu/foo /usr/lib/x86_64-linux-gnu/foo

Very likely the output will be something like this:

,
| bar: /lib/x86_64-linux-gnu/foo
| dpkg-query: no path found matching pattern /usr/lib/x86_64-linux-gnu/foo
`

In other words, one of the duplicate files belongs to package bar, and
the other one is unknown to dpkg.  That one should be deleted or moved
out of the way, the other one left alone.

> root@unicorn:/# perl -e 'print "hello world\n"'
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LC_TIME = "C",
>   LANG = "en_US.utf8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").
> hello world
> root@unicorn:/# /usr/lib/usrmerge/convert-usrmerge
> perl: warning: Setting locale failed.
> perl: warning: Please check that your locale settings:
>   LANGUAGE = (unset),
>   LC_ALL = (unset),
>   LC_TIME = "C",
>   LANG = "en_US.utf8"
> are supported and installed on your system.
> perl: warning: Falling back to the standard locale ("C").

FWIW, these messages are harmless.  The current locale is missing in the
chroot, and perl complains about that.  You will not see this during
package upgrades because Debian carries a patch to suppress it when
running perl from a maintainer script[1].

> The minimal debootstrap system has libidn2 (which is in /usr/lib/x*)
> but not libidn, so I wasn't able to reproduce the OP's setup faithfully.
> I figured using a copy of libz (which is in /lib/x*) might suffice.
>
> Has anyone else ever run into this before,

Not personally, but I suspect it might happen on a few old installations
that had been upgraded over the years.  Packages have moved libraries
from /usr/lib to /lib or vice versa, and for instance in the case of a
dpkg database corruption where the *.list file that belongs to a package
becomes empty dpkg will not remove the old files which now come to bite
you.  Such incidents might have happened 10 years ago without being
noticed.

So this problem falls into the "should not happen, but could happen"
category.

> or have any insight into how
> the OP's system became unusable as a result?

No, I do not see this.  In my book that falls into the "cannot happen"
category which is notoriously hard to reproduce or debug.

Cheers,
   Sven


1. 

Re: "dpkg-reconfigure" dash no longer works

[Sven Joachim]

On 2023-06-09 12:06 -0400, The Wanderer wrote:

> On 2023-06-09 at 12:00, Charles Curley wrote:
>
>> On Fri, 9 Jun 2023 13:38:25 +
>> S M  wrote:
>>
>>> I noticed on a newly installed system with Debian 12 that
>>> dpkg-reconfigure no longer allows to switch the /bin/sh symlink from
>>> dash to bash.
>>
>> You can still change it manually (rm ; ln -s).
>
> Or just 'ln -sf', to do it in something closer to an atomic fashion.
>
> Except that, since (at least from what I can see on a quick check) the
> /bin/sh symlink appears to be shipped explicitly in the dash package,
> next time that package gets upgraded the symlink will probably be
> overwritten with one pointing back to dash again.
>
> If the system is smart enough to not replace a sysadmin-edited symlink
> during package upgrade, then that wouldn't happen - but I'd honestly
> expect that it would, since otherwise if a symlink got messed up and
> broke things, reinstalling the package it came from wouldn't be
> guaranteed to fix those things.

That is true.  However, you can avoid that by diverting the /bin/sh
symlink which tells dpkg to unpack it under a different name.  To do so,
you have to first remove the diversion that dash itself sets up.  The
following six commands change the /bin/sh symlink permanently to bash
and also take care of the manpage:

# dpkg-divert --remove --no-rename /usr/share/man/man1/sh.1.gz
# dpkg-divert --remove --no-rename /bin/sh
# ln -sf bash.1.gz /usr/share/man/man1/sh.1.gz
# ln -sf bash /bin/sh
# dpkg-divert --add --local --no-rename /usr/share/man/man1/sh.1.gz
# dpkg-divert --add --local --no-rename /bin/sh

The version of dash in experimental no longer diverts the /bin/sh
symlink itself, so in the future the first two steps will not be
necessary.  The dash maintainer wanted to include this change in
bookworm, but was turned down by the release team[1].

> Of course, there's still the question of the *reason* why this change
> was made and why using anything but dash for /bin/sh is now considered
> no longer supported. I don't have any explanation for that, and until
> the maintainers actually give one, neither do the rest of us - but in
> the absence of one, it's hard to be sure that pointing the symlink to
> /bin/bash won't break something.

Unfortunately neither the Debian changelog of dash nor the commit
message for this change[2] give an explanation.  Removing the debconf
handling certainly simplifies the package, and there are not too many
scripts around that start with "#!/bin/sh" and fail to work with dash -
these are the reasons I can think of.

There is also an open bug against the release notes[3] filed by the dash
maintainer.

Cheers,
   Sven

1. https://bugs.debian.org/1035745
2. 
https://salsa.debian.org/debian/dash/-/commit/c322a1c9fc6be11d7eb4439407c0a398aba8bbb7
3. https://bugs.debian.org/1036907

Re: Running Debian without initramfs?

[Sven Joachim]

On 2023-06-08 15:41 +0100, James Addison wrote:

> Does anyone have experience running Debian systems without using an initramfs?

I did this in the distance past, some 15 years ago or so.  Have long
abandoned that idea, though.

> I'd be particularly keen to hear about laptop/desktop/server systems,
> because I think that a large motivating factor to use initramfs --
> across many distributions -- was to provide a mechanism
> outside-the-compiled-kernel to load additional device driver modules,
> and I'd like to check that that motivation is still valid.

s/device driver//

Loading modules via an intramfs is crucial for a distro kernel, because
the only alternative would be to compile in support for dozens of
filesystems that users might want to use as their root filesystem.

Cheers,
   Sven

Re: debuginfod.debian.net missing some build ids

[Sven Joachim]

On 2023-06-06 17:02 -0700, Jacob Rutherford wrote:

> I've been trying to debug a binary that's linked against the libc6 package
> from Sid, but some of my tools are telling me that debuginfo for the libc6
> sources aren't found on the debuginfod servers. The matching build-ids can
> be found in the libc6-dbg package here:
> https://packages.debian.org/sid/amd64/libc6-dbg/filelist, but they cannot
> be found on the debuginfod server for some reason, eg:
>
> $ echo $DEBUGINFOD_URLS
> https://debuginfod.debian.net
> $ llvm-debuginfod-find-15 --debuginfo
> 0401bd8da6edab3e45399d62571357ab12545133 # pick any build-id from libc6-dbg
> build id not found
> $ curl
> https://debuginfod.debian.net/buildid/0401bd8da6edab3e45399d62571357ab12545133/debuginfo
> not found
>
> Any ideas why this might be the case?

Not really.  According to the page in the Debian Wiki[1] this is
supposed to work (and with libc6-dbg from stable it does appear to
work), so maybe you should contact Sergio Durigan Junior directly.

Good luck,
Sven


1. https://wiki.debian.org/Debuginfod#What_distributions_are_supported.3F

Re: X11 should not run as root or?

[Sven Joachim]

On 2023-06-02 16:32 +, therealcyclist wrote:

> I tried the new Debian bookworm installer rc4 and i manually installed i3-wm.
> I started i3 from tty with startx command as user.
> to my surprise i found out that the xorg process is running as root.
> that can't be intentional, can it?

As long as there is a working kernel driver for all your graphics cards,
this is not intended.

> I have fixed the problem by adding the following line in 
> /etc/X11/Xwrapper.config
>
> needs_root_rights = no
>
> After that xorg runs as user.

That is rather strange.  The source of the wrapper program that decides
whether Xorg needs root rights has not been touched for many years[1].

Cheers,
   Sven


1. 
https://salsa.debian.org/xorg-team/xserver/xorg-server/-/commits/debian-unstable/hw/xfree86/xorg-wrapper.c

Re: Unable to run virsh on bookworm

[Sven Joachim]

On 2023-05-09 19:10 +, Sean Whalen wrote:

> I've installed virt-manager on a Debian bookworm system, and that is
> working fine. However, when I try to use the libvirt CLI client,
> virsh, I receive this error message:
>
> virsh: /usr/local/lib/x86_64-linux-gnu/libvirt.so.0: version
> `LIBVIRT_PRIVATE_9.0.0' not found (required by virsh)

Note the '/usr/local/lib/…' path here.  This version of libvirt.so.0 is
most likely older than the one in the libvirt0 package.  Probably at
some time in the past you installed it.

> The Fedora package libvirt-libs
> 
> 9.0.0 states that it provides
> libvirt.so.0(LIBVIRT_PRIVATE_9.0.0)(64bit), so I'm not sure why the
> Debian package wouldn't be the same way, or why virt-manager works but
> virsh does not.
>
> I just filed a bug
>  (that was
> my time using the Debian bug tracking system). Is anyone aware of a
> workaround for this bug until it is fixed?

You can and you have to fix it yourself, by moving the locally installed
libvirt.so.0 out of the way.

Cheers,
   Sven

Re: Segfaults after upgrade to Debian 11.7 on virtualized systems with AMD Ryzen CPU

[Sven Joachim]

On 2023-04-30 14:56 +0200, Andreas Haumer wrote:

> I have several virtualized systems around here.
>
> Yesterday I upgraded some of our Bullseye VMs to 11.7 and found,
> that now all systems running on a host with an AMD Ryzen 5950X CPU now
> crash with segfaults at various commands.
>
> I have other VMs running on a server with an AMD EPYC CPU.
> Those VMs work fine with Debian 11.7
>
> But the VMs on the AMD Ryzen 5950X host now all crash.
>
> The kernel boots and I see the following messages (excerpt):
> [ 2.696267] modprobe[296]: segfault at 7ffee6eaeef8 ip
> 7f6c836f2133 sp 7ffee6eaeed0 error 25 in
> libc-2.31.so[7f6c83629000+159000]
> [2.696272] Code: Unable to access opcode bytes at RIP 0x7f6c836f2109.
> [ 2.710874] mount[284]: segfault at 7ffed19f7f78 ip 7ff4b09b1632
> sp 7ffed19f7f78 error 25 in libc-2.31.so[7ff4b08d7000+159000]
> [2.711774] Code: Unable to access opcode bytes at RIP 0x7ff4b09b1608.

Interesting, but certainly not good.  On Stackoverflow you can find a
thread[1] how to interpret these segfault messages.

> The VMs are configured to use the hosts CPU configuration.
> On the host I use QEMU/KVM/libvirt as virtualization software:
>
> root@pauli:~# virsh version
> Compiled against library: libvirt 7.0.0
> Using library: libvirt 7.0.0
> Using API: QEMU 7.0.0
> Running hypervisor: QEMU 5.2.0
>
> The host is still running Debian 11.6
>
> I'm currently trying to figure out what is going on here.

My first idea would be that the libc6 upgrade triggered these problems,
although the new kernel could also be at fault.  Try downgrading libc6
in one of the VMs to version 2.31-13+deb11u5 and see if that helps.

Good luck,
Sven


1. https://stackoverflow.com/questions/2549214/interpreting-segfault-messages

Re: W: Possible missing firmware /lib/firmware/brand/yada*

[Sven Joachim]

On 2023-04-28 21:30 -0400, Felix Miata wrote:

> # inxi -Gxx
> Graphics:
>   Device-1: Intel 82Q963/Q965 Integrated Graphics vendor: Dell driver: i915
> v: kernel arch: Gen-4 ports: active: DVI-D-1 empty: VGA-1 bus-ID: 00:02.0
> chip-ID: 8086:2992# aka ancient
> # grep MODULES /etc/initramfs-tools/initramfs.conf
> # MODULES: [ most | netboot | dep | list ]
> MODULES=dep
> #
>
> These many per transaction $SUBJECT initrd construction messages have been 
> routine
> for a long time in Bullseye and Bookworm regardless of active GPU installed, 
> and
> whether or not a firmware-brand-graphics .deb exists and is installed
> for it.

It would be useful to give an example of these messages, as well as a
list of firmware packages you have installed.

> Is there something that can be done to avoid this screen and log
> litter?

Install the package that contains the firmware files.  For Intel and
NVidia graphics that is firmware-misc-nonfree, for AMD it is
firmware-amd-graphics.

> Can anyone
> point to an existing meta-bug report on the subject of stopping the litter?
> Searching seems to find only reports pointing to particular GPUs, e.g.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016286

It's the same for any GPUs, as well as for other hardware.  The
update-initramfs script runs modinfo(8) to find out which firmware files
a loaded module might request and issues a warning for any such file
which is not there.  You can check the code for yourself[1].

Cheers,
   Sven


1. https://sources.debian.org/src/initramfs-tools/0.142/hook-functions/#L109

Re: linux kernel versions in stable

[Sven Joachim]

On 2023-04-22 12:13 -0700, Ross Boylan wrote:

> There are many signs of a new kernel version in the latest updates:
> linux-libc-dev, linux-source, linux-kbuild all show an upgrade
> available from 5.10.162-1 to 5.10.178-2.
>
> Conspicuously absent are any of the linux-image packages; the most
> recent ones are 5.10.162-1.  I figured they might just be delayed, but
> https://tracker.debian.org/pkg/linux-signed-amd64 doesn't mention the
> 178 version at all.
>
> What's up?

The problem seems to be that linux did FTBFS on mipsel*[1].

> First, is upgrading the apparently partial list of packages advisable
> without having the kernel against which, I presume, they were built,
> present?

The version of linux-libc-dev usually does not matter.  Upgrading the
other packages probably makes little sense.

> Second, is an upgraded linux-image coming, and where is it?

There has been an upload of linux 5.10.178-3 which seems to attempt to
fix the mipsel* problems[2].  Assuming this builds everywhere, I would
expect uploads of the linux-signed packages to follow shortly
thereafter.

Cheers,
   Sven


1. https://buildd.debian.org/status/package.php?p=linux=bullseye
2. 
https://tracker.debian.org/news/1429652/accepted-linux-510178-3-source-into-proposed-updates/

Re: Pinning not working?!

[Sven Joachim]

On 2023-04-03 19:12 +, Thomas Schweikle wrote:

> I'd like to pin audacious to version 4.1. I've defined in
> /etc/apt/preferences.d/audacious.pref:
>
> Package: audacious*
> Pin: version 4.1*
> Pin-Priority: 1000
>
> Package: libaudcore5*
> Pin: version 4.1*
> Pin-Priority: 1000
>
> Package: libaudgui5*
> Pin: version 4.1*
> Pin-Priority: 1000
>
> Package: libaudgt2*
> Pin: version 4.1*
> Pin-Priority: 1000
>
> Now running "apt policy audacious" gives:
> audacious:
>   Installiert:   4.1-2
>   Installationskandidat: 4.3-0build3~ubuntu2204
>   Versionstabelle:
>  4.3-0build3~ubuntu2204 500
> 500
> https://ppa.launchpadcontent.net/ubuntuhandbook1/apps/ubuntu
> jammy/main amd64 Packages
>  *** 4.1-2 500
> 500 http://de.archive.ubuntu.com/ubuntu kinetic/universe amd64
> Packages
> 100 /var/lib/dpkg/status
>
> does not seen to work at all, since the 4.1-2 package has priority 500
> but if pinning would work it should have 1000. What is wrong here?

I do not have a kinetic system at hand, but could not reproduce this
problem with apt 2.6.0 on unstable.  Maybe you could try to run "apt
policy" under strace and see if it actually reads your audacious.pref
file, but otherwise I do not really have an idea what is wrong.

Cheers,
   Sven

Re: new archive section: non-free-firmware

[Sven Joachim]

On 2023-01-28 13:11 -0700, Charles Curley wrote:

> On Sat, 28 Jan 2023 19:05:39 +
> "Andrew M.A. Cater"  wrote:
>
>> This all follows on the General Resolution a while ago.
>
> Right. I looked at the page to which Sven Joachim 
> referred. https://www.debian.org/vote/2022/vote_003 Some of the
> proposals explicitly required the installer to do so. However, I am not
> familiar enough with Debian processes to determine which language was
> approved, so I could not determine the answer to my question.

Sorry, that was my fault.  I should have given the link to outcome of
the vote as well, it was Option 5 "Change SC for non-free firmware in
installer, one installer"[1].

Cheers,
   Sven


1. https://lists.debian.org/debian-devel-announce/2022/10/msg1.html

new archive section: non-free-firmware

[Sven Joachim]

Some news for you who are running unstable or testing/bookworm and have
firmware packages installed from non-free (most users who do not run
Debian in a VM probably have): these firmware packages are being moved
to a new section non-free-firmware, and you should update your
sources.list(5) entries to include that section to keep them up to date.

In unstable this is already happening, and aptitude just informed me
that two installed firmware-* packages have become obsolete, i.e. are no
longer available from non-free.  In bookworm, non-free-firmware is
currently still empty, but that will change in the coming days and weeks.

To use the new section, edit sources.list like this:

before:
deb http://deb.debian.org/debian/ unstable main contrib non-free

after:
deb http://deb.debian.org/debian/ unstable main contrib non-free 
non-free-firmware

and similar for testing or bookworm instead of unstable.

If you have aptitude installed[1], the following command gives you a
list of installed packages from non-free:

$ aptitude search -F %p --disable-columns '~i~snon-free

If that list only includes packages matching "firmware", you can remove
non-free from your sources.list once the transition of firmware packages
to the new section is complete.

For more information why this was done, read
https://www.debian.org/vote/2022/vote_003.

Cheers,
   Sven


1. If somebody knows a similar command in apt, please post it.

Re: kernel errors

[Sven Joachim]

On 2023-01-23 16:13 +, Richmond wrote:

> I put a dvd in and mounted it. Then rebooted. I saw these messages:
>
>  [  756.539018] pktcdvd: pktcdvd0: writer mapped to sr0
>  [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram 
> cd/rw xa/form2 cdda tray
>  [   19.585098] pktcdvd: pktcdvd0: writer mapped to sr0
>
> Then removed the DVD and rebooted, back to these:
>
>  [4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram 
> cd/rw xa/form2 cdda tray
>  [9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK 
> driverbyte=DRIVER_SENSE cmd_age=2s
>  [9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current]
>  [9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - tray 
> closed
>  [9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 00 
> 02 00
>  [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer
>
> I am starting to consider re-installing, although everything is working,
> I don't like the look of it. Perhaps I should just re-install the
> kernel?

This would most likely not help.  Instead you should try to figure out
what process is trying to read from your empty drive, and why.
Consulting journalctl might help with that.

Cheers,
   Sven

Re: Ctrl-C ignored after pasting a long text in an X terminal emulator

[Sven Joachim]

On 2023-01-22 05:17 +0100, Vincent Lefevre wrote:

> On 2023-01-21 21:19:06 -0600, David Wright wrote:
>> On Sun 22 Jan 2023 at 03:50:17 (+0100), Vincent Lefevre wrote:
>> > 3. Type Ctrl-C (one or several times) in the terminal.
>> > But nothing happens.
>>
>> I presume that's because the input buffer is already full, so
>> you'd need what I think they called an out-of-band signal,
>> like pressing Break used to do on an old teletype terminal.
>
> Why doesn't the terminal have a function to flush and discard
> the input buffer or have some reserved space for the intr and
> quit characters? Or automatically increase the size of the
> input buffer?

This might be a limitation of Linux's pty(7) subsystem.  The xterm
manpage mentions the following:

,
| BUGS
|  Large pastes do not work on some systems.  This is not a bug in
|  xterm; it is a bug in the pseudo terminal driver of those systems.
|  Xterm feeds large pastes to the pty only as fast as the pty will
|  accept data, but some pty drivers do not return enough information
|  to know if the write has succeeded.
`

See also https://bugs.debian.org/273194 in xterm.  Disclaimer: I do not
have any expertise in that area.

Cheers,
   Sven

Re: Postfix fails after upgrade from bullseye to bookworm

[Sven Joachim]

On 2023-01-20 21:11 +0100, Sven Joachim wrote:

> On 2023-01-20 20:45 +0100, Sven Joachim wrote:
>
>> My hunch is that postfix recomputes all the hashes in
>> /var/spool/postfix/etc/ssl/certs, rather than copying the files from the
>> host system into the chroot which would be a lot faster.
>
> For those who want to dig deeper, /usr/lib/postfix/configure-instance.sh
> is the (Debian-specific) script which sets up the chroot.  Surely it
> should not recompute all the hashes every time postfix is restarted, but
> apparently it does so at least on Charles' and my system.

Wow.  Looking into the BTS, I found bug #895089[1], changed "c_rehash"
to "openssl rehash" in /usr/lib/postfix/configure-instance.sh as
recommended there, and now "systemctl restart postfix.service" completes
in two seconds!

Will follow up on the bug ASAP, if nobody beats me to it.

Cheers,
   Sven


1. https://bugs.debian.org/895089

Re: Postfix fails after upgrade from bullseye to bookworm

[Sven Joachim]

On 2023-01-20 20:45 +0100, Sven Joachim wrote:

> On 2023-01-20 11:55 -0700, Charles Curley wrote:
>
>> On Fri, 20 Jan 2023 19:17:37 +0100
>> Sven Joachim  wrote:
>>
>>> Clearly something fishy is going on here.
>>
>> I concur. What I saw with htop was a slew of calls to SSL. Here's
>> a sample of what it was doing. It is a processor hog.
>>
>> root@white:~# ps aux | grep -i openssl
>> root  4586  5.8  0.9   8256  2064 pts/3S+   11:48   0:00 grep 
>> --colour=auto -i openssl
>> root 4587 150 2.1  4720 ?  R 11:48 0:00 /usr/bin/openssl x509
>> -subject_hash_old -fingerprint -noout -in QuoVadis_Root_CA_2.pem
>
> Indeed I see many calls to openssl in top, apparently they are children
> of a single c_rehash process.  CPU load is low here, though (2-3 %).
>
>> I have no idea what that's about. Maybe someone with SSL experience can
>> chime in here?
>
> My hunch is that postfix recomputes all the hashes in
> /var/spool/postfix/etc/ssl/certs, rather than copying the files from the
> host system into the chroot which would be a lot faster.

For those who want to dig deeper, /usr/lib/postfix/configure-instance.sh
is the (Debian-specific) script which sets up the chroot.  Surely it
should not recompute all the hashes every time postfix is restarted, but
apparently it does so at least on Charles' and my system.

Cheers,
   Sven

Re: Postfix fails after upgrade from bullseye to bookworm

[Sven Joachim]

On 2023-01-20 11:55 -0700, Charles Curley wrote:

> On Fri, 20 Jan 2023 19:17:37 +0100
> Sven Joachim  wrote:
>
>> Clearly something fishy is going on here.
>
> I concur. What I saw with htop was a slew of calls to SSL. Here's
> a sample of what it was doing. It is a processor hog.
>
> root@white:~# ps aux | grep -i openssl
> root  4586  5.8  0.9   8256  2064 pts/3S+   11:48   0:00 grep 
> --colour=auto -i openssl
> root 4587 150 2.1  4720 ?  R 11:48 0:00 /usr/bin/openssl x509
> -subject_hash_old -fingerprint -noout -in QuoVadis_Root_CA_2.pem

Indeed I see many calls to openssl in top, apparently they are children
of a single c_rehash process.  CPU load is low here, though (2-3 %).

> I have no idea what that's about. Maybe someone with SSL experience can
> chime in here?

My hunch is that postfix recomputes all the hashes in
/var/spool/postfix/etc/ssl/certs, rather than copying the files from the
host system into the chroot which would be a lot faster.

It is probably time for me to revisit my postfix configuration.

Cheers,
   Sven

Re: Postfix fails after upgrade from bullseye to bookworm

[Sven Joachim]

On 2023-01-20 13:39 -0500, Greg Wooledge wrote:

> On Fri, Jan 20, 2023 at 07:17:37PM +0100, Sven Joachim wrote:
>> It seems that postfix's startup time has greatly regressed, on my laptop
>> there are very long delays both at boot:
>>
>> ,
>> | $ systemd-analyze blame | head -n1
>> | 33.340s postfix@-.service
>> `
>
> A delay that's a multiple of 30 seconds is very often a DNS lookup
> failure.  I would imagine your postfix configuration is trying to
> perform a DNS lookup on some hostname or other, and that this is
> happening before you're actually "online", for whatever definition of
> "online" is relevant here.

That should be NetworkManager-wait-online.service.  In the logs I see
that systemd starts the postfix service directly after reaching
network-online.target, as it is supposed to do.  The mystery is why it
takes another 30+ seconds before any messages from postfix itself appear
in the logs.

> That's a total guess, though.  Find your logfiles and read them to see
> what's actually going on.

Here is what I see in the journal when I restart postfix.service:

,
| Jan 20 20:16:06 myhost postfix/postfix-script[1470]: stopping the Postfix 
mail system
| Jan 20 20:16:06 myhost postfix/master[1307]: terminating on signal 15
| Jan 20 20:16:06 myhost systemd[1]: postfix@-.service: Deactivated 
successfully.
| Jan 20 20:16:06 myhost systemd[1]: Stopped Postfix Mail Transport Agent 
(instance -).
| Jan 20 20:16:06 myhost systemd[1]: postfix@-.service: Consumed 36.372s CPU 
time.
| Jan 20 20:16:06 myhost systemd[1]: Starting Postfix Mail Transport Agent 
(instance -)...
| Jan 20 20:16:41 myhost postfix[1800]: Postfix is using backwards-compatible 
default settings
| Jan 20 20:16:41 myhost postfix[1800]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
| Jan 20 20:16:41 myhost postfix[1800]: To disable backwards compatibility use 
"postconf compatibility_level=3.6" and "pos\
| tfix reload"
| Jan 20 20:16:42 myhost postfix/postfix-script[2026]: starting the Postfix 
mail system
| Jan 20 20:16:42 myhost postfix/master[2028]: daemon started -- version 3.7.3, 
configuration /etc/postfix
| Jan 20 20:16:42 myhost systemd[1]: Started Postfix Mail Transport Agent 
(instance -).
| Jan 20 20:16:42 myhost systemd[1]: Starting Postfix Mail Transport Agent...
| Jan 20 20:16:42 myhost systemd[1]: Finished Postfix Mail Transport Agent.
`

I have left nothing out, so WTH is postfix waiting for in these 35
seconds?

Cheers,
   Sven

Re: Postfix fails after upgrade from bullseye to bookworm

[Sven Joachim]

On 2023-01-20 09:34 -0700, Charles Curley wrote:

> On Fri, 13 Jan 2023 11:52:29 -0700
> Charles Curley  wrote:
>
>> That suggests there's something wrong with
>> the way systemd is starting postfix. I will look into that later
>> today.
>
> Not quite "later today", but:
>
> A bit of thinking about it, and I realized that the computer in
> question is an ancient 686 with very limited RAM, physical and swap. So
> I experimented with watching the startup using htop. That got me
> thinking that maybe the start timeout was too short.
>
> I edited postfix@-.service, like so:
>
> systemctl edit postfix@-.service
>
> and added a line to the end of the [service] stanza:
>
> TimeoutSec=360

It seems that postfix's startup time has greatly regressed, on my laptop
there are very long delays both at boot:

,
| $ systemd-analyze blame | head -n1
| 33.340s postfix@-.service
`

as well when restarting postfix:

,
| $ time sudo systemctl restart postfix.service
| sudo systemctl restart postfix.service  0,06s user 0,03s system 0% cpu 38,611 
total
`

Clearly something fishy is going on here.

Cheers,
   Sven

Re: PowerBook G4 OS

[Sven Joachim]

On 2023-01-10 12:45 -0800, Bob Crochelt wrote:

> I have a Powerbook G4 currently running Debian 8 (Jessie).  Is there a
> more recent release supported on PPC, and where could I find it please?

No, there is no more recent release, at least not of Debian.  The
powerpc architecture is still hosted on debian-ports[1], but contains
only the unstable branch of Debian, so packages will contain new and
exciting bugs rather than the boring old ones you get in stable.

Trying to upgrade from Debian 8 will most likely completely break in all
kinds of ways, so if you want to switch to unstable the best way is to
reinstall.  You can find a ~10 months netinst iso at [2].

If you are feeling less adventurous, you could use debootstrap to setup
a chroot first and try the newest software there.

Good luck,
Sven


1. https://www.ports.debian.org/
2. https://cdimage.debian.org/cdimage/ports/current/

Re: Debian security team support for Bullseye?

[Sven Joachim]

On 2023-01-07 11:22 -0800, John Conover wrote:

> How much longer will Debian security team support Bullseye?

For one year after the release of Bookworm, whenever that may be.

> The LTS Wiki page is kind of confusing as to when I have to upgrade to
> Bookworm.

It seems to project that the LTS team takes over Bullseye in July 2024,
but the exact time depends on when Bookworm is actually released.

Cheers,
   Sven

Re: Chroot and x32

[Sven Joachim]

On 2022-11-29 11:24 -0500, Jeffrey Walton wrote:

> I'm running a Debian Unstable machine. I use it for Chroots. I noticed
> x32 is not available when I attempted to setup a chroot with
> debootstrap:
>
> $ debootstrap --arch=x32 --keyring
> /usr/share/keyrings/debian-archive-keyring.gpg \
>   --variant=buildd --exclude=debfoster unstable debian-x32
> http://ftp.ports.debian.org/debian-ports
>
> E: Unable to execute target architecture
>
> In the past I seem to recall I had a x32 chroot for testing. And the
> Debian Ports page shows x32 as a work in progress. Cf.,
> https://www.debian.org/ports/ .
>
> Has x32 been dropped? Or am I doing something wrong?

Debian kernels disable x32 support by default for security reasons.  You
can enable it at boot time via the "syscall.x32=y" kernel parameter.
Here is the patch that Debian applies to the upstream kernel sources:

https://sources.debian.org/src/linux/6.0.10-1/debian/patches/features/x86/x86-make-x32-syscall-support-conditional.patch/

Cheers,
   Sven

Re: How to check for scheduled shutdown

[Sven Joachim]

On 2022-11-22 20:18 +0100, Kamil Jońca wrote:

> Urs Thuermann  writes:
>
>> After shutdown -h  I see no way to see this scheduled shutdown.
>> Before systemd, I could always see the shutdown process with its
>> arguments using ps(1).
>
> Hm.
> kjonca@alfa:~%man shutdown
> SHUTDOWN(8)   
> 
> shutdown  
> 
> SHUTDOWN(8)
>
> NAME
>shutdown - Halt, power off or reboot the machine
> [...]
> OPTIONS
> [...]
>--show
>Show a pending shutdown action and time if there is any.
>
> kjonca@alfa:~%sudo shutdown --show
> No scheduled shutdown.
>
> Am I overlooked something?

Perhaps that the --show option was only added in systemd 250 and is not
available in Bullseye and older Debian releases.

Cheers,
   Sven

Re: Causing segmentations fault; Was: Re: No Public Key

[Sven Joachim]

On 2022-11-14 11:39 -0500, Greg Wooledge wrote:

> If anyone figures out a way to make mutt NOT segfault when reading this
> type of email, I'd love to hear it.

Upgrading to 2.2.8 or later should do the trick.  I can confirm that
mutt 2.2.9-1 in unstable no longer segfaults displaying the message in
question.

https://gitlab.com/muttmua/mutt/-/issues/428

Cheers,
   Sven

Re: update-initramfs outside of /boot

[Sven Joachim]

On 2022-10-01 17:26 +0200, Erwan David wrote:

> Le 01/10/2022 à 17:16, Stefan Monnier a écrit :
>>> My /boot is 235 MB (from deb 10 installer), however in testing I now have
>>> 56MB initramfs files and update-initramfs cannot work for the 3rd kernel to
>>> install (and apt autoremove keeps 2 kernels, thus at upgrade there are
>>> temporarily 3 kernels).

The most sustainable solution is to increase your /boot filesystem,
which unfortunately might not be convenient.

>>  MODULES=dep
>>
>> and
>>
>>  COMPRESS=lzma
>>
>> in `initramfs.conf` can make a big difference.
>>
>>
>>  Stefan
>>
>>
> I alreaady have compres=zstd (should be better than
> lzma). modules=most because I do not like the "guess".

MODULES=dep should be fine as long as you do not intend to move your
disk to another machine.

> An d It would
> be a temporary mesuer since initramfs siuze keeps growing. I just do
> not see the point of building it in /boot rather than eg /tmp or
> another directory specified in conf.

It would be possible to create the initramfs in another directory, but
to ensure atomic upgrades it would have to be copied to /boot anyway
_before_ unlinking the old one (if any).  Otherwise the system could
become unbootable if it crashes at the wrong moment.

Cheers,
   Sven

Re: usr-is-merged package in bullseye?

[Sven Joachim]

On 2022-09-13 18:55 +0100, Tim Woodall wrote:

> On Tue, 13 Sep 2022, Greg Wooledge wrote:
>
>> On Tue, Sep 13, 2022 at 04:45:40PM +0100, Tim Woodall wrote:
>>> There's a package usr-is-merged that will stop usrmerge being installed
>>> with init-system-helpers (and so avoids bringing in its dependencies)
>>> but I don't see that available in bullseye.
>>>
>>> Most of my systems are already merged /usr and I'd prefer to avoid
>>> bringing in unnecessary packages when I upgrade to bookworm (which will
>>> be after bookworm becomes stable). Will the usr-is-merged package be
>>> added to bullseye before then?
>>
>> Added to bullseye?  That sounds unlikely.  New packages are almost never
>> *added* to a stable release.
>>
>> I can only guess that once we're in the bookworm freeze, some instructions
>> will start to appear for how users are expected to manage the transition.
>
> I might be misunderstanding but I was expecting bookworm to get the
> dependency init-system-helpers -> usrmerge imminently. Sid gets it, I
> think, on Thursday.

That is true.

> That's why I want usr-is-merged on my bullseye systems. I'll backport
> from bookworm.

You could, but why?

> Yes, on a migration you can add bookworm sources, apt-get install
> usr-is-merged, and then do the upgrade, but I'll probably forget, I've
> still got a couple of machines on buster to deal with first.

There seems to be some confusion here.  To actually convert your system
to a merged /usr you need to install the usrmerge package which does the
work, and is already available in bullseye and buster.  The
usr-is-merged package is just for convenience, and to ensure that the
system actually has a merged /usr (it will fail to install otherwise, so
if you have an unmerged /usr you need to install usrmerge first).

Cheers,
   Sven

Re: Seeing progross during fsck on boot

[Sven Joachim]

On 2022-09-01 22:51 +0100, Mike wrote:

> A long time, maybe 11 years ago, I built a NAS box based around comodity
> hardware and the Debian of the day.  It's currently been through several
> apt-get dist-upgrades and currently running Debian 11 with loads of old
> config grandfathered into it.
>
> It's a server, so runs 24x7 but every few months or so falls on its
> arse.  Periodically it wants to fsck the disks, either because they've
> gone 20 mounts or so without a fsck or more often because they've gone
> however many days it is without a fsck.
>
> This I can live with.  I can even live with the fact that with several
> TB file systems and quite a few files, the processs takes around fuor
> hours.  I'd just be nice to have some progress reported.  While it
> managed to spit details of any file system errors that have been found
> and corrected, other than that it sits there utterly silent.  For hours.
> I can see that it's doing something as 1) it's expected behaviour and 2)
> I can see the disk light solid on.  Nevertheless, it would be nice to
> see the progress bar indicting how it was getting along.
>
> Does aoyone have any idea how to enable this?  I have no idea where to
> look.  I've had several attempts at finding the answer with a well-known
> Internet search engine but while I've found many similar questions and
> even sometimes the same one as I'm asking but so far an answer has
> proved illusive.
>
> Does anyone have any suggestions for a solution or indeed where one may
> look for one?

You probably want "ShowStatus=auto" in the [Manager] section of
/etc/systemd/system.conf, or boot with the "systemd.show_status=auto"
option.  See the systemd manpage:

,
| KERNEL COMMAND LINE
| [...]
|systemd.show_status
|Takes a boolean argument or the constants error and auto. Can
|be also specified without an argument, with the same effect as
|a positive boolean. If enabled, the systemd manager (PID 1)
|shows terse service status updates on the console during
|bootup. With error, only messages about failures are shown,
|but boot is otherwise quiet.  auto behaves like false until
|there is a significant delay in boot. Defaults to enabled,
|unless quiet is passed as kernel command line option, in which
|case it defaults to error. If specified overrides the system
|manager configuration file option ShowStatus=, see systemd-
|system.conf(5).
`

Cheers,
   Sven

Re: uvcdynctrl on bullseye?

[Sven Joachim]

On 2022-09-02 16:47 +0100, Dave Howorth wrote:

> I'd like to use uvcdynctrl on a bullseye 64-bit system. But according
> to https://packages.debian.org/search?keywords=uvcdynctrl the package
> is not available for any flavour of bullseye. It is available for both
> earlier (stretch and buster) and later (bookworm and sid) releases.

That is true, unfortunately.

> So I'm curious what the reason is?

The best way to find out is to visit https://tracker.debian.org/ and
enter the package name (can be a source or binary package).  In this
case, this leads to https://tracker.debian.org/pkg/libwebcam where you
should be looking for "REMOVED from testing" links.

> And if I could use one of the other versions on my system? I'm sadly
> no expert on forwards and backwards compatibility issues.

Using an older version is usually possible, but it would expose you to
exactly the same bug that is the reason why the package is not available
in bullseye.

Using newer versions is not recommended, because they depend on
libraries not available on bullseye.  You do not want to upgrade to
bookworm's libc6, for instance.

The best option is often to use a backport[1].  For libwebcam such a
backport has already been prepared by the maintainer, but not been
accepted yet[2].  You would need to either wait for it to become
available or build it yourself, e.g. from the tag in the package's git
repository[3].

Cheers,
   Sven


1. https://backports.debian.org/
2. https://ftp-master.debian.org/new/libwebcam_0.2.5-2~bpo11+1.html
3. https://salsa.debian.org/debian/libwebcam/-/tree/debian/0.2.5-2_bpo11+1

Re: Substitute for archivemail

[Sven Joachim]

On 2022-08-31 08:47 -0400, Kenneth Parker wrote:

> On Wed, Aug 31, 2022, 5:36 AM riveravaldez 
> wrote:
>
>> On 8/30/22, Anssi Saari  wrote:
>> > Leandro Noferini  writes:
>> >
>> >> In these days I upgraded the server to bullseye and so I have not yet
>> >> archivemail: what could I use as subsitute?
>> >
>> > I wonder about that too,
>>
>> Hi, not an archivemail user, but just in case it's useful: you can
>> check the right column bottom section ('Similar packages') on Debian's
>> archivemail package page to see if there's something relevant there
>> (and if it's available in newer Debian versions):
>>
>> https://packages.debian.org/buster/archivemail
>
>
> Okay.   So archivemail hasn't been updated for Python 3 yet.

s/ yet//

Some people have tried, but gave up eventually, therefore the package
has been removed.  See https://bugs.debian.org/936146 for details.

Cheers,
   Sven

Re: Will firefox-esr move to version 102 in bullseye?

[Sven Joachim]

On 2022-08-24 15:01 -0400, Greg Wooledge wrote:

> On Wed, Aug 24, 2022 at 07:52:44PM +0100, Tixy wrote:
>> Mozilla stops supporting the old ESR a few months after a new one is
>> released [1]. So I assume Debian would ship the new one, certainly at
>> least at the point the old one gets known security vulnerabilities.
>>
>> [1] https://support.mozilla.org/en-US/kb/firefox-esr-release-cycle
>
> Yes, this is correct.  A current timeline seems to be here:
>
> https://wiki.mozilla.org/Release_Management/Calendar
>
> Looking at the ESR column in the first table, 2022-08-23 brought us
> ESR versions 91.13 and 102.2, while 2022-09-20 will have only version
> 102.3.
>
> So, as of Sept. 20th (projected), the 91.x ESR branch will be unsupported,
> and we'll all have to move to the 102.x branch, whether we want it or not.

For Debian stable, I expect Firefox and Thunderbird to move to the 102
branch after the next Bullseye point release, scheduled for September
10[1].  To build them, at least rustc 1.59 is needed, and Bullseye
currently only has version 1.51 (packaged as rustc-mozilla).

Cheers,
   Sven


1. https://lists.debian.org/debian-live/2022/08/msg6.html

Re: Bookworm : graphic glitches all over my screen after upgrade

[Sven Joachim]

On 2022-08-23 15:13 +0200, rudu wrote:

> Coming back from holidays, I did a pretty huge upgrade of my Bookworm
> system on my aging desktop (2009).
> After a reboot, what I could see is best described via this snapshot :
> https://wtf.roflcopter.fr/pics/rVcN0HFu/vgQCGy7g.png
>
> What I tried so far :
> - replacing my nouveau driver by a proprietary one, but :
> $ nvidia-detect
> Detected NVIDIA GPUs:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G96C
> [GeForce 9400 GT] [10de:0641] (rev a1)
>
> Checking card:  NVIDIA Corporation G96C [GeForce 9400 GT] (rev a1)
> Your card is only supported by the 340 legacy drivers series, which is
> only available up to buster.
>
> - installed the last kernel for testing :
> $ dpkg -l linux-image-* | grep ^ii
> ii  linux-image-5.18.0-4-amd64  5.18.16-1    amd64 Linux 5.18
> for 64-bit PCs (signed)
> ii  linux-image-5.7.0-2-amd64   5.7.10-1 amd64 Linux 5.7
> for 64-bit PCs (signed)
> ii  linux-image-5.7.0-3-amd64   5.7.17-1 amd64 Linux 5.7
> for 64-bit PCs (signed)
> ii  linux-image-amd64   5.18.16-1    amd64 Linux for
> 64-bit PCs (meta-package)
> ... no change.
>
> - reconfigured window display management between lightdm/sddm/gdm3 :
> Curiously, only sddm showed no sign of being affected, until I opened
> a graphic environment (LXDE, XFCE4, Gnome-Xorg/wayland,
> Plasma-Xorg/wayland) where the problem was always back.
>
> - I looked into /var/log/apt/term.log resulting from my last upgrade
>   and tried to find something relevant and I saw this :
> cat /var/log/apt/term.log | grep xserver
> Préparation du dépaquetage de .../38-xserver-common_2%3a21.1.4-1_all.deb ...
> Dépaquetage de xserver-common (2:21.1.4-1) sur (2:21.1.3-2) ...
> Préparation du dépaquetage de
> .../39-xserver-xorg-core_2%3a21.1.4-1_amd64.deb ...
> Dépaquetage de xserver-xorg-core (2:21.1.4-1) sur (2:21.1.3-2+b1) ...
> Préparation du dépaquetage de
> .../359-xserver-xephyr_2%3a21.1.4-1_amd64.deb ...
> Dépaquetage de xserver-xephyr (2:21.1.4-1) sur (2:21.1.3-2+b1) ...
> Paramétrage de xserver-common (2:21.1.4-1) ...
> Paramétrage de xserver-xephyr (2:21.1.4-1) ...
> Paramétrage de xserver-xorg-core (2:21.1.4-1) ...
>
> I don't know what to do or where to look, my system is barely usable
> now and freezes regularly ...

Seems you are experiencing bug #1017499[1], for which no solution
currently exists.  Try downgrading your installed packages from
src:mesa.

Good luck,
  Sven


1. https://bugs.debian.org/1017499

Re: Proprietary WiFi drivers for live mode

[Sven Joachim]

On 2022-06-25 18:11 +0300, Kristijonas Lukas Bukauskas wrote:

> I have an old Dell laptop with Broadcom BCM43142 WiFi device
> (https://wiki.debian.org/wl). It doesn't have a hard drive, so I
> sometimes boot Debian from USB Memory Stick in live mode.
> The problem is that WiFi doesn't work because of the proprietary drivers
> it needs.

Probably you do not need proprietary drivers for your card, but it
requires non-free firmware.  Which on these old Broadcom devices is a
PITA, because Broadcom did not make it easily available.

> I tried booting it from live+nonfree image
> (https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.3.0-live+nonfree/amd64/iso-hybrid/),
> but still no luck (WiFi doesn't work). As I understand, the needed
> drivers would load when installing the system, but they do not load in
> live mode.

There is a misunderstanding here.  Debian's non-free images do not
contain proprietary drivers, but they provide firmware for the devices,
so that the in-kernel drivers can actually work.

If the non-free image does not work, the firmware for your device is
missing because of licensing reasons.  There is a package named
firmware-b43-installer in contrib which downloads Broadcom's old drivers
and extracts the firmware from them. Obviously you need a network
connection for that, so you might have to use it on another system.

Good luck,
Sven


1. https://packages.debian.org/bullseye/firmware-b43-installer

Re: Restoring file capabilities in /usr

[Sven Joachim]

On 2022-02-16 20:03 +0100, d...@x.org.pl wrote:

> Is there an easy method of restoring original file capabilities for the
> entire /usr directory?
>
> The background is I wanted to move my /usr directory to another
> partition and I copied it with "cp -ar ..." and deleted the original
> content of /usr to find out my ping does not work because of the lack of
> the required capabilities for the binary.
> That is not too much of an issue, because I can fix the ping command.
> However, I am afraid there might be some other binaries lurking to bite
> me when I need it least...
>
> Is there an easy method (like apt based for instance) of restoring file 
> capabilities for the whole
> /usr directory?

Capabilities are currently not stored in Debian packages, but are set up
by the postinst scripts.  Here is how to find them:

$ grep -w -l setcap /var/lib/dpkg/info/*.postinst

Reinstall the affected packages (likely there are only a few of them),
and you should be fine.

Cheers,
   Sven

Re: Any plan to upgrade bash to 5.1.16 on bullseye?

[Sven Joachim]

On 2022-02-16 11:18 +0100, Christian Britz wrote:

> On 2022-02-16 10:16 UTC+0100, Daniel Qian wrote:
>> Hi,
>>
>> There is a severe bug on GNU Bash which is fixed in 5.1.16.
>>
>> Bug info: https://lists.gnu.org/archive/html/bug-bash/2022-01/msg00020.html
>>
>> While currently debian bullseye GNU Bash is 5.1.4.
>
> Without reading the details: If you think this should be fixed in Debian
> stable, please go to bugs.debian.org and check if there is already a
> report.

There is, https://bugs.debian.org/1003012.  Apparently no progress on a
stable upload has been made in the last five weeks, so it might be good
to ping that bug.

Cheers,
   Sven

Re: Building a package for ScummVM 2.5.0

[Sven Joachim]

On 2021-10-12 21:48 +0200, Christian Britz wrote:

> I am trying to build a Debian package for the latest ScummVM release
> for personal use and need help.
> I have no deep knowledge of Debian packaging, but in the past I had
> some success with applying dh_make to source trees.

I would probably rather start with the existing scummvm package in the
archive and adapt that to the new upstream release.

> This is what I have done in the source folder:
>
> dh_make -n -s -e a...@bbb.ccc
> fakeroot debian/rules binary
>
> Output:
>
> dh binary
>    dh_update_autotools_config
>    dh_autoreconf
>    dh_auto_configure
>     ./configure --build=x86_64-linux-gnu --prefix=/usr
> --includedir=\${prefix}/include --mandir=\${prefix}/share/man
> --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
> --disable-option-checking --disable-silent-rules
> --libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run
> --disable-maintainer-mode --disable-dependency-tracking
> Running ScummVM configure...
> error: unrecognized option: --disable-option-checking
> [...]
>
> The configure script seems to be unable to deal with the parameter
> --disable-option-checking. Where is this set? The debian sub directory
> does not contain that string.

It is passed by dh_auto_configure, see
/usr/share/perl5/Debian/Debhelper/Buildsystem/autoconf.pm.

> Running ./configure manually works fine.

That is what the Debian package does[1], because scummvm's configure
script is apparently not produced by autoconf.

Cheers,
   Sven


1. https://sources.debian.org/src/scummvm/2.2.0+dfsg1-4/debian/rules/#L37

Re: gcc-10: options order important?

[Sven Joachim]

On 2021-09-03 12:24 +0200, Piotr A. Dybczyński wrote:

> Hi,
>
> in contrary to previous versions, now in Debian 11 with gcc-10:
>
> gcc aa.c -lm -o aa   works, but
>
> gcc -lm aa.c -o aa   does not work, saying: 
>
> /usr/bin/ld: /tmp/ccWyhudO.o: in function `main':
> aa.c:(.text+0x1f): undefined reference to `sqrt'
> collect2: error: ld returned 1 exit status
>
> It seems that an option -lm cannot be placed in an arbitrary place which I 
> used to
> do. Is this intentional ?

Yes, gcc now invokes ld with the --as-needed option.  This reduces
unnecessary linking and thereby Debian package dependencies, but it also
has the effect you are seeing, as mentioned in the binutils
documentation:

,
| Object files or libraries appearing on the command line _after_ the
| library in question do not affect whether the library is seen as needed.
| This is similar to the rules for extraction of object files from
| archives.  '--no-as-needed' restores the default behaviour.
`

Cheers,
   Sven

Re: APT testing and unstabe Firefox: can't find newest version from unstable

[Sven Joachim]

On 2021-09-03 19:05 +0200, Daniel M. wrote:

> I'm running debian testing ("bookworm" at the moment) and have firefox
> 88 installed from unstable. My sources.list contains testing and
> unstable main, contrib and non-free lines and I have pinning set up to
> 900 testing, 500 unstable. Default-Release is set to "testing".
>
> The debian package tracker (https://tracker.debian.org/pkg/firefox)
> states that version 91.0.1-1 of firefox should be available, but I can
> in no way install it. "apt -t unstable install firefox" doesn't work,
> neither does "apt install firefox/unstable". Both get me version 88
> again. "apt-cache policy firefox" also only lists this version. If I
> remove firefox and install it again with one of these ways I again get
> version88.
>
> What am I doing wrong? Shouldn't I be able to install version 91 via
> one of these ways?

Version 91 is only in experimental.

Cheers,
   Sven

Re: You are required to change your password immediately (administrator enforced).

[Sven Joachim]

On 2021-08-18 14:16 +0200, Harald Dunkel wrote:

> On 8/17/21 21:55, Sven Joachim wrote:
>> On 2021-08-17 19:59 +0200, Harald Dunkel wrote:
>>
>>>
>>> How can I make sure I don't have to change passwords on 400+ hosts?
>> Do not run sid on 400+ hosts.  Do not run testing either, especially
>> in
>> the first months after a release.
>>
>
> Of course not. But sid becomes the next release in 2 years, and then it
> might be to late to get rid of this lie.

Feel free to file a bug against the libcrypt1 package and/or the release
notes.  The change itself looks quite reasonable to me though, as
md5crypt hashes are really insecure these days.

The following command could be used to check for old md5crypt password
hashes, see crypt(5):

sudo cat /etc/shadow | grep -F ':$1$'

Cheers,
   Sven

Re: You are required to change your password immediately (administrator enforced).

[Sven Joachim]

On 2021-08-17 21:55 +0200, Sven Joachim wrote:

> On 2021-08-17 19:59 +0200, Harald Dunkel wrote:
>
>> After the most recent update of a host running sid there was a
>> password change dialog:
>>
>> You are required to change your password immediately (administrator 
>> enforced).
>> You are required to change your password immediately (administrator 
>> enforced).
>
> Same here.  The only package that could be related to this surprise
> which I upgraded seems to be libcrypt1.  Huh?

Indeed libcrypt1 seems to the culprit.  After changing my password and
downgrading libcrypt1 (as well as libcrypt-dev) to the bullseye version
I could restore my /etc/shadow from a backup without being nagged again.

It also seems that the problem only occurs if you have not changed your
password for quite a few years and it still has an md5 hash in
/etc/shadow.  For details see
https://github.com/besser82/libxcrypt/issues/129.

Cheers,
   Sven

Re: You are required to change your password immediately (administrator enforced).

[Sven Joachim]

On 2021-08-17 19:59 +0200, Harald Dunkel wrote:

> After the most recent update of a host running sid there was a
> password change dialog:
>
> You are required to change your password immediately (administrator enforced).
> You are required to change your password immediately (administrator enforced).

Same here.  The only package that could be related to this surprise
which I upgraded seems to be libcrypt1.  Huh?

> That would be me, but I cannot remember having set such a policy, so
> WTH? Not to mention that this broke non-interactive ssh sessions as
> well.
>
> How can I make sure I don't have to change passwords on 400+ hosts?

Do not run sid on 400+ hosts.  Do not run testing either, especially in
the first months after a release.

Cheers,
   Sven

Re: PC fan getting very loud

[Sven Joachim]

On 2021-05-08 11:13 +0200, deloptes wrote:

> Fujitsu ESPRIMO Q520 when opening some sh*tty web sitesin firefox the fan
> gets extremly noisy.

Such is the modern web. :-(

> On a Fujitsu C700 with the same setup there is no such problem - although I
> probably do not open these sites - but some other sites cause a lot of load
> and still the fan is not getting so noisy.

Dust off your ESPRIMO Q520 machine, and consider reapplying thermal
paste.  If that does not help, buy a better fan (the small form factor
limits your choices, though).

Cheers,
   Sven

Re: Some services cannot start at boot time because /run is not initialized

[Sven Joachim]

On 2021-04-22 14:26 +0200, Dmitry Katsubo wrote:

> Dear Debian community,
>
> I have noticed that all failed services were missing some directories under 
> /run directory. I checked the service which is supposed to create them:
>
> *  systemd-tmpfiles-setup.service - Create Volatile Files and Directories
>Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; 
> static; vendor preset: enabled)
>Active: inactive (dead)
>  Docs: man:tmpfiles.d(5)
>man:systemd-tmpfiles(8)
>
> systemd[1]: sysinit.target: Found ordering cycle on 
> systemd-tmpfiles-setup.service/start
> systemd[1]: sysinit.target: Found dependency on local-fs.target/start
> systemd[1]: sysinit.target: Found dependency on zram-setup@zram1.service/start
> systemd[1]: sysinit.target: Found dependency on sysinit.target/start
> systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted 
> to break ordering cycle starting with sysinit.target/start

This is obviously bad, since many files and directories under /run will
be missing.

> and it looks like there is problem in zram-setup@zram1.service which I 
> configured like that:
>
> [Unit]
> Requires=dev-%i.device
> After=dev-%i.device
> Before=local-fs.target
> [Install]
> WantedBy=local-fs.target
>
> # systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After 
> local-fs.target
> Requires=home.mount -.mount var.mount
> Requisite=
> Wants=systemd-fsck-root.service zram-setup@zram0.service 
> zram-setup@zram1.service systemd-remount-fs.service
> BindsTo=
> PartOf=
> Before=binfmt-support.service sysinit.target 
> systemd-machine-id-commit.service systemd-tmpfiles-setup.service 
> networking.service systemd-tmpfiles-clean.service console-setup.service
> After=run-user-1000.mount zram-setup@zram0.service root.mount -.mount 
> tmp.mount zram-setup@zram1.service systemd-fsck-root.service 
> systemd-remount-fs.service home.mount var.mount local-fs-pre.target
>
> Even though I don't see any conflict with dependencies, it is confusing 
> systemd.
>
> Any idea concerning how to fix that is welcomed.

I think you need to add a line with

DefaultDependencies=no

to the [Unit] section of your .service file.  That is because by
default, all services have an implicit dependency on sysinit.target (see
systemd.target(5)), and sysinit.target depends on local-fs.target:

,
| $ systemctl show -p WantedBy local-fs.target
| WantedBy=sysinit.target
`

HTH,
Sven

Re: Debian chromium package enable_hangout_services_extension=false by default. How to turn it on during run time?

[Sven Joachim]

On 2021-04-18 07:56 +0800, Robbi Nespu wrote:

> Hello! I not able to use "screen share" on google meet using chromium
> browser.
>
> Each time I clicked on it, I get "your browser can't share your
> screen" and dev tool > console don't complaint anything about it.
>
> I did a google-fu and found out it related with a feature that been
> disabled by debian (rule) during built.
>
> $ apt-cache policy chromium
> chromium:
>   Installed: 89.0.4389.114-1
>   Candidate: 89.0.4389.114-1
>   Version table:
>  *** 89.0.4389.114-1 500
> 500 http://ftp.jp.debian.org/debian bullseye/main amd64 Packages
> 100 /var/lib/dpkg/status
>
> So I checked here
> https://sources.debian.org/src/chromium/89.0.4389.114-1/debian/rules/
> # disabled features
> defines+=is_debug=false \
>  use_goma=false \
>  use_ozone=false \
>  use_sysroot=false \
>  use_allocator=\"none\" \
>  use_libjpeg_turbo=true \
>  use_custom_libcxx=false \
>  use_gnome_keyring=false \
>  use_unofficial_version_number=false \
>  enable_vr=false \
>  enable_nacl=false \
>  enable_nacl_nonsfi=false \
>  enable_swiftshader=false \
>  enable_reading_list=false \
>  enable_one_click_signin=false \
>  enable_iterator_debugging=false \
>  enable_hangout_services_extension=false \ # <--- HERE
>  optimize_webui=false \
>  angle_has_histograms=false \
>  enable_js_type_check=false \
>  treat_warnings_as_errors=false \
>
> How I can turn it on during runtime? without need to patch manually
> and built the package locally?

I don't think you can, this is a build time feature IIUC.  There is a
bug report requesting it to be enabled: https://bugs.debian.org/886358.

Cheers,
   Sven

Re: Need help finding the right package under which to report a bug

[Sven Joachim]

On 2021-04-18 12:31 +0800, Robbi Nespu wrote:

> A quick or temporary solution are to git clone
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
> and copy thus selection (warning line) of missing modules to
> /lib/firmware/amdgpu/
>
> (Don't try my solution if you are novice).

I would rather live with the warnings unless I actually had a GPU which
needs this firmware.  Don't know if you can actually buy these yet.

> Look like the bug are the 5.10.0-6-amd64 kernel.

No, it is in the firmware-amd-graphics package.  A bug report against
this package could help to remind the maintainers that they should
include the arcturus firmware in future uploads.

Cheers,
   Sven

Re: [sid] efibootmgr not working on linux 5.10.x & LGA1155

[Sven Joachim]

On 2021-04-08 22:30 +0200, Grzesiek wrote:

> On 3/18/21 9:55 PM, Sven Joachim wrote:
>> On 2021-03-18 21:03 +0100, Grzesiek Sójka wrote:
>> 
>>> I noticed recently that efibootmgr stoped working. On all my Sid
>>> machines I get the following:
>>>
>>> # efibootmgr
>>> EFI variables are not supported on this system.
>>>
>>> But if I run Buster (the same hardware) then everything is ok. So this
>>> is definitely software problem. I also noticed that the
>>> /sys/firmware/efi/efivars
>>> directory is empty.
>> Not here, and efibootmgr works for me.
>> 
>>> Kernel problem? Missing modules?
>> Perhaps the efivarfs module is not loaded.  I don not have to load
>> it
>> manually, though.
>
> The problem seems to be related to 5.10.x kernels & LGA1155 based systems.
>
> 1. On laptop based on i5-8250u efibootmgr works fine (all kernel versions)
>
> 2. On systems based on LGA1155 socket (i5-2500k, i7-3770):
> - kernels 5.10.x: efibootmgr does not work,
> directory /sys/firmware/efi/efivars is empty
> - kernel 5.8.0-2: efibootmgr woks as expected
>
> On 5.8.0-2 i get:
>
> # lsmod | grep efi
> efivarfs   16384  0
> efi_pstore 16384  0
> efivars20480  1 efi_pstore
>
> There is no efivars.ko in 5.10.x. Maybe that is the problem?

The efivars module has indeed been removed from Debian's 5.10 kernels,
as it had been deprecated in favor of efivarfs for a while.

Which versions of efibootmgr and libefivar1 do you have installed?

Cheers,
   Sven

Re: apt upgrade merging modified files

[Sven Joachim]

On 2021-03-25 04:39 -0400, Michael Grant wrote:

> When I apt-update, sometimes I update something for which I modified a config 
> file and I get this menu:
>
> Configuration file '/etc/matrix-synapse/homeserver.yaml'
>  ==> Modified (by you or by a script) since installation.
>  ==> Package distributor has shipped an updated version.
>What would you like to do about it ?  Your options are:
> Y or I  : install the package maintainer's version
> N or O  : keep your currently-installed version
> D : show the differences between the versions
> Z : start a shell to examine the situation
>  The default action is to keep your current version.
> *** homeserver.yaml (Y/I/N/O/D/Z) [default=N]

This prompt is coming from dpkg which notes that a conffile has been
changed.  In Debian/dpkg jargon, a conffile is a configuration file that
is shipped in a package.  The dpkg program keeps a checksum for each
conffile in its database and can therefore detect modifications, but it
does not track the content of conffiles.

> Sometimes, rarely, I get a 5th option offering to try to merge the
> files.  I don't know what causes the merge option to be available or
> not.

These packages use a different mechanism for their configuration files
based on a program called ucf.  The files are _not_ shipped in the
package, but created from a template in the maintainer scripts.  Unlike
dpkg, ucf also stores the content of these files and is therefore able
to offer merge options.

> Is there some way I can at minimum add a 5th option to the above menu
> to run emacs in emerge mode with those files as args?  This would save
> lazy me the steps of echoing the vars and starting emacs manually.
>
> I run etckeeper, it would be really sweet if this was smart enough to
> attempt a 3-way merge (merge with an ancestor file).

I am afraid this is not easily possible.  Making dpkg's conffile prompt
smarter has been requested many times, but nothing has happened since
bug #32877[1] and its many siblings have been filed.  Yes, that bug is
22 years old.

Cheers,
   Sven


1. https://bugs.debian.org/32877

Re: Could a product with Chipset information for USB WiFi access dongle be advised please?

[Sven Joachim]

On 2021-03-25 18:15 +0530, Susmita/Rajib wrote:

> Could you please suggest me an USB WiFi dongle that is recommended by
> Debian and available in India?
> https://wiki.debian.org/WiFi#USB_Devices
> and
> https://wiki.debian.org/DeviceDatabase/USB
>
> Problem with Amazon is that the chipsets are not available with the
> product. How could I find a product that would have the listed
> chipset?
>
> I ordered these two products without any possibility for comparison
> with the said Debian Pages:
>
> (1)
> TP-Link USB WiFi Adapter for PC(TL-WN725N), N150 Wireless Network
> Adapter for Desktop - Nano Size WiFi Dongle Compatible with Windows
> 10/7/8/8.1/XP/ Mac OS 10.9-10.15 Linux Kernel 2.6.18-4.4.3
>
> This one identifies itself on the USB port as: 0bda:8179
> The full lsusb output:
> Bus 001 Device 010: ID 0bda:8179 Realtek Semiconductor Corp.
> RTL8188EUS 802.11n Wireless Network Adapter

I have been using that device for a few days, seems to working mostly
fine.  Only tested it with Linux 5.10, though (the kernel in
bullseye/unstable).

Some observations/caveats:

- The firmware-realtek package is required.

- The r8188eu module for the dongle is in the staging area, as it does
  not quite meet the kernel developers' standards, a problem with
  various Realtek drivers.  In theory it might even be removed some day,
  but since it has been there for over seven years and the hardware is
  very popular this is highly unlikely to happen in practice.

- The activity LED on the dongle sometimes stays on during suspend and
  then remains in that state after resume until the device is
  re-plugged.  This may or may not bother you.

Considering the low price, I cannot really complain.

Cheers,
   Sven

Re: [sid] efibootmgr not working

[Sven Joachim]

On 2021-03-18 21:03 +0100, Grzesiek Sójka wrote:

> I noticed recently that efibootmgr stoped working. On all my Sid
> machines I get the following:
>
> # efibootmgr
> EFI variables are not supported on this system.
>
> But if I run Buster (the same hardware) then everything is ok. So this
> is definitely software problem. I also noticed that the
> /sys/firmware/efi/efivars
> directory is empty.

Not here, and efibootmgr works for me.

> Kernel problem? Missing modules?

Perhaps the efivarfs module is not loaded.  I don not have to load it
manually, though.

Cheers,
   Sven

Re: What does "Control: reassign -1 libaqbanking44" mean?

[Sven Joachim]

On 2021-03-12 02:13 -0400, Tony Rowe wrote:

> On Fri, Mar 12, 2021 at 12:36:59PM +0900, 황병희 wrote:
>> Hi i am translator Debain webpage in Korean.
>> 
>> At bug mailing,
>> some user wrote in body of message [1] as below:
>> 
>> #+begin_src text
>> Control: reassign -1 libaqbanking44
>> #+end_src
>> 
>> In particular, i am curious the digit "-1".
>> For long time i was thinking about that the "-1".
>> 
>> Is that "subtraction"? or another meaning?
>> 
>> Oh please really my head is stiff..
>> 
>> Sincerely, Byung-Hee
>> 
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=984980
>> 
>> -- 
>> ^고맙습니다 _地平天成_ 감사합니다_^))//
>  
> Hi Byung-Hee,
>
> "-1" refers to making "one clone" of the bug report and is issued to 
> the control server, usually by the packager of the package (as I 
> understand it). [1]

No, in this context it means "the bug you are replying to".

https://www.debian.org/Bugs/Reporting.html#control

Cheers,
   Sven

Re: Is there an alternative filesystem hierarchy that could be adapted to Debian.

[Sven Joachim]

On 2021-03-10 17:13 -0500, Stefan Monnier wrote:

>> I think all these shortened names derive from a time when computing
>> resources were limited. If you're using an 80x25 terminal over at 50
>> bits per second to a time-shared mainframe, it's more comfortable to
>> type "/usr" than it is to type "/Programs". Easier to type "cp" than to
>> type "copy", and so on. It's all fairly arbitrary. Why C:\? Why not
>> System:\? Convention and history and inertia.
>
> [ I think even back in the early days of time-sharing, connections were
>   faster than 50bit/s.  ]
>
> I suspect that the short names were chosen rather so as to minimize the
> amount of typing that humans need to do on the command line.

The Unix-Haters Handbook has the following theory:

,
| Those of us who used early 70s I/O devices suspect the degeneracy stems
| from the speed, reliability, and, most importantly, the keyboard of the
| ASR-33 Teletype, the common input/output device in those days. Unlike
| today’s keyboards, where the distance keys travel is based on feedback
| principles, and the only force necessary is that needed to close a
| microswitch, keys on the Teletype (at least in memory) needed to travel
| over half an inch, and take the force necessary to run a small electric gener-
| ator such as those found on bicycles. You could break your knuckles touch
| typing on those beasts.
| 
| If Dennis and Ken had a Selectric instead of a Teletype, we’d probably be
| typing “copy” and “remove” instead of “cp” and “rm.” Proof again that
| technology limits our choices as often as it expands them.
`

Cheers,
   Sven

Re: The best way to install inkscape 1.0 on Debian stable

[Sven Joachim]

On 2021-03-05 17:02 +0900, A_Man_Without_Clue wrote:

> What is the best way to install the latest version of the inkscape on
> Buster?
>
> Buster installs inkscape 0.9 and I still encounter lots of bugs with it.
> I would like to try the latest but what is the best way to install
> newest version? Download .deb file?

Install inkscape from the buster-backports repository, which you might
have to enable first.

https://backports.debian.org/Instructions/

Cheers,
   Sven

Re: official list of alternatives?

[Sven Joachim]

On 2021-02-14 01:57 +0300, IL Ka wrote:

> Hello.
>
> There is a list of alternatives in ``sensible-browser`` including
> ``www-browser``, ``x-www-browser`` etc.
>
> This makes me think that all alternatives must be documented somewhere in
> debian policy.

What makes you think so?  Many alternatives have only two or three
implementations, sometimes from the same source package.

> Something like "each developer of X-based browser must register it as
> x-www-browser alternative".
>
> However, I haven't found anything except "pager" and "editor" (section 11)
> Do I miss something?

At least x-terminal-emulator and x-window-manager are also mentioned.
But there are many others, on my system alone over 100:

,
| $ ls /var/lib/dpkg/alternatives | wc -l
| 122
`

Obviously it would not be practical to document them all in the policy.

Cheers,
   Sven

Re: gnome-control-center

[Sven Joachim]

On 2021-01-31 17:09 +, Gareth Evans wrote:

> I'm trying to install gnome-online-accounts on Debian 10.7 with Mate:
>
>
> $ sudo apt install gnome-control-center gnome-online-accounts
> [...]
> Package gnome-control-center is not available, but is referred to by another 
> package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> However the following packages replace it:
>   gnome-control-center-data
> E: Package 'gnome-control-center' has no installation candidate
>
> $ sudo apt install gnome-online-accounts
> [...]
> Recommended packages:
>   gnome-control-center
> The following NEW packages will be installed:
>   gnome-online-accounts
> 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
> [...]
>
>
> gnome-control-center-data doesn't seem to provide gnome-control-center
> as the first apt install blurb seems to me to suggest (but neither
> does it seem that it should!)
>
> https://tracker.debian.org/pkg/gnome-control-center
>
> shows gnome-control-center 1:3.38.3-1 is in testing, but also that a
> stable version exists - 1:3.30.3-2~deb10u1 - isn't this what should be
> installed upon request, along with dependencies?

Yes.  Possible explanations: your sources.list is broken, or you have
assigned a negative pin priority to gnome-control-center (see
apt_preferences(5)).

What does "apt policy" print?

Cheers,
   Sven

Re: Can I remove i386 packages?

[Sven Joachim]

On 2021-01-23 15:47 +0100, steve wrote:

> Le 23-01-2021, à 09:55:29 +0100, to...@tuxteam.de a écrit :
>
>>On Sat, Jan 23, 2021 at 09:19:33AM +0100, steve wrote:
>>> Hi,
>>>
>>> I have the following i386 packages installed on my system. Can I removed
>>> them without any side-effects?
>>>
>>> apt list --installed | grep i386
>>
>>Possibly an "apt-get autoremove" will take care of them.
>
> No, doesn't work.
>
>>In any case, you can do e.g. an "apt-get -s purge libc6:i386" and
>>get an idea of what's going to happen. For the option "-s" you
>>don't need root rights (actually, better not have them: kind of
>>belt-and-suspenders ;-)
>
> # apt-get purge ".*:i386"
> WARNING: The following essential packages will be removed.
> This should NOT be done unless you know exactly what you are doing!
>   libgcc-s1:i386 gcc-10-base:i386 (due to libgcc-s1:i386) libc6:i386 (due to 
> libgcc-s1:i386)
> 0 upgraded, 0 newly installed, 17 to remove and 0 not upgraded.
> After this operation, 22.0 MB disk space will be freed.
> You are about to do something potentially harmful.
> To continue type in the phrase 'Yes, do as I say!'
>
>
> Pretty scary message… but since I know I have the amd64 versions, I
> typed the phrase and the system still works  ;)

The libgcc-s1:i386 is marked as "Important: yes" which means that apt
will refuse to remove it by default.  It should not be that way, but
apparently this is a workaround for potentially losing libgcc_s.so.1 on
upgrades from buster.  See https://bugs.debian.org/972936.

Cheers,
   Sven

Re: Upstream Default (FOSS) DDX Driver for NVidia GPUs is not Nouveau

[Sven Joachim]

On 2021-01-20 16:45 -0500, Felix Miata wrote:

> In 2008 a new technology DDX driver's development was begun:
> 
> The new technology made it hardware independent, able to be used by any GPU 
> that
> has a full-functioning DRM/KMS driver. 2D acceleration depended on Glamor. In
> Debian, the xf86-video-modesetting package was named 
> xserver-xorg-video-modesetting.
>
> In 2014, the development stage of xf86-video-modesetting ceased.
> 
>
> Its life as a separate package then ceased as well. It was moved into the 
> server
> package. I never found an announcement to the effect, but I believe this move 
> in
> effect made it the default DDX driver for any version of the Xorg server from
> version 1.17.0 and up.

Not really, the upstream Xorg server still uses a graphics card specific driver
if available.  On Debian, the modesetting driver is preferred for
non-vintage Intel and NVidia GPUs by distribution-specific patches[1,2].

Cheers,
   Sven


1. 
https://sources.debian.org/src/xorg-server/2:1.20.10-2/debian/patches/06_use-intel-only-on-pre-gen4.diff
2. 
https://sources.debian.org/src/xorg-server/2:1.20.10-2/debian/patches/07_use-modesetting-driver-by-default-on-GeForce.diff

Re: Python 3 wicd

[Sven Joachim]

On 2021-01-19 10:16 +0200, Andrei POPESCU wrote:

> On Ma, 19 ian 21, 02:54:25, Gareth Evans wrote:
>> There is apparently a Python 3 fork of wicd (or two) but I can't
>> figure out what state they're in - are either of these likely to
>> become available in Buster repos?  Backports?
>
> Wicd is currently only available in experimental (according to
> https://tracker.debian.org/wicd)[1], while backports can only be done
> from packages in testing (currently bullseye).
>
> Considering bullseye is now already in the first stage of the freeze
> before release there is little chance for Wicd to be included in
> bullseye at all.
>
> After bullseye is released it might become available in
> bullseye-backports, maybe also buster-backports-sloppy.

The version in experimental is a git snapshot from September 2019,
apparently development has stalled.  People upgrading to bullseye should
probably look for alternatives, I think network-manager is the only
reasonable one unless you are willing to resort to commandline tools.

Cheers,
   Sven

Re: Backup debconf state

[Sven Joachim]

On 2021-01-19 16:09 +0100, Erwan David wrote:

> Hello everybody
>
> If I want to be able to fast reinstall a debian after a crash, I
> already backup /etc (including /etc/apt), a file with the output of
> apt-show manual
> to get the list of manually installed packages, /etc, but It would be
> handy to have the state of debconf (with all the answers I already
> gave).
> Is a backup of /var/cache debconf sufficient for this ?

Yes, that should be enough.  Note that maintainer scripts which use
debconf should first consult the configuration files in /etc and only
fall back to the debconf database if those do not deliver the necessary
information.  That's why the debconf database is located under
/var/cache and not under /var/lib.

Cheers,
   Sven

Re: How to restore BIOS-based backup on a UEFI machine

[Sven Joachim]

On 2021-01-14 17:05 +0100, Sven Joachim wrote:

> I don't think so, the only important thing is that on the restore
> machine you need to set up an EFI system partition[1] from which the
> system boots.  It has to be formatted as FAT32 and mounted under
> /boot/efi when you install grub-efi-amd64.

I forgot the include the link to [1]:

https://en.wikipedia.org/wiki/EFI_system_partition

Cheers,
   Sven

Re: How to restore BIOS-based backup on a UEFI machine

[Sven Joachim]

On 2021-01-14 16:41 +0100, Jesper Dybdal wrote:

> I backup my Buster server simply as a (compressed, encrypted) cpio archive.
>
> Restoring it to a BIOS-based machine is simple: boot a rescue cd,
> partition the disk, restore all files, fix fstab if necessary, run
> update-grub and grub-install in a chroot environment.  That works.
>
> But if the machine should some day die and I can only find/buy a
> UEFI-only machine to restore it to, how do I do that?

Partitioning and restoring should work pretty much the same way, but in
addition you have to replace the bootloader, i.e. install grub-efi-amd64
instead of grub-pc, before you can boot the restored system.

> And are there
> any precautions I should take in advance (on the BIOS system, before
> creating backups that may be needed on a future UEFI system) in order
> to make it easier to restore to a UEFI machine?

I don't think so, the only important thing is that on the restore
machine you need to set up an EFI system partition[1] from which the
system boots.  It has to be formatted as FAT32 and mounted under
/boot/efi when you install grub-efi-amd64.

Cheers,
   Sven

Re: No GRUB with brand-new GPU

[Sven Joachim]

On 2020-12-26 18:44 -0500, The Wanderer wrote:

> On 2020-12-26 at 18:28, Felix Miata wrote:
>
>> I suggest a good place to start would be to goto /etc/default/grub
>> and switch from whichever mode is employed to the other, either plain
>> text to graphical, or vice versa, then regenerate grub.cfg and try
>> booting.
>
> That's a good suggestion, except I don't see any way to do that in the
> /etc/default/grub I have.
>
> The closest thing I see is
>
> # Uncomment to disable graphical terminal (grub-pc only)
> #GRUB_TERMINAL=console
>
> but that says it's for grub-pc only, i.e. the "legacy" version of grub,
> whereas I'm running grub2.

No, grub-pc is not the legacy version of grub, it is grub2 for legacy
computers without EFI.  The version of grub2 for modern UEFI systems is
grub-efi-amd64 which uses the framebuffer set up by the system's
firmware (hence, no traditional text mode).

Cheers,
   Sven

Re: The .xsession-errors problem

[Sven Joachim]

On 2020-10-26 18:35 +0200, Teemu Likonen wrote:

> It seems that ~/.xsession-errors file can still grow to infinity in
> size. Sometimes it grows really fast. This is nothing new: we have all
> seen it and talked about it. What do you do to maintain this file?
>
>   - Do you just delete it when you happen to notice it's too big?
>
>   - Do you configure some rotating system, perhaps with logrotate(8)?
> (Why doesn't Debian have this automatically?)
>
>   - Do you add it to your backup system's ignore list so that a
> potentially big file doesn't fill your backups?

I simply truncate it in my ~/.xsession file, since I don't care what's
in it once my session has ended.  Maybe this has some side effects when
starting multiple sessions, but I rarely do that and so far did not have
any problems.

>   - What do Debian documentation and faq lists teach about maintaining
> this potentially huge file?
>
>   - Why is it normal that in Debian (and GNU/Linux) you need to manually
> delete a hidden file to keep it from filling your hard disks?
>
> Note that I'm not necessarily looking for help but different views are
> welcome. I'm mostly interested in the phenomenon that there still is
> this well-known indefinitely growing file and seemingly no automatic
> rotation.

If you have a good idea how to fix that, please send it to bug
#287876[1] or one of its siblings.

Cheers,
   Sven


1. https://bugs.debian.org/287876

Re: Can't scroll back with Shift+PageUp in TTY

[Sven Joachim]

On 2020-10-24 13:40 +0200, Yvan Masson wrote:

> I just discover that Shift+PageUp and Shift+PageDown in TTY does not
> work on my Debian computers (1 running testing, one running stable,
> and 2 VMs running stable). It works on another VM running CentOS
> 8. And it works on my testing box when inside gnome-terminal.
>
> I could not find anything relevant on the net. Any idea how to get
> Shift+PageUp working again in TTY?

The feature has been removed due to security concerns[1].
It is unclear when (if?) it will come back.

Cheers,
   Sven


¹ https://security-tracker.debian.org/tracker/CVE-2020-14390

Re: libXp -- was there a better way?

[Sven Joachim]

On 2020-10-23 23:53 +0100, Mark Fletcher wrote:

> I occasionally use a specialist piece of software called xephem, which
> is old but doesn't to my knowledge have a newer replacement that's 1% as
> good. I tried to fire it up the other night for the first time since I
> installed buster. It refused to run because libXp.so.6 was missing. A
> bit of googling showed me that this is an old, deprecated library for
> printing in X.

That is true, it is a client library for a server (xprint) which had
been removed from Debian a few years earlier.

> I couldn't run the execuable of xephem I had previously
> built and I couldn't build the latest version because of its expectation
> to find the include  which is provided by the same
> library... ("latest" version isn't very new...)

From 2015, I guess the xephem authors have stopped its development.

> libXp.so.6 was last in Debian in Jessie, in package libxp6. Looking at
> the dependencies of libxp6 in Jessie, they were all installed on my
> system (obviously newer versions) except multiarch-support. So I
> downloaded the package from Jessie and used gdebi to install it on my
> system. This worked, and now xephem runs.
>
> To avoid trouble when I next upgrade I propose from here to create a
> dummy package for xephem using equivs to register the dependency on
> libxp6, and then mark libxp6 as automatically installed, so the package
> manager in a future upgrade can figure out it can remove xephem's dummy
> package and thereby get rid of libxp6 if it causes conflicts.

Sounds like a good plan to me.

> I have no
> idea if xephem will now be able to print, but I don't care as I don't
> want to use its printing functionality, I only did any of this because
> the missing library was preventing it from starting.

I guess it won't be able to print because of the missing server, but
maybe I am wrong here.

> My question is, was there a better way to resolve this dependency? And,
> in a Buster system which has been installed not upgraded, am I in danger
> of creating trouble for myself by having this old package on my system?

Quite unlikely, the only problem is the missing security support for
this library and the software using it (i.e., xephem).

Cheers,
   Sven

Re: SSD and HDD

[Sven Joachim]

On 2020-10-11 13:48 -0400, Jim Popovitch wrote:

> On Sun, 2020-10-11 at 19:47 +0200, Sven Joachim wrote:
>> "Percentage Used Endurance Indicator"
>
> Where do you see that?

For a SATA SSD:

# smartctl -l devstat $SSD

Cheers,
   Sven

Re: SSD and HDD

[Sven Joachim]

On 2020-10-11 17:45 +0100, mick crane wrote:

> Bearing in mind I rarely do installs and when I do usually let the
> installer do its thing.
> Got a PC that has SSD and a HDD. I see that you are supposed to avoid
> writes to SSD for longevity.

No, you are not.  I put an SSD into my desktop computer almost four
years ago, and its "Percentage Used Endurance Indicator" is currently at
12%, so it probably will be good for another twenty years or longer.

> Is it a matter of putting entries in fstab for /swap /var /home to
> suitably formatted partitions on HDD ?
> Or is there more to  it ?

My advice would be to only use the HDD for big data files where speed is
no concern,  e.g. your music/picture/video collection and such.
Everything else can go onto the SSD.

Cheers,
   Sven

Re: Mounting /dev/shm noexec

[Sven Joachim]

On 2020-10-02 22:35 +0300, Valter Jaakkola wrote:

> I an effort to increase security one of the things I'm trying to do is to have
> no world-writable directories where anything (well, binaries at least) could 
> be
> executed from. I use Debian Linux 10 amd64. (I'm a home user.)
>
> When I run `sudo find / -type d -perm -2` and remove from the listing the
> directories which are on noexec-mounted partitions, just /dev/shm and
> /dev/mqueue are left (and some docker directories in /var/lib/docker/overlay2,
> to which I can't write as a normal user).

There are a few other directories where users can typically write to
and execute binaries, though: /tmp, /var/tmp, $HOME, /run/user/$USER.

> The problem for me is mounting /dev/shm noexec -- I can't find where to do 
> it. I
> couldn't find a lot of information about this on the internet. The few sources
> mostly only suggest adding it to fstab, but I'm hesitant about this as it 
> isn't
> there already. I'd rather change the settings at the source, where it's 
> mounted
> in the first place.
>
> I also ran `grep -rwlsI -e shm` through /etc and /usr/share but didn't find
> anything that would've looked like the mounting of /dev/shm, or where 
> parameters
> for it could have been changed.
>
> So where can I change the mounting parameters of /dev/shm, or otherwise 
> arrange
> it so that /dev/shm is noexec already at/after boot?

In /etc/fstab. :-)

> (Out of curiosity, where is /dev/shm mounted from?)

It's mounted by systemd, the list of core systems it mounts is hardcoded
in the source[1].  Filesystems that appear in /etc/fstab are remounted
with the options given there (for the gory details see
systemd-fstab-generator(8) and systemd.mount(5)).

Cheers,
   Sven


1. 
https://sources.debian.org/src/systemd/241-7~deb10u4/src/core/mount-setup.c/#L61

Re: Question on 'dpkg --get-selections'

[Sven Joachim]

On 2020-09-11 22:03 -0700, Marc Shapiro wrote:

> Is there any option to have 'dpkg --get-selections' NOT include
> automatically installed packages?

No, dpkg has no notion of automatically installed packages, that is an
apt concept.

> Otherwise, all packages show as manually installed, including those
> that would otherwise have been automatically installed.

You can obtain a list of automatically installed packages with
apt-mark(1):

$ apt-mark showauto > automatically-installed-packages

Then, on the replicated system where you presumably had used
"dpkg --set-selections" to install the same set of packages:

# apt-mark auto $(cat automatically-installed-packages)

HTH,
Sven

Re: unable to login

[Sven Joachim]

On 2020-09-03 15:20 +0100, anthony gennard wrote:

> Greg Wooledge on 1st September very kindly gave me a detailed reply to my
> cry for help.
>
> I tried to follow his reply but I have lost all my memory following a
> stroke.
> So it took me some time to do so as I had to relearn the basic file
> commands. I got as far as the following:-
>
> " - bash: home/john: Is a directory
>   john@john-PC:/$ ls -ld home/john /home/john/.ICEauthority
>   dr-xr-xr-x 26 john john 4096 Aug 31 11:46 home/john
>   -rw---1 john john 9016 Aug 31 11:21 home/john/.ICEauthority "
>
> This takes me no further forward.
>
> What puzzles me is that the login worked at least 30 times without the
> error message and I cannot understand why it stopped.

Your home directory is not writable by you, so no new files can be created
there.  Run "chmod 755 /home/john" to fix that.

Cheers,
   Sven

Re: No irq handler for vector

[Sven Joachim]

On 2020-08-27 19:14 +0100, Brad Rogers wrote:

> On Thu, 27 Aug 2020 19:53:01 +0200
> john doe  wrote:
>
> Hello john,
>
>>What should I do to correct whatever they are telling me?
>
> Seems to be being worked on ATM.

I don't think that is actually the case, the activity in the archlinux
forum notwithstanding.

> See https://bbs.archlinux.org/viewtopic.php?id=256227 for some insight.

There are also bugreports in Fedora and Debian:

https://bugzilla.redhat.com/show_bug.cgi?id=1551605
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912085

> See
> https://unix.stackexchange.com/questions/535199/how-to-deduce-the-nature-of-an-interrupt-from-its-number
> for some quite detailed discussion about the issue.
>
> Short version - you can't do anything.  _Yet_.

I have been seeing these messages for several years on my laptop.  The
good news is that it works fine despite them, but the emergency level
meant that the messages also appeared on the current terminal after
resume from suspend.  I installed an rsyslog filter to stop that.

Cheers,
   Sven

Re: /dev/fd is missing, how comes?

[Sven Joachim]

On 2020-08-08 07:39 +0200, Harald Dunkel wrote:

> Hi folks,
>
> after booting my desktop PC this morning it seems that /dev/fd is
> missing. This breaks dkms.
>
> How comes? Which tool/package/service was supposed to create the
> symlink for /dev/fd?

It used to be created by udev:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967546

Cheers,
   Sven

Re: aptitude problem with control file (in stretch)

[Sven Joachim]

On 2020-08-07 14:08 +0200, Harald Dunkel wrote:

> On 8/5/20 6:29 PM, Sven Joachim wrote:
>> I am not sure I understand what you actually want to do, though.
>>
>
> I am maintaining a set of meta packages, referencing the packages
> to install on my hosts. To avoid having separate meta packages for
> each new Debian version I have to use conditional dependencies, like
>
> Package: sample-setup
> Architecture: all
> Depends: ${misc:Depends}
>   , sample-setup-chroot
>   :
>   , nvme-cli | base-files ( << 9 )
>   :
>
> Meaning nvme-cli has to be installed for Debian 9 or newer.
>
>
> This package
>
> Package: sample-lxc
> Architecture: all
> Depends: ${misc:Depends}
>   , cgmanager | systemd
>   , debootstrap
>   , lxc
>   , lxc-templates | lxc ( << 3 )
> :
>
> did not work as expected (IMHO), apparently because (1:2 << 3) = false.

That's what I meant to tell you in my first reply, sorry if it was
unclear.  I think changing the dependency to
"lxc-templates | lxc ( << 1:3 )" is what you want here.

See deb-version(7) for how dpkg (and apt) compares versions.

Cheers,
   Sven

Re: Atheros wifi problem

[Sven Joachim]

On 2020-08-05 18:01 +0100, Hilary Snaden wrote:

> Following the recent discussion about Atheros AR9271 wifi no longer working.
>
> After the most recent kernel update to 5.7.10-1 (2020-07-26), my
> AR9271 wifi dongle is recognised again, but there is now a worse
> problem: if I use the dongle, the box gradually freezes over the
> course of around 5 to 20 minutes, starting with network manager. If I
> unplug the dongle before the freeze spreads, the box unfreezes, else
> it requires a power cycle to revive it.
>
> The internal wifi still works normally.
>
> The only obvious error message relates to iwl-debug-yoyo.bin not being
> found.
>
> Can anyone confirm that ath9k_htc was fixed from kernel 5.7.9? The
> kernel mailing list is ambiguous about whether the fix would be in
> 5.7.11 or whether it appeared in 5.7.9.

I don't know anything about ath9k_htc, but the latest fixes for it
appeared in 5.7.11 ("ath9k: Fix general protection fault in
ath9k_hif_usb_rx_cb"[1] and "ath9k: Fix regression with Atheros
9271"[2]), so they are not in Debian yet.

Cheers,
   Sven


1. 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.7.y=b43063ff55858f73cbd44fc4496b3489c8bdfba4
2. 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.7.y=dcb80ffe3825fb551a293491424695198b2e397d

Re: aptitude problem with control file (in stretch)

[Sven Joachim]

On 2020-08-05 12:33 +0200, Harald Dunkel wrote:

> On 8/5/20 11:03 AM, Sven Joachim wrote:
>> I am surprised to read that, considering that your installed lxc
>> version
>> does not actually fulfill the dependency.  Note the epoch.
>> $ dpkg --compare-versions 1:2.0.11-1~xgo90+1 lt 3 || echo 'Got it!'
>> Got it!
>>
>
> Maintaining the sample-lxc package I have no influence upon
> other packages introducing new epoch numbers. Upstream moved
> the templates into a separate github repository for lxc
> version 3, so its unreasonable to consider Debian's epoch
> number for package dependencies in this case.
>
> How can I express this dependency upon lxc's upstream version
> number in my control file, ignoring the epoch number?

You don't, at least as long as there is only an lxc package _with_ the
epoch available, like the one you have currently installed.

I am not sure I understand what you actually want to do, though.

Cheers,
   Sven

Re: aptitude problem with control file (in stretch)

[Sven Joachim]

On 2020-08-05 09:42 +0200, Harald Dunkel wrote:

> I've got a problem with upgrading a private package in Stretch. The control
> file says:
>
>   Package: sample-lxc
>   Architecture: all
>   Depends: ${misc:Depends}
>   , cgmanager | systemd
>   , debootstrap
>   , lxc
>   , lxc-templates | lxc ( << 3 )
>   Recommends: cgroup-tools
>   , apparmor
>   , uidmap
>   , yum
>   Conflicts: lxcfs
>   Description: LXC framework
>This package provides LXC for our environment.
>
> lxc-templates is available only for lxc >= 3 (Buster or Bullseye), and
> then its a must-have in my environment.
>
> Trying to install this package on Stretch aptitude complains about a
> missing lxc-templates package, even though the most recent lxc version
> 1:2.0.11-1~xgo90+1 is installed.
>
> apt and apt-get are fine, AFAICS.

I am surprised to read that, considering that your installed lxc version
does not actually fulfill the dependency.  Note the epoch.

$ dpkg --compare-versions 1:2.0.11-1~xgo90+1 lt 3 || echo 'Got it!'
Got it!

Cheers,
   Sven

Re: apt update; apt upgrade, from local mirror not working

[Sven Joachim]

On 2020-08-01 22:49 +1000, Zenaan Harkness wrote:

> Take 2:
> Why does the fact my local mirror only has one of my 2 enabled
> architectures, cause apt upgrade to stop working altogether?

Because apt expects all enabled architectures to be actually present by
default, which looks like a reasonable assumption to me.

> Does fixing this mean I requile a local mirror of both my architectures?

Not necessarily, you can also use different mirrors and use the
[ arch=… ] syntax to fetch only the desired architecture(s) from
each.  See sources.list(5).

Cheers,
   Sven

Re: grub update and reinstallation

[Sven Joachim]

On 2020-08-01 12:23 +0100, Graham Seaman wrote:

> On 01/08/2020 07:50, Tom Dial wrote:
>> I have a laptop that became unbootable because
>> the initial loader failed to find a symbol (grub_calloc) and balked.
>> Like the one mentioned here, it uses legacy boot. One explanation has it
>> that this happened because the MBR and the remainder of grub were not
>> both updated or were updated with slightly incompatible data.
>>
>> One fix appears to be to reinstall grub using a rescue CD or another
>> system. That worked for me.
>
> My home server sits in my loft managing comms with the outside world;
> yesterday it overheated (not a surprise) and went down.

You should probably open the machine up and clean it. :-)

> On reboot
> after cooling it came back up with the grub_calloc problem, so like
> Tom I reinstalled after which it appears to be OK.
>
> BUT because I have no idea why the original problem occurred, or why a
> reinstall fixed the problem, I have no idea if this is a permanent
> fix, or if I have a system which is liable to fail to reboot again in
> the future. Does anyone know? It's a very simple single drive system
> with legacy boot.

In this case the error is quite unlikely to occur, I have no idea why it
happened for you in the first place.

> I run it with security updates on auto, and check
> for other updates manually once a week or so. Should I change this
> pattern for a while while possible grub problems are sorted upstream?

I would recommend to run "dpkg-reconfigure grub-pc".  This should bring
up three dialogues, the last of which asks for the disk(s) to install grub
on.  On your system this is most likely /dev/sda.

Or get the device name from the debconf database:

readlink -f $(debconf-show grub-pc 2>/dev/null | grep grub-pc/install_devices: 
| cut -d ':' -f2)

Cheers,
   Sven

Re: apt update; apt upgrade, from local mirror not working

[Sven Joachim]

On 2020-08-01 17:35 +1000, Zenaan Harkness wrote:

> So I have a local sid+testing mirror I've been using for years, and just 
> updated it:
>
> nice /usr/bin/debmirror  --nocleanup --verbose   --progress  
> --allow-dist-rename--arch=amd64 
> --section=main,main/debian-installer,contrib,non-free   --dist=sid,testing
>   --host=ftp.iinet.net.au--method=http--root=pub/debian   
> --diff=none --rsync-extra=trace,doc,tools--exclude-deb-section=debug  
>--exclude='/Translation-.*\.bz2$' --include='/Translation-en.*\.bz2$'  
> /Library/Lpools/zen/p1-setups_misc/repos/debian/d00-sid+tst+src-64
>
>
> The only "recent" change is adding i386 arch a couple weeks back.

Seems you should use "--arch=amd64,i386" rather than "--arch=amd64"
then.

Cheers,
   Sven

Re: aptitude: a way to reinstall a package and all its dependents?

[Sven Joachim]

On 2020-07-31 15:10 +0200, local10 wrote:

> Am looking for a way to reinstall a package and all "subpackages" the
> package depends on. Normally I use aptitude to install packages.

Something like this should do the trick:

# aptitude reinstall mypackage '~i~Rmypackage'

See the "Search term reference" in the aptitude user manual[1].
I haven't found a way to that recursively.

Cheers,
   Sven


1. https://www.debian.org/doc/manuals/aptitude/ch02s04s05.en.html