Re: Bug#866335: Python3.6 plans​ for Buster

[Emilio Pozuelo Monfort]

Hi Scott,

On 05/07/17 06:25, Scott Kitterman wrote:
> On Wednesday, June 28, 2017 11:19:37 PM Scott Kitterman wrote:
>> On Friday, June 23, 2017 02:09:34 PM Scott Kitterman wrote:
>>> On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote:
> ...
 As a reminder (and for anyone new) we'll do the transition to python3.6
 in three stages:
  - Add python3.6 as supported and rebuild all binary extensions to
  support
> ...
>>> Unless I've missed something, I've not heard back from anyone indicating
>>> significant issues that would warrant not taking the first step in this
>>> plan (I'm aware astropy may have some problems, but that's it).
>>>
>>> My plan is to ask the release team for a transition tracker and start the
>>> first part of this in Unstable once they've agreed.  If anyone thinks this
>>> is premature, please let me know.
>>
>> Unless I brown bagged the upload somehow, this is started now.
>>
>> https://release.debian.org/transitions/html/python3.6.html
> 
> Status update:

Thanks for the update. Very comprehensive.

> 
> Python3-defaults with python3.5 and python3.6 as supported versions is in 
> Buster, but python3.6 for the entire ecosystem is not.
> 
> All binNMUs have been scheduled and the one arch:all sourceful upload that's 
> needed is complete.  According to the release team's tracker the transition 
> is 
> 85% complete.  There are roughly five classes of things in the remaining 15%:
> 
> 1.  Builds for leaf packages that are scheduled, but not complete.  Nothing 
> needs to be done for these.  The slow architectures will catch up eventually.
> 
> 2.  Packages which are RC buggy because they can't currently be built on some 
> (or all archs) for reasons unrelated to python3.6.  It would be good to NMU 
> to 
> fix these if people have time, but they might not be the best use of Python 
> packaging oriented people's time.
> #866536 jpy FTBFS on mips/mipsel: 1 Python unit test(s) failed. Installation 
> is likely broken.
> #839760 xcffib: FTBFS on big-endian architectures: assert reply.value. 
> to_atoms() == (wm_delete_window, )
> #839314 xcffib: FTBFS: xcffibgen: Invalid bitCase: QName {qName = 
> "required_start_align", qURI = Nothing, qPrefix = Nothing}
> #866543 xcffib: FTBFS after switch to having python3.6 supported
> #867018 python-pysam FTBFS with libhts-dev 1.4.1-2
> #813083 pyviennacl: FTBFS: src/ viennacl/vector.h:225:34: error: no matches 
> converting function ‘project’ to type ‘class viennacl::vector ...
> #854195 yt FTBFS on armel/armhf: testsuite MemoryErrors
> #867197 yt: FTBFS on ppc64el: test failure
> #864443 pytables: ftbfs on armhf
> #867028 uvloop FTBFS on armel/armhf: Test_UV_UnixSSL. 
> test_create_unix_server_ssl_1 fails
> 
> 3.  Packages which now FTBFS due to adding python3.6.
> #866575 libapache2-mod-wsgi-py3: Impossible depends when built with more then 
> one supported python3 version
> #862380 khmer: FTBFS with Python 3.6
> #862805 protobuf: tests fail with Python 3.6
> #866694 pythonmagick: FTBFS with python3.6 as a supported python3
> #866696 python-pyeclib: FTBFS on mips64el due to test failures after rebuild 
> with python3.6
> #865224 uwsgi: ftbfs with multiple supported python3 versions
> #866547 python-biomaj3: FTBFS with python3.6 as a supported version
> #864327 shiboken: extend test skipping hack to python 3.6
> 
> 4.  Packages which declare build-depends on python3-all-dev but do not build 
> for all python3 verions or don't set their dependencies correctly.
> #866412 cinnamon-screensaver: Excessive and hard coded depends complicate 
> python3 transition
> #866504 django-compat: Excessive build-depends complicate python3 transition 
> (maybe rm is the best solution here)
> #866555 gpgme1.0: Build for all python3 versions or change build-dep
> #866514 ngs.sdk: Excessive build-depends complicate python3 transition
> #866700 pcp: Only builds for default python3 version
> #866528 python-biotools: Inappropriate use of arch:any vice arch:all
> #799635 python-characteristic: Uses python3-all-dev build-dep when 
> python3-all 
> is all that's needed
> #866533 python-dictobj: Package is arch any when it should be arch all
> #867010 python-cassandra-river: Please build for all supported python3 
> versions
> #800709 gcc-python-plugin: Should build-dep on python3-dev vice all-dev
> #867243 python3-astroml: Missing python3 interpreter depends
> 
> 5.  Things needing further research/work:
> python-pbr, nuitka, and pyopenssl are all packages with arch:all content that 
> need access to Python.h.  Is there a way to have them not show up as part of 
> transition?

