Re: Joining the team

2020-11-24 Thread Brian May
Thomas Goirand  writes:

> Because joining a team, putting packages in them, and enforcing strong
> ownership, is not logic at all. I know you like to do this way, but this
> shouldn't be what we advise for new comers.

Agreed. In my opinion what the policy allows and what is best practise
are two different things.

If you want strong ownership, you can get that already by not having the
package part of the team. To invite people to do so as part of the
Debian policy just makes the policy more complicated (and confusing)
then it needs to be. And creates needless conflicts within our team.

Depending on what you want, You are also free to follow the packaging
guidelines, policies, etc, even if the package isn't formally part of
the team. You could even join this group
https://wiki.debian.org/LowThresholdNmu and allow others to make changes
to your packages without going through the slow NMU process.
-- 
Brian May 



Re: sshuttle / python3.8

2019-12-15 Thread Brian May
Emmanuel Arias  writes:

> Hello I am available to help.
>
> Let me take a look.

Thanks!

Any luck so far?
-- 
Brian May 



sshuttle / python3.8

2019-12-11 Thread Brian May
Hello,

I have been informed that the sshuttle package, in Debian is most likely
completely broken under Python 3.8

https://github.com/sshuttle/sshuttle/issues/381

To me this looks like a regression in Python 3.8. but at the same time
sshuttle is possibly misusing(?) sockets in ways that were 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 



Re: Bug#943666: python3: Update Python Policy for removal of the Python 2 stack

2019-11-06 Thread Brian May
Stéphane Blondon  writes:

> Perhaps there is a doubt how to read it?
> - do not (remove python-foo-doc or rename it to python3-foo-doc)
> - (do not remove python-foo-doc) or (rename it to python3-foo-doc)
>
> Would it be better if we remove the indentation and use this sentence(?):
> if documentation is in python-foo-doc, do not move it

Myself, I read it as the first option.

I would personally use:

- Do not remove python-foo-doc and do not rename it to python3-foo-doc.

Or maybe even expand as two bullet points:

- Do not remove python-foo-doc.
- Do not rename it to python3-foo-doc.

I think this makes it very explicit what was intended.
--
Brian May 



Re: Help needed with celery/kombu

2019-04-16 Thread Brian May
Emmanuel Arias  writes:

> I am trying to update celery to 4.3.0.

First a warning: Might be hard to justify getting a new release of
celery into Buster at thiss point in time...

> But when I run ```gbp import-orig --uscan```
>
> I have the next error:
>
> gpgv: Signature made Sun 31 Mar 2019 03:56:37 PM UTC
> gpgv:    using RSA key 246C61675A0FB0E16A3E219C29C4F24992EDDC6D
> gpgv: Can't check signature: No public key
> uscan die: OpenPGP signature did not verify. at
> /usr/share/perl5/Devscripts/Uscan/Output.pm line 58.
> gbp:error: Uscan failed: OpenPGP signature did not verify.

It looks like don't have the public key that the package was signed
with.

I see there in stretch that there is a key in
debian/upstream-signing-key.pgp, maybe upstream changed their key?

$ gpg < debian/upstream-signing-key.pgp
gpg: WARNING: no command 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 



[Struan Bartlett] [Python-modules-team] Debian Multiarch package issue: virtualenv and python3-virtualenv

2019-03-10 Thread Brian May
Forwarding to debian-python mailing list from the Debian Python Modules
Team which most people don't look at.

Actually a bug report probably would be the best of of reporting this,
as it looks like it could be a bug.

--- Begin Message ---

Hello

We have been unable to install virtualenv and python3-virtualenv on 
Debian stretch/i386 with python3:amd64, without customising the former 
two packages, due to what appear to be minor package configuration issues.


We have resolved the issues in custom-built packages by:
- Adding a 'Multi-Arch: allowed' header to each of these two packages
- Removing the apparently surplus python3 dependency in 
python3-virtualenv, leaving only the python3:any dependency
- Modifying the python3 dependency in virtualenv, to make it python3:any 
too.

(please see example diffs below).

Please would you advise what additional action, if any, we need to take 
to raise these issue formally and see them fixed in future package releases?


Kind regards

Struan Bartlett

diff -ubw DEBIAN/control*
--- DEBIAN/control  2016-12-01 23:08:39.0 +
+++ DEBIAN/control2 2019-03-06 22:40:00.0 +
@@ -1,10 +1,11 @@
 Package: python3-virtualenv
 Source: python-virtualenv
 Version: 15.1.0+ds-1
 Architecture: all
+Multi-Arch: allowed
 Maintainer: Debian Python Modules Team 


 Installed-Size: 137
-Depends: python-pip-whl (>= 8.1.1-2), python3, python3-pkg-resources, 
python3:any (>= 3.3.2-2~)
+Depends: python-pip-whl (>= 8.1.1-2), python3-pkg-resources, 
python3:any (>= 3.3.2-2~)

 Section: python
 Priority: optional
 Homepage: https://pypi.python.org/pypi/virtualenv```
(edited)

# diff -ubw DEBIAN/control*
--- DEBIAN/control  2016-12-01 23:08:39.0 +
+++ DEBIAN/control2 2019-03-06 22:45:13.0 +
@@ -1,10 +1,11 @@
 Package: virtualenv
 Source: python-virtualenv
 Version: 15.1.0+ds-1
 Architecture: all
+Multi-Arch: allowed
 Maintainer: Debian Python Modules Team 


 Installed-Size: 30
-Depends: python3, python3-virtualenv
+Depends: python3:any, python3-virtualenv
 Breaks: python-virtualenv (<< 1.11.6)
 Replaces: python-virtualenv (<< 1.11.6)
 Section: python

--

Struan Bartlett
Founder & CEO
NewsNow.co.uk

The UK's #1 News Portal:
> www.NewsNow.co.uk <http://www.NewsNow.co.uk> (est. 1998)

Tel:+44 (0)845 838 8890
Fax:+44 (0)845 838 8898

NewsNow Publishing Limited, trading also as NewsNow.co.uk, is a company 
registered in England and Wales under company no. 3435857 with 
registered office Northdown House, 11-21 Northdown Street, London N1 9BN


___
Python-modules-team mailing 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/


Re: upstream release of unreleased package

2019-02-17 Thread Brian May
Andrey Rahmatullin  writes:

> No, you should not add the new upstream version as a patch. Especially as
> you already have the tarball imported. What is the repo missing is merging
> upstream/0.3.8 into the master branch. If you imported the tarball with
> gbp import-orig it would have happened automatically.

