Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Scott Kitterman]

On September 29, 2015 7:55:36 AM EDT, Julien Cristau 
 wrote:
>On Tue, Sep 29, 2015 at 12:26:44 +0100, Sandro Tosi wrote:
>
>> Once again, the python policy about Maintainer/Uploaders has been
>ignored
>> 
>>
>http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership
>> https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin
>> 
>> either policy changes or this has to stop at some point.
>> 
>OTOH, this is experimental.  It's not like this upload has any effect
>on
>anyone except to let Thomas work on packages that depend on it.  Are
>there any specific changes you object to, and that can't be easily
>reverted before an upload to unstable?

It's also not much effort to do a bit of coordination with the team.  The 
technical impact of this kind of antisocial behavior is, IMO, secondary.

Scott K

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Barry Warsaw]

On Sep 29, 2015, at 12:26 PM, Sandro Tosi wrote:

>Once again, the python policy about Maintainer/Uploaders has been ignored
>
>either policy changes or this has to stop at some point.

A few observations.

The policy should perhaps be better promoted or more explicitly written.  The
links you provided are useful, but I wonder whether they are easily
overlooked, forgotten, or misinterpreted.

Policy doesn't really spell out the operational differences for when the team
is Maintainer vs. Uploader, and the wiki page explicitly says it's an
*unwritten* policy (despite the fact that putting it in the wiki probably
qualifies as "written" :).  How should the change be acknowledged by the
maintainer?  Should I Cc the mailing list when I contact the maintainer?  Is
it okay to commit to vcs but not upload?  How long do you wait for feedback
before you can do the upload?

(Aside: git!  I would love to be able to commit and push a branch and then ask
for the maintainer to review, merge, and upload - or give me the green light
to go ahead.)

Should we have some automated tools to help out here?  I'm not sure where to
hook in such a tool, but if for example when I build a source package, I got a
nice little lintian-like warning saying "The package is team uploadable but
not team maintained, did you give the maintainer time to respond to your
issue?"  Something like that would go a long way toward mitigating accidental
or careless toe-stepping.

Do all team members understand the implications when they set the two fields?
Some maintainers may not really care and may have been less conscientious
about setting the fields.

The wiki says that the general rule of thumb is to set the team as Maintainer,
to which I agree.  I may not have been as deliberate about my own packages, so
I plan on reviewing them, and will fix any that aren't "special".

Cheers,
-Barry

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Piotr Ożarowski]

[Sandro Tosi, 2015-09-29]
> Once again, the python policy about Maintainer/Uploaders has been ignored
> 
> http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership
> https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin
> 
> either policy changes or this has to stop at some point.

it still applies and I will start removing people from DPMT / PAPT who
do not follow it.
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Sandro Tosi]

Once again, the python policy about Maintainer/Uploaders has been ignored

http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership
https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin

either policy changes or this has to stop at some point.

On Tue, Sep 29, 2015 at 12:19 PM, Debian FTP Masters
 wrote:
