[Desktop-packages] [Bug 1338304] [NEW] Chromium Lubuntu 14.04 show block characters for Chinese

2014-07-06 Thread voidvector 
Public bug reported:

Chinese characters show up as blocks in Chromium (and Chrome) for
Lubuntu 14.04.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: chromium-browser 34.0.1847.116-0ubuntu2
ProcVersionSignature: Ubuntu 3.13.0-30.55-generic 3.13.11.2
Uname: Linux 3.13.0-30-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
CurrentDesktop: LXDE
Date: Sun Jul  6 16:49:53 2014
Desktop-Session:
 DESKTOP_SESSION = Lubuntu
 XDG_CONFIG_DIRS = 
/etc/xdg/lubuntu:/etc/xdg/xdg-Lubuntu:/usr/share/upstart/xdg:/etc/xdg
 XDG_DATA_DIRS = 
/etc/xdg/lubuntu:/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/share/Lubuntu:/usr/local/share/:/usr/share/
DetectedPlugins:
 
Env:
 MOZ_PLUGIN_PATH = None
 LD_LIBRARY_PATH = None
ExecutablePath: /usr/lib/chromium-browser/chromium-browser
InstallationDate: Installed on 2014-04-21 (76 days ago)
InstallationMedia: Lubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
SourcePackage: chromium-browser
UpgradeStatus: No upgrade log present (probably fresh install)
gconf-keys: /desktop/gnome/applications/browser/exec = 
b'firefox\n'/desktop/gnome/url-handlers/https/command = b'sensible-browser 
%s\n'/desktop/gnome/url-handlers/https/enabled = 
b'true\n'/desktop/gnome/url-handlers/http/command = b'sensible-browser 
%s\n'/desktop/gnome/url-handlers/http/enabled = 
b'true\n'/desktop/gnome/session/required_components/windowmanager = 
b''/apps/metacity/general/compositing_manager = 
b''/desktop/gnome/interface/icon_theme = 
b'gnome\n'/desktop/gnome/interface/gtk_theme = b'Clearlooks\n'
modified.conffile..etc.default.chromium.browser: [deleted]
mtime.conffile..etc.chromium.browser.default: 2014-04-20T23:53:45.488048

** Affects: chromium-browser (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1338304

Title:
  Chromium Lubuntu 14.04 show block characters for Chinese

Status in “chromium-browser” package in Ubuntu:
  New

Bug description:
  Chinese characters show up as blocks in Chromium (and Chrome) for
  Lubuntu 14.04.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: chromium-browser 34.0.1847.116-0ubuntu2
  ProcVersionSignature: Ubuntu 3.13.0-30.55-generic 3.13.11.2
  Uname: Linux 3.13.0-30-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.2
  Architecture: amd64
  CurrentDesktop: LXDE
  Date: Sun Jul  6 16:49:53 2014
  Desktop-Session:
   DESKTOP_SESSION = Lubuntu
   XDG_CONFIG_DIRS = 
/etc/xdg/lubuntu:/etc/xdg/xdg-Lubuntu:/usr/share/upstart/xdg:/etc/xdg
   XDG_DATA_DIRS = 
/etc/xdg/lubuntu:/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/share/Lubuntu:/usr/local/share/:/usr/share/
  DetectedPlugins:
   
  Env:
   MOZ_PLUGIN_PATH = None
   LD_LIBRARY_PATH = None
  ExecutablePath: /usr/lib/chromium-browser/chromium-browser
  InstallationDate: Installed on 2014-04-21 (76 days ago)
  InstallationMedia: Lubuntu 14.04 LTS "Trusty Tahr" - Release amd64 
(20140416.2)
  SourcePackage: chromium-browser
  UpgradeStatus: No upgrade log present (probably fresh install)
  gconf-keys: /desktop/gnome/applications/browser/exec = 
b'firefox\n'/desktop/gnome/url-handlers/https/command = b'sensible-browser 
%s\n'/desktop/gnome/url-handlers/https/enabled = 
b'true\n'/desktop/gnome/url-handlers/http/command = b'sensible-browser 
%s\n'/desktop/gnome/url-handlers/http/enabled = 
b'true\n'/desktop/gnome/session/required_components/windowmanager = 
b''/apps/metacity/general/compositing_manager = 
b''/desktop/gnome/interface/icon_theme = 
b'gnome\n'/desktop/gnome/interface/gtk_theme = b'Clearlooks\n'
  modified.conffile..etc.default.chromium.browser: [deleted]
  mtime.conffile..etc.chromium.browser.default: 2014-04-20T23:53:45.488048

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1338304/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1338304] Re: Chromium Lubuntu 14.04 show block characters for Chinese