We can't filter by architecture afaik. We can hardcode some packages but I'd
rather not do that.

> Some packages that depend on python3-all-dev, but don't end up depending on 
> python3 (<< python3.7) after binNMU still need investigation: eccodes, grib-
> api, python-escript, lasagne, sunpy
> pycuda (contrib) needs binary upload to rebuild, not autobuilt
> 
> Note: becaus

Re: git-dpm: remove a patch

[Scott Kitterman]

On Wednesday, July 05, 2017 08:51:34 AM Vincent Bernat wrote:
> Hey!
> 
> How to remove a patch with git-dpm?
> 
> I have tried:
> 
> git-dpm c-p
> git reset --hard HEAD~1
> git-dpm u-p
> 
> And got:
> 
> 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!
> 
> I don't understand what it means. git-dpm tag doesn't report anything
> suspicious so I suppose that debian/.git-dpm is correct.

Did you try they way it says in man git-dpm:

   Removing existing patches
  First get the master branch:
   git clone URL

  Create the patched branch and check it out:
   git-dpm checkout-patched

  Get a list of commits since the last upstream release: git 
rebase -i upstream-unstable

  This will open your default editor with a list of commits.  Edit 
the list to remove undesired commits.
   ...
   git commit

  Then you want to get those changes into the Debian branch and 
the old patch files deleted (which you can do using git-dpm update-patches), 
but you most likely want to also document  what  you  did  in  the
  changelog, so all in one step:
   git-dpm dch -- -i

  Perhaps change something in the Debian packaging:
   ...
   git commit -a

  Then push the whole thing back:
   git push

Scott K

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

Re: git-dpm: remove a patch

[Brian May]

Vincent Bernat  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 

Re: git-dpm: remove a patch

[Nikolaus Rath]

On Jul 05 2017, Vincent Bernat  wrote:
> Hey!
>
> How to remove a patch with git-dpm?

Look for "Removing existing patches" in git-dpm(1):

$ git-dpm checkout-patched
$ git  rebase  -i upstream-unstable
$ git-dpm dch -- -i

Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Bug#866335: Python3.6 plans​ for Buster

[Scott Kitterman]

