Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name

[Yao Wei (魏銘廷)]

>> * Package name: gender-guesser
>> Version : 0.4.0
>> Upstream Author : Israel Saeta Pérez 
>> * URL : https://github.com/lead-ratings/gender-guesser
>> * License : GPL-3 & GFDL-1.2+
>> Programming Lang: Python
>> Description : Guess the gender from first name

Hi,

I'd like to ask a practical question, do we have anything either in WNPP or in 
the archive that depends or uses this package?

Although I guess this library might violate DFSG 5 by itself, I would like to 
see where it's actually used and why we need the library.

Yao Wei

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

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Yao Wei (魏銘廷)]

Hi,

> Benda Xu  於 2021年4月19日 11:40 寫道：
> 
> The winning option "Debian will not issue a public statement on this
> issue" implies that the majority of DDs is not interested in such
> non-technical affairs.  Such a working group will distract us from
> achieving technical excellence.
> 

Most of the non DPL-electing GRs are at risk of tearing Debian Project apart.  
And IMO this is the least dangerous option.  It's not because we are not 
interested in non-technical affairs.

Yao Wei

Re: Making Debian available, non-free promotor

[Yao Wei]

On Fri, Jan 29, 2021 at 01:38:24PM +0100, Ansgar wrote:
> Yao Wei writes:
> >> We encourage you to get devices that respects your freedom.
> 
> Should this message also be shown when non-free firmware is preinstalled
> in the system for educational purposes?
> 
> Or do devices that have pre-installed non-free firmware respect the
> user's freedom?  As long as the users doesn't look and doesn't hear
> about it, it's not there after all (two-wise-monkey-free / FSF-free?).
> The best example probably are TiVo devices which don't have
> user-upgradable firmware and thus should be called "freedom respecting"
> ;-)
> 
> We could also recommend users to just install Debian in a VM which
> abstracts away the hardware, e.g., in a VM under Windows.  This also
> respects user freedom in the same sense as above as Windows is usually
> preinstalled.  (And AFAIU on modern systems Debian will usually run in
> some partition anyway and not have full hardware access, so it already
> runs in a "VM" of sorts.)
> 

It is to describe the DFSG-freedom we value.  I know that having
upgradable non-free firmware is better than having non-upgradable
firmware in case if there's vulnerability we need to address.  If we
find it not suitable, we can remove the text if that is going to be
implemented.

Of course it is easier to use Debian inside VM, but that is not the
situation we would like to address.

> iwlwifi does work fine with just free software just like hard disks and
> similar?

This listing is to list the packages that the user needs to download
into the flash drive.  In my case, iwlwifi requires additional firmware
so I picked it as an example.

And, the reason that I am picking networking, is that when system is
installed with networking, the user can then download packages for other
devices that require non-free packages to work.

Usability wise, the message on the non-free firmware loading in
debian-installer is not prominent enough, that people needs to discover
it through manual.  (This is also the case of the behavior in d-i that
it installs sudo when root password is empty.)  I would imagine that
people just download ISO, install, and they would consult search engines
for the problems they encounter, without realizing we have such function
built into our installer.

Thanks,
Yao Wei


signature.asc
Description: PGP signature

Re: Making Debian available, non-free promotor

[Yao Wei]

Hi,

Could there be the way that, with installer unable to connect to the
internet, it detects the list of missing blobs, and generate a webpage
in the thumb drive, and let user plug in another flash drive to download
them.

At then, we can let users download the missing drivers from the
generated webpage, like the following:

> Additional packages for the network interface
> ==
>
> As Debian is the universal operating system, we consider both users
> and free software important.  However, the network device of the
> computer requires firmware that is not available in the installation
> media, because these are considered non-free according to our
> guideline.
> 
> We encourage you to get devices that respects your freedom.
>
> Meanwhile, you can either try another device that's known good using
> only free software, or download the .deb package(s) linked below and
> put into the same place this file resides:
>
> ---
> 
> firmware-iwlwifi
> - for: Network Controller: Intel Corporation Wireless 8265 / 8275
> - https://packages.debian.org/bullseye/firmware-iwlwifi 