2014-07-06 Thread voidvector 
** Attachment added: "Screenshot from 2014-07-06 16:56:24.png"
   
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1338304/+attachment/4146785/+files/Screenshot%20from%202014-07-06%2016%3A56%3A24.png

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/1338304

Title:
  Chromium Lubuntu 14.04 show block characters for Chinese

Status in “chromium-browser” package in Ubuntu:
  New

Bug description:
  Chinese characters show up as blocks in Chromium (and Chrome) for
  Lubuntu 14.04.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: chromium-browser 34.0.1847.116-0ubuntu2
  ProcVersionSignature: Ubuntu 3.13.0-30.55-generic 3.13.11.2
  Uname: Linux 3.13.0-30-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.2
  Architecture: amd64
  CurrentDesktop: LXDE
  Date: Sun Jul  6 16:49:53 2014
  Desktop-Session:
   DESKTOP_SESSION = Lubuntu
   XDG_CONFIG_DIRS = 
/etc/xdg/lubuntu:/etc/xdg/xdg-Lubuntu:/usr/share/upstart/xdg:/etc/xdg
   XDG_DATA_DIRS = 
/etc/xdg/lubuntu:/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/share/Lubuntu:/usr/local/share/:/usr/share/
  DetectedPlugins:
   
  Env:
   MOZ_PLUGIN_PATH = None
   LD_LIBRARY_PATH = None
  ExecutablePath: /usr/lib/chromium-browser/chromium-browser
  InstallationDate: Installed on 2014-04-21 (76 days ago)
  InstallationMedia: Lubuntu 14.04 LTS "Trusty Tahr" - Release amd64 
(20140416.2)
  SourcePackage: chromium-browser
  UpgradeStatus: No upgrade log present (probably fresh install)
  gconf-keys: /desktop/gnome/applications/browser/exec = 
b'firefox\n'/desktop/gnome/url-handlers/https/command = b'sensible-browser 
%s\n'/desktop/gnome/url-handlers/https/enabled = 
b'true\n'/desktop/gnome/url-handlers/http/command = b'sensible-browser 
%s\n'/desktop/gnome/url-handlers/http/enabled = 
b'true\n'/desktop/gnome/session/required_components/windowmanager = 
b''/apps/metacity/general/compositing_manager = 
b''/desktop/gnome/interface/icon_theme = 
b'gnome\n'/desktop/gnome/interface/gtk_theme = b'Clearlooks\n'
  modified.conffile..etc.default.chromium.browser: [deleted]
  mtime.conffile..etc.chromium.browser.default: 2014-04-20T23:53:45.488048

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1338304/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1575555] Re: Chrome/Chromium use "Thin" as default font weight

2016-05-13 Thread voidvector 
GH, thank you for putting this in.

At standard body text font size, around 14px for websites, thin width is
a lot less scan-able. You have to make an effort to read it. The feeling
is similar to reading "Courier New" body text. You can read it if you
make an effort, and you can get accustomed to it, however, it reduces UX
by a lot.

The "门" problem exists without the proposed font package installed.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to fonts-noto-cjk in Ubuntu.
https://bugs.launchpad.net/bugs/157

Title:
  Chrome/Chromium use "Thin" as default font weight

Status in fonts-noto-cjk package in Ubuntu:
  Fix Released
Status in fonts-noto-cjk source package in Xenial:
  Fix Committed
Status in fonts-noto-cjk package in Debian:
  Fix Released

Bug description:
  [Impact]

  Chromium and Google Chrome use "Thin" as the default Noto Sans CJK
  font weight, which makes some Chinese and Japanese web pages difficult
  to read, and thus gives a bad user experience.

  The fonts-noto-cjk version in the PPA

  https://launchpad.net/~gunnarhj/+archive/ubuntu/fonts-noto-cjk

  installs 7 weight specific font files instead of a single "super"
  file. This works around the Chromium/Chrome issue.

  Note: It has been fixed in yakkety via autosync, so "backporting"
  yakkety (as an SRU) instead of uploading from the PPA is an option.

  [Test Case]

  To reproduce the bug:

  * Install Chromium or Google Chrome.
  * Go to  and notice the very thin characters.
  * Install fonts-noto-cjk from the PPA and notice the difference.

  [Regression Potential]

  This is about another font packaging form, without any change in glyph
  coverage, so the the regression risk should be low.

  [Original description]

  The package seems to only "thin" variant of the font, which makes it
  very unreadable in applications such as Chrome (when it has to fall
  back on Chinese fonts on a mostly-English page). I had to remove the
  package and then manually download the font from Google website and
  install it to make the regular weight available

  Release: 16.04 LTS
  Package Version: 1.004+repack1-1
  Expected: All weights of the noto cjk font to be installed
  Happened: Only the "thin" weight of the font seems to be installed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/fonts-noto-cjk/+bug/157/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1818396] [NEW] libgdiplus.pc does not contain correct linking flag

