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
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
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
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
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:
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
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
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
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,
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
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
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
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
>
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
>
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
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
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
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
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
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
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
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
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
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
>
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:
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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/
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:
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
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
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
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
>
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
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
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
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
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
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
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
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-ma
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
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
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 mi
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
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,
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
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
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
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
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
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
>
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
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
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
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,
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
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
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
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?
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
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
--
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
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
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 epis
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
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
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
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
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
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
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
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
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
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,
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
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
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
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?
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.
>
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
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
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 .
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:
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
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.
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:
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
1 - 100 of 197 matches
Mail list logo