>
>
> Accepted:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Wed, 02 Sep 2015 13:17:15 +
> Source: python-networkx
> Binary: python-networkx python3-networkx python-networkx-doc
> Architecture: source all
> Version: 1.10-1
> Distribution: experimental
> Urgency: medium
> Maintainer: Sandro Tosi 
> Changed-By: Thomas Goirand 
> Description:
>  python-networkx - tool to create, manipulate and study complex networks
>  python-networkx-doc - tool to create, manipulate and study complex networks 
> - documenta
>  python3-networkx - tool to create, manipulate and study complex networks 
> (Python3)
> Closes: 800431
> Changes:
>  python-networkx (1.10-1) experimental; urgency=medium
>  .
>[ Sandro Tosi ]
>* New upstream release (Closes: #800431).
>  .
>[ Thomas Goirand ]
>* Move to Build-Depends: what was in Build-Depends-Indep: but which is 
> needed
>  for the clean target.
>* Dropped version of packages for those already provided in Jessie.
>* Removed now useless python-3.4.patch patch from Chuck Short.
>* Removed do-not-use-sphinx_rtd_theme.patch patch. Build-Depends on the
>  python-sphinx-rtd-theme package instead.
>* Exclude tests which are doing internet access and failing.
>* Do not rename non-existing README file.
> Checksums-Sha1:
>  43b217e9bfc7a180822f6bb72c507670fc4161b6 2550 python-networkx_1.10-1.dsc
>  99292e464c25be5e96de295752880bf5e5f1848a 1189291 
> python-networkx_1.10.orig.tar.gz
>  1ec58c43a77675987a4c087f4034de393a8c31e6 187972 
> python-networkx_1.10-1.debian.tar.xz
>  858a5824f6ff6e20182d0b572319933485498c48 4483016 
> python-networkx-doc_1.10-1_all.deb
>  ac050975613a620d1acb5b2a6e12f1d69dec34c6 820962 
> python-networkx_1.10-1_all.deb
>  f6feb64baa117e593b1ad7a90f782fbc361b1bf8 621436 
> python3-networkx_1.10-1_all.deb
> Checksums-Sha256:
>  c25abfa8a95bcad43df30823b89e3d676674d00ec9d60c2c0e24165ac43ea710 2550 
> python-networkx_1.10-1.dsc
>  ced4095ab83b7451cec1172183eff419ed32e21397ea4e1971d92a5808ed6fb8 1189291 
> python-networkx_1.10.orig.tar.gz
>  b0ce586bcb110d276e6195c6dc9448f1aa7c30e1172d79053abf7e296f68030f 187972 
> python-networkx_1.10-1.debian.tar.xz
>  f1f064fc93d9532743536474cdf4fce24e46599f74c79256461b4c4e17a19bda 4483016 
> python-networkx-doc_1.10-1_all.deb
>  280b30027e3d3f36e83d1bee434a456db80553e697e4ff21a399b136d2a7568e 820962 
> python-networkx_1.10-1_all.deb
>  6c615e4a23a98d62215bb49ba2746ce7111ba3fd53e2ef06f0f2a1b876f3ab54 621436 
> python3-networkx_1.10-1_all.deb
> Files:
>  478146aafb466aa4480002d8e0283e56 2550 python optional 
> python-networkx_1.10-1.dsc
>  eb7a065e37250a4cc009919dacfe7a9d 1189291 python optional 
> python-networkx_1.10.orig.tar.gz
>  7fc5a2a7210482fd793b5567a56e5471 187972 python optional 
> python-networkx_1.10-1.debian.tar.xz
>  c92c6f60db8e58f5964e640917503960 4483016 doc optional 
> python-networkx-doc_1.10-1_all.deb
>  90fce4157d27999dde4bd61db1e46c7f 820962 python optional 
> python-networkx_1.10-1_all.deb
>  c1e4b687e06e67fea72228d29a17372b 621436 python optional 
> python3-networkx_1.10-1_all.deb
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJWCm7EAAoJENQWrRWsa0P+Bj8QAIlac+W7xs6l+1PmSCUOUmLI
> qGH3HOHfDX+9uFCa1ILz41K2OnP8F54o9SAdHLY+ckdGXoSTNT//SlqalrfUwEfi
> DXstqVfZGzgsJSh/a4cF4eutWRdEZeCcVGzhJvvZV5icIheRujEkD22BDPerw1fH
> kIPzYnV9dKWGS7xf5gLEHivhu2GloazSMFDrCSF2jE+e1sAoQvpbuquxLfBS0xVg
> 3kfDYIIXv3JV5WReETF/kN5us2eA34L4dAzehqe1+LLR9WEsjNTVCe7nuSV1/eyA
> +R+wsPRlZNVlzuWz2ieshVL3BXD8EWf9jC2mYinIQhC+VxWLC0qNTNRE7JE4n+Gu
> JJU2YvXLOIRHyld7EjYBrYqeZkz+buQ2Q036R5TQN4PH3H1jZKUrKhUdnBNgAf3Y
> YqoactuiZyCvRjMSnsFzsr6hwjpvpHVgJkUDgfFTiJtVQDO/371VzJwtoPrXV4yI
> obOD4MaW9n3afxF5NRRDZa2Nq8RRPAlNFu+u7sLrIvlUVe5ERSb7GnGWWAeNAF02
> okm8s9HVNZbs6BUoa8hz37OfyPc5AOW3XpOn1libP2JVW6+0Ah6/mU9fq56dOP5o
> nVbMSC74MMy6xLmi3jBVk4ChQg2MwaXQzik55U6JW5MK3P9s6Sq0A67Zs+fuyE3M
> GYO+p3rg2WMFx0SdeWjH
> =ir36
> -END PGP SIGNATURE-
>
>
> Thank you for your contribution to Debian.



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Bug#800437: ITP: python-sievelib -- Client-side Sieve and Managesieve library

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-sievelib
  Version : 0.8
  Upstream Author : Antoine Nguyen 
* URL : https://pypi.python.org/pypi/sievelib
* License : Expat
  Programming Lang: Python
  Description : Client-side Sieve and Managesieve library

 Client-side Sieve and Managesieve library written in Python.
 .
 Sieve:
 Currently, the provided parser supports most of the functionalities described
 in RFC 5228. The only exception concerns section 2.4.2.4. Encoding Characters
 using "encoded-character" which is not supported.
 The following Sieve extensions are also supported:
  * Date and Index (RFC 5260)
  * Vacation (RFC 5230)
 .
 ManageSieve:
 All mandatory commands are supported. The RENAME extension is supported, with a
 simulated behaviour for server that do not support it.
 For the AUTHENTICATE command, supported mechanisms are DIGEST-MD5, PLAIN and
 LOGIN.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJWCmSZAAoJEGlMre9Rx7W2zxgQAJFiF8aI2HleVK/v4bBgXYW/
+piXia+uP5o1k0H2fLrI/HNumSQGUryQTz1iYMRb3z3OtRv/qGTnPNTchx2qpLBw
chQJHAs8Gv/SRILFy8J+vs0P66QCORYevbN846ZjPO06/QkowVIywnm3BXgxkr7r
eTShIgNG3S5tv1dosOXgzifqEowIHIlP6Z9iI6FfwhhGfsE+cs4j8znwOHfWcVEG
EMqDb79fKlk19IAHAtyOL4cW7k3hBkoWQqyGu+1kZmJw18Imi3bUasP/MmCwIPAm
ZoXyeQpvkGo59VkRpE0swYZNrjztSbx54f0XMgT8g5SAbUXBMTc5PYuA3pp2ZBYh
Zvku0joyzVZKGooX4yRZ8AHtCOMLG9Xj2aFi7/sP5U9+0MZI2I51TeyBoC5lIb1L
vFhUVA82dNTGC7xSqxOQrsggSsJdWzc6dds1E2WWCHVqZimLTKyqNTSaJeSaFNKa
ZDG+BvNMJXaa9cnZI9kr5jVNqK6GuFi79Tafx25y+JToE38xMDFallpcGoOOrD3Q
xMVAiMYfITTXTu0Bv8PITkM8OGEgWfvZUxlJpPQWiwVt5zyPXCDqY4MuxgT0Yebk
I5X3ukw/Ek318vU0ntBkS05PIwO+5Tkf/69Y4j7h87sD67XfplNZELrRXg7FcEud
VpxwsooeCPOtmX7VE/Xh
=OsAc
-END PGP SIGNATURE-

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Julien Cristau]