2019-03-03 Thread voidvector 
Public bug reported:

Current `libgdiplus.pc` is near empty. This is a file used in pkg-config
setups for generating compilation flags of downstream projects.

This cause compilation failure for setups with pkg-config. At minimum,
the .pc file should produce `-lgdiplus`, however it doesn't.

Original source:

https://github.com/mono/libgdiplus/blob/master/libgdiplus.pc.in

** Affects: libgdiplus (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libgdiplus in Ubuntu.
https://bugs.launchpad.net/bugs/1818396

Title:
  libgdiplus.pc does not contain correct linking flag

Status in libgdiplus package in Ubuntu:
  New

Bug description:
  Current `libgdiplus.pc` is near empty. This is a file used in pkg-
  config setups for generating compilation flags of downstream projects.

  This cause compilation failure for setups with pkg-config. At minimum,
  the .pc file should produce `-lgdiplus`, however it doesn't.

  Original source:

  https://github.com/mono/libgdiplus/blob/master/libgdiplus.pc.in

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libgdiplus/+bug/1818396/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1634369] [NEW] no longer able to resolve .local names in Yakkety

2016-10-18 Thread voidvector 
Public bug reported:

This maybe a configuration mismatch between gvfs and dnsmasq.

I am running Xubuntu on Yakkety
I have a Synology DiskStation (a NAS), which provides a Samba share. I have a 
DD-WRT router (has dnsmasq be default). Both are on near default setting.

In Xenial, I was able to navigate to the DiskStation via Thunar ->
Browse Network -> DiskStation. In Yakkety, I am able to see the
DiskStation, however I got the following error when trying to access it:

Failed to open "DISKSTATION"
Failed to retrieve share list from server: Connection Refused.

After some digging, I found that `gvfs-tree network:///` showed the
following

```
network:///
|-- dnssd-domain-DISKSTATION._smb._tcp -> smb://DiskStation.local:445/
`-- smb-root -> smb:///
```

In Xenial, I am able to ping DiskStation.local, but in Yakkety, it does
not resolve to anything.

There is no problem with `gvfs-mount smb://DiskStation/` or typing
`smb://DiskStation/` into Thunar's address bar.

>From what I gathered Yakkety desktop comes with dnsmasq installed. This
may be a bug with dnsmasq configuration, or gvfs's interaction with it.

** Affects: gvfs (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1634369

Title:
  no longer able to resolve .local names in Yakkety

Status in gvfs package in Ubuntu:
  New

Bug description:
  This maybe a configuration mismatch between gvfs and dnsmasq.

  I am running Xubuntu on Yakkety
  I have a Synology DiskStation (a NAS), which provides a Samba share. I have a 
DD-WRT router (has dnsmasq be default). Both are on near default setting.

  In Xenial, I was able to navigate to the DiskStation via Thunar ->
  Browse Network -> DiskStation. In Yakkety, I am able to see the
  DiskStation, however I got the following error when trying to access
  it:

  Failed to open "DISKSTATION"
  Failed to retrieve share list from server: Connection Refused.

  After some digging, I found that `gvfs-tree network:///` showed the
  following

  ```
  network:///
  |-- dnssd-domain-DISKSTATION._smb._tcp -> smb://DiskStation.local:445/
  `-- smb-root -> smb:///
  ```

  In Xenial, I am able to ping DiskStation.local, but in Yakkety, it
  does not resolve to anything.

  There is no problem with `gvfs-mount smb://DiskStation/` or typing
  `smb://DiskStation/` into Thunar's address bar.

  From what I gathered Yakkety desktop comes with dnsmasq installed.
  This may be a bug with dnsmasq configuration, or gvfs's interaction
  with it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1634369/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1634369] Re: no longer able to resolve .local names in Yakkety

2016-10-18 Thread voidvector 
** Description changed:

- I am running Xubuntu on Yakkety 
- I have a Synology DiskStation (a NAS), which provides a Samba share. I have a 
DD-WRT router. Both are on near default setting. 
+ I am running Xubuntu on Yakkety
+ I have a Synology DiskStation (a NAS), which provides a Samba share. I have a 
DD-WRT router. Both are on near default setting.
  
  In Xenial, I was able to navigate to the DiskStation via Thunar ->
  Browse Network -> DiskStation. In Yakkety, I am able to see the
  DiskStation, however I got the following error when trying to access it:
  
  Failed to open "DISKSTATION"
  Failed to retrieve share list from server: Connection Refused.
  
  After some digging, I found that `gvfs-tree network:///` showed the
  following
  
  ```
  network:///
  |-- dnssd-domain-DISKSTATION._smb._tcp -> smb://DiskStation.local:445/
  `-- smb-root -> smb:///
  ```
  
  In Xenial, I am able to ping DiskStation.local, but in Yakkety, it does
  not resolve to anything.
+ 
+ There is no problem with `gvfs-mount smb://DiskStation/` or typing
+ `smb://DiskStation/` into Thunar's address bar.
+ 
+ 
+ From what I gathered Yakkety desktop comes with dnsmasq installed. This may 
be a bug with dnsmasq configuration, or gvfs's interaction with it.

