Re: psycopg3 packaging: need new version of cython3 (and psycopg2)

2021-10-01 Thread Paul Wise
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

2021-09-09 Thread Paul Wise
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

2021-06-25 Thread Paul Wise
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

2021-06-25 Thread Paul Wise
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

2021-06-25 Thread Paul Wise
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.

2021-06-19 Thread Paul Wise
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

2021-05-05 Thread Paul Wise
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

2021-05-05 Thread Paul Wise
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

2021-03-03 Thread Paul Wise
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.

2021-02-09 Thread Paul Wise
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

2021-02-08 Thread Paul Wise
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

2021-02-07 Thread Paul Wise
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

2021-01-21 Thread Paul Wise
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

2021-01-21 Thread Paul Wise
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

2021-01-21 Thread Paul Wise
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

2021-01-20 Thread Paul Wise
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

2021-01-19 Thread Paul Wise
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

2020-12-30 Thread Paul Wise
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

2020-10-30 Thread Paul Wise
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

2020-10-30 Thread Paul Wise
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

2020-10-07 Thread Paul Wise
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

2020-10-04 Thread Paul Wise
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

2020-09-18 Thread Paul Wise
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

2020-05-18 Thread Paul Wise
On Mon, May 18, 2020 at 7:12 AM Nicolas Chauvat wrote:

> In other words, could the contribution from Ubuntu to Debian
> diminishes because more effort is put on Snaps and less effort on
> improving upstream Debian packages ?

The same applies to Snap more generally as well as AppImage, Flatpak
and downloader packages. Those ecosystems are gaining mindshare with
upstream developers so distributions like Debian are going to lose
mindshare among upstreams and then among users since they get all
their apps from Flathub etc and so fewer people will be packaging for
Debian. I've already seen packages in Debian switch from being
properly packaged to just a snap installer or a downloader script.
Personally I would like to see Debian automatically generate
AppImage/Flatpak/Snap packages (and perhaps server container formats
like Docker) from existing .debs in order to offer our users and users
of other distros more ways to use Debian produced packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: packaging DiscoDOS - a cli tool for vinyl DJs

2020-05-15 Thread Paul Wise
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

2020-05-15 Thread Paul Wise
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

2020-04-12 Thread Paul Wise
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?

2020-03-20 Thread Paul Wise
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?

2020-02-23 Thread Paul Wise
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 ?

2019-11-19 Thread Paul Wise
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?

2019-11-02 Thread Paul Wise
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?

2019-11-01 Thread Paul Wise
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

2019-09-08 Thread Paul Wise
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

2019-06-09 Thread Paul Wise
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.

2018-10-12 Thread Paul Wise
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.

2018-06-08 Thread Paul Wise
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.

2018-06-07 Thread Paul Wise
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.

2018-06-05 Thread Paul Wise
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

2018-05-25 Thread Paul Wise
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

2018-04-04 Thread Paul Wise
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

2018-03-24 Thread Paul Wise
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

2018-03-22 Thread Paul Wise
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

2018-03-21 Thread Paul Wise
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

2018-03-20 Thread Paul Wise
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)

2018-03-19 Thread Paul Wise
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)

2018-03-19 Thread Paul Wise
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)

2018-03-19 Thread Paul Wise
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

2018-03-17 Thread Paul Wise
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

2018-03-16 Thread Paul Wise
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...

2018-02-17 Thread Paul Wise
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...

2018-02-16 Thread Paul Wise
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

2018-02-11 Thread Paul Wise
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

2018-02-08 Thread Paul Wise
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

2018-02-08 Thread Paul Wise
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

2018-01-27 Thread Paul Wise
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

2017-10-01 Thread Paul Wise
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

2017-09-30 Thread Paul Wise
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

2017-08-07 Thread Paul Wise
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)

2017-04-04 Thread Paul Wise
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?

2017-03-12 Thread Paul Wise
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?

2017-03-11 Thread Paul Wise
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

2017-02-06 Thread Paul Wise
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?

2017-01-17 Thread Paul Wise
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

2016-11-09 Thread Paul Wise
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

2016-11-06 Thread Paul Wise
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

2016-11-06 Thread Paul Wise
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)

2016-11-01 Thread Paul Wise
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 ?