On Tue, Sep 29, 2015 at 12:26:44 +0100, Sandro Tosi wrote:

> Once again, the python policy about Maintainer/Uploaders has been ignored
> 
> http://python-modules.alioth.debian.org/python-modules-policy.html#maintainership
> https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin
> 
> either policy changes or this has to stop at some point.
> 
OTOH, this is experimental.  It's not like this upload has any effect on
anyone except to let Thomas work on packages that depend on it.  Are
there any specific changes you object to, and that can't be easily
reverted before an upload to unstable?

Cheers,
Julien
-- 
Julien Cristau  
Logilab http://www.logilab.fr/
Informatique scientifique & gestion de connaissances

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Sandro Tosi]

> OTOH, this is experimental.  It's not like this upload has any effect on
> anyone except to let Thomas work on packages that depend on it.

still the policy defines a set of rules that apply to any debian
suites, or are you suggesting that experimental is not cover by those
rules and we could do whatever we want?

The bug asking for a new version was issues 2 hours before the upload
with urgency wishlist, without mentioning it was a blocker for
anything.

>  Are
> there any specific changes you object to

As for the technical aspects, tests were disabled mentioning they
access internet (and from the code it is not clear at all if they do,
and I kinda doubt that), the test suite for py3k fails with 'FAILED
(SKIP=17, errors=69, failures=13)' halting the build in my clean
pbuilder env, the doc requirements list "sphinxcontrib-bibtex" which
is not yet in debian (the reason I halted the upgrade myself sometime
ago) so I'm not sure how the doc could have been built + all the time
I wasted having to write this

