Bug#1005640: Packaging effort of python3-unicodedata2

[Yao Wei (魏銘廷)]

Uh,

I just uploaded the same package to NEW queue yesterday

https://salsa.debian.org/fonts-team/python-unicodedata2

I removed the duplicated parts and linked the source files from unicode-data to 
regenerate headers to avoid having another copy of it.

Yao Wei

(This email is sent from a phone; sorry for HTML email if it happens.)

> On Feb 14, 2022, at 13:03, Boyuan Yang  wrote:
> 
> Hi all,
> 
> Please check out current progress on python3 unicode2 module packaging at
> https://salsa.debian.org/python-team/packages/python-unicodedata2 . I have
> pushed it onto NEW queue. Having another copy of unicode-data might not be
> ideal, but let's wait for the response from FTP Masters first.
> 
> Thanks,
> Boyuan Yang

Bug#1003522: fonttools: Please review the (build-)dependencies

[Yao Wei]

Hi,

I applied your patch into packaging repo on salsa.

Since the built binaries are the same I would not like to do another
release right away.  If you think we should have a release in either
experimental or testing, please ping me again.

Thanks a lot!

Best regards,
Yao Wei


signature.asc
Description: PGP signature

Bug#1001717: fcitx5-chewing: Unmatched license for debian/* (GPL-2+ -> LGPL-2.1+)

[Yao Wei (魏銘廷)]

Hi,

I'll do a relicense and attribute you as one of the authors.

Yao Wei

(This email is sent from a phone; sorry for HTML email if it happens.)

