Barry Warsaw writes:
> * "PMPT" policy
> http://python-modules.alioth.debian.org/
> git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
Is policy.rst automatically kept in sync somehow in between
python-modules.git and http://python-modules.alioth.debian.org/?
--
Brian May
27;t support git.
Not something that concerns me personally, quilt was starting to become
very painful for me. I regularly ended up forgetting the "quilt add"
operation before editing files, resulting in invalid patches.
--
Brian May
ing master instead of
debian/master, unless you want to maintain seperate branches for Ubuntu
and Debian packages (a level of complexity I prefer not to think too
much about right now...)
--
Brian May
e.g. post-git-migrate?
As a first step, I would suggest deleting the entire "Subversion
Procedures" section. Maybe it could be replaced by a "Git Procedures"
section that has a link to the wiki page?
https://wiki.debian.org/Python/GitPackaging
--
Brian May
On Thu, 15 Oct 2015 at 15:50 Brian May
wrote:
> As far as I can tell version 1.3.6-4 is in testing (not 1.3.6-3 as per
> message), it got into testing 5 days ago, and this version has closed the
> bug.
>
Actually, I may have misread that. Probably only got into testing today,
mayb
Hello,
Can somebody please explain this email? I know it says 2015-11-05, but
looks like it was sent today.
As far as I can tell version 1.3.6-4 is in testing (not 1.3.6-3 as per
message), it got into testing 5 days ago, and this version has closed the
bug.
Is this something I have to worry abou
On Wed, 14 Oct 2015 at 01:31 Stefano Rivera wrote:
> python-django: No control file
> python-django: Not git-dpmmed
>
Suspect it might be getting confused with the different branch names used
here. At least there was a control file when I looked last :-)
Hello,
Why are packages missing from anonscm.debian.org which are on
git.debian.org?
e.g.
https://anonscm.debian.org/cgit/python-modules/packages/django-model-utils.git
https://anonscm.debian.org/cgit/python-modules/packages/django-xmlrpc.git
I note these packages don't have the required VCS-
Just noticed that pypi lists version 0.4.6 as the latest version:
https://pypi.python.org/pypi/django-simple-captcha/0.4.6
However pypi.debian.net lists 0.4.5 as the latest version:
http://pypi.debian.net/django-simple-captcha
Think is is because pypi only has a whl file, no source file. Have f
As far as I know this actually did work despite the complaining about no
parent commit... What does that mean?
git-dpm import-new-upstream --ptc --rebase-patched
../django-model-utils_2.3.1.orig.tar.gz
There were no patches recorded, so merging the new state directly (no
git-dpm rebase-patched nee
git push --tags
Total 0 (delta 0), reused 0 (delta 0)
remote: Sending notification emails to:
python-modules-comm...@lists.alioth.debian.org,
python-django_...@packages.qa.debian.org
remote: Sending notification emails to:
python-modules-comm...@lists.alioth.debian.org,
python-django_...@packages.q
On Sun, 11 Oct 2015 at 13:50 Brian May
wrote:
> Unfortunately debian/sid does not build on sid, the tests fail:
> "IndexError: index 5 is out of bounds for axis 0 with size 2" - I don't
> think this is anything I did. It builds fine on Jessie.
>
Seems Django 1.7.x is
Package: git-dpm
Version: 0.9.1-1
Severity: normal
Trying to add a tag to an new release of a DPMT migrated package I get
the following error:
brian@prune:~/tree/debian/python-modules/django-ajax-selects$ git-dpm
tag
git-dpm: ERROR: tag 'upstream/1.3.6' already exists and differs!
To me this doe
On Sun, 11 Oct 2015 at 10:42 Barry Warsaw wrote:
> What I've done, and it's probably horrible, is to just `git-dpm tag
> --refresh`
> and then `git push --tags --force`.
>
That does look yuck.
If my vague understanding is correct, it seems that git-dpm wants to assign
the tags to the same commi
On Sun, 11 Oct 2015 at 13:50 Brian May
wrote:
> I just converted and pushed these branches to git-dpm.
>
>
Just noticed how it named the upstream branches.
* [new branch] upstream-debian/experimental -> upstream-debian/experimental
* [new branch] upstream-debian/jessie -> upstrea
On Sun, 11 Oct 2015 at 11:40 Brian May
wrote:
> Should we convert all branches to git-dpm? Or forget the branches
> referring to obsolete distributions?
>
> Probably should do these:
>
> origin/debian/experimental
> origin/debian/jessie
> origin/debian/sid
>
I just
Should we convert all branches to git-dpm? Or forget the branches referring
to obsolete distributions?
Probably should do these:
origin/debian/experimental
origin/debian/jessie
origin/debian/sid
Not sure about these
origin/debian/squeeze
origin/debian/wheezy
origin/debian/wheezy-backports
Of c
On Sat, 10 Oct 2015 at 09:55 Barry Warsaw wrote:
> Probably so. I have a checkout of python-django here and it seems to
> already
> be in git. I haven't looked at the converted svn->git repo yet, but I'm
> wondering if what was converted was just old and out of date? I'm pretty
> sure
> it was
On Sat, 10 Oct 2015 at 09:54 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?
>
Have moved the repository back. Should be usable exactly as
On Sat, 10 Oct 2015 at 16:43 Scott Kitterman wrote:
> http://git.debian.org/?p=python-modules/packages/ redirects to
> http://anonscm.debian.org/cgit/python-modules/packages which doesn't show
> a
> repository for django-ajax-selects, so it looks like it's actually missing.
>
I noticed that too.
When I fixed a bug in git:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801208
It put a link to a diff in the bug report:
http://git.debian.org/?p=python-modules/packages/django-ajax-selects.git;a=commitdiff;h=9d026b4
Initially this was coming up with "Internal Server Error". Now it is com
According to the wiki I do this with the following command:
brian@prune:~/tree/debian/python-modules/django-ajax-selects$ git-dpm tag
git-dpm: ERROR: tag 'upstream/1.3.6' already exists and differs!
This wasn't the response I was expecting. I am not sure why it is trying to
change the upstream ta
On Sat, 10 Oct 2015 at 12:18 Ben Finney wrote:
> Now that you already have the remote configured, you can re-configure it
> with:
>
> $ git remote set-url origin git+ssh://
> usern...@git.debian.org/git/python-modules/tools/python-modules.git
>
> where “origin” is the name of the remote, and
On Fri, 9 Oct 2015 at 19:26 Stefano Rivera wrote:
>
> Here:
> https://wiki.debian.org/Python/GitPackaging#Where_do_the_team.27s_git_branches_live.3F
>
>
I seem to have problems with this because my username on my local box is
"brian" however my username on git.debian.org is "bam". There doesn't
a
Hello,
Question is what do we do with Django now the git-migrations have taken
place?
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?
Regards
On Fri, 9 Oct 2015 at 18:58 Stefano Rivera wrote:
> It migrated everything that's in SVN. What happens to the result is up
> to us. We can replace migrated results with existing git packages.
>
Ok, I probably should create another thread to discuss this for Django then.
Also, contrary to the ru
On Fri, 9 Oct 2015 at 19:01 Stefano Rivera wrote:
> Things that need to be looked at:
> http://whiteboard.debian.net/dpmt-git-migration.wb
>
Not sure what the headings mean. "Git packages moved out the way" seems
obvious - and probably exactly what I mentioned before with Django, but
what about
On Sat, 3 Oct 2015 at 00:24 Barry Warsaw wrote:
> 5-Oct - Do one last test run with an updated svn dump. Put the results in
> a
> public place for folks to play with and comment on.
>
> 8-Oct - Assuming no objections or showstoppers, turn off write access to
> all
> of DPMT svn.
>
> 9-Oct - One
On Fri, 9 Oct 2015 at 17:22 Brian May
wrote:
> That is the develop branch. So not in any released version, which is the
> master branch.
>
The tests at the moment are somewhat useless too, still need to be written.
Think the best solution at the moment (unfortunately) is just to di
On Thu, 8 Oct 2015 at 17:12 Robert Collins
wrote:
> Presumably
> https://github.com/crucialfelix/django-ajax-selects/tree/develop/tests
> would be the intent?
>
That is the develop branch. So not in any released version, which is the
master branch.
The develop branch is missing the files in MAN
On Fri, 9 Oct 2015 at 02:06 Stefano Rivera wrote:
> Done. And kicking off the migration now...
>
Great!
Will the migration do packages like python-django?
Just thinking that python-django in subversion is old, and the version in
git doesn't (yet) use git-dpm; you don't want the migration chang
On Fri, 9 Oct 2015 at 08:49 Robert Collins
wrote:
> The reason it's being discovered is likely due to the pattern bugfix
> (also in 3.5) - previously discover couldn't handle directories with
> names tht didn't match the file pattern - and that meant nested test
> suites didn't load right.
>
I g
On Fri, 9 Oct 2015 at 08:16 Robert Collins
wrote:
> But - ajax_select/__init__.py is going to be imported, and thats whats
> erroring. I don't think that this is a 3.5 unit testing change - I
> think its an error importing some bit of django.
>
On 2nd thoughts, I didn't really read that properly
On Fri, 9 Oct 2015 at 08:16 Robert Collins
wrote:
> But - ajax_select/__init__.py is going to be imported, and thats whats
> erroring. I don't think that this is a 3.5 unit testing change - I
> think its an error importing some bit of django.
>
Except there is no errors under Python2.7. If Pytho
On Thu, 8 Oct 2015 at 22:44 Dmitry Shachnev wrote:
> Python 3.4 is still the default version in Debian. We can't do the switch
> at once, so the transition is split into three steps:
>
> 1) Add Python 3.5;
> 2) Make 3.5 the default;
> 3) Remove Python 3.4.
>
> We are currently in the end of first
On Thu, 8 Oct 2015 at 22:44 Dmitry Shachnev wrote:
>
> There was a change in unittest autoloader in Python 3.5. It now tries to
> import the package even if it has no tests. I do not know if it is an
> intended change, or a side-effect of fixing some bug ([1]?). Maybe Robert
> can enlighten us he
On Thu, 8 Oct 2015 at 17:12 Robert Collins
wrote:
>
> Presumably
> https://github.com/crucialfelix/django-ajax-selects/tree/develop/tests
> would be the intent?
>
Blah. I always have this this debate with myself if I should download the
orig.tar.gz from github or from pypi.
Sometimes pypi is mi
On Thu, 8 Oct 2015 at 08:12 Brian May
wrote:
>I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_3.5/build;
>python3.5 -m unittest discover -v
>ajax_select (unittest.loader._FailedTest) ... ERROR
>
>
On second thoughts, wonder what tests it is running. I can
On Thu, 8 Oct 2015 at 08:18 Robert Collins
wrote:
> Probably the discover improvements in 3.5 try using python -m
> unittest2.discover
>
Just trying that now.
I see that there is a python3-unittest2 package - should I be using that
one or the unittest built in Python 3.5?
On Thu, 8 Oct 2015 at 00:32 Thomas Goirand wrote:
> You've only enforced *your own* policy, backed-up by only a small vocal
> minority, taking the rule to the extreme (ie: a few days before the Git
> migration, it's still not ok to start new projects using Git, according
> to you...).
>
Accordin
Hello,
When debugging #801208, I noticed the following output:
dh_auto_test -O--buildsystem=pybuild
I: pybuild base:170: cd /«PKGBUILDDIR»/.pybuild/pythonX.Y_2.7/build;
python2.7 -m unittest discover -v
--
Ran 0
On Tue, 6 Oct 2015 at 18:46 Thomas Goirand wrote:
> This IMO is the same topic as having a Gerrit review system (and not
> just Git) which could do tests on each change of a package even before
> having them committed to our git.
>
Sounds like an interesting thing to discuss/test after we move t
On Tue, 6 Oct 2015 at 09:33 Scott Kitterman wrote:
> Except in this case you not only didn't but then got defensive when called
> on it. If you'd just reacted with something like "Oops, made a mistake,
> I'll
> revert it from svn and ask for it to be removed from experimental."
> (fortunately fo
On Tue, 6 Oct 2015 at 02:49 Barry Warsaw wrote:
> Waiting longer isn't an option IMHO. It's helping to add to the
> dysfunction
> of the team. I will also offer to help if the 3.5 transition gets stuck
> because of the git conversion.
>
Hurry up and break my packages :-)
Do the Vcs-* headers
On Mon, 5 Oct 2015 at 08:54 Stefano Rivera wrote:
> There's a fundamental question to ask here. Do we want to welcome Python
> packages into the team, or do we want to put up barriers and require a
> level of commitment before packages can be brought into the team?
Speaking for myself, I welcom
Package: wnpp
Severity: wishlist
Owner: Brian May
* Package name: python-django-cors-headers
Version : 1.1.0
Upstream Author : Otto Yiu
* URL : https://github.com/ottoyiu/django-cors-headers/
* License : MIT
Programming Lang: Python2 and Python3
On Fri, 22 May 2015 at 07:14 Scott Kitterman wrote:
> I was considering the idea of porting things from ipaddr to ipaddress for
> python2, but there's a lot more of that then there is for ipaddress (which
> is
> up to only two packages we know about).
>
As it is a goal to have everything Python3
On Mon, 27 Apr 2015 at 12:26 mudongliang
wrote:
> Today I try to install a software - youdao dict.
> First I try it in vmware machine: Linuxmint and Ubuntu. It can succeed!
> But when I do it in Debian , it fails ; And the reason is the lost of
> python3-xlib.
> So I search in the web page of Deb
On Tue, 21 Apr 2015 at 14:38 Damyan Ivanov wrote:
> Its description says "static site generator". Sounds a lot like HTTP
> to me, not less than ikiwiki for example.
>
I think you might be getting HTTP confused with HTML.
Both ikiwiki and mkdocs turn files into static HTML files, but neither
sup
On Mon, 20 Apr 2015 at 10:44 Ben Finney wrote:
> What does the package primarily install? Would you characterise the
> work's purpose as:
>
> * web: “Web servers, browsers, proxies, download tools etc.”
>
Doesn't seem applicable, it doesn't do anything with HTTP.
* utils: “Utilities for file/di
CCing: debian-python.
On Fri, 17 Apr 2015 at 21:39 Damyan Ivanov wrote:
> mkdocs is a "static site generator geared towards building project
> documentation". This certainly does not match section "python", which
> is for the python language and libraries.
>
> Please change the section to 'web',
On Sun, 22 Mar 2015 at 02:07 Benjamin Lau wrote:
> Why not wrap avconv and ffmpeg using the Python sh module[1]?
> I was kind of curious about the problem myself so I did an
> implementation of the thumbnail extraction using ffprobe and ffmpeg
> (attached).[2]
>
Thanks for your work. As much a
On Sat, 21 Mar 2015 at 21:21 Etienne Millon wrote:
> You should be able to get metadata using python-enzyme ; not sure
> about what's best to actually extract the thumbnail.
>
Thanks for the suggestion. Unfortunately, enzyme doesn't appear to be able
to cope with my video files (from a Canon 5DM
Hello,
Are there any good libraries in Python, that can get packaged for Debian,
for processing video?
my requirements are simple: I need to be able to generate
a thumbnail of designated size and also tell what the width and height in
pixels of the video; Being able to scale the video would be ev
Package: wnpp
Severity: wishlist
Owner: Brian May
* Package name: python-hammock
Version : 0.2.4
Upstream Author : Kadir Pekel
* URL : https://github.com/kadirpekel/hammock
* License : EXPAT
Programming Lang: Python
Description : Rest APIs python
tly in Debian, and would require somebody to
package it.
So far I haven't packaged it myself because none of my packages require or
use it
python-six seems to meet my needs so far...
--
Brian May
Package: slimit
Version: 0.8.1-1
Severity: important
python-django-pipeline and python3-django-pipeline support using the
slimit Python API directly. As in it contains the following line:
"from slimit import minify"
As such slimit should be packaged as a Python library, and come supplied
with a
i.python.org/pypi/devpi-server
http://pypi.python.org/pypi/devpi-web
http://pypi.python.org/pypi/devpi-client
As each one has its own version number, and presumably its own release
cycle, presumably you should be packaging them as separate Debian source
packages.
--
Brian May
On 14 February 2015 at 09:52, Brian May wrote:
> What should I call the package? mkdocs? Or python3-mkdocs?
>
Thinking about this, I will call the source python-mkdocs, but the binary
package just mkdocs.
As I think the names python-mkdocs and python3-mkdocs imply some sort of
publ
for depending on markdown < 2.5 is for Python 2.6 support, which we don't
care about.
--
Brian May
Package: wnpp
Severity: wishlist
Owner: Brian May
* Package name: python-mkdocs
Version : 0.11.1
Upstream Author : Tom Christie
* URL : http://www.mkdocs.org/
* License : BSD
Programming Lang: Python
Description : Static site generator geared towards
ected in came good.
Not entirely sure this is a bug that needs to be reported, however letting
other people know just in case this isn't something unique to be setup on
this particular computer.
Thanks
--
Brian May
are plugins for [1].
[3] not to be confused with https://github.com/vlsci/karaage/ which is a
fork of [1].
[4] autodetection implemented using
pkg_resources.iter_entry_points('karaage.apps'); so it relies on each
plugin being in a separate distributable.
--
Brian May
es another question of "Why bother?" of which I can't
think of a good answer.
It might be possible to have just a single debian directory for the entire
git tree, have a suspicion that might get complicated however...
--
Brian May
Package: wnpp
Severity: wishlist
Owner: Brian May
* Package name: python-django-audit-log
Version : 0.7.0
Upstream Author : Vasil Vangelovski
* URL : https://pypi.python.org/pypi/django-audit-log/0.7.0
* License : BSD
Programming Lang: Python
Description
terminology from now.
--
Brian May
On 12 December 2014 at 09:48, Ben Finney wrote:
>
> Just about any non-trivial Python package (and some trivial ones) in
> Debian will have many distinct modules.
>
Possibly I am getting my terminology confused.
You're familiar with ‘python-django’, as just one example. Including
> django.contr
everything combined,
or maybe trying to convincing upstream that they shouldn't combine the
(very much related) modules into one source.
(at the present it is still very much alpha and no released version yet)
Thanks
--
Brian May
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
python-django-guardian was RC bug #763222. I believe this is a just a
technical bug in the tests, the actual package should work fine.
However, it means the package won't build.
This in tur
Package: wnpp
Severity: wishlist
Owner: Brian May
* Package name: python-mysqlclient
Version : 1.3.4
Upstream Author : INADA Naoki
* URL : https://github.com/PyMySQL/mysqlclient-python
* License : GPL
Programming Lang: Python
Description : Python
rom
the file supplied by python-configparser?
If it is the same file, you could delete it from python-pies2overrides and
depend on python-configparser.
--
Brian May
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 as
uncommitted changes.
Also d
go
1.7 (e.g. if a Python Team module depends on a non-python team module).
I see you remembered to CC Raphael Hertzog - thanks for that; I totally
forgot.
--
Brian May
On 12 September 2014 12:10, Brian May
wrote:
> Bugs with no response from Debian maintainer (except #755645 with no
> recent activity):
>
[...]
> #760875 [i| | ] [src:django-longerusername] django-longerusername:
> Please fix the package for Django 1.7
>
Possibly this bu
works with Django 1.7
Bugs forwarded upstream (may not get fixed in time for the freeze):
#755585 [i| |↝] [src:dico] dico: Please ensure it works with Django 1.7
#755667 [i| |↝] [src:django-openid-auth] django-openid-auth: Please ensure
it works with Django 1.7
--
Brian May
thon 2.6 stuff that is no
longer relevant, as Python2.6 isn't supported any more. Will remove this
too.
--
Brian May
On 7 August 2014 10:19, Brian May wrote:
> virtualenv --system-site-packages ~/old_django
> . ~/old_django/bin/activate
> pip install django==1.6.5
> pip install django-south
> django-admin --settings=??? migrate --all
>
Calling django-admin like that won't use the vir
Django1.6, I only have tested 1.7
myself.
--
Brian May
y to redo it.
--
Brian May
-- Forwarded message --
From: Debian Bug Tracking System
Date: 9 September 2014 16:06
Subject: Processed: not a django1.7 bug
To: Brian May
Processing commands for cont...@bugs.debian.org:
> user python-dja...@packages.debian.org
Setting user to python-dja...@packages.debian.org (
27; by hand or make the
migrations using Python 3.
Presumably if you use unicode strings everywhere or add the following to
the top of model files, this wouldn't be an issue. Not tested it myself.
from __future__ import unicode_literals
I reported this upstream:
https://code.djangoproject.com/ticket/23455
Thanks
--
Brian May
not 100% confident of the branches - I guess I
should use the debian/experimental branch?
Thanks
--
Brian May
>
As far as I can tell, this problem has been fixed. ftp-master didn't
respond, maybe it come good by itself?
--
Brian May
On 22 August 2014 09:49, Brian May wrote:
> I think the following bug I just noticed is significant. Unless fixed, it
> means that after Django 1.7 is released Debian won't have a Mysql library
> for it that works with Python3.
>
> https://bugs.debian.org/758844
> http:/
posed to python modules, of course), although I don't know enough
> about veusz to say whether this is the case or not.
>
Also, if is an application (as opposed to module/library), there is
probably no point packaging both Python3 and Python2 versions. Pick one,
and package that.
--
Brian May
er.
I am sure there are more reasons, these are the ones that have annoyed me
recently. Unlike some, I am happy to continue using subversion. However I
feel I could do a better, more professional job with git.
--
Brian May
of the problems.
e.g.
https://github.com/brianmay/django-guardian/blob/master/debian/patches/0008-Fix-conflicting-related_name.patch
--
Brian May
On 25 August 2014 15:50, Brian May wrote:
> At the moment, am wondering if maybe this is a Django 1.7 bug.
>
Unless I hear otherwise, I am going to assume this is a Django 1.7 bug:
https://code.djangoproject.com/ticket/23360
--
Brian May
On 22 August 2014 09:49, Brian May wrote:
> I think the following bug I just noticed is significant. Unless fixed, it
> means that after Django 1.7 is released Debian won't have a Mysql library
> for it that works with Python3.
>
> https://bugs.debian.org/758844
> http:/
As an experiment, I imported django-guardian from the *.dsc files to git
using git-dpm, and applied my changes. Not sure if I have got this right,
it was the first time I used git-dpm.
The result is currently at:
https://github.com/brianmay/django-guardian/tree/patched (patched branch).
This is te
I think the following bug I just noticed is significant. Unless fixed, it
means that after Django 1.7 is released Debian won't have a Mysql library
for it that works with Python3.
https://bugs.debian.org/758844
http://bugs.mysql.com/bug.php?id=72542
--
Brian May
On 19 August 2014 18:37, Brian May wrote:
> At which point I ran out of time :-)
>
Ok, did all that. guardian does some "creative" things, am surprised it
works under any version of Django. e.g. defining conflicting DB models, and
only use one of them.
Next error:
Traceback (
On 21 August 2014 10:42, Cyril Brulebois wrote:
> Brian May (2014-08-21):
> > Can somebody please tell me why python-openssl and python3-openssl isn't
> > available in sid?
> […]
> > It appears that the packages produced have changed to architecture
> > depe
thing wrong with my local chroot?
It appears that the packages produced have changed to architecture
dependant packages, seriously wondering if maybe this got DAK confused.
(this problem is preventing me from uploading a fix for an RC bug)
Thanks
--
Brian May
On 19 Aug 2014 18:37, "Brian May" wrote:
>
> On 19 Aug 2014 18:04, "Raphael Hertzog" wrote:
> > Did you fill that new directory with an initial migration generated with
> > ./manage.py makemigrations?
>
> Yes, did that, but than I realized I needed
On 19 Aug 2014 18:04, "Raphael Hertzog" wrote:
> Did you fill that new directory with an initial migration generated with
> ./manage.py makemigrations?
Yes, did that, but than I realized I needed to do testapp.
So I did just testapp by itself, but suspect both django apps need to be
done.
At wh
On 19 August 2014 11:03, Brian May wrote:
> Any ideas how to fix
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755598 ?
>
> I have had a fiddle, but not really making any progress (apart from
> Python3 package which works fine).
>
> For example, I renamed migrations to
ntly working
> on packaging 0.5.1. ;)
>
Seems like I missed those changes. Not sure how. Might be better off
spending my time on django-guardian instead.
--
Brian May
directory, however still get the same error.
Thanks
--
Brian May
$1~$2/,filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/librabbitmq-c-$1.tar.gz/
\
https://github.com/alanxz/rabbitmq-c/releases \
/alanxz/rabbitmq-c/archive/v([\d\.]+)\.tar\.gz
--
Brian May
201 - 300 of 400 matches
Mail list logo
