On 2024-08-08 08:42, Carsten Schoenert wrote:
> $ gbp import-orig --verbose --sign-tags --pristine-tar
> --upstream-branch=upstream --debian-branch=debian/master
> ~/Downloads/psrecord-1.4.tar.gz
I suggest to use `upstream/latest` as upstream branch.
It spares you separating upstream/latest, upstr
Package: wnpp
Severity: wishlist
Owner: Martin
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
* Package name: python-thumbhash
Version : 0.1.2
Upstream Author : Justin
* URL : https://github.com/justinforlenza/thumbhash-py/
* License
Quoting PICCA Frederic-Emmanuel
:
It install by default the build dependencies. which is not what
peoples are doing when they install the packages.
It should be possible to define the autopkgtest dependencies. This
way we could catch missing dependencies in python-
dependencies.
Is it pos
Hi Piotr,
On 2024-04-15 15:07, Piotr Ożarowski wrote:
> sqlalchemy 2.X currently FTBFS due to a segmentation fault (3.11 and
> 3.12) somewhere in pysqlite:
...
> I will upload to unstable once I figure that one out
Any news on that? Thank you!
(I'm not sure, if I can help with that, unfortunately
Hi Alexandre,
I pushed my changes to debian/master. If you have time to work on
pymodbus (e.g. update disable-failing-unittests.patch), please go on.
I probably can't work on that this week.
Cheers
Quoting Alexandre Detiste :
I ll check back home, but it's most likely I was waiting for SQLAlchemy
2.xx.
Good!
I know for share that one package does wait for SA 2.xx but can t remember
which one.
It looksk
like all but one of the debian/patches are obsolete now?
It seems, that *two* pa
On 2024-04-15 11:38, Alexandre Detiste wrote:
> Le lun. 15 avr. 2024 à 11:20, Thomas Goirand a écrit :
>> The rest of:
>> - pymodbus
>>
>> I don't even know what they do.
>
> Life is better when one does not have to deal with modbus :-)
Yes!
> This package is outdated and need a refresh.
As I s
Quoting Piotr Ożarowski :
sqlalchemy 2.X currently FTBFS due to a segmentation fault (3.11 and
3.12) somewhere in pysqlite:
...
I will upload to unstable once I figure that one out
Perfect! I prefer not to mess with the package, if I don't have to ;-)
Thanks, Piotr!
Quoting Thomas Goirand :
The rest of:
- pymodbus
- sqlalchemy-utc
- wtforms-alchemy
I don't even know what they do.
All that to say: I'm ok at this point if SQLA 2.x is uploaded to Sid
and we move on...
I'll check, if I can update pymodbus, which is some versions behind
upstream. Maybe that
Hi,
are there any news regarding the status of sqlalchemy?
I'm curious, because the next version of gajim will depend on
sqlalchemy >= 2, which is only in experimental right now.
Cheers
On 2024-03-15 14:21, Alexandre Detiste wrote:
> I would pick-up matplotlib I guess, I have some special connection to it,
...
> Help is appreciated, I already cherry picked some commits from Ciel's PR.
I *might* help on this, because we use matplotlib at $DAYJOB, but can't
promise much, as my work
On 2024-02-27 15:15, Thomas Goirand wrote:
> Though indeed, I don't
> think it's reasonable to have a package in the team, but with strong
> ownership. I believe that we should either have a package in the team,
> or not. Period.
I'm in favour of that change, too, but I can live with the current s
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org
Package Name: python-term-image
Version: v0.7.1
Upstream Author: Toluwaleke Ogundipe
License: MIT
Programming Lang: Python 3
Homepage: https://github.com/AnonymouX47/term-image
Descriptio
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org
Package Name: vapid / python3-py-vapid
Version: 1.8.2
Upstream Author: JR Conlin
License: MPL2
Programming Lang: Python 3
Homepage: https://github.com/web-push-libs/vapid
Description: Sim
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org
Package Name: encrypted-content-encoding / python3-http-ece
Version: v1.2.0
Upstream Author: Martin Thomson
License: MIT
Programming Lang: Python 3
Homepage: https://github.com/web-push
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-python@lists.debian.org
Control: blocks 1019277 by -1
Package Name: pickle-secure
Version: 0.99.9
Upstream Author: Stephanos Kuma
License: LGPL-3
Programming Lang: Python 3
Description: wrapper around pickle tha
On 2023-02-22 23:12, Diane Trout wrote:
> | visidata | none | Build-Depends |
There seems to be no versioned depends or similar in the code.
Should be safe, but in doubt ask Anja (upstream).
Cheers
Package: wnpp
Owner: deba...@debian.org
Severity: wishlist
* Package name: py-rnp
Version : 0.1.0
Upstream Author : Daniel Wyatt
* URL or Web page : https://github.com/rnpgp/py-rnp
* License : (under investigation)
Description : Intent to Package [ITP]
Python bindin
Package: wnpp
Severity: wishlist
* Package name: ttconv
Version : 1.0.5
Upstream Author : Pierre-Anthony Lemieux
* URL or Web page : https://github.com/sandflow/ttconv
* License : BSD 2-Clause
Description : library and tool for converting timed text or subtitle
form
Package: wnpp
Severity: wishlist
* Package name: python-aiosignald
Version : v0.3.1
Upstream Author : Nicolas Cedilnik
* URL or Web page : https://git.sr.ht/~nicoco/aiosignald
* License : AGPL-3+
Description : Python bindings for signald
> Interact with the signal
On 2022-08-03 19:57, Felix Delattre wrote:
> So far I have contributed to Debian:
And Felix is also my co-upstream of https://tracker.debian.org/sms4you :-)
Package: wnpp
Severity: wishlist
Owner: Martin
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
* Package name: python-cobs
Version : v1.2.0
Upstream Author : Craig McQueen
* URL : https://github.com/cmcqueen/cobs-python/
* License
n Sprickerhof (jspri...@debian.org) will transfer the package to
the DPT and sponsor me.
I have read the policy [2] and accept it.
Best wishes,
Martin
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007004
[2]:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
On 2021-06-26 02:04, Paul Wise wrote:
> 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 packa
On 2021-05-10 14:00, Andrius Merkys wrote:
> I do not think that slowing down of development is reason serious enough
> to remove a package which is otherwise fine. Or are there other reasons
> that I am not aware of?
I don't have a problem with slow development, but the current
version is probabl
Dears,
trac is a long-time Debian package, uploaded first by Jesus
Climent in 2004. I like the traditional look of Trac and its
climate-friendly resource usage :-)
Now, while Trac is still maintained upstream and has been ported
to Python 3 recently, development slowed down since long and the
cur
On 2021-02-17 02:13, Andrey Rahmatullin wrote:
> Are you asking about testing or stable? Because for stable the "packages
> are either outdated or do not exist" situation is somewhat expected and
> testing is not that interesting case, though even in testing we may have a
> lot of outdated packages
On 2021-02-16 10:17, Bastian Venthur wrote:
> I *wish* I could
> just install everything via the Debian Packaging System, but the reality for
> most relevant Python packages is very different: packages are either
> outdated or do not exist in Debian
Are you talking about many packages? Or only som
On 2021-02-12 10:16, Thomas Goirand wrote:
> I mostly agree to add a metapackage. I just don't agree with the choice
> of package name. It makes our user believe that Python isn't "full"
> without it, and they then may install it when they don't need it to
> consume whatever is packaged in Debian.
On 2020-12-05 19:51, Andrey Rahmatullin wrote:
> On Sat, Dec 05, 2020 at 02:43:44PM +0100, Martin wrote:
> > Package wokkel has changed the dependency from python3-crypto to
> > python3-cryptodome, leading to #975748 and #975770.
> The changelog entry says "Switch to python
Dears,
I'm a little confused about what the correct name for the
binary package python3-pycryptodome should or will be.
Because https://bugs.debian.org/891619 talks about renaming it
and/or providing python3-crypto.
Package wokkel has changed the dependency from python3-crypto to
python3-cryptod
On 2020-07-27 20:18, Sandro Tosi wrote:
> So: let's just make that automatic? Thoughts?
Yes.
On 2020-05-15 17:43, jojo wrote:
> I'd like to join the list because I think my software is a valuable addition
> to the debian universe, my ultimate goal would be to bring it into Ubuntu
> Studio because it is music-related.
Cool! Sounds like a very interesting program, indeed!
Hi Matteo, hi Thomas,
the new version of salutatoi does not need python-feed and
python-xe anymore. AFAIK, there are not other dependencies on
them. Maybe you would like to ask for removal?
If not, remember to update them to Python 3 (currently supported
only in experimental, but still with Python
Quoting Mattia Rizzolo :
Given that the whole stack of packages is scheduled to get out on
2020-02-16, it's more likely that everything will be removed, and then
cssutils will migrate back (and with it everything that will be suitable
to migrate back into testing) at the next britney run.
That'
Quoting Mattia Rizzolo :
I reckon the way forward is to fix those two FTBFS in calibre.
If calibre gets removed from testing on 2020-02-16, the reason
for non-migration of cssutils and removing depending packages
from testing, e.g. gajim, vanishes. Will this work out due to
britneys wisdom? Or
Hi,
at https://tracker.debian.org/pkg/cssutils I don't see,
why the package does not migrate. Some package depend on
cssutils and will be removed from testing soon...
Any idea what's wrong with cssutils?
TIA & Cheers
Quoting Sandro Tosi :
So Jan 1 arrived, what do you think we should do? i didnt see any
progress on the port to python3 upstream; should we start filing RM
for trac extensions/plugins and once they are gone, RM src:trac?
I don't expect a Python 3 version of Trac before a year from now.
Debian,
Hi,
I'm not sure how to interpret this 14799 lines piuparts log:
https://piuparts.debian.org/sid/fail/python-aiohttp-session-doc_2.9.0-2.log
It says "ERROR: FAIL: Installation and purging test."
Any idea what's wrong with the package? TIA!
Cheers
On 2019-11-29 18:13, Nicholas D Steeves wrote:
> IMHO one of the Debian Trac uploaders should post to the #12130 Trac
> ticket informing them of our plan.
I linked to the email of 2019-10-14:
https://trac.edgewall.org/ticket/12130#comment:63
On 2019-11-29 16:24, Sandro Tosi wrote:
> I know it may sound hard, but is it now time to remove trac from
> Debian, and ideally re-introduce it back when it's being ported to
> py3k?
See also:
https://groups.google.com/forum/#!topic/trac-users/5VMI83sbqFs
What would be the alternative?
It would
On 9/2/19 1:18 PM, Martin Kelly wrote:
On 9/1/19 10:07 PM, Scott Kitterman wrote:
On September 2, 2019 4:00:53 AM UTC, Sandro Tosi
wrote:
I would just stop building these. And if the reverse dependencies
have a
py2removal bug itself, then comment in these issues that the
suggested
ame a couple, sagemath and simpy) that
would be then uninstallable, and so on and so forth for all their
rdeps.
Martin, i think for now the only option is to keep the py2 packages
around until we're ready to drop them (ie they have 0 rdeps).
I just checked on packages.d.o and according to it, p
Python 2 versions of these packages (and
invalidate the Suggests/Recommends of these other packages), or should I
instead just document this issue? If I document it, where should this
documentation go?
Thanks,
Martin
On 2019-07-08 10:00, Elena ``of Valhalla'' wrote:
> I don't think it would be accepted by backports, since it goes against
> the requirement that stuff in backports is in testing (and meant to
> remain there when it becomes stable).
I'm not sure, but building an additional binary package from the
On 2019-03-21 00:47, Thomas Goirand wrote:
> Can't you guys just simply give write access to Andreas? What's the
> issue? Why is it taking so long? This really give the feeling the "team"
> is still very much dysfunctional,
Maybe two, three people more can get "owner" permissions?
Hi,
I like to make python-social-auth a transitional package which
installs social-auth-core and social-auth-app-django. Which is
practically the new project by upstream. Or just remove it?
We don't want python-social-auth in buster, do we?
TIA & Cheers
On 2019-02-04 12:14, Raphael Hertzog wrote:
> Anyway, the fact that we have one known user should not forbid you
> to go forward with all this. I will change the Kali infrastructure
> to use something else, most likely buildd and wannabuild.
Or maybe port rebuildd to Python 3?
On 1/26/19 4:56 PM, Scott Kitterman wrote:
On Saturday, January 26, 2019 04:05:50 PM Martin Kelly wrote:
Hi,
I'm attempting to release a new version of my package python-gmpy2 [1]
and am hitting a bug that I can't figure out how to resolve.
Specifically, in the latest version unde
.
Does anyone have some guidance and/or debugging suggestions?
Thanks,
Martin
[1] https://salsa.debian.org/python-team/modules/python-gmpy2
On 2019-01-22 15:02, Julien Danjou wrote:
> I'm not actively maintaining rebuildd for years now. I'm not even sure
> it has still any user. I wouldn't spend time on porting rebuildd nor I
> would let it block it updating web.py.
> Not sure what's the other solution would be (removal?) but if you ha
Quoting Mattia Rizzolo :
On Tue, Jan 22, 2019 at 12:18:09PM +0100, W. Martin Borgert wrote:
I'm going to package the latest git master of web.py¹, because of
Python 3.7 compatibility. It has a new dependency on cheroot², which
has only a Python 3 version in Debian. I could ask Julien to pr
Hi,
I'm going to package the latest git master of web.py¹, because of
Python 3.7 compatibility. It has a new dependency on cheroot², which
has only a Python 3 version in Debian. I could ask Julien to provide a
Python 2 package of cheroot for buster, but I prefer to drop Python 2
support of web.py
hanks for any suggestions,
Martin
Quoting Steffen Möller :
Now, I am tempted to create a package matplotlib3 instead of forcing
everyone to update from this long term release (see
https://matplotlib.org/).
Any opinions from your sides?
I wonder, whether it's easier to wait for buster and then create an
orange backport? I'm
On 2018-08-03 10:08, W. Martin Borgert wrote:
> On 2018-08-03 08:04, Simon McVittie wrote:
> > There is no upstream/master, upstream/unstable, upstream/stretch or
> > similar in DEP-14, because:
>
> I did not suggest mingling upstream branches with Debian
> versions
On 2018-08-03 08:04, Simon McVittie wrote:
> There is no upstream/master, upstream/unstable, upstream/stretch or
> similar in DEP-14, because:
I did not suggest mingling upstream branches with Debian
versions, which seems to be your impression. I just (maybe
wrongly) thought, that upstream/master
On 2018-08-03 04:33, Scott Kitterman wrote:
> On August 3, 2018 3:51:00 AM UTC, "W. Martin Borgert"
> wrote:
> >How about changing "upstream" to "upstream/latest" (for upstream
> >releases, typically for unstable) and "upstream/mas
On 2018-08-03 11:06, Ondrej Novy wrote:
> 2. change default branch to debian/master
How about changing "upstream" to "upstream/latest" (for upstream
releases, typically for unstable) and "upstream/master" (for
following upstream master, typically for experimental)?
(https://python-modules.alioth.debian.org/python-modules-policy.html),
as stated in https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin,
but the link is dead.
Thanks,
Martin
Dear team,
https://wiki.debian.org/Python/GitPackagingPQ#Git_Branch_Names
states:
"we are strongly recommending you use DEP-14 style branch names"
and below:
"upstream - The un-Debianized upstream source."
I ask to change the latter branch name to "upstream/latest",
first, because that's what
Quoting Nguyễn Hồng Quân :
Python 3.6 has much better performance than Python 3.5, especially on
embedded computer (I tried and compared).
This is interesting! Did you also compare Python 2.7 with 3.5/3.6?
I'm looking for more reasons to finally port my embedded software :~)
Quoting Nguyễn Hồng Quân :
We write an application which needs Python 3.6.
Could you elaborate, why you need Python 3.6 instead of 3.5?
Maybe there is a way to make your application work with 3.5?
E.g. by backporting specific modules?
Quoting Thomas Goirand :
Which is why I think we should have standardize on python-foo for the
source package (which is what I do).
Same here, even if foo is not yet taken.
Save the environment, do not pollute the global packages namespace! :~)
On 2018-03-12 23:15, Thomas Goirand wrote:
> But what now that python-foo is gone? Should I rename the doc package?
No, but that's just my gut feeling.
Quoting Simon McVittie :
In python-mpd-doc and python-dbus-doc, I installed the real documentation
files in /u/s/d/python-*-doc, but placed symlinks to them in both
/u/s/d/python-* and /u/s/d/python3-*. Perhaps that's a reasonable way
to achieve the spirit of the Policy §12.3 recommendation while
Hi,
policy (12.3) says, that putting the contents of package-doc
into /usr/share/doc/package/ (main package) is preferred over
/usr/share/doc/package-doc/. debhelper detects the Python 2
package as main package. One can override this to the path for
the Python 3 package, but both feels wrong to me
On 2018-02-24 23:49, Stefano Rivera wrote:
> 'trac-batchmodify',
> 'trac-git',
The functionality of those two is now part of trac itself.
We might want to keep them for LTS purposes until they are not
part of any LTS release anymore. But I don't care much...
Quoting Stefano Rivera :
I didn't get much review last time, but there did seem to be a general
+1
From me not only "+1", but also "thank you"!
Hi,
if I have a Python program, that currently is not yet maintained
by PAPT, but want to move it to the team: May I use
salsa.d.o/python-team/applications/ now? Any objections?
TIA & Cheers
Quoting Ondrej Novy :
2018-02-08 10:14 GMT+01:00 Ondrej Novy :
I created team "python-team" in salsa with 3 subgroups:
interpreter
modules
applications
OK.
I can do DPMT GIT migration, but I need agreement on new structure.
OK! :~)
We can merge two subgroups later.
No need to merge t
On 2018-02-07 09:58, Matthias Klose wrote:
> I don't think that is a good idea. Both teams are not very active when it
> comes
> to address RC issues and updating to new upstream versions. From my point of
> view the apps team is worse than the modules team in this regard.
In fact, this is one
Hi,
how about moving the Python team(s) to salsa?
And how about merging the modules and apps teams into one?
Moving git packages (modules team) is very easy using
import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git
Moving svn packages (apps team) is probably more work.
Any opinions?
On 2017-10-27 17:26, Angel Abad wrote:
> Because there is no official release with these changes, I will
> write upstream developer and I will tell you.
Was there any outcome? TIA!
Hi,
unfortunately, I had to orphan some packages:
python-activipy -- implementation of ActivityStreams 2.0 (#882871)
python-mpld3 -- D3 viewer for matplotlib (#882858)
python-mplexporter -- general matplotlib exporter (#882857)
python-odoorpc -- pilot Odoo servers through RPC (#882870)
python-oer
On 2017-10-27 17:26, Angel Abad wrote:
> Because there is no official release with these changes, I will
> write upstream developer and I will tell you.
Very good, thanks! You can reach him via xmpp:ral...@ik.nu
> I you want to co-maintain wokkel package we could talk about it.
Well, it is not t
Hi Angel and team,
would you mind, if I update wokkel and close #735304 (teams git
repo) and #879712 (Python 3 support)? I would add myself to
uploaders, too.
TIA & Cheers
signature.asc
Description: PGP signature
On 2017-10-02 10:37, Thomas Goirand wrote:
> On 10/01/2017 11:50 PM, Matthias Klose wrote:
> > Do you want point users to the five year lagging behind eclipse package in
> > Debian?
>
> Why 5 years? We do release stable approx every 2.5 years...
5 years minus 12 days:
Eclipse 3.8.1 has been uploa
On 2017-10-01 23:16, Andrey Rahmatullin wrote:
> On Sun, Oct 01, 2017 at 04:52:55PM +0200, W. Martin Borgert wrote:
> > I usually start to use software, when it arrives in Debian.
> > Or I package it. If there is some snap or other third party
> > package, I'm
On 2017-10-01 17:16, Ghislain Vaillant wrote:
> Most likely a lot. We are talking about a large application with probably
> quite a few dependencies in Java / Kotlin.
>
> Why not? Because failure to commit to regular updates would feed the
> current narrative that Debian ships old and loosely maint
On 2017-10-01 08:26, 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 usually start to use software, when it arrives in Debia
On 2017-09-24 10:35, Diane Trout wrote:
> What do people think about having documentation only packages?
Good thing. Like manpages etc.
signature.asc
Description: PGP signature
On 2017-08-26 11:42, Dmitry Shachnev wrote:
> https://codesearch.debian.net/search?q=html%2Fobjects%5C.inv+path%3Adebian%2Fpatches%2F.*
I should use codesearch more often :~)
And "searx" should have a backend for it!
On 2017-08-25 22:36, Tristan Seligmann wrote:
> In the case of Python's documentation inventory specifically, this is built
> and distributed in the python*-doc packages, and there should be no need to
> download it from python.org.
Thanks! I use the packaged file now in python-simpy3.
AFAIK, only
Hi,
I believe that a small number of Python module doc packages use
binary Sphinx inventory (.inv) files during build, that are just
downloaded from python.org by the package maintainer. I don't
know anything about Sphinx nor how to encode/decode .inv files.
https://pypi.python.org/pypi/sphobjinv
Hi team,
pysolar upstream version 0.7 dropped support for Python 2, so I
did not upload it for stretch. I'm considering upload for buster
now. What do you think?
Cheers
signature.asc
Description: PGP signature
Quoting Dominik George :
at Teckids, we are about to start using Django CMS for our website.
We have a policy to only use Debian stable/main if at all possible.
This is a very useful policy!
So I wonder whether there is a reason django-cms is not in Debian?
(Apart from "noone started maintai
Many thanks, Stefano, for your work on this!
On 2017-05-31 20:58, Stefano Rivera wrote:
> * trac-batchmodify: OK
> * trac-git: missing a tag [DONE]
Those two are only in oldstable.
Not sure whether it is worth to migrate them at all.
> * trac-privateticketsplugin: missing some tags [DONE]
This
Typo: it should read moschlar-guest
Am 27.12.2016 um 11:50 schrieb Christoph Martin:
> Der Python-Apps Alioth project maintainers,
>
> please give moschlarb-guest access rights to the repositories in
> python-apps. He wants to help maintain together with me nagstamon.
>
>
Der Python-Apps Alioth project maintainers,
please give moschlarb-guest access rights to the repositories in
python-apps. He wants to help maintain together with me nagstamon.
Regars
Christoph
--
Christoph Martin
On 2016-12-24 10:48, Sandro Tosi wrote:
> what's all this? 89 commits? are you pulling commits from upstream
> git? this looks just spam to the mailing list
Sorry, this was not intended. I pulled upstream in fact, but I
was not aware that I was pushing it to our git, too. :~(
Quoting Barry Warsaw :
I'd love to know if there's a Debian-wide policy on such things. E.g. if
"opt-out with informed user consent" was an official policy that we could
clearly point to and reference, it would greatly help provide
guidance to both
Debian maintainers and upstreams.
In the i
ment that you have read
https://python-modules.alioth.debian.org/policy.html and that you accept it.
I read the policy and I'm accepting it.
Thanks
--
Ing. Martin Kratochvíl
On 2016-09-10 17:29, Sandro Tosi wrote:
> in some countries (italy to name one) you would be
> breaking the law accepting emails and not delivering them to the
> recipient.
Same in Germany, AFAIK.
On 2016-08-19 08:19, Sandro Tosi wrote:
> does anyone else agrees with this view? should we clarify that, when
> available, python2 modules must be provided (along with their py3k)?
Yes.
On 2016-08-10 10:18, Thomas Goirand wrote:
> Instead of
> accepting the merge, and resolving conflicts later on, git-dpm goes into
> the rebase conflict mode of Git, and it's often not obvious what to do
> there. Messing-up everything, and restart from scratch (and then iterate
> until done properl
On 2016-08-09 23:28, Daniel Stender wrote:
> On this occasion ... let it be me to start the discussion: let's get into Git
> also for Python Apps soon.
A common VCS for both DPMT and PAPT would be nice, indeed.
(I have been reminded rightfully by both Piotr and Sandro, that
PAPT still uses SVN. C
/options
>extend-diff-ignore = "^[^/]*[.]egg-info/"
>
>and keeping .egg-info here.
>
>But if you don't want it here, use dh_clean OR create file debian/clean
>(man dh_clean for complete doc).
I will do that. Thank you both for your quick replies.
Best,
-Martin
--
Martin A. Brown
http://linux-ip.net/
he 'clean' target not the right one? Is there a 'distclean' or
something else I should be using?
Thank you in advance,
-Martin
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822722
--
Martin A. Brown
http://linux-ip.net/
ll imports already says a
lot. New dependencies can still break your module in subtle ways, but
at least things like new/removed Python versions, linker errors, wrong
paths etc. are spotted.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: PGP signature
1 - 100 of 263 matches
Mail list logo