> Boyuan Yang  於 2021年12月15日 04:09 寫道：
> 
> Source: fcitx5-chewing
> Version: 5.0.7-1
> Tags: sid bookworm
> Severity: normal
> X-Debbugs-CC: m...@debian.org
> 
> Hi Yao Wei,
> 
> As seen in
> https://salsa.debian.org/input-method-team/fcitx5-chewing/-/commit/a723daa5f225cd5b4574a8a350aa2c34fe674db0
> , the new release of fcitx5-chewing 5.0.8 has switched its license from GPL-2+
> to LGPL-2.1+. However, you documented that files written by you in debian/*
> dir
> https://salsa.debian.org/input-method-team/fcitx5-chewing/-/blob/a723daa5f225cd5b4574a8a350aa2c34fe674db0/debian/copyright#L22
> is released under GPL-2+.
> 
> Could you please re-license you contribution under a LGPL-2.1+ or a more
> permissive license to match this upstream switch?
> 
> Thanks,
> Boyuan Yang

Bug#990316: Add GLFW_IM_MODULE=fcitx on ibus and fcitx5 to enable IME in kitty

[Yao Wei]

Hi,

On Fri, Nov 19, 2021 at 03:31:49PM +0900, Osamu Aoki wrote:
> Can you tell us XDG_CURRENT_DESKTOP under sway?

medicalwei@torchic:~$ echo $XDG_SESSION_DESKTOP 
sway

> One thing I feel odd is "GLFW_IM_MODULE=ibus".
> 
> Why not like?
> 
> * GLFW_IM_MODULE=fcitx5
> * GLFW_IM_MODULE=fcitx
> 
> The upstrean web site has confusing comments.
> 
> Does fcitx5 and ibus use compatible API?

fcitx5 implements ibus dbus interface so fcitx5 is compatible with that
setup.

Also, GLFW in kitty only has implementation for ibus dbus interface, so
using values other than ibus does not work.

You can check by the code search:

  https://github.com/kovidgoyal/kitty/search?q=GLFW_IM_MODULE

Best regards,
Yao Wei


signature.asc
Description: PGP signature

Bug#990316: Add GLFW_IM_MODULE=fcitx on ibus and fcitx5 to enable IME in kitty

[Yao Wei]

On Fri, Nov 19, 2021 at 10:50:22AM +0900, Osamu Aoki wrote:
> Hmmm...I see.  This is worrying
> 
> Anyway, situation of enabling IM needs help from someone understanding GLFW 
> related
> backend keyboard input handling.  The successful user seem to use "sway" for 
> Desktop
> management.  Is there any other programs using similar backend.
> 
> If problem is happening with backend using xim, that is likely the situation 
> just
> like GTK.  But this seems to indicate otherwise.
> 
> Anyway, those who seems having trouble setting up ibus or fcitx5 didn't set up
> environment variable properly.  There are too much noise.  So we need 
> feedback from
> good tester reporting situation with versions involved (ibus, fcitx5, ...)
> 
> Current in testing are:
> 
> kitty   0.19.3-1
> ibus1.5.25-3
> fcitx5  5.0.9-2
> sway1.5.1-2
> 
> 
> (fcitx   1:4.2.9.8-3)
> 
> > > I am not sure what is "the other way around"?
> > 
> > The purpose of im-config is to make sure that an IM framework — if 
> > present — is launched and configured by default.
> > 
> > > So for wayland ready IM (ibus and fcitx5?) it may be right to set
> > > such setting.
> > 
> > Please remember that im-config doesn't do anything in case of IBus on a 
> > GNOME desktop, but we defer to GNOME's mechanisms for launching and 
> > configuring IBus.
> 
> Yes.  I plan to keep it this way for GNOME.
> 
> Wei, Please let us know XDG_CURRENT_DESKTOP on the system you tested.  What 
> do you
> get on sway system who try to use kitty?

Hi,

I am currently using sway without desktop manager. I am able to use
fcitx5 on kitty in sway after setting GLFW_IM_MODULE=ibus, and if that
variable is unset the IM is not operable in kitty.

Regarding to the concern of the upstream developr, I don't observe
performance hit after setting the variable. The only question I am having
is that whether we should set that variable in im-config because that
seems to be only used in kitty and nowhere else.

The followings are the package versions I was testing with:

  fcitx5  5.0.9-2
  kitty   0.19.3-1
  sway1.5.1-2

Best regards,
Yao Wei


signature.asc
Description: PGP signature

Bug#997489: fonttools: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.9 returned exit code 13

[Yao Wei (魏銘廷)]

It is caused by unicode-data updated to 14.0. The doctest is to get all 
attributes of an Arabic symbol, but in 14.0 "Nkoo" attribute is added to the 
list, causing the test to fail. 

Yao Wei

(This email is sent from a phone; sorry for HTML email if it happens.)

>> === FAILURES 
>> ===
>> ___ [doctest] fontTools.unicodedata.script_extension 
>> ___
>> 071  Return the script extension property assigned to the Unicode character
>> 072 'char' as a set of string.
>> 073 
>> 074 >>> script_extension("a") == {'Latn'}
>> 075 True
>> 076 >>> script_extension(chr(0x060C)) == {'Rohg', 'Syrc', 'Yezi', 
>> 'Arab', 'Thaa'}
>> Expected:
>>True
>> Got:
>>False
>> 
>> /<>/.pybuild/cpython3_3.9/build/fontTools/unicodedata/__init__.py:76:
>>  DocTestFailure

Bug#995214: Wide apostrophe ending up on single width pages

[Yao Wei (魏銘廷)]

Hi,

> On Sep 28, 2021, at 13:54, 積丹尼 Dan Jacobson  wrote:
> 
> Why is this happening in Firefox and Chrome?
> $ LC_CTYPE=zh_TW.UTF-8 $BROWSER http://ud.taichung.gov.tw/

See

https://github.com/adobe-fonts/source-han-sans/issues/28

On the font perspective the same codepoints for curly apostrophes and quotation 
marks are used for Japanese and Korean and they are full-width.

You can try preferring Latin fonts to CJK fonts.

Yao Wei

(This email is sent from a phone; sorry for HTML email if it happens.)

Bug#995214: Wide apostrophe ending up on single width pages

[Yao Wei (魏銘廷)]

> On Sep 29, 2021, at 08:58, Yao Wei (魏銘廷)  wrote:
> 
> On the font perspective the same codepoints for curly apostrophes and 
> quotation marks are used for Japanese and Korean and they are full-width.

My mistake. It's Traditional and Simplified Chinese that's full-width by 
default.

Bug#986803: CVE-2021-28875 CVE-2021-28876 CVE-2021-28877 CVE-2021-28878 CVE-2021-28879 CVE-2020-36317 CVE-2020-36318

[Yao Wei (魏銘廷)]

I made a mistake on CVE-2020-36317 and CVE-2020-36318 patches. The names of the 
patches are incorrect (I put 2021 instead of 2020)

Yao Wei

(This email is sent from a phone; sorry for HTML email if it happens.)

> On Apr 25, 2021, at 08:57, Yao Wei  wrote:
> 
> tag -1 patch
> thanks
> 
> Attached is the proposed patch onto debian repo for this bug.  Note
> that because the patch order is important (one patch depends on another).
> 
> Some tests on the original PRs did not apply because there were no such
> files in 1.48
> 
> Please review before apply since I don't know whether any of these CVEs
> are introduced by changes not in 1.48.
> 
> Thanks,
> Yao Wei
> <0001-CVE-fixups-Closes-986803.patch>

Bug#973188: virt-top: diff for NMU version 1.0.9-1.1

[Yao Wei]

Control: tags 973188 + pending

Dear maintainer,

I've prepared an NMU for virt-top (versioned as 1.0.9-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru virt-top-1.0.9/debian/changelog virt-top-1.0.9/debian/changelog
--- virt-top-1.0.9/debian/changelog	2019-08-25 22:27:13.0 +0800
+++ virt-top-1.0.9/debian/changelog	2021-04-24 19:57:06.0 +0800
@@ -1,3 +1,12 @@
+virt-top (1.0.9-1.1) unstable; urgency=medium
+
+  * Non-maintainer Upload
+  * debian/patches/ocamlclibs-no-runtime-variant.patch: Do not supply
+runtime-variant (Closes: #973188)
+  * debian/control: Fix missing dependencies
+
+ -- Yao Wei (魏銘廷)   Sat, 24 Apr 2021 19:57:06 +0800
+
 virt-top (1.0.9-1) unstable; urgency=medium
 
   * Team upload
diff -Nru virt-top-1.0.9/debian/control virt-top-1.0.9/debian/control
--- virt-top-1.0.9/debian/control	2019-08-25 22:27:13.0 +0800
+++ virt-top-1.0.9/debian/control	2021-04-24 19:57:06.0 +0800
@@ -20,7 +20,11 @@
 
 Package: virt-top
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Depends: ocaml-base-nox | ocaml-base | ocaml-nox | ocaml,
+ libcurses-ocaml,
+ libgettext-ocaml,
+ libvirt-ocaml,
+ ${misc:Depends}, ${shlibs:Depends}
 Description: show stats of virtualized domains
  virt-top is a top-like utility for showing stats of virtualized domains. Many
  keys and command line options are the same as for ordinary top.
diff -Nru virt-top-1.0.9/debian/patches/ocamlclibs-no-runtime-variant.patch virt-top-1.0.9/debian/patches/ocamlclibs-no-runtime-variant.patch
--- virt-top-1.0.9/debian/patches/ocamlclibs-no-runtime-variant.patch	1970-01-01 08:00:00.0 +0800
+++ virt-top-1.0.9/debian/patches/ocamlclibs-no-runtime-variant.patch	2021-04-24 19:57:06.0 +0800
@@ -0,0 +1,21 @@
+From: =?utf-8?b?IllhbyBXZWkgKOmtj+mKmOW7tyki?= 
+Date: Sat, 24 Apr 2021 19:23:41 +0800
+Subject: Do not supply runtime-variant (Closes: #973188)
+
+---
+ src/Makefile.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/Makefile.in b/src/Makefile.in
+index a2ac09b..a2a8883 100644
+--- a/src/Makefile.in
 b/src/Makefile.in
+@@ -65,7 +65,7 @@ OBJS		+= main.cmo
+ XOBJS		:= $(OBJS:.cmo=.cmx)
+ 
+ OCAMLCFLAGS	:= -g -warn-error CDEFLMPSUVYZX-3 -ccopt '@CFLAGS@'
+-OCAMLCLIBS	:= -linkpkg -runtime-variant _pic -cclib '@LDFLAGS@'
++OCAMLCLIBS	:= -linkpkg -cclib '@LDFLAGS@'
+ 
+ OCAMLOPTPACKAGES := $(OCAMLCPACKAGES)
+ OCAMLOPTFLAGS	:= $(OCAMLCFLAGS)
diff -Nru virt-top-1.0.9/debian/patches/series virt-top-1.0.9/debian/patches/series
--- virt-top-1.0.9/debian/patches/series	2019-08-25 22:27:13.0 +0800
+++ virt-top-1.0.9/debian/patches/series	2021-04-24 19:57:06.0 +0800
@@ -1,2 +1,3 @@
 10_add-opt-and-byte-compile-targets.patch
 libvirt-Handle-VIR_DOMAIN_PMSUSPENDED-state.patch
+ocamlclibs-no-runtime-variant.patch


signature.asc
Description: PGP signature

Bug#981426: RM: cu2qu -- ROM; merged to fonttools

[Yao Wei]

Hi,

Sorry that I didn't check the rdeps of cu2qu but only build-rdeps of it.

On Fri, Feb 12, 2021 at 08:14:39AM +0900, Hideki Yamane wrote:
> Hi Paul,
> 
> On Thu, 11 Feb 2021 21:32:54 +0100
> Paul Gevers  wrote:
> > So, Yao, what's the way forward for python3-fontmake and python3-ufo2ft?
> > Will fonttools provide python3-cu2qu?

fonttools will provide same functionality of cu2qu but it will be under
fonttools package.

>  And Yao, please push your changes for ufo2ft to salsa repo.

Done!  I forgot to push branch again :/

Thank,
Yao Wei


signature.asc
Description: PGP signature

Bug#976126: /usr/share/calendar/calendar.debian: update Debian-related events

[Yao Wei (魏銘廷)]

Package: calendar
Version: 12.1.7
Severity: wishlist
File: /usr/share/calendar/calendar.debian
Tags: newcomer
X-Debbugs-Cc: in-memoriam-...@debian.org, debian-de...@debian.org

I mistyped cal with calendar and found such interesting program.

I think it is good to update some important Debian events into this file,
including inaugurate days of DPLs. (neilm, maddog, lamby, hartmans, and
highvoltage), and the day we missed Ian Murdock and several others.

I would consider this issue to be newcomer-friendly since this is
the only file needed to change for the fix (except changelog):

  
https://salsa.debian.org/meskes/bsdmainutils/-/commits/master/debian/calendars/calendar.debian

I personally would like to add DebConf dates as well, and if there's
any other important dates we need to remember, please also reply to the
issue.

Thanks,
Yao Wei


signature.asc
Description: PGP signature

Bug#974141: ITP: fcitx5-chewing -- Chewing support for fcitx5

[Yao Wei]

Package: wnpp
Severity: wishlist
Owner: Yao Wei (魏銘廷) 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: fcitx5-chewing
  Version : 5.0.1
  Upstream Author : Weng Xuetian 
* URL : https://github.com/fcitx/fcitx5-chewing
* License : GPL-2+
  Programming Lang: C
  Description : Chewing support for fcitx5

This package is the support library for fcitx5 to use Chewing input
method, which is one of the popular Zhuyin input method for traditional
Chinese.

This package should be maintained by Debian Input Method Team.

Bug#965151: /usr/bin/tx: transifex-client and afdko shipping binaries under the same name

[Yao Wei]

(CC to @paravoid as original reporter of the same issue)

On Sun, Jul 26, 2020 at 05:04:42AM +, Paul Wise wrote:
> This sort of thing needs to happen upstream first.

I reported it, without noticing that they had the same report third
time, and it was not a charm, still marked as wontfix for compatibility
of existing scripts.

https://github.com/adobe-type-tools/afdko/issues/1196

https://github.com/adobe-type-tools/afdko/issues/1162

https://github.com/adobe-type-tools/afdko/issues/672


signature.asc
Description: PGP signature

Bug#965151: /usr/bin/tx: transifex-client and afdko shipping binaries under the same name

[Yao Wei]

Hi,

On Mon, Jul 20, 2020 at 03:05:26AM +, Paul Wise wrote:
> Probably making all the commands in the afdko package subcommands of a
> new afdko command would be the way to go (similar to how git uses
> subcommands).

Worked this around in 3.5.0+dfsg1-1 upload, by supplying a wrapper
script `afdko`, and moving all the binaries into /usr/libexec/afdko/ .

If a font needs afdko to build one need to put /usr/libexec/afdko/ into
their PATH.

Yao Wei


signature.asc
Description: PGP signature

Bug#965151: /usr/bin/tx: transifex-client and afdko shipping binaries under the same name

[Yao Wei]

Hi,

There's a serious bug when I am uploading afdko package, that one of the
binaries in this package "tx" has name conflicting with
transifex-client.

  https://bugs.debian.org/965151

I am currently considering doing it by moving all binaries of afdko from
/usr/bin to /usr/bin/afdko, and then creating another package
afdko-legacy, that, similar to node-legacy before node changed the name
to ax25-node, symlinks all binaries from /usr/bin/afdko back to
/usr/bin.  This will decrease the mess of one package having multiple
binaries, and ensure the compatibility of font building scripts that
invokes afdko tx.  Does it require CTTE agreement since afdko-legacy is
also in conflict with tx?

Another python module package that's in my ITP also invokes afdko's tx:

  https://bugs.debian.org/962383

How other packages that depends on nodejs did when its name was nodejs?
And how did they use nodejs on package building and/or run-time?

Ref on nodejs vs node CTTE:

  https://lists.debian.org/debian-devel-announce/2012/07/msg2.html

Thanks,
Yao Wei


signature.asc
Description: PGP signature

Bug#806464: ITP: trufont -- cross-platform ufo3 font editor

[Yao Wei]

On Sun, Jun 07, 2020 at 01:15:00PM +0200, Jonas Smedegaard wrote:
> What is the status of initially packaging trufont?
> 
> Any particular blockers you might need help with?

Hi,

Well, there's no particularly weird blockers on my side, but instead I
saw this project is updated since last Septemper.

I will retry packaging this along with two NEW dependencies
(ufo-extractor: #891390, hsluv: #891391) again.

Thanks for nudging,
Yao Wei


signature.asc
Description: PGP signature

Bug#962383: ITP: cffsubr -- CFF subroutinizer based on AFDKO tx

[Yao Wei]

Package: wnpp
Severity: wishlist
Owner: Yao Wei 

* Package name: cffsubr
  Version : 0.2.6
  Upstream Author : Cosimo Lupo 
* URL : https://github.com/adobe-type-tools/cffsubr
* License : Apache-2.0
  Programming Lang: Python
  Description : CFF subroutinizer based on AFDKO tx

This is CFF subroutinizer Python module, which utilizes Adobe AFDKO
(ITP: #762252) tx binary.

This is a new optional dependency of ufo2ft to subroutinize CFF fonts,
and this package should be maintained under Debian Fonts Task Force.


signature.asc
Description: PGP signature

Bug#959474: Issues with Chinese language (all variants) when building some pages in buster

[Yao Wei]

On Mon, May 04, 2020 at 10:19:02PM -0400, Boyuan Yang wrote:
> Mwei (https://nm.debian.org/person/mwei/) just talked to me saying that it
> could be a bug with isSPACE_L1 macro in perl's pp.c. He will be replying the
> email soon.
> 

Hi,

(I used reportbug to handle reply of this thread, and I missed a lot of
recipients here.  This is a resend of reply in #959474.  Sorry for the
noise.)

After a bit of investigation of Perl source code (5.31.11 downloaded
from upstream) I found the they have weird handling of whitespace when
`feature unicode_strings` turned on.  I am not a perl person and I
haven't executed the source code yet, so my interpretation might be
wrong.

When `unicode_strings` is on, `in_uni_8_bit` should true internally, and
in three places of pp.c:6040, pp.c:6076, pp.c:6114 `isSPACE_L1` is
called to check whether the examining character is a whitespace, by
checking whether the character is 0x85 or 0xA0 (handy.h:1611).  In the
case of the character 包, the last byte of 3-byte UTF-8 code is 0x85,
henceforth the problem.


signature.asc
Description: PGP signature

Bug#959474: Issues with Chinese language (all variants) when building some pages in buster

[Yao Wei (魏銘廷)]

Package: www.debian.org
Followup-For: Bug #959474

Hi,

After a bit of investigation of Perl source code (5.31.11 downloaded
from upstream) I found the they have weird handling of whitespace when
`feature unicode_strings` turned on.  I am not a perl person and I
haven't executed the source code yet, so my interpretation might be
wrong.

When `unicode_strings` is on, `in_uni_8_bit` should true internally, and
in three places of pp.c:6040, pp.c:6076, pp.c:6114 `isSPACE_L1` is
called to check whether the examining character is a whitespace, by
checking whether the character is 0x85 or 0xA0 (handy.h:1611).  In the
case of the character 包, the last byte of 3-byte UTF-8 code is 0x85,
henceforth the problem.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


signature.asc
Description: PGP signature

Bug#953872: ITP: fonts-jf-openhuninn -- Chinese (Taiwan) font based on Kosugi Maru

[Yao Wei]

On Sun, Mar 15, 2020 at 08:27:29AM +0800, Yao Wei wrote:
> On Sat, Mar 14, 2020 at 06:56:49PM +0800, Yao Wei wrote:
> > * License : OFL-1.1, without Reserved Font Names
> 
> The license should come with Reserved Font Names "Varela" and "Varela
> Round" since the latin part of the fonts are replaced with it.

And the author was mistaken that they think they added RFN, but they
didn't use OFL's "With Reserved Font Names" texts in the copyright
claim.

The future version will have RFN on it.


signature.asc
Description: PGP signature

Bug#953872: ITP: fonts-jf-openhuninn -- Chinese (Taiwan) font based on Kosugi Maru

[Yao Wei]

On Sat, Mar 14, 2020 at 06:56:49PM +0800, Yao Wei wrote:
> * License : OFL-1.1, without Reserved Font Names

The license should come with Reserved Font Names "Varela" and "Varela
Round" since the latin part of the fonts are replaced with it.


signature.asc
Description: PGP signature

Bug#950103: fonts-lemonada FTBFS: KeyError: "glyph 'M' already exists"

[Yao Wei (魏銘廷)]

Package: src:fonts-lemonada
Followup-For: Bug #950103

This issue seems to be in Glyphs.app that it creates files with
duplicated layer names, glyphslib follows UFO layers spec that names
must not be duplicated.  This issue was fixed in glyphslib 5.1.1.

See: https://github.com/googlefonts/glyphsLib/issues/566

RFS for glyphslib 5.1.2+ds1-1 was given privately to hosiet and should
show up soon.

Thanks,
Yao Wei


signature.asc
Description: PGP signature

Bug#933609: How hard it is to find the Date of a package

[Yao Wei (魏銘廷)]

A probably known easier way is to see the standardized changelog of the 
package.  There should be a date in each version.

Yao Wei

(This email is sent from a phone; sorry for HTML email if it happens.)

> On Aug 1, 2019, at 09:27, 積丹尼 Dan Jacobson  wrote:
> 
> Package: www.debian.org
> 
> Let's examine how extremely hard it is for a user to squeeze update date
> of a package he is thinking of installing out of the Debian system.
> 
> First of all update dates are not part of any Package* file. So forget
> apt, etc.
> 
> Now we must turn to the web.
> 
> Case in point:
> 
> "Should we install webext-ublock-origin, or get it from the Chrome web
> store. I know, let's see which is newer!" #933608
> 
> https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm
> says says "Updated July 25, 2019"
> 
> That was simple.
> 
> OK, let's turn to Debian.
> 
> https://www.google.com/search?q=webext-ublock-origin leads to
> https://packages.debian.org/sid/web/webext-ublock-origin
> from where we must know to click on "all",
> https://packages.debian.org/sid/all/webext-ublock-origin/download
> 
> There we see
>  More information on webext-ublock-origin_1.19.0+dfsg-2_all.deb:
>  Exact Size1617728 Byte (1.5 MByte)
>  MD5 checksum190c7c66089925f72489624d700c34a0
>  SHA1 checksumNot Available
>  SHA256 checksum
> bf50b4180ba0daddd720b5ce1702a315ed7743cc749ebb3cc131fe60dcc648c9
> 
> but Date is still not included.
> 
> So we must copy a link, and run HEAD on it,
> 
> $ HEAD 
> http://ftp.us.debian.org/debian/pool/main/u/ublock-origin/webext-ublock-origin_1.19.0+dfsg-2_all.deb
> 200 OK
> Connection: close
> Date: Thu, 01 Aug 2019 01:17:03 GMT
> Accept-Ranges: bytes
> ETag: "5d22808b-18af40"
> Server: nginx/1.13.6
> Content-Length: 1617728
> Content-Type: application/octet-stream
> Last-Modified: Sun, 07 Jul 2019 23:30:19 GMT
> 
> 
> Ah, finally!
> 
> But let's say we are not as smart.
> 
> So we must shorten the link:
> 
> http://ftp.us.debian.org/debian/pool/main/u/ublock-origin/
> 
> Then click Last Modified (twice), then look for the file we want...
> 

Bug#932568: ITP: fontbakery -- Font quality checker

[Yao Wei]

Hi,

On Sat, Jul 20, 2019 at 03:13:10PM -0400, Nicholas D Steeves wrote:
> This seems like a really cool plan :-)  Out of curiosity will it also
> detect suboptimal rendering for a font if/when new freetype/fontconfig
> versions make changes to how fonts arerendered?  (P.S. sorry that I
> don't know if these new font types use libfreetype or something else)

It checks some parameters of a font file, like unit size, weight, and
name etc.  It does not check how it is rendered afaik.

However, if such phenomenon can be recognized as a font parameter, it is
possible that we write a test for such check.

Yao Wei


signature.asc
Description: PGP signature

Bug#680668: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)

[Yao Wei (魏銘廷)]

What's the recommended Kai font replacement for Arphic one?

Yao Wei

(This email is sent from a phone; sorry for HTML email if it happens.)

> On Jan 12, 2019, at 17:34, 林博仁  wrote:
> 
> I would like to request dropping the following two fonts:
> 
> * fonts-arphic-ukai
> * fonts-arphic-uming
> 
> IMO there's no one really uses it, with a confusing font family names, 
> unmaintained, and causes glitches in certain cases like the GNU gettext 
> manual 
> <https://www.facebook.com/groups/ubuntu.zh.hant/permalink/2225280084193968/> 
> etc.
> 
> It should be replaced by Noto Serif CJK/Source Han Serif fonts.
> 
> 林博仁(Buo-ren, Lin)
> buo.ren@gmail.com
> 
> 
> "Yao Wei (魏銘廷)"  於 2019年1月12日 週六 下午5:02寫道：
>> Hi,
>> 
>> > On Jan 12, 2019, at 16:35, Holger Wansing  wrote:
>> > 
>> > And for traditional Chinese:
>> > 
>> > Package: task-chinese-t-desktop
>> > Architecture: all
>> > Description: Traditional Chinese desktop
>> > This task localises the desktop in Traditional Chinese.
>> > Depends: ${misc:Depends},
>> > Recommends:
>> >   scim,
>> >   scim-chewing,
>> >   scim-gtk-immodule,
>> >   im-config,
>> >   fonts-arphic-ukai,
>> >   fonts-arphic-uming,
>> > # seems openjdk needs this to display Chinese.
>> >   fonts-noto,
>> >   fonts-noto-cjk,
>> >   libreoffice-l10n-zh-tw,
>> >   libreoffice-help-zh-tw,
>> >   firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw,
>> > # poppler-data is needed to display
>> > # Chinese on poppler applications.
>> >   poppler-data
>> > 
>> > Is this working so far, or should things be improved, to close this bug?
>> 
>> Currently, the following set is recommended (for GNOME3 desktop) instead
>> of the ones above, because current GNOME3 has native support on ibus
>> (and probably fcitx):
>> 
>> ibus,
>> ibus-chewing,
>> ibus-table,
>> im-config,
>> fonts-arphic-ukai,
>> fonts-arphic-uming,
>> fonts-noto, # this seems to be unnecessary, but not really sure.
>> fonts-noto-cjk,
>> libreoffice-l10n-zh-tw,
>> libreoffice-help-zh-tw,
>> firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw,
>> poppler-data
>> 
>> or we can follow task-chinese-s-desktop and use fcitx instead of ibus in
>> task-chinese-t-desktop:
>> 
>> fcitx,
>> fcitx-chewing,
>> fcitx-table,
>> im-config,
>> fonts-arphic-ukai,
>> fonts-arphic-uming,
>> fonts-noto, # this seems to be unnecessary, but not really sure.
>> fonts-noto-cjk,
>> libreoffice-l10n-zh-tw,
>> libreoffice-help-zh-tw,
>> firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw,
>> poppler-data
>> 
>> Other input methods like gcin and hime are also available, but I seldom
>> see people using SCIM.
>> 
>> Just 2 cents,
>> Yao Wei

Bug#680668: tasksel: Input methods for chinese - (Was: Updating chinese-t-desktop in tasksel for Wheezy.)

[Yao Wei (魏銘廷)]

Hi,

> On Jan 12, 2019, at 16:35, Holger Wansing  wrote:
> 
> And for traditional Chinese:
> 
> Package: task-chinese-t-desktop
> Architecture: all
> Description: Traditional Chinese desktop
> This task localises the desktop in Traditional Chinese.
> Depends: ${misc:Depends},
> Recommends:
>   scim,
>   scim-chewing,
>   scim-gtk-immodule,
>   im-config,
>   fonts-arphic-ukai,
>   fonts-arphic-uming,
> # seems openjdk needs this to display Chinese.
>   fonts-noto,
>   fonts-noto-cjk,
>   libreoffice-l10n-zh-tw,
>   libreoffice-help-zh-tw,
>   firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw,
> # poppler-data is needed to display
> # Chinese on poppler applications.
>   poppler-data
> 
> Is this working so far, or should things be improved, to close this bug?

Currently, the following set is recommended (for GNOME3 desktop) instead
of the ones above, because current GNOME3 has native support on ibus
(and probably fcitx):

ibus,
ibus-chewing,
ibus-table,
im-config,
fonts-arphic-ukai,
fonts-arphic-uming,
fonts-noto, # this seems to be unnecessary, but not really sure.
fonts-noto-cjk,
libreoffice-l10n-zh-tw,
libreoffice-help-zh-tw,
firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw,
poppler-data

or we can follow task-chinese-s-desktop and use fcitx instead of ibus in
task-chinese-t-desktop:

fcitx,
fcitx-chewing,
fcitx-table,
im-config,
fonts-arphic-ukai,
fonts-arphic-uming,
fonts-noto, # this seems to be unnecessary, but not really sure.
fonts-noto-cjk,
libreoffice-l10n-zh-tw,
libreoffice-help-zh-tw,
firefox-esr-l10n-zh-tw | firefox-l10n-zh-tw,
poppler-data

Other input methods like gcin and hime are also available, but I seldom
see people using SCIM.

Just 2 cents,
Yao Wei


signature.asc
Description: Message signed with OpenPGP

Bug#900777: fontmake: fails to rebuild fonts-firacode from its glyphs source

[Yao Wei]

Hi,

fontmake and the dependencies has been updated:

  * fontmake 1.8.0: https://salsa.debian.org/fonts-team/fontmake
  * glyphslib 3.1.4: https://salsa.debian.org/fonts-team/glyphslib
  * mutatormath 2.1.2: https://salsa.debian.org/fonts-team/mutatormath
  * fontmath 0.4.9: https://salsa.debian.org/fonts-team/fontmath

On Fri, Dec 14, 2018 at 10:23:10AM +0800, Yao Wei wrote:
> > fontmake 1.6.1 has been in Debian since September. Maybe you're
> > thinking of fontmake 1.8 which isn't in Salsa yet.
> 
> Ouch.  I will update this soon.

Yao Wei


signature.asc
Description: PGP signature

Bug#900777: fontmake: fails to rebuild fonts-firacode from its glyphs source

[Yao Wei]

Hi,

Replying inline:

On Thu, Dec 13, 2018 at 10:00:46AM -0500, Jeremy Bicha wrote:
> I think I've done all of these today (or earlier) except for:
> 
> ufo2ft 2.5: the build requires skia-pathops. Did you want to work on
> packaging that too?

This is not an requirement as far as the source code suggests.  It seems
skia-pathops is optional, where booleanoperations is used by default for
path operations.

Also, skia has been in RFP for a while (#818180).  I think we can
package this but it is not a blocking issue for this package.

> fontmake 1.6.1 has been in Debian since September. Maybe you're
> thinking of fontmake 1.8 which isn't in Salsa yet.

Ouch.  I will update this soon.

Yao Wei


signature.asc
Description: PGP signature

Bug#900777: fontmake: fails to rebuild fonts-firacode from its glyphs source

[Yao Wei]

On Fri, Nov 30, 2018 at 07:04:53AM -0500, Jeremy Bicha wrote:
> Please check that you have git pushed the upstream and pristine-tar
> branches for that list.

Ouch.

Uploaded, Please check.

Yao Wei


signature.asc
Description: PGP signature

Bug#900777: fontmake: fails to rebuild fonts-firacode from its glyphs source

[Yao Wei]

Hi,

I would like to RFS the following packages to close this bug, as I am
non-uploading DD:

  * fontmake 1.6.1: https://salsa.debian.org/fonts-team/fontmake
  * ufo2ft 2.5.0: https://salsa.debian.org/fonts-team/ufo2ft
  * fonttools 3.32.0: https://salsa.debian.org/fonts-team/fonttools
  * defcon 0.6.0: https://salsa.debian.org/fonts-team/defcon
  * cu2qu 1.6.5: https://salsa.debian.org/fonts-team/cu2qu
  * booleanoperations 0.8.1: 
https://salsa.debian.org/fonts-team/booleanoperations
  * ufolib2 (NEW) 0.2.1: https://salsa.debian.org/fonts-team/ufolib2

As well as following python module dependencies:
  * python-fs (NEW for python3) 2.1.1: 
https://salsa.debian.org/python-team/modules/python-fs
  * python-backports.os (NEW) 0.1.1: 
https://salsa.debian.org/python-team/modules/python-backports.os

On Tue, Nov 27, 2018 at 12:37:45PM +0100, Fabian Greffrath wrote:
> James Godfrey-Kittle wrote:
> > Your error is the same as in the original email. The error "Glyph
> > psili cannot be in both @MC_top and @MC_topleft" I believe was fixed
> > by https://github.com/googlei18n/ufo2ft/pull/276, and should not occur
> > with ufo2ft >= 2.3.0.
> 
> Great, thank you! So, we have a chance to build this font from sources
> once an updated ufo2ft package (and probably glyphslib) enters Debian.


signature.asc
Description: PGP signature

Bug#900777: fontmake: fails to rebuild fonts-firacode from its glyphs source

[Yao Wei]

Hi,

Sorry for the late reply, here was me testing to build Fira Code after
bumping fontmake:

INFO:fontmake.font_project:Building master UFOs and designspace from Glyphs
source
INFO:glyphsLib.classes:Parsing "FiraCode.glyphs" file into 
INFO:fontmake.font_project:Building OTF for FiraCode-Regular
INFO:ufo2ft:Pre-processing glyphs
INFO:ufo2ft.filters:Running DecomposeComponentsFilter on FiraCode-Regular
INFO:ufo2ft.filters:Running RemoveOverlapsFilter on FiraCode-Regular
INFO:ufo2ft:Building OpenType tables
INFO:ufo2ft.outlineCompiler:The copyright was normalized for storage in the
CFF table and consequently some characters were dropped: 'Copyright
Copyright 2015 by Nikita Prokopov'
ERROR:ufo2ft.featureCompiler:Compilation failed! Inspect temporary file:
'/tmp/tmpyyyj2ern'
Traceback (most recent call last):
  File "/usr/bin/fontmake", line 11, in 
load_entry_point('fontmake==1.6.1', 'console_scripts', 'fontmake')()
  File "/usr/lib/python3/dist-packages/fontmake/__main__.py", line 248, in
main
project.run_from_glyphs(glyphs_path, **args)
  File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line 548,
in run_from_glyphs
self.run_from_designspace(designspace_path, **kwargs)
  File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line 623,
in run_from_designspace
**kwargs)
  File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line 654,
in run_from_ufos
self.build_otfs(ufos, **kwargs)
  File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line 232,
in build_otfs
self.save_otfs(ufos, **kwargs)
  File "/usr/lib/python3/dist-packages/fontTools/misc/loggingTools.py",
line 372, in wrapper
return func(*args, **kwds)
  File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line 395,
in save_otfs
for font, ufo in zip(fonts, ufos):
  File "/usr/lib/python3/dist-packages/fontmake/font_project.py", line 280,
in _iter_compile
yield compile_func(ufo, **options)
  File "/usr/lib/python3/dist-packages/ufo2ft/__init__.py", line 89, in
compileOTF
featureCompilerClass=featureCompilerClass,
  File "/usr/lib/python3/dist-packages/ufo2ft/__init__.py", line 230, in
compileFeatures
return featureCompiler.compile()
  File "/usr/lib/python3/dist-packages/ufo2ft/featureCompiler.py", line
131, in compile
self.buildTables()
  File "/usr/lib/python3/dist-packages/ufo2ft/featureCompiler.py", line
252, in buildTables
self.ttFont, self.features, filename=path
  File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py", line
31, in addOpenTypeFeaturesFromString
addOpenTypeFeatures(font, featurefile, tables=tables)
  File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py", line
22, in addOpenTypeFeatures
builder.build(tables=tables)
  File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py", line
109, in build
self.parseTree.build(self)
  File "/usr/lib/python3/dist-packages/fontTools/feaLib/ast.py", line 260,
in build
s.build(builder)
  File "/usr/lib/python3/dist-packages/fontTools/feaLib/ast.py", line 289,
in build
Block.build(self, builder)
  File "/usr/lib/python3/dist-packages/fontTools/feaLib/ast.py", line 260,
in build
s.build(builder)
  File "/usr/lib/python3/dist-packages/fontTools/feaLib/ast.py", line 328,
in build
Block.build(self, builder)
  File "/usr/lib/python3/dist-packages/fontTools/feaLib/ast.py", line 260,
in build
s.build(builder)
  File "/usr/lib/python3/dist-packages/fontTools/feaLib/ast.py", line 850,
in build
builder.add_mark_base_pos(self.location, self.base.glyphSet(),
self.marks)
  File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py", line
973, in add_mark_base_pos
self.add_marks_(location, builder, marks)
  File "/usr/lib/python3/dist-packages/fontTools/feaLib/builder.py", line
969, in add_marks_
location)
fontTools.feaLib.error.FeatureLibError: :1578:9: Glyph psili
cannot be in both @MC_top and @MC_topleft


On Fri, Nov 9, 2018 at 6:41 PM Fabian Greffrath  wrote:

> Hi,
>
> Yao Wei wrote:
> > While newer version is ready, I found that building Fira Code needs the
> > dependencies under fontmake to be bumped, hence this bug is kept
> > unresolved.
>
> could you please tell me what exactly needs to be updated in order to
> build fonts-firacode with fontmake?
>
> Thanks!
>
>  - Fabian
>
>
>

Bug#912656: ITS: python-fs

[Yao Wei]

Hi Mattia,

I am currently not the team member of DPMT yet, hence the request.  I am
going to request to join the team right now.

Though I am packaging several Python packages, these are maintained
under Debian Fonts Task Force because those are packages to build fonts.

Thanks,
Yao Wei

On Fri, Nov 02, 2018 at 05:27:09PM +0100, Mattia Rizzolo wrote:
> I'm confused here, this package is already maintained by DPMT, with it
> in Uploaders.  Team members can already freely upload it; sure it is in
> Uploaders only so you'd need to give the maintainer a heads up, but you
> need not block on this, much less go through the ITS process.
> 
> Also, the maintainer janos is already being tracked by the MIA team,
> despite being not exactly responsive there either.
> 
> I recommend you just go ahead and do a team upload, and if you really
> wish so also move around Maintainer/Uploaders (and put yourself in it).


signature.asc
Description: PGP signature

Bug#900777: fontmake: fails to rebuild fonts-firacode from its glyphs source

[Yao Wei]

Hi,

While newer version is ready, I found that building Fira Code needs the
dependencies under fontmake to be bumped, hence this bug is kept unresolved.

Yao Wei

On Tue, Oct 30, 2018 at 17:27 Fabian Greffrath  wrote:

> Hi Jeremy,
>
> Jeremy Bicha wrote:
> > 3.1 is not a trivial update since our glyphdata handling will need to
> > be redone (debian/rules, debian/copyright and we probably need a
> > glyphsinfo update).
>
> I have seen some progress in the salsa GIT repo recently. Is there
> anything still missing to have this package uploaded, anything that I
> could do to help?
>
> Cheers,
>
>  - Fabian
>
>
>

Bug#892883: mirrors: Debian mirror opensource.nchc.org.tw: add as candidate of ftp.tw

[Yao Wei]

I see the reason why your mirror status cannot be read from the status
site.

Could you change the MIRRORNAME in the ftpsync.conf file to "
opensource.nchc.org.tw"? It is now "free.nchc.org.tw", but the mirror
status cannot find the trace file.

It is important for the maintainers to know where your mirror is synced
from.

Yao Wei
On Sat, 24 Mar 2018 at 13:03 Steven Shiau <ste...@nchc.org.tw> wrote:

> Hi,
> Yes, we have updated ftpsync on our mirror server
> (opensource.nchc.org.tw or a.k.a free.nchc.org.tw), and is ready to
> receive push mirror.
> Now I'd like to ask the mirrors team where may we receive the push trigger?
> Thank you very much.
>
> Steven
>
> On 3/24/2018 AM 11:49, Yao Wei wrote:
> > Hi,
> >
> > You should update your ftpsync program first, which is here:
> >
> > http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz
> >
> > Also push mirror for ccTLD mirror seems to be necessary. You can
> > consider setting that up with mirrors.xtom.com.hk
> > <http://mirrors.xtom.com.hk> (this is what ftp.ntou.edu.tw
> > <http://ftp.ntou.edu.tw> do) or ask the mirrors team here for
> > receiving push from upstream.
> >
> > Yao Wei
> > On Sat, 24 Mar 2018 at 09:28 Steven Shiau <ste...@nchc.org.tw
> > <mailto:ste...@nchc.org.tw>> wrote:
> >
> >
> > On 2018年03月14日 11:14, Yao Wei (魏銘廷) wrote:
> > > Package: mirrors
> > > Severity: wishlist
> > > X-Debbugs-CC: debian-mirr...@lists.debian.org
> > <mailto:debian-mirr...@lists.debian.org>, Steven Shiau
> > <ste...@nchc.org.tw <mailto:ste...@nchc.org.tw>>, Ceasar Sun
> > Chen-kai <cea...@nchc.org.tw <mailto:cea...@nchc.org.tw>>, Thomas
> > <tho...@nchc.org.tw <mailto:tho...@nchc.org.tw>>
> > >
> > > Hi,
> > >
> > > As stated in the debian-mirrors mailing list, NCHC wants to list
> > > ftp.tw.debian.org <http://ftp.tw.debian.org> as their primary
> > mirror:
> > >
> > > https://lists.debian.org/debian-mirrors/2018/03/msg0.html
> > >
> > > Also, according to the mirror status webpage:
> > >
> > > https://mirror-master.debian.org/status/mirror-status.html
> > >
> > > NCHC needs to use ftpsync rather than typical rsync to sync the
> > mirror,
> > > because of lacking sitetrace.
> > Thanks. If we follow the doc
> > https://salsa.debian.org/mirror-team/archvsync/, is it a must to
> > receive
> > an update trigger for ftpsync? If so, which upstream do you recommend
> > and where is public key of that upstream?
> > Thank you very much.
> >
> > Steven
> > >
> > > Yao Wei
> >
> > --
> > Steven Shiau 
> > Public Key Server PGP Key ID: 4096R/163E3FB0
> > Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0
> >
>
> --
> Steven Shiau 
> Public Key Server PGP Key ID: 4096R/163E3FB0
> Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0
>
>

Bug#892883: mirrors: Debian mirror opensource.nchc.org.tw: add as candidate of ftp.tw

[Yao Wei]

Hi,

You should update your ftpsync program first, which is here:

http://ftp.debian.org/debian/project/ftpsync/ftpsync-current.tar.gz

Also push mirror for ccTLD mirror seems to be necessary. You can consider
setting that up with mirrors.xtom.com.hk (this is what ftp.ntou.edu.tw do)
or ask the mirrors team here for receiving push from upstream.

Yao Wei
On Sat, 24 Mar 2018 at 09:28 Steven Shiau <ste...@nchc.org.tw> wrote:

>
> On 2018年03月14日 11:14, Yao Wei (魏銘廷) wrote:
> > Package: mirrors
> > Severity: wishlist
> > X-Debbugs-CC: debian-mirr...@lists.debian.org, Steven Shiau <
> ste...@nchc.org.tw>, Ceasar Sun Chen-kai <cea...@nchc.org.tw>, Thomas <
> tho...@nchc.org.tw>
> >
> > Hi,
> >
> > As stated in the debian-mirrors mailing list, NCHC wants to list
> > ftp.tw.debian.org as their primary mirror:
> >
> >   https://lists.debian.org/debian-mirrors/2018/03/msg0.html
> >
> > Also, according to the mirror status webpage:
> >
> >   https://mirror-master.debian.org/status/mirror-status.html
> >
> > NCHC needs to use ftpsync rather than typical rsync to sync the mirror,
> > because of lacking sitetrace.
> Thanks. If we follow the doc
> https://salsa.debian.org/mirror-team/archvsync/, is it a must to receive
> an update trigger for ftpsync? If so, which upstream do you recommend
> and where is public key of that upstream?
> Thank you very much.
>
> Steven
> >
> > Yao Wei
>
> --
> Steven Shiau 
> Public Key Server PGP Key ID: 4096R/163E3FB0
> Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0
>
>

Bug#891391: Fwd: [hsluv/hsluv-python] Question: How did you make transpiled Haxe code to hsluv.py? (#10)

[Yao Wei]

Forwarding from the author's reply on the issue tracker.

-- Forwarded message -
From: Alexei Boronine <notificati...@github.com>
Date: Tue, 20 Mar 2018 at 20:27
Subject: Re: [hsluv/hsluv-python] Question: How did you make transpiled
Haxe code to hsluv.py? (#10)
To: hsluv/hsluv-python <hsluv-pyt...@noreply.github.com>
CC: Yao Wei <medical...@gmail.com>, Author <aut...@noreply.github.com>


I only used dead code removal as an example of how the Haxe-generated code
was cleaned up manually. The clean-up also included variable renaming and
formatting changes. There is no way to automatically generate hsluv-python
code, so you should definitely just use it as-is. I think for the purpose
of the Debian policy, you can consider hsluv.py to be *derived* from
generated code rather than *being* generated code.

It would be great to see hsluv-python packaged for Debian, thank you for
taking the time to do it :)

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/hsluv/hsluv-python/issues/10#issuecomment-374579551>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEi8Qw-ToKck3XwqJ7lEhJVGtPpdmbWks5tgPXEgaJpZM4SxHRT>
.

Bug#891507: [Pkg-gtkpod-devel] Bug#891507: usbmuxd: Plugging device second time does not start usbmuxd

[Yao Wei]

Control: fixed -1 1.1.1~git20180302.b888970-0.1

Hi,

Sorry that I almost forgot your email. It works after upgrading to the
specific version.

Yao Wei
On Sat, 3 Mar 2018 at 05:42 Yves-Alexis Perez <cor...@debian.org> wrote:

> On Mon, 2018-02-26 at 18:44 +0800, Yao Wei wrote:
> > Hi,
> >
> > When I plug my iPhone 6S Plus (05ac:12a8) the first time, it does charge
> > with a charging symbol, but when I remove it and plug it the second
> > time, it does not charge.
> >
> > I tried to restart usbmuxd and it does start to charge, so I am
> > concluding that usbmuxd has been shutdown when the last device is
> > removed, and not bringing back by systemd-udevd.
> >
> > The problem is also discussed in armbian forum:
> >
> https://forum.armbian.com/topic/2072-systemd-udevd-does-not-start-usbmuxd/
>
> Hi,
>
> I've just uploaded usbmuxd 1.1.1~git20180302.b888970-0.1. When it'll be
> available for you, can you give it a test and report back if it fixes the
> issue for you?
>
> It seems to work for me on an iphone SE (05ac:12a8).
>
> Regards,
> --
> Yves-Alexis

Bug#891389: ITP: python3-defconqt -- A set of Qt objects for use in defcon applications

[Yao Wei]

On Sun, Feb 25, 2018 at 12:54:51PM +0800, Yao Wei wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Yao Wei (魏銘廷) <m...@lxde.org>
> Control: block 806464 by -1
> 
> * Package name: python3-defconqt
>   Version : x.y.z
>   Upstream Author : Name <someb...@example.org>
> * URL : http://www.example.org/
> * License : GPL-3 or LGPL-3
>   Programming Lang: Python3
>   Description : A set of Qt objects for use in defcon applications
> 
> This is the dependency used by trufont (#806464)

Sorry, sending things too quick without checking:

* Package name : python3-defconqt
  Version : 0.5.3
  Upstream Author : Adrien Tétar
* URL : https://github.com/trufont/defconQt
* License : GPL-3 or LGPL-3
  Programming Lang: Python3

Description : A set of Qt objects for use in defcon applications




signature.asc
Description: PGP signature

Bug#881124: shadow.ind.ntou.edu.tw: request name change, and add as candidate of ftp.tw

[Yao Wei]

Hi,

Our server had a raid failure.

We are calling data recovery service (because of private data, mirror
unrelated, is in the drive) so it would probably take a month to recover.

Yao Wei
On Sat, 30 Dec 2017 at 00:45 Yao Wei <m...@lxde.org> wrote:

> Hi,
>
> The score on the mirror status page reaches 100 now. Is it good to set it
> up as a primary candidate?
> Yao Wei
>

Bug#886599: RFH: broadcom-sta -- Broadcom STA Wireless driver (non-free)

[Yao Wei]

My current daily device is a BCM4360, so I am probably eligible as a
tester.  Although I don't read driver code...

On Mon, 8 Jan 2018 at 08:51 Eduard Bloch  wrote:

> Package: wnpp
> Severity: normal
>
> I request assistance with maintaining the broadcom-sta package.
>
> I don't have permanent access to related hardware nor do I use similar
> devices regularly, so my detector for all new breakages (mostly
> kernel change related) has been non-functional for months, causing nasty
> delays in support coverage.
>
> Fortunatelly, the package has apparently still lots of active users who
> come along with usable patches (but sometimes also with weird ones,
> therefore having strong C language knowledge and some kernel
> infrastructure knowledge is advisable).
>
> The package description is:
>  Broadcom STA is a binary-only device driver to support the following IEEE
>  802.11a/b/g/n wireless network cards: BCM4311-, BCM4312-, BCM4313-,
>  BCM4321-, BCM4322-, BCM43142-, BCM43224-, BCM43225-, BCM43227-, BCM43228-,
>  BCM4331-, BCM4360-, and BCM4352-based hardware.
>  .
>  This package contains the common files and it should not be installed
> manually
>  (it will be installed automatically as needed).
>
> MfG/best regards,
> Eduard.
>
>

Bug#881124: shadow.ind.ntou.edu.tw: request name change, and add as candidate of ftp.tw

[Yao Wei]

Hi,

The score on the mirror status page reaches 100 now. Is it good to set it
up as a primary candidate?
Yao Wei

Bug#884006: copyright-format: Documenting copyrights not in source package but in binary package

[Yao Wei]

Hi Sean,

Built-Using doesn't contain copyright notice and license info, for example
Expat has the following clause:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

Yao Wei
On Tue, 12 Dec 2017 at 09:47 Sean Whitton <spwhit...@spwhitton.name> wrote:

> Hello Yao,
>
> On Tue, Dec 12 2017, Yao Wei wrote:
>
> > My problem is roughly case 1 (and for me, to solve case 2). However as
> > a requirement of some licenses the file must come with the copyright
> > notice, and I am afraid if generates files which it's source comes
> > from another package cannot comply with such requirements.
>
> Can you explain why the Built-Using: field doesn't satisfy this?  AIUI,
> this case is precisely what the Built-Using: field is for.
>
> (I thought that this wasn't an issue with the Expat license, anyway;
> only the GPL, but I'm not sure)
>
> --
> Sean Whitton
>

Bug#884006: copyright-format: Documenting copyrights not in source package but in binary package

[Yao Wei]

Hi Sean,

My problem is roughly case 1 (and for me, to solve case 2). However as a
requirement of some licenses the file must come with the copyright notice,
and I am afraid if generates files which it's source comes from another
package cannot comply with such requirements.

The generated file inside the upstream package does have a copy of Expat
license and copyright notice in the file, but the generated file doesn't
include them.

It might be only build dependency but not runtime dependency and the
copyright notice should be carried by the binary package.

Yao Wei
On Tue, 12 Dec 2017 at 09:01 Sean Whitton <spwhit...@spwhitton.name> wrote:

> Hello Yao,
>
> On Mon, Dec 11 2017, Yao Wei wrote:
>
> > Files-Binary would be package name and file path to the files which its
> > copyright is not in source package but in binary package.  For example:
> >
> >   Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
> >   Copyright:2038 John Doe
> >   License:  Expat
> >
> > ---
> >
> > Another solution to this problem is mark certain file which is generated
> > using what source package inside the header, and during build process
> > the copyright information requires to be attached in the binary package.
> > This should introduce another tag "Depends", like:
> >
> >   Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
> >   Depends:  package-b
>
> Thank you for taking the time to write this up!
>
> If I understand correctly, the use case is when your package contains a
> file, but the source is in another package?
>
> I think there are two subcases.  Either
>
> 1. your binary package contains a file, and the source is in another
>package (your source package does NOT contain the file; it is
>generated/copied during build)
> 2. your source package (and maybe also your binary package) contains a
>file, and the source is in another package.
>
> Case (1) is (roughly) what the Built-Using field is for.
>
> The ftp-masters have indicated that case (2) is not acceptable.[1]
> CCing them in case they want to expand on that.
>
> So I don't think there is a use case for this.  But please let me know
> if I've misunderstood.
>
> [1]  https://bugs.debian.org/882723#35
>
> --
> Sean Whitton
>

Bug#884006: copyright-format: Documenting copyrights not in source package but in binary package

[Yao Wei]

On Sun, Dec 10, 2017 at 10:46:12AM -0700, Sean Whitton wrote:
> > One of the files inside Package A is generated during build time.
> > However, the generation of the file requires Package B which has
> > different copyright, and the generated file in Package A is basically
> > a format conversion of the file in Package B, and the copyright needs
> > to be retained per license of Package B.  It could be copyright
> > violation of Package B if copyright status and requirements is not
> > fulfilled in Package A and we redistribute Package A.
> >
> > I would suggest a tag "Files-Binary" in copyright-format to fulfill
> > this situation.
> 
> What would the definition of this field be?  It is not clear from your
> example.

Files-Binary would be package name and file path to the files which its
copyright is not in source package but in binary package.  For example:

  Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
  Copyright:2038 John Doe
  License:  Expat

---

Another solution to this problem is mark certain file which is generated
using what source package inside the header, and during build process
the copyright information requires to be attached in the binary package.
This should introduce another tag "Depends", like:

  Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
  Depends:  package-b

If the maintainer knows what specific file in package-b it requires,
they can specify it like:

  Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
  Depends:  package-b, data/orig-file

And if the specified file in package-b has the same problem of
package-a, as it only exists in binary package, it can be like this:

  Files-Binary:   package-a-data, usr/share/package-a-data/file-in-question
  Depends-Binary: package-b-data, usr/share/package-b-data/orig-file

---

For real-world use case, I am packaging glyphslib, which has above
problem for a stripped file which needs to be generated from source:

  https://anonscm.debian.org/cgit/pkg-fonts/glyphslib.git/tree/debian/copyright

Please comment or propose another idea if the use case of them is not
clear.

Yao Wei


signature.asc
Description: PGP signature

Bug#878643: fonttools: Incomplete debian/copyright?

[Yao Wei]

Hi,

I am trying to address the problem in recent commits:

  
https://anonscm.debian.org/cgit/pkg-fonts/fonttools.git/tree/debian/copyright?id=23ab347dec865109b74ac78be6c06eff81a0a0f4

And found there are some files distributed without licenses in upstream
package.  This issue is reported to upstream:

  https://github.com/fonttools/fonttools/issues/1116

On Sun, Oct 15, 2017 at 12:00:30PM +0100, Chris Lamb wrote:
> I just ACCEPTed fonttools from NEW but noticed it was missing 
> attribution in debian/copyright for a large nember of files
> under Tests/*.
> 
> This is not exhaustive so please check over the entire package 
> carefully and address these on your next upload.

Yao Wei


signature.asc
Description: PGP signature

Bug#881466: ITP: nekojishi -- Interactive visual novel with furries and Taiwanese cultures

[Yao Wei]

Hi,

I found that there are several sound materials, listed in about screen,
are probably not as distributable as I imagined:

  * AudioBlocks (https://www.audioblocks.com):
https://www.audioblocks.com/license
§C.1 You cannot sell, license, or redistribute our Stock Files, nor
can you build your own stock media site with our file
  * SoundJay.com (https://www.soundjay.com):
https://www.soundjay.com/tos.html

They both have license limiting distributing the files, AudioBlocks
states one cannot redistribute the files.  Can recompressing the files
into .deb count toward it?  I am trying to play safe.

---

  * RoyalFreeSound (https://www.youtube.com/user/RoyalFreeSound)
  * SOUND and IMAGE FX 
(https://www.youtube.com/channel/UCQvVl9c7RKpyO5aKwxtb_lw)

These are YouTube videos without specifying the license of the material.
Is that possible to swap these out for proper licensed things?

---

  * Taira Komori (http://taira-komori.jpn.org)
  * Freesound.org (http://freesound.org)

Taira Komori also uploads to Freesound.org under CC-BY, which are
DFSG-free.  Other sounds might remain unattributed but we can still do a
precise check to the sound library.

Best regards,
Yao (Meow) Wei


signature.asc
Description: PGP signature

Bug#806503: ITP: mutatormath -- calculation of piecewise linear interpolations in n-dimensions with masters

[Yao Wei]

On Wed, Aug 30, 2017 at 11:20:24AM +0800, Yao Wei wrote:
> I am going to fulfill the dependency for glyphslib (#868005). This is
> one of them.

Hi,

The test file they are using seems to be a derivative works from Adobe
according to their meta file.

I filed an issue on their GitHub repository and see if the upstream
can help us:

  https://github.com/LettError/MutatorMath/issues/96

Yao Wei


signature.asc
Description: PGP signature

Bug#877165: RFS: fonttools 3.15.1-3

[Yao Wei]

Hi,

Patches are applied.  Please confirm.

Yao Wei

On Wed, Oct 04, 2017 at 11:47:06AM +0200, Rene Engelhard wrote:
> Can't yet push myself as I am not (yet) in pkg-fonts, so here's what
> would be needed still. Please apply (git-am) :)


signature.asc
Description: PGP signature

Bug#877165: RFS: fonttools 3.15.1-3

[Yao Wei]

On Wed, Oct 04, 2017 at 11:23:06AM +0200, Rene Engelhard wrote:
> Those changes are in alioth are broken.

Please git pull again. The changes are just in.

Yao Wei


signature.asc
Description: PGP signature

Bug#876439: [Pkg-fonts-devel] Bug#876439: Bug#876439: Continue providing Python 2 libraries

[Yao Wei]

On Wed, Oct 04, 2017 at 04:26:45PM +0800, Yao Wei wrote:
> I believe that the package "fonttools" is actually for transitional
> purposes so it should depend on python-fonttools instead of
> python3-fonttools.  Do we actually using its executable directly, or we
> use it as a library?

Sorry that I should put fonttools program in package named "fonttools",
which uses python3 to run.

Also, the proposed changes are in Alioth. Please review:

  https://anonscm.debian.org/cgit/pkg-fonts/fonttools.git/

And I need someone to sponsor upload this.

Thanks,
Yao Wei


signature.asc
Description: PGP signature

Bug#876439: [Pkg-fonts-devel] Bug#876439: Continue providing Python 2 libraries

[Yao Wei]

On Wed, Oct 04, 2017 at 10:22:22AM +0200, Rene Engelhard wrote:
> in my initial report. (But yes, python-fonttools/python3-fonttools would make 
> sense,
> but then fonttools probably should depends on the python3 thingy and people 
> who need
> the python2 module can build-depend on python-fonttools. Or does stuff use 
> stuff
> from fonttools _and a different_ python version?

I believe that the package "fonttools" is actually for transitional
purposes so it should depend on python-fonttools instead of
python3-fonttools.  Do we actually using its executable directly, or we
use it as a library?

Yao Wei


signature.asc
Description: PGP signature

Bug#876439: [Pkg-fonts-devel] Bug#876439: Continue providing Python 2 libraries

[Yao Wei]

Hi,

So, to actually maintain the dependency of fonts building, is it
advisable to let fonttools depend on python-fonttools instead of
python3-fonttools?

I am going to package libraries to make fontmake available in Debian
(which is a python3 program so all python3 dependencies), however no
package have dependency on python3-fonttools yet.  If that's okay, I
will try to rework on the packaging.

Yao Wei

On Wed, Oct 04, 2017 at 12:11:00PM +0530, Balasankar C wrote:
> Latest upload of fonttools broke many reverse build-dependencies. Please
> don't drop Python 2 support without a prior warning or proper migration
> plan/period.


signature.asc
Description: PGP signature

Bug#877165: RFS: fonttools 3.15.1-3

[Yao Wei]

Hi,

I would like to request for sponsorship for uploading the package for
closing the serious bug #877165, which will change the binary package
name from fonttools to python3-fonttools.  Also I would like to change
the section of this package from fonts to devel.

The changes takes place in Alioth.  Please review.

Best regards,
Yao Wei


signature.asc
Description: PGP signature

Bug#865283: fontmake

[Yao Wei]

Thanks for heading up. I am also going to package another font
(fonts-alegreya-sans) that uses Glyphs.app for authoring.

Yao Wei

On Mon, Oct 02, 2017 at 04:06:34PM +0200, Paride Legovini wrote:
> Just to make the point, I prepared an up to date table of the missing
> dependencies for fontmake:
> 
> - https://github.com/googlei18n/cu2qu [RFP #868004]
> - https://github.com/googlei18n/glyphsLib [ITP #868005]
> - https://github.com/googlei18n/ufo2ft[RFP #868006]
>   - https://github.com/fonttools/fonttools[OK]
>   - https://github.com/googlei18n/compreffor  [MISSING]
> - https://github.com/LettError/MutatorMath[ITP #806503]
>   - https://github.com/typesupply/fontMath[ITP #806514]
>   - https://github.com/unified-font-object/ufoLib [ITP #870878]
> - https://github.com/typemytype/booleanOperations.git [RFP #806516]
> - https://github.com/typesupply/defcon.git[ITP #806513]
> 
> All the ITPs are owned by Yao Wei, who is doing a great work in
> packaging most of fontmake's dependencies. I'll try to take care of some
> of the missing ones, if nobody is already working on them.
> 
> I'm interested in fontmake as I maintain the fonts-hack package
> (together with Fabian Greffrath). Starting from the soon to be released
> version 3, this font will be distributed together with a build script
> based on fontmake. This means that it will be finally possible to
> distribute a source package for Hack that builds to a binary package,
> making it a truly FLOSS font.
> 
> Kind regards,
> 
> Paride


signature.asc
Description: PGP signature

Bug#806514: ITP: fontmath -- collection of objects that implement fast font, glyph, etc.

[Yao Wei]

Control: retitle -1 ITP: fontmath -- collection of objects that implement fast 
font, glyph, etc.
Control: owner -1 !

I am going to fulfill the dependency of glyphsLib (#868005), and this is
one of the missing puzzles.

On Sat, 28 Nov 2015 18:43:33 +0900 Hideki Yamane  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Hideki Yamane 
> 
> * Package name: fontmath
>   Version : 0.2~20151123
>   Upstream Author : Tal Leming 
> * URL : https://github.com/typesupply/fontMath
> * License : MIT
>   Programming Lang: Python
>   Description : collection of objects that implement fast font, glyph, 
> etc.
> 
>  A set of objects for performing math operations on font data.
> 
> 


signature.asc
Description: PGP signature

Bug#868005: RFP: glyphsLib -- Library for opening and converting Glyphs font sources

[Yao Wei]

Control: retitle -1 ITP: glyphsLib -- Library for opening and converting Glyphs 
font sources
Control: owner -1 !
Control: block -1 by 806503 806513 806514 870878

I would like to upload this after uploading the dependencies.

On Mon, 10 Jul 2017 22:01:38 -0700 James Godfrey-Kittle  
wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: glyphsLib
>   Version : 1.7.5
>   Upstream Author : Google Internationalization Team
> * URL : https://github.com/googlei18n/glyphsLib
> * License : Apache-2.0
>   Programming Lang: Python
>   Description : Library for opening and converting Glyphs font sources
> 
> This library can open and manipulate Glyphs font source files
> (.glyphs), and provides a tool for exporting these sources to the UFO
> format.
> 
> 


signature.asc
Description: PGP signature

Bug#806503: ITP: mutatormath -- calculation of piecewise linear interpolations in n-dimensions with masters

[Yao Wei]

Control: owner -1 !
Control: retitle -1 mutatormath -- calculation of piecewise linear 
interpolations in n-dimensions with masters

Hi,

I am going to fulfill the dependency for glyphslib (#868005). This is
one of them.

Yao Wei

On Sat, 28 Nov 2015 12:45:39 +0900 Hideki Yamane <henr...@debian.org> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Hideki Yamane <henr...@debian.org>
> 
> * Package name: mutatormath
>   Version : 0.0.1~20151122
>   Upstream Author : Erik van Blokland <e...@letterror.com>
> * URL : https://github.com/LettError/MutatorMath
> * License : BSD-3-clause
>   Programming Lang: Python
>   Description : calculation of piecewise linear interpolations in 
> n-dimensions with masters
> 
>  MutatorMath is a Python library for the calculation of piecewise linear
>  interpolations in n-dimensions with any number of masters. 
>  It was developed for interpolating data related to fonts, but if can handle
>  any arithmetic object.
> 
> 


signature.asc
Description: PGP signature

Bug#872773: ITP: firefox-passff -- pass manager extension for Firefox

[Yao Wei]

On Mon, Aug 21, 2017 at 06:33:48AM -0400, Paul Wise wrote:
> I don't think either firefox-passff or passff is an appropriate name
> for webextensions. I'd suggest instead to prefix it with webextension-
> or webext-, but you probably should start a discussion on debian-devel
> about that.
> 
> I'd suggest to talk to the maintainers of Firefox XUL and Chromium
> extensions already in Debian about forming a new team for
> WebExtensions.

I later found out that the package is not ready for Chromium yet, but
anyways I started the thread in debian-devel and pkg-mozext-maintainers
now.

Also found out that the package ublock-origin has been maintained by
pkg-mozext team for both xul-ext and chromium addons.


signature.asc
Description: PGP signature

Bug#870875: ITP: fonts-alegreya-sans -- Humanist sans-serif font designed by Juan Pablo del Peral

[Yao Wei]

Alternatively we can use this commit to achieve BFS:
https://github.com/huertatipografica/Alegreya-Sans/commit/e870e363e24b3fea3466de93514282987892b82c


signature.asc
Description: PGP signature

Bug#862169: jessie-pu: package lxterminal/0.2.0-1

[Yao Wei]

Hi,

On Tue, Jun 27, 2017 at 10:59:24PM +0200, Cyril Brulebois wrote:
> You're fixing this through jessie-pu (short for jessie-proposed-updates),
> rather than via security; so please use “jessie” as the target codename.

Sorry that the patch was meant to jessie-security target.  Attached is
the corrected one.

Yao Wei
diff -Nru lxterminal-0.2.0/debian/changelog lxterminal-0.2.0/debian/changelog
--- lxterminal-0.2.0/debian/changelog   2014-10-22 06:18:50.0 +0800
+++ lxterminal-0.2.0/debian/changelog   2017-05-09 11:37:21.0 +0800
@@ -1,3 +1,10 @@
+lxterminal (0.2.0-1+deb8u1) jessie; urgency=high
+
+  * Fix improper use of /tmp for a socket file (CVE-2016-10369)
+(Closes: #862098)
+
+ -- Yao Wei (魏銘廷) <m...@lxde.org>  Tue, 09 May 2017 11:37:21 +0800
+
 lxterminal (0.2.0-1) unstable; urgency=low
 
   * Adding --disable-silent-rules to fix buildlog checker warning.
diff -Nru lxterminal-0.2.0/debian/patches/01-cve-2016-10369.diff 
lxterminal-0.2.0/debian/patches/01-cve-2016-10369.diff
--- lxterminal-0.2.0/debian/patches/01-cve-2016-10369.diff  1970-01-01 
08:00:00.0 +0800
+++ lxterminal-0.2.0/debian/patches/01-cve-2016-10369.diff  2017-05-09 
11:37:21.0 +0800
@@ -0,0 +1,19 @@
+From: Yao Wei (魏銘廷) <m...@lxde.org>
+Subject: fix: CVE-2016-10369: socket can be blocked by another user
+
+* fix: use g_get_user_runtime_dir for socket directory
+
+Origin: upstream, 
https://git.lxde.org/gitweb/?p=lxde/lxterminal.git;a=commit;h=f99163c6ff8b2f57c5f37b1ce5d62cf7450d4648
+Bug-Debian: http://bugs.debian.org/862098
+
+--- a/src/unixsocket.c
 b/src/unixsocket.c
+@@ -120,7 +120,7 @@
+  * This function returns TRUE if this process should keep running and 
FALSE if it should exit. */
+ 
+ /* Formulate the path for the Unix domain socket. */
+-gchar * socket_path = g_strdup_printf("/tmp/.lxterminal-socket%s-%s", 
gdk_get_display(), g_get_user_name());
++gchar * socket_path = g_strdup_printf("%s/.lxterminal-socket-%s", 
g_get_user_runtime_dir(), gdk_display_get_name(gdk_display_get_default()));
+ 
+ /* Create socket. */
+ int fd = socket(PF_UNIX, SOCK_STREAM, 0);
diff -Nru lxterminal-0.2.0/debian/patches/series 
lxterminal-0.2.0/debian/patches/series
--- lxterminal-0.2.0/debian/patches/series  2014-10-22 05:56:19.0 
+0800
+++ lxterminal-0.2.0/debian/patches/series  2017-05-09 11:37:21.0 
+0800
@@ -0,0 +1 @@
+01-cve-2016-10369.diff