I realize that it is an additional step that may stop users from using
Debian.  But if we do not want to lower the priority of free software in
favor to the user, we have to increase the usability for people with
non-free devices in DFSG-only realm.

Just 2 cents,
Yao Wei


signature.asc
Description: PGP signature

Package broke in stable due to old API. Fix in stable or backports?

[Yao Wei]

Hi,

I have a package `meteo-qt` which is broke due to the use of old API,
which is reported here:
  https://bugs.debian.org/960451

There should be many existing cases, that external service the stable
package is using deprecates the old API, which in turn breaks the
package.  Do we have documented conventions that where the fixed package
should be uploaded to: stable-proposed-updates or backports?

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-devel@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.

Re: 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

Re: 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

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

Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???

[Yao Wei (魏銘廷)]

This case, in my interpretation, the text from the QR code is not upstream 
author's preferred form of modification.

The QR code probably is author's preferred form of modification by changing the 
payment QR code as a whole.

Ethics wise, we could ask author if they can accept other payment method than 
QR code form, while I can understand the extreme popularity in Mainland China.

Yao Wei

Re: Mozilla Firefox DoH to CloudFlare by default (for US users)?

[Yao Wei]

On Tue, Sep 10, 2019 at 08:24:03AM +0200, Ondřej Surý wrote:
> While I still strongly agree with you on this one (even though I think all
> major ISPs here are scumbags, especially the incumbent), I still strongly
> think we should not have this debate here, and we should turn this around
> the usual Debian policy - to not send data to 3rd party without explicit user
> content and defaulting to not doing so.

Should we propagate our concerns to Mozilla?

Yao Wei


signature.asc
Description: PGP signature

Re: On the Removal of src:tensorflow

[Yao Wei]

On Wed, Sep 04, 2019 at 07:38:11PM -0700, Mo Zhou wrote:
> I'm wondering who will read it. In the past I broadcasted some bits
> I learned to the public mailing lists and people responded, but
> nobody had ever asked me any detail about anything related.

Recently there's ITP for DeepSpeech (#921519) based on Baidu's research
and Mozilla Common Voice project, which is depending on TensorFlow:

https://github.com/mozilla/DeepSpeech

I think it is a good practice to leave a tombstone in the wiki that what
you consider may be pitfalls for packaging deep learning programs and
the problems that are specific to certain ML frameworks.

If anyone wants to resurrect TensorFlow in Debian, then it is a good
reference to see what they would like to avoid.

Best regards,
Yao Wei


signature.asc
Description: PGP signature

Re: duplicate popularity-contest ID

[Yao Wei (魏銘廷)]

> On Aug 5, 2019, at 20:29, Bill Allombert  wrote:
> 
> I am not quite sure what it is the reason for this problem.
> Maybe people use prebuild system images with a pregenerated
> /etc/popularity-contest.conf file (instead of being generated
> by popcon postinst).

Could this be caused by Debian-live installer based on Calamares?

Yao Wei

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

Debian and our frenemies of containers and userland repos

[Yao Wei]

Hi,

Following to Mo Zhou's thread of Conda and Debian, it reminds me that,
could Debian reduced into a "proof of concept" as an operating system
with collection of apps and things composed of completely free software,
as more and more software repositories are moving away from the free
software repositories like Debian, and userland repositories and app
containers becomes more prominent and easier to access.  I feel the fear
when I was in a flatpak session in DebConf17.

It can be a "solid base" of container images and barebone systems, but
the days are numbered as operating systems as free and focused on its
mission (like Google COOS, Yocto, Alpine etc.) is evolving steady.

Could it be a disaster for us?  And more importantly, do users care?

Best regards,
Yao Wei


signature.asc
Description: PGP signature

Getting rid of codenames (Was: getting rid of "testing")

[Yao Wei (魏銘廷)]

How about getting rid of codenames altogether?  Like we use unstable for 
unstable, experimental for experimental as it already is, no testing and buster 
but debian11, debian12, etc.

Although it is eliminating some funs but it is much more predictable and simple 
to remember. I also confused squeeze with stretch.

Yao Wei

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

