d and wonderful ways that I
could not predict.
This isn't so useful for distribution of Python based desktop
applications, but I don't do a lot of that (and probably would be
looking for a good off-the-shelf solution if I did).
--
Brian May
ing in one go. As this
is the only tested upgrade procedure.
--
Brian May
on. Often only the latest version is supported by upstream also.
--
Brian May
the slow NMU process.
--
Brian May
Emmanuel Arias writes:
> Hello I am available to help.
>
> Let me take a look.
Thanks!
Any luck so far?
--
Brian May
never
intended(?).
Unfortunately, even though I am upstream and Debian maintainer, I don't
have any time to look at this.
Help appreciated.
Thanks
--
Brian May
ython3-foo-doc.
I think this makes it very explicit what was intended.
--
Brian May
lied. Trying to guess what you mean ...
pub rsa2048/0xE02B14E5030A2708 2013-10-24 [SC]
Key fingerprint = F11D EE52 6472 1B58 8D5A DE93 E02B 14E5 030A 2708
uid Celery Security Team
sub rsa2048/0x71F0610B99741E57 2013-10-24 [E]
--
Brian May
es-t...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team--- End Message ---
--
Brian May
https://linuxpenguins.xyz/brian/
in this case no patches are required. Not sure I entirely
understand the situation however.
"for a new upstream release of the unreleased" - has it been released
upstream or not?
--
Brian May
r branch, then you can make changes to the debian/* files.
Sorry, I don't have time to try to explain how to fix this right now :-(
--
Brian May
llu...@autistici.org writes:
> Then, I did git push. It was correct? What should I do next? The output
> (see below) suggest to create a merge request.
> Thanks in advance.
Ignore that. That is just the git server providing helpful information
that isn't really appropriate here.
--
Brian May
ved sources from one directory to another.
> In such case, I just edit the patch directly to fix the path. With a git
> rebase, you'd probably have to rewrite all the patch by hand. Here
> again, that's useless trouble.
Yes, that case is harder to deal with.
--
Brian May
(all required
branches, e.g. "git push origin : --tags") after you finish work.
Easy to forget however.
--
Brian May
things could get messy.
I did see it happen from time to time that the previous maintainer would
leave the repository in a weird state that could only be fixed
(unfortunately) with a git rebase.
--
Brian May
ualenvs. Packaged programs in
Debian should be using /usr/bin/python*.
Having said that, I can confirm you are correct, this does appear to be
common.
--
Brian May
Thomas Goirand <z...@debian.org> writes:
> I agree as well. Please file a bug for its removal.
See Bug#897257.
--
Brian May <b...@debian.org>
Package: ftp.debian.org
Severity: normal
Hello,
django-celery is broken, deprecated upstream, and has been replaced by
other packages that are already in Debian, such as django-celery-results
and django-celery-beat.
This was discussed on debian-python, see:
repository), but there are a number of python errors running tests,
and I lack the interest in attempting to fix them (although at quick
glance some of these errors look trivial to fix...)
As far as I am aware, nothing in Debian depends on django-celery.
Any thoughts?
--
Brian May <
solve this problem, but I think it is a necessarily prerequisite
for a solution.
--
Brian May <b...@debian.org>
nstall via "pip3.6".
> For Python3.6, you just need to provide python3.6 (+ its standard lib),
> python3.6-dev.
If using pip to install packages is fine (which can result in compiling
from source although increasing use of wheels helps), then I personally
fail to see the problem with using s
accessing settings.
I believe this bug report, and several others you filled recently that
contain this same text are false.
Like it or not, it is just not possible to import Django libraries
without providing a valid django settings file. This is not a sign that
something is broken.
--
Brian May <b...@debian.org>
the moment each of those pages says that the Python teams have chosen
> the relevant packaging system and that the other packaging system is
> forbidden, which is confusing at best.
Both pages do need updating.
--
Brian May <b...@debian.org>
Robert Collins <robe...@debian.org> writes:
> Yah, packaging permissions are an installation problem, and setup.py
> is (no longer) intended for installation.
Thanks, that is what I thought too.
Have followed up in the bug report.
--
Brian May <b...@debian.org>
Robert Collins <robe...@debian.org> writes:
> Replied on the bug :)
Thanks.
He responded, he is not using pip, but creating a "Void package" from
source.
I am inclined respond, as he is not using pip, he needs to ensure the
permissions are correct.
--
Brian May <b...@debian.org>
projects ;-)
Same here.
I just got a bug report :-(
https://github.com/sshuttle/sshuttle/issues/217
Not really sure what circumstances this causes problems, or what I
should do about it.
--
Brian May <b...@debian.org>
to do on a
continued basis.
Any ideas?
--
Brian May <b...@debian.org>
nnounce/2018/01/msg3.html>
___
Python-modules-team mailing list
python-modules-t...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
--- End Message ---
--
Brian May <br...@linuxpenguins.xyz>
h
documentation
Currently the first two packages are in CollabMaint, and the last in
DPMT.
Does this sound like the right approach?
Regards
--
Brian May <b...@debian.org>
Is the python logo under a license acceptable for including in a Debian
> package? or does it need to be stripped out?
> 2. If it is acceptable for inclusion how should it be documented in
> debian/copyright?
Probably questions for debian-legal, not debian-python...
--
Brian May <b...@debian.org>
systemd[1]: snap-hello-20.mount: Failed to load
configuration: No such file or directory
Oct 15 13:18:47 prune systemd[1]: snap-hello-20.mount: Collecting.
--
Brian May <b...@debian.org>
against it to see if any fail. Although I think I may
have just described a transition anyway :-).
--
Brian May <b...@debian.org>
Michael Hudson-Doyle <michael.hud...@canonical.com> writes:
> Yes. Let's see if I can find some better answers...
Thanks!
--
Brian May <b...@debian.org>
to unstable. However I might be wrong here. In any case, my
research led me to believe the first error *might* be a kernel
issue... I believe my packages to be fine.
The only response I got however was an implied "don't use snap" and "I
personally don't like the concept of snap"
least one of my problems is a Kernel issue in Debian
stable (at least my current theory), however this seems to indicate to
me that snap is still somewhat bleeding edge and cannot be relied on.
--
Brian May <b...@debian.org>
On 2017-09-07 14:54, Scott Kitterman wrote:
> It's a wiki. The resolution of your annoyance is within your grasp.
I had already fixed it. Sorry if I didn't make this clear.
On 2017-09-07 08:42, Scott Kitterman wrote:
> Conveniently, we already decided to switch:
>
> https://wiki.debian.org/Python/GitPackagingPQ
It was annoying me that these instructions were missing the last steps
on how to switch the default branch to debian/master and delete the old
branch.
On 2017-09-07 08:42, Scott Kitterman wrote:
> Conveniently, we already decided to switch:
>
> https://wiki.debian.org/Python/GitPackagingPQ
Worth noting, while there are some big gotchas with git-dpm, there are
also some big gotchas with GPB PQ. GPB PQ isn't a magical solution that
will solve
me for every case, except for the one package
where I hadn't pushed upstream changes correctly beforehand.
The script also includes the correct procedure for converting from
master to debian/master.
--
Brian May <b...@debian.org>
Christopher Hoskin <christopher.hos...@gmail.com> writes:
> What's the plan for moving them to unstable? Are they still using git
> pq rather than git-dpm?
I have updated celery to use git pq. Not done kombu or python-amqp yet
however.
--
Brian May <b...@debian.org>
was going to look at updating vine, kombu and python-ampq this
> weekend, but the upstream tarballs have been signed by a different key
> pair than the one advertised at:
:-(
Please keep me up-to-date on developments.
Thanks!
--
Brian May <b...@debian.org>
ges/jinja2/environment.py", line 430, in
getattr
return getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'page' is undefined
debian/rules:12: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
debian/rules:9: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
--
Brian May <b...@debian.org>
fladischermich...@fladi.at writes:
> I made some changes to the django-filter package in git. Could you check
> if it fixes your issues? Right now 1.0.4-1 builds fine for me with the
> current version of DRF in unstable.
Looks fine to me, uploaded.
Thanks
--
Brian May <b...@debian.org>
ve filters to
allow commit notifications to go throughg.
If you believe that your message should be auto-approved for this
list, please get in touch with
python-modules-commits-ow...@lists.alioth.debian.org.
--- cut ---
--
Brian May <b...@debian.org>
t
parameter?
I believe git-dpm sees you removing a patch and assumes you might be
doing something wrong - so it stops you. However as you know what you
are doing, you should override it.
--
Brian May <b...@debian.org>
in detail why.
* celery: requires cyanide (including docs) and sphinx_celery to be packaged in
Debian.
Thanks.
--
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
me of the patch branch is based on the current branch.
Also note that the "gbp pq import" must be done on patches unapplied
format, so don't go too far back in the history.
--
Brian May <b...@debian.org>
On 2017-06-01 09:16, Simon McVittie wrote:
> but this style (which is a DEP3 invention, and not used outside Debian and its
> derivatives) is not:
>
> Author: ...
> Description: First line of description
> More description
> more description
> yet more description
> Bug-Debian: ...
Might be
On 2017-06-01 09:16, Simon McVittie wrote:
> From: ...
> Date: ...
> Subject: First line of description
>
> More description
> more description
> yet more description
>
> Bug-Debian: ...
> Applied-upstream: ...
> More-DEP3-fields-in-pseudo-header: ...
> ---
> optional diffstat here
>
> diff
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://wiki.debian.org/Python/GitPackagingPQ
Another problem I
kage
not in Debian) - from a quick scan of all my */debian/rules files on my
system - which I think includes all packages I have ever touched.
--
Brian May <b...@debian.org>
, before
installation.
I vaguely recall asking something similar before. If somebody could
assist and/or give a me a reference to the previous thread, that would
be appreciated.
Thanks
--
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
running "python" and
then "import enum". Hmmm. I wonder if I had a Python3 virtualenv active
at the time...
Oh well, thanks for the correction.
--
Brian May <b...@debian.org>
enum package
The first is wheezy and jessie only, and the later looks like Python3
only.
Oh, I see, there is a python-enum34 package too... Will try that.
Thanks for your help.
--
Brian May <b...@debian.org>
and 3.5) of python in Sid.
Any ideas?
--
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
On 2017-04-04 08:21, Brian May wrote:
> I would suggest that Buster have Python 2.7, however we only support 3rd
> party libraries where it is practical to do so. Any library that has
> dropped Python 2.7 support upstream, is not practical for us to support
> in Python2. Anything
dropped Python 2.7 support upstream, is not practical for us to support
in Python2. Anything that depends on such a package (directly or
indirectly) also is not practical for us to support.
--
Brian May <b...@debian.org>
map/
It will require Python >= 3.5 - that is no support for Python 2.x.
https://docs.djangoproject.com/en/dev/releases/2.0/
--
Brian May <b...@debian.org>
sponse to
https://bugs.debian.org/858586, however I tend to think this might be
the best way forward.
--
Brian May <b...@debian.org>
dn't let me upload this package
anyway.
--
Brian May <b...@debian.org>
Reverse Depends: python-sahara (>= 1:5.0.0-2)
> Reverse Depends: python-senlin (>= 2.0.0-2)
> Reverse Depends: python-trove (>= 1:6.0.0-2)
> Reverse Depends: python-watcher (>= 0.30.0-4)
Alternative: maybe I should go to the other plan of uploading the old
version of kombu with an increased epoch?
--
Brian May <b...@debian.org>
Brian May <br...@linuxpenguins.xyz> writes:
> * Upload python-amqp 2.1.4 to unstable (plus anything that this
> breaks??).
I an inclined to think this might be the best option. There are only two
packages that depend on python-amqp - that I can see anyway, and one of
them is
le.
Looks like this change has problems, see #858540. Suspect a missing
depends on the vine package.
--
Brian May <b...@debian.org>
for testing, but
not impossible.
(am assuming it has already entered the archive, or is going to very
soon)
--
Brian May <b...@debian.org>
of the packages is a highly popular package, might want
to exercise a bit more caution. I don't think the packages mentioned so
far count.
--
Brian May <b...@debian.org>
Thomas Goirand <z...@debian.org> writes:
> IMO, upstream are right that the PyPi releases should be minimal. They
> are, from my view point, a binary release, not a source release.
To go against this, often PyPI releases contain *.pyc files. Looking at
django-filter 0.13.0 right no
Ghislain Vaillant <ghisv...@gmail.com> writes:
> Do you get rid of the useless dotfiles (gitignore, ci settings, tox...)
> or leave them alone then?
So far .. they have never caused any problems. So leave them as is.
Think you can leave tox, that can still be useful.
--
On 2017-03-14 14:48, Christopher Hoskin wrote:
> For reasons of my own, I need to create a Celery 4.0.2 Debian package. This
> means also updating the Kombu and AMQP packages. As I'm doing this work
> anyway,
> my preference would be to share it with the World through DPMT.
>
> However, I
will always be consistant, and not suddenly
and unexpectedly drop files.
--
Brian May <b...@debian.org>
h the C code (libraries and client).
This will make it hard to fix #857335 (python3 support) as upstream only
provide python3 support at the moment in an experimental branch, and
don't appear to be in any hurry to merge the experimental branch.
So I don't expect it to appear in PyPI anytime soon.
-
age the maintainer downloads, and
subsequently everyone who uses the (signed) Debian packaging is
affected.
If however PyPI were to remove signatures, this would make the decision
whether to use PyPI or github as the source somewhat easier.
--
Brian May <b...@debian.org>
eature to
allow for caching).
Maybe there is some way of turning signatures on by default, so I don't
have to remember for every upload, if so, I haven't been able to work it
out yet however.
--
Brian May <b...@debian.org>
* Is there any point having signed PyPI releases when (very likely) the
underlying upstream git repository has no signatures?
* Is there any point having signed PyPI releases when (very likely) the
public key is stored in an insecure DPMT respository on
git.debian.org?
--
Brian May <b...@debian.org>
Brian May <b...@debian.org> writes:
> git read-tree --reset -u upstream
> git reset -- debian
> git checkout debian
> git rm debian/.git-dpm
I have tried these steps on python-mkdocs in the debian/experimental
branch, and then upgraded to the latest upstream (using instructio
e initial
conversion and can be done manually as required.
Assuming at the moment, that only few packages would require manual
processing, otherwise this may require a rethink.
--
Brian May <b...@debian.org>
thers would like to use debian/sid because
> it's faster to type.
At the moment - since there were no objections yet - I have revised the
wiki documentation (link already provided) to include DEP-14 and
debian/master (as per DEP-14).
--
Brian May <b...@debian.org>
the transition, what happens to the master branch? Do we delete
it?
--
Brian May <b...@debian.org>
Vincent Bernat <ber...@debian.org> writes:
> I think you mean git-dpm.
Whoops. Yes, of course.
--
Brian May <b...@debian.org>
On 2017-03-06 10:15, Barry Warsaw wrote:
> On Mar 05, 2017, at 01:47 AM, Thomas Goirand wrote:
>
>> Why waiting? The freeze is typically a time of very low activity and low
>> disturbance. That's a perfect moment for doing the switch.
>
> I think it's generally been the consensus, even outside
On 2017-03-06 10:54, Thomas Goirand wrote:
> I'm hereby volunteering for such a sprint (if I hopefully make it to
> Montreal). Hopefully, migrating from git-dpm to git-pq wont be as hard
> as from SVN to Git.
Great! The sooner (after the freeze) we can do this, the better IMHO.
git-dpm looked
ith the open stack
packages however).
--
Brian May <b...@debian.org>
oked at the scripts so I don't know what state they are in,
however I think it would be far simpler to go straight to
gbp-pq. Converting to git-dpm is, I think, a complicated task compared
with going straight to gbp-pq.
--
Brian May <b...@debian.org>
Which generates the following error:
404 - No such project
Regards
--
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
Dominik George <n...@naturalnet.de> writes:
> This is not a Python package.
>
> (Hint: no __init__.py…)
Not required for Python3.
https://www.python.org/dev/peps/pep-0420/
--
Brian May <b...@debian.org>
ge to GBP PQ for work flow,
and then worry about dgit after I have had a chance to play with dgit a
bit more.
--
Brian May <b...@debian.org>
Brian May <b...@debian.org> writes:
> git read-tree --reset -u upstream
> git reset -- debian
> git checkout debian
> git rm debian/.git-dpm
git commit
Of course...
--
Brian May <b...@debian.org>
sets the tree as per the latest upstream (assuming this
is uptodate) and then restores the debian directory that got
deleted. Then we just have to delete the debian/.git-dpm file and are
finished.
--
Brian May <b...@debian.org>
Brian May <b...@debian.org> writes:
> https://wiki.debian.org/Python/GitPackagingPQ
>
> So far it is just a clone, I haven't tried making any changes.
I have gone through and made numerous updates.
There might be errors, as I was going from memory for some of this
stuff.
I
ags/debian/*:refs/dgit-fetch/debian/tags/debian/*'
'+refs/dgit/sid:refs/dgit-fetch/debian/dgit/sid'
dgit: subprocess failed with error exit status 128
--
Brian May <b...@debian.org>
Brian May <b...@debian.org> writes:
> [brian:~/tree … modules/factory-boy] master 255 ± dgit --gbp --clean=git
> sbuild --verbose
> Format `3.0 (quilt)', need to check/update patch stack
> examining quilt state (multiple patches, gbp mode)
> dgit:
age for push "This will push your git history to the
dgit-repos, but you probably want to follow it up with a push to
alioth."
--
Brian May <b...@debian.org>
ches-unapplied git tree
dgit: but git tree differs from orig in upstream files.
This error puzzles me, to me it seems to be saying there is a mismatch
between git with patches unapplied and the *.orig.tar.gz file - however
I don't think this is the case.
--
Brian May <b...@debian.org>
Barry Warsaw <ba...@debian.org> writes:
> On Feb 05, 2017, at 04:01 PM, Brian May wrote:
>
>>What should we call the clone page?
>>
>>PqGitPackaging???
>
> GitPackagingPq ?
https://wiki.debian.org/Python/GitPackagingPQ
So far it is just a clone, I haven't tri
on opportunistically
> switching away from git-dpm.
What should we call the clone page?
PqGitPackaging???
--
Brian May <b...@debian.org>
ime to make sure we have a proper migration strategy
> and sufficient documentation.
That may be a better reason.
Hence the reason I suggested not doing a mass migration of all packages
at once (at least for now) but to update the package when it otherwise
needs updating.
--
Brian May <b...@debian.org>
wever now I
can't see how to run the tests (the supplied mptt/settings.py file is
insufficient).
It is not really important enough for me to worry much more.
--
Brian May <b...@debian.org>
Hello All,
Why didn't the upload of python-django-mptt automatically close #828669?
Too late now, it was removed from testing and I think it is too late to
re-add. I don't think it is important.
However I just wondered why this bug didn't get closed.
(I thought I also responded to that
me.localtime(timestamp+time.timezone).tm_isdst
> ValueError: timestamp out of range for platform time_t
>
> --
> Ran 45 tests in 7.922s
>
> FAILED (errors=2)
> debian/rules:27: recipe for target 'override_dh_auto_test' failed
--
Brian May <b...@debian.org>
Scott Kitterman <deb...@kitterman.com> writes:
> OK. Where do I find documentation to give this a try?
I used the following documentation:
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.patches.html
--
Brian May <b...@debian.org>
have been using:
gbp buildpackage "--git-builder=debuild -i -I -S"
In order to get a *.dsc file that sbuild can use. This command appears
to leave the patches applied. Guess I should investigate changing that
line to somethine else...
--
Brian May <b...@debian.org>
1 - 100 of 347 matches
Mail list logo
