[Touch-packages] [Bug 1726124] Re: DNS domain search paths not updated when VPN started
I hope something can be worked out before this lands in the next LTS- release. This breaks one of the most common uses of a VPN (remote work). Right now a workaround is using this script after connecting to a VPN- server: https://github.com/jonathanio/update-systemd-resolved It calls systemd-resolved via DBus to add the proper settings after the OpenVPN connection is established. Of course this means abandoning NetworkManager for use with OpenVPN, because there is also no way to specify --up and --down parameters. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1726124 Title: DNS domain search paths not updated when VPN started Status in network-manager package in Ubuntu: Confirmed Status in network-manager-openvpn package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: I connect to work with openvpn through network-manager-openvpn. I'm selecting automatic (DHCP) to get an IP address, and "Use this connection only for resources on its network" to support split tunneling. In the last few versions of Ubuntu I used, this all worked fine. In Ubuntu 17.10 (fresh install, not upgrade) I can access hosts on both my VPN network and the internet, BUT I have to use FQDN for my VPN network hosts: the updates to the DNS search path provided by my VPN DHCP server are never being applied. Investigating the system I see that /etc/resolv.conf is pointing to /run/systemd/resolve/stub-resolv.conf and that resolv.conf does not have any of the VPN's search path settings in it: # This file is managed by man:systemd-resolved(8). Do not edit. # # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 127.0.0.53 search home In previous versions of Ubuntu, where NetworkManager controlled the resolver not systemd, /etc/resolv.conf pointed to /run/NetworkManager/resolv.conf and there was a local dnsmasq instance that managed all the complexity. In Ubuntu 17.10 when I look in /run/NetworkManager/resolv.conf file, I see that the search paths ARE properly updated there: $ cat /run/NetworkManager/resolv.conf # Generated by NetworkManager search internal.mycorp.com other.mycorp.com home nameserver 127.0.1.1 However this file isn't being used, and also there's no dnsmasq running on the system so if I switch my /etc/resolv.conf to point to this file instead, then all lookups fail. Strangely, if I look at the systemd-resolv status I see that in theory systemd-resolve does seem to know about the proper search paths: $ systemd-resolve --status ... Link 3 (tun0) Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.3.0.10 10.8.42.2 DNS Domain: ~internal.mycorp.com ~other.mycorp.com but for whatever reason the search domains are not getting put into the resolv.conf file: $ host mydesk ;; connection timed out; no servers could be reached $ host mydesk.internal.mycorp.com mydesk.internal.mycorp.com has address 10.8.37.74 (BTW, the timeout in the failed attempt above takes 10s: it is SUPER frustrating when all your host lookups are taking that long just to fail). ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: systemd 234-2ubuntu12 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 CurrentDesktop: GNOME Date: Sun Oct 22 15:08:57 2017 InstallationDate: Installed on 2017-10-21 (1 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Release amd64 (20171018) MachineType: System manufacturer System Product Name ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-16-generic root=UUID=4384306c-5fed-4b48-97a6-a6d594c4f72b ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 12/02/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 2101 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: M5A78L-M/USB3 dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Asset-1234567890
[Touch-packages] [Bug 1665893] Re: DNS resolution of VPN hosts stopped working
*** This bug is a duplicate of bug 1667825 *** https://bugs.launchpad.net/bugs/1667825 I am running into DNS issues with OpenVPN as well. When connected `dig ddg.gg` fails, but `dig ddg.gg @8.8.8.8` works. This started after running updates yesterday. I can't tell if bug #1667825 is the same issue, but I get the same problem regardless of whether I start OpenVPN from the command line or via the Network-Manager. (I'm not sure if the latter makes the connection 'managed' or not.) Can this issue be scaled up in importance if confirmed? Users not being able to use a VPN service (e.g., in a place with free public wifi) is a huge security risk! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1665893 Title: DNS resolution of VPN hosts stopped working Status in dnsmasq package in Ubuntu: Confirmed Bug description: I have been using 17.04 for a few weeks now, but a recent update seems to have broken DNS resolution for VPN hosts. The local network is 192.168.50.*, with DNS at 192.168.50.2. The remote network is 192.168.0.*, with DNS at 192.168.0.2. I can ping remote hosts, but I can't resolve their names, although syslog says the following: systemd-resolved[2865]: Switching to DNS server 192.168.0.2 for interface tun0. The remote DNS domain is ozone.caligrafix.cl. Here is what does and doesn't work, using a valid remote host name (cali00): dig cali00: fails dig cali00.ozone.caligrafix.cl: fails dig cali00 @192.168.0.2: works dig cali00.ozone.caligrafix.cl @192.168.0.2: works Here is the complete log of VPN connection setup: Feb 18 11:56:34 tadzim3 NetworkManager[2242]: [1487429794.9928] audit: op="connection-activate" uuid="ae3693ea-df59-414e-95a8-bf280a65b8db" name="cali-fw" pid=4439 uid=1000 result="success" Feb 18 11:56:34 tadzim3 NetworkManager[2242]: [1487429794.9976] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",0]: Started the VPN service, PID 7173 Feb 18 11:56:35 tadzim3 NetworkManager[2242]: [1487429795.0048] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",0]: Saw the service appear; activating connection Feb 18 11:56:35 tadzim3 NetworkManager[2242]: [1487429795.1165] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",0]: VPN plugin: state changed: starting (3) Feb 18 11:56:35 tadzim3 NetworkManager[2242]: [1487429795.1170] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",0]: VPN connection: (ConnectInteractive) reply received Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10 2017 Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08 Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: TCP/UDP: Preserving recently used remote address: [AF_INET]186.103.161.74:25402 Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: UDP link local: (not bound) Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: UDP link remote: [AF_INET]186.103.161.74:25402 Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: NOTE: chroot will be delayed because of --client, --pull, or --up-delay Feb 18 11:56:35 tadzim3 nm-openvpn[7180]: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay Feb 18 11:56:36 tadzim3 nm-openvpn[7180]: [cali-fw-vpn] Peer Connection Initiated with [AF_INET]186.103.161.74:25402 Feb 18 11:56:37 tadzim3 nm-openvpn[7180]: TUN/TAP device tun0 opened Feb 18 11:56:37 tadzim3 nm-openvpn[7180]: /usr/lib/NetworkManager/nm-openvpn-service-openvpn-helper --debug 0 7173 --bus-name org.freedesktop.NetworkManager.openvpn.Connection_6 --tun -- tun0 1500 1558 10.8.1.2 255.255.255.0 init Feb 18 11:56:37 tadzim3 NetworkManager[2242]: [1487429797.1267] manager: (tun0): new Tun device (/org/freedesktop/NetworkManager/Devices/7) Feb 18 11:56:37 tadzim3 NetworkManager[2242]: [1487429797.1368] devices added (path: /sys/devices/virtual/net/tun0, iface: tun0) Feb 18 11:56:37 tadzim3 NetworkManager[2242]: [1487429797.1368] device added (path: /sys/devices/virtual/net/tun0, iface: tun0): no ifupdown configuration found. Feb 18 11:56:37 tadzim3 NetworkManager[2242]: [1487429797.1443] vpn-connection[0x5622aa56c370,ae3693ea-df59-414e-95a8-bf280a65b8db,"cali-fw",0]: VPN connection: (IP Config Get) reply received. Feb 18 11:56:37 tadzim3 NetworkManager[2242]: [1487429797.1463]
[Touch-packages] [Bug 1607291] Re: Dual SIM devices show "No SIM" icon in indicators if there is only one SIM installed
If this becomes an option in 'custom tarball', does that mean I can access that option with the regular OTA updates? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to indicator-network in Ubuntu. https://bugs.launchpad.net/bugs/1607291 Title: Dual SIM devices show "No SIM" icon in indicators if there is only one SIM installed Status in Canonical System Image: Confirmed Status in Ubuntu UX: New Status in indicator-network package in Ubuntu: Incomplete Bug description: rc-proposed, since about a week I have 2 SIM icons in the indicators panel. One that shows the signal strength for the installed SIM card (which is fine), and then a second one which shows the "no SIM card" icon. When there is a SIM card installed, the indicator should not show a "no SIM installed" icon, even though there would be a second free slot available. See attached screenshot. To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1607291/+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 1592108] Re: No option to disable remote album/artist/track art requests
Thanks for the in-depth reply. It is reassuring to hear that dash.ubuntu.com acts as a proxy. On a personal level I find this to be more tolerable than a direct interface with a commercial service I have no customer relation with. The data aspect alone is probably enough to warrant inclusion of a toggle for this feature, or perhaps an option to only download this kind of data when connected to wifi. That said, I politely disagree on the privacy aspect. Please indulge me — an avid Ubuntu user — in relating my personal view on this matter. >From a principled standpoint there are two things that would help in maintaining Ubuntu's reputation with regards to privacy. One is informed consent. It would like to be informed about what kind of data is being automatically transmitted to other parties. Perhaps via a page in the documentation that lists the various types of external connections that are being made on a stock release of Ubuntu Touch (and probably the normal Ubuntu OS). Is such a list available? One reason that I mention this is that the default behaviour of the dash in stock desktop Ubuntu used to be to search Amazon automatically with search terms entered. This has since been disabled by default, but did raise valid privacy concerns. I feel strongly that Ubuntu is the kind of OS where users are actively given a chance to influence the data they are broadcasting, especially in this age of mass surveillance and mass tracking. But to do that, users must be aware of what is happening and who they are communicating with. As you mention it makes quite a difference if artwork requests are done directly to 7digital or via Canonical's proxy. The second is perhaps an extension of that, and is simply to enable users to disable this kind of behaviour. Ideally users can disable third party communications like these (indirect) requests to 7digital at will from the Privacy and Security settings. I will admit that music artwork does seem lot less sensitive in terms of its privacy impact than general searches in the dash, but I feel strongly that this decision should be left with the user, especially for stock software included with the OS, and bundled services of the OS (e.g., the thumbnailer). A hypothetical case that comes to my mind is this. Consider Wikipedia's list of controversial album art¹. If I was visiting a country with strict laws regarding nudity and sexuality and an active policy of examining your personal electronic devices at the border (sadly, not unlikely these days) it would be unpleasant — at the very least — to have a Music App fetch the album covers for, say, Nirvana – Nevermind or The Scorpions – Virgin Killer (!). Needless to say that even if the music itself was allowed, possession of these kind of images is highly illegal in such jurisdictions, with punishments that are no laughing matter. If our hypothetical Scorpions- fan took care not to upload any music tagged with album covers to his device, he would still end up with those covers in plain view to any customs officer inspecting his phone or tablet. 1: https://en.wikipedia.org/wiki/List_of_controversial_album_art -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to thumbnailer in Ubuntu. https://bugs.launchpad.net/bugs/1592108 Title: No option to disable remote album/artist/track art requests Status in Ubuntu Music App: Invalid Status in Ubuntu UX: New Status in thumbnailer package in Ubuntu: New Status in ubuntu-system-settings package in Ubuntu: New Bug description: The Music App appears to download album/artist/track art automatically. Is there a way to disable this functionality to save bandwidth? The Music App does not appear to have any user settings at all (unless I am overlooking them). The service used to fetch the art from is far from bug-free. For an album called 'Musik für festliche Stunden' I get an album cover for 'Strauss zum Saubermachen'. While that does seem like an interesting album (clean the house with Strauss?) it is not even remotely the correct album. To manage notifications about this bug go to: https://bugs.launchpad.net/music-app/+bug/1592108/+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 1592108] Re: No option to disable album/artist/track art requests
Do I understand correctly that the thumbnailer uses a remote service (7digital?) by default? >From a user's perspective I would expect to be able to reach this setting from the Music App, but if the use of this remote service is something that is done by the thumbnailer, I am not sure if adding it as an option to only the Music App is correct. If I understand correctly; from an engineering perspective the thumbnailer's job is to get the art, the Music App uses the art, but does not care how the thumbnailer got it. Perhaps this should be a system-wide setting under 'Security & Privacy' instead? I must admit that I am not wholly comfortable with the idea of a daemon (thumbnailer) contacting commercial third party resources without being able to turn it off. ** Summary changed: - No option to disable album/artist/track art requests + No option to disable remote album/artist/track art requests -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to thumbnailer in Ubuntu. https://bugs.launchpad.net/bugs/1592108 Title: No option to disable remote album/artist/track art requests Status in Ubuntu Music App: New Status in Ubuntu UX: New Status in thumbnailer package in Ubuntu: New Bug description: The Music App appears to download album/artist/track art automatically. Is there a way to disable this functionality to save bandwidth? The Music App does not appear to have any user settings at all (unless I am overlooking them). The service used to fetch the art from is far from bug-free. For an album called 'Musik für festliche Stunden' I get an album cover for 'Strauss zum Saubermachen'. While that does seem like an interesting album (clean the house with Strauss?) it is not even remotely the correct album. To manage notifications about this bug go to: https://bugs.launchpad.net/music-app/+bug/1592108/+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 1536307] Re: Unknown albums and unknown artists should not be shown
Temporary workaround: In the album view, enter a single space in the search field. This seems to filter out all the 'Unknown Albums'. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to thumbnailer in Ubuntu. https://bugs.launchpad.net/bugs/1536307 Title: Unknown albums and unknown artists should not be shown Status in Ubuntu Music App: New Status in thumbnailer package in Ubuntu: Triaged Bug description: Unpack the attached archive into the Music folder and wait for mediascanner to finish indexing (takes a few minutes). Now look at the album tab in the music app. There are hundreds of unknown albums at the beginning of the list. The attached music collection has a lot of poorly tagged songs in it (just like many users' collections will have imperfectly tagged songs). There are lots of songs with an empty album tag. (Such songs are legit too because I might add, say, audio recordings of a meeting or audio books to my collection.) The music app shows a separate "Unknown Album" for each and every song with an empty album tag. That's wrong. It should not show any album at all in this case because, by definition, a song with no album tag isn't part of any album--it's a stand-along song. (Note that collapsing all songs without an album tag into a single album not an option because it would conflate many unrelated tracks into a single album that doesn't exist.) This is how the mediascanner scope deals with empty albums; the music app should do the same thing. To manage notifications about this bug go to: https://bugs.launchpad.net/music-app/+bug/1536307/+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 1536307] Re: Unknown albums and unknown artists should not be shown
(Problem present in OTA-11) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to thumbnailer in Ubuntu. https://bugs.launchpad.net/bugs/1536307 Title: Unknown albums and unknown artists should not be shown Status in Ubuntu Music App: New Status in thumbnailer package in Ubuntu: Triaged Bug description: Unpack the attached archive into the Music folder and wait for mediascanner to finish indexing (takes a few minutes). Now look at the album tab in the music app. There are hundreds of unknown albums at the beginning of the list. The attached music collection has a lot of poorly tagged songs in it (just like many users' collections will have imperfectly tagged songs). There are lots of songs with an empty album tag. (Such songs are legit too because I might add, say, audio recordings of a meeting or audio books to my collection.) The music app shows a separate "Unknown Album" for each and every song with an empty album tag. That's wrong. It should not show any album at all in this case because, by definition, a song with no album tag isn't part of any album--it's a stand-along song. (Note that collapsing all songs without an album tag into a single album not an option because it would conflate many unrelated tracks into a single album that doesn't exist.) This is how the mediascanner scope deals with empty albums; the music app should do the same thing. To manage notifications about this bug go to: https://bugs.launchpad.net/music-app/+bug/1536307/+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 1536307] Re: Unknown albums and unknown artists should not be shown
I have the same problem, but with a music collection that is actually quite well-tagged. For a lot of (pop) music the actual album something came from is irrelevant and undesirable to have tagged, because it clutters up the album view of (other) music players. When I am browsing albums, I expect to see only albums I own in their entirety, not 'albums' that contain only that one-off hit and miss all other tracks. The problem here is that any song that lacks the album tag, gets shown in the album view as a unique artist/album combination. Right now I have a thousand or so stand-alone tracks (starting with 10cc – Unknown Album and ending with ZZ Top – Unknown Album) to swipe-scroll through before I get to the real albums. This takes about two minutes, and has to be done every time you open the music app. Rather unworkable. I would suggest grouping all tracks that lack an album tag into a single 'Unknown Album' pseudo-album, regardless of artist. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to thumbnailer in Ubuntu. https://bugs.launchpad.net/bugs/1536307 Title: Unknown albums and unknown artists should not be shown Status in Ubuntu Music App: New Status in thumbnailer package in Ubuntu: Triaged Bug description: Unpack the attached archive into the Music folder and wait for mediascanner to finish indexing (takes a few minutes). Now look at the album tab in the music app. There are hundreds of unknown albums at the beginning of the list. The attached music collection has a lot of poorly tagged songs in it (just like many users' collections will have imperfectly tagged songs). There are lots of songs with an empty album tag. (Such songs are legit too because I might add, say, audio recordings of a meeting or audio books to my collection.) The music app shows a separate "Unknown Album" for each and every song with an empty album tag. That's wrong. It should not show any album at all in this case because, by definition, a song with no album tag isn't part of any album--it's a stand-along song. (Note that collapsing all songs without an album tag into a single album not an option because it would conflate many unrelated tracks into a single album that doesn't exist.) This is how the mediascanner scope deals with empty albums; the music app should do the same thing. To manage notifications about this bug go to: https://bugs.launchpad.net/music-app/+bug/1536307/+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 1587321] Re: Browser: Path component of URL is hidden by default
It is an understandable design decision, and from an aesthetic standpoint truncating the URL does make sense. My objection is twofold. One problem is that in my opinion truncating the URL limits the usability of the browser. Even though plenty of website do make a mess of anything behind the /, other websites and services do have understandable, bookmarkable URLs that aid the user in his or her browsing. Thankfully the URL is still a usable part of many websites, and modern Javasript frameworks too (traditionally the place where URLs were mangled for technical reasons) are now once again embracing proper and usable URLs (e.g., EmberJS). Philosophically, I worry about hiding something as empowering and basic to the web as the URL. While I can sympathise with the notion that the path, query, and fragment parts of a HTTP URL are often technical details that may clutter the UI and confuse some users, I feel that hiding it is not in the spirit of the open web, and does not benefit users in the long run. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to webbrowser-app in Ubuntu. https://bugs.launchpad.net/bugs/1587321 Title: Browser: Path component of URL is hidden by default Status in Canonical System Image: Incomplete Status in Ubuntu UX: New Status in webbrowser-app package in Ubuntu: Confirmed Bug description: Current behaviour: In the web browser the URL gets truncated to just the (sub)domain part. For example, the URL of the 'report a bug' form on Launchpad is: https://bugs.launchpad.net/canonical-devices-system-image/+filebug What is displayed in the browser is: bugs.launchpad.net The rest of the URL won't show until you touch the address bar. This behaviour is problematic, because it hides one of the primary attributes of the open web. Expected behaviour: By default the URL should not be hidden. Because space is constrained on the typical devices this browser is used on, the protocol part can be omitted by default, as long as the typical lock icon is present for HTTPS URL (see attached image). So by default: bugs.launchpad.net/canonical-devices-system-image/+filebug On touch on the address bar: https://bugs.launchpad.net/canonical-devices-system-image/+filebug I would recommend following the standard behaviour of modern web browsers to emphasize the domain part of the URL in black (with the rest of the URL in grey) as well. Device: Meizu Pro 5 (OTA 10.2) To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1587321/+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