> On Jun 28, 2019, at 04:17, Wouter Verhelst  wrote:
> 
> On Tue, Jun 25, 2019 at 01:11:09PM +0500, Andrey Rahmatullin wrote:
>> On Tue, Jun 25, 2019 at 09:46:00AM +0200, Bastian Blank wrote:
>>>> Related to that I would like to be able to write something like
>>>>  deb http://deb.debian.org/debian debian11 main
>>>>  deb http://security.debian.org/debian-security debian11-security main
>>>> in sources.list as codenames confuse people.
>>> 
>>> Can you please elaborate on the "confuse people"?
>> I guess only (most?) Debian contributors and hardcore Debian users
>> remember the order of the codenames and their mappings to current
>> stable/oldstable/testing and to numeric versions.
> 
> If even that.
> 
> Potato was followed by sarge, but I think there was something in between
> (although I'm not sure). There's an etch somewhere, and a lenny.
> 
> But what were the orderings again? I honestly don't remember.
> 
> Yes please, let's use debian11 in the URL somewhere.
> 
> -- 
> To the thief who stole my anti-depressants: I hope you're happy
> 
>  -- seen somewhere on the Internet on a photo of a billboard
> 

Re: Programs contain ads - acceptable for packaging for Debian?

[Yao Wei (魏銘廷)]

Hi,

> Bagas Sanjaya  於 2019年6月20日 20:54 寫道：
> 
> Such ads is displayed only when users have Internet connection, and there is 
> no way to patch ZZZ in order to remove ads (or we have to buy "pro" version 
> which doesn't contain ads and adds more features).


As a DFSG-free software it should be possible per license agreement. We can 
review the license for that.

Could you file a RFP for the exact software you would like to package?  We 
would like to see where the problem is.

Yao Wei

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

Re: Concern for: A humble draft policy on "deep learning v.s. freedom"

[Yao Wei (魏銘廷)]

Hi,

>> With a labeling like "ToxicCandy Model" for the situation, it makes bad
>> impression on people and I am afraid people may not be make rational
>> decision.  Is this characterization correct and sane one?  At least,
>> it looks to me that this is changing status-quo of our policy and
>> practice severely.  So it is worth evaluating idea without labeling.
> 
> My motivation for the naming "ToxicCandy" is pure: to warn developers
> about this special case as it may lead to very difficult copyright
> or software freedom questions. I admit that this name looks not
> quite friendly. Maybe "SemiFree" look better?

About the term ToxicCandy it makes me reminded of an existing
term "Tainted" which also used in Linux kernel to describe kernel
running with non-free module.

So... how about "Tainted Model"?

Just 2 cents,
Yao Wei

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

Re: Configure your PC to contribute to Debian community

[Yao Wei]

On Wed, May 08, 2019 at 10:22:18PM -0300, Emmanuel Arias wrote:
> I was writing a serie of blog's entry [1] (on spanish)
> trying to  let for me on the future some data. Maybe
> it could be helpful for you.
> 
> I have to write it on english version too and updated,
> because I was using a virtual machine, but now I was using
> chroot (that I think is better)
> 
> [1]https://eamanu.com/blog/guia-debian-maintainer-1-creando-la-estacion-de-trabajo/

I think we can have some sort of starter kit (dotfiles or setup script)
for new contributors or contributors with new Debian installations to
set up such as reportbug, gbp, quilt, sbuild, environment variables,
etc.  To put things simple I propose the kit should have generic
configurations.

Recently I bought a retired computer from work, and to use reportbug, I
copied my setup from my laptop, and this idea came to my mind.

Best regards,
Yao Wei


signature.asc
Description: PGP signature

Re: Unicode License Additional Coverage

[Yao Wei (魏銘廷)]

Never mind.  I was wrongfully read as the license has the problem.

(It is that, IVD files had no license attached to it, someone might think it is 
"All rights reserved" by copyright law in most jurisdictions. Please correct me 
if I am wrong again.)

Yao Wei

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

> On Jan 4, 2019, at 06:04, Yao Wei (魏銘廷)  wrote:
> 
> Hi,
> 
> Could you elaborate what part of license that someone might have concern?
> 
> It looks like X11 license for me at the first glance. 
> 
> Yao Wei
> 
> (This email is sent from a phone; sorry for HTML email if it happens.)
> 
>> On Jan 4, 2019, at 04:49, Paul Hardy  wrote:
>> 
>> Dear Debian,
>> 
>> Unicode, Inc. has informed me that they just added the directory
>> http://www.unicode.org/ivd/data/ to the list of directories explicitly
>> mentioned as covered by their license; see
>> http://www.unicode.org/copyright.html#License.
>> 
>> Among other files, that directory contains IVD_Sequences.txt, which
>> emacs (among other packages) uses.  The license ambiguity for that
>> file had been a concern for someone.
>> 
>> All the best,
>> 
>> 
>> Paul Hardy
>> 

Re: Unicode License Additional Coverage

[Yao Wei (魏銘廷)]

Hi,

Could you elaborate what part of license that someone might have concern?

It looks like X11 license for me at the first glance. 

Yao Wei

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

> On Jan 4, 2019, at 04:49, Paul Hardy  wrote:
> 
> Dear Debian,
> 
> Unicode, Inc. has informed me that they just added the directory
> http://www.unicode.org/ivd/data/ to the list of directories explicitly
> mentioned as covered by their license; see
> http://www.unicode.org/copyright.html#License.
> 
> Among other files, that directory contains IVD_Sequences.txt, which
> emacs (among other packages) uses.  The license ambiguity for that
> file had been a concern for someone.
> 
> All the best,
> 
> 
> Paul Hardy
> 

Re: Q: secure boot

[Yao Wei (魏銘廷)]

Hi,

As far as I remember there are some netbooks (from Lenovo) which cannot turn 
Secure Boot off even if it is x86 based.

We can tell user to buy laptop with Coreboot + HEADS preinstalled, or laptops 
that can turn Secure Boot off, but what if they are installing their existing 
machine?

(I hope Coreboot becomes more common in the market instead of Aptio, but it is 
hard to buy such laptop, even Chromebook, unless overseas from Taiwan...)

Yao Wei

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

Re: "debian.pool.ntp.org" for Debian derivatives?

[Yao Wei (魏銘廷)]

We are probably accepting their TOS without reading them first:

https://www.ntppool.org/tos.html

Yao Wei

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

> On Oct 18, 2018, at 20:51, Ansgar Burchardt  wrote:
> 
>> On Thu, 2018-10-18 at 13:57 +0200, Philipp Hahn wrote:
>> So my question is more like "is it okay to not change Debians default
>> NTP server selection", so the initial setup and those lazy enough to
>> not change the default get a sane time?
> 
> I don't think Debian can answer that question and suggest to ask the
> pool operators.  This seems to be the correct list:
>  https://lists.ntp.org/listinfo/pool
> 
> A related question is the use of API keys that are included in some
> packages (e.g. chromium).  These are also vendor-specific, but cannot
> be really secret (as they are included in the binaries and could be
> extracted even for proprietary software).
> 
> Ansgar
> 

Re: Updating the New Debian Developer welcome email

[Yao Wei (魏銘廷)]

Hi,

I filed the bug yesterday in nm.debian.org package but got a reply that the 
welcome message is managed by admin team, not NM.

https://bugs.debian.org/910057

Are there discussions about updating welcome email in Debian RT already?

Yao Wei

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

> On Oct 3, 2018, at 08:56, James McCoy  wrote:
> 
>> On Tue, Oct 02, 2018 at 05:45:35PM -0700, Joseph Herlant wrote:
>> Yesterday I received my New Debian Developer welcome email (\o/)
> 
> Congrats!
> 
>> and
>> noticed that it's still referencing alioth for the hosting of VCS
>> repositories.
>> 
>> I couldn't find in which repo the template for this email was hosted.
>> Could you point me to the right repo so I can do a MR for this please?
> 
> DSA manages user accounts.  After a little digging, I found the
> template[0].
> 
> [0]: 
> https://salsa.debian.org/dsa-team/mirror/userdir-ldap/blob/master/templates/welcome-message-Debian
> 
> Cheers,
> -- 
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
> 

Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

[Yao Wei]

Hi,

I believe by decentralization we can just implement it by not relying our
data on single company but multiple.

Still, it is up to their implementation how we can access their storage,
and as long as we can access it with free software (JavaScript stuff could
be a pitfall though) it shouldn't be too much problem for us.

Yao Wei

On Fri, Aug 17, 2018 at 16:52 Andrey Rahmatullin  wrote:

> On Fri, Aug 17, 2018 at 08:27:00AM +, Ulrike Uhlig wrote:
> > While I understand the simplicity of using $company's cloud storage, I'd
> > rather not rely on some external company and in particular not on this
> > one. This company does not exactly represent what I would call ethical,
> > non-proprietary, and decentralized.
> Is that a problem?
>
> > Are there no partners that would kindly provide such storage to Debian
> > (Gandi?).
> Are they ethical, non-proprietary, and decentralized?
>
> --
> WBR, wRAR
>

Re: Q: How to get build depends package from debian/control

[Yao Wei]

Though this works, I'd prefer mk-build-deps from devscripts since this
produces pseudo-package that depends on the build dependencies, and the
dependencies can be removed by removing the pseudo-package.

On Mon, 12 Feb 2018 at 07:39 Hideki Yamane  wrote:

> On Mon, 12 Feb 2018 12:32:08 +1300
> Michael Hudson-Doyle  wrote:
> > apt-get build-dep ./ installs the build dependencies from the local
> > ./debian/control doesn't it?
>
>  It is... Thanks!
>
> --
> Regards,
>
>  Hideki Yamane henrich @ debian.org/iijmio-mail.jp
>
>

Re: kernel nvidia dkms rebuild after upgrade?

[Yao Wei]

It is caused by a missing dependency libelf-dev.
It is already reported against linux-headers-4.14.0-3-amd64:
https://bugs.debian.org/886474

I have the same symptom of broadcom-sta-dkms

On Mon, 8 Jan 2018 at 02:47 Boyan Penkov  wrote:

> Hello,
>
> After the latest update to 4.9.0-5, and a backport (4.14.0-bpo2) -- in
> light of meltdown -- my nvidia drivers failed to load.
>
> Rebulding the modules manually --
>
> https://askubuntu.com/questions/53364/command-to-rebuild-all-dkms-modules-for-all-installed-kernels/174017
> -- did fix it.
>
> Did I miss something?
>
> Cheers!
>
> --
> Boyan Penkov
>
>

Re: Which files should go in ‘/usr/share/common-licenses/’?

[Yao Wei]

Shall I also point out that it might save some spaces for Debian archive?
It could be little but not effortless. Also for packagers it is easier to
read shorter copyright files rather than full of license details.

Yao Wei
On Sun, 10 Dec 2017 at 03:39 Ole Streicher <oleb...@debian.org> wrote:

> Ben Finney <bign...@debian.org> writes:
> > The files in ‘/usr/share/common-licenses/’ get installed on every Debian
> > system, by the ‘base-files’ package. This is needed because that allows
> > ‘/usr/share/doc/…/copyright’ to refer to a file there, knowing it will
> > be available.
> >
> > If I understand correctly, the justification of putting a file there
> > must include that it is overwhelmingly more likely to save *storage
> > space* overall (by reducing the space in a corresponding number of
> > ‘/usr/share/doc/…/copyright’ files), especially on machines that have
> > low disk space in ‘/usr/share/’.
> >
> > So I think we should specifically ask the position of people who have
> > expertise maintaining machines with very small disk space: How to judge
> > which files should be unilaterally installed in that directory, in the
> > hope of saving not only the efforts of package maintainers, but also the
> > storage requirements on storage-constrained systems.
>
> One minimal compromise could be to put the licenses of the packages in
> essential to /usr/share/common-licenses: since those get installed on
> any system, it will surely save space to centralize them.
>
> Best
>
> Ole
>
>

Re: Debian Stretch new user report (vs Linux Mint)

[Yao Wei]

On Mon, Dec 04, 2017 at 06:49:05PM +, Holger Levsen wrote:
> On Mon, Dec 04, 2017 at 11:41:34PM +0500, Andrey Rahmatullin wrote:
> > There are alternatives?
> 
> always.
> 
> 
> -- 
> cheers,
>   Holger

About alternatives, I found it difficult to buy a brand-new laptop with
802.11ac wifi chip which is available on the market.  All of them
requires firmware or even non-free Linux modules.  I asked MediaTeK
people with such issue when I had a job interview, and they replied that
they want to respect their shareholders. *sighs*

Everyone argues that firmware should be non-free and should be not
included in the ISO, but if the firmware is not able to sideload, it
means the firmware is not changable, and in most of the case we don't
have source code for it.  I believe it is the worse scenario than having
a non-free blob, which we can still have security updates.

My 2 cent is, we can distribute ISOs without non-free things, but we
need an add-on pack to put into the USB flash drive for non-free network
drivers, and we categorize the add-on not part of Debian.  We also have
to improve the website to point out, that "In most of the case non-free
drivers are required for your computer hardware to work", and point the
user to the add-on.

I hope my idea can balance our priorities of both the free software and
the users, and not give up one of them to achieve the other.

Yao Wei


signature.asc
Description: PGP signature

Re: allowed uses of non-baseline CPU extensions

[Yao Wei]

Hi,

I believe that we haven't talked about another problem is that what if
one installing Debian in the portable drive and use it in another
computer.

I think we could use debconf to warn user that the CPU of the computer
you are installing does not support instructions the package is
requiring, which should be also volkswagenable on user's request.

Yao Wei


signature.asc
Description: PGP signature

Packaging WebExtensions compatible with multiple browsers

[Yao Wei]

Hi,

There are some problems for us to package Debian packages for
WebExtensions that can support Firefox and Chromium using the same
codebase.  I do come up with my idea, but I still need a conclusion to
prepare a package:

1. Should we use different prefix for the WebExtensions packages that
support different browsers?

I think webext- prefix can be good for this kind of packages.

2. Should we split the package for different browsers?

There's current efforts packaging ublock-origin for both chromium and
xul-ext.  However shifting to WebExtensions implies that the codebase
will be the same.  To save disk space and lower the security risk not to
split the main package could be good.  Some of the browser-dependent
files can be splitted to their dedicated packages.

Inputs are welcome!

Best regards,
Yao Wei


signature.asc
Description: PGP signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Yao Wei]

On Mon, May 15, 2017 at 04:01:36PM +0300, Adrian Bunk wrote:
> Non-informative frontpages like the LXDE one are what scares me away.

Actually I agree as a user already using GNU/Linux, but for new users it
might have different experience.

> The contents of the Gentoo homepage is similar to what Debian has but 
> presented with a different CSS - something like that would be a good 
> improvement.

Agreed. I would argue that the page is too empty and every piece of news
information in the home page needs a click to view.  It could be nice to
expose a little bit more for the news articles.

Also we need something like "Why Debian?", but it could be better
represented in another page with colorful pictographs.  We need to call
designers' help for this.


signature.asc
Description: PGP signature

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Yao Wei]

