[Touch-packages] [Bug 1912575] Re: [regression] gpm no longer starts automatically, service must be started manually
** Bug watch added: Debian Bug tracker #980726 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980726 ** Also affects: gpm (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980726 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gpm in Ubuntu. https://bugs.launchpad.net/bugs/1912575 Title: [regression] gpm no longer starts automatically, service must be started manually Status in gpm package in Ubuntu: New Status in gpm package in Debian: Unknown Bug description: gpm no longer starts automatically, service must be started manually. The problem started this past week, so maybe in version 1.20.7-7 ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: gpm 1.20.7-7 ProcVersionSignature: Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18 Uname: Linux 5.8.0-36-generic x86_64 ApportVersion: 2.20.11-0ubuntu55 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Jan 21 11:49:14 2021 InstallationDate: Installed on 2020-11-27 (54 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Alpha amd64 (20201125) SourcePackage: gpm UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpm/+bug/1912575/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1911211] Re: Please upgrade to openssl 1.1.1g or later for 20.04
** Changed in: openssl (Ubuntu) Status: New => Invalid ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1911211 Title: Please upgrade to openssl 1.1.1g or later for 20.04 Status in openssl package in Ubuntu: Invalid Bug description: There is a CVE for openssl ( https://www.openssl.org/news/vulnerabilities.html#CVE-2020-1967 ) which has been resolved in openssl v1.1.1g. The currently-shipped version for Ubuntu 20.04 is 1.1.1f. I do see 1.1.1i as a branch in launchpad, but that appears to be an import from Debian Sid. Please upgrade as you are able. I would be willing to test this package. Thank you! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1911211/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1912575] [NEW] [regression] gpm no longer starts automatically, service must be started manually
Public bug reported: gpm no longer starts automatically, service must be started manually. The problem started this past week, so maybe in version 1.20.7-7 ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: gpm 1.20.7-7 ProcVersionSignature: Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18 Uname: Linux 5.8.0-36-generic x86_64 ApportVersion: 2.20.11-0ubuntu55 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Jan 21 11:49:14 2021 InstallationDate: Installed on 2020-11-27 (54 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Alpha amd64 (20201125) SourcePackage: gpm UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gpm (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug hirsute regression regression-release ** Tags added: regression-release -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gpm in Ubuntu. https://bugs.launchpad.net/bugs/1912575 Title: [regression] gpm no longer starts automatically, service must be started manually Status in gpm package in Ubuntu: New Bug description: gpm no longer starts automatically, service must be started manually. The problem started this past week, so maybe in version 1.20.7-7 ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: gpm 1.20.7-7 ProcVersionSignature: Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18 Uname: Linux 5.8.0-36-generic x86_64 ApportVersion: 2.20.11-0ubuntu55 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Jan 21 11:49:14 2021 InstallationDate: Installed on 2020-11-27 (54 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Alpha amd64 (20201125) SourcePackage: gpm UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpm/+bug/1912575/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1912575] Re: [regression] gpm no longer starts automatically, service must be started manually
Looks like gpm.service was just introduced. It probably needs some tweaking. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gpm in Ubuntu. https://bugs.launchpad.net/bugs/1912575 Title: [regression] gpm no longer starts automatically, service must be started manually Status in gpm package in Ubuntu: New Bug description: gpm no longer starts automatically, service must be started manually. The problem started this past week, so maybe in version 1.20.7-7 ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: gpm 1.20.7-7 ProcVersionSignature: Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18 Uname: Linux 5.8.0-36-generic x86_64 ApportVersion: 2.20.11-0ubuntu55 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Jan 21 11:49:14 2021 InstallationDate: Installed on 2020-11-27 (54 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Alpha amd64 (20201125) SourcePackage: gpm UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpm/+bug/1912575/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1912577] [NEW] package linux-image-5.8.0-40-generic 5.8.0-40.45~20.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Public bug reported: When i am put update and upgrade comment this error will appear. what can i do. a few days ago same problem occur and i lost my ubuntu. then i re-instaled it. now the same problem will occur what can i do, kindly help me. ProblemType: Package DistroRelease: Ubuntu 20.04 Package: linux-image-5.8.0-40-generic 5.8.0-40.45~20.04.1 ProcVersionSignature: Ubuntu 5.8.0-38.43~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-38-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Jan 21 09:20:45 2021 ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 InstallationDate: Installed on 2021-01-18 (2 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.2 SourcePackage: initramfs-tools Title: package linux-image-5.8.0-40-generic 5.8.0-40.45~20.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1912577 Title: package linux-image-5.8.0-40-generic 5.8.0-40.45~20.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Status in initramfs-tools package in Ubuntu: New Bug description: When i am put update and upgrade comment this error will appear. what can i do. a few days ago same problem occur and i lost my ubuntu. then i re-instaled it. now the same problem will occur what can i do, kindly help me. ProblemType: Package DistroRelease: Ubuntu 20.04 Package: linux-image-5.8.0-40-generic 5.8.0-40.45~20.04.1 ProcVersionSignature: Ubuntu 5.8.0-38.43~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-38-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip Date: Thu Jan 21 09:20:45 2021 ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 InstallationDate: Installed on 2021-01-18 (2 days ago) InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731) Python3Details: /usr/bin/python3.8, Python 3.8.5, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.2ubuntu0.2 SourcePackage: initramfs-tools Title: package linux-image-5.8.0-40-generic 5.8.0-40.45~20.04.1 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1912577/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak
Performing verification for Focal
I installed rsyslog-relp 8.2001.0-1ubuntu1.1 and librelp0 1.5.0-1ubuntu2
from -updates.
>From there I set up the configuration file, launched a new rsyslog instance,
>and
used netcat to set 100 packets to the relp port.
https://paste.ubuntu.com/p/jCs9Dy6FYF/
As we can see, there are 100 sockets still open in the CLOSE_WAIT state.
>From there I enabled -proposed and installed librelp
1.5.0-1ubuntu2.20.04.1.
I started a new instance of rsyslog, and used netcat to send another 100 packets
to the relp port. This time, all sockets were closed and not left in CLOSE_WAIT.
https://paste.ubuntu.com/p/vdzsVTctmf/
I also ran the testcase from the upstream testsuite, imrelp-
sessionbreak-vg.sh.
I did this by:
1) pull-lp-source rsyslog focal
2) edit debian/rules, add --enable-valgrind, remove --without-valgrind-tests,
3) wget
https://github.com/rsyslog/rsyslog/commit/baee0bd5420649329793746f0daf87c4f59fe6a6.patch
4) quilt import baee0bd5420649329793746f0daf87c4f59fe6a6.patch
5) quilt push
6) chmod +x tests/imrelp-sessionbreak-vg.sh
6) debuild -uc -us -b
It will eventually build tests, and imrelp-sessionbreak-vg.sh passes:
make[5]: Entering directory '/home/ubuntu/rsyslog-8.2001.0/tests'
...
PASS: imrelp-sessionbreak-vg.sh
...
We pass both the upstream testsuite and the testcase from the bug
report.
The file descriptor leak has been fixed, happy to mark as verified for
Focal.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1908473
Title:
rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
leads to file descriptor leak
Status in librelp package in Ubuntu:
Fix Released
Status in rsyslog package in Ubuntu:
Fix Released
Status in librelp source package in Focal:
Fix Committed
Status in rsyslog source package in Focal:
Won't Fix
Status in librelp source package in Groovy:
Fix Committed
Status in rsyslog source package in Groovy:
Fix Released
Status in librelp source package in Hirsute:
Fix Released
Status in rsyslog source package in Hirsute:
Fix Released
Bug description:
[Impact]
In recent versions of rsyslog and librelp, the imrelp module leaks
file descriptors due to a bug where it does not correctly close
sockets, and instead, leaves them in the CLOSE_WAIT state.
This causes rsyslogd on busy servers to eventually hit the limit of
maximum open files allowed, which locks rsyslogd up until it is
restarted.
A workaround is to restart rsyslogd every month or so to manually
close all of the open sockets.
Only users of the imrelp module are affected, and not rsyslog users in
general.
[Testcase]
Install the rsyslog-relp module like so:
$ sudo apt install rsyslog rsyslog-relp
Next, generate a working directory, and make a config file that loads
the relp module.
$ sudo mkdir /workdir
$ cat << EOF >> ./spool.conf
\$LocalHostName spool
\$AbortOnUncleanConfig on
\$PreserveFQDN on
global(
workDirectory="/workdir"
maxMessageSize="256k"
)
main_queue(queue.type="Direct")
module(load="imrelp")
input(
type="imrelp"
name="imrelp"
port="601"
ruleset="spool"
MaxDataSize="256k"
)
ruleset(name="spool" queue.type="direct") {
}
# Just so rsyslog doesn't whine that we do not have outputs
ruleset(name="noop" queue.type="direct") {
action(
type="omfile"
name="omfile"
file="/workdir/spool.log"
)
}
EOF
Verify that the config is valid, then start a rsyslog server.
$ sudo rsyslogd -f ./spool.conf -N9
$ sudo rsyslogd -f ./spool.conf -i /workdir/rsyslogd.pid
Fetch the rsyslogd PID and check for open files.
$ RLOGPID=$(cat /workdir/rsyslogd.pid)
$ sudo ls -l /proc/$RLOGPID/fd
total 0
lr-x-- 1 root root 64 Dec 17 01:22 0 -> /dev/urandom
lrwx-- 1 root root 64 Dec 17 01:22 1 -> 'socket:[41228]'
lrwx-- 1 root root 64 Dec 17 01:22 3 -> 'socket:[41222]'
lrwx-- 1 root root 64 Dec 17 01:22 4 -> 'socket:[41223]'
lrwx-- 1 root root 64 Dec 17 01:22 7 -> 'anon_inode:[eventpoll]'
We have 3 sockets open by default. Next, use netcat to open 100
connections:
$ for i in {1..100} ; do nc -z 127.0.0.1 601 ; done
Now check for open file descriptors, and there will be an extra 100 sockets
in the list:
$ sudo ls -l /proc/$RLOGPID/fd
https://paste.ubuntu.com/p/f6NQVNbZcR/
We can check the state of these sockets with:
$ ss -t
https://paste.ubuntu.com/p/7Ts2FbxJrg/
The listening sockets will be in CLOSE-WAIT, and the netcat sockets
will be in FIN-WAIT-2.
$ ss -t | grep CLOSE-WAIT | wc -l
100
If you install the test package available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf299578-test
When you open connections with netcat, these will be closed properly,
and the file descriptor leak
[Touch-packages] [Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak
** Tags removed: verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1908473
Title:
rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
leads to file descriptor leak
Status in librelp package in Ubuntu:
Fix Released
Status in rsyslog package in Ubuntu:
Fix Released
Status in librelp source package in Focal:
Fix Committed
Status in rsyslog source package in Focal:
Won't Fix
Status in librelp source package in Groovy:
Fix Committed
Status in rsyslog source package in Groovy:
Fix Released
Status in librelp source package in Hirsute:
Fix Released
Status in rsyslog source package in Hirsute:
Fix Released
Bug description:
[Impact]
In recent versions of rsyslog and librelp, the imrelp module leaks
file descriptors due to a bug where it does not correctly close
sockets, and instead, leaves them in the CLOSE_WAIT state.
This causes rsyslogd on busy servers to eventually hit the limit of
maximum open files allowed, which locks rsyslogd up until it is
restarted.
A workaround is to restart rsyslogd every month or so to manually
close all of the open sockets.
Only users of the imrelp module are affected, and not rsyslog users in
general.
[Testcase]
Install the rsyslog-relp module like so:
$ sudo apt install rsyslog rsyslog-relp
Next, generate a working directory, and make a config file that loads
the relp module.
$ sudo mkdir /workdir
$ cat << EOF >> ./spool.conf
\$LocalHostName spool
\$AbortOnUncleanConfig on
\$PreserveFQDN on
global(
workDirectory="/workdir"
maxMessageSize="256k"
)
main_queue(queue.type="Direct")
module(load="imrelp")
input(
type="imrelp"
name="imrelp"
port="601"
ruleset="spool"
MaxDataSize="256k"
)
ruleset(name="spool" queue.type="direct") {
}
# Just so rsyslog doesn't whine that we do not have outputs
ruleset(name="noop" queue.type="direct") {
action(
type="omfile"
name="omfile"
file="/workdir/spool.log"
)
}
EOF
Verify that the config is valid, then start a rsyslog server.
$ sudo rsyslogd -f ./spool.conf -N9
$ sudo rsyslogd -f ./spool.conf -i /workdir/rsyslogd.pid
Fetch the rsyslogd PID and check for open files.
$ RLOGPID=$(cat /workdir/rsyslogd.pid)
$ sudo ls -l /proc/$RLOGPID/fd
total 0
lr-x-- 1 root root 64 Dec 17 01:22 0 -> /dev/urandom
lrwx-- 1 root root 64 Dec 17 01:22 1 -> 'socket:[41228]'
lrwx-- 1 root root 64 Dec 17 01:22 3 -> 'socket:[41222]'
lrwx-- 1 root root 64 Dec 17 01:22 4 -> 'socket:[41223]'
lrwx-- 1 root root 64 Dec 17 01:22 7 -> 'anon_inode:[eventpoll]'
We have 3 sockets open by default. Next, use netcat to open 100
connections:
$ for i in {1..100} ; do nc -z 127.0.0.1 601 ; done
Now check for open file descriptors, and there will be an extra 100 sockets
in the list:
$ sudo ls -l /proc/$RLOGPID/fd
https://paste.ubuntu.com/p/f6NQVNbZcR/
We can check the state of these sockets with:
$ ss -t
https://paste.ubuntu.com/p/7Ts2FbxJrg/
The listening sockets will be in CLOSE-WAIT, and the netcat sockets
will be in FIN-WAIT-2.
$ ss -t | grep CLOSE-WAIT | wc -l
100
If you install the test package available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf299578-test
When you open connections with netcat, these will be closed properly,
and the file descriptor leak will be fixed.
[Where problems could occur]
If a regression were to occur, it would be limited to users of the
imrelp module, which is a part of the rsyslogd-relp package, and
depends on librelp.
rsyslog-relp is not part of a default installation of rsyslog, and is
opt in by changing a configuration file to enable imrelp.
The changes to rsyslog implement a testcase which exercises the problematic
code to ensure things are working as expected; this
can be enabled manually on build, and has been verified to pass (#7).
[Other]
Upstream bug list:
https://github.com/rsyslog/rsyslog/issues/4350
https://github.com/rsyslog/rsyslog/issues/4005
https://github.com/rsyslog/librelp/issues/188
https://github.com/rsyslog/librelp/pull/193
The following commits fix the problem:
rsyslogd
commit baee0bd5420649329793746f0daf87c4f59fe6a6
Author: Andre lorbach
Date: Thu Apr 9 13:00:35 2020 +0200
Subject: testbench: Add test for imrelp to check broken session handling.
Link:
https://github.com/rsyslog/rsyslog/commit/baee0bd5420649329793746f0daf87c4f59fe6a6
librelp
===
commit 7907c9c57f6ed94c8ce5a4e63c3c4e019f71cff0
Author: Andre lorbach
Date: Mon May 11 14:59:55 2020 +0200
Subject: fix memory leak on session break.
Link:
[Touch-packages] [Bug 1910537] Re: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer)
The hardware data in comment #4 does explicitly say: Supported sample rates (kHz): 48 but I don't know if the Linux audio stack (PulseAudio + ALSA) is smart enough to honour that automatically. Sounds like it's not. Try making a new file ~/.config/pulse/daemon.conf with: default-sample-rate = 48000 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1910537 Title: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer) Status in pulseaudio package in Ubuntu: Incomplete Bug description: This is a complicated thing. I have a very specific problem with audio output on HDMI. I want to use an older notebook with Lubuntu 20.04 as a video source for libreoffice slides, videos etc. to feed them over HDMI into a Blackmagic Design ATEM Mini Pro ISO (video mixer) as one input. Configured on the desktop just like a second screen or beamer. Video works well and rock-stable, no problem at all. But not audio. Although I carefully configured audio with pavucontrol to be directed to the HDMI output, the ATEM switcher does not recognize it as an audio source (like when connecting a digital camera) and does not receive or indicate any audio input. Note: But when I use the very same computer, same HDMI cable, same video with a cheap chinese portable LCD screen with speakers (i.e. pull the cable from the ATEM and plug it into the screen) it immediately starts playing both video and audio. So there is evidence that the ubuntu notebook definitely passes it's sound to HDMI and there's really an audio signal on the HDMI. I've opened a bug at Blackmagic Design, and got their reply that they can't help and have never heard of such a problem before. Their guess is that the linux notebook is not setting EDID configuration correctly and thus not recognized by the ATEM, while the cheap LCD screen propably does not care about EDID and just plays everything, therefore a wrong EDID information would not matter. Although I have decades of experience with Linux, I am not too familiar with details of HDMI and the internals of the X11 driver, so I'm not sure where to start debugging, not even, whether this is a problem of Xorg/X11 or pulseaudio. I've checked this with another notebook with much more recent (intel) hardware, which offers dozens of HDMI audio options in the pavucontrol selection menu, but same problem: Video works, but the ATEM does not recognize it as a audio source. Blackmagic Design (they're good in Windows and MacOS, but not Linux) recommended to use an edid manager, whatever this means. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-58.64-generic 5.4.73 Uname: Linux 5.4.0-58-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: LXQt Date: Thu Jan 7 13:16:26 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DpkgLog: ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0742] InstallationDate: Installed on 2020-05-16 (235 days ago) InstallationMedia: Lubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 04f2:b336 Chicony Electronics Co., Ltd Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Acer AO756 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-58-generic root=UUID=a69345e2-b61e-4d25-baab-b23f75273af6 ro quiet cryptdevice=UUID=d132b97b-f47a-4432-88b5-42aca187b9ff:luks-d132b97b-f47a-4432-88b5-42aca187b9ff root=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff resume=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/19/2012 dmi.bios.vendor: Acer dmi.bios.version: V1.05 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: Mimic dmi.board.vendor: Acer dmi.board.version: Type2 - Board Version dmi.chassis.type: 10 dmi.chassis.vendor: Acer dmi.chassis.version: V1.05 dmi.modalias: dmi:bvnAcer:bvrV1.05:bd07/19/2012:svnAcer:pnAO756:pvrV1.05:rvnAcer:rnMimic:rvrType2-BoardVersion:cvnAcer:ct10:cvrV1.05:
[Touch-packages] [Bug 1910537] Re: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer)
There are a few sample rate-related settings in /etc/pulse/daemon.conf (or just make your own personal ~/.config/pulse/daemon.conf). You can edit that file and remove the ';' prefix to enable any settings. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1910537 Title: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer) Status in pulseaudio package in Ubuntu: Incomplete Bug description: This is a complicated thing. I have a very specific problem with audio output on HDMI. I want to use an older notebook with Lubuntu 20.04 as a video source for libreoffice slides, videos etc. to feed them over HDMI into a Blackmagic Design ATEM Mini Pro ISO (video mixer) as one input. Configured on the desktop just like a second screen or beamer. Video works well and rock-stable, no problem at all. But not audio. Although I carefully configured audio with pavucontrol to be directed to the HDMI output, the ATEM switcher does not recognize it as an audio source (like when connecting a digital camera) and does not receive or indicate any audio input. Note: But when I use the very same computer, same HDMI cable, same video with a cheap chinese portable LCD screen with speakers (i.e. pull the cable from the ATEM and plug it into the screen) it immediately starts playing both video and audio. So there is evidence that the ubuntu notebook definitely passes it's sound to HDMI and there's really an audio signal on the HDMI. I've opened a bug at Blackmagic Design, and got their reply that they can't help and have never heard of such a problem before. Their guess is that the linux notebook is not setting EDID configuration correctly and thus not recognized by the ATEM, while the cheap LCD screen propably does not care about EDID and just plays everything, therefore a wrong EDID information would not matter. Although I have decades of experience with Linux, I am not too familiar with details of HDMI and the internals of the X11 driver, so I'm not sure where to start debugging, not even, whether this is a problem of Xorg/X11 or pulseaudio. I've checked this with another notebook with much more recent (intel) hardware, which offers dozens of HDMI audio options in the pavucontrol selection menu, but same problem: Video works, but the ATEM does not recognize it as a audio source. Blackmagic Design (they're good in Windows and MacOS, but not Linux) recommended to use an edid manager, whatever this means. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-58.64-generic 5.4.73 Uname: Linux 5.4.0-58-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: LXQt Date: Thu Jan 7 13:16:26 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DpkgLog: ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0742] InstallationDate: Installed on 2020-05-16 (235 days ago) InstallationMedia: Lubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 04f2:b336 Chicony Electronics Co., Ltd Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Acer AO756 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-58-generic root=UUID=a69345e2-b61e-4d25-baab-b23f75273af6 ro quiet cryptdevice=UUID=d132b97b-f47a-4432-88b5-42aca187b9ff:luks-d132b97b-f47a-4432-88b5-42aca187b9ff root=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff resume=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/19/2012 dmi.bios.vendor: Acer dmi.bios.version: V1.05 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: Mimic dmi.board.vendor: Acer dmi.board.version: Type2 - Board Version dmi.chassis.type: 10 dmi.chassis.vendor: Acer dmi.chassis.version: V1.05 dmi.modalias: dmi:bvnAcer:bvrV1.05:bd07/19/2012:svnAcer:pnAO756:pvrV1.05:rvnAcer:rnMimic:rvrType2-BoardVersion:cvnAcer:ct10:cvrV1.05: dmi.product.family: Type1Family dmi.product.name: AO756 dmi.product.sku: Type1Sku0 dmi.product.version: V1.05
[Touch-packages] [Bug 508522] Re: Add automatic switching to HSP/HFP from A2DP when a mic is needed
Sounds reasonable to me... https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules /#module-bluetooth-policy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/508522 Title: Add automatic switching to HSP/HFP from A2DP when a mic is needed Status in PulseAudio: New Status in chromium-browser package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: Triaged Bug description: Binary package hint: pulseaudio I'm testing a Nokia BH-905i headset (see http://www.wissel.net/blog/d6plinks/SHWL-8AZGGF ) on Ubuntu 10.10. The Bluetooth module correctly identifies the headset and the both audio profiles "HSP/ HFP Telephony duplex" and "A2DP High Fidelity Playback". For music playback only A2DP is suitable (HSP/HFP sounds like listening to music played through an old telephone). A2DP does not have an INPUT mode, so use of the headset for VoiP isn't possible. What would be needed is a separate selection to allow to select A2DP for output and HSP/HFP for input. Smartphones (a lot of them *nix based) phones do that (or they switch on the fly?). Formal structure: 1) Ubuntu 10.10 2) Pulse-Audio 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu21.1 consisting og pluseaudio, pulseaudio-esound-compat, pulseaudio-module-bluetooth, pulseaudio-module-gconf, pulseaudio-module-x11, pulseaudio-utils 3) Select high quality audio output and still use the Bluetooth microphone 4) Had to choose: either high quality audio or "telephone quality" with microphone I can change the profile without the Bluetooth connection dropping, but that's ridiculous. E.g. listening to music, a call comes in. Then I would need to switch the profile before answering. Please note that in Windows, Mac OS, iOS, Android, and Windows Mobile it's done automatically. Check out attached screencast. ProblemType: Bug AplayDevices: List of PLAYBACK Hardware Devices card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 Architecture: i386 ArecordDevices: List of CAPTURE Hardware Devices card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: oivasyuv 2309 F pulseaudio Card0.Amixer.info: Card hw:0 'Intel'/'HDA Intel at 0xd850 irq 17' Mixer name : 'Analog Devices AD1984A' Components : 'HDA:11d4194a,103c30e8,00100400' Controls : 22 Simple ctrls : 14 Date: Sat Jan 16 22:31:41 2010 DistroRelease: Ubuntu 9.10 InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5) Package: pulseaudio 1:0.9.19-0ubuntu4 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-17.54-generic-pae SourcePackage: pulseaudio Uname: Linux 2.6.31-17-generic-pae i686 To manage notifications about this bug go to: https://bugs.launchpad.net/pulseaudio/+bug/508522/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak
Performing verification for librelp in Groovy.
I installed rsyslog-relp 8.2006.0-2ubuntu1 and librelp 1.5.0-1ubuntu2
from -updates to reproduce:
https://paste.ubuntu.com/p/gtn4rcXc72/
>From there I set up the configuration script, ran a new instance of
rsyslog, and used netcat to open 100 connections to the relp port.
When I checked the list of file descriptors, there were 100 sockets
open, in the CLOSE_WAIT state.
>From there, I enabled -proposed and installed librelp
1.5.0-1ubuntu2.20.10.1:
https://paste.ubuntu.com/p/nt342PJkQ5/
I started a new rsyslog instance, and used netcat to open 100
connections to the relp port.
All sockets were closed when rsyslog was done with them, and there were
no sockets in CLOSE_WAIT.
I also ran the provided testcase in rsyslog, imrelp-sessionbreak-vg.sh.
I did this by:
1) pull-lp-source rsyslog groovy
2) edit debian/rules, add --enable-valgrind, remove --without-valgrind-tests,
3) debuild -uc -us -b
It will eventually build tests, and imrelp-sessionbreak-vg.sh passes:
make[5]: Entering directory '/home/ubuntu/rsyslog-8.2006.0/tests'
...
PASS: imrelp-sessionbreak-vg.sh
...
We pass both the upstream testsuite and the testcase from the bug
report.
The file descriptor leak has been fixed, happy to mark as verified for
Groovy.
** Tags removed: verification-needed-groovy
** Tags added: verification-done-groovy
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1908473
Title:
rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
leads to file descriptor leak
Status in librelp package in Ubuntu:
Fix Released
Status in rsyslog package in Ubuntu:
Fix Released
Status in librelp source package in Focal:
Fix Committed
Status in rsyslog source package in Focal:
Won't Fix
Status in librelp source package in Groovy:
Fix Committed
Status in rsyslog source package in Groovy:
Fix Released
Status in librelp source package in Hirsute:
Fix Released
Status in rsyslog source package in Hirsute:
Fix Released
Bug description:
[Impact]
In recent versions of rsyslog and librelp, the imrelp module leaks
file descriptors due to a bug where it does not correctly close
sockets, and instead, leaves them in the CLOSE_WAIT state.
This causes rsyslogd on busy servers to eventually hit the limit of
maximum open files allowed, which locks rsyslogd up until it is
restarted.
A workaround is to restart rsyslogd every month or so to manually
close all of the open sockets.
Only users of the imrelp module are affected, and not rsyslog users in
general.
[Testcase]
Install the rsyslog-relp module like so:
$ sudo apt install rsyslog rsyslog-relp
Next, generate a working directory, and make a config file that loads
the relp module.
$ sudo mkdir /workdir
$ cat << EOF >> ./spool.conf
\$LocalHostName spool
\$AbortOnUncleanConfig on
\$PreserveFQDN on
global(
workDirectory="/workdir"
maxMessageSize="256k"
)
main_queue(queue.type="Direct")
module(load="imrelp")
input(
type="imrelp"
name="imrelp"
port="601"
ruleset="spool"
MaxDataSize="256k"
)
ruleset(name="spool" queue.type="direct") {
}
# Just so rsyslog doesn't whine that we do not have outputs
ruleset(name="noop" queue.type="direct") {
action(
type="omfile"
name="omfile"
file="/workdir/spool.log"
)
}
EOF
Verify that the config is valid, then start a rsyslog server.
$ sudo rsyslogd -f ./spool.conf -N9
$ sudo rsyslogd -f ./spool.conf -i /workdir/rsyslogd.pid
Fetch the rsyslogd PID and check for open files.
$ RLOGPID=$(cat /workdir/rsyslogd.pid)
$ sudo ls -l /proc/$RLOGPID/fd
total 0
lr-x-- 1 root root 64 Dec 17 01:22 0 -> /dev/urandom
lrwx-- 1 root root 64 Dec 17 01:22 1 -> 'socket:[41228]'
lrwx-- 1 root root 64 Dec 17 01:22 3 -> 'socket:[41222]'
lrwx-- 1 root root 64 Dec 17 01:22 4 -> 'socket:[41223]'
lrwx-- 1 root root 64 Dec 17 01:22 7 -> 'anon_inode:[eventpoll]'
We have 3 sockets open by default. Next, use netcat to open 100
connections:
$ for i in {1..100} ; do nc -z 127.0.0.1 601 ; done
Now check for open file descriptors, and there will be an extra 100 sockets
in the list:
$ sudo ls -l /proc/$RLOGPID/fd
https://paste.ubuntu.com/p/f6NQVNbZcR/
We can check the state of these sockets with:
$ ss -t
https://paste.ubuntu.com/p/7Ts2FbxJrg/
The listening sockets will be in CLOSE-WAIT, and the netcat sockets
will be in FIN-WAIT-2.
$ ss -t | grep CLOSE-WAIT | wc -l
100
If you install the test package available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf299578-test
When you open connections with netcat, these will be closed properly,
and the file descriptor leak will be fixed.
[Where problems could occur]
If a
[Touch-packages] [Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak
I tested this on Focal. I installed librelp0 and restart rsyslog. Prior
to the change, sockets were stacking up in CLOSE-WAIT (both from normal
use and from the netcat test). After the change, sockets are being
closed correctly.
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1908473
Title:
rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
leads to file descriptor leak
Status in librelp package in Ubuntu:
Fix Released
Status in rsyslog package in Ubuntu:
Fix Released
Status in librelp source package in Focal:
Fix Committed
Status in rsyslog source package in Focal:
Won't Fix
Status in librelp source package in Groovy:
Fix Committed
Status in rsyslog source package in Groovy:
Fix Released
Status in librelp source package in Hirsute:
Fix Released
Status in rsyslog source package in Hirsute:
Fix Released
Bug description:
[Impact]
In recent versions of rsyslog and librelp, the imrelp module leaks
file descriptors due to a bug where it does not correctly close
sockets, and instead, leaves them in the CLOSE_WAIT state.
This causes rsyslogd on busy servers to eventually hit the limit of
maximum open files allowed, which locks rsyslogd up until it is
restarted.
A workaround is to restart rsyslogd every month or so to manually
close all of the open sockets.
Only users of the imrelp module are affected, and not rsyslog users in
general.
[Testcase]
Install the rsyslog-relp module like so:
$ sudo apt install rsyslog rsyslog-relp
Next, generate a working directory, and make a config file that loads
the relp module.
$ sudo mkdir /workdir
$ cat << EOF >> ./spool.conf
\$LocalHostName spool
\$AbortOnUncleanConfig on
\$PreserveFQDN on
global(
workDirectory="/workdir"
maxMessageSize="256k"
)
main_queue(queue.type="Direct")
module(load="imrelp")
input(
type="imrelp"
name="imrelp"
port="601"
ruleset="spool"
MaxDataSize="256k"
)
ruleset(name="spool" queue.type="direct") {
}
# Just so rsyslog doesn't whine that we do not have outputs
ruleset(name="noop" queue.type="direct") {
action(
type="omfile"
name="omfile"
file="/workdir/spool.log"
)
}
EOF
Verify that the config is valid, then start a rsyslog server.
$ sudo rsyslogd -f ./spool.conf -N9
$ sudo rsyslogd -f ./spool.conf -i /workdir/rsyslogd.pid
Fetch the rsyslogd PID and check for open files.
$ RLOGPID=$(cat /workdir/rsyslogd.pid)
$ sudo ls -l /proc/$RLOGPID/fd
total 0
lr-x-- 1 root root 64 Dec 17 01:22 0 -> /dev/urandom
lrwx-- 1 root root 64 Dec 17 01:22 1 -> 'socket:[41228]'
lrwx-- 1 root root 64 Dec 17 01:22 3 -> 'socket:[41222]'
lrwx-- 1 root root 64 Dec 17 01:22 4 -> 'socket:[41223]'
lrwx-- 1 root root 64 Dec 17 01:22 7 -> 'anon_inode:[eventpoll]'
We have 3 sockets open by default. Next, use netcat to open 100
connections:
$ for i in {1..100} ; do nc -z 127.0.0.1 601 ; done
Now check for open file descriptors, and there will be an extra 100 sockets
in the list:
$ sudo ls -l /proc/$RLOGPID/fd
https://paste.ubuntu.com/p/f6NQVNbZcR/
We can check the state of these sockets with:
$ ss -t
https://paste.ubuntu.com/p/7Ts2FbxJrg/
The listening sockets will be in CLOSE-WAIT, and the netcat sockets
will be in FIN-WAIT-2.
$ ss -t | grep CLOSE-WAIT | wc -l
100
If you install the test package available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf299578-test
When you open connections with netcat, these will be closed properly,
and the file descriptor leak will be fixed.
[Where problems could occur]
If a regression were to occur, it would be limited to users of the
imrelp module, which is a part of the rsyslogd-relp package, and
depends on librelp.
rsyslog-relp is not part of a default installation of rsyslog, and is
opt in by changing a configuration file to enable imrelp.
The changes to rsyslog implement a testcase which exercises the problematic
code to ensure things are working as expected; this
can be enabled manually on build, and has been verified to pass (#7).
[Other]
Upstream bug list:
https://github.com/rsyslog/rsyslog/issues/4350
https://github.com/rsyslog/rsyslog/issues/4005
https://github.com/rsyslog/librelp/issues/188
https://github.com/rsyslog/librelp/pull/193
The following commits fix the problem:
rsyslogd
commit baee0bd5420649329793746f0daf87c4f59fe6a6
Author: Andre lorbach
Date: Thu Apr 9 13:00:35 2020 +0200
Subject: testbench: Add test for imrelp to check broken session handling.
Link:
https://github.com/rsyslog/rsyslog/commit/baee0bd5420649329793746f0daf87c4f59fe6a6
[Touch-packages] [Bug 1639531] Re: GCC compiles programs to shared object instead of executable, preventing GUI file managers from executing programs
This is serious bug and is really counter-productive in 21 century when
downloading some portable archive and cannot launch software, Very
troublesome. This way is one way to scare people back to Windows.
affects 20.10 and 21.04 too, please raise voice people.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shared-mime-info in
Ubuntu.
https://bugs.launchpad.net/bugs/1639531
Title:
GCC compiles programs to shared object instead of executable,
preventing GUI file managers from executing programs
Status in gcc-defaults:
Unknown
Status in shared-mime-info:
Unknown
Status in shared-mime-info package in Ubuntu:
Triaged
Bug description:
Release of Ubuntu being used
Description:Ubuntu 16.10
Release:16.10
Version of the package being used
=
gcc:
Installed: 4:6.1.1-1ubuntu2
Candidate: 4:6.1.1-1ubuntu2
Version table:
*** 4:6.1.1-1ubuntu2 500
500 http://archive.ubuntu.com/ubuntu yakkety/main amd64 Packages
100 /var/lib/dpkg/status
What was expected
=
Programs compiled using `gcc -o program program.c` should be runnable
by double-clicking them from a GUI file manager.
Compiling a simple program (`void main() { }`) using Xubuntu 16.04's
current version of `gcc` (`gcc version 5.4.0 20160609 (Ubuntu
5.4.0-6ubuntu1~16.04.2)`) produces the following output from
`/usr/bin/file program`:
program: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.6.32, BuildID[sha1]=signature_here, not stripped
This is correct behavior, allowing the executables to run from
Nautilus and Thunar.
What happened instead
=
Programs compiled using `gcc -o program program.c` are not runnable by
double-clicking them from a GUI file manager, even though they are
runnable from the terminal.
Compiling a simple program (`void main() { }`) using the current
version of `gcc` (`6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12)`) produces
the following output from `/usr/bin/file program`:
program: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.6.32, BuildID[sha1]=signature_here, not stripped
The program is also identified as a "shared library" instead of an
"executable" in Thunar, causing it to not be runnable from the GUI.
Others are unable to run such programs from Nautilus.
To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc-defaults/+bug/1639531/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak
Same one failure on today's rebuild. Strange, since this is the exact
same code as Groovy.
** Attachment added:
"buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.5"
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1908473/+attachment/5454976/+files/buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.5
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1908473
Title:
rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
leads to file descriptor leak
Status in librelp package in Ubuntu:
Fix Released
Status in rsyslog package in Ubuntu:
Fix Released
Status in librelp source package in Focal:
Fix Committed
Status in rsyslog source package in Focal:
Won't Fix
Status in librelp source package in Groovy:
Fix Committed
Status in rsyslog source package in Groovy:
Fix Released
Status in librelp source package in Hirsute:
Fix Released
Status in rsyslog source package in Hirsute:
Fix Released
Bug description:
[Impact]
In recent versions of rsyslog and librelp, the imrelp module leaks
file descriptors due to a bug where it does not correctly close
sockets, and instead, leaves them in the CLOSE_WAIT state.
This causes rsyslogd on busy servers to eventually hit the limit of
maximum open files allowed, which locks rsyslogd up until it is
restarted.
A workaround is to restart rsyslogd every month or so to manually
close all of the open sockets.
Only users of the imrelp module are affected, and not rsyslog users in
general.
[Testcase]
Install the rsyslog-relp module like so:
$ sudo apt install rsyslog rsyslog-relp
Next, generate a working directory, and make a config file that loads
the relp module.
$ sudo mkdir /workdir
$ cat << EOF >> ./spool.conf
\$LocalHostName spool
\$AbortOnUncleanConfig on
\$PreserveFQDN on
global(
workDirectory="/workdir"
maxMessageSize="256k"
)
main_queue(queue.type="Direct")
module(load="imrelp")
input(
type="imrelp"
name="imrelp"
port="601"
ruleset="spool"
MaxDataSize="256k"
)
ruleset(name="spool" queue.type="direct") {
}
# Just so rsyslog doesn't whine that we do not have outputs
ruleset(name="noop" queue.type="direct") {
action(
type="omfile"
name="omfile"
file="/workdir/spool.log"
)
}
EOF
Verify that the config is valid, then start a rsyslog server.
$ sudo rsyslogd -f ./spool.conf -N9
$ sudo rsyslogd -f ./spool.conf -i /workdir/rsyslogd.pid
Fetch the rsyslogd PID and check for open files.
$ RLOGPID=$(cat /workdir/rsyslogd.pid)
$ sudo ls -l /proc/$RLOGPID/fd
total 0
lr-x-- 1 root root 64 Dec 17 01:22 0 -> /dev/urandom
lrwx-- 1 root root 64 Dec 17 01:22 1 -> 'socket:[41228]'
lrwx-- 1 root root 64 Dec 17 01:22 3 -> 'socket:[41222]'
lrwx-- 1 root root 64 Dec 17 01:22 4 -> 'socket:[41223]'
lrwx-- 1 root root 64 Dec 17 01:22 7 -> 'anon_inode:[eventpoll]'
We have 3 sockets open by default. Next, use netcat to open 100
connections:
$ for i in {1..100} ; do nc -z 127.0.0.1 601 ; done
Now check for open file descriptors, and there will be an extra 100 sockets
in the list:
$ sudo ls -l /proc/$RLOGPID/fd
https://paste.ubuntu.com/p/f6NQVNbZcR/
We can check the state of these sockets with:
$ ss -t
https://paste.ubuntu.com/p/7Ts2FbxJrg/
The listening sockets will be in CLOSE-WAIT, and the netcat sockets
will be in FIN-WAIT-2.
$ ss -t | grep CLOSE-WAIT | wc -l
100
If you install the test package available in the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf299578-test
When you open connections with netcat, these will be closed properly,
and the file descriptor leak will be fixed.
[Where problems could occur]
If a regression were to occur, it would be limited to users of the
imrelp module, which is a part of the rsyslogd-relp package, and
depends on librelp.
rsyslog-relp is not part of a default installation of rsyslog, and is
opt in by changing a configuration file to enable imrelp.
The changes to rsyslog implement a testcase which exercises the problematic
code to ensure things are working as expected; this
can be enabled manually on build, and has been verified to pass (#7).
[Other]
Upstream bug list:
https://github.com/rsyslog/rsyslog/issues/4350
https://github.com/rsyslog/rsyslog/issues/4005
https://github.com/rsyslog/librelp/issues/188
https://github.com/rsyslog/librelp/pull/193
The following commits fix the problem:
rsyslogd
commit baee0bd5420649329793746f0daf87c4f59fe6a6
Author: Andre lorbach
Date: Thu Apr 9 13:00:35 2020 +0200
Subject: testbench: Add test for imrelp to check broken session handling.
Link:
[Touch-packages] [Bug 1912122] Re: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions
This bug was fixed in the package rsyslog - 8.2010.0-1ubuntu2 --- rsyslog (8.2010.0-1ubuntu2) hirsute; urgency=medium * debian/dmesg.service: Change /var/log/dmesg from 0644 to 0640 to adhere to new DMESG_RESTRICT restrictions. (LP: #1912122) -- Matthew Ruffell Mon, 18 Jan 2021 13:34:48 +1300 ** Changed in: rsyslog (Ubuntu Hirsute) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1912122 Title: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions Status in rsyslog package in Ubuntu: Fix Released Status in rsyslog source package in Groovy: Won't Fix Status in rsyslog source package in Hirsute: Fix Released Bug description: [Impact] In bug 1886112, CONFIG_SECURITY_DMESG_RESTRICT was enabled on the Ubuntu kernel starting with Groovy and onward, in an effort to restrict access to the kernel log buffer from unprivileged users. It seems we have overlooked /var/log/dmesg, as it is still mode 0644, while /var/log/kern.log, /var/log/syslog are all 0640: $ ll /var/log -rw-r--r-- 1 root adm 81768 Jan 18 09:09 dmesg -rw-r- 1 syslogadm 24538 Jan 18 13:05 kern.log -rw-r- 1 syslogadm213911 Jan 18 13:22 syslog Change /var/log/dmesg to 0640 to close the information leak. [Testcase] $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg [0.00] kernel: Linux version 5.8.0-36-generic (buildd@lgw01-amd64-011) (gcc (Ubuntu 10.2.1-2ubuntu3) 10.2.1 20201221, GNU ld (GNU Binutils for Ubuntu) 2.35.50.20210106) #40+21.04.1-Ubuntu SMP Thu Jan 7 11:35:09 UTC 2021 (Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18) [0.00] kernel: Command line: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash --- If you install the package in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1912122-test $ sudo systemctl daemon-reload $ sudo systemctl start dmesg.service $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg cat: /var/log/dmesg: Permission denied [Where problems could occur] Some users or log scraper programs might need to view the kernel log buffers, and in this case, their underlying service accounts should be added to the 'adm' group. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1912122] Re: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions
Hi Robie, I agree this probably isn't worth a SRU to Groovy, I just made the packages available in the odd chance that they might be considered. I will mark Groovy as won't fix. Hirsute is what really matters in the end. ** Changed in: rsyslog (Ubuntu Groovy) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1912122 Title: /var/log/dmesg is 0644, should be 0640 to match new DMESG_RESTRICT restrictions Status in rsyslog package in Ubuntu: In Progress Status in rsyslog source package in Groovy: Won't Fix Status in rsyslog source package in Hirsute: In Progress Bug description: [Impact] In bug 1886112, CONFIG_SECURITY_DMESG_RESTRICT was enabled on the Ubuntu kernel starting with Groovy and onward, in an effort to restrict access to the kernel log buffer from unprivileged users. It seems we have overlooked /var/log/dmesg, as it is still mode 0644, while /var/log/kern.log, /var/log/syslog are all 0640: $ ll /var/log -rw-r--r-- 1 root adm 81768 Jan 18 09:09 dmesg -rw-r- 1 syslogadm 24538 Jan 18 13:05 kern.log -rw-r- 1 syslogadm213911 Jan 18 13:22 syslog Change /var/log/dmesg to 0640 to close the information leak. [Testcase] $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg [0.00] kernel: Linux version 5.8.0-36-generic (buildd@lgw01-amd64-011) (gcc (Ubuntu 10.2.1-2ubuntu3) 10.2.1 20201221, GNU ld (GNU Binutils for Ubuntu) 2.35.50.20210106) #40+21.04.1-Ubuntu SMP Thu Jan 7 11:35:09 UTC 2021 (Ubuntu 5.8.0-36.40+21.04.1-generic 5.8.18) [0.00] kernel: Command line: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash --- If you install the package in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1912122-test $ sudo systemctl daemon-reload $ sudo systemctl start dmesg.service $ sudo adduser dave $ su dave $ groups dave $ cat /var/log/kern.log cat: /var/log/kern.log: Permission denied $ cat /var/log/syslog cat: /var/log/syslog: Permission denied $ cat /var/log/dmesg cat: /var/log/dmesg: Permission denied [Where problems could occur] Some users or log scraper programs might need to view the kernel log buffers, and in this case, their underlying service accounts should be added to the 'adm' group. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1912122/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1675079] Re: 16.04 LTS Partition /boot fills up with Kernel images, gets underwear in a twist
Update to comment 37 Issue 2) was my fault of not properly unmarking all components of the kernel, so that some of it kept the "manual" status and prevented removal. But once I severed all those marks, "apt autoremove" could do it's work. Issue 1) was reported first here: https://bugs.kde.org/show_bug.cgi?id=430296 and then here: https://github.com/hughsie/PackageKit/issues/450 ** Bug watch added: KDE Bug Tracking System #430296 https://bugs.kde.org/show_bug.cgi?id=430296 ** Bug watch added: github.com/hughsie/PackageKit/issues #450 https://github.com/hughsie/PackageKit/issues/450 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1675079 Title: 16.04 LTS Partition /boot fills up with Kernel images, gets underwear in a twist Status in unattended-upgrades package in Ubuntu: Fix Released Status in update-manager package in Ubuntu: Fix Released Status in unattended-upgrades source package in Xenial: Fix Released Status in update-manager source package in Xenial: Fix Released Status in unattended-upgrades source package in Artful: Won't Fix Status in update-manager source package in Artful: Fix Released Bug description: [Impact] * Update-manager and unattended-upgrades install many kernel packages during the lifetime of a release but does not remove them automatically leading to those packages filling disk space potentially completely filling /boot and making the system unable to install updates or even boot. * Stable release users are impacted by this bug for years and their systems already collected many autoremovable unused kernel packages, thus they would benefit from backporting the fix greatly. * The bug is fixed by removing autoremovable (not currently booted) kernel packages when running unattended-upgrades or update-manager. Update manager offers the kernel removals when there are other updates to be installed. [Test Case] 1. Install kernel packages to be removed, mark them auto-installed and run apt's kernel hook script to make apt consider them autoremovable: sudo apt install -y linux-image-extra-4.4.0-92-generic linux-image-extra-4.4.0-93-generic sudo apt-mark auto linux-image-extra-4.4.0-92-generic linux-image-extra-4.4.0-93-generic sudo /etc/kernel/postinst.d/apt-auto-removal 2. Also downgrade a package to be upgraded: sudo apt-get install -y --allow-downgrades ca- certificates=20160104ubuntu1 3. (update-manager). Run update-manager and observe that kernel packages are offered for removal in Details of updates. sudo update-manager 4. (update-manager) Click on Install Now and observe that the kernel packages are removed. 3. (unattended-upgrades) Run unattended-upgrades manually and observe the removal of the autoremovable kernel packages: sudo unattended-upgrade -v [Regression Potential] The change may cause update-manager or unattanded-upgrades to remove used kernel packages or fail to install other package updates. [Other Info] The unattended-upgrades fix is uploaded with many other fixes and those may cause regressions in other areas in unattended-upgrades. [Original bug text] On a 16.04LTS system, the /boot partition will eventually fill with Kernel images, until the point where "apt-get autoremove" can't complete. This issue has previously been reported as fixed, but it is not fixed: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1357093 Generally what I see is the final kernel image that fills the drive is incompletely installed (the header package does not make it). "apt- get autoremove" tries to work, but fails. I must manually remove kernel images to free enough space. I see this on a machine used by my elderly parents, where 'Download and install updates automatically' is set. And on my home machines, where the setting is elsewhere. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1675079/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1912526] [NEW] cannot import new keys if another malformed key exists
Public bug reported: "apt-key add" fails to import keys if there exists another key with a malformed file name. Such malformed key names used to be provided by the openSUSE Build Service (https://github.com/openSUSE/software-o-o/issues/842). After importing such malformed key, future key imports will fail with something like: $ sudo apt-key add linux_signing_key.pub gpg: invalid key resource URL '/tmp/apt-key-gpghome.f8IaqZ48Ze/isv:ownCloud:desktop.asc.gpg' gpg: keyblock resource '(null)': General error even though no such file "isv:ownCloud:desktop.asc.gpg" exists anywhere on the filesystem. This affects deb packages that import public repo keys during installation, such as Google Chrome or Vivaldi, and results in minor issues such as breaking GUI tools and CLI warnings, and the major issue that the installed repo cannot be used anymore to update the software (Google Chrome, Vivaldi). apt-key should be robust to such issues and continue importing keys. As in the example above, apt-key should import "linux_signing_key.pub" no matter if another unrelated key is malformed etc. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apt 2.0.2ubuntu0.2 ProcVersionSignature: Ubuntu 5.8.0-38.43~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-38-generic x86_64 NonfreeKernelModules: openafs nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Jan 20 19:24:34 2021 InstallationDate: Installed on 2020-04-24 (271 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: apt (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1912526 Title: cannot import new keys if another malformed key exists Status in apt package in Ubuntu: New Bug description: "apt-key add" fails to import keys if there exists another key with a malformed file name. Such malformed key names used to be provided by the openSUSE Build Service (https://github.com/openSUSE/software-o-o/issues/842). After importing such malformed key, future key imports will fail with something like: $ sudo apt-key add linux_signing_key.pub gpg: invalid key resource URL '/tmp/apt-key-gpghome.f8IaqZ48Ze/isv:ownCloud:desktop.asc.gpg' gpg: keyblock resource '(null)': General error even though no such file "isv:ownCloud:desktop.asc.gpg" exists anywhere on the filesystem. This affects deb packages that import public repo keys during installation, such as Google Chrome or Vivaldi, and results in minor issues such as breaking GUI tools and CLI warnings, and the major issue that the installed repo cannot be used anymore to update the software (Google Chrome, Vivaldi). apt-key should be robust to such issues and continue importing keys. As in the example above, apt-key should import "linux_signing_key.pub" no matter if another unrelated key is malformed etc. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: apt 2.0.2ubuntu0.2 ProcVersionSignature: Ubuntu 5.8.0-38.43~20.04.1-generic 5.8.18 Uname: Linux 5.8.0-38-generic x86_64 NonfreeKernelModules: openafs nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Wed Jan 20 19:24:34 2021 InstallationDate: Installed on 2020-04-24 (271 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1912526/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- focal' to 'verification-done-focal'. If the problem still exists, change the tag 'verification-needed-focal' to 'verification-failed-focal'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed Status in OEM Priority Project: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in grub2 source package in Focal: Invalid Status in initramfs-tools source package in Focal: Invalid Status in linux source package in Focal: Fix Committed Status in grub2 source package in Groovy: Invalid Status in initramfs-tools source package in Groovy: Invalid Status in linux source package in Groovy: Fix Committed Status in grub2 source package in Hirsute: Invalid Status in initramfs-tools source package in Hirsute: Invalid Status in linux source package in Hirsute: Confirmed Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. --- However, we currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error. [Impact] * Decoding failure messages in dmsg with a single lz4 initrd * Multiple lz4 compressed initrds cannot be decompressed by kernel, when loaded by grub * Multiple lz4 compressed initrds cannot be decompressed by kernel, when there is padding between them [Test Case] * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4 * Create an lz4 compressed initrd with a single test-file in it with some content. I.e. echo "second-initrd" > test-file, and then pack that with cpio hewc owned by root & lz4 -l. * Create a combined padded initrd of stock initrd, pad4, and the test-marker initrd created above. * Boot above with "break=top" kernel command line. * With broken kernels, there should be dmesg error message that decoding failed, and one will observe that /test-file does not exist in the shell. * With fixed kernel, /test-file in the initrd shell should exist, and should have the expected content "second-initrd". * The alignment and padding in the above test case depends on the size of the first initrd => if a given padded initrd does not reproduce the problem, try varying the size of the first initrd or that of the padding between 0..4. [Where problems could occur] * This changes compatible lz4 decompressor in the kernel, which can also be used by other kernel modules such as cryptography, squashfs, zram, f2fs, comprssed kernel image, pstore. For example, previously rejected files with "bogus" length and extra padding may now be accepted, whereas they were previously getting rejected by the decompressor. * Ideally kernel should switch to the stable lz4 format which has better specification of end of stream. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1835660] Re: initramfs unpacking failed
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- groovy' to 'verification-done-groovy'. If the problem still exists, change the tag 'verification-needed-groovy' to 'verification-failed- groovy'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-groovy ** Tags added: verification-needed-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1835660 Title: initramfs unpacking failed Status in OEM Priority Project: New Status in grub2 package in Ubuntu: Invalid Status in initramfs-tools package in Ubuntu: Invalid Status in linux package in Ubuntu: Confirmed Status in grub2 source package in Focal: Invalid Status in initramfs-tools source package in Focal: Invalid Status in linux source package in Focal: Fix Committed Status in grub2 source package in Groovy: Invalid Status in initramfs-tools source package in Groovy: Invalid Status in linux source package in Groovy: Fix Committed Status in grub2 source package in Hirsute: Invalid Status in initramfs-tools source package in Hirsute: Invalid Status in linux source package in Hirsute: Confirmed Bug description: "initramfs unpacking failed: Decoding failed", message appears on boot up. If I "update-initramfs" using gzip instead of lz, then boot up passes without decoding failed message. --- However, we currently believe that the decoding error reported in dmesg is actually harmless and has no impact on usability on the system. Switching from lz4 to gzip compression, simply papers over the warning, without any benefits, and slows down boot. Kernel should be fixed to correctly parse lz4 compressed initrds, or at least lower the warning, to not be user visible as an error. [Impact] * Decoding failure messages in dmsg with a single lz4 initrd * Multiple lz4 compressed initrds cannot be decompressed by kernel, when loaded by grub * Multiple lz4 compressed initrds cannot be decompressed by kernel, when there is padding between them [Test Case] * Create empty padding with $ dd if=/dev/zero of=pad4 bs=1 count=4 * Create an lz4 compressed initrd with a single test-file in it with some content. I.e. echo "second-initrd" > test-file, and then pack that with cpio hewc owned by root & lz4 -l. * Create a combined padded initrd of stock initrd, pad4, and the test-marker initrd created above. * Boot above with "break=top" kernel command line. * With broken kernels, there should be dmesg error message that decoding failed, and one will observe that /test-file does not exist in the shell. * With fixed kernel, /test-file in the initrd shell should exist, and should have the expected content "second-initrd". * The alignment and padding in the above test case depends on the size of the first initrd => if a given padded initrd does not reproduce the problem, try varying the size of the first initrd or that of the padding between 0..4. [Where problems could occur] * This changes compatible lz4 decompressor in the kernel, which can also be used by other kernel modules such as cryptography, squashfs, zram, f2fs, comprssed kernel image, pstore. For example, previously rejected files with "bogus" length and extra padding may now be accepted, whereas they were previously getting rejected by the decompressor. * Ideally kernel should switch to the stable lz4 format which has better specification of end of stream. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1835660/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1873895] Re: Regression: block staircase display with side-by-side monitors of different pixel widths
You may find the following information useful. It looks like Ubuntu needs to add these fixes ... https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/10#note_769719 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libxcb in Ubuntu. https://bugs.launchpad.net/bugs/1873895 Title: Regression: block staircase display with side-by-side monitors of different pixel widths Status in Linux: Unknown Status in libxcb package in Ubuntu: Confirmed Status in xfwm4 package in Ubuntu: Confirmed Status in xserver-xorg-video-amdgpu package in Ubuntu: Confirmed Bug description: Update based on further research. This only happens when the secondary external display is operating at a different pixel width to the internal. In this case eDP is 1920x1080 whereas the external HDMI-A-0 is natively 1680x1050. It is caused by xfwm4's recent switch from using glx to xpresent for AMD GPUs. The underlying bug is in the AMD driver. I was able to reproduce on an external 1920x1200 display only when it was set to a non-native 1680x1050 resolution. --- Two identical Lenovo E495 laptops with 20.04 installed. The problem occurred initially on the laptop that is having package upgrades applied regularly. With dual monitors and the external monitor placed left or right the display has a blocked staircase effect shown in the attached photograph, and seems related to https://gitlab.freedesktop.org/xorg/driver/xf86-video- amdgpu/-/issues/10 More detailed investigation suggests it only happens when the X coordinate of the two monitors is different. The symptom looks like an off-by-one error because it appears as if the display is divided into, say, 10 rows and 15 columns but the first row has 16 'columns' worth of blocks on it and so wraps to the beginning of the 2nd row, and so on. On the laptop without package upgrades being applied this didn't happen. So I upgraded it (314 packages) and restarted and it too sees the same problem. I suspected libxcomposite1 and downgraded it to 1:0.4.5-0ubuntu1 but that didn't solve it. I now suspect libxcb but so far haven't been able to prove it. --- ProblemType: Bug ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: XFCE DistUpgraded: Fresh install DistroCodename: focal DistroRelease: Ubuntu 20.04 DistroVariant: ubuntu GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Picasso [1002:15d8] (rev c1) (prog-if 00 [VGA controller]) Subsystem: Lenovo ThinkPad E595 [17aa:5124] InstallationDate: Installed on 2020-04-08 (11 days ago) InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200408) MachineType: LENOVO 20NECTO1WW Package: xserver-xorg-video-amdgpu 19.1.0-1 PackageArchitecture: amd64 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-21-generic root=/dev/mapper/ELLOE000-rootfs ro acpi_osi=! "acpi_osi=Windows 2016" quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27 Tags: focal ubuntu ubuntu Uname: Linux 5.4.0-21-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip libvirt lp lpadmin lxd plugdev sambashare sudo users _MarkForUpload: True dmi.bios.date: 12/23/2019 dmi.bios.vendor: LENOVO dmi.bios.version: R11ET32W (1.12 ) dmi.board.asset.tag: Not Available dmi.board.name: 20NECTO1WW dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.modalias: dmi:bvnLENOVO:bvrR11ET32W(1.12):bd12/23/2019:svnLENOVO:pn20NECTO1WW:pvrThinkPadE495:rvnLENOVO:rn20NECTO1WW:rvrNotDefined:cvnLENOVO:ct10:cvrNone: dmi.product.family: ThinkPad E495 dmi.product.name: 20NECTO1WW dmi.product.sku: LENOVO_MT_20NE_BU_Think_FM_ThinkPad E495 dmi.product.version: ThinkPad E495 dmi.sys.vendor: LENOVO version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.4-2ubuntu1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:1.20.8-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20200226-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.16-1 To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1873895/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1875944] Re: Lenovo Ideapad 130-15AST 20.04 distorted and unusable
*** This bug is a duplicate of bug 1873895 *** https://bugs.launchpad.net/bugs/1873895 You may find the following information useful. It looks like Ubuntu needs to add these fixes ... https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/10#note_769719 ** Bug watch added: gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues #10 https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/10 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libdrm in Ubuntu. https://bugs.launchpad.net/bugs/1875944 Title: Lenovo Ideapad 130-15AST 20.04 distorted and unusable Status in Ubuntu MATE: Confirmed Status in libdrm package in Ubuntu: Confirmed Status in linux package in Ubuntu: Confirmed Bug description: Output of lshw here: https://pastebin.com/NMBigV4G Screenshot of the desktop here in the community forum: https://ubuntu-mate.community/t/lenovo-ideapad-20-04-upgrade-distorted-and-unusable/21617 I'm not all that experienced at filing bug reports here so I have included the attachment of the photo found at the forum link. The picture in the community forum link is what the MATE 20.04 live USB boots to. I first upgraded from 18.04 using do-release-upgrade. The result looked like the photo as well. Then I reinstalled 18.04, upgraded to 19.10, which looked and performed normally. I then upgraded the 19.10 install to 20.04 with the same result as the photo. I also tried with a different flash drive just to rule that out. Then I made the live USB of the 20.04 image and booted it to what you see in the forum post. I made a live USB of both Stock Ubuntu and Kubuntu 20.04 and both worked just fine. Until I tried the other two flavors I was thinking it was system specific, but after they worked normally it seems to be a MATE specific issue with this system. It appears to be only a display problem. The DE is completely unusable with the mouse, but I can launch a terminal and run commands, although the terminal is just as distorted as the photo above, so you can't see what you are typing or the resulting output. --- ProblemType: Bug ApportVersion: 2.20.9-0ubuntu7.14 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: clay 1524 F pulseaudio /dev/snd/controlC0: clay 1524 F pulseaudio BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CompositorRunning: None CurrentDesktop: MATE DistUpgraded: Fresh install DistroCodename: bionic DistroRelease: Ubuntu 18.04 DistroVariant: ubuntu DkmsStatus: rtl8821ce, v5.5.2_34066.20200325, 5.3.0-46-generic, x86_64: installed GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] [1002:98e4] (rev ea) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:39f5] InstallationDate: Installed on 2020-04-27 (11 days ago) InstallationMedia: Ubuntu-MATE 18.04.4 LTS "Bionic Beaver" - Release amd64 (20200203.1) MachineType: LENOVO 81H5 Package: linux (not installed) ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.3.0-46-generic root=UUID=bec09cbc-83af-49f6-8aeb-f02059977f4a ro quiet splash vt.handoff=1 ProcVersionSignature: Ubuntu 5.3.0-46.38~18.04.1-generic 5.3.18 RelatedPackageVersions: linux-restricted-modules-5.3.0-46-generic N/A linux-backports-modules-5.3.0-46-generic N/A linux-firmware1.173.17 Tags: bionic ubuntu Uname: Linux 5.3.0-46-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 06/27/2018 dmi.bios.vendor: LENOVO dmi.bios.version: 8ZCN15WW(V1.04) dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40700 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo ideapad 130-15AST dmi.modalias: dmi:bvnLENOVO:bvr8ZCN15WW(V1.04):bd06/27/2018:svnLENOVO:pn81H5:pvrLenovoideapad130-15AST:rvnLENOVO:rnLNVNB161216:rvrSDK0J40700WIN:cvnLENOVO:ct10:cvrLenovoideapad130-15AST: dmi.product.family: ideapad 130-15AST dmi.product.name: 81H5 dmi.product.sku: LENOVO_MT_81H5_BU_idea_FM_ideapad 130-15AST dmi.product.version: Lenovo ideapad 130-15AST dmi.sys.vendor: LENOVO version.compiz: compiz 1:0.9.13.1+18.04.20180302-0ubuntu1 version.libdrm2: libdrm2 2.4.99-1ubuntu1~18.04.2 version.libgl1-mesa-dri: libgl1-mesa-dri 19.2.8-0ubuntu0~18.04.3 version.libgl1-mesa-glx: libgl1-mesa-glx 19.2.8-0ubuntu0~18.04.3 version.xserver-xorg-core: xserver-xorg-core N/A version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A version.xserver-xorg-video-intel:
[Touch-packages] [Bug 1912498] Re: Preinstall some new essential raspi packages in the official raspi images
All branches ready for review, attaching debdiff for review of the ubuntu-meta package changes as well - would appreciate some feedback. It's worth mentioning the status for hirsute. So basically in hirsute and groovy we only use the seeds for the raspi desktop images. In hirsute, with as things are right now, adding it would be hard as we'd be generating a lot of component mismatches due to pulling things from restricted, universe etc. It's a problem conceptually and for migration reasons, but for a stable series like focal it's less so. Especially that since ages we've been building raspi images from universe + multiverse packages anyway, so it's already 'bad'. ** Patch added: "ubuntu-meta_1.450.3.debdiff" https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1912498/+attachment/5454877/+files/ubuntu-meta_1.450.3.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1912498 Title: Preinstall some new essential raspi packages in the official raspi images Status in livecd-rootfs package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: Opinion Status in livecd-rootfs source package in Focal: In Progress Status in ubuntu-meta source package in Focal: In Progress Bug description: [Impact] For 20.04.2, also as part of support for some new Pi variants (CM4, Pi400), we want to preinstall some new essential packages in our raspi images such as rpi-eeprom, raspberrypi-userland etc. This can be done in two possible ways. One is the 'old way', with a single change to livecd-rootfs adding the new packages. But what we'd like to propose this time is actually a more proper way, i.e. introducing device-specific raspi seeds and a raspi meta-package that would pull in all the needed dependencies. This way is better for the future, as if we decide we want to add new packages to existing raspi installations, we can do it easily by modifying the seeds and rebuilding meta. Currently we have no way like this. So the current approach includes changes in the following components: * The ubuntu and platform seeds (git branches) * ubuntu-meta package (adding ubuntu-server-raspi) * livecd-rootfs package (installing the raspi-server task) [Test Case] After accepting all the package into -proposed (and making sure the git seed changes are merged), run a raspi arm64 and armhf build. Check if the image boots. Confirm that the new images have the following seeded: rpi-eeprom, libraspberrypi-bin, flash-kernel, pi-bluetooth. Compare manifests between a normal, previous raspi image build and the one using seeds - check if nothing has been 'dropped'. Also, check if no other image builds have been affected and still build correctly, compare image manifests. [Where problems could occur] In its current form, as the update touches some livecd-rootfs auto/config paths, it's possible that a malformed cut-paste broke some edge case scenario, so it's good if other non-raspi builds are also checked for correctness. Seed changes are less likely to break anything, but manifests should be checked in case something got dropped by accident. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1912498/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1912498] Re: Preinstall some new essential raspi packages in the official raspi images
** Merge proposal linked: https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/+merge/396583 ** Merge proposal linked: https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/+merge/396585 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1912498 Title: Preinstall some new essential raspi packages in the official raspi images Status in livecd-rootfs package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: Opinion Status in livecd-rootfs source package in Focal: In Progress Status in ubuntu-meta source package in Focal: In Progress Bug description: [Impact] For 20.04.2, also as part of support for some new Pi variants (CM4, Pi400), we want to preinstall some new essential packages in our raspi images such as rpi-eeprom, raspberrypi-userland etc. This can be done in two possible ways. One is the 'old way', with a single change to livecd-rootfs adding the new packages. But what we'd like to propose this time is actually a more proper way, i.e. introducing device-specific raspi seeds and a raspi meta-package that would pull in all the needed dependencies. This way is better for the future, as if we decide we want to add new packages to existing raspi installations, we can do it easily by modifying the seeds and rebuilding meta. Currently we have no way like this. So the current approach includes changes in the following components: * The ubuntu and platform seeds (git branches) * ubuntu-meta package (adding ubuntu-server-raspi) * livecd-rootfs package (installing the raspi-server task) [Test Case] After accepting all the package into -proposed (and making sure the git seed changes are merged), run a raspi arm64 and armhf build. Check if the image boots. Confirm that the new images have the following seeded: rpi-eeprom, libraspberrypi-bin, flash-kernel, pi-bluetooth. Compare manifests between a normal, previous raspi image build and the one using seeds - check if nothing has been 'dropped'. Also, check if no other image builds have been affected and still build correctly, compare image manifests. [Where problems could occur] In its current form, as the update touches some livecd-rootfs auto/config paths, it's possible that a malformed cut-paste broke some edge case scenario, so it's good if other non-raspi builds are also checked for correctness. Seed changes are less likely to break anything, but manifests should be checked in case something got dropped by accident. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1912498/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1912498] Re: Preinstall some new essential raspi packages in the official raspi images
** Merge proposal linked: https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/+git/livecd-rootfs/+merge/396582 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1912498 Title: Preinstall some new essential raspi packages in the official raspi images Status in livecd-rootfs package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: Opinion Status in livecd-rootfs source package in Focal: In Progress Status in ubuntu-meta source package in Focal: In Progress Bug description: [Impact] For 20.04.2, also as part of support for some new Pi variants (CM4, Pi400), we want to preinstall some new essential packages in our raspi images such as rpi-eeprom, raspberrypi-userland etc. This can be done in two possible ways. One is the 'old way', with a single change to livecd-rootfs adding the new packages. But what we'd like to propose this time is actually a more proper way, i.e. introducing device-specific raspi seeds and a raspi meta-package that would pull in all the needed dependencies. This way is better for the future, as if we decide we want to add new packages to existing raspi installations, we can do it easily by modifying the seeds and rebuilding meta. Currently we have no way like this. So the current approach includes changes in the following components: * The ubuntu and platform seeds (git branches) * ubuntu-meta package (adding ubuntu-server-raspi) * livecd-rootfs package (installing the raspi-server task) [Test Case] After accepting all the package into -proposed (and making sure the git seed changes are merged), run a raspi arm64 and armhf build. Check if the image boots. Confirm that the new images have the following seeded: rpi-eeprom, libraspberrypi-bin, flash-kernel, pi-bluetooth. Compare manifests between a normal, previous raspi image build and the one using seeds - check if nothing has been 'dropped'. Also, check if no other image builds have been affected and still build correctly, compare image manifests. [Where problems could occur] In its current form, as the update touches some livecd-rootfs auto/config paths, it's possible that a malformed cut-paste broke some edge case scenario, so it's good if other non-raspi builds are also checked for correctness. Seed changes are less likely to break anything, but manifests should be checked in case something got dropped by accident. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1912498/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 508522] Re: Add automatic switching to HSP/HFP from A2DP when a mic is needed
Daniel, do you think there would be any problem in overriding the default configuration we ship to have auto_switch=2 set by default? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/508522 Title: Add automatic switching to HSP/HFP from A2DP when a mic is needed Status in PulseAudio: New Status in chromium-browser package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: Triaged Bug description: Binary package hint: pulseaudio I'm testing a Nokia BH-905i headset (see http://www.wissel.net/blog/d6plinks/SHWL-8AZGGF ) on Ubuntu 10.10. The Bluetooth module correctly identifies the headset and the both audio profiles "HSP/ HFP Telephony duplex" and "A2DP High Fidelity Playback". For music playback only A2DP is suitable (HSP/HFP sounds like listening to music played through an old telephone). A2DP does not have an INPUT mode, so use of the headset for VoiP isn't possible. What would be needed is a separate selection to allow to select A2DP for output and HSP/HFP for input. Smartphones (a lot of them *nix based) phones do that (or they switch on the fly?). Formal structure: 1) Ubuntu 10.10 2) Pulse-Audio 1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu21.1 consisting og pluseaudio, pulseaudio-esound-compat, pulseaudio-module-bluetooth, pulseaudio-module-gconf, pulseaudio-module-x11, pulseaudio-utils 3) Select high quality audio output and still use the Bluetooth microphone 4) Had to choose: either high quality audio or "telephone quality" with microphone I can change the profile without the Bluetooth connection dropping, but that's ridiculous. E.g. listening to music, a call comes in. Then I would need to switch the profile before answering. Please note that in Windows, Mac OS, iOS, Android, and Windows Mobile it's done automatically. Check out attached screencast. ProblemType: Bug AplayDevices: List of PLAYBACK Hardware Devices card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 Architecture: i386 ArecordDevices: List of CAPTURE Hardware Devices card 0: Intel [HDA Intel], device 0: AD198x Analog [AD198x Analog] Subdevices: 2/2 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: oivasyuv 2309 F pulseaudio Card0.Amixer.info: Card hw:0 'Intel'/'HDA Intel at 0xd850 irq 17' Mixer name : 'Analog Devices AD1984A' Components : 'HDA:11d4194a,103c30e8,00100400' Controls : 22 Simple ctrls : 14 Date: Sat Jan 16 22:31:41 2010 DistroRelease: Ubuntu 9.10 InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release i386 (20091028.5) Package: pulseaudio 1:0.9.19-0ubuntu4 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-17.54-generic-pae SourcePackage: pulseaudio Uname: Linux 2.6.31-17-generic-pae i686 To manage notifications about this bug go to: https://bugs.launchpad.net/pulseaudio/+bug/508522/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1911456] Re: Can't receive files over bluetooth unless settings dialog is open
The issue is a gnome-control-center design decision one and has been reported upstream https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1189 ** Changed in: bluez (Ubuntu) Status: New => Invalid ** Bug watch added: gitlab.gnome.org/GNOME/gnome-control-center/-/issues #1189 https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1189 ** Changed in: gnome-user-share (Ubuntu) Importance: Undecided => Low ** Changed in: gnome-user-share (Ubuntu) Status: New => Triaged ** Package changed: gnome-user-share (Ubuntu) => gnome-control-center (Ubuntu) ** Also affects: gnome-control-center via https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1189 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1911456 Title: Can't receive files over bluetooth unless settings dialog is open Status in gnome-control-center: Unknown Status in bluez package in Ubuntu: Invalid Status in gnome-control-center package in Ubuntu: Triaged Bug description: On 18.04 I could send files from my phone to my laptop at any time. On 20.04 I can't get files to be accepted by the laptop over bluetooth. After much frustration and experimenting, I figured out that it will work, but only if the bluetooth settings dialog is open. If the settings dialog is not open, the incoming file is rejected. If the dialog is closed after the file transfer begins, the transfer continues but the file is discarded when the transfer is complete. This is very frustrating. I need to be able to send files (mostly photos and videos) from my phone to my laptop without having to open the settings dialog on the laptop, just like I could before upgrading. To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-control-center/+bug/1911456/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1912498] Re: Preinstall some new essential raspi packages in the official raspi images
** Also affects: ubuntu-meta (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-meta (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: livecd-rootfs (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: livecd-rootfs (Ubuntu) Importance: High => Wishlist ** Changed in: livecd-rootfs (Ubuntu Focal) Importance: Undecided => High ** Changed in: ubuntu-meta (Ubuntu Focal) Importance: Undecided => High ** Changed in: ubuntu-meta (Ubuntu) Importance: Undecided => Wishlist ** Changed in: ubuntu-meta (Ubuntu) Status: New => Opinion ** Changed in: livecd-rootfs (Ubuntu) Status: New => Opinion ** Changed in: livecd-rootfs (Ubuntu Focal) Status: New => In Progress ** Changed in: ubuntu-meta (Ubuntu Focal) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1912498 Title: Preinstall some new essential raspi packages in the official raspi images Status in livecd-rootfs package in Ubuntu: Opinion Status in ubuntu-meta package in Ubuntu: Opinion Status in livecd-rootfs source package in Focal: In Progress Status in ubuntu-meta source package in Focal: In Progress Bug description: [Impact] For 20.04.2, also as part of support for some new Pi variants (CM4, Pi400), we want to preinstall some new essential packages in our raspi images such as rpi-eeprom, raspberrypi-userland etc. This can be done in two possible ways. One is the 'old way', with a single change to livecd-rootfs adding the new packages. But what we'd like to propose this time is actually a more proper way, i.e. introducing device-specific raspi seeds and a raspi meta-package that would pull in all the needed dependencies. This way is better for the future, as if we decide we want to add new packages to existing raspi installations, we can do it easily by modifying the seeds and rebuilding meta. Currently we have no way like this. So the current approach includes changes in the following components: * The ubuntu and platform seeds (git branches) * ubuntu-meta package (adding ubuntu-server-raspi) * livecd-rootfs package (installing the raspi-server task) [Test Case] After accepting all the package into -proposed (and making sure the git seed changes are merged), run a raspi arm64 and armhf build. Check if the image boots. Confirm that the new images have the following seeded: rpi-eeprom, libraspberrypi-bin, flash-kernel, pi-bluetooth. Compare manifests between a normal, previous raspi image build and the one using seeds - check if nothing has been 'dropped'. Also, check if no other image builds have been affected and still build correctly, compare image manifests. [Where problems could occur] In its current form, as the update touches some livecd-rootfs auto/config paths, it's possible that a malformed cut-paste broke some edge case scenario, so it's good if other non-raspi builds are also checked for correctness. Seed changes are less likely to break anything, but manifests should be checked in case something got dropped by accident. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1912498/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1908502] Re: [MIR] libtiff5 dependency on libdeflate0
** Description changed: - tiff 4.1.0+git201212-1 enabled deflate support, adding libdeflate0 as a - dependency to libtiff5, making the package uninstallable. + * Availability - Therefor I uploaded 4.1.0+git201212-1ubuntu1 disabling the deflate - support to make libtiff5 installable again. + In sync with Debian, built on all architectures + https://launchpad.net/ubuntu/+source/libdeflate/1.7-1 - Either this package stays this way, or it needs a MIR for libdeflate. + * Rationale + + It's a new depends of libtiff + + * Security + + No known security issues, but due to the nature of this package, a + security review is probably needed. + + https://security-tracker.debian.org/tracker/source-package/libdeflate + https://people.canonical.com/~ubuntu-security/cve/pkg/libdeflate.html + https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libdeflate + + * Quality assurance + + The desktop team is going to subscribe to the package + + https://launchpad.net/ubuntu/+source/libdeflate/+bugs + https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libdeflate + + No open reports + + The package enables upstream tests during the build and ships basic + autopkgtests + + * Dependencies + + No universe binary dependencies + + * Standards compliance + + current 4.5.1 standards-version, debhelper compat 13, dh style simple + rules + + * Maintenance + + Upstream is active, the package is maintained in Debian and in sync for + Ubuntu ** Changed in: tiff (Ubuntu Hirsute) Assignee: Olivier Tilloy (osomon) => (unassigned) ** Changed in: tiff (Ubuntu Hirsute) Status: Confirmed => Invalid ** Summary changed: - [MIR] libtiff5 dependency on libdeflate0 + [MIR] libdeflate ** Changed in: libdeflate (Ubuntu Hirsute) Status: Incomplete => New ** Description changed: * Availability In sync with Debian, built on all architectures https://launchpad.net/ubuntu/+source/libdeflate/1.7-1 * Rationale It's a new depends of libtiff * Security - No known security issues, but due to the nature of this package, a - security review is probably needed. + There is no known security issues https://security-tracker.debian.org/tracker/source-package/libdeflate https://people.canonical.com/~ubuntu-security/cve/pkg/libdeflate.html https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libdeflate * Quality assurance The desktop team is going to subscribe to the package https://launchpad.net/ubuntu/+source/libdeflate/+bugs https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libdeflate No open reports The package enables upstream tests during the build and ships basic autopkgtests * Dependencies No universe binary dependencies * Standards compliance current 4.5.1 standards-version, debhelper compat 13, dh style simple rules * Maintenance Upstream is active, the package is maintained in Debian and in sync for Ubuntu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tiff in Ubuntu. https://bugs.launchpad.net/bugs/1908502 Title: [MIR] libdeflate Status in libdeflate package in Ubuntu: New Status in tiff package in Ubuntu: Invalid Status in libdeflate source package in Hirsute: New Status in tiff source package in Hirsute: Invalid Bug description: * Availability In sync with Debian, built on all architectures https://launchpad.net/ubuntu/+source/libdeflate/1.7-1 * Rationale It's a new depends of libtiff * Security There is no known security issues https://security-tracker.debian.org/tracker/source-package/libdeflate https://people.canonical.com/~ubuntu-security/cve/pkg/libdeflate.html https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libdeflate * Quality assurance The desktop team is going to subscribe to the package https://launchpad.net/ubuntu/+source/libdeflate/+bugs https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libdeflate No open reports The package enables upstream tests during the build and ships basic autopkgtests * Dependencies No universe binary dependencies * Standards compliance current 4.5.1 standards-version, debhelper compat 13, dh style simple rules * Maintenance Upstream is active, the package is maintained in Debian and in sync for Ubuntu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libdeflate/+bug/1908502/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1891810] Re: Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers
Ah, looks like I don't need to do anything for focal's systemd-nspawn other than add openat2 to SyscallFilters= in the .nspawn file. With that, and the seccomp from the PPA, everything seems OK - thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1891810 Title: Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers Status in libseccomp package in Ubuntu: New Status in libseccomp source package in Xenial: New Status in libseccomp source package in Bionic: New Status in libseccomp source package in Focal: New Status in libseccomp source package in Groovy: New Bug description: The version of libseccomp2 in bionic does not know about the openat2 syscall. In my particular usecase, I was trying to run podman/buildah in an nspawn container, using fuse-overlayfs. This leads to peculiar failure modes as described in this issue: https://github.com/containers/fuse-overlayfs/issues/220 This could well cause other problems, previously issues like that have affected snapd, etc. Backporting the master branch of libseccomp fixed this for me, but for an SRU a cherrypick of https://github.com/seccomp/libseccomp/commit/b3206ad5645dceda89538ea8acc984078ab697ab might be sufficient... ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libseccomp2 2.4.3-1ubuntu3.18.04.3 ProcVersionSignature: Ubuntu 5.4.0-42.46~18.04.1-generic 5.4.44 Uname: Linux 5.4.0-42-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.16 Architecture: amd64 Date: Sun Aug 16 17:35:09 2020 Dependencies: gcc-8-base 8.4.0-1ubuntu1~18.04 libc6 2.27-3ubuntu1.2 libgcc1 1:8.4.0-1ubuntu1~18.04 ProcEnviron: TERM=screen.xterm-256color PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libseccomp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1891810/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1843733] Re: fftw3 ftbfs in eoan (armhf only)
** Changed in: fftw3 (Debian) Status: Unknown => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to fftw3 in Ubuntu. https://bugs.launchpad.net/bugs/1843733 Title: fftw3 ftbfs in eoan (armhf only) Status in FFTW: New Status in fftw3 package in Ubuntu: Fix Released Status in fftw3 source package in Eoan: Won't Fix Status in fftw3 package in Debian: Confirmed Bug description: fftw3 ftbfs in eoan (armhf only). https://launchpadlibrarian.net/441265031/buildlog_ubuntu-eoan- armhf.fftw3_3.3.8-2_BUILDING.txt.gz ( cd tests ; /usr/bin/make smallcheck ) make[1]: Entering directory '/<>/tests' perl -w ./check.pl -r -c=1 -v `pwd`/bench Executing "/<>/tests/bench --verbose=1 --verify 'ok7e10x12bv29' --verify 'ik7e10x12bv29' --verify '//obr2304' --verify '//ibr2304' --verify '//ofr2304' --verify '//ifr2304' --verify 'obr2304' --verify 'ibr2304' --verify 'ofr2304' --verify 'ifr2304' --verify '//obc2304' --verify '//ibc2304' --verify '//ofc2304' --verify '//ifc2304' --verify 'obc2304' --verify 'ibc2304' --verify 'ofc2304' --verify 'ifc2304'" ok7e10x12bv29 1.71318e-07 1.44516e-06 2.00887e-07 ik7e10x12bv29 1.66737e-07 1.44901e-06 1.76717e-07 Segmentation fault (core dumped) FAILED /<>/tests/bench: --verify 'ok7e10x12bv29' --verify 'ik7e10x12bv29' --verify '//obr2304' --verify '//ibr2304' --verify '//ofr2304' --verify '//ifr2304' --verify 'obr2304' --verify 'ibr2304' --verify 'ofr2304' --verify 'ifr2304' --verify '//obc2304' --verify '//ibc2304' --verify '//ofc2304' --verify '//ifc2304' --verify 'obc2304' --verify 'ibc2304' --verify 'ofc2304' --verify 'ifc2304' make[1]: *** [Makefile:723: smallcheck] Error 1 make[1]: Leaving directory '/<>/tests' To manage notifications about this bug go to: https://bugs.launchpad.net/fftw3/+bug/1843733/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1912491] [NEW] Incorrect processing of network name and time messages from operator leads to multiple issues
Public bug reported: Ubuntu version: 20.04.1 LTS modemmanager version: 1.12.8-1 modem-manager-gui version: 0.0.19.1-2 What I expected to happen: SMSes in the GUI have correct timestamps; the operator name is reported correctly in the GUI; USSD communications work correctly in the GUI and through the mmcli interface. What is actually happening: SMSes in the GUI have no timestamps; the operator name disappears from the GUI; USSD communications randomly fail both in the GUI and on the commandine. I understand that the maintainers of this package are not responsible for the GUI application, but below I explain my rationale for filing this bug against this package and why I think these issues are related. I use modemmanager and modem-manager-gui to manage a GSM modem in my Thinkpad. In 18.04 everything worked correctly, but since I upgraded to 20.04 I have noticed multiple issues which I believe may have the same underlying cause: 1. Received SMSes logged in modem-manager-gui no longer have timestamps. This may be the same issue as is reported here in the Fedora package, since the upstream version appears to be the same: https://bugzilla.redhat.com/show_bug.cgi?id=1839752 2. When I start up modem-manager-gui, I can see the operator name displayed correctly in the info tab, but after some time it disappears, and I see "Searching" as the value in the "Registration" field. 3. This is the most critical issue and the primary reason that I'm reporting this. When I interact with any USSD menu, I experience intermittent "Invalid USSD message received" errors which disrupt any sufficiently long chain of USSD interactions and make it near-impossible to complete certain tasks via USSD. It's only through extensive trial and error that I found that sometimes it's possible to retry the same reply successfully, although this is very sensitive to timeouts. After initially observing this behaviour in modem-manager-gui I tried to use the mmcli interface on the commandline to access these USSD menus, and found the same erratic behaviour. This is why I'm filing this bug against the modemmanager package. The exact error messages are always in this format: error: couldn't send response in USSD session: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Invalid USSD message received: '^NWNAME: "MTN-SA","","65510" ^NWTIME: 21/01/20,13:13:31+08,0'' My layperson's hypothesis is that these are messages from the operator containing the name of the network and the system time of the network, but modemmanager is not expecting them and therefore not processing them correctly for some reason, which is why 1) the network name and time is not being set in modem-manager-gui and 2) USSD communications are being disrupted by unexpected messages. I'd be happy to help to debug this further if there is any other information that I can provide. ** Affects: modemmanager (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/1912491 Title: Incorrect processing of network name and time messages from operator leads to multiple issues Status in modemmanager package in Ubuntu: New Bug description: Ubuntu version: 20.04.1 LTS modemmanager version: 1.12.8-1 modem-manager-gui version: 0.0.19.1-2 What I expected to happen: SMSes in the GUI have correct timestamps; the operator name is reported correctly in the GUI; USSD communications work correctly in the GUI and through the mmcli interface. What is actually happening: SMSes in the GUI have no timestamps; the operator name disappears from the GUI; USSD communications randomly fail both in the GUI and on the commandine. I understand that the maintainers of this package are not responsible for the GUI application, but below I explain my rationale for filing this bug against this package and why I think these issues are related. I use modemmanager and modem-manager-gui to manage a GSM modem in my Thinkpad. In 18.04 everything worked correctly, but since I upgraded to 20.04 I have noticed multiple issues which I believe may have the same underlying cause: 1. Received SMSes logged in modem-manager-gui no longer have timestamps. This may be the same issue as is reported here in the Fedora package, since the upstream version appears to be the same: https://bugzilla.redhat.com/show_bug.cgi?id=1839752 2. When I start up modem-manager-gui, I can see the operator name displayed correctly in the info tab, but after some time it disappears, and I see "Searching" as the value in the "Registration" field. 3. This is the most critical issue and the primary reason that I'm reporting this. When I interact with any USSD menu, I experience intermittent "Invalid USSD message received" errors which
[Touch-packages] [Bug 1910537] Re: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer)
BTW: what would pulseaudio / ubuntu pass out on HDMI if I do play two audio sources, one with 44.1 and one with 48 kHz, at the same time? Any tool or method to check what's going out to HDMI? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1910537 Title: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer) Status in pulseaudio package in Ubuntu: Incomplete Bug description: This is a complicated thing. I have a very specific problem with audio output on HDMI. I want to use an older notebook with Lubuntu 20.04 as a video source for libreoffice slides, videos etc. to feed them over HDMI into a Blackmagic Design ATEM Mini Pro ISO (video mixer) as one input. Configured on the desktop just like a second screen or beamer. Video works well and rock-stable, no problem at all. But not audio. Although I carefully configured audio with pavucontrol to be directed to the HDMI output, the ATEM switcher does not recognize it as an audio source (like when connecting a digital camera) and does not receive or indicate any audio input. Note: But when I use the very same computer, same HDMI cable, same video with a cheap chinese portable LCD screen with speakers (i.e. pull the cable from the ATEM and plug it into the screen) it immediately starts playing both video and audio. So there is evidence that the ubuntu notebook definitely passes it's sound to HDMI and there's really an audio signal on the HDMI. I've opened a bug at Blackmagic Design, and got their reply that they can't help and have never heard of such a problem before. Their guess is that the linux notebook is not setting EDID configuration correctly and thus not recognized by the ATEM, while the cheap LCD screen propably does not care about EDID and just plays everything, therefore a wrong EDID information would not matter. Although I have decades of experience with Linux, I am not too familiar with details of HDMI and the internals of the X11 driver, so I'm not sure where to start debugging, not even, whether this is a problem of Xorg/X11 or pulseaudio. I've checked this with another notebook with much more recent (intel) hardware, which offers dozens of HDMI audio options in the pavucontrol selection menu, but same problem: Video works, but the ATEM does not recognize it as a audio source. Blackmagic Design (they're good in Windows and MacOS, but not Linux) recommended to use an edid manager, whatever this means. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-58.64-generic 5.4.73 Uname: Linux 5.4.0-58-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: LXQt Date: Thu Jan 7 13:16:26 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DpkgLog: ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0742] InstallationDate: Installed on 2020-05-16 (235 days ago) InstallationMedia: Lubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 04f2:b336 Chicony Electronics Co., Ltd Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Acer AO756 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-58-generic root=UUID=a69345e2-b61e-4d25-baab-b23f75273af6 ro quiet cryptdevice=UUID=d132b97b-f47a-4432-88b5-42aca187b9ff:luks-d132b97b-f47a-4432-88b5-42aca187b9ff root=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff resume=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/19/2012 dmi.bios.vendor: Acer dmi.bios.version: V1.05 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: Mimic dmi.board.vendor: Acer dmi.board.version: Type2 - Board Version dmi.chassis.type: 10 dmi.chassis.vendor: Acer dmi.chassis.version: V1.05 dmi.modalias: dmi:bvnAcer:bvrV1.05:bd07/19/2012:svnAcer:pnAO756:pvrV1.05:rvnAcer:rnMimic:rvrType2-BoardVersion:cvnAcer:ct10:cvrV1.05: dmi.product.family: Type1Family dmi.product.name: AO756 dmi.product.sku: Type1Sku0 dmi.product.version: V1.05
[Touch-packages] [Bug 1910537] Re: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer)
I think I've found the problem. @Uldis: please check and verify It doesn't work with a video with Channel(s) : 1 channel Channel layout : C Sampling rate: 44.1 kHz but it works when playing a video with Channel(s) : 2 channels Sampling rate: 48.0 kHz So maybe it's the sampling rate. Probably Linux outputs a sampling rate conforming with the current source, and the ATEM seems to expect 48kHz, while accepting everything on HDMI1, but getting it scrambled and distorted, since there's not enough data (8% missing), while the input on HDMI2-4 simply doesn't match the expectations. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1910537 Title: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer) Status in pulseaudio package in Ubuntu: Incomplete Bug description: This is a complicated thing. I have a very specific problem with audio output on HDMI. I want to use an older notebook with Lubuntu 20.04 as a video source for libreoffice slides, videos etc. to feed them over HDMI into a Blackmagic Design ATEM Mini Pro ISO (video mixer) as one input. Configured on the desktop just like a second screen or beamer. Video works well and rock-stable, no problem at all. But not audio. Although I carefully configured audio with pavucontrol to be directed to the HDMI output, the ATEM switcher does not recognize it as an audio source (like when connecting a digital camera) and does not receive or indicate any audio input. Note: But when I use the very same computer, same HDMI cable, same video with a cheap chinese portable LCD screen with speakers (i.e. pull the cable from the ATEM and plug it into the screen) it immediately starts playing both video and audio. So there is evidence that the ubuntu notebook definitely passes it's sound to HDMI and there's really an audio signal on the HDMI. I've opened a bug at Blackmagic Design, and got their reply that they can't help and have never heard of such a problem before. Their guess is that the linux notebook is not setting EDID configuration correctly and thus not recognized by the ATEM, while the cheap LCD screen propably does not care about EDID and just plays everything, therefore a wrong EDID information would not matter. Although I have decades of experience with Linux, I am not too familiar with details of HDMI and the internals of the X11 driver, so I'm not sure where to start debugging, not even, whether this is a problem of Xorg/X11 or pulseaudio. I've checked this with another notebook with much more recent (intel) hardware, which offers dozens of HDMI audio options in the pavucontrol selection menu, but same problem: Video works, but the ATEM does not recognize it as a audio source. Blackmagic Design (they're good in Windows and MacOS, but not Linux) recommended to use an edid manager, whatever this means. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-58.64-generic 5.4.73 Uname: Linux 5.4.0-58-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: LXQt Date: Thu Jan 7 13:16:26 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DpkgLog: ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0742] InstallationDate: Installed on 2020-05-16 (235 days ago) InstallationMedia: Lubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 04f2:b336 Chicony Electronics Co., Ltd Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Acer AO756 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-58-generic root=UUID=a69345e2-b61e-4d25-baab-b23f75273af6 ro quiet cryptdevice=UUID=d132b97b-f47a-4432-88b5-42aca187b9ff:luks-d132b97b-f47a-4432-88b5-42aca187b9ff root=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff resume=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date:
[Touch-packages] [Bug 1910537] Re: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer)
BTW, same with the older ATEM Mini (non-Pro) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1910537 Title: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer) Status in pulseaudio package in Ubuntu: Incomplete Bug description: This is a complicated thing. I have a very specific problem with audio output on HDMI. I want to use an older notebook with Lubuntu 20.04 as a video source for libreoffice slides, videos etc. to feed them over HDMI into a Blackmagic Design ATEM Mini Pro ISO (video mixer) as one input. Configured on the desktop just like a second screen or beamer. Video works well and rock-stable, no problem at all. But not audio. Although I carefully configured audio with pavucontrol to be directed to the HDMI output, the ATEM switcher does not recognize it as an audio source (like when connecting a digital camera) and does not receive or indicate any audio input. Note: But when I use the very same computer, same HDMI cable, same video with a cheap chinese portable LCD screen with speakers (i.e. pull the cable from the ATEM and plug it into the screen) it immediately starts playing both video and audio. So there is evidence that the ubuntu notebook definitely passes it's sound to HDMI and there's really an audio signal on the HDMI. I've opened a bug at Blackmagic Design, and got their reply that they can't help and have never heard of such a problem before. Their guess is that the linux notebook is not setting EDID configuration correctly and thus not recognized by the ATEM, while the cheap LCD screen propably does not care about EDID and just plays everything, therefore a wrong EDID information would not matter. Although I have decades of experience with Linux, I am not too familiar with details of HDMI and the internals of the X11 driver, so I'm not sure where to start debugging, not even, whether this is a problem of Xorg/X11 or pulseaudio. I've checked this with another notebook with much more recent (intel) hardware, which offers dozens of HDMI audio options in the pavucontrol selection menu, but same problem: Video works, but the ATEM does not recognize it as a audio source. Blackmagic Design (they're good in Windows and MacOS, but not Linux) recommended to use an edid manager, whatever this means. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-58.64-generic 5.4.73 Uname: Linux 5.4.0-58-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: LXQt Date: Thu Jan 7 13:16:26 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DpkgLog: ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0742] InstallationDate: Installed on 2020-05-16 (235 days ago) InstallationMedia: Lubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 04f2:b336 Chicony Electronics Co., Ltd Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Acer AO756 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-58-generic root=UUID=a69345e2-b61e-4d25-baab-b23f75273af6 ro quiet cryptdevice=UUID=d132b97b-f47a-4432-88b5-42aca187b9ff:luks-d132b97b-f47a-4432-88b5-42aca187b9ff root=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff resume=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/19/2012 dmi.bios.vendor: Acer dmi.bios.version: V1.05 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: Mimic dmi.board.vendor: Acer dmi.board.version: Type2 - Board Version dmi.chassis.type: 10 dmi.chassis.vendor: Acer dmi.chassis.version: V1.05 dmi.modalias: dmi:bvnAcer:bvrV1.05:bd07/19/2012:svnAcer:pnAO756:pvrV1.05:rvnAcer:rnMimic:rvrType2-BoardVersion:cvnAcer:ct10:cvrV1.05: dmi.product.family: Type1Family dmi.product.name: AO756 dmi.product.sku: Type1Sku0 dmi.product.version: V1.05 dmi.sys.vendor: Acer version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2 version.libgl1-mesa-dri: libgl1-mesa-dri 20.0.8-0ubuntu1~20.04.1
[Touch-packages] [Bug 1910537] Re: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer)
Confirmed: distorted sound on HDMI1 no sound on HDMI2-4 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1910537 Title: HDMI audio not working on Blackmagic Design ATEM Mini Pro ISO (video mixer) Status in pulseaudio package in Ubuntu: Incomplete Bug description: This is a complicated thing. I have a very specific problem with audio output on HDMI. I want to use an older notebook with Lubuntu 20.04 as a video source for libreoffice slides, videos etc. to feed them over HDMI into a Blackmagic Design ATEM Mini Pro ISO (video mixer) as one input. Configured on the desktop just like a second screen or beamer. Video works well and rock-stable, no problem at all. But not audio. Although I carefully configured audio with pavucontrol to be directed to the HDMI output, the ATEM switcher does not recognize it as an audio source (like when connecting a digital camera) and does not receive or indicate any audio input. Note: But when I use the very same computer, same HDMI cable, same video with a cheap chinese portable LCD screen with speakers (i.e. pull the cable from the ATEM and plug it into the screen) it immediately starts playing both video and audio. So there is evidence that the ubuntu notebook definitely passes it's sound to HDMI and there's really an audio signal on the HDMI. I've opened a bug at Blackmagic Design, and got their reply that they can't help and have never heard of such a problem before. Their guess is that the linux notebook is not setting EDID configuration correctly and thus not recognized by the ATEM, while the cheap LCD screen propably does not care about EDID and just plays everything, therefore a wrong EDID information would not matter. Although I have decades of experience with Linux, I am not too familiar with details of HDMI and the internals of the X11 driver, so I'm not sure where to start debugging, not even, whether this is a problem of Xorg/X11 or pulseaudio. I've checked this with another notebook with much more recent (intel) hardware, which offers dozens of HDMI audio options in the pavucontrol selection menu, but same problem: Video works, but the ATEM does not recognize it as a audio source. Blackmagic Design (they're good in Windows and MacOS, but not Linux) recommended to use an edid manager, whatever this means. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: xorg 1:7.7+19ubuntu14 ProcVersionSignature: Ubuntu 5.4.0-58.64-generic 5.4.73 Uname: Linux 5.4.0-58-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.14 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: skip CompositorRunning: None CurrentDesktop: LXQt Date: Thu Jan 7 13:16:26 2021 DistUpgraded: Fresh install DistroCodename: focal DistroVariant: ubuntu DpkgLog: ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] 2nd Generation Core Processor Family Integrated Graphics Controller [1025:0742] InstallationDate: Installed on 2020-05-16 (235 days ago) InstallationMedia: Lubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) Lsusb: Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 04f2:b336 Chicony Electronics Co., Ltd Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Acer AO756 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-58-generic root=UUID=a69345e2-b61e-4d25-baab-b23f75273af6 ro quiet cryptdevice=UUID=d132b97b-f47a-4432-88b5-42aca187b9ff:luks-d132b97b-f47a-4432-88b5-42aca187b9ff root=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff resume=/dev/mapper/luks-d132b97b-f47a-4432-88b5-42aca187b9ff splash vt.handoff=7 SourcePackage: xorg UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/19/2012 dmi.bios.vendor: Acer dmi.bios.version: V1.05 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: Mimic dmi.board.vendor: Acer dmi.board.version: Type2 - Board Version dmi.chassis.type: 10 dmi.chassis.vendor: Acer dmi.chassis.version: V1.05 dmi.modalias: dmi:bvnAcer:bvrV1.05:bd07/19/2012:svnAcer:pnAO756:pvrV1.05:rvnAcer:rnMimic:rvrType2-BoardVersion:cvnAcer:ct10:cvrV1.05: dmi.product.family: Type1Family dmi.product.name: AO756 dmi.product.sku: Type1Sku0 dmi.product.version: V1.05 dmi.sys.vendor: Acer version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.101-2 version.libgl1-mesa-dri: libgl1-mesa-dri
[Touch-packages] [Bug 1891810] Re: Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers
OK, this is getting complicated. seccomp 2.5.0 and systemd-nspawn both have bugs which when combined cause most/all syscall filters to actually be disabled! See https://github.com/seccomp/libseccomp/issues/273#issuecomment-668458070 So I think your new packages are probably OK, but as they pull in 2.5.1 my system is breaking because the version of systemd-nspawn I'm using (default version from focal) is apparently still old enough not to include openat2() (Yes, reading upthread it seems I knew all of this in August and have managed to forget it over the last few months!) I will backport/patch systemd-nspawn and re-test these packages when time permits.. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1891810 Title: Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers Status in libseccomp package in Ubuntu: New Status in libseccomp source package in Xenial: New Status in libseccomp source package in Bionic: New Status in libseccomp source package in Focal: New Status in libseccomp source package in Groovy: New Bug description: The version of libseccomp2 in bionic does not know about the openat2 syscall. In my particular usecase, I was trying to run podman/buildah in an nspawn container, using fuse-overlayfs. This leads to peculiar failure modes as described in this issue: https://github.com/containers/fuse-overlayfs/issues/220 This could well cause other problems, previously issues like that have affected snapd, etc. Backporting the master branch of libseccomp fixed this for me, but for an SRU a cherrypick of https://github.com/seccomp/libseccomp/commit/b3206ad5645dceda89538ea8acc984078ab697ab might be sufficient... ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libseccomp2 2.4.3-1ubuntu3.18.04.3 ProcVersionSignature: Ubuntu 5.4.0-42.46~18.04.1-generic 5.4.44 Uname: Linux 5.4.0-42-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.16 Architecture: amd64 Date: Sun Aug 16 17:35:09 2020 Dependencies: gcc-8-base 8.4.0-1ubuntu1~18.04 libc6 2.27-3ubuntu1.2 libgcc1 1:8.4.0-1ubuntu1~18.04 ProcEnviron: TERM=screen.xterm-256color PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libseccomp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1891810/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1891810] Re: Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers
Attached is a trivial test case, needs to be run in a container by a container manager that uses seccomp for syscall filtering (e.g. nspawn.) It should either silently succeed or print "openat2: Function not implemented" ; if seccomp combined with the container manager (e.g. nspawn) blocks the openat2 call, it will instead print "openat2: Operation not permitted." ** Attachment added: "Trivial test case" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1891810/+attachment/5454861/+files/openat.c -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1891810 Title: Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers Status in libseccomp package in Ubuntu: New Status in libseccomp source package in Xenial: New Status in libseccomp source package in Bionic: New Status in libseccomp source package in Focal: New Status in libseccomp source package in Groovy: New Bug description: The version of libseccomp2 in bionic does not know about the openat2 syscall. In my particular usecase, I was trying to run podman/buildah in an nspawn container, using fuse-overlayfs. This leads to peculiar failure modes as described in this issue: https://github.com/containers/fuse-overlayfs/issues/220 This could well cause other problems, previously issues like that have affected snapd, etc. Backporting the master branch of libseccomp fixed this for me, but for an SRU a cherrypick of https://github.com/seccomp/libseccomp/commit/b3206ad5645dceda89538ea8acc984078ab697ab might be sufficient... ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libseccomp2 2.4.3-1ubuntu3.18.04.3 ProcVersionSignature: Ubuntu 5.4.0-42.46~18.04.1-generic 5.4.44 Uname: Linux 5.4.0-42-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.16 Architecture: amd64 Date: Sun Aug 16 17:35:09 2020 Dependencies: gcc-8-base 8.4.0-1ubuntu1~18.04 libc6 2.27-3ubuntu1.2 libgcc1 1:8.4.0-1ubuntu1~18.04 ProcEnviron: TERM=screen.xterm-256color PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libseccomp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1891810/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1901528] Re: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip)
Thx Ilya for the verification on groovy - I'm adjusting the tags accordingly ... ** Tags removed: verification-needed verification-needed-groovy ** Tags added: verification-done verification-done-groovy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1901528 Title: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip) Status in Ubuntu on IBM z Systems: Fix Committed Status in gzip package in Ubuntu: Fix Released Status in zlib package in Ubuntu: Invalid Status in gzip source package in Groovy: Fix Committed Status in zlib source package in Groovy: Invalid Bug description: When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB. This problem does not happen when running gzip against a single file at a time. It only happens when you provide multiple files as gzip arguments. So this works whether zlib acceleration is enabled or not: for file in file1 file2; do gzip $file ; done But this fails (when zlib acceleration is enabled): gzip file1 file2 The patch to fix this has been accepted upstream: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=be0a534ba2b6e77da289de8da79e70843b1028cc [Impact] * With zlib acceleration enabled, attempting to compress multiple files over 5MB would cause a segmentation fault. * The files could still be compressed in separate commands [Test Case] * Create two files that are larger than 5MB * Enable zlib acceleration (z15 hardware required) * Run the command gzip * NOTE: we do not have access to z15 hardware and therefore are relying on IBM to verify this fix [Where problems could occur] * Due to lack of testing resources, it's possible the bug has not been fully fixed, and the segmentation fault could still occur. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1901528/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1912256] Re: Missing channel binding prevents authentication to ActiveDirectory
I should maybe add the following detail: Channel binding, from all I can tell, is only available via TLS (even conceptually). That is, the issue mentioned in the bug report only happens when using ldaps. In certain cases, it is therefore possible to work around the lack of channel binding by _not using TLS_. Typically, you'll have to set minssf to >=1 if TLS is not used, due to security settings of the LDAP server (AD DC). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1912256 Title: Missing channel binding prevents authentication to ActiveDirectory Status in openldap package in Ubuntu: New Bug description: > Are you uncertain if your issue is really a bug? Effect is an authentication error. Root case is a "missing feature" (see below) and requires updating dependencies, downporting. > If you are certain this is a bug please include the source package the bug is in. It's in the interaction between three libraries: openldap, cyrus-sasl, krb5 > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu Broken in 18.04 and also in 20.10 (I guess it's also broken in anything inbetween) > 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1 ldap-utils: 2.4.53+dfsg-1ubuntu1.2 libgssapi-krb5-2: 1.17-10ubuntu0.1 > 3) What you expected to happen # kinit $ export LDAPSASL_CBINDING=tls-endpoint $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps:// SASL/GSSAPI authentication started SASL username: SASL SSF: 0 u: > 4) What happened instead SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C090597, comment: AcceptSecurityContext error, data 80090346, v4563 --- Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends activating this as a required feature. See https://access.redhat.com/articles/4661861 Authentication to any AD DC which has mandatory channel binding fails. Channel binding requires at least an update to cyrus-sasl, which is not in any release as far as I can see: https://github.com/cyrusimap/cyrus- sasl/commit/975edbb69070eba6b035f08776de771a129cfb57 It also needs this commit in openldap: https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6 Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5). RH also mentions it needs up-to-date krb5 libraries, but I can't tell what minimum version this needs. I can build all libraries from source, current master (except for krb5 where I've used 1.18.3) and can confirm that channel binding works when using those libraries. I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I would guess by extension also SSSD and realmd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1912256/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1891810] Re: Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers
Hmm, I tested with libseccomp2_2.5.1-0ubuntu0.20.04.1_test4_amd64.deb from the PPA and it doesn't seem to fix the openat2 problem - just realised I should have added I'm now using focal not bionic for my container host.. will try to investigate why once I'm back on my desktop machine. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1891810 Title: Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers Status in libseccomp package in Ubuntu: New Status in libseccomp source package in Xenial: New Status in libseccomp source package in Bionic: New Status in libseccomp source package in Focal: New Status in libseccomp source package in Groovy: New Bug description: The version of libseccomp2 in bionic does not know about the openat2 syscall. In my particular usecase, I was trying to run podman/buildah in an nspawn container, using fuse-overlayfs. This leads to peculiar failure modes as described in this issue: https://github.com/containers/fuse-overlayfs/issues/220 This could well cause other problems, previously issues like that have affected snapd, etc. Backporting the master branch of libseccomp fixed this for me, but for an SRU a cherrypick of https://github.com/seccomp/libseccomp/commit/b3206ad5645dceda89538ea8acc984078ab697ab might be sufficient... ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: libseccomp2 2.4.3-1ubuntu3.18.04.3 ProcVersionSignature: Ubuntu 5.4.0-42.46~18.04.1-generic 5.4.44 Uname: Linux 5.4.0-42-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.16 Architecture: amd64 Date: Sun Aug 16 17:35:09 2020 Dependencies: gcc-8-base 8.4.0-1ubuntu1~18.04 libc6 2.27-3ubuntu1.2 libgcc1 1:8.4.0-1ubuntu1~18.04 ProcEnviron: TERM=screen.xterm-256color PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: libseccomp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1891810/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1901528] Comment bridged from LTC Bugzilla
--- Comment From i...@de.ibm.com 2021-01-20 05:23 EDT--- s390x build of gzip 1.10-2ubuntu1.1 fixes the issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to zlib in Ubuntu. https://bugs.launchpad.net/bugs/1901528 Title: [Ubuntu 20.10] - When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB (gzip) Status in Ubuntu on IBM z Systems: Fix Committed Status in gzip package in Ubuntu: Fix Released Status in zlib package in Ubuntu: Invalid Status in gzip source package in Groovy: Fix Committed Status in zlib source package in Groovy: Invalid Bug description: When zlib acceleration is enabled, gzip fails when given multiple files larger than 5KB. This problem does not happen when running gzip against a single file at a time. It only happens when you provide multiple files as gzip arguments. So this works whether zlib acceleration is enabled or not: for file in file1 file2; do gzip $file ; done But this fails (when zlib acceleration is enabled): gzip file1 file2 The patch to fix this has been accepted upstream: https://git.savannah.gnu.org/cgit/gzip.git/commit/?id=be0a534ba2b6e77da289de8da79e70843b1028cc [Impact] * With zlib acceleration enabled, attempting to compress multiple files over 5MB would cause a segmentation fault. * The files could still be compressed in separate commands [Test Case] * Create two files that are larger than 5MB * Enable zlib acceleration (z15 hardware required) * Run the command gzip * NOTE: we do not have access to z15 hardware and therefore are relying on IBM to verify this fix [Where problems could occur] * Due to lack of testing resources, it's possible the bug has not been fully fixed, and the segmentation fault could still occur. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1901528/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1903995] Re: upower report wrong battery percentage for Logitech Unify devices
Sorry for being slow in getting back to you about this.
I believe that this should be fixed by this upstream commit, which will
be in the 5.12 kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/commit/?h
=for-next=e037acf0b1aed31cb5f3b09ccb602b4768c133d5
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upower in Ubuntu.
https://bugs.launchpad.net/bugs/1903995
Title:
upower report wrong battery percentage for Logitech Unify devices
Status in upower package in Ubuntu:
Triaged
Bug description:
The battery percentage reported by upower for Logitech devices
connected using Unify receiver are wrong. Below are the results for
two devices: Mouse and Keyboard:
* Battery percentages reported by Unify receiver using Solaar:
$ solaar show | grep -iP "^(( \d: )|(.*batt.*))"
1: Wireless Keyboard K270(unifying)
4: BATTERY STATUS {1000}
Battery: 70%, discharging.
2: Wireless Mouse MX Master
7: BATTERY STATUS {1000}
Battery: 20%, discharging.
* Battery percentages reported by upower:
$ upower -i /org/freedesktop/UPower/devices/keyboard_hidpp_battery_0
native-path: hidpp_battery_0
model:Wireless Keyboard K270
serial: 4003-1a-39-5f-c1
power supply: no
updated: Thu 12 Nov 2020 13:59:18 CET (119 seconds ago)
has history: yes
has statistics: yes
keyboard
present: yes
rechargeable:yes
state: discharging
warning-level: none
battery-level: normal
percentage: 55% (should be ignored)
icon-name: 'battery-low-symbolic'
$ upower -i /org/freedesktop/UPower/devices/mouse_hidpp_battery_1
native-path: hidpp_battery_1
model:Wireless Mouse MX Master
serial: 4071-f8-eb-bf-d1
power supply: no
updated: Thu 12 Nov 2020 14:03:14 CET (27 seconds ago)
has history: yes
has statistics: yes
mouse
present: yes
rechargeable:yes
state: discharging
warning-level: low
battery-level: low
percentage: 10% (should be ignored)
icon-name: 'battery-caution-symbolic'
Basically the difference is big so I'm getting a lot of notifications
related to low battery even if the battery is OK:
* Mouse, upower: 10%real (Solaar): 20%
* Keyboard: upower: 70%real (Solaar): 55%
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: upower 0.99.11-1build2
ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
Uname: Linux 5.4.0-53-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.11
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Thu Nov 12 13:58:35 2020
InstallationDate: Installed on 2020-04-19 (206 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200417)
SourcePackage: upower
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.apport.crashdb.conf: 2020-06-17T11:02:56.934699
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1903995/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1779657] Re: apt autoremove not removing old kernels
No manually installed kernels. And these were not meta packages. But since I am on 20.04 now, this is not affecting me anymore. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1779657 Title: apt autoremove not removing old kernels Status in apt package in Ubuntu: Incomplete Bug description: I noticed that apt autoremove stopped removing old kernels recently. Currently I have 6 installed and apt autoremove does not try to remove old ones: $ sudo apt autoremove --purge Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. In /etc/apt/apt.conf.d/01autoremove-kernels it is said to only keep last three versions: # list of different kernel versions: 4.15.0-24.26~16.04.1 4.15.0-23.25~16.04.1 4.15.0-22.24~16.04.1 4.15.0-15.16~16.04.1 4.13.0-45.50~16.04.1 4.13.0-43.48~16.04.1 # Installing kernel: 4.13.0-45.50~16.04.1 (4.13.0-45-generic) # Running kernel: 4.15.0-23.25~16.04.1 (4.15.0-23-generic) # Last kernel: 4.15.0-24.26~16.04.1 # Previous kernel: 4.15.0-23.25~16.04.1 # Kernel versions list to keep: 4.13.0-45.50~16.04.1 4.15.0-23.25~16.04.1 4.15.0-24.26~16.04.1 # Kernel packages (version part) to protect: 4\.13\.0-45-generic 4\.15\.0-23-generic 4\.15\.0-24-generic It was working fine previously and I didn't change anything that could break this functionality. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: apt 1.2.26 ProcVersionSignature: Ubuntu 4.15.0-24.26~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-24-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CurrentDesktop: Unity Date: Mon Jul 2 14:12:03 2018 InstallationDate: Installed on 2018-01-19 (164 days ago) InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1779657/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1779657] Re: apt autoremove not removing old kernels
Sean: What you quoted is the part that tells apt to not remove kernel _meta_ packages. Individual kernels are automatically removed subject to the kernel autoremoval helper script output in /etc/apt/apt.conf.d /01autoremove-kernels; which keeps up to 3 kernels around. Note that this stops working if you manually install a certain kernel version, as it only works for automatically installed kernel versions. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1779657 Title: apt autoremove not removing old kernels Status in apt package in Ubuntu: Incomplete Bug description: I noticed that apt autoremove stopped removing old kernels recently. Currently I have 6 installed and apt autoremove does not try to remove old ones: $ sudo apt autoremove --purge Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. In /etc/apt/apt.conf.d/01autoremove-kernels it is said to only keep last three versions: # list of different kernel versions: 4.15.0-24.26~16.04.1 4.15.0-23.25~16.04.1 4.15.0-22.24~16.04.1 4.15.0-15.16~16.04.1 4.13.0-45.50~16.04.1 4.13.0-43.48~16.04.1 # Installing kernel: 4.13.0-45.50~16.04.1 (4.13.0-45-generic) # Running kernel: 4.15.0-23.25~16.04.1 (4.15.0-23-generic) # Last kernel: 4.15.0-24.26~16.04.1 # Previous kernel: 4.15.0-23.25~16.04.1 # Kernel versions list to keep: 4.13.0-45.50~16.04.1 4.15.0-23.25~16.04.1 4.15.0-24.26~16.04.1 # Kernel packages (version part) to protect: 4\.13\.0-45-generic 4\.15\.0-23-generic 4\.15\.0-24-generic It was working fine previously and I didn't change anything that could break this functionality. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: apt 1.2.26 ProcVersionSignature: Ubuntu 4.15.0-24.26~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-24-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CurrentDesktop: Unity Date: Mon Jul 2 14:12:03 2018 InstallationDate: Installed on 2018-01-19 (164 days ago) InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1779657/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1779657] Re: apt autoremove not removing old kernels
Probably the kernels were manually installed for some reason, but there's certainly not enough to act on this. Needs at least /var/lib/apt/extended_states /var/lib/dpkg/status /etc/apt/apt.conf.d /01autoremove-kernels to be able to investigate what happened here. ** Changed in: apt (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1779657 Title: apt autoremove not removing old kernels Status in apt package in Ubuntu: Incomplete Bug description: I noticed that apt autoremove stopped removing old kernels recently. Currently I have 6 installed and apt autoremove does not try to remove old ones: $ sudo apt autoremove --purge Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. In /etc/apt/apt.conf.d/01autoremove-kernels it is said to only keep last three versions: # list of different kernel versions: 4.15.0-24.26~16.04.1 4.15.0-23.25~16.04.1 4.15.0-22.24~16.04.1 4.15.0-15.16~16.04.1 4.13.0-45.50~16.04.1 4.13.0-43.48~16.04.1 # Installing kernel: 4.13.0-45.50~16.04.1 (4.13.0-45-generic) # Running kernel: 4.15.0-23.25~16.04.1 (4.15.0-23-generic) # Last kernel: 4.15.0-24.26~16.04.1 # Previous kernel: 4.15.0-23.25~16.04.1 # Kernel versions list to keep: 4.13.0-45.50~16.04.1 4.15.0-23.25~16.04.1 4.15.0-24.26~16.04.1 # Kernel packages (version part) to protect: 4\.13\.0-45-generic 4\.15\.0-23-generic 4\.15\.0-24-generic It was working fine previously and I didn't change anything that could break this functionality. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: apt 1.2.26 ProcVersionSignature: Ubuntu 4.15.0-24.26~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-24-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CurrentDesktop: Unity Date: Mon Jul 2 14:12:03 2018 InstallationDate: Installed on 2018-01-19 (164 days ago) InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801) SourcePackage: apt UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1779657/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1793472] Re: [wishlist] Add mdadm into desktop by default
Intel VROC (Intel Virtual RAID on CPU) needs mdadm to install on it per OEM test result. Intel reference document like below does mention that: https://www.intel.com/content/dam/support/us/en/documents/memory-and- storage/ssd-software/Linux_VROC_6-0_User_Guide.pdf ** Also affects: oem-priority Importance: Undecided Status: New ** Changed in: oem-priority Importance: Undecided => High ** Tags added: oem-priority -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1793472 Title: [wishlist] Add mdadm into desktop by default Status in OEM Priority Project: New Status in ubuntu-meta package in Ubuntu: New Bug description: Consider the situation that we have OEM systems with software raid devices and the desktop image will be installed on them as primary storage. Another work is to patch casper to support md (Please refer bug #1793444). To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1793472/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1899288] Re: Python3 can't co-exist with Oracle's VirtualBox on 20.10
Still true of the deb packages provided by upstream for Virtualbox 6.1.18. The problem is really with the packaging on their side which does not target ubuntu 20.10. In fact, they say so by indicating that they have a deb up to 19.10 and 20.04. I guess there is little that ubuntu can do if Virtualbox does not want to package a deb for ubuntu 20.10 that is not an LTS. Most likely, they'll stick to 20.04 and start supporting newer ubuntu at 21.10 in preparation for the 22.04 LTS release. On the other hand, I believe that ubuntu could help a lot here by making the current virtualbox always available in testing version on a PPA. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dh-python in Ubuntu. https://bugs.launchpad.net/bugs/1899288 Title: Python3 can't co-exist with Oracle's VirtualBox on 20.10 Status in dh-python package in Ubuntu: Confirmed Status in what-is-python package in Ubuntu: Incomplete Bug description: Sorry I couldn't file this bug against the correct packages. The form told me there are no such packages as python-is-python3 and dh-python in Ubuntu... Release: Groovy Gorilla (Ubuntu 20.10). Package versions: python-is-python3 3.8.2-4 dh-python 4.20200925 The release of Ubuntu 20.10 is less than two weeks out, so I'd like to draw attention to a problem I've run into. It seems that 20.10 defaults to python3 and wants to install python-is-python3, which pulls in the latest version of dh-python, which in turn can't co-exist with Oracle's Virtualbox-6.1 and wants to uninstall it. I don't mind having _both_ python2 (apparently a requirement of VirtualBox) and python3 installed. But as of right now I can have either python-is-python3, and not be able to do a complete upgrade since virtualbox-6.1 will be uninstalled, or python-is-python2, in which case I cripple 20.10's python3 install, since I won't get dh- python and python-six. Ia there something the python packagers do about this? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dh-python/+bug/1899288/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