signature.asc
Description: PGP signature

Bug#862150: unblock: lxterminal/0.3.0-2

[Yao Wei]

retitle 862150 unblock: lxterminal/0.3.0-2
thanks

Sorry for indicating wrong version.  It should be lxterminal/0.3.0-2 for
the unblock request.

unblock lxterminal/0.3.0-2


signature.asc
Description: PGP signature

Bug#848198:

[Yao Wei]

Seems good. I was on the mobile phone and the download link didn't appear
for the mobile.
On Mon, 6 Mar 2017 at 11:11 Anthony Wong <y...@anthonywong.net> wrote:

> Hi Yao Wei,
>
> I see there is a colour one at
> https://www.google.com/get/noto/#emoji-zsye-color, should we give this
> one a shot instead?
>
> Thanks,
> Anthony
>
>
> On 6 March 2017 at 10:49, Yao Wei <m...@lxde.org> wrote:
>
> However prebuilt Noto Color Emoji isn't in the original repository but in
> Android source. The TTF in the repo is old greyscale Emoji. If that's
> considered okay I can go that way.
> On Mon, 6 Mar 2017 at 03:18 Anthony Wong <y...@anthonywong.net> wrote:
>
> Hi,
>
> I wonder if we can skip building it from source and just package the
> pre-built font file provided by Google? Like what we are doing with Noto
> CJK font.
> The license of the font file is SIL Open Font License Version 1.1, as far
> as I check.
>
> Thanks,
> Anthony Wong
>
>
>

