Hey people,
I wanted to share the Freexian announce that I just published in my blog:
https://raphaelhertzog.com/2022/03/29/join-freexian-to-help-improve-debian/
We are a small team of Debian developers/contributors. We are bound by
our mission statement:
> Freexian's mission is to help Debian e
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-python@lists.debian.org
* Package name: python3-pyupgrade
Version : 2.16.0
Upstream Author : Anthony Sottile
* URL : https://github.com/asottile/pyupgrade
* License : BSD
Programming Lang: Python
Descrip
Hi,
On Wed, 17 Feb 2021, Brian May wrote:
> I believe there are a number of Python packages in Debian unstable that
> are out of date in respect to latest upstream.
>
> e.g.
> https://qa.debian.org/developer.php?login=bam%40debian.org&comaint=yes
>
> Somebody needs to do the work to update them.
On Fri, 12 Feb 2021, Thomas Goirand wrote:
> What I read from Elana, is that *upstream* think we have a problem. But
> do we really have one? Or are we just being influenced by upstream who
> is trying to impose a view we don't necessary share?
Or is it you that is trying to impose your view on th
Hello Andrius,
On Fri, 16 Oct 2020, Andrius Merkys wrote:
> Recently cherrytree [1] has been rewritten from Python to C++, thus it
> no longer belongs in DPT. Could someone with adequate permissions
> transfer it from DPT to generic Debian group on salsa.d.o?
> Alternatively, one could grant me pe
[ Putting Jelmer in copy ]
On Sun, 19 Jul 2020, Sandro Tosi wrote:
> On Sun, Jul 19, 2020 at 11:04 AM Raphael Hertzog wrote:
> > On Fri, 10 Jul 2020, Sandro Tosi wrote:
> > > The checks i have in mind for now, are:
> > >
> > > * pristine-tar bra
Hi,
On Fri, 10 Jul 2020, Sandro Tosi wrote:
> The checks i have in mind for now, are:
>
> * pristine-tar branch must exist, if not -> it's a bug
> * pristine-tar + upstream branch must produce the same tarball as
> downloaded from the archive, if not -> it's a bug
> * bonus point: fix the repo if
Hello Mattia,
On Sun, 24 May 2020, Mattia Rizzolo wrote:
> On Sat, May 23, 2020 at 05:03:50PM -0700, debianb...@felinefamily.org wrote:
> > The package maintainer, Arnoud Fountaine uploaded the fix to the last
> > bug a week or so ago but it’s been stuck in the NEW queue ever since.
> > Is there a
On Mon, 11 May 2020, Sandro Tosi wrote:
> when i push i always do
>
> $ git push --all ; git push --tags
To push only branches which are shared on both sides and the associated
tags I use this:
$ git push origin : --follow-tags
Which I alias as "git dpush" so I have this in ~/.gitconfig:
[alias
On Fri, 06 Dec 2019, Louis-Philippe Véronneau wrote:
> On 19-12-06 04 h 34, Jonathan Carter wrote:
> > For other MRs, I noticed that many small changes in the packaging didn't
> > have an associated changelog entry with it, so I had to dch to add a
> > changelog entry. I think for small changes I'd
Hi,
On Sun, 15 Sep 2019, Louis-Philippe Véronneau wrote:
> For step 1, I proposed we use the "Salsa Pipeline" [1], as I feel it is
> the most mature solution, has more contributors and has more features
> (including reprotest and piuparts). This option seems to have had the
> most support so far.
Thanks for leading this!
Cheers,
> On September 1, 2019 9:43:33 AM GMT+09:00, Matthias Klose
> wrote:
> >On 01.09.19 01:59, Norbert Preining wrote:
> >> Hi Raphael,
> >>
> >> @Matthias, please read on.
> >>
> >> On Sat, 31 Aug 2019,
Hi,
On Sun, 01 Sep 2019, Norbert Preining wrote:
> Fine with me. If you could give me DPMT membership on salsa I can push
> my current work there.
I can't grant you the right to the whole group (I'm not an owner) but
I created the repository and granted you the rights on this repository
at least:
Hello,
On Sat, 31 Aug 2019, Norbert Preining wrote:
> I would be interested in adopting mechanize if the current maintainers
> / uploaders are fine with it. Or we put it into the python modules team
> and I do the stuff there. All is fine for me.
I would like to see the package in the python modu
On Sun, 25 Aug 2019, Dmitry Shachnev wrote:
> The correct procedure is running “gbp pq import” *before* importing a new
> tarball. Then after importing you do “gbp pq rebase”.
>
> Sometimes I myself forget to run “gbp pq import”. In this case I do the
> following:
Instead you should use "gbp pq i
Hi,
On Tue, 22 Jan 2019, Julien Danjou wrote:
> I'm not actively maintaining rebuildd for years now. I'm not even sure
> it has still any user.
FWIW, the Kali buildd do still use rebuildd.
> I wouldn't spend time on porting rebuildd nor I would let it block it
> updating web.py.
> Not sure what'
Hello,
I'm part of the DPMT and I have already agreed to follow the policy.
However I'm not part of PAPT and I would like to join this team too
because at multiple times I have felt the need to update some packages
in that team and I just skipped doing it because I did not have access
to the git r
Hi,
ccing maintainers of reverse dependencies of python-xlwt. We
switched to a new upstream version (0.7.5 -> 1.3.0) so you might
want to check that your packages are still working with this new
version (rows, python-pandas,
On Thu, 26 Oct 2017, Thomas Goirand wrote:
> I've found out that antlr.p
Hi,
On Mon, 26 Mar 2018, Piotr Ożarowski wrote:
> [Moritz Schlarb, 2018-02-15]
> > please also add my user "moschlar-guest" to the respective Groups on Salsa.
>
> looks like my thread is broken, I cannot find referenced emails. Do you
> accept our policy? Which packages do you want to work on?
O
Hi,
On Thu, 22 Feb 2018, Ondrej Novy wrote:
> 2018-02-22 11:18 GMT+01:00 Drew Parsons :
> > The python group on salsa does not have the button for joining the
> > group (I don't actually want to join the group, but the commits to
> > xhtml2pdf should be pushed).
>
> I'm sorry, but you need to joi
On Thu, 08 Feb 2018, W. Martin Borgert wrote:
> No need to merge the subgroups ever.
> With this structure, it is one team already.
>
> If there nobody objects, we have to:
> - migrate the git archives (you volunteered, thanks!)
- setup the webhook to close bugs
- configure email on pushes
Hello,
On Wed, 07 Feb 2018, W. Martin Borgert wrote:
> how about moving the Python team(s) to salsa?
Definitely!
But we might want to learn from the perl team to structure the
python-team:
https://lists.debian.org/debian-perl/2018/01/msg00039.html
We could then have everything python related in
Hi,
On Thu, 01 Jun 2017, Brian May wrote:
> On 2017-06-01 07:32, Barry Warsaw wrote:
>
> > Let's assume not (which is fine with me; i.e. why adopt git-dpm for PAPT
> > when
> > we know we just want to get rid of it later?). Then i tried to import a new
> > upstream as described here https://wik
On Thu, 01 Jun 2017, Ian Campbell wrote:
> > https://anonscm.debian.org/cgit/python-modules/packages/python-django.git/commit/?id=ded34be
>
> There's a typo in there:
>
> +run tests with “-W errro” when you detect that you are running against the
> ^
Fixed, thanks.
Cheer
On Mon, 30 Jan 2017, Brian May wrote:
> Help in fixing this RC bug would be appreciated. I have forwarded this
> upstream, however need a quick fix for the Debian package (not sure but
> suspect it might be too late for stretch).
>
> Unfortunately, not sure where to start. I don't understand this
On Sun, 29 Jan 2017, Brian May wrote:
> 3. Update debian/source/options with "unapply-patches" (anything else?).
You don't need that. dpkg-buildpackage unapplies them automatically after
the build if it has applied them. If they were already applied before the
build, then it leaves them applied.
Hi,
On Wed, 30 Nov 2016, Scott Kitterman wrote:
> Raphael, do you think that the upstream Django project might be willing to
> make some kind of best practices for naming third party django packages? If
> they did that, then that would give us a basis for Debian maintainers talking
> to their
On Mon, 28 Nov 2016, Scott Kitterman wrote:
> > > Please let me know what you think. I'm open to suggestions on wording.
> > > I'd like to get this done in the next week and do a python-defaults
> > > upload with this and a few minor (non-policy) changes that are pending.
+1 from me. I'm actuall
On Mon, 28 Nov 2016, Piotr Ożarowski wrote:
> [Barry Warsaw, 2016-11-28]
> > Is there any risk of having confusing names because of a conflict between a
> > 3rd party Django module and a Django subpackage? e.g. python3-django-foo
> > vs. python3-django.foo.
> >
> > I'm sure it's a non-issue in pr
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
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
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, 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, 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
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
>
>
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
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
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
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 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
>
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:
> 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 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 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
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
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,
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
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 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
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,
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 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 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 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 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
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
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
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 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'
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
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 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,
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 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 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
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
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?
> > >
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
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
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 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
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,
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
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 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
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
[ 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,
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 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 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
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
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
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
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 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
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 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
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 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
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 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 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, 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
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, 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
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
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
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,
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
1 - 100 of 244 matches
Mail list logo
