Bug#1073205: docker-compose: new python3-requests dependency brokes docker-compose

[Philip Chung]

On Mon Jul 22 2024 10:59:51 GMT-0700 (Pacific Daylight Time), Philip 
Chung wrote:
Attached is a patch for compatibility with version 7 of the 
python-docker/docker-py library. It removes the SSL version handling and 
--skip-hostname-check option, which are no longer supported in docker-py 
since 7.0.0.


Philip Chung


The patch does not adjust the tests relating to TLS configuration.

Philip Chung

Bug#1073205: docker-compose: new python3-requests dependency brokes docker-compose

[Philip Chung]

Control: tags -1 + patch

On Wed, 3 Jul 2024 10:16:00 -0300 Ernesto Domato  wrote:


Yesterday, an update to version 7.1.0-1 of the same library broke
again the package that now when you try to run any command, it throws
this error:

Traceback (most recent call last):
  File "/usr/bin/docker-compose", line 33, in 
sys.exit(load_entry_point('docker-compose==1.29.2',
'console_scripts', 'docker-compose')())
 
^
  File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 81, in main
command_func()
  File "/usr/lib/python3/dist-packages/compose/cli/main.py", line 200,
in perform_command
project = project_from_options('.', options)
  ^^
  File "/usr/lib/python3/dist-packages/compose/cli/command.py", line
