es."
Maybe I am wrong here, maybe this is similar to GPG, but regardless it
made me a bit nervous.
--
Brian May @ Debian
olution?
Somebody needs to post the answers to questions like these to the
discussion thread.
--
Brian May @ Debian
Otto Kekäläinen writes:
> Are you OK that I upload a new python-mkdocs version together with
> Ahmed (CCd)?
Fine with me, I haven't had a lot of time for Debian lately.
--
Brian May @ Debian
, etc. Maybe this is why the practise is not
recommended?
--
Brian May @ Debian
the GPG key required to sign that changes file.
--
Brian May
https://linuxpenguins.xyz/brian/
rd 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
ould upgrade everything in one go. As this
is the only tested upgrade procedure.
--
Brian May
al alternative is to use the latest
version. Often only the latest version is supported by upstream also.
--
Brian May
ng through 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
mmand supplied. 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
ng list
python-modules-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/
ssible 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
upstream moved 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
sh changes (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
th virtualenvs. 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 writes:
> I agree as well. Please file a bug for its removal.
See Bug#897257.
--
Brian May
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:
https://lists.debian.org/debian-python
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
https
problem, but I think it is a necessarily prerequisite
for a solution.
--
Brian May
; 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 something like pyenv.
--
Brian May
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
se 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
Robert Collins 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
Robert Collins 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
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
orgot to do on a
continued basis.
Any ideas?
--
Brian May
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
https://linuxpenguins.xyz/brian/
documentation
Currently the first two packages are in CollabMaint, and the last in
DPMT.
Does this sound like the right approach?
Regards
--
Brian May
nse 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
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
y fail. Although I think I may
have just described a transition anyway :-).
--
Brian May
Michael Hudson-Doyle writes:
> Yes. Let's see if I can find some better answers...
Thanks!
--
Brian May
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". which wasn't really helpful.
--
Brian May
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
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.
The
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 al
or 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
Christopher Hoskin 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
g 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
inja2/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
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
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
-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
detail why.
* celery: requires cyanide (including docs) and sphinx_celery to be packaged in
Debian.
Thanks.
--
Brian May
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
to be
considered for local checked out copies - making a new clean checkout
might be the easiest solution.
--
Brian May
https://linuxpenguins.xyz/brian/
he current version i 9.0
--
Brian May
https://linuxpenguins.xyz/brian/
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 good
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 --g
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 have
- 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
, 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
https://linuxpenguins.xyz/brian/
t; 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
e 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
3.5) of python in Sid.
Any ideas?
--
Brian May
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 tha
ython 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
p/
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
ian.org/858586, however I tend to think this might be
the best way forward.
--
Brian May
imental but the changes will hit unstable
Upload is targeting `experimental', but the changes will hit `unstable'.
Looks like you forgot -d experimental when invoking sbuild.
Although I used the -s option (I don't won't to risk making the same
error!), I believe if I didn't, it wouldn't let me upload this package
anyway.
--
Brian May
-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
Brian May 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 python-kombu.
# apt-cache rdepends
On 2017-03-24 08:33, Christopher Hoskin wrote:
> Presumably it will also run into trouble as python-amqp is at 1.4.9 in
> unstable, but 2.1.4 from experimental is required.
Yuck. I guess the options we have available are (without any evaluation
or filtering of bad or stupid options):
* Try to g
Brian May writes:
> Looks like this change has problems, see #858540. Suspect a missing
> depends on the vine package.
Trying to fix this, I notice it also depends on python{,3}-amqp that
only exists in experimental :-(
--
Brian May
hange has problems, see #858540. Suspect a missing
depends on the vine package.
--
Brian May
not impossible.
(am assuming it has already entered the archive, or is going to very
soon)
--
Brian May
opular package, might want
to exercise a bit more caution. I don't think the packages mentioned so
far count.
--
Brian May
Thomas Goirand 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 now.
--
Brian May
Christopher Hoskin writes:
> Thanks. I'm new to gbp pq, but beginning to get the hang of it.
Your changes looks good to me, I have now made them. FYI, I believe
anybody can create an account and make changes to the wiki.
> Thanks for your help!
Thanks for your help!
--
Brian May
Ghislain Vaillant 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.
--
Brian May
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 notice
nt, and not suddenly
and unexpectedly drop files.
--
Brian May
e (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.
--
Brian May
aintainer 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
hing).
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
* 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
Brian May 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 instructions on
wiki). Works perfec
sion 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
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
On 2017-03-07 08:43, Thomas Goirand wrote:
> I prefer if we use debian/unstable rather than debian/master though, so
> it is more explicit where we upload that branch.
My reading of DEP-14 is that is says we should use debian/master.
Not that I care much myself, either is fine with me.
Why de
ion, what happens to the master branch? Do we delete
it?
--
Brian May
Vincent Bernat writes:
> I think you mean git-dpm.
Whoops. Yes, of course.
--
Brian May
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 o
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 goo
open stack
packages however).
--
Brian May
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
Which generates the following error:
404 - No such project
Regards
--
Brian May
https://linuxpenguins.xyz/brian/
Dominik George 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
flow,
and then worry about dgit after I have had a chance to play with dgit a
bit more.
--
Brian May
Brian May writes:
> git read-tree --reset -u upstream
> git reset -- debian
> git checkout debian
> git rm debian/.git-dpm
git commit
Of course...
--
Brian May
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
Brian May 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 didn't specify any
+refs/tags/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
1 - 100 of 402 matches
Mail list logo
