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 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
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)?
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
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
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
On 2016-01-08 01:54, Scott Kitterman wrote:
...
> This is done (#810306).
...
> Bug#810309: torchat
> Bug#810308: python-sleekxmpp
> Bug#810307: offlineimap
Scott, many thanks for filing the bugs and fixing python-socksipy!
Hi,
TLDR: Both are the same, providing the "socks" module. We should
remove one of them. Maybe renaming the other to python-socks.
Longer story: Recently, I upgraded the outdated python-socksipy
package. This involved following a new upstream. Later I was
informed, that the new upstream was alrea
On 2015-12-13 00:22, W. Martin Borgert wrote:
> If neither Gustavo nor you were interested in CherryPy, I would
> consider putting my name in the Uploaders field. I would
> probably upgrade the package to version 3.8.1 and add a Python 3
> package - we still ship seven year old 2.
On 2015-12-12 21:41, Mattia Rizzolo wrote:
> https://tracker.debian.org/pkg/python-cherrypy
>
> This package, python-cherrpy, is Maintainer: DPMT, but has nobody listed
> in Uploaders.
...
> I'm CCing the former maintainer, since I don't know if he follows this
> list.
If neither Gustavo nor you w
Hi,
just a heads-up email:
I will try to work on some open bugs of python-pyftpdlib,
mainly because I need the Python 3 version urgently.
Janos, if you want me to stop, just say so! :~)
Cheers
Quoting Julien Puydt :
Do you know pristine-tar is orphaned ? (bug #737871)
This is known to readers of this mailing list, e.g.
https://lists.debian.org/debian-python/2014/10/msg00039.html
So far, it just seems to work for (most of?) us.
Cheers
On 2015-10-11 16:49, Christophe Siraut wrote:
> I do not intend to continue maintaining python-django-contact-form, I
> just removed myself from the uploaders field, maintainer is DPMT.
> Tests are currently failing and package fails to build from source.
> Upstream released a new version 3 months
Quoting Piotr Ożarowski :
[Barry Warsaw, 2015-10-07]
* Team in Maintainers is a strong statement that fully collaborative
maintenance is preferred. Anyone can commit to the vcs and upload as
needed. A courtesy email to Uploaders can be nice but not required.
* Team in Uploaders is a weak
Quoting Piotr Ożarowski :
I assume you all like other ideas, like no team in Maintainer, right?
To me, "team maintenance" would mean, that the team appears in the
"Maintainer" field. In "Uploaders" it doesn't make sense, so where
would the team appear?
Personally, I prefer to have the team in
On 2015-09-04 22:44, Diane Trout wrote:
> I've made some limited progress trying to package Bokeh (BSD-3-Clause)
Many thanks for working this!
> I managed to get the version 0.9.1 from pypi installable. (Though since it
> was
> my own experiments I didn't remove the jquery / bootstrap librarie
On 2015-06-17 00:01, Larissa Reis wrote:
> After discussion on this list, I'm making the new simpy version a
> separate package (see thread starting from [1]). I still need a mentor
> to review and a sponsor for the package.
Uploaded. Thanks for working on this package!
I like, that people can mov
On 2015-05-22 19:08, Dmitry Shachnev wrote:
> I think with such a little number of rdepends it's easier to port
> them than to carry two packages.
Yes - at least if we don't expect many people to have locally
installed software depending on python-simpy.
Anybody up to put simpy into git instead o
Hi,
sorry for the late reply:
On 2015-05-02 03:07, Larissa Reis wrote:
> Changes since the last upload:
>
> * New upstream release (Closes: #729866)
> - Simpy 3 API is not compatible with Simpy 2. For information on porting
> from Simpy 2, see
> http://simpy.rtfd.org/en/latest/topic
On 2015-04-15 16:27, Paul Tagliamonte wrote:
> I'd like to send an email to d-d-a asking that project to consider no
> longer creating new Debian tools in Python 2.
Makes sense.
I try to use Py3 whenever possible. Sometimes some libs are still
missing, mainly when upstream is not very active. My
I just now don't have the time to look at bug #775609
(python3-exif doesn't work, RC). If nobody steps in, I would
upload a new package w/o Python 3 support for jessie.
Wheezy hat python-exif, but not python3-exif, so there is no
regression for users of wheezy.
Anyway, upstream made a new release
On 2014-10-12 14:49, Thomas Goirand wrote:
> Let's say there's a few more other people which
> were not accounted for and that were not at Debconf, those who prefers
> having upstream source code in the VCS are still the majority.
And some weren't at Debconf and prefer to work with upstream
source
On 2014-10-10 13:13, Matthias Urlichs wrote:
> Looking at that code, IMHO it should be sufficient to add the arguments
> '--' and 'debian' to all calls of "git revlist".
Who can add this?
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble
On 2014-10-10 10:13, Raphael Hertzog wrote:
> On Fri, 10 Oct 2014, W. Martin Borgert wrote:
> > I assume, that the script uses post-receive, so it has access to
> > all commits, including all affected paths. If so, generating only
> > emails or IRC messages when debian/ is in
On 2014-10-10 15:59, Ben Finney wrote:
> Agreed. This is a direct result of rebasing Debian packaging history
> onto upstream VCS history, and keeping them all in the same repo as one
> undifferentiated history, no?
Not sure, but isn't this more a result of the scripts in use, to
not differentiate
(Please, when using email, choose an appropriate subject. Thanks!)
On 2014-10-09 10:02, Raphael Hertzog wrote:
> I fixed the default configuration in setup-repository to limit to 20
> commits per push as a maximum. And I also limited the size of individual
> commit emails to 1000 lines.
I wonder,
On 2014-09-23 22:29, Sandro Tosi wrote:
> there's some people who's subscribed to the commit ml, so getting all
> the changes done to our repos. Now, with the transition to git we are
> getting this: 135 emails for updating a package (and these are only
> upstream changes). Did you consider this si
On 2014-01-27 00:14, Nicolas Dandrimont wrote:
(a lot)
I agree with everything.
If somebody has time to update "my" packages to modern helpers,
convert them from svn to git, or enable Python 3, please go on!
About git: This needs clarification, e.g. will we settle on gbp?
Shall our branch be "ma
Quoting "Barry Warsaw" :
Sounds a lot like `virtualenv --system-site-packages` right?
IMHO, --system-site-packages should be the default.
IIRC, it was the default in squeeze (1.4.9),
but is not anymore in wheezy (1.7.1.2). Opinions?
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debi
On 2013-09-20 13:52, Paul Tagliamonte wrote:
> It's not about keeping the libraries up to date, it's about keeping the
> applications up to date.
...
> Hell, we shouldn't even introduce a module unless it has an app using
> it.
I tend to disagree here (slightly). Too me, it is very important,
that
On 2013-09-18 09:36, Paul Tagliamonte wrote:
> 1) pip isn't for global package management, for this is stupid. If we
> disabled root use of pip, I think we'd all be a bit happier.
Very quick and very dirty patch attached.
> 4) Python modules from dpkg are borderline useless for developer
Quoting "Matthias Klose" :
Also the platform package manager should be the preferred way to install
packages, not pip, so even a Recommends is a bit strange.
Yes, a "not-recommended" field would make sense here.
As a passionate pip hater I would go for a Conflicts,
which finally would make pip
Quoting "anatoly techtonik" :
On Fri, Oct 14, 2011 at 2:07 PM, W. Martin Borgert
wrote:
...
The Python thing is to how to generate (and regenerate) these install
files? I certainly don't want to create them by hand.
I don't know any automated way to generate install
Quoting "anatoly techtonik" :
What does this testing implies? If there is a reference document on
testing - somebody else may do this. This doc should exists even just
to tell which parts can possibly go wrong as well as history of
previous problems and mistakes. I'm running unreleased 0.6b3 for
Quoting "anatoly techtonik" :
Nice. But how do you create these install files? Can stdeb tool help
with that?
I don't know stdeb, but install files are easyly understood.
See the documenation:
http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install
(We're leaving Python related
On 2011-10-13 21:31, anatoly techtonik wrote:
> There is a long standing bug in trac-bitten [1] to make a spin off a
> bitten-slave package from the same source that will include just slave
> client for running builds, which is independent of Trac [2]. Usually,
> you can build bitten-slave with:
>
Quoting "anatoly techtonik" :
It's 9 months since the patch to upgrade trac-bitten was committed to
Debian repository and it's not packaged yet. Can anybody release it?
Problem is: I can't (currently) test new versions properly - no time.
Second issue: I really want to have two packages: Master
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
Package name: openerp6-web
Version : 6.0.3
Upstream Author : OpenERP
URL : http://www.openerp.com/
License : OEPL (non-free, but relatively permissive)
Programming Lang: Python
D
Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert"
Package name: openerp6-server
Version : 6.0.3
Upstream Author : OpenERP
URL : http://www.openerp.com/
License : AGPL, GPL, BSD, etc.
Programming Lang: Python
Description : Enterpris
Quoting "Éric Araujo" :
Are you sure the full python-setuptools is required, not only
python-pkg-resources?
Look in debian/changelog :~) I replaced python-setuptools
once with python-pkg-resources and had to revert the change.
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
Quoting "Arthur de Jong" :
I've updated the Trac packaging in
svn://svn.debian.org/svn/python-apps/packages/trac/trunk
to 0.12 and done some migration and cleaning up (see debian/changelog
for details).
Btw. could you please remove my now unused path
svn://svn.debian.org/svn/python-apps/packa
Quoting "Sandro Tosi" :
Talk with the current maintainer (which you're not).
In this case it's PAPT. I'm the only Uploader, but happy
about anybody helping with Trac and/or Bitten. Currently
I'm too busy to help with new versions, but if somebody
has time and skills and fun, please go ahead!
Quoting "anatoly techtonik" :
Does that mean that I need to figure out why tarball was repacked and
manually repack it again with the same changes to do new release?
In this case the maintainer (I) was too lazy/sloppy/whatever
to document it properly or add a debian/rules target to do
the repac
On 2010-08-22 12:38, Julian Andres Klode wrote:
> Well, it does not really make sense to use invalid locales, so I see no
> problems if applications exit with a failure. Users should fix their
> environments instead.
It would be nice, if applications would fall back to the "C"
locale and warn abou
Quoting "Paul Wise" :
Actually, is there any generalised syntax, language, deprecation and
mistake checker for python?
There are pychecker, pyflakes, and pylint in Debian.
This specific case raises a warning in pylint, if I'm not mistaken.
--
To UNSUBSCRIBE, email to debian-python-requ...@lis
Quoting will...@agencialivre.com.br:
Looks like the exaile[1] package is very out-of-date.
...
I tried to contact the maintainers of this package without success.
Given that
- the package is really out of date,
- the last three uploads were NMUs,
- Ubuntu has more recent version,
- there are
Quoting "Piotr Ożarowski" :
[W. Martin Borgert, 2010-06-11]
did anyone already put more than one Python source in a Debian
package? I.e. more than one setup.py? Do examples exist? TIA!
Stefano did, see f.e. python-repoze.who-plugins
Perfect, many thanks!
(For those who are curiou
Hi,
did anyone already put more than one Python source in a Debian
package? I.e. more than one setup.py? Do examples exist? TIA!
Cheers
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
htt
Hi,
would it be realistic/possible to have Django 1.2 in Squeeze?
IMHO, it will come too late, because Squeeze will freeze in
March and the Django release in planned for March, 9th...
But maybe other people are more optimistic?
Cheers
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.de
Quoting "anatoly techtonik" :
python-support README [1] contains different instructions for
'arch-all' and 'arch-any' packaged. How do I know which one is mine?
all: Package works on all architectures without (re-) compilation,
e.g. a program written in Python
any: Package needs e.g. comp
Quoting "anatoly techtonik" :
That's not sufficient. To update Trac environment you will need to run
"trac-admin upgrade" and optionally "trac-admin wiki upgrade". The
second point is that web-servers (including Apache) treat symlinks
differently and I am unsure how to setup web permissions corre
Quoting "anatoly techtonik" :
Then we should also patch "trac-admin deploy" command so that it
create symlinks to static resources instead of copies to update user
environments to latest jQuery automaically.
I don't remember, I ever used "trac-admin deploy", and I wonder how
useful it is. It sa
Quoting "anatoly techtonik" :
Is it possible to create symlink on a symlink?
(I am on windows right now - can't test)
Yes.
That's true. Trac was designed to work even without JavaScript, but
Trac plugins are written by community and people often assume that
jQuery is available.
That's why t
Quoting "anatoly techtonik" :
Then why can't you wait until upstream developers, whose product
bundles that library, confirm, validate, test and release fix for that
error in their source package together with release announcement? Also
in the case of Trac/jQuery.
Again, many applications have
Quoting "anatoly techtonik" :
1. Trac is not a package - it's an application.
Inside of Debian, applications, libraries, and many other things
come as "package" as we call it. In Debian, trac is a package.
If there will be a
problem in one of the files that shipped with Trac sources - it is a
Quoting "anatoly techtonik" :
If
you see jquery.js file inside of its source package - why not to leave
it alone - where is the Policy that requires to replace it with some
external copy?
In general, Debian puts a lot of work into finding and removing
embedded code copies. Sometimes, this is no
Quoting "anatoly techtonik" :
Even if most users don't need them, tests greatly increase the value
of bugreports and doesn't bloat python packages too much.
True. What do other people think of the issue?
If unit tests were in the package, reportbug could automatically
run them on a bug report.
Quoting "anatoly techtonik" :
There are more than 200 plugins tagged for 0.11 on
http://trac-hacks.org/ They were developed and debugged with jQuery
1.2.x which is not forward compatible with 1.3.x
Most Trac plugins do not use JavaScript, even less use jQuery.
I don't feel like I
want to chec
Quoting "anatoly techtonik" :
Trac 0.11 ships with jQuery 1.2.6
However, Debian patches remove this file in favor of libjs-jquery
package which contains version 1.3.x
This breaks plugins for Trac 0.11 that rely on 1.2.x jQuery features
removed in 1.3.x
How to properly add dependency for jQuery<1
Quoting "anatoly techtonik" :
Python policy is silent about unit tests. Should they be stripped? Or
should they be Debianized or left as-is?
Just my opinion: Unit tests should be in the source package, but not
in the binary package. Most users don't need them, and if somebody
wants to try them,
1 - 100 of 116 matches
Mail list logo
