Bug#1055043: Debian carnivore: port from Python 2 to 3
Package: qa.debian.org Severity: serious User: qa.debian@packages.debian.org Usertags: carnivore X-Debbugs-CC: m...@qa.debian.org, debian-python@lists.debian.org The carnivore system which tracks the activity of Debian members is written in Python 2, which has been removed from Debian, so carnivore needs porting to Python 3 and volunteers are needed to work on that. https://salsa.debian.org/qa/qa/-/tree/master/carnivore/ https://salsa.debian.org/qa/qa/-/blob/master/data/cronjobs/carnivore https://salsa.debian.org/qa/qa/-/blob/data/cronjobs/ddpo.carnivore https://salsa.debian.org/qa/qa/-/blob/data/ddpo/extract_carnivore.pl -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: How to realize different test categories?
On Fri, 2023-07-28 at 12:14 +, Christian Buhtz wrote: > I realized that most of the tests in my test suite are integration or > system tests which are impossible to handle by Debians build server and > testing system (how do you name it?). These sorts of tests are suitable for autopkgtests run on debci: https://wiki.debian.org/ContinuousIntegration So you can tag your tests as suitable for build time or not suitable for build time, and then run build time tests on buildds and others on the debci service using autopkgtests. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1029808: lintian: warnings related to *.pyc *.pyo __pycache__/
Package: lintian Version: 2.116.1 Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org The *.pyc *.pyo files are Python bytecode and are almost always generated from Python source code. Since Python 3 these are usually stored in a __pycache__/ directory. Since these files are not source code, they should not be present in the Debian source packages, but there are hundreds of them in Debian: $ apt-file -I dsc search --regex '\.py[co]$' | wc -l 507 Please complain on *.pyc *.pyo being present in Debian source packages. Please also check that when they are present, that they have a *.py source file present. When it is in the same directory it will have the same name but .py extension. When the generated files are in a __pycache__/ directory then *.pyc file name will contain .cpython-NN but the *.py source file will not. Please also complain about other files in __pycache__/ directories. Since these dirs are caches and caches are often ignored by various tools, the other files could get lost from backups, VCS repos, etc. $ apt-file -I dsc search __pycache__/ | grep -vF .cpython- ack: /t/swamp/__pycache__/notes.pl asciidoc: /tests/__test_data__/plugin/backends/__pycache__/.gitkeep mypy-protobuf: /test/generated/testproto/__pycache__/__init__.py mypy-protobuf: /test/generated/testproto/dot/com/__pycache__/__init__.py -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: How to create multi-source tarball with different submodules for scipy
On Mon, 2023-01-16 at 17:05 +0100, Andreas Tille wrote: > I intended to merge all these submodules in a single > scipy_1.10.0.orig-submodules.tar.gz. Any reason not to use one tarball per submodule? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: pyyaml 6
On Fri, 2022-10-07 at 00:10 +0200, Gordon Ball wrote: > * Upload to unstable and see what breaks? The experimental pseudo-excuses already say several packages break: https://qa.debian.org/excuses.php?experimental=1=pyyaml autopkgtest for ganeti/3.0.2-1: amd64: Regression, arm64: Regression autopkgtest for llvm-toolchain-13/1:13.0.1-7: amd64: Pass, arm64: Regression autopkgtest for satpy/0.37.1-1: amd64: Regression, arm64: Regression autopkgtest for spades/3.15.5+dfsg-1: amd64: Regression So at least these issues need to be investigated and maybe bugs filed. > * Request an archive rebuild with this version and see what breaks? Definitely. > * File bugs against all likely affected packages with a fixed date for > an upload? Definitely. I don't know if any packages in Debian have versioned dependencies on pyyaml, but if they do then it might be worth filing a transition bug. Probably also a good idea to do that anyway too. https://wiki.debian.org/Teams/ReleaseTeam/Transitions There might also be Debian services broken by pyyaml 6, but they can be dealt with during the upgrade of the debian.org machines to bookworm. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Are YOU interested in a potential remote sprint sometime in October/November? (yes YOU!)
On Fri, 2022-08-19 at 09:29 -0300, Emmanuel Arias wrote: > I'm just curious, we know or it's easy to know if there're more parts > of the Debian infrastructure where Python is used and we can help? Others have already answered this, but I wanted to point out these lists of Debian services and their codebases/contacts etc. https://wiki.debian.org/Services https://wiki.debian.org/DebianNetDomains -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: pybuild-autopkgtest (was: Notes from the DC22 Python Team BoF)
On Tue, 2022-07-26 at 17:53 -0300, Antonio Terceiro wrote: > Well the idea is to only actually commit the change and upload the > package with the new Testsuite value after ensuring that actually works, > i.e. that the autopkgtest passes. This sounds like something for lintian and the Janitor. I suggest lintian because not all Python packages are in the team and I suggest the Janitor because it makes changes automatically, although I am not entirely sure if it runs autopkgtests yet? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Versioneer [was Re: a review of your bumblebee-status package]
On Tue, 2022-06-07 at 16:12 +0200, Timo Röhling wrote: > Versioneer is meant to simplify version tracking for the developer; > it supports a number of authoritative sources such as "git > describe" to determine the current version number. There are two > modes of operation: > > - in developer mode, versioneer detects the version number > dynamically. This is what you'll see if you use the (Git) > repository sources. > - in install mode, the release version number is statically > embedded. This is what you'll see if > you download from PyPI. > > Internally, these modes are realized by two different _version.py > files; the developer version is usually added to version control, > and the setuptools "build" and "sdist" steps are > intercepted to insert the static _version.py as needed. Personally I would not use the _version.py file from PyPI. Sounds like the more correct thing to do is clone the GitHub repo, check out the tag that Debian will use, run the build step, save the generated _version.py file, add a patch containing that _version.py to the Debian source package and generate an orig.tar from `git archive`. Alternatively, upstream could switch from versioneer to flit-scm or setuptools-scm, which both allow reporting the version number through an environment variable, which IIRC pybuild does automatically. Upstream should really drop the vendored versioneer either way though. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Updating pytest
On Fri, 2022-06-03 at 19:08 +0100, Julian Gilbey wrote: > I believe that ci.debian.net checks packages against packages in > experimental (see > https://ci.debian.net/packages/s/spyder/unstable/amd64/ for example), > so it may be that the work is already done for us; what I don't know, > though, is how to extract this information for the package in > experimental. Perhaps worth asking the debian-ci people. I think this page includes debci results for experimental: https://release.debian.org/britney/pseudo-excuses-experimental.html It shows what would happen when migrating experimental to unstable. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Update packages to recent version
On Thu, 2022-01-13 at 21:25 +0100, Mechtilde Stehmann wrote: > Are there any hints to upload newer versions? There are some hints about this on the team git policy page: https://wiki.debian.org/Python/GitPackaging Probably some other wiki pages are helpful too. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: [RFS] RadioTray
On Mon, 2022-01-10 at 20:57 +0100, Matthias wrote: > Should this also be done, although the radiotray package is still removed? Wait until after the package is accepted or at least in NEW. https://ftp-master.debian.org/new.html -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1003376: ITP: python-circuitbreaker -- Python "Circuit Breaker" implementation
Package: wnpp Severity: wishlist Owner: Paul Wise X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org Control: block 1003372 by -1 * Package name: python-circuitbreaker Version : 1.3.2 Upstream Author : Fabian Fuelling * URL : https://github.com/fabfuel/circuitbreaker * License : BSD Programming Lang: Python Description : Python "Circuit Breaker" implementation This is needed by oci-python-sdk (#1003372). The package will be maintained within the Python team. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: [RFS] RadioTray
On Tue, 2021-12-28 at 18:37 +0100, Matthias wrote: > but it would be great, if RadioTray will get back into the official > Debian repository. Please note the extra steps required when reintroducing packages: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs > Is here someone, who is willing to sponsor RadioTray? If you don't get a response here, filing an RFS can sometimes work: https://mentors.debian.net/sponsors/rfs-howto/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: psycopg3 packaging: need new version of cython3 (and psycopg2)
On Fri, Oct 1, 2021 at 7:05 PM Tomasz Rybak wrote: > Should I upload 3.0.alpha9 to unstable (maybe blocking transition > to testing), and later try to fix most of its problems, uploading > psycopg3 to unstable shortly after? > Or should I first upload 3.0.alpha9 to experimetnal, trying to fix > most of issues there, and upload to sid only when it reaches 3.0.final? > This is important package, so I'd like to get some opinions before > proceeding. And also - what should we do with cython (not cython3), > in our quest to migrate from Python2? Since Cython has many reverse dependencies and this sounds like a major upgrade of Cython, this sounds like a transition I would definitely stage the transition in experimental and do a test rebuild of all reverse dependencies using the ratt too. Doing this in experimental also allows you to see autopkgtest results for packages in testing but using the Cython from experimental. https://wiki.debian.org/Teams/ReleaseTeam/Transitions https://release.debian.org/transitions/ https://release.debian.org/britney/pseudo-excuses-experimental.html > On similar topic - should I upload newest version of psycopg2 > (removing *dbg package at the same time)? Debian has 2.8.6 while > latest upstream is 2.9.1. It's less invasive change than in case > of cython, but I'd still like to get some opinions, or at least > acknowledgement. The same as above probably applies for psycopg2. -- bye, pabs https://wiki.debian.org/PaulWise
Re: feedparser: New packaging
On Thu, Sep 9, 2021 at 1:01 PM Christian Buhtz wrote: > "maintainer" is the "Debian Python Team". So is this list the right > place to contact that team? Correct. > First, I want to be sure not stealing work from someone. Is there an > active maintainer on the Debian side for the package "feedparser"? As you can see from the upload history, the package is team maintained with different people doing most of the uploads and people not in the Uploaders field even doing new upstream releases. > Second, I am aware that I need an "uploader" because I do not have (and > do not want to) have write access to the repository. However, this is a > far away problem because the package itself needs to get done first. ;) The term we use for this is sponsor. IIRC for the Python team this means making changes in the git repository on salsa (see the Vcs-* fields) and then adding the package needing sponsorship to the topic of the #debian-python IRC channel on OFTC. If you aren't yet in the Python team on salsa you can submit merge requests in the meantime, and there is a page about how to join on the wiki. https://wiki.debian.org/Glossary#sponsor https://wiki.debian.org/Teams/PythonTeam https://wiki.debian.org/IRC https://wiki.debian.org/Teams/PythonTeam/HowToJoin > Third (and most important), I need someone like a mentor. Whom can I ask > when I have background questions that are not mentioned in the wiki or > if I have technical problems? I need someone take my hand and someone to > kick my butt when I need it. ;) In general Debian does not have mentors, instead we ask people with questions to ask them in public on the mailing lists or IRC channels, this way whoever sees the question first can respond and others can learn from the question and answer too. Apart from the usual support channels for questions about using Debian, debian-mentors list/channel is a good place to ask packaging questions and for more Python specific things the debian-python list/channel might be a better option. > I am sure it is helpful to introduce myself to the community. Which > place would be the best for it? The Debian Python Mailinglist or > anywhere else? Or a link to a Debian Wiki Entry? Definitely, both of those options seem reasonable. -- bye, pabs https://wiki.debian.org/PaulWise
Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
On Fri, Jun 25, 2021 at 11:42 PM Jeremy Stanley wrote: > 1. Cryptographically signed tags in a Git repository, with >versioning, revision history, release notes and authorship either >embedded within or tied to the Git metadata. > > 2. Cryptographically signed tarballs of the file tree corresponding >to a tag in the Git repository, with versioning, revision >history, release notes and authorship extracted into files >included directly within the tarball. I would like to see #2 split into two separate tarballs, one for the exact copy of the git tree and one containing the data about the other tarball. Then use dpkg-source v3 secondary tarballs to add the data about the git repo to the Debian source package. > Saying that a raw dump of the file content from a revision control > system is recommended over using upstream's sdists presumes all > upstreams are the same. They're not, and which is preferable (or > doable, or even legal) differs from one to another. Just because > some sdists, or even many, are not suitable as a basis for packaging > doesn't mean that sdists are a bad idea to base packages on. Yes, > basing packages on bad sdists is bad, it's hard to disagree with > that. Probably we should start systematically comparing upstream VCS repos with upstream sdists and reacting to the differences. So far, I've reacted by ignoring the sdists completely. -- bye, pabs https://wiki.debian.org/PaulWise
Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
On Fri, Jun 25, 2021 at 9:17 PM Jeremy Stanley wrote: > The proposal is somewhat akin to saying that a > tarball created via `make dist` is unsuitable for packaging. This is definitely true; they generally contain generated files (configure, Makefile.in) and embedded code copies (missing install-sh depcomp config.sub config.guess etc), neither of which should be part of the "source". -- bye, pabs https://wiki.debian.org/PaulWise
Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs
On Fri, Jun 25, 2021 at 8:49 PM Nicholas D Steeves wrote: > I feel like there is probably consensus against the use of PyPi-provided > upstream source tarballs in preference for what will usually be a GitHub > release tarball I think this should be a Debian-wide default and documented in Debian Policy. I plan to bring this up more widely after the bullseye release. -- bye, pabs https://wiki.debian.org/PaulWise
Re: RFS: colorzero/2.0-1 [ITP] -- Construct, convert, and manipulate colors in a Pythonic manner.
On Sat, Jun 19, 2021 at 9:06 PM Thomas Goirand wrote: > That's a way more simple, as sometimes, upstream ships an egg-info and > building *modifies* it (and then, nightmare starts...). Usually upstream doesn't ship egg-info in the source repository though, I think I would switch from PyPI tarballs containing egg-info to upstream source repos not containing egg-info and other generated files. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Build an initial Debian source package with py2dsp from a GitHub project
On Wed, May 5, 2021 at 10:14 PM Sandro Tosi wrote: > this solution also underestimates the in-progress migration towards > poetry and pyproject.toml, where `python3 setup.py sdist` is not > available. Where does the metadata come from for projects using these things? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Build an initial Debian source package with py2dsp from a GitHub project
On Wed, May 5, 2021 at 7:50 PM Andrey Rahmatullin wrote: > But Github doesn't provide the metadata. Usually the metadata is available in setup.cfg (or possibly setup.py), both of which should be in GitHub, although data in setup.py would be harder to extract. -- bye, pabs https://wiki.debian.org/PaulWise
Re: How can I override module name in autopkgtest-pkg-python
On Wed, Mar 3, 2021 at 8:12 PM Andreas Tille wrote: > I worked on the package python-cython-blis[1] FYI, upstream is very hostile towards having their software in Debian so I suggest you cease packaging this and anything that depends on it: https://github.com/explosion/cython-blis/issues/32 The developers reference mentions that packaging software with hostile upstream developers is often not a good idea. https://www.debian.org/doc/manuals/developers-reference/developer-duties.en.html#coordination-with-upstream-developers "If you find that the upstream developers are or become hostile towards Debian or the free software community, you may want to re-consider the need to include the software in Debian. Sometimes the social cost to the Debian community is not worth the benefits the software may bring." -- bye, pabs https://wiki.debian.org/PaulWise
Re: Python louvain packages naming confusion.
On Tue, Feb 9, 2021 at 10:21 PM Diane Trout wrote: > The fairly popular (in the world of bioinformatics) ScanPy package uses > a Python version of the louvain clustering algorithm implemented by: ... > However currently in the Debian archive there's a different louvain > package I think this is something that the two upstream projects should discuss and come to an agreement on the right outcome, since the current set of names is confusing and overlapping. Perhaps the two projects will end up getting merged into one project, or one of them deprecated or one or both of them renamed. > I was wondering if the python3-louvain's binary package should be > renamed to python3-community to match the python package name, and then > the other louvain-igraph package could provide a bin package named > python3-louvain which would match the package name. There are no reverse dependencies in Debian, but this is going to be tricky for users who previously installed python3-louvain.deb from python-louvain upstream and then after upgrading they suddenly get python3-louvain.deb from louvain-igraph with presumably an incompatible API etc. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Ressurrecting freevial as the new upstream
On Mon, Feb 8, 2021 at 11:45 PM Alex Muntada wrote: > Yes, but I tried debhelper-compat 13 and dh, which failed most > probably due to --fail-missing. That seems like there are some things missing from debian/*.install. > Thanks for the pointer, I was aware of several archived bugs in > freevial but didn't know or remember that the security tracker > was also affected by removals from unstable. It seems that freevial had no reported security issues before, so it looks like you can ignore that item. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Ressurrecting freevial as the new upstream
On Fri, Feb 5, 2021 at 5:42 PM Alex Muntada wrote: > also trying to build the package myself but I've never packaged a > Python program before and it doesn't build successfully so far. Did you start from the previously existing packaging? That is what is usually done when reintroducing packages: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs -- bye, pabs https://wiki.debian.org/PaulWise
Re: Generic Python packages which don’t work on all architectures
On Thu, Jan 21, 2021 at 11:30 PM Paul Wise wrote: > there is probably some coverage of arch:all packages on debci, not > sure if it tests them on multiple arches though. FTR, #debci says arch:all packages get tested on all debci arches. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Generic Python packages which don’t work on all architectures
On Thu, Jan 21, 2021 at 3:42 PM Ole Streicher wrote: > But this is also the case for all packages which implicitly depend on > other packages which are not available on some architectures. This is true, but it doesn't make for a good user experience. > Generally, arch:all packages depend on a lot of architecture dependent > packages, and unless one resolves the whole dependency chain, there is > no way to check whether a package is actually installable. The buildds have installability checking for build-deps (IIRC using dose), so some sort of QA service could be doing these sort of checks more cheaply than installing arch:all packages outside of amd64. Also unfortunately piuparts.d.o doesn't yet support multiple arches, but there is probably some coverage of arch:all packages on debci, not sure if it tests them on multiple arches though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Generic Python packages which don’t work on all architectures
On Thu, Jan 21, 2021 at 1:12 PM Ole Streicher wrote: > This would be a quite flexible and extendible approach to have packages > installable only where they work. There is precedent for this sort of thing in the isa-support source package, which fails installation when your CPU doesn't support particular ISA extensions like SSE or NEON. It is a reasonable workaround for now, but the packages using the pseudo-packages would still be available, causing confusion when people try to install them. It would be better to just not have them available where they aren't going to work. I also wonder how multi-arch stuff would interact with the pseudo-packages idea. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Generic Python packages which don’t work on all architectures
On Wed, Jan 20, 2021 at 7:40 PM Stephen Kitt wrote: > I’ve come across a situation which doesn’t seem to be addressed by existing > policies: the python-ptrace source package only ships > architecture-independent content, but it works on a small number of > architectures (currently, 32/64-bit x86, 32-bit ARM, 32/64-bit PPC). The iotop package is in a similar situation, it uses Linux kernel APIs so does not work on Hurd or kFreeBSD. > As a result, the packages it builds are installable everywhere, but that’s a > false promise since they don’t work everywhere. Would it make sense to > convert it to an architecture-dependent package, only on those architectures > which are really supported? This is what I eventually chose for iotop. At the time I wanted dpkg and dak to support something like Architecture: linux-all, which would build arch: all packages, but only put them in the Packages files for the Linux architectures. I am now thinking that a more generic solution than Architecture: linux-all is needed, in order to cover your case as well. Perhaps something like Available-Architecures or Runtime-Architectures or Architecture-all-Architectures: or similar. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Looking to help
On Tue, Jan 19, 2021 at 7:35 AM Perry Aganad wrote: > I have been using debian for a while now and I am a point where I want > to help and start contributing to debian itself. I read the web page > about contributing and I took away that I should just jump right in, and > I specifically jumped here because I do know how write python scripts. I > am new at this but I'm a quick learner so please let me know if I can > help out in anyway, thanks!. As well as maintaining Python packages, lots of Debian services are written in Python: https://wiki.debian.org/Services and there are other ways to help besides Python packaging/coding: https://www.debian.org/intro/help https://wiki.debian.org/how-can-i-help -- bye, pabs https://wiki.debian.org/PaulWise
Re: Looking for a Sponsor - Papereshaper
On Wed, Dec 30, 2020 at 4:50 PM Devops PK Carlisle LLC wrote: > The git is here: https://github.com/pkcarlislellc/git-papershaper I don't intend to package nor sponsor this, but here is a review: Drop git- from the name of the GitHub repository. Add a git repository to the SourceForge project also and push to both repos. Remove the possibly non-free and or non-redistributable images in the git repository. If they are actually redistributable and freely licensed, please document the location where they were obtained from, their copyright owner and license. If they are non-redistributable then you will need to rewrite the history of the git repository to exclude them. Merge the two scripts into one supporting both versions of Python (or just drop the Python 2 one). IIRC you can use the print function in Python 2 by adding the line below. After that the remaining changes don't look necessary, or can be made conditional with sys.version_info. from future import print_function The first thing in the README.md should be a one-sentence description of what the program does. Drop the Google Code mention/link from the README.md. The README.md mentions that webcamgrab.txt was taken from another program, but doesn't mention the copyright/license information for the file anywhere. While the SourceForge project for the other program says GPLv3, the tarball containing the list of webcams doesn't mention any license. Change the GPL reference at the start of the README.md to mention which versions. The list of webcams is liable to get out of date, especially when shipped with the script, it might be a good idea to have continuous monitoring of the list, plus a way to auto-update it on end-user systems. Consider switching to the XDG standard for some of the paths: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://wiki.archlinux.org/index.php/XDG_Base_Directory https://github.com/srstevenson/xdg When I run check-all-the-things in the source tree, a number of the checks produce output that is worth reviewing. https://github.com/collab-qa/check-all-the-things/ grep -ri gimp codespell doc8 grep -r http: proselint spellintian pycodestyle pyflakes pylint vulture -- bye, pabs https://wiki.debian.org/PaulWise
Re: How to watch pypi.org
On Sat, Oct 31, 2020 at 2:31 AM Jeremy Stanley wrote: > I have to agree, though in the upstream projects with which I'm > involved, those generated files are basically a lossy re-encoding of > metadata from the Git repositories themselves: AUTHORS file > generated from committer headers, ChangeLog files from commit > subjects, version information from tag names, and so on. Some of > this information may be referenced from copyright licenses, so it's > important in those cases for package maintainers to generate it when > making their source packages if not using the sdist tarballs > published by the project. As the maintainer of the autorevision package (which aims at dumping a cache of VCS version metadata, for when exporting a tarball from a VCS), I've been thinking about this for a while now. I've been thinking about modifying automake (and other build tools) to have a mode that basically does `git archive` instead of just calling tar and also creates separate tarballs for all the other generated or embedded files. One for the autorevision metadata, one for the autotools cruft, one for a cache of the data needed for AUTHORS/ChangeLog/NEWS etc and possibly other ones. Then Debian can use our multi-component quilt 3.0 format to take the git archive, the autorevision metadata, and the cache of the VCS data, but leave the autotools cruft behind. Then we can audit the git repo for generated files and embedded data/code copies and when there are none, we can confidently build the configure script from source knowing that everything required is available in the build-deps. The same could apply to projects uploading to NPM or PyPi, although I'm not sure if those support this sort of thing though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: How to watch pypi.org
On Fri, Oct 30, 2020 at 2:19 PM Fioddor Superconcentrado wrote: > As I said I'm very new to this and all (python) packages I'm using lately use > the usual python tools (pipy, setup.py, etc) and my first approach has been > to stick as close as possible to the upstream procedures. But I might very > likely be taking a wrong decision. What are the reasons to go for git instead > of pypi? I see that it is 'more upstream' but it seems that everyone else is > pointing to pypi as a distro-agnostic solution. As Andrey says, missing files is one issue, another is that tarballs often contain extra generated files that should be built from source, but if you use the tarball then they quite likely will not be built from source. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Update PYTHONPATH after install
On Wed, Oct 7, 2020 at 5:56 PM Francis Murtagh wrote:
> My understanding of Debian policy means python3 modules should be installed
> in /usr/lib/python3/dist-packages/
Correct.
> Once the package installs there how is the PYTHONPATH meant to be updated so
> that user can import the module into the python3 interpreter?
This is not necessary...
> As the PYTHONPATH would normally look in /usr/local/ rather than /usr/lib/
... since the default import path includes /usr/lib:
$ unset PYTHONPATH
$ python3 -c 'import sys ; print("\n".join(sys.path))'
/usr/lib/python38.zip
/usr/lib/python3.8
/usr/lib/python3.8/lib-dynload
/usr/local/lib/python3.8/dist-packages
/usr/lib/python3/dist-packages
/usr/lib/python3.8/dist-packages
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: How to watch pypi.org
On Sun, Oct 4, 2020 at 3:29 PM Fioddor Superconcentrado wrote: > I've packaged a project provided via https://pipi.org and I wanted to create > a debian/watch file but pipi.org publishes the tarball behind a strange url > like I would suggest using the upstream git repo instead of the PyPi tarballs. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#970533: ITP: pytest-rerunfailures -- pytest plugin that re-runs failed tests up to -n times to eliminate flakey failures
Package: wnpp Severity: wishlist Owner: Paul Wise X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: pytest-rerunfailures Version : 9.1 Upstream Author : Leah Klearman and others * URL : https://github.com/pytest-dev/pytest-rerunfailures * License : MPL 2.0 Programming Lang: Python Description : pytest plugin that re-runs failed tests up to -n times to eliminate flakey failures This is a test dependency of gensim and it will be maintained in the Python team. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: packaging DiscoDOS - a cli tool for vinyl DJs
On Fri, 2020-05-15 at 19:56 -0700, Steve Langasek wrote: > FTR, UbuntuStudio is an official Ubuntu flavor, not a derivative ;) Woops. Did that change at some point or did I mix them up with another distro or just make a stupid mistake? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: packaging DiscoDOS - a cli tool for vinyl DJs
On Fri, May 15, 2020 at 4:56 PM Thomas Goirand wrote: > I really think it's a shame that people join Debian just because of > Ubuntu... :( FTR, Ubuntu Studio is not Ubuntu, it is an Ubuntu derivative. Would it be fair to say that your main objection is that Ubuntu has much higher popularity than Debian and so the Ubuntu policy to work upstream where possible leads people to come to Debian without necessarily caring about the Debian community or users but more about Ubuntu users? Personally, I think over the years Ubuntu's Debian involvement has been a net positive for Debian, both in terms of packaging and other technical changes and in terms of attracting new contributors, often Ubuntu migrants end up contributing to Debian more than Ubuntu. I think the same goes for derivatives in general. -- bye, pabs https://wiki.debian.org/PaulWise
Re: PEP-517/PEP-518 Support In Debian
On Sun, Apr 12, 2020 at 10:32 PM Scott Kitterman wrote: > I took a look at the presence of pyproject.toml files in the Debian archive. > There are currently 99 packages. Of those, only 28 specify a 'build-backend', > which is required by 517/518 to be useful for building a package. Is there a tool that can report problems in pyproject.toml files? Either way I think that lintian needs to detect this particular issue. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Where can I find packages that need a maintainer?
On Thu, Feb 13, 2020 at 1:25 AM Pablo Mestre wrote: > With the desire to continue contributing I would like to know where I > can find other packages that need a maintainer. The WNPP data (specifically RFA, O bugs) list packages needing a new maintainer: https://www.debian.org/devel/wnpp/ There are several options for querying this data: Install and run the how-can-i-help package: https://wiki.debian.org/how-can-i-help Use the wnpp-check/wnpp-alert scripts: https://manpages.debian.org/wnpp-check https://manpages.debian.org/wnpp-alert Use one of the websites that presents the WNPP data in different ways: https://wnpp.debian.net/ https://wnpp-by-tags.debian.net/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Where can I find packages that need a maintainer?
On Thu, Feb 13, 2020 at 1:25 AM Pablo Mestre wrote: > I recently started as a maintainer of a package for Debian which is > currently awaiting approval to be reintroduced into the repositories. [1] In case you weren't aware, there are some extra steps when reintroducing packages: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs Principally this is about reopening bugs closed by the removal and then triaging them and closing any fixed in the new version. https://www.debian.org/Bugs/Developer#closing Last time I needed to do this, I ran this hacky shell one-liner: bts $(for bug in $(curl 'https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=colortest-python' | pandoc -f html -t plain --wrap none | grep -B1 -F +rm | grep -o \#[0-9]\\+ | tr -d \#) ; do echo -n "unarchive $bug , reopen $bug , "; done) For your package it gives this command: bts unarchive 753281 , reopen 753281 , unarchive 936320 , reopen 936320 , unarchive 782208 , reopen 782208 , unarchive 890074 , reopen 890074 , See-also this request for making it easier to do this: https://bugs.debian.org/949125 -- bye, pabs https://wiki.debian.org/PaulWise
Re: would anybody be interested in maintaining feed2toot ?
On Tue, Nov 19, 2019 at 8:03 PM shirish शिरीष wrote: > I recently discovered feed2toot. It basically maintains a bot which > can help in re-directing traffic from blog, vlogs, youtube etc. to > fediverse. In a way it's a content re-director. It basically takes an > RSS feed and re-directs it any of the mastodon social networks. Sounds like something that should get added to feed2exec. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Python module packages that don't bytecompile on installation?
On Sat, Nov 2, 2019 at 6:04 PM Matthias Klose wrote: > At this point I'd ignore any Python2 related package, and concentrate on > Python3 > stuff only. Yes, I was referring only to python3-* module packages. > Byte compilation is an optimization, speeding up a program start if > byte-compiled files are ready. Packages are smaller without bc, take a bit > longer to install. I think nobody is asking the question if .py files should > be > dropped in favor of .pyc files. As I understand it, the .pyc files are interpreter version specific and doing a transition for each major Python update was deemed to be too much work, so instead we offload building the .pyc files onto user's systems. > I'd say, there are currently more pressing issues than that, like the Python2 > removal, or the introduction of Python 3.8. 3.8 also offers a central > directory > for bc files, so that's maybe another thing to look at, but not a priority now > from my point of view. Agreed re Python 2 etc. Eventually switching to using a central directory in /var would be nice, right now the .pyc files are dumped cruftily into /usr subdirs. -- bye, pabs https://wiki.debian.org/PaulWise https://bonedaddy.net/pabs3/
Python module packages that don't bytecompile on installation?
Hi all, I run adequate on my system, which means I notice when Python module packages don't bytecompile when they are installed. So far I've just been ignoring the warnings that adequate prints. https://salsa.debian.org/debian/adequate In addition I noticed: * some Python modules on my system weren't bytecompiled but did bytecompile when I reinstalled them (blinker for example) * many of the Python modules on my system don't bytecompile their test directories (django for example) * relatively few packages I have installed don't bytecompile when I ignore test paths (lib2to3, tk, uno, distutils) Some questions: Should all module packages bytecompile? Should all module packages bytecompile all their directories? What are the downsides when module packages don't bytecompile? What are the downsides when module packages do bytecompile? Do we need a lintian complaint about this issue? Do we need any improvements in how module packages bytecompile? For example using triggers instead of postinst scriptlets. Any other thoughts? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Re: Bug#920127: Removed package(s) from unstable
On Mon, Sep 9, 2019 at 4:11 AM Scott Kitterman wrote: > This was sent to the FTP Team, but it seems like someone with some bandwidth > to assist from DPMT/PAPT would be a better audience. Note that the removal's > already been done, but if someone wants to sponsor a python3 update to the > package, they can ping me for a quick trip through New to bring it back. It seems like a little bit more due diligence is needed before filing removals. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Looking for projects to work on
On Sun, Jun 9, 2019 at 11:54 PM Manas Kashyap wrote: > I have been looking on any issue or currently in progress project to work on > , with a little mentoring i think i can finish the project and also help in > maintaining it . If you have some experience with Python & Django, there is always work to do on the Debian package tracker. There are bugs and feature requests tagged as suitable for newcomers and most of the features not tagged that way don't need large amounts of code to complete. The contributing documentation is quite comprehensive: https://tracker.debian.org/ https://qa.pages.debian.net/distro-tracker/contributing.html -- bye, pabs https://wiki.debian.org/PaulWise
Re: Future of pygame in Debian.
On Sat, Oct 13, 2018 at 9:36 AM peter green wrote: > The other two are testsuite failures on architectures where frankly I doubt > pygame has many users* ... > *Both are very expensive architectures driven by IBM. Raptor Computing sells (expensive but less than IBM) POWER9 desktops with GPUs so it is conceivable that someone might want to use pygame based games on ppc64el at some point. https://www.raptorcs.com/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Dask sourceless javascript passed by me.
On Sat, Jun 9, 2018 at 2:05 AM, Diane Trout wrote: > Using a screen shot is just to deal with our build from source rule and > to avoid a privacy leak from loading a remote resource. I believe that rule applies to all of Debian main, not just ELF binaries. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Dask sourceless javascript passed by me.
On Fri, Jun 8, 2018 at 5:59 AM, Diane Trout wrote: > How do I replace the .orig.tar.gz that I already uploaded? You will need a new upstream version, typically people use 0.1.2+dfsg1 (for DFSG issues) or 0.1.2+ds1 (for other repack reasons) in these sort of situations. > I was planning on replacing the plots with a screen shot until I have a > solution to actually build the plots from source. Screenshots are derivative works of the UI they are from, so theoretically you need to care about the source for screenshots too. In practice I guess everyone ignores this. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Dask sourceless javascript passed by me.
On Wed, Jun 6, 2018 at 12:30 PM, Diane Trout wrote: > I was planning on patching the references to the .html files out and > removing them in the debian/rules files. > > But is that enough? That doesn't fix the orig.tar.gz. I would suggest talking to upstream about fixing this properly (no prebuilt files or embedded code copies in the VCS and tarballs). -- bye, pabs https://wiki.debian.org/PaulWise
Re: RFS: mwic 0.7.5-1
On Sat, May 26, 2018 at 4:22 AM, Georg Faerber wrote: > Please review / sponsor mwic 0.7.5-1. Changes pushed to git [1], .dsc > available via [2]. The dh_clean arguments can be put in debian/clean to avoid an override. Why did you change the timestamp at the bottom of debian/changelog? I think you can remove the second instance of "to" in the short description. Please upload a screenshot of typical usage: https://screenshots.debian.net/package/mwic Please review and edit the debtags: https://debtags.debian.org/edit/mwic You might want to look at the build reproducibility results: https://tests.reproducible-builds.org/debian/rb-pkg/mwic.html -- bye, pabs https://wiki.debian.org/PaulWise
Re: setup.py sdist permissions
On Wed, Apr 4, 2018 at 6:09 AM, Brian May wrote: > * Shouldn't sdist be ignoring my umask considering it is generating > packages for public consumption? IMO sdist should be deterministic in the reproducible builds sense: https://reproducible-builds.org/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: RFS: mwic 0.7.4-1
On Wed, Mar 21, 2018 at 8:43 PM, Paul Wise wrote: > I'll take a look, probably on Friday. Uploaded to NEW, thanks for your contribution. If you are so inclined, I would appreciated a commit (or patch) adding mwic support to check-all-the-things: https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/english.ini https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/doc/README -- bye, pabs https://wiki.debian.org/PaulWise
Re: apt.Cache.update with alternative sources.list
On Thu, Mar 22, 2018 at 6:12 AM, Ole Streicher wrote: > I need some access (as normal user) to an apt cache with an alternative > sources.list (those in /etc/blends/ installed by blends-dev), but I have > problems to find out how to use it. If you want to completely isolate apt from the system configuration for apt, the correct way to do that is to set the APT_CONFIG environment variable. See apt.conf(5), APT_CONFIG is the first mechanism used for setting the apt config and /etc is the second place apt looks for configuration. If you do not want to override every item (including hooks/etc) in every file in /etc/apt/apt.conf.d then you need to use APT_CONFIG. Examples of how to do this include chdist (from devscripts), apt-venv or the derivatives census codebase. -- bye, pabs https://wiki.debian.org/PaulWise
Re: RFS: mwic 0.7.4-1
On Wed, Mar 21, 2018 at 6:02 PM, Georg Faerber wrote: > To put it differently, especially regarding this upstream metadata > check: If someone opens a bug against lintian to add a new check, does > "this new check" needs to be backed up by some general consensus within > the project? Is there some "formal process" around this, besides opening > a new bug? Just the new bug and the judgement of the lintian maintainers. > Changes pushed to git, package on m.d.n updated. I'll take a look, probably on Friday. -- bye, pabs https://wiki.debian.org/PaulWise
Re: RFS: mwic 0.7.4-1
On Wed, Mar 21, 2018 at 1:11 AM, Georg Faerber wrote: > Thanks a lot for your review, and sorry for not responding earlier, too > much stuff on my table: There is no need to apologise for being busy :) > On 18-03-18 11:33:59, Paul Wise wrote: >> The copyright years are missing 2012, I'm not sure if the ftp-masters >> would reject the package on that basis. > > I've referred to the upstream git history, instead of the licence file. > Fixed. I found the missing copyright year in one of the test files, not the license file. >> doc/mwic.1 and tests/coverage are generated files, they should be >> removed from the upstream VCS and tarballs and be always built from >> source. If upstream refuses, you should remove them in `debian/rules >> clean` and very early in `debian/rules build` so that the package will >> never depend on the existing upstream files. > > I've searched quite a bit on the Internets how to do this, and leverage, > for now, dh_clean. I hope that this is an acceptable method for this, I > didn't found any "official" source. I'll approach upstream regarding > these files. It needs to be done in both debian/rules clean and build, otherwise building the package without the clean step will use the prebuilt file. dh_clean is fine for the first one, but you need to override dh_auto_configure or dh_auto_build for the second one. > Also, the man page is now generated during dh_auto_install. I've added a > build dependency on python3-docutils for this. That is the wrong time to generate it, please change that to dh_auto_build. > After reading your mail I debugged this again: It's not about the top > level directory, at least if using gbp buildpackage, but about > 'export-dir'. Placing a symlink inside there which points to the actual > signature makes this work! :) ... > For now, I've wrote a wrapper script just for personal use, but I'll > work on [2] and [3] to get this implemented in a proper way. Great. > See above. (Personally, I really dislike the trailing comma.) The reason for the trailing comma option is that when you add a new item to the end of a list of dependencies, you don't also have to modify the line before it, making the diff easier to read, which is most of the point of the wrap-and-sort tool. > There is no man page currently, and also, more importantly, out of the > box this doesn't run in a non-interactive way. I guess, at least some > people, might run mwic via a CI pipeline, that's why I don't ship this. > I'll approach upstream regarding this. Fair enough. > I'm aware that this was recently added to lintian, and reading > the bug, again, makes me wonder what's the process of getting a new > check into lintian. The process for adding a check is to file a bug on lintian and wait a day, lamby is incredibly active on incoming lintian requests. > Correct. Still, my question stands: How do I enable autopkgtests for > this package? I haven't yet dealt with autopkgtests so I'm not sure. > The texts are the same, there are only differences in special chars like > ", so I guess this is a false positive. You may want to file a bug on license-reconcile about these false positives re Expat vs MIT/X11. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#891391: ITP: python-hsluv -- Python implementation of HSLuv (Human-friendly HSL)
On Tue, 2018-03-20 at 08:39 +0800, Yao Wei (魏銘廷) wrote: > In the screenshot provided in the issue the code seems to be pretty > different, so I am wondering that does it count as an > "reimplementation" of hsluv? To me it looks fairly similar and the changes seem mechanical, they could probably even be done with automatic Python AST modification. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#891391: ITP: python-hsluv -- Python implementation of HSLuv (Human-friendly HSL)
On Mon, Mar 19, 2018 at 10:04 PM, Yao Wei wrote: > [1]: https://github.com/hsluv/hsluv-python/blob/master/hsluv.py I quote from that file: """ This module is generated by transpiling Haxe into Python and cleaning the resulting code by hand, e.g. removing unused Haxe classes. To try it yourself, clone https://github.com/hsluv/hsluv and run: haxe -cp haxe/src hsluv.Hsluv -python hsluv.py """ If that is the case, then it could be possible to automate this conversion and drop the generated and then modified file from git. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#891391: ITP: python-hsluv -- Python implementation of HSLuv (Human-friendly HSL)
On Mon, Mar 19, 2018 at 10:04 PM, Yao Wei wrote: > I am having a situation that this code is said to be "transpiled" from > HSLuv written in Haxe [1], the code seems to be gone though a lot of > overhaul from the generated code that cannot be diffed. I believe the > code written in Python is preferred form of making modifications for > hsluv-python project. However, I need consensus on this mattter. I suggest you dig through the git history of both HSLuv and Python-HSLuv to develop an intuition about how the upstreams are developing both projects and then clarify the details of their development processes with upstream. Personally, I find the thought of modifying generated code to be horrible and would have either stuck with building from Haxe or reimplementing the code in Python. At the end of the day, what matters is that there is equality of access to the work between the upstream authors and users of Debian derivatives. i.e., make sure upstream aren't keeping something secret or using something proprietary and make sure Debian passes on what we receive from upstream. -- bye, pabs https://wiki.debian.org/PaulWise
Re: RFS: mwic 0.7.4-1
On Sat, Mar 17, 2018 at 5:49 PM, Georg Faerber wrote:
> Thanks a lot; sure, see [1].
These things block the upload:
The copyright years are missing 2012, I'm not sure if the ftp-masters
would reject the package on that basis.
I require these things to be fixed before I would sponsor the package:
doc/mwic.1 and tests/coverage are generated files, they should be
removed from the upstream VCS and tarballs and be always built from
source. If upstream refuses, you should remove them in `debian/rules
clean` and very early in `debian/rules build` so that the package will
never depend on the existing upstream files.
Some things that you may want to improve at some point:
Please include the upstream signature in the source package. uscan
does the right thing these days, or you can rename it to
mwic_0.7.4.orig.tar.gz.asc and place it alongside the orig.tar.gz file
and rebuild the source package.
I like to wrap each of the fields in debian/watch on new lines.
I like to use these wrap-and-sort parameters:
wrap-and-sort --short-indent --wrap-always --sort-binary-packages
--trailing-comma
misc/mwic4po seems like it would be worth installing in the package?
Please add some upstream metadata:
https://wiki.debian.org/UpstreamMetadata
Output from automated checks is available at the very end of this email.
> Could you move the repo as well, or create a new one within the Python
> team?
I'll leave that to someone who knows how to do that, I haven't dealt
with salsa yet.
> Yeah, I've used this as well, but in this case it's not that helpful as
> it finds the code defining the error [2].
I'd guess this is the source of the line you quoted:
https://sources.debian.org/src/autopkgtest/5.1/runner/autopkgtest/?hl=144#L138
lintian
X: mwic source: upstream-metadata-file-is-missing
check-all-the-things
$ env PERL5OPT=-m-lib=. cme check dpkg
...
Warning in 'control source Build-Depends:0' value 'debhelper (>=
11~)': should be (>= 11) not (>= 11~) because compat is 11
Warning in 'control source Build-Depends:1' value 'python3 (>= 3.2)':
unnecessary greater-than versioned dependency: python3 (>= 3.2).
Debian has oldoldstable -> 3.2.3-6; oldstable -> 3.4.2-2;
oldstable-kfreebsd -> 3.4.2-2; stable -> 3.5.3-1; unstable -> 3.6.3-2;
testing -> 3.6.4-1; unstable -> 3.6.4-1;
Warning in 'control binary:mwic Depends:0' value 'python3 (>= 3.2)':
unnecessary greater-than versioned dependency: python3 (>= 3.2).
Debian has oldoldstable -> 3.2.3-6; oldstable -> 3.4.2-2;
oldstable-kfreebsd -> 3.4.2-2; stable -> 3.5.3-1; unstable -> 3.6.3-2;
testing -> 3.6.4-1; unstable -> 3.6.4-1;
$ doc8
Scanning...
Validating...
.../mwic-0.7.4/doc/manpage.rst:19: D001 Line too long
.../mwic-0.7.4/doc/manpage.rst:20: D001 Line too long
.../mwic-0.7.4/doc/manpage.rst:53: D001 Line too long
# You may want to file a bug on license-reconcile
# about these false positives re Expat vs MIT/X11
$ env PERL5OPT=-m-lib=. license-reconcile
...
License mismatch: File private/check-rst has license MIT/X11 (BSD
like) which does not match Expat. at
/usr/share/perl5/Debian/LicenseReconcile/App.pm line 222, line
3.
# This command checks style. While a consistent style
# is a good idea, people who have different style
# preferences will want to ignore some of the output.
# Do not bother adding non-upstreamable patches for this.
$ find . -type f -iname '*.py' -exec pycodestyle --ignore W191 {} +
# This command checks style. While a consistent style
# is a good idea, people who have different style
# preferences will want to ignore some of the output.
# Do not bother adding non-upstreamable patches for this.
$ pydocstyle .
$ find . -type f -iname '*.py' -exec pylint3 --rcfile=/dev/null
--msg-template='{path}:{line}:{column}: [{category}:{symbol}] {obj}:
{msg}' --reports=n {} +
$ python3-bandit -r .
$ grep -nHriE 'fixme|todo|hack|xxx+|broken' .
./tests/multiword-t-he.txt:6:# FIXME:
./tests/test_extdict.py:121:t({'aasumes'}, {'assumes'}) # FIXME? 'assumes'
./tests/test_extdict.py:122:t({'Addtional'}, {'Additional'}) #
FIXME? 'addtional'
./tests/multiword-t-he.exp:17:FIXME:
./tests/multiword-t-he.exp:18:| # FIXME:
./private/run-pylint:32:log=$(mktemp -t pylint.XX)
./.pylintrc:5:fixme,
$ vulture .
lib/cli.py:54: Unused variable 'namespace'
lib/cli.py:54: Unused variable 'option_string'
lib/cli.py:187: Unused variable 'ch'
lib/cli.py:192: Unused variable 'ch'
lib/cli.py:310: Unused variable 'args'
lib/colors.py:32: Unused variable 'warn'
lib/colors.py:35: Unused variable 'unreverse'
tests/test_blackbox.py:35: Unused attribute 'maxDiff'
tests/test_blackbox.py:85: Unused attribute 'redundant'
tests/test_blackbox.py:90: Unused variable 'enabled'
tests/test_blackbox.py:101: Unused function 'loadTestsFromFile'
tests/test_blackbox.py:105: Unused function 'wantFunction'
tests/test_blackbox.py:115: Unused function '_test'
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: RFS: mwic 0.7.4-1
On Sat, Mar 17, 2018 at 5:29 AM, Georg Faerber wrote: > I'm searching a sponsor for the initial upload of mwic. I'll be happy to sponsor this, but I will need you to upload the source package to mentors.d.n first. > - Running autopkgtest gives "SKIP no tests in this package". I've > searched the Internets regarding this, but didn't found anything > useful. I appreciate input and feedback regarding this. In general, codesearch.d.n is a better place to find error strings than web search engines. This is probably due to autodep8. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Thread on flit...
On Sat, Feb 17, 2018 at 4:41 PM, Julien Puydt wrote: > It is intended for trivial packaging... so perhaps dh_python could > detect its use and do something smarter. Ideally, debhelper should DTRT no matter what build system is in use. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Thread on flit...
On Thu, Feb 15, 2018 at 11:05 PM, Julien Puydt wrote: > Should it be packaged? If it meets Debian standards and is needed by another package, there is no reason why it shouldn't be packaged. -- bye, pabs https://wiki.debian.org/PaulWise
Re: pyapi-gitlab vs python-gitlab
On Fri, Feb 9, 2018 at 8:43 PM, IOhannes m zmölnig wrote: > i've contacted them in 2017-12 (via github), and afaict both projects > acknowleged the problem and rejected a solution :-( > > https://github.com/pyapi-gitlab/pyapi-gitlab/issues/263 > https://github.com/python-gitlab/python-gitlab/issues/385 Thanks for the links. The pyapi-gitlab upstream responded to my email and mentioned that he doesn't have time to maintain it and suggested that it would be fine for Debian to switch to python-github. -- bye, pabs https://wiki.debian.org/PaulWise
Re: pyapi-gitlab vs python-gitlab
On Fri, Feb 9, 2018 at 11:17 AM, Scott Kitterman wrote: > I'd encourage you to work with the upstreams to deconflict the namespace. > This isn't really a problem Debian should solve. Good point, I've contacted them via email and will file tickets if there is no response. -- bye, pabs https://wiki.debian.org/PaulWise
pyapi-gitlab vs python-gitlab
Hi all, I wanted to use the python-gitlab cli but I noticed it wasn't in the Debian packages and then I noticed that we have pyapi-gitlab as python*-gitlab packages instead of python-gitlab. I'm not sure what the right solution here is? Maybe rename the pyapi-gitlab packages to include pyapi in the names? http://python-gitlab.readthedocs.io/en/stable/cli.html https://github.com/python-gitlab/python-gitlab/ https://github.com/pyapi-gitlab/pyapi-gitlab/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Package name of src:fontmake
On Sun, Jan 28, 2018 at 2:30 AM, Piotr Ożarowski wrote:
> please also remember to install this private library into private (as
> in: outside dist-packages) dir. You can do that with something like:
Is there or should there be a lintian warning about packages not named
python{,3}-* containing public Python libraries?
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: pycharm package in debian
On Sun, Oct 1, 2017 at 3:26 PM, Ghislain Vaillant wrote: > May I ask what would be the benefit for pycharm to be in Debian, when we > already have the official Jetbrains Toolbox App or the snap package as means > to install and update the application? I've never heard of the first of those, definitely wouldn't use the snap package and probably not the Jetbrains thing, unless either of them were built entirely from packages in Debian main, which I am assuming they aren't ever going to be. -- bye, pabs https://wiki.debian.org/PaulWise
Re: pycharm package in debian
On Sat, Sep 30, 2017 at 10:35 PM, Julien Puydt wrote: > Le 30/09/2017 à 14:22, kamaraju kusumanchi a écrit : >> Are there any plans to make a debian package of pycharm that is part >> of official debian? I used their community edition on windows 7 and it >> is awesome. > > Maybe you should look at WNPP to see if someone filed a RFP or ITP, and > if not, submit a RFP yourself? Looks like someone attempted it but gave up, so if you would like to do it that would be great. https://bugs.debian.org/742394 https://mentors.debian.net/intro-maintainers -- bye, pabs https://wiki.debian.org/PaulWise
Re: a few quick questions on gbp pq workflow
On Sun, Aug 6, 2017 at 2:53 PM, Jeremy Stanley wrote: > Why would you need to repack a tarball just because it contains > prebuilt docs (non-DFSG-free licensed documentation aside)? I'd suggest removing prebuilt files should happen in both the upstream VCS and tarballs, failing that then at `debian/rules clean` and `debian/rules build` time should be enough for Debian's purposes. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Packaging ElasticSearch (different version for different server API version)
On Wed, Apr 5, 2017 at 3:21 AM, Adam Cécile wrote: > It's working just fine, and I even think it's a lot saner as I can simply do > "from elasticsearch5 import ElasticSearch" instead "from elasticsearch2 > import ElasticSearch" to test my code against a new ES5 servers cluster. > Do you think it's acceptable to "change" upstream behavior like this ? I think this is a feature that would be best added upstream so that it can be supported by other distributions too. -- bye, pabs https://wiki.debian.org/PaulWise
Re: GnuPG signatures on PyPI: why so few?
On Mon, Mar 13, 2017 at 4:28 AM, Jeremy Stanley wrote: > upload them to PyPI since the authors of the coming Warehouse > replacement for the current CheeseShop PyPI have already indicated > that they intend to drop support for signatures entirely. Did they give any reasoning for this decision? -- bye, pabs https://wiki.debian.org/PaulWise
Re: PyPI source or github source?
On Sun, Mar 12, 2017 at 10:19 AM, Brian May wrote: > Sure, you could argue that PyPI source packages should contain > everything the github package does. In fact there is a PyPI tool to help > get the MANIFEST.in correct for such purposes - > https://pypi.python.org/pypi/check-manifest Anyone interested in packaging this? > Unfortunately, github releases cannot (AFAIK) easily be signed, unless > you retrieve signed git tags directly from git (which is not supported > by uscan AFAIK). Would be good if gbp buildpackage supported signing git > tags, I don't think it does either. uscan does support git but doesn't check OpenPGP signatures on tags. It would probably be easy to add that, please file a bug about it. > * Do we consider signed git tags / commits secure, considering they are > based on SHA1? Better than having unsigned tags/commits. > * Is there any point having signed PyPI releases when (very likely) the > underlying upstream git repository has no signatures? Yes, presumably the PyPI releases are built from the author's copy of the git repository, rather than directly from the online repository, hopefully they have verified all commits they pulled into it. > * Is there any point having signed PyPI releases when (very likely) the > public key is stored in an insecure DPMT respository on > git.debian.org? Yes, it is also stored in immutable places like the archive and snapshot.d.o. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Best way to package a python module which is "private" with exposed calling script
On Tue, Feb 7, 2017 at 7:32 AM, Simon McVittie wrote: > This is not portable to platforms that don't have symlinks (hello Windows) FYI, Windows has symlinks: https://msdn.microsoft.com/en-us/library/windows/desktop/aa363878(v=vs.85).aspx https://en.wikipedia.org/wiki/NTFS_symbolic_link -- bye, pabs https://wiki.debian.org/PaulWise
Re: http://pypi.debian.net/ down?
On Wed, Jan 18, 2017 at 3:39 PM, Andreas Tille wrote: > lots of watch files are reported as failing since (at least yesterday). > Is something wrong with http://pypi.debian.net/ ? There was an issue renewing sponsorship of the VM. There is a proposal on debian-admin to move it to DSA. DSA hasn't responded to it yet. -- bye, pabs https://wiki.debian.org/PaulWise
Re: /usr/bin/python2 shebangs
On Thu, Nov 10, 2016 at 12:02 AM, Thomas Goirand wrote: > The point is, some people also use venvs. In a world of Python 3 only, > some upstream will continue to use /usr/bin/python (IMO, rightly). We > should be able to provide a default implementation for these scripts. I think this is a bug in virtualenv: $ virtualenv -p /usr/bin/python3 test Already using interpreter /usr/bin/python3 Using base prefix '/usr' New python executable in /home/pabs/test/bin/python3 Also creating executable in /home/pabs/test/bin/python Installing setuptools, pkg_resources, pip, wheel...done. $ virtualenv -p python3 test Already using interpreter /usr/bin/python3 Using base prefix '/usr' New python executable in /home/pabs/test/bin/python3 Also creating executable in /home/pabs/test/bin/python Installing setuptools, pkg_resources, pip, wheel...done. -- bye, pabs https://wiki.debian.org/PaulWise
Re: DEP 8: Gathering Django usage analytics
On Mon, Nov 7, 2016 at 12:06 PM, Paul Wise wrote: > Making it opt-in with *informed* user consent. Thinking on it more, due to the whole click-through culture on the modern web, I'm not sure that informed user consent is quite enough. Some discussion of that phenomenon in the latest FaiF episode: http://faif.us/cast/2016/nov/01/0x5E/ > Use a Django-hosted piwik/etc service instead of Google Analytics. https://vimeo.com/97505679 -- bye, pabs https://wiki.debian.org/PaulWise
Re: DEP 8: Gathering Django usage analytics
On Mon, Nov 7, 2016 at 10:21 AM, Brian May wrote: > I think upstream Django have requested our feedback on this pull request: > > https://github.com/django/deps/pull/31 I would suggest a few things: Making it opt-in with *informed* user consent. Use a Django-hosted piwik/etc service instead of Google Analytics. > Should I ask on debian-devel? Seems reasonable. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Packaging new version of ZODB (Zope Object Database)
On Wed, Nov 2, 2016 at 8:51 AM, Julien Muchembled wrote: > Bug#842870: ITP: zodbpickle -- Fork of pickle module, for ZODB Please ensure the security team are informed about this fork, via their embedded-code-copies file: https://wiki.debian.org/EmbeddedCodeCopies -- bye, pabs https://wiki.debian.org/PaulWise
Re: Jupyter Notebook: how to comment out code in ipynb files ?
On Tue, Sep 27, 2016 at 12:17 AM, Jerome BENOIT wrote: > everyone read the documentation. Ok, so when they load the documentation, their web browser will call out to the Internet. > on unstable, the embedded youtube stuff was detected. Ah, good. I must have overlooked that. > Out of curiosity, is there somewhere DFSG-free youtube video ? Youtube doesn't have facilities for distributing video source materials, but there are videos under free licenses there I guess. The Blender videos and probably some Synfig videos come to mind. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Jupyter Notebook: how to comment out code in ipynb files ?
On Mon, Sep 26, 2016 at 12:53 PM, Jerome BENOIT wrote: > I put them a few hours ago at the Debian Sage Tean [1] repository at Aliot > [2]. Looks like these are not false positives and are definitely privacy breaches (probably minor since I'm not sure anyone would read the docs) and there is one privacy breach that lintian missed, an embedded youtube video, see below. > In fact I have just checked, I think that now that the images can be gathered > locally. Make sure that the gathered images are DFSG-free. The youtube video definitely is not. $ egrep -C3 src=\"https?: nbsphinx-doc/usr/share/doc/python-nbsphinx-doc/html/code-cells.html https://www.python.org/static/img/python-logo-large.png"/> -- http://jupyter.org/assets/nav_logo.svg"/> -- http://python.org/images/python-logo.gif"/> -- https://www.youtube.com/embed/WAikxUGbomY; frameborder="0" allowfullscreen > -- bye, pabs https://wiki.debian.org/PaulWise
Re: Jupyter Notebook: how to comment out code in ipynb files ?
On Mon, Sep 26, 2016 at 12:03 PM, Jerome BENOIT wrote: > Now, I am not so sure: in case it is a false positive Can you upload source and binary packages somewhere so we can determine the right answer? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Jupyter Notebook: how to comment out code in ipynb files ?
On Mon, Sep 26, 2016 at 12:22 AM, Jerome BENOIT wrote: > Some code in an ipynb document have to be discarded because > it causes a privacy-breach-logo lintian error. Bring the involved > icon in the debian folder makes no senses because the code is meant > to be a URL example. Currently, I literally discard the involved code, > neverthless I would prefer to just comment it out in such a way it is > still available in the very source: any idea ? Which package and document are you talking about? -- bye, pabs https://wiki.debian.org/PaulWise
Re: can we disable the bounce kicker? Re: confirm
On Sun, Sep 11, 2016 at 3:23 AM, Sandro Tosi wrote: > On Sat, Sep 10, 2016 at 7:35 PM, Barry Warsaw wrote: >> On Sep 10, 2016, at 02:46 PM, Sandro Tosi wrote: >> >>>I'm sure i'm not the only member using gmail, which bounces spam >>>emails and that what causes this problem. >> >> Are you sure about that? Bouncing spam has been bad practice for a very long >> time. > > i indeed used a wrong term (in email-world bounce has a specific > meaning): gmail rejects spam emails (according to its filters) during > the smtp session with the other MTA, so it's not a bounce, but the > sender (alioth in this case) cant deliver the email, and that's what > triggers the suspended membership process. Rejecting instead of discarding spam sent to mailing lists has also been bad practice for a long time. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#834768: RFS: codicefiscale/0.9-1
On Sat, Aug 20, 2016 at 10:05 PM, Elena ``of Valhalla'' wrote: > Thanks. I currently check packages with lintian (--pedantic) and > piuparts, and I sort-of-know-but-still-don't-use check-all-the-things: If it helps convince you to use it, installing without recommends will lead to knowing which tools to install for the specific package you are checking. Also, patches welcome for the Python TODO list :) https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/python https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/doc/README#n33 > is there something else I should/can add to the list? I guess you are already running it via piuparts, but run adequate on the installed packages. Adding some DEP-8 tests might be a good idea: http://dep.debian.net/deps/dep8/ More stuff will get run when it reaches Debian: https://wiki.debian.org/qa.debian.org -- bye, pabs https://wiki.debian.org/PaulWise
Re: help2man usage with pybuild / debhelper packaging workflow
On Sat, Jun 4, 2016 at 8:05 PM, Ghislain Vaillant wrote: > I like this approach. Any example you may have in mind? Apparently onionbalance uses sphinxcontrib-autoprogram. I plan to figure out python3-sphinx-argparse at some point for check-all-the-things. Another really useful thing to have is automatic bash completion based on the objects used for --help output. I use python3-argcomplete in check-all-the-things for that (see git master). -- bye, pabs https://wiki.debian.org/PaulWise
Re: request to join DPMT
On Tue, May 3, 2016 at 7:17 PM, Jonathon Love wrote: > can someone add me to the team? You were added a week ago: https://lists.debian.org/msgid-search/20160426064708.gy2...@sar0.p1otr.com You may want to subscribe to the debian-python list: https://lists.debian.org/debian-python/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: pep8 build depends on jessie
On Mon, May 2, 2016 at 7:06 AM, Brian May wrote: > The idea was to allow it to build unchanged on Jessie, which doesn't > have python-pep8. I guess my question wasn't clear enough. I was asking why pep8/python-pep8 are used at build time at all. They are tools for checking style, there is no reason to use them at build time at all. -- bye, pabs https://wiki.debian.org/PaulWise
Re: pep8 build depends on jessie
On Sun, May 1, 2016 at 6:21 PM, Brian May wrote: > "python-pep8 | pep8" in the build depends Why is pep8 in a Build-Depends? It doesn't seem like something that should be used at build time, only at upstream development time. -- bye, pabs https://wiki.debian.org/PaulWise
Re: JOB: for a Debian Pythonista to work with others alike
On Wed, Apr 20, 2016 at 4:47 AM, Yaroslav Halchenko wrote: > Hopefully you wouldn't throw way too many stones for such an OT, but I > thought to ask since the audience is right! ;) Please post these on debian-jobs instead. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Packaging dependencies for mailman3-hyperkitty
On Fri, 2016-03-25 at 19:35 +0100, Pierre-Elliott Bécue wrote: > That's in progress, the only goal of this detection is to deactivate > javascript dynamic load of threads. We're thinking about alternative > solutions. I don't understand why you would deactivate JavaScript dynamic load for bots? Typically they don't support JavaScript (except Google) and you should have a fallback for people who turn off JavaScript anyway. I hope mailman3/HyperKitty web interfaces use progressive enhancement: http://en.wikipedia.org/wiki/Progressive_enhancement > I understand your point, and I'll think about it, but my goal is to make > upstream remove obsolete dependencies. django-libravatar seems to be the > only project that bundles support for that, and it's not maintained, whereas > django-gravatar2 is still maintained. I guess you are talking about this project, it hasn't seen any issues filed so probably just works as-is without needing any changes? https://github.com/fnp/django-libravatar > So, for now, I think that I'd rather have a first mailman3 suite in debian, > and then, think about how to make things better. :) I see. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Packaging dependencies for mailman3-hyperkitty
On Thu, Mar 24, 2016 at 11:43 PM, Pierre-Elliott Bécue wrote: > Packaging dependencies for mailman3-hyperkitty Does HyperKitty depend on mailman3 or just enhance it by providing an archive web interface? If the latter, I would suggest calling it hyperkitty instead of mailman3-hyperkitty. > robot-detection suffers the same illness, but it's tiny, it's possible to > integrate it in hyperkitty, or make it optionnal. Embedded code copies are against Debian policy, please package it separately or get upstream to switch to something else. https://wiki.debian.org/EmbeddedCodeCopies Something like that sounds like it isn't possible to keep usefully up-to-date in Debian stable though, since the landscape of robots on the web will be changing continually and many will be aiming to emulate browsers. https://pypi.python.org/pypi/robot-detection In addition, it seems to be woefully inadequate for that since the API doesn't appear to take into account IP address ranges. It also depends on the robotstxt.org database, which would need to be packaged separately and is also no longer kept up to date at this time: http://www.robotstxt.org/db.html "This robots database is currently undergoing re-engineering. Due to popular demand we have restored the existing data, but addition/modification are disabled." As the page says, there is a better database of user-agents available http://www.botsvsbrowsers.com/ http://www.botsvsbrowsers.com/category/1/index.html Unfortunately this is incompatible with the data format used by robotstxt.org/robot-detection: http://www.robotstxt.org/db/all.txt So you can see from the botsvsbrowsers.com data, the User-Agent field is often bogus or contains vulnerability attack patterns and is thus mostly not useful at all and should probably just be ignored by all web apps at this point. So I would suggest convincing upstream to remove whatever use of robot-detection is present in mailman3 or hyperkitty. > That leaves me with django-gravatar2, that seems useful, and is still > developed. I heard there is some kind of "canonical" way of packaging django > apps. As I'm not used to that, I'm here to ask advice. I would suggest upstream switch from Gravatar (a centralised proprietary service) to Libravatar (a federated Free Software service that falls back on Gravatar): https://www.libravatar.org/ Re canonical django packaging, you may be talking about this: https://wiki.debian.org/DjangoPackagingDraft There are also lots of python-django-* packages in Debian that you could look at. -- bye, pabs https://wiki.debian.org/PaulWise
Re: nose2 reverse dependancies
On Tue, Mar 8, 2016 at 12:02 PM, Brian May wrote: > Paul Wise writes: > Are these available in Debian/testing? If so, what packages? According to packages.debian.org and apt metadata: botch is only in unstable dose-ceve is in dose-extra, which is in all suites. -- bye, pabs https://wiki.debian.org/PaulWise
Re: static analysis and other tools for checking Python code
On Sat, Mar 5, 2016 at 10:03 PM, Nicolas Chauvat wrote: > Would "pylint -E *.py" do what you want? That is essentially what the added check does now. > Or maybe use find with 'file' as a filter? MIME support is in progress in c-a-t-t. -- bye, pabs https://wiki.debian.org/PaulWise
Re: static analysis and other tools for checking Python code
On Fri, Mar 4, 2016 at 11:11 PM, Nicolas Chauvat wrote: > It does recursively scan for Python files: That doesn't pick up Python scripts that don't have .py in their name. I couldn't get it to work with files in the current directory: $ touch __init__.py $ echo 'a = b+1' > bar.py $ pylint -E . No config file found, using default configuration Should I file bugs about these two issues? It does work with subdirectories as you pointed out though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: static analysis and other tools for checking Python code
On Fri, Mar 4, 2016 at 10:14 PM, Daniel Stender wrote: > BTW there's also Prospector which provides a uniform interface to many > individual linters: > https://packages.qa.debian.org/p/prospector.html Already on the TODO list: https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/python If it is possible to disable the prospector checks for things that prospector runs that c-a-t-t already runs, please feel free to add a check that runs prospector. It seems that prospector is only a wrapper, it doesn't do any checks only implemented in it though? -- bye, pabs https://wiki.debian.org/PaulWise
Re: static analysis and other tools for checking Python code
On Fri, Mar 4, 2016 at 5:24 PM, Nicolas Chauvat wrote: > I hope this helps making clearer what pylint can be used for. I had a > look at the README and I suppose the intro section at the top could > state the above goal with more clarity. It does, thanks. Do you know if pylint can recursively scan for Python files rather than being passed the names of Python files? Incidentally, I got a patch for c-a-t-t to support pylint from the author of yamllint: https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/patch/?id=4dc0a9ca929fa3488ab93cb4e997101d52bbe8a8 -- bye, pabs https://wiki.debian.org/PaulWise
Re: static analysis and other tools for checking Python code
On Thu, 2016-03-03 at 12:52 +0100, Nicolas Chauvat wrote: > That would be https://pypi.python.org/pypi/PyChecker > > Pylint has never run code from the source tree. I wonder where I got that impression from. What about from the module it is checking? > "pylint " should work fine. Unfortunately that needs the module installed to work. Is there any way to make it scan the source tree instead? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: static analysis and other tools for checking Python code
On Thu, Mar 3, 2016 at 7:52 AM, Jeremy Stanley wrote: > ... All of flake8, hacking, bandit, pep257, clonedigger and more are on the TODO list: https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/python FYI pep257 is definitely packaged: https://packages.debian.org/search?keywords=pep257 > I can probably think up more that I've used, but the above rise to > the top of my list. More suggestions would be useful but most useful would be actual tests. They are very simple to add if you know how to run the tools. -- bye, pabs https://wiki.debian.org/PaulWise
Re: static analysis and other tools for checking Python code
On Wed, Mar 2, 2016 at 9:23 PM, Nicolas Chauvat wrote: > Maybe add pylint? As I understand it: pylint runs code from the source tree so it isn't suitable for running by default as that could be a security issue for people reviewing potentially untrusted code. pylint isn't able to be run automatically, it needs a human to come up with the right command-line. c-a-t-t could certainly print a suggestion to run pylint like it does for fuzzers like afl/zzuf. -- bye, pabs https://wiki.debian.org/PaulWise