60, in project_from_options
return get_project(
   
  File "/usr/lib/python3/dist-packages/compose/cli/command.py", line
152, in get_project
client = get_client(
 ^^^
  File "/usr/lib/python3/dist-packages/compose/cli/docker_client.py",
line 41, in get_client
client = docker_client(
 ^^
  File "/usr/lib/python3/dist-packages/compose/cli/docker_client.py",
line 124, in docker_client
kwargs = kwargs_from_env(environment=environment, ssl_version=tls_version)
 ^
TypeError: kwargs_from_env() got an unexpected keyword argument 'ssl_version'

Reverting the library to 6.1.3-0.2 solves the problem,

Thanks




Attached is a patch for compatibility with version 7 of the 
python-docker/docker-py library. It removes the SSL version handling and 
--skip-hostname-check option, which are no longer supported in docker-py 
since 7.0.0.


Philip Chungdiff --git a/compose/cli/docker_client.py b/compose/cli/docker_client.py
index e4a0fea6..4c54567e 100644
--- a/compose/cli/docker_client.py
+++ b/compose/cli/docker_client.py
@@ -40,7 +40,7 @@ def load_context(name=None):
 def get_client(environment, verbose=False, version=None, context=None):
 client = docker_client(
 version=version, context=context,
-environment=environment, tls_version=get_tls_version(environment)
+environment=environment
 )
 if verbose:
 version_info = client.version().items()
@@ -52,23 +52,6 @@ def get_client(environment, verbose=False, version=None, context=None):
 return client
 
 
-def get_tls_version(environment):
-compose_tls_version = environment.get('COMPOSE_TLS_VERSION', None)
-if not compose_tls_version:
-return None
-
-tls_attr_name = "PROTOCOL_{}".format(compose_tls_version)
-if not hasattr(ssl, tls_attr_name):
-log.warning(
-'The "{}" protocol is unavailable. You may need to update your '
-'version of Python or OpenSSL. Falling back to TLSv1 (default).'
-.format(compose_tls_version)
-)
-return None
-
-return getattr(ssl, tls_attr_name)
-
-
 def tls_config_from_options(options, environment=None):
 environment = environment or Environment()
 cert_path = environment.get('DOCKER_CERT_PATH') or None
@@ -82,7 +65,6 @@ def tls_config_from_options(options, environment=None):
 # see https://github.com/docker/compose/issues/5632
 verify = options.get('--tlsverify') or environment.get_boolean('DOCKER_TLS_VERIFY')
 
-skip_hostname_check = options.get('--skip-hostname-check', False)
 if cert_path is not None and not any((ca_cert, cert, key)):
 # FIXME: Modify TLSConfig to take a cert_path argument and do this internally
 cert = os.path.join(cert_path, 'cert.pem')
@@ -95,9 +77,7 @@ def tls_config_from_options(options, environment=None):
 cert = os.path.join(default_cert_path(), 'cert.pem')
 key = os.path.join(default_cert_path(), 'key.pem')
 
-tls_version = get_tls_version(environment)
-
-advanced_opts = any([ca_cert, cert, key, verify, tls_version])
+advanced_opts = any([ca_cert, cert, key, verify])
 
 if tls is True and not advanced_opts:
 return True
@@ -108,20 +88,18 @@ def tls_config_from_options(options, environment=None):
 
 return TLSConfig(
 client_cert=client_cert, verify=verify, ca_cert=ca_cert,
-assert_hostname=False if skip_hostname_check else None,
-ssl_version=tls_version
 )
 
 return None
 
 
-def docker_client(environment, version=None, context=None, tls_version=None):
+def docker_client(environment, version=None, context=None):
 """
 Returns a docker-py client configured using environment variables
 according to the same logic as the official Docker client.
 """
 try:
-kwargs = kwargs_from_env(environment=environment, ssl_versi

Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl

[Philip Hands]

Tj  writes:

> Source: debian-installer
> Followup-For: Bug #1075713
> X-Debbugs-Cc: tj.iam...@proton.me
>
> I've done some further research via debian-installer repo, build logs,
> and inspecting fb-modules-*-amd64-di packages.

Thanks :-)

> Focusing on just 6.8.12-1 and 6.9.7-1 I cannot see any difference in the
> ISO builds. That is, for both:
>
>  * linux-image-*-amd64 does include drivers/gpu/drm/qxl/qxl.ko*
>  * fb-modules-*-amd64-di.udeb does not
>  * kernel-image-*-amd64-di does not
>  * d-i Makefile's DRM_MODULES has/does not list/copy qxl.ko
>
> This makes me wonder if the 20240628_0519 daily netinst really did have
> this module but as I cannot find a copy of the ISO I cannot check.

openQA keeps copies for a while (and that is what date-stamps them, as
the filenames are static[1]):

  
https://openqa.debian.net/tests/277189/asset/iso/20240628_0519-debian-testing-amd64-netinst.iso

> If it did not then something must have changed in the qemu/kvm side.

Looking at this again:
  https://openqa.debian.net/tests/278609#investigation
I realise that it's got a "Show more" thing in the
diff_packages_to_last_good which I'd not noticed earlier. :-/

I _had_ thought that it was just a few apt & autoconf tools that had
changed, but actually there's loads of things, including qemu.

Looking at the etckeeper log on the worker, I see that there was an
upgrade from qemu 1:7.2+dfsg-7+deb12u5 to 1:7.2+dfsg-7+deb12u at
2024-06-29 11:12:50, which is just after the last succesful run, so that
does point towards qemu being the problem.

This afternoon I may have time to check if I can demonstrate that this
is actually a regression in qemu, and will reasign the bug if so (I
don't mind at all if someone else does that test for me :-) )

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Bug#1075713: linux: D-I's X fails to start under kvm -vga qxl

[Philip Hands]

Package: linux
Version: 6.9.7-1
Severity: normal
User: debian...@lists.debian.org
Usertags: openqa

Hi,

It seems that qxl is no longer supported under kvm when running a recent
(6.9.7-1) kernel in debian-installer.

This was discovered during automated testing on openqa.debian.net.

Having since re-run a test of the daily netinst from 20240628_0519, that still
works, so this is not something that's being caused by changes in the test
infrastructure.

I've now switched the tests away from specifying `qxl` as kvm's -vga setting,
and that's now succeeding, which shows that the problem is probably not caused
by some change in D-I.

Diffing the list of installed udebs shows that almost all of the changes relate
to the kernel/modules version going from 6.8.12-1 to 6.9.7-1.

on #debian-x jcristau pointed this out in the Xorg.0.log diff:

jcristau | that points at a kernel change i think   
 │
jcristau | `-(II) FBDEV(0): hardware: EFI VGA (video memory: 1876kB)` suggests 
efifb was used, i think

I attach the diffs of the udeb package list, and the Xorg.0.log

To reproduce the problem, get a recent daily netinst from, e.g.:

  
https://get.debian.org/images/daily-builds/daily/20240703-3/amd64/iso-cd/debian-testing-amd64-netinst.iso
or
  
https://get.debian.org/images/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso

and boot it with:

  kvm -m 1G  -vga qxl -cdrom /path/to/debian-testing-amd64-netinst.iso

and then select the default (graphical) install -- it will fail to get to X,
instead producing something like:

  https://openqa.debian.net/tests/278593#step/_boot_to_debianinstaller/5

Cheers, Phil.
diff --git a/working_X.log b/broken_X.log
index 70498da..6c43c74 100644
--- a/working_X.log
+++ b/broken_X.log
@@ -1,7 +1,6 @@
-
 X.Org X Server 1.21.1.11
 X Protocol Version 11, Revision 0
-Current Operating System: Linux (none) 6.8.12-amd64 #1 SMP PREEMPT_DYNAMIC 
Debian 6.8.12-1 (2024-05-31) x86_64
+Current Operating System: Linux (none) 6.9.7-amd64 #1 SMP PREEMPT_DYNAMIC 
Debian 6.9.7-1 (2024-06-27) x86_64
 Kernel command line: BOOT_IMAGE=/install.amd/vmlinuz vga=788 --- quiet
 xorg-server 2:21.1.12-1 (https://www.debian.org/support) 
 Current version of pixman: 0.42.2
@@ -10,7 +9,7 @@ Current version of pixman: 0.42.2
 Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Fri Jun 28 05:18:06 2024
+(==) Log file: "/var/log/Xorg.0.log", Time: Sun Jun 30 04:50:40 2024
 (==) Using system config directory "/usr/share/X11/xorg.conf.d"
 (==) No Layout section.  Using the first Screen section.
 (==) No screen section available. Using defaults.
@@ -29,7 +28,7 @@ Markers: (--) probed, (**) from config file, (==) default 
setting,
 (==) ModulePath set to "/usr/lib/xorg/modules"
 (II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
-(II) Loader magic: 0x556081837b80
+(II) Loader magic: 0x558609ebdb80
 (II) Module ABI versions:
X.Org ANSI C Emulation: 0.4
X.Org Video Driver: 25.2
@@ -80,580 +79,19 @@ Markers: (--) probed, (**) from config file, (==) default 
setting,
 (II) Module fbdevhw: vendor="X.Org Foundation"
compiled for 1.21.1.11, module version = 0.0.2
ABI class: X.Org Video Driver, version 25.2
-(II) FBDEV(2): using default device
 (EE) Screen 0 deleted because of no matching config section.
 (II) UnloadModule: "modesetting"
 (EE) Screen 0 deleted because of no matching config section.
 (II) UnloadModule: "fbdev"
 (II) UnloadSubModule: "fbdevhw"
-(II) FBDEV(0): Creating default Display subsection in Screen section
-   "Default Screen Section" for depth/fbbpp 24/32
-(==) FBDEV(0): Depth 24, (==) framebuffer bpp 32
-(==) FBDEV(0): RGB weight 888
-(==) FBDEV(0): Default visual is TrueColor
-(II) FBDEV(0): hardware: EFI VGA (video memory: 1876kB)
-(DB) xf86MergeOutputClassOptions unsupported bus type 0
-(II) FBDEV(0): checking modes against framebuffer device...
-(II) FBDEV(0): checking modes against monitor...
-(II) FBDEV(0): Virtual size is 800x600 (pitch 800)
-(**) FBDEV(0):  Built-in mode "current": 48.0 MHz, 46.9 kHz, 75.1 Hz
-(II) FBDEV(0): Modeline "current"x0.0   48.00  800 832 928 1024  600 604 608 
624 -hsync -vsync -csync (46.9 kHz b)
-(==) FBDEV(0): DPI set to (96, 96)
-(II) Loading sub module "fb"
-(II) LoadModule: "fb"
-(II) Module "fb" already built-in
-(**) FBDEV(0): using shadow framebuffer
-(II) Loading sub module "shadow"
-(II) LoadModule: "shadow"
-(II) Loading /usr/lib/xorg/modules/libshadow.so
-(II) Module shadow: vendor="X.Org Foundation"
-   compiled for 1.21.1.11, module version = 1.1.0
-   ABI class: X.Org ANSI C Emulation, version 0.4
-(II) 

Bug#1073785: rough fix

[Philip Hands]

Hi,

This patch:

  
https://salsa.debian.org/philh/debootstrap/-/commit/b33d53bd2aad01c9ccf5b66b986ff06f472123cf

when built in this pipeline:

  https://salsa.debian.org/philh/debootstrap/-/pipelines/691006

results in this working test:

  https://openqa.debian.net/tests/273854

I'd imagine that there's more to be done if we want this to work nicely
for downstreams however.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Bug#1073785: debootstrap-udeb: removal of trixie --> sid link causes fatal error in D-I

[Philip Hands]

Package: debootstrap-udeb
Version: 1.0.135
Severity: serious
User: debian...@lists.debian.org
Usertags: openqa

While testing daily netinst debian-installer images with openQA, we see that
debootstrap fails:

  https://openqa.debian.net/tests/272866#step/install_base/1

  "The debootstrap program exited with an error (return value 1)"

looking in the syslog, one finds:

  debootstrap: E: NOSCRIPT
  debootsrtap: EA: /usr/share/debootstrap/scripts/trixie
  debootstrap: EF: No such script: %s

If I reinstate the trixie --> sid symlink, the installation can then proceed.

I presume that when removing the "redundant" links in commit 2d3eae91, there was
an intent that the scripting should default to "sid" when the required script is
found to be missing, but this seems not to have been done correctly.

It looks to me as if 73e1b5f9 simply fails to deal with the case where
distro-info is unavailable (debian-installer does not include it).

Cheers, Phil.

Bug#1072995: gnome-software: a method for disabling autostart should be documented, and perhaps made easier

[Philip Hands]

Package: gnome-software
Severity: wishlist

Some users do not actually benefit from gnome-software/packagekit, and
occasionally suffer as a result of it's presence.

A case in point is an elderly relative, who despite encouragement has never
found a reason to install a new package for themselves, so relies on me to do
upgrades, or suggest new packages.

However, occasionally they get bitten by what looks like #909804, where the
machine can become unresponsive immediately after boot or resume. Even without
that, if one is never going to use the functionality, the background downloads
are a waste of resources on both the local machine, and our mirror network.

That being the case, I think it might be useful to add something to the README
describing the best way to prevent gnome-software from autostarting.

An internet search turns up various suggestions (and reveals that I'm clearly
not alone in wanting a good answer to this question), the best of which seems to
be here:

  
https://www.reddit.com/r/gnome/comments/gn8rs4/how_to_disable_gnome_software_autostart/

=-=-=-=-
  All this can be done by pasting these lines into terminal:

mkdir -pv ~/.config/autostart && cp 
/etc/xdg/autostart/gnome-software-service.desktop ~/.config/autostart/
echo "X-GNOME-Autostart-enabled=false" >> 
~/.config/autostart/gnome-software-service.desktop
dconf write /org/gnome/desktop/search-providers/disabled 
"['org.gnome.Software.desktop']"

  If you want to also disable Gnome Software automatic updates:

dconf write /org/gnome/software/allow-updates false
dconf write /org/gnome/software/download-updates false

  These steps do not neuter Software completely - you can still use it to 
install/remove apps.
=-=-=-=-

I think preserving the ability to use gnome-software (as in this suggestion) is
quite useful for many users, so that should definitely be one of the options
offered.

I'm guessing that the alternative solution that I've seen (masking the
packagekit service) would not allow gnome-software to continue working. If I'm
wrong about that, that might instead be the right thing to suggest.

For people who are never going to want to install software via the GUI, it would
be easier if it were possible to do e.g. `apt remove gnome-software`. This
currently doesn't do what one wants, as the dependency from gnome-core to
gnome-software means that one ends up removing much of gnome along with
gnome-software.

Would it be possible to use a Recommends: there instead, to enable this?

Cheers, Phil.

Bug#1070755: akregator: also being seen during openQA tests

[Philip Hands]

Package: akregator
Version: 4:22.12.3-1+b2
Followup-For: Bug #1070755
User: debian...@lists.debian.org
Usertags: openqa

Hi,

It seems we're also getting the reported behaviour when testing under openqa.

Sadly one doesn't get to see anything when it happens:

  https://openqa.debian.net/tests/265985#step/akregator/7

but having jumped into one of those tests, and tried it again, I then got the
same "did not close" warning, as reported.

We are running this in the test as:

  QT_LOGGING_RULES="*=true" akregator

which will hopefully get you some logs to look at. I believe the resulting
output ends up here:

  https://openqa.debian.net/tests/265985/logfile?filename=akregator-journal.txt

HTH

Cheers, Phil.

Bug#1071227: busybox-udeb: provides binaries that are also provided by kmod-udeb (e.g. modprobe)

[Philip Hands]

Package: busybox-udeb
Severity: normal
User: debian-rele...@lists.debian.org

Hi,

I notice that busybox-udeb provides the following binaries in /sbin:

  depmod insmod lsmod modinfo modprobe rmmod

while kmod-udeb provides the same, except located in /usr/sbin.

It would be better if this were not the case, especially now that D-I is
/usr-merged, so one will presumably get to use whichever of those is unpacked
last.

This suggests to me that the versions from kmod-udeb should be used, and
busybox-udeb should be configured to no longer generate these binaries.

BTW I'm assuming that these binaries only make sense on Linux, so it's that it's
fine that non-linux builds will not have them (kmod-udeb being linux only).

Cheers, Phil.

Bug#1070795: xfsprogs-udeb: the udeb is empty (size 904 bytes) so does not contain mkfs.xfs

[Philip Hands]

Package: xfsprogs-udeb
Version: 6.7.0-2
Severity: grave
User: debian...@lists.debian.org
Usertags: openqa

Hi,

Recent openQA tests show that it is not currently possible to create an XFS
filesystem using the latest debian-installer:

  https://openqa.debian.net/tests/259699#step/install_base/13

Looking into this, I note that the 6.7.0-2 udeb is empty:

  $ ls -l xfsprogs-udeb_6.7.0-2_amd64.udeb
  -rw-r--r-- 1 phil phil 904 May  8 00:02 xfsprogs-udeb_6.7.0-2_amd64.udeb
  $ dpkg-deb -c xfsprogs-udeb_6.7.0-2_amd64.udeb
  drwxr-xr-x root/root 0 2024-05-07 22:53 ./

which explains why mkfs.xfs is not available in the installer at present.

Cheers, Phil.

Bug#832473: synaptic: Cannot change mark from "complete removal" to "removal"

[Philip Chung]

On Mon, 25 Jul 2016 13:56:58 -0700 Kyanos  wrote:

Package: synaptic
Version: 0.83+b1
Severity: minor

Dear Maintainer,

If I mark a package for complete removal, I cannot change the mark
directly to simple removal.

Steps to reproduce:

1. Select a package.

2. Mark the package for complete removal.[1]

3. Mark the package for removal.[1]

[1] This can be done by either right-clicking and selecting the
appropriate option, going to the Package menu and selecting the option,
or using a keyboard shortcut. Any of these will yield the same result.

Actual result:

The package is still marked for complete removal. There is still a
yellow cross on the package mark, and the summary that is shown after
clicking "Apply" lists the package under "To be completely removed
(including configuration files)".

Expected result:

The package should be marked for removal. There should be a red cross on
the package mark, and the summary that is shown after clicking "Apply"
should list the package under "To be removed"


I'm revisiting this old bug report of mine and I confirm that this still 
occurs in the latest version of Synaptic.


Upon further investigation, I believe this can actually be traced to APT 
itself, or more specifically libapt-pkg. Synaptic uses the pkgDepCache 
class from libapt-pkg to handle these states, and the 
pkgDepCache::MarkDelete method is called to mark a package for removal 
or complete removal.


In the implementation of that method (source file apt-pkg/depcache.cc), 
there is a particular check that suggests a deliberate design decision 
to disallow moving from purging (complete removal) to simple removal but 
allow moving in the other direction:



// Check that it is not already marked for delete
if ((P.Mode == ModeDelete || P.InstallVer == 0) && 
(Pkg.Purge() == true || rPurge == false))

   return true;


I've CC'ed the APT team on this e-mail to get their input. If there are 
good reasons for this decision then I am happy to have this bug closed 
as "won't fix." (I don't think there is a compelling reason for Synaptic 
to work around this design decision in APT.)


Kyanos

Bug#1069158: jack-mixer: Missing Depends on python3-gi, gir1.2-gtk-3.0, and python3-cairo

[Philip Chung]

Package: jack-mixer
Version: 17-2+b2
Severity: serious
Justification: Policy 3.5
X-Debbugs-Cc: philipchung1...@yahoo.com

Dear Maintainer,

The jack_mixer binary fails to start if these packages are not installed.

I've reported this against the version currently in bookworm (stable), 
but I believe it applies to testing and unstable as well.


Without python3-gi, the following trace appears:

Traceback (most recent call last):
  File "/usr/bin/jack_mixer", line 5, in 
from jack_mixer.app import main
  File "/usr/lib/python3/dist-packages/jack_mixer/app.py", line 21, in 
import gi
ModuleNotFoundError: No module named 'gi'


Without gir1.2-gtk-3.0, the trace is:

Traceback (most recent call last):
  File "/usr/bin/jack_mixer", line 5, in 
from jack_mixer.app import main
  File "/usr/lib/python3/dist-packages/jack_mixer/app.py", line 23, in 
gi.require_version("Gtk", "3.0")
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 126, in 
require_version
raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Gtk not available

Without python3-cairo, the trace is:

Traceback (most recent call last):
  File "/usr/bin/jack_mixer", line 5, in 
from jack_mixer.app import main
  File "/usr/lib/python3/dist-packages/jack_mixer/app.py", line 30, in 
from .channel import InputChannel, NewInputChannelDialog, 
NewOutputChannelDialog, OutputChannel
  File "/usr/lib/python3/dist-packages/jack_mixer/channel.py", line 27, in 

from . import meter
  File "/usr/lib/python3/dist-packages/jack_mixer/meter.py", line 20, in 

import cairo
ModuleNotFoundError: No module named 'cairo'


(See also bug #995784 about adding python3-cairo as a Recommends for 
python3-gi)


Philip Chung

-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages jack-mixer depends on:
ii  jackd21.9.21~dfsg-3
ii  libc6 2.36-9+deb12u4
ii  libglib2.0-0  2.74.6-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3
ii  python3   3.11.2-1+b1

jack-mixer recommends no packages.

jack-mixer suggests no packages.

-- no debconf information

Bug#1065951: patch applied as MR!6

[Philip Hands]

Hi,

Just in case it helps, I've applied Michael's patch, and opened an MR on salsa:

  https://salsa.debian.org/virtualsquare-team/vde2/-/merge_requests/6

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Bug#1067516: util-linux: sulogin should not render system inaccessable in single-user/emergency mode

[Philip Hands]

Package: util-linux
Severity: normal

The D-I team are just about to reword the root password prompt in a way that
will likely lead to more people taking the chance to lock root and rely upon
sudo from the initial user. This is something that's already possible, so this
wording change is at most going to increase the popularity of this option.

At present, this results in sulogin becoming useless (unless one reconfigures
it), because it prompts the user for a password that does not exist.

This situation prompted this MR against user-setup (in D-I):

  https://salsa.debian.org/installer-team/user-setup/-/merge_requests/6

however it occurs to me that even if we adopt this, it does nothing to address
existing installs.

BTW That MR offers to configure things so that a locked root account will cause
sulogin to fail open, dropping the user into a root shell without asking for a
password.

While thinking about this, it occurs to me that one might be able to add an
option to sudo (-g perhaps) that would allow one to specify a group that should
be treated as a proxy for root when root's password is locked. Then, if that
option were specified, the users in the specified group ('sudo' on Debian) could
be allowed to specify their password instead, and if the password were correct,
be only then given root on the system. I guess one could either just check
against all group members for a match, or add a prompt for the username too.

This bug is therefore in two parts:

   1) ask users how they want this configured, if they have a locked root
  account, and have not been asked about it yet.

   2) implement the mentioned -g option, or come up with some other way of
  enabling the user to login during a single/emergency boot, without simply
  dropping the user straight into a root shell.

Cheers, Phil.

Bug#1051139: fix doas for sxmo

[Philip J Freeman]

I'm working on a fix for this bug here:

https://salsa.debian.org/DebianOnMobile-team/sxmo-utils/-/merge_requests/2

I'm not sure I like installing Sxmo's doas.conf as /etc/doas.conf.
Looking into alternatives, but it seems that Debian's doas doesn't
support a doas.d/ directory, as pointed out by Jochen Sprickerhof.

This patch (as submitted in the MR on salsa) is currently working for me
on my pinephonepro.

Bug#1064617: update password selection advice

[Philip Hands]

Holger Wansing  writes:

> Apparently we have reached something like a consensus on this topic, 
> should we merge this then?
>
> <https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7>
>
> Any objections?

None from me.

The only reason I've not done it already was that I wanted to check that
the wording still works if we were to merge MR !6 [1] or something like it.

However the current t64 transition bugs stopped me from building a
mini-ISO, and I've been busy since noticing that, so didn't have time to
work out how to work round those bugs.

That's not a reason to delay this MR though.

Cheers, Phil.

[1] https://salsa.debian.org/installer-team/user-setup/-/merge_requests/6



>
>
> Holger
>
>
> -- 
> Sent from /e/ OS on Fairphone3
>

-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Justin B Rye  writes:

> Philip Hands wrote:
>>> Maybe instead of saying "use the system's initial user account to
>>> become root" it should say "allow the system's initial user account
>>> to gain administrative privileges"?  I'm not sure.  Oh, and we might
>>> even want to mention the word "superuser", or then again we might not.
>> 
>> I think Diederik's suggestion of using 'root' for the account and
>> 'super-user' for the privileges might be the way to go.
>
> Looking at what I end up with after another couple of rounds of
> fiddling with it I'm not sure if it's doing quite what you asked for,
> but you still might want it so here it is:

Thanks for that.

> -   Some account needs to have system administrative privileges. The
> -   password/passphrase for that account should be something that
> -   cannot be guessed.
> +   Some account needs to be available with administrative super-user
> +   privileges. The password/passphrase for that account should be
> +   something that cannot be guessed.
> .
> To allow direct password-based access via the 'root' account, you
> can set the password/passphrase for that account here.
> .
> -   Alternatively, you can lock root's password
> +   Alternatively, you can lock the root account's password
> by leaving this setting empty, and
> instead use the system's initial user account
> (which will be set up in the next step)
> -   to become root. This will be enabled for you
> -   by adding that user to the 'sudo' group.
> +   to gain administrative privileges. This will be enabled for you by
> +   adding that initial user to the 'sudo' group.
> .
> Note: what you type here will be hidden (unless you select to show it).

That can be seen here:

  
https://salsa.debian.org/philh/user-setup/-/commit/a684977100e6746725372f8294f271f890c50430
&
  https://openqa.debian.net/tests/240580#step/passwords/1

I think I prefer the previous version better for some reason.

IMO Having the 'password/passphrase' throughout makes it awkward to
read, and actually we've got one place where it still just says
password, and fixing that would make it slightly worse IMO.

How about dropping the passphrase stuff?

  
https://salsa.debian.org/philh/user-setup/-/commit/7c8dd1bd9d5c8596e7b8f82a19a075e0a5572ed7
&
  https://openqa.debian.net/tests/240582#step/passwords/1

which I think is more readable (and is probably fine now that we've
dropped the stuff about password selection which could be read as
suggesting that a password is expected to be a single word).

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#819273: A licence file has finally been added to the RobotoMono github repo!

[Philip Armstrong]

A licence file has finally been added to the Roboto Mono github repo!

It’s now officially Apache-2.0 licenced:

  https://github.com/googlefonts/RobotoMono/blob/main/LICENSE.txt

If someone is willing to do the work of adding Roboto-Mono to the 
fonts-roboto package that would be great :)


cheers, Phil

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Justin B Rye  writes:

...
> Post-coffee (also fixing that wobbly indent):
>
>Some account needs to have system administrative privileges. The
>password/passphrase for that account should be something that
>cannot be guessed.
>.
>To allow direct password-based access via the 'root' account, you
>can set the password/passphrase for that account here.
>.
>Alternatively, you can lock root's password
>by leaving this setting empty, and
>instead use the system's initial user account
>(which will be set up in the next step)
>to become root. This will be enabled for you
>by adding that user to the 'sudo' group.
>.
>Note: what you type here will be hidden (unless you select to show it).

I like that version better than mine, so commited it[1], and re-ran the
test to give a screenshot:

  https://openqa.debian.net/tests/239766#step/passwords/1

> Maybe instead of saying "use the system's initial user account to
> become root" it should say "allow the system's initial user account
> to gain administrative privileges"?  I'm not sure.  Oh, and we might
> even want to mention the word "superuser", or then again we might not.

I think Diederik's suggestion of using 'root' for the account and
'super-user' for the privileges might be the way to go.

Cheers, Phil.

[1] 
https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7/diffs?commit_id=2668d06de4f2de4735404a0671ecfb33f7bbd159
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Justin B Rye  writes:

> Philip Hands wrote:
>> Justin B Rye  writes:
>>> Philip Hands wrote:
>>>> Justin B Rye  writes:> ...
>>>> The reason behind that structure was supposed to be that one definitely
>>>> needs _a_ password, but not necessarily a root password, so the password
>>>> advice applies to whichever password you'll decide to grant root access
>>>> to, which might not be set here.
>>>
>>> This template is specifically about the "Root password/passphrase";
>> 
>> Well, sort-of, except that the user's response (whether to leave this
>> blank or not) modifies what happens with the user account's permissions,
>> so it's also about explaining the way that logic works in the installer
>> and what that will do to the target system.
>>
>>> probably I should have quoted the patch I was looking at, which starts
>>> with "One needs a password/passphrase that grants access to the 'root'
>>> (system administrative) account" but goes on to say "Alternatively,
>>> you can lock root's password by leaving this setting empty".
>> 
>> I'm intimately familiar with the patches you're reading, so I feel like
>> this comment suggests that we may be talking past one another somehow.
>
> Yes, this is a common problem: you're so familiar with what we need
> it to say that you aren't noticing what the text currently does say.
> https://salsa.debian.org/installer-team/user-setup/-/commit/77c1517fade367bc465da2a5908c5ac47dd8bba7
>
>   Template: passwd/root-password
>   Type: password
>   # :sl1:
>   _Description: Root password/passphrase:
>One needs a password/passphrase that grants
>access to the 'root' (system administrative) account.
>Be aware that a malicious or unqualified user
>that obtains root access can have disastrous results,
>so you should choose a password/passphrase that cannot be guessed.
>It should not be a word found in dictionaries,
>or something that could be easily associated with you.
>
> (Summary: You DO need a root password.)

No, as I said, what that's trying to say is that there needs to exist a
password that one way or the other will let one get access to the root
account (since otherwise one is not going to be able to admin the
machine), but that is not neccesarily the same thing as a "root
password", because the password being refered to might well be the
initial user's password, as long as they end up in the sudo group.

If it comes across as meaning that there needs to be a "root password",
then it's not succeeding in expressing the nuance of the situation
correctly, and we probably need to fix that (assuming that we can come
up with a better wording that still fits in the space available).

>.
>To allow direct password-based access to root,
>you should set the 'root' password/passphrase here.
>.
>Alternatively, you can lock root's password
>by leaving this setting empty, and
>instead use the system's initial user account
>(which will be set up in the next step)
>to become root. This will be enabled for you
>by adding that user to the 'sudo' group.
>.
>Note: what you type here will be hidden (unless you select to show it).
>
> (Summary: You DON'T need a root password.)
>
> Suggested rewrite (short version):
>
>  _Description: Root password/passphrase:
>   To allow direct password/passphrase-based access to the 'root'
>   (system administrative) account you can set it up here.
>   To protect your system you should not use one that can be guessed.
>   .
>   Alternatively, you can lock root's password
>by leaving this setting empty, and
>instead use the system's initial user account
>(which will be set up in the next step)
>to become root. This will be enabled for you
>by adding that user to the 'sudo' group.
>.
>Note: what you type here will be hidden (unless you select to show it).

This is certainly better than good enough, so I'd be fine with this too.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Justin B Rye  writes:

> Philip Hands wrote:
>> Justin B Rye  writes:
...
>> 
>> The reason behind that structure was supposed to be that one definitely
>> needs _a_ password, but not necessarily a root password, so the password
>> advice applies to whichever password you'll decide to grant root access
>> to, which might not be set here.
>
> This template is specifically about the "Root password/passphrase";

Well, sort-of, except that the user's response (whether to leave this
blank or not) modifies what happens with the user account's permissions,
so it's also about explaining the way that logic works in the installer
and what that will do to the target system.

> probably I should have quoted the patch I was looking at, which starts
> with "One needs a password/passphrase that grants access to the 'root'
> (system administrative) account" but goes on to say "Alternatively,
> you can lock root's password by leaving this setting empty".

I'm intimately familiar with the patches you're reading, so I feel like
this comment suggests that we may be talking past one another somehow.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Justin B Rye  writes:

> Holger Wansing wrote:
>> @d-l10n-english: hey guys, we would like to get a proposal reviewed, 
>> which aims to improve the root/user password screens in the installer.
>> 
>> Please find the related merge request at
>> <https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7>
>
> It needs a small amount of rephrasing, but the most important problem
> is that it starts by saying you need to set a password and then goes
> on to suggest that you might not need to set a password.  Maybe that
> can be fixed by rearranging things slightly...
>
>  Template: passwd/root-password
>  Type: password
>  # :sl1:
>  _Description: Root password/passphrase:
>   To allow direct password/passphrase-based access to the 'root'
>   (system administrative) account you can set it up here.
>   The results can be disastrous if a malicious or incompetent user
>   obtains root access, so you should not set one that can be guessed,
>   found in dictionaries, or easily associated with you.
>   .
>   Alternatively, you can lock root's password
>   by leaving this setting empty, and
>   instead use the system's initial user account
>   (which will be set up in the next step)
>   to become root. This will be enabled for you
>   by adding that user to the 'sudo' group.
>   .
>   Note: what you type here will be hidden (unless you select to show it).
>
> Does this still feel like the same advice?

The reason behind that structure was supposed to be that one definitely
needs _a_ password, but not necessarily a root password, so the password
advice applies to whichever password you'll decide to grant root access
to, which might not be set here.

I'm OK with the way you've phrased it, although my personal preference
would be to simply drop the "disastrous" sentence if we use this
version, because I think it breaks the straightforward flow of the text
laying out the choice we're trying to get the user to make between the
two available options. (I also rather doubt that anything we say at this
point in the install will have the slightest influence on people's
choice of password).

> Otherwise the only thing I see is:
>
>  Template: passwd/user-password
>  Type: password
>  # :sl1:
>  _Description: Choose a password/passphrase for the new user:
>   Make sure to select a strong password/passphrase, that cannot be guessed.
>
> No comma needed there.

Well done -- I kept noticing that, and somehow didn't get round to
fixing it. I've now deleted it, so thanks for pointing it out again. :-)

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Cyril Brulebois  writes:

> Philip Hands  (2024-03-05):
>> Cool, in that case I'll fix those two things and then use the result
>> for the MR[1], and if the openQA test runs look OK, will merge that.
>
> Only skimmed over it, but that looks sensible, thanks all.
>
> Is it worth getting d-l-english involved in a final review before
> getting that translated?  Contrary to a lot of not-so-critical l10n
> material, that particular screen is crucial, and I'd hate it if we
> wasted translator efforts due to a missed typo or obvious improvement.

I'm happy with doing that, and we might as well get it right given that
it's been ~12 years since the first bug, so a few more days makes no
odds.

I'm pretty sympathetic with the idea of simply dropping the password
advice (as just mentioned by Diederik) but it seems that Holger prefers
to keep it in -- either is fine with me.

BTW I don't know much about how the translation side of things works,
but given that there are many ways of getting the fine detail of this to
be incorrect in various ways, is there a standard method for adding
hints for translators, and should that be done?

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Holger Wansing  writes:

> Hi,
>
> Am 5. März 2024 15:01:21 MEZ schrieb Philip Hands :
>>Here are my latest attempts:
>
> "Be aware that that a ..."
> doubled "that"
>
> "... (unless you select to show it)"
> missing fullstop.

Well spotted - Thanks :-)

> Otherwise: looks good to me.

Cool, in that case I'll fix those two things and then use the result for
the MR[1], and if the openQA test runs look OK, will merge that.

Cheers, Phil.

[1] https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Holger Wansing  writes:

> Hi,
>
> Am 2. März 2024 21:07:34 MEZ schrieb Philip Hands :
>>
>>This sentence is the thing that prompted me to change things in the
>>first place, because it is not true. One does not _need_ to set a root
>>password.
>
> It should be understood as 
> "If you want to enable login as root, you have to set a root password now."
>
> And in expert mode it is in fact working this way:
> At first, you are asked if you want to enable login as root. If you answer 
> yes 
> here, you are prompted to set a root password. 
> And at that point it is indeed required to set a root password, since you 
> chose to enable root login in the first question and the installer does not
> allow an empty password for root.
>
> To make it work in default install, we could change the question as
> in above citation.
>
>>I don't actually care very much whether we encourage sudo use. My
>>wording ended up (after many variations) quite strongly encouraging it
>>mostly as an antidote to the implication that comes from having a
>>question dedicated to setting the root password, but I'd be happy with
>>any wording that makes sure that people understand that both options are
>>totally fine.
>
> The sudo possibility is also mentioned:
>
> 'The root user should not have an empty password. If you leave this
> empty, the root account will be disabled and the system's initial user
> account will be given the power to become root using the "sudo"
> command.'
>
> I have rephrased that a bit, see below.
>
>>The other thing that I was trying to ensure is that people are reassured
>>that they'll get to specify a password that will get them root access even if
>>they decide to leave the root password unset.  This is because I've seen
>>people become quite uncertain about what to expect at this point in the
>>install.
>>
>>I've found that it is not easy to come up with things that include much
>>nuance about this, while still fitting in the space available, which is
>>why I decided to try a more opinionated approach.
>>
>>One could soften what I wrote by replacing "generally recommended" with
>>something like "often appropriate" -- how does that seem to people?
>
> Your proposal too much focusses on the sudo way IMO.
> We risk getting complains from people, who miss advise regarding the
> enabled root login.
>
> I have rephrased the dialog a bit, to make the sudo way more visible and
> better understandable.
>
>>One can of course tinker with this stuff indefinitely. I actually spent
>>a fair amount of time wondering how best to describe not setting a root
>>password for instance -- should one say "leave the password unset", "set
>>an empty password", "enter no password", or something like "just hit
>>"? (and does that last one actually apply to all the available
>>UIs?).
>>
>>The same goes for how you say that the password is not going to get
>>shown (unless you ask for it to be shown), which in the GTK UI gets
>>characters replaced with dots, IIRC in the text UI its with asterisks,
>>and I'd guess it just gets completely hidden in the speech install.
>
> I think that's not much of a problem. People are used to the situation,
> that passwords are not shown, but replaced by asterisks or similar.
> And we have the checkbox for showing it in clear text, that should be
> enough.
>
>
> Updated patch attached.
>
>
> Holger
>
>
>
> diff --git a/debian/user-setup-udeb.templates 
> b/debian/user-setup-udeb.templates
> index cdb6d78..7393511 100644
> --- a/debian/user-setup-udeb.templates
> +++ b/debian/user-setup-udeb.templates
> @@ -34,21 +34,19 @@ Template: passwd/root-password
>  Type: password
>  # :sl1:
>  _Description: Root password:
> - You need to set a password for 'root', the system administrative
> - account. A malicious or unqualified user with root access can have
> + If you want to allow login as root, you need to set a password for 'root',
> + the system administrative account now.
> + A malicious or unqualified user with root access can have
>   disastrous results, so you should take care to choose a root password
> - that is not easy to guess. It should not be a word found in dictionaries,
> - or a word that could be easily associated with you.
> + that cannot be guessed. It should not be a word found in dictionaries,
> + or something that could be easily associated with you.
>   .
> - A good password will contain a mixture of letters, numbers and punctuation
> - and should be changed at regular intervals.
> + You can also leav

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Diederik de Haas  writes:

> Hi,
>
> On Friday, 1 March 2024 20:46:49 CET Holger Wansing wrote:
>> Philip Hands  wrote (Fri, 01 Mar 2024 06:46:27 +0100):
>> > If you want to make a constructive contribution, how about suggesting a
>> > wording that reflects the advice that you think would be most useful to
>> > the people that actually read the advice?
>> 
>> I would like to make a proposal, leaving the default setting as is
>> (aka: default to an enabled root account, no sudo), with only some wording
>> changings.
>> 
>> Patch attached.
>> 
>> What do you think?
>
> I think it's an improvement and I have some suggestions, which hopefully 
> makes 
> it even better. I don't have a git-diff, but hopefully this works too.
>
> I'm not a native English speaker or particularly good at this, so it's more 
> the direction then the exact wording that's important. Others can undoubtedly 
> improve upon it.
>
>  _Description: Root password:
> "You need to set a password for 'root', the system administrative account.

This sentence is the thing that prompted me to change things in the
first place, because it is not true. One does not _need_ to set a root
password.

I don't actually care very much whether we encourage sudo use. My
wording ended up (after many variations) quite strongly encouraging it
mostly as an antidote to the implication that comes from having a
question dedicated to setting the root password, but I'd be happy with
any wording that makes sure that people understand that both options are
totally fine.

The other thing that I was trying to ensure is that people are reassured
that they'll get to specify a password that will get them root access even if
they decide to leave the root password unset.  This is because I've seen
people become quite uncertain about what to expect at this point in the
install.

I've found that it is not easy to come up with things that include much
nuance about this, while still fitting in the space available, which is
why I decided to try a more opinionated approach.

One could soften what I wrote by replacing "generally recommended" with
something like "often appropriate" -- how does that seem to people?

One can of course tinker with this stuff indefinitely. I actually spent
a fair amount of time wondering how best to describe not setting a root
password for instance -- should one say "leave the password unset", "set
an empty password", "enter no password", or something like "just hit
"? (and does that last one actually apply to all the available
UIs?).

The same goes for how you say that the password is not going to get
shown (unless you ask for it to be shown), which in the GTK UI gets
characters replaced with dots, IIRC in the text UI its with asterisks,
and I'd guess it just gets completely hidden in the speech install.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Hi Diederik,

You're probably right that it deserves a separate bug, but I was trying
to avoid wasting the translators time by doing this in two steps, and
forcing them to do the work twice.

I cannot say that I have read the stuff in these dialogs (except when
editing them) for at least 20 years, so tailoring the content of them
for people like me seems like a mistake. I was therefore trying to put
myself in the position of a person that's reading them for the first
time, and perhaps a person that's installing Linux for the first time.

Having helped people to install Linux for ~30 years, I'd say that it's
the norm for people to be almost incapable of coming up with a decent
password if they were not expecting the question.

As I said, I'm happy to hear better suggestions, since I've had about 15
attempts at this so far, and every time I see the text rendered in the
D-I screenshot, I end up not liking the result very much.

If you want to make a constructive contribution, how about suggesting a
wording that reflects the advice that you think would be most useful to
the people that actually read the advice?

If nothing like a consensus is available, then just removing the old
advice seems like an OK place to end up too, which is why I went to the
effort of splitting the commits.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Bug#1064617: Passwords should not be changed frequently

[Philip Hands]

Pascal Hambourg  writes:

> On 25/02/2024 at 01:17, Matthew Wilcox wrote:
>> 
>> I just did an installation with the 2024-02-24
>> debian-testing-amd64-netinst.iso image.  I forget the exact wording
>> used, but when setting up a user, d-i printed advice that user passwords
>> should be changed frequently.  This is no longer current good advice
>> (since 2017):
>
> This topic has some history, see
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656509>
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868869>
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998408>
> <https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7>

It had not occured to me until Matthew's suggestion that we might simply
remove the obsolete advice, rather than trying to improve the wording.

In light of that, I've split the MR into 2 commits, the first of which
removes the old advice (which hopefully inflicts the smallest possible
load on our translators) and the second of which is an attempt to come
up with something better (criticism welcome, I've had multiple attempts
at this, so I imagine there's still room for improvement).

Depending upon whether we think it's worth using translators' time on
this subject, we can then select one or both commits, and finally close
these bugs.

You can see my latest attempt here:

  https://openqa.debian.net/tests/238094#step/passwords/1

in which I'm recommending setting no password for root, which then gives
the initial user 'sudo' membership[1].

The slightly awkward thing about this recommendation is that it
encourages people to put themselves in the situation that:

  https://salsa.debian.org/installer-team/user-setup/-/merge_requests/6

is trying to address, so if we make this recommendation, we should also
deal with that issue (which I think we should do anyway).

Cheers, Phil.

[1] This strikes me as decent advice for newbies, for whom this sort of
guidance is most necessary. The problem with asking a newbie for a
root password is that they're likely to choose a poor one. Even if
they later realise that they should have choosen better passwords,
they may well not at that point remember that they still have a
useless password for root that needs updating.

On the other hand, now that ssh defaults to not allowing password
based logins to root, perhaps the potential presence of a poor
password on a sudo enabled account should be of greater concern,
since that will still be open to remote logins, so I can see that
one could argue this either way.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1064624: Hard to short-stroke an encrypted drive

[Philip Hands]

Matthew Wilcox  writes:

> Package: debian-installer
>
> The partitioner "guided partitioning" offers me:
>
>  - use the largest continuous free space
>  - use entire disk
>  - use entire disk and set up LVM
>  - use entire disk and set up encrypted LVM
>
> I want "use largest contiguous space and set up encrypted LVM".
> That would let me reserve 200GB of my SSD as unencrypted free space,
> which will improve the write endurance of my SSD.

Can one achieve this by telling LVM to allocate less than the full size
of the device to the PV one puts on it?

If one does that, I would guess that one could later extend the PV to
use more/all of the disk using pvresize, so that those that prefer space
over endurance could make that decission when they are running out of
space.

If that's all true, we could have a couple of preseed variables to set
the percentage and maximum amount that would be left fallow for this
purpose, and (eventually) set non-zero defaults when installing to SSD.

Is that something like what you're after?

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1063938: tmux: Does not automatically set mode-keys to vi based on VISUAL or EDITOR environment

[Philip Chung]

Package: tmux
Version: 3.4-1
Severity: minor

Dear Maintainer,

The mode-keys option is no longer being set to vi based on the EDITOR 
environment variable.


Steps to reproduce:

1. Set EDITOR environment variable to /usr/bin/vi and set export flag
2. Start tmux
3. Type Enter a few times to get some lines in the terminal
4. Type Ctrl-[ to enter copy mode
5. Type k to nagivate up
6. Observe that the cursor does not move

When I explicitly set mode-keys (Ctrl-b followed by ":set mode-keys 
vi"), navigation with h, j, k, and l works.


I can also reproduce this with version 3.3a-5 (current version in testing).

According to the man page, tmux automatically sets the mode-keys option 
to vi when the user's preferred editor is vi:


> mode-keys [vi | emacs]
> Use vi or emacs-style key bindings in copy mode. The  default is 
emacs, unless VISUAL or EDITOR contains ‘vi’.


Philip Chung

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tmux depends on:
ii  libc62.37-15
ii  libevent-core-2.1-7  2.1.12-stable-8
ii  libsystemd0  255.3-2
ii  libtinfo66.4+20240113-1
ii  libutempter0 1.2.1-3

tmux recommends no packages.

tmux suggests no packages.

-- no debconf information

Bug#1063518: console-setup: setupcon: 1386: Syntax error: Missing '))'

[Philip Hands]

Michael Tokarev  writes:

> 09.02.2024 16:58, ca...@allfreemail.net
>> Package: console-setup
>> Followup-For: Bug #1063518
>> 
>> Consider making all scripts provided by console-setup
>> shellcheck-clean, there are lots of tiny issues that can turn into
>> big issues under the right conditions.
>
> Please do not do this. Shellcheck is a huge problem and we had large amount
> of bugs due to people trying to apply its suggestions.  It's very difficult
> in many cases to spot why shellcheck is wrong (classic is the suggestion to
> put $var into double quotes "$var" which breaks badly if $var is supposed to
> contain zero or more separate words - this way, even boot scripts has become
> buggy leading to system becoming unbootable).
>
> Shellcheck is a very bad tool.

I think the reality is somewhere between these two positions.

Shellcheck is not particularly helpful for most of D-I because it
doesn't have a shell variant that perfectly matches our busybox sh
build.  That might have just improved, since I notice that a busybox sh
variant has just been merged upstream, so we'll see if that makes things
better.

On the other hand, if I'd been paying attention at the time, the fact
that this change dropped the number of shellcheck reports for setupcon
from 189 to 1 should have rung some alarm bells, but it seems that I've
learnt to ignore the little '!' in my emacs status bar -- I'll have to
keep an eye on that in future.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Bug#1062210: libpam-runtime: pam-auth-update doesn't allow user-ordering of modules

[Philip Prindeville]

Package: libpam-runtime
Version: 1.4.0-11ubuntu2.3
Severity: important

Dear Maintainer,

We were trying to configure PAM authentication to use LDAP, Radius, and local 
(pam_unix) authentication sources in that order, so we ran "sudo 
pam-auth-update --enable ldap radius unix".  Alas it's written in the 
descending priority order coming from the /usr/share/pam-configs/ files.

It would be useful to allow the user to override those priorities so I don't 
have to run "pam-auth-update" then "sudoedit /etc/pam.d/common-auth" to achieve 
the ordering I desire.

There might be local policy issues that require a particular ordering,
and it would be good to have the tool be compatible with such policies.


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 5.15.0-86-generic (SMP w/10 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpam-runtime depends on:
ii  debconf [debconf-2.0]  1.5.79ubuntu1
ii  libpam-modules 1.4.0-11ubuntu2.3

libpam-runtime recommends no packages.

libpam-runtime suggests no packages.

-- debconf information:
  libpam-runtime/profiles: unix, ldap, systemd, capability
  libpam-runtime/title:
  libpam-runtime/no_profiles_chosen:
  libpam-runtime/override: false
  libpam-runtime/conflicts:

Bug#1060117: pass-otp: oathtool safety: avoid argument splitting, send secrets via stdin instead of arguments

[Philip Rinn]

Hi Paul,

thanks, I'll have a look next week and prepare an upload.

Best,
Philip


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060266: [Pkg-auth-maintainers] Some help for coordinated uploads needed

[Philip Rinn]

Hi Florian,

On 12.01.24 at 12:08, Florian Schlichting:

I would like to do an upload of yubikey-manager very soon in order to
fix #1060266 (serious) in python3-ykman. Can we perhaps do an upload of
python-fido2 to unstable in the course of this weekend? Do you want to
do that yourself, so you can update solo1-cli at the same time, or are
you ok with me going ahead and you follow with solo1-cli whenever
convenient?


sure, please go ahead. Just ping me, once you uploaded phython-fido2 to unstable 
so I can upload solo1-cli afterwards.


Thanks for all the preparation!
Philip


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060429:

[Philip Rinn]

Control: reassign -1 python-django-solo

Hi Helmut,

thanks for the bug report, but I guess you missed that solo1-cli.ships this 
file for years (in stable, testing, unstable) while  python-django-solo was 
just uploaded yesterday. So I think the bug is in python-django-solo actually.

Best,
Philip

Bug#1006911: thunar: Cannot use IPv6 addresses in remote URLs

[Philip Chung]

Control: tags -1 fixed-upstream

On Thu Aug 18 2022 11:11:25 GMT-0700 (Pacific Daylight Time), Philip 
Chung wrote:> Control: forwarded -1 
https://gitlab.xfce.org/xfce/thunar/-/issues/864



> [...]


I have reported this issue upstream because I am fairly confident that 
this is not distribution-specific.


This has been fixed upstream in version 4.18.8 and 4.19.0.

Philip Chung

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Philip Hands]

Anthony Iliopoulos  writes:

> On Sun, Oct 29, 2023 at 09:02:01PM +0100, Philip Hands wrote:
...
>>   error: invalid XFS directory entry.
...
> This issue exists independently of the large extent counter, and it is
> related to grub commit ef7850c75 ("fs/xfs: Fix issues found while
> fuzzing the XFS filesystem"). That's actually the issue described in
> #1051543.

Ah, yes -- good point.

> There's a proposed fix at [1], and it works as expected with that patch
> applied.
...
> [1] 
> https://lore.kernel.org/grub-devel/20231018030347.36174-1-n...@vault24.org/

I can confirm that having applied both patches:

  https://salsa.debian.org/philh/grub2/-/pipelines/596346

it now succeeds at both installing grub, and then booting the system:

  https://openqa.debian.net/tests/200503#details

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Philip Hands]

Philip Hands  writes:

> Anthony Iliopoulos  writes:
> ...
>> Yeap it is due to nrext64, I've submitted a patch to grub (should have
>> cc'ed linux-xfs..)
>>
>> https://lore.kernel.org/grub-devel/20231026095339.31802-1-ail...@suse.com/
>
> That certainly seems to fix this bug.

... but sadly that may not be the end of the story.

I've persuaded D-I to use the patched grub version, and when testing it,
it now gets past the previous failure to complete the install, but then
fails to boot after the first reboot, as seen here:

  https://openqa.debian.net/tests/200160#step/_console_wait_login/7

where it drops to the 'grub rescue>' prompt, complaining that:

  error: file `/boot/grub/i386-pc/normal.mod' not found.

if one types `ls (hd0,msdos1)/boot/grub/i386-pc` at that rescue prompt,
it lists the files up to msdospart.mod and then says:

  error: invalid XFS directory entry.

(BTW the directory seemed fine before the reboot, because I listed it)

This makes me wonder: Could it be that the code within the grub
components that get installed onto the disk also needs to be patched to
understand the newer directory structure, and without that it is unable
to read the whole directory, and thus fails to boot it?

Cheers, Phil.

P.S. If you want to try this for yourself, the test image used (that pulls in
the patched grub) is to be found here:

https://salsa.debian.org/philh/grub2/-/jobs/4865564/artifacts/file/debian/output/debian-202306XX+ABI~6.5.0~3+salsaci+20231029+21-amd64-gtkmini.iso

and adding `partman/default_filesystem=xfs` on the kernel command line
before booting into D-I will get it to default to using XFS.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Philip Hands]

Anthony Iliopoulos  writes:
...
> Yeap it is due to nrext64, I've submitted a patch to grub (should have
> cc'ed linux-xfs..)
>
> https://lore.kernel.org/grub-devel/20231026095339.31802-1-ail...@suse.com/

That certainly seems to fix this bug.

I tested it by applying that patch to grub, and then getting that
version of grub installed into the target just after the initial attempt
to run grub had failed, which then allows a retry of the grub install
step to succeed.

Also, with the patched version: `grub-probe -d /dev/vda1` produces 'xfs'

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Philip Hands]

"Darrick J. Wong"  writes:
...
> Curiously, this log says:
>
> Oct 24 05:35:32 in-target: Setting up xfsprogs (6.4.0-1) ...^M
>
> So ... is it running 6.4 and not 6.5?

The daily test versions of Debian-Installer draw components from
"unstable", which is where the 6.5 version is at present, which then
creates the file system with problematic flags.

However, the test images normally install "testing" onto the target, to
avoid pointless breakage caused by the potential for "unstable" to be,
well ... unstable, hence the 6.4 version that gets put in-target.

Having 6.4 in the target system doesn't help in this case, because the
damage has already been done while creating the file system, by the 6.5
version of the udeb.

One can confirm that this is the case by looking for xfsprogs in here:

  
https://openqa.debian.net/tests/198911/logfile?filename=complete_install-DI-installed-pkgs.txt

which lists the installed components (udebs) of the installer that's running:

  xfsprogs-udeb    6.5.0-1

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Philip Hands]

Philip Hands  writes:
...
> Could this be related to #1051543?
>
> I'll try testing D-I while using the patch from that bug, to see if that 
> helps.

It seems (to me at least) that the patch there does not apply usefully
to the version we're talking about, so I'll leave it to people that know
more about grub & XFS to look further.

=-=-=

BTW the jobs where this failure first occured are:

(BIOS)  https://openqa.debian.net/tests/198911
(UEFI)  https://openqa.debian.net/tests/198912

and the immediately previous working jobs are these:

(BIOS)  https://openqa.debian.net/tests/198840
(UEFI)  https://openqa.debian.net/tests/198841

In the jobs you can see a 'Logs & Assets' tab, where you can find e.g.
the syslog from the D-I run.

Here's the one from the first BIOS failure:

  https://openqa.debian.net/tests/198911/logfile?filename=DI_syslog.txt

One thing I notice when comparing that to the matching successful log:

  
https://openqa.debian.net/tests/198840/logfile?filename=complete_install-DI_syslog.txt

is that they both include a block of lines like:

   grub-installer: Unknown device "/dev/vda1": No such device

so that's just noise by the looks of it, since it was also saying that
when it was working.

I've since slightly reorganised the openQA jobs, to have a job that only
differs from the normal minimal install by the selection of XFS, so if
you want to see currently failing jobs, they will be the ones called
nonGUI_XFS@64bit & nonGUI_XFS (for BIOS & UEFI installs, respectively)
in this overview:

  https://openqa.debian.net/tests/overview?distri=debian=10

HTH

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

Bug#1054644: xfsprogs-udeb: causes D-I to fail, reporting errors about missing partition devices

[Philip Hands]

Package: xfsprogs-udeb
Version: 6.5.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: openqa

While doing openQA testing of Debian-Installer, I notice that XFS installs
started failing a few days ago, and comparing the versions of udebs that changed
between success and failure, the only likely candidate is xfsprogs-udeb, which
has a version of 6.4.0-1 in the last working test, and 6.5.0-1 in the first
failing one.

I've also built the latest D-I with 6.4.0-1, and that restores it to a working
condition.

I note that if one runs e.g.:  grub-probe -d /dev/vda1
at the moment of failure, the XFS filesystem is not recognised
(despite being mounted as XFS at that moment).

Could this be related to #1051543?

I'll try testing D-I while using the patch from that bug, to see if that helps.

Cheers, Phil.

Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1

[Philip Hands]

Luca Boccassi  writes:

> On Sat, 23 Sept 2023 at 14:29, Simon McVittie  wrote:
>>
>> On Wed, 30 Aug 2023 at 16:27:12 +0100, Simon McVittie wrote:
>> > [ Reason ]
>> > Part of the transition to merged-/usr, and more specifically, allowing
>> > us to stop shipping files in trixie whose physical path on disk does
>> > not match their path in the dpkg database due to directory aliasing.
>> >
>> > This change needs to be in bookworm (and bullseye, and maybe buster)
>> > before that process can continue, because official buildds run debootstrap
>> > from stable (or older).
>> >
>> > I also took the opportunity to backport changes that make the autopkgtests
>> > pass.
>> >
>> > [ Impact ]
>> > If not accepted, trixie will continue to be stuck in a
>> > mostly-but-not-entirely merged-/usr limbo, with the moratorium from 
>> > #1035831
>> > remaining in place.
>>
>> I'm aware that we're getting close to the deadline for 12.2 and 11.8,
>> so I've uploaded the proposed version to bookworm-proposed-updates for
>> easier testing and review. Luca: the proposed version and a signed tag
>> are available from my fork on salsa (I am not able to push to the d-i
>> repository for debootstrap). I uploaded with dgit, so the git tree and
>> the .dsc have been verified to be identical.
>>
>> If this version is not accepted for whatever reason, then I think we
>> should treat version 1.0.128+nmu2+deb12u1 as having been used, and skip
>> ahead to 1.0.128+nmu2+deb12u2 for any subsequent bookworm update.
>> (And if there is a problem with having this version in bookworm-pu for
>> whatever reason, I'm happy to upload a +deb12u2 that is identical to
>> 1.0.128+nmu2 except for the changelog.)
>
> Thank you, pushed both branches.
>
> Release Team, we are aware that you requested an explicit review from
> D-I for this and #1025708, however there are no available reviewers,
> so it appears we are deadlocked. Would you please consider waiving
> this requirement to break the deadlock?
> Philip Hands has confirmed on Salsa that the change has been tested
> with OpenQA and everything still works:
> https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/105#note_429838

Just thought I'd mention that those tests were for current unstable.

As mentioned in:
  
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/105#note_430223
my attempts to test the same change in bullseye have not yet worked out,
because bullseye's D-I is missing the features that were recently added
to D-I in order to allow one to add a test repo from which D-I can
obtain modified udebs (such as debootstrap).

I'll ought to be able to sort out tweaked versions of net-retriever &
anne for bullseye, in which case a test should be possible.

I'm somewhat dubious that such a test is going to tell us anything
interesting though.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1052448: kmail: Account Assistant window can be covered by main Kmail window

[Philip Hands]

Package: kmail
Version: 4:22.12.3-1
Severity: minor

Hi,

While performing automated tests of KDE with openQA (on openqa.debian.net) it
has been observed that Kmail, on first run, can end up looking like this:

  https://openqa.debian.net/tests/190198#step/kmail/5

in case that link rots at some point, I'll also do some ASCII art:

   +- Account Assistant --+
   |  |
   +- Kmail --+
   |  |

  ...

   |  |
   +--+
   |[Help] [Back] [Next] [Finish] [Cancel]|
   +--+

I guess that for a normal user, it's generally going to be obvious that they
need to click the Account Assistant window to get it back on top.

For our automated testing, luckily the 'cancel' button is still visible, so we
get to click on the lower window to get rid of it, and can continue.

Despite that, I'd have thought that it would be better to insist on the account
assistant staying on top.

Cheers, Phil.

Bug#1052377: gdm3: less than beautiful word-wrap decision seen in failed authentication message.

[Philip Hands]

Package: gdm3
Version: 45~beta-1
Severity: wishlist

Hi,

While testing Gnome installs using openQA I noticed that if providing the wrong
password, one is shown a message that is word-wrapped in an awkward manner:

  Sorry, password authentication didn't work. Please try
 again.

you can see a screenshot of that here:

  https://openqa.debian.net/tests/190043#step/_graphical_wait_login/9

I would suggest that whatever is deciding to wrap that text could be improved to
prefer balancing the number of words in the two lines somewhat better, and to
prefer doing line breaks after punctuation, in order to obtain a result like:

  Sorry, password authentication didn't work.
   Please try again.

Even if it just did the most simple-minded thing: choosing to wrap as soon after
the middle of the string that it finds white-space, that would look better IMO:

  Sorry, password authentication
  didn't work. Please try again.

I'm sure that this bug actually exists in some library that gdm3 uses, so please
reassign it as appropriate.

I am aware that this is completely trivial (hence wishlist), but doing QA
testing tends to make one notice such things, and I'm sure that whatever is
making that line-break decision is making equally poor decisions in many other
places, and in other translations, and that the whole user experience might be
(very slightly) improved if it did a better job.

Cheers, Phil.

Bug#1051468: cannot install BIOS machine with mini.iso, error creating /target/sys/firmware/efi/efivars

[Philip Hands]

Hi Edward,

Edward Little  writes:

> Please remove the following email address:  e.little...@gmail.com

I guess that you're subscribed to the debian-boot mailing list.

If so, you'll have seen copies of the mails seen here:

  https://lists.debian.org/debian-boot/2023/09/threads.html

in which case you can unsubscribe here:

  https://lists.debian.org/debian-boot/

Since I'm looking at that page, I've done that for you (you should
already have a confirmation mail)

BTW every email forwarded by the debian mailing list system includes a
footer with links to unsubscription instructions, just in case you're on
other lists you don't want to be on.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1051468: cannot install BIOS machine with mini.iso, error creating /target/sys/firmware/efi/efivars

[Philip Hands]

Marc Haber  writes:

> On Fri, Sep 08, 2023 at 03:48:25PM +0200, Pascal Hambourg wrote:
>> On 08/09/2023 at 13:56, Marc Haber wrote :
>> > I tried installing sid from mini.iso into a libvirt/qemu/kvm VM with
>> > BIOS "firmware", choosing mainly default values, and ended up with the
>> > system logging "grub-installer: error: Error creating
>> > /target/sys/firmware/efi/efivars" and an error message "Failed to mount
>> > /target/proc, Mounting the proc file system on /target/proc failed".
>> 
>> This issue has been discussed in #1031183 starting from
>> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031183#17>
>> (it is a different issue from the original bug report, so a separate bug
>> should have been filed) and a merge request is in progress.
>> <https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/19>
>
> Loooks like the same issue, happens also with a regular netinst install.

If you'd like to test the result of building that merge request into a
mini.iso, you can give it a go with this:

https://salsa.debian.org/philh/grub-installer/-/jobs/4675763/artifacts/file/debian/output/debian-202306XX+salsaci+20230908+294-amd64-gtkmini.iso

which was built in this pipeline:

https://salsa.debian.org/philh/grub-installer/-/pipelines/577147

where you will find links to the commit & branch that's from.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#998408: "good password" advice in installer is still bad two years after this was reported

[Philip Hands]

Jonathan Kamens  writes:

> Oh, I see now that the fact that the installer shouldn't recommend 
> changing one's password regularly was also reported previously, in bug 
> #868869.

Also, in #656509 (in which Cyril states that the effort of translating a
new message outweighs the importance of the change).

I've no idea if that justification for inaction still stands, but I
thought this would make a nice little example for the use of the
salsa-CI pipeline (and my branch2repo variant of that), so here's an MR:

  https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7

and here's a screenshot of what the change looks like:

  https://openqa.debian.net/tests/185853#step/passwords/1

I'm not 100% happy with the wording (and the underlines around 'should'
need to go) so I'm very likely to tweak it tomorrow.

Suggestions for improvement welcome, although be aware that given the
resistance to fixing this in the past, it's always possible such a
change will also be deemed unjustified now.

I think it's probably about time we fixed it, since even the civil
servants in the UK have stopped recommending password changes by now,
and they tend to make such changes at least a decade late. ;-)

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1051373: libglib2.0-0: 2.77.3-1 breaks Midnight Commander extension file

[Philip Withnall]

See upstream report
https://gitlab.gnome.org/GNOME/glib/-/issues/3095#note_1839091, which
will be fixed upstream for 2.78.0, which is due to be released in the
next couple of days.

Philip

On Wed, 2023-09-06 at 22:49 +, Michael Gold wrote:
> Package: libglib2.0-0
> Version: 2.77.3-1
> Severity: important
> 
> Dear Maintainer,
> 
> After upgrading libglib2.0-0 from 2.77.2-1 to 2.77.3-1, I'm no longer
> able to open files by selecting them in Midnight Commander and
> pressing
> Enter.  A change in the behaviour of g_key_file_get_string() appears
> to
> be the cause.  For example, one section of the mc.ext.ini file
> contains:
> [pdf]
> Regex=\.(pdf|PDF|ps|djvu)$
> Open=pdf %f &
> 
> With the new package, a call to g_key_file_get_string() for the
> "Regex"
> value returns NULL.  If I pre-load the old library version, it
> returns
> the string, and mc executes the specified command if I press Enter
> with
> a PDF file selected.
> 
> The package version of "mc" is "3:4.8.29-2".
> 
> - Michael
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.4.0-4-amd64 (SMP w/32 CPU threads; PREEMPT)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_CA:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages libglib2.0-0 depends on:
> ii  libc6 2.37-7
> ii  libffi8   3.4.4-1
> ii  libmount1 2.39.2-1
> ii  libpcre2-8-0  10.42-4
> ii  libselinux1   3.5-1
> ii  zlib1g    1:1.2.13.dfsg-3
> 
> Versions of packages libglib2.0-0 recommends:
> ii  libglib2.0-data   2.77.3-1
> ii  shared-mime-info  2.2-1
> ii  xdg-user-dirs 0.18-1
> 
> Versions of packages libglib2.0-0 suggests:
> pn  low-memory-monitor  
> 
> -- no debconf information

Bug#1051144: reportbug: tex-common fails to install due to fmtutil error

[Philip Armstrong]

Package: tex-common
Version: 6.18
Severity: normal

Output of apt:

Setting up tex-common (6.18) ...
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time... 
fmtutil failed. Output has been stored in
/tmp/fmtutil.Jzo9pPaf
Please include this file if you report a bug.

/tmp/fmtutil.Jzo9pPaf contains the following:
---
fmtutil [ERROR]: no (or empty) hitex.fmt made by: hitex -ini   -jobname=hitex 
-progname=hitex -etex -ltx hitex.ini  
   p
 p
refer
 
   e
l.48 prefere
d 0
? 
! Emergency stop.
 
   p
 p
refer
 
   e
l.48 prefere
d 0
Transcript written on hitex.log.
--

Looking at /usr/share/texlive/texmf-dist/tex/hitex/base/hiplainpage.tex & 
diffing it with the
version at CTAN, it seems that the latter spells the word in question as 
“preferred”.

If I edit prefered -> preferred in the Debian file, the install completes 
successfully.

cheers,

Phil


dpkg: error processing package tex-common (--configure):
 installed tex-common package post-installation script subprocess returned 
error exit status 1


-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 
'testing'), (500, 'stable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

tex-common recommends no packages.

Versions of packages tex-common suggests:
ii  debhelper  13.11.6

Versions of packages texlive-base depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libpaper-utils 1.1.29
ii  sensible-utils 0.0.20
ii  texlive-binaries   2023.20230311.66589-3
ii  ucf3.0043+nmu1
ii  xdg-utils  1.1.3-4.1

Versions of packages texlive-base recommends:
ii  lmodern  2.005-1

Versions of packages texlive-base suggests:
ii  evince [postscript-viewer]   45~alpha-2
ii  ghostscript [postscript-viewer]  10.01.2~dfsg-1
ii  gv [postscript-viewer]   1:3.7.4-2+b1
ii  perl-tk  1:804.036-1+b2
pn  xpdf | pdf-viewer
pn  xzdec

Versions of packages texlive-binaries depends on:
ii  libc6   2.37-7
ii  libcairo2   1.16.0-7
ii  libfontconfig1  2.14.2-4
ii  libfreetype62.13.2+dfsg-1
ii  libgcc-s1   13.2.0-2
ii  libgraphite2-3  1.3.14-1
ii  libharfbuzz0b   8.0.1-1
ii  libicu7272.1-3
ii  libkpathsea62023.20230311.66589-3
ii  libmpfr64.2.0-1
ii  libpaper1   1.1.29
ii  libpixman-1-0   0.42.2-1
ii  libpng16-16 1.6.40-1
ii  libpotrace0 1.16-2
ii  libptexenc1 2023.20230311.66589-3
ii  libstdc++6  13.2.0-2
ii  libsynctex2 2023.20230311.66589-3
ii  libteckit0  2.5.11+ds1-1+b1
ii  libtexlua53-5   2023.20230311.66589-3
ii  libtexluajit2   2023.20230311.66589-3
ii  libx11-62:1.8.6-1
ii  libxaw7 2:1.0.14-1
ii  libxi6  2:1.8-1+b1
ii  libxmu6 2:1.1.3-3
ii  libxpm4 1:3.5.12-1.1
ii  libxt6  1:1.2.1-1.1
ii  libzzip-0-130.13.72+dfsg.1-1.1
ii  perl5.36.0-7
ii  t1utils 1.41-4
ii  zlib1g  1:1.2.13.dfsg-3

Versions of packages texlive-binaries recommends:
ii  dvisvgm   3.1-1
ii  texlive-base  2022.20230122-3

-- debconf information:
  texlive-base/binary_chooser: pdftex, dvips, dvipdfmx, xdvi
  texlive-base/texconfig_ignorant:

Bug#1050924: dgit: allowed a push-source for a version that already exists in the archive

[Philip Hands]

Package: dgit
Version: 10.7
Severity: important

Hi,

Following on from an IRC chat with Ian, I'm submitting a bug as requested.

In a moment of inattention[1], I seem to have found myself in a git "master"
branch that was sitting on release 1.109 of the `preseed` package (whereas the
latest release is in fact 1.119)

I then cherry-picked the changes that I should have been aiming at 1.120, ran
gbp dch to generate 1.110, failed to spot anything awry, and since this was to
be the first dgit upload of `preseed` (a native package), I then ran:

  dgit -wgf --deliberately-not-fast-forward push-source

as per dgit-main-native(1).

This cheerfully did the push, including a `debian/1.110` tag.

Of course the thing it tagged as debian/1.110 is not the same thing as the 
actual `1.110`
release (which was from Jan 2022).

Prior to doing any of this, https://browse.dgit.debian.org/?q=preseed showed "No
repositories found".   I think it _may_ also have said that just after the push.

Once I did a dgit clone, the listing appeared, and the git history in the clone
showed me that it had stitched together my bogus-1.110 with the 1.119 version
that it presumably generated in order to satisfy my clone request.

There seems to share some features with https://bugs.debian.org/1050711

Cheers, Phil.

[1] perhaps due to a dyslexia-related occasional inability to distinguish things
such as: 1.109 vs. 1.119.

-- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (99, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-11-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dgit depends on:
ii  apt2.6.1
ii  ca-certificates20230311
ii  coreutils  9.1-1
ii  curl   7.88.1-10+deb12u1
ii  devscripts 2.23.4
ii  dpkg-dev   1.21.22
ii  dput   1.1.3
ii  git [git-core] 1:2.39.2-1.1
ii  git-buildpackage   0.9.30
ii  libdpkg-perl   1.21.22
ii  libjson-perl   4.1-1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-gettext-perl 1.07-5
ii  libtext-csv-perl   2.02-2
ii  libtext-glob-perl  0.11-3
ii  libtext-iconv-perl 1.7-8
ii  libwww-curl-perl   4.17-10
ii  perl [libdigest-sha-perl]  5.36.0-7

Versions of packages dgit recommends:
ii  distro-info-data 0.58
ii  liburi-perl  5.17-1
ii  openssh-client [ssh-client]  1:9.2p1-2

Versions of packages dgit suggests:
ii  sbuild  0.85.0

-- no debconf information

Bug#1050887: endlessh.service includes unhelpful instructions for listening on low ports

[Philip Hands]

Package: endlessh
Version: 1.1-5
Severity: normal

Dear Maintainer,

In `/lib/systemd/system/endlessh.service` there is this comment:

  ## If you want Endlessh to bind on ports < 1024
  ## 1) run:
  ## setcap 'cap_net_bind_service=+ep' /usr/local/bin/endlessh
  ## 2) uncomment following line
  #AmbientCapabilities=CAP_NET_BIND_SERVICE
  ## 3) comment following line
  PrivateUsers=true

which isn't very helpful, since the README instructs one to do the much 
preferable:

  systemctl enable --now endlessh@222.socket

BTW I started out this bug pointing out that /usr/local/bin is the wrong path,
and suggesting that socket activation would be much preferable, before noticing
that actually, that's already what the README's suggesting.

The comment should probably just be removed, or replaced with something like:

  # to run Endlessh on alternative ports, see: 
/usr/share/doc/endlessh/README.Debian

oh, actually, not quite ... I notice that the endlessh@.socket file appears to
be missing at present, so that would need to be added to the package first.

Cheers, Phil.

Bug#1050001: Unwinding directory aliasing [and 3 more messages]

[Philip Hands]

Helmut Grohne  writes:
...
> As such, my expectation is that moving from where we are to your idea
> is not any easier than moving from a post-DEP-17 state. Therefore, I
> do not see any need to delay DEP-17 work.

I've been wondering about this possibility too.

If a symlink flowerbed is where we decided we wanted to end up, I get
the impression that starting from post-DEP-17 would be rather easier
than starting from where we are now.

DEP-17 provides us with a detailed roadmap for the first leg of that
trip, whereas the route via reversion seems to be littered with unknowns
at present.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1050305: dh-python: Packages using distutils-extra missing dependencies

[Philip Rinn]

Hi,

the 'requires' are actually generated by DistUtilsExtra.auto and are present in 
the PKG-INFO file in the .egg-info directory.

It seems dh-python is not picking them up correctly, thus reassigning.

Best,
Philip


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050305: python3-distutils-extra: DistUtilsExtra.auto fails to determine "requires" from import statements in source code

[Philip Rinn]

Package: python3-distutils-extra
Version: 2.50
Severity: normal
X-Debbugs-Cc: ri...@debian.org

Hi,

it seems, DistUtilsExtra.auto fails to determine "requires" from import
statements in source code.

While gTranscribe produces the correct dependencies on 2023-01-05
(https://buildd.debian.org/status/fetch.php?pkg=gtranscribe=all=0.11-1=1672939550=0)
it doesn't do that on 2023-08-15
(https://buildd.debian.org/status/fetch.php?pkg=gtranscribe=all=0.11-2=1692119063=0)

The only difference between 0.11-1 and 0.11-2 is

--- a/debian/clean
+++ b/debian/clean
@@ -1,2 +1,3 @@
 MANIFEST
 po/gTranscribe.pot
+gTranscribe.egg-info/

Building 0.11-1 today on unstable results in missing dependencies as well.

Best,
Philip


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-distutils-extra depends on:
ii  intltool   0.51.0-6
ii  python33.11.4-5+b1
ii  python3-distutils  3.11.4-1
ii  python3-pkg-resources  68.0.0-2
ii  python3-setuptools 68.0.0-2

python3-distutils-extra recommends no packages.

Versions of packages python3-distutils-extra suggests:
ii  devscripts  2.23.5

-- no debconf information

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Philip Hands]

Philip Hands  writes:
...
> However, I am now wondering whether we might not be better off using
> `archdetect` to see if we're on an efi system, and then make the attempt
> to call mountvirtfs for the efivarfs conditional on that.

After a diversion[1], I had a look at the archdetect option, and have
discovered that this simple patch:

  
https://salsa.debian.org/philh/grub-installer/-/commit/6f33bd183d7d0ced76958440534407dc9d0ad141

fixes the UEFI boot, without breaking the BIOS boot (on amd64 at least,
while doing a minimal install):

  
https://openqa.debian.net/tests/overview?version=testing=--20230820_1958_salsa=debian

I hope/assume that all the arches that need this have the good grace to
return `efi` as their subarch. If there's any risk that's not the case,
we could also apply the previous patch.

If you want to do your own tests, the mini.iso can be downloaded via:

https://salsa.debian.org/philh/grub-installer/-/jobs/4582667/artifacts/file/debian/output/debian-202306XX+salsaci+20230820+228-amd64-gtkmini.iso

BTW that's in the artifacts of the `mini-ISO` job, which can be found by
looking at the pipeline linked from the commit above[2], and looking to
the right for the Downstream pipelines -- further right you can find
links to the openQA jobs above.

Cheers, Phil.

[1] rewriting branch2repo so that it doesn't need a state repo. for
many use-cases, which will hopefully allow anyone to run these D-I tests
on salsa, without any special setup.

[2] https://salsa.debian.org/philh/grub-installer/-/pipelines/567684
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty

[Philip Hands]

Steve McIntyre  writes:

> On Wed, Jul 12, 2023 at 11:15:57AM +0200, Cyril Brulebois wrote:
>>Hi Michael,
>>
>>Cyril Brulebois  (2023-06-28):
>>> Control: reassign -1 busybox-udeb 1:1.36.1-3
>>
>>[…]
>>
>>> With a local build, confirmed -3 is buggy, and that reverting only
>>> busybox-udeb to -1 is sufficient to restore syslog support in the
>>> installer.
>>> 
>>> Reassigning there; the GRUB thing can be filed separately once we have
>>> actual information via syslog.
>>
>>A fix would be appreciated, we've got reports piling up about things we
>>have no logs for.
>
> After weeks with this breakage, I've just uploaded a minimal NMU to
> fix it, reverting the syslog changes since -1. I've buit and tested
> successfully locally.

Thanks -- and I agree, it works :-)

  https://openqa.debian.net/tests/178534/logfile?filename=DI_syslog.txt

As it happens, over the weekend it occurred to me that I might be able
to pave the way to a fix for this bug by coming up with a test for the
failure.

Awkwardly, syslogd wants to open /dev/log and bails out if it's already
in use, so I resorted to (the somewhat disgusting hack of) using podman:

   
https://salsa.debian.org/philh/busybox/-/commit/2697f7cce81d1a70de202a30e7062dc9f64a94b1

At least it allows syslogd to run well enough to succeed or fail
similarly to the behaviour seen in the bug.

Here it is going wrong with the -3 code:

  https://salsa.debian.org/philh/busybox/-/jobs/4523822#L3963
  (lines 3969-3975, with the last line showing the entire syslog)

and here is an example of it going right:

  https://salsa.debian.org/philh/busybox/-/jobs/4523808#L3668

  Line 3668 here, saying "PASS: syslogd-works" indicates that we
  succeeded in grepping the test string in /var/log/syslog

The difference between these two is simply disabling
CONFIG_FEATURE_REMOTE_LOG, as seen here:

  
https://salsa.debian.org/philh/busybox/-/commit/89c253f75690dd41487b6fd6f9356a1e890a6ac2

I'm not proposing that as a fix, but it does seem to indicate where the
problem may be located. I'm afraid I've failed to work out what's
actually going wrong here (my C's pretty rusty).

BTW At one point I thought I'd narrowed it down to the while loop here:

  
https://salsa.debian.org/philh/busybox/-/commit/328fdfbe43cd8d9e4425c3ee1c68aadfa44ee434

but if that did work, it does no longer. Either I was mistaken about it
having worked earlier (I'm at least 80% sure that's not the case) or
something non-deterministic is going on ... which makes me wonder if the
underlying cause might be something to do with using uninitialised data
somewhere.

Hopefully this will be of some use to those more familiar with the code.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Philip Hands]

Arnaud Rebillout  writes:

> Tentative fix, for what it's worth:
>
> https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/19

The original code there seems a bit tangled, and the need to check for
efivarfs in two places seemed suboptimal, so here's an attempt to
improve on it, including making the displayed error less misleading:

  https://salsa.debian.org/philh/grub-installer/-/commit/f14c5e70

[ It didn't seem worth distinguishing between the mkdir or the mount
  failing on-screen, so I've just logged that instead, and having done
  that, since there would only be one call to die() and I'd need to pass
  extra parameters for the error substutions, I just got rid of die() and
  put the code inline instead. ]

To see what that looks like, I temporarily disabled the efivarfs test:

  https://salsa.debian.org/philh/grub-installer/-/commit/fcb794f6

then one gets to see this error:

  https://openqa.debian.net/tests/176310#step/grub/5

=-=-

However, I am now wondering whether we might not be better off using
`archdetect` to see if we're on an efi system, and then make the attempt
to call mountvirtfs for the efivarfs conditional on that.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil


signature.asc
Description: PGP signature

Bug#1040457: RFS: libfilezilla/0.44.0-1 -- build high-performing platform-independent programs (runtime lib)

[philip . wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libfilezilla":

 * Package name : libfilezilla
   Version  : 0.44.0-1
   Upstream contact : Tim Kosse 
 * URL  : https://lib.filezilla-project.org/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/libfilezilla
   Section  : libs

The source builds the following binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent 
programs (translations)
  libfilezilla40 - build high-performing platform-independent programs 
(runtime lib)


To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/libfilezilla/

Alternatively, you can download the package with 'dget' using this 
command:


  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.44.0-1.dsc


Changes since the last upload:

 libfilezilla (0.44.0-1) unstable; urgency=medium
 .
   * New upstream version 0.44.0
   * Soname bump rename package to libfilezilla40

Regards

Phil

Bug#1038916: guix: daemon breaks with --discover option specified

[Philip McGrath]

Package: guix
Version: 1.4.0-4
Severity: normal
X-Debbugs-Cc: phi...@philipmcgrath.com

Dear Maintainer,

Debian's `guix-daemon` breaks if given the `--discover` option, apparently
because some files from upstream Guix 1.4.0 are not installed by the Debian
package. Note that the man page for `guix-daemon` in Debian claims that
`--discover` is supported.

I discussed this problem at
https://lists.gnu.org/archive/html/help-guix/2023-06/msg00083.html before
finding the cause of the issue.

Minimal steps to reproduce:

 1. `sudo apt install guix`
 2. Enable the `--discover` option:
 a. `sudo systemctl edit guix-daemon.service`
 b. In your editor, write:
```
[Service]
ExecStart=
ExecStart=/usr/bin/guix-daemon \
--build-users-group=_guixbuild \
--discover=yes
```
 c. `sudo systemctl restart guix-daemon.service`
 3. Run `sudo systemctl status guix-daemon.service` and observe that, while
the service is running,  the journal contains a message like
`Jun 22 16:05:40 debiantestin-2 guix-daemon[2522]: guix: discover: command 
not found`.
 4. Run a command like `guix pull` and observe the error below.

```
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to f25529b (55,750 new 
commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   f25529b
substitute: ;;; Failed to autoload read-substitute-urls in (guix scripts 
discover):
substitute: ;;; no code for module (guix scripts discover)
substitute: Backtrace:
substitute: In ice-9/boot-9.scm:
substitute:   1752:10 15 (with-exception-handler _ _ #:unwind? _ # _)
substitute: In unknown file:
substitute:   14 (apply-smob/0 #)
substitute: In ice-9/boot-9.scm:
substitute: 724:2 13 (call-with-prompt _ _ #)
substitute: In ice-9/eval.scm:
substitute: 619:8 12 (_ #(#(#)))
substitute: In guix/ui.scm:
substitute:2275:7 11 (run-guix . _)
substitute:2217:7 10 (run-guix-command substitute "--query")
substitute: In ice-9/boot-9.scm:
substitute:   1747:15  9 (with-exception-handler # \u2026)
substitute:   3327:17  8 (resolve-interface (guix scripts substitute) #:select 
_ \u2026)
substitute: In ice-9/threads.scm:
substitute: 390:8  7 (_ _)
substitute: In ice-9/boot-9.scm:
substitute:   3253:13  6 (_)
substitute: In ice-9/threads.scm:
substitute: 390:8  5 (_ _)
substitute: In ice-9/boot-9.scm:
substitute:   3544:20  4 (_)
substitute:2836:4  3 (save-module-excursion _)
substitute:   3564:26  2 (_)
substitute: In unknown file:
substitute:1 (primitive-load-path "guix/scripts/substitute" 
#)
substitute: In guix/scripts/substitute.scm:
substitute:753:33  0 (_)
substitute:
substitute: guix/scripts/substitute.scm:753:33: error: read-substitute-urls: 
unbound variable
guix pull: error: `/usr/bin/guix substitute' died unexpectedly
```

Other commands that might use substitutes, like `guix build hello`, exhibit
the same error. Using `--no-substitutes` works around the problem, with the
obvious downside.

The Debian package really doesn't seem to contain `(guix scripts discover)`,
neither in source nor in compiled form, and it does seem to be present in the
upstream Guix 1.4.0 release. I haven't checked for other files that might be
missing, but it seems like that would be worth doing.

Thanks again!
Philip

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages guix depends on:
ii  guile-3.0   3.0.8-2
ii  guile-3.0-libs  3.0.8-2
ii  guile-gcrypt0.4.0-2
ii  guile-git   0.5.2-5
ii  guile-gnutls3.7.9-2
ii  guile-json  4.7.3-2
ii  guile-lzlib 0.0.2-3
ii  guile-sqlite3   0.1.3-3
ii  guile-ssh   0.16.2-1
ii  guile-zlib  0.1.0-4
ii  libbz2-1.0  1.0.8-5+b1
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libgcrypt20 1.10.2-2
ii  libsqlite3-03.40.1-2
ii  libssh-dev  0.10.5-2
ii  libstdc++6  12.2.0-14
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages guix recommends:
ii  ca-certificates  20230311
ii  less 590-2
ii  nscd 2.36-9
ii  systemd  252.11-1

guix suggests no packages.

-- no debconf information


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

Bug#1034683: r-base: new upstream release unintentionally uploaded to unstable

[Philip Rinn]

Hi,

could we please close this bug? We released bookworm some days ago and 
propagating to testing should be fine now. [It blocks R packages to propagate to 
testing currently.]


Thanks
Philip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037264: cksum crashes intermittently with "Illegal instruction" on some Xen DomU

[Philip Rowlands]

On Sat, 10 Jun 2023, at 11:09, Pádraig Brady wrote:
> cksum since v9.0 checks at runtime whether pclmul is supported.
> It seems that check is not working appropriately on a Xen DomU.

Hypervisors routinely lie about CPUID feature flags, in order to maintain 
compatibility between a fleet of diverse servers. It's possible in this case 
that the system was misconfigured to present flags which the underlying CPU 
doesn't support.

> The routine in question is pclmul_supported() at:
> https://github.com/coreutils/coreutils/blob/b841f111/src/cksum.c#L160-L191
>
> That either suggests xen is incorrectly setting PCLMUL and AVX bits,
> or perhaps these two bits are not sufficient.
> Hmm I wonder do we also need to explicitly check for SSSE3 support?

Intel says to check for SSE and SSE2; quoting the manual
===
11.6.2 Checking for Intel® SSE and SSE2 Support
Before an application attempts to use Intel SSE and/or Intel SSE2, it should 
check that they are present on the
processor:
1. Check that the processor supports the CPUID instruction. Bit 21 of the 
EFLAGS register can be used to check
processor’s support the CPUID instruction.
2. Check that the processor supports Intel SSE and/or SSE2 (true if 
CPUID.01H:EDX.SSE[bit 25] = 1 and/or
CPUID.01H:EDX.SSE2[bit 26] = 1).

12.13.4 Checking for Intel® AES-NI Support
Before an application attempts to use AESNI instructions or PCLMULQDQ, the 
application should follow the steps
illustrated in Section 11.6.2, “Checking for Intel® SSE and SSE2 Support.” 
Next, use the additional step provided
below:
Check that the processor supports Intel AES-NI (if CPUID.01H:ECX.AESNI[bit 25] 
= 1); check that the processor
supports PCLMULQDQ (if CPUID.01H:ECX.PCLMULQDQ[bit 1] = 1).
===

Wikipedia mentions an AVX-512 version (VPCLMULQDQ) but I don't think we're 
using that.

I can't find the equivalent AMD docs. Is there a library / macro check for 
this, to avoid the low-level bit inspection?

It would be useful to see the output of "cpuid -1" which does a verbose decode 
of all CPUID flags, on the system which sees the SIGILL. (How can it be 
intermittent??)

Interesting that the strace output finishes with:

read(0, "", 61440)  = 0
--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x55bec9cc6cf5} ---
+++ killed by SIGILL +++

i.e. ILL_ILLOPN (operand) rather than ILL_ILLOPC (opcode). What could cause 
this?


Cheers,
Phil

Bug#1037317: RFS: libfilezilla/0.43.0-1 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libfilezilla":

 * Package name : libfilezilla
   Version  : 0.43.0-1
   Upstream contact : Tim Kosse 
 * URL  : https://lib.filezilla-project.org/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/libfilezilla
   Section  : libs

The source builds the following binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent programs 
(translations)
  libfilezilla39 - build high-performing platform-independent programs (runtime 
lib)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libfilezilla/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.43.0-1.dsc

Changes since the last upload:

 libfilezilla (0.43.0-1) unstable; urgency=medium
 .
   * New upstream version 0.43.0
   * Soname bump rename package to libfilezilla39

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Philip Hands]

Package: rootskel
Version: 1.135
Severity: normal
Tags: patch

Hi,

One can see the symptoms by looking here:

  https://openqa.debian.net/tests/151286

the orange "Soft Failed" boxes highlight some of the failing screens, where the
failure can be seen in the screenshot immediately preceeding the "Soft Failed"

I'll attach an example to save people from having to follow that link.

Apparently, this MR fixes the problem:

  https://salsa.debian.org/installer-team/rootskel/-/merge_requests/8

Although this does prompt the question of why aarch64 has TERM set to 'vt102' at
this point, rather than 'linux'.

Also, I wonder whether there could be other circumstances when $TERM is set to
'vt102' where this change could be problematic (I'm guessing that the $TERM_TYPE
checks deal with that, but I'm not sure).

BTW This seems to have some overlap with #263137.

Cheers, Phil.

Bug#1014943: waybar: fork-awesome alternatives

[Philip Hands]

Package: waybar
Version: 0.9.17-2
Followup-For: Bug #1014943

Dear Maintainer,

I also hit this bug.

As mentioned Fork Awesome is available in Debian, so instead of these:

  0xf76b     temperature-low
  0xf769     temperature-high

one can use these:

  https://forkaweso.me/Fork-Awesome/icon/thermometer-empty/
0xf2cb      fa-thermometer-empty
  https://forkaweso.me/Fork-Awesome/icon/thermometer-full/
0xf2c7      fa-thermometer-full

For my own setup, I've also changed the brightness config, thus:

  // "format-icons": ["", "", "", "", "", "", "", "", ""]
  "format-icons": ["", ""]

using these:
  https://forkaweso.me/Fork-Awesome/icon/sun/
  https://forkaweso.me/Fork-Awesome/icon/sun-o/

(I've no idea what the original series of icons were supposed to be indicating,
but those two at least give one something that is brightness related, which
seems like a step forward.)

Oh, and I've just noticed that I'm yet to find an alternative for whatever the
symbol is meant to be when one is charging the battery.

Cheers, Phil.
-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing'), (99, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages waybar depends on:
ii  init-system-helpers 1.65.2
ii  libatkmm-1.6-1v52.28.3-1
ii  libc6   2.36-9
ii  libcairomm-1.0-1v5  1.14.4-2
ii  libdate-tz3 3.0.1+ds-5
ii  libdbusmenu-gtk3-4  18.10.20180917~bzr492+repack1-3
ii  libevdev2   1.13.0+dfsg-1
ii  libfmt9 9.1.0+ds1-2
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libglibmm-2.4-1v5   2.66.5-2
ii  libgtk-3-0  3.24.37-2
ii  libgtk-layer-shell0 0.8.0-1
ii  libgtkmm-3.0-1v53.24.7-1
ii  libinput10  1.22.1-1
ii  libjack-jackd2-0 [libjack-0.125]1.9.21~dfsg-3
ii  libjsoncpp251.9.5-4
ii  libmpdclient2   2.20-1+b1
ii  libnl-3-200 3.7.0-0.2+b1
ii  libnl-genl-3-2003.7.0-0.2+b1
ii  libpulse0   16.1+dfsg1-2+b1
ii  libsigc++-2.0-0v5   2.12.0-1
ii  libsndio7.0 1.9.0-0.3+b2
ii  libspdlog1.10 [libspdlog1.10-fmt9]  1:1.10.0+ds-0.4
ii  libstdc++6  12.2.0-14
ii  libudev1252.6-1
ii  libupower-glib3 0.99.20-2
ii  libwayland-client0  1.21.0-1
ii  libwireplumber-0.4-00.4.13-1
ii  libxkbregistry0 1.5.0-1

waybar recommends no packages.

Versions of packages waybar suggests:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
pn  libappindicator3-1  
ii  sway1.7-6

-- no debconf information

Bug#1036304: guix: /etc/profile.d/guix.sh not updated for 1.4.0

[Philip McGrath]

On Friday, May 19, 2023 5:58:06 PM EDT Vagrant Cascadian wrote:
> On 2023-05-18, Philip McGrath wrote:
> > Among other changes upstream, I changed it in
> > 23aafc800c9e678662766440916449ec5bbce830 to initialize various XDG
> > environment variables, fixing a bug that can prevent KDE Plasma sessions
> > from starting properly, instead leaving the user with a black screen. I
> > encountered that bug again today when I logged back in after running
> > `guix home reconfigure` for the first time on a new Bookworm
> > installation. I described the problem in more detail upstream in
> > https://issues.guix.gnu.org/56050 and the linked mailing- list thread.
> 
> This sounds suspiciously similar to a long outstanding debian bug:
> 
>   https://bugs.debian.org/988260
> 
> So if updating this would solve that, that is really promising!
> 

I saw that debian bug when reporting this, and I haven't read it very closely, 
but it reminded me of a problem I had caused by an unnecessarily propagated 
input to emacs-next-pgtk: https://issues.guix.gnu.org/57421 My patch hasn't 
been merged upstream, but I make the same change to in my home-
configuration.scm.

> > Note also that the file was renamed to zzz-guix.sh in
> > 93be56a3ab28ed0a482f354b7f536681c99b6999.
> 
> Hrm. that will be a little bit trickier to change...
> 

IMO that change seems less important, since at least my bookworm system 
doesn't have the /etc/profile.d/xdg_dirs_desktop_session.sh mentioned in the 
commit message. Updating guix.sh without renaming was enough to fix things for 
me.

> 
> It is, unfortunately, very late in the bookworm release cycle... might
> have to wait till bookworm's first point release... will see how
> invasive the changes are.
> 

Understandable—late enough that I'm installing it on my desktop! Thanks for 
taking a look.
Philip




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

Bug#1036304: guix: /etc/profile.d/guix.sh not updated for 1.4.0

[Philip McGrath]

Package: guix
Version: 1.4.0-3
Severity: important
X-Debbugs-Cc: phi...@philipmcgrath.com

Dear Maintainer,

The /etc/profile.d/guix.sh script was not updated for 1.4.0, or indeed 
seemingly since it was first added to the Debian package to address #985916.

Among other changes upstream, I changed it in 
23aafc800c9e678662766440916449ec5bbce830 to initialize various XDG environment 
variables, fixing a bug that can prevent KDE Plasma sessions from starting 
properly, instead leaving the user with a black screen. I encountered that bug 
again today when I logged back in after running `guix home reconfigure` for the 
first time on a new Bookworm installation. I described the problem in more 
detail upstream in https://issues.guix.gnu.org/56050 and the linked mailing-
list thread.

Note also that the file was renamed to zzz-guix.sh in 
93be56a3ab28ed0a482f354b7f536681c99b6999.

Thanks for packaging Guix for Debian!
Philip


-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages guix depends on:
ii  guile-3.0   3.0.8-2
ii  guile-3.0-libs  3.0.8-2
ii  guile-gcrypt0.4.0-2
ii  guile-git   0.5.2-5
ii  guile-gnutls3.7.9-2
ii  guile-json  4.7.3-2
ii  guile-lzlib 0.0.2-3
ii  guile-sqlite3   0.1.3-3
ii  guile-ssh   0.16.2-1
ii  guile-zlib  0.1.0-4
ii  libbz2-1.0  1.0.8-5+b1
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libgcrypt20 1.10.1-3
ii  libsqlite3-03.40.1-2
ii  libssh-dev  0.10.4-2
ii  libstdc++6  12.2.0-14
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages guix recommends:
ii  ca-certificates  20230311
ii  less 590-1.2
ii  nscd 2.36-9
ii  systemd  252.6-1

guix suggests no packages.

-- no debconf information


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

Bug#1035598: /var/lib/dpkg/info/kanboard.postinst: 24: lighty-enable-mod: not found

[Philip Carinhas]

Kanboard uses a varitey of databases and webservers.
None of those dependencies should block installation.

-Phil 

-- 
.--,
| Fortuitous Technologies  -  DevOps, Design & Development |
| A Stitch in Design Saves Nine -  http://fortuitous.com   |
| Philip Carinhas, CEO * p...@fortuitous.com * 512-351-7783 |
 `-'


signature.asc
Description: PGP signature

Bug#1035343: racket: Consider using CS on all architectures

[Philip McGrath]

Package: racket
Version: 8.7+dfsg1-1
Severity: normal

Dear Maintainer,

Since at least Racket 8.6, the Racket CS implementation runs even on 
architectures for which it cannot generate native code. I suggest that the 
Debian should package Racket CS for all architectures instead of falling back 
to Racket BC for some, e.g. ppc64el.

I don't fully understand the nuances of the bookworm freeze policy. (I'm sorry 
I didn't report this sooner.) It seems at least plausible that this could be a 
"small, targeted fix[]", especially from the perspective that it would amount 
to bringing a few niche architectures to parity with the popular ones, but I 
could also understand an argument to the contrary.

Some background: Racket CS (based on "Chez Scheme") is the current default 
implementation, having replaced Racket BC ("Before Chez" or "ByteCode") with 
the release of Racket 8.0. Racket CS, like Chez Scheme, compiles to machine 
code, whereas Racket BC compiles to platform-independent bytecode. Initially, 
the recommendation from upstream was to fall back to Racket BC on 
architectures which Racket CS didn't support: Debian's packaging did so as of 
8.0+dfsg1-2 and 8.0+dfsg1-3.

However, Racket CS is now able to run even on architectures for which it 
cannot generate machine code. Initially, support for a "portable bytecode" 
backend was added to Racket's variant of Chez Scheme to simplify bootstrapping 
during development. Later, variants specialized to word size and endianness 
were added (e.g. "tpb64l", suitable for any 64-bit little-endian machine), as 
was basic support for chunks of this byte code to C (which was useful for Chez 
"boot files"). These improvements are sometimes referred to as "pbarch" and 
"pbchunk", respectively.

Ultimately, this worked well enough to make Racket CS viable on architectures 
without native compilation support. Performance is reportedly comparable to 
Racket BC on those architectures, which never had JIT support on Racket BC. 
Changing to Racket CS also enables Racket's "futures" and "places" for those 
architectures. Perhaps the most significant benefit, albeit less concrete, is 
getting those niche architectures onto the Racket implementation that is 
actively developed and used.

The new support was announced with the Racket 8.5 release, but a few pieces 
turned out to be missing: there's some discussion at [1]. I maintain the Guix 
package of Racket, and we enabled Racket CS on all architectures starting with 
Racket 8.6, in particular in [2] and [3]. (Our patches were complicated by the 
fact that we expose some of Racket's internals in ways Debian doesn't.)

I'd be glad to help with this as I can, with the caveats that I have very 
little time until next week, don't have any relevant hardware, and have only 
the tiniest amount of experience with Debian packaging (though I'm a long-time 
user of Debian and downstreams).

Thanks for maintaining Racket in Debian!
Philip McGrath

[1]: https://racket.discourse.group/t/950/27
[2]: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a15d72f
[3]: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ed24d6b


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

Bug#1035082: RFS: libfilezilla/0.42.2-1 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libfilezilla":

 * Package name : libfilezilla
   Version  : 0.42.2-1
   Upstream contact : Tim Kosse 
 * URL  : https://lib.filezilla-project.org/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/libfilezilla
   Section  : libs

The source builds the following binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent programs 
(translations)
  libfilezilla38 - build high-performing platform-independent programs (runtime 
lib)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libfilezilla/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.42.2-1.dsc

Changes since the last upload:

 libfilezilla (0.42.2-1) experimental; urgency=medium
 .
   * New upstream version 0.42.2
   * Soname bump rename package to libfilezilla38

Note: We have 0.42.0 in the experimental NEW queue, so this to supersede.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1034663: RFS: libfilezilla/0.42.0-1 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libfilezilla":

 * Package name : libfilezilla
   Version  : 0.42.0-1
   Upstream contact : Tim Kosse 
 * URL  : https://lib.filezilla-project.org/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/libfilezilla
   Section  : libs

The source builds the following binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent programs 
(translations)
  libfilezilla36 - build high-performing platform-independent programs (runtime 
lib)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libfilezilla/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.42.0-1.dsc

Changes since the last upload:

 libfilezilla (0.42.0-1) experimental; urgency=medium
 .
   * New upstream version 0.42.0
   * Soname bump rename package to libfilezilla36
   * d/watch: Use upstream preferred tar.xz tarball

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1034195: filezilla: Workaround package build for i386 included experimental - 3.63.2.1-4

[Philip Wyett]

Hi Gert,

I have used d/rules to work around the issue by adding the C(XX)FLAGS -msse4.1 
conditionally for
the i386 build.

I will look at how this can be made available for Bookworm, but we are in 
release freeze, so may
take time.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1034195: upstream gcc bug

[Philip Wyett]

On Thu, 2023-04-13 at 21:47 +0200, Gert van de Kraats wrote:
> Phil
> 
> I made an upstream issue at GCC:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504 .
> 
> Perhaps you can add other packages there, that have the same problem?

Hi Gert,

Thanks for that. Let us see what progress is made/resolution is reached.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1034195: Question

[Philip Wyett]

On Wed, 2023-04-12 at 22:47 +0200, Gert van de Kraats wrote:
> Hi Phil,
> 
> Thanks for soon reply.
> 
> What do you mean by upstream. I only know a ticket at filezilla, but 
> this is closed.
> 
> I think this is  a regression bug at gcc 12, but I could not find a 
> bugreport upstream or at Debian for gcc.
> 
> Greetings,
> 
> Gert

Hi Gert,

Sorry, when I mean upstream I do mean filezilla and communications with the 
project indicates no
real interest in the 32-bit x86 build these days with the fact that 64-bit x86 
has now been out for
a couple of decades.

I did allocate this bug to gcc under Debian and they threw it back as a 
filezilla bug.

I will give some time to this again in a few days (when I am free) and we can 
see what we can do.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1034195: GCC bug

[Philip Wyett]

On Wed, 2023-04-12 at 15:45 +0200, Gert van de Kraats wrote:
> I saw the problem already is known at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020327
> and
> https://trac.filezilla-project.org/ticket/12777
> 
> I downloaded source filezilla-3.63.2.1 from filezilla website and got
> the same problem as mentioned at that bug:
> 
> gcc -DHAVE_CONFIG_H   -I../../../src/putty -I../../config -DNO_GSSAPI 
> -D_FILE_OFFSET_BITS=64  -fpch-preprocess  -g -O2 -Wall -MT 
> libfzputtycommon_a-sshsha.o -MD -MP -MF 
> .deps/libfzputtycommon_a-sshsha.Tpo -c -o libfzputtycommon_a-sshsha.o 
> `test -f 'sshsha.c' || echo '../../../src/putty/'`sshsha.c
> In file included from /usr/lib/gcc/i686-linux-gnu/12/include/immintrin.h:98,
>   from ../../../src/putty/sshsha.c:347:
> /usr/lib/gcc/i686-linux-gnu/12/include/avx512fp16intrin.h:38:9: error: 
> ‘_Float16’ is not supported on this target
> 
> I changed the Makefile at src/putty and added -msse4.1 to CFLAGS and
> CXXFLAGS.
> After this change I could compile filezilla without a problem.
> Installing filezilla gave some problems because the files are not
> installed at the right location, but with some symbolic links
> filezilla works without a problem.
> According to "cat proc/cpuinfo" my cpu supports sse and sse2.
> 
> Like Tim Kosse I think this is a gcc-12-bug, not a filezilla-bug.
> I do not see any changes in this area at filezilla since previous
> release filezilla-3.57.0.
> If I compile sshsha.c at that release with gcc-12, I get the same error.
> If I compile sshsha.c at both releases with gcc-11, I get no error.
> 
> If a pragma GCC target is activated for some source, then the
> compiler should not generate an error if the build target is not
> supporting this. This makes cross-compilation impossible.
> 
> In that case it is the responsibility of the programmer to assure that
> this code is only executed if the specified target is available.
> 
> I think   pragma GCC target sse4.1 (locally) and -msse4.1 (globally)
> should do the same thing.

Hi,

If you wish to add this to the upstream bug report, I will look at testing it 
on the i386 builders
if and when it makes it into a release.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1034195: filezilla: Filezilla not available anymore at i386

[Philip Wyett]

On Mon, 2023-04-10 at 23:23 +0200, Gert van de Kraats wrote:
> Source: filezilla
> Version: 3.63.0-1
> Severity: important
> 
> Dear Maintainer,
> 
> Recently I automatically upgraded to version 3.63.0-1.
> With this version the package and binary filezilla is no longer available at
> i386 architecture (32 bits).
> 
> This is also visible at the Debian package overview for filezilla.
> The common filezilla are delivered. Also libfilezilla34 still is 
> delivered at
> i386.
> 
> 
> -- System Information:
> Debian Release: 12.0
> APT prefers testing-security
> APT policy: (500, 'testing-security'), (500, 'testing')
> Architecture: i386 (i686)
> 
> Kernel: Linux 6.1.0-7-686-pae (SMP w/2 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Hi Gert,

As with many developers, the upstream filezilla has employed CPU features i.e. 
sse2 that is not
enabled on the Debian i386 build servers. This is their right and meant 
exclusion from i386 of
filezilla. I am sorry if this is an issue, but unavoidable and has been the 
case for many packages
that are no longer available on i386.

libflezilla does not as yet employ CPU features that would cause exclusion from 
i386 and being a
library, could be used by other applications. This is why I felt it best to 
leave its i386 build
intact.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#913431: Debian Installer Bullseye RC 2 release

[Philip Hands]

Hi Vincent,

I've applied your patch and pushed it to to salsa (my fork) to get it
built by CI ... which failed, because of the use of ${X/...} and
${X:...}, which it seems busybox doesn't like.

So I've changed that code, and added a couple of other tweaks, as you
can see here:

  https://salsa.debian.org/philh/partman-base/-/commits/bug/913431

Perhaps you can look at the result, and check that it still does what
you intended, and pick anything you like out of the rest.

BTW the working pipeline build includes the creation of a mini-ISO image
(once one kicks branch2repo into action), that should allow this code to
be tested in D-I:

  
https://salsa.debian.org/installer-team/debian-installer/-/jobs/4087808/artifacts/file/public/gtk-mini.iso

HTH

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1031844: RFS: libfilezilla/0.41.1-1 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libfilezilla":

 * Package name : libfilezilla
   Version  : 0.41.1-1
   Upstream contact : Tim Kosse 
 * URL  : https://lib.filezilla-project.org/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/libfilezilla
   Section  : libs

The source builds the following binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent programs 
(translations)
  libfilezilla35 - build high-performing platform-independent programs (runtime 
lib)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libfilezilla/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.41.1-1.dsc

Changes since the last upload:

 libfilezilla (0.41.1-1) experimental; urgency=medium
 .
   * New upstream version 0.41.1
   * Soname bump rename package to libfilezilla35

Regards

Phil

--

*** Playing the game for the games own sake. ***

Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1031195: os-autoinst: FTBFS on several release architectures

[Philip Hands]

Control: reopen -1

It seems that the initial attempt to fix this bug was a failure, so I'm
reopening the bug and will attempt to do a proper job shortly.

Cheers, Phil.

Bug#1026027: graphical installer: using nano in a installer shell fails

[Philip Hands]

Control: tags -1 + pending

Sven Joachim  writes:
...
> I have attached the obvious patch.

Here's your patch:

  https://salsa.debian.org/philh/debian-installer-utils/-/tree/sven-bug/102602

which generates this mini ISO:

  
https://salsa.debian.org/installer-team/debian-installer/-/jobs/3960725/artifacts/file/public/gtk-mini.iso

wherein the bug is fixed.

That being the case, I've pushed it into the master branch.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#993155: O: ssh-askpass -- under X, asks user for a passphrase for ssh-add

[Philip Hands]

Control: retitle -1 O: ssh-askpass -- under X, asks user for a passphrase for 
ssh-add

I am now orphaning this package.

The previous logic (from this RFA) still applies, but in addition to
that, I'm no longer even running X, having switched to Wayland, so my
ability to test this package has diminished yet further.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#1031220: grub-installer: variable $device_map used without being defined

[Philip Hands]

Source: grub-installer
Severity: minor

Hi,

While looking at the grub-installer script, shellcheck highlighted the fact that
we appear to be using the variable $device_map in grub-installer, without it
being defined.

A grep of the D-I source tree for 'device_map=' found nothing, so it seems it's
not being set in an included library either.

git history reveals that it used to be set[1], until f97462fcb which was
removing a load of device.map related code as a merge from Ubuntu, so I guess
this is just some detritus that got missed at that point and happend to cause no
problems since.

That's presumably because that code only gets executed if the boot device
matches ``[hf]d[0-9]*'', which I'm guessing is either never or rarely.

If it ever does match, this gets run[2,3]:

   bootdisk="$(grep -v '^#' $device_map | grep "^ *$bootdev_nopart" \
| sed 's/^ *(.*)[[:space:]]*\(.*\)/\1/')"

which I'd expect to hang, waiting on the first grep's STDIN (unless STDIN is
redirected from /dev/null, or some such, at the time).

If the condition regarding the boot device is ever likely to be true, then this
code ought to be fixed, or at least the two cases in question could be changed
to throw a meaningful error, so that people can report useful bugs about it.
Otherwise, the obsolete code should be removed.

I'm happy to create an MR once I know which option is required.

Cheers, Phil.

[1]  
https://salsa.debian.org/installer-team/grub-installer/-/commit/f97462fcbb4bbeb4a600c30ddc84a88#ae6e84c2dbfeefe14b039001e1b64254dada292b_81_78
[2]  
https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L1066
[3]  
https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L1077

Bug#1030585: Re : Bug#1030585 closed by Philip Wyett (reply to philip.wy...@kathenas.org) (Re: Bug#1030585: filezilla: Does not upgrade)

[Philip Wyett]

On Wed, 2023-02-08 at 14:12 +0100, nicolas.patr...@gmail.com wrote:
> ==quoted message from Philip Wyett , subject 
> “Re: Bug#1030585:
> filezilla: Does not upgrade”==
> 
> > Closing.
> 
> OK, but why?
> Filezilla is removed from Debian?
> 
> Yours,
> nicolas patrois : pts noir asocial

Hi,

As stated on the report prior to closing, see below.

Upstream requires SSE2, which is not provided in the Debian i386 builder(s). 
Because of this
filezilla for i386 is no longer built for bookworm/sid as of version 3.62.2-1.

Apologies for it no longer being available on your architecture.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1030585: filezilla: Does not upgrade

[Philip Wyett]

Control: tags -1 + upstream wontfix

Hi,

Upstream requires SSE2, which is not provided in the Debian i386 builder(s). 
Because of this
filezilla for i386 is no longer built for bookworm/sid as of version 3.62.2-1.

Apologies for it no longer being available on your architecture.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1030303: install tmpfiles and sysusers config into correct path

[Philip Hands]

Michael Biebl  writes:

> I noticed that openqa and openqa-worker install its tmpfiles and
> sysusers configuration files into /lib.

IIRC Originally the instalation into /lib was done in order to deal with
the fact that dh_installsystem seemed not to notice them under /usr/lib.

I presumed that would get fixed at some point, and intended to revert
to installing them into their upstream location once that's done.

However, I was also under the impression that we were supposed to be
refraining from moving files between /lib/ and /usr/lib until after
usr-merge was sorted out, in order to avoid issues with dpkg, so wasn't
planning on touching this until that is all settled, just in case
the openqa packages need rearanging at some point (since moving files
between packages is what provokes that problem)

I'd be happy to be proven wrong on this, as that would allow me to
discard the special case from the install file.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1029616: perltidy: please package upstream 20221112 release

[Philip Hands]

Package: perltidy
Version: 20220613-1
Severity: normal

Hi Don,

I notice that upstream has released 20221112 (prompted by the fact that upstream
openqa has a versioned depends on that new version)

I knocked up a new version of the package, which is visible here:

  https://salsa.debian.org/philh/perltidy

but which provokes lintian to say that there are sources missing:

  
https://philh.pages.debian.net/-/perltidy/-/jobs/3847974/artifacts/debian/output/lintian.html

which seems to be because the pod files under ./local-docs/ in the upstream git
repo don't make it into the tarballs.

I guess one could put them back in, or start basing the package on the git tags
instead of the tarballs -- that seems like a decission for the maintaner, so
I'll leave it up to you.

Regarding tags: I note that they have also used tags of the form 20221112.03
which presumably either mean point releases of 20221112 or pre-releases of the
next actual release, but I'm not sure which, or whether that should be
considered a version to package.

HTH

Cheers, Phil.

Bug#1021211: remmina: switch to libsoup3

[Philip Wyett]

On Mon, 2023-01-23 at 10:35 +0100, Andre Heider wrote:
> Can we please have spice back?
> 
> It's been half a year, and my patch with an alternative solution still 
> works fine with 1.4.29 (which is what I'm using for that period on a 
> daily basis):
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015147#27
> 
> Thanks,
> Andre
> 

Hi,

All related issues were solved in version 1.4.28, so the 1.4.29 in unstable can 
have builds re-
enabled for spice and www plugins.

However... Please be sensitive in fixes for backport builds as this package is 
in bullseye
backports. 1.4.29 can be built with both 'libsoup2.4 and webkit2gtk 4.0' and 
'libsoup3 and
webkit2gtk 4.1' with spice and www plugins enabled.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1028475: Backport recent GVariant security fixes to Stable

[Philip Withnall]

On Sat, 2023-01-14 at 21:15 +0100, Salvatore Bonaccorso wrote:
> Hi Simon,
> 
> Thank you for adding looping in.
> 
> On Thu, Jan 12, 2023 at 10:10:35AM +, Simon McVittie wrote:
> > Control: tags -1 + security
> > 
> > On Wed, 11 Jan 2023 at 16:37:01 +, Philip Withnall wrote:
> > > Are there plans to backport the recent GVariant security fixes to
> > > Debian Stable?
> > > 
> > > These are:
> > >  - https://gitlab.gnome.org/GNOME/glib/-/issues/2782
> > >  - https://gitlab.gnome.org/GNOME/glib/-/issues/2121
> > >  - https://gitlab.gnome.org/GNOME/glib/-/issues/2540
> > >  - https://gitlab.gnome.org/GNOME/glib/-/issues/2794
> > >  - https://gitlab.gnome.org/GNOME/glib/-/issues/2797
> > >  - https://gitlab.gnome.org/GNOME/glib/-/issues/2840
> > >  - https://gitlab.gnome.org/GNOME/glib/-/issues/2841
> > > 
> > > In addition, these two issues have highly related fixes (which
> > > it’s
> > > probably easiest to backport in the same tranche), but they are
> > > not
> > > security issues:
> > >  - https://gitlab.gnome.org/GNOME/glib/-/issues/2612
> > >  - https://gitlab.gnome.org/GNOME/glib/-/issues/2839
> > > 
> > > Apologies if a decision has been deliberately taken to not
> > > backport
> > > them, I don’t fully understand the criteria for what gets
> > > backported.
> > 
> > There are actually two sets of criteria for what gets backported to
> > stable. If the Debian security team (Cc'd) thinks an issue is
> > sufficiently
> > serious to need a security advisory and an immediate release, then
> > they
> > prepare a security update, either doing the work themselves or
> > coordinating
> > with the package's maintainer for the actual code changes.
> > 
> > If the security team are not interested in an issue, but the
> > package's
> > maintainer thinks the issue needs a stable update, then the
> > package's
> > maintainer coordinates with the release team to get the change into
> > the
> > next stable point release, which happens once per 1-2 months.
> > 
> > I think these issues are all denial-of-service, which the security
> > team
> > usually treats as not sufficiently important for an advisory and an
> > off-schedule fix. Security team: do you agree, based on the
> > information
> > quoted below? If yes, we can treat this as a low-priority security
> > fix
> > (I would personally rate its severity at somewhere between
> > important
> > and minor) and fix it in a point release later.
> 
> I do agree, a point release update seems enough (if feasible, in
> backport size and confidence).

Makes sense to me. Thanks both for considering this.

Philip

Bug#1028529: RFS: libfilezilla/0.41.0-1 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

On Sat, 2023-01-14 at 16:48 +0100, Adam Borowski wrote:
> On Fri, Jan 13, 2023 at 05:15:29AM +0000, Philip Wyett wrote:
> > I thought any change to push soname bumps through experimental was still 
> > only a discussion?
> > 
> > As you are aware, libfilezilla is only consumed by filezilla and any
> > soname bumps are not dangerous to other libaries or applications.  Could
> > this change pass through directly to unstable if I modify the changelog to
> > state this fact?
> 
> I think so, yeah.
> 
> 
> Meow!

Hi,

I have updated the upload to mentors with the following changelog entry:

libfilezilla (0.41.0-1) unstable; urgency=medium

   * New upstream version 0.41.0
   * Soname bump rename package to libfilezilla34
 - Only additions to API in this release
 - Only consumed by filezilla, so low risk soname bump

I hope this this will be enough to allow for sponsorship and a direct upload to 
unstable.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#748901: fixed in upstream git

[Philip Hands]

Hi,

This seems to be the upstream issue relating to this bug:

  https://github.com/corecode/dma/issues/89

which was closed with this commit:

  
https://github.com/corecode/dma/commit/7024d2e27873598792f095ff832d345388fa4827

which is pretty trivial, so could either be backported or one could
perhaps start shipping the unreleased version out of git.

I'll be making my own version of dma for local use, as this bug is a bit
of a disaster, but for others that are not aware that it's dma that's
sabotaging their mail setup, I would say that this bug needs fixing
urgently.

I'll happily do an NMU with just the single commit applied, if that helps.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#1028529: RFS: libfilezilla/0.41.0-1 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

On Thu, 2023-01-12 at 18:04 +0100, Adam Borowski wrote:
> On Thu, Jan 12, 2023 at 12:05:10PM +0000, Philip Wyett wrote:
> >  libfilezilla (0.41.0-1) unstable; urgency=medium
> >  .
> >* New upstream version 0.41.0
> >* Soname bump rename package to libfilezilla34
> 
> Hi,
> the ftp team has requested that soname bumps go through experimental,
> because of transition freeze, and that requests to do otherwise are
> clearly marked in the changelog, saying why.
> 
> 
> Meow!

Hi,

I thought any change to push soname bumps through experimental was still only a 
discussion?

As you are aware, libfilezilla is only consumed by filezilla and any soname 
bumps are not dangerous
to other libaries or applications. Could this change pass through directly to 
unstable if I modify
the changelog to state this fact?

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1028529: RFS: libfilezilla/0.41.0-1 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libfilezilla":

 * Package name : libfilezilla
   Version  : 0.41.0-1
   Upstream contact : Tim Kosse 
 * URL  : https://lib.filezilla-project.org/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/libfilezilla
   Section  : libs

The source builds the following binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent programs 
(translations)
  libfilezilla34 - build high-performing platform-independent programs (runtime 
lib)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libfilezilla/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.41.0-1.dsc

Changes since the last upload:

 libfilezilla (0.41.0-1) unstable; urgency=medium
 .
   * New upstream version 0.41.0
   * Soname bump rename package to libfilezilla34

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1028475: Backport recent GVariant security fixes to Stable

[Philip Withnall]

Package: glib2.0
Version: 2.66.8-1
Tags: security

Are there plans to backport the recent GVariant security fixes to
Debian Stable?

These are:
 - https://gitlab.gnome.org/GNOME/glib/-/issues/2782
 - https://gitlab.gnome.org/GNOME/glib/-/issues/2121
 - https://gitlab.gnome.org/GNOME/glib/-/issues/2540
 - https://gitlab.gnome.org/GNOME/glib/-/issues/2794
 - https://gitlab.gnome.org/GNOME/glib/-/issues/2797
 - https://gitlab.gnome.org/GNOME/glib/-/issues/2840
 - https://gitlab.gnome.org/GNOME/glib/-/issues/2841

In addition, these two issues have highly related fixes (which it’s
probably easiest to backport in the same tranche), but they are not
security issues:
 - https://gitlab.gnome.org/GNOME/glib/-/issues/2612
 - https://gitlab.gnome.org/GNOME/glib/-/issues/2839

Apologies if a decision has been deliberately taken to not backport
them, I don’t fully understand the criteria for what gets backported.

---

There are two sets of risks in these issues:

1. Denial of service caused by handling a malicious serialised variant
which is structured to cause allocations or looping superlinear to its
serialised size. Applications are at risk if they accept untrusted
serialised variants by checking them with g_variant_get_normal_form()
(or don’t check them). Applications which reject variants with
g_variant_is_normal_form() first are not vulnerable. In order to be
exploitable, the variant must have a dynamically typed component in it
(i.e. a `v` type somewhere). This is typically as part of an `a{sv}`.

2. Denial of service caused by handling a malicious text-form variant
which is structured to cause looping superlinear to its text size.
Applications are at risk if they parse untrusted text-form variants.

Scenario 2 is much less likely than scenario 1, as the GVariant text-
form parser is not documented as suitable for use on untrusted input.
Scenario 1 is likely because g_variant_get_normal_form() *is*
documented as being safe to use on untrusted input.

Issue #2840 documents a heap buffer overflow, but this vulnerability
was introduced as part of the fixes for the above two scenarious, so
GLib is only vulnerable to the overflow if an incomplete set of patches
are backported.

---

I have a set of backport commits for this for GLib 2.70.4, which we are
using in Endless OS. At a quick glance, these commits should also be
most of the work needed for backporting to 2.66.8 in Debian Stable. I
am happy to help out with this if that’s useful.

Philip

Bug#1027729: RM: filezilla [i386] -- Upstream requires sse2, please remove i386

[Philip Wyett]

Package: ftp.debian.org
Severity: normal

Upstream requires sse2 and i386 does not support it, so building these binaries 
will no longer take
place on Debian.

Please remove the src:filezilla binaries from i386.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1027690: lmms: Segfault on startup with kwidgetsaddons 5.101.0

[Philip Chung]

Package: lmms
Version: 1.2.2+dfsg1-4+b3
Severity: grave
Tags: patch upstream
Justification: renders package unusable
Forwarded: https://github.com/LMMS/lmms/issues/6587

Dear Maintainer,

LMMS experiences a segmentation fault on startup. According to an 
upstream bug report [1], this appears to be due to a specific workaround 
for an old bug in KXMLGUI [2], which breaks with kwidgetsaddons 5.101.0.


As the comments on the upstream bug report suggest, a workaround is to 
downgrade kwidgetsaddons to 5.100.0. I can confirm that downgrading the 
libkf5widgetsaddons5 and libkf5widgetsaddons-data packages works on my 
system.


The fix for this segmentation fault is to remove the workaround [3], as 
the KXMLGUI bug has been fixed for some time (since version 5.55.0).


Philip Chung

[1] https://github.com/LMMS/lmms/issues/6587
[2] https://bugs.kde.org/show_bug.cgi?id=337491
[3] See this fix in another distribution: 
https://github.com/void-linux/void-packages/pull/41313

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lmms depends on:
ii  libasound21.2.8-1
ii  libc6 2.36-7
ii  libfftw3-single3  3.3.10-1
ii  libfltk1.31.3.8-5
ii  libfluidsynth32.3.0-1+b1
ii  libgcc-s1 12.2.0-11
ii  libgig10  4.3.0~ds1-2+b1
ii  libmp3lame0   3.100-6
ii  libogg0   1.3.5-3
ii  libportaudio2 19.6.0-1.2
ii  libpulse0 16.1+dfsg1-2+b1
ii  libqt5core5a  5.15.7+dfsg-2
ii  libqt5gui55.15.7+dfsg-2
ii  libqt5widgets55.15.7+dfsg-2
ii  libqt5xml55.15.7+dfsg-2
ii  libsamplerate00.2.2-3
ii  libsdl1.2debian   1.2.15+dfsg2-8
ii  libsndfile1   1.1.0-3+b1
ii  libsndio7.0   1.9.0-0.3+b1
ii  libsoundio2   2.0.0-2
ii  libstdc++612.2.0-11
ii  libstk-4.6.2  4.6.2+dfsg-2
ii  libvorbis0a   1.3.7-1
ii  libvorbisenc2 1.3.7-1
ii  libvorbisfile31.3.7-1
ii  lmms-common   1.2.2+dfsg1-4
ii  stk   4.6.2+dfsg-2
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages lmms recommends:
ii  caps 0.9.26-1
pn  lmms-vst-server  
ii  tap-plugins  1.0.0-1

Versions of packages lmms suggests:
ii  caps [ladspa-plugin] 0.9.26-1
pn  fil-plugins  
pn  fluid-soundfont-gm   
pn  freepats 
pn  mcp-plugins  
pn  omins
ii  tap-plugins [ladspa-plugin]  1.0.0-1

-- no debconf information

Bug#1025486: ModuleNotFoundError: No module named 'scrape_schema_recipe' / 'ebooklib'

[Philip Rinn]

Control: reopen -1

Hi,

it seems you forgot to add a depend/recommend on python3-scrape-schema-recipe:

philip@debian:~$ LANG=C apt list gourmand
Listing... Done
gourmand/testing,testing,unstable,unstable,now 1.1.0+really1.0.0-3 all 
[installed]

philip@debian:~$ gourmand
args = Namespace(db_url='', threads=False, gourmanddir='', 
thread_debug_interval=5.0, thread_debug=False, debug_file='', time=False, 
debug=None)

WARNING: Plugin module import failed
PATH: ['/usr/bin', '/usr/lib/python310.zip', '/usr/lib/python3.10', 
'/usr/lib/python3.10/lib-dynload', '/usr/local/lib/python3.10/dist-packages', 
'/usr/lib/python3/dist-packages', '/usr/lib/python3.10/dist-packages', 
'/usr/lib/python3/dist-packages/gourmand/plugins', 
'/usr/lib/python3/dist-packages/gourmand/plugins/import_export']

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gourmand/plugin_loader.py", line 300, in 
get_module

self._loaded = __import__(self.module)
  File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/web_import_plugin/__init__.py", 
line 1, in 

from . import generic_web_importer_plugin
  File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/web_import_plugin/generic_web_importer_plugin.py", 
line 6, in 

from gourmand.plugins.import_export.website_import_plugins.state import \
  File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/website_import_plugins/__init__.py", 
line 1, in 

from . import (about_dot_com_plugin, allrecipes_plugin,
  File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/website_import_plugins/allrecipes_plugin.py", 
line 3, in 

from . import schema_org_parser
  File 
"/usr/lib/python3/dist-packages/gourmand/plugins/import_export/website_import_plugins/schema_org_parser.py", 
line 7, in 

import scrape_schema_recipe
ModuleNotFoundError: No module named 'scrape_schema_recipe'
WARNING: Failed to load plugin web_import_plugin


Best regards
Philip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027479: RFS: libfilezilla/0.40.0-1 -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "libfilezilla":

 * Package name : libfilezilla
   Version  : 0.40.0-1
   Upstream contact : Tim Kosse 
 * URL  : https://lib.filezilla-project.org/
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/debian/libfilezilla
   Section  : libs

The source builds the following binary packages:

  libfilezilla-dev - build high-performing platform-independent programs 
(development)
  libfilezilla-common - build high-performing platform-independent programs 
(translations)
  libfilezilla33 - build high-performing platform-independent programs (runtime 
lib)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/libfilezilla/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.40.0-1.dsc

Changes since the last upload:

 libfilezilla (0.40.0-1) unstable; urgency=medium
 .
   * New upstream version 0.40.0
   * Soname bump rename package to libfilezilla33
   * Update Standards-Version to 4.6.2.0 - No changes required
   * Update 'copyright' year to 2023

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1016963: Please test u-boot for a64-olinuxino-emmc

[Philip Rinn]

On 29.12.22 at 01:14, Vagrant Cascadian wrote:

If you have access to any of these boards, please consider testing
u-boot versions as packaged in debian for versions from debian stable
(2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
(2023.01-rc*) and updating the wiki page if successful and/or replying
to 1016...@bugs.debian.org with a positive confirmation...

...and if not successful, filing bugs against the relevent u-boot-*
packages and marking them as blocking 1016963.


a64-olinuxino-emmc


I tested all four versions and they work on my A64-Olinuxino-eMMC board. [Tested 
from and updated unstable installation.]


Best,
Philip

Bug#1027411: rednotebook: en_GB translation uses German word "Zurück" for "Back"

[Philip Wyett]

On Sat, 2022-12-31 at 06:07 +, Philip Wyett wrote:
> On Sat, 2022-12-31 at 13:59 +1300, Ash Joubert wrote:
> > There are more: the navigation dropdown has Vorwärts (Forwards), and the 
> > Help menu has a German entry (with German tooltip) for "Give Feedback". 
> > Everything else is in English. I do not speak German and have never used 
> > a German locale on any computer.
> > 
> > Kind regards,
> > 
> 
> Hi,
> 
> Thanks for the bug report.
> 
> I have reproduced and filed a bug upstream. See link below.
> 
> https://github.com/jendrikseipp/rednotebook/issues/659
> 
> Regards
> 
> Phil
> 

Fixed version 2.29 has been uploaded to unstable/sid and will appear in due 
course.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#1027411: rednotebook: en_GB translation uses German word "Zurück" for "Back"

[Philip Wyett]

On Sat, 2022-12-31 at 13:59 +1300, Ash Joubert wrote:
> There are more: the navigation dropdown has Vorwärts (Forwards), and the 
> Help menu has a German entry (with German tooltip) for "Give Feedback". 
> Everything else is in English. I do not speak German and have never used 
> a German locale on any computer.
> 
> Kind regards,
> 

Hi,

Thanks for the bug report.

I have reproduced and filed a bug upstream. See link below.

https://github.com/jendrikseipp/rednotebook/issues/659

Regards

Phil

-- 
*** Playing the game for the games own sake. ***


Associations:

* Debian Maintainer (DM)
* Fedora/EPEL Maintainer.
* Contributor member of the AlmaLinux foundation.

WWW: https://kathenas.org

Buy Me a Coffee: https://www.buymeacoffee.com/kathenasorg

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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