That would probably explain why I had problems. I didn't check that the
latest upstream branch correctly matched the source without patches, and
generated the orig.tar.gz file based on the lastest upstream branch
(which wasn't tagged correctly either).

It is possible 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 



Re: upstream release of unreleased package

2019-02-10 Thread Brian May
llu...@autistici.org writes:

> lluvia@technoethical:~/debian/visualequation$ git commit -m "modifying 
> d/changelog for new upstream release"
> [patch-queue/debian/master 70ae5b1] modifying d/changelog for new 
> upstream release
>   1 file changed, 3 insertions(+), 2 deletions(-)

This is your first error. Changes to debian/* files belong to the
debian/master branch, not the patch-queue/debian/master branch.

So you should be finalise the changes to the patch-queue first, then run
something like "gbp pq export" which will switch back the the
debian/master 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 



Re: upstream release of unreleased package

2019-02-09 Thread 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 



Re: git-dpm -> gbp conversion (mass-change)

2018-08-09 Thread Brian May
Thomas Goirand  writes:

> Let's say a patch has been applied upstream. In such case, I just do a
> few "quilt push" to check, then I see one is already applied (by running
> "patch --dry-run -P1  patch from the series file, and I'm done. In case of using git with the
> rebase thing, then I get into useless trouble.

This case is easy. When rebase comes up with a conflict, you can tell it
to skip/drop that entire change.

This tends to be my default choice when I don't understand why something
conflicts during such a rebase.

> Another case is if 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 



Re: git-dpm -> gbp conversion (mass-change)

2018-08-08 Thread Brian May
Ruben Undheim  writes:

> There is no nightmare unless there are patch conflicts.

The one case where you could have a "nightmare" is:

1. Maintainer A updates package to latest upstream version.
2. Maintainer A uploads packages to Debian, and it is accepted.
3. Maintainer A forgets to push changes to git. Or doesn't push all
branches/tags as required.
4. Maintainer B finds package, and updates to latest upstream version
(which could be later then what maintainer A saw).
5. Maintainer B pushes changes to git.
6. Somebody complains that fixes that where included in the first
version have now gone missing.

7. Maintainer A pushes his changes, find they are rejected, and wrongly
does a "push -f", loosing the changes from maintainer B.

OR

7. Maintainer A realizes what has happened, has two sets of patches
against two different upstream versions, and somehow needs to reconcile
them.

etc, etc.

However, I don't know of any workflow that would make the issues here
any easier.

Moral of the story, always make sure you pull changes (from all
branches) before starting to work, just to make sure nobody else has
made changes. Plus always make sure you push changes (all required
branches, e.g. "git push origin : --tags") after you finish work.

Easy to forget however.
-- 
Brian May 



Re: git-dpm -> gbp conversion (mass-change)

2018-08-08 Thread Brian May
Nikolaus Rath  writes:

> The problems with git-dpm are the implementation and lack of
> maintenance, not the way the Debian changes are managed. 

git-dpm requires that you always use its tools. If another maintainer
got confused and used another toolset to upgrade the upstream version,
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 



Re: Safest way to set python3 as default for `python`

2018-07-19 Thread Brian May
Stuart Prescott  writes:

> There's a reasonable number of things in /usr/bin with "#!/usr/bin/env
> python" that would be unhappy with this configuration.

I don't think binaries in /usr/bin should be using "#!/usr/bin/env
python". These will also break with 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 



Re: django-celery

2018-05-01 Thread 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>



Bug#897257: RM: django-celery -- ROM; Deprecated package

2018-04-30 Thread 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/2018/04/msg00120.html

Please remove this package and all binaries from testing and unstable.

I don't believe anything depends on django-celery.

Thanks



django-celery

2018-04-27 Thread Brian May
Hello,

Beginning to think we should seriously think about dropping this
package. It is badly neglected by upstream, and there are now better
alternatives. Such as django-celery-results (not sure if this is in
Debian).

I attempted to fix it by upgrading to the latest upstream version (see
git 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 <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/



Re: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import

2018-04-24 Thread Brian May
Thomas Goirand <z...@debian.org> writes:

> Feel free to raise this on a Django upstream message. I very much agree
> this isn't best.

I believe there is (or at least was, and probably still is) general
agreement that the Django settings mechanism is horrible for numerous
reasons. IIRC this has been discussed at past PyCON AU conferences.

Unfortunately, this has been labelled as a "hard problem". As in coming
up with a replacement that the Django core developers can agree to is
non-trivial (which also means dealing with existing applications in a
sensible manner).

e.g. do a google search for "django settings class" and you will see
that there are a number of projects to get class based settings for
Django. A feature I really wish Django supported out of the
box. Unfortunately most of these projects (I might have missed
something) appear to have been abandoned.

Maybe this is an isssue that needs to be pushed at PyCon or PyConAU.

If there isn't an existing upstream bug report already, somebody should
definitely file one. Or add details as to how the problem affects
testing, if not already given. I don't believe the bug report by itself
will solve this problem, but I think it is a necessarily prerequisite
for a solution.
-- 
Brian May <b...@debian.org>



Re: Backport of Python 3.6 for Debian Stretch?

2018-04-24 Thread Brian May
Nguyễn Hồng Quân <ng.hong.q...@gmail.com> writes:

> ​Sorry? As I told, just leave the python3-xxx packages to be used with
> python3.5 (default Python3 of Debian 9).
> I don't need those to be used with Python3.6.
> For whatever I need to use with Python3.6, I just install 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 something like pyenv.
-- 
Brian May <b...@debian.org>



Re: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import

2018-04-20 Thread Brian May
Helmut Grohne <hel...@subdivi.de> writes:

> django.core.exceptions.ImproperlyConfigured: Requested setting
> DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must
> either define the environment variable DJANGO_SETTINGS_MODULE or call
> settings.configure() before 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>



Re: Questions about salsa and Git

2018-04-12 Thread Brian May
Simon McVittie <s...@debian.org> writes:

> Is this now official policy for new/updated/converted Python modules
> maintained by DPMT?
>
> Is it official policy for new/updated/converted Python applications
> maintained by PAPT?

I am not exactly an authoritive figure, but I believe the answer to both
of these is yes.

It is possible that there are a number of packages that still need to be
converted. I had a script on aloth to do this, it might need updating
for salsa. Especially as it relied on direct access to the git directory
to change the default branch.

> At 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>



Re: setup.py sdist permissions

2018-04-05 Thread Brian May
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>



Re: setup.py sdist permissions

2018-04-04 Thread Brian May
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>



Re: setup.py sdist permissions

2018-04-04 Thread Brian May
Yaroslav Halchenko <deb...@onerussian.com> writes:

> just anecdotal support: my umask is 077 as well, have been doing uploads
> to pypi for a while, never had report from the users about any problem.
> The reasons could be either it indeed doesn't matter or nobody uses my
> 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>



setup.py sdist permissions

2018-04-03 Thread Brian May
Hello,

As an upstream maintainer of certain packages on pypi, it has come to my
attention that my packages have files in the source package with
permission 600 or 700 (and my owner and group). This is most likely
because my umask is set to 077, because in general I prefer not having
all my private files world/group readable.

* Is this actually a problem for users?

* Shouldn't sdist be ignoring my umask considering it is generating
  packages for public consumption?

It seems like the only known solution is to manually set umask to 022
before calling sdist, something I am likely to forgot to do on a
continued basis.

Any ideas?
-- 
Brian May <b...@debian.org>



[alioth lists migration team] [Python-modules-team] Notice of mailing list closure: python-modules-team

2018-04-03 Thread Brian May
A lot of our packages currently have this list in the maintainer
field. Maybe we want to keep this list for now???


--- Begin Message ---
Dear list subscribers,

As per the announcement on debian-devel-announce[1] and as part of
the shutdown of the alioth service, the migration of
lists.alioth.debian.org mailing lists to alioth-lists.debian.net is now
underway.

We tried to contact the designated list owner via
python-modules-team-ow...@lists.alioth.debian.org but got either no reply,
or a bounce message. Accordingly, this list will not be migrated to the
new system and will stop working on 14th April.

Information about alternatives to this service which may be more suitable
for the list can be found at
<https://wiki.debian.org/Salsa/AliothMigration#Import_mailing_list>.

In the event that this list should be migrated to the new system,
please first appoint a Debian developer as a list owner, then let us know
by replying to this email, copying in the list.

More information about the new service can be found here:
<https://wiki.debian.org/Alioth/MailingListContinuation>

Thanks,
the alioth-lists migration team.

[1] <https://lists.debian.org/debian-devel-announce/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>
https://linuxpenguins.xyz/brian/


mkdocs

2018-03-15 Thread Brian May
Hello,

I am thinking now (with the migration to Salsa) is a good time to move
all the packages directly related to mkdocs to PAPT:

mkdocs-bootstrap - bootstrap themes for MkDocs
mkdocs-bootswatch - bootswatch themes for MkDocs
mkdocs - Static site generator geared towards building project 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>



Re: python logo.

2018-03-05 Thread Brian May
Peter Green <plugw...@debian.org> writes:

> I am looking into cleaning up some software so it can be uploaded to
> Debian. Inside the documentation folder is a copy of the python
> logo. I found the python.org page for the logo more confusing than
> helpful.
>
> 1. 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>



Re: snap in debian

2017-10-14 Thread Brian May
Michael Hudson-Doyle <michael.hud...@canonical.com> writes:

> Yay unreproducible bugs. If you manage to reproduce, please have a look in
> syslog or systemd's journal for anything that looks related.

Not sure this helps me, maybe it might help somebody else? "Failed to
load configuration" might be relevant. What configuration?

This is a grep for hello in journalctl, after trying to remove the hello
snap. I couldn't see anything else relevant.

Oct 15 13:15:45 prune sudo[17326]:brian : TTY=pts/1 ; PWD=[removed] ; 
USER=root ; COMMAND=/usr/bin/snap remove hello
Oct 15 13:15:46 prune systemd[1]: snap-hello-20.mount: Changed mounted -> dead
Oct 15 13:15:46 prune systemd[1843]: snap-hello-20.mount: Changed mounted -> 
dead
Oct 15 13:15:46 prune systemd[1843]: snap-hello-20.mount: Collecting.
Oct 15 13:15:46 prune systemd[1]: Sent message type=signal sender=n/a 
destination=n/a object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=2105 
reply_cookie=0 error=n/a
Oct 15 13:15:46 prune systemd[1]: Sent message type=signal sender=n/a 
destination=n/a object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=2106 
reply_cookie=0 error=n/a
Oct 15 13:15:46 prune systemd-logind[632]: Got message type=signal sender=:1.0 
destination=n/a object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=2105 
reply_cookie=0 error=n/a
Oct 15 13:15:46 prune systemd[1413]: snap-hello-20.mount: Changed mounted -> 
dead
Oct 15 13:15:46 prune systemd[1413]: snap-hello-20.mount: Collecting.
Oct 15 13:15:46 prune systemd-logind[632]: Got message type=signal sender=:1.0 
destination=n/a object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount 
interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=2106 
reply_cookie=0 error=n/a
Oct 15 13:15:46 prune systemd[1]: snap-hello-20.mount: Trying to enqueue job 
snap-hello-20.mount/stop/replace
Oct 15 13:15:46 prune systemd[1]: snap-hello-20.mount: Installed new job 
snap-hello-20.mount/stop as 3721
Oct 15 13:15:46 prune systemd[1]: snap-hello-20.mount: Enqueued job 
snap-hello-20.mount/stop as 3721
Oct 15 13:15:46 prune systemd[1]: snap-hello-20.mount: Job 
snap-hello-20.mount/stop finished, result=done
Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a 
destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount 
interface=org.freedesktop.DBus.Properties member=Get cookie=3 reply_cookie=0 
error=n/a
Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a 
destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount 
interface=org.freedesktop.DBus.Properties member=Get cookie=4 reply_cookie=0 
error=n/a
Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a 
destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount 
interface=org.freedesktop.DBus.Properties member=Get cookie=5 reply_cookie=0 
error=n/a
Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a 
destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount 
interface=org.freedesktop.DBus.Properties member=GetAll cookie=1 reply_cookie=0 
error=n/a
Oct 15 13:15:46 prune systemd[1]: Preset files don't specify rule for 
snap-hello-20.mount. Enabling.
Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a 
destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount 
interface=org.freedesktop.DBus.Properties member=GetAll cookie=1 reply_cookie=0 
error=n/a
Oct 15 13:15:46 prune systemd[1]: Got message type=method_call sender=n/a 
destination=org.freedesktop.systemd1 
object=/org/freedesktop/systemd1/unit/snap_2dhello_2d20_2emount 
interface=org.freedesktop.DBus.Properties member=GetAll cookie=1 reply_cookie=0 
error=n/a
Oct 15 13:18:47 prune 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>



Re: pyasn1

2017-10-14 Thread Brian May
Vincent Bernat <ber...@debian.org> writes:

> pyasn1 is currently at version 0.1.9. The current version is
> 0.3.7. There is a bug report asking for a new version:
>
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872724
>
> Should a transition be opened for such a packet (this is not usual to
> have transition for Python packages, but there are many reverse
> dependencies to this one)?

Is the new version likely to break dependencies? If so, a transition
might be good.

Might be worth creating a test version for experimental and rebuilding
all dependancies against it to see if any fail. Although I think I may
have just described a transition anyway :-).
-- 
Brian May <b...@debian.org>



Re: snap in debian

2017-10-04 Thread Brian May
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>



Re: snap in debian

2017-10-04 Thread Brian May
Michael Hudson-Doyle <michael.hud...@canonical.com> writes:
> Can you elaborate? Do you have apparmor enabled? I am aware that there are
> problems on stable currently but being explicit reduces guessing.

See the stack overflow question. The major issue was the error when
trying to remove an existing container.

2017-09-09T15:08:29+10:00 ERROR cannot remove snap file "robotica", will retry 
in 3 mins: snap-robotica-x1.mount failed to stop: timeout

I also had problems with incorrect permissions randomly appearing, even
though I used exactly the same process every time.

> Can you try just installing the package from unstable rather than
> rebuilding it? (sometimes static linking does solve problems :-p)

I was guessing it won't be possible to install the package straight from
unstable onto a stable system, and am not interested in upgrading at
this point 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". which wasn't really helpful.
-- 
Brian May <b...@debian.org>



snap in debian

2017-10-01 Thread Brian May
Ghislain Vaillant <ghisv...@gmail.com> writes:

> May I ask what would be the benefit for pycharm to be in Debian, when we 
> already have the official Jetbrains Toolbox App or the snap package as 
> means to install and update the application?

For what its worth, last time I tried snap on Debian stable I found it
didn't work reliably.

I asked in Stack Overflow, and managed to backport the version of snap
from unstable. Where I encountered exactly the same problems as before:

https://stackoverflow.com/questions/46127373/snap-packages-on-debian-stable

So possibly at 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>



Re: git-dpm (was Re: Bug#729956: Forwarded upstream)

2017-09-06 Thread 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.

Re: git-dpm (was Re: Bug#729956: Forwarded upstream)

2017-09-06 Thread Brian May
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. 

These steps are very important to: 

(a) prevent confusion on which branch to use. 
(b) prevent confusion on qa.debian.org, which uses the default branch to
check that the git version. 

=== cut === 

ssh git.debian.org
cd "/git/python-modules/packages/$1.git"
git symbolic-ref HEAD refs/heads/debian/master
exit

cd "$TMP"
git push origin :master

=== cut ===

I also have a script to automate the entire conversion, and assuming the
git repository is up-to-date and nobody is withholding pushes, it seems
to work well.  

/srv/home/users/bam/convert on git.debian.org

Re: git-dpm (was Re: Bug#729956: Forwarded upstream)

2017-09-06 Thread Brian May
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 all our problems. e.g. forgetting to import the PQ (if not
already done) *before* updating to a new upstream version. Or forgetting
to import the PQ after a git pull makes modifications to the upstream
patch files. 

In general, however, when something does go badly wrong I think it will
be a lot easier to diagnose, understand, and fix with GPB PQ then with
git-dpm. git-dpm can get very messy very quickly, particularly if you
forget to pull before making changes (personally I make this mistake too
frequently) or update to a new upstream version without using the
correct git-dpm workflow - I have seen both of these situations happen.

Re: a few quick questions on gbp pq workflow

2017-08-06 Thread Brian May
Allison Randal <alli...@lohutok.net> writes:

> - Will DPMT be following DEP-14 and using the branch name debian/master
> instead of master?

I believe so. Although from memory the conversion instructions are
incomplete on how to change the default branch to debian/master, which
is required before you can delete the old master branch.

Having a master branch that is no longer useful may have confused me
with some packages that other people have converted, but haven't had
time to check.

> - The gbp pq workflow page still points at the general Debian git-dpm
> instructions in the links for "import an existing .dsc file" and "start
> from scratch". Are there alternate versions of those pages for gbp pq
> somewhere?
>
> https://wiki.debian.org/PackagingWithGit/GitDpm/ImportDsc
> https://wiki.debian.org/PackagingWithGit/GitDpm/Initialize

Whoops. Possibly these links should be removed, all the information
required should be on this page. If not, feel free to add it...

> - Does DPMT prefer signed tags or unsigned tags, the wiki page is pretty
> agnostic on the topic.

Personally I use signed tags. gbp has a --git-sign-tags option.

> - Are there other lingering workflow questions for gbp pq not yet
> recorded on the wiki page?

The only major issue is the lack of proper procedure on how do the
master --> debian/master branch rename. As in I think the procedures
leaves behind a master branch, and keeps it as the default.

I have a script on git.debian.org - hopefully everyone should be able to
read this:

/srv/home/users/bam/convert

Which will handle the entire conversion. Must be run on git.debian.org,
and for best results git should have your username and email setup on
git.debian.org. Works for 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>



Re: updating packages

2017-08-01 Thread Brian May
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>



Re: updating packages

2017-07-30 Thread Brian May
Christopher Hoskin <christopher.hos...@gmail.com> writes:

> As sphinx is used for documentation, even if you're building a python2
> package, you can use the python3 sphinx. Build-depends on
> python3-sphinx and Build-Conflicts on python-sphinx.

Yes, was wondering that.

> I 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>



Re: updating packages

2017-07-29 Thread Brian May
Christopher Hoskin <christopher.hos...@gmail.com> writes:

> sphinx_celery is already packaged as sphinx-celery:
>
> https://packages.qa.debian.org/s/sphinx-celery.html

Only has a Python 3 version. Not sure if this matters.

At the moment, when I try to build djangorestframework I get the
following error. Maybe jinja2 is too old or too new?

# Build the HTML documentation.
mkdir /<>/docs.debian
LC_ALL=C.UTF-8 PYTHONPATH=/usr/share/mkdocs/themes mkdocs build && mv site 
docs.debian/html
INFO-  Building documentation to directory: /<>/site 
Traceback (most recent call last):
  File "/usr/bin/mkdocs", line 9, in 
load_entry_point('mkdocs==0.15.3', 'console_scripts', 'mkdocs')()
  File "/usr/lib/python3/dist-packages/click/core.py", line 722, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/mkdocs/__main__.py", line 137, in 
build_command
), clean_site_dir=clean)
  File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 290, in 
build
build_pages(config)
  File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 234, in 
build_pages
build_template('404.html', env, config, site_navigation)
  File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 149, in 
build_template
output_content = template.render(context)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in 
render
return self.environment.handle_exception(exc_info, True)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in 
handle_exception
reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
raise value.with_traceback(tb)
  File "/<>/docs_theme/404.html", line 1, in top-level template 
code
{% extends "main.html" %}
  File "/<>/docs_theme/main.html", line 7, in top-level template 
code
{% if page.title %}{{ page.title }} - {% endif %}{{ config.site_name 
}}
  File "/usr/lib/python3/dist-packages/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>



Re: updating packages

2017-07-29 Thread 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 <b...@debian.org>



python-modules-commits-ow...@lists.alioth.debian.org bounces

2017-07-07 Thread Brian May
Hello,

I am getting a constant stream of bounces from emails generated by the
commit hooks.

I tried sending an email to that address, but not got any response yet.

Yes, message really does say "throughg".

Regards.

--- cut ---
Sorry we reject non-member mails due to spam but we have 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>



Re: git-dpm: remove a patch

2017-07-05 Thread Brian May
Vincent Bernat <ber...@debian.org> writes:

> git-dpm: Calling merge-patched-into-debian first...
> git-dpm: ERROR: cowardly refusing to update patched to already merged 
> version!. Use --allow-revert to override!

Have you tried doing what it suggests, using the --allow-revert
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>



updating packages

2017-07-03 Thread Brian May
Hello,

I have started updating packages, trying to fix Django 1.11 issues where
applicable, but seem to be running into road blocks for everything I
try. Have updated git. Help appreciated:

* django-filter, requires djangorestframework.
* djangorestframework, tests fail, not yet investigated 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/



Re: gbp pq conversion

2017-07-02 Thread Brian May
The one mistake I seem to often make with gbp pq is import the new
sources and then discover I forgot to one "gbp pq import". The "gbp pq
import" needs to happen first (if not already done), before importing
new sources. Otherwise "gbp pq rebase" and "gbp pq export" can end up
deleting all patches.

The solution I have found is

1. Create a temporary branch at the current commit

git branch tmp

2. Take the debian/master branch to the previous "good" commit:

   git reset --hard version origin/debian/master

   change the origin/debian/master as appropriate.

3. Import the patch queue (possibly might need to delete any existing
patches branch first):

   gbp pq import

4. Go back to the latest version:

   git reset --hard tmp
   git branch -d tmp

Note that "gbp pq import" must be done in the correct branch, as the
name 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>



gbp pq conversion

2017-06-25 Thread Brian May
I have a script in git.debian.org that will hopefully help.

I am still testing it on packages, one at a time. I am not yet 100%
confident in its correct operation - although it appeared to work for
Django tables.

/srv/home/users/bam/convert django-tables

I imagine this will need some refinement. In particular, it has some
paranoid checks at the top, which possibly could be relaxed. I overwrite
gbp.conf instead of trying to do something sensible if it exists (hence
the check to ensure it doesn't exist).

I have commented out the code to the the patch queue import and export,
partly because gbp is not installed on git.debian.org, and partly
because this part probably should be done manually in order to check
information is not lost.

Hopefully the permmissions are correct, so that anyone can access the
file.

After the conversion the master branch will be deleted, this needs to be
considered for local checked out copies - making a new clean checkout
might be the easiest solution.
-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/



Re: PAPT git migration

2017-05-31 Thread Brian May
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 to know how many of our packages have patches that use
this format too.

Re: PAPT git migration

2017-05-31 Thread Brian May
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 --git ...
> ...
> 
> 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: ...

So to me it looks like the required changes are: 

* Rename Author field to From. Ensure it is first field. 
* Add Date field. Set to what? 
* Rename Description to Subject. 
* Ensure blank line before description. 
* Remove space at start of every line in description. 
* Ensure blank line after description. 

The Applied-upstream field looks nice to have, but maybe not essential. 

Is this correct? Did I miss anything? 

A tool to automate some, if not all of this, would be good.

Re: PAPT git migration

2017-05-31 Thread Brian May
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 noticed with that document - but not had time to
come up with a solution yet. 

There are several places where "git push --all" (or variant) is
recommended. But this will also push the gbp pq branch(es), which should
never get pushed.

Re: avoiding regressions with python3-all-dev in between transitions?

2017-05-20 Thread Brian May
Steve Langasek <vor...@debian.org> writes:

> As with every recent transition, we are finding a number of packages that
> have wrong build-dependencies on python3-all-dev despite having no support
> in the packaging for multiple versions.  Some of these packages just
> continue to build for the default version, and some of them fail to build.

I suspect a related issue is packages that build fine, but the tests
don't actually run tests against all python versions.

For example, python-django-jsonfield has in debian/rules:

override_dh_auto_test:
python2 debian/run_tests.py
python3 debian/run_tests.py

Wonder how many other packages are similar.

This particular case looks like it was my fault :-( - from a change made
in 2014. It is possible I used the same pattern in other packages,
although I can't find anything else right now (not counting a package
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>



pytest-bdd tests

2017-05-18 Thread Brian May
Hello,

Concerning pytest-bdd - which is in git and dependant packages now in
unstable:

I suspect that the tests require the package to be installed first. As
they require pytest be able to find the hooks that pytest-bdd has
installed.

Unfortunately, tests by default happen on the working tree, 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/



Re: python-parse-type

2017-05-16 Thread Brian May
Nicolas CANIART <nico...@caniart.net> writes:

> But there exists a Python 2.7 backport: the enum34 package (there are
> others but I think this one is the most used and standard). See
> https://pypi.python.org/pypi/enum34/1.1.6

Wondering why I thought otherwise. I tested this by 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>



Re: python-parse-type

2017-05-16 Thread Brian May
Piotr Ożarowski <pi...@debian.org> writes:

> packaged as python-enum34 (correct name is python-enum, that's why you
> didn't find it most probably)

I see the following packages:

python-enum - robust enumerated type support in Python
python3-enum34 - backport of Python 3.4's 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>



python-parse-type

2017-05-16 Thread Brian May
Hello,

Trying to build the python-parse-type package on Sid (source is in git
for DPMT), required by python-pytest-bdd, I get the following error
repeated a number of times:

Traceback:
tests/test_parse_util.py:7: in 
from .parse_type_test import TestCase, unittest
tests/parse_type_test.py:3: in 
from parse_type import TypeBuilder
parse_type/__init__.py:3: in 
from parse_type.cardinality import Cardinality
parse_type/cardinality.py:8: in 
from enum import Enum
E   ImportError: No module named enum

Huh? I thought enum is a standed python feature for both versions (2.7
and 3.5) of python in Sid.

Any ideas?
-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/



Re: Fwd: next version of csvkit

2017-04-03 Thread Brian May
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 that depends on such a package (directly or
> indirectly) also is not practical for us to support.

 I just noticed that Ubuntu plan to drop Python 2.7 completely - from
default installs at least - for the 18.04 release: 

"Plans for 18.04 LTS 

Overarching goals include: 

Python 3 only on the default installs for desktop, server, touch, snappy
images. (Some may already be there.)
Python 3.6 transition" 

https://wiki.ubuntu.com/Python 

Trying to find out what the situation will be for the 17.04 release, not
finding much yet however. 

  

Re: Fwd: next version of csvkit

2017-04-03 Thread Brian May
Vincent Bernat <ber...@debian.org> writes:

> On the current subject, I also agree we should not drop prematurely
> packages targeted to Python 2. It is likely the support will be extended
> past 2020, at least by distributions with a 10-year support.

RHEL 7 will be supported until 2024.
https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#RHEL_7

I seem to recall RH had a commitment to support Python 2.7 until 2030,
but I can't find that now.

However, just because some random distribution is supporting Python 2
past 2020, doesn't mean we have any obligation to do so.

Also "we support Python 2.7" doesn't mean "support Python 2.7 in
unstable." It is possible that we will continue supporting Stretch, post
2020 as a LTS release.

https://wiki.debian.org/LTS

Providing *full* Python 2.7 support in unstable is likely to prove to be
harder and harder when various upstreams start dropping Python 2.7
support, starting with Django this December. e.g. When Django drops
support, and we upload that version to unstable, suddenly everything
that depends on Django will also fail to work under Python 2.7.

https://docs.djangoproject.com/en/dev/releases/2.0/

If Django 2.0 is released on schedule, I would like to see it in Buster
- assuming our release cycle remains every 2 years, that will make it
early 2019.

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 that depends on such a package (directly or
indirectly) also is not practical for us to support.
-- 
Brian May <b...@debian.org>



Re: What should Debian do about Python 2? (was Re: next version of csvkit)

2017-04-03 Thread Brian May
Barry Warsaw <ba...@debian.org> writes:

> For libraries that already support 2 and 3, I don't think we necessarily need
> to actively drop Python 2 yet.  We have great tools, so it's usually just as
> easy to continue supporting both.  I'm on the fence for new library packages,
> but I suppose if it's also just as easy to support both, we might as well go
> through NEW for both, since it's easier to drop binary packages than add them.

It is perhaps worth noting that Django 2.0 is due to be released in
December:

https://www.djangoproject.com/weblog/2015/jun/25/roadmap/

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>



Re: Updating Celery, Kombu, python-amqp

2017-03-24 Thread Brian May
Michael Fladischer <mich...@fladi.at> writes:

> This seems to be the best way to deal with this. I don't think that
> python-amqp 2.x should be uploaded to unstable as it would potentially
> break a lot of things in OpenStack.

I will wait a little bit in case there is a response to
https://bugs.debian.org/858586, however I tend to think this might be
the best way forward.
-- 
Brian May <b...@debian.org>



Re: Updating Celery, Kombu, python-amqp

2017-03-24 Thread Brian May
Christopher Hoskin <christopher.hos...@gmail.com> writes:

> I've filed a bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858586
>
> Very sorry about this mess. This is what comes of trying to do
> something complex and precise late at night after a long day's work :(

I can't complain. I have also accidentally uploaded to unstable instead
of experimental for the same reason. IIRC I didn't understand how the
sbuild options worked. I have now put a check in my build scripts to
prevent this type of mistake happening.

I strongly recommend to use dput-ng, it will stop this kind of
mistake. I just checked this to make sure:

% dput -s ftp-master python-mkdocs_0.16.1-1_i386.changes
Not uploading for real - dry run
Uploading python-mkdocs using ftp to ftp-master (host: ftp.upload.debian.org; 
directory: /pub/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads to 
the target distribution
running protected-distribution: warn before uploading to distributions where a 
special policy applies
running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
Upload is targeting experimental 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 <b...@debian.org>



Re: Updating Celery, Kombu, python-amqp

2017-03-24 Thread Brian May
Christopher Hoskin <christopher.hos...@gmail.com> writes:

> What worries me is:
>
> apt-rdepends -r python-amqp

I wasn't aware of this command. Thanks for this.

If I understand this command correctly, it is showing everything that
depends directly and indirectly on python-amqp?

Hmm. Looks like a large number of these are due to
python-oslo.messaging. So can't use the argument that the update to
python-kombu has already broken these.

So if we upgrade python-amqp *and* that (worse case) requires
python-oslo.messaging be upgraded too, that is a lot of packages (listed
below) that *directly* depend on python-oslo.messaging. Eventually we
will have to deal with this, maybe during the freeze isn't a good time?

> python-oslo.messaging
>   Reverse Depends: oslo-messaging-zmq-receiver (= 5.10.0-2)
>   Reverse Depends: python-aodh (>= 3.0.0-2)
>   Reverse Depends: python-barbican (>= 1:3.0.0-1)
>   Reverse Depends: python-ceilometer (>= 1:7.0.1-1)
>   Reverse Depends: python-ceilometermiddleware (>= 0.5.0-3)
>   Reverse Depends: python-cinder (>= 2:9.0.0-3)
>   Reverse Depends: python-congress (>= 4.0.0+dfsg1-3)
>   Reverse Depends: python-designate (>= 1:3.0.0-2)
>   Reverse Depends: python-glance (>= 2:13.0.0-2)
>   Reverse Depends: python-glare (>= 0.1.0-3)
>   Reverse Depends: python-heat (>= 1:7.0.0-3)
>   Reverse Depends: python-ironic (>= 1:6.2.0-2)
>   Reverse Depends: python-keystone (>= 2:10.0.0-6)
>   Reverse Depends: python-magnum (>= 3.1.1-2)
>   Reverse Depends: python-manila (>= 1:3.0.0-2)
>   Reverse Depends: python-mistral (>= 3.0.0-1)
>   Reverse Depends: python-murano (>= 1:3.0.0-2)
>   Reverse Depends: python-networking-sfc (>= 2.0.1~git20160926.27f311e-1)
>   Reverse Depends: python-neutron (>= 2:9.1.1-1)
>   Reverse Depends: python-neutron-dynamic-routing (>= 2:9.0.0-1.2)
>   Reverse Depends: python-neutron-fwaas (>= 1:9.0.0-3)
>   Reverse Depends: python-neutron-lbaas (>= 1:9.1.0-2)
>   Reverse Depends: python-neutron-lib (>= 0.4.0-3)
>   Reverse Depends: python-neutron-vpnaas (>= 2:9.0.0-3)
>   Reverse Depends: python-nova (>= 2:14.0.0-3)
>   Reverse Depends: python-oslo.versionedobjects (>= 1.17.0-2)
>   Reverse Depends: python-osprofiler (>= 1.4.0-2)
>   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>



Re: Updating Celery, Kombu, python-amqp

2017-03-24 Thread Brian May
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 python-kombu.

# apt-cache rdepends python-amqp
python-amqp
Reverse Depends:
  python-oslo.messaging
  python-kombu
  python-kombu
  python-kombu
  python-kombu
  python-oslo.messaging

Any objections to uploading the experimental version of python-amqp into
unstable?
-- 
Brian May <b...@debian.org>



Re: Updating Celery, Kombu, python-amqp

2017-03-23 Thread Brian May
Brian May <b...@debian.org> 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 <b...@debian.org>



Re: Updating Celery, Kombu, python-amqp

2017-03-23 Thread Brian May
Christopher Hoskin <christopher.hos...@gmail.com> writes:

> I've made a mistake, and kombu has got uploaded to unstable instead of
> experimental. (I had experimental in the changelog, but didn't pass
> "-d experimental" to sbuild on the final build). I'm very sorry about
> this. What is the best way to resolve this? Should I file a bug
> against the ftp.debian.org pseudo-package?

I see your changes in the debian/experimental branch. Wondering if it is
probably best to include them now in master (or debian/master?),
considering they are now in debian/unstable.

Looks like this change has problems, see #858540. Suspect a missing
depends on the vine package.
-- 
Brian May <b...@debian.org>



Re: Updating Celery, Kombu, python-amqp

2017-03-22 Thread Brian May
Christopher Hoskin <christopher.hos...@gmail.com> writes:

> I've made a mistake, and kombu has got uploaded to unstable instead of
> experimental. (I had experimental in the changelog, but didn't pass
> "-d experimental" to sbuild on the final build). I'm very sorry about
> this. What is the best way to resolve this? Should I file a bug
> against the ftp.debian.org pseudo-package?

Is this upload likely to break anything in unstable?

If not, I wouldn't worry too much about it. Might make things a little
bit harder in the unlikely case a update is required for testing, but
not impossible.

(am assuming it has already entered the archive, or is going to very
soon)
-- 
Brian May <b...@debian.org>



Re: Updating Celery, Kombu, python-amqp

2017-03-18 Thread Brian May
Christopher Hoskin <christopher.hos...@gmail.com> writes:

> python-amqp depends on vine, but when I previously packaged vine[0], I
> only built the python3 package. Is it too soon to start dropping
> python2 packages from uploads intended for Buster?

I am hardly any authoritative source for this team, but I don't see any
problems.

Just need to be mindful of anything that depends or build depends on the
python-* on the package you are removing - if you break a large number
of packages (including cascading breakages), maybe not worth it. Just
yet anyway.

Or maybe if one 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>



Re: PyPI source or github source?

2017-03-18 Thread Brian May
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 now.
-- 
Brian May <b...@debian.org>



Re: PyPI source or github source?

2017-03-14 Thread Brian May
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.
-- 
Brian May <b...@debian.org>



Re: Updating Celery, Kombu, python-amqp

2017-03-13 Thread 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 that python-amqp has a lot of other reverse dependancies,
> including OpenStack, and that we're currently in a release freeze. I've also
> seen there's been some discussion about using the DEP14 branch/tag convention
> and switching to gbp pq.
> 
> Would people be happy for me to start updating Celery and its dependancies,
> uploading the results to experimental, or should I keep my work to myself for
> the time being?

As an uploader for celery, kombu, and python-amqp, I see no problem
myself. I can't speak for other packages, and definitely I can't speak
for packages not under DPMT. 

For now, I would suggest creating a debian/experimental branch,
switching to gbp pq (as using non-standard branch names is easier with
gbp pq), and then continuing. I have done this already for the
python-mkdocs package. 

If you need any help, let me know. 

  

Re: PyPI source or github source?

2017-03-13 Thread Brian May
Scott Kitterman <deb...@kitterman.com> writes:

> Like Barry, I've never had an issue with upstreams fixing their MANIFEST.in 
> so 
> that the sdist is complete when I point out the issue.

I have had some people who do argue that sdist is an installation
format, not a source format - if you want the source use github. I think
most of them eventually do change, however it makes me a bit uneasy that
maybe they might be right. As a result, some of my recent packages I
have used github, rather then try to "fix" things on PyPI. That way I
can be sure that the build will always be consistant, and not suddenly
and unexpectedly drop files.
-- 
Brian May <b...@debian.org>



Re: PyPI source or github source?

2017-03-13 Thread Brian May
Barry Warsaw <ba...@debian.org> writes:

> I've so far only encountered one package that releases on GitHub and not PyPI:
> pyparted.  And I've filed an upstream bug about that.

I just found another one: python-ledger. Unfortunately in this case,
Python packages are also bundled with 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.
-- 
Brian May <b...@debian.org>



Re: GnuPG signatures on PyPI: why so few?

2017-03-12 Thread Brian May
Donald Stufft <don...@stufft.io> writes:

> https://mail.python.org/pipermail/distutils-sig/2016-May/028933.html 
> <https://mail.python.org/pipermail/distutils-sig/2016-May/028933.html>

  "I am aware of a single tool anywhere that actively supports verifying the
  signatures that people upload to PyPI, and that is Debian's uscan program. 
Even
  in that case the people writing the Debian watch file have to hardcode in a
  signing key into it and in my experience, when faced with a validation error
  it's not unusual for Debian to simply disable signature checking for that
  project and/or just blindly update the key to whatever the new key is."

I would never just blindly disable signature checking or update the key
without carefully checking that this is legitimate first (and/or
carefully checking the diff). For example, if releases were signed by
person A, but now signed by person B, there should be some sort of
public record of this fact. If not, ask on a public forum.

If you remove signatures (or don't supply them in the first place), then
we - as Debian packagers - have no way of validating the upload. So you
only need to compromise the package 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>



Re: GnuPG signatures on PyPI: why so few?

2017-03-11 Thread Brian May
Ben Finney <bign...@debian.org> writes:

> However, this only works if upstream releases are actually accompanied
> by a valid GnuPG signature each time. The PyPI infrastructure supports
> this; why isn't it more widely encouraged?

One reason I have found for myself: I can forget to sign the package
when uploading to PyPI, and PyPI doesn't let you make any changes after
the package is uploaded without changing the version (including adding
signature file). There is a long running bug report on this, it is not
going to get fixed (TLDR it is not a bug, it is a design feature 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>



PyPI source or github source?

2017-03-11 Thread Brian May
Ben Finney <bign...@debian.org> writes:

> Debian's UScan has the ability to find, download, and verify the GnuPG
> signature for a package source release. Lintian will remind the
> maintainer if a Debian source package is not taking advantage of this.

A related issue is:

Should we be using PyPI as our source of packages? Or github?

You mention a very good reason why PyPI should be the preferred form,
packages *can* be signed by the author.

However, often packages in PyPI are not the complete source package you
would get from github. They may be sufficient for installations, but
often not for Debian packaging - which really should have the complete
source package. e.g. they can be missing tests, license files,
documentation that doesn't get installed, etc.

Sure, you could argue that PyPI source packages should contain
everything the github package does. In fact there is a PyPI tool to help
get the MANIFEST.in correct for such purposes -
https://pypi.python.org/pypi/check-manifest; however a counter argument
could also be made that upstrems generally don't care about such issues
- probably won't notice any regressions - if it installs from PyPI that
is all that really matters - and the only way we can be sure we are
getting the complete source iis from github.

Unfortunately, github releases cannot (AFAIK) easily be signed, unless
you retrieve signed git tags directly from git (which is not supported
by uscan AFAIK). Would be good if gbp buildpackage supported signing git
tags, I don't think it does either.

I started off thinking github was the best source, then slowly swayed
towards PyPI, now I am thinking maybe github again.

Comments?

Some related issues:

* Do we consider signed git tags / commits secure, considering they are
  based on SHA1?

* 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>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-03-09 Thread Brian May
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 instructions on
wiki). Works perfectly[1].

The only unexpected problem I had is that "gbp import-orig --uscan", by
default, switches to the master branch and attempts to merge the new
upstream there. Which wasn't going to work, because master still is the
patches-applied git-dpm version. I had assumed that it would work on the
current branch; it doesn't.

The wiki should be ammended with instructions on how to edit
debian/gbp.conf at the appropriate steps. Writing a new default to
debian/gbp.conf does fix this.

The above also assumes that upstream==origin/upstream==latest
upstream. Which means you need to have done a git pull recently on the
upstream branch. Depending on the circumstances, using origin/upstream
might be a better choice rather then upstream.


Notes:

[1] Well apart from a new "source-is-missing" lintian warning, probably
from the new upstream. So probably not ready for upload just yet.
-- 
Brian May <b...@debian.org>



Re: Adopting OpenStack packages

2017-03-08 Thread Brian May
Simon McVittie <s...@debian.org> writes:

> Here's a maybe-stupid idea: use http://dep.debian.net/deps/dep14/ branch
> naming (debian/master, debian/experimental) for that branch, and switch to
> it as the default branch (edit foo.git/HEAD on alioth) when unfreezing
> and "officially" switching to gbp-pq?

One thing we could do right now, for selected packages, is create a
debian/experimental branch, switch to gbp-pq, update to latest upstream,
and upload to experimental. This will not interfere in any way to do
updates to unstable/testing - which still use the master branch, and
similarly won't cause any confusion which branch to use.

These packages that we do this to probably should be excluded from any
post-freeze automatic bulk switch to gbp-pq however. As the procedure is
likely to different (unless there are changes in the master branch, this
probably just involve creating a new debian/master branch from
debian/experimental and deleting the old master branch).

It might pay to have a list somewhere of packages that have already been
converted to gbp-pq, and what branches. Of course it is easy to
autodetect this too, just look for the presence of a debian/.git-dpm
file in that selected branches.

Before doing any automated conversion, we should make the following
checks on the following branches:

* master: exists and has debian/.git-dpm file
* debian/master: this branch should not exist - no DPMT package should
  be using this branch name yet.
* debian/experimental: if this exists it should have a debian/.git-dpm

If any of these checks fails, the respository should be converted
manually. Or it might be an indication that the repository is already in
the required format.

Any other branches are probably not that important for the 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>



Re: Transition away from git-dpm was: Re: Adopting OpenStack packages

2017-03-07 Thread Brian May
Thomas Goirand <z...@debian.org> writes:

>> Why debian/unstable, and not debian/sid?
>
> Because "unstable" is what we write in debian/changelog, so that's
> consistent, and also consistent if we upload to experimental. But I'm
> fine either ways anyway, if others 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>



Re: Transition away from git-dpm was: Re: Adopting OpenStack packages

2017-03-06 Thread Brian May
Scott Kitterman <sc...@kitterman.com> writes:

> Personally, I don't know enough to have an opinion.  I'm interested in the 
> views of DPMT members with gbp pq experience.  What's the consensus about 
> branch naming (all I know is for git-dpm, it was pretty hard wired)?

I tend to think that branching will easier with git pq. I seem to
remember some maintainers having problems with non-standard branch names
under git dpm. So one valid reason for not adopting different branches
will no longer apply.

I personally think that DEP14 would be a good idea. I think the only
difference people would notice is that master is renamed to
debian/master.

We would need to be careful though, having both a master and a
debian/master - even during transition planning - could be
confusing. Which one do I update? Probably no way to mark a branch read
only on alioth either (?).

After the transition, what happens to the master branch? Do we delete
it?
-- 
Brian May <b...@debian.org>



Re: Adopting OpenStack packages

2017-03-06 Thread Brian May
Vincent Bernat <ber...@debian.org> writes:

> I think you mean git-dpm.

Whoops. Yes, of course.
-- 
Brian May <b...@debian.org>



Re: Adopting OpenStack packages

2017-03-05 Thread 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 of this team, that
> doing vcs or other disruptive switches are bad ideas during times of release
> freezes.  For example, upstream CPython recently switched to git + github, but
> while an enormous amount of work went into making that as smooth as possible
> beforehand, the actual switch wasn't done until after the 3.6 release.

More importantly, from my perspective, I am unlikely to be making any
significant changes (in fact maybe no changes) to any of my packages
until after the freeze. So there doesn't seem to be much point in trying
to rush this through, right now. 

After the freeze, some of my packages will no doubt require updating the
the latest upstream version. This will be a good test for gbp pq. 

If people wanted to, now would be a good time to document/implement/test
the procedure for doing the conversion (without actually doing it for
real). 

Re: Adopting OpenStack packages

2017-03-05 Thread Brian May
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 good at the time, however the more I think about it, the
more I think gbp is the superior solution - especially for a team
effort. It is very easy to break gbp pq unless you are careful to follow
correct procedures. Once a broken repository is pushed (e.g. manual
changes to debian/patches/*), it is not easy to fix without liberal use
of pushing a rebased repository. Or starting git-dpm from scratch. If
there was a conflict with debian patches (fortunately this hasn't
happened to me yet), I think it would be very challenging to resolve the
conflict with git-dpm (not that gbp pq is going to be great in this
situation either, however I think it would be easier to understand what
is going on, and hence find a good solution). 

The concept to convert from git-dpm to gbp pq is very very easy: 

1. Delete debian/.git-dpm 
2. Unapply all patches. 
3. Commit and push. 

(repeat for all branches on all repositories) 

Step 2 is easier said then done. I can do it easy enough on my own
packages. I think we need a documented process anyone can follow. Plus
dealing with errors as required (e.g. if unapplying patches causes
conflicts due to non-compliant git-dpm package) - if anything like this
happens - hopefully on not many packages, these packages might require
manual processing. 

The obvious way "quilt pop -a" doesn't work, because the quilt .pc
directory does not exist, and quilt thinks the patches are already
unapplied. I sent an email previously with some (untested) suggestions I
had. 
  

Re: Adopting OpenStack packages

2017-03-03 Thread Brian May
Thomas Goirand <z...@debian.org> writes:

> And I'm not even addressing yet the horrible git-dpm troubles, how
> many more years the team is forcibly burying every contributor into.

There is discussion on changing this. The consensus seems to be we
should wait until after the next release however.

> Plus Alioth is a security nightmare, and it's loaded so much that even
> a simple git push can take hours (real life experience).

I have not noticed this. Maybe the repositories I have dealt with are
small and simple.

(I don't have any opinions on what should happen with the open stack
packages however).
-- 
Brian May <b...@debian.org>



Re: PAPT and git

2017-02-23 Thread Brian May
Barry Warsaw <ba...@debian.org> writes:

> Yes!  Stefano has a bunch of scripts that he used to convert DPMT svn to git,
> so there's a great starting place.  Probably the main thing to change there
> would be to forego conversion to git-dpm and work on conversion to
> gbp-pq.

I would suggest waiting until after the freeze. This is a bigger and
much more invasive change then simply converting git-dpm to gbp-pq.

> Or, let's be expedient and use the existing scripts to go to git-dpm for now,
> taking up gbp-pq transition along with DPMT after Stretch.

I haven't looked 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>



Pending broken links

2017-02-20 Thread Brian May
Hello,

I have noticed that the automatically generated links sent to the BTS on
git changes that close bugs are broken.

e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855510#10 has the
following link:

http://git.debian.org/?p=python-modules/packages/slimit.git;a=commitdiff;h=d20c791

Which generates the following error:

404 - No such project

Regards
-- 
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/



Re: How to split modules in multiple deb packages

2017-02-20 Thread Brian May
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>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-13 Thread Brian May
Scott Kitterman <deb...@kitterman.com> writes:

> We know in the DPMT context what debcheckout will produce, so for our 
> purposes they don't matter.
>
> How does dgit avoid maintainer forgot to push problems without being limited 
> to the granularity of one commit per upload?

When you upload a package, you upload the *.debs and push to git a the
same time. With the one dgit command that checks everything is
consistant, and tags things appropriately. I not sure of the exact
details of how the push is done yet.

I think dgit would really help with the problem I occasionally get: Does
this git source really correspond with the package that was
uploaded. Mistakes can happen in git that can result in you looking at
one git version that is very different to what was uploaded. Yes, this
does happen.

Mostly however, I think the prime benefit of using dgit would be that it
helps other non-team members maintain the package - as does happen from
time to time in the form on NMUs. We can help these people by sticking
to a standard that others can use.

It would not directly help DPMT workflow, as that mostly remains as
is. Hence my first priority would be to change 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>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-13 Thread Brian May
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>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-13 Thread Brian May
Barry Warsaw <ba...@debian.org> writes:

> One section I think we should add at some point is instructions on how to
> manually convert to gbp-pq, at least until we do a mass conversion.

Yes agreed.

Not sure how to unapply all patches. "quilt pop -a" won't work, quilt
doesn't realize the patches are applied.

"git checkout upstream -- ." would work, but won't delete any files that
were created by the patch.

Maybe something like the following?

git read-tree --reset -u upstream
git reset -- debian
git checkout debian
git rm debian/.git-dpm

The first line 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>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-12 Thread Brian May
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 didn't specify anything for dgit. The only sections that would require
changing would be the building and uploading sections, everything else
documented here would be unchanged.
-- 
Brian May <b...@debian.org>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-10 Thread Brian May
kuLa <k...@kulisz.net> writes:

> dgit indeed is using it's own repos:
> https://browse.dgit.debian.org/
> git.dgit.debian.org


The way I understand it is that dgit is simply a replacement for the
upload operation. To implement this with the required checks, it is
recommended (but not required) that you use its build operation.

Instead of using "dput" or similar, you use "dgit push". This checks the
most recent build and makes sure it was built correctly from git HEAD,
and then uploads the build to debian *and* the source to
git.dgit.debian.org

Apart from build and upload there are no other changes to standard
git-dpm or gbp pq procedures.

This provides one key benefit for us, we can be reasonably confident
that the upload corresponds with a published git source.

As an example of an existing dgit package with multiple patches, have a
look at Samba: https://browse.dgit.debian.org/samba.git/tree/debian/patches

Having said that, it looks like the server might be having problems at
the moment, I can't clone any packages.

[brian:/tmp] % dgit clone samba
canonical suite name for unstable is sid
fetching existing git history
remote: fatal: Out of memory, calloc failed
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header
dgit: failed command: git fetch -p -n -q https://git.dgit.debian.org/samba 
'+refs/tags/archive/debian/*:refs/dgit-fetch/debian/tags/archive/debian/*' 
'+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 <b...@debian.org>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-10 Thread Brian May
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: split brain (separate dgit view) may be needed (--quilt=gbp).
> dgit: base trees orig=3b9eaf2cb2a9245a1c10 o+d/p=6f1d04c157a8cd0a7eea
> dgit: quilt differences: src:  ## orig ## gitignores:  == orig ==
> dgit: quilt differences:  HEAD ## o+d/p   HEAD == o+d/p
> dgit: --quilt=gbp specified, implying patches-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.

Ok, so there really was a difference: the git archive was missing the
"docs/_static/.keep_dir" file that is included in the upstream file.

Probably good that dgit detects discrepancies such as these, however not
so good that it took me sometime to work out the problem based on the
given message. If it told me what was different, it would be much be
helpful.

(also leads to the question why this file was missing from my import
last month - but I can't remember what I did now)

When I did build the package I can confirm that the generated source
package had multiple patch files (as expected).
-- 
Brian May <b...@debian.org>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-10 Thread Brian May
Scott Kitterman <deb...@kitterman.com> writes:

> How is that different/better than debcheckout?

I am still learning dgit, however I think that dgit uses its own git
repositories. dgit-repos. I am not sure where these are located or how
access is controlled.

>From the man page 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>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-10 Thread Brian May
Nikolaus Rath <nikol...@rath.org> writes:

> But it seems to me that you are contemplating whether or not the team
> should be using dgit. This is also not a decision that needs to be made
> prior to any switch away from dgit-dpm, you can start using dgit at any
> point.

My vague understanding is that dgit complements the workflow, whatever
workflow you may want - including git-dpm and pq. Hence I was surprised
and confused when people said it only supported the single patch model -
I don't think this is correct.

My attempt to build a package (in this case pq based) was less then
successful. Possibly because I am not awake.

[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: split brain (separate dgit view) may be needed (--quilt=gbp).
dgit: base trees orig=3b9eaf2cb2a9245a1c10 o+d/p=6f1d04c157a8cd0a7eea
dgit: quilt differences: src:  ## orig ## gitignores:  == orig ==
dgit: quilt differences:  HEAD ## o+d/p   HEAD == o+d/p
dgit: --quilt=gbp specified, implying patches-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>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-08 Thread Brian May
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 tried making any changes.
-- 
Brian May <b...@debian.org>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-04 Thread Brian May
Barry Warsaw <ba...@debian.org> writes:

> What I'd really like to see is a page like
> https://wiki.debian.org/Python/GitPackaging for a non-git-dpm workflow.  (The
> page itself could probably use a bit of gardening anyway.)  Specifically, I'd
> like to see guidance on any tasks which are different for git-pq (or
> non-git-dpm as the case may be).
>
> I'd suggest cloning that page instead of modify that page to cover both
> cases.  Edit the clone as if it were the opinionated view of just using gbp
> tools and gbp-pq.  The page should also have instructions on opportunistically
> switching away from git-dpm.

What should we call the clone page?

PqGitPackaging???
-- 
Brian May <b...@debian.org>



Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-04 Thread Brian May
Scott Kitterman <deb...@kitterman.com> writes:

> We should probably be thinking in terms of post-release for this change.  
> During the pre-release freeze, the release team doesn't typically allow 
> changes that extraneous to fixing the specific issue they are letting a 
> package into Testing to fix.  The .git-dpm file is shipped in the package, so 
> if we drop git-dpm, we're going to have to deal with getting .git-dpm 
> removals 
> through the release team for any package that needs update during the
> freeze.

The .git-dpm file is only shipped with the Debian source package, and
AFAIK has no meaning outside git. So it is a useless file for the Debian
source package. There should be no impact whatsoever in removing it, and
you could even argue that it was a bug to distribute it in the Debian
source in the fist place.

> That will also give us time 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>



Re: python-django-mptt

2017-02-02 Thread Brian May
Thomas Goirand <z...@debian.org> writes:

> I just tried to fix the FTBFS of a few pakcages last aug. after the
> Django 1.10 upload indeed. But I can't remember what I did for this
> package, for which I don't care much (I just tried to be helpful
> globally in Debian in this case). Did I forget to include what I push to
> Git? :/

Ok, so it looks like the patch was applied, however the changelog entry
was not updated.

However I still can't get it to build.

So keeping the RC bug open is still appropriate.

I tried updating to the latest upstream version (see git) however 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>



python-django-mptt

2017-01-31 Thread Brian May
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 last email too, but will have to
double check this) 

https://anonscm.debian.org/cgit/python-modules/packages/python-django-mptt.git/tree/debian/changelog


Regards

  

Re: [Python-modules-team] Bug#849652: faker: FTBFS on 32-bit: ValueError: timestamp out of range for platform time_t

2017-01-30 Thread Brian May
To: debian-python mailing list

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
date_time_this_century() function that appears to be the cause of it.

Thanks

"Chris West (Faux)" <solo-debianb...@goeswhere.com> writes:

> The package fails to build:
>
> FulROR: test_date_time_this_period (faker.tests.FactoryTestCase)
> --
> Traceback (most recent call last):
>   File "faker/tests/__init__.py", line 389, in test_date_time_this_period
> 
> self.assertTrue(self._datetime_to_time(provider.date_time_this_century(before_now=False,
>  after_now=True)) >= self._datetime_to_time(datetime.datetime.now()))
>   File "faker/providers/date_time/__init__.py", line 403, in 
> date_time_this_century
> return cls.date_time_between_dates(now, next_century_start, tzinfo)
>   File "faker/providers/date_time/__init__.py", line 381, in 
> date_time_between_dates
> datetime_to_timestamp(datetime_end),
>   File "faker/providers/date_time/__init__.py", line 22, in 
> datetime_to_timestamp
> return mktime(dt.timetuple())
> OverflowError: mktime argument out of range
>
> ==
> ERROR: test_date_time_this_period_with_tzinfo (faker.tests.FactoryTestCase)
> --
> Traceback (most recent call last):
>   File "faker/tests/__init__.py", line 418, in 
> test_date_time_this_period_with_tzinfo
> provider.date_time_this_century(before_now=False, after_now=True, 
> tzinfo=utc) >= datetime.datetime.now()
>   File "faker/providers/date_time/__init__.py", line 403, in 
> date_time_this_century
> return cls.date_time_between_dates(now, next_century_start, tzinfo)
>   File "faker/providers/date_time/__init__.py", line 381, in 
> date_time_between_dates
> datetime_to_timestamp(datetime_end),
>   File "faker/providers/date_time/__init__.py", line 21, in 
> datetime_to_timestamp
> dt = dt.astimezone(tzlocal())
>   File "/usr/lib/python2.7/dist-packages/dateutil/tz/tz.py", line 99, in 
> utcoffset
> if self._isdst(dt):
>   File "/usr/lib/python2.7/dist-packages/dateutil/tz/tz.py", line 143, in 
> _isdst
> return time.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>



Re: git-dpm breakage src:faker

2017-01-30 Thread Brian May
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>



Re: git-dpm breakage src:faker

2017-01-29 Thread Brian May
Raphael Hertzog <hert...@debian.org> writes:

> 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.

Guess it depends how you build the package. I 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>



Re: [Python-modules-team] Bug#851722: django-pipeline: FTBFS randomly (failing tests)

2017-01-28 Thread Brian May
Hello All,

I would appreciate any help with this bug. While I have ideas on the
cause, I cannot reproduce it; and I am reluctant to forward upstream a
bug I cannot personally reproduce.

Thanks.


Santiago Vila <sanv...@debian.org> writes:

> Package: src:django-pipeline
> Version: 1.6.8-2
> Severity: important
>
> Dear maintainer:
>
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> but it failed:
>
> 
> [...]
>  debian/rules build-indep
> dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
>dh_testdir -i -O--buildsystem=pybuild
>dh_update_autotools_config -i -O--buildsystem=pybuild
>dh_auto_configure -i -O--buildsystem=pybuild
> I: pybuild base:184: python2.7 setup.py config 
> running config
> I: pybuild base:184: python3.5 setup.py config 
> running config
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/<>'
> dh_auto_build
> I: pybuild base:184: /usr/bin/python setup.py build 
> running build
>
> [... snipped ...]
>
> default_collector.clear()
>   File "/<>/pipeline/collector.py", line 23, in clear
> dirs, files = self.storage.listdir(path)
>   File "/usr/lib/python2.7/dist-packages/django/core/files/storage.py", line 
> 399, in listdir
> for entry in os.listdir(path):
> OSError: [Errno 2] No such file or directory: '/<>/tests/static'
>
> ==
> ERROR: test_pipeline_enabled_and_found 
> (tests.tests.test_views.ServeStaticViewsTest)
> --
> Traceback (most recent call last):
>   File "/<>/tests/tests/test_views.py", line 24, in setUp
> default_collector.clear()
>   File "/<>/pipeline/collector.py", line 23, in clear
> dirs, files = self.storage.listdir(path)
>   File "/usr/lib/python2.7/dist-packages/django/core/files/storage.py", line 
> 399, in listdir
> for entry in os.listdir(path):
> OSError: [Errno 2] No such file or directory: '/<>/tests/static'
>
> ==
> ERROR: test_pipeline_enabled_and_not_found 
> (tests.tests.test_views.ServeStaticViewsTest)
> --
> Traceback (most recent call last):
>   File "/<>/tests/tests/test_views.py", line 24, in setUp
> default_collector.clear()
>   File "/<>/pipeline/collector.py", line 23, in clear
> dirs, files = self.storage.listdir(path)
>   File "/usr/lib/python2.7/dist-packages/django/core/files/storage.py", line 
> 399, in listdir
> for entry in os.listdir(path):
> OSError: [Errno 2] No such file or directory: '/<>/tests/static'
>
> --
> Ran 88 tests in 0.931s
>
> FAILED (errors=8, skipped=15)
> Creating test database for alias 'default'...
> Destroying test database for alias 'default'...
> E: pybuild pybuild:276: test: plugin custom failed with: exit code=1: 
> PYTHONPATH=. python2.7 /usr/bin/django-admin test --settings=tests.settings
> dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
> debian/rules:24: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 25
> make[1]: Leaving directory '/<>'
> debian/rules:11: recipe for target 'build-indep' failed
> make: *** [build-indep] Error 2
> dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
> 
>
> This is just how the build ends, not necessarily the relevant part.
>
> I've put several build logs here:
>
> https://people.debian.org/~sanvila/build-logs/django-pipeline/
>
> If this is really a bug in one of the build-depends, please use reassign and 
> affects,
> so that this is still visible in the page for this package.
>
> The bug should be reproducible with sbuild on a single CPU virtual machine,
> provided you try enough times (as the failure happens randomly).
>
> Thanks.
>
> ___
> Python-modules-team mailing list
> python-modules-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
-- 
Brian May <b...@debian.org>



  1   2   3   4   >