Hi,

Are there a discussion list of people working on the issue? I'd like to
follow and see if there's any I could help.

If no, could this issue be submitted as a Debian bug?

Thanks,
Yao Wei

On Sun, May 14, 2017 at 02:33:19PM +0530, Pirate Praveen wrote:
> This is already planned (though pagure instead of gitlab). Anyone who
> wish to see it happen faster can help with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829046
> 


signature.asc
Description: PGP signature

Re: Multilicense `debian/copyright` file

[Yao Wei]

It is required to look into each file header and specify these
different files for each license.

Yao Wei

On 2012/7/14, at 13:09, Aliaksei Sheshka sheshka...@gmail.com wrote:

 Hi debian-devel list!

 Please help me to write a proper `debian/copyright` file.
 Original COPYING file says:

 Several parties hold copyright to various parts of IRRToolSet.  One or more
 of the following licenses may apply to the code contained within this
 distribution.
 1. USC (and occasionally USC/IBM) license
 .
 2. RIPE NCC license
 
 3. GNU General Public License version 2
 ...

 What should put in the `debian/copyright` then ?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/-707740834926000392@unknownmsgid

Accepted awesome 3.4.9-1.1 (source i386)

[Ming-Ting Yao Wei]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Apr 2011 13:56:39 +0800
Source: awesome
Binary: awesome
Architecture: source i386
Version: 3.4.9-1.1
Distribution: unstable
Urgency: low
Maintainer: Julien Danjou a...@debian.org
Changed-By: Ming-Ting Yao Wei medical...@gmail.com
Description: 
 awesome- highly configurable, next generation framework window manager for
