Package name of src:fontmake
Hi, We at Fonts Team are packaging utilities for building fonts from Glyphs.app and UFO format to OTF/TTF, and we are trying to align our package to Python Policy. The packaging effort is in Salsa: https://salsa.debian.org/fonts-team/fontmake We feel unsettled of the binary package naming. Should it be: * "fontmake" single package * "python3-fontmake" single package * "fontmake" package for /usr/bin and "python3-fontmake" package elsewhere? My personal intepretation is that since this package is not used as python library this should be "fontmake" single package, but we need someone from Python Teams to confirm that. Yao Wei signature.asc Description: PGP signature
[Salsa] DPMT Join Request from @mwei
Hi, As stated in the bug #912656 (which the first email is also CC'd to this mailing list), I would like to join the DPMT team, for uploading python-fs package for py2 and py3. My Salsa handle is @mwei. Thanks, Yao Wei signature.asc Description: PGP signature
Re: Updating the Python Modules *Team* policy
Hi, I am proposing another merge request: https://salsa.debian.org/python-team/tools/python-modules/merge_requests/2 Prominent changes are follows: * Change git repo from Alioth to Salsa * Suggests to use git-buildpackage and quilt format instead of git-dpm - Some unrelevant paragraphs on git-dpm are also removed * Changes strong discourgement of deviating from the policy since we are doing so recently. On Thu, Nov 08, 2018 at 08:42:13AM -0500, Chris Lamb wrote: > > I feel the consensus is that that PR should just get merged and that the > > DPMT > > policy can just be updated by team consensus on this list. Consider this a > > heads up that I'll merge this in the next few days, unless there's any issue > > people can come up with. > > Great idea. > > Indeed, lets just get this merged (why wait?) so we don't confuse > or even scare away potential contributors with outdated docs. We > can always continue to iterate on it or even revert parts of it, > after all. Thanks, Yao Wei signature.asc Description: PGP signature
Re: Updating the Python Modules *Team* policy
Hi, My merge request already incorporates what Nicolas proposed, So, I think that would mean both "replacing" and "in addition to" since my changeset is a superset to the previous one. The other changes are listed in my previous email. On Thu, Nov 08, 2018 at 10:45:15AM -0500, Chris Lamb wrote: > > I am proposing another merge request: > > > > https://salsa.debian.org/python-team/tools/python-modules/merge_requests/2 > > Another in the sense of "replacing" or "in addition to" the one > Nicolas already proposed we merge? > > (If the former, how is it superior?) Yao Wei signature.asc Description: PGP signature
Re: [Salsa] DPMT Join Request from @mwei
Hi, I read the policy, but I found several questions about it. 1. We are now using Salsa but the policy remains in Alioth. 2. We are probably not preferring using git-dpm but gbp + quilt right now. (not sure about this though: I was doing git-dpm in a Python package maintained outside Python teams but another DD told me that I should use gbp + quilt) Other than these two I have no problem about the rest of the policy. Yao Wei (This email is sent from a phone; sorry for HTML email if it happens.) > On Nov 8, 2018, at 18:45, Ondrej Novy wrote: > did you read our policy > (https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst) > and do you accept it?
Re: Plan for DebCamp
> On Jul 13, 2019, at 18:18, Emmanuel Arias wrote: > > Exist any plan for debian packaging during the DebCamp/DebConf? Hi, I am going to package font building related packages, and also seeking help from uploading DDs in DPMT to sponsor upload. Also I am going to prepare for that talk in DebConf! Yao Wei (is non-uploading DD atm) (This email is sent from a phone; sorry for HTML email if it happens.)
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
> On Nov 29, 2019, at 01:28, Simon McVittie wrote: > > Is there consensus that the top-level module name is what matters, and not > following the recommendation is a bug? > https://www.debian.org/doc/packaging-manuals/python-policy/module_packages.html > says "The binary package for module foo should preferably be named > python3-foo, if the module name allows" and "import foo should import > the module", which suggests that it is indeed the name of the top-level > importable module, and not the name of the egg, that matters (which would > imply that -dbus and -gi are correct, and -pypubsub is not). If the module name has upper case in it, it would actually break Policy §5.6.1 For example one of my package has module name fontParts, and if folllowing Python policy, the name would be python3-fontParts, and it would be a policy violation. So it has to be using all lower-case name, therefore running tests generated by autopkgtest fails. I have to generate the testing script manually and modify accordingly. Yao Wei (This email is sent from a phone; sorry for HTML email if it happens.)