2016-09-26 Thread Paul Wise
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 ?

2016-09-25 Thread Paul Wise
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 ?

2016-09-25 Thread Paul Wise
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 ?

2016-09-25 Thread Paul Wise
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

2016-09-10 Thread Paul Wise
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

2016-08-20 Thread Paul Wise
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

2016-06-04 Thread Paul Wise
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

2016-05-03 Thread Paul Wise
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

2016-05-01 Thread Paul Wise
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

2016-05-01 Thread Paul Wise
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

2016-04-19 Thread Paul Wise
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

2016-03-25 Thread Paul Wise
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

2016-03-24 Thread Paul Wise
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

2016-03-07 Thread Paul Wise
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

2016-03-06 Thread Paul Wise
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

2016-03-04 Thread Paul Wise
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

2016-03-04 Thread Paul Wise
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

2016-03-04 Thread Paul Wise
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

2016-03-03 Thread Paul Wise
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

2016-03-02 Thread Paul Wise
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

2016-03-02 Thread Paul Wise
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



Re: static analysis and other tools for checking Python code

2016-03-01 Thread Paul Wise
On Wed, Mar 2, 2016 at 12:38 PM, Scott Kitterman wrote:

> It's probably worth looking at [1] to see if there's anything worth salvaging
> for what you're doing.
...
> [1] http://snapshot.debian.org/package/lintian4python/0.28.4/

If someone were to revive upstream development of lintian4python
(perhaps as a native package) and reintroduce it to Debian again,
c-a-t-t could certainly start running it again. I had to disable it
when it got removed from Debian.

https://jwilk.net/software/lintian4python
https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/python#n35