>, and that can't be easily
> reverted before an upload to unstable?

I dont know if I understand correctly: are you saying that, since he
needed that package updated he could technical sub-optimal work, and
then let the maintainer/somebody else fix what's left broken? because
that's what's going to happen :(  (python3-memcache anyone?)

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Maintainer vs. Uploaders

[Piotr Ożarowski]

[Barry Warsaw, 2015-09-29]
> How should the change be acknowledged by the
> maintainer?  Should I Cc the mailing list when I contact the maintainer?  Is

do we really need a written policy how to contact fellow co-maintainer? 
Ping on IRC, send an email, send a message via xmpp or phone, ... use
whatever you usually use to contact any other Debian maintainer.

An example message:
"I just commited some changes in foo related to bar. Please take a look,
I plan to upload it to unstable in a day or two. Let me know if I should
wait a bit longer or if you're not OK with these changes. Thanks"

I think such message to all Uploaders who clearly know more about given
package than I do is a good practice even if team is listed in
Maintainer field. I don't think sending such message after fixing a typo
is needed, but it's definitely a must when someone replaces dh with
cdbs or vice versa.

> it okay to commit to vcs but not upload?  How long do you wait for feedback
> before you can do the upload?

yes, it's always OK to commit changes (which can be reverted). It's not OK
to force someone else to maintain these changes by uploading it.

> Should we have some automated tools to help out here?  I'm not sure where to

no, we already have -commits mailing list which nobody reads. Yet
another reason why team should be in Uploaders and not in Maintainer
field.

> Do all team members understand the implications when they set the two fields?
> Some maintainers may not really care and may have been less conscientious
> about setting the fields.

Maintainer vs Uploaders rules needs to be moved to policy. I will
propose a patch to the policy soon (I'd prefer a native speaker to do
it, though)

> The wiki says that the general rule of thumb is to set the team as Maintainer,
> to which I agree.

I don't (due to "package and forget" issue)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Julien Puydt]

Hi,

Le mardi 29 sept. 2015 à 09:48:16 (-0400), Barry Warsaw a écrit :
> On Sep 29, 2015, at 12:26 PM, Sandro Tosi wrote:
> 
> >Once again, the python policy about Maintainer/Uploaders has been ignored
> >
> >either policy changes or this has to stop at some point.
> 
> A few observations.
> 
> The policy should perhaps be better promoted or more explicitly written.  The
> links you provided are useful, but I wonder whether they are easily
> overlooked, forgotten, or misinterpreted.
> 
> Policy doesn't really spell out the operational differences for when the team
> is Maintainer vs. Uploader, and the wiki page explicitly says it's an
> *unwritten* policy (despite the fact that putting it in the wiki probably
> qualifies as "written" :).  How should the change be acknowledged by the
> maintainer?  Should I Cc the mailing list when I contact the maintainer?  Is
> it okay to commit to vcs but not upload?  How long do you wait for feedback
> before you can do the upload?

I'm just a DM, but I'm still in the team, so I think I can state my 
opinion, and explain how I would do things.

First thing, report a bug on the package (request for a new version, for 
example). Wait. Provide patches. Wait.

Second, contact the maintainer off list Wait.

Third, contact the list and put the maintainer in CC, stating that 
things don't get further fast enough and you would like the team to get 
involved. Wait.

Fourth, if the maintainer hasn't answered, then proceed with an RFS or 
upload (depending on whether one is DD or DM).

> (Aside: git!  I would love to be able to commit and push a branch and then ask
> for the maintainer to review, merge, and upload - or give me the green light
> to go ahead.)

I create all my packages in git -- that's what the debian-science team 
uses. And I consider the fact that a package is subversion-maintained a 
hindrance.
 
> Should we have some automated tools to help out here?  I'm not sure where to
> hook in such a tool, but if for example when I build a source package, I got a
> nice little lintian-like warning saying "The package is team uploadable but
> not team maintained, did you give the maintainer time to respond to your
> issue?"  Something like that would go a long way toward mitigating accidental
> or careless toe-stepping.

Oh dear, another lintian output to bother me! And don't call that a 
"warning", some sensitive people prefer the word "tag" :-P

> Do all team members understand the implications when they set the two fields?
> Some maintainers may not really care and may have been less conscientious
> about setting the fields.

I definitely didn't really understand the implications. I put the DPMT 
as maintainer and myself as uploader because :
- I want lintian not to  bug me about NMU ;
- I want to make clear I won't consider people are stepping on my toes if
they start helping with a package.

Cheers,

Snark on #debian-python

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Barry Warsaw]

On Sep 29, 2015, at 02:02 PM, Tristan Seligmann wrote:

>After reading this thread, I feel like I should go through all of my
>packages and remove the team from Maintainer for all of them. I try very
>hard to respond promptly to pings (bugs, email, IRC, ...) about my
>packages, even if it's just to say "sorry, I can't take care of that right
>now, feel free to upload"; but I'm not sure that having someone blindly
>upload my packages if they haven't worked on them before is a good idea.

I'm willing to deal with some honest mistakes with my packages in order to
foster a vibrant and active community.

I am happy to answer questions about my packages, but I feel spoiled by how
nicely things work as an upstream with code hosting sites like GitLab.  If we
had merge requests, online and email reviews, one-click auto-merge (and
uploads!) I think we'd have a better team collaboration workflow.  Even
post-commit/upload emailed diffs would at least let me review changes after
the fact, so I could repair things if I noticed a big problem.

Cheers,
-Barry

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Tristan Seligmann]

On Tue, 29 Sep 2015 at 15:48 Barry Warsaw  wrote:

> The wiki says that the general rule of thumb is to set the team as
> Maintainer,
> to which I agree.  I may not have been as deliberate about my own
> packages, so
> I plan on reviewing them, and will fix any that aren't "special".
>

After reading this thread, I feel like I should go through all of my
packages and remove the team from Maintainer for all of them. I try very
hard to respond promptly to pings (bugs, email, IRC, ...) about my
packages, even if it's just to say "sorry, I can't take care of that right
now, feel free to upload"; but I'm not sure that having someone blindly
upload my packages if they haven't worked on them before is a good idea.

(And I say this having done a few team uploads in DPMT / collab-maint
recently; while I didn't think too much about these at the time, in
retrospect I feel like I made a mistake uploading those packages)

git migration (AKA missing old good svn days)

[Piotr Ożarowski]

[Barry Warsaw, 2015-09-29]
> On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote:
> 
> >(and remember to remove DPMT from debian/control if it's not in SVN ;P)
> 
> Given that the final git migration is imminent (really! otherwise I'm going to
> scream ;), can we not force people to go through this churn right now?

but it's OK to force others to search for repo location, used workflow,
tool, naming convention, etc?

> Yes, let's discourage any new packages from manually migrating or starting out
> in git just until flag day.  But I'm not sure it's worth removing DPMT on
> existing repos just to add it back, hopefully RSN.

we agreed to something - 1 package per person, just for tests, with
reports sent to this mailing list. Can you point me to a single report?
Can you point me to a single person who converted only one package?
Are you sure everyone uses the same workflow?

I don't like it, I don't like it at all and that's why I complain and
that's why I don't sponsor such packages.
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: git migration (AKA missing old good svn days)

[Vincent Bernat]

 ❦ 29 septembre 2015 23:05 +0200, Piotr Ożarowski  :

>> Yes, let's discourage any new packages from manually migrating or starting 
>> out
>> in git just until flag day.  But I'm not sure it's worth removing DPMT on
>> existing repos just to add it back, hopefully RSN.
>
> we agreed to something - 1 package per person, just for tests, with
> reports sent to this mailing list. Can you point me to a single
> report?

I may have missed this announce. What's the message ID?
-- 
Perilous to all of us are the devices of an art deeper than we ourselves
possess.
-- Gandalf the Grey [J.R.R. Tolkien, "Lord of the
Rings"]


signature.asc
Description: PGP signature

Re: lintian and team uploads

[Scott Kitterman]

On Tuesday, September 29, 2015 10:31:23 PM Julien Puydt wrote:
> Le mardi 29 sept. 2015 à 15:51:44 (-0400), Barry Warsaw a écrit :
> > On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote:
> > >(and remember to remove DPMT from debian/control if it's not in SVN ;P)
> > 
> > Given that the final git migration is imminent (really! otherwise I'm
> > going to scream ;), can we not force people to go through this churn
> > right now?
> Indeed, I find that offensive : if git is a better tool than subversion,
> and if it's going to be used, what's the point?
> 
> > Yes, let's discourage any new packages from manually migrating or starting
> > out in git just until flag day.  But I'm not sure it's worth removing
> > DPMT on existing repos just to add it back, hopefully RSN.
> 
> I would like to make some points clear:
> 1. I wouldn't have contributed a single package in subversion, as it's just
> too cumbersome to use. I liked svn when it replaced cvs, but not so much
> since I started using git.
> 2. When I saw the DPMT policy mentioned only subversion, I asked around
> (can't remember if it was just on IRC or on this ml) and was told it was ok
> to use git since the migration was bound to happen sooner or later.
> 3. Afterwards, being just a DM, I sent RFS mails through this very list in
> which I generally gave the Vcs-* fields from the d/control files, which
> clearly showed I used git : no complaint about it.
> 4. Those package got sponsored without complaint about it either.
> 
> So you'll understand that getting flames (even with smileys) about it
> now is quite annoying.
> 
> I still have a series of things I plan to package for Debian ; those are
> Python Modules, and I'll use git. If that's a problem for the Debian
> Python Modules Team, can you point me to a more appropriate team?

Just chill out and have a little patience.  What VCS gets used just doesn't 
make that much different for most things we need to do.  If you can't bring 
yourself to commit to svn, then just have a bit of patience.

Scott K

Re: Maintainer vs. Uploaders

[Barry Warsaw]

On Sep 29, 2015, at 04:30 PM, Piotr Ożarowski wrote:

>Maintainer vs Uploaders rules needs to be moved to policy. I will
>propose a patch to the policy soon (I'd prefer a native speaker to do
>it, though)

+1, and I'd be happy to review the specific text.

Cheers,
-Barry

Re: Suggestion for recommended build tools a python application

[Julien Puydt]

Hi,

Le mercredi 30 sept. 2015 à 00:17:32 (+0600), Titon Barua a écrit :
> I found some online resource where someone suggested using autotools for
> building GTK+python applications. I can definitely go that route, but how
> would it affect packaging for debian? How am I supposed to specify the
> python module dependencies?

With autotools, you can check python deps using the AC_CHECK_PYTHON_MODULE
macro, which you can for example find here:
http://anonscm.debian.org/cgit/debian-science/packages/sagemath.git/tree/debian/pruner/m4/python_module.m4

Snark on #debian-python

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Piotr Ożarowski]

[Barry Warsaw, 2015-09-29]
> On Sep 29, 2015, at 05:40 PM, Julien Puydt wrote:
> 
> >- I want lintian not to  bug me about NMU ;
> 
> This one's easy.  Just put "Team upload" in the changelog (e.g. `dch --team`).

it's even easier than that... add yourself to Uploaders (you're
maintaining it after all!)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: python-networkx_1.10-1_amd64.changes ACCEPTED into experimental

[Julien Puydt]

Le mardi 29 sept. 2015 à 20:40:11 (+0200), Piotr Ożarowski a écrit :
> [Barry Warsaw, 2015-09-29]
> > On Sep 29, 2015, at 05:40 PM, Julien Puydt wrote:
> > 
> > >- I want lintian not to  bug me about NMU ;
> > 
> > This one's easy.  Just put "Team upload" in the changelog (e.g. `dch 
> > --team`).
> 
> it's even easier than that... add yourself to Uploaders (you're
> maintaining it after all!)

Yes, that's what I said: I put myself as uploaders so lintian
doesn't bug me about NMU. 

Snark on #debian-python

Suggestion for recommended build tools a python application

[Titon Barua]

Hi,
I am developing a plugin for IBus, written in python3. The project depends
on some other python modules and system packages, like python3-gi,
gir1.2-ibus-1.0 etc. Also, it needs to install data files to the system (
inside /usr/lib/ibus/component/) to make itself available to IBus. I am a
debian user and the project being debian packaging friendly is an important
goal.

As far as my project requirements go, I can't use any of the
distutils/setuptools/distribute since they can't handle dependency checks
not satiable through PyPI ( ridiculous isn't it? ). I can't also dive into
the absurdity of making a `wheel` and installing it with `pip` since wheels
don't allow file deployment in absolute system path.

I found some online resource where someone suggested using autotools for
building GTK+python applications. I can definitely go that route, but how
would it affect packaging for debian? How am I supposed to specify the
python module dependencies?

I've done some research on 'dh' with 'pybuild', but it seems to be
concerned with packaging python projects using in distutils family tools.

Right now, my project has a custom installer script that asks the users to
install necessary packages and copies the files to the appropriate
location. I would gladly appreciate if anyone can guide to a saner
alternative.

- Titon

[ Sorry for overwhelming you guys with questions. I love python, but I
absolutely despise being a back-end server side application developer who
writes in python; every bit of productivity gained by the language is
usually lost in pulling out hairs in times of deployment and system
integration. ]

Re: Bug#798999: transition: python3.5 supported

[Tomasz Rybak]

Dnia 2015-09-27, nie o godzinie 10:28 -0400, Scott Kitterman pisze:
[ cut ]
> Yes.  They have started.  I think we're about a third of the way
> through Dependency level 1.  Numpy is in Dependency level 5, so this
> is not unexpected for now.  You can follow the progress in the
> transition tracker [1].
> 

Can I ask to not automatically rebuild PyOpenCL?
I'll rebuild and upload it myself, with few fixes.

Best regards.

-- 
Tomasz Rybak  GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A  488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak




signature.asc
Description: This is a digitally signed message part

lintian and team uploads

[Piotr Ożarowski]

[Julien Puydt, 2015-09-29]
> Yes, that's what I said: I put myself as uploaders so lintian
> doesn't bug me about NMU. 

my guess¹ is that you used different name/email in debian/control and
debian/changelog

[¹] and it's the last one, include pointer to sources next time
(and remember to remove DPMT from debian/control if it's not in SVN ;P)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: lintian and team uploads

[Barry Warsaw]

On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote:

>(and remember to remove DPMT from debian/control if it's not in SVN ;P)

Given that the final git migration is imminent (really! otherwise I'm going to
scream ;), can we not force people to go through this churn right now?

Yes, let's discourage any new packages from manually migrating or starting out
in git just until flag day.  But I'm not sure it's worth removing DPMT on
existing repos just to add it back, hopefully RSN.

Cheers,
-Barry

Re: lintian and team uploads

[Julien Puydt]

Le mardi 29 sept. 2015 à 15:51:44 (-0400), Barry Warsaw a écrit :
> On Sep 29, 2015, at 09:46 PM, Piotr Ożarowski wrote:
> 
> >(and remember to remove DPMT from debian/control if it's not in SVN ;P)
> 
> Given that the final git migration is imminent (really! otherwise I'm going to
> scream ;), can we not force people to go through this churn right now?

Indeed, I find that offensive : if git is a better tool than subversion, 
and if it's going to be used, what's the point?
 
> Yes, let's discourage any new packages from manually migrating or starting out
> in git just until flag day.  But I'm not sure it's worth removing DPMT on
> existing repos just to add it back, hopefully RSN.

I would like to make some points clear:
1. I wouldn't have contributed a single package in subversion, as it's just
too cumbersome to use. I liked svn when it replaced cvs, but not so much
since I started using git.
2. When I saw the DPMT policy mentioned only subversion, I asked around (can't
remember if it was just on IRC or on this ml) and was told it was ok to use
git since the migration was bound to happen sooner or later.
3. Afterwards, being just a DM, I sent RFS mails through this very list in
which I generally gave the Vcs-* fields from the d/control files, which
clearly showed I used git : no complaint about it.
4. Those package got sponsored without complaint about it either.

So you'll understand that getting flames (even with smileys) about it 
now is quite annoying.

I still have a series of things I plan to package for Debian ; those are 
Python Modules, and I'll use git. If that's a problem for the Debian 
Python Modules Team, can you point me to a more appropriate team?

Snark on #debian-python