Re: packaging django-rest-framework-filters
On 11/22/18 6:02 AM, Wookey wrote: > And it looks like it should be called src:drf-filters > binary:python3-djangoresetframework-filters to fit in with naming > conventions of related packages/python team (even though upstream is > 'django-rest-framework-filters'). Right? The binary package name is right, though there's no convention for the source package naming. "drf-filters" doesn't feel very descriptive to me though. > Also related: I've updated drf-extensions to 0.4 (from the current > 0.3.1), as that is needed for lava, and fixes > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865851 > > What I'm not quite sure about is if there is any reason _not_ to > update this package. It has no reverse dependencies so I presume this > is a good idea and I should just get on with it? would a 10-day NMU be > appropriate? If you join the team, I see no reason why you couldn't do the upgrade yourself indeed, especially if you do a 10-day NMU on it. Cheers, Thomas Goirand (zigo)
packaging django-rest-framework-filters
Hello python-people, I need to package django-rest-framework-filters in order to make lava (hardware test framework) work nicely in debian. https://www.linaro.org/engineering/projects/lava/ I found https://wiki.debian.org/Python/GitPackaging which seems very helpful That seems to say to just start a project on salsa, but I thought I'd better ask here if that was right, as this seems to imply that the debian python modules team would then be adopting this? I've done very little python packaging so advice on best approach is very welcome. Is there a dh_make-alike for python, or should I base the packing on something related, like djangorestframework-*/drf-*? And it looks like it should be called src:drf-filters binary:python3-djangoresetframework-filters to fit in with naming conventions of related packages/python team (even though upstream is 'django-rest-framework-filters'). Right? Also related: I've updated drf-extensions to 0.4 (from the current 0.3.1), as that is needed for lava, and fixes https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865851 What I'm not quite sure about is if there is any reason _not_ to update this package. It has no reverse dependencies so I presume this is a good idea and I should just get on with it? would a 10-day NMU be appropriate? I have another mostly written-mail with details of what I did, whcih I'll send shortly, but it's pretty uncontroversial. Cheers for any pointers. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Request to join PAPT (Was: Bug#914230: ITP: git-imerge -- incremental merge and rebase for git)
On Tue, Nov 20, 2018 at 07:37:49PM +, James Clarke wrote: > Package: wnpp > Severity: wishlist > Owner: James Clarke > > * Package name: git-imerge > Version : 1.1.0 > Upstream Author : Michael Haggerty > * URL : https://github.com/mhagger/git-imerge > * License : GPLv2+ > Programming Lang: Python > Description : incremental merge and rebase for git > > Performs a merge between two branches incrementally. If conflicts are > encountered, figures out exactly which pairs of commits conflict, and > presents the user with one pairwise conflict at a time for resolution. > > I recently discovered this useful tool and now use it for my day-to-day > work dealing with forks of large upstream projects. I intend to maintain > this as part of PAPT (which I've just found out is open to all DDs, > though out of courtesy I've still Cc'ed debian-python). Hi, It turns out policy.rst is lying, I don't have permission to create a repository. Therefore I would like to request to join PAPT, please (and accept the policy even in spite of its lies). Thanks, James
Re: Python 3.7 or 3.6 in Buster
On 05.11.18 10:32, Matthias Klose wrote: > On 05.11.18 09:17, Michael Hudson-Doyle wrote: >> On Mon, 5 Nov 2018 at 21:09, Thomas Goirand wrote: >> >>> Hi there! >>> >>> During Debconf, we decided we would not decide yet, and see in November >>> if we think it's reasonable to allow Python 3.7 to reach Buster. Time >>> has passed, RC bugs have been fixed, and now is probably the time to >>> open this thread. >>> >>> To me, as much as the OpenStack packages are concerned, I'm kind of fine >>> with 3.7, modulo fixing this bug in Glance: >>> >>> https://bugs.debian.org/911947 >>> >>> which I forwarded here: >>> https://bugs.launchpad.net/glance/+bug/1800601 >>> >>> It looks like this bug is 3.7.1 specific (ie: there's no bug if using >>> Python 3.7.0). Upstream had a look, and didn't find a way to fix (yet). >>> Help appreciated. >>> >> >> I commented on the bug. >> >> >>> It looks like everything else in OpenStack works. >>> >>> What is the situation for other packages? Do we have lots of Python 3.7 >>> problems remaining? If so, it'd be nice to have them listed somewhere, >>> so we have a clear picture of what's going on. >>> >> >> We're going through the process of switching to 3.7 as default in Ubuntu >> right now, so I think it makes sense to switch Debian too fairly soon. I'm >> trying to remember to attach all my patches to Debian bug reports... > > in Ubuntu, we were able to migrate it (equivalent to the unstable -> testing > migration) with 3.7 as the default. We are in progress removing 3.6 as > supported, which exposed some autopkg test regressions which are currently > worked on. See > http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python3-defaults > >> Cheers, >> mwh >> >> Do other fellow DD also think it's kind of ok to keep 3.7 in Buster? >>> >>> Also, Doko, do you plan on upgrading to newer point release? Python >>> 3.7.1-rc1 and 3.7.1 both were the cause of troubles for me. I just hope >>> this wont happen again (though I'd understand if you wished to upgrade >>> once more before the freeze). In any ways, it'd be nice to communicate >>> what you're planning on doing. > > I'm in favor of going with 3.7, and would like to update to the current 3.7 > release branch at freeze, and then to 3.7.2 later, expected in January. fyi, the release team accepted the transition, and 3.7 should arrive as the default in unstable very soonish.