[lintian4python]
groups = package
flags = todo
comment = re-enable if the package is ever revived, see #768988 and #778796
apt = lintian4python
files = ../*.changes ../*.deb ../*.dsc *.changes *.deb *.dsc
command = lintian4py {files}

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: nose2 reverse dependancies

2016-03-01 Thread Paul Wise
On Wed, Mar 2, 2016 at 7:02 AM, Mattia Rizzolo wrote:

> FYI, I don't know of a nice way to build a dependency graph, like
> sometimes I see somewhere, with graphiz

On #debian-mentors recently this question came up and the answers were:

debtree
apt-cache dotty
botch
dose-ceve

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



static analysis and other tools for checking Python code

2016-03-01 Thread Paul Wise
Hi all,

Some of you may have noticed I'm working on a tool called
check-all-the-things that does what it says on the tin.

https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git
https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/doc/README

One of the things it has checks for is Python. So far it runs pyflakes
and pep8 and a few hacky greps for some things that shouldn't be done
in Python in my experience.

https://anonscm.debian.org/cgit/collab-maint/check-all-the-things.git/tree/data/python

There is a long list of TODO items for Python checking tools. I would
really appreciate some help turning this TODO list into checks and or
packaging of some of the tools not yet in Debian.

If anyone knows of tools that do the equivalent of the hacky greps
that would be helpful too, or even just which tool should be adding
tests for those issues.

If anyone wants to help work on the c-a-t-t code, it is written in Python too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Autopkgtest smoke test for Python libraries

2016-03-01 Thread Paul Wise
On Wed, Mar 2, 2016 at 6:53 AM, Ben Finney wrote:

> Who can recommend a way to make this a more automated part of the Debian
> Python package build workflow?

Add things that should be changed to `cme fix` or pypi2deb

https://wiki.debian.org/AutomaticPackagingTools

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Python Policy: Things to consider for Stretch

2016-02-15 Thread Paul Wise
On Tue, Feb 16, 2016 at 11:42 AM, Barry Warsaw wrote:

> I don't remember exactly why we called it 'site-packages' ...

Thanks for the history :)

I always thought it strange to put site- in /usr/local since
/usr/local already implies site/system-wide packages. Same for dist-
since /usr already implies distribution packages. I find it weird that
site- gets used in ~/ since they are clearly user packages not
site/system-wide packages.

Any thoughts on that?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




Re: Pushing a bunch of packages to jessie-backports

2015-11-28 Thread Paul Wise
On Fri, Nov 27, 2015 at 8:02 PM, Thomas Goirand wrote:

> That's one of the multiple breakage that the NEW queue brings. There's
> unfortunately no way to fix that for this kind of complex uploads with
> inter-dependencies and updates of existing packages. The only way,
> unfortunately, is to have the NEW queue processed fast enough by the FTP
> masters.

Pretty sure the FTP team tools for the NEW queue deal with ordering
interdepending packages correctly.

Also, the FTP team are not responsible for backports NEW, that is a
separate team.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Dealing with flit -- a simplified packaging of python modules

2015-09-27 Thread Paul Wise
On Sat, Sep 26, 2015 at 5:21 AM, Donald Stufft wrote stuff

Thanks for the summary, it sounds like the Python community is slowly
moving towards a setup that is more closely aligned with Debian's
values and setup.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Dealing with flit -- a simplified packaging of python modules

2015-09-26 Thread Paul Wise
On Fri, 2015-09-25 at 19:25 -0400, Donald Stufft wrote:

> Because the way Python packaging currently is and historically has
> been, binary packages are not something that is widely available or
> viable.

Hmm, I thought eggs have been around for ages (seems about 8 years)?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




signature.asc
Description: This is a digitally signed message part


Re: Dealing with flit -- a simplified packaging of python modules

2015-09-25 Thread Paul Wise
On Thu, Sep 24, 2015 at 1:17 PM, Thomas Kluyver wrote:

> That's my point ;-). From our upstream point of view, it's not a bug
> that the distributions we put on PyPI contain generated/bundled files -
> we do it that way deliberately, so that end users can install without
> needing Javascript developer tools to build those files. If you want a
> pure source tarball without generated files, that's available from
> Github.

Why are end users using source packages instead of binary packages and
then complaining that the source tarballs aren't ready-to-run binary
packages?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Sphinx 1.3 in Debian experimental

2015-06-29 Thread Paul Wise
On Tue, Jun 30, 2015 at 4:14 AM, Barry Warsaw wrote:

 Maybe upstream would accept a patch similar to what I've done before.  It
 could map |today| to the value of an environment variable, if it's set.
 E.g. something like SPHINX_TODAY.  Then pybuild, dh_python{2,3}, or some other
 infrastructure piece could set that to the parsed changelog value.  Generally,
 it wouldn't be set, so |today| would have the normal semantics.

|today| sounds like a misfeature, more interesting would be |version|
or |source_date|.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6Hf3+bK32PcF+mrNZ=0v9wcq+4z7yup-8zp27acpar...@mail.gmail.com



Re: Python 2 d-d-a proposal

2015-04-16 Thread Paul Wise
On Thu, Apr 16, 2015 at 4:48 AM, Scott Kitterman wrote:

 You might also ask Debian teams using Python in the Debian infrastructure to
 review their packaged dependencies and identify any that aren't available for
 Python3.  We'll need to know that soon so we can work on porting
 dependencies/finding alternatives.  I think we should have as a goal for
 Stretch (that's the next one, right?) to have all the packages in place needed
 to run python using Debian infrastructure on Python3.  That'll leave some time
 then 'just' to port the Debian specific stuff.

For services hosted on DSA machines, you can find the known
dependencies in this file:

https://anonscm.debian.org/cgit/mirror/debian.org.git/tree/debian/control

This is missing dependencies DSA doesn't know about, services on
alioth.debian.org, debconf.org and many debian.net services though. If
you build the debian.org meta-packages and install them in a chroot,
you should be able to get an idea of which Python 2 modules are needed
for services hosted on DSA machines.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gpnmf6xzrd6qp3ry-6nfwpnw25ndi+vnouwvk+xnc...@mail.gmail.com



Python and Debian infrastructure

2015-04-16 Thread Paul Wise
In addition to the Python 3 related work:

Port service dependencies to Python 3.
Port service code-bases to Python 3.

We also need to:

Port Django based services to Django 1.7

Port services based on Pylons (deprecated) to something else like Django:

snapshot.debian.org
debexpo (mentors.debian.net)
debshots (screenshots.debian.net, in progress to Rails)
debianmemberportfolio (portfolio.debian.net)

Does anyone know of any other deprecated Python stuff that we should
move away from?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6hkht1l2v9veyj3rtwq0w65t4awuoemaxub1tucylh...@mail.gmail.com



  1   2   >