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
s 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
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
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",
Control: forwarded -1 https://github.com/systemd/systemd/issues/9702
Control: tags -1 + upstream
Control: tags -1 + fixed-upstream
According to
https://github.com/systemd/systemd/issues/9702#issuecomment-407144025
this is fixed in the upstream.
Ryutaroh
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
>
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
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
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
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
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
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.
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",
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
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
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
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
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
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}
", 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,
e 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 teilt
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
t: 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)
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
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
'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:
>> "post
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 +
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
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
/cpu.conf
[Service]
CPUQuota=1%
Now everything works as expected in my environment!
Ryutaroh Matsumoto
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
hould 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/com
42.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.debi
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] Oop
Control: forwarded -1 https://bugs.launchpad.net/snappy/+bug/1839709
Control: tags -1 + upstream
/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
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
]
[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/sh
/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
/mozilla/twemoji-colr
Ryutaroh Matsumoto
.
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
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
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)
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
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-amd6
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
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
0292: 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/i
/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
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
://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
-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
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
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
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
ux package.
Best regards,
Ryutaroh Matsumoto
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
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
ut 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
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
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
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
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
: 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
f 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
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
Control: tags -1 + fixed - moreinfo
Control: retitle -1 Fix found: systemd-sysusers hangs if nis is
enabled in a systemd-nspawn container
I found a solution (or a workaround).
The problem is that
(1) systemd-sysusers tries to use Sun RPC (TCP connection to 127.0.0.1:111)
in a nis enabled
thunderbird
texlive-fonts-extra
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
, 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
Hi Michael,
Thank you for paying attention to this.
> Do you have users/groups defined in
> /usr/lib/sysusers.d/ or /etc/sysusers.d which are only resolvable via NIS?
The above directories are untouched. The container was made by
mmdebstrap --variant=debootstrap bullseye.
/etc/passwd nor
> Do you have nscd installed inside the container (looking at the strace
> it appears you might have not).
I installed "unscd" instead of "nscd", as "unscd" is said to be less buggy.
> Is nscd installed outside of the container where you don't see the problem?
The host running container also
The container is started as
systemd-nspawn -M bullseye --network-macvlan=eno1 -b
The option --network-macvlan=eno1 is necessary so that the container
can talk with the NIS server running on a third computer (not a container
nor the host running the container).
Ryutaroh
From: Ryutaroh Matsumoto
oid your
misunderstanding.
Ryutaroh
From: Norbert Preining
Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK
fonts
Date: Sat, 15 Feb 2020 12:27:27 +0900
> On Sat, 15 Feb 2020, Ryutaroh Matsumoto wrote:
>> This is LuaHBTeX, Version 1.11.2 (TeX L
>> I know. It was by lualatex-dev in TeXLive 2019 as of 14 Februrary.
>
> Within the next 2 months or so TeX Live 2020 pretest will be uploaded,
> which will contain luahbtex and all the required changes.
As you know, lualatex-dev in TeXlive 2019 (after Nov. 2019)
will almost the same as
> Your best bet is bringing this up to the luatex-dev mailing list, not
> here in Debian, because we will surely not patch anything of that
> dimension.
I agree. Actually, this Debian bug already has "upstream" tag and
marked "forwarded" to https://github.com/u-fischer/luaotfload/issues/49
I
> luahbtex should behave better, right, if the font is loaded with the
> harf renderer selected?
Ah, you seems right. But, when I added [RawFeature={mode=harf}] to
the example given at the beginning of this report and processed the file
with lualatex-dev in TeXLive 2019 of February 14, the memory
I prepared a qemu-x86-64 disk image that can reproduce this symptom at
https://drive.google.com/drive/folders/1ObSUu3DCF2r4tzcGrykhBCRpPSemHNiu
After logging in as root with password root,
systemd-nspawn -M container1 -n -b
reproduces the symptom, that is,
/bin/systemd-sysusers talks with
From: Michael Biebl
Date: Sun, 9 Feb 2020 08:53:33 +0100
> Not sure what the right solution is. One might be, that the nis NSS
> module handles this situation (rpcbind.socket running, rpcbind.service
> not running) better, or that rpcbind.socket changes its ordering to
> avoid this situation.
>
Hi Nobert, my email last week was incorrect.
> luahbtex should behave better, right, if the font is loaded with the
> harf renderer selected?
Actually, mode=harf with luaotfload 3.12 uses only 0.3 GB, but
\setmainfont in fontspec.sty somehow uses 2 GB...
It was reported at
By luaotfload 3.12 and
This is LuaHBTeX, Version 1.11.2 (TeX Live 2020/dev)
the memory consumption is 2 GB,
by texlive 15 February 2020.
Ryutaroh
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
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
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
/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
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
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
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 ...
st 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
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.
Be
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
cgroupv2 related LXC bugs in
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-systemd-maintain...@lists.alioth.debian.org;tag=cgroupv2
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable
ub.com/lxc/lxc/issues/3371
but I am unsure. So I do not attach the upstream tag.
I do not think this is related to pure CGroupV2.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'exp
observed on the hybrid cgroup hierarchy, and seems
independent of Debian Bug #947335
The Debian version of the criu package is
criu3.13-7
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'
The reported issue #958158 is not observed in
LXC 4.0.2 on Ubuntu 20.04.
So I wonder if this is an upstream issue or Debian specific.
Ryutaroh
localed-x11-keymap PASS
logind PASS
unit-config PASS
networkd-test.py PASS
build-login PASS
boot-and-servicesPASS
udev PASS
root-unittests PASS
boot-smoke PASS
Best regards, Ryutaroh Matsumoto
> Do you have any idea what's going wrong?
At the end of your attached log, we have
lxc-start autopkgtest-sid 20200421123647.929 NOTICE start -
start.c:start:2041 - Exec'ing "/sbin/init"
lxc-start autopkgtest-sid 20200421123647.929 NOTICE start -
start.c:post_start:2052 - Started
bin" = "/usr/bin/lxc-test-apparmor" ] && \
ignore "$STRING" && continue
fi
But the test passes as far as I see.
So could you enable it by updating debian/tests/exercise?
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Releas
ot;/usr/bin/lxc-test-reboot" ] && \
ignore "$STRING" && continue
fi
So, please consider to allow lxc as an autopkgtest backend of lxc itself.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT
to
`__sanitizer_cov_trace_pc'
collect2: error: ld returned 1 exit status
The same symptom is also observed in gcc-10 package.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64
1 - 100 of 377 matches
Mail list logo