Closes: 614531
Changes: 
 awesome (3.4.9-1.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * Patch CMakeList to build successfully. (Closes: #614531)
Checksums-Sha1: 
 ee15bad45147dbcd09a190f21dc7450ab3b67c1a 2320 awesome_3.4.9-1.1.dsc
 abcbb58f176254237b3b0a21dcafbd0ac8ab40c8 8406 awesome_3.4.9-1.1.debian.tar.gz
 1f40aed6eb420486e4562bf9eb67c4d3f752a277 836892 awesome_3.4.9-1.1_i386.deb
Checksums-Sha256: 
 bb1bb1d59caeabf751a8bee48391c3c31b43174addeae1071933114aa0bb37f0 2320 
awesome_3.4.9-1.1.dsc
 374c93212b727e38ca10b2d6dfd69a7e04917c1c18e023f5d1a3ad7be3b9e39d 8406 
awesome_3.4.9-1.1.debian.tar.gz
 81f73af55161eff2003a2d055167da3535fc5d71d41b4633c3dc5e2a10d34570 836892 
awesome_3.4.9-1.1_i386.deb
Files: 
 6196272a61b01a64d4101dca087f1184 2320 x11 optional awesome_3.4.9-1.1.dsc
 8deabcf3c4accb3d5079f08b0aa0dc5d 8406 x11 optional 
awesome_3.4.9-1.1.debian.tar.gz
 db1640b98deac9c6e541cdfa816385e2 836892 x11 optional awesome_3.4.9-1.1_i386.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCgAGBQJNvYCzAAoJEPgLgUbQQog2ZucP/066XP3qqAm5ed+VfeWUzC55
YLXk9nVacwOy9zJURr7b7E9NWspD7b3b7X1lw5ixMRInUgmAY4jc959c+glWw4Pw
D7JqwCR+COAZMOf9peEVhPuwmE79sfhtzOa8GyCJDYSOAgINqgi5t6414Hm4KcMp
pbwLR5MrIOCnMD0aO4lHAl6JS42hUQMylCfKrQ7G72muDWwBqmUGxAGhpq0I0eCb
C7d9VEHNI/1GCaCg7/gQQQPMBB0SoD/g61utyhz4Uap5Vp53QEAw47J1+ZHLzpWC
RuH5CEnVt/rnkOR59gfC48rkE7kNVqGK6FoF01SqjbqCuQhjLejFvuHEDlDlIj7W
ROMuOjZi+kpo9/PpEi+9tSefzFyUquQsO2yUnjUzG7r06tcBhMWa2HL/Qfx3vDrb
n++F/Kzdk0Qj1IZZKgeqQDpr7pvBdAeKVzA3TzLJ6yy19qID5Q/yhitl4Vb7gWXW
OxrI+CA4489Pty9cL9xGnfqd4hPsWZBdZH19Q9DLPvfgZuQi9VKh7oQ64NGw45VM
tsYi7AxSX891AZzkXseeON6CwRL8ZPVFx5Ptyf1Dm6YZSe0UqZSXtD5jmeOj9Bde
PeeMQDqWz7OESAwQn59rkZVw0MBFlySrfOhsogsFfDaz+BXL9OuuwaXO0hpGSJ71
FOC9M347ZUZp8+E06/5z
=vFY6
-END PGP SIGNATURE-


Accepted:
awesome_3.4.9-1.1.debian.tar.gz
  to main/a/awesome/awesome_3.4.9-1.1.debian.tar.gz
awesome_3.4.9-1.1.dsc
  to main/a/awesome/awesome_3.4.9-1.1.dsc
awesome_3.4.9-1.1_i386.deb
  to main/a/awesome/awesome_3.4.9-1.1_i386.deb


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1qhihg-0001rp...@franck.debian.org