On Wednesday, July 05, 2017 10:24:26 AM Emilio Pozuelo Monfort wrote:
> Hi Scott,
> 
> On 05/07/17 06:25, Scott Kitterman wrote:
> > On Wednesday, June 28, 2017 11:19:37 PM Scott Kitterman wrote:
> >> On Friday, June 23, 2017 02:09:34 PM Scott Kitterman wrote:
> >>> On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote:
> > ...
> > 
>  As a reminder (and for anyone new) we'll do the transition to python3.6
>  
>  in three stages:
>   - Add python3.6 as supported and rebuild all binary extensions to
>   support
> > 
> > ...
> > 
> >>> Unless I've missed something, I've not heard back from anyone indicating
> >>> significant issues that would warrant not taking the first step in this
> >>> plan (I'm aware astropy may have some problems, but that's it).
> >>> 
> >>> My plan is to ask the release team for a transition tracker and start
> >>> the
> >>> first part of this in Unstable once they've agreed.  If anyone thinks
> >>> this
> >>> is premature, please let me know.
> >> 
> >> Unless I brown bagged the upload somehow, this is started now.
> >> 
> >> https://release.debian.org/transitions/html/python3.6.html
> > 
> > Status update:
> Thanks for the update. Very comprehensive.
> 
> > Python3-defaults with python3.5 and python3.6 as supported versions is in
> > Buster, but python3.6 for the entire ecosystem is not.
> > 
> > All binNMUs have been scheduled and the one arch:all sourceful upload
> > that's needed is complete.  According to the release team's tracker the
> > transition is 85% complete.  There are roughly five classes of things in
> > the remaining 15%:
> > 
> > 1.  Builds for leaf packages that are scheduled, but not complete. 
> > Nothing
> > needs to be done for these.  The slow architectures will catch up
> > eventually.
> > 
> > 2.  Packages which are RC buggy because they can't currently be built on
> > some (or all archs) for reasons unrelated to python3.6.  It would be good
> > to NMU to fix these if people have time, but they might not be the best
> > use of Python packaging oriented people's time.
> > #866536 jpy FTBFS on mips/mipsel: 1 Python unit test(s) failed.
> > Installation is likely broken.
> > #839760 xcffib: FTBFS on big-endian architectures: assert reply.value.
> > to_atoms() == (wm_delete_window, )
> > #839314 xcffib: FTBFS: xcffibgen: Invalid bitCase: QName {qName =
> > "required_start_align", qURI = Nothing, qPrefix = Nothing}
> > #866543 xcffib: FTBFS after switch to having python3.6 supported
> > #867018 python-pysam FTBFS with libhts-dev 1.4.1-2
> > #813083 pyviennacl: FTBFS: src/ viennacl/vector.h:225:34: error: no
> > matches
> > converting function ‘project’ to type ‘class viennacl::vector ...
> > #854195 yt FTBFS on armel/armhf: testsuite MemoryErrors
> > #867197 yt: FTBFS on ppc64el: test failure
> > #864443 pytables: ftbfs on armhf
> > #867028 uvloop FTBFS on armel/armhf: Test_UV_UnixSSL.
> > test_create_unix_server_ssl_1 fails
> > 
> > 3.  Packages which now FTBFS due to adding python3.6.
> > #866575 libapache2-mod-wsgi-py3: Impossible depends when built with more
> > then one supported python3 version
> > #862380 khmer: FTBFS with Python 3.6
> > #862805 protobuf: tests fail with Python 3.6
> > #866694 pythonmagick: FTBFS with python3.6 as a supported python3
> > #866696 python-pyeclib: FTBFS on mips64el due to test failures after
> > rebuild with python3.6
> > #865224 uwsgi: ftbfs with multiple supported python3 versions
> > #866547 python-biomaj3: FTBFS with python3.6 as a supported version
> > #864327 shiboken: extend test skipping hack to python 3.6
> > 
> > 4.  Packages which declare build-depends on python3-all-dev but do not
> > build for all python3 verions or don't set their dependencies correctly.
> > #866412 cinnamon-screensaver: Excessive and hard coded depends complicate
> > python3 transition
> > #866504 django-compat: Excessive build-depends complicate python3
> > transition (maybe rm is the best solution here)
> > #866555 gpgme1.0: Build for all python3 versions or change build-dep
> > #866514 ngs.sdk: Excessive build-depends complicate python3 transition
> > #866700 pcp: Only builds for default python3 version
> > #866528 python-biotools: Inappropriate use of arch:any vice arch:all
> > #799635 python-characteristic: Uses python3-all-dev build-dep when
> > python3-all is all that's needed
> > #866533 python-dictobj: Package is arch any when it should be arch all
> > #867010 python-cassandra-river: Please build for all supported python3
> > versions
> > #800709 gcc-python-plugin: Should build-dep on python3-dev vice all-dev
> > #867243 python3-astroml: Missing python3 interpreter depends
> > 
> > 5.  Things needing further research/work:
> > python-pbr, nuitka, and pyopenssl are all packages with arch:all content
> > that need access to Python.h.  Is there a way to have them not show up as
> > part of transition?
> 
> We can't filter by architecture afaik. We can hardcode some packages but I'd
> rather not do that.
>

Re: git-dpm: remove a patch

[Vincent Bernat]

 ❦  5 juillet 2017 13:27 +0200, Nikolaus Rath  :

>> How to remove a patch with git-dpm?
>
> Look for "Removing existing patches" in git-dpm(1):
>
> $ git-dpm checkout-patched
> $ git  rebase  -i upstream-unstable
> $ git-dpm dch -- -i

That's totally similar to use "git reset --hard HEAD~1" (since I want to
remove the last commit).
-- 
Make sure all variables are initialised before use.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: git-dpm: remove a patch

[Vincent Bernat]

 ❦  5 juillet 2017 21:19 +1000, Brian May  :

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

This seemed to have worked as expected: the patch is gone.
-- 
"Elves and Dragons!" I says to him.  "Cabbages and potatoes are better
for you and me."
-- J. R. R. Tolkien


signature.asc
Description: PGP signature

Request to join DPMT

[Sean Whitton]

Hello pythoners,

I'd like to join the team so that I can put my new package,
pytest-helpers-namespace (#867375), under DPMT team maintenance.

I have read, and I accept,
.

My alioth username is spwhitton.

Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature