Bug#772204: dput: .orig.tar.gz for non -1 package for security-master

[Osamu Aoki]

Hi Ben,

Thanks for thinking about dput.

(TBH, I don't use dput/dupload much since I use dgit)

On Mon, 2024-04-08 at 07:46 +1000, Ben Finney wrote:
> Control: severity -1 minor
> Control: tags -1 - moreinfo
> Control: merge 706607 -1
> 
> On 28-Aug-2016, Ben Finney wrote:
> 
> > Is this behaviour the same problem reported in [bug#706607], or is that a
> > separate problem?

FYI:

These 2 bug reports are not talking the same triggering conditions.  But fix may
be a single path since these are around the same message.  So merging these are
valid action :-)

* https://bugs.debian.org/772204
  * This is for security upload situation
  * Upload requires to have orig.tar.gz for all security uploads
  * Adjusting message is requested to be clear.

* https://bugs.debian.org/706607#21
  * This is for normal upload case.
  * Upload doesn't require to have orig.tar.gz for usual uploads.
  * Bug hits when used for derivative dists which uses -0 or similar as
"revision"

Here, "revision" means string matched for P.

If I understand correctly, requiring orig.tar.gz upload for "revision" -1 is
only for uploading to Debian repository.  Ubuntu or other derivatives such as
Kali start their "revision" from -0 or similar.

706607 talks interesting corner case for the upstream version which may contain
"-" in it.

706607 talks valid phrase adjustment but that's not enough to address situation
described in 772204.

In light of these, I think following are needed.

Action 1:
* Fix REGEX to accommodate -0 variants and upstream version with "-".

Action 2:
* Adjust message to address rejection condition and repository policy


I hope you addressed both pending actions.

Regards,

Osamu

Bug#1067132: RFP: incus-ui-canonical -- Incus-UI-Canonical is a browser frontend for Incus (patched LXD-UI)

[Osamu Aoki]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: 1036...@bugs.debian.org, 1067...@bugs.debian.org, 
pkg-javascript-de...@lists.alioth.debian.org

* Package name: incus-ui-canonical
  Version : 0.6
  Upstream Contact: Canonical, zabbly, os...@debian.org (See below)
* URL : https://github.com/osamuaoki/incus-ui-canonical
* License : GPL-3
  Programming Lang: HTML, JavaScript, TypeScript
  Description : Incus-UI-Canonical is a browser frontend for Incus (patched 
LXD-UI)


 incus-ui-canonical is a browser frontend for Incus. It enables easy and
 accessible container and virtual machine management. Targets small and
 large scale private clouds.

 This enhances user experience of incus users.

 This RFP needs help by a person familiar with Node.js, Typescript, etc.

 Background:

 Canonical's actions around relicensing LXD and Linuxcontainer.org's
 reaction of starting Incus as the LXD alternative made Debian to move to
 Incus for Trixie.

 Canonical was shipping LXD's browser frontend LXD-UI as a snap package
 but it never got packaged for Debian.
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036926

 After the fork, incus upstream associated zabbly started to ship latest
 incus deb package on his site while bundling patched LXD-UI with
 rebranding etc.  His packaging method was an interesting one focusing
 on creating a binary package using github workflow, it was not
 compatible with normal Debian packaging practices.

   https://github.com/canonical/lxd-ui (Canonical LXD-UI)
   https://github.com/zabbly/incus (zabbly's incus package builder)
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067041

 Updating Debian's incus package to include web frontend is not a
 option.  So current Debian incus package lacks web frontend since it
 only relies on https://github.com/lxc/incus.

 Basically, I created https://github.com/osamuaoki/incus-ui-canonical by
 applying patches from zabbly on Canonical's LXD-UI (version 0.6) to
 adopt zabbly's work into more Debian package friendly format.

 Although the resulting web frontend is a static single html page with
 lots of javascripts, building them requires lots of node codes which
 hasn't been packaged for Debian yet.  The build script currently used
 in https://github.com/osamuaoki/incus-ui-canonical access external
 repository, thus isn't ready for Debian.  So consider this as a
 baseline code which needs more work.  Thus this RFP needs help by a
 person familiar with Node.js, Typescript, etc.

 According to zabbly, Incus UI (Equivalent of which, this package tries
 to offer as a normal deb-package) is a single-page application written
 in TypeScript and React and only replicates what you can do with the
 incus CLI program (i.e. works through the REST API).  This is the
 reason behind why zabbly using LXD-UI based code and not other possible
 UIs:

   https://github.com/PenningLabs/lxconsole (PYTHON)
   https://github.com/AdaptiveScale/lxdui (PYTHON)
   https://github.com/turtle0x1/LxdMosaic (JS with SQL)
   https://github.com/lxdware/lxd-dashboard (PHP)

 Some interesting background can be found:

   https://stgraber.org/2023/11/25/adding-a-web-ui-to-the-incus-demo-service/
   https://discuss.linuxcontainers.org/t/web-ui-for-incus/18198
   
https://discuss.linuxcontainers.org/t/stateful-uis-and-questions-about-lxd-ui-history/18302
   https://discuss.linuxcontainers.org/t/incus-web-ui-spacing/18928
   https://discuss.linuxcontainers.org/t/lxconsole-as-web-ui/19212

 Other distro related info:
   https://github.com/KosmX/incus-ui-canonical-arch Arch Linux package
   https://gist.github.com/vaxvhbe/ce679df15fc521c8aca1ff9ddf537201 RPM spec 
file?

Osamu

Bug#1067041: Please also include "Incus UI"

[Osamu Aoki]

Hi,

I actually made a hackish binary package for "Incus UI".

  https://github.com/osamuaoki/incus-ui-canonical

At least, this is more compatible with official Debian package.  (I know this is
not ready for Debian upload at all.)

I realize that the current Debian package doesn't seem to set INCUS_UI.

Do you plan to set it to `/var/lib/incus/ui`?  I think that is better place to
put web page for distribution if it ever happens.

Or should I need to set it through `/etc/environment`?

I think someone with interest and good skill on typescript and node needs to
work on this to make real debian package.

Osamu

Bug#1067041: Please also include "Incus UI"

[Osamu Aoki]

Hi,

When I initially start writing this wishlist bug report, I was expecting
existence of one upstream source tree. The more I checked situation around
incus-ui, I concur with your thought and see more challenges for packaging.

Although I have no idea for typescript nor node, I realize that, though the
building lxd-ui was trivial task on my local Debian machine, it is a non-trivial
task for Debian packaging unless I dare to package many node packages.

I found 2 references for existing packaging efforts (ARCH and SPEC for some RPM)
 * https://gist.github.com/vaxvhbe/ce679df15fc521c8aca1ff9ddf537201 SPEC
 * https://github.com/KosmX/incus-ui-canonical-arch/blob/master/PKGBUILD ARCH
 
So I tried on my local machine to build unmodified source as a starter:

 $ sudo apt install yarnpkg npm
 $ git clone https://github.com/canonical/lxd-ui.git
 $ cd lxd-ui
 $ yarn install
 $ yarn build

Then I easily had a static web page with javascript to serve at
  build/ui/

I realize zabby's patches to make Incus UI were applied to the upstream LXD-UI
source, so it wasn't as brute force changes as I was afraid of.  But, as I
checked in the build tree under node-modules/, there are too many packages
(~600) involved.  This means there is a heavy burden of creating an official deb
package since all these packages need to be packaged in advance for Debian to
satisfy the Debian build requirement.  Then, on the top of it, there is an issue
of maintaining patches as you mentioned.

If I will file a RFP, I should do it as a fresh one to get the best exposure
(instead of retitle ITP or this bug report.)

Let me record few references I found.

Debian
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067041 this wishlist bug
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036926 closed ITP lxd-ui

Upstream message around web-ui
* https://stgraber.org/2023/11/25/adding-a-web-ui-to-the-incus-demo-service/
* https://discuss.linuxcontainers.org/t/web-ui-for-incus/18198/2
* https://discuss.linuxcontainers.org/t/incus-web-ui-spacing/18928
* https://discuss.linuxcontainers.org/t/lxconsole-as-web-ui/19212
*
https://discuss.linuxcontainers.org/t/stateful-uis-and-questions-about-lxd-ui-history/18302

Incus upstream doesn't wish to spend his time on this web page generation and
maintenance and provided proof-of-concept example by rebranding lxd-ui

Incus UI is a single-page application written in TypeScript and React and only
replicates what you can do with the incus CLI program (i.e. works through the
REST API).

Other UI -- all needs external dependencies
* https://github.com/PenningLabs/lxconsole (PYTHON)
* https://github.com/AdaptiveScale/lxdui (PYTHON)
* https://github.com/turtle0x1/LxdMosaic (JS with SQL)
* https://github.com/lxdware/lxd-dashboard (PHP)

Quoting Incus upstream:
Those more complex web interfaces will typically come with their own set of
instructions on how to properly deploy them, what OS they support to run their
daemon and database, how to setup the database for high-availability when in a
cluster environment, how to perform backups of that data, …

--- none of these seem to be good replacements of Incus UI(rebranded lxd-ui).

Regards,

Osamu

On Sun, 2024-03-17 at 22:40 +, Mathias Gibbens wrote:
> > Hi Osamu,
> > 
> >   Prior to the LXD/Incus hard fork, I did have an ITP to look at
> > packaging lxd-ui (#1036926). I think the "proper" way to package Incus
> > UI would be to have it as a new package (incus-ui), which incus
> > packaging could then Recommend or Suggest.
> > 
> >   I would also be more comfortable with Incus UI it was a proper fork
> > of Canonical's repository that carried the seven patches from
> > zabbly/incus. As a packager, we shouldn't be taking one upstream and
> > totally transforming it into something else via patches since that's
> > just too much work to carry in our packaging. :)
> > 
> >   My suggestion would be to rework this bug into a RFP and/or merge
> > with the prior ITP. I don't have any plans to work on this, but someone
> > else might.
> > 
> > Mathias

Bug#1067041: Please also include "Incus UI"

[Osamu Aoki]

Source: incus
Version: 0.6-1~bpo12+1
Severity: wishlist

I am using zabby's deb for incus on bookworm following:

  https://github.com/zabbly/incus

Unlike current Debian package, this deb installs files into /opt so this
is not compliant to the current Debian packaging policy.  This is quite
understandable since he is making these binary deb as the upstream
developer.

zabby's deb comes with nice feature of Incus UI.  With it, we can use
browser to manage incus.  All I have to get to the cute web UI is:

 $ incus config set core.https_address ":8443"
 $ firefox-esr https://localhost:8443

zabby's comment on web UI is at:
  https://discuss.linuxcontainers.org/t/web-ui-for-incus/18198

He basically uses generated static LXD-UI pages and rebranded with brute
force patching and seems to build deb binary package.  The github site
doesn't seem to be real Debian source tree.  The above git source only
exposes patches he used etc.

LXD-UI itself is available from Canonical with GPL3
  https://github.com/canonical/lxd-ui
It is a typescript source.

Providing the same page in /var/lib/incus/ui (instead of current
/opt/incus/ui) compliant to Debian policy should help user with updated
path configuration while compiling incus.  I am talking about
followings:

/opt/incus/ui
├── assets
│   ├── AutoExpandingTextArea-b0984bfa.js
│   ├── BaseLayout-da695259.js
│   ├── CancelOperationBtn-dfd3023a.js
│   ├── CertificateAdd-d4a7d2ae.js
│   ├── certificate-eda28c43.js
│   ├── CertificateGenerate-8ae719bf.js
│   ├── ClusterGroupForm-25c7ab41.js
│   ├── clusterGroups-6c3ae0ac.js
│   ├── ClusterList-0300f9c4.js
│   ├── ConfigFieldDescription-04cc287b.js
│   ├── CreateClusterGroup-c6ee6b8a.js
│   ├── CreateInstance-a4f78951.js
│   ├── CreateInstanceFromImageBtn-7f531769.js
│   ├── CreateNetwork-4e810edc.js
│   ├── CreateNetworkForward-22e93cd5.js
│   ├── CreateProfile-2069b1e2.js
│   ├── CreateProject-cecc9d43.js
│   ├── CreateStoragePool-55b5f272.js
│   ├── DiskSizeSelector-5b72fc84.js
│   ├── EditClusterGroup-b708f190.js
│   ├── EditNetworkForward-25840707.js
│   ├── formFields-f410667c.js
│   ├── FormFooterLayout-e758fca7.js
│   ├── FormMenuItem-5a280379.js
│   ├── HelpLink-57385562.js
│   ├── ImageList-a33f30ee.js
│   ├── images-20841d65.js
│   ├── images-8e8d15cf.js
│   ├── img
│   │   ├── favicon-32x32.png
│   │   └── incus-logo.svg
│   ├── index-100d4e14.js
│   ├── index-a1e42770.css
│   ├── index.esm-20fecc07.js
│   ├── instanceDelete-92f38617.js
│   ├── InstanceDetail-1dce84a0.js
│   ├── InstanceDetail-ff373be6.css
│   ├── instanceEdit-3e40081d.js
│   ├── InstanceFormMenu-21a11985.js
│   ├── InstanceList-49b398fa.js
│   ├── instanceValidation-3b4af1be.js
│   ├── instanceValidation-d51d9b53.css
│   ├── loadIsoVolumes-a8ddc0c0.js
│   ├── Login-25eed496.js
│   ├── Meter-cf3a0fcf.js
│   ├── NetworkDetail-a584b0b6.js
│   ├── NetworkDevicesForm-70bef83c.js
│   ├── NetworkForm-4b1a1351.js
│   ├── NetworkForwardForm-a6450899.js
│   ├── network-forwards-23e433d0.js
│   ├── NetworkList-d460bfff.js
│   ├── NetworkMap-8937e175.js
│   ├── networks-d1e4a90f.js
│   ├── NotificationRow-a23c7bb5.js
│   ├── OperationList-ccc34f7d.js
│   ├── operations-3c8573d9.js
│   ├── PageHeader-efb2fb2e.js
│   ├── ProfileDetail-aa5b79ee.js
│   ├── ProfileDetailsForm-cfb6fa83.js
│   ├── ProfileFormMenu-ffc77ee4.js
│   ├── ProfileList-62f69cf9.js
│   ├── ProfileSelector-90b3c743.js
│   ├── ProjectConfiguration-069a34e2.js
│   ├── ProjectForm-54c842f9.js
│   ├── ProtectedRoute-e9d1eae7.js
│   ├── RenameHeader-45fc28ec.js
│   ├── ScrollableTable-d58fc75b.js
│   ├── searchAndFilter-67115edd.js
│   ├── SelectableMainTable-a37bf25d.js
│   ├── SelectedTableNotification-9bffcb9e.js
│   ├── Settings-a73d738f.js
│   ├── settings-c23f9009.js
│   ├── SnapshotForm-be2640fe.js
│   ├── snapshots-78c0e63e.js
│   ├── Storage-dc687613.js
│   ├── StoragePoolDetail-c056ed2d.js
│   ├── StoragePoolSize-b4aaa57a.js
│   ├── StorageUsedBy-d3753f8f.js
│   ├── StorageVolumeCreate-1103f5ec.js
│   ├── storageVolume-dc1599e5.js
│   ├── StorageVolumeDetail-9514de93.js
│   ├── StorageVolumeForm-4ac2614e.js
│   ├── StorageVolumesFilter-1d98b8f2.js
│   ├── SubmitButton-c7658723.js
│   ├── TabLinks-be66fd30.js
│   ├── useClusterMembers-ab2fc364.js
│   ├── useDeleteIcon-9df3ee17.js
│   ├── useSortTableData-cb0187d4.js
│   ├── VolumeAddSnapshotBtn-11eaa84e.js
│   └── WarningList-8aeb56fe.js
└── index.html

3 directories, 90 files

For proper Debian packaging, using LXD-UI source as upstream and use
zabby's patch as post-build patch script may be easier.

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

Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/12 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

Bug#1065590: debmake: Debmake produces warnings about invalid escape sequence on Python 3.12

[Osamu Aoki]

Hi,

As I checked https://docs.python.org/3/whatsnew/3.12.html

   A backslash-character pair that is not a valid escape sequence now generates
   a SyntaxWarning, instead of DeprecationWarning. For example,
   re.compile("\d+\.\d+") now emits a SyntaxWarning ("\d" is an invalid escape
   sequence, use raw strings for regular expression: re.compile(r"\d+\.\d+")).
   In a future Python version, SyntaxError will eventually be raised, instead of
   SyntaxWarning. (Contributed by Victor Stinner in gh-98401.)
   
I suppose I need to use raw string explicitly.

This is nasty change which affects many code out there.  Sigh.

Osamu

On Wed, 2024-03-06 at 22:43 -0800, Loren M. Lang wrote:
> Package: debmake
> Version: 4.4.0-3
> Severity: minor
> 
> Dear Maintainer,
> 
> Using debmake on unstable with Python 3.12 installed. While installing
> debmake with apt-get, a long series of warnings were produced similar to
> this:
> 
> Setting up debmake (4.4.0-3) ...
> /usr/lib/python3/dist-packages/debmake/__main__.py:304: SyntaxWarning: invalid
> escape sequence '\/'
>   + ' -type f 2>&1 | sed -e "s/^debian\/'
> /usr/lib/python3/dist-packages/debmake/__main__.py:306: SyntaxWarning: invalid
> escape sequence '\/'
>   + '\///" | sort >../{0}.install.log'.format(para["package"])
> 
> The package should install cleanly without warnings. These warnings do
> not seem to affect the functionality as Python 3.12 simply falls back to
> 3.11 behavior after producing the warning.
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-21-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
> 
> Versions of packages debmake depends on:
> ii  devscripts  2.23.7
> ii  dpkg-dev    1.22.4
> ii  python3 3.11.8-1
> ii  python3-debian  0.1.49
> ii  rsync   3.2.7-1+b1
> 
> Versions of packages debmake recommends:
> ii  build-essential  12.10
> ii  curl 8.6.0-3
> ii  strace   6.5-0.1
> ii  wget 1.21.4-1+b1
> 
> Versions of packages debmake suggests:
> ii  autotools-dev 20220109.1
> pn  ccache    
> pn  cmake 
> pn  debmake-doc   
> pn  dgit  
> ii  dh-autoreconf 20
> ii  dh-python 6.20231223
> ii  eatmydata 131-1
> pn  gem2deb   
> ii  git   1:2.43.0-1
> ii  git-buildpackage  0.9.33
> pn  gitk  
> pn  javahelper    
> ii  lintian   2.117.0
> pn  mc    
> ii  quilt 0.67+really0.67-4
> pn  rpm2cpio  
> ii  sbuild    0.85.5
> 
> -- no debconf information

Bug#1058960: dpkg: warning: unable to delete old directory '/usr/share/debian-reference': Directory not empty

[Osamu Aoki]

Hi,

I overlooked this bug report.  Sorry for slow response.

Yep, I need to take care this generated file and symlink issue.

Let me think.  

In the mean time, I just fixed more important issue of clean install problem.

Osamu

On Tue, 2023-12-19 at 17:18 +0100, Sven Joachim wrote:
> On 2023-12-18 22:57 +0100, Christoph Anton Mitterer wrote:
> 
> > Package: debian-reference
> > Version: 2.109
> > Severity: normal
> > 
> > 
> > Hey.
> > 
> > Something looks odd with the package’s files registration in Debian.
> > On upgrade from 2.108 to 2.109 I got:
> > Unpacking debian-reference-common (2.109) over (2.108) ...
> > dpkg: warning: unable to delete old directory '/usr/share/debian-
> > reference/images': Directory not empty
> > Preparing to unpack .../01-debian-reference-en_2.109_all.deb ...
> > Unpacking debian-reference-en (2.109) over (2.108) ...
> > dpkg: warning: unable to delete old directory '/usr/share/debian-reference':
> > Directory not empty
> > 
> > 
> > And indeed, none of these files seem to belong to a Debian package:
> > $ dpkg -S /usr/share/debian-reference/images/*
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/images/caution.png
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/images/home.png
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/images/important.png
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/images/next.png
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/images/note.png
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/images/prev.png
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/images/tip.png
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/images/up.gif
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/images/warning.png
> > $ dpkg -S /usr/share/debian-reference/*
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/apa.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch01.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch02.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch03.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch04.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch05.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch06.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch07.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch08.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch09.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch10.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch11.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/ch12.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/debian-reference.css
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/debian-reference.en.pdf
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/debian-reference.en.txt.gz
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/images
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/index.en.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/index.html
> > dpkg-query: no path found matching pattern /usr/share/debian-
> > reference/pr01.en.html
> > 
> > These files do however seem to exist in the package, though registered as:
> > $ grep /usr/share/doc/debian-reference-common/docs
> > /var/lib/dpkg/info/debian-reference-common.list
> > /usr/share/doc/debian-reference-common/docs
> > /usr/share/doc/debian-reference-common/docs/.htaccess
> > /usr/share/doc/debian-reference-common/docs/debian-reference.css
> > /usr/share/doc/debian-reference-common/docs/images
> > /usr/share/doc/debian-reference-common/docs/images/caution.png
> > /usr/share/doc/debian-reference-common/docs/images/home.png
> > /usr/share/doc/debian-reference-common/docs/images/important.png
> > /usr/share/doc/debian-reference-common/docs/images/next.png
> > /usr/share/doc/debian-reference-common/docs/images/note.png
> > /usr/share/doc/debian-reference-common/docs/images/prev.png
> > /usr/share/doc/debian-reference-common/docs/images/tip.png
> > /usr/share/doc/debian-reference-common/docs/images/up.gif
> > /usr/share/doc/debian-reference-common/docs/images/warning.png
> > /var/lib/dpkg/info$ grep /usr/share/doc/debian-reference-common/docs
> > 

Bug#1063649: maint-guide: synatx error in setup instructions for sbuild

[Osamu Aoki]

Control: tags -1 pending


Hi,

Fixed in the salsa repo.


Thanks

On Sat, 2024-02-10 at 12:52 +, Nicholas Bamber wrote:
> Package: maint-guide
> Severity: important
> X-Debbugs-Cc: np.bam...@gmail.com
> 
> Dear Maintainer,
> 
> Hi Osamu,
> 
> 
> I think I found an error in section 3.6 (sbuild) of Guide for Debian
> Maintainers.
> 
> I think
> > $ sudo usermod -a -G  sbuild
> should be
> 
> > $ sudo usermod -a -G  sbuild 
> yours Nicholas
> 
> 
> -- System Information:
> Debian Release: 12.4
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-17-amd64 (SMP w/2 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 /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> maint-guide depends on no packages.
> 
> maint-guide recommends no packages.
> 
> Versions of packages maint-guide suggests:
> pn  debian-policy 
> pn  developers-reference  
> ii  devscripts    2.23.4+deb12u1
> pn  dh-make   
> pn  doc-base  
> ii  dput  1.1.3
> ii  fakeroot  1.31-1.2
> ii  lintian   2.116.3
> pn  pbuilder  
> ii  quilt 0.67+really0.66-1
> 

Bug#1061145: debmake: use python3 command for Python 3 packages instead of python command

[Osamu Aoki]

Hi,

Thanks for reminder.  That is my oversight.  (I may have been expecting python2-
>3 transition will include python command to be available back then... I don't
remember ...)

With python package moving to pyproject.toml, I am just repackaging one of my
python package.  For trixie, I suppose we need to fix this as:

```
python3 -m build
```

In bookworm (current stable), we needed setup.py even if it is an empty one.

But I need this to be in line with trixie

Osamu

On Fri, 2024-01-19 at 09:53 -0300, Ernesto Domato wrote:
> Package: debmake
> Version: 4.4.0-3
> Severity: normal
> X-Debbugs-Cc: edom...@gmail.com
> 
> Hi,
> 
> When I tried to use debmake to package a Python 3 only application, and even
> when I force it
> to -b":python3", debmake try to run "python setup.py" which is wrong and
> should
> use "python3 setup.py"
> 
> Thanks.
> Ernesto
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.6.11-amd64 (SMP w/8 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
> 
> Versions of packages debmake depends on:
> ii  devscripts  2.23.7
> ii  dpkg-dev    1.22.2
> ii  python3 3.11.6-1
> ii  python3-debian  0.1.49
> ii  rsync   3.2.7-1+b1
> 
> Versions of packages debmake recommends:
> ii  build-essential  12.10
> ii  curl 8.5.0-2
> ii  strace   6.5-0.1
> ii  wget 1.21.4-1+b1
> 
> Versions of packages debmake suggests:
> ii  autotools-dev 20220109.1
> pn  ccache    
> pn  cmake 
> ii  debmake-doc   1.17-9
> pn  dgit  
> ii  dh-autoreconf 20
> ii  dh-python 6.20231223
> ii  eatmydata 131-1
> pn  gem2deb   
> ii  git   1:2.43.0-1
> pn  git-buildpackage  
> ii  gitk  1:2.43.0-1
> pn  javahelper    
> ii  lintian   2.116.3
> ii  mc    3:4.8.30-1
> ii  quilt 0.67+really0.67-4
> pn  rpm2cpio  
> ii  sbuild    0.85.4
> 
> -- no debconf information

Bug#1063590: debian-reference-common: debian-reference and mkindexhtml are broken

[Osamu Aoki]

OOps.  I see.

On Fri, 2024-02-09 at 19:50 +0100, Jörg-Volker Peetz wrote:
> Package: debian-reference-common
> Version: 2.113
> Severity: important
> 
> Dear Osamu Aoki,
> 
> as far as I understand the scripts
> /usr/share/debian-reference-common/mkindexhtml and
> /usr/bin/debian-reference are broken since the move of the documents to
> /usr/share/doc/debian-reference-common/docs .
> The scripts still use /usr/share/doc/debian-reference as DR_DOC_ROOT
> which should now be /usr/share/doc/debian-reference-common .
> Therefore, during installation no index.html is generated and calling
> debian-reference fails silently.

Bug#1059244: grub-pc stops booting and its workaround

[Osamu Aoki]

Hi,

Follow-up to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059244

It looks like this problem has been around for 8 years.

I saw:  

Debian netinstall 8.1 i386 GRUB2 does not copy i386-pc modules to /boot/grub

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

There he was able to boot just with /boot (not with / like me) by using the same workaround as I did.

Anyway, I keep this bug separate so people will have easy time finding workaround by googling.

Regards

Osamu


Minor correction:
On Fri, 2023-12-22 at 01:34 +, Osamu Aoki wrote:

...

> ## Thoughts on the hardware configuration trigger:
> 
> Possible triggers I suspect:
> - /boot on /dev/sda5 (not on MBR primary partition /dev/sda1 etc.)
> - SSD size (500GB) and sector location of /boot


Here, I should have said

- `/` including `/boot` on /dev/sda5 (not on MBR primary partition /dev/sda1 etc.)  
- SSD size (500GB) and sector location of FS containing /boot

Bug#1059244: grub-pc stops booting and its workaround

[Osamu Aoki]

Package: grub-pc
Version: 2.06-13+deb12u1
Severity: normal
X-Debbugs-Cc: os...@debian.org

I hope this helps people who tries to install Debian stable on MBR.

(I think modifying grub-pc install script for stable package to do what
I manually did is rather a low risk change with decent benefits.  Please
consider.)

## Grub problem encountered and my workaround:

I encountered a dificult grub-pc install during my fresh install of
Bookworm/12 using NETINST USB to /dev/sda5 as root `/` holding partition
formatted as ext4.  Here, /dev/sda is 500GB SSD formatted to use MBR.

When I initially encountered this bug, system data such as /boot, /var
and /usr were on /dev/sda5.  So fancy mounting points listed below were
introduced after setting up my workaround to get grub-pc working.

When initially installed before my workaround, grub stoped booting
before showing the normal blue selection menu.  I get presented with the
"GRUB RESCUE>" prompt and I can type "ls" and it lists installed SSDs.

It complained on missing `/boot/grub/i386-pc/normal.mod`

I copied the whole /usr/lib/grub/i386-pc/ directory to /boot/grub/ since
it was missing not just i386-pc/normal.mod file but i386-pc/ directory
itself.

(This system repair workaround was performed by booting the system with
SystemRescue USB stick. https://www.system-rescue.org/ )

Then my system boot without problem showing nice blue selection screen.
After booting, I see `/boot/grub/.background_cache.png` created.

## Thoughts on the packaging:

As I compaired grub install situation with my another system using UEFI,
there I see /boot/grub/x86_64-efi/ directory and all *.mod files.
UEFI system also had /usr/lib/grub/x86_64-efi with the same *.mod.

My question is why Debian packager decided not to do the same for
grub-pc?  If he did the same for grub-pc, I didn't suffer broken grub
install.

## Thoughts on the hardware configuration trigger:

Possible triggers I suspect:
- /boot on /dev/sda5 (not on MBR primary partition /dev/sda1 etc.)
- SSD size (500GB) and sector location of /boot

## Few more background etc.

As you might have thought, I initially tried to boot using `/boot` (not
`/`) on /dev/sda5.  Then I had `/` in LVM (Then not encrypted.).  Back
then, error message was much more cryptic since it didn't print normal
path.  It was looking for some partition with long label starting with "lvm".

So it took me a good amount of head-scratching before finding workable
solution.

With the above workaround, I may be able to use encrypted root on LVM.
I didn't test it.  For now, I don't have an appetite to re-install this
PC.

With the current setup, I effectively have an encrypted system (except
for /etc and /boot.  (I think I can also move /root to encrypted FS.)

This system comes with early UEFI system.  But it was a bit problematic
one so I ended up to use it in legacy mode with MBR partition.

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/mapper/CRYPTO-BTRFS /usr btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=259,subvol=/@usr 0 0
/dev/mapper/CRYPTO-BTRFS /btrfs btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/ 0 0
/dev/mapper/CRYPTO-BTRFS /opt btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=256,subvol=/@opt 0 0
/dev/mapper/CRYPTO-BTRFS /home/osamu btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=261,subvol=/@osamu 0 0
/dev/mapper/CRYPTO-BTRFS /srv btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=257,subvol=/@srv 0 0
/dev/mapper/CRYPTO-BTRFS /var btrfs 
rw,relatime,ssd,space_cache=v2,subvolid=258,subvol=/@var 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod ext2
set root='hd0,msdos5'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 

Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy

[Osamu Aoki]

HI,

On Fri, 2023-12-08 at 21:36 -0800, Ross Vandegrift wrote:
> On Mon, Nov 13, 2023 at 01:48:09PM +0900, Osamu Aoki wrote:
> > But not for LXD since it uses different images.  Image normally downloaded
> > and
> > used by `lxc launch ...` becomes buggy once its instance is started because
> > then
> > cloud-init starts system initialization with its default setting.
> 
> Oh right, that's what I wasn't putting together.  Sorry for making you repeat
> yourself.
> 
> > Here is how I get around this problem by removing toxic netdev out of
> > installed
> > file /etc/cloud/cloud.cfg:
> 
> Is unusual GID numbering the only impact, or does this cause more significant
> problems?  I guess user code that tries to statically assign GID 1000 will
> break.

Yes.  Although UID=1000, GID=1000 is expected it is not guaranteed.


> I agree it should be fixed.  In unstable it seems reasonable to change the
> config.  But I'm not sure I think it warrants a stable update.

For stable, if you have chance to update, please consider to add README or just
keep this bug open for bookworm.

README should have workaround as I wrote:
 
  https://osamuaoki.github.io/en/2023/11/12/lxc-2/#configuration-of-lxd-instance
(While wait and bug upstream LXD image generation code to fix it to address this
issue.
   https://github.com/canonical/cloud-init/issues/4603#issuecomment-1827955514

For unstable, please consider to limit groups listed to ones in base-config.

Regards,

Osamu

Bug#993308: firefox-esr: You might need to add a libpci3 dependency to ESR 91

[Osamu Aoki]

Package: firefox-esr
Version: 115.4.0esr-1~deb12u1

Hi,

I installed firefox-esr to default LXD Debian 12 bookworm cloud image run as
container via APT.

This system has just firefox-esr and no GUI desktop.  Wayland on the host system
(GNOME Wayland bookworm) is used to display graphics.

Starting firefox-esr in this system without libpci3 in this container works with
following warning displayed on console but firefox is working and I can see web
pages with it.

```

osamu@wayland:~$ firefox   
[GFX1-]: glxtest: libpci missing
```

Once I installed libpci3, the above warning is gone.

So the appropriate dependency for this package is adding "Recommends: libpci3"


Normal Debian system usually have `pciutils` package (priority=standard) and it
pulls in `libpci3`.  Since I was using container, I could get real minimal
system without `libpci3`. 

Osamu

Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy

[Osamu Aoki]

Hi,

Not quite.

On Sun, 2023-11-12 at 07:47 -0800, Ross Vandegrift wrote:
> On Sat, Nov 11, 2023 at 09:46:51PM +0900, Osamu Aoki wrote:
> > Package: cloud-init
> > Version: 22.4.2-1
> > Severity: normal
> > 
> > ## Background:
> > 
> > The problem and possible root cause fix are reported on upstream github
> > issue: https://github.com/canonical/cloud-init/issues/4603
> > 
> > ## Issue:
> > I noticed instance generated from Debian bookworm cloud image on
> > linuxcontainer.org had odd GID=1000 for netdev. Since netdev should be a
> > system group, this situation violates Debian policy.
> 
> Hi Osamu,
> 
> As Shengjing Zhu mentioned in [1], this issue was fixed in #1038691.  Is that
> incorrect?


This #1038691 is for Package: cloud.debian.org .

As I understand, the bug in cloud-init is worked around and only the resulting
image for cloud.debian.org is fixed via the image building code.

But not for LXD since it uses different images.  Image normally downloaded and
used by `lxc launch ...` becomes buggy once its instance is started because then
cloud-init starts system initialization with its default setting.

Of course, we can avoid this situation by fixing image manually by modifying its
default setting.

Here is how I get around this problem by removing toxic netdev out of installed
file /etc/cloud/cloud.cfg:
```
 $ cd path/to
 $ lxc init images:debian/bookworm/cloud dbc0
 $ lxc file pull dbc0/etc/cloud/cloud.cfg .
 $ sed -i -e 's/ netdev,//' cloud.cfg
 $ lxc file push cloud.cfg dbc0/etc/cloud/
 $ lxc publish dbc0 --alias dbc
Instance published with fingerprint:
379e858cc15808dbdf6a27a028a8b0098213656c0b4565bbc1b64b90b61d9dbd
 $ lxc start dbc0
 $ lxc launch dbc dbc1
```

Osamu


> [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055700#25

Bug#976673: deb822 support patch for dget

[Osamu Aoki]

control: tags -1 patch
thanks

Hi,

I just sent MR
> https://salsa.debian.org/debian/devscripts/-/merge_requests/373

I hit this bug and looked at the code.  Since failure happens during its sanity
check, I just add extra rule to relax the URL sanity check.

Since deb822 is case insensitive, I made it so.

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976673
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030277

Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy

[Osamu Aoki]

Package: cloud-init
Version: 22.4.2-1
Severity: normal

## Background:

The problem and possible root cause fix are reported on upstream github
issue: https://github.com/canonical/cloud-init/issues/4603

## Issue:
I noticed instance generated from Debian bookworm cloud image on
linuxcontainer.org had odd GID=1000 for netdev. Since netdev should be a
system group, this situation violates Debian policy.

Basically, cloud-init has a bug of creating system group starting from
GID=1000 if it sees some group name listed in groups-list and missing on
the system's /etc/group.

## What am I asking to Debian packagers

The root cause fix takes long time in upstream.  There should be some
least invasive workaround to avoid this issue on most use cases simply
by updating debian/cloud.cfg file.

I suggest to drop "netdev" from `debian/cloud.cfg` as the least invasive
minimal change.  This should be done on both on stable (now) and
unstable (unless upstream fixes the root cause).

## Technical consideration.

This debian/cloud.cfg is installed by override_dh_installinit target in
debian/rules .  I compaired this against upstream config/cloud.cfg.tmpl.
It looks like this has modified upstream generated cloud.cfg which
sharies its contents with Ubuntu.  I see "[Uu]buntu" swapped with
"[Dd]ebian" in cloud.cfg. Besides these cosmetic changes, Debian
packaging already made interesting change in it.  Let's look at groups
in cloud.cfg.

upstream: adm, audio, cdrom, dialout, dip, floppy, lxd, netdev, plugdev, sudo, 
video
debian:   adm, audio, cdrom, dialout, dip, floppy, netdev, plugdev, sudo, video

I don't know how these are chosen mostly for Ubuntu by upstream but
Debian packager made decision to drop "lxd" here.

Minimal Debian system has its system group defined in base-passwd
package.  So "adm, audio, cdrom, dialout, dip, floppy, plugdev, sudo,
video" are guranteed to exist. Debian package should drop not only "lxd"
but also "netdev".

I don't think removing `netdev` cause much problem.

As you know, `netdev` is for `/dev/wfkill` and wpsupplicant and similar
packages.  If anyone decides to add these packages to the root image, it
get generated properly by postinst.  Of course, adding `netdev` group to 
the primary user account `debian` is needed if the user wishes.  That's
something to be documented.  We must keep Debian system compliant to
Debian policy.

Debian Policy
https://www.debian.org/doc/debian-policy/ch-opersys.html#uid-and-gid-classes

  100-999:
  Dynamically allocated system users and groups. Packages which need a
  user or group, but can have this user or group allocated dynamically and
  differently on each system, should use adduser --system to create the
  group and/or user. adduser will check for the existence of the user or
  group, and if necessary choose an unused id based on the ranges
  specified in adduser.conf.


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

Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/12 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

Versions of packages cloud-init depends on:
ii  eject  2.38.1-5+b1
ii  fdisk  2.38.1-5+b1
ii  gdisk  1.0.9-2.1
ii  isc-dhcp-client4.4.3-P1-2
ii  locales2.36-9+deb12u3
ii  lsb-base   11.6
ii  lsb-release12.0-1
ii  procps 2:4.0.2-3
ii  python33.11.2-1+b1
ii  python3-configobj  5.0.8-1
ii  python3-jinja2 3.1.2-1
ii  python3-jsonpatch  1.32-2
ii  python3-jsonschema 4.10.3-1
ii  python3-netifaces  0.11.0-2+b1
ii  python3-oauthlib   3.2.2-1
ii  python3-requests   2.28.1+dfsg-1
ii  python3-serial 3.5-1.1
ii  python3-yaml   6.0-3+b2
ii  sysvinit-utils [lsb-base]  3.06-4
ii  util-linux 2.38.1-5+b1

Versions of packages cloud-init recommends:
ii  cloud-guest-utils  0.33-1
ii  eatmydata  130-2
ii  sudo   1.9.13p3-1+deb12u1

Versions of packages cloud-init suggests:
ii  btrfs-progs  6.2-1
ii  e2fsprogs1.47.0-2
ii  xfsprogs 6.1.0-1

-- no debconf information

Bug#1055752: `groupadd --force --system sambashare` in samba.postinst is wrong

[Osamu Aoki]

Source: samba
Severity: normal

Problem: `groupadd --force --system sambashare` in samba.postinst is wrong

Versions:  2:4.17.12+dfsg-0+deb12u1, 2:4.19.2+dfsg-1
Salsa: 0610d7670c6 ("update changelog; upload version 4.19.2+dfsg-1 to 
unstable", 2023-10-16)

groupadd is in essential but command syntax is not the same as addgroup
from adduser package.  Simply replacing adduser is not the right fix.

I see you committed on this happened from:
  1eb07efc2fb ("d/winbind.postinst: switch addgroup => groupadd and eliminate 
getent", 2022-11-03)

What happened was adduser is not essential.  So if you don't depend on
it, piuparts fails.  (Yes, there may have been some transitional problem
etc.  But this is the core of the issue.)  So please add depends to
adduser and use the older good code.

If you insist on using groupadd from shadow package, you need to use
something along (but this may still fail on some corner cases:

groupadd -f -K MIN_GID=100 -K MAX_GID=999 sambashare

I still think this use of groupadd is bad idea.

Use of getent in old code should be no problem since it is in libc-bin
which is priority required.

If you still have problem with your local piuparts checks, please check
your base sid image used for it.  If it still has adduser package in it,
remove it.

-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf not present

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

Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/12 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

-- no debconf information

Bug#1055700: netdev in official Debian cloud image has GID=1000

[Osamu Aoki]

Source: lxd
Version: 5.0.2-5
Severity: minor

`lxc launch` generated Debian cloud image (bookworm) has odd /etc/group
in it.  GID=1000 is netdev.  If it is properly generated using
---
 # addgroup --system netdev
---
this GID for netdev should be somewhare between 100 and 999.

Although, I know that this is most likely not caused by the lxd source,
I didn't know where to file this bug.  Please reassign this report to
appropriate resources.

Osamu

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

Kernel: Linux 6.5.0-0.deb12.1-amd64 (SMP w/12 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

Bug#1052521: debmake-doc: instructions for adding user to sbuild group have a bug and are (maybe) incomplete

[Osamu Aoki]

Hi,

Sent it too early.

On Wed, 2023-11-08 at 15:22 +0900, Osamu Aoki wrote:

Hi,

This is a good point to rethink description.
> On Sat, 2023-09-23 at 15:31 -0400, Jonathan Kamens wrote:
> > > > > Package: debmake-doc
> > > > > Version: 1.17-7
> > > > > Severity: minor
> > > > > 
> > > > > 1) Section 3.6 of the debmake doc says to run `adduser
> > > > > 
> > > > > sbuild` but there should be `sudo` at the beginning of that command.

Yes.

> But a new question is should I use `adduser`? It is not essential. Maybe it's
> time to start using distribution non-dependent `usermod` here.
> 
> > > > > 2) It also says "Logout and login to check you are a member of sbuild
> > > > > group using id command." I don't know how universal this is, but if a
> > > > > user has done `loginctl enable-linger` or has a user-level systemd
> > > > > daemon configured, logging out logging back in won't work; they still
> > > > > won't be in the group. They would need to either reboot or run `kill
> > > > > -TERM -1` (NOT as root) to make all of their processes die and thereby
> > > > > get the user-level systemd to restart. I know you're trying to keep
> > > > > the guide simple so you you may not want to get into the nitty-gritty
> > > > > details, but perhaps it is worth mentioning that if logging out and
> > > > > logging back in doesn't work the user should try restarting their
> > > > > computer.
> 
What I knew were
$ sudo usermod -aG sbuild USER
$ sudo shutdown -r now
-> This hard reboot from UEFI
or
$ sudo usermod -aG sbuild USER
$ killall systemd
-> This is soft reboot only systemd

I don't know the latter has any bad side effects. Otherwise this is quicker.


Your trick seem to be cleaner
$ sudo usermod -aG sbuild USER
$ kill TERM -TERM -1


Considering -TERM is -15, this may be redundant.  Do you need this?
Kill manpage has 
  kill -9 -1
 Kill all processes you can kill.
-9 is SIGKILL.


All these kill commands seem to work without going into hard reboot.

Osamu

Bug#1052521: debmake-doc: instructions for adding user to sbuild group have a bug and are (maybe) incomplete

[Osamu Aoki]

Hi,

This is a good point to rethink description.

On Sat, 2023-09-23 at 15:31 -0400, Jonathan Kamens wrote:
> > > > Package: debmake-doc
> > > > Version: 1.17-7
> > > > Severity: minor
> > > > 
> > > > 1) Section 3.6 of the debmake doc says to run `adduser 
> > > > sbuild` but there should be `sudo` at the beginning of that command.

Yes.

But a new question is should I use `adduser`? It is not essential. Maybe it's
time to start using distribution non-dependent `usermod` here.

> > > > 2) It also says "Logout and login to check you are a member of sbuild
> > > > group using id command." I don't know how universal this is, but if a
> > > > user has done `loginctl enable-linger` or has a user-level systemd
> > > > daemon configured, logging out logging back in won't work; they still
> > > > won't be in the group. They would need to either reboot or run `kill
> > > > -TERM -1` (NOT as root) to make all of their processes die and thereby
> > > > get the user-level systemd to restart. I know you're trying to keep
> > > > the guide simple so you you may not want to get into the nitty-gritty
> > > > details, but perhaps it is worth mentioning that if logging out and
> > > > logging back in doesn't work the user should try restarting their
> > > > computer.

What I knew were

$ sudo usermod -aG sbuild USER
$ sudo shutdown -r now

-> This hard reboot from UEFI

or

$ sudo usermod -aG sbuild USER
$ sudo killall systemd

-> This is soft reboot only systemd

I don't know the latter has any bad side effects. Otherwise this is quicker.


Your trick seem to be cleaner
$ sudo usermod -aG sbuild USER
$ kill TERM -TERM -1


Considering -TERM is -15, this may be redundant.  Do you need this?


Kill manpage has 
  kill -9 -1
 Kill all processes you can kill.

-9 is SIGKILL.

Bug#1055260: Wayland and sound server connection

[Osamu Aoki]

Source: debian-reference
Version: 2.105
Severity: wishlist

Although we have "7.8. X server connection", there is no mention of
Wayland and sound server connection.

Of course, Wayland server connection is limitted to local machine, it
should be given at least minimum pointer for people using lxd or kvm.

This should be carefully written without getting into too much details.

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

Kernel: Linux 6.4.0-0.deb12.2-amd64 (SMP w/12 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

Bug#1009724: flex/bison example update

[Osamu Aoki]

control: tags -1 pending
thanks

After sending bug report to flex, I rewrote this section for flex and bison.

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

Osamu

Bug#1055082: fastwc examples needs to be updated

[Osamu Aoki]

Hi,

> > You can follow progress on this Bug here: 1055082:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055082.

Oops, "-lfl" may have been redundant...

Regards,

Osamu

Bug#1055082: fastwc examples needs to be updated

[Osamu Aoki]

Package: flex
Version: 2.6.4-8.2
Severity: minor
Tags: patch

The flex binary package comes with examples under 
/usr/share/doc/flex/examples/fastw .

These were from 2016 and don't work as expected with current gcc and
flex.

Attached patch fix these issues.
 * need "int" for main
 * need tailing "%%"

I think these may have been OK with old tool chain but they cause
trouble these days.

Now these can be compiled with

```
gcc -lfl mywc.c -o mywc
for f in 1 2 3 4 5; do
flex wc$f.l
gcc -lfl lex.yy.c -o wc$f
rm -f lex.yy.c
done
```

These example files are from upstream source under
https://salsa.debian.org/srivasta/flex/-/tree/master/examples/fastwc/

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

Kernel: Linux 6.4.0-0.deb12.2-amd64 (SMP w/12 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

Versions of packages flex depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  libc6  2.36-9+deb12u3
ii  m4 1.4.19-3

Versions of packages flex recommends:
ii  gcc [c-compiler] 4:12.2.0-3
ii  gcc-12 [c-compiler]  12.2.0-14
ii  libfl-dev2.6.4-8.2

Versions of packages flex suggests:
ii  bison2:3.8.2+dfsg-1+b1
ii  build-essential  12.9
ii  flex-doc 2.6.4-8.2

-- no debconf information
diff -Nru fastwc-orig/mywc.c fastwc/mywc.c
--- fastwc-orig/mywc.c  2016-10-21 09:43:44.0 +0900
+++ fastwc/mywc.c   2023-10-31 13:23:40.545931128 +0900
@@ -3,7 +3,7 @@
 #include 
 #include 
 
-main()
+int main()
 {
int c, cc = 0, wc = 0, lc = 0;
FILE *f = stdin;
diff -Nru fastwc-orig/wc1.l fastwc/wc1.l
--- fastwc-orig/wc1.l   2016-10-21 09:43:44.0 +0900
+++ fastwc/wc1.l2023-10-31 13:23:48.742047498 +0900
@@ -17,3 +17,4 @@
printf( "%8d %8d %8d\n", lc, wc, cc );
yyterminate();
}
+%%
diff -Nru fastwc-orig/wc2.l fastwc/wc2.l
--- fastwc-orig/wc2.l   2016-10-21 09:43:44.0 +0900
+++ fastwc/wc2.l2023-10-31 13:23:58.150181074 +0900
@@ -19,3 +19,4 @@
printf( "%8d %8d %8d\n", lc, wc, cc );
yyterminate();
}
+%%
diff -Nru fastwc-orig/wc3.l fastwc/wc3.l
--- fastwc-orig/wc3.l   2016-10-21 09:43:44.0 +0900
+++ fastwc/wc3.l2023-10-31 13:24:06.806303970 +0900
@@ -23,3 +23,4 @@
printf( "%8d %8d %8d\n", lc, wc, cc );
yyterminate();
}
+%%
diff -Nru fastwc-orig/wc4.l fastwc/wc4.l
--- fastwc-orig/wc4.l   2016-10-21 09:43:44.0 +0900
+++ fastwc/wc4.l2023-10-31 13:24:21.638514548 +0900
@@ -26,3 +26,4 @@
printf( "%8d %8d %8d\n", lc, wc, cc );
yyterminate();
}
+%%
diff -Nru fastwc-orig/wc5.l fastwc/wc5.l
--- fastwc-orig/wc5.l   2016-10-21 09:43:44.0 +0900
+++ fastwc/wc5.l2023-10-31 13:24:32.578669865 +0900
@@ -23,3 +23,4 @@
printf( "%8d %8d %8d\n", lc, wc, cc );
yyterminate();
}
+%%

Bug#1051979: Do not suggest APT::Default-Release setting

[Osamu Aoki]

Hi,

On Mon, 2023-10-30 at 17:39 +0700, Max Nikulin wrote:
> On 30/10/2023 10:28, Osamu Aoki wrote:
> > On Thu, 2023-09-21 at 21:56 +0700, Max Nikulin wrote:
> > > On 18/09/2023 20:12, Osamu Aoki wrote:
> > > > 
> > > >  APT::Default-Release "testing";
> > > > 
> > > > I think this don't drive people to set this to "stable" as much.
> > > 
> > >   From my point of view it is a bit better, but hardly noticeable. And it
> > > is still misleading for Debian users since testing has security updates
> > > as well, thus not so trivial regexp is preferred. apt.conf(5) has more
> > > examples, but neither of them is close to what might be used in real life:
> > 
> > Although, repository for testing security updates exists, it is hardly used
> > in
> > practice.
> 
> I feel some kind of miscommunication here. I was trying to say that
> 
>  APT::Default-Release "stable";
> 
> prevents updates from stable-security (bookworm-security). 

Yes, I know that is what you said.

"APT::Default-Release "testing";" is my initial improvement suggestion with
minimal change.

> This 
> repository is rather important, it is configured by installer, it is 
> mentioned in various docs, e.g.
> https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_archive_basics

That is this document (my debian-reference) before this fix.

My comment was aimed at upstream APT manpage or elsewhere outside of my control
where I can't control.

> deb http://security.debian.org/debian-security bookworm-security main 
> non-free-firmware contrib non-free
> 
> I would not call it "hardly used".

I am talking about testing-security being hardly used.

>  I agree that testing-security 
> repository is currently empty, but I assume, it may not be so during 
> late freeze stages. Moreover, having example for "testing", users may 
> try to blindly apply it for "stable".

Release team has been saying not to expect testing-security to be used (with
developer resource limitation etc.)

If you care such risk, please use stable platform.

> > Updated text:
> > 
> >     The target release archive can be set by the command line option, e.g.,
> > "apt-get
> >     install -t testing some-package"
> 
> Thank you for improving of the docs. I consider the issue as fixed.


Good.

Bug#1053885: manpages generation for many commands is flawed

[Osamu Aoki]

control: reassign -1 src:golang-github-spf13-cobra
thanks

Hi,

On Mon, 2023-10-30 at 03:12 +, Mathias Gibbens wrote:
> Hi Osamu,
> 
>   Thanks for noticing and reporting this. I've looked into it a bit,
> and I think it would be appropriate to report this to the spf13/cobra
> project[0]. From my reading of the LXD/Incus use of the library, I
> don't think they're doing anything "special" that would affect the
> behavior generating the manpages. If you do report it there, we can re-
> assign this bug to src:golang-github-spf13-cobra.
> 
> Mathias
> 
> [0] -- https://github.com/spf13/cobra

Thanks for your assessment.  I had the same feeling but wasn't sure on build
process.  Let's reassign this.

Bug#1051979: Do not suggest APT::Default-Release setting

[Osamu Aoki]

control: tags -1 pending
thanks

Hi,

On Thu, 2023-09-21 at 21:56 +0700, Max Nikulin wrote:
> 
> On 18/09/2023 20:12, Osamu Aoki wrote:
> > 
> > Since　Bug#1041708 was mentioned, I CC it.
> 
> It is marked as "done", so perhaps you need to reopen it if you expect
> some actions.
> 
> > I propose to replace this line with
> > 
> >     APT::Default-Release "testing";
> > 
> > I think this don't drive people to set this to "stable" as much.
> 
>  From my point of view it is a bit better, but hardly noticeable. And it
> is still misleading for Debian users since testing has security updates
> as well, thus not so trivial regexp is preferred. apt.conf(5) has more
> examples, but neither of them is close to what might be used in real life:

Although, repository for testing security updates exists, it is hardly used in
practice. 

> > Default-Release
> > 
> > Default release to install packages from if more than one version is
> > available. Contains release name, codename or release version. Examples:
> > 'stable', 'testing', 'unstable', 'bookworm', 'trixie', '4.0', '5.0*'.
> > See also apt_preferences(5).
> 
> I believe that explicit warnings against usage of APT::Default-Release
> will be helpful for users.
> 
> I have not noticed issues with regexp and "apt-get source" or synaptic
> in bookworm. Either they exist or not, mention of regexp as an option is
> valuable from my point of view (with or without a warning concerning
> lack of support in some tool). It will affect decision of those who are
> aware of regexp from the bullseye release notes.
> 

I don't want to spend too much on past release related bugs (including
documentation).  DR is an entry document so it shouldn't clutter.  I decided to
change DR as follows by drop mentioning "APT::Default-Release "stable":

Current text:
   The target release archive can be set by several methods.
   * "/etc/apt/apt.conf" configuration file with "APT::Default-Release 
"stable";"
   line
   * command line option, e.g., "apt-get install -t testing some-package"
   
Updated text:

   The target release archive can be set by the command line option, e.g., 
"apt-get
   install -t testing some-package"
   
For APT bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041708
this is outside of my control and it has been closed by the maintainer.  So I
didn't CC this reply.

Regards,

Osamu

Bug#1031978: debian-reference-fr: wrong position for tables in french PDF version

[Osamu Aoki]

Control: severity -1 wishlist
Control: tags -1 wontfix
thanks

There is no simple way to change table placement in PDF for debian-reference
(DR).  I think the mentioned table is in the correct position in HTML.  Latex
tool chain relocate it to appropriate position considering the PDF is page
based.

I understand this may be uncomfortable for you but this is mostly preference
issue.  So this is wishlist bug.  Also this happens outside of my control, I
mark this as wontfix.

Best regards,

Osamu

Bug#686481: debian-reference instructs users on how to install non-free software

[Osamu Aoki]

Control: tags -1 - moreinfo
Control: tags -1 + wontfix
thanks

This is about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686481

I have made major update of debian-reference (DR) in 2012 and 2022 to address
this bug report concerns and non-free-firmware. I realized this old bug is still
around for my package.  Let me reassess this bug.

The title of this bug by "SirGrant" is misleading at least for the current DR. 
DR doesn't instruct *instruct* user to install non-free software.  DR only
provides  information on how to install non-free software.

Moreover, current DR explicitly mention in "2.1.6. Debian is 100% free software"
https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_is_100_free_software
as:

   Users should be aware of the risks of using packages in the non-free, 
non-free-
   firmware and contrib areas:
   
   * lack of freedom for such software packages
   * lack of support from Debian on such software packages (Debian can't 
 support software properly without having access to its source code.)
   * contamination of your 100% free Debian system

So I think I am respectful for people not wishing to get close to non-free.

My message was a bit ambiguous in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686481#20 .

What I meant was I am happy to accept practical path for technical measures on
DR (not Debian Policy) which enable to keep quiet on even mentioning non-free in
DR as an optional build feature for particular distribution.  After 10+ years,
no productive proposal nor discussion has happened on this direction.

Also, in light of Debian CD including non-free-firmware these days, I think that
the level of *mention* in DR is appropriate.  So I can close this bug but for
avoiding future repeat of this discussion, I decided to keep this bug but with
changing this bug tag from moreinfo to wontfix.

Regards,

Osamu

PS: I am CCing people who participated on this bug.  I intentinally excluded
list address.

Bug#969177: debmake: cannot create deb for nodejs modeule

[Osamu Aoki]

Hi,

On Sun, 2023-10-29 at 23:52 +0900, Osamu Aoki wrote:
> Hi,
> 
> On Sun, 2023-10-29 at 15:11 +0530, Pirate Praveen wrote:
> ...
> > As you noted in subsequent comment, we can skip package.yaml. Build depends
> > can be dh-sequence-nodejs instead of pkg-js-tools (npm2deb did that switch).
> 
> Both in bookworm and sid, dh-sequence-nodejs is a virtual package offered by
> dh-
> nodejs.  The binary package dh-nodejs is based on source package pkg-js-tools
> which seems to have gone through package split.
> 
> Although I just updated package, it may be good idea to change this to dh-
> nodejs
> now.
> 
> > If dh-sequence-nodejs is in Build Deps then we don't need to add --with
> > nodejs
> > to dh as well.
> 
> This seems to be redundant but I think no harm and good practice to be
> explicit
> to be future proof.  This comes from python experience.  I may be wrong.
> 
> Osamu
> > 

dh-nodejs is Depends on pkg-js-tools
pkg-js-tools is not Depends (only Suggests) for dh-nodejs
For packaging we only need dh-nodejs

So requiring pkg-js-tools is not enough... needs to be fixed.

Bug#969177: debmake: cannot create deb for nodejs modeule

[Osamu Aoki]

Hi,

On Sun, 2023-10-29 at 15:11 +0530, Pirate Praveen wrote:
...
> As you noted in subsequent comment, we can skip package.yaml. Build depends
> can be dh-sequence-nodejs instead of pkg-js-tools (npm2deb did that switch).

Both in bookworm and sid, dh-sequence-nodejs is a virtual package offered by dh-
nodejs.  The binary package dh-nodejs is based on source package pkg-js-tools
which seems to have gone through package split.

Although I just updated package, it may be good idea to change this to dh-nodejs
now.

> If dh-sequence-nodejs is in Build Deps then we don't need to add --with nodejs
> to dh as well.

This seems to be redundant but I think no harm and good practice to be explicit
to be future proof.  This comes from python experience.  I may be wrong.

Osamu
> 

Bug#1028595: debmake creates invalid debian/source/control

[Osamu Aoki]

Control: tags -1 pending
thanks

Hi, thank you for catching this bug.

Actual bug is creation of debian/source/control

debian/tests/control needs to be editted to get it build.

I added reminder in the template.

Osamu

Bug#969177: debmake: cannot create deb for nodejs modeule

[Osamu Aoki]

Control: tags -1 pending
thanks

Hmmm...

I see ...
* https://github.com/npm/npm/issues/5901
* https://github.com/npm/npm/issues/3336

So package.yaml is not native part of npm packaging

* https://www.npmjs.com/package/package-yml
* https://github.com/rlidwka/yapm

These seems to enable yaml but requires new fetch and build tools.

So if you need support for package.yaml, please file a new bug report with
concrete build procedures and example.  So I can update build script etc.

Since patch is applied for the original bug, I am marking this bug as pending.

Osamu 


On Sat, 2023-10-28 at 15:34 +0900, Osamu Aoki wrote:
> Hi,
> 
> On Fri, 2023-10-27 at 20:59 +0530, Pirate Praveen wrote:
> > 
> > 
> > On 27/10/23 8:12 PM, Osamu Aoki wrote:
> > > Hi,
> ...
> > > Can you elaborate what do you mean by
> > > > Though after this it'd take some effort to edit source package name.
> > > 
> > > Maybe, we can work together to fix it.  Please understand I have no idea
> > > on
> > > the nodejs package name conventions.
> > 
> > May be looking for a package.json or package.yaml file in the source 
> > directory would be a better thing to detect a nodejs package.
> 
> 
> Currently, I have 'src/debmake/analyze.py' containing:
> 
> >     # Javascript nodejs
> >     elif os.path.isfile("package.json"):
> >     para["build_type"] = "nodejs"
> >     para["dh_with"].update({"nodejs"})
> >     para["build_depends"].update({"pkg-js-tools"})
> > 
> 
> Should I do:
>     # Javascript nodejs
>     elif os.path.isfile("package.json") or os.path.isfile("package.yaml"):
>     para["build_type"] = "nodejs"
>     para["dh_with"].update({"nodejs"})
>     para["build_depends"].update({"pkg-js-tools"})
> 
> Regards,
> 
> Osamu

Bug#1003106: --tar does not honor .gbp.conf tarball-dir option, creating a clash

[Osamu Aoki]

Control: tags -1 moreinfo

Hi,

This is my response to your BTS report:  
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003106

I am trying to reduce non-essential features as much as possible.

As you noticed, reading another package's configuration is risky path towards
over-complicating this code.

* There are many places to place such configuration option.
* Parser is non-trivial.
* There may be similar another packages which needs to be checked if we atart
doing this

So, if I ever address your needs, I prefer to add an new option to pass download
path for debmake itself.  That still seems to be complicating code.

Of course, if you bother to write a clean path to implement such a feature, I
will consider including it.  So I mark this as moreinfo

I think it is easier for you to write a simple shell wrapper of debamke to
address your need, for now.  If you send me such example, I will include it to
README.Debian.

Osamu

Bug#1021872: curl should work with debmake

[Osamu Aoki]

Control tags -1 pending
thanks

curl need "-O" option to make it behave like wget.

Bug#969177: debmake: cannot create deb for nodejs modeule

[Osamu Aoki]

Hi,

On Fri, 2023-10-27 at 20:59 +0530, Pirate Praveen wrote:
> 
> 
> On 27/10/23 8:12 PM, Osamu Aoki wrote:
> > Hi,
...
> > Can you elaborate what do you mean by
> > > Though after this it'd take some effort to edit source package name.
> > 
> > Maybe, we can work together to fix it.  Please understand I have no idea on
> > the nodejs package name conventions.
> 
> May be looking for a package.json or package.yaml file in the source 
> directory would be a better thing to detect a nodejs package.


Currently, I have 'src/debmake/analyze.py' containing:

> # Javascript nodejs
> elif os.path.isfile("package.json"):
> para["build_type"] = "nodejs"
> para["dh_with"].update({"nodejs"})
> para["build_depends"].update({"pkg-js-tools"})
> 

Should I do:
# Javascript nodejs
elif os.path.isfile("package.json") or os.path.isfile("package.yaml"):
para["build_type"] = "nodejs"
para["dh_with"].update({"nodejs"})
para["build_depends"].update({"pkg-js-tools"})

Regards,

Osamu

Bug#1052005: KDE Plasma with IBus: im-config changes needed

[Osamu Aoki]

Hi, this is just FYI.

Upcoming "IBus in a Plasma (Wayland) session" is interesting topic.

Since it may be related, let me quote interesting links from my previous post at
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054622#25

* Input Method Hub -- good overview
  https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39
* Wayland and input methods -- wayland-protocol description
  https://dorotac.eu/posts/input_method/
* Using Fcitx 5 on Wayland -- view by fcitx community
  https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland
* about Input Method wayland protocols #2331 -- view by ibus maintainer
  https://github.com/ibus/ibus/issues/2331
* New ideas using Wayland Input Methods -- view by QT people? August 3, 2023
  https://blog.davidedmundson.co.uk/blog/new-ideas-using-wayland-input-methods/


Out of all these linked pages, the following table may be useful for resolving
this bug (I may be wrong):

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39#implementation-matrix


Regards,

Osamu

On Fri, 2023-09-15 at 23:47 +0200, Gunnar Hjalmarsson wrote:
> Package: im-config
> Version: 0.57-2
> Severity: important
> 
> If you use IBus in a Plasma (Wayland) session, the intention seems to be 
> that you apply an "IBus Wayland" virtual keyboard and let Wayland handle 
> everything internally. Otherwise the suggestion window does not show up, 
> for instance. OTOH, with the virtual keyboard enabled im-config should 
> better be disabled.
> 
> In a Plasma (X11) session im-config keeps dealing with IBus as intended.
> 
> Probably we should change im-config so it doesn't do anything in case of 
> a Plasma (Wayland) session. However, during my tests things get 
> extremely slow with that "IBus Wayland" virtual keyboard enabled, which 
> may be a bug or a "user error" from my side.
> 
> In any case it's highly desirable that any changes are made in 
> consultation with somebody who actually uses IBus together with Plasma.
> 

Bug#983116: im-config: does not work under wayland and zsh as login shell

[Osamu Aoki]

Control: severity -1 wishlist
Control: tags -1 wontfix
thanks

Hi, I am doing BTS clean-up.

See discussion at:

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

Regards,

Osamu

Bug#969177: debmake: cannot create deb for nodejs modeule

[Osamu Aoki]

Hi,

Thanks for the patch.  I committed to salsa.

Can you elaborate what do you mean by
> Though after this it'd take some effort to edit source package name.

Maybe, we can work together to fix it.  Please understand I have no idea on the
nodejs package name conventions.

Regards,

Osamu
On Fri, 2023-10-27 at 00:44 +0530, Nilesh Patra wrote:
> Control: tags -1 patch
> 
> On Thu, 26 Oct 2023 23:25:00 +0530 Akshay S Dinesh 
> wrote:
> > On Thu, 14 Jul 2022 16:37:52 +0200 Pirate Praveen 
> >  wrote:
> > > Control: reopen -1
> > > Control: notfixed 4.4.0-1
> > > 
> > > On Thu, 14 Jul 2022 10:54:14 +0200 Pirate Praveen
> > >  wrote:
> > > > Control: fixed -1 4.4.0-1
> > > > 
> > > > Looks like it is fixed in current version, closing this bug. Thanks!
> > > 
> > > Seems like I was mistaken, tried on a fresh clean chroot and it still
> > > fails.
> > > 
> > > 
> > 
> > 
> > There's this commit referencing 4.4.0-1 on June 25, 2021 
> > https://salsa.debian.org/debian/debmake/-/commit/c59f0dbc112c5aaa737e0afdacbcc193e5e17dea
> > 
> > And this commit which fixes the bug on June 26, 2021 
> > https://salsa.debian.org/debian/debmake/-/commit/7f6c310aff8bf13eb64b98aff14e5e0b2bd58301
> > 
> > And this commit on May 6, 2022 which talks about 4.4.0
> > https://salsa.debian.org/debian/debmake/-/commit/07b1e07a9d9d327778d535287fdc70ac05dbe9e4
> > 
> > I'm unsure what's what.
> 
> It sure has been committed, and it is also present in the source package
> in the archive too. Seems to me that the uploader uploaded this on May
> 6, 2022 but did not edit the date as can be confirmed from the
> upload entry as well.
> 
> https://tracker.debian.org/news/1323132/accepted-debmake-440-1-source-
> into-unstable/
> 
> > https://packages.debian.org/sid/all/debmake/filelist is missing 
> > /usr/share/debmake/extra0desc_long/nodejs
> 
> Right that's because the changes in the commit are incomplete to fix this bug,
> since the nodejs extradesc file is never installed because it has its entry
> missing from setup.cfg.
> 
> I've attached a (one-line) patch at the end of the mail to fix this up
> properly.
> 
> > In any case, a workaround is to do
> > 
> > echo " This package contains the nodejs program." | sudo tee 
> > /usr/share/debmake/extra0desc_long/nodejs
> 
> 
> I was surprised to know that debmake tries to take the "type" field of
> the package from the directory name itself. So another workaround (this
> one is admittedly stupid) is:
> 
> > $ mv node-pretty-ms-8.0.0 pretty-ms-8.0.0
> > $ cd pretty-ms-8.0.0
> > $ debmake
> > $ cd ..
> > $ mv pretty-ms-8.0.0 node-pretty-ms-8.0.0
> 
> Though after this it'd take some effort to edit source package name.
> 
> Best,
> Nilesh
> 
> 
> diff --git a/setup.cfg b/setup.cfg
> index 57235a5..b19b18c 100644
> --- a/setup.cfg
> +++ b/setup.cfg
> @@ -54,6 +54,7 @@ console_scripts =
> src/extra0desc_long/dev
> src/extra0desc_long/doc
> src/extra0desc_long/lib
> +   src/extra0desc_long/nodejs
> src/extra0desc_long/perl
> src/extra0desc_long/python
> src/extra0desc_long/python3

Bug#1054622: im-config: can set GTK_IM_MODULE to xim, which causes GTK 4 to complain

[Osamu Aoki]

Control: tags -1 wontfix
thanks

Since setting to im-config "xim" was user action, its consequences are none of
our business.  Gunnar, I will set this as wontfix.

Brian, zoom is non-free external program. Neovim-GTK seems to be your locally
compiled package, they are not good examples of issues to be fixed.

I do understand new GTK4 may complain as warning if you set GTK_IMMODULE to xim.
So please just don't do it.  

On Fri, 2023-10-27 at 21:18 +0900, Osamu Aoki wrote:
> Hi,
> 
> Let's not repeat our discussion on im-config by discussing how ZOOM (external
> to
> Debian with poor record to provide proper dependencies in its deb package
> despite our advise to correct it) interacts with Debian default settings. 
> 
> Having said it, I still think it is worth discussing how im-config should set
> environment variables in near future especially with how wayland is getting
> its
> popularity.
> 
> Please read notable links on this topics first:
> 
> * Input Method Hub -- 
>   - https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39
> * Wayland and input methods -- wayland-protocol description
>   - https://dorotac.eu/posts/input_method/
> * Using Fcitx 5 on Wayland -- view by fcitx community
>   - https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland
> * about Input Method wayland protocols #2331 -- view by ibus maintainer
>   - https://github.com/ibus/ibus/issues/2331
> * New ideas using Wayland Input Methods -- view by QT people? August 3, 2023
>   - 
> https://blog.davidedmundson.co.uk/blog/new-ideas-using-wayland-input-methods/
> 
> I don't understand all the details but this topic for input method in wayland
> seems to be very much in development phase as of October/2023. I think it is
> worth tracking this technical development.
> 
> Most interesting part was: "Do we still need XMODIFIERS, GTK_IM_MODULE and
> QT_IM_MODULE?" --> For XMODIFIERS, yes, we do. X11 application running under
> X11
> and XWayland has nearly no difference.
> 
> Let me comment on this bug report.
> 
> On Fri, 2023-10-27 at 00:17 +, brian m. carlson wrote:
> > On 2023-10-26 at 22:51:19, Gunnar Hjalmarsson wrote:
> > > On 2023-10-26 23:51, brian m. carlson wrote:
> > > > I have a system with Zoom installed, which necessitates installing
> > > > ibus, which I don't want to use (because it overrides my shortcut
> > > > keys without consent).  Thus, the advice I've received is to install
> > > > im-config and use to set the module to "xim".
> 
> Have you read the previous bug report thoroughly before posting this.
> Specifically:
> * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988540
> 
> > > That's bad advice. Where did you get it?
> 
> Setting to "xim" was only mentioned by the bug reporter and we corrected it as
> bad idea and promoted to use "none".
> 
> > > Don't set it to "xim", set it to "none" instead, which means that im-
> > > config
> > > does not touch any environment variables (and does not launch ibus-
> > > daemon).
> > 
> > I believe I got it when I filed a bug report on ibus about some bug
> > where it affected my input in some way.  I don't recall, since it's been
> > some time.
> > > > I don't think, given that GTK+ 4 is used for a wide variety of
> > > > software in Debian, that it's safe to set GTK_IM_MODULE to "xim"
> > > > anymore, and im-config needs to not do that.
> 
> Please present links to support your technical references.
> 
> By the way, the GTK+ was used for only up to version 3.  I think its name is
> now
> GTK4 library.
> 
> > > Your observation is not a sufficient reason to conclude that "xim" is
> > > never
> > > useful and should be removed as an option. im-config does not set that
> > > option automatically, but only if the user chooses it explicitly. In your
> > > case due to a bad advice. ;)
> > > 
> > > So I'm inclined to close this bug as a "wontfix", but await possible
> > > further
> > > input on the matter.
> 
> I agree.
> 
> 
> > I'd argue that setting any environment variables that make programs
> > scream to the terminal is not okay.  I'm fine with im-config setting any
> > value that doesn't do that.
> 
> Since wiki page https://wiki.debian.org/Keyboard is referenced in
> README.Debian
> of im-config, I updated this wiki page to make it easier to find this proper
> work around.
> 
> https://wiki.debian.org/Keyboard#IM_framework_disabled_case_.28XKB.29
> 
> Regards,
> 
> Osamu
> 

Bug#1054622: im-config: can set GTK_IM_MODULE to xim, which causes GTK 4 to complain

[Osamu Aoki]

Hi,

Let's not repeat our discussion on im-config by discussing how ZOOM (external to
Debian with poor record to provide proper dependencies in its deb package
despite our advise to correct it) interacts with Debian default settings. 

Having said it, I still think it is worth discussing how im-config should set
environment variables in near future especially with how wayland is getting its
popularity.

Please read notable links on this topics first:

* Input Method Hub -- 
  - https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39
* Wayland and input methods -- wayland-protocol description
  - https://dorotac.eu/posts/input_method/
* Using Fcitx 5 on Wayland -- view by fcitx community
  - https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland
* about Input Method wayland protocols #2331 -- view by ibus maintainer
  - https://github.com/ibus/ibus/issues/2331
* New ideas using Wayland Input Methods -- view by QT people? August 3, 2023
  - 
https://blog.davidedmundson.co.uk/blog/new-ideas-using-wayland-input-methods/

I don't understand all the details but this topic for input method in wayland
seems to be very much in development phase as of October/2023. I think it is
worth tracking this technical development.

Most interesting part was: "Do we still need XMODIFIERS, GTK_IM_MODULE and
QT_IM_MODULE?" --> For XMODIFIERS, yes, we do. X11 application running under X11
and XWayland has nearly no difference.

Let me comment on this bug report.

On Fri, 2023-10-27 at 00:17 +, brian m. carlson wrote:
> On 2023-10-26 at 22:51:19, Gunnar Hjalmarsson wrote:
> > On 2023-10-26 23:51, brian m. carlson wrote:
> > > I have a system with Zoom installed, which necessitates installing
> > > ibus, which I don't want to use (because it overrides my shortcut
> > > keys without consent).  Thus, the advice I've received is to install
> > > im-config and use to set the module to "xim".

Have you read the previous bug report thoroughly before posting this.
Specifically:
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988540

> > That's bad advice. Where did you get it?

Setting to "xim" was only mentioned by the bug reporter and we corrected it as
bad idea and promoted to use "none".

> > Don't set it to "xim", set it to "none" instead, which means that im-config
> > does not touch any environment variables (and does not launch ibus-daemon).
> 
> I believe I got it when I filed a bug report on ibus about some bug
> where it affected my input in some way.  I don't recall, since it's been
> some time.
> > > I don't think, given that GTK+ 4 is used for a wide variety of
> > > software in Debian, that it's safe to set GTK_IM_MODULE to "xim"
> > > anymore, and im-config needs to not do that.

Please present links to support your technical references.

By the way, the GTK+ was used for only up to version 3.  I think its name is now
GTK4 library.

> > Your observation is not a sufficient reason to conclude that "xim" is never
> > useful and should be removed as an option. im-config does not set that
> > option automatically, but only if the user chooses it explicitly. In your
> > case due to a bad advice. ;)
> > 
> > So I'm inclined to close this bug as a "wontfix", but await possible further
> > input on the matter.

I agree.


> I'd argue that setting any environment variables that make programs
> scream to the terminal is not okay.  I'm fine with im-config setting any
> value that doesn't do that.

Since wiki page https://wiki.debian.org/Keyboard is referenced in README.Debian
of im-config, I updated this wiki page to make it easier to find this proper
work around.

https://wiki.debian.org/Keyboard#IM_framework_disabled_case_.28XKB.29

Regards,

Osamu

Bug#1053885: manpages generation for many commands is flawed

[Osamu Aoki]

Source: lxd
Version: 5.0.2-5
Severity: normal
Tags: upstream

Problem: 

Manpages of lxd-client are sometimes unintelligible.  For example:

```
$ man lxc launch
LXD - Command line client(1)   LXD - Command line client(1)

NAME
   lxc-launch - Create and start instances from images

SYNOPSIS
   lxc launch [:] [:][] [flags]
...
Auto generated by spf13/cobra  May 2023  LXD - Command line client(1)
```

Please compare odd SYNOPSIS in the above manpage with `-h` option result
of the command as below..

```
$ lxc launch -h
Description:
  Create and start instances from images

Usage:
  lxc launch [:] [:][] [flags]
...
```

Proposed interim fix:

Add README.Debian for affected binary packages mentioning manpaage
problem and guide people to use `-h` option with command to get
intelligible help.

Speculated root cause and fix path:

As noted at the bottom of manpage, this is generated from help message
of the corresponding command.  I don't know how exacly it process help
message but it processing seems to drop words between "<" and ">".

If plain text markup is converted to XML and then passed to xml2man or
xmlto type processor, this kind of problem may happen unless "<" and ">"
are escaped properly before their processing.

I understand this is upstream problem but I don't know where to send
this bug report due to lxd and incus situation.  This is probably needs
fix to the manpage generation script or rewrite all manpage without
problematic "<" and ">".

Osamu

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

Kernel: Linux 6.4.0-0.deb12.2-amd64 (SMP w/12 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

Bug#1041708: Bug#1051979: Do not suggest APT::Default-Release setting

[Osamu Aoki]

Hi,

As far as I understand, my text comes from:
  $ man apt_preferences 

Since　Bug#1041708 was mentioned, I CC it.

I concur more-or-less with what Julian Andres Klode said for the solution.

I think what is needed is:
  by way of being not set up anymore, 
  nor presenting impression of recommendation in release notes.

## Debian Reference

As for the entry document such as Debian Reference, 

I should skip mentioning setting "APT::Default-Release" to whatever since
setting it in /etc/apt/apt.conf.d/* tends to cause persistent confusing setting.

If someone dare to set such thing, use /etc/apt/preferences with PIN priority. 
I have such example already with ample warnings.

## man apt_preferences

What is written there is 100% correct.  But it does create impression of using 

   APT::Default-Release "stable";

as a part of normal system configuration to some readers.

I think this document needs to explain apt system functionality thoroughly,
dropping use of `APT::Default-Release` reference may not be a option.

I propose to replace this line with 

   APT::Default-Release "testing";

I think this don't drive people to set this to "stable" as much.

If I go farther, to make deprecated usage of APT::Default-Release in
/etc/apt/apt.conf more explicit, I suggest that the following part:

   Note that this has precedence over any general priority you set in the
   /etc/apt/preferences file described later, but not over specifically pinned
   packages. For example,
   
should be changed to something along:

   Note that this has precedence over any general priority you set in the
   /etc/apt/preferences file described later, but not over specifically pinned
   packages. (In order to avoid confusion with /etc/apt/preferences settings,
   use of APT::Default-Release in /etc/apt/apt.conf is deprecated.)  For
   example,
   

That's my thought on this topic.

Osamu

On Mon, 2023-09-18 at 10:24 +0700, Max Nikulin wrote:
> On 16/09/2023 15:37, Osamu Aoki wrote:
> > So my first thought was replace it with:
> > 
> > - Release definition in "/etc/apt/apt.conf" configuration file started with
> > "APT::Default-Release"
> > 
> > But As I read complicationa it causes from your messages, let's drop it.  I
> > don't use it anyway.
> 
> Since the "APT::Default-Release" option is present in the document for 
> years, I would prefer to see a warning close to the current place where 
> it is mentioned. Consider somebody is asked about this setting and their 
> opens the reference to provide a link. Completely disappeared mention 
> may make them thinking that it was seen in another document.
> 
> I do not insist however. I admit that removing obsolete material 
> completely is widely used practice, so I am OK with your plan to just 
> drop it.
> 
>  From my point of view, it is worst variant when "APT::Default-Release" 
> is described without the not so trivial regexp or without a warning 
> concerning complications. This feature evolved into a kind of pitfall.
> 
> Thank you for your work on debian-reference.
> 
> 

Bug#1051979: Do not suggest APT::Default-Release setting

[Osamu Aoki]

Hi,

Thank you for careful review.


On Fri, 2023-09-15 at 15:01 +0700, Max Nikulin wrote:
> Package: debian-reference
> Version: 2.100
> 
> The "2.7.7. Tweaking candidate version with apt-pinning" section
> in "Chapter 2. Debian package management" recommends
> 
> > The target release archive can be set by several methods.
> > 
> > - "/etc/apt/apt.conf" configuration file with "APT::Default-Release
> > "stable";" line
> > - command line option, e.g., "apt-get install -t testing some-package"
> 
> https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tweaking_candidate_version
> 
> Unfortunately "APT::Default-Release "stable";" prevents installing of 
> updates from stable-security and stable-updates repositories. So this 
> option should be either just dropped or a warning should be added to 
> alert users who remembers it from previous release.

I see your concern.  I merely meant to point out "APT::Default-Release
> > "...";" line sets "Default-Release".  I don't meant to use it with "stable"

So my first thought was replace it with:

- Release definition in "/etc/apt/apt.conf" configuration file started with
"APT::Default-Release"

But As I read complicationa it causes from your messages, let's drop it.  I
don't use it anyway.

Bug#944102: create sources.list with signed-by

[Osamu Aoki]

Hi,

I think this proposal to use "signed-by" is a good idea.

But if you ever make such support, please consider to use deb822 style file
instead of one-line old style.

This way, we can avoid creating a source list configuration file with insanely
long line can be avoided.  (I don't know which key is the best choice though.)

My local /etc/apt/sources.list.d/debian.sources


  types: deb deb-src
  uris: http://deb.debian.org/debian/
  suites: bookworm
  components: main non-free-firmware contrib non-free
  signed-by: /usr/share/keyrings/debian-archive-bookworm-automatic.gpg
  #Signed-By: /usr/share/keyrings/debian-archive-bookworm-stable.gpg
  #Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
  
  types: deb deb-src
  uris: http://security.debian.org/debian-security/
  suites: bookworm-security   
  components: main non-free-firmware contrib non-free
  signed-by: /usr/share/keyrings/debian-archive-bookworm-security-automatic.gpg
  #Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg


Osamu

Bug#1032453: locales and locales-all

[Osamu Aoki]

Hi,

I understand at least I need to do s/creating/create/ .

But that may not address lost feeling of bug reporter.

I am thinking to update:

The locales-all package comes with all locale data pre-compiled but doesn't
creating "/etc/default/locale".

with:

The locales-all package comes with pre-compiled locale data for all locale data.
Since it doesn't create "/etc/default/locale", you may still need to install the
locales package, too.



The locales package of some Debian derivative distributions come with pre-
compiled locale data for all locale data. You need to install both locales and
locales-all packages on Debian to emulate such system environment.


I am intensionally vague not to specify Ubuntu here.

Osamu

Bug#1043039: debian-reference: apt-key deprecated, demote apt-pinning, ...

[Osamu Aoki]

Source: debian-reference
Version: 2.100
Severity: normal
X-Debbugs-Cc: xiao sheng wen(肖盛文) , eulalio 
, Locid , Felipe Nogueira 
, Guillonneau Jean-Paul , 
Beatrice Torracca , Andika Triwidada , 
Kwam's Sammy 

Hi,

Non-free-firmware is in Debian.

One thing is SC text change 1.1 -> 1.2.
DR is updated in git
  b5da8ee ("Update for SC 1.2", 2023-08-05)
(This is for https://bugs.debian.org/1032453)

For bookworm, I only made minimal changes to avoid translation problem.
Now that it is released, I need to includ non-free-firmware references
everywhere.

Other issues I see are:

* DR need to address apt-key deprecation.
* deb822 sources.list need to be included to prepare for future changes.
* Older text tends to lead users to use apt-pinning since there were no
  pointers to alternative solution.  Flatpak etc.
* Chaper 2 contents may be reordered to make it easy to read without
  requiring translation updates.
* Text in DR can be made more robust for release process.  So I can
  switch Stable release name before release just around early freeze
  phase.

Recent git commit: 
  0ed6188 ("reorder and deb822 etc.", 2023-07-29)
should address these issues.

Fixes for English have been commited to git repo.

Translation for these changes are highly appreciated.

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

Kernel: Linux 6.1.0-10-amd64 (SMP w/12 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

Bug#1032453: non-free-firmware changes and documentation needs to happen after SC change

[Osamu Aoki]

Hi,

On Thu, 2023-06-08 at 14:26 +0200, Laura Arjona Reina wrote:
> Hello
> 
> Apologies for the late reply.
> 
> I have reviewed our why_debian page (https://www.debian.org/intro/why_debian) 
> and I don't see the need of update to reflect non-free-firmware related
> changes: 
> The sentence about Debian being 100% free can stay the same as Social Contract
> §1 states; and the changes that were made to the Social Contract with the GR
> are 
> not mentioned in our why_debian page.

Thanks for your input.  Very true.

Since Debian Reference quotes SC, I need to update Debian Reference.

As for the discussion below for the text style (negative...), I decided to keep
current text to avoid additional translation works for trivial stylistic points.
 
> El 21/4/23 a las 18:43, Osamu Aoki escribió:
> > Hi,
> > 
> > 
> > On Fri, 2023-04-21 at 15:35 +0200, Laura Arjona Reina wrote:
> > > Hello
> > > 
> > > El 21 de abril de 2023 14:30:24 CEST, Osamu Aoki 
> > > escribió:
> > ...
> > > 
> > > > So this why_debian page needs to be updated first.
> > ...
> > > > But in order to update this why_debian page properly, I think we need to
> > > > wait SC change.  (I CC debian-www@d.o ML)
> > ...
> > > > No agreement has been reached on SC text since that is the next planned
> > > > action.
> > > > 
> > > 
> > > This already happened:
> > > 
> > > https://salsa.debian.org/webmaster-team/webwml/-/commit/79d1ad80a8ac84afa8c8a224b81fb50c327e6b4f
> > 
> > Oops.  Thanks.
> > 
> > > > Once the new SC text is accepted, I will update this §2.1.5 following
> > > > why_debian page on www.debian.org.
> > > > 
> > > 
> > > In a first pass I thought that the page why_debian didn't need an update.
> > > I'll
> > > look at this more closely, comparing with Debian Reference and other
> > > updated
> > > documents, during this weekend (if anybody wants to go ahead, I'm also
> > > happy
> > > to read  proposals from others).
> > 
> > I see we can still argue Debian is 100% FREE and leave the text as they are.
> > 
> > The question is how to address things written in updated SC in the updated
> > why_debian /debian-reference §2.1.5.  I mean the following part:
> > 
> > 
> > > Thus, although non-free works are not a part of Debian, we support their
> > > use
> > > and provide infrastructure for non-free packages (such as our bug tracking
> > > system and mailing lists). The Debian official media may include firmware
> > > that
> > > is otherwise not part of the Debian system to enable use of Debian with
> > > hardware that requires such firmware.
> > 
> > 
> > Some short footnote may help.  Since I don't like to use negated text, I may
> > add
> > text along following as footnote later.  (This is my first thought.  I may
> > need
> > to think more.)
> > 
> > 
> > > Debian project supports use of non-free works and provides infrastructure
> > > for
> > > non-free packages (such as our bug tracking system and mailing lists). The
> > > Debian official media may include firmware that is otherwise not part of
> > > the
> > > Debian system to enable use of Debian with hardware that requires such
> > > firmware.
> > 
> > But before doing this, I want to see how why_debian deals this.

Bug#1040807: Processed: Re: Bug#1040807: debian-reference: typo hdparam(8) -> hdparm(8)

[Osamu Aoki]

Hi,

Good catch.  Thanks.

On Tue, 2023-07-11 at 00:00 +, Debian Bug Tracking System wrote:
> Processing control commands:
> 
> > tags -1 pending
> Bug #1040807 [debian-reference] debian-reference: typo hdparam(8) -> hdparm(8)
> Added tag(s) pending.

For these trivial typo fix, you may fix PO files if you have extra time.

Osamu

Bug#1036635: default papersize is always "letter"

[Osamu Aoki]

Package: libpaper-utils
Version: 1.1.29
Severity: normal

Hi, I tried with all pointing to "a4", but I get "letter".
```sh
$ ls -l /etc/papersize
-rw-r--r-- 1 root root 3 May 23 23:24 /etc/papersize
$ cat /etc/papersize
a4
$ LANG=ja_JP.UTF-8 LC_ALL=ja_JP.UTF-8 LC_PAPER=ja_JP.UTF-8 PAPERSIZE=a4 
PAPERCONF=/etc/papersize paperconf -d
letter
```
There is something wrong?  Or am I doing things wrong?

How can I set default paper size to "a4".

FYI:
$ LANG=ja_JP.UTF-8 LC_ALL=ja_JP.UTF-8 LC_PAPER=ja_JP.UTF-8 PAPERSIZE=a4 
PAPERCONF=/etc/papersize locale
LANG=ja_JP.UTF-8
LANGUAGE=en_US:en
LC_CTYPE="ja_JP.UTF-8"
LC_NUMERIC="ja_JP.UTF-8"
LC_TIME="ja_JP.UTF-8"
LC_COLLATE="ja_JP.UTF-8"
LC_MONETARY="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_PAPER="ja_JP.UTF-8"
LC_NAME="ja_JP.UTF-8"
LC_ADDRESS="ja_JP.UTF-8"
LC_TELEPHONE="ja_JP.UTF-8"
LC_MEASUREMENT="ja_JP.UTF-8"
LC_IDENTIFICATION="ja_JP.UTF-8"
LC_ALL=ja_JP.UTF-8

So paperconf should be running under ja_JP.UTF8 (in the same papersize=a4 
world.)

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/12 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

Versions of packages libpaper-utils depends on:
ii  libc6  2.36-9
ii  libpaper1  1.1.29

libpaper-utils recommends no packages.

libpaper-utils suggests no packages.

-- no debconf information

Bug#1032453: non-free-firmware changes and documentation needs to happen after SC change

[Osamu Aoki]

Hi,


On Fri, 2023-04-21 at 15:35 +0200, Laura Arjona Reina wrote:
> Hello
> 
> El 21 de abril de 2023 14:30:24 CEST, Osamu Aoki  escribió:
...
> 
> > So this why_debian page needs to be updated first.
...
> > But in order to update this why_debian page properly, I think we need to
> > wait SC change.  (I CC debian-www@d.o ML)
...
> > No agreement has been reached on SC text since that is the next planned
> > action.
> > 
> 
> This already happened:
> 
> https://salsa.debian.org/webmaster-team/webwml/-/commit/79d1ad80a8ac84afa8c8a224b81fb50c327e6b4f

Oops.  Thanks.

> > Once the new SC text is accepted, I will update this §2.1.5 following
> > why_debian page on www.debian.org.
> > 
> 
> In a first pass I thought that the page why_debian didn't need an update. I'll
> look at this more closely, comparing with Debian Reference and other updated
> documents, during this weekend (if anybody wants to go ahead, I'm also happy
> to read  proposals from others).

I see we can still argue Debian is 100% FREE and leave the text as they are.

The question is how to address things written in updated SC in the updated
why_debian /debian-reference §2.1.5.  I mean the following part:


> Thus, although non-free works are not a part of Debian, we support their use
> and provide infrastructure for non-free packages (such as our bug tracking
> system and mailing lists). The Debian official media may include firmware that
> is otherwise not part of the Debian system to enable use of Debian with
> hardware that requires such firmware.


Some short footnote may help.  Since I don't like to use negated text, I may add
text along following as footnote later.  (This is my first thought.  I may need
to think more.)


> Debian project supports use of non-free works and provides infrastructure for
> non-free packages (such as our bug tracking system and mailing lists). The
> Debian official media may include firmware that is otherwise not part of the
> Debian system to enable use of Debian with hardware that requires such
> firmware.

But before doing this, I want to see how why_debian deals this.

Regards,

Osamu

Bug#1032453: non-free-firmware changes and documentation needs to happen after SC change

[Osamu Aoki]

Thank you for your reminder to update "Debian Reference".

> 
> With the non-free-firmware changes, the text in §2.1.5 seems to need
> an update. It reads like this:
...
> 
> But the first and third points are no longer true? So it seems these
> do not work as reasons to explain why Debian is %100 free software.
> 
> I think some other non-free references need to be updated or
> non-free-firmware added to the «contrib, non-free» lists. One such
> example is the reference to «non-free/kernel».

I agree this eventually needs to be update.  For upcoming bookworm release, I
think it is premature to update §2.1.5 and I have only updated technical side of
this change at: "Table 2.3. List of Debian archive area".

https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#listofdebianarchivearea


This is something I can do as recording facts. So I did it.

I didn't invent the section §2.1.5.  It is from Debian web page.
  Reasons to use Debian / why_debian
  https://www.debian.org/intro/why_debian


So this why_debian page needs to be updated first.

But in order to update this why_debian page properly, I think we need to wait SC
change.  (I CC debian-www@d.o ML)

What has happened is "General Resolution: non-free firmware" is decided as
"Choice 5: Change SC for non-free firmware in installer, one installer".
  https://www.debian.org/vote/2022/vote_003#textf
  https://www.debian.org/vote/2022/vote_003#outcome

No agreement has been reached on SC text since that is the next planned action.

Once the new SC text is accepted, I will update this §2.1.5 following why_debian
page on www.debian.org.

Please bug me when the situation over this issue matures.  I will keep this as
an open bug for now.

Regards,

Osamu

Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian

[Osamu Aoki]

Hi,

This is very convoluted issue.

Disclaimer: I use (n)vim and anthy and voted for non-free-firmware=yes (i.e.,
prioritize user experience)

On Thu, 2023-03-02 at 09:42 +, Simon McVittie wrote:
> Control: tags -1 + moreinfo
> 
> On Sat, 28 Jan 2023 at 16:46:35 +0900, YOSHINO Yoshihito wrote:
> > As mentioned in Bug #984875, gnome-initial-setup's default choice of
> > input method is hardcoded in the dependent libgnome-desktop-4-2 package.
> > The Japanese one is anthy
> > https://sources.debian.org/src/gnome-desktop/43.1-1/libgnome-desktop/default-input-sources.h/#L39
> > preferred by upstream (Fedora/Red Hat) perhaps because its code base is
> > simple and easy to maintain, while this is not suitable for most Debian
> > Japanese users, who use mozc because of its better conversion quality,
> > thus task-japanese-gnome-desktop and task-japanese-desktop has preferred
> > mozc over anthy. So the hardcoded value should be adjusted for our
> > users.
> 
> Is there consensus among Japanese-speaking users of Debian that mozc is
> a better default for all Japanese speakers, including new users who are
> not familiar with GNOME or Debian?

Choice of input method engine and its framework are hot topics without easy
unanimous agreements. 

Before going into that kind of discussion, I would like to draw attention to
general performance perception and some technical points.

* Why mozc:
In general, mozc tends to provide better suggestions for the possible choice of
input conversion choices than ones provided by anthy.  This may be the reason
why people like mozc than anthy.

* Why anthy:
In debian/control, mozc source package comes as:
> Architecture: i386 amd64 armel armhf arm64 riscv64
while anthy doesn't have such limitation.  My vague memory tells me that the
code for mozc is written for the little endian system only.  (mozc's C++ header
file structure and shipped data requires specific endianness.)

Also data used for obtaining conversion proposals are more opaque for mozc. 
Data for anthy is more intuitive for modification than that of mozc.  Neither
are easy to do, though.

> I want to avoid changing this from anthy to mozc-jp, and then getting a
> second bug report from a different Japanese user saying that we need to
> change it back!
> 
> Looking at #984875 and #983653, I also see a mention of mozc only being
> available on certain architectures: it's available on x86, ARM and riscv64,
> but not on mips*el, ppc64el or s390x.

Correct.

> How does this interact with the default being mozc-jp? Do we need to use
> a #ifdef to make the default be mozc on architectures that have it, and
> anthy on architectures that don't?

If we decide to propose mozc as preferred choice, that should be a possible
choice.

> I'm also concerned that mozc still depends on GTK 2 (a switch to GTK
> 3 was tried and then reverted, see #967641). This is OK for bookworm,
> but will probably not be supportable in Debian 13.

> > Upstream prefers ibus-anthy for Japanese input
> 
> Please talk to upstream about this: if mozc is a better default for Debian,
> then it's probably also a better default for upstream.
>
> The only issue reports I could find upstream are
> https://gitlab.gnome.org/GNOME/gnome-desktop/-/issues/181 which is about
> switching the default from kkc to anthy, and
> https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/104 which is
> older and refers to kkc as being the default.

 * kkc and anthy are both in GPL: kkc was intended to be improved replacement of
anthy by RH developer.  Its resulting performance was not convincing to replace
anthy.  Anthy was by Japanese government sponsored and it's last updates was
gathered and organized by DD (muto-san).

 * mozc is mostly BSD-3-Clause with its opaque learned data being BSD-3-Clause-
with-ICOT-term.  It's by google employee, if I recall.  RH ppl may not like
opaqueness of learned data outside of their easy update.  Learned data is only
provided as a data dump.

> On Wed, 22 Feb 2023 at 15:09:15 +0900, ken...@xdump.org wrote:
> >   Thus with attached patch, gnome-initial-setup will not
> >   show label for mozc-jp as "日本語 (Mozc)" by default.
> 
> What would be the best label to be displayed there?
> 
> What is actually displayed instead?
> 
> >   To display label correctly, fetch_ibus_engines_result must be called 
> >   in advance.
> 
> That's probably not possible: fetch_ibus_engines_result is called
> asynchronously with the result of a D-Bus method call, so it's already
> called as early as possible, and before that point we don't have the
> necessary information.
> 
> Probably the best we can do there is to hard-code a special case for
> mozc-jp.
> 
>     smcv

In order to get mozc to be promoted to be more prominent position, we need to
make sure the maintainer of mozc feels comfortable.  He (Iwamatsu-san) seems to
be making curating many patches and making patch to keep up with gtk3
transition.  Gunnar also seems to be doing QA and regression checks. 

Bug#934536: info version shipped, but IMO complete, close this bug?

[Osamu Aoki]

Yes, info version is included and it contains appendix, too.

So closing this bug is right action.

Thanks for your effort.


On Thu, 2023-02-09 at 16:28 +, Holger Levsen wrote:
> hi,
> 
> actually I found the info version now, but it seems complete to me:
> 
> $ sudo apt install info
> $ info developers-reference
> 
> # voila. /usr/share/info/developers-reference.info.gz is where the file is.
> 
> So I'm still inclined to close this bug.
> 
> 

Bug#1030189: Let regular users know need to put non-free-firmware in sources.list

[Osamu Aoki]

Control: clone 1030189 -1
Control: reassign -1 debian-faq

Thanks Sven,

How about Debian FAQ?  Shouldn't it mention non-free-firmware

 * debian-faq package
 * https://www.debian.org/doc/manuals/debian-faq/ftparchives.en.html

FYI: I already updated debian-reference

https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_archive_basics

(minimal changes to avoid translation breakages)


> Le mer. 1 févr. 2023 à 21:36, Sven Joachim  a écrit :
> 
> > Control: reassign -1 release-notes
> >
...
> > Somehow, but how exactly?  Good question that was brought up on
> > debian-devel[2], alas without replies yet.
> >
> > Cheers,
> >    Sven
> >
> >
> > 1. https://lists.debian.org/debian-user/2023/01/msg00706.html
> > 2. https://lists.debian.org/debian-devel/2023/01/msg00312.html

Bug#1030282: non-free-firmware needs to be mentioned

[Osamu Aoki]

Source: debian-reference
Version: 2.99
Severity: normal

On /etc/apt/sources.list, we now need to mention non-free-firmware 
  * add non-free-firmware to example /e/a/s.l
  * add description of non-free-firmware

Also, since GNOME has migrated to use pipewire, this may need updates:
  * remove standard from pulseaudio side description
  * remove experimental from pipewire side description
  * pipewire-audio-client-libraries -> pipewire-alsa, pipewire-jack

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/12 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

Bug#1021339: VIM 8.2 deb etc.

[Osamu Aoki]

Hi,

On Thu, 2023-01-19 at 14:02 +0100, Xavier Bestel wrote:
> Le jeudi 19 janvier 2023 à 21:14 +0900, Osamu Aoki a écrit :
> [...]
> > the upstream neovim folks release a functional Debian package nvim-
> > linux64.deb at https://github.com/neovim/neovim/releases/ .
> 
> Unfortunately my laptop is arm64 (it's a Mac M1 with Debian on top), so
> these packages can't work.
> I'll just wait.

They also provide tar.gz source.  You can build binary executable by following:
> https://github.com/neovim/neovim/wiki/Building-Neovim#ubuntu--debian
> https://github.com/neovim/neovim/wiki/Installing-Neovim#install-from-source

Please note this build script downloads dependencies during its build process to
provide /usr/local/bin/nvim.  So this build script can't be used "as is" for the
official package build.  But for your local need, this may be a good option to
build functional executable binary.

Many new nvim scripts tends to require 0.8 features such as ones provided by the
treesitter and api such as lua autocmd.  After all, neovim is a fast moving
target --- 0.9 in a few weeks.   Some of its popular ecosystem tend to require
us to be on the bleeding edge of nvim release.

Good luck.

Osamu 

Bug#1021339: VIM 8.2 deb etc.

[Osamu Aoki]

Xavier,

Packaging the official Debian package needs to meet many requirements.  So we
may need to be patient.

Although it may not be obvious for us to find the link in the opening web page
of neovim, the upstream neovim folks release a functional Debian package nvim-
linux64.deb at https://github.com/neovim/neovim/releases/ .

If you need neovim 8.2 for ordinary PC workstation, you can install neovim using
"dpkg -i nvim-linux64.deb".  Good luck.

I am using it on my PC without much issues.  (I see some issues of updating
AstroNvim probably due to its depending package issues.)

Osamu  

Bug#1029112: Surprise build issue with ibus-libzhuyin

[Osamu Aoki]

Hi,

Debian official packages are required to build without downloading external
files during their build.  (Builddd is in isolated network environment only with
access to the Debian package repository.


> Tags: ftbfs

So if it requires wget file access, it is ftbfs.  Don't make build script to do
this.   ... (continue to the bottom).

> Making all in model
> make[4]: Entering directory '/<>/data/model'
> wget http://downloads.sourceforge.net/libzhuyin/models/model13.text.tar.gz
> /bin/bash: line 1: wget: command not found
> 
> And yes, it's true that wget is not included in Build-Depends. But 
> previously that has not been needed. This is from the buildlog for the 
> latest successful build:
> 
> Making all in model
> make[4]: Entering directory '/<>/data/model'
> rm -f phrase_index.bin pinyin_index.bin addon_phrase_index.bin 
> addon_pinyin_index.bin bigram.db tsi.bin
> gen_binary_files --table-dir ../../data/model
> import_interpolation --table-dir ../../data/model < 
> ../../data/model/interpolation2.text
> gen_unigram --table-dir ../../data/model
> 
> or just:
> 
> Making check in model
> make[3]: Entering directory '/<>/data/model'
> make[3]: Nothing to be done for 'check'.
> 
> I have not found any code changes which would explain the new behavior. 
> And when trying (in an Ubuntu PPA) to add wget to Build-Depends, it 
> failed to resolve the download URL. (It builds fine on my harddisk, though.)
> 
> I figured out that this patch would help it build successfully:
> 
> --- a/data/Makefile.am
> +++ b/data/Makefile.am
> @@ -27,7 +27,6 @@
> 
>    SUBDIRS = \
>    icons \
> -    model \
>    $(NULL)
> 
>    appdatadir = @datadir@/appdata
> 
> But since I don't know how that would affect the functionality of the 
> package, I have left it in its failed state for now.
> 
> In other words: I need help to solve this.


If I were you, I will build package "without this mod in an environment with
wget included as Build-dep" and "with this mod only without wget in chroot". 
Then I will check resulting binary packages.

If these generated packages contain different model data, then you need to
modify code to use pre-existing data and download such model data in advance to
be included in debian/ directory.  Of course, you need to check license terms of
such model data and document it.

If these contain same model data, your proposed fix should be OK.

Regards,

Osamu

Bug#1014052: ibus and xwayland

[Osamu Aoki]

Hi Yabuki-san,


Please check if new im-config 0.53-1 solves your issue.


We included patch proposed at:

  https://salsa.debian.org/input-method-team/im-config/-/merge_requests/16

TBH, I am not even sure this is the right solution to your problem or any
others.

I have no idea how X session startup code are used by different DMs and I don't
have enough resource (or time) to investigate this in depth.  (GDM3 vs. LightDM)

At least, this looks like a harmless patch which might solve double start of
ibus.

Regards,

Osamu

Bug#982062: Please mention API issues in README.Debian

[Osamu Aoki]

Hi,

As for https://bugs.debian.org/982062 which causes lack of bookmark
synchronization etc., I agree it is a minor bug.

Considering this will not be fixed by the upstream by reading this post. 
  https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html

Since this bug will certainly cause confusion to many users, it will be nice to
mention short not on this bug with resulting issues in README.Debian.

Osamu

Bug#1021352: goa issue with mail gone

[Osamu Aoki]

Hi,


As for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021352

I don't experience mail problem any more.

So this problem seems some tangent issue possibly related to some package
version dependency etc with some related packages.

I see similar issue reported (and I experienced previously).

But reproducing this bug is not so simple, I suppose.

Osamu

Bug#1021352: GOA malfunction for mails

[Osamu Aoki]

I can confirm this problem on my Debian testing system .

> gnome-online-accounts 3.46.0-1 

My workaround is:

Settings -> Online accounts -> Open my registered online account panel, 
--> Move Mail slide switch off/on
--> Click X on right top to close window

This trick worked every time

(I suppose changing this may have restated the 
> /usr/libexec/goa-daemon
 as I see "ps axjf".)
[2022-10-02] gnome-online-accounts 3.46.0-1 MIGRATED to testing (Debian testing
watch)

So this matches my experience of this problem.

Osamu

Bug#1021106: maint-guide: Typos in previous changelog entries

[Osamu Aoki]

On Sun, 2022-10-02 at 10:40 +0200, Helge Kreutzmann wrote:
>  * po: update de by Holger Wansing.
> 
> As I made the update between 1.2.48 and 1.2.49, please correct this to
> 
>  * po: update de by Helge Kreutzmann.
> 

Corrected.  Sorry.


> And the next line seems to be another typo:
> FTBR. → FTBFS.

This FTBR is for "fails to build reproducibly"

I see this marking at:
https://qa.debian.org/developer.php?login=os...@debian.org
for maint-guide
by https://reproducible-builds.org/citests/

(Explained now.)


Thanks.

Bug#1020855: unicode-cldr-core: Update to latest version

[Osamu Aoki]

On Tue, 2022-09-27 at 18:18 +0200, Bastian Germann wrote:
> Package: unicode-cldr-core
> Version: 32.0.1-1.1
> Severity: important
> 
> Please update the package to the latest version which is 41 currently.

Hi,

This package was packaged when ibus or its related software needed this as 
build dep.
Since then, it is not using this as I vaguely remember.

I was going to orphan or ask to remove this huge package.

Do you have active use case for this?

Do you want to take over?  

Once I find time to check current facts around this, I may ask package removal 
unless
someone takes over.

Osamu

Bug#1020821: po4a-gettextize sanity check too strict, please slow-down deprecation

[Osamu Aoki]

Martin,


On Tue, 2022-09-27 at 09:38 +0200, Martin Quinson wrote:
> I recently realized that some people were using po4a-gettextize in place
> of po4a-updatepo to create the po, even if that's absolutely not the expected
> way of using tools. That use of po4a-gettextize is not expected by the code, 
> so
> thing may well go wrong, either now or in the future. This is why I decided to
> drop that use of po4a-gettextize.


I think you need to update po4a(7) page.  The use case of po4a-gettext to 
create POT
is written there.  I updated this file when I added this overcomplicated use 
case. 
Overcomplicated tool situation is tough to maintain.

But, if you drop support, please match docs.

The thing is I now realize I can get the equivalent just using po4a command 
only. 
(Running twice)

Use of po4a-updatepo may save me some build time but I am now keeping it simple 
to
use po4a.

As for openCC use with po4a, it was rather simple to do.

debian-reference will be OK soon.

Osamu

Bug#1020821: po4a-gettextize sanity check too strict, please slow-down deprecation

[Osamu Aoki]

Hi,

You are correct.  I was using po4a-gettextize to update PO.

Good news is migration to pure po4a command only approach is not much of work.  
Just
a bit more CPU time waisted but ... it is actually cleaner.

After initial surprise, I tried a few experimental builds with cool head. I 
realized
I can easily migrate to pure po4a-way even for a document with lots (2.5K 
msgid) of
auto-generated contents without burdening the translators. Excluding 2.5K 
msgids is
important for each translators.  Just for the record, let me write down this 
for the
record.

* create original English document
* create filtered and trimmed English document
* move existing po's to po4a places (Maybe this can be avoided but I wanted 
simple
proven set up)
* po4a -v po4a/po4a.cfg
   * use po4a/po4a.cfg to create and update PO using po4a in po4a/po
   * Useless generation of filtered translated document is the side effect
* cp -r po4a po4a-tmp
* cp -f po4a-tmp.cfg po4a-tmp/po4a-tmp.cfg
* po4a -v po4a-tmp/po4a-tmp.cfg
   * use po4a-tmp/po4a-tmp.cfg to create and update PO using po4a (no need to 
store
result)
   * Important generation of full translated document
* rm -rf po4a-tmp

Pure po4a approach doesn't allow me to use auto translation between zh-tw and 
zh-cn
but this is not so critical.  Maybe this can be addressed too with the help of
gettext package and script.  (Instead of just "cp -r", we run script I suppose.)


On Tue, 2022-09-27 at 09:38 +0200, Martin Quinson wrote:
> Hello,
> 
> Here is a quick first answer. I'll check more later but I'm busy these days 
> so I
> have to do a fast approximate answer, or you'll have to wait for a sloow
> answer.
> 
> I think that the deprecation is not involved in your problem. It's another
> issue. I recently realized that some people were using po4a-gettextize in 
> place
> of po4a-updatepo to create the po, even if that's absolutely not the expected
> way of using tools. That use of po4a-gettextize is not expected by the code, 
> so
> thing may well go wrong, either now or in the future. This is why I decided to
> drop that use of po4a-gettextize.
> 
> Please try to use po4a-updatepo instead and tell me if it solves the issue as 
> I
> suspect.
> 
> Thanks for your time and for reporting,
> Mt
> 
> Le mardi 27 septembre 2022 à 15:40 +0900, Osamu Aoki a écrit :
> > Package: po4a
> > Version: 0.68-1
> > Severity: normal
> > 
> > Hi,
> > 
> > I am experiencing FTBFS on debian-reference and maint-guide
> > 
> > If you want to deprecate po4a-translate and po4a-updatepo and force me
> > to use po4a, that's sad but I understand your position.  Maintenance of
> > them may be burden for you.  But can we do this with a bit more
> > coordination and with transition period.
> > 
> > I am facing problem with new 0.68-1
> > 
> >     - Greatly improve the gettextization process
> >     - po4a-translate and po4a-updatepo are now deprecated:
> >   you should use po4a instead.
> > 
> > Error I am facing is as follows:
> > 
> > po4a-gettextize -M utf-8 -L utf-8 --format docbook -m 
> > debian-reference.en.xmlt
> > > \
> > sed -e 's,^"Content-Type: text/plain; charset=CHARSET\\n"$,"Content-Type:
> > text/plain; charset=UTF-8\\n",' |\
> > msgcat --no-location -o po/templates.pot.new -
> > You must provide the same amount of master files and localized files to
> > synchronize them, as po4a-gettextize is intended to synchronize master files
> > and previously existing translations. If just want to extract POT files of
> > your master files, please use po4a-updatepo. Please note that the most
> > convenient way of using po4a is to write a po4a.conf file and use the
> > integrated po4a(1) program.
> > if diff -I '^"POT-Creation-Date:' -q po/templates.pot po/templates.pot.new ;
> > then \
> >   echo "Don't update templates.pot" ;\
> >   touch po/templates.pot ;\
> >   rm -f po/templates.pot.new ;\
> > else \
> >   echo "Update templates.pot" ;\
> >   mv -f po/templates.pot.new po/templates.pot ;\
> > fi
> > diff: po/templates.pot: No such file or directory
> > diff: po/templates.pot.new: No such file or directory
> > 
> > 
> > template.pot is not generated by po4a-gettext any more 
> > 
> > I intensionally touch-up master file to reduce translation PO file size
> > by placing "DUMMY" to certain master file contents used by
> > po4a-gettextize.  So those parts doesn't apear in po/pot and translator
> > have easier time.  In order to attain this, I directly use
> > po4a-translate and po4a-updatepo from Makefile to get translated results
&g

Bug#1020821: po4a-gettextize sanity check too strict, please slow-down deprecation

[Osamu Aoki]

Package: po4a
Version: 0.68-1
Severity: normal

Hi,

I am experiencing FTBFS on debian-reference and maint-guide

If you want to deprecate po4a-translate and po4a-updatepo and force me
to use po4a, that's sad but I understand your position.  Maintenance of
them may be burden for you.  But can we do this with a bit more
coordination and with transition period.

I am facing problem with new 0.68-1

- Greatly improve the gettextization process
- po4a-translate and po4a-updatepo are now deprecated:
  you should use po4a instead.

Error I am facing is as follows:

po4a-gettextize -M utf-8 -L utf-8 --format docbook -m debian-reference.en.xmlt 
| \
sed -e 's,^"Content-Type: text/plain; charset=CHARSET\\n"$,"Content-Type: 
text/plain; charset=UTF-8\\n",' |\
msgcat --no-location -o po/templates.pot.new -
You must provide the same amount of master files and localized files to 
synchronize them, as po4a-gettextize is intended to synchronize master files 
and previously existing translations. If just want to extract POT files of your 
master files, please use po4a-updatepo. Please note that the most convenient 
way of using po4a is to write a po4a.conf file and use the integrated po4a(1) 
program.
if diff -I '^"POT-Creation-Date:' -q po/templates.pot po/templates.pot.new ; 
then \
  echo "Don't update templates.pot" ;\
  touch po/templates.pot ;\
  rm -f po/templates.pot.new ;\
else \
  echo "Update templates.pot" ;\
  mv -f po/templates.pot.new po/templates.pot ;\
fi
diff: po/templates.pot: No such file or directory
diff: po/templates.pot.new: No such file or directory


template.pot is not generated by po4a-gettext any more 

I intensionally touch-up master file to reduce translation PO file size
by placing "DUMMY" to certain master file contents used by
po4a-gettextize.  So those parts doesn't apear in po/pot and translator
have easier time.  In order to attain this, I directly use
po4a-translate and po4a-updatepo from Makefile to get translated results
with the full English file with reduced size PO.

Please also realize that my Makefile also use opencc to translate
missing translation msgstr in PO files supplimenting between zh_CN and
zh_TW peacefully.  po4a command has no way to do this either.

Since this failure seems to be induced by the newly added sanity check
to force us to migrate to use po4a, I am asking you to go slow on this
migration.  Can you just give us option to avoid this failure at least
for the next release?  Do you really force this sanity check now?

I hope to come up with new build script using po4a.  But unless that
happens, debian-reference and maint-guide will be out of testing.



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

Kernel: Linux 5.19.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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages po4a depends on:
ii  gettext 0.21-9
ii  libpod-parser-perl  1.65-1
ii  libsgmls-perl   1.03ii-37
ii  libsyntax-keyword-try-perl  0.27-1
ii  libyaml-tiny-perl   1.73-1
ii  opensp  1.5.2-13+b2
ii  perl5.34.0-5

Versions of packages po4a recommends:
ii  liblocale-gettext-perl 1.07-4+b2
ii  libterm-readkey-perl   2.38-2
ii  libtext-wrapi18n-perl  0.06-10
ii  libunicode-linebreak-perl  0.0.20190101-1+b4

po4a suggests no packages.

-- no debconf information

Bug#1020274: ITP: dual-function-keys -- interception plugin for generic dual function keys

[Osamu Aoki]

Package: wnpp
Severity: wishlist
Owner: Osamu Aoki 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: dual-function-keys
  Version : 1.5.0
  Upstream Author : Alexander Courtis 
* URL : 
https://gitlab.com/interception/linux/plugins/dual-function-keys.git
* License : MIT
  Programming Lang: C
  Description : interception plugin for generic dual function keys

Package name above is the source package name.  The binary package is
prefixed with "interception-" in line with interception-caps2esc which
was uploaded today..

Recommends: interception-tools
Description: interception plugin for generic dual function keys
 Using dual-function-keys with interception-tools offers the flexible keyboard
 configure with dual-function capabilities under Wayland/X/Linux console.
 .
 This is a generic companion plugin program to mangle evdev data with
 interception-tools.  Basically, xmodmap-like functionality is realized
 at the kernel level in this way for arbitral keys.
 .
 If you just needs to use CapsLock key for dual function Esc/Ctrl key,
 please try the caps2esc plugin package as a starter which is simpler to
 set up.  But this dual-function-keys can configure tap and hold timing
 even for such case.

This package allows keymap customization via YAML file.
This is a part of official plugins from interception upstream.

Bug#1019967: ITP: caps2esc -- Filter for dual function Ctrl and Esc key at CapsLock

[Osamu Aoki]

Hi,


After good night sleep ...

On Sat, 2022-09-17 at 23:59 +0900, Osamu Aoki wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Osamu Aoki 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name    : caps2esc

I will use "interception-caps2esc" instead to make it easy to find and in line 
with
Arch practice.

>   Version : 0.3.2
>   Upstream Author : Francisco Lopes 
> * URL : https://gitlab.com/interception/linux/plugins/caps2esc
> * License : MIT
>   Programming Lang: C
>   Description : Filter for dual function Ctrl and Esc key at CapsLock

Description :Interception plugin for dual function Ctrl and Esc key at CapsLock

> Using caps2esc with interception-tools offers the optimal keyboard
> experience for vi/Vim/NeoVim aficionados under Wayland/X/Linux console.
> 
>  * Dual function Ctrl and Esc key at CapsLock key location
>  * CapsLock function key at Esc key location
> 
> Background:
> 
> This is one of the simplest but hugely useful companion filter program
> to mangle evdev data with interception-tools.  Basically, xmodmap-like
> functionality is realized at the kernel level in this way.
> 
> This recommends interception-tools which was just accepted to Debian
> unstable.
> 

Bug#1019967: ITP: caps2esc -- Filter for dual function Ctrl and Esc key at CapsLock

[Osamu Aoki]

Package: wnpp
Severity: wishlist
Owner: Osamu Aoki 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: caps2esc
  Version : 0.3.2
  Upstream Author : Francisco Lopes 
* URL : https://gitlab.com/interception/linux/plugins/caps2esc
* License : MIT
  Programming Lang: C
  Description : Filter for dual function Ctrl and Esc key at CapsLock

Using caps2esc with interception-tools offers the optimal keyboard
experience for vi/Vim/NeoVim aficionados under Wayland/X/Linux console.

 * Dual function Ctrl and Esc key at CapsLock key location
 * CapsLock function key at Esc key location

Background:

This is one of the simplest but hugely useful companion filter program
to mangle evdev data with interception-tools.  Basically, xmodmap-like
functionality is realized at the kernel level in this way.

This recommends interception-tools which was just accepted to Debian
unstable.

Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.

[Osamu Aoki]

Hi,

One think I noticed long time ago for GDM3 is it doesn't seem to use input 
method.

Now GNOME set up ibus infrastructure, it may be killing and cleaning input 
method to
provide clean start for GNOME.  I didn't check but it may be worth checking
situation.  Maybe this is something we can only deal as documenting limitation 
and
side effects for GDM3.  Just a thought...

On Sun, 2022-09-11 at 01:44 +0200, Gunnar Hjalmarsson wrote:
> On 2022-08-28 07:21, Yukiharu YABUKI wrote:
> > I have realized that this issue happended in GDM3 environment.
> > In LightDM environment, this issue does not happend.
> 
> Hmm.. So you have GDM3 installed, which depends on the core GNOME 
> packages including gnome-session-common. Maybe that GNOME user service 
> systemd file has something to do with it, after all.
> 
> Can we do an experiment?
> 
> 1. Change your ~/.xinput file to "none" using this command:
> 
>     im-config -n none
> 
> 2. Change your default display manager to GDM3.
> 
> 3. Reboot and log in.
> 
> 4. Find out if ibus-daemon is still running:
> 
>     ps aux | grep ibus
> 

Bug#1018693: manpage translation missing

[Osamu Aoki]

Source: adduser
Version: 3.128
Severity: normal

symptoms: piuparts run fails with:

0m17.8s ERROR: WARN: Broken symlinks:
  /usr/share/man/da/man8/addgroup.8.gz -> adduser.8.gz (adduser)
  /usr/share/man/da/man8/delgroup.8.gz -> deluser.8.gz (adduser)
  /usr/share/man/de/man8/addgroup.8.gz -> adduser.8.gz (adduser)
  /usr/share/man/de/man8/delgroup.8.gz -> deluser.8.gz (adduser)
  /usr/share/man/es/man8/delgroup.8.gz -> deluser.8.gz (adduser)
  /usr/share/man/fr/man8/addgroup.8.gz -> adduser.8.gz (adduser)
  /usr/share/man/fr/man8/delgroup.8.gz -> deluser.8.gz (adduser)
  /usr/share/man/it/man8/addgroup.8.gz -> adduser.8.gz (adduser)
  /usr/share/man/it/man8/delgroup.8.gz -> deluser.8.gz (adduser)
  /usr/share/man/pl/man8/addgroup.8.gz -> adduser.8.gz (adduser)
  /usr/share/man/pl/man8/delgroup.8.gz -> deluser.8.gz (adduser)
  /usr/share/man/pt/man8/addgroup.8.gz -> adduser.8.gz (adduser)
  /usr/share/man/pt/man8/delgroup.8.gz -> deluser.8.gz (adduser)
  /usr/share/man/ru/man8/addgroup.8.gz -> adduser.8.gz (adduser)
  /usr/share/man/ru/man8/delgroup.8.gz -> deluser.8.gz (adduser)
  /usr/share/man/sv/man8/delgroup.8.gz -> deluser.8.gz (adduser)
---

observation:
20a9f34 ("remove debconf", 2022-07-13)
This essentially stopped building translated manpages (I guess)

(This removed old debian/po/* but existing po/* seems to be not used for
building manapage)

As a result, translated manpage files such as
/usr/share/man/da/man8/adduser.8.gz are missing in current binary debs
while source contain po4a for manpage.

All these links are generated by debian/links and create dangling links. 

I don't see fix for these in salsa pending, yet.

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 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

Bug#1017762: incompatible after "btrfs subvolume set-default ..."

[Osamu Aoki]

Source: partman-btrfs
Version: 55
Severity: normal

It is great to have btrfs support with @rootfs.  Thanks.  I wish if it
is a bit more verbose on what it does in installer dialogue. This is
more important if we want to use existing btrfs with something like
@home-uid1000 in it ;-)

Anyway, I experienced an unsuccessful install to the existing btrfs
partition.  I had @rootfs-broken-backup in it and I set "btrfs subvolume
set-default ..." to it.   Don't ask me why I did.  But this caused d-i
to stop installation without much error report.

EXPECTED BEHAVIOR:

1.  Clearly mention the use of subvolume @rootfs in d-i dialogue.
(This is for both fsck or fsck-less install cases.)

2.  Check "btrfs subvolume get-default " to be "ID 5
(FS_TREE)".  If not,
* stop installation with clear message or (reasonable?)
* set-default to fix this. (better?)
(This is for fsck-less install)

3.  Check existance of @rootfs.  If exists, 
   * stop installation with clear message or (simple)
   * make a backup snapshot of @rootfs to some other name and
remove @rootfs to have clean start. (better)
   (This is for fsck-less install)

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 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

Bug#1017750: multiboot friendly /boot/efi/EFI/debian/grub.cfg update

[Osamu Aoki]

Control: tags -1 patch

Here is a proof-of-concept untested patch to address backup.

With this approach, backup suffix is UUID.


--- postinst.in.orig	2022-08-20 05:00:47.915499523 +0900
+++ postinst.in	2022-08-20 05:15:55.732025173 +0900
@@ -330,7 +330,6 @@
 echo "WARNING: Bootloader is not properly installed, system may not be bootable" >&2
 fi
 }
-
 case "$1" in
   configure)
 . /usr/share/debconf/confmodule
@@ -710,6 +709,10 @@
 FORCE_EXTRA_REMOVABLE="--force-extra-removable"
   fi
   NO_NVRAM="$(no_nvram_arg)"
+  if  -f /boot/efi/EFI/debian/grub.cfg ; then
+  SUFFIX=$(sed -n -e 's,^search.fs_uuid \([^ ]*\) root.*,\1,p' /boot/efi/EFI/debian/grub.cfg)
+  cp -f /boot/efi/EFI/debian/grub.cfg /boot/efi/EFI/debian/grub.cfg.$SUFFIX
+  fi
   run_grub_install --target="$target" "$FORCE_EXTRA_REMOVABLE" "$NO_NVRAM"
 fi
 

Bug#1017741: [PATCH] Update package description for EFI*

[Osamu Aoki]

Hi,

> -Original Message-
> From: Colin Watson 
> To: Osamu Aoki , 1017...@bugs.debian.org
> Subject: Re: Bug#1017741: [PATCH] Update package description for EFI*
> Date: Fri, 19 Aug 2022 20:24:32 +0100
> 
> On Sat, Aug 20, 2022 at 03:50:44AM +0900, Osamu Aoki wrote:
> > diff --git a/debian/control b/debian/control
> > index 71cca4436..74769e0eb 100644
> > --- a/debian/control
> > +++ b/debian/control
> > @@ -263,11 +263,11 @@ Description: GRand Unified Bootloader, version 2 
> > (EFI-IA32
> > modules)
> >  update-grub.
> >   .
> >   This package contains GRUB modules that have been built for use with the
> > - EFI-IA32 architecture, as used by Intel Macs (unless a BIOS interface has
> > - been activated).  It can be installed in parallel with other flavours, but
> > - will not automatically install GRUB as the active boot loader nor
> > - automatically update grub.cfg on upgrade unless grub-efi-ia32 is also
> > - installed.
> > + EFI-IA32 architecture, as used by modern PCs with UEFI (unless a legacy PC
> > + BIOS interface has been activated).  It can be installed in parallel with
> > + other flavours, but will not automatically install GRUB as the active boot
> > + loader nor automatically update grub.cfg on upgrade unless grub-efi-ia32 
> > is
> > + also installed.
> >  
> >  Package: grub-efi-ia32-dbg
> >  Section: debug
> > @@ -296,9 +296,9 @@ Description: GRand Unified Bootloader, version 2 
> > (EFI-IA32
> > version)
> >  update-grub.
> >   .
> >   This is a dependency package for a version of GRUB that has been built for
> > - use with the EFI-IA32 architecture, as used by Intel Macs (unless a BIOS
> > - interface has been activated).  Installing this package indicates that 
> > this
> > - version of GRUB should be the active boot loader.
> > + use with the EFI-IA32 architecture, as used by modern PCs with UEFI 
> > (unless a
> > + legacy PC BIOS interface has been activated).  Installing this package
> > + indicates that this version of GRUB should be the active boot loader.
> >  
> >  Package: grub-efi-ia32-signed-template
> >  Architecture: i386
> 
> This part of the patch looks wrong.  The efi-ia32 platform (i.e. 32-bit
> firmware; note that this is *not* about which OS architecture is in use)
> is in fact suitable for only very few modern PCs; IIRC there were a few
> others beyond just Intel Macs, though I think Intel Macs were still the
> majority sold.
> 
> The changes look more accurate for the efi-amd64 platform (i.e. 64-bit
> firmware).

Come to think of, you are 100% correct.

Bug#1017750: multiboot friendly /boot/efi/EFI/debian/grub.cfg update

[Osamu Aoki]

Package: grub-efi-amd64
Version: 2.06-3
Severity: wishlist

Currently, if you have dual boot of 2 Debian system installations, every
time grub2 of one system runs postinst, it overwrites
/boot/efi/EFI/debian/grub.cfg file in ESP pointing search.fs_uuid
pointing to lead to /boot/grub/* by UUID.

It doesn't backup existing /boot/efi/EFI/debian/grub.cfg.

If you consider this to be the result of upstream feature of update-grub
then it will be tough to be fixed.

But can you think of updating Debian postinst script to check the
existence of the /boot/efi/EFI/debian/grub.cfg file first and back it
up?  This helps recovery of system and trivial to be implemented.

I prefer time-stamped string as suffix for the backup file but this can
be anything maintainer likes.

This way, we can easily select /boot/grub/* after crash without manually
typing UUID.  Having at least 2 or 3 stage backups is more friendly.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/nvme0n1p5 / btrfs 
rw,relatime,ssd,space_cache,subvolid=22924,subvol=/@rootfs 0 0   <--- This is 
my main @rootfs
/dev/nvme0n1p5 /btrfs/main btrfs 
rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 0 0
/dev/nvme0n1p5 /home/osamu btrfs 
rw,relatime,ssd,space_cache,subvolid=596,subvol=/@osamu 0 0
/dev/nvme1n1p1 /btrfs/sub btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/ 
0 0 <--- This partition holds 2nd @rootfs
/dev/nvme0n1p1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0 <--- ESP
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates

 (snip uninteresting part)
 Followings are my custom dual boot configuration 

### BEGIN /etc/grub.d/40_fixed_linux ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'Debian GNU/Linux --- main SSD' --class debian --class gnu-linux 
--class gnu --class os $menuentry_id_option 
'gnulinux-fixed-fe3e1db5-6454-46d6-a14c-071208ebe4b1' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod btrfs
search --no-floppy --fs-uuid --set=root 
fe3e1db5-6454-46d6-a14c-071208ebe4b1
echo'Loading Linux from /dev/nvme0n1p5 ...'
linux   /@rootfs/vmlinuz root=UUID=fe3e1db5-6454-46d6-a14c-071208ebe4b1 
ro rootflags=subvol=@rootfs  quiet
echo'Loading initial ramdisk from /dev/nvme0n1p5 ...'
initrd  /@rootfs/initrd.img
}
menuentry 'Debian GNU/Linux --- sub SSD' --class debian --class gnu-linux 
--class gnu --class os $menuentry_id_option 
'gnulinux-fixed-51f9cd11-30b3-4d99-b2ed-fe411fa22ee6' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod btrfs
search --no-floppy --fs-uuid --set=root 
51f9cd11-30b3-4d99-b2ed-fe411fa22ee6
echo'Loading Linux from /dev/nvme1n1p1 ...'
linux   /@rootfs/vmlinuz root=UUID=51f9cd11-30b3-4d99-b2ed-fe411fa22ee6 
ro rootflags=subvol=@rootfs  quiet
echo'Loading initial ramdisk from /dev/nvme1n1p1 ...'
initrd  /@rootfs/initrd.img
}
### END /etc/grub.d/40_fixed_linux ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg
fi
### END /etc/grub.d/41_custom ###
*** END /boot/grub/grub.cfg


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 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

Versions of packages grub-efi-amd64 depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  grub-common2.06-3
ii  grub-efi-amd64-bin 2.06-3
ii  grub2-common   2.06-3
ii  ucf3.0043

grub-efi-amd64 recommends no packages.

grub-efi-amd64 suggests no packages.

-- debconf information:
  grub2/kfreebsd_cmdline:
* grub2/linux_cmdline:
* grub2/force_efi_extra_removable: false
* grub2/update_nvram: true
* grub2/linux_cmdline_default: quiet
  grub2/kfreebsd_cmdline_default: quiet

Bug#1017741: [PATCH] Update package description for EFI*

[Osamu Aoki]

Source: grub2
Version: 2.04-20
Severity: minor
Tags: patch

Most modern PCs has been sold with UEFI support for more than 10 years.

Microsoft's certification requirements for now obsolete Windows 8
required UEFI since 2012.

In 2006, Intel Mac was practically the only one but now Macs are
ARM-based.  So mentioning Macs here is misleading.

(Patch file may be sent separately.)

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

Kernel: Linux 5.18.0-4-amd64 (SMP w/12 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
>From 4ee56739aa78d51224c27a4ea1164160b2368347 Mon Sep 17 00:00:00 2001
From: Osamu Aoki 
Date: Sat, 20 Aug 2022 03:31:54 +0900
Subject: [PATCH] Update package description for EFI*

Most modern PCs has been sold with UEFI support for more than 10 years.

Microsoft's certification requirements for now obsolete Windows 8
required UEFI since 2012.

In 2006, Intel Mac was practically the only one but now Macs are
ARM-based.  So mentioning Macs here is misleading.

Signed-off-by: Osamu Aoki 
---
 debian/control | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/debian/control b/debian/control
index 71cca4436..74769e0eb 100644
--- a/debian/control
+++ b/debian/control
@@ -263,11 +263,11 @@ Description: GRand Unified Bootloader, version 2 
(EFI-IA32 modules)
 update-grub.
  .
  This package contains GRUB modules that have been built for use with the
- EFI-IA32 architecture, as used by Intel Macs (unless a BIOS interface has
- been activated).  It can be installed in parallel with other flavours, but
- will not automatically install GRUB as the active boot loader nor
- automatically update grub.cfg on upgrade unless grub-efi-ia32 is also
- installed.
+ EFI-IA32 architecture, as used by modern PCs with UEFI (unless a legacy PC
+ BIOS interface has been activated).  It can be installed in parallel with
+ other flavours, but will not automatically install GRUB as the active boot
+ loader nor automatically update grub.cfg on upgrade unless grub-efi-ia32 is
+ also installed.
 
 Package: grub-efi-ia32-dbg
 Section: debug
@@ -296,9 +296,9 @@ Description: GRand Unified Bootloader, version 2 (EFI-IA32 
version)
 update-grub.
  .
  This is a dependency package for a version of GRUB that has been built for
- use with the EFI-IA32 architecture, as used by Intel Macs (unless a BIOS
- interface has been activated).  Installing this package indicates that this
- version of GRUB should be the active boot loader.
+ use with the EFI-IA32 architecture, as used by modern PCs with UEFI (unless a
+ legacy PC BIOS interface has been activated).  Installing this package
+ indicates that this version of GRUB should be the active boot loader.
 
 Package: grub-efi-ia32-signed-template
 Architecture: i386
@@ -325,11 +325,11 @@ Description: GRand Unified Bootloader, version 2 
(EFI-AMD64 modules)
 update-grub.
  .
  This package contains GRUB modules that have been built for use with the
- EFI-AMD64 architecture, as used by Intel Macs (unless a BIOS interface has
- been activated).  It can be installed in parallel with other flavours, but
- will not automatically install GRUB as the active boot loader nor
- automatically update grub.cfg on upgrade unless grub-efi-amd64 is also
- installed.
+ EFI-AMD64 architecture, as used by modern PCs with UEFI (unless a legacy PC
+ BIOS interface has been activated).  It can be installed in parallel with
+ other flavours, but will not automatically install GRUB as the active boot
+ loader nor automatically update grub.cfg on upgrade unless grub-efi-amd64 is
+ also installed.
 
 Package: grub-efi-amd64-dbg
 Section: debug
@@ -358,9 +358,9 @@ Description: GRand Unified Bootloader, version 2 (EFI-AMD64 
version)
 update-grub.
  .
  This is a dependency package for a version of GRUB that has been built for
- use with the EFI-AMD64 architecture, as used by Intel Macs (unless a BIOS
- interface has been activated).  Installing this package indicates that this
- version of GRUB should be the active boot loader.
+ use with the EFI-AMD64 architecture, as used by modern PCs with UEFI (unless
+ a legacy PC BIOS interface has been activated).  Installing this package
+ indicates that this version of GRUB should be the active boot loader.
 
 Package: grub-efi-amd64-signed-template
 Architecture: amd64
-- 
2.35.1

Bug#1014052: org.freedesktop.IBus.session.* files

[Osamu Aoki]

Hi,

> -Original Message-
> From: Gunnar Hjalmarsson 
> Reply-To: Gunnar Hjalmarsson , 1014...@bugs.debian.org
> To: Osamu Aoki , 1014...@bugs.debian.org
> Cc: 1014052-submit...@bugs.debian.org
> Subject: Bug#1014052: org.freedesktop.IBus.session.* files
> Date: Thu, 11 Aug 2022 10:38:50 +0200
> 
> On 2022-08-11 05:22, Osamu Aoki wrote:
> > In the source tree there, I see:
> > > org.freedesktop.IBus.service.in
> > > org.freedesktop.IBus.session.generic.service.in
> > > org.freedesktop.IBus.session.GNOME.service.in
> > 
> > The first one was used before.  Now we don't seem to install the
> > first one but install other 2 files.
> 
> The first one is installed as
> 
> /usr/share/dbus-1/services/org.freedesktop.IBus.service
> 
> $ cat /usr/share/dbus-1/services/org.freedesktop.IBus.service
> [D-BUS Service]
> Name=org.freedesktop.IBus
> Exec=/usr/bin/ibus-daemon --replace --panel disable --xim
> 


Oh, wring file names in my original post and  ... My original concern for 
installed
systemd configuration files are there.  One for GNOME, one for others.  And 
others
seems to relyon some variable substitution.  Is it working correctly?

/usr/lib/systemd/user/ has followings:

> org.freedesktop.IBus.session.generic.service
> org.freedesktop.IBus.session.GNOME.service
> 

Osamu

Bug#1014052: org.freedesktop.IBus.session.* files

[Osamu Aoki]

Hi,

When I was doing something else, I accidentally see funny things in
/usr/lib/systemd/user, we now have 2 files:

* org.freedesktop.IBus.session.generic.service.in
* org.freedesktop.IBus.session.GNOME.service.in

This seems to come from new commits (salsa)
e6e270123 (Gunnar Hjalmarsson 2022-03-14 09:25:47 +0100  1)
in the source tree ibus/bus/services

I am wondering if we set 
> $IBUS_DAEMON_ARGS
correctly before calling ?

In the source tree there, I see:
> org.freedesktop.IBus.service.in
> org.freedesktop.IBus.session.generic.service.in
> org.freedesktop.IBus.session.GNOME.service.in
> 
The first one was used before.  Now we don't seem to install the first one but
install other 2 files.

Any though?

Bug#1011749: Uploaded package for interception-tools

[Osamu Aoki]

I have done complete new packaging with correct COPYRIGHT

Also minimized renaming and followed the upstream preferred set.

  intercept -> interception (intercept available in -compat package.)
  udevmon   -> udevmon (no change)
  uinput-> uinput (no change)
  mux   -> mux (no change)

Regards,

Osamu

Bug#627463: texlive-latex-base: link to PDF is not made properly

[Osamu Aoki]

Hi,

> -Original Message-
> From: Hilmar Preuße 
> To: Osamu Aoki 
> Cc: 627...@bugs.debian.org
> Subject: Re: Bug#627463: texlive-latex-base: link to PDF is not made properly
> Date: Sat, 3 Aug 2019 21:45:09 +0200
> 
> Am 20.05.2011 um 21:30 teilte Osamu Aoki mit:
> 
> Hi Osamu,
> 
> I'm going through some old bugs and check if they are still valid.
> 

Thanks.

> 
> Then I tried evince, which behaves differently, e.g. by clicking on the
> first link, the full document path expands to:
> 
> /home/hille/devel/TeXLive/open_bugs/627463/usr/share/doc/developers-
> reference/developers-reference.pdf
> 
> , where "/home/hille/devel/TeXLive/open_bugs/627463" is the $PWD, when I
> started evince.
> 
> So my impression is that one should speak to the developers of the pdf
> readers one by one. The links itself in the pdf files seem to be OK; at
> least when hovering over the links.
> 
> Let me know if the bug can be closed from the TeX Live side.

I agree with your assessment and closing this bug.  Thanks.

Osamu

Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.

[Osamu Aoki]

Hi,

> -Original Message-
> From: Yukiharu YABUKI 
> To: Osamu Aoki 
> Cc: 1014...@bugs.debian.org
> Subject: Re: Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` 
> change
> japanese to anthy with kanji key.
> Date: Mon, 1 Aug 2022 02:14:11 +0900
> 
> ...

> I did 'ps axjf'. This output was too big. I selected from output.
> ...
> python3 /usr/share/ibus-anthy/engine/main.py --ibus 1  385655  385641
> 385641 ? -1 Sl1000   0:11 /usr/libexec/ibus-x11
> --kill-daemon
> 

I don't know but "kill" sounds dangerous :-) but maybe OK.   It's installed by 
ibus.

Anyway, since you are running relatively minor desktop with i3, this may be the
reason.  Proper working of im-config rely on xdm/kdm like start up.

Since it is almost impossible to figure-out when did it broke, the best thing 
is to
set up testing VMs.

Then try different DE settings: GNOME -> KDE -> LXDE -> i3
Once you know when things break, we have better chance to identify issue.

Good luck.

Osamu 

Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.

[Osamu Aoki]

Hi, Yabuki-san and Gunnar,

Gunnar,

im-config has gone through several changes last several years to accommodate 
non-ibus
for GNOME on wayland.  We may have introduced some regression for X based 
system.

Since I don't use non-wayland system, we may have over looked problem there.

One point I am worried is ibus daemon starting process.  The currently, we 
don't set
"-r" to replace existing daemon.  Does im-config starts daemon twice?  Should 
we add
"-r" option there?  (I know it should not start twice.)

My GNOME start up has several start ups of ibus daemon.  Do we need similar ?
```
$ journalctl -a -b |grep 'ibus'
Jul 31 15:35:25 goofy /usr/libexec/gdm-wayland-session[1037]: dbus-daemon[1037]:
[session uid=116 pid=1037] Activating service name='org.gtk.vfs.Daemon' 
requested by
':1.22' (uid=116 pid=1366 comm="ibus-daemon --panel disable")
Jul 31 15:35:25 goofy /usr/libexec/gdm-wayland-session[1037]: dbus-daemon[1037]:
[session uid=116 pid=1037] Activating service name='org.freedesktop.portal.IBus'
requested by ':1.22' (uid=116 pid=1366 comm="ibus-daemon --panel disable")
Jul 31 15:35:25 goofy /usr/libexec/gdm-wayland-session[1037]: dbus-daemon[1037]:
[session uid=116 pid=1037] Activating service name='org.freedesktop.portal.IBus'
requested by ':1.35' (uid=116 pid=1514 comm="ibus-daemon --panel disable -r 
--xim")
Jul 31 15:35:32 goofy dbus-daemon[1749]: [session uid=1000 pid=1749] Activating
service name='org.freedesktop.portal.IBus' requested by ':1.61' (uid=1000 
pid=1986
comm="/usr/bin/ibus-daemon --panel disable")
```


Yabuki-san,

I don't understand your situation well.  Maybe telling me minimum set up to 
reproduce
under KVM may be a good idea.  Anyway, 

`ctrl+j` key-binding sounds like something ibus-anthy preference menu sets if 
you
ever set it so or it is the default. (I may have changed it on my system so I 
can't
check for you ...)  That's after having working ibus-anthy and using anthy as 
input
method.  It only changs operational mode of anthy.  You set it through anthy's
preference menu.

Switching between "日本語 - anthy" and "日本語 - japanese" sounds like switching 
between
different ibus engines.  That's usually SUPER-SPACE and its binding is set by  
ibus-
setup for pure classic X system.  (I usually don't bother enabling "日本語 - 
japanese"
as input method since I need more than Hiragana ... You can see which methods 
are
active by looking at ibus-setup GUI selection screen.)

Checking running processes on your system with "sudo ps axjf" may give you some 
idea.

As I checked on GNOME/wayland, it starts ibus daemon without --xim.
(excuse me for folded lines)

```
   PPID PIDPGID SID TTYTPGID STAT   UID   TIME COMMAND  

  0   2   0   0 ? -1 S0   0:00 [kthreadd]   

  2   3   0   0 ? -1 I<   0   0:00  \_ [rcu_gp] 

... skip
  0   1   1   1 ? -1 Ss   0   0:01 /sbin/init   

... skip
  1171917191719 ? -1 Ss1000   0:00
/lib/systemd/systemd --user 

... skip
   1719198319831983 ? -1 Ss1000   0:00  \_ sh -c
/usr/bin/ibus-daemon --panel disable $([ "$XDG_SESSION_TYPE" = "x11" ] && echo 
"--
xim")
   1983198619861983 ? -1 Sl1000   0:20  |   \_
/usr/bin/ibus-daemon --panel disable
   1986210519861983 ? -1 Sl1000   0:00  |   \_
/usr/libexec/ibus-dconf
   1986210619861983 ? -1 Sl1000   0:03  |   \_
/usr/libexec/ibus-extension-gtk3
   1986218319861983 ? -1 Sl1000   0:12  |   \_
python3 /usr/share/ibus-anthy/engine/main.py --ibus
   2183680819861983 ? -1 Z 1000   0:00  |   |   
\_
[python3] 
   1986289819861983 ? -1 Sl1000   0:00  |   \_
/usr/lib/ibus-mozc/ibus-engine-mozc --ibus
...
   1719549054905490 ? -1 Ssl   1000   0:24  \_
/usr/libexec/gnome-terminal-server
   5490550855085508 pts/0   7133 Ss1000   0:00  |   \_ bash
   5508713371335508 pts/0   7133 S+1000   0:00  |   |   \_
/usr/bin/mc -P /tmp/mc-osamu/mc.pwd.5508
   7133713571357135 pts/1   7135 Ss+   1000   0:00  |   |   
\_
bash -rcfile .bashrc
   5490749074907490 pts/2   8568 Ss1000   0:00  |   \_ bash
   7490856885687490 pts/2   8568 S+   0   0:00  |   |   \_ 
sudo
ps axjf
   8568856985698569 pts/3   8570 Ss   0   0:00  |   |   
\_
sudo ps axjf
   8569857085708569 pts/3   8570 R+   0   0:00  |   |   
   
\_ ps axjf
   5490795179517951 pts/4   8044 Ss1000   0:00  |   \_ bash
   7951804480447951 pts/4   8044 S+1000   0:00  |   |   \_
/usr/bin/mc -P /tmp/mc-osamu/mc.pwd.7951
   80448046 

Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.

[Osamu Aoki]

Hi,

> -Original Message-
> From: Yukiharu YABUKI 
> To: Gunnar Hjalmarsson 
> Cc: Osamu Aoki , 1014...@bugs.debian.org
> Subject: Re: Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` 
> change
> japanese to anthy with kanji key.
> Date: Sat, 30 Jul 2022 00:30:02 +0900
> 
> Hi,
> 
> I did execute im-config. Then I choose ibus. 
> So im-config made ~/.xinputrc
> 
> ~/.xinput contains
> 
> # im-config(8) generated on Sat, 30 Jul 2022 00:23:42 +0900
> run_im ibus
> # im-config signature: f863f9b702709aac186b408cc110240c  -
> ```
> 
> On Thu, 28 Jul 2022 22:51:10 +0200
> Gunnar Hjalmarsson  wrote:
> 
> > Actually, with im-config installed, there shouldn't be a need for any 
> > kind of configuration in your $HOME. ibus should still be started and 
> > properly configured.
> > 
> > Do you possibly have some extra configuration which conflicts with 
> > im-config?
> 
> --
> Yukiharu YABUKI 


So you are still suffering ... Strange.

Do you have the same issue with any GTK program?  Say lxterminal ?

If program using ibus/anthy is GTK, it doesn't access such daemon.  It access 
library
instead.  So the symptom reported is strange.

Are you suffering this problem with rxvt or xterm?

Please double check if your power-down is the real one (not sleep button) by 
shutting
down system from the virtual Linux console command line (ALT-CTRL-F3 etc.) with 
"sudo
shutdown -h now" or similar.

Osamu

> > 

Bug#1015786: marked as pending in neovim

[Osamu Aoki]

> Control: tag -1 pending

Thanks.

I also think your fix is most reasonable choice.

Osamu

Bug#1015785: source only update issue

[Osamu Aoki]

Hi,

You are correct.

Since maint-guide is now deprecated and not actively updated, with next upload 
I only
mention as:

-Debian now requires source-only uploads for normal upload.  So this page is
outdated.
-
-

My updated debmake-doc is maint-guide replavement.  It mentions source-only 
uploads
but intentionally leaves when binary upload is needed.  I think security upload 
is
(was?) another one. Since this is moving target, I redirect reader to
https://wiki.debian.org/SourceOnlyUpload ,
So there is no bug in debmake-doc.

Since you know well, please update "RESTRICTION" section in the wiki page.

Thanks.

Osamu

Bug#1015786: Retitle #1015786

[Osamu Aoki]

Control: retitle -1 Update recommend and suggests for paste action
thanks

Bug#1015786: rc

[Osamu Aoki]

Package: neovim
Version: 0.7.2-3
Severity: wishlist

neovim support modern pasting now.

In light of this updating dependency further with following packages may
be good idea.

* "wl-clipboard" (this is even higher priority than "xclip")
* "tmux"

Details:

Currently, neovim recommends:
  --\ Recommends (3)
--- python3-pynvim
--- xclip | xsel
--- xxd
  --\ Suggests (2)
--- ctags
--- vim-scripts

On the other hand, `:h clipboard-tool`  lists

  - g:clipboard
  - pbcopy, pbpaste (macOS)
  - wl-copy, wl-paste (if $WAYLAND_DISPLAY is set)
  - xclip (if $DISPLAY is set)
  - xsel (if $DISPLAY is set)
  - lemonade (for SSH) https://github.com/pocke/lemonade
  - doitclient (for SSH) http://www.chiark.greenend.org.uk/~sgtatham/doit/
  - win32yank (Windows)
  - termux (via termux-clipboard-set, termux-clipboard-set)
  - tmux (if $TMUX is set)

If I am not mistaken, it seems natural to add "wl-clipboard" as another
recommends entry

Also, it only lists "tmux" and no "screen".  If this is due to lack of
paste support by "screen", including "tmux" in recommends or suggests
may be a good idea.

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/12 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

Versions of packages neovim depends on:
ii  libc62.33-8
ii  libluajit-5.1-2  2.1.0~beta3+git20220320+dfsg-4
ii  libmsgpackc2 3.3.0-4
ii  libtermkey1  0.22-1
ii  libtree-sitter0  0.20.6-1
ii  libunibilium42.1.0-1
ii  libuv1   1.44.1-2
ii  libvterm00.1.4-1
ii  lua-luv  1.43.0-0-2
ii  neovim-runtime   0.7.2-3

Versions of packages neovim recommends:
ii  python3-pynvim  0.4.2-2
ii  xclip   0.13-2
ii  xxd 2:8.2.4793-1

Versions of packages neovim suggests:
ii  exuberant-ctags [ctags]  1:5.9~svn20110310-16
ii  vim-scripts  20210124.2

-- no debconf information

Bug#1014899: Debian adaptation

[Osamu Aoki]

Hi,

I created a patch to adopt timeshift to typical Debian system installed by d-i.

Thiis is FYI.

This is rather a big patch set.  I am not going to maintain this but as a 
proof-of-
concept.  Now I can make snapshot for /.  (I have separate subvolum for 
/home/
so snapshot of /home is useless.)

The best fix may be work with upstream to make @rootfs and @home configurable
parameter.  But this may help identify where you need to refactor.

I am not going to label as + patch

Osamu
From 579ad52e500b38ed176a071e99e62ae5f2483709 Mon Sep 17 00:00:00 2001
From: Osamu Aoki 
Date: Fri, 15 Jul 2022 22:26:09 +0900
Subject: [PATCH] @ -> @rootfs

Signed-off-by: Osamu Aoki 
---
 src/Console/AppConsole.vala |  2 +-
 src/Core/Main.vala  | 68 -
 src/Core/Snapshot.vala  |  8 ++--
 src/Core/SnapshotRepo.vala  | 12 +++---
 src/Core/Subvolume.vala |  4 +-
 src/Gtk/RestoreDeviceBox.vala   |  2 +-
 src/Gtk/SnapshotBackendBox.vala |  2 +-
 src/Gtk/SnapshotListBox.vala|  8 ++--
 8 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/src/Console/AppConsole.vala b/src/Console/AppConsole.vala
index 3084e87..12fcc1a 100644
--- a/src/Console/AppConsole.vala
+++ b/src/Console/AppConsole.vala
@@ -688,7 +688,7 @@ public class AppConsole : GLib.Object {
 
 if (App.btrfs_mode && !App.check_device_for_backup(dev, true)){
 	log_error(_("Selected snapshot device is not a system disk"));
-	log_error(_("Select BTRFS system disk with root subvolume (@)"));
+	log_error(_("Select BTRFS system disk with root subvolume (@rootfs)"));
 	dev = null;
 }
 			}
diff --git a/src/Core/Main.vala b/src/Core/Main.vala
index bb53e38..38a2ba1 100644
--- a/src/Core/Main.vala
+++ b/src/Core/Main.vala
@@ -373,14 +373,14 @@ public class Main : GLib.Object{
 
 		log_debug("check_btrfs_layout_system()");
 
-		bool supported = sys_subvolumes.has_key("@");
+		bool supported = sys_subvolumes.has_key("@rootfs");
 		if (include_btrfs_home_for_backup){
 			supported =  supported && sys_subvolumes.has_key("@home");
 		}
 
 		if (!supported){
 			string msg = _("The system partition has an unsupported subvolume layout.") + " ";
-			msg += _("Only ubuntu-type layouts with @ and @home subvolumes are currently supported.") + "\n\n";
+			msg += _("Only Debian-type layouts with @rootfs and @home subvolumes are currently supported.") + "\n\n";
 			msg += _("Application will exit.") + "\n\n";
 			string title = _("Not Supported");
 			
@@ -406,7 +406,7 @@ public class Main : GLib.Object{
 
 if (dev_home != dev_root){
 	
-	supported = supported && check_btrfs_volume(dev_root, "@", unlock);
+	supported = supported && check_btrfs_volume(dev_root, "@rootfs", unlock);
 
 	if (include_btrfs_home_for_backup){
 		supported = supported && check_btrfs_volume(dev_home, "@home", unlock);
@@ -414,10 +414,10 @@ public class Main : GLib.Object{
 }
 else{
 	if (include_btrfs_home_for_backup){
-		supported = supported && check_btrfs_volume(dev_root, "@,@home", unlock);
+		supported = supported && check_btrfs_volume(dev_root, "@rootfs,@home", unlock);
 	}
 	else{
-		supported = supported && check_btrfs_volume(dev_root, "@", unlock);
+		supported = supported && check_btrfs_volume(dev_root, "@rootfs", unlock);
 	}
 }
 			}
@@ -1452,7 +1452,7 @@ public class Main : GLib.Object{
 
 		log_msg(_("Creating new backup...") + "(BTRFS)");
 
-		log_msg(_("Saving to device") + ": %s".printf(repo.device.device) + ", " + _("mounted at path") + ": %s".printf(repo.mount_paths["@"]));
+		log_msg(_("Saving to device") + ": %s".printf(repo.device.device) + ", " + _("mounted at path") + ": %s".printf(repo.mount_paths["@rootfs"]));
 		if ((repo.device_home != null) && (repo.device_home.uuid != repo.device.uuid)){
 			log_msg(_("Saving to device") + ": %s".printf(repo.device_home.device) + ", " + _("mounted at path") + ": %s".printf(repo.mount_paths["@home"]));
 		}
@@ -1471,11 +1471,11 @@ public class Main : GLib.Object{
 		
 		// create subvolume snapshots
 
-		var subvol_names = new string[] { "@" };
+		var subvol_names = new string[] { "@rootfs" };
 		
 		if (include_btrfs_home_for_backup){
 			
-			subvol_names = new string[] { "@","@home" };
+			subvol_names = new string[] { "@rootfs","@home" };
 		}
 		
 		foreach(var subvol_name in subvol_names){
@@ -1489,8 +1489,8 @@ public

Bug#1014899: root subvolume should be @rootfs for Debian

[Osamu Aoki]

Source: timeshift
Version: 22.06.1-0.1
Severity: normal

I realize the current released d-i (bullseye) can install system to
btrfs.  The released d-i uses @rootfs subvolume and recent grub can cope
with this arrangement on Debian.

This is nice but this arrangement is different from Ubuntu which uses @
subvolume.

It will be nice to patch timeshift source to use @rootfs instead of @ on
Debian.

Osamu

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.

[Osamu Aoki]

Hi,

I had similar experience of loosing Japanese input upon system updates.

This happened only after system updates without rebooting.

I never investigated the packages involved in this problem.

Rebooing the system always fixed this problem for me based on my vague memory.

I don't recall this happened before moving to Wayland.

As you know, recent Debian system restarts some processes run under systemd upon
system updates. Maybe some ibus or ibus-anthy or even xwayland related process 
may
need to be included in the set of programs to be restarted to avoid rebooting 
the
system.  This is my speculation of this situation.

If this is related to restarting xwayland startup scripts, Ubuntu bug mentioned 
by
Gunnar may be related.

Regards,

Osamu

> -Original Message-
> From: Yukiharu YABUKI 
> Reply-To: Yukiharu YABUKI , 1014...@bugs.debian.org
> To: Debian Bug Tracking System 
> Subject: Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change
> japanese to anthy with kanji key.
> Date: Wed, 29 Jun 2022 22:42:13 +0900
> 
> Package: ibus
> Version: 1.5.26-4
> Severity: normal
> X-Debbugs-Cc: yyab...@debian.org
> 
> Dear Maintainer,
> 
> In unstable, after reboot, I hit kanji key, but ibus does not changed
> japanse to anthy. Stable release version changed japanse to anthy.
> 
> So, I tried to fix. I do `ibus-daemon -xrd`. Then kanji key can
> change japanse to anthy.
> 
> I set up same way between stable and unstable.
> 
> 
> 

Bug#1012041: Patch: debian/control

[Osamu Aoki]

Hi

> And the patch needs to be actually tested.

Very true.  Excuse me.

I think what you suggests is the way to go.

Thanks

Osamu

Bug#1012041: Patch: debian/control

[Osamu Aoki]

Control: tags + patch -1

thanks

From 980e431896d4442142bf480b14abd0049208861f Mon Sep 17 00:00:00 2001
From: Osamu Aoki 
Date: Tue, 31 May 2022 14:28:00 +0900
Subject: [PATCH] Ensure update upon xkb-data update

Signed-off-by: Osamu Aoki 
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 1bd81cc..1af1fc6 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Vcs-Git: https://salsa.debian.org/installer-team/console-setup.git
 Package: keyboard-configuration
 Architecture: all
 Multi-Arch: foreign
-Depends: ${misc:Depends}, liblocale-gettext-perl
+Depends: ${misc:Depends}, liblocale-gettext-perl, xkb-data (= ${source:Version})
 Pre-Depends: debconf (>= 1.5.34)
 Breaks: console-setup (<< 1.71), console-setup-mini (<< 1.47)
 Replaces: console-setup (<< 1.47), console-setup-mini (<< 1.47)
-- 
2.35.1

Bug#1012087: Typo in package description (and it is too terse)

[Osamu Aoki]

Source: lesana
Version: 0.9.1-3
Severity: minor

I see typo in package description: s/inventaries/inventories/

I also think this description is too terse.  Please think about updating
it by copying description from https://pypi.org/project/lesana/ .

---
Description: manage collections of various kinds through yaml files
 lesana is a python3 library to organize collections of various kinds. It
 is designed to have a data storage / serialization format that is
 friendly to git and other VCSs, but decent performances.
 .
 To reach this aim it uses yaml as its serialization format, which is
 easy to store in a VCS, share between people and syncronize between
 different computers, but it also keeps an index of this data in a local
 xapian database in order to allow for fast searches.
 .
 lesana supports collections of any kind, as long as their entries can be
 described with a mostly flat dictionary of fields of the types described
 in the documentation file field_types.
 .
 Some example collection schemas are provided, but one big strenght of
 lesana is the ability to customize your collection with custom fields by
 simply writing a personalized settings.yaml.
---

("but decent performances" may be grammatically odd.  Something like
"with decent performances" sounds better for me but it isn't essential.)

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

Kernel: Linux 5.17.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

Bug#1012041: KeyboardNames.pl is out-of-sync with xkeyboard-config

[Osamu Aoki]

Source: console-setup
Version: 1.205
Severity: normal

Problem symptom:
I was looking at "dpkg-reconfigure keyboard-configuration" under
Japanese locale and testing.  Although Generic 101 and 104 keyboards are
translated properly, Generic 102 and 105 keyboards were not translated
properly.

Resolution proposal:
Please place some kind of version skew avoidance measure by specifying
xkb-data as binary dependence with exact version value for
keyboard-configuration.  This dependency is because of gettext/po data
used.

Technical analysis:
As I looked into problem, kbdnames-maker + KeyboardNames.pl was using po
from xkeyboard-config:

  my $mo ()

As I checked xkeyboard-config.po, its string obtained for msgid for 102
and 105 keyboards has been changed.  If we want to fix this issue,
KeyboardNames.pl needs to be updated at least:

```
$ diff -u KeyboardNames.pl.orig KeyboardNames.pl
--- KeyboardNames.pl.orig   2022-05-29 14:36:14.940304836 +0900
+++ KeyboardNames.pl2022-05-29 15:02:29.524014093 +0900
@@ -71,10 +71,10 @@
 'FL90' => 'compalfl90',
 'Fujitsu-Siemens Amilo laptop' => 'fscaa1667g',
 'Generic 101-key PC' => 'pc101',
-'Generic 102-key PC' => 'pc102',
+'Generic 102-key (Intl) PC' => 'pc102',
 'Generic 104-key PC' => 'pc104',
 'Generic 104-key PC with L-shaped Enter key' => 'pc104alt',
-'Generic 105-key PC' => 'pc105',
+'Generic 105-key (Intl) PC' => 'pc105',
 'Generic 86-key PC' => 'pc86',
 'Genius Comfy KB-12e' => 'geniuscomfy',
 'Genius Comfy KB-16M/Multimedia KWD-910' => 'genius',
```

But this KeyboardNames.pl is a generated file so simple patch is not the
answer.  This file is generated by console-setup/Keyboard/Makefile .

Testing had old console-setup from Nov./2021 while xkb-data was updated
in April (testing migration on 2022-04-10)

Of course, console-setup 1.208 (uploaded to unstable on 2022-05-26)
solve the issue when it reaches testing in a few days this time. (But
this was broken for about a month unnoticed.)

It would be nice if we can avoid this version skew to happen in testing
by adding binary package dependency for PO file.

Regards,

Osamu


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

Kernel: Linux 5.17.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 keyboard-configuration depends on:
ii  debconf 1.5.79
ii  liblocale-gettext-perl  1.07-4+b2

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.63
ii  kbd 2.3.0-3
ii  keyboard-configuration  1.207

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
pn  console-common
pn  console-data  
pn  console-tools 
ii  gnome-control-center  1:42.1-2
ii  kbd   2.3.0-3
ii  systemd   250.4-1

Bug#685746: use of Recommends by library

[Osamu Aoki]

Hi,

For recommends, since TC is voted for "We advise the policy maintainers to 
consider
how to clarify ...", here is a reference information for drafting such 
clarification
clause. 

Whereas the original concern of this bug was the use of recommends by 
metapackage,
the underlining issue is broad and unrestricted definition of use of 
recommends, I
think.

>   The Recommends field should list packages that would be found together
>   with this one in all but unusual installations.

The word "together" has no sense of dependency direction.

Related problem is library recommending particular binary as discussed recently 
in
debian-devel:

 Subject: Re: use of Recommends by vlc to force users to use pipewire
 From: Jonas Smedegaard 
 To: debian-de...@lists.debian.org
 Date: Thu, 26 May 2022 17:59:38 +0200 (05/27/2022 12:59:38 AM)
 Message-Id: <165358077835.2132435.4699236542149578...@auryn.jones.dk>

Here Jonas has a interesting view point of "direction".  Let me quote:

> Package relations are directional: Applications need libraries, but
> libraries rarely need applications.
> 
> libpipewire-0.3-0 should not recommend pipewire, because the library
> cannot know if reverse dependencies needs it strongly or weakly.

I know suggest/enhance definition has view point on direction.  I don't see it 
in
recommends.  

In the related posts, issue of recommending xdg-desktop-portal end up pulling in
WebKitGTK is discussed.  This aspect is something to be accounted.

The use of ored recommends in that discussion threads by Vincent is also needs
attention.

> AFAIK, this kind of issue is normally solved with on ORed Recommends
> (when a virtual package is not defined for that). For instance,
> libaspell15 has
> 
>   Recommends: aspell-en | aspell-dictionary | aspell6a-dictionary
> 
> So, if the user already chose a solution, it won't be overridden
> by the default.
> 
> Here, this could be
> 
>   Recommends: pipewire | pulseaudio
> 
> but IMHO, it is not up to libraries to do such Recommends, but
> to audio applications or desktop environments, or something
> done automatically at installation time where the user chooses
> which kind of installation he wants? But isn't a sound system
> already installed by default with a typical installation of a
> desktop machine?

I think another direction question is data package to utility tool, and 
documentation
package to its utility.

Also considering normal use cases, circular dependency created by 
depends+recommends
combination needs to be addressed to avoid situation like:
  https://bugs.debian.org/655483

Technical solution by aptitude is one thing but having sane policy to avoid 
creating
such cases as much as possible is desirable thing.  Having some thing of 
"direction"
in recommends usage definition may help.

Just a thought.

Regards,

Osamu

PS: BCCed people quoted.

Bug#1011749: ITP: interception-tools -- minimal composable infrastructure on top of libudev and libevdev

[Osamu Aoki]

Package: wnpp
Severity: wishlist
Owner: Osamu Aoki 
X-Debbugs-Cc: debian-de...@lists.debian.org, Ethan Djeric 
, Francisco Lopes 

* Package name: interception-tools
  Version : 0.6.8
  Upstream Author : Francisco Lopes 
* URL : https://gitlab.com/interception/linux/tools
* License : GPLv3
  Programming Lang: C, C++
  Description : minimal composable infrastructure on top of libudev and 
libevdev

The Interception Tools is a small set of utilities for operating on input
events of evdev devices, including udevmon, intercept, uninput and mux.

In short, this is a generic helper tool to mangle keyboard input in very
low level within Linux kernel.  This works for Wayland, X, or Linux
virtual console.  Home position mod-tap etc. can be implemented using
this.

Longer explanation goes:

The tools here relying on libevdev are intercept and uinput.
intercept's purpose is to capture input from a given device (optionally
grabbing it) and write such raw input to stdout. uinput does the reverse,
it receives raw input from stdin and write it to a virtual uinput device
created by cloning characteristics of real devices, from YAML configuration, or
both.

So, assuming $DEVNODE as the path of the device, something like
/dev/input/by-id/some-kbd-id, the following results in a no-op:
intercept -g $DEVNODE | uinput -d $DEVNODE
In this case using -g is important so that the target device is grabbed for
exclusive access, allowing the new virtual device created by uinput to
substitute it completely: we grab it and others can grab the clone.
Now additional processing can be added in the middle easily.

There were Ubuntu PPA by Ethan Djeric .  I used it
as the starting point.  I have tidied up packaging so it can pass
piuparts and lintian test.  I also created manpages.

At this moment, I have this on github and in good shape.  Once accepted,
I will move this to salsa.

   https://github.com/osamuaoki/interception-tools

This offer 4 commands and one of it is "intercept". Debian already have
"intercept" in the "bear" package.

As you know generic name and short name are problematic.

I am wondering if I need to rename as:

  intercept -> evdev-intercept
  udevmon   -> evdev-udevmon
  uinput-> evdev-uinput
  mux   -> evdev-mux

(I am asking thought of upstream too.)

Here are associated programs to give idea what we can.

Additional Tools
 uswitch: redirect stdin to a muxer if logged user matches
 xswitch: redirect stdin to a muxer if window matches
Official Plugins
  caps2esc:   transforming the most useless key ever in the most useful one
  space2meta: turn your space key into the meta key when chorded to
  another key (on key release only)
  hideaway: move the mouse pointer out of sight after a couple of seconds
  dual-function-keys: tap for one key, hold for another
Some Community Plugins
  ralt2hyper: Remap Right Alt (commonly AltGr) to Hyper (i.e. Control, Alt and 
Super)
  chorded_keymap
  interception-vimproved
  interception-k2k

Also, if Ubuntu PPA person wishes to co-maintain, I will be happy to
sponsor.

Regards,

Osamu

Bug#988540: im-config: breaks the keyboard configuration

[Osamu Aoki]

Hi,

Maybe I used too strong word to describe XIM + ibus combination situation.
But I still feel unsafe to do so.

Please note I am not saying use of xterm under pure X environment (without 
ibus) with
xmodmap to be unsafe nor buggy.  That's fine good old system.

> -Original Message-
> From: Vincent Lefevre 
...
> I normally use the lightdm display manager to start X (or in case of
> breakage, I start X from a Linux virtual console with "startx"). This
> has the effect to run my .xsession script. After some settings, it
> starts my window manager FVWM2 (actually a wrapper to handle ssh-agent),
> from which applications are run. FVWM2 is just a window manager, not a
> desktop environment.

> A classic X server. I also often use remote X applications (for
> which there are no issues with my XKB settings, but I don't know
> about ibus / im-config, in particular if it relies on environment
> variables that are not passed via SSH).

I see.  You are in good old X environment.
ibus runs on your computer running ssh client.  So it works.

> > > [...] However, "im-config -n none" may be sufficient.
> .> 
> >..
>  This is explained in GUI dialog (if you used GUI) by /usr/share/im-
> > config/data/78_none.conf.
> 
> IIRC, when I tried it, I didn't use the GUI.

OK.  But that is what happens.  Hmmm manpage needs to be updated to explain 
"none".

> > > > I don't know what do you mean by code point.
> 
...
> > 
> >   https://bugzilla.redhat.com/show_bug.cgi?id=2013610
> 
> If you mean this bug, the user is trying to do things that are not
> possible with XKB. So I'm not surprised that there may be issues
> in such a case.

True.  This recent bug may not affect such simple input.  (Korean phonetic 
input had
issue previously but we applied workaround: IBUS_ENABLE_SYNC_MODE=0)

Anyway, its not safe playing with data path which has been hit by many bugs. I 
have
no interest in compiling list of previous bugs but I have bad memory around 
this data
path.  

Let's look at practical aspect.

You want to run pure X Window based system without input method framework 
(ibus) but
use xmodmap to take care character table and XIM to send keyboard generated 
data to
your application.  We now have answer for your needs.

1.  Keep away from GNOME since it forces you to install and activate ibus.
2.  Don't install ibus nor fcitx5.
3.  If ibus is installed for any reason, disable it with "im-config -n none".

Regards,

Osamu