[Bug 1396379] Re: installer uses first EFI system partition found even when directed otherwise
This is still happening in Ubuntu 21.10, and the installer interface is very confusing. I wanted to create an Ubuntu installer on an external drive, so I connected the Ubuntu 21.10 live USB to one port, and an USB SSD to another port. When installing, I made sure to choose /dev/sdc (the usb ssd drive) as my target external device both for installing my system and for installing the bootloader (an explicit option in the modern installer). In the end, ubuntu installed its uefi files on my internal nvme drive efi partition, making both my system and the external usb ssd non bootable. My 2c: this is serious. But if it can't be solved because it's too hard... just don't let the user select their bootloader device, and issue a "BIG FAT WARNING: YOUR MAIN EFI PARTITION - /dev/nvme0p1n1 - will be modified!" message. Then I can choose what to do. I would expect such behaviour from Windows. Not from Ubuntu. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1396379 Title: installer uses first EFI system partition found even when directed otherwise To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1737534] Re: smbd/nmbd don't restart after upgrade if started but disabled
Uhm, so I should ENABLE the service, and then prevent it from starting? Isn't that a bit convolute? Also, in the other ticket you say that "The debian and ubuntu way is that if you don't want it running, you shouldn't install it." -> may I ask where this fact is stated? My understanding was that an upgrade should not alter the state of the system - if a service is running and must be restarted after an upgrade, it is restarted, otherwise it's left alone (the try-restart use-case). I've never seen stated that after an upgrade a service should pick the state which is currently mandated by the runlevel/init system, and it's the first time it happens to me (in other contexts, I would start services via ansible/puppet). Sure, your workaround might work. But the "the correct expected outcome", IMHO, is that the status of a service (started/stopped) should be the same before and after an upgrade, regardless of whether the unit is active or inactive. To me, this seems to be the behaviour of whatever I've encountered on Debian/Ubuntu/Centos in the last 10 years (barring bugs). I did a couple of cross checks for some system packages, and everything I tested (nginx, apache) seems to work this way; I even just checked nginx on Ubuntu 14.04 and works as stated above (i.e. service is disabled but started, after upgrade it's restarted properly). If you need more specific data I'll provide you with that... maybe it's a matter that there's no consensus on Debian/Ubuntu about the topic, but I'd say it's high time that such consensus is created. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1737534 Title: smbd/nmbd don't restart after upgrade if started but disabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1737534/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1737534] [NEW] smbd/nmbd don't restart after upgrade if started but disabled
Public bug reported: If smbd and nmbd are started and running but their service is disabled, and an apt-get upgrade is performed which updates samba/samba-common, at the end of the upgrade the smbd and nmbd daemons will not be running anymore. Distribution: Ubuntu 16.04 Pre-upgrade version: 4.3.8+dfsg-0ubuntu1 Post-upgrade version: 4.3.11+dfsg-0ubuntu0.16.04.12 What I expected to happen: After the dist-upgrade, since smbd and nmbd services were running, they should have been started again What happened instead: smbd and nmbd services are inactive. The problem doesn't arise if the service is enabled; I suppose that somewhere after the upgrade, the samba package queries for the global unit enablement status rather than the unit status before the upgrade; this is especially problematic with unattended-upgrades, there're reasons for which I don't start samba at boot (it gets started by an ansible task after a disk is checked, decrypted and mounted), and it has happened to me to have a machine with samba properly running and then dead after an automated upgrade. ** Affects: samba (Ubuntu) Importance: Undecided Status: New ** Attachment added: "full upgrade log transcript" https://bugs.launchpad.net/bugs/1737534/+attachment/5021329/+files/smb-upgrade-norestart.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1737534 Title: smbd/nmbd don't restart after upgrade if started but disabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1737534/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1704682] Re: isc-dhcp-client gladly accepts and sets server options that were not requested
I forgot to dump the routing table after the client went up: user@bitbuntu:/etc/dhcp$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.20.20.1 0.0.0.0 UG0 00 enp0s3 172.20.20.0 0.0.0.0 255.255.255.0 U 0 00 enp0s3 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1704682 Title: isc-dhcp-client gladly accepts and sets server options that were not requested To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1704682/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1704682] [NEW] isc-dhcp-client gladly accepts and sets server options that were not requested
Public bug reported:
Operating System: Ubuntu 16.04 amd64, fully updated. isc-dhcp-client
package 4.3.3-5ubuntu12.7
I noticed this behaviour when trying a special setting (I didn't want to
accept the default gateway from my dhcp server). Even if I modify the
request setting by removing the routers, thus causing dhclient NOT to
send the 'Routers' option (option 3), my home router (Asus DSL-n66u)
sends everything it knows, including the default gateway.
But, from reading the documentation and various mailing lists, it seems
that the client should DISCARD options that were not requested. That
could even be a security vulnerability; a rogue DHCP server could break
much more havoc than expected, e.g. redirecting an host's default
gateway while the owner thought that was impossible.
dhclient.conf:
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
netbios-name-servers, netbios-scope, interface-mtu,
ntp-servers;
interface "enp0s3" {
request subnet-mask, broadcast-address;
}
tcpdump log:
00:45:48.691568 Out 08:00:27:4b:a4:c9 ethertype IPv4 (0x0800), length 344: (tos
0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from
08:00:27:4b:a4:c9, length 300, xid 0xc9572a43, secs 3, Flags [none] (0x)
Client-Ethernet-Address 08:00:27:4b:a4:c9
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Requested-IP Option 50, length 4: 172.20.20.92
Hostname Option 12, length 8: "bitbuntu"
Parameter-Request Option 55, length 2:
Subnet-Mask, BR
0x: 4510 0148 8011 3996 E..H..9.
0x0010: 0044 0043 0134 f56e 0101 0600 .D.C.4.n
0x0020: c957 2a43 0003 .W*C
0x0030: 0800 274b a4c9 ..'K
0x0040:
0x0050:
0x0060:
0x0070:
0x0080:
0x0090:
0x00a0:
0x00b0:
0x00c0:
0x00d0:
0x00e0:
0x00f0:
0x0100: 6382 5363 3501 0132 c.Sc5..2
0x0110: 04ac 1414 5c0c 0862 6974 6275 6e74 7537 \..bitbuntu7
0x0120: 0201 1cff
0x0130:
0x0140:
00:45:48.691583 B 08:00:27:4b:a4:c9 ethertype IPv4 (0x0800), length 344: (tos
0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from
08:00:27:4b:a4:c9, length 300, xid 0xc9572a43, secs 3, Flags [none] (0x)
Client-Ethernet-Address 08:00:27:4b:a4:c9
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Requested-IP Option 50, length 4: 172.20.20.92
Hostname Option 12, length 8: "bitbuntu"
Parameter-Request Option 55, length 2:
Subnet-Mask, BR
0x: 4510 0148 8011 3996 E..H..9.
0x0010: 0044 0043 0134 f56e 0101 0600 .D.C.4.n
0x0020: c957 2a43 0003 .W*C
0x0030: 0800 274b a4c9 ..'K
0x0040:
0x0050:
0x0060:
0x0070:
0x0080:
0x0090:
0x00a0:
[Bug 1623087] Re: GnuPG can't find /usr/bin/dirmngr
This is related to
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1634464 as well,
where the maintainer says the "apt-key adv" is deprecated ("like
everything else"). Not easy to understand what's deprecated.
By the way, "gpg --keyserver YYY --recv-key XXX" works 100% in Ubuntu
Xenial, with no deprecation or warning whatsoever. It should not break
in such unexpected way on Yakkety. It seems a gnupg->gnupg2 migration
issue to me; I think that at least for Yakkety dirmngr should be
included as a required dependency from gnupg2, a warning on the
deprecation of such feature could be issues, then the dirmngr package
could be switched to an optional dep LATER.
Even though IMHO such behaviour is still bad. If I do "gpg --help" in
ubuntu yakkety, I clearly see the "--recv-keys" option. Then it breaks
when using it if dirmngr is not installed. I would not list such option
and let the user employ a different command altogether for fetching
remote keys, instead: that would be WAY easier.
By the way, PLEASE consider that
"apt-key adv --keyserver ..."
is a VERY widely used and recommended command for installing keys. And
some keyservers may not even expose a decent way of fetching public keys
without the HKP protocol, making gpg --keyserver "the right choice".
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1623087
Title:
GnuPG can't find /usr/bin/dirmngr
To manage notifications about this bug go to:
https://bugs.launchpad.net/hundredpapercuts/+bug/1623087/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1634464] Re: cloudimg apt missing dirmngr
I would add: the current Ubuntu help page (yes, it's a community one, but nothing official exists AFAIK) for SecureApt, as well as the Debian one, advertise a gpg feature which doesn't work anymore in Yakkety: https://help.ubuntu.com/community/SecureApt https://wiki.debian.org/SecureApt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1634464 Title: cloudimg apt missing dirmngr To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1634464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1634464] Re: cloudimg apt missing dirmngr
Hello Julian, some notes on your answer. "If you want to use optional (deprecated) features of apt-key like adv" -> How could I tell that "apt-key adv" is deprecated? Neither the man page nor the command says that adv is deprecated, and I couldn't find anything related in the first Google search result. "like almost everything else" -> what are you referring to? apt-key itself is deprecated? Why this is not written in the man page or in the output? Also, apt-key manpage only tells the user about the need of installing gnupg manually if the advanced options are required - dirmngr is not mentioned ANYWHERE. So: - I'm using a pattern that I've been using, successfully, for years on Ubuntu and Debian distros; - apt-key is installed; - gnupg is installed; - there's no other documentation about that anywhere (release notes? https://wiki.ubuntu.com/YakketyYak/ReleaseNotes ) OF COURSE as a user I think there's a yakkety bug. And, I might say, this is an example of a bad migration path; if I perform this command on Xenial $ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv A1D267C030C00DCB877900ED939C61C5D1270819 [sudo] password for alan: Executing: /tmp/tmp.FAWWu2wvKx/gpg.1.sh --keyserver keyserver.ubuntu.com --recv A1D267C030C00DCB877900ED939C61C5D1270819 gpg: requesting key D1270819 from hkp server keyserver.ubuntu.com gpg: key D1270819: "Alan Franzoni (automated signing key) <automa...@franzoni.eu>" not changed gpg: Total number processed: 1 gpg: unchanged: 1 I should AT LEAST receive a "pending deprecation" warning. On the contrary, it works 100% and gives me absolutely no clue on the fact I'm doing something wrong. That's not the way to go. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1634464 Title: cloudimg apt missing dirmngr To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1634464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1479251] Re: E: Package 'libegl1-mesa-drivers-lts-vivid' has no installation candidate
I was unable to migrate from the Utopic to the Vivid stack with the provided commands; it seems that the --install-recommends breaks on some dependency to libegl1-mesa-drivers-lts-vivid, which is not installable. My upgrade succeeded without the install recommends: sudo apt-get install linux-generic-lts-vivid xserver-xorg-core-lts-vivid xserver-xorg-lts-vivid xserver-xorg-video-all-lts-vivid xserver-xorg- input-all-lts-vivid libwayland-egl1-mesa-lts-vivid libegl1-mesa-lts- vivid libgbm1-lts-vivid libgl1-mesa-dri-lts-vivid libgl1-mesa-glx- lts-vivid libgles2-mesa-lts-vivid libgles1-mesa-lts-vivid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1479251 Title: E: Package 'libegl1-mesa-drivers-lts-vivid' has no installation candidate To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mesa-lts-vivid/+bug/1479251/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 106960] Re: Python 2.5 testing issues
Asking anything after seven years is pointless, isn't it? On Tue, Feb 11, 2014 at 11:06 AM, Sebastian Ramacher 106...@bugs.launchpad.net wrote: Is this still an issue? ** Changed in: codespeak-lib (Ubuntu) Status: Confirmed = Incomplete -- You received this bug notification because you are subscribed to the bug report. https://bugs.launchpad.net/bugs/106960 Title: Python 2.5 testing issues To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/codespeak-lib/+bug/106960/+subscriptions -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/106960 Title: Python 2.5 testing issues To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/codespeak-lib/+bug/106960/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 688335] [NEW] superfluous __init__.py generates import errors
Public bug reported: The zope.interface package is manually copying __init__.py from sources to the zope directory. This should NOT be done when a nspkg.pth is installed for the package, as it is correctly done. Although this does not seem to provoke issues at a first glance, it's what provokes two hard-to-track issues with zc.buildout: https://bugs.launchpad.net/zc.buildout/+bug/685638 https://bugs.launchpad.net/zc.buildout/+bug/659231 if you check other zope.* packages in debian/ubuntu, you'll see none of them manually copy __init__.py . Full discussion here: http://mail.python.org/pipermail/distutils-sig/2010-December/017127.html Patch attached. I'll open a bug in Debian ASAP: ** Affects: zope.interface (Ubuntu) Importance: Undecided Status: New ** Tags: interface python zope -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/688335 Title: superfluous __init__.py generates import errors -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 688335] Re: superfluous __init__.py generates import errors
** Patch added: don't copy __init__.py https://bugs.launchpad.net/bugs/688335/+attachment/1761450/+files/init.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/688335 Title: superfluous __init__.py generates import errors -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 369203] Re: Python2.5.4 curses.initscr() fails
IPython stopped working as well. The root cause seems to be the application of curses-init.dpatch (which was allegedly created for python2.6) on python = 2.5 interpreters in the latest 2.5.4-1ubuntu4 release (in Jaunty, not sure which release introduces such patch in other distro version). If the additional patch provided by Evan Broder can't be applied for some reason, just prevent the curses-init.dpatch from being applied in 2.5! It seems pretty pointless to apply a patch which should improve functionality which screws up everything instead. -- Python2.5.4 curses.initscr() fails https://bugs.launchpad.net/bugs/369203 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 365798] Re: cpu frequency scaling not supported after upgrading to 9.04
I'm experiencing the very same issue on Jaunty 64 bit on Athlon 64 x2. What really seems to have happened is that some functionalities which were built as *modules* in the 2.6.27 kernel are now built right into the kernel: 64 bit config comparison (unset values removed): config-2.6.27-11-generic:424:CONFIG_CPU_FREQ=y config-2.6.27-11-generic:428:CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y config-2.6.27-11-generic:431:CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m config-2.6.27-11-generic:432:CONFIG_CPU_FREQ_GOV_ONDEMAND=m config-2.6.27-11-generic:433:CONFIG_CPU_FREQ_GOV_PERFORMANCE=y config-2.6.27-11-generic:434:CONFIG_CPU_FREQ_GOV_POWERSAVE=m config-2.6.27-11-generic:435:CONFIG_CPU_FREQ_GOV_USERSPACE=m config-2.6.27-11-generic:436:CONFIG_CPU_FREQ_STAT=m config-2.6.27-11-generic:437:CONFIG_CPU_FREQ_STAT_DETAILS=y config-2.6.27-11-generic:438:CONFIG_CPU_FREQ_TABLE=m config-2.6.27-11-generic:3392:CONFIG_X86_ACPI_CPUFREQ=m config-2.6.27-11-generic:3420:CONFIG_X86_POWERNOW_K8=m config-2.6.27-11-generic:3421:CONFIG_X86_POWERNOW_K8_ACPI=y config-2.6.28-11-generic:429:CONFIG_CPU_FREQ=y config-2.6.28-11-generic:433:CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y config-2.6.28-11-generic:436:CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y config-2.6.28-11-generic:437:CONFIG_CPU_FREQ_GOV_ONDEMAND=y config-2.6.28-11-generic:438:CONFIG_CPU_FREQ_GOV_PERFORMANCE=y config-2.6.28-11-generic:439:CONFIG_CPU_FREQ_GOV_POWERSAVE=y config-2.6.28-11-generic:440:CONFIG_CPU_FREQ_GOV_USERSPACE=y config-2.6.28-11-generic:441:CONFIG_CPU_FREQ_STAT=y config-2.6.28-11-generic:442:CONFIG_CPU_FREQ_STAT_DETAILS=y config-2.6.28-11-generic:443:CONFIG_CPU_FREQ_TABLE=y config-2.6.28-11-generic:3601:CONFIG_X86_ACPI_CPUFREQ=y config-2.6.28-11-generic:3630:CONFIG_X86_POWERNOW_K8=y config-2.6.28-11-generic:3631:CONFIG_X86_POWERNOW_K8_ACPI=y But probably something did not work with some modules / kernel parts. Maybe some functions were designed to work as modules only, and they simply can't work if builtin? Experience with 3 Jaunty PCs: 1) HP Desktop with a Pentium E2160 CPU and Jaunty 32 bit - cpufreq still available and working 2)Dell desktop with Core 2 Duo E6xxx CPU, Jaunty 32 bit - cpufreq still available and working 3) Homebuilt Athlon 64 x2, Jaunty 64 bit - cpufreq unavailable since Jaunty upgrade. I'm attaching a tar.gz with the output from cpuinfo, uname -a and find for the three pcs. ** Attachment added: cpufreq_issues.tar.gz http://launchpadlibrarian.net/27166496/cpufreq_issues.tar.gz -- cpu frequency scaling not supported after upgrading to 9.04 https://bugs.launchpad.net/bugs/365798 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 380220] [NEW] 'Rename session' shortcut Ctrl+Alt+S seems impossible to assign
Public bug reported: Binary package hint: yakuake Ubuntu version: Jaunty 32 bit Package: yakuake2.9.4-0ubuntu1 It seems impossibile to make Ctrl+Alt+S shortcut (which used to rename the currently active session) work on Jaunty with kubuntu-desktop (kde4). If I use it out-of-the box (i.e. fresh install of yakuake) it just says the setting for ctrl+alt+s is ambiguous and suggests I open the Configure shortcuts from the Settings Menu and check it out for duplicate assignments. By the way all the key bindings are the default ones, and ctrl+alt+s is bound to 'Rename session'. If I remove such a key bind, ctrl+alt+s performs the rename tab action, whose setting I can't find in yakuake and seems to rename the full yakuake window title (not just the session name - i.e. the line which goes on with 'KDE Terminal Emulator' ). If i fire up konsole, I can see Ctrl+Alt+S is bound to 'Rename tab' (BTW yakuake just uses one tab and multiple sessions). If i delete the keybinding in konsole it is correctly cleared from it, but yakuake seems still stuck to rename tab. It is just as if it ctrl+alt+s is an hardcoded keybinding for rename tab in yakuake, or maybe it was forgot to let the user edit it in Configure shortcuts? ** Affects: yakuake (Ubuntu) Importance: Undecided Status: New -- 'Rename session' shortcut Ctrl+Alt+S seems impossible to assign https://bugs.launchpad.net/bugs/380220 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