** Description changed:

+ This maybe a configuration mismatch between gvfs and dnsmasq.
+ 
  I am running Xubuntu on Yakkety
- I have a Synology DiskStation (a NAS), which provides a Samba share. I have a 
DD-WRT router. Both are on near default setting.
+ I have a Synology DiskStation (a NAS), which provides a Samba share. I have a 
DD-WRT router (has dnsmasq be default). Both are on near default setting.
  
  In Xenial, I was able to navigate to the DiskStation via Thunar ->
  Browse Network -> DiskStation. In Yakkety, I am able to see the
  DiskStation, however I got the following error when trying to access it:
  
  Failed to open "DISKSTATION"
  Failed to retrieve share list from server: Connection Refused.
  
  After some digging, I found that `gvfs-tree network:///` showed the
  following
  
  ```
  network:///
  |-- dnssd-domain-DISKSTATION._smb._tcp -> smb://DiskStation.local:445/
  `-- smb-root -> smb:///
  ```
  
  In Xenial, I am able to ping DiskStation.local, but in Yakkety, it does
  not resolve to anything.
  
  There is no problem with `gvfs-mount smb://DiskStation/` or typing
  `smb://DiskStation/` into Thunar's address bar.
  
- 
- From what I gathered Yakkety desktop comes with dnsmasq installed. This may 
be a bug with dnsmasq configuration, or gvfs's interaction with it.
+ From what I gathered Yakkety desktop comes with dnsmasq installed. This
+ may be a bug with dnsmasq configuration, or gvfs's interaction with it.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1634369

Title:
  no longer able to resolve .local names in Yakkety

Status in gvfs package in Ubuntu:
  New

Bug description:
  This maybe a configuration mismatch between gvfs and dnsmasq.

  I am running Xubuntu on Yakkety
  I have a Synology DiskStation (a NAS), which provides a Samba share. I have a 
DD-WRT router (has dnsmasq be default). Both are on near default setting.

  In Xenial, I was able to navigate to the DiskStation via Thunar ->
  Browse Network -> DiskStation. In Yakkety, I am able to see the
  DiskStation, however I got the following error when trying to access
  it:

  Failed to open "DISKSTATION"
  Failed to retrieve share list from server: Connection Refused.

  After some digging, I found that `gvfs-tree network:///` showed the
  following

  ```
  network:///
  |-- dnssd-domain-DISKSTATION._smb._tcp -> smb://DiskStation.local:445/
  `-- smb-root -> smb:///
  ```

  In Xenial, I am able to ping DiskStation.local, but in Yakkety, it
  does not resolve to anything.

  There is no problem with `gvfs-mount smb://DiskStation/` or typing
  `smb://DiskStation/` into Thunar's address bar.

  From what I gathered Yakkety desktop comes with dnsmasq installed.
  This may be a bug with dnsmasq configuration, or gvfs's interaction
  with it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1634369/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1634369] Re: no longer able to resolve .local names in Yakkety

2016-10-23 Thread voidvector 
I have since resolved this by setting up LAN domain via router's
Dnsmasq.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/1634369

Title:
  no longer able to resolve .local names in Yakkety

Status in gvfs package in Ubuntu:
  New

Bug description:
  This maybe a configuration mismatch between gvfs and dnsmasq.

  I am running Xubuntu on Yakkety
  I have a Synology DiskStation (a NAS), which provides a Samba share. I have a 
DD-WRT router (has dnsmasq be default). Both are on near default setting.

  In Xenial, I was able to navigate to the DiskStation via Thunar ->
  Browse Network -> DiskStation. In Yakkety, I am able to see the
  DiskStation, however I got the following error when trying to access
  it:

  Failed to open "DISKSTATION"
  Failed to retrieve share list from server: Connection Refused.

  After some digging, I found that `gvfs-tree network:///` showed the
  following

  ```
  network:///
  |-- dnssd-domain-DISKSTATION._smb._tcp -> smb://DiskStation.local:445/
  `-- smb-root -> smb:///
  ```

  In Xenial, I am able to ping DiskStation.local, but in Yakkety, it
  does not resolve to anything.

  There is no problem with `gvfs-mount smb://DiskStation/` or typing
  `smb://DiskStation/` into Thunar's address bar.

  From what I gathered Yakkety desktop comes with dnsmasq installed.
  This may be a bug with dnsmasq configuration, or gvfs's interaction
  with it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1634369/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp