Hello everybody,
as you might have seen on Joey's blog, he expressed some wishes about the
future of dh_python:
http://kitenet.net/~joey/blog/entry/proposed_transition_plan_for_removal_of_dh_python_from_debhelper.html
As I can understand him, we really should respect his wish. If Matthias agrees,
Hi,
On Tue, 22 Aug 2006, Floris Bruynooghe wrote:
> > The changes needed in dh_pysupport are trivial. As of version 0.4, it
> > handles dependencies in more cases than dh_python, and does it only if
> > debian/pycompat isn't found. The only thing to do is to remove this
> > check.
> >
> > I also
Hi,
On Wed, 23 Aug 2006, Ian Ward wrote:
> I am hoping to get svn access to python-modules so that I can help to
> maintain the Urwid and Templayer packages. My Alioth account is
> wardi-guest.
You have been added to the project. You'll have access tomorrow.
Cheers,
--
Raphaël Hertzog
Premi
Hi,
On Fri, 25 Aug 2006, Floris Bruynooghe wrote:
> AIUI debian/pycompat is not needed anymore currently as dh_python has
> enough by having the XS-Python-Version field, while if you are using
> python-support dh_python is not used at all anymore so it doesn't need
> the debian/pycompat anymore ei
On Fri, 25 Aug 2006, Pierre Habouzit wrote:
> debian/pycompat is needed if you want dh_python to do the substitution.
> You also can (atm) use dh_pysupport do it alone, in that case you must
> not use debian/pycompat, neither dh_python.
If someone really wants to use dh_pysupport to generate the
On Mon, 28 Aug 2006, Adeodato Simó wrote:
> * Brian May [Mon, 28 Aug 2006 13:22:55 +1000]:
>
> > Adeodate> Also, do you remember having root
> > Adeodato> bzr as root?
>
> > Huh?
>
> Sorry, that should have read: "do you remember having *run* bzr as root".
> It's the most likely cause fo
On Sun, 03 Sep 2006, Steve Langasek wrote:
> On Sun, Sep 03, 2006 at 11:38:19PM +0200, Julien Danjou wrote:
> > Suggested packages:
> > python-doc python-profiler
> > The following NEW packages will be installed:
> > python-minimal
> > The following packages will be upgraded:
> > python
> > 1
On Mon, 04 Sep 2006, Steve Langasek wrote:
> > Pyversions is mainly used at build-time and not at installation time.
> > Whatever requires pyversions (and in this case python-gnome2) should be
> > depending on the first version of python that provides it (and now the
> > good question: how do you d
On Wed, 20 Sep 2006, Kevin Coyner wrote:
> Hello
>
> I'd like to join the python-modules packaging team.
>
> I've just sent out a RFS for the package 'rls' and also already
> maintain 'htmlgen', both python packages. I also have another
> python related package in the pipeline.
I looked at rpl
Context for debian-python: we're deprecating dh_python on Joey's request
and thus move the logic of substvars generation into
dh_pycentral/dh_pysupport. debhelper/python-central/python-support will
be jointly uploaded in 2 days (the packages are in DELAYED/2-days right now)
to make that happen.
We
On Mon, 23 Oct 2006, Matthias Klose wrote:
> With zope2.8 removed, the last package depending on python2.3 is gone,
> so we are technically able to drop the support for python2.3. As
> currently some packages have reverse dependencies on python2.3,
> removing python2.3 without any other action, wo
Hi,
On Thu, 30 Nov 2006, Daniel Schepler wrote:
> > This is the normal behaviour of the package since in sid python2.3 is no
> > more marked as supported in /usr/share/python/debian_defaults ...
>
> It seems to me that it's a bad idea to make this change in sid while the old
> python packages ar
Hello,
On Wed, 06 Dec 2006, Sanghyeon Seo wrote:
> My crystal ball, eh, my package tracker told me, that there are many
> outdated Python-related packages in Debian. I filtered false
> positives. (e.g. version parsing got it wrong, version packaged in
> Gentoo/FreeBSD is alpha/beta, etc.)
>
> htt
Hello,
On Fri, 08 Dec 2006, Mikhail Gusarov wrote:
> RH> If anyone updates some of theses packages, please invite the maintainers
> RH> to join the "Debian Python Modules Team".
> RH> http://python-modules.alioth.debian.org
>
> Please add me. My python-openid, python-yadis and python-urljr are
Hi,
On Fri, 12 Jan 2007, Oleksandr Moskalenko wrote:
> I'd like to join the PMPT. My alioth login is "malex".
>
> Python-related packages that I maintain include beaker, myghty, myghtyutils,
> pydb, pylons, quixote, and webhelpers.
You have been added. Welcome to the group!
We really need some
Hi,
On Sat, 13 Jan 2007, Thomas Viehmann wrote:
> Raphael Hertzog wrote:
> > We really need some more DD who could help sponsoring, for example Ian
> > Ward seems to have trouble finding sponsors for his urwid package.
> It seems somebody else picked up urwid.
>
> I&#x
Hi,
On Tue, 27 Feb 2007, Romain Beauxis wrote:
> Hi all !
>
> I have packaged yesterday two small python modules for interfacing with
> memcached. This was required by a colleague on one of our project.
>
> One is a pur python project and the other one a binding for the C library,
> said
Hi,
On Wed, 14 Mar 2007, Ben Finney wrote:
> Howdy all,
>
> I'm writing an application[0] in Python, and am nearly at the point
> where I want to package it. I need to do so in a way that's useful to
> me, so that means a Debian package; and useful to anyone using Python,
> so that means a Python
Hi,
On Wed, 14 Mar 2007, Tristan Seligmann wrote:
> I'd like to be added to the PMPT project on Alioth; my account name is
> mithrandi-guest. I'll probably be comaintaning various Divmod packages
> with Stefano Zacchiroli.
You have been added.
Cheers,
--
Raphaël Hertzog
Premier livre français
Hi,
On Thu, 15 Mar 2007, Ben Finney wrote:
> > Check the part concerning eegs.
>
> The page says:
>
> Adding "egg support" is only required in some specific cases: when
> another software uses the python module via an egg and when this
> egg support is not yet integrated upstream."
>
On Thu, 15 Mar 2007, Josselin Mouette wrote:
> Le mercredi 14 mars 2007 à 09:48 +0100, Raphael Hertzog a écrit :
> > > I have some idea about doing each of those, but no real clues about
> > > packaging for both Python's Cheeseshop and a Debian package
> > > s
On Mon, 19 Mar 2007, Ben Finney wrote:
> Searching for information about this, I've seen references to
> 'packagename.substvars' that should be created during package
> building. What is it that should be creating these? A missing 'dh_foo'
> command?
dh_pycentral should do it for you... what's the
Hi,
On Tue, 20 Mar 2007, Ben Finney wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> writes:
>
> > On Mon, 19 Mar 2007, Ben Finney wrote:
> > > [dpkg-gencontrol complains about unknown substitution variables]
> >
> > dh_pycentral should do it for you...
>
On Tue, 20 Mar 2007, Ben Finney wrote:
> > > and 'dpkg-gencontrol' complained about every one of those.
> >
> > This is a misfeature of dpkg-gencontrol.
>
> Is 'dh_gencontrol' not useful then? If not, why is it in the
> boilerplate created by 'dh_make'? If it is useful, what am I doing
> different
On Tue, 20 Mar 2007, Ben Finney wrote:
> > > > what's the content of the package ?
>
> Pure Python modules, which should be installed to the system
> site-packages for use by the application.
No the package doesn't contain that, only those files:
drwxr-xr-x root/root 0 2007-03-19 23:31 ./
On Tue, 20 Mar 2007, Josselin Mouette wrote:
> Le lundi 19 mars 2007 à 23:44 +0100, Raphael Hertzog a écrit :
> > === modified file 'debian/rules'
> > --- debian/rules2007-03-19 06:44:04 +
> > +++ debian/rules2007-03-19 22:37:56 +
> >
On Tue, 20 Mar 2007, Ben Finney wrote:
> Part of that target is to rename the generated egg-info directory;
> Setuptools creates it as 'foo-N.M-pyX.Y.egg-info', but the
> python-central documentation seems to indicate this should be renamed
> to 'foo.egg-info':
>
> # install only one Egg dir (
On Wed, 21 Mar 2007, Ben Finney wrote:
> How should the Debian packaging files interact with this? Examples
> I've seen for using python-central have the egg being built in the
> Debian-specific debian/rules targets, but this is clearly duplication
> if the upstream Makefile already builds an egg.
On Wed, 21 Mar 2007, Raphael Hertzog wrote:
> On Wed, 21 Mar 2007, Ben Finney wrote:
> > How should the Debian packaging files interact with this? Examples
> > I've seen for using python-central have the egg being built in the
> > Debian-specific debian/rules ta
Hello,
On Thu, 05 Apr 2007, Michel Casabona wrote:
> Hello,
>
> I'd like to join the team to maintain the python-hachoir packages that I
> build,
> which will be soon uploaded to debian (thanks a lot to Piotr Ożarowski),
> and help maintaining other packages if possible.
You have been added. We
On Sun, 24 Jun 2007, Bernd Zeimetz wrote:
> that would mean I'd have to checkout all modules, I wanted to avoid
> that.
BTW, I discovered that there might be a way to checkout everything out of
trunk without extracting tags and branches. The idea would be to have a
directory all-packages with
Hello,
this mail is crossposted to two mailing lists. Please reply only to the one
that concerns you (perl or python team).
The collab-maint project gives write access to all DD by default using
ACL (see man setfacl and getfacl).
$ getfacl /svn/collab-maint/
[...]
group:Debian:rwx
[...]
default:g
Hello Brett,
I was looking for some OpenID support in Django and found out
http://code.google.com/p/django-openid/
Would you be interested in packaging this ?
Also, given the long time between two stable releases of Django it might
be worth packaging development release in experimental. What do
On Thu, 26 Jul 2007, Raphael Hertzog wrote:
> Hello,
>
> this mail is crossposted to two mailing lists. Please reply only to the one
> that concerns you (perl or python team).
This warning is still valid. :-)
> As an Alioth admin, I can add those ACL. However I'd like to hav
Hi,
On Tue, 04 Sep 2007, Toshio Kuratomi wrote:
> I'm revising the Fedora Python Guidelines to make better use of eggs and
> saw an interesting bug report against python-docutils that left me
> wondering how Debian had dealt with some of the decisions that I'm
> having to make. If we come out wit
On Thu, 06 Sep 2007, Steve Langasek wrote:
> > > So I myself chose to be among Uploaders and set Maintainer to DPMT,
> > > because this more enforces team work and I like team work.
>
> > I had a discussion on #debian-devel about this, and "they" thought it
> > was pretty stupid to have DPMT as up
On Tue, 08 Jan 2008, Vincent Bernat wrote:
> > What should I be doing about this?
>
> Isuppose thatalintian overrideworks too.Create
> debian/source.lintian-overrides with:
> yourpackage source: package-lacks-versioned-build-depends-on-debhelper 6
debhelper 6 has been up
On Thu, 10 Jan 2008, Yaroslav Halchenko wrote:
> I know that some packages might not yet ship extensions built for 2.5,
> but still, since lenny is targetting python >= 2.5, and unstable is
> unstable, why don't we allow users to experiment a bit and change
> default python on their systems to pyth
On Mon, 14 Apr 2008, Adeodato Simó wrote:
> Finally, and quite importantly, there is what to do with modules that
> have been added to the standard library in 2.5 (ctypes, celementtree,
> wgsiref). These use either pycentral or pysupport, and since they mark
> themselves as for python << 2.5 only,
On Tue, 15 Apr 2008, Adeodato Simó wrote:
> * Josselin Mouette [Tue, 15 Apr 2008 12:28:00 +0200]:
> > The solution is really simple, just add them to python’s Provides: list.
>
> Plus, uhm, can't really be done for (c)elementtree, since python 2.5
> provides the modules under a different name/name
Hi,
On Fri, 18 Apr 2008, Vincent Bernat wrote:
> Could someone with appropriate rights remove my account bernat-guest and
> add bernat instead?
Already done by Piotr apparently.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-de
On Mon, 16 Jun 2008, Ben Finney wrote:
> What's causing this, and how can I fix it so it doesn't have this
> unexpected extra dependency?
It's because dh (from debhelper 7) will use dh_pysupport by default
if it's available.
Just use what debhelper uses by default or make sure to skip
that script
On Sun, 28 Sep 2008, Chris Lamb wrote:
> Raphael Hertzog wrote:
>
> > Do you plan to maintain the various Django related packages in the
> > python-modules team ?
>
> I'm open to persuasion on this, otherwise no.
Well, I'm maintaining like you several Djan
On Tue, 23 Dec 2008, Ondrej Certik wrote:
> I am surprised I am actually the 6th most active. Pretty cool. :)
I am surprised to still be in the top 10 (hertzog)… it means the team is
not so active as one would expect. :-)
Anyway, I'm fine with git as well but I'm not convinced it's that
important
Package: python-syck
Version: 0.61.2-1
Severity: serious
The package uses python-support but does not depend on it.
The dependency should be auto-generated in a substvar, you just have to
add the proper substvar.
Note: the package is unmaintained, someone from the python team should
probably take
On Fri, 18 Sep 2009, Josselin Mouette wrote:
> If there are no objections, I will submit a MBF for those 75 packages in
> a few days.
Go ahead, we have waited too much for python 2.6 already.
Cheers,
--
Raphaël Hertzog
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a
On Thu, 10 Mar 2011, Piotr Ożarowski wrote:
> seriously, THERE WILL BE NO NEW PYTHON 2.X VERSION RELEASED UPSTREAM¹,
> we don't have to worry about 2.X transitions when 2.7 will become the
> only supported one. If you don't like Breaks, I will remove it, it
> really doesn't matter - that's why at t
Hello,
I just uploaded a new version of python-trml2pdf where I removed myself
from Uploaders. I originally packaged this because it's needed for Satchmo
but I never went further to package satchmo. So I have no interest in this
package.
In the mean time it got one reverse dependency, namely kraf
Hi Barry,
On Tue, 28 Jan 2014, Barry Warsaw wrote:
> As the package is supposed to be team maintained, I'm wondering *where* it's
> maintained. I have some patches to fix build failures against Sphinx 1.2.1.
Good question. Luke, are you using git-svn and you forgot to push or
something?
> PS. I
(Please cc me as I'm not subscribed)
Hello,
I have filed 85 bugs against all reverse-deps of python-django
to ask their maintainers to ensure that their packages works well
with Django 1.7 (1). A good chunk of those are maintained or co-maintained
by the Python Modules team, and as usual in a lar
Hi,
On Wed, 23 Jul 2014, Brian May wrote:
> Attempt to summarize the problem: You want to make sure Django 1.7 is never
> installed if there are any apps with Django south migrations that haven't
> been run, and if Django 1.7 is installed you want to make sure django-south
> is not in INSTALLED_AP
[ Please keep me in CC ]
Hello,
I'm one of the python-django Debian package maintainers and I have been
working on preparing the field for Django 1.7... and we have one problem
that we don't know how to handle.
Consider that Debian contains Django but also Django applications using
South. When o
Hi Brian,
On Fri, 25 Jul 2014, Brian May wrote:
> I can't help but think this might be unrealistic (?). Changes required for
> new versions of Django often break compatibility with old versions, and
> 1.4.5 is really old now. Just because many packages don't have versioned
> dependencies on Django
Hi Andrew,
thanks for your quick answer.
On Thu, 24 Jul 2014, Andrew Godwin wrote:
> There is no way around this; it's unfortunate that the packaging situation
> means that Django will get auto-upgraded as part of a distribution upgrade;
> I'm surprised that Debian hasn't had this with packages
On Sun, 03 Aug 2014, Brian May wrote:
> > Django 1.7 final isn't even released upstream, and therefore, downstream
> > projects didn't even try to run against it. There *will* be issues we
> > will have to deal with. 85 packages is quite something. I'm ok, and even
> > welcome to *try* to make it b
Hi,
On Mon, 04 Aug 2014, Thomas Goirand wrote:
> and already found out that TEMPLATE_DIRS needed an additional comma in
> settings.py, though there's still a lot more failure in the unit tests.
> If you want to help, just try to rebuild Horizon (and add a comma as I
> wrote in horizon/tests/settin
Hi,
On Tue, 05 Aug 2014, Matthew Vernon wrote:
> https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-grappelli.git
> https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-stronghold.git
[...]
> Naturally, I'd like to upload these as maintained by
> python-modules-t...@lists.alioth.debian.org. Is that going to
Hi Matthew,
On Wed, 06 Aug 2014, Matthew Vernon wrote:
> Is 1.7 released yet? At least Grappelli only aims to work with released
> versions, so I think it's currently only 1.6-compatible. I'd expect
> 1.7-support to be along once that's been out for a bit.
1.7 will be out in a few days/weeks and
On Thu, 07 Aug 2014, Brian May wrote:
> On 23 July 2014 15:58, Brian May wrote:
>
> > You are expected to do all database migrations with Django 1.6, then
> > upgrade to Django 1.7
> >
>
> Some more thoughts.
>
> Are there any packages in Debian that attempt to automatically do database
> migra
Hi,
I rebuilt all reverse deps of python-django and I tagged confirmed all the
associated bugs where the package failed to build with python-django 1.7
and I sent the relevant extract of the build log...
It makes a total of 31 bugs that will need some attention:
https://bugs.debian.org/cgi-bin/pk
So let me give my own answer to some of the questions asked here.
On Wed, 06 Aug 2014, Dimitri John Ledkov wrote:
> However, it does not integrate with git-dpm at the moment and there is
> no clear conversion / vcs history import available. Do we care about
> preserving vcs history for our package
On Wed, 13 Aug 2014, Piotr Ożarowski wrote:
> [Raphael Hertzog, 2014-08-13]
> > > * old patch needs an update, what should I do?
> > > (quilt edit? quilt refresh? XYZ rebase on a different branch?)
> > > * new patch is needed, how can I add it?
> > >
Hi,
On Tue, 19 Aug 2014, Brian May wrote:
> > For example, I renamed migrations to south_migrations and created a
> > Django1.7 compliant migrations directory, however still get the same error.
Did you fill that new directory with an initial migration generated with
./manage.py makemigrations?
C
Hi Barry,
On Tue, 19 Aug 2014, Barry Warsaw wrote:
> * The egg-info directory is a PITA.
>
> The upstream tarball has a lazr.smtptest.egg-info directory. debuild -S blows
> this away, and then git thinks I want to delete it. It doesn't get staged, so
> it's easy to `git checkout -- lazr.smtptes
On Wed, 20 Aug 2014, Barry Warsaw wrote:
> So, because of the way I've named the branches, the full invocation is:
>
> $ git-buildpackage -S --git-export-dir=../build-area/
> --git-debian-branch=lazr.smtptest --git-upstream-tree=upstream-lazr.smtptest
So --git-export-dir is usally best set in ~/
Hi,
On Thu, 21 Aug 2014, Barry Warsaw wrote:
> Then I `git init`'d a new local repository and used `gbp import-dsc` to
> initialize the git information. That seemed to work just fine.
FWIW, I usually setup the repository on git.debian.org first and then I
clone that empty repository. With this p
On Fri, 22 Aug 2014, Barry Warsaw wrote:
> >Why would you push your temporary branch?
>
> Only because `git push --all` seems like the obvious choice. But I think
> git's cli is akin to quantum mechanics, i.e. don't trust your intuition. :)
Ideal is when a "git push" alone is enough, you can do
Hi Sandro,
On Wed, 27 Aug 2014, Sandro Tosi wrote:
> It seems to me like very vocal Git fanatics, who refuse to touch any
> package which is not maintained in Git (-.-), are pushing and pushing
> to that VCS without any clear advantage.
You might dismiss those people but you're speaking of true c
On Wed, 27 Aug 2014, Stuart Prescott wrote:
> > I've done some personal investigation since the BOF, and am preparing
> > some really simple migration scripts, so we can get a feel for what it
> > will look like. My scripts so far (very very simple)
> > git://git.debian.org/users/stefanor/dpmt-migr
On Wed, 27 Aug 2014, Sandro Tosi wrote:
> like true contributors are those using svn right now. and what about
> the majority of contributors now? we should change just because maybe,
> eventually, if we're lucky we'll attract more contributors? saying "I
> won't contribute to your team if you don'
Hi,
On Thu, 28 Aug 2014, Barry Warsaw wrote:
> * There are anomalies when pushing and pulling branches created with g-i-d.
>I get the following errors when I do the initial push:
>
> remote: fatal: Invalid revision range
> ..e14331dcbaf3f097267ca1
On Thu, 04 Sep 2014, Barry Warsaw wrote:
> On Sep 04, 2014, at 04:36 PM, Scott Kitterman wrote:
>
> >Actually, nevermind. That's not the problem you were trying to solve,
> >although you could remove the patch as described and then apply the updated
> >patch at the end of the series.
>
> Yeah, t
On Thu, 04 Sep 2014, Barry Warsaw wrote:
> Even with those complaints, git-dpm feels like the better tool for team
> package management in git. The problems are minor and probably easily
> fixable.
>From my point of view, since you're anyway using features of
git-buildpackage, it would be better
Hi,
On Tue, 09 Sep 2014, Brian May wrote:
> Can I please get the following change in python-django git?
>
> Add the following to debian/control:
>
> X-Python-Version: >= 2.7
>
> This will make backports to stable a lot easier. Otherwise the package
> builds fine, but won't install in Python 2.6
Hi Brian,
thanks for those investigations!
On Thu, 11 Sep 2014, Brian May wrote:
> Note that I have explicitly called python. This ensures Python 3 not used
> (not supported by South + the virtualenv is Python 2 only) and that we get
> the python from the virtualenv.
>
> I have tested this and i
Hi,
On Sat, 13 Sep 2014, Thomas Goirand wrote:
> I think we should all focus first on the Python Team modules, and see
> where that leads us. Also, to me, considering the amount of remaining
> bugs without a single reply, it's too early to upload Django 1.7 to Sid.
> Raphael, do you still plan to
Hi,
On Fri, 12 Sep 2014, Zygmunt Krynicki wrote:
> I wrote large parts of lava-server and both of the django- packages
> here but I'm not an active upstream anymore (I cannot commit to those
> repositories, only Linaro folks can) . If anyone wants my help though
> I'd gladly render assistance.
I
Hi,
On Tue, 16 Sep 2014, Brian May wrote:
> On 11 September 2014 16:39, Brian May
> wrote:
>
> > Ok, will look into this tomorrow.
> Just pushed a change.
>
> Unfortunately, had problems testing this because "debian/rules clean"
> removes Django.egg-info/* which is flagged by git-buildpackage a
Hi,
On Wed, 24 Sep 2014, Julian Taylor wrote:
> > Nah. It's a great reason to teach the tool in question to be *way* more
> > reasonable. Who needs a single email per commit? Esp. since the number of
> > actual commits will go way up with increased git usage – feature branches
> > are easy in git,
On Thu, 09 Oct 2014, Sandro Tosi wrote:
> so is there any chance you stop this commit storm madness anytime
> soon? another bunch of >300 commit messages arrive this night
I fixed the default configuration in setup-repository to limit to 20
commits per push as a maximum. And I also limited the
On Thu, 09 Oct 2014, W. Martin Borgert wrote:
> 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.
&
On Fri, 10 Oct 2014, W. Martin Borgert wrote:
> 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
Hi,
On Fri, 10 Oct 2014, Charles Plessy wrote:
> Le Fri, Oct 10, 2014 at 11:11:46AM +0200, W. Martin Borgert a écrit :
> >
> > Where is the repository of the scripts involved? Maybe I have
> > some spare time this weekend... I hope, it's all sh or Python.
> > I forgot all my Perl.
>
> Hi Martin,
Package: wnpp
Severity: wishlist
* Package name: prospector
Version : 0.9.9
Upstream Author : Carl Crowder
* URL : https://github.com/landscapeio/prospector
* License : GPL-2+
Programming Lang: Python
Description : Python code analysis tool
Prospector i
On Wed, 07 Oct 2015, Piotr Ożarowski wrote:
> I assume you all like other ideas, like no team in Maintainer, right?
While I understand the desire to have one identified maintainer for each
package, I don't agree with the rule.
Changing maintainer means changing the flow of information and it is a
Hi,
On Fri, 09 Oct 2015, Brian May wrote:
> We can move the migrated version out of the way, restore the old version,
> and update it to the required standards (e.g. git-dpm). Is everyone happy
> with this approach?
Yes, except for the naming of branches where I would prefer to keep
the DEP-14 na
On Sun, 11 Oct 2015, Brian May wrote:
> What branches do I need to put the debian/README.source file in? There are
> six debian/* branches, don't think it is a good idea to try and maintain a
> consistent debian/README.source in all branches.
>
> Maybe debian/experimental would be sufficient? Or p
Hi,
On Sat, 10 Oct 2015, Barry Warsaw wrote:
> >And I would suggest that we generalize the DEP-14 naming scheme as part of
> >our git packaging policy...
>
> I'm all for standardization, but I do like the shorter names for the common
> case where you only need the unstable version. Certainly if
On Sun, 11 Oct 2015, Brian May wrote:
> Just noticed how it named the upstream branches.
>
> * [new branch] upstream-debian/experimental -> upstream-debian/experimental
> * [new branch] upstream-debian/jessie -> upstream-debian/jessie
> * [new branch] upstream-debian/sid -> upstream-debian/sid
>
On Sun, 11 Oct 2015, Brian May wrote:
> Just noticed how it named the upstream branches.
>
> * [new branch] upstream-debian/experimental -> upstream-debian/experimental
> * [new branch] upstream-debian/jessie -> upstream-debian/jessie
> * [new branch] upstream-debian/sid -> upstream-debian/sid
>
Hello,
I just filed 20 bugs on packages that FTBFS with Django 1.8. They have
two weeks to be fixed before we upload Django 1.8 to unstable.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django18
If you maintain a package in the Django ecosystem, pleas
On Tue, 20 Oct 2015, Brian May wrote:
> Barry Warsaw writes:
>
> > Now, in practice, it doesn't matter if you ignore git-dpm and just use quilt
> > *as long as the final state of the repo is compatible with git-dpm*.
> > Meaning,
> > in general, you can make whatever local decisions you want as
On Wed, 21 Oct 2015, Sandro Tosi wrote:
> On Wed, Oct 21, 2015 at 11:01 PM, Brian May wrote:
> > Maybe we should fix #801666 first and then revisit this question?
>
> git-dpm hasnt seen a single line changed since more than a year
> (http://anonscm.debian.org/cgit/git-dpm/git-dpm.git/) so I wont
Hi Piotr,
On Mon, 26 Oct 2015, Piotr Ożarowski wrote:
> How can I improve it? Do you need more detailed description of options?
> Do you need more examples? Or maybe I should hide most of options, the
> "corner case" ones? I focus on making things work out of the box, if
> possible, and make it ve
Hi Sandro,
On Mon, 02 Nov 2015, Sandro Tosi wrote:
> hello,
> with the new DPMT repo layout and tools, what is the right way to
> maintain multiple active branches for our packages? things like:
>
> 1. unstable at v(ersion)3, bpo70 at v1 and bpo8 at v2
> 2. unstable at v1, experimental at v2
>
>
On Wed, 20 Jan 2016, Mattia Rizzolo wrote:
> loggerhead: loggerhead
And that rdep is relatively important since AFAIK we use loggerhead at least on
alioth to browse bzr repositories.
Maybe it's best to invest a bit of time into updating it rather than
dropping it just for the sake of its low popc
On Wed, 23 Mar 2016, Brian May wrote:
> I: pybuild base:184: PYTHONPATH=. python3.5 /usr/bin/django-admin test
> --settings=tests.settings
^
> File "/«PKGBUILDDIR»/pipeline/compressors/slimit.py", line 12, in
> compress_js
> from slimit import min
On Wed, 23 Mar 2016, Brian May wrote:
> Looks like slimit doesn't support Python3 and hasn't had an upstream
> release since 2013-03-26.
>
> Any suggestions where to go from here?
>
> Maybe hack pipeline to disable the failing test? I think pipeline can be
> configured to use jsmin instead of sli
On Wed, 10 Aug 2016, Nikolaus Rath wrote:
> I don't believe that switching from git-dpm to git-buildpackage is going
> to make things easier, it'll just be trading one set of problems for
> another.
I don't agree on this. I have been a happy git-buildpackage user for all
my packages. The problem w
Hello Marcos,
On Wed, 23 Nov 2016, Marcos Fouces wrote:
> I am still waiting for an answer. I don't know how to proceed in this case.
You should have subscribed to debian-python@lists.debian.org and you would have
seen that you have to reply to
https://lists.debian.org/20161117075743.i7exf7vmpbi4
1 - 100 of 244 matches
Mail list logo
