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 carn
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 r
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 sourc
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&package=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 the
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 mod
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, i
On Thu, 2022-01-13 at 21:25 +0100, Mechtilde Stehmann wrote:
> Are there any hints to upload newer versions?
There are some hints about this on the team git policy page:
https://wiki.debian.org/Python/GitPackaging
Probably some other wiki pages are helpful too.
--
bye,
pabs
https://wiki.debi
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
Des
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
> mo
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 "feedpa
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 cor
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-
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
P
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 tarball
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.
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.o
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
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 s
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
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 lo
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
pa
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,
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 her
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 a
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
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 ve
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 int
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 tarb
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 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
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.
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
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 to
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
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.deb
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 o
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 f
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
> packag
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
https://wiki.debian.org/
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 replac
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
prebu
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
https://wiki.debian.org
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/coll
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 co
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
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 missin
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 e
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 pref
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
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 t
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
> https://github.com/python-gitlab/python-gitlab/issue
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:/
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
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 pub
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-python@lists.debian.org
* Package name: robobrowser
Version : 0.5.3
Upstream Author : Joshua Carp
* URL : http://robobrowser.readthedocs.org/
https://github.com/jmcarp/robobrowser
* License : BSD 3-clause
On Fri, Oct 13, 2017 at 3:27 AM, Diane Trout wrote:
> Being able to find all your documentation in one place would really be
> convenient.
I don't think doc-base/doc-central will ever be the answer to this as
it is very specific to Debian and thus not available on other distros.
Eventually the Fr
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, defin
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 `debi
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
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 int
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,
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 in
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
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
https://wiki.deb
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,
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 literal
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
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 t
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 Sat, Jun 4, 2016 at 12:30 AM, Christian Seiler wrote:
> Well, you could add a custom target to debian/rules that calls
> help2man for all these scripts - so that you as a maintainer
> can refresh the manpages every now and then. (And store them
> in debian/ in the packaging.) That way, you don
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,
pa
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 reas
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, Apr 8, 2016 at 6:42 AM, Scott Kitterman wrote:
> The only way to reliably know if it can be built is to do so as part of the
> package build, so you should regenerate the binary file and install that in
> your package.
In addition, removing the generated files in `debian/rules clean` an
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? T
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
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 .
1 - 100 of 223 matches
Mail list logo
