Re: DPMT and git workflows

2018-01-19 Thread Stuart Prescott
IOhannes m zmölnig (Debian/GNU) wrote:
> On 01/19/2018 12:45 PM, Simon McVittie wrote:
>> Relatedly, Alioth is going to be shut down at some point, with git
>> repositories frozen and made read-only, so it would seem a good idea to
>> start migrating git packaging to salsa.debian.org before that happens.
>> python-modules-team and python-apps-team groups, perhaps? I can create
>> a python-modules-team group and migrate tap.py as a sample if people
>> would like to see an example package.
>> 
> 
> should we keep the structure of putting all packages into a separate
> subdir (aka "sub-group").

I don't think there is anything to be gained by that and there are some 
limitations on sub-groups in salsa such as not being able to have rendered 
websites (that feature is prototyped but not yet enabled).

 
> i was also thinking about creating a single python-team group with a
> PAPT and a DPMT subgroup, but apart from aesthetics i cannot think of
> any good reason to do so. it probably creates more trouble than it is
> worth.

I don't know the historical origins of this split and I have never seen the 
advantage in splitting the two groups. Maybe it's time to have PAPT do the 
svn→git transition and put everything in the same debian-python-team?

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7



Re: [tryton-debian] Bug#877849: Namespace conflict for python-magic

2018-01-19 Thread Mathias Behrle
* Christoph Biedl: " Re: [tryton-debian] Bug#877849: Namespace conflict for
  python-magic" (Mon, 15 Jan 2018 09:37:51 +0100):

Hi Christoph,

> Mathias Behrle wrote...
> 
> > I found
> >
> > $ apt-cache rdepends python-magic  
> (...)
> 
> Yeah, I already had checked a few of them where possible with little
> efforts. These were the test I had been talking of (actually, including
> python3-magic rdeps as well).
> 
> > May be we should signal them explicitely to test the new package in
> > experimental? What do you think?  
> 
> My plan is to send a call for testing to debian-devel once python-magic
> has been accepted. It shouldn't hurt to add the dd-list output for these
> packages. That would be 27 addresses. I might be convinced to send out
> individual notices - but I think that's exaggerting. Odds for bugs are
> fairly low, and there's still a lot of time until the buster freeze to
> detect and fix them.
> 
> Christoph, it's called "unstable" for a reason

JFTR: relatorio_0.8.0-1~exp1 was just built and uploaded. It builds against 
python-magic (>=2:0.4.15-1~exp1) and all tests are passing succesfully.

Mathias

-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgpxeGjmgUq8Y.pgp
Description: Digitale Signatur von OpenPGP


Re: DPMT and git workflows

2018-01-19 Thread Debian/GNU
On 01/19/2018 12:45 PM, Simon McVittie wrote:
> On Fri, 19 Jan 2018 at 14:25:57 +0300, Dmitry Shachnev wrote:
>> I think for new packages it is better to use gbp-pq based workflow:
>> https://wiki.debian.org/Python/GitPackagingPQ
> 
> Is there consensus that the gbp-pq workflow is now allowed? I only
> maintain one package in DPMT (tap.py) and every time I upload it I have
> to remind myself how git-dpm works, so I'd like to switch it over to
> gbp-pq as soon as I can.
> 
> Relatedly, Alioth is going to be shut down at some point, with git
> repositories frozen and made read-only, so it would seem a good idea to
> start migrating git packaging to salsa.debian.org before that happens.
> python-modules-team and python-apps-team groups, perhaps? I can create
> a python-modules-team group and migrate tap.py as a sample if people
> would like to see an example package.
> 

should we keep the structure of putting all packages into a separate
subdir (aka "sub-group").

i was also thinking about creating a single python-team group with a
PAPT and a DPMT subgroup, but apart from aesthetics i cannot think of
any good reason to do so. it probably creates more trouble than it is worth.

gfards
IOhannes



signature.asc
Description: OpenPGP digital signature


Re: DPMT and git workflows

2018-01-19 Thread Simon McVittie
On Fri, 19 Jan 2018 at 14:25:57 +0300, Dmitry Shachnev wrote:
> I think for new packages it is better to use gbp-pq based workflow:
> https://wiki.debian.org/Python/GitPackagingPQ

Is there consensus that the gbp-pq workflow is now allowed? I only
maintain one package in DPMT (tap.py) and every time I upload it I have
to remind myself how git-dpm works, so I'd like to switch it over to
gbp-pq as soon as I can.

Relatedly, Alioth is going to be shut down at some point, with git
repositories frozen and made read-only, so it would seem a good idea to
start migrating git packaging to salsa.debian.org before that happens.
python-modules-team and python-apps-team groups, perhaps? I can create
a python-modules-team group and migrate tap.py as a sample if people
would like to see an example package.

smcv



Re: FYI: Fwd: RFS: pygithub/1.35-1[ITA]

2018-01-19 Thread Dmitry Shachnev
On Wed, Jan 17, 2018 at 11:14:41PM +0100, Filip Pytloun wrote:
> Hello Emmanuel,
>
> few notes to your package:
>
> - it would be good to move under DPMT (have you joined the team
>   already?), create git repository and use git-dpm to import current
>   version and make your changes, also set Maintainer and Vcs-* to
>   reflect this

I think for new packages it is better to use gbp-pq based workflow:
https://wiki.debian.org/Python/GitPackagingPQ

git-dpm is unmaintained and is (IMO) more difficult to work with.

--
Dmitry Shachnev


signature.asc
Description: PGP signature