Bug#848198:

[Yao Wei]

However prebuilt Noto Color Emoji isn't in the original repository but in
Android source. The TTF in the repo is old greyscale Emoji. If that's
considered okay I can go that way.
On Mon, 6 Mar 2017 at 03:18 Anthony Wong  wrote:

> Hi,
>
> I wonder if we can skip building it from source and just package the
> pre-built font file provided by Google? Like what we are doing with Noto
> CJK font.
> The license of the font file is SIL Open Font License Version 1.1, as far
> as I check.
>
> Thanks,
> Anthony Wong
>

Bug#849042: Bug#848198: fonts-noto-color-emoji

[Ming-ting “Yao” Wei]

Hi,

I am packing that but progressing slowly because there's need to upload build 
dependency (nototools, #848206) to build from source and I might need to handle 
the documentation of the package. 

I can do a rename of this ITP to include the fallback version of the emoji. 
Should we do that? (Also I can't find the source of Noto Emoji despite of the 
redistributable ttf.) 

Yao Wei, sending this on a phone

> On 23 Dec 2016, at 04:17, Taylor Kline <taylor.kl...@utexas.edu> wrote:
> 
> Hello Yao,
> 
> Are you progressing with packaging fonts-noto-color-emoji? I filed an RFP:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849042
> 
> and a fonts-noto wishlist item:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849127
> 
> before discovering your intent to package filed on 15 December.
> 
> Thanks,
> -Taylor

Bug#831391: [Pkg-ime-devel] Bug#831391: U+2601 CLOUD 反而像電信桿而非雲

[Yao Wei]

以下指令可以列出 Sans 這個字體所有使用到的實際字體：

fc-match Sans -s

請把這個指令產生的列表傳過來給我們判斷你顯示 U+2601 CLOUD 時是使用哪一個字體。

On Fri, 15 Jul 2016 at 23:43 積丹尼 Dan Jacobson <jida...@jidanni.org> wrote:

> >>>>> "YW" == Yao Wei <m...@lxde.org> writes:
> YW> 這個問題比較像是在字型，可以請你確認一下系統使用的字體是哪一套嗎？
>
> 教我要用什麼指令得知之？ Thanks.
>
> Versions of packages scim-chewing depends on:
> ii  libatk1.0-0  2.20.0-1
> ii  libc62.23.90+20160711.c10f90d-1
> ii  libcairo-gobject21.14.6-1+b1
> ii  libcairo21.14.6-1+b1
> ii  libchewing3  0.5.1-1
> ii  libgcc1  1:6.1.1-9
> ii  libgdk-pixbuf2.0-0   2.34.0-1
> ii  libglib2.0-0 2.49.2-2
> ii  libgtk-3-0   3.20.6-2
> ii  libpango-1.0-0   1.40.1-1
> ii  libpangocairo-1.0-0  1.40.1-1
> ii  libscim8v5   1.4.17-1
> ii  libstdc++6   6.1.1-9
> ii  scim 1.4.17-1
>

Bug#831391: [Pkg-ime-devel] Bug#831391: U+2601 CLOUD 反而像電信桿而非雲

[Yao Wei]

這個問題比較像是在字型，可以請你確認一下系統使用的字體是哪一套嗎？
On Fri, 15 Jul 2016 at 21:09 積丹尼 Dan Jacobson  wrote:

> Package: scim-chewing
> Version: 0.5.1-1
>
> U+2601 CLOUD 於 "3." 反而像電信桿而非雲。
> ___
> Pkg-ime-devel mailing list
> pkg-ime-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ime-devel

Bug#806565: big-cursor: Does not support /etc/alternatives/x-cursor-theme

[Yao Wei]

Hi,

It is currently served as a replacement of cursor.pcf.gz in X11 fonts,
and to use it, set your x-cursor-theme to core.theme.

And the size of other cursor themes is changeable, and there's
currently no Debian way to change the cursor size.
To change it, create a file in /etc/X11/Xresources/ or ~/.Xresources
and have a line with
Xcursor.size: 48

According to Adwaita cursor theme, currently legit options for cursor
sizes are 24px, 32px, 48px, 64px and 96px.


On Sun, Nov 29, 2015 at 7:43 AM, Joel Roth <jo...@pobox.com> wrote:
> Dear Maintainer,
>
> Installing the big-cursor package does not change the mouse
> pointers for several window managers including fvwm and
> icewm.
>
> I consider this a high priority, because users with vision
> issues need to be adapt Debian to their requirements without
> having to explore the many web pages with incomplete and
> conflicting recommendations.

Thanks,
Yao Wei

Bug#796435: reportbug fails on filing against wnpp

[Yao Wei]

After digging debianbts.py a bit, I found that bug #792509 has Owner: -1
that python considers it a number.  It might be also a problem to the
bug tracker.


signature.asc
Description: Digital signature

Bug#796435: reportbug fails on filing against wnpp

[Yao Wei]

I workarounded the problem by wrapping str() on string in
debianbts.py:321. Hope it could be useful before real fix pushed into
repository.


signature.asc
Description: Digital signature

Bug#730477: lxterminal: shows sudo password

[Yao Wei]

tags 730477 unreproducible
close 730477
thanks

Hello,

I found it unreproducible on my machine.  If you want to reopen, please
make sure to remember your commands.

Thank you,
Yao Wei


signature.asc
Description: Digital signature

Bug#784662: lxterminal: Lxterminal half in english

[Yao Wei]

It seems that the problem is in the incomplete translation.  It will be
fixed in the next release, but will ask the previous person releasing
the package if we can release the newer release.


signature.asc
Description: Digital signature

Bug#756541: ITA: big-cursor -- larger mouse cursors for X

[Yao Wei]

retitle 756541 ITA: big-cursor -- larger mouse cursors for X
owner 756541 !

I would like to adopt this packkage as this might be useful for running
X on high resolution displays which becomes much popular nowadays.


signature.asc
Description: Digital signature

Bug#768635: big-cursor: Requires a change to /etc/alternatives/x-cursor-theme

[Yao Wei]

Sorry for the late but this would directly modify the files installed
in the xcursor-themes. I found another way which should be suitable:

1. Install xcursor-themes
2. sudo update-alternatives --config x-cursor-theme
3. Select /etc/X11/cursors/core.theme

Then the cursor fall back to the X11 cursor which can be provided by
this package, or the default cursor by X11.

On Sat, 08 Nov 2014 10:35:16 -1000 Joel Roth jo...@pobox.com wrote:
 Package: big-cursor
 Version: 3.9
 Severity: normal
 
 Dear Maintainer,
 
 Installing big-cursor package did not change the default
 cursor on two systems I maintain (sid, Ubuntu LTS) where X
 is started with startx. 
 
 Big-cursor was not offered as a choice when I ran:
 
 update-alternatives --config x-cursor-theme
 
 I resolved the issues by editing
 /etc/alternatives/x-cursor-theme.
 
 If this approach is suitable, perhaps it could be documented
 in README.Debian:
 
   For some systems it may be necessary to edit
   /etc/alternatives/x-cursor-theme as follows:
 
   [Icon Theme]
   Inherits=big-cursor
 
 Thank you.
 
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers unstable
   APT policy: (500, 'unstable')
 Architecture: amd64 (x86_64)
 Foreign Architectures: i386
 
 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
 set to en_US.utf8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages big-cursor depends on:
 ii  xfonts-base   1:1.0.3
 ii  xfonts-utils  1:7.7+2
 
 big-cursor recommends no packages.
 
 big-cursor suggests no packages.
 
 -- no debconf information
 
 


signature.asc
Description: Digital signature

Bug#783816: RFP: thefuck -- Correct your misbehavior on the command line

[Yao Wei]

One question,

Is it allowed to have different package name without actually
forking the project?
I don't wanna create another Iceweasel here.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758688: libvirt-daemon-system (1.2.7-9) dist-upgrade failed

[Yao Wei]

Package: libvirt-daemon-system
Version: 1.2.7-9
Followup-For: Bug #758688

I personally guess the prerm script assumes virtlockd service is up:
deb-systemd-invoke stop virtlockd.socket virtlockd.service /dev/null

The installation can continue after the following command:
deb-systemd-invoke start virtlockd.socket virtlockd.service

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libvirt-daemon-system depends on:
ii  adduser  3.113+nmu3
ii  gettext-base 0.19.2-1
ii  init-system-helpers  1.20
ii  libapparmor1 2.8.0-5.1+b2
ii  libaudit11:2.3.7-1
ii  libavahi-client3 0.6.31-4
ii  libavahi-common3 0.6.31-4
ii  libblkid12.20.1-5.8
ii  libc62.19-9
ii  libcap-ng0   0.7.3-1.1
ii  libdbus-1-3  1.8.6-2
ii  libdevmapper1.02.1   2:1.02.88-1
ii  libgnutls-deb0-283.2.16-1
ii  libnl-3-200  3.2.24-2
ii  libnl-route-3-2003.2.24-2
ii  libnuma1 2.0.9-1.1
ii  librados20.80.5-1
ii  librbd1  0.80.5-1
ii  libsasl2-2   2.1.26.dfsg1-11
ii  libselinux1  2.3-1
ii  libssh2-11.4.3-3
ii  libsystemd-daemon0   208-7
ii  libvirt-clients  1.2.7-9
ii  libvirt-daemon   1.2.7-9
ii  libvirt0 1.2.7-9
ii  libxml2  2.9.1+dfsg1-4
ii  libyajl2 2.1.0-1
ii  logrotate3.8.7-1

Versions of packages libvirt-daemon-system recommends:
ii  bridge-utils  1.5-9
ii  dmidecode 2.12-3
ii  dnsmasq-base  2.71-1
ii  ebtables  2.0.10.4-3
ii  iproute2  3.16.0-1
ii  iptables  1.4.21-2
ii  parted3.2-4
ii  pm-utils  1.4.1-15

Versions of packages libvirt-daemon-system suggests:
pn  apparmor none
pn  auditd   none
ii  policykit-1  0.105-6.1
pn  radvdnone
ii  systemd  208-7
pn  systemtapnone

-- Configuration Files:
/etc/libvirt/qemu.conf [Errno 13] Permission denied: u'/etc/libvirt/qemu.conf'

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#757187: libpam-google-authenticator should provide a method to configure using pam-auth-update

[Yao Wei]

Package: libpam-google-authenticator
Version: 20130529-2
Severity: wishlist

Dear Maintainer,

When I use `sudo dpkg-reconfigure libpam-runtime`, I found that it
cannot be configured using the menu.  pam-auth-update is what it handles
the configuration in dpkg-reconfigure.  Please consider adding the
capability in your next update.

Thanks,
Yao Wei


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (550, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libpam-google-authenticator depends on:
ii  libc6 2.19-7
ii  libpam0g  1.1.8-3
ii  libqrencode3  3.4.3-1

libpam-google-authenticator recommends no packages.

libpam-google-authenticator suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#683774: RFP: fonts-adobe-sourcesanspro -- set of OpenType fonts designed for user interfaces

[Yao Wei]

merge 683774 736680
thanks

I am thinking of working around it by forking the project and
providing a source code form that can be built from tools in main.

Is it possible and DFSG-compatible?

Thanks,
-- 
Yao Wei


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754926: fonts-noto: Update fonts-noto to include CJK fonts

[Yao Wei]

Package: fonts-noto
Version: 2013-04-11-2
Severity: wishlist
Tags: l10n

Dear Maintainer,

Google added CJK fonts in Noto font family [0], please consider updating
them.

This includes 3 different weights of CJK glyphs.

[0]: http://www.google.com/get/noto/cjk.html



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (550, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743798: RFP: ipad-charge -- Utility to make iPad charge with the computer

[Yao Wei]

Package: wnpp
Severity: wishlist

* Package name: ipad-charge
  Version : (seems no packaged release available upstream)
  Upstream Author : Max Korenkov mkoren...@gmail.com
* URL : https://github.com/mkorenkov/ipad_charge
* License : GPLv2
  Programming Lang: C
  Description : Utility to make iPad charge with the computer

iPad requires a special command to make it charge with computers.
There's already utilities, for example, ASUS Ai Charger on Windows to
make iPad charge, and users in Ubuntu community comes up with a small
utility to make iPad charge.

pkg-gtkpod seems is the most relevant maintainer group for this package.

If no one is interested in this, I will try packaging this utility if I
have more time on this.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731736: partman doesn't detect GPT partitions installed Windows 8.1

[Yao Wei]

parted says:
/dev/sda contains GPT signatures, indicating that it has a GPT table.
However, it does not have a valid fake msdos partition table, as it
should. Perhaps it was corrupted.

I am going to follow this to fix my GPT table:
https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/205331

However, Linux can still tell the partitions. I am wondering why it
isn't a valid GPT table. Should I dd the
header of the hard drive?



-- 
Yao Wei


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731736: partman doesn't detect GPT partitions installed Windows 8.1

[Yao Wei]

Package: partman
Severity: important
Tags: d-i

partman doesn't show up the GPT partitions installed Windows 8.1 and thus I
cannot install Debian amend the Windows partition.

Although /dev/sda lists /dev/sda{1,2}, partman in d-i doesn't list the
partitions and free space, only the drive itself.

partman debug log is amended in this report.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (550, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
/bin/partman: ***
/lib/partman/init.d/25md-devices: 
***
/lib/partman/init.d/30parted: 
***
parted_server: === Starting the server
parted_server: main_loop: iteration 1
parted_server: Opening infifo
/lib/partman/init.d/30parted: IN: OPEN =dev=sda /dev/sda
parted_server: Read command: OPEN
parted_server: command_open()
parted_server: Request to open =dev=sda
parted_server: Opening outfifo
parted_server: OUT: OK


parted_server: OUT: OK


parted_server: Note =dev=sda as unchanged
parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 2
parted_server: Opening infifo
/lib/partman/init.d/30parted: IN: OPEN =dev=sdb /dev/sdb
parted_server: Read command: OPEN
parted_server: command_open()
parted_server: Request to open =dev=sdb
parted_server: Opening outfifo
parted_server: OUT: OK


parted_server: OUT: OK


parted_server: Note =dev=sdb as unchanged
parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 3
parted_server: Opening infifo
/lib/partman/init.d/30parted: IN: OPEN =dev=sdc /dev/sdc
parted_server: Read command: OPEN
parted_server: command_open()
parted_server: Request to open =dev=sdc
parted_server: Opening outfifo
parted_server: OUT: OK


parted_server: OUT: OK


parted_server: Note =dev=sdc as unchanged
parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 4
parted_server: Opening infifo
/lib/partman/init.d/35dump: 
***
/lib/partman/init.d/35dump: IN: DUMP =dev=sda
parted_server: Read command: DUMP
parted_server: command_dump()
parted_server: Opening outfifo
parted_server: OUT: OK


parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 5
parted_server: Opening infifo
Device: yes
Model: ATA OCZ-VERTEX4
Path: /dev/sda
Sector size: 512
Sectors: 250069680
Sectors/track: 63
Heads: 255
Cylinders: 15566
Partition table: no
/lib/partman/init.d/35dump: IN: DUMP =dev=sdb
parted_server: Read command: DUMP
parted_server: command_dump()
parted_server: Opening outfifo
parted_server: OUT: OK


parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 6
parted_server: Opening infifo
Device: yes
Model: ATA Hitachi HDS72101
Path: /dev/sdb
Sector size: 512
Sectors: 1953525168
Sectors/track: 63
Heads: 255
Cylinders: 121601
Partition table: yes
Type: gpt
Partitions: #   id  length  typefs  pathname
(0,0,0) (0,0,33)-1  0-17407 17408   primary label   /dev/sdb-1  
(0,0,34)(0,32,31)   -1  17408-1048575   1031168 primary free
/dev/sdb-1  
(0,32,32)   (31870,166,39)  1   1048576-26214504857526214400
primary ntfs/dev/sdb1   
(31870,166,40)  (91201,52,50)   2   262145048576-750155464703   
488010416128primary ext4/dev/sdb2   
(91201,52,51)   (121601,80,29)  -1  750155464704-1000204869119  
250049404416primary free/dev/sdb-1  
(121601,80,30)  (121601,80,62)  -1  1000204869120-1000204886015 16896   
primary label   /dev/sdb-1  
Dump finished.
/lib/partman/init.d/35dump: IN: DUMP =dev=sdc
parted_server: Read command: DUMP
parted_server: command_dump()
parted_server: Opening outfifo
parted_server: OUT: OK


parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 7
parted_server: Opening infifo
Device: yes
Model: Sony Storage Media
Path: /dev/sdc
Sector size: 512
Sectors: 30801920
Sectors/track: 63
Heads: 255
Cylinders: 1917
Partition table: no
/lib/partman/init.d/49md: 
***
/lib/partman/init.d/49md: IN: PARTITIONS =dev=sda
parted_server: Read command: PARTITIONS
parted_server: command_partitions()
parted_server: Opening outfifo
parted_server: OUT: OK


parted_server: No partitions
parted_server: OUT: 


parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 8
parted_server: Opening infifo
/lib/partman/init.d/49md: IN: PARTITIONS =dev=sdb
parted_server: Read command: PARTITIONS
parted_server: command_partitions()
parted_server: Opening outfifo
parted_server: OUT: OK


parted_server: OUT: -1  17408-1048575   1031168 primary free 

Bug#697677: mtpfs: Missing fuse-utils dependency

[Yao Wei]

Package: mtpfs
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The current version of mtpfs depends on fuse-utils which is not exist in the 
current sid repository.
The `fusermount` binary in sid now resides in `fuse` package.

-- System Information:
Debian Release: 7.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-rt-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#582090: ITP: viewnior -- simple, fast and elegant image viewer

[Yao Wei]

I forgot to mention that my modifications are in gtkimageview branch.

https://github.com/medicalwei/Viewnior/tree/gtkimageview

Sorry for your inconvenience.
- 原始郵件 -
 Hi,
 
 I can't see any modifications from the upstream trunk. Did you push the
 modifications to github ?
 
 Regards,
 Julien Lavergne
 
 Le 11/25/2011 05:41 AM, Yao Wei a écrit :
  
  Actually I did a runable diff in Github: (but some zooming and mouse
  wheel won't work)
  
  http://github.com/medicalwei/viewnior
  
  - 原始郵件 -
   On 11/23/2011 07:02 AM, Julien Lavergne wrote:
   
Argh, bad news :(
   
   
   Yes, it turns this from a technical issue (package the app, and make
   sure it meets packaging standards) into a much more difficult how to
   keep everyone happy political issue!
   
Do we have an idea of the actual diff between the 2 versions ?
   
   
   I'll see if I can diff this over the coming weekend, unless someone
  else
   does it first :)
   
Contacting gtkimageview upstream is a good idea, a backup plan may
be to patch the package in Debian, but it's not a very nice
solution :(
   
   
   Another backup plan might be to create a libviewnior package with
   the modified library in it, and then a viewnior package that depends
   on it and uses it instead of gtkimageview??   But I don't know if
   Debian would like/accept that as an approach.
   
   Jonathan
  
 

Bug#582090: ITP: viewnior -- simple, fast and elegant image viewer

[Yao Wei]

Actually I did a runable diff in Github: (but some zooming and mouse wheel 
won't work)

http://github.com/medicalwei/viewnior

- 原始郵件 -
 On 11/23/2011 07:02 AM, Julien Lavergne wrote:
 
  Argh, bad news :(
 
 
 Yes, it turns this from a technical issue (package the app, and make
 sure it meets packaging standards) into a much more difficult how to
 keep everyone happy political issue!
 
  Do we have an idea of the actual diff between the 2 versions ?
 
 
 I'll see if I can diff this over the coming weekend, unless someone else
 does it first :)
 
  Contacting gtkimageview upstream is a good idea, a backup plan may be
  to patch the package in Debian, but it's not a very nice solution :(
 
 
 Another backup plan might be to create a libviewnior package with the
 modified library in it, and then a viewnior package that depends on it
 and uses it instead of gtkimageview??   But I don't know if Debian would
 like/accept that as an approach.
 
 Jonathan

Bug#582090: ITP: viewnior -- simple, fast and elegant image viewer

[Yao Wei]

It seems nice to have a helper who also wants to get this into debian. However, 
the package dependency makes it more complex to do so.

It uses a modified version of gtkimageview which is done by the author itself, 
but the library is needed to be stripped out of viewnior to get into Debian for 
maintenance reasons, and viewnior's author doesn't like to do so.

Paul Liu (a DD which seems can help us sponsor uploading this package) suggests 
we should contact gtkimageview author to incorporate the library changes from 
viewnior, but I don't know the way how should we do, and I am too 
unconcerntrate on this ITP.

Help me,
Yao Wei

- 原始郵件 -
 Lubuntu is very interested in including Viewnior as its default image
 viewer for Lubuntu 12.04.   I am an Lubuntu developer.
 
 I have previous Debian/Ubuntu packaging experience.   I am willing to
 package Viewnior for Debian (and so Ubuntu), and in fact I have already
 packaged it.   I do not want to step on someone's toes; can we work
 together, or is it OK for me to continue this work and seek a sponsor to
 get this package into Debian?
 
 Thanks,
 
 Jonathan
 
 

Bug#614531: awesome: diff for NMU version 3.4.9-1.1

[Ming-Ting Yao Wei]

tags 614531 + patch
tags 614531 + pending
thanks

Dear maintainer,

I've prepared an NMU for awesome (versioned as 3.4.9-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru awesome-3.4.9/debian/changelog awesome-3.4.9/debian/changelog
--- awesome-3.4.9/debian/changelog	2011-01-17 21:46:40.0 +0800
+++ awesome-3.4.9/debian/changelog	2011-04-30 14:17:20.0 +0800
@@ -1,3 +1,10 @@
+awesome (3.4.9-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Patch CMakeList to build successfully. (Closes: #614531)
+
+ -- Ming-Ting Yao Wei medical...@gmail.com  Sat, 30 Apr 2011 13:56:39 +0800
+
 awesome (3.4.9-1) unstable; urgency=low
 
   * New upstream release
diff -Nru awesome-3.4.9/debian/patches/normalize-icon-path-names.diff awesome-3.4.9/debian/patches/normalize-icon-path-names.diff
--- awesome-3.4.9/debian/patches/normalize-icon-path-names.diff	1970-01-01 08:00:00.0 +0800
+++ awesome-3.4.9/debian/patches/normalize-icon-path-names.diff	2011-04-30 13:56:32.0 +0800
@@ -0,0 +1,19 @@
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -273,14 +273,15 @@
+ 
+ # {{{ Theme icons
+ file(GLOB icon_sources RELATIVE ${SOURCE_DIR} ${SOURCE_DIR}/themes/*/titlebar/*.png)
+-set(ALL_ICONS ${icon_sources})
+ 
+ foreach(icon ${icon_sources})
+ # Copy all icons to the build dir to simplify the following code.
+ # Source paths are interpreted relative to ${SOURCE_DIR}, target paths
+ # relative to ${BUILD_DIR}.
+ get_filename_component(icon_path ${icon} PATH)
++get_filename_component(icon_name ${icon} NAME)
+ file(COPY ${icon} DESTINATION ${icon_path})
++set(ALL_ICONS ${ALL_ICONS} ${icon_path}/${icon_name})
+ endforeach()
+ 
+ macro(a_icon_convert match replacement input)
diff -Nru awesome-3.4.9/debian/patches/series awesome-3.4.9/debian/patches/series
--- awesome-3.4.9/debian/patches/series	2011-01-17 21:29:45.0 +0800
+++ awesome-3.4.9/debian/patches/series	2011-04-30 13:55:58.0 +0800
@@ -1 +1,2 @@
 debian-changes-3.4.9-1
+normalize-icon-path-names.diff

Bug#614531: awesome: diff for NMU version 3.4.9-1.1

[Ming-Ting Yao Wei]

Dear maintainer,

I've prepared an NMU for awesome (versioned as 3.4.9-1.1). The diff
is attached to this message.

Regards.

P.S. note that I don't know if it is the right procedure to resend NMU.
diff -Nru awesome-3.4.9/debian/changelog awesome-3.4.9/debian/changelog
--- awesome-3.4.9/debian/changelog	2011-01-17 21:46:40.0 +0800
+++ awesome-3.4.9/debian/changelog	2011-04-30 14:17:20.0 +0800
@@ -1,3 +1,10 @@
+awesome (3.4.9-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Patch CMakeList to build successfully. (Closes: #614531)
+
+ -- Ming-Ting Yao Wei medical...@gmail.com  Sat, 30 Apr 2011 13:56:39 +0800
+
 awesome (3.4.9-1) unstable; urgency=low
 
   * New upstream release
diff -Nru awesome-3.4.9/debian/patches/normalize-icon-path-names.diff awesome-3.4.9/debian/patches/normalize-icon-path-names.diff
--- awesome-3.4.9/debian/patches/normalize-icon-path-names.diff	1970-01-01 08:00:00.0 +0800
+++ awesome-3.4.9/debian/patches/normalize-icon-path-names.diff	2011-04-30 13:56:32.0 +0800
@@ -0,0 +1,19 @@
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -273,14 +273,15 @@
+ 
+ # {{{ Theme icons
+ file(GLOB icon_sources RELATIVE ${SOURCE_DIR} ${SOURCE_DIR}/themes/*/titlebar/*.png)
+-set(ALL_ICONS ${icon_sources})
+ 
+ foreach(icon ${icon_sources})
+ # Copy all icons to the build dir to simplify the following code.
+ # Source paths are interpreted relative to ${SOURCE_DIR}, target paths
+ # relative to ${BUILD_DIR}.
+ get_filename_component(icon_path ${icon} PATH)
++get_filename_component(icon_name ${icon} NAME)
+ file(COPY ${icon} DESTINATION ${icon_path})
++set(ALL_ICONS ${ALL_ICONS} ${icon_path}/${icon_name})
+ endforeach()
+ 
+ macro(a_icon_convert match replacement input)
diff -Nru awesome-3.4.9/debian/patches/series awesome-3.4.9/debian/patches/series
--- awesome-3.4.9/debian/patches/series	2011-01-17 21:29:45.0 +0800
+++ awesome-3.4.9/debian/patches/series	2011-04-30 13:55:58.0 +0800
@@ -1 +1,2 @@
 debian-changes-3.4.9-1
+normalize-icon-path-names.diff

Bug#623792: awesome: Dependency broken in Sid (libev3)

[Ming-Ting Yao Wei]

Package: awesome
Version: 3.4.9-1
Severity: grave
Justification: renders package unusable



-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

The dependency to libev3 is broken in sid, which renders the package 
uninstallable.

I will try building awesome with libev4 if possible.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#614531: FTBFS: make[5]: *** No rule to make target `themes/zenburn/titlebar/floating_normal_active.png', needed by `CMakeFiles/generated_icons'. Stop.

[Ming-Ting Yao Wei]

Package: awesome
Followup-For: Bug #614531


The upstream bug tracker closed bug #869 in their bug tracker.

I tried to apply the last patch and is building well.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages awesome depends on:
ii  dbus-x11  1.4.8-2simple interprocess messaging syst
ii  libc6 2.11.2-13  Embedded GNU C Library: Shared lib
ii  libcairo2 1.10.2-6   The Cairo 2D vector graphics libra
ii  libdbus-1-3   1.4.8-2simple interprocess messaging syst
ii  libev41:4.04-1   high-performance event loop librar
ii  libglib2.0-0  2.28.6-1   The GLib library of C routines
ii  libimlib2 1.4.4-1powerful image loading and renderi
ii  liblua5.1-0   5.1.4-5Simple, extensible, embeddable pro
ii  libpango1.0-0 1.28.3-6   Layout and rendering of internatio
ii  libstartup-notification0  0.10-1 library for program launch feedbac
ii  libx11-6  2:1.4.3-1  X11 client-side library
ii  libxcb-atom1  0.3.6-1utility libraries for X C Binding 
ii  libxcb-aux0   0.3.6-1utility libraries for X C Binding 
ii  libxcb-event1 0.3.6-1utility libraries for X C Binding 
ii  libxcb-icccm1 0.3.6-1utility libraries for X C Binding 
ii  libxcb-image0 0.3.6-1utility libraries for X C Binding 
ii  libxcb-keysyms1   0.3.6-1utility libraries for X C Binding 
ii  libxcb-property1  0.3.6-1utility libraries for X C Binding 
ii  libxcb-randr0 1.7-2  X C Binding, randr extension
ii  libxcb-render01.7-2  X C Binding, render extension
ii  libxcb-shape0 1.7-2  X C Binding, shape extension
ii  libxcb-shm0   1.7-2  X C Binding, shm extension
ii  libxcb-xinerama0  1.7-2  X C Binding, xinerama extension
ii  libxcb-xtest0 1.7-2  X C Binding, xtest extension
ii  libxcb1   1.7-2  X C Binding
ii  libxdg-basedir1   1.1.1-2Implementation of the XDG Base Dir
ii  menu  2.1.45 generates programs menu for all me

Versions of packages awesome recommends:
pn  rlwrapnone (no description available)
ii  x11-xserver-utils 7.6+2  X server utilities

awesome suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#602950: mirror submission for shadow.ind.ntou.edu.tw

[Ming-Ting Yao Wei]

Package: mirrors
Severity: wishlist

Submission-Type: new
Site: shadow.ind.ntou.edu.tw
Type: leaf
Archive-architecture: ALL alpha amd64 arm armel hppa hurd-i386 i386 ia64 
kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc 
Archive-ftp: /debian/
Archive-http: /debian/
Archive-rsync: debian/
CDImage-ftp: /debian-cd/
CDImage-http: /debian-cd/
CDImage-rsync: debian-cd/
IPv6: no
Archive-upstream: ftp.tw.debian.org
CDImage-upstream: ftp.tw.debian.org
Updates: twice
Maintainer: Ming-Ting Yao Wei m...@lxde.org
Country: TW Taiwan
Location: National Taiwan Ocean University
Sponsor: Institute of Network Development ind.ntou.edu.tw
Comment: I'll try to contact Andrew Lee soon for push triggered mirroring.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org