[Touch-packages] [Bug 1887210] Re: USB DAC/AMP unselectable from Sound Settings and crashes alsamixer
Any news ? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1887210 Title: USB DAC/AMP unselectable from Sound Settings and crashes alsamixer Status in alsa-driver package in Ubuntu: Confirmed Bug description: I am experiencing the same issue with the same device described in this report comment: https://bugs.launchpad.net/ubuntu/+source/alsa- driver/+bug/1267866/comments/26 The device works as expected with Windows 10 and macOS no drivers required. However, the device is not an option from Ubuntu's sound settings. It is visible in alsamixer, however, it crashes immediately upon selection with 'cannot load mixer controls: Broken pipe'. Here's some more debug information. Let me know if there is anymore I can provide or feel free to redirect me if there is another place this is better reported. Device: Schiit Audio Fulla 3 USB DAC/AMP Kernel version: 5.4.0-40-generic Ubuntu version: 20.04 Alsa debug output: http://alsa- project.org/db/?f=3f494b2155bdde7f5ee0e52240da77468bcb `dmesg -w` output upon re-plugging in the device: [ 895.624302] usb 3-2.3: new high-speed USB device number 8 using xhci_hcd [ 895.739125] usb 3-2.3: New USB device found, idVendor=30be, idProduct=0100, bcdDevice= 1.02 [ 895.739129] usb 3-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 895.739131] usb 3-2.3: Product: I'm Fulla Schiit [ 895.739133] usb 3-2.3: Manufacturer: Schiit Audio [ 896.076914] input: Schiit Audio I'm Fulla Schiit as /devices/pci:00/:00:07.1/:11:00.3/usb3/3-2/3-2.3/3-2.3:1.3/0003:30BE:0100.0007/input/input20 [ 896.136457] hid-generic 0003:30BE:0100.0007: input,hidraw5: USB HID v1.00 Device [Schiit Audio I'm Fulla Schiit] on usb-:11:00.3-2.3/input3 [ 896.228480] audit: type=1107 audit(1594446870.681:57): pid=1286 uid=105 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_signal" bus="system" path="/org/freedesktop/NetworkManager" interface="org.freedesktop.NetworkManager" member="CheckPermissions" name=":1.8" mask="receive" pid=10228 label="snap.spotify.spotify" peer_pid=1287 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=? terminal=?' [ 896.238190] usb 3-2.3: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1 [ 896.298659] usb 3-2.3: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1 [ 896.427249] usb 3-2.3: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1 [ 896.618498] usb 3-2.3: cannot get ctl value: req = 0x81, wValue = 0x100, wIndex = 0x1100, type = 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1887210/+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 1919003] Re: Network Name Resolution fails with iproute2 4.15.0-2ubuntu1.3
My initial conclusion may not have been correct. I now think that the fix in iproute2 4.15.0-2ubuntu1.3 made the problem more apparent. The Network Name Resolution service is not actually failing. It is being stopped and restarted (based on the logs). So the real problem seems to be a very aggressive approach to restarting the Network Name Resolution service. In our case, the DHCPClient request is not getting a response, yet the Network Name Resolution service is still being restarted. Mar 13 03:43:32 em-vf-ns1 dhclient[3443]: DHCPDISCOVER on nsblk01 to 255.255.255.255 port 67 interval 5 (xid=0xe499a07d) Mar 13 03:43:37 em-vf-ns1 dhclient[3443]: No DHCPOFFERS received. Mar 13 03:43:37 em-vf-ns1 dhclient[3443]: No working leases in persistent database - sleeping. Mar 13 03:43:37 em-vf-ns1 systemd[1]: Stopping Network Name Resolution... Mar 13 03:43:37 em-vf-ns1 systemd[1]: Stopped Network Name Resolution. Mar 13 03:43:37 em-vf-ns1 systemd[1]: Starting Network Name Resolution... Mar 13 03:43:37 em-vf-ns1 systemd[1]: Started Network Name Resolution. Mar 13 03:43:37 em-vf-ns1 systemd[1]: Starting resolvconf-pull-resolved.service... Mar 13 03:43:37 em-vf-ns1 systemd[1]: Started resolvconf-pull-resolved.service. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1919003 Title: Network Name Resolution fails with iproute2 4.15.0-2ubuntu1.3 Status in iproute2 package in Ubuntu: New Bug description: The following is repeated periodically in the syslog: Feb 28 20:25:02 em-cel1 systemd[1]: Started Network Name Resolution. Feb 28 20:25:02 em-cel1 systemd[1]: Starting resolvconf-pull-resolved.service... Feb 28 20:25:02 em-cel1 systemd[1]: Started resolvconf-pull-resolved.service. Feb 28 20:25:19 em-cel1 systemd[1]: Stopping Network Name Resolution... Feb 28 20:25:19 em-cel1 systemd[1]: Stopped Network Name Resolution. Feb 28 20:25:19 em-cel1 systemd[1]: Starting Network Name Resolution... There is no log anywhere to indicate why the service failed. The service stopped failing when we downgraded iproute2 from 4.15.0-2ubuntu1.3 to 4.15.0-2ubuntu1.1. The DHCPClient seems to be involved in the chain of events. At the same frequency as the service failures, we do an ifup on a non- auto dhcp interface. The ifup results in a DHCP request, which in this case does not get a response (the link to the DHCP server is down. When we stop the process that does the periodic ifup, the service remains up (with iproute2 4.15.0-2ubuntu1.3). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1919003/+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 1890572] Re: USB backend never ends if the printer is not connected
** Changed in: cups
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1890572
Title:
USB backend never ends if the printer is not connected
Status in CUPS:
Fix Released
Status in cups package in Ubuntu:
New
Bug description:
USB backend never ends if the printer is not connected. We have been
able to identify a infinity loop in print_device function in usb-
libusb.c file:
```
fprintf(stderr, "DEBUG: Printing on printer with URI: %s\n", uri);
while ((g.printer = find_device(print_cb, uri)) == NULL)
{
_cupsLangPrintFilter(stderr, "INFO",
_("Waiting for printer to become available."));
sleep(5);
}
```
It's also easy to test by invoking the backend by hand:
```
# export DEVICE_URI='usb://Printer/Model?serial=?'
# /usr/lib/cups/backend/usb 0 root title 1 '' data.file
DEBUG: Loading USB quirks from "/usr/share/cups/usb".
DEBUG: Loaded 159 quirks.
DEBUG: Printing on printer with URI: usb://Printer/Model?serial=?
DEBUG: libusb_get_device_list=6
INFO: Waiting for printer to become available.
DEBUG: libusb_get_device_list=6
INFO: Waiting for printer to become available.
DEBUG: libusb_get_device_list=6
INFO: Waiting for printer to become available.
DEBUG: libusb_get_device_list=6
INFO: Waiting for printer to become available.
DEBUG: libusb_get_device_list=6
INFO: Waiting for printer to become available.
...
```
Setting a job timeout policy or manually stopping work are not options
for us. We may have jobs that take hours to complete.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cups/+bug/1890572/+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 1919003] [NEW] Network Name Resolution fails with iproute2 4.15.0-2ubuntu1.3
Public bug reported: The following is repeated periodically in the syslog: Feb 28 20:25:02 em-cel1 systemd[1]: Started Network Name Resolution. Feb 28 20:25:02 em-cel1 systemd[1]: Starting resolvconf-pull-resolved.service... Feb 28 20:25:02 em-cel1 systemd[1]: Started resolvconf-pull-resolved.service. Feb 28 20:25:19 em-cel1 systemd[1]: Stopping Network Name Resolution... Feb 28 20:25:19 em-cel1 systemd[1]: Stopped Network Name Resolution. Feb 28 20:25:19 em-cel1 systemd[1]: Starting Network Name Resolution... There is no log anywhere to indicate why the service failed. The service stopped failing when we downgraded iproute2 from 4.15.0-2ubuntu1.3 to 4.15.0-2ubuntu1.1. The DHCPClient seems to be involved in the chain of events. At the same frequency as the service failures, we do an ifup on a non- auto dhcp interface. The ifup results in a DHCP request, which in this case does not get a response (the link to the DHCP server is down. When we stop the process that does the periodic ifup, the service remains up (with iproute2 4.15.0-2ubuntu1.3). ** Affects: iproute2 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1919003 Title: Network Name Resolution fails with iproute2 4.15.0-2ubuntu1.3 Status in iproute2 package in Ubuntu: New Bug description: The following is repeated periodically in the syslog: Feb 28 20:25:02 em-cel1 systemd[1]: Started Network Name Resolution. Feb 28 20:25:02 em-cel1 systemd[1]: Starting resolvconf-pull-resolved.service... Feb 28 20:25:02 em-cel1 systemd[1]: Started resolvconf-pull-resolved.service. Feb 28 20:25:19 em-cel1 systemd[1]: Stopping Network Name Resolution... Feb 28 20:25:19 em-cel1 systemd[1]: Stopped Network Name Resolution. Feb 28 20:25:19 em-cel1 systemd[1]: Starting Network Name Resolution... There is no log anywhere to indicate why the service failed. The service stopped failing when we downgraded iproute2 from 4.15.0-2ubuntu1.3 to 4.15.0-2ubuntu1.1. The DHCPClient seems to be involved in the chain of events. At the same frequency as the service failures, we do an ifup on a non- auto dhcp interface. The ifup results in a DHCP request, which in this case does not get a response (the link to the DHCP server is down. When we stop the process that does the periodic ifup, the service remains up (with iproute2 4.15.0-2ubuntu1.3). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1919003/+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 1878969] Re: time-epoch never changes in SRUs
focal:
$ pull-lp-source systemd 245.4-4ubuntu3.4
...
$ stat -c '%y' systemd-245.4/NEWS
2020-04-01 13:23:42.0 -0400
$ lxc launch --vm ubuntu:focal lp1878969-f
...
$ lxc exec lp1878969-f systemctl disable systemd-timesyncd
Removed /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service.
Removed /etc/systemd/system/dbus-org.freedesktop.timesync1.service.
$ lxc stop lp1878969-f
$ sudo date -s '1990-01-01'
Mon Jan 1 00:00:00 UTC 1990
$ lxc start lp1878969-f
$ lxc console lp1878969-f
...
ubuntu@lp1878969-f:~$ dpkg -l systemd|grep systemd
ii systemd245.4-4ubuntu3.4 amd64system and service manager
ubuntu@lp1878969-f:~$ date
Wed Apr 1 17:24:01 UTC 2020
>From https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.5
" -- Ioanna Alifieraki Tue, 23 Feb
2021 00:18:57 +"
$ sudo date -s '1990-01-01'
Mon Jan 1 00:00:00 UTC 1990
$ lxc start lp1878969-f
$ lxc console lp1878969-f
...
ubuntu@lp1878969-f:~$ systemctl status systemd-timesyncd.service --no-pager
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled;
vendor preset: enabled)
Active: inactive (dead)
Docs: man:systemd-timesyncd.service(8)
ubuntu@lp1878969-f:~$ dpkg -l systemd|grep systemd
ii systemd245.4-4ubuntu3.5 amd64system and service manager
ubuntu@lp1878969-f:~$ date
Tue Feb 23 00:19:42 UTC 2021
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1878969
Title:
time-epoch never changes in SRUs
Status in ubuntu-core-initramfs:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Xenial:
New
Status in systemd source package in Bionic:
Fix Committed
Status in systemd source package in Focal:
Fix Committed
Bug description:
[Impact]
* Systems without hwclock come up with a fixed time epoch which is not
updated in SRUs
* Ideally booting with a newer built of systemd should move time epoch to be
at least when systemd was last built. For example to the value of
SOURCE_DATE_EPOCH.
[Test Case]
* Boot without network NTP or hwclock
* Observe that the epoch is the same as the time when NEWS entry in the
systemd source code was last touched.
* Boot newer update of systemd, observe that the time epoch is at least 2020
[Regression Potential]
* Bad epoch, may result in unable to perform TLS connections,
validated GPG signatures, and snapd assertions. Changing epoch to be
more recent is desired. Some machines may rely on the fact that
"bionic" without hwclock always comes up in year 2018. But in practice
that is incorrect thing to do.
[Other Info]
* By default
option('time-epoch', type : 'integer', value : '-1',
description : 'time epoch for time clients')
in systemd is set to the modification time of the NEW entry
time_epoch = run_command(stat, '-c', '%Y', NEWS).stdout().to_int()
If available, it should be set to SOURCE_DATE_EPOCH=1585051767 value
to be compliant with the https://reproducible-
builds.org/docs/timestamps/ specification.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-core-initramfs/+bug/1878969/+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 1907472] Re: glibc x32 autopkgtest fails in hirsute with binutils and audit in -proposed
I've observed the failure in the i386 build of glibc_2.33-0ubuntu4: Linux lcy01-amd64-014 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 i686 athlon i686 GNU/Linux ... if [ -f /proc/cpuinfo ] ; then cat /proc/cpuinfo ; fi processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : AMD Opteron 23xx (Gen 3 Class Opteron) stepping: 3 microcode : 0x165 cpu MHz : 2500.048 cache size : 512 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb lm 3dnowext 3dnow rep_good nopl cpuid extd_apicid tsc_known_freq pni cx16 x2apic popcnt hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw vmmcall bugs: tlb_mmatch fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 bogomips: 5000.09 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ... +-+ | Encountered regressions that don't match expected failures. | +-+ FAIL: math/test-double-libmvec-sincos FAIL: math/test-double-vlen2-sincos FAIL: math/test-float-libmvec-sincosf FAIL: math/test-float-vlen4-sincos touch /<>/stamp-dir/check_x32 CHECK SUMMARY check for check_libc passed check for check_amd64 passed check for check_x32 failed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to audit in Ubuntu. https://bugs.launchpad.net/bugs/1907472 Title: glibc x32 autopkgtest fails in hirsute with binutils and audit in -proposed Status in audit package in Ubuntu: New Status in binutils package in Ubuntu: New Status in glibc package in Ubuntu: New Bug description: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest- hirsute/hirsute/amd64/g/glibc/20201208_160143_17354@/log.gz -- FAIL: math/test-double-libmvec-sincos original exit status 1 Didn't expect signal from child: got `Illegal instruction' -- -- FAIL: math/test-double-vlen2-sincos original exit status 132 -- -- FAIL: math/test-float-libmvec-sincosf original exit status 1 Didn't expect signal from child: got `Illegal instruction' -- -- FAIL: math/test-float-vlen4-sincos original exit status 132 -- To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1907472/+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 1917763] Re: FFE: new upstream release 21.0 and migrate to llvm 12
ACK, go for it (with 11 for now, I agree that switching to an RC compiler feels dodgy) ** Changed in: mesa (Ubuntu) Status: New => Triaged ** Changed in: mesa (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1917763 Title: FFE: new upstream release 21.0 and migrate to llvm 12 Status in mesa package in Ubuntu: Triaged Bug description: Mesa 21.0.0 will be released soon, and we still want it in 21.04. It's been in Debian experimental since rc1. The packaging also migrates it to use llvm 12. The risks involve graphical issues or even crashes when running more intense OpenGL/Vulkan apps like games. Running a desktop is a simple use-case and should work fine across the board. Upstream gitlab has a fairly extensive CI for various drivers, while Intel tests on their own CI. This means that any showstoppers should be shaken out already. We will be able to pull maybe two point-releases before hirsute is frozen, and then push more as an SRU. I've tested 21.0.0-rc's on Intel and AMD (RX 5700) and the latter too with some games, all good. packages for hirsute are available on ppa:canonical-x/x-staging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1917763/+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 1917763] Re: FFE: new upstream release 21.0 and migrate to llvm 12
Note that migrating to llvm 12 can be done later, and use llvm 11 for now until 12.0 is released (is at rc3 now). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1917763 Title: FFE: new upstream release 21.0 and migrate to llvm 12 Status in mesa package in Ubuntu: New Bug description: Mesa 21.0.0 will be released soon, and we still want it in 21.04. It's been in Debian experimental since rc1. The packaging also migrates it to use llvm 12. The risks involve graphical issues or even crashes when running more intense OpenGL/Vulkan apps like games. Running a desktop is a simple use-case and should work fine across the board. Upstream gitlab has a fairly extensive CI for various drivers, while Intel tests on their own CI. This means that any showstoppers should be shaken out already. We will be able to pull maybe two point-releases before hirsute is frozen, and then push more as an SRU. I've tested 21.0.0-rc's on Intel and AMD (RX 5700) and the latter too with some games, all good. packages for hirsute are available on ppa:canonical-x/x-staging To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1917763/+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 1918955] Re: SRU network: fix LXC_NET_NONE cleanup
** Description changed: Hi. I'm using 20.04, and I need a fix for https://github.com/lxc/lxc/pull/3589 - I think my only options to get that via packaging are - a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master - b.) build my own. + I think my only options to get that via packaging are + a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master + b.) build my own. I don't love either of those options. Can we please get a SRU update to 20.04 of an lxc with that fix? + + The fix is not in 4.0.5, so I marked this as affecting Groovy (currently + 1:4.0.4-0ubuntu3) without testing. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1918955 Title: SRU network: fix LXC_NET_NONE cleanup Status in lxc package in Ubuntu: Fix Released Status in lxc source package in Focal: Confirmed Status in lxc source package in Groovy: Confirmed Status in lxc source package in Hirsute: Fix Released Bug description: Hi. I'm using 20.04, and I need a fix for https://github.com/lxc/lxc/pull/3589 I think my only options to get that via packaging are a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master b.) build my own. I don't love either of those options. Can we please get a SRU update to 20.04 of an lxc with that fix? The fix is not in 4.0.5, so I marked this as affecting Groovy (currently 1:4.0.4-0ubuntu3) without testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1918955/+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 1918954] [NEW] [MS-7293, Realtek ALC883, Orange Line Out, Rear] No sound at all
Public bug reported: We have no sounds on speakers nor signals during the starting. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: pulseaudio 1:11.1-1ubuntu7.11 ProcVersionSignature: Ubuntu 4.15.0-136.140-generic 4.15.18 Uname: Linux 4.15.0-136-generic i686 ApportVersion: 2.20.9-0ubuntu7.23 Architecture: i386 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: hmljkl 1444 F pulseaudio /dev/snd/controlC1: hmljkl 1444 F pulseaudio CurrentDesktop: Unity:Unity7:ubuntu Date: Fri Mar 12 17:19:26 2021 InstallationDate: Installed on 2021-03-11 (1 days ago) InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release i386 (20170801) SourcePackage: pulseaudio Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:VT82xx successful Symptom_Card: VT8237A/VT8251 HDA Controller - HDA VIA VT82xx Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: hmljkl 1444 F pulseaudio /dev/snd/controlC1: hmljkl 1444 F pulseaudio Symptom_Jack: Orange Line Out, Rear Symptom_PulsePlaybackTest: PulseAudio playback test failed Symptom_Type: No sound at all Title: [MS-7293, Realtek ALC883, Orange Line Out, Rear] No sound at all UpgradeStatus: Upgraded to bionic on 2021-03-12 (0 days ago) dmi.bios.date: 10/27/2006 dmi.bios.vendor: Phoenix Technologies, LTD dmi.bios.version: 6.00 PG dmi.board.name: MS-7293 dmi.board.vendor: FUJITSU SIEMENS dmi.board.version: 1.00 dmi.chassis.type: 3 dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr6.00PG:bd10/27/2006:svnFUJITSUSIEMENS:pnMS-7293:pvr1.00:rvnFUJITSUSIEMENS:rnMS-7293:rvr1.00:cvn:ct3:cvr: dmi.product.name: MS-7293 dmi.product.version: 1.00 dmi.sys.vendor: FUJITSU SIEMENS ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug bionic i386 -- 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/1918954 Title: [MS-7293, Realtek ALC883, Orange Line Out, Rear] No sound at all Status in pulseaudio package in Ubuntu: New Bug description: We have no sounds on speakers nor signals during the starting. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: pulseaudio 1:11.1-1ubuntu7.11 ProcVersionSignature: Ubuntu 4.15.0-136.140-generic 4.15.18 Uname: Linux 4.15.0-136-generic i686 ApportVersion: 2.20.9-0ubuntu7.23 Architecture: i386 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: hmljkl 1444 F pulseaudio /dev/snd/controlC1: hmljkl 1444 F pulseaudio CurrentDesktop: Unity:Unity7:ubuntu Date: Fri Mar 12 17:19:26 2021 InstallationDate: Installed on 2021-03-11 (1 days ago) InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release i386 (20170801) SourcePackage: pulseaudio Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:VT82xx successful Symptom_Card: VT8237A/VT8251 HDA Controller - HDA VIA VT82xx Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: hmljkl 1444 F pulseaudio /dev/snd/controlC1: hmljkl 1444 F pulseaudio Symptom_Jack: Orange Line Out, Rear Symptom_PulsePlaybackTest: PulseAudio playback test failed Symptom_Type: No sound at all Title: [MS-7293, Realtek ALC883, Orange Line Out, Rear] No sound at all UpgradeStatus: Upgraded to bionic on 2021-03-12 (0 days ago) dmi.bios.date: 10/27/2006 dmi.bios.vendor: Phoenix Technologies, LTD dmi.bios.version: 6.00 PG dmi.board.name: MS-7293 dmi.board.vendor: FUJITSU SIEMENS dmi.board.version: 1.00 dmi.chassis.type: 3 dmi.modalias: dmi:bvnPhoenixTechnologies,LTD:bvr6.00PG:bd10/27/2006:svnFUJITSUSIEMENS:pnMS-7293:pvr1.00:rvnFUJITSUSIEMENS:rnMS-7293:rvr1.00:cvn:ct3:cvr: dmi.product.name: MS-7293 dmi.product.version: 1.00 dmi.sys.vendor: FUJITSU SIEMENS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1918954/+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 1918955] [NEW] SRU network: fix LXC_NET_NONE cleanup
Public bug reported: Hi. I'm using 20.04, and I need a fix for https://github.com/lxc/lxc/pull/3589 I think my only options to get that via packaging are a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master b.) build my own. I don't love either of those options. Can we please get a SRU update to 20.04 of an lxc with that fix? ** Affects: lxc (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: lxc (Ubuntu Focal) Importance: Undecided Status: Confirmed ** Affects: lxc (Ubuntu Groovy) Importance: Undecided Status: Confirmed ** Affects: lxc (Ubuntu Hirsute) Importance: Undecided Status: Fix Released ** Also affects: lxc (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: lxc (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: lxc (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: lxc (Ubuntu Hirsute) Status: New => Fix Released ** Changed in: lxc (Ubuntu Groovy) Status: New => Confirmed ** Changed in: lxc (Ubuntu Focal) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1918955 Title: SRU network: fix LXC_NET_NONE cleanup Status in lxc package in Ubuntu: Fix Released Status in lxc source package in Focal: Confirmed Status in lxc source package in Groovy: Confirmed Status in lxc source package in Hirsute: Fix Released Bug description: Hi. I'm using 20.04, and I need a fix for https://github.com/lxc/lxc/pull/3589 I think my only options to get that via packaging are a.) https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/lxc-git-master b.) build my own. I don't love either of those options. Can we please get a SRU update to 20.04 of an lxc with that fix? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1918955/+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 1917625] Re: OpenSSL TLS 1.1 handshake fails internal error
> I feel that openssl upstream needs to add:
server_context.verify_consistent()
Yeah, I agree with you. :) The idea came up three years ago when I filed
issue https://github.com/openssl/openssl/issues/5127
> 1) if openssl version 3.x, and security level is greater than 0, assume no
> TLS1.1 is available
Thank you, I'll consider this fact when I implement OpenSSL 3.0.0
support
> 2) if openssl version 1.1.1+, and security level is greater than 1, assume no
> TLS1.1 is available
TLS 1.1 connections work fine on seclevel 2 with default upstream
OpenSSL 1.1.1 and with Fedora's OpenSSL 1.1.1 using crypto-policy
"DEFAULT". I'm using
server_context.set_ciphers("@SECLEVEL=2:ALL")
to change the security level. Here Ubuntu deviates from standard OpenSSL
1.1.1 policies. So I ask again: Should we detect and special case the
deviation and document it?
> 3) if ctx.get_min_proto_level returns TLS1.2 assume no TLS1.1 is available
That's the original problem,
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878 . On
Ubuntu SSL_CTX_get_min_proto_version() returns 0 (lowest available
version) and TLS1_VERSION is available.
> 4) else try setting min_proto_level and run tests
The setter SSL_CTX_set_min_proto_version() does not return an error
indication.
** Bug watch added: github.com/openssl/openssl/issues #5127
https://github.com/openssl/openssl/issues/5127
--
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/1917625
Title:
OpenSSL TLS 1.1 handshake fails internal error
Status in openssl package in Ubuntu:
Confirmed
Status in openssl source package in Hirsute:
Confirmed
Bug description:
OpenSSL's SSL_do_handshake() method fails with
TLSV1_ALERT_INTERNAL_ERROR when client side has TLS 1.0 to 1.2 enabled
but server side has only TLS 1.0 and 1.1 enabled. The issue breaks
Python's test suite for test_ssl. It looks like the problem is caused
by an Ubuntu downstream patch. Vanilla OpenSSL, Debian, and Fedora are
not affected.
A simple reproducer is:
import ssl
import socket
from test.test_ssl import testing_context, ThreadedEchoServer, HOST
client_context, server_context, hostname = testing_context()
# client 1.0 to 1.2, server 1.0 to 1.1
client_context.minimum_version = ssl.TLSVersion.TLSv1
client_context.maximum_version = ssl.TLSVersion.TLSv1_2
server_context.minimum_version = ssl.TLSVersion.TLSv1
server_context.maximum_version = ssl.TLSVersion.TLSv1_1
with ThreadedEchoServer(context=server_context) as server:
with client_context.wrap_socket(socket.socket(),
server_hostname=hostname) as s:
s.connect((HOST, server.port))
assert s.version() == 'TLSv1.1'
On Ubuntu 20.04 the code fails with:
Traceback (most recent call last):
File "/internalerror.py", line 15, in
s.connect((HOST, server.port))
File "/usr/lib/python3.8/ssl.py", line 1342, in connect
self._real_connect(addr, False)
File "/usr/lib/python3.8/ssl.py", line 1333, in _real_connect
self.do_handshake()
File "/usr/lib/python3.8/ssl.py", line 1309, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error
(_ssl.c:1123)
On Debian testing and Fedora 33 the same test passes with out:
server: new connection from ('127.0.0.1', 52346)
server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1.0', 256)
server: selected protocol is now None
You can find Dockerfiles with reproducers at https://github.com/tiran
/distro-truststore/tree/main/tests/ubuntu-1899878
Also see:
* https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878
* https://bugs.python.org/issue43382
* https://bugs.python.org/issue41561
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625/+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 1917625] Re: OpenSSL TLS 1.1 handshake fails internal error
> s->cert->sec_cb() and then call it with SSL_SECOP_VERSION operation
with nbits set to TLS1.1 version? then it will return and tell us if it
is acceptable or not, by the security level.
Nice!
Could you hook up the check to SSL_CTX_set_min_proto_version() and return an
error code when level and security policy don't match? It's a modern setter, so
it can return 0 on error.
int SSL_CTX_set_min_proto_version(SSL_CTX *ctx, int version);
--
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/1917625
Title:
OpenSSL TLS 1.1 handshake fails internal error
Status in openssl package in Ubuntu:
Confirmed
Status in openssl source package in Hirsute:
Confirmed
Bug description:
OpenSSL's SSL_do_handshake() method fails with
TLSV1_ALERT_INTERNAL_ERROR when client side has TLS 1.0 to 1.2 enabled
but server side has only TLS 1.0 and 1.1 enabled. The issue breaks
Python's test suite for test_ssl. It looks like the problem is caused
by an Ubuntu downstream patch. Vanilla OpenSSL, Debian, and Fedora are
not affected.
A simple reproducer is:
import ssl
import socket
from test.test_ssl import testing_context, ThreadedEchoServer, HOST
client_context, server_context, hostname = testing_context()
# client 1.0 to 1.2, server 1.0 to 1.1
client_context.minimum_version = ssl.TLSVersion.TLSv1
client_context.maximum_version = ssl.TLSVersion.TLSv1_2
server_context.minimum_version = ssl.TLSVersion.TLSv1
server_context.maximum_version = ssl.TLSVersion.TLSv1_1
with ThreadedEchoServer(context=server_context) as server:
with client_context.wrap_socket(socket.socket(),
server_hostname=hostname) as s:
s.connect((HOST, server.port))
assert s.version() == 'TLSv1.1'
On Ubuntu 20.04 the code fails with:
Traceback (most recent call last):
File "/internalerror.py", line 15, in
s.connect((HOST, server.port))
File "/usr/lib/python3.8/ssl.py", line 1342, in connect
self._real_connect(addr, False)
File "/usr/lib/python3.8/ssl.py", line 1333, in _real_connect
self.do_handshake()
File "/usr/lib/python3.8/ssl.py", line 1309, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error
(_ssl.c:1123)
On Debian testing and Fedora 33 the same test passes with out:
server: new connection from ('127.0.0.1', 52346)
server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1.0', 256)
server: selected protocol is now None
You can find Dockerfiles with reproducers at https://github.com/tiran
/distro-truststore/tree/main/tests/ubuntu-1899878
Also see:
* https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878
* https://bugs.python.org/issue43382
* https://bugs.python.org/issue41561
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625/+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 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
On SSLcontext, security callback has prototype /* Security callback */ int (*sec_cb) (const SSL *s, const SSL_CTX *ctx, int op, int bits, int nid, void *other, void *ex); if one calls that function, with context passed in, "op" set to SSL_SECOP_VERSION, "bits" set to zero, "nid" set to protocol version, other set to NULL, and ex set to null => then the security callback will tell us if at the current configuration a given protocol version is acceptable. This should work on OpenSSL 1.1.0+ -- 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/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 Status in openssl package in Ubuntu: Incomplete Bug description: Please take a look at https://bugs.python.org/issue41561. Developers who work on Python think that the issue is due to a change in Ubuntu 20.04 that is best described by https://bugs.python.org/issue41561#msg378089: "It sounds like a Debian/Ubuntu patch is breaking an assumption. Did somebody report the bug with Debian/Ubuntu maintainers of OpenSSL already? Fedora also configures OpenSSL with minimum protocol version of TLS 1.2. The distribution does it in a slightly different way that makes the restriction discoverable and that is compatible with Python's test suite." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+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 1918930] Re: Unexpected file size of one package interrupts update process for all packages and leaves system vulnerable
APT can't know how "critical" the other packages are compared to the packages which failed to download (which really shouldn't happen to begin with). I mean, if you don't (normally) use an SSH server, but hard-depend on a sublime text-editor experience… Have you tried the --fix-missing option the error message points to? It will make it so that apt still shows the errors, but it will continue on and install all packages it could successfully acquire. That is still a failure for the whole process though (if that would be silent it would be too easy for an attacker to fail these downloads and make you believe you are up-to-date while nothing was installed – especially in unattended processes). Perhaps we should make that an interactive question in "apt" to have it more easily discoverable for an interactive user? (not commenting on the LP things, you may want to talk to them directly about this rather than venting in an unrelated bugreport) -- 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/1918930 Title: Unexpected file size of one package interrupts update process for all packages and leaves system vulnerable Status in apt package in Ubuntu: New Bug description: An unexpected file size error of *one* package interrupts the whole update process for *all* packages and this can leave the system in a vulnerable state - this is not a constructed situation, but very real right now, look at the following console output - sublime has some problems with its package size, but then important ssh updates are not executed. Bad. The following packages will be upgraded: brave-browser git git-man libpython2.7-minimal libpython2.7-stdlib linux-firmware openssh-client openssh-server openssh-sftp-server python2.7 python2.7-minimal python3-pil sublime-merge 13 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 4.548 kB/199 MB of archives. After this operation, 1.744 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 https://download.sublimetext.com apt/stable/ sublime-merge 2049 [4.548 kB] Err:1 https://download.sublimetext.com apt/stable/ sublime-merge 2049 File has unexpected size (4542548 != 4548032). Mirror sync in progress? [IP: 104.236.0.104 443] Hashes of expected file: - SHA512:f65ce3ca80ff0877da48826a0151036cd8e0bdf28b03d225a03f202262ca1278accdac8e7eb46a22904203750ccf06e3abe496a44f7a4b0c3363076501f72369 - SHA256:e71fcf37e9d934a60b5112a7b79c819f03f55d331371ec0e9b02378c6234478c - SHA1:7fe54a9f7ea5383dbdfc0aae39310e2902c6d7f5 [weak] - MD5Sum:fd78a3b986bd7da8b2ebd1f659f5938c [weak] - Filesize:4548032 [weak] E: Failed to fetch https://download.sublimetext.com/files/sublime-merge_build-2049_amd64.deb File has unexpected size (4542548 != 4548032). Mirror sync in progress? [IP: 104.236.0.104 443] Hashes of expected file: - SHA512:f65ce3ca80ff0877da48826a0151036cd8e0bdf28b03d225a03f202262ca1278accdac8e7eb46a22904203750ccf06e3abe496a44f7a4b0c3363076501f72369 - SHA256:e71fcf37e9d934a60b5112a7b79c819f03f55d331371ec0e9b02378c6234478c - SHA1:7fe54a9f7ea5383dbdfc0aae39310e2902c6d7f5 [weak] - MD5Sum:fd78a3b986bd7da8b2ebd1f659f5938c [weak] - Filesize:4548032 [weak] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Note: This issue is not about the package size error in a third party repo - I do not blame Ubuntu for problems with that. This is about breaking the whole process of updating the system because one single sub-task fails. Why not make the basic tools really robust and reliable? BTW - here are s many free pixels on this screen - why not add two or three small sentences about text formatting syntax available in this extremely primitive text input box? Is there any text formatting at all? Why not put just a little bit of love to the user perspective and experience? Just two little senteces about formatting would make it so much more user friendly to type here. It feels so quick-and- dirty, it hurts. Very sad. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1918930/+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 1917625] Re: OpenSSL TLS 1.1 handshake fails internal error
Oooh,
can we add bindings for:
s->cert->sec_cb() and then call it with SSL_SECOP_VERSION operation with
nbits set to TLS1.1 version? then it will return and tell us if it is
acceptable or not, by the security level.
--
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/1917625
Title:
OpenSSL TLS 1.1 handshake fails internal error
Status in openssl package in Ubuntu:
Confirmed
Status in openssl source package in Hirsute:
Confirmed
Bug description:
OpenSSL's SSL_do_handshake() method fails with
TLSV1_ALERT_INTERNAL_ERROR when client side has TLS 1.0 to 1.2 enabled
but server side has only TLS 1.0 and 1.1 enabled. The issue breaks
Python's test suite for test_ssl. It looks like the problem is caused
by an Ubuntu downstream patch. Vanilla OpenSSL, Debian, and Fedora are
not affected.
A simple reproducer is:
import ssl
import socket
from test.test_ssl import testing_context, ThreadedEchoServer, HOST
client_context, server_context, hostname = testing_context()
# client 1.0 to 1.2, server 1.0 to 1.1
client_context.minimum_version = ssl.TLSVersion.TLSv1
client_context.maximum_version = ssl.TLSVersion.TLSv1_2
server_context.minimum_version = ssl.TLSVersion.TLSv1
server_context.maximum_version = ssl.TLSVersion.TLSv1_1
with ThreadedEchoServer(context=server_context) as server:
with client_context.wrap_socket(socket.socket(),
server_hostname=hostname) as s:
s.connect((HOST, server.port))
assert s.version() == 'TLSv1.1'
On Ubuntu 20.04 the code fails with:
Traceback (most recent call last):
File "/internalerror.py", line 15, in
s.connect((HOST, server.port))
File "/usr/lib/python3.8/ssl.py", line 1342, in connect
self._real_connect(addr, False)
File "/usr/lib/python3.8/ssl.py", line 1333, in _real_connect
self.do_handshake()
File "/usr/lib/python3.8/ssl.py", line 1309, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error
(_ssl.c:1123)
On Debian testing and Fedora 33 the same test passes with out:
server: new connection from ('127.0.0.1', 52346)
server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1.0', 256)
server: selected protocol is now None
You can find Dockerfiles with reproducers at https://github.com/tiran
/distro-truststore/tree/main/tests/ubuntu-1899878
Also see:
* https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878
* https://bugs.python.org/issue43382
* https://bugs.python.org/issue41561
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625/+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 1917625] Re: OpenSSL TLS 1.1 handshake fails internal error
ideally it would be nice if we could access sec_cb and call it with the
protocol versions to check the versions there.
--
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/1917625
Title:
OpenSSL TLS 1.1 handshake fails internal error
Status in openssl package in Ubuntu:
Confirmed
Status in openssl source package in Hirsute:
Confirmed
Bug description:
OpenSSL's SSL_do_handshake() method fails with
TLSV1_ALERT_INTERNAL_ERROR when client side has TLS 1.0 to 1.2 enabled
but server side has only TLS 1.0 and 1.1 enabled. The issue breaks
Python's test suite for test_ssl. It looks like the problem is caused
by an Ubuntu downstream patch. Vanilla OpenSSL, Debian, and Fedora are
not affected.
A simple reproducer is:
import ssl
import socket
from test.test_ssl import testing_context, ThreadedEchoServer, HOST
client_context, server_context, hostname = testing_context()
# client 1.0 to 1.2, server 1.0 to 1.1
client_context.minimum_version = ssl.TLSVersion.TLSv1
client_context.maximum_version = ssl.TLSVersion.TLSv1_2
server_context.minimum_version = ssl.TLSVersion.TLSv1
server_context.maximum_version = ssl.TLSVersion.TLSv1_1
with ThreadedEchoServer(context=server_context) as server:
with client_context.wrap_socket(socket.socket(),
server_hostname=hostname) as s:
s.connect((HOST, server.port))
assert s.version() == 'TLSv1.1'
On Ubuntu 20.04 the code fails with:
Traceback (most recent call last):
File "/internalerror.py", line 15, in
s.connect((HOST, server.port))
File "/usr/lib/python3.8/ssl.py", line 1342, in connect
self._real_connect(addr, False)
File "/usr/lib/python3.8/ssl.py", line 1333, in _real_connect
self.do_handshake()
File "/usr/lib/python3.8/ssl.py", line 1309, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error
(_ssl.c:1123)
On Debian testing and Fedora 33 the same test passes with out:
server: new connection from ('127.0.0.1', 52346)
server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1.0', 256)
server: selected protocol is now None
You can find Dockerfiles with reproducers at https://github.com/tiran
/distro-truststore/tree/main/tests/ubuntu-1899878
Also see:
* https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878
* https://bugs.python.org/issue43382
* https://bugs.python.org/issue41561
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625/+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 1917625] Re: OpenSSL TLS 1.1 handshake fails internal error
I feel that openssl upstream needs to add:
server_context.verify_consistent()
Because in the above example, even before trying to establish the
connection between the two context, the server context is already
internally inconsistent.
And upstream has changed the meaning of security levels in the past, and
will do so again in the future. Ditto distro customization which brought
the preview of such change earlier.
It does feel that until such API arrives upstream, one needs to do
something to the effect of:
1) if openssl version 3.x, and security level is greater than 0, assume no
TLS1.1 is available
2) if openssl version 1.1.1+, and security level is greater than 1, assume no
TLS1.1 is available
3) if ctx.get_min_proto_level returns TLS1.2 assume no TLS1.1 is available
4) else try setting min_proto_level and run tests
5) if min_proto_lvel is not available the build is against openssl 1.0.2x
series, TLS1.1 is probably available.
Above logic should cover the next upstream openssl version; the current
deployments of ubuntu derivatives; the debian derivatives; and
fedora/rhel derivatives.
I think
--
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/1917625
Title:
OpenSSL TLS 1.1 handshake fails internal error
Status in openssl package in Ubuntu:
Confirmed
Status in openssl source package in Hirsute:
Confirmed
Bug description:
OpenSSL's SSL_do_handshake() method fails with
TLSV1_ALERT_INTERNAL_ERROR when client side has TLS 1.0 to 1.2 enabled
but server side has only TLS 1.0 and 1.1 enabled. The issue breaks
Python's test suite for test_ssl. It looks like the problem is caused
by an Ubuntu downstream patch. Vanilla OpenSSL, Debian, and Fedora are
not affected.
A simple reproducer is:
import ssl
import socket
from test.test_ssl import testing_context, ThreadedEchoServer, HOST
client_context, server_context, hostname = testing_context()
# client 1.0 to 1.2, server 1.0 to 1.1
client_context.minimum_version = ssl.TLSVersion.TLSv1
client_context.maximum_version = ssl.TLSVersion.TLSv1_2
server_context.minimum_version = ssl.TLSVersion.TLSv1
server_context.maximum_version = ssl.TLSVersion.TLSv1_1
with ThreadedEchoServer(context=server_context) as server:
with client_context.wrap_socket(socket.socket(),
server_hostname=hostname) as s:
s.connect((HOST, server.port))
assert s.version() == 'TLSv1.1'
On Ubuntu 20.04 the code fails with:
Traceback (most recent call last):
File "/internalerror.py", line 15, in
s.connect((HOST, server.port))
File "/usr/lib/python3.8/ssl.py", line 1342, in connect
self._real_connect(addr, False)
File "/usr/lib/python3.8/ssl.py", line 1333, in _real_connect
self.do_handshake()
File "/usr/lib/python3.8/ssl.py", line 1309, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: TLSV1_ALERT_INTERNAL_ERROR] tlsv1 alert internal error
(_ssl.c:1123)
On Debian testing and Fedora 33 the same test passes with out:
server: new connection from ('127.0.0.1', 52346)
server: connection cipher is now ('ECDHE-RSA-AES256-SHA', 'TLSv1.0', 256)
server: selected protocol is now None
You can find Dockerfiles with reproducers at https://github.com/tiran
/distro-truststore/tree/main/tests/ubuntu-1899878
Also see:
* https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878
* https://bugs.python.org/issue43382
* https://bugs.python.org/issue41561
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1917625/+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 1918930] [NEW] Unexpected file size of one package interrupts update process for all packages and leaves system vulnerable
Public bug reported: An unexpected file size error of *one* package interrupts the whole update process for *all* packages and this can leave the system in a vulnerable state - this is not a constructed situation, but very real right now, look at the following console output - sublime has some problems with its package size, but then important ssh updates are not executed. Bad. The following packages will be upgraded: brave-browser git git-man libpython2.7-minimal libpython2.7-stdlib linux-firmware openssh-client openssh-server openssh-sftp-server python2.7 python2.7-minimal python3-pil sublime-merge 13 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 4.548 kB/199 MB of archives. After this operation, 1.744 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 https://download.sublimetext.com apt/stable/ sublime-merge 2049 [4.548 kB] Err:1 https://download.sublimetext.com apt/stable/ sublime-merge 2049 File has unexpected size (4542548 != 4548032). Mirror sync in progress? [IP: 104.236.0.104 443] Hashes of expected file: - SHA512:f65ce3ca80ff0877da48826a0151036cd8e0bdf28b03d225a03f202262ca1278accdac8e7eb46a22904203750ccf06e3abe496a44f7a4b0c3363076501f72369 - SHA256:e71fcf37e9d934a60b5112a7b79c819f03f55d331371ec0e9b02378c6234478c - SHA1:7fe54a9f7ea5383dbdfc0aae39310e2902c6d7f5 [weak] - MD5Sum:fd78a3b986bd7da8b2ebd1f659f5938c [weak] - Filesize:4548032 [weak] E: Failed to fetch https://download.sublimetext.com/files/sublime-merge_build-2049_amd64.deb File has unexpected size (4542548 != 4548032). Mirror sync in progress? [IP: 104.236.0.104 443] Hashes of expected file: - SHA512:f65ce3ca80ff0877da48826a0151036cd8e0bdf28b03d225a03f202262ca1278accdac8e7eb46a22904203750ccf06e3abe496a44f7a4b0c3363076501f72369 - SHA256:e71fcf37e9d934a60b5112a7b79c819f03f55d331371ec0e9b02378c6234478c - SHA1:7fe54a9f7ea5383dbdfc0aae39310e2902c6d7f5 [weak] - MD5Sum:fd78a3b986bd7da8b2ebd1f659f5938c [weak] - Filesize:4548032 [weak] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Note: This issue is not about the package size error in a third party repo - I do not blame Ubuntu for problems with that. This is about breaking the whole process of updating the system because one single sub-task fails. Why not make the basic tools really robust and reliable? BTW - here are s many free pixels on this screen - why not add two or three small sentences about text formatting syntax available in this extremely primitive text input box? Is there any text formatting at all? Why not put just a little bit of love to the user perspective and experience? Just two little senteces about formatting would make it so much more user friendly to type here. It feels so quick-and-dirty, it hurts. Very sad. ** Affects: apt (Ubuntu) Importance: Undecided Status: New -- 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/1918930 Title: Unexpected file size of one package interrupts update process for all packages and leaves system vulnerable Status in apt package in Ubuntu: New Bug description: An unexpected file size error of *one* package interrupts the whole update process for *all* packages and this can leave the system in a vulnerable state - this is not a constructed situation, but very real right now, look at the following console output - sublime has some problems with its package size, but then important ssh updates are not executed. Bad. The following packages will be upgraded: brave-browser git git-man libpython2.7-minimal libpython2.7-stdlib linux-firmware openssh-client openssh-server openssh-sftp-server python2.7 python2.7-minimal python3-pil sublime-merge 13 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 4.548 kB/199 MB of archives. After this operation, 1.744 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 https://download.sublimetext.com apt/stable/ sublime-merge 2049 [4.548 kB] Err:1 https://download.sublimetext.com apt/stable/ sublime-merge 2049 File has unexpected size (4542548 != 4548032). Mirror sync in progress? [IP: 104.236.0.104 443] Hashes of expected file: - SHA512:f65ce3ca80ff0877da48826a0151036cd8e0bdf28b03d225a03f202262ca1278accdac8e7eb46a22904203750ccf06e3abe496a44f7a4b0c3363076501f72369 - SHA256:e71fcf37e9d934a60b5112a7b79c819f03f55d331371ec0e9b02378c6234478c - SHA1:7fe54a9f7ea5383dbdfc0aae39310e2902c6d7f5 [weak] - MD5Sum:fd78a3b986bd7da8b2ebd1f659f5938c [weak] - Filesize:4548032 [weak] E: Failed to fetch https://download.sublimetext.com/files/sublime-merge_build-2049_amd64.deb File has unexpected size (4542548 != 4548032). Mirror sync in progress? [IP: 104.236.0.104 443] Hashes of expected file: - SHA512:f65ce3
[Touch-packages] [Bug 1918928] [NEW] APT 2021/03 SRU release scheduling
Public bug reported:
We want to release the APT SRUs from Mar 2021 in a staggered manner,
such that we have 2-3 days between each release to get more chance to
discover regressions before rolling out to older releases.
Hence this bug, which we tag block-proposed-{bionic,focal} and then
untag once the delay has passed.
For groovy, we just want the normal aging :-)
** Affects: apt (Ubuntu)
Importance: Undecided
Status: In Progress
** Tags: block-proposed-bionic block-proposed-focal
** Changed in: apt (Ubuntu)
Status: New => In Progress
--
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/1918928
Title:
APT 2021/03 SRU release scheduling
Status in apt package in Ubuntu:
In Progress
Bug description:
We want to release the APT SRUs from Mar 2021 in a staggered manner,
such that we have 2-3 days between each release to get more chance to
discover regressions before rolling out to older releases.
Hence this bug, which we tag block-proposed-{bionic,focal} and then
untag once the delay has passed.
For groovy, we just want the normal aging :-)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1918928/+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 1574186] Re: applications-development icon is partly black
According to migrated upstream bug https://gitlab.gnome.org/GNOME/librsvg/-/issues/141 This works correctly on librsvg 2.42.3. ** Bug watch added: gitlab.gnome.org/GNOME/librsvg/-/issues #141 https://gitlab.gnome.org/GNOME/librsvg/-/issues/141 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to librsvg in Ubuntu. https://bugs.launchpad.net/bugs/1574186 Title: applications-development icon is partly black Status in librsvg package in Ubuntu: Triaged Bug description: The issue appeared after upgrading to Ubuntu 16.04, the icon was right in 15.10. I'm using Ubuntu Mate but the issue is likely indpendant of the DE. When displaying the applications-development.svg icon (from categories), either in Caja (Nautilus fork) or the Applications menu, the silver part is black instead of the normal appearance. It only appears with sizes 16, 22, 24 & 32; sizes 48, 64 & 128 appear fine. The weird things is that it doesn't happen if I open the icons in Inkscape or display them in a HTML page. It only happens in the file manager and Apps menu (and probably other places I haven't been able to check, like menus and such). Might be a Gtk rendering issue rather than the icons themselves. I attach a montage that shows the black-ish icons. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/librsvg/+bug/1574186/+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 1899878] Re: Python's test_ssl fails starting from Ubuntu 20.04
I've read through this bug and I don't see a good way forward with a solution here. OpenSSL 1.1.1 doesn't provide the exact API that is required to solve it, which would probably be 3) as suggested above, but I don't think Ubuntu should change the meaning of the value returned by that API. Ubuntu is returning the value that is expected of the upstream 1.1.1 code when security levels are used. While Ubuntu, Debian, and Fedora use different approaches to achieve a similar goal, and Ubuntu did modify the meaning of security level 2 to restrict it further than the upstream default, the fact remains that building OpenSSL with a higher default security level results in a situation where there seems to be no good API to request what the minimum TLS version is. It may appear reasonable that a simple query to the current security level could have given a hardcoded indication of what is available. Unfortunately, that assumption doesn't stand the test of time as it is no longer valid once the security levels have been modified to align with the current best practices, either in a new OpenSSL release, or by a distro. This is a less than ideal situation, but I think the only way forward currently available when obsolete TLS versions need to be used is to set the minimum security level accepted by OpenSSL. We should work with upstream OpenSSL to make sure 3.0 provides the right APIs, documentation, and guidance that are required to handle changing defaults like this more elegantly in the future. -- 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/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 Status in openssl package in Ubuntu: Incomplete Bug description: Please take a look at https://bugs.python.org/issue41561. Developers who work on Python think that the issue is due to a change in Ubuntu 20.04 that is best described by https://bugs.python.org/issue41561#msg378089: "It sounds like a Debian/Ubuntu patch is breaking an assumption. Did somebody report the bug with Debian/Ubuntu maintainers of OpenSSL already? Fedora also configures OpenSSL with minimum protocol version of TLS 1.2. The distribution does it in a slightly different way that makes the restriction discoverable and that is compatible with Python's test suite." To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+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 1829860] Re: APT unlocks in same order as it locks
** Changed in: apt (Ubuntu Xenial) Status: New => Won't Fix -- 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/1829860 Title: APT unlocks in same order as it locks Status in apt package in Ubuntu: Fix Released Status in apt source package in Xenial: Won't Fix Status in apt source package in Bionic: Fix Released Status in apt source package in Disco: Fix Released Bug description: [Impact] APT releases the locks in the same order it acquires them, rather than reverse order. Given that we have no waiting for locks, this is not _super_ problematic, but it might be wrong: You'd get a lock failure on dpkg's lock, rather than lock-frontend. [Test case] Watch lock release with strace and see that it unlocks the right way. [Regression potential] Some other locking races or something? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1829860/+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 1918907] Re: Default Acquire::AllowReleaseInfoChange::Suite to "true"
Fixed since 2.1.10, which is in groovy already. ** No longer affects: apt (Ubuntu Groovy) ** Changed in: apt (Ubuntu) Status: New => Fix Released -- 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/1918907 Title: Default Acquire::AllowReleaseInfoChange::Suite to "true" Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: New Status in apt source package in Focal: New Bug description: [Impact] APT 1.6-2.0 deny third-party repositories from changing their Suite value. This change was reverted in later apt releases, and will be reverted in 1.8 in Debian as well, so for consistency, we want to push that change to stable [Test plan] We added test cases to our extensive integration test suite run by autopkgtest. [Where problems could occur] It's hard to imagine anything here, we simply turn the flag for allowed from false to true. We even add tests for Suite changes :) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1918907/+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 1918880] Re: pulseaudio threaded-ml suspend issue
"; realtime-scheduling = yes" is commented away in /etc/pulse/daemon.conf (this is a very fresh install of 20.04 and I haven't customized much). Should I enable this? Either way, I'll try to exercise suspend and keep an eye out for this issue happening again. I tried looking around but didn't find any similar reports. -- 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/1918880 Title: pulseaudio threaded-ml suspend issue Status in pulseaudio package in Ubuntu: Incomplete Bug description: My laptop failed to suspend overnight and was unresponsive when I opened it back up. This is on Ubuntu 20.04.2 LTS with kernel 5.6.0-1048-oem and pulseaudio:amd64/focal-updates 1:13.99.1-1ubuntu3.10 uptodate. In syslog, I found a stream of suspend attempts with pulseaudio-related issues repeating in a 40s cycle, so reporting this as a PA issue. Mar 12 00:08:31 churn systemd[1]: Reached target Sleep. Mar 12 00:08:31 churn upowerd[1698]: Could not acquire inhibitor lock: GDBus.Error:org.freedesktop.login1.OperationInProgress: The operation inhibition has been requested for is already running Mar 12 00:08:31 churn systemd[1]: Starting Suspend... Mar 12 00:08:31 churn ModemManager[1427]: [sleep-monitor] inhibit failed: GDBus.Error:org.freedesktop.login1.OperationInProgress: The operation inhibition has been requested for is already running Mar 12 00:08:31 churn kernel: [883904.845262] iwlwifi :00:14.3: Applying debug destination EXTERNAL_DRAM Mar 12 00:08:31 churn ModemManager[1427]: Couldn't check support for device '/sys/devices/pci:00/:00:14.3': Device support check task already available for device '/sys/devices/pci:00/:00:14.3' Mar 12 00:08:31 churn systemd-sleep[516395]: Suspending system... Mar 12 00:08:31 churn kernel: [883904.853576] PM: suspend entry (s2idle) Mar 12 00:08:51 churn kernel: [883904.856917] Filesystems sync: 0.003 seconds Mar 12 00:08:51 churn kernel: [883904.857284] Freezing user space processes ... Mar 12 00:08:51 churn kernel: [883904.991749] iwlwifi :00:14.3: FW already configured (0) - re-configuring Mar 12 00:08:51 churn kernel: [883924.868069] Freezing of tasks failed after 20.010 seconds (1 tasks refusing to freeze, wq_busy=0): Mar 12 00:08:51 churn kernel: [883924.868160] threaded-ml D0 3306 2128 0x80004326 Mar 12 00:08:51 churn kernel: [883924.868166] Call Trace: Mar 12 00:08:51 churn kernel: [883924.868183] __schedule+0x2d8/0x760 Mar 12 00:08:51 churn kernel: [883924.868188] schedule+0x55/0xc0 Mar 12 00:08:51 churn kernel: [883924.868195] do_exit.cold+0x9f/0xb5 Mar 12 00:08:51 churn kernel: [883924.868200] rewind_stack_do_exit+0x17/0x20 Mar 12 00:08:51 churn kernel: [883924.868205] RIP: 0033:0x7fc8a96ebcb9 Mar 12 00:08:51 churn kernel: [883924.868216] Code: Bad RIP value. Mar 12 00:08:51 churn kernel: [883924.868219] RSP: 002b:7fc899504850 EFLAGS: 0293 ORIG_RAX: 0007 Mar 12 00:08:51 churn kernel: [883924.868223] RAX: fdfc RBX: 208bbe357f60 RCX: 7fc8a96ebcb9 Mar 12 00:08:51 churn kernel: [883924.868225] RDX: 7530 RSI: 0003 RDI: 208bbe357f60 Mar 12 00:08:51 churn kernel: [883924.868227] RBP: 0003 R08: R09: 1587756a Mar 12 00:08:51 churn kernel: [883924.868229] R10: 0f90 R11: 0293 R12: 7530 Mar 12 00:08:51 churn kernel: [883924.868231] R13: 7530 R14: 208bbe3285d0 R15: 7fff6f13d440 Mar 12 00:08:51 churn kernel: [883924.868427] OOM killer enabled. Mar 12 00:08:51 churn rtkit-daemon[1608]: The canary thread is apparently starving. Taking action. Mar 12 00:08:51 churn NetworkManager[1297]: [1615504131.1026] device (p2p-dev-wlp0s20f3): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'managed') Mar 12 00:08:51 churn rtkit-daemon[1608]: Demoting known real-time threads. Mar 12 00:08:51 churn NetworkManager[1297]: [1615504131.1036] manager: NetworkManager state is now DISCONNECTED Mar 12 00:08:51 churn rtkit-daemon[1608]: Demoted 0 threads. Mar 12 00:08:51 churn NetworkManager[1297]: [1615504131.1039] manager: sleep: sleep requested (sleeping: no enabled: yes) Mar 12 00:08:51 churn NetworkManager[1297]: [1615504131.1039] device (wlp0s20f3): state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'managed') Mar 12 00:08:51 churn pulseaudio[2134]: q overrun, queuing locally Mar 12 00:08:51 churn kernel: [883924.868429] Restarting tasks ... done. Mar 12 00:08:51 churn pulseaudio[2134]: message repeated 4 times: [ q overrun, queuing locally] Mar 12 00:08:51 churn NetworkManager[1297]: [1615504131.1245] device (p2p-dev-wlp0s20f3): state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'ma
[Touch-packages] [Bug 1918920] Re: Harden test for no new acquires after transaction abort
This is fixed in 2.2.2 which will be synced ASAP, but this bug was created after 2.2.2 and hence is not closed in the changelog. ** Changed in: apt (Ubuntu) Status: New => Fix Committed -- 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/1918920 Title: Harden test for no new acquires after transaction abort Status in apt package in Ubuntu: Fix Committed Status in apt source package in Bionic: New Status in apt source package in Focal: New Status in apt source package in Groovy: New Bug description: [Impact] test-pdiff-usage is somewhat flaky, especially on Debian, this makes it less flaky. No end user impact as it's a test-only change. [Test plan] Running autopkgtest, which runs our extensive integration test suite which includes the changed test. [Where problems could occur] No end user regression potential on its own, but might slightly change regression potential for future pdiff changes: Test approach is slightly different now. It still catches that updates fail correctly, but tests more concretely that a transaction was aborted rather than that no worker received work (which was not guaranteed, the work could be scheduled before it was aborted). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1918920/+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 1918920] [NEW] Harden test for no new acquires after transaction abort
Public bug reported: [Impact] test-pdiff-usage is somewhat flaky, especially on Debian, this makes it less flaky. No end user impact as it's a test-only change. [Test plan] Running autopkgtest, which runs our extensive integration test suite which includes the changed test. [Where problems could occur] No end user regression potential on its own, but might slightly change regression potential for future pdiff changes: Test approach is slightly different now. It still catches that updates fail correctly, but tests more concretely that a transaction was aborted rather than that no worker received work (which was not guaranteed, the work could be scheduled before it was aborted). ** Affects: apt (Ubuntu) Importance: Undecided Status: Fix Committed ** Affects: apt (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: apt (Ubuntu Focal) Importance: Undecided Status: New ** Affects: apt (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: apt (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: apt (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: apt (Ubuntu Bionic) Importance: Undecided Status: New -- 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/1918920 Title: Harden test for no new acquires after transaction abort Status in apt package in Ubuntu: Fix Committed Status in apt source package in Bionic: New Status in apt source package in Focal: New Status in apt source package in Groovy: New Bug description: [Impact] test-pdiff-usage is somewhat flaky, especially on Debian, this makes it less flaky. No end user impact as it's a test-only change. [Test plan] Running autopkgtest, which runs our extensive integration test suite which includes the changed test. [Where problems could occur] No end user regression potential on its own, but might slightly change regression potential for future pdiff changes: Test approach is slightly different now. It still catches that updates fail correctly, but tests more concretely that a transaction was aborted rather than that no worker received work (which was not guaranteed, the work could be scheduled before it was aborted). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1918920/+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 1894172] Re: isc-dhcp-server using wrong env variable for INTERFACES
Hey,
The above regression was a false-positive; there were several retries,
all of them passed (cf:
https://autopkgtest.ubuntu.com/packages/c/chrony/bionic/armhf).
So this should be good to go (regression-wise)! \o/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1894172
Title:
isc-dhcp-server using wrong env variable for INTERFACES
Status in isc-dhcp package in Ubuntu:
Fix Released
Status in isc-dhcp source package in Bionic:
Fix Committed
Status in isc-dhcp source package in Focal:
Fix Committed
Status in isc-dhcp source package in Groovy:
Fix Committed
Bug description:
[Impact]
When checking isc-dhcp-server unit file it was seen that isc-dhcp-
server is being started by:
ConditionPathExists=/etc/default/isc-dhcp-server
ConditionPathExists=|/etc/ltsp/dhcpd.conf
ConditionPathExists=|/etc/dhcp/dhcpd.conf
[Service]
EnvironmentFile=/etc/default/isc-dhcp-server
RuntimeDirectory=dhcp-server
# The leases files need to be root:dhcpd even when dropping privileges
ExecStart=/bin/sh -ec '\
CONFIG_FILE=/etc/dhcp/dhcpd.conf; \
if [ -f /etc/ltsp/dhcpd.conf ]; then CONFIG_FILE=/etc/ltsp/dhcpd.conf;
fi; \
[ -e /var/lib/dhcp/dhcpd.leases ] || touch /var/lib/dhcp/dhcpd.leases; \
chown root:dhcpd /var/lib/dhcp /var/lib/dhcp/dhcpd.leases; \
chmod 775 /var/lib/dhcp ; chmod 664 /var/lib/dhcp/dhcpd.leases; \
exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid
-cf $CONFIG_FILE $INTERFACES'
But the /etc/default/isc-dhcp-server file sets $INTERFACESv4 and
$INTERFACESv6.
This causes the service to listen on all interfaces, which is what the
user might not want. In case the user wants to use *only* IPv6 and not
IPv4, this could maybe lead to problems as what the user intended to
do could be really different from what the outcome turns out to be
(because of this bug).
The previous upload(er) forgot to mention (and split) the INTERFACES
variable to v4 and v6 and as a result, it has been this way for so
long.
The SRU would split the variables into respective names, thereby
making sure that what /etc/default/isc-dhcp-serve sets, is available
in the respective service file.
[Test Plan]
To reproduce this bug, simply do the following:
$ lxc launch ubuntu-daily:focal isc-dhcp-lp1894172-focal
$ lxc shell isc-dhcp-lp1894172-focal
# apt update && apt install isc-dhcp-server -y
# grep "INTERFACES" /etc/default/isc-dhcp-server
INTERFACESv4=""
INTERFACESv6=""
grep "INTERFACES" /lib/systemd/system/isc-dhcp-server.service
exec dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid
-cf $CONFIG_FILE $INTERFACES'
# grep "INTERFACES" /lib/systemd/system/isc-dhcp-server6.service
exec dhcpd -user dhcpd -group dhcpd -f -6 -pf /run/dhcp-server/dhcpd6.pid
-cf $CONFIG_FILE $INTERFACES'
With this, it is clearly visible that even though /lib/systemd/system
/isc-dhcp-server{,6}.service file uses the INTERFACES variable but the
/etc/default/isc-dhcp-server defines 2 different variables,
INTERFACESv4 and INTERFACESv6.
After the SRU is performed, the respective services files should use
INTERFACESv4 and INTERFACESv6 variable, instead of just INTERFACES.
To ensure smooth upgrade of this package, we'd check if the user
hasn't manually set a INTERFACESv{4,6} variable to workaround this
bug. If they have, then we simply check and make sure, we use the
correct variable.
[Where problems could occur]
The problem could occur if the user has manually set some different
workaround for this bug and so the usual upgrade could break some of
their old configuration(s).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1894172/+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 1918907] Re: Default Acquire::AllowReleaseInfoChange::Suite to "true"
** Also affects: apt (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: apt (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: apt (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: apt (Ubuntu Focal) Importance: Undecided Status: New ** No longer affects: apt (Ubuntu Hirsute) -- 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/1918907 Title: Default Acquire::AllowReleaseInfoChange::Suite to "true" Status in apt package in Ubuntu: New Status in apt source package in Bionic: New Status in apt source package in Focal: New Status in apt source package in Groovy: New Bug description: [Impact] APT 1.6-2.0 deny third-party repositories from changing their Suite value. This change was reverted in later apt releases, and will be reverted in 1.8 in Debian as well, so for consistency, we want to push that change to stable [Test plan] We added test cases to our extensive integration test suite run by autopkgtest. [Where problems could occur] It's hard to imagine anything here, we simply turn the flag for allowed from false to true. We even add tests for Suite changes :) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1918907/+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 1918907] [NEW] Default Acquire::AllowReleaseInfoChange::Suite to "true"
Public bug reported: [Impact] APT 1.6-2.0 deny third-party repositories from changing their Suite value. This change was reverted in later apt releases, and will be reverted in 1.8 in Debian as well, so for consistency, we want to push that change to stable [Test plan] We added test cases to our extensive integration test suite run by autopkgtest. [Where problems could occur] It's hard to imagine anything here, we simply turn the flag for allowed from false to true. We even add tests for Suite changes :) ** Affects: apt (Ubuntu) Importance: Undecided Status: New -- 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/1918907 Title: Default Acquire::AllowReleaseInfoChange::Suite to "true" Status in apt package in Ubuntu: New Bug description: [Impact] APT 1.6-2.0 deny third-party repositories from changing their Suite value. This change was reverted in later apt releases, and will be reverted in 1.8 in Debian as well, so for consistency, we want to push that change to stable [Test plan] We added test cases to our extensive integration test suite run by autopkgtest. [Where problems could occur] It's hard to imagine anything here, we simply turn the flag for allowed from false to true. We even add tests for Suite changes :) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1918907/+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
