Bug#1084778: (reminder) hackish workaround needs to be removed
Source: debmake-doc Version: 1.20-1 Severity: wishlist Due to the asciidoctor bug: * https://github.com/asciidoctor/asciidoctor/issues/4628 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084777 I have hackish asciidoc/superscript.sh file in this source trr. This should be removed once this bug is fixed in the upstream. Osamu -- System Information: Debian Release: 12.7 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#1084777: broken conversion of emphasis + superscript to docbook xml
Source: asciidoctor Version: 2.0.23-1 Severity: normal Tags: upstream As reported to the upstream: https://github.com/asciidoctor/asciidoctor/issues/4628 I found this problem when using asciidoctor for `debamake-doc` package. In this sense, I really used current sid environment (2.0.31-1) too. == From my upstream bug report == I used asciidoctor (2 versions are tested: docker image=2.0.23 and Debian/stable=2.0.18) for test and I encounter the following broken output for DocBook while HTML doesn't suffer this problem. See below for test sample data, buggy result, and Makefile to reproduce bug. Input file (test.asc): ``` // vim:set filetype=asciidoc: = TEST * B^SUPER^E * B**^SUPER^**E * B^*SUPER*^E * B^**SUPER**^E ``` DocBook conversion result below (the first 2 itemized lines are good, the last 2 itemized lines are bad): ``` http://docbook.org/ns/docbook"; xmlns:xl="http://www.w3.org/1999/xlink"; version="5.0" xml:lang="en"> TEST 2024-10-01 BSUPERE BSUPERE B^SUPER^E B^SUPER^E ``` You see non-converted-`^`s. HTML page doesn't have this problem. FYI: My `Makefile` : ``` ASCIIDOC := podman run -it -v .:/documents/ \ docker.io/asciidoctor/docker-asciidoctor asciidoctor DOCNAME := test all: test.html test.xml clean: rm -rf *.xml *.html %.xml: %.asc $(ASCIIDOC) --doctype book\ -b docbook \ -a 'newline=\n' \ $< %.html: %.asc $(ASCIIDOC) --doctype book\ -b html \ -a toc2 \ -a 'newline=\n' \ $< ``` -- System Information: Debian Release: 12.7 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#1053928: debmake-doc: [INTL:pt]
Hi, Thanks for the updated PO. It was updated to new asciidoctor compatible markup and merged. While doing so, I realized PO had several broken markups. Since they were trivial to fix, I fixed them all. Please note I made a major content update. So please update pt-po when you find time. XML markup errors can be easily found just by building HTML file. ``` $ make LANGPO=pt html css ``` Error lines are line number of generated debmake-doc.pt.xml,. If PO file line folding cause difficulties for processing (string search), you can run: ``` $ make LANGPO=pt nowrap ``` This makes msgid/msgstr line in single line. ``` $ make LANGPO=pt wrap ``` ... Good luck. Osamu
Bug#1078563: git-debrebase(1): mention to use --force for the start of Debian packaging
Package: git-debrebase Version: 10.7+deb12u2 Severity: wishlist FYI: I checked salsa for the latest git-debrebase.1.pod, too. I was trying to start experiment dgit-maint-debrebase(7) while reading: * git-debrebase(1) * git-debrebase(5) I may be wrong but after several trials, it seems --force option is needed for the initial usage of this command for the simple fresh git repository case. ``` $ git debrebase new-upstream 2.0 git-debrebase: snag detected (-fanchor-treated): old anchor is recognized due to --anchor, cannot check upstream git-debrebase: error: git-debrebase: snags: 1 blocker(s) (you could -f, or --force) $ git debrebase --force new-upstream 2.0 git-debrebase: snag detected (-fanchor-treated): old anchor is recognized due to --anchor, cannot check upstream git-debrebase: snags: 1 overriden by global --force git-debrebase: laundered (head was 76d14a8c58abc7dbcac014e4a6a1800bf238b28d) Recorded previous head for preservation Successfully rebased and updated refs/heads/main. ``` In git-debrebase(1), it only says: ``` --force Turns all snags into warnings. See the -f option. Do not invoke git-debrebase --force in scripts and aliases; instead, specify the particular -f for expected snags. ``` No explicit statement when typically this is needed. In git-debrebase(5), it only says: ``` Anchor An anchor commit, which is usually a special two-parent merge: (snip) Alternatively, an anchor may be a single-parent commit which introduces the "debian/" directory and makes no other changes: ie, the start of Debian packaging. ``` The combination of these may mean: * Initial packaging branch after packaging 1.0 has an anchor with a single-parent commit * it is not *usual* case and requires --force. If this is the case, please explicitly mention this in git-debrebase(1). Just FYI: # 1 Diagram in git-debrebase(5) is missing single-parent commit anchor case. # 2 As for the following 3 documents are a bit overwhelming with too many corner cases: * dgit-maint-debrebase(7) * git-debrebase(1) * git-debrebase(5) I think it will be nice to have "GET STARTED just using local git repository from scratch" for simple packaging case which used to be handled by gbp is good start. No "dgit push/pull". Something along ... ``` $ git init;git add .;git commit -m "1.0" ... hack $ dgit build-source # for 1.0 ... $ git checkout upstream ... hack $ git commit -a -m "2.0" $ git debrebase --force new-upstream 2.0 ... ``` Once user can experiment locally, it becomes much easier to understand all the complexities. -- 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 Versions of packages git-debrebase depends on: ii devscripts 2.23.4+deb12u1 ii git [git-core] 1:2.39.2-1.1 ii libdpkg-perl1.21.22 ii libfile-fnmatch-perl0.02-3+b1 ii liblocale-gettext-perl 1.07-5 ii perl5.36.0-7+deb12u1 Versions of packages git-debrebase recommends: ii dgit 10.7+deb12u2 ii git-buildpackage 0.9.30 git-debrebase suggests no packages. -- no debconf information
Bug#1061145: debmake: use python3 command for Python 3 packages instead of python command
control: tags -1 unreproducible
thanks
I can't reproduce the issue reported.
I used debmake package source as the test bed. Changing setup.py to use
#!/usr/bin/python.
osamu@goofy:~/salsa/debmake/debmake-014/test-space/debmake-4.4.0 (=test)
13:30:32 ↵
$ alias python
bash: alias: python: not found
osamu@goofy:~/salsa/debmake/debmake-014/test-space/debmake-4.4.0 (=test)
13:30:43 ↵
$ type python
bash: type: python: not found
osamu@goofy:~/salsa/debmake/debmake-014/test-space/debmake-4.4.0 (=test)
13:31:02 ↵
$ head -n1 setup.py
# /usr/bin/python
osamu@goofy:~/salsa/debmake/debmake-014/test-space/debmake-4.4.0 (=test)
13:31:35 ↵
$ debmake
I: set parameters
I: =
I: package_dir = /usr/lib/python3/dist-packages
I: base_path = /usr
I: base_lib_path = /usr/lib/debmake
I: base_share_path = /usr/share/debmake
I: =
I: sanity check of parameters
I: pkg="debmake", ver="4.4.0", rev="1"
I: *** start packaging in "debmake-4.4.0". ***
I: provide debmake_4.4.0.orig.tar.gz for non-native Debian package
I: pwd = "/home/osamu/salsa/debmake/debmake-014/test-space"
I: Use existing "debmake_4.4.0.orig.tar.gz" as upstream tarball
I: pwd = "/home/osamu/salsa/debmake/debmake-014/test-space/debmake-4.4.0"
I: parse binary package settings:
I: binary package=debmake Type=bin / Arch=any M-A=foreign
I: analyze the source tree
W: neither distutils nor setuptools. check setup.py.
I: build_type = Python distutils
I: scan source for copyright+license text and file extensions
...snip
.
I: check_all_licenses completed for 404 files.
I: bunch_all_licenses
I: format_all_licenses
W: many ext = "python" type extension programs without matching -b set.
?: -b":python, ..." or -b":python3" missing. Continue? [Y/n]: Y
I: pwd = "/home/osamu/salsa/debmake/debmake-014/test-space/debmake-4.4.0"
I: make debian/* template files
I: single binary package
I: debmake -x "1" ...
I: creating => debian/control
I: creating => debian/copyright
I: substituting => /usr/share/debmake/extra0/changelog
I: creating => debian/changelog
I: substituting => /usr/share/debmake/extra0/rules
I: creating => debian/rules
I: substituting => /usr/share/debmake/extra1/README.Debian
I: creating => debian/README.Debian
I: substituting => /usr/share/debmake/extra1/watch
I: creating => debian/watch
I: substituting => /usr/share/debmake/extra1source/format
I: creating => debian/source/format
I: substituting => /usr/share/debmake/extra1tests/control
I: creating => debian/source/control
I: substituting => /usr/share/debmake/extra1upstream/metadata
I: creating => debian/upstream/metadata
I: substituting => /usr/share/debmake/extra1tests/control
I: creating => debian/tests/control
I: substituting => /usr/share/debmake/extra1patches/series
I: creating => debian/patches/series
I: substituting => /usr/share/debmake/extra1sourcex/local-options
I: creating => debian/source/local-options
I: substituting => /usr/share/debmake/extra1sourcex/options
I: creating => debian/source/options
I: substituting => /usr/share/debmake/extra1sourcex/patch-header
I: creating => debian/source/patch-header
I: run "debmake -x2" to get more template files
I: $ wrap-and-sort
So far, no problem (so the core part of debmake works.)
But you may be running debuild afterward or via -i.
$ debuild
dpkg-buildpackage -us -uc -ui -i
dpkg-buildpackage: info: source package debmake
dpkg-buildpackage: info: source version 4.4.0-1
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Osamu Aoki
dpkg-source -i --before-build .
dpkg-buildpackage: info: host architecture amd64
dpkg-checkbuilddeps: error: Unmet build dependencies: python-all
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i failed
This is not nice.
$ rg python-all
debmake/analyze.py
208:para["build_depends"].update({"python-all"})
381:para["build_depends"].update({"python-all"})
529:para["build_depends"].update({"python-all"})
We should fix this to use python3-all.
Since I am not sure what exactly was your issue. I am tagging this
unreproducible. Please post log like above.
FYI: I am in process of updating debmake. The upcoming version even assign
python3 for all python script so the reported issue should not occur no matter
what was the root cause, I hope.
Bug#1075842: maint-guide: Please update 5.2 to state that debian/compat has been replaced in modern debhelper versions
control: reassign -1 debmake-doc thanks Yah, this is about time to start using new scheme for version dependency. But as written at the top of each web page of maint-guide: https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#control The rewrite of this tutorial document with updated contents and more practical examples is available as "Guide for Debian Maintainers". Please use this new tutorial as the primary tutorial document. So let me update "Guide for Debian Maintainers (debmake-doc)" instead: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#control FYI: HISTORICAL BACKGROUND / FUTURE ACTION PLANS maint-guide was updated by me to address debhelper 9. It was a bit awkward update since I intentionally made this as the minimum change revision just to address debian/rules to use dh syntax. It didn't address library nor add more realistic examples. These became keen issue for addressing M-A. That lead me to rewrite this maint-guide from scratch with ample examples as debmake-doc. Back then dh_make was not adressing new dh9 syntax and it was written in perl. So I made debmake as an alternative. (The current dh_make has been updated and uses python.) I have to admit, I am getting behind on updating packages I offer with newer situation. TODO: * Update debmake-doc to address debhelper 12 in its example * Update debmake to address debhelper 12 in its template * Update debmake to address salsa CI in its template * Update debmake python code structure to use pyproject.toml for itself * no more setup.py * Update debmake code to work with python code using pyproject.toml Once these are done, I think it is time to ask FTP master to remove maint-guide. As I checked debhelper-compat-upgrade-checklist(7), I may need to update more on following concerns: * use of dpkg-maintscript-helper to remove/rename conffiles (available from dpkg 1.15) * /usr/libexec (per FHS 3.0, adopted in Debian Policy 4.1.5). * init-system-helpers (>= 1.54~) * DEB_BUILD_OPTIONS (notest etc.) * conffiles (oops, it seems 12+ needs this) -- need careful * pointer to https://www.debian.org/doc/debian-policy/ap-flowcharts.html Regards, Osamu On Sat, 2024-07-06 at 09:42 +0200, Niels Thykier wrote: > Package: maint-guide > Severity: minor > X-Debbugs-Cc: ni...@thykier.net > > Hi > > I think as of debhelper/12, the recommended way of setting the debhelper > compat level is via the `Build-Depends: debhelper-compat (= X)` in > `debian/control`. With compat level 14 and beyond, debhelper will no > longer use that file at all (replacing it instead with a `X-DH-Compat: > X` field in `debian/control`). > > Therefore, I think section 5.2 should be updated to say that this was a > historical way to define the debhelper compat level and that you may see > them in older packaging. However, it should not be used in newer packages. > > Best regards, > Niels
Bug#1057080: ibus-mozc: Automatically enables itself on non-Japanese systems
Hi, I have a second thought after good night sleep What Yao Wei (魏銘廷) suggested may be in good direction but I want it to be done with **one twist**. Action 1: add /etc/default/ibus-mozc with its default content ``` # Change "ja_JP" in the following to "ALWAYS" if you wish mozc to be set-up # under non-Ja_JP environment too. START_IBUS_MOZC=ja_JP ``` Action2: Modify /usr/share/ibus-mozc/ibus-mozc-gnome-initial-setup.sh started by /etc/xdg/autostart/ibus-mozc-gnome-initial-setup.desktop as: * Start this set-up script: * if START_IBUS_MOZC is not "ja_JP" in /etc/default/ibus-mozc or * if LOCALE is "ja_JP" Action 3: Add README.Debian explaining situation This way, people like me using mozc under en_US have way to work around the change proposed by Yao Wei. osamu FYI: I still think creating non-DE dependent ibus setup program is a good idea. Current hackish dconf tweak is rather fragile.
Bug#1057080: ibus-mozc: Automatically enables itself on non-Japanese systems
Hi, I am not the maintainer of this package but came to this bug after hearing it on a Debian JP workshop session. I think what should happen is the following: For now, Endless OS should create its customization package which used dpkg- divert to disable ibus-mozc's autostart script and provides its own per-user input method setting script (or use gnome-initial-setup?). After all, the act of installing all the language support packages is a non-typical use case. Here is my rationale and comment for the future direction.: Fundamental problem is that Debian Package installation script can configure system wide settings via post-inst script but not each user's personal settings. Since ibus input method activation is performed per-user basis, we need some mechanism to make 99% of use case as smooth as possible like what is done. Under normal use case, whoever install ibus-mozc expects it to work upon first login to the system. I do understand what ibus-mozc is doing may not be the best technical solution but is a reasonable **DE independent solution**. If you can come up with a new **DE independent** per-user IM setting package and upload to Debian, we can stop using current mechanism. That will be great contribution to Debian from Endless OS. (FYI: I like your Gnome DE mod code which I use via extension.) Please remember Debian need to support many DEs. Best regards, Osamu
Bug#772204: dput: .orig.tar.gz for non -1 package for security-master
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)
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"
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"
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"
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
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
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 > > /var/lib/dpkg/in
Bug#1063649: maint-guide: synatx error in setup instructions for sbuild
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
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
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
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
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 --hint-bios=h
Bug#1055786: GID=1000 for netdev created by cloud-init violates Debian Policy
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Control tags -1 pending thanks curl need "-O" option to make it behave like wget.
Bug#969177: debmake: cannot create deb for nodejs modeule
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
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
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
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
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
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
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
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
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
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
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, ...
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
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)
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"
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
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
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
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?
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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-
Bug#1020821: po4a-gettextize sanity check too strict, please slow-down deprecation
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
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
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
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.
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
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 ..."
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
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*
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
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*
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
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
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
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
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.
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.
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.
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
> Control: tag -1 pending Thanks. I also think your fix is most reasonable choice. Osamu
Bug#1015785: source only update issue
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
Control: retitle -1 Update recommend and suggests for paste action thanks
Bug#1015786: rc
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
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
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
