Bug#947984: libvirt-daemon-driver-lxc: internal error: Unable to find 'devices' cgroups controller mount in cgroup2 / unified hierarchy
Control: tags -1 + fixed-upstream upstream I verified that libvirt 5.10 fixes this problem as [root@localhost ~]# lxc-create -n fedora31test -t download -- -d fedora -r 31 -a amd64 [root@localhost ~]# virt-install --memory 2048 --connect lxc:/ --os-variant fedora31 --filesystem /var/lib/lxc/fedora31test/rootfs,/ --network none --transient --import --name fedora31test worked just fine.
Bug#948102: libvirt-clients: seems to depend libvirt-daemon-system
Package: libvirt-clients Version: 5.6.0-3 Severity: grave Justification: renders package unusable Dear Maintainer, virsh is completely unusable without libvirt-daemon-system as root@debian:~# virsh uri error: failed to connect to the hypervisor error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt-clients depends on: ii libapparmor12.13.3-7 ii libc6 2.29-3 ii libgcc1 1:9.2.1-21 ii libreadline88.0-3 ii libselinux1 3.0-1 ii libvirt05.6.0-3 ii libxml2 2.9.4+dfsg1-8 ii sensible-utils 0.0.12+nmu1 libvirt-clients recommends no packages. Versions of packages libvirt-clients suggests: ii libvirt-daemon 5.6.0-3 -- no debconf information
Bug#948101: virtinst: seems to depend on libvirt-daemon-system
Package: virtinst Version: 1:2.2.1-3 Severity: grave Justification: renders package unusable Dear Maintainer, Without installing libvirt-daemon-system, virt-installer is completely unusable as root@debian:~# virt-install --install fedora29 --unattended ERRORFailed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages virtinst depends on: ii e2fsprogs 1.45.4-1 ii genisoimage 9:1.1.11-3+b2 ii gir1.2-libosinfo-1.0 1.6.0-1 ii python3 3.7.5-3 ii python3-distutils 3.8.0-1 ii python3-gi3.34.0-3 ii python3-libvirt 5.6.0-1 ii python3-libxml2 2.9.4+dfsg1-8 ii python3-requests 2.22.0-2 Versions of packages virtinst recommends: ii qemu-utils 1:4.1-3 ii virt-viewer 7.0-2 virtinst suggests no packages. -- no debconf information
Bug#947984: libvirt-daemon-driver-lxc: internal error: Unable to find 'devices' cgroups controller mount in cgroup2 / unified hierarchy
Package: libvirt-daemon-driver-lxc Version: 5.6.0-3 Severity: normal User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Control: block 943981 by -1 Dear Maintainer, libvirt-daemon-driver-lxc fails in cgroup2 / unified hierarchy (host Linux booted with systemd.unified_cgroup_hierarchy) with the following error message: root@debian:~# virt-install --connect lxc:/ --os-variant fedora30 --memory 2096 --filesystem /var/lib/lxc/chrome1/rootfs,/ --network network=default,model=virtio --graphics=vnc,listen=0.0.0.0 --video qxl --accelerate --cpuset 2 --cpu host-model --transient --import --name chrommee WARNING Graphics requested but DISPLAY is not set. Not running virt-viewer. WARNING No console to launch for the guest, defaulting to --wait -1 Starting install... ERRORinternal error: Unable to find 'devices' cgroups controller mount Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect lxc:/ start chrommee otherwise, please restart your installation. root@debian:~# virsh --connect lxc:/ start chrommee error: failed to get domain 'chrommee' Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt-daemon-driver-lxc depends on: ii libblkid1 2.34-0.1 ii libc6 2.29-3 ii libcap-ng0 0.7.9-2.1+b1 ii libfuse22.9.9-2 ii libgcc1 1:9.2.1-21 ii libvirt-daemon 5.6.0-3 ii libvirt05.6.0-3 ii libxml2 2.9.4+dfsg1-8 libvirt-daemon-driver-lxc recommends no packages. libvirt-daemon-driver-lxc suggests no packages. -- no debconf information
Bug#944389: lxc: Fails to work with cgroupv2 / unified hierarchy
Control: tags -1 + fixed I made a user instruction on how to use lxc on a Debian host booted with systemd.unified_cgroup_hierarchy=1 at https://wiki.debian.org/LXC/CGroupV2 I believe that this issue is now resolved, but I refrain from closing this, while I add "fixed" tag. Ryutaroh Matsumoto
Bug#946480: lxc: non-root user cannot start a container under cgroupv2 / unified hierarchy
Control: unblock 943981 by -1 Control: tags -1 - upstream Now I think this issue #946480 should be handled by updates to https://wiki.debian.org/LXC and/or README.Debian telling non-root users that they have to run lxc-start as systemd-run --user --scope -p "Delegate=yes" lxc-start -F -n ... There seems nothing required to change other than documents, though addition of more sensible error handling and error messages are helpful at the upstream. Ryutaroh
Bug#944389: lxc: Fails to work with cgroupv2 / unified hierarchy
Dear Michael and the Debian maintainers of LXC, I suggest to close this issue #944389. The reason is that Addition of lxc.cgroup.devices.allow = lxc.cgroup.devices.deny = lxc.init.cmd = /lib/systemd/systemd systemd.unified_cgroup_hierarchy=1 to a container config allows normal start-up of an LXC container when /sbin/init is a recent version of systemd, and only lxc.cgroup.devices.deny = lxc.cgroup.devices.allow = are sufficient when /sbin/init is not systemd, for the latest Debian LXC package 3.1.0+really3.0.4-2 made on August 2019 running on a Debian Bullseye booted with systemd.unified_cgroup_hierarchy=1 This #944389 seems a documentation issue that should be fixed at https://wiki.debian.org/LXC or README.Debian and does not seems an issue in the Debian package or the upstream (except possible update to README.Debian). Best regards, Ryutaroh Matsumoto
Bug#946791: io.weight cannot be enabled in recent Debian kernel package
Source: linux Followup-For: Bug #946791 Control: tags -1 + patch Dear Maintainer, I reported that IOWeight config item in systemd has no effect on recent Debian kernels. I found the root cause. io.weight was changed to io.bfq.weight, and recent systemd sets values of IOWeight to io.bfq.weight as https://github.com/systemd/systemd/commit/2dbc45aea747f25cc1c3848fded2ec0062f96bcf For io.bfq.weight to appear in cgroup v2 filesystem, the bfq kernel module must be loaded. Addition of "bfq" to /etc/initramfs-tools/modules solved this issue. Since the systemd needs bfq module to be loaded, changing CONFIG_IOSCHED_BFQ=m to CONFIG_IOSCHED_BFQ=y in kernel config seems suitable. If the Debian kernel team considers this issue to be handled by another package, e.g. initramfs-tools or systemd, please reassign this. If this issue is considered not being a bug, please close this. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#947335: lxc-checkpoint does not work under cgroupv2 / unified hierarchy
Package: lxc Version: 1:3.1.0+really3.0.4-2 Severity: normal Tags: upstream User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Control: forwarded -1 https://github.com/lxc/lxc/issues/3240 Dear Maintainer, Title says everything, and this is an upstream issue reported as https://github.com/lxc/lxc/issues/3240 Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.73 ii libc6 2.29-3 ii libgcc11:9.2.1-21 ii liblxc11:3.1.0+really3.0.4-2 ii lsb-base 11.1.0 Versions of packages lxc recommends: ii apparmor 2.13.3-7 ii bridge-utils 1.6-2 pn debootstrap ii dirmngr 2.2.17-3 ii dnsmasq-base [dnsmasq-base] 2.80-1+b1 ii gnupg2.2.17-3 ii iproute2 5.4.0-1 ii iptables 1.8.3-2 pn libpam-cgfs pn lxc-templates pn lxcfs ii openssl 1.1.1d-2 pn rsync ii uidmap 1:4.7-2 Versions of packages lxc suggests: ii btrfs-progs 5.4-1 ii lvm2 2.03.02-3 pn python3-lxc -- debconf information: lxc/auto_update_config:
Bug#947334: lxc-checkpoint needs the criu package
Package: lxc Version: 1:3.1.0+really3.0.4-2 Severity: normal Dear Maintainer, lxc-checkpoint command needs "criu", which is only available in Debian experimental now. But "criu" is neither suggested nor recommended. Some kind of dependency by lxc seems necessary. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.73 ii libc6 2.29-3 ii libgcc11:9.2.1-21 ii liblxc11:3.1.0+really3.0.4-2 ii lsb-base 11.1.0 Versions of packages lxc recommends: ii apparmor 2.13.3-7 ii bridge-utils 1.6-2 pn debootstrap ii dirmngr 2.2.17-3 ii dnsmasq-base [dnsmasq-base] 2.80-1+b1 ii gnupg2.2.17-3 ii iproute2 5.4.0-1 ii iptables 1.8.3-2 pn libpam-cgfs pn lxc-templates pn lxcfs ii openssl 1.1.1d-2 pn rsync ii uidmap 1:4.7-2 Versions of packages lxc suggests: ii btrfs-progs 5.4-1 ii lvm2 2.03.02-3 pn python3-lxc -- debconf information: lxc/auto_update_config:
Bug#947007: buildah bud causes errors with Dockerfile
Dear Dmitry, Thank you for your response. I also noticed the lack of /etc/container/storage.conf. Its absense did not cause any error, but storage.conf is mentioned at the bottom of the buildah man page as https://github.com/containers/buildah/blob/master/docs/buildah.md#files So inclusion of storage.conf at /usr/share/doc/buildah/examples or /etc/containers might be suitable. storage.conf(5) is mentioned in https://github.com/containers/buildah/blob/master/docs/buildah.md but I didn't find storage.conf(5) in the Debian package. Best regards, Ryutaroh From: Dmitry Smirnov Subject: Re: Bug#947007: buildah bud causes errors with Dockerfile Date: Thu, 19 Dec 2019 23:58:46 +1100 > Yes, thanks. Most of those issues are already fixed in the repository > and pending upload. > > > On Thursday, 19 December 2019 11:06:05 PM AEDT Ryutaroh Matsumoto wrote: >> The reason of buildah bud giving errors are three-fold: >> >> (1) Lack of /etc/containers/registries.conf >> I copied /usr/share/doc/buildah/examples/registries.conf in the >> buildah Debian package. > > That's how it is expected to be used. > > Not everybody need Docker registries and having them by default > may not be a good idea... > > Also this configuration file is shared with Podman which adds > to complexity... > > >> (2) Lack of /etc/containers/policy.json >> I copied policy.json from the golang-github-containers-image-dev >> Debian package. > > https://salsa.debian.org/go-team/packages/golang-github-containers-buildah/commit/911ac680 > > >> (3) Lack of runc or crun >> I manually installed crun and executed buildah --runtime /usr/bin/cron >> The runc or crun package should be suggested/recommended by the >> buildah Debian package. > > https://salsa.debian.org/go-team/packages/golang-github-containers-buildah/commit/9b802644 > > Certainly fixes for 2 and 3 will be uploaded soon. > Not sure about 1 as I'm still thinking about how to resolve it elegantly > and what would be reasonable default. > > -- > Cheers, > Dmitry Smirnov. > > --- > > Freedom is the freedom to say that two plus two make four. If that is > granted, all else follows. > -- George Orwell
Bug#947007: buildah bud causes errors with Dockerfile
Package: buildah Version: 1.10.1-5 Severity: normal Dear Maintainer, buildah bud does not work on a Dockerfile starting with FROM alpine:3.10 I tried to create an image by https://github.com/y-yu/new-year-letter/blob/master/docker/Dockerfile The reason of buildah bud giving errors are three-fold: (1) Lack of /etc/containers/registries.conf I copied /usr/share/doc/buildah/examples/registries.conf in the buildah Debian package. (2) Lack of /etc/containers/policy.json I copied policy.json from the golang-github-containers-image-dev Debian package. (3) Lack of runc or crun I manually installed crun and executed buildah --runtime /usr/bin/cron The runc or crun package should be suggested/recommended by the buildah Debian package. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages buildah depends on: ii libc6 2.29-3 ii libdevmapper1.02.1 2:1.02.155-3 ii libglib2.0-02.62.3-2 ii libgpgme11 1.13.1-1 ii libostree-1-1 2019.6-1 ii libseccomp2 2.4.2-2 ii libselinux1 3.0-1 ii uidmap 1:4.7-2 Versions of packages buildah recommends: ii fuse-overlayfs 0.7.2-1 buildah suggests no packages. -- no debconf information
Bug#943981: docker.io: Won't start under cgroupsv2
Dear Docker Maintainers and Systemd Maintainers for Debian, Podman and podman-compose seem to work with no problem on Debian Bullseye booted with systemd.unified_cgroup_hierarchy=1, at least when podman is run by root. Installation procedure is as below. So, after podman and podman-compose are included in the standard Debian packages, and update-alternative can switch the standard docker and the podman, we can unblock 943981 by 840829. 1. apt-get -t disco install buildah podman skopeo slirp4netns containernetworking-plugins from deb http://ppa.launchpad.net/projectatomic/ppa/ubuntu disco main 2. apt-get -t bullseye install crun 3. Change runtime = "runc" to runtime = "crun" in /usr/share/containers/libpod.conf 4. Copy https://github.com/projectatomic/registries/blob/master/registries.fedora to /etc/containers/registries.conf Then podman works fine in place of docker as far as I see. podman-compose, a substitute of docker-compose, can be installed as pip3 install -U podman-compose. Best regards, Ryutaroh Matsumoto
Bug#946791: io.weight cannot be enabled in recent Debian kernel package
Control: reassign -1 linux 5.3.15-1 Control: retitle -1 io.weight cannot be enabled in recent Debian kernel package Dear Debian Kernel Team, This report 946791 was originally reported to systemd package, as IOWeight systemd config item does not create "io.weight" under /sys/fs/cgroup, when the boot option systemd.unified_cgroup_hierarchy=1 is given. But I confirmed that this bug happes with linux-image-5.3.0-3-amd645.3.15-1 and does NOT happen with linux-image-4.19.0-6-amd644.19.67-2+deb10u1 where systemd package version is 244-3. So I would like to reassign this to Linux package. Best regards, Ryutaroh Matsumoto
Bug#944389: lxc support status of cgroupv2 / unified hierarchy
Control: tags -1 + fixed-upstream upstream Dear LXC maintainers and Systemd maintainers, I added fixed-upstream to #944389, and it seems that blocking of #943981 by LXC can be lifted after some work. If LXC is the only reason for systemd package to revert to hybrid hierarchy, it can probably return to the unified default. The below is justification/explanation. I did 1. "apt-get source lxc" on Ubuntu Eoan (sorry not Debian Bullseye), 2. overwirtten the source by the * stable-3.0 * branch of lxc github, 3. and rebuilt it by "debuild -b -uc -us". The built package worked as expected with no problem under cgroupv2 / unified hierarchy, on Ubuntu Eoan. Some adjustment to the config file was necessary as below: ERRORcgfsng - cgroups/cgfsng.c:cg_legacy_set_data:2415 - Failed to setup limits for the "devices" controller. The controller seems to be unused by "cgfsng" cgroup driver or not enabled on the cgroup hierarchy ERRORstart - start.c:lxc_spawn:1910 - Failed to setup legacy device cgroup controller limits The above error is caused by failed attempt to use Cgroup V1 device controller, to fix it we need: lxc.cgroup.devices.allow = lxc.cgroup.devices.deny = The newer systemd refuses to start in the LXC container by the error message: Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems. Exiting PID 1... The reason of this error is lack of /sys/fs/cgroup in the container. To fix this, we need lxc.mount.auto = cgroup:rw:force In another bug report #946480 I reported that a non-root user cannot start an LXC container. The reason of the failure is lack a manipulable CGroup directory by a non-root user. To fix this issue, a non-root user has to start a container by systemd-run --user --scope -p "Delegate=yes" lxc-start -F ... (foreground) or systemd-run --user -r -p "Delegate=yes" lxc-start -F ... (backgroud) so that non-root lxc-start has a manipulable cgroup directory. The essential problem in #946480 is that there is no user instruction of how to start an LXC container by non-root, and #946480 is a purely documentation issue. Maybe updating https://wiki.debian.org/LXC is enough. Conventionally, libpam-cgfs chowned non-root user's session scope so that a non-root LXC container can manipulate it. But merely chowning the session scope is insufficient to make cgroup.subtree_control writable by non-root users under cgroupv2 / unified hierarchy. So libpam-cgfs has become useless in cgroupv2 / unified hierarchy, which was #946170 Best regards, Ryutaroh Matsumoto
Bug#946715: texlive-lang-japanese: should recommend/suggest texlive-latex-recommended
Package: texlive-lang-japanese
Version: 2019.20191208-1
Severity: normal
Dear Maintainer,
Many files in texlive-lang-japanese need files in texlive-latex-recommended.
E.g., compiling the following file
\documentclass{ltjarticle}
\begin{document}
test.
\end{document}
gives the following error without texlive-latex-recommended.
It may be a good idea for texlive-lang-japanese to recommend/suggest
to texlive-latex-recommended. In my view, texlive-latex-recommended
is recommended by too few Debian packages, while texlive-latex-recommended seems
necessary by many texlive related Debian packages...
$ lualatex test-ja.tex
This is LuaTeX, Version 1.10.0 (TeX Live 2019/Debian)
restricted system commands enabled.
(./test-ja.tex
LaTeX2e <2019-10-01> patch level 3
luaotfload | main : initialization completed in 0.182 seconds
(/usr/share/texlive/texmf-dist/tex/luatex/luatexja/ltjarticle.cls
Document Class: ltjarticle 2019/10/17 v1.8c-ltj-17 Standard LuaLaTeX-ja class
(/usr/share/texlive/texmf-dist/tex/luatex/luatexja/luatexja.sty
(/usr/share/texlive/texmf-dist/tex/luatex/luatexja/luatexja-core.sty
(/usr/share/texlive/texmf-dist/tex/luatex/luatexbase/luatexbase.sty
(/usr/share/texlive/texmf-dist/tex/luatex/ctablestack/ctablestack.sty))
(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty)
! LaTeX Error: File `pdftexcmds.sty' not found.
Type X to quit or to proceed,
or enter new name. (Default extension: sty)
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages texlive-lang-japanese depends on:
ii fonts-ipaexfont-gothic 00401-2
ii fonts-ipaexfont-mincho 00401-2
ii fonts-ipafont-gothic00303-20
ii fonts-ipafont-mincho00303-20
ii ruby1:2.5.2
ii tex-common 6.13
ii texlive-base2019.20191208-4
ii texlive-binaries2019.20190605.51237-3
ii texlive-lang-cjk2019.20191208-1
texlive-lang-japanese recommends no packages.
texlive-lang-japanese suggests no packages.
Versions of packages tex-common depends on:
ii dpkg 1.19.7
ii ucf 3.0038+nmu1
Versions of packages tex-common suggests:
ii debhelper 12.7.1
Versions of packages texlive-lang-japanese is related to:
ii tex-common6.13
ii texlive-binaries 2019.20190605.51237-3
-- no debconf information
Bug#946480: lxc: non-root user cannot start a container under cgroupv2 / unified hierarchy
Package: lxc Version: 1:3.1.0+really3.0.4-2 Severity: important Tags: upstream User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Control: forwarded -1 https://github.com/lxc/lxc/issues/3221 Control: block 943981 by -1 Dear Maintainer, Exactly the same as reported by a Fedora 31 user at https://github.com/lxc/lxc/issues/3221 I believe that this is not a duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888647 because libpam-cgfs can do nothing useful under cgroupv2 / unified hierarchy as discussed at https://github.com/lxc/lxc/issues/3198 Best regards, Ryutaroh -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.29-2 ii libgcc11:8.3.0-6 ii liblxc11:3.1.0+really3.0.4-2 ii lsb-base 10.2019051400 Versions of packages lxc recommends: ii apparmor 2.13.2-10 pn bridge-utils ii debootstrap 1.0.114 ii dirmngr 2.2.12-1+deb10u1 ii dnsmasq-base [dnsmasq-base] 2.80-1 ii gnupg2.2.12-1+deb10u1 ii iproute2 4.20.0-2 ii iptables 1.8.2-4 pn libpam-cgfs pn lxc-templates pn lxcfs ii openssl 1.1.1d-0+deb10u1 ii rsync3.1.3-6 pn uidmap Versions of packages lxc suggests: ii btrfs-progs 4.20.1-2 ii lvm2 2.03.02-3 pn python3-lxc -- debconf information: lxc/auto_update_config:
Bug#946170: libpam-cgfs: does nothing under cgroupv2 / unified hierarchy
Control: severity -1 minor Control: unblock 943981 by -1 The discussion at the upstream https://github.com/lxc/lxc/issues/3198 shows that libpam-cgfs cannot do anything useful on Linux booted with systemd.unified_cgroup_hierarchy. So I would like to lower the severity and blocking status. This cannot be fixed, but the man page should be updated, and a proper instruction should be given so that a non-root user can start an LXC container with full functionality. Best regards, Ryutaroh
Bug#944389: LXC seems very untested under cgroup2 / unified hierarchy
LXC (github master branch) shows lots of problem when host Linux booted with systemd.unified_cgroup_hierarchy, and it seems very untested to me. I was able to find lots of problems as below. https://github.com/lxc/lxc/issues/3211 https://github.com/lxc/lxc/issues/3208 https://github.com/lxc/lxc/issues/3206 https://github.com/lxc/lxc/issues/3201 (closed but the bug still exists) https://github.com/lxc/lxc/issues/3198 In addition, the upstream developer seems reluctant to admit a problem, see https://github.com/lxc/lxc/issues/3201 Ryutaroh
Bug#946170: libpam-cgfs: does nothing under cgroupv2 / unified hierarchy
The upstream maintainer seems to think that libpam-cgfs cannot work under cgroup2 / unified hierarchy as seen in the discussion of https://github.com/lxc/lxc/issues/3198 Ryutaroh
Bug#946172: lxc-checkconfig gives incorrect warnings with cgroupv2 / unified hierarchy
Package: lxc Version: 1:3.1.0+really3.0.4-2 Severity: minor Tags: upstream User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Control: -1 forwarded https://github.com/lxc/lxc/issues/3208 Dear Maintainer, Under cgroup2 / unified hierarchy, lxc-checkconfig gives some incorrect warnings in red color as # lxc-checkconfig Kernel configuration not found at /proc/config.gz; searching... Kernel configuration found at /boot/config-5.3.0-2-amd64 Cgroup v1 systemd controller: missing Cgroup v1 freezer controller: missing Cgroup namespace: required It was reported to https://github.com/lxc/lxc/issues/3208 Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.29-3 ii libgcc11:8.3.0-6 ii liblxc11:3.1.0+really3.0.4-2 ii lsb-base 10.2019051400 Versions of packages lxc recommends: ii apparmor 2.13.2-10 ii bridge-utils 1.6-2 ii debootstrap 1.0.114 ii dirmngr 2.2.12-1+deb10u1 ii dnsmasq-base [dnsmasq-base] 2.80-1 ii gnupg2.2.12-1+deb10u1 ii iproute2 4.20.0-2 ii iptables 1.8.2-4 ii libpam-cgfs 1:3.1.0+really3.0.4-2 ii lxc-templates3.0.4-1 pn lxcfs ii nftables 0.9.0-2 ii openssl 1.1.1c-1 ii rsync3.1.3-8 ii uidmap 1:4.5-1.1 Versions of packages lxc suggests: pn btrfs-progs ii lvm2 2.03.02-3 pn python3-lxc -- debconf information: lxc/auto_update_config:
Bug#946170: libpam-cgfs: does nothing under cgroupv2 / unified hierarchy
Package: libpam-cgfs Version: 1:3.1.0+really3.0.4-2 Severity: important Tags: upstream User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Control: -1 forwarded https://github.com/lxc/lxc/issues/3198 Control: block 943981 by -1 Dear Maintainer, According to https://github.com/lxc/lxc/blob/master/doc/pam_cgfs.sgml.in libpam_cgfs chowns some cgroup directories to a login user, but actually it does nothing under cgroup2 unified hierarchy, as $ ls -l /sys/fs/cgroup/user.slice/user-1000.slice /sys/fs/cgroup/user.slice/user-1000.slice/session-2.scope /sys/fs/cgroup/user.slice/user-1000.slice: total 0 -r--r--r-- 1 root root 0 Dec 5 03:40 cgroup.controllers -r--r--r-- 1 root root 0 Dec 5 03:40 cgroup.events -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.freeze -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.max.depth -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.max.descendants -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.procs -r--r--r-- 1 root root 0 Dec 5 03:40 cgroup.stat -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.subtree_control -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.threads -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.type -rw-r--r-- 1 root root 0 Dec 5 03:40 cpu.pressure -r--r--r-- 1 root root 0 Dec 5 03:40 cpu.stat -rw-r--r-- 1 root root 0 Dec 5 03:40 io.max -rw-r--r-- 1 root root 0 Dec 5 03:40 io.pressure -r--r--r-- 1 root root 0 Dec 5 03:40 io.stat -r--r--r-- 1 root root 0 Dec 5 03:40 memory.current -r--r--r-- 1 root root 0 Dec 5 03:40 memory.events -r--r--r-- 1 root root 0 Dec 5 03:40 memory.events.local -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.high -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.low -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.max -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.min -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.oom.group -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.pressure -r--r--r-- 1 root root 0 Dec 5 03:40 memory.stat -r--r--r-- 1 root root 0 Dec 5 03:40 pids.current -r--r--r-- 1 root root 0 Dec 5 03:40 pids.events -rw-r--r-- 1 root root 0 Dec 5 03:40 pids.max drwxr-xr-x 2 root root 0 Dec 5 03:40 session-2.scope drwxr-xr-x 4 ryutaroh ryutaroh 0 Dec 5 03:40 user@1000.service /sys/fs/cgroup/user.slice/user-1000.slice/session-2.scope: total 0 -r--r--r-- 1 root root 0 Dec 5 03:42 cgroup.controllers -r--r--r-- 1 root root 0 Dec 5 03:40 cgroup.events -rw-r--r-- 1 root root 0 Dec 5 03:42 cgroup.freeze -rw-r--r-- 1 root root 0 Dec 5 03:42 cgroup.max.depth -rw-r--r-- 1 root root 0 Dec 5 03:42 cgroup.max.descendants -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.procs -r--r--r-- 1 root root 0 Dec 5 03:42 cgroup.stat -rw-r--r-- 1 root root 0 Dec 5 03:40 cgroup.subtree_control -rw-r--r-- 1 root root 0 Dec 5 03:42 cgroup.threads -rw-r--r-- 1 root root 0 Dec 5 03:42 cgroup.type -rw-r--r-- 1 root root 0 Dec 5 03:42 cpu.pressure -r--r--r-- 1 root root 0 Dec 5 03:40 cpu.stat -rw-r--r-- 1 root root 0 Dec 5 03:42 io.max -rw-r--r-- 1 root root 0 Dec 5 03:42 io.pressure -r--r--r-- 1 root root 0 Dec 5 03:42 io.stat -r--r--r-- 1 root root 0 Dec 5 03:42 memory.current -r--r--r-- 1 root root 0 Dec 5 03:42 memory.events -r--r--r-- 1 root root 0 Dec 5 03:42 memory.events.local -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.high -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.low -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.max -rw-r--r-- 1 root root 0 Dec 5 03:40 memory.min -rw-r--r-- 1 root root 0 Dec 5 03:42 memory.oom.group -rw-r--r-- 1 root root 0 Dec 5 03:42 memory.pressure -r--r--r-- 1 root root 0 Dec 5 03:42 memory.stat -r--r--r-- 1 root root 0 Dec 5 03:42 pids.current -r--r--r-- 1 root root 0 Dec 5 03:42 pids.events -rw-r--r-- 1 root root 0 Dec 5 03:40 pids.max Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpam-cgfs depends on: ii libc6 2.29-3 ii libgcc1 1:8.3.0-6 ii libpam-runtime 1.3.1-5 ii libpam0g1.3.1-5 libpam-cgfs recommends no packages. libpam-cgfs suggests no packages. -- no debconf information
Bug#944389: lxc: Fails to work with cgroupv2 / unified hierarchy
Package: lxc Version: 3.2.1+master~20191129-1942-0ubuntu1~disco Tags: fixed-upstream Followup-For: Bug #944389 Dear Maintainer, On the github I was advised to add lxc.cgroup.devices.allow = lxc.cgroup.devices.deny = lxc.mount.auto = proc:mixed sys:mixed cgroup:rw:force to /var/lib/lxc/container/config, and with above lines lxc can start Debian 10.2, on the lxc 3.2.1+master~20191129-1942-0ubuntu1~disco from https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/daily even on cgroup 2 enabled Debian. But Debian package 3.1.0+really3.0.4-2 is still unable to start a container on unified cgroup hierarchy. I added the fixed-upstream tag. On github I was also suggested to add lxc.cgroup.relative = 1 to obey the systemd guideline at https://github.com/systemd/systemd/blob/master/docs/CGROUP_DELEGATION.md#some-donts Best regards, Ryutaroh -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii lxc-utils 3.2.1+master~20191129-1942-0ubuntu1~disco lxc recommends no packages. lxc suggests no packages. -- no debconf information
Bug#944389: lxc: Fails to work with cgroupv2 / unified hierarchy
Package: lxc Version: 1:3.1.0+really3.0.4-2 Followup-For: Bug #944389 With config lines: lxc.cgroup.devices.deny = lxc.cgroup.devices.allow = lxc.init.cmd = /bin/bash the container starts, but without lxc.init.cmd = /bin/bash the /sbin/init in the container prints Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems. and does not start, when host Debian started with systemd.unified_cgroup_hierarchy. There seems to be some compatibility issue between lxc and systemd in the container. Best regards, Ryutaroh -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.29-3 ii libgcc11:8.3.0-6 ii liblxc11:3.1.0+really3.0.4-2 ii lsb-base 10.2019051400 Versions of packages lxc recommends: ii apparmor 2.13.2-10 ii bridge-utils 1.6-2 ii debootstrap 1.0.114 ii dirmngr 2.2.12-1+deb10u1 ii dnsmasq-base [dnsmasq-base] 2.80-1 ii gnupg2.2.12-1+deb10u1 ii iproute2 4.20.0-2 ii iptables 1.8.2-4 pn libpam-cgfs ii lxc-templates3.0.4-1 pn lxcfs ii nftables 0.9.0-2 ii openssl 1.1.1c-1 ii rsync3.1.3-8 ii uidmap 1:4.5-1.1 Versions of packages lxc suggests: pn btrfs-progs ii lvm2 2.03.02-3 pn python3-lxc -- debconf information: lxc/auto_update_config:
Bug#944389: lxc: Fails to work with cgroupv2 / unified hierarchy
Package: lxc Version: 1:3.1.0+really3.0.4-2 Followup-For: Bug #944389 Dear Maintainer, This problem can be worked around by adding lxc.cgroup.devices.deny = lxc.cgroup.devices.allow = to the end of /var/lib/lxc/test-container/config LXC does not support the V2 device controller until very recently https://github.com/lxc/lxc/commit/637de040ae55216a0551a35c23ff0de99cd6d719 So there should be no harm of adding lxc.cgroup.devices.deny = lxc.cgroup.devices.allow = Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lxc depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.29-3 ii libgcc11:8.3.0-6 ii liblxc11:3.1.0+really3.0.4-2 ii lsb-base 10.2019051400 Versions of packages lxc recommends: ii apparmor 2.13.2-10 ii bridge-utils 1.6-2 ii debootstrap 1.0.114 ii dirmngr 2.2.12-1+deb10u1 ii dnsmasq-base [dnsmasq-base] 2.80-1 ii gnupg2.2.12-1+deb10u1 ii iproute2 4.20.0-2 ii iptables 1.8.2-4 pn libpam-cgfs ii lxc-templates3.0.4-1 pn lxcfs ii nftables 0.9.0-2 ii openssl 1.1.1c-1 ii rsync3.1.3-8 ii uidmap 1:4.5-1.1 Versions of packages lxc suggests: pn btrfs-progs ii lvm2 2.03.02-3 pn python3-lxc -- debconf information: lxc/auto_update_config:
Bug#934372: snapd: does not work under cgroup v2 at all
Package: snapd Version: 2.42.1-1 Followup-For: Bug #934372 Control: block 943981 by -1 Control: severity -1 minor Control: user pkg-systemd-maintain...@lists.alioth.debian.org Control: usertag -1 + cgroupv2 Dear Maintainer, The situation improved in version 2.42.1, now we have $ snap run hello-world WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement Hello World! I changed the severity and a usertag cgroupv2, see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943981 Best regards, Ryutaroh -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages snapd depends on: ii adduser 3.118 ii apparmor 2.13.2-10 ii ca-certificates 20190110 ii gnupg2.2.12-1+deb10u1 ii libapparmor1 2.13.2-10 ii libc62.29-3 ii libcap2 1:2.25-2 ii libseccomp2 2.4.2-2 ii libudev1 241-7~deb10u1 ii openssh-client 1:7.9p1-10 ii squashfs-tools 1:4.4-1 ii systemd 241-7~deb10u1 ii udev 241-7~deb10u1 Versions of packages snapd recommends: ii gnupg 2.2.12-1+deb10u1 Versions of packages snapd suggests: ii zenity 3.30.0-2 -- no debconf information
Bug#940072: context: weakly depends on inkscape
Package: context Version: 2019.03.21.20190425-2 Severity: minor Dear Maintainer, ConTeXt uses inkscape to handle SVG in OpenType font format as http://tracker.luatex.org/view.php?id=1013 But the Debian package does not depend/recommend/suggest the inkscape package. Some kind of dependency seems reasonable. The same comment might apply to texlive-luatex package, though the supporting status of SVG-OT font by lualatex seems unclear as https://github.com/latex3/luaotfload/issues/96 Ryutaroh Matsumoto -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages context depends on: ii lmodern 2.004.5-6 ii ruby 1:2.5.1 ii tex-common6.12 ii tex-gyre 20180621-3 ii texlive-base 2019.20190830-1 ii texlive-binaries 2019.20190605.51237-2 ii texlive-metapost 2019.20190830-1 Versions of packages context recommends: pn context-modules pn fonts-freefont pn fonts-gfs-artemisia pn fonts-gfs-baskerville pn fonts-gfs-bodoni-classic pn fonts-gfs-didot pn fonts-gfs-didot-classic pn fonts-gfs-gazis pn fonts-gfs-neohellenic pn fonts-gfs-olga pn fonts-gfs-porson pn fonts-gfs-solomos pn fonts-gfs-theokritos ii fonts-sil-gentium 20081126:1.03-2 Versions of packages context suggests: pn context-nonfree ii fontforge 1:20170731~dfsg-1 ii libxml-parser-perl 2.44-4 pn perl-tk -- no debconf information
Bug#849602: firefox: font TwitterMozilla can be installed below /usr/share/fonts
The Twemoji Mozilla font bundled in Firefox can also be used by
ConTeXt Mark IV packaged in Debian. Processing the following file
by /usr/bin/context generates the attached PDF file.
\definefontfeature
[overlay]
[default]
[ccmp=yes,
colr=yes,
dist=yes]
\definefontsynonym
[emoji]
[file:TwemojiMozilla.ttf*overlay]
\starttext
\emoji{family man woman girl boy}
\stoptext
Ryutaroh Matsumoto
Ryutaroh Matsumoto :
>
> Package: firefox
> Version: 68.0.2-3
> Followup-For: Bug #849602
> Control: retitle -1 font TwitterMozilla can be installed below
> /usr/share/fonts
>
> Dear Maintainer,
>
> EmojiOne in Firefox was replaced by Twemoji distributed by Twitter.
> TwemojiMozilla.ttf in Firefox 68 is COLR/CPAL format in opentype
> https://docs.microsoft.com/en-us/typography/opentype/spec/colr
> which is not a bitmap font format and gives better scaling result
> than the bitmap font format.
>
> On the other hand Noto Color Emoji by Google is in CBDT format
> https://docs.microsoft.com/en-us/typography/opentype/spec/cbdt
> which is the bitmap.
> In Debian there seems no color emoji font in COLR/CPAL format.
>
> COLR/CPAL color font format is supported in gimp
> https://gitlab.gnome.org/GNOME/gimp/issues/1663
> and harftex https://github.com/khaledhosny/harftex
> Support request is filed against LibreOffice
> https://bugs.documentfoundation.org/show_bug.cgi?id=104403
>
> Addition of another emoji font in COLR format to /usr/share/fonts
> may be useful for Debian.
>
> Best regards,
> Ryutaroh Matsumoto
twemoji-mozilla.pdf
Description: Adobe PDF document
Bug#881475: EmojiOne in Firefox was replaced by Twitter Emoji
Control: retitle -1 RFP: twemoji-mozilla -- Twitter Emoji font in COLR/CPAL layered format EmojiOne in Firefox/Mozilla was replaced by Twemoji (Twitter Emoji), and Mozilla no longer continues the developement of EmojiOne. Firefox 67 and later bundle Twemoji maintained at https://github.com/mozilla/twemoji-colr Ryutaroh Matsumoto
Bug#849602: firefox: font TwitterMozilla can be installed below /usr/share/fonts
Package: firefox Version: 68.0.2-3 Followup-For: Bug #849602 Control: retitle -1 font TwitterMozilla can be installed below /usr/share/fonts Dear Maintainer, EmojiOne in Firefox was replaced by Twemoji distributed by Twitter. TwemojiMozilla.ttf in Firefox 68 is COLR/CPAL format in opentype https://docs.microsoft.com/en-us/typography/opentype/spec/colr which is not a bitmap font format and gives better scaling result than the bitmap font format. On the other hand Noto Color Emoji by Google is in CBDT format https://docs.microsoft.com/en-us/typography/opentype/spec/cbdt which is the bitmap. In Debian there seems no color emoji font in COLR/CPAL format. COLR/CPAL color font format is supported in gimp https://gitlab.gnome.org/GNOME/gimp/issues/1663 and harftex https://github.com/khaledhosny/harftex Support request is filed against LibreOffice https://bugs.documentfoundation.org/show_bug.cgi?id=104403 Addition of another emoji font in COLR format to /usr/share/fonts may be useful for Debian. Best regards, Ryutaroh Matsumoto
Bug#934371: libvirt0: latest verstion 5.6.0 is released
Package: libvirt0 Followup-For: Bug #934371 Control: close -1 5.6.0-1 The latest Debian package is 5.6.0. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt0 depends on: ii libacl1 2.2.53-4 ii libapparmor12.13.2-10 ii libaudit1 1:2.8.4-3 ii libc6 2.28-10 ii libcap-ng0 0.7.9-2 ii libcurl3-gnutls 7.64.0-4 ii libdbus-1-3 1.12.16-1 ii libdevmapper1.02.1 2:1.02.155-3 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.9-4 ii libnl-3-200 3.4.0-1 ii libnuma12.0.12-1 ii libsasl2-2 2.1.27+dfsg-1 ii libselinux1 2.8-1+b1 ii libssh2-1 1.8.0-2.1 ii libxml2 2.9.4+dfsg1-7+b3 ii libyajl22.1.0-3 Versions of packages libvirt0 recommends: ii lvm2 2.03.02-3 libvirt0 suggests no packages. -- no debconf information
Bug#935951: fonts-noto-color-emoji: was updated on August 2019 to support Unicode 12.0 Emoji
Package: fonts-noto-color-emoji Version: 0~20180810-1 Severity: wishlist Dear Maintainer, Google updated the font to support Unicode 12.0 on August 2019 at https://github.com/googlefonts/noto-emoji/blob/master/NotoColorEmoji.ttf Please consider to update the package. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#935950: fonts-symbola: Much newer version is available at upstream
Package: fonts-symbola Version: 2.60-1 Severity: wishlist Dear Maintainer, The latest version of the Symbola font was released on March 2019 at http://users.teilar.gr/%7Eg1951d/ and it supports Unicode 12.0. If the license allows its inclusion to Debian, please consider to update the package. Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#934372: snapd: does not work under cgroup v2 at all
Control: forwarded -1 https://bugs.launchpad.net/snappy/+bug/1839709 Control: tags -1 + upstream
Bug#934372: snapd: does not work under cgroup v2 at all
Package: snapd Version: 2.40-1 Severity: important Dear Maintainer, When I boot Linux using the control group V2, by adding systemd.unified_cgroup_hierarchy=1 to the kernel command line, no snap package can be used. For example, snap run hello-world just gives cannot open cgroup hierarchy /sys/fs/cgroup/freezer: No such file or directory Best regards, Ryutaroh Matsumoto -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages snapd depends on: ii adduser 3.118 ii apparmor 2.13.2-10 ii ca-certificates 20190110 ii gnupg2.2.12-1 ii libapparmor1 2.13.2-10 ii libc62.28-10 ii libcap2 1:2.25-2 ii libseccomp2 2.3.3-4 ii libudev1 241-5 ii openssh-client 1:7.9p1-10 ii squashfs-tools 1:4.3-13 ii systemd 241-5 ii udev 241-5 Versions of packages snapd recommends: ii gnupg 2.2.12-1 Versions of packages snapd suggests: ii zenity 3.30.0-2 -- no debconf information
Bug#934371: libvirt0: latest verstion 5.6.0 is released
Package: libvirt0 Version: 5.2.0-2 Severity: wishlist Dear Maintainer, A newer version 5.6.0 was released at https://libvirt.org/sources/libvirt-5.6.0.tar.xz The latest version should also fix bug #931243 Best regards, Ryutaroh -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt0 depends on: ii libacl1 2.2.53-4 ii libapparmor12.13.2-10 ii libaudit1 1:2.8.4-3 pn libavahi-client3 ii libavahi-common30.7-4+b1 ii libc6 2.28-10 ii libcap-ng0 0.7.9-2 ii libcurl3-gnutls 7.64.0-4 ii libdbus-1-3 1.12.16-1 ii libdevmapper1.02.1 2:1.02.155-3 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4 ii libnl-3-200 3.4.0-1 ii libnl-route-3-200 3.4.0-1 ii libnuma12.0.12-1 ii libsasl2-2 2.1.27+dfsg-1 ii libselinux1 2.8-1+b1 ii libssh2-1 1.8.0-2.1 ii libxml2 2.9.4+dfsg1-7+b3 ii libyajl22.1.0-3 Versions of packages libvirt0 recommends: ii lvm2 2.03.02-3 libvirt0 suggests no packages. -- no debconf information
Bug#934369: linux-image-5.2.0-1-amd64-unsigned: powertop -i 10 always causes kernel NULL pointer dereference
Package: src:linux Version: 5.2.6-1 Severity: normal Dear Maintainer, When I run "powertop -i 10" it always triggers "kernel NULL pointer dereference". I observed this issue on two different models on Panasonic notbooks. I can always reproduce this. dmesg output is pasted below. Best regards, Ryutaroh Matsumoto [ 1653.251287] BUG: kernel NULL pointer dereference, address: [ 1653.252724] #PF: supervisor instruction fetch in kernel mode [ 1653.254161] #PF: error_code(0x0010) - not-present page [ 1653.255580] PGD 0 P4D 0 [ 1653.256875] Oops: 0010 [#1] SMP PTI [ 1653.258313] CPU: 2 PID: 1927 Comm: powertop Tainted: GE 5.2.0-1-amd64 #1 Debian 5.2.6-1 [ 1653.259375] Hardware name: Panasonic Corporation CF-LX3YEUCU/CFLX3-1L, BIOS V1.11L16 10/29/2013 [ 1653.260208] RIP: 0010:0x0 [ 1653.260973] Code: Bad RIP value. [ 1653.261694] RSP: 0018:b2328376bcd8 EFLAGS: 00010246 [ 1653.262425] RAX: RBX: 904c161b7400 RCX: 0001 [ 1653.263141] RDX: 904c15e4bc00 RSI: 904c161b7400 RDI: 904c1735e2b0 [ 1653.263854] RBP: 904c1735e2b0 R08: R09: [ 1653.264565] R10: 904c17311840 R11: R12: 904c161b7410 [ 1653.265276] R13: b591cbf0 R14: R15: 904c161b7400 [ 1653.265976] FS: 7f8f41cdcfc0() GS:904c1790() knlGS: [ 1653.266708] CS: 0010 DS: ES: CR0: 80050033 [ 1653.267420] CR2: ffd6 CR3: 0001a61d6003 CR4: 001606e0 [ 1653.268141] Call Trace: [ 1653.268861] do_dentry_open+0x13a/0x370 [ 1653.269588] path_openat+0x2c6/0x1480 [ 1653.270337] ? terminate_walk+0xe6/0x100 [ 1653.271059] ? path_lookupat.isra.48+0xa3/0x220 [ 1653.271791] ? reuse_swap_page+0x105/0x320 [ 1653.272513] do_filp_open+0x93/0x100 [ 1653.273226] ? __check_object_size+0x15d/0x189 [ 1653.273945] do_sys_open+0x184/0x220 [ 1653.274690] do_syscall_64+0x53/0x130 [ 1653.275426] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 1653.276170] RIP: 0033:0x7f8f420391ae [ 1653.276909] Code: 25 00 00 41 00 3d 00 00 41 00 74 48 48 8d 05 59 65 0d 00 8b 00 85 c0 75 69 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 0f 87 a6 00 00 00 48 8b 4c 24 28 64 48 33 0c 25 [ 1653.278535] RSP: 002b:7ffc883a15b0 EFLAGS: 0246 ORIG_RAX: 0101 [ 1653.279348] RAX: ffda RBX: 56490228b8b0 RCX: 7f8f420391ae [ 1653.280172] RDX: RSI: 7ffc883a2960 RDI: ff9c [ 1653.281004] RBP: 0008 R08: 0008 R09: 0001 [ 1653.281834] R10: R11: 0246 R12: 7f8f42405835 [ 1653.282691] R13: 7f8f42405835 R14: 0001 R15: 5649022971a0 [ 1653.283531] Modules linked in: msr(E) xt_CHECKSUM(E) xt_MASQUERADE(E) xt_conntrack(E) ipt_REJECT(E) nf_reject_ipv4(E) xt_tcpudp(E) nft_compat(E) tun(E) bridge(E) stp(E) llc(E) nft_counter(E) nft_chain_nat(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) nf_tables(E) nfnetlink(E) ctr(E) ccm(E) cmac(E) bnep(E) nls_ascii(E) nls_cp437(E) intel_rapl(E) vfat(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) fat(E) coretemp(E) kvm_intel(E) kvm(E) irqbypass(E) btusb(E) arc4(E) btrtl(E) btbcm(E) btintel(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) aesni_intel(E) aes_x86_64(E) bluetooth(E) iwlmvm(E) uvcvideo(E) videobuf2_vmalloc(E) videobuf2_memops(E) videobuf2_v4l2(E) crypto_simd(E) mac80211(E) cryptd(E) drbg(E) videobuf2_common(E) glue_helper(E) videodev(E) ansi_cprng(E) acpi_als(E) ecdh_generic(E) ecc(E) kfifo_buf(E) media(E) iwlwifi(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) ledtrig_audio(E) industrialio(E) snd_hda_codec_hdmi(E) efi_pstore(E) [ 1653.283553] snd_hda_intel(E) mei_me(E) intel_cstate(E) intel_uncore(E) snd_hda_codec(E) snd_hda_core(E) joydev(E) efivars(E) snd_hwdep(E) mei(E) pcspkr(E) serio_raw(E) panasonic_laptop(E) rmi_smbus(E) intel_rapl_perf(E) sparse_keymap(E) sg(E) rmi_core(E) snd_pcm(E) iTCO_wdt(E) iTCO_vendor_support(E) cfg80211(E) snd_timer(E) snd(E) rfkill(E) watchdog(E) soundcore(E) intel_pch_thermal(E) processor_thermal_device(E) int3402_thermal(E) int3403_thermal(E) int340x_thermal_zone(E) int3400_thermal(E) intel_soc_dts_iosf(E) acpi_thermal_rel(E) pcc_cpufreq(E) evdev(E) intel_smartconnect(E) battery(E) ac(E) parport_pc(E) ppdev(E) lp(E) parport(E) efivarfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) btrfs(E) xor(E) zstd_decompress(E) zstd_compress(E) raid6_pq(E) libcrc32c(E) crc32c_generic(E) sd_mod(E) xhci_pci(E) ehci_pci(E) xhci_hcd(E) ehci_hcd(E) ahci(E) sdhci_pci(E) libahci(E) cqhci(E) i915(E) i2c_algo_bit(E) crc32c_intel(E) sdhci(E) psmouse(E) libata(E) i2c_i801(E) [ 1653.288408] drm_kms_helper(E) scsi_mod(E) usbcore(E) lpc_ich(E) e1000e(E) mmc_core(E) mfd_core(E) drm(E) usb_common(E) fan(E) video(E) bu
Bug#934309: linux-image-5.2.0-1-amd64-unsigned: suggesting INTEL_IOMMU_DEFAULT_ON
Package: src:linux Version: 5.2.6-1 Severity: wishlist Dear Maintainer, Without hardware IOMMU, heavy IO traffic sometimes causes "swiotlb buffer is full" from kernel/dma/swiotlb.c. Then an error is returned to a device driver calling dma_map_sg() or something similar. Some device drivers (e.g. ehci-pci.c) do not handle failures from dma_map_*() functions, and failures of assigning DMA memories often lead undesirable behaviors. Enablement of hardware IOMMU reduces possiblity of "swiotlb buffer is full". I'd like to request to consider INTEL_IOMMU_DEFAULT_ON. AMD IOMMU seems to be enabled by default, btw. Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.2.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-19)) #1 SMP Debian 5.2.6-1 (2019-08-05) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.2.0-1-amd64 root=UUID=12f1110c-5548-452b-ba7e-b995b8aa7f45 ro i915.fastboot=1 swiotlb=noforce iommu=force,merge,nopanic,nopt intel_iommu=on cgoup_no_v1=all systemd.unified_cgroup_hierarchy=1 systemd.show_status=1 ** Tainted: E (8192) * Unsigned module has been loaded. ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Panasonic Corporation product_name: CFSZ6-1L product_version: 001 chassis_vendor: Panasonic Corporation chassis_version: 001 bios_vendor: American Megatrends Inc. bios_version: V1.11L10 board_vendor: Panasonic Corporation board_name: CFSZ6-1L board_version: 1 ** Loaded modules: ctr(E) ccm(E) cmac(E) cpufreq_powersave(E) cpufreq_userspace(E) cpufreq_conservative(E) bnep(E) intel_rapl(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) arc4(E) snd_hda_codec_hdmi(E) snd_soc_skl(E) snd_soc_skl_ipc(E) snd_soc_sst_ipc(E) cdc_mbim(E) snd_hda_codec_realtek(E) btusb(E) snd_soc_sst_dsp(E) btrtl(E) btbcm(E) snd_hda_codec_generic(E) cdc_wdm(E) btintel(E) snd_hda_ext_core(E) ledtrig_audio(E) snd_soc_acpi_intel_match(E) snd_soc_acpi(E) snd_soc_core(E) qcserial(E) bluetooth(E) usb_wwan(E) cdc_ncm(E) snd_compress(E) efi_pstore(E) aesni_intel(E) usbnet(E) mii(E) snd_hda_intel(E) usbserial(E) aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) intel_cstate(E) uvcvideo(E) iwlmvm(E) snd_hda_codec(E) videobuf2_vmalloc(E) videobuf2_memops(E) intel_uncore(E) videobuf2_v4l2(E) mac80211(E) iTCO_wdt(E) intel_rapl_perf(E) videobuf2_common(E) snd_hda_core(E) serio_raw(E) iTCO_vendor_support(E) snd_hwdep(E) videodev(E) watchdog(E) drbg(E) iwlwifi(E) media(E) snd_pcm(E) efivars(E) pcspkr(E) snd_timer(E) ansi_cprng(E) snd(E) soundcore(E) cfg80211(E) tpm_crb(E) ecdh_generic(E) ecc(E) rfkill(E) sg(E) mei_me(E) processor_thermal_device(E) mei(E) intel_soc_dts_iosf(E) intel_pch_thermal(E) battery(E) acpi_als(E) kfifo_buf(E) industrialio(E) int3403_thermal(E) int340x_thermal_zone(E) tpm_tis(E) tpm_tis_core(E) panasonic_laptop(E) int3406_thermal(E) tpm(E) sparse_keymap(E) rng_core(E) int3400_thermal(E) acpi_pad(E) acpi_thermal_rel(E) ac(E) pcc_cpufreq(E) evdev(E) joydev(E) parport_pc(E) ppdev(E) lp(E) parport(E) efivarfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sr_mod(E) cdrom(E) sd_mod(E) ahci(E) libahci(E) crc32c_intel(E) i915(E) psmouse(E) sdhci_pci(E) xhci_pci(E) i2c_algo_bit(E) cqhci(E) xhci_hcd(E) libata(E) drm_kms_helper(E) e1000e(E) scsi_mod(E) i2c_i801(E) sdhci(E) mmc_core(E) usbcore(E) drm(E) usb_common(E) fan(E) video(E) button(E) ** Network interface configuration: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback ** Network status: *** IP interfaces and addresses: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000 link/ether a8:13:74:97:2f:94 brd ff:ff:ff:ff:ff:ff 3: wwp0s20f0u2i12: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether ba:d9:fa:0c:cc:18 brd ff:ff:ff:ff:ff:ff 4: wlp2s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:28:f8:4a:37:bf brd ff:ff:ff:ff:ff:ff inet 192.168.1.4/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp2s0 valid_lft 13555sec preferred_lft 13555sec inet6 2409:251:2c0:1500:fbf1:f1f9:2ab9:f9c7/64 scope global dynamic noprefixroute valid_lft 13558sec preferred_lft 11758sec inet6 fe80::9b0f:dffc:a216:933/64 scope link noprefixroute valid_lft forever preferred_lft forever *
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Hi Hilmar, I forgot to mention one thing. The version of luaotfload was 2.98 (almost the same as your 2.97). What I saw may be the same as what you told. I tend to agree with the upstream developer as he also consideres this issue as an open bug at https://github.com/u-fischer/luaotfload/issues/49 Anyway 1.8 GB is much better (for Japanese) than 6GB. Ryutaroh From: Ryutaroh Matsumoto Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts Date: Fri, 19 Jul 2019 10:39:30 +0900 (JST) > Hi Hilmar, > > Thank you for your response. > I have checked this issue under TeXLive 2019 as of July 18 > (installed by "install-tl") under ubuntu 19.04 > (not debian/ubuntu packages) > > The memory consumption of the latex file included in this > bug report was "only" 1.8 GB after rm -rf ~/.texlive2019. > Noto CJK fonts versions are those of ubuntu 19.04 > (not the latest ones). > It was 6 GB when I filed this report. > Maybe 32-bit Linux can now handle the Noto CJK fonts. > > At least we can say significant improvement is in the upstream, > though 1.8 GB seems a bit larger than necessary... > > I again compiled the same latex file by xelatex, > but the processing finished immediately and > I could not see the memory consumption by "top"... > > Ryutaroh > > > From: =?UTF-8?Q?Hilmar_Preu=c3=9fe?= > Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto > CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto > CJK fonts > Date: Thu, 18 Jul 2019 16:24:39 +0200 > >> On 18.07.19 13:39, Ryutaroh Matsumoto wrote: >> >> Hi Ryutaroh, >> >>> I believe that the problem is spotted and fixed at >>> https://github.com/u-fischer/luaotfload/issues/55 >>> >>> The above seems to be uploaded to ctan on July 15. >>> Maybe the next release of texlive-luatex package will close >>> this issue without special effort. >>> >> >> 2019-05-18 luaotfload v2.97 >> * fix issue #47 >> * fix whatsits interfering with letterspacing (issue #53) >> * fix luaotfload-tool switches version and find not working >> correctly (PR#59) >> * fix luaotfload-tool support of ttc fonts (PR#58) >> * sync with context files from 2019-05-18 (improves handling of >> large fonts, see e.g. issue #55 and PR#58) >> >> So, I'd expect that v2.97 solves the problem. This version however is in >> Debian unstable, hence I gave it another try. I've noticed a virtual >> memory allocation of luatex having a size of 1,9 GB when building the >> cache. Not sure, if this is an significant improvement over the initial >> situation. >> >> Hilmar >> -- >> sigfault >> #206401 http://counter.li.org >>
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Hi Hilmar, Thank you for your response. I have checked this issue under TeXLive 2019 as of July 18 (installed by "install-tl") under ubuntu 19.04 (not debian/ubuntu packages) The memory consumption of the latex file included in this bug report was "only" 1.8 GB after rm -rf ~/.texlive2019. Noto CJK fonts versions are those of ubuntu 19.04 (not the latest ones). It was 6 GB when I filed this report. Maybe 32-bit Linux can now handle the Noto CJK fonts. At least we can say significant improvement is in the upstream, though 1.8 GB seems a bit larger than necessary... I again compiled the same latex file by xelatex, but the processing finished immediately and I could not see the memory consumption by "top"... Ryutaroh From: =?UTF-8?Q?Hilmar_Preu=c3=9fe?= Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts,Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts Date: Thu, 18 Jul 2019 16:24:39 +0200 > On 18.07.19 13:39, Ryutaroh Matsumoto wrote: > > Hi Ryutaroh, > >> I believe that the problem is spotted and fixed at >> https://github.com/u-fischer/luaotfload/issues/55 >> >> The above seems to be uploaded to ctan on July 15. >> Maybe the next release of texlive-luatex package will close >> this issue without special effort. >> > > 2019-05-18 luaotfload v2.97 > * fix issue #47 > * fix whatsits interfering with letterspacing (issue #53) > * fix luaotfload-tool switches version and find not working > correctly (PR#59) > * fix luaotfload-tool support of ttc fonts (PR#58) > * sync with context files from 2019-05-18 (improves handling of > large fonts, see e.g. issue #55 and PR#58) > > So, I'd expect that v2.97 solves the problem. This version however is in > Debian unstable, hence I gave it another try. I've noticed a virtual > memory allocation of luatex having a size of 1,9 GB when building the > cache. Not sure, if this is an significant improvement over the initial > situation. > > Hilmar > -- > sigfault > #206401 http://counter.li.org >
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Control: tags 930292 - fixed-upstream Control: forwarded 930292 https://github.com/u-fischer/luaotfload/issues/49 Sorry I was wrong. The issue in the upstream is still open as above. Ryutaroh
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Control: tags 930292 + fixed-upstream I believe that the problem is spotted and fixed at https://github.com/u-fischer/luaotfload/issues/55 The above seems to be uploaded to ctan on July 15. Maybe the next release of texlive-luatex package will close this issue without special effort. Ryutaroh
Bug#931554: wpasupplicant: systemctl reload is not accepted
Package: wpasupplicant Version: 2:2.8-2 Severity: wishlist Tags: upstream patch Dear Maintainer, When wifi password is written in /etc/wpa_supplicant/wpa_supplicant-if.conf, wpa_supplicant@if.service is started by systemd. When one adds a new pair of SSID and its password in the above config file, wpa_supplicant has to reload the changed config file. But "systemctl reload" is not accepted because "ExecReload" is not given in /lib/systemd/system/wpa_supplicant@.service. The attached patch makes "systemctl reload" be accepted. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.1.15-cpusetrdma (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wpasupplicant depends on: ii adduser3.118 ii libc6 2.28-10 ii libdbus-1-31.12.16-1 ii libnl-3-2003.4.0-1 ii libnl-genl-3-200 3.4.0-1 ii libnl-route-3-200 3.4.0-1 ii libpcsclite1 1.8.24-1 ii libreadline7 7.0-5 ii libssl1.1 1.1.1c-1 ii lsb-base 10.2019051400 wpasupplicant recommends no packages. Versions of packages wpasupplicant suggests: pn libengine-pkcs11-openssl pn wpagui -- no debconf information --- /lib/systemd/system/wpa_supplicant@.service 2019-04-29 04:20:19.0 +0900 +++ /etc/systemd/system/wpa_supplicant@.service 2019-07-07 23:52:42.366364276 +0900 @@ -10,6 +10,7 @@ [Service] Type=simple ExecStart=/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-%I.conf -Dnl80211,wext -i%I +ExecReload=/bin/kill -HUP $MAINPID [Install] Alias=multi-user.target.wants/wpa_supplicant@%i.service
Bug#931243: libvirt0: does not work under cgroup v2 (and rtkit)
Control: tags 931243 + fixed-upstream This issue has been recognized and fixed by the upstream developers at https://libvirt.org/git/?p=libvirt.git;a=commit;h=1d49cdcd116186e079db5668893da17f56141652 The below is the upstream commit log: util: vircgroupv2: don't error out if enabling controller fails Currently CPU controller cannot be enabled if there is any real-time task running and is assigned to non-root cgroup which is the case on several distributions with graphical environment. Instead of erroring out treat it as the controller is not available. Signed-off-by: Pavel Hrdina Reviewed-by: Peter Krempa Ryutaroh
Bug#931243: libvirt0: does not work under cgroup v2 (and rtkit)
I found a much better workaround. rtkit works fine after the CGroup V2 CPU controller is enabled. So, if the V2 CPU controller is enabled before a user process gets the realtime priority, libvirt-daemon works also fine. I made the following lines to /etc/systemd/system/libvirtd.service.d/cpu.conf [Service] CPUQuota=1% Now everything works as expected in my environment! Ryutaroh Matsumoto
Bug#931243: libvirt0: does not work under cgroup v2 (and rtkit)
Package: libvirt0 Version: 5.2.0-2 Followup-For: Bug #931243 Control: found 931243 5.2.0-2 Dear Maintainer, I installed version 5.2.0-2 from the experimental and confirmed that this issue still exists in 5.2.0-2. Ryutaroh -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.1.15-ryutaroh (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt0 depends on: ii libacl1 2.2.53-4 ii libapparmor12.13.2-10 ii libaudit1 1:2.8.4-3 pn libavahi-client3 ii libavahi-common30.7-4+b1 ii libc6 2.28-10 ii libcap-ng0 0.7.9-2 ii libcurl3-gnutls 7.64.0-4 ii libdbus-1-3 1.12.16-1 ii libdevmapper1.02.1 2:1.02.155-3 ii libgcc1 1:8.3.0-6 ii libgnutls30 3.6.7-4 ii libnl-3-200 3.4.0-1 ii libnl-route-3-200 3.4.0-1 ii libnuma12.0.12-1 ii libsasl2-2 2.1.27+dfsg-1 ii libselinux1 2.8-1+b1 ii libssh2-1 1.8.0-2.1 ii libxml2 2.9.4+dfsg1-7+b3 ii libyajl22.1.0-3 Versions of packages libvirt0 recommends: ii lvm2 2.03.02-3 libvirt0 suggests no packages. -- no debconf information
Bug#931247: linux-image-5.0.0-trunk-amd64-unsigned: could enable pressure stall information?
Package: src:linux Version: 5.0.2-1~exp1 Severity: wishlist Dear Maintainer, Could you consider to set the kernel config variables as follows? CONFIG_PSI=y CONFIG_PSI_DEFAULT_DISABLED=y PSI stands for "pressure stall information" as described in https://lwn.net/ml/cgroups/20180712172942.10094-1-han...@cmpxchg.org/ It is enabled only if "psi=1" is given as the boot kernel parameter, so the only interested users can try and be affected. Best regards, Ryutaroh Matsumoto -- Package-specific info: ** Version: Linux version 5.0.0-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-3)) #1 SMP Debian 5.0.2-1~exp1 (2019-03-18) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.0.0-trunk-amd64 root=UUID=2fac8e46-9da0-4d9c-8b22-79bc7c6e1a8d ro psi=1 i8042.reset=1 systemd.unified_cgroup_hierarchy=1 ** Tainted: E (8192) * Unsigned module has been loaded. ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Panasonic Corporation product_name: CF-LX3YEUCU product_version: 001 chassis_vendor: Panasonic Corporation chassis_version: 001 bios_vendor: American Megatrends Inc. bios_version: V1.11L16 board_vendor: Panasonic Corporation board_name: CFLX3-1L board_version: 1 ** Loaded modules: fuse(E) ufs(E) qnx4(E) hfsplus(E) hfs(E) minix(E) ntfs(E) msdos(E) jfs(E) xfs(E) dm_mod(E) nft_chain_route_ipv4(E) xt_CHECKSUM(E) nft_chain_nat_ipv4(E) ipt_MASQUERADE(E) nf_nat_ipv4(E) nf_nat(E) xt_conntrack(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) ipt_REJECT(E) nf_reject_ipv4(E) nft_counter(E) xt_tcpudp(E) nft_compat(E) tun(E) bridge(E) stp(E) llc(E) nf_tables(E) devlink(E) nfnetlink(E) ctr(E) ccm(E) cmac(E) bnep(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) intel_rapl(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) arc4(E) kvm_intel(E) btusb(E) kvm(E) irqbypass(E) uvcvideo(E) btrtl(E) btbcm(E) iwlmvm(E) videobuf2_vmalloc(E) videobuf2_memops(E) videobuf2_v4l2(E) btintel(E) mac80211(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) snd_hda_codec_hdmi(E) ledtrig_audio(E) videobuf2_common(E) snd_hda_intel(E) videodev(E) snd_hda_codec(E) snd_hda_core(E) iwlwifi(E) media(E) snd_hwdep(E) snd_pcm(E) snd_timer(E) snd(E) bluetooth(E) drbg(E) ansi_cprng(E) ecdh_generic(E) acpi_als(E) soundcore(E) crct10dif_pclmul(E) cfg80211(E) crc32_pclmul(E) mei_me(E) ghash_clmulni_intel(E) kfifo_buf(E) industrialio(E) sg(E) mei(E) joydev(E) rfkill(E) iTCO_wdt(E) iTCO_vendor_support(E) serio_raw(E) efi_pstore(E) efivars(E) int3400_thermal(E) processor_thermal_device(E) panasonic_laptop(E) intel_smartconnect(E) acpi_thermal_rel(E) intel_soc_dts_iosf(E) int3403_thermal(E) intel_pch_thermal(E) int3402_thermal(E) int340x_thermal_zone(E) evdev(E) pcspkr(E) sparse_keymap(E) pcc_cpufreq(E) intel_cstate(E) intel_uncore(E) intel_rapl_perf(E) battery(E) ac(E) parport_pc(E) ppdev(E) lp(E) parport(E) efivarfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) ecb(E) btrfs(E) xor(E) zstd_decompress(E) zstd_compress(E) raid6_pq(E) libcrc32c(E) crc32c_generic(E) sd_mod(E) crc32c_intel(E) aesni_intel(E) i915(E) ahci(E) sdhci_pci(E) ehci_pci(E) libahci(E) xhci_pci(E) i2c_algo_bit(E) cqhci(E) aes_x86_64(E) crypto_simd(E) xhci_hcd(E) libata(E) psmouse(E) cryptd(E) ehci_hcd(E) glue_helper(E) sdhci(E) drm_kms_helper(E) lpc_ich(E) i2c_i801(E) scsi_mod(E) mmc_core(E) usbcore(E) e1000e(E) usb_common(E) drm(E) thermal(E) fan(E) video(E) button(E) ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Haswell-ULT DRAM Controller [8086:0a04] (rev 09) Subsystem: Matsushita Electric Industrial Co., Ltd. Haswell-ULT DRAM Controller [10f7:8338] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: hsw_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Matsushita Electric Industrial Co., Ltd. Haswell-ULT Integrated Graphics Controller [10f7:8338] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:03.0 Audio device [0403]: Intel Corporation Haswell-ULT HD Audio Controller [8086:0a0c] (rev 09) Subsystem: Matsushita Electric Industrial Co., Ltd. Haswell-ULT HD Audio Controller [10f7:8338] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:04.0 Signal processing control
Bug#931243: libvirt0: does not work under cgroup v2 (and rtkit)
Package: libvirt0
Version: 5.0.0-4
Severity: important
Tags: patch upstream
Dear Maintainer,
* libvirt0 tries to add "cpu" controller under the cgroup v2
(a.k.a. unified cgroup hierarchy), which can be enabled by
"systemd.unified_cgroup_hierarchy=1" boot option in /etc/default/grub
* The cpu controller cannot be enabled if there exists a process
with the realtime priority, as stated
WARNING: cgroup2 doesn't yet support control of realtime processes and
the cpu controller can only be enabled when all RT processes are in
the root cgroup. Be aware that system management software may already
have placed RT processes into nonroot cgroups during the system boot
process, and these processes may need to be moved to the root cgroup
before the cpu controller can be enabled.
at https://www.kernel.org/doc/Documentation/cgroup-v2.txt
* If a user installs "pulseaudio", which is true for almost all
desktop environments, then "rtkit" is also installed and
"pulseaudio" runs in the realtime priority.
Under the above situation, when a user runs "virsh" or "virt-manager"
or something like that, he/she gets the error message
Invalid value '+cpu' for 'cgroup.subtree_control': Invalid argument
and cannot use an application relying on libvirt0. It is also
reported at
https://unix.stackexchange.com/questions/525498/libvirt-will-not-start-vms-with-error-invalid-value-cpu-for-cgroup-subtree
Temporary workaround 1: apt-get remove rtkit
Temporary workaround 2: Use the following patch
--- libvirt-5.0.0/src/util/vircgroup.c-orig 2019-06-29 12:57:39.959731576
+0900
+++ libvirt-5.0.0/src/util/vircgroup.c 2019-06-29 12:58:57.858871856 +0900
@@ -1268,6 +1268,7 @@
{
if (virLastErrorIsSystemErrno(ENXIO) ||
virLastErrorIsSystemErrno(EPERM) ||
+ virLastErrorIsSystemErrno(EINVAL) ||
virLastErrorIsSystemErrno(EACCES)) {
virResetLastError();
VIR_DEBUG("No cgroups present/configured/accessible, ignoring error");
A right solution:
An application should not try to enable the cpu controller in
cgroup v2, as instructed at
https://github.com/systemd/systemd/blob/master/docs/CGROUP_DELEGATION.md
So a right solution is to stop touching "cgroup.subtree_control". It is also
discussed in the upstream as
https://github.com/libvirt/libvirt/commit/62dd4d25a2bc5ee33ed22728dc79a5da99906748
Best regards,
Ryutaroh Matsumoto
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8),
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libvirt0 depends on:
ii libacl1 2.2.53-4
ii libapparmor12.13.2-10
ii libaudit1 1:2.8.4-3
pn libavahi-client3
ii libavahi-common30.7-4+b1
ii libc6 2.28-10
ii libcap-ng0 0.7.9-2
ii libcurl3-gnutls 7.64.0-4
ii libdbus-1-3 1.12.16-1
ii libdevmapper1.02.1 2:1.02.155-3
ii libgcc1 1:8.3.0-6
ii libgnutls30 3.6.7-4
ii libnl-3-200 3.4.0-1
ii libnl-route-3-200 3.4.0-1
ii libnuma12.0.12-1
ii libsasl2-2 2.1.27+dfsg-1
ii libselinux1 2.8-1+b1
ii libssh2-1 1.8.0-2.1
ii libxml2 2.9.4+dfsg1-7+b3
ii libyajl22.1.0-3
Versions of packages libvirt0 recommends:
ii lvm2 2.03.02-3
libvirt0 suggests no packages.
-- no debconf information
Bug#930941: texlive-lang-japanese: depends fonts-ipaexfont-mincho while it includes ipaexm.ttf
Package: texlive-lang-japanese Version: 2019.20190605-1 Severity: minor Tags: l10n Dear Maintainer, texlive-lang-japanese package includes /usr/share/texlive/texmf-dist/fonts/truetype/public/ipaex/ipaexm.ttf and depends on fonts-ipaexfont-mincho, which includes /usr/share/fonts/opentype/ipaexfont-mincho/ipaexm.ttf There are overlaps between /usr/share/texlive/texmf-dist/fonts/truetype/public/ipaex and fonts-ipaexfont-gothic fonts-ipaexfont-mincho fonts-ipafont-gothic fonts-ipafont-mincho packages. The above overlap seems a bit logically inconsistent with texlive-fonts-extra-links package. Best regards, Ryutaroh Matsumoto -- Package-specific info: IMPORTANT INFORMATION: We will only consider bug reports concerning the packaging of TeX Live as relevant. If you have problems with combination of packages in a LaTeX document, please consult your local TeX User Group, the comp.text.tex user group, the author of the original .sty file, or any other help resource. In particular, bugs that are related to up-upstream, i.e., neither Debian nor TeX Live (upstream), but the original package authors, will be closed immediately. *** The Debian TeX Team is *not* a LaTeX Help Desk *** If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.minimalbeispiel.de/mini-en.html (english) or http://www.minimalbeispiel.de/mini.html (german) ## minimal input file ## other files ## List of ls-R files -rw-rw-r-- 1 root staff 216 Jun 10 20:30 /usr/local/share/texmf/ls-R -rw-r--r-- 1 root root 2887 Jun 16 12:11 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Feb 28 23:28 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Jun 5 12:18 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Jun 5 12:18 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 475 Mar 19 05:31 /etc/texmf/web2c/texmf.cnf lrwxrwxrwx 1 root root 33 Jun 5 12:18 /usr/share/texmf/web2c/fmtutil.cnf -> /var/lib/texmf/fmtutil.cnf-DEBIAN lrwxrwxrwx 1 root root 32 Jun 5 12:18 /usr/share/texmf/web2c/updmap.cfg -> /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 5089 Jun 16 12:11 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Sep 2 2018 mktex.cnf -rw-r--r-- 1 root root 475 Mar 19 05:31 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages texlive-lang-japanese depends on: ii fonts-ipaexfont-gothic 00401-1 ii fonts-ipaexfont-mincho 00401-1 ii fonts-ipafont-gothic00303-18 ii fonts-ipafont-mincho00303-18 ii ruby1:2.5.1 ii tex-common 6.11 ii texlive-base2019.20190605-1 ii texlive-binaries2019.20190605.51237-1 ii texlive-lang-cjk2019.20190605-1 texlive-lang-japanese recommends no packages. texlive-lang-japanese suggests no packages. Versions of packages tex-common depends on: ii dpkg 1.19.7 ii ucf 3.0038+nmu1 Versions of packages tex-common suggests: ii debhelper 12.1.1 Versions of packages texlive-lang-japanese is related to: ii tex-common6.11 ii texlive-binaries 2019.20190605.51237-1 -- no debconf information
Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr
Hi Hilmar,
Thank you for your suggestion.
I filed "6GB real memory is used by lualatex even with small input"
issue at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930292
It is independent of Japanese localization of lualatex.
Best regards,
Ryutaroh
From: Hilmar Preuße
Subject: Re: Bug#929128: fonts-noto-cjk: not recognized by lualatex until
mktexlsr
Date: Mon, 10 Jun 2019 00:02:00 +0200
> Am 26.05.2019 um 03:52 teilte Ryutaroh Matsumoto mit:
>
> Matsumoto-san,
>
>> You are right. The way to reproduce this issue (not related to
>> mktexlsr)
>> is
>> (1) Install texlive-full and fonts-noto-cjk from experimental.
>> (2) Run lualatex with the below LaTeX source and have error
>> "Package fontspec Error: The font "NotoSerifCJKJPLight" cannot be
>> found."
>> (3) Installation of fonts-noto-cjk-extra fixes the issue even though
>> no font from
>> fonts-noto-cjk-extra is used. XeLaTeX (with
>> \usepackage[noto]{zxjafont}) and
>> uplatex (with \usepackage[unicode,noto-otc]{pxchfon}) produce the
>> desired
>> PDF without fonts-noto-cjk-extra.
>>
> I'm able to process your file using lualatex right now. Then I tried
> to
> process it using uplatex and xelatex and both did not work. I always
> get
> messages like
>
> (/usr/share/texlive/texmf-dist/tex/luatex/luatexja/luatexja.sty
> ! Undefined control sequence.
> l.46 \directlua
>{require('ltj-unicode-ccfix.lua')}% catcode of ideographs
>
> I guess the document class needs luatex. ;-)
>
> Hilmar
> --
> #206401 http://counter.li.org
Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts
Package: texlive-luatex
Version: 2019.20190605-1
Severity: minor
Tags: upstream l10n
Dear Maintainer,
This report contains UTF-8 encoded text in the latex example.
lualatex uses 6 GB of real memory with a small input (see below)
when the Noto CJK fonts used in the first time.
This is an upstream issue, but I file it here by a suggestion
at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929128#61
A procedure to reproduce this is as follows:
1. Install the Noto CJK fonts, e.g. by apt-get install fonts-noto-cjk
fonts-noto-cjk-extra
2. If one has already used the Noto CJK fonts by luatex, clear the cache by rm
-rf $HOME/.texlive201?
3. Process the following file by lualatex
\documentclass{minimal}
\usepackage{fontspec}
\setmainfont{Noto Serif CJK JP}
\setsansfont{Noto Sans CJK JP}
\setmonofont{Noto Sans Mono CJK JP}
\begin{document}
\noindent
{日本語test \bfseries 日本語test}\\
{\sffamily 日本語test \bfseries 日本語test}\\
{\ttfamily 日本語test \bfseries 日本語test}
\end{document}
I believe that the same issue should arise with the Chinese and
the Korean texts, but have not verified it.
Noto CJK Super OTC font (everything is included in the single file)
does not increase the memory usage (= 6GB). Debian Noto CJK package
does not employ super OTC.
Best regards,
Ryutaroh Matsumoto
-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource.
In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.
*** The Debian TeX Team is *not* a LaTeX Help Desk ***
If you report an error when running one of the TeX-related binaries
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.
Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.
Don't forget to also include minimal examples of other files that are
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!
If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at
http://www.minimalbeispiel.de/mini-en.html (english)
or
http://www.minimalbeispiel.de/mini.html (german)
##
minimal input file
##
other files
##
List of ls-R files
-rw-r--r-- 1 root root 2887 Jun 10 12:23 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 28 23:28 /usr/share/texmf/ls-R ->
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Jun 5 12:18 /usr/share/texlive/texmf-dist/ls-R ->
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Jun 5 12:18 /usr/share/texlive/texmf-dist/ls-R ->
/var/lib/texmf/ls-R-TEXLIVEDIST
##
Config files
-rw-r--r-- 1 root root 475 Apr 15 12:58 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Jun 5 12:18 /usr/share/texmf/web2c/fmtutil.cnf ->
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Jun 5 12:18 /usr/share/texmf/web2c/updmap.cfg ->
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5089 Jun 10 12:22
/var/lib/texmf/tex/generic/config/language.dat
##
Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Jan 17 2017 mktex.cnf
-rw-r--r-- 1 root root 475 Apr 15 12:58 texmf.cnf
##
md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8),
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages texlive-luatex depends on:
ii libjs-jquery 3.3.1~dfsg-3
ii tex-common6.11
ii texlive-base 2019.20190605-1
ii texlive-binaries 2019.20190605.51237-1
texlive-luatex recommends no packages.
texlive-luatex suggests no packages.
Versions of packages tex-common depends on:
ii dpkg 1.19.7
ii ucf 3.0038+nmu1
Versions of packages tex-comm
Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr
Hi Hilmar,
thanks for your interest and comment.
It is (in my opinion) a well-known issue among
Japanese LuaLaTeX users, and I can show a even worse
example (for your fun), which needs 6 GB of real RAM
and 10 minutes to compile three lines, in the first time
you process a CJK tex source as below :-)
Please process it by "lualatex" after "rm -rf ~/.texlive201?"
and installing texlive-full and fonts-noto-cjk
and fonts-noto-cjk-extra.
It should produce a PDF document with 7 CJK typefaces.
Once lualatex complies it, the same file is compiled
in much shorter time and much smaller memory.
(So one needs "rm -rf ~/.texlive201?" to see long compilation time.)
I was told that luajitlatex (on Windows) needed even longer
time to compile it :-)
\documentclass[a4paper,12pt]{ltjsarticle}
\usepackage[noto-otf,deluxe]{luatexja-preset}
\begin{document}
\Large\noindent
{\mcfamily \ltseries 細明朝体\\ \mdseries 明朝体\\ \bfseries 太明朝体}\\
{\gtfamily ゴシック体\\ \bfseries 太ゴシック体\\ \ebseries 極太ゴシック体}\\
{\mgfamily 丸ゴシック体}\\
\end{document}
I am a bit reluctant to file the above issue to
texlive-lang-japanese (or texlive-luatex??) because
it does not seem a packaging problem by the Debian TeX team and
they tell us in "reportbug" that
> -- Package-specific info:
> IMPORTANT INFORMATION: We will only consider bug reports concerning
> the packaging of TeX Live as relevant. If you have problems with
> combination of packages in a LaTeX document, please consult your
> local TeX User Group, the comp.text.tex user group, the author of
> the original .sty file, or any other help resource.
>
> In particular, bugs that are related to up-upstream, i.e., neither
> Debian nor TeX Live (upstream), but the original package authors,
> will be closed immediately.
>
>*** The Debian TeX Team is *not* a LaTeX Help Desk ***
Best regards,
Ryutaroh
From: Hilmar Preuße
Subject: Re: Bug#929128: fonts-noto-cjk: not recognized by lualatex until
mktexlsr
Date: Sun, 26 May 2019 17:45:14 +0200
> Am 26.05.2019 um 03:52 teilte Ryutaroh Matsumoto mit:
>
> Matsumoto-san,
>
> I followed your instructions and tried to reproduce some kind of
> issue.
> I compiled your document using TL from experimental; it triggered some
> kind of memory leak in luatex. At least I would not expect that luatex
> needs 1,5 GB of RAM to compile your document:
>
> %Cpu(s): 1.3 us, 47.8 sy, 0.3 ni, 0.0 id, 50.5 wa, 0.0 hi, 0.0 si,
> 0.0 st
> MiB Mem : 938.3 total, 59.5 free, 860.5 used, 18.3 buff/cache
> MiB Swap: 1376.6 total, 295.4 free, 1081.2 used. 21.0 avail Mem
>
> PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+
> COMMAND
> 137 root 0 -20 0 0 0 I 32.2 0.0 0:11.56
> kworker/0+
> 5014 root 20 0 1533540 669688168 D 8.3 69.7 1:13.58
> lualatex
>
> Please file a bug against our package texlive-binaries, version
> 2019.20190507.51032-1 .
>
> Many thanks!
>
> Hilmar
>
>>> Matsumoto-san, I am actually surprised that mktexlsr call fixed it,
>>> since luatex doesn't use ls-R files.
>>> Do you have a way to reproduce this behaviour?
>>
>> You are right. The way to reproduce this issue (not related to
>> mktexlsr)
>> is
>> (1) Install texlive-full and fonts-noto-cjk from experimental.
>> (2) Run lualatex with the below LaTeX source and have error
>> "Package fontspec Error: The font "NotoSerifCJKJPLight" cannot be
>> found."
>> (3) Installation of fonts-noto-cjk-extra fixes the issue even though
>> no font from
>> fonts-noto-cjk-extra is used. XeLaTeX (with
>> \usepackage[noto]{zxjafont}) and
>> uplatex (with \usepackage[unicode,noto-otc]{pxchfon}) produce the
>> desired
>> PDF without fonts-noto-cjk-extra.
>>
>> \documentclass[a4paper,12pt]{ltjsarticle}
>> \usepackage[noto-otf]{luatexja-preset}
>>
>> \begin{document}
>> 日本語
>> \end{document}
>>
>> This seems a feature or a bug in TeXLive 2019 upstream, which should
>> not have
>> been filed in BTS. So I close this issue.
>>
>
>
> --
> #206401 http://counter.li.org
Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr
Hi Hideki, thanks for your kind comment. My understanding is that it is related to luatexja-preset.sty (or Japanese localization of LuaLaTeX). When we run the "report-bug" against a tex package, it tells us that > -- Package-specific info: > IMPORTANT INFORMATION: We will only consider bug reports concerning > the packaging of TeX Live as relevant. If you have problems with > combination of packages in a LaTeX document, please consult your > local TeX User Group, the comp.text.tex user group, the author of > the original .sty file, or any other help resource. > > In particular, bugs that are related to up-upstream, i.e., neither > Debian nor TeX Live (upstream), but the original package authors, > will be closed immediately. > >*** The Debian TeX Team is *not* a LaTeX Help Desk *** So, provided that the issue is in luatexja-preset.sty, the Debian TeX team may unwelcome it... Is it OK to reopen it (and maybe reassign it to texlive-lang-japanese)? If I understand the issue correctly, the problem is that * lualatex + luatexja-preset.sty requires "NotoSerifCJKJPLight" even when "NotoSerifCJKJPLight" font is not used in a document, while uplatex or xelatex (with their localizations files) does not require "NotoSerifCJKJPLight" unless it is used. But the above behavior seems a kind of "design"... And a solution can be inclusion of all CJK font files into "fonts-noto-cjk", which suggests that this issue should be filed against "fonts-noto-cjk". Your feedbacks are welcome. Ryutaroh From: Hideki Yamane Subject: Re: Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr Date: Sun, 26 May 2019 16:08:15 +0900 > Hi, > > On Sun, 26 May 2019 10:52:36 +0900 > Ryutaroh Matsumoto wrote: >> Sorry again for bothering all of you > > To be clear, it's _nothing_ wrong with you, IMHO. > Maybe it's better to reopen and reassign to appropriate texlive package > with "upstream" tag. > > -- > Regards, > > Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#929558: texlive-fonts-extra: STIX2 fonts cannot called by their font names by xelatex & fontspec.sty
Package: texlive-fonts-extra
Version: 2019.20190508-1
Severity: minor
Dear Maintainer,
STIX2Text-Regular.otf in texlive-fonts-extra and
texgyretermes-regular.otf in fonts-texgyre
both come from TeXLive.
TeX Gyre can be called by their font names in xelatex+fontspec as
\documentclass{minimal}
\usepackage{fontspec}
\setmainfont{TeX Gyre Termes}
\begin{document}
test.
\end{document}
On the other hand,
\setmainfont{STIX Two Text} % This causes an error.
\setmainfont{STIX2Text-Regular.otf} %This is accepted by XeLaTeX.
The difference between two fonts arises from the installed
locations by Debian.
Besides, the version 1 of STIX fonts is packaged in "fonts-stix",
and outside of /usr/share/texmf and /usr/share/texlive.
If the above behavior is a design or a feature,
that's fine with me.
Best regards,
Ryutaroh
-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource.
In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.
*** The Debian TeX Team is *not* a LaTeX Help Desk ***
If you report an error when running one of the TeX-related binaries
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.
Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.
Don't forget to also include minimal examples of other files that are
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!
If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at
http://www.minimalbeispiel.de/mini-en.html (english)
or
http://www.minimalbeispiel.de/mini.html (german)
##
minimal input file
##
other files
##
List of ls-R files
-rw-rw-r-- 1 root staff 80 May 26 10:24 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 2886 May 26 10:24 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 28 23:28 /usr/share/texmf/ls-R ->
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 May 8 15:32 /usr/share/texlive/texmf-dist/ls-R ->
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 May 8 15:32 /usr/share/texlive/texmf-dist/ls-R ->
/var/lib/texmf/ls-R-TEXLIVEDIST
##
Config files
-rw-r--r-- 1 root root 475 Mar 19 05:31 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 May 8 15:32 /usr/share/texmf/web2c/fmtutil.cnf ->
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 May 8 15:32 /usr/share/texmf/web2c/updmap.cfg ->
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5054 May 18 18:50
/var/lib/texmf/tex/generic/config/language.dat
##
Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Sep 2 2018 mktex.cnf
-rw-r--r-- 1 root root 475 Mar 19 05:31 texmf.cnf
##
md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8),
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages texlive-fonts-extra depends on:
ii tex-common6.11
ii texlive-base 2019.20190508-1
Versions of packages texlive-fonts-extra recommends:
ii fonts-adf-accanthis0.20110505-3
ii fonts-adf-berenis 0.20110505-3
ii fonts-adf-gillius 0.20110505-3
ii fonts-adf-universalis 0.20110505-3
ii fonts-cabin1.5-2
ii fonts-comfortaa3.001-2
ii fonts-croscore 20181227-1
ii fonts-crosextra-caladea20130214-2
ii fonts-crosextra-carlito20130920-1
ii fonts-dejavu-core 2.37-1
ii fonts-dejavu-extra 2.37-1
ii fonts-ebgaramond 0.016-1
ii fonts-ebgaramond-extra 0.016-1
ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-1
Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr
>> mktexlsr in installation of a font package is executed >> as a trigger to tex-common as we often see >> "Processing triggers for tex-common", if I understand it >> correctly. > > How is this triggered? For the case of "fonts-ipaex-mincho", "apt-get install texlive-full" installs "fonts-ipaex-mincho" and "texlive-fonts-recommended" by the dependency. Then the "postinst" in "texlive-fonts-recommended" runs "update-texmf-config map", which in turn runs "mktexlsr". That's my understanding. Ryutaroh From: Hideki Yamane Subject: Re: Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr Date: Fri, 24 May 2019 14:04:31 +0900 > Hi, > > On Fri, 24 May 2019 13:15:46 +0900 (JST) > Ryutaroh Matsumoto wrote: >> "postinst" scripts are very different between >> fonts-ipaexfont-mincho and fonts-noto-cjk. > > Yes, but it's for obsolete config and alternatives. > > >> mktexlsr in installation of a font package is executed >> as a trigger to tex-common as we often see >> "Processing triggers for tex-common", if I understand it >> correctly. > > How is this triggered? > > > -- > Hideki Yamane
Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr
Hi Hideki, > Isn't it a issue on mktexlsr, instead of fonts? mktexlsr in installation of a font package is executed as a trigger to tex-common as we often see "Processing triggers for tex-common", if I understand it correctly. fonts-ipaexfont-mincho package installs its fonts to /usr/share/fonts/opentype, and the font file is recognized by uplatex and lualatex after its installation. "postinst" scripts are very different between fonts-ipaexfont-mincho and fonts-noto-cjk. My guess is that mimicing fonts-ipaexfont-mincho in the postinst of fonts-noto-cjk addresses this issue. If my guess is correct, fonts-noto-cjk-extra should also have the same issue. Ryutaroh From: Hideki Yamane Subject: Re: Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr Date: Fri, 24 May 2019 11:59:24 +0900 > Hi, > > On Fri, 17 May 2019 23:53:05 +0900 > Ryutaroh Matsumoto wrote: >> I suggest to execute mktexlsr in the installation of fonts-noto-cjk >> if mktexlsr is installed. > > Isn't it a issue on mktexlsr, instead of fonts? > > > -- > Hideki Yamane
Bug#929163: fonts-noto: should depends all noto font packages.
Package: fonts-noto Version: 20181227-1 Severity: important The package description states "Use this package if you want all Noto fonts". But if one puts "APT::Install-Recommends 0;" in /etc/apt/apt.conf, some noto fonts, namely fonts-noto-cjk fonts-noto-cjk-extra fonts-noto-color-emoji fonts-noto-extra fonts-noto-mono fonts-noto-ui-core fonts-noto-ui-extra fonts-noto-unhinted are not installed. They should be depended instead of recommended. -- Package-specific info: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii fontconfig 2.13.1-2 amd64generic font configuration library - support binaries ii libfreetype6:amd64 2.9.1-3 amd64FreeType 2 font engine, shared library files ii libxft2:amd64 2.3.2-2 amd64FreeType-based font drawing library for X -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fonts-noto depends on: ii fonts-noto-core 20181227-1 Versions of packages fonts-noto recommends: ii fonts-noto-cjk 1:20181130+repack1-1~exp1 ii fonts-noto-cjk-extra1:20181130+repack1-1~exp1 ii fonts-noto-color-emoji 0~20180810-1 ii fonts-noto-extra20181227-1 ii fonts-noto-mono 20181227-1 ii fonts-noto-ui-core 20181227-1 ii fonts-noto-ui-extra 20181227-1 ii fonts-noto-unhinted 20181227-1 fonts-noto suggests no packages. -- no debconf information
Bug#929156: texlive-lang-japanese: should recommend/suggest fonts-noto-cjk-extra
Package: texlive-lang-japanese
Version: 2019.20190508-1
Severity: minor
Tags: l10n
Dear Maintainer,
texlive-lang-japanese depends on
fonts-ipaexfont-mincho, fonts-ipafont-mincho, and so on.
The reason of the dependency may be that luatexja-preset.sty uses
the IPA fonts as its default Japanese fonts.
By a similar reason, I propose for texlive-lang-japanese to
recommend or suggest fonts-noto-cjk-extra.
For example, by the following style files bundled in texlive-lang-japanese,
one can use \mgfamily, \ltseries and \ebseries in the Noto CJK fonts
(full tex example and its generated PDF are attached by -A option of
"reportbug").
% Process this by uplatex and dvipdfmx
\documentclass[uplatex,a4paper,12pt]{jsarticle}
\usepackage[deluxe]{otf}
\usepackage[unicode,noto-otc]{pxchfon}
I reported a related but independent issue against fonts-noto-cjk
as #929128
-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource.
In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.
*** The Debian TeX Team is *not* a LaTeX Help Desk ***
If you report an error when running one of the TeX-related binaries
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.
Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.
Don't forget to also include minimal examples of other files that are
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!
If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at
http://www.minimalbeispiel.de/mini-en.html (english)
or
http://www.minimalbeispiel.de/mini.html (german)
##
minimal input file
##
other files
##
List of ls-R files
-rw-rw-r-- 1 root staff 80 May 17 20:32 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 2887 May 18 18:51 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 28 23:28 /usr/share/texmf/ls-R ->
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 May 8 15:32 /usr/share/texlive/texmf-dist/ls-R ->
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 May 8 15:32 /usr/share/texlive/texmf-dist/ls-R ->
/var/lib/texmf/ls-R-TEXLIVEDIST
##
Config files
-rw-r--r-- 1 root root 475 Mar 19 05:31 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 May 8 15:32 /usr/share/texmf/web2c/fmtutil.cnf ->
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 May 8 15:32 /usr/share/texmf/web2c/updmap.cfg ->
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5054 May 18 18:50
/var/lib/texmf/tex/generic/config/language.dat
##
Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Sep 2 2018 mktex.cnf
-rw-r--r-- 1 root root 475 Mar 19 05:31 texmf.cnf
##
md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8),
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages texlive-lang-japanese depends on:
ii fonts-ipaexfont-gothic 00401-1
ii fonts-ipaexfont-mincho 00401-1
ii fonts-ipafont-gothic00303-18
ii fonts-ipafont-mincho00303-18
ii ruby1:2.5.1
ii tex-common 6.11
ii texlive-base2019.20190508-1
ii texlive-binaries2019.20190507.51032-1
ii texlive-lang-cjk2019.20190508-1
texlive-lang-japanese recommends no packages.
texlive-lang-japanese suggests no packages.
Versions of packages tex-common depends on:
ii dpkg 1.19.6
ii ucf 3.0038+nmu1
Versions of packages tex-common suggests:
ii debhelper 12.1.1
Versions of packages texlive-lang-japanese is related to:
ii tex-common6.11
ii texlive-binaries
Bug#929128: fonts-noto-cjk: not recognized by lualatex until mktexlsr
Package: fonts-noto-cjk Version: 1:20181130+repack1-1~exp1 Severity: normal Dear Maintainer, Font Noto CJK can be used by lualatex (in texlive-latex-base). But lualatex does not recognize the Noto fonts until one executes mktexlsr. I suggest to execute mktexlsr in the installation of fonts-noto-cjk if mktexlsr is installed. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled fonts-noto-cjk depends on no packages. fonts-noto-cjk recommends no packages. Versions of packages fonts-noto-cjk suggests: ii fonts-noto-cjk-extra 1:20181130+repack1-1~exp1 -- no debconf information
Bug#905001: ibus-wayland always fails on weston with "No input_method global"
Package: ibus-wayland Version: 1.5.18-1 Severity: grave Tags: upstream Justification: renders package unusable Control: forwarded -1 https://github.com/ibus/ibus/issues/2030 Dear Maintainer, ibus-wayland always 100% fails with the error message "No input_method global" when used with the weston Debian package. As such, the ibus-wayland Debian package is COMPLETELY USELESS. I suggest removal of ibus-wayland package, unless the upstream fixes this. This is a bug in upstream. I already reported this to https://github.com/ibus/ibus/issues/2030 See the upstream bug report for the root cause of this. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ibus-wayland depends on: ii libc6 2.27-5 ii libglib2.0-02.56.1-2 ii libibus-1.0-5 1.5.18-1 ii libwayland-client0 1.15.0-2 ii libxkbcommon0 0.8.0-2 ibus-wayland recommends no packages. ibus-wayland suggests no packages. -- no debconf information
Bug#903011: please consider non-disruptive workaround,Re: Bug#903011: please consider non-disruptive workaround
Dear Michael, > Let's give upstream a bit more time to address this. They have lots of > bug reports to deal with and I'm a bit wary to apply a workaround I see. Thank you for your consideration. Best regards, Ryutaroh
Bug#903011: please consider non-disruptive workaround
Dear Debian systemd maintainers, CC: Michael, This debian bug #903011 seems rather severe to me as this makes all the per-user resource control unusable as reported to the upstream at https://github.com/systemd/systemd/issues/9502 https://github.com/systemd/systemd/issues/9512 https://github.com/systemd/systemd/issues/9578 and the upstream maintainers do not seem eager to address this bug, though the upstream report 9512 received "bug" and "v240 milestone" tags, while 9502 and 9578 keep "needs-reporter-feedback" tag despite sufficient feedbacks. There is a non-disruptive workaround for this bug, and it prevents all of the upstream bugs 9502, 9512 and 9578 above: (1) Make the following file as /lib/systemd/system/user-nonexistent.slice [Unit] Description=Dummy Slice for working around the bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903011 Documentation=https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903011 Before=systemd-user-sessions.service systemd-logind.service [Slice] Slice=user.slice [Install] WantedBy=multi-user.target (2) Run systemctl enable user-nonexistent.slice If the debian systemd maintainers (A) regard this group of three upstream bugs as severe, and (B) confirm that the above workaround works as expected and is non-disruptive, I would appreciate it if you consider incorporating the above workaround until the real cause is fixed in the upstream. Best regards, Ryutaroh Matsumoto
Bug#904393: qemu-kvm: CLOCK_MONOTONIC jumps during suspend of the host Linux
Package: qemu-kvm Version: 1:2.12+dfsg-3 Severity: normal Dear Maintainer, CLOCK_MONOTONIC should not jump during sleep, according to the systemd developer https://github.com/systemd/systemd/issues/9538#issuecomment-405901335 When the host Linux is supended by "systemctl suspend", CLOCK_MONOTONIC of the host does not include the time during suspend and does not jump, but CLOCK_MONOTONIC in the linux running on qemu-kvm jumps, as follows: root@debian-unstable:/var/tmp# while true; do python3 -c "import time; print(time.monotonic())"; sleep 100; done 19938.840492947 20038.868252082 20138.894991601 20238.91993227 20338.948723988 20995.602910365 This leads to loss of systemd-journald logs as described in https://github.com/systemd/systemd/issues/9538 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qemu-kvm depends on: ii qemu-system-x86 1:2.12+dfsg-3 qemu-kvm recommends no packages. qemu-kvm suggests no packages. -- no debconf information
Bug#904335: fixed in upstream
Control: tags -1 + fixed-upstream According to https://github.com/systemd/systemd/issues/9702#issuecomment-407144025 this is fixed in the upstream. Ryutaroh
Bug#904335: forwarded to the upstream
Control: forwarded -1 https://github.com/systemd/systemd/issues/9702 Control: tags -1 + upstream
Bug#903288: change of the upstream bug report
Control: tags -1 - fixed-upstream Control: notforwarded -1 Control: forwarded -1 https://github.com/systemd/systemd/issues/2809 Update the upstream forwarded URI so that bts-link does the right thing. Ryutaroh
Bug#903011: two related bugs at the upstream
Control: tags -1 + upstream Control: found -1 239-5 I confirm that this bug 903011 still exists in 239-5. Two other bugs reported at the upstream https://github.com/systemd/systemd/issues/9502 https://github.com/systemd/systemd/issues/9578 probably have the same cause because the same workaround https://github.com/systemd/systemd/issues/9512#issuecomment-404270548 prevents all of them. Ryutaroh
Bug#903011: Workaround to bug 903011
Control: tags -1 + patch I posted a workaround to the upstream as https://github.com/systemd/systemd/issues/9512#issuecomment-404270548 I do not think it is a right approach. Ryutaroh
Bug#903265: systemd-container: --property=Delegate=... does not work with systemd-nspawn,Re: Bug#903265: systemd-container: --property=Delegate=... does not work with systemd-nspawn
Control: retitle -1 systemd: outputs confusing '-.slice: Failed to set cpu.max: Operation not permitted' in systemd-nspawn container Control: reassign -1 systemd 239-5 In a systemd-nspawn container, cpu.weight, cpu.max, io.weight, memory.low, memory.high, memory.max, pids.max cannot be written by the container root privilege. It is a normal situation (I misunderstood it when I originally filed this bug report). On the other hand, systemd 239 tries to write values to the above files at its boot time even in a container. When systemd 239 is booted in a systemd-nspawn container, it outputs the following error message. But the systemd is only complaining against a normal and expected situation. I believe that the following messages are simply useless and can be safely ignored if systemd is started as PID 1 in a systemd container. -.slice: Failed to set cpu.weight: Operation not permitted -.slice: Failed to set cpu.max: Operation not permitted -.slice: Failed to set io.weight: Operation not permitted -.slice: Failed to set memory.low: Operation not permitted -.slice: Failed to set memory.high: Operation not permitted -.slice: Failed to set memory.max: Operation not permitted -.slice: Failed to set pids.max: Operation not permitted Ryutaroh
Bug#903265: systemd-container: --property=Delegate=... does not work with systemd-nspawn,Re: Bug#903265: systemd-container: --property=Delegate=... does not work with systemd-nspawn
Control: severity -1 minor Control: tags -1 + upstream In light of https://github.com/systemd/systemd/issues/9539#issuecomment-404008050 I believe that this bug is of minor severity. Ryutaroh
Bug#903288: systemd-container: container does not reboot when it is started by machinectl or systemctl,Re: Bug#903288: systemd-container: container does not reboot when it is started by machinectl or
Control: tags -1 + upstream It turns out to be an upsteam bug standing for two years... https://github.com/systemd/systemd/issues/9540#issuecomment-403342632
Bug#903288: systemd-container: container does not reboot when it is started by machinectl or systemctl,Re: Bug#903288: systemd-container: container does not reboot when it is started by machinectl or
Control: forwarded -1 https://github.com/systemd/systemd/issues/9540 Hi Michael, Thanks for your quick response. I reported this to the upstream as above. Ryutaroh From: Michael Biebl Date: Sun, 8 Jul 2018 19:28:08 +0200 > We don't really ship any Debian specific patches in that regard, so it > would be great if you can file this upstream.
Bug#903265: systemd-container: --property=Delegate=... does not work with systemd-nspawn,Re: Bug#903265: systemd-container: --property=Delegate=... does not work with systemd-nspawn
Control: forwarded -1 https://github.com/systemd/systemd/issues/9539 Hi Michael, Thanks for your quick response. I reported this to the upstream as above. Ryutaroh From: Michael Biebl Date: Sun, 8 Jul 2018 19:29:52 +0200 > Try with apparmor disabled (apparmor=0 on the kernel command line) and > with kernel 4.16. If it still fails, I would report it upstream.
Bug#903288: systemd-container: container does not reboot when it is started by machinectl or systemctl
Package: systemd-container Version: 239-5 Severity: normal A systemd-nspawn container does not reboot if it is started by machinectl or systemctl on the host Linux. The key error messages are Jul 08 21:17:17 unstable systemd[1]: Starting Container container-unstable... Jul 08 21:17:17 unstable systemd-nspawn[943]: Failed to register machine: Machine 'container-unstable' already exists Jul 08 21:17:17 unstable systemd[1]: systemd-nspawn@container-unstable.service: Main process exited, code=exited, status=1/FAILURE Jul 08 21:17:17 unstable systemd[1]: systemd-nspawn@container-unstable.service: Failed with result 'exit-code'. Jul 08 21:17:17 unstable systemd[1]: Failed to start Container container-unstable. Jul 08 21:17:17 unstable systemd[1]: systemd-nspawn@container-unstable.service: Consumed 31ms CPU time, received 0B IP traffic, sent 0B IP traffic If I start it as systemd-nspawn -b -M container-unstable --network-ipvlan=wls3 then "systemctl reboot" inside the container works as expected. So, I believe that this issue is different from the archived one https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900956 The below is transcript to reproduce the above: root@unstable:/var/tmp# machinectl start container-unstable root@unstable:/var/tmp# machinectl list MACHINECLASS SERVICEOS VERSION ADDRESSES container-desktop container systemd-nspawn - - 192.168.1.131 container-unstable container systemd-nspawn - - 192.168.1.130 2 machines listed. root@unstable:/var/tmp# ssh -l root 192.168.1.130 root@192.168.1.130's password: Linux container-unstable 4.17.0-1-amd64 #1 SMP Debian 4.17.3-1 (2018-07-02) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sun Jul 8 21:13:16 2018 from 192.168.1.129 root@container-unstable:~# systemctl reboot Connection to 192.168.1.130 closed by remote host. Connection to 192.168.1.130 closed. root@unstable:/var/tmp# machinectl list MACHINE CLASS SERVICEOS VERSION ADDRESSES container-desktop container systemd-nspawn - - 192.168.1.131 1 machines listed. root@unstable:/var/tmp# journalctl -n 20 -u systemd-nspawn@container-unstable --no-pager -- Logs begin at Sun 2018-07-08 21:06:44 JST, end at Sun 2018-07-08 21:17:17 JST. -- Jul 08 21:17:15 unstable systemd-nspawn[867]: [FAILED] Failed unmounting /tmp. Jul 08 21:17:15 unstable systemd-nspawn[867]: [ OK ] Unmounted /run/systemd/nspawn/incoming. Jul 08 21:17:15 unstable systemd-nspawn[867]: [ OK ] Reached target Unmount All Filesystems. Jul 08 21:17:15 unstable systemd-nspawn[867]: [ OK ] Stopped target Local File Systems (Pre). Jul 08 21:17:15 unstable systemd-nspawn[867]: [ OK ] Stopped Remount Root and Kernel File Systems. Jul 08 21:17:15 unstable systemd-nspawn[867]: [ OK ] Stopped target Swap. Jul 08 21:17:15 unstable systemd-nspawn[867]: [ OK ] Reached target Shutdown. Jul 08 21:17:15 unstable systemd-nspawn[867]: [ OK ] Reached target Final Step. Jul 08 21:17:15 unstable systemd-nspawn[867]: Starting Reboot... Jul 08 21:17:17 unstable systemd[1]: systemd-nspawn@container-unstable.service: Consumed 1.083s CPU time, received 13.1K IP traffic, sent 8.5K IP traffic Jul 08 21:17:17 unstable systemd[1]: systemd-nspawn@container-unstable.service: Service RestartSec=100ms expired, scheduling restart. Jul 08 21:17:17 unstable systemd[1]: systemd-nspawn@container-unstable.service: Scheduled restart job, restart counter is at 1. Jul 08 21:17:17 unstable systemd[1]: Stopped Container container-unstable. Jul 08 21:17:17 unstable systemd[1]: systemd-nspawn@container-unstable.service: Consumed 1.083s CPU time, received 13.1K IP traffic, sent 8.5K IP traffic Jul 08 21:17:17 unstable systemd[1]: Starting Container container-unstable... Jul 08 21:17:17 unstable systemd-nspawn[943]: Failed to register machine: Machine 'container-unstable' already exists Jul 08 21:17:17 unstable systemd[1]: systemd-nspawn@container-unstable.service: Main process exited, code=exited, status=1/FAILURE Jul 08 21:17:17 unstable systemd[1]: systemd-nspawn@container-unstable.service: Failed with result 'exit-code'. Jul 08 21:17:17 unstable systemd[1]: Failed to start Container container-unstable. Jul 08 21:17:17 unstable systemd[1]: systemd-nspawn@container-unstable.service: Consumed 31ms CPU time, received 0B IP traffic, sent 0B IP traffic root@unstable:/var/tmp# exit exit Script done on 2018-07-08 21:18:58+09:00 -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.17.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh
Bug#903265: systemd-container: --property=Delegate=... does not work with systemd-nspawn
Package: systemd-container Version: 239-5 Severity: normal Dear Maintainer, According to the manual page, --property=Delegate=... with systemd-nspawn should let the executed container to have access to "...", but it does not work as documented with the newest Debian package (and possibly with the upstream?). I wonder if it is a problem with Linux 4.17.0-1-amd64 installed from Debian experimental, or AppArmor... So I first report this to Debian BTS. I also wonder if this behavior and #903011 are just two different symptoms arising from the single root cause. Specifically, when I executed the command systemd-nspawn -b -M container-unstable --network-ipvlan=wls3 --property="Delegate=memory pids cpu io" I see the below. Please note that the CGroup V2 is used with systemd, i.e., systemd.unified_cgroup_hierarcy=1 is given to the kernel command line. Spawning container container-unstable on /var/lib/machines/container-unstable. Press ^] three times within 1s to kill container. systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid) Detected virtualization systemd-nspawn. Detected architecture x86-64. Welcome to Debian GNU/Linux buster/sid Set hostname to . File /lib/systemd/system/systemd-journald.service:36 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling. Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.) -.slice: Failed to set cpu.weight: Operation not permitted -.slice: Failed to set cpu.max: Operation not permitted -.slice: Failed to set io.weight: Operation not permitted -.slice: Failed to set memory.low: Operation not permitted -.slice: Failed to set memory.high: Operation not permitted -.slice: Failed to set memory.max: Operation not permitted -.slice: Failed to set pids.max: Operation not permitted (The above messages show the problem, and many lines are deleted here) [ OK ] Started Update UTMP about System Runlevel Changes. Debian GNU/Linux buster/sid container-unstable console container-unstable login: root Password: Last login: Sun Jul 8 18:08:54 JST 2018 on console Linux container-unstable 4.17.0-1-amd64 #1 SMP Debian 4.17.3-1 (2018-07-02) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. root@container-unstable:~# cd /sys/fs/cgroup/ Here I moved to the root CGroup V2 hirarachy. root@container-unstable:/sys/fs/cgroup# ls -l total 0 -r--r--r-- 1 root root 0 Jul 8 18:26 cgroup.controllers -r--r--r-- 1 root root 0 Jul 8 18:26 cgroup.events -rw-r--r-- 1 root root 0 Jul 8 18:27 cgroup.max.depth -rw-r--r-- 1 root root 0 Jul 8 18:27 cgroup.max.descendants -rw-r--r-- 1 root root 0 Jul 8 18:26 cgroup.procs -r--r--r-- 1 root root 0 Jul 8 18:26 cgroup.stat -rw-r--r-- 1 root root 0 Jul 8 18:26 cgroup.subtree_control -rw-r--r-- 1 root root 0 Jul 8 18:26 cgroup.threads -rw-r--r-- 1 root root 0 Jul 8 18:27 cgroup.type -rw-r--r-- 1 root root 0 Jul 8 18:26 cpu.max -r--r--r-- 1 root root 0 Jul 8 18:27 cpu.stat -rw-r--r-- 1 root root 0 Jul 8 18:26 cpu.weight -rw-r--r-- 1 root root 0 Jul 8 18:27 cpu.weight.nice drwxr-xr-x 2 root root 0 Jul 8 18:26 init.scope -rw-r--r-- 1 root root 0 Jul 8 18:27 io.max -r--r--r-- 1 root root 0 Jul 8 18:27 io.stat -rw-r--r-- 1 root root 0 Jul 8 18:26 io.weight -r--r--r-- 1 root root 0 Jul 8 18:27 memory.current -r--r--r-- 1 root root 0 Jul 8 18:27 memory.events -rw-r--r-- 1 root root 0 Jul 8 18:26 memory.high -rw-r--r-- 1 root root 0 Jul 8 18:26 memory.low -rw-r--r-- 1 root root 0 Jul 8 18:26 memory.max -r--r--r-- 1 root root 0 Jul 8 18:27 memory.stat -r--r--r-- 1 root root 0 Jul 8 18:27 pids.current -r--r--r-- 1 root root 0 Jul 8 18:27 pids.events -rw-r--r-- 1 root root 0 Jul 8 18:26 pids.max drwxr-xr-x 13 root root 0 Jul 8 18:26 system.slice drwxr-xr-x 3 root root 0 Jul 8 18:26 user.slice I see that I have (as root) write permission to the relevant files above. BUT I cannot write values to the relevant files: root@container-unstable:/sys/fs/cgroup# echo 1000 >pids.max -bash: echo: write error: Operation not permitted root@container-unstable:/sys/fs/cgroup# echo 3G >memory.high -bash: echo: write error: Operation not permitted When I executed the above command, I checked the Delegation status of the container from another console, and I got: ryutaroh@unstable:~$ systemctl show systemd-nspawn@container-unstable.service | grep Delegate Delegate=yes DelegateControllers=cpu io memory pids Systemd also thinks that it delegates the requested permissions... -- System Information: Debian
Bug#903025: It is a feature of kernel
Control: tags -1 + confirmed It was closed as a GitHub issue at the upstream as: https://github.com/systemd/systemd/issues/9513#issuecomment-403225211 The reason is "This is a feature of the current Linux kernel". I am not sure if we should file a report to the kernel package, or add "upstream", "wontfix" tags to this. Best regards, Ryutaroh
Bug#903144: iproute2: ip-link(8) manual page does not explain options for ipvlan
Package: iproute2 Version: 4.17.0-2 Severity: minor Dear Maintainer, When we add ipvlan to a physical interface, like /sbin/ip link add link wls3 name ipvlan1 type ipvlan mode l2 bridge we can also add options like "l2", "bridge", etc. Those options are not explained in ip-link(8) manual page. They are explained at https://www.kernel.org/doc/Documentation/networking/ipvlan.txt -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages iproute2 depends on: ii debconf [debconf-2.0] 1.5.67 ii libc6 2.27-3 ii libcap21:2.25-1.2 ii libcap2-bin1:2.25-1.2 ii libdb5.3 5.3.28-13.1+b1 ii libelf10.170-0.5 ii libmnl01.0.4-2 ii libselinux12.8-1+b1 ii libxtables12 1.6.2-1 Versions of packages iproute2 recommends: pn libatm1 Versions of packages iproute2 suggests: pn iproute2-doc -- debconf information: iproute2/setcaps: false
