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#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]

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#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-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140406161336.5052.77176.report...@mami.m-wei.net

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-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cajknrte4qe_vow3jsfbg7uetihcaxpci201r3hq13ovakyk...@mail.gmail.com

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-wnpp-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAJkNRTGaborCQDABr5ArWscHZk0wzBV5jp8E_FxO9SpTniDD=a...@mail.gmail.com

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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#902029: 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