Bug#907806: How to disable tests for Python2 only?
On Mon, 01 Oct 2018, Andreas Tille wrote: > Hi Yaroslav, > was this helpful for you? sorry -- didn't look into scikit-learn yet. BTW - 0.20 release was posted, so we should update and try again. Will you have time or should I ? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#907806: How to disable tests for Python2 only?
Hi Yaroslav, was this helpful for you? Kind regards Andreas. On Wed, Sep 26, 2018 at 01:06:38PM +0200, Andreas Tille wrote: > > On Mon, Sep 24, 2018 at 11:32:03AM -0400, Yaroslav Halchenko wrote: > > > > > I confirm that there are cases where this workflow makes sense. We need > > > to outweight pros and cons. > > > > To say the truth, I am no longer sure since it is possible to still have > > regular upstream repo as a remote and dedicated branches for them in the > > same git repo (locally), so I could still cherry pick etc. Pretty much > > what I do eg for cython etc. > > > > That is why I am agreeing to go "standard" so to make life easier for > > others as well. > > Sounds good. :-) > > > My only concern with the "standard" workflow ATM is that pristine-tar is > > not as reliable as needed to be. # of open issues manifests to that > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=pristine-tar;dist=unstable > > and Joey himself moved from using it to dgit AFAIK. But anyways it is > > unrelated to this discussion, sorry for bringing it up ;( > > I admit that I'm a bit concerned about some kind of increasing orphanage > of pristine-tar. Luckily I personally had not faced any serious problem > with it. I simply hope that if we follow a standard that many people > are using somebody will either take over and solve the problems if they > become really hard or someone will develop some tool to switch to some > new standard easily. ;-) > > > > I hope I will find the time tomorrow or the day after tomorrow. > > > > thanks > > I have pushed scikit-learn 0.20~rc1+dfsg-1 to Git[1]. I tried to adapt > all patches to the new upstream version (several were applied upstream). > The one which excluded some tests accessing remote locations did not > applied. I added a comment and a FIXME string in case some other means > might be needed as replacement. I hope I did not messed up things. > > The build starts but fails later with > > ... > x86_64-linux-gnu-gcc-ar: adding 40 object files to > build/temp.linux-x86_64-2.7/libcblas.a > running build_ext > customize UnixCCompiler > customize UnixCCompiler using build_ext > customize UnixCCompiler > customize UnixCCompiler using build_ext > building 'sklearn.__check_build._check_build' extension > compiling C sources > C compiler: x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall > -Wstrict-prototypes -fno-strict-aliasing -g -O2 > -fdebug-prefix-map=/build/scikit-learn-0.20~rc1+dfsg=. > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time > -D_FORTIFY_SOURCE=2 -fPIC > > creating build/temp.linux-x86_64-2.7/sklearn/__check_build > compile options: '-I/usr/lib/python2.7/dist-packages/numpy/core/include > -I/usr/lib/python2.7/dist-packages/numpy/core/include > -I/usr/include/python2.7 -c' > x86_64-linux-gnu-gcc: sklearn/__check_build/_check_build.c > x86_64-linux-gnu-gcc: error: sklearn/__check_build/_check_build.c: No such > file or directory > x86_64-linux-gnu-gcc: fatal error: no input files > compilation terminated. > x86_64-linux-gnu-gcc: error: sklearn/__check_build/_check_build.c: No such > file or directory > x86_64-linux-gnu-gcc: fatal error: no input files > compilation terminated. > > > I admit I need to give up here and trust your insight that you will be > able to deal with this. > > BTW, I'm wondering whether the code copy of atlas/lapack in > sklearn/src/cblas will be really needed - but for the moment I think > we should concentrate to get the package out at all before we care > about code copies. > > > > I'll check what might be the easier solution and will come back once I > > > did so. Hopefully you will have solved the ssh issue meanwhile. > > > > I will try again later today, and when home (different network/provider) > > Hope this works now > >Andreas. > > > [1] https://salsa.debian.org/science-team/scikit-learn > > -- > http://fam-tille.de > > -- http://fam-tille.de
Bug#907806: How to disable tests for Python2 only?
Hi Yaroslav, On Mon, Sep 24, 2018 at 11:32:03AM -0400, Yaroslav Halchenko wrote: > > > I confirm that there are cases where this workflow makes sense. We need > > to outweight pros and cons. > > To say the truth, I am no longer sure since it is possible to still have > regular upstream repo as a remote and dedicated branches for them in the > same git repo (locally), so I could still cherry pick etc. Pretty much > what I do eg for cython etc. > > That is why I am agreeing to go "standard" so to make life easier for > others as well. Sounds good. :-) > My only concern with the "standard" workflow ATM is that pristine-tar is > not as reliable as needed to be. # of open issues manifests to that > https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=pristine-tar;dist=unstable > and Joey himself moved from using it to dgit AFAIK. But anyways it is > unrelated to this discussion, sorry for bringing it up ;( I admit that I'm a bit concerned about some kind of increasing orphanage of pristine-tar. Luckily I personally had not faced any serious problem with it. I simply hope that if we follow a standard that many people are using somebody will either take over and solve the problems if they become really hard or someone will develop some tool to switch to some new standard easily. ;-) > > I hope I will find the time tomorrow or the day after tomorrow. > > thanks I have pushed scikit-learn 0.20~rc1+dfsg-1 to Git[1]. I tried to adapt all patches to the new upstream version (several were applied upstream). The one which excluded some tests accessing remote locations did not applied. I added a comment and a FIXME string in case some other means might be needed as replacement. I hope I did not messed up things. The build starts but fails later with ... x86_64-linux-gnu-gcc-ar: adding 40 object files to build/temp.linux-x86_64-2.7/libcblas.a running build_ext customize UnixCCompiler customize UnixCCompiler using build_ext customize UnixCCompiler customize UnixCCompiler using build_ext building 'sklearn.__check_build._check_build' extension compiling C sources C compiler: x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -g -O2 -fdebug-prefix-map=/build/scikit-learn-0.20~rc1+dfsg=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC creating build/temp.linux-x86_64-2.7/sklearn/__check_build compile options: '-I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/python2.7 -c' x86_64-linux-gnu-gcc: sklearn/__check_build/_check_build.c x86_64-linux-gnu-gcc: error: sklearn/__check_build/_check_build.c: No such file or directory x86_64-linux-gnu-gcc: fatal error: no input files compilation terminated. x86_64-linux-gnu-gcc: error: sklearn/__check_build/_check_build.c: No such file or directory x86_64-linux-gnu-gcc: fatal error: no input files compilation terminated. I admit I need to give up here and trust your insight that you will be able to deal with this. BTW, I'm wondering whether the code copy of atlas/lapack in sklearn/src/cblas will be really needed - but for the moment I think we should concentrate to get the package out at all before we care about code copies. > > I'll check what might be the easier solution and will come back once I > > did so. Hopefully you will have solved the ssh issue meanwhile. > > I will try again later today, and when home (different network/provider) Hope this works now Andreas. [1] https://salsa.debian.org/science-team/scikit-learn -- http://fam-tille.de
Bug#907806: How to disable tests for Python2 only?
On Mon, 24 Sep 2018, Andreas Tille wrote: > Probably due to racing condition since I migrated the repository before > your pushes. > > > either needed to be imported as quilt patches or alternatively you can > > > use git mode in d/watch which creates a new tarball for you > > > incorporating the latest state of upstream Git (I doubt that would be a > > > sensible solution in the current case). > > if we are to stay with my non conventional setup of sitting straight on > > top of the upstream git repo, then we would just need to merge > > debian-0.20 branch into debian branch (might be a fast-forward) whenever > > we are ready to upload that beast. > I confirm that there are cases where this workflow makes sense. We need > to outweight pros and cons. To say the truth, I am no longer sure since it is possible to still have regular upstream repo as a remote and dedicated branches for them in the same git repo (locally), so I could still cherry pick etc. Pretty much what I do eg for cython etc. That is why I am agreeing to go "standard" so to make life easier for others as well. My only concern with the "standard" workflow ATM is that pristine-tar is not as reliable as needed to be. # of open issues manifests to that https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=pristine-tar;dist=unstable and Joey himself moved from using it to dgit AFAIK. But anyways it is unrelated to this discussion, sorry for bringing it up ;( > > ... > > If we are to convert to the more conventional gbp workflow (I am ok with > > that now ;)) , I guess the best would be to just reimport from the > > snapshots entire history of the package and proceed from there. Then > > commits in debian-0.20 would need to be rebased (or cherry picked or > > your suggested format-patch+am) to stay on top of the "master" > > branch > I hope I will find the time tomorrow or the day after tomorrow. thanks > > and picking any needed changes, would be appreciated. I will adjust ;) > I'll check what might be the easier solution and will come back once I > did so. Hopefully you will have solved the ssh issue meanwhile. I will try again later today, and when home (different network/provider) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#907806: How to disable tests for Python2 only?
Hi Yaroslav, On Mon, Sep 24, 2018 at 11:03:16AM -0400, Yaroslav Halchenko wrote: > > > You asked me to clone http://github.com/yarikoptic/scikit-learn to > > https://salsa.debian.org/science-team/scikit-learn which I did. In > > cool :-) > > *your* packaging repository is no branch 0.20rc1 those commits would be > > indeed salsa clone is missing the > https://github.com/yarikoptic/scikit-learn/tree/debian-0.20 branch which > sits on top of debian branch and the 0.20rc1 upstream tag (pushed > now to my fork on github) Probably due to racing condition since I migrated the repository before your pushes. > > either needed to be imported as quilt patches or alternatively you can > > use git mode in d/watch which creates a new tarball for you > > incorporating the latest state of upstream Git (I doubt that would be a > > sensible solution in the current case). > > if we are to stay with my non conventional setup of sitting straight on > top of the upstream git repo, then we would just need to merge > debian-0.20 branch into debian branch (might be a fast-forward) whenever > we are ready to upload that beast. I confirm that there are cases where this workflow makes sense. We need to outweight pros and cons. My main argument against it is *currently* that the workflow is not described in our team policy and I previous had always trouble with workflows not described there because there are always some details some other team member can not guess. Below you agree to use the traditional workflow so I'd like to stick to this. > > like using git mode in debian/watch and try to extract your commits to > > debian/ dir via `git format-patch` and import these into Debian Science > > repository via `git am`. However, I do not see this as very promising > > If we are to convert to the more conventional gbp workflow (I am ok with > that now ;)) , I guess the best would be to just reimport from the > snapshots entire history of the package and proceed from there. Then > commits in debian-0.20 would need to be rebased (or cherry picked or > your suggested format-patch+am) to stay on top of the "master" > branch I hope I will find the time tomorrow or the day after tomorrow. > > since I'm not sure whether you are really in favour to migrate to Debian > > Science or rather stick to your workflow. > > I am ok with either way now, as long as the package stays easy to > backport (so cythonize in debian/rules etc stays) I do not plan to fiddle with d/rules since I do not really understand what's happening there - at least as long as it works. :-) > > So before I start spending > > time into this it would be helpful if you confirm that you can > > >gbp clone g...@salsa.debian.org:science-team/scikit-learn.git > > as I said, smth is finicky with ssh for me for salsa: > > $>gbp clone g...@salsa.debian.org:science-team/scikit-learn.git > gbp:info: Cloning from 'g...@salsa.debian.org:science-team/scikit-learn.git' > gbp:error: Git command failed: Error running git clone: ssh: connect to host > salsa.debian.org port 22: Network is unreachable > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > $> sudo tcptraceroute salsa.debian.org 22 > Running: > traceroute -T -O info -p 22 salsa.debian.org > traceroute to salsa.debian.org (209.87.16.44), 30 hops max, 60 byte packets > 1 _gateway (10.31.176.1) 1.733 ms 2.085 ms 2.620 ms > 2 berry1-crt.border1-rt.dartmouth.edu (129.170.1.42) 2.598 ms 2.074 ms > 2.060 ms > 3 i2-cleveland.border1-rt.dartmouth.edu (129.170.9.241) 6.170 ms 6.151 ms > 6.155 ms > 4 et-3-1-0.4079.rtsw.clev.net.internet2.edu (162.252.70.93) 15.175 ms > 15.531 ms 15.542 ms > 5 ae-1.4079.rtsw.eqch.net.internet2.edu (162.252.70.131) 25.121 ms 25.082 > ms 24.325 ms > 6 et-7-0-0.4079.rtsw.minn.net.internet2.edu (162.252.70.107) 31.915 ms > 32.184 ms 31.981 ms > 7 et-7-0-0.4079.rtsw.miss2.net.internet2.edu (162.252.70.59) 55.142 ms > 57.452 ms 55.346 ms > 8 et-4-1-0.4079.rtsw.seat.net.internet2.edu (162.252.70.1) 65.376 ms > 65.717 ms 65.842 ms > 9 * * * > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > > > I can clone though via https:// (just can't push changes via ssh) Is this true for all repositories on Salsa? May be something with your ssh-key? > > and we both agree about the method how we want to inject the upstream > > source there. Debian Science policy says this is done via > > >gbp import-orig --pristine-tar > > > while the upstream tarball is obtained via uscan or some get-orig-source > > script in exceptional cases. What do you think about this? > > If you could migrate to the team standard using > > gbp import-dscs --debsnap > > and picking any needed changes, would be appreciated. I will adjust ;) I'll check what might be the easier solution and will come back once I did so.
Bug#907806: How to disable tests for Python2 only?
On Mon, 24 Sep 2018, Andreas Tille wrote: > > > When you talked about new upstream version: Do you want to give 0.20rc1 > > I did give it a try... > > From the now empty list of > > https://github.com/scikit-learn/scikit-learn/issues/created_by/yarikoptic it > > might be that all of the ones I've filed are addressed by now, BUT I do not > > see > > them in > > $> git lg 0.20rc1..origin/0.20.X > > * c196ec405 - (origin/0.20.X) Remove OPTICS from 0.20 (#12053) (7 days ago) > > [Joel Nothman] > > * 17f8016c5 - Bugfix release of joblib that also restores PyPy support > > (#12012) (3 weeks ago) [Olivier Grisel] > > * c40726e91 - CI handle sparse checkout with new branch (4 weeks ago) [Joel > > Nothman] > > * 96a3e21fb - CI Verbosity in push_doc (4 weeks ago) [Joel Nothman] > > * 9c3ecb2c4 - CI use correct scikit-learn.github.io branch (4 weeks ago) > > [Joel Nothman] > > * 061343e9f - CI Only try to remove docs dir if present (4 weeks ago) [Joel > > Nothman] > > so might have been fixed in master, and not backported yet, which indeed > > might be the case: > > https://github.com/scikit-learn/scikit-learn/issues/12016#issuecomment-419079493 > You asked me to clone http://github.com/yarikoptic/scikit-learn to > https://salsa.debian.org/science-team/scikit-learn which I did. In cool > *your* packaging repository is no branch 0.20rc1 those commits would be indeed salsa clone is missing the https://github.com/yarikoptic/scikit-learn/tree/debian-0.20 branch which sits on top of debian branch and the 0.20rc1 upstream tag (pushed now to my fork on github) > either needed to be imported as quilt patches or alternatively you can > use git mode in d/watch which creates a new tarball for you > incorporating the latest state of upstream Git (I doubt that would be a > sensible solution in the current case). if we are to stay with my non conventional setup of sitting straight on top of the upstream git repo, then we would just need to merge debian-0.20 branch into debian branch (might be a fast-forward) whenever we are ready to upload that beast. > I have no trouble with accessing the repository on Salsa. > > Meanwhile, debian-0.20 branch is on > > http://github.com/yarikoptic/scikit-learn > I admit I'm not sure what you want me to do next. It somehow smells > like using git mode in debian/watch and try to extract your commits to > debian/ dir via `git format-patch` and import these into Debian Science > repository via `git am`. However, I do not see this as very promising If we are to convert to the more conventional gbp workflow (I am ok with that now ;)) , I guess the best would be to just reimport from the snapshots entire history of the package and proceed from there. Then commits in debian-0.20 would need to be rebased (or cherry picked or your suggested format-patch+am) to stay on top of the "master" branch > since I'm not sure whether you are really in favour to migrate to Debian > Science or rather stick to your workflow. I am ok with either way now, as long as the package stays easy to backport (so cythonize in debian/rules etc stays) > So before I start spending > time into this it would be helpful if you confirm that you can >gbp clone g...@salsa.debian.org:science-team/scikit-learn.git as I said, smth is finicky with ssh for me for salsa: $>gbp clone g...@salsa.debian.org:science-team/scikit-learn.git gbp:info: Cloning from 'g...@salsa.debian.org:science-team/scikit-learn.git' gbp:error: Git command failed: Error running git clone: ssh: connect to host salsa.debian.org port 22: Network is unreachable fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. $> sudo tcptraceroute salsa.debian.org 22 Running: traceroute -T -O info -p 22 salsa.debian.org traceroute to salsa.debian.org (209.87.16.44), 30 hops max, 60 byte packets 1 _gateway (10.31.176.1) 1.733 ms 2.085 ms 2.620 ms 2 berry1-crt.border1-rt.dartmouth.edu (129.170.1.42) 2.598 ms 2.074 ms 2.060 ms 3 i2-cleveland.border1-rt.dartmouth.edu (129.170.9.241) 6.170 ms 6.151 ms 6.155 ms 4 et-3-1-0.4079.rtsw.clev.net.internet2.edu (162.252.70.93) 15.175 ms 15.531 ms 15.542 ms 5 ae-1.4079.rtsw.eqch.net.internet2.edu (162.252.70.131) 25.121 ms 25.082 ms 24.325 ms 6 et-7-0-0.4079.rtsw.minn.net.internet2.edu (162.252.70.107) 31.915 ms 32.184 ms 31.981 ms 7 et-7-0-0.4079.rtsw.miss2.net.internet2.edu (162.252.70.59) 55.142 ms 57.452 ms 55.346 ms 8 et-4-1-0.4079.rtsw.seat.net.internet2.edu (162.252.70.1) 65.376 ms 65.717 ms 65.842 ms 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * I can clone though via https:// (just can't push changes via ssh) > and we both agree about the method how we want to inject the upstream > source there. Debian Science policy says this is done via >gbp import-orig --pristine-tar > while the upstream tarball is obtained via
Bug#907806: How to disable tests for Python2 only?
Hi Yaroslav, On Mon, Sep 24, 2018 at 09:40:49AM -0400, Yaroslav Halchenko wrote: > > On Mon, 24 Sep 2018, Andreas Tille wrote: > > > When you talked about new upstream version: Do you want to give 0.20rc1 > > I did give it a try... > > From the now empty list of > https://github.com/scikit-learn/scikit-learn/issues/created_by/yarikoptic it > might be that all of the ones I've filed are addressed by now, BUT I do not > see > them in > > $> git lg 0.20rc1..origin/0.20.X > * c196ec405 - (origin/0.20.X) Remove OPTICS from 0.20 (#12053) (7 days ago) > [Joel Nothman] > * 17f8016c5 - Bugfix release of joblib that also restores PyPy support > (#12012) (3 weeks ago) [Olivier Grisel] > * c40726e91 - CI handle sparse checkout with new branch (4 weeks ago) [Joel > Nothman] > * 96a3e21fb - CI Verbosity in push_doc (4 weeks ago) [Joel Nothman] > * 9c3ecb2c4 - CI use correct scikit-learn.github.io branch (4 weeks ago) > [Joel Nothman] > * 061343e9f - CI Only try to remove docs dir if present (4 weeks ago) [Joel > Nothman] > > so might have been fixed in master, and not backported yet, which indeed > might be the case: > https://github.com/scikit-learn/scikit-learn/issues/12016#issuecomment-419079493 You asked me to clone http://github.com/yarikoptic/scikit-learn to https://salsa.debian.org/science-team/scikit-learn which I did. In *your* packaging repository is no branch 0.20rc1 those commits would be either needed to be imported as quilt patches or alternatively you can use git mode in d/watch which creates a new tarball for you incorporating the latest state of upstream Git (I doubt that would be a sensible solution in the current case). > > a try or do you want to wait for 0.20? > > regarding push to salsa: > > something is funky with salsa or with my network? > > (git)hopa:~deb/scikit-learn[debian-0.20] > $> git remote add salsa g...@salsa.debian.org:science-team/scikit-learn.git > > $> git fetch salsa > ssh: connect to host salsa.debian.org port 22: Network is unreachable > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. I have no trouble with accessing the repository on Salsa. > Meanwhile, debian-0.20 branch is on > http://github.com/yarikoptic/scikit-learn I admit I'm not sure what you want me to do next. It somehow smells like using git mode in debian/watch and try to extract your commits to debian/ dir via `git format-patch` and import these into Debian Science repository via `git am`. However, I do not see this as very promising since I'm not sure whether you are really in favour to migrate to Debian Science or rather stick to your workflow. So before I start spending time into this it would be helpful if you confirm that you can gbp clone g...@salsa.debian.org:science-team/scikit-learn.git and we both agree about the method how we want to inject the upstream source there. Debian Science policy says this is done via gbp import-orig --pristine-tar while the upstream tarball is obtained via uscan or some get-orig-source script in exceptional cases. What do you think about this? Kind regards Andreas. -- http://fam-tille.de
Bug#907806: How to disable tests for Python2 only?
On Mon, 24 Sep 2018, Andreas Tille wrote: > When you talked about new upstream version: Do you want to give 0.20rc1 I did give it a try... From the now empty list of https://github.com/scikit-learn/scikit-learn/issues/created_by/yarikoptic it might be that all of the ones I've filed are addressed by now, BUT I do not see them in $> git lg 0.20rc1..origin/0.20.X * c196ec405 - (origin/0.20.X) Remove OPTICS from 0.20 (#12053) (7 days ago) [Joel Nothman] * 17f8016c5 - Bugfix release of joblib that also restores PyPy support (#12012) (3 weeks ago) [Olivier Grisel] * c40726e91 - CI handle sparse checkout with new branch (4 weeks ago) [Joel Nothman] * 96a3e21fb - CI Verbosity in push_doc (4 weeks ago) [Joel Nothman] * 9c3ecb2c4 - CI use correct scikit-learn.github.io branch (4 weeks ago) [Joel Nothman] * 061343e9f - CI Only try to remove docs dir if present (4 weeks ago) [Joel Nothman] so might have been fixed in master, and not backported yet, which indeed might be the case: https://github.com/scikit-learn/scikit-learn/issues/12016#issuecomment-419079493 > a try or do you want to wait for 0.20? regarding push to salsa: something is funky with salsa or with my network? (git)hopa:~deb/scikit-learn[debian-0.20] $> git remote add salsa g...@salsa.debian.org:science-team/scikit-learn.git $> git fetch salsa ssh: connect to host salsa.debian.org port 22: Network is unreachable fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Meanwhile, debian-0.20 branch is on http://github.com/yarikoptic/scikit-learn -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#907806: How to disable tests for Python2 only?
Hi Yaroslav, On Mon, Sep 10, 2018 at 09:39:38PM +0200, Andreas Tille wrote: > On Mon, Sep 10, 2018 at 11:44:00AM -0400, Yaroslav Halchenko wrote: > > > > > ... sorry to repeat myself but having team maintained packages on > > > github is not inviting to others. Is there any reason not to > > > use Salsa? > > > > yeap, let's make a repo on salsa. Would you be ok to retain my weird > > "based on upstream git" setup? > > https://salsa.debian.org/science-team/scikit-learn > > (I did so about one year ago but you decided to stay on Github. > I removed the old repo and injected what I cloned this morning > and added a pristine-tar branch. I volunteer to do it even > a third time but not more. ;-) ) I have not seen any commits of yours in the new repository. Did I understood correctly that you have some pending changes you want to push? > Hope this helps and thanks for caring for the package. I agree that > packaging the new upstream version is probably the best strategy if > it is in the not too distant future (= we will not loose all the > rdepends from testing) I realised that the releases at Github are not tagged reliably (not even the current release is tagged there). Thus I pointed d/watch to pypi and also used Files-Excluded to strip joblib from upstream source. When you talked about new upstream version: Do you want to give 0.20rc1 a try or do you want to wait for 0.20? Kind regards Andreas. -- http://fam-tille.de
Bug#907806: How to disable tests for Python2 only?
On Mon, Sep 10, 2018 at 11:44:00AM -0400, Yaroslav Halchenko wrote: > > > ... sorry to repeat myself but having team maintained packages on > > github is not inviting to others. Is there any reason not to > > use Salsa? > > yeap, let's make a repo on salsa. Would you be ok to retain my weird > "based on upstream git" setup? https://salsa.debian.org/science-team/scikit-learn (I did so about one year ago but you decided to stay on Github. I removed the old repo and injected what I cloned this morning and added a pristine-tar branch. I volunteer to do it even a third time but not more. ;-) ) Hope this helps and thanks for caring for the package. I agree that packaging the new upstream version is probably the best strategy if it is in the not too distant future (= we will not loose all the rdepends from testing) Kind regards Andreas. -- http://fam-tille.de
Bug#907806: How to disable tests for Python2 only?
> ... sorry to repeat myself but having team maintained packages on > github is not inviting to others. Is there any reason not to > use Salsa? > +1 Regards! -- Arias Emmanuel http://eamanu.com Github/Gitlab; @eamanu Debian: @eamanu-guest
Bug#907806: How to disable tests for Python2 only?
On Mon, 10 Sep 2018, Andreas Tille wrote: > On Mon, Sep 10, 2018 at 10:54:02AM -0400, Yaroslav Halchenko wrote: > > Outstanding few issues so far are reported/dealt with upstream: > > https://github.com/scikit-learn/scikit-learn/issues?q=is%3Aopen+is%3Aissue+author%3Ayarikoptic+label%3ABlocker > > updating packaging is in debian-0.20 branch at > > http://github.com/yarikoptic/scikit-learn > ... sorry to repeat myself but having team maintained packages on > github is not inviting to others. Is there any reason not to > use Salsa? yeap, let's make a repo on salsa. Would you be ok to retain my weird "based on upstream git" setup? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#907806: How to disable tests for Python2 only?
On Mon, Sep 10, 2018 at 10:54:02AM -0400, Yaroslav Halchenko wrote: > Outstanding few issues so far are reported/dealt with upstream: > https://github.com/scikit-learn/scikit-learn/issues?q=is%3Aopen+is%3Aissue+author%3Ayarikoptic+label%3ABlocker > updating packaging is in debian-0.20 branch at > http://github.com/yarikoptic/scikit-learn ... sorry to repeat myself but having team maintained packages on github is not inviting to others. Is there any reason not to use Salsa? Kind regards Andreas. -- http://fam-tille.de
Bug#907806: How to disable tests for Python2 only?
On Mon, 10 Sep 2018, Andrey Rahmatullin wrote: > On Mon, Sep 10, 2018 at 04:33:21PM +0200, Andreas Tille wrote: > > Hi, > > looking at the bug log of scikit-learn[1] it seems to be a simple means to > > do > > --- a/debian/control > > +++ b/debian/control > > @@ -20,6 +20,7 @@ Build-Depends: debhelper (>= 9), dh-autoreconf, > > python3-pytest, > > python3-matplotlib, > > python3-joblib (>= 0.9.2), > > + python3-distributed , > > libsvm-dev (>= 2.84.0), > > libatlas3-base, > > Build-Depends-Indep: > I don't think that's how build profiles work. > > However, it seems that due to the fact that this package uses > > --buildsystem=python_distutils > Which is already a problem, as it doesn't support py3. > There is a lot of strange hacks in this rules file. I'm especially > interested in "dh_autoreconf debian/rules -- clean_generated" but that's a > question for another discussion. many hacks might be left overs for historical (age of the package) + backports (hence cythonize rule, allows to provide backports for older debian/ubuntu via neurodebian) reason. Would be nice to review/remove those no longer needed, but attention should be taken care not to break backportability. So far built/tested fine even for jessie (8) and ubuntu xenial (16.04). > > Are there any other ways to exclude some tests for Python2 to make this > > package build again? > rules call nosetests directly so I guess find out how to do that with > nosetests. overall, as I've just noted in the bugreport, I think it is better to concentrate on making upcoming 0.20 (will use pytest not nose among other things) into debian. Outstanding few issues so far are reported/dealt with upstream: https://github.com/scikit-learn/scikit-learn/issues?q=is%3Aopen+is%3Aissue+author%3Ayarikoptic+label%3ABlocker updating packaging is in debian-0.20 branch at http://github.com/yarikoptic/scikit-learn -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
Bug#907806: How to disable tests for Python2 only?
On Mon, Sep 10, 2018 at 04:33:21PM +0200, Andreas Tille wrote: > Hi, > > looking at the bug log of scikit-learn[1] it seems to be a simple means to do > > --- a/debian/control > +++ b/debian/control > @@ -20,6 +20,7 @@ Build-Depends: debhelper (>= 9), dh-autoreconf, > python3-pytest, > python3-matplotlib, > python3-joblib (>= 0.9.2), > + python3-distributed , > libsvm-dev (>= 2.84.0), > libatlas3-base, > Build-Depends-Indep: I don't think that's how build profiles work. > However, it seems that due to the fact that this package uses > --buildsystem=python_distutils Which is already a problem, as it doesn't support py3. There is a lot of strange hacks in this rules file. I'm especially interested in "dh_autoreconf debian/rules -- clean_generated" but that's a question for another discussion. > Are there any other ways to exclude some tests for Python2 to make this > package build again? rules call nosetests directly so I guess find out how to do that with nosetests. -- WBR, wRAR signature.asc Description: PGP signature
Bug#907806: How to disable tests for Python2 only?
Hi, looking at the bug log of scikit-learn[1] it seems to be a simple means to do --- a/debian/control +++ b/debian/control @@ -20,6 +20,7 @@ Build-Depends: debhelper (>= 9), dh-autoreconf, python3-pytest, python3-matplotlib, python3-joblib (>= 0.9.2), + python3-distributed , libsvm-dev (>= 2.84.0), libatlas3-base, Build-Depends-Indep: Since python-distributed does not exist for Python2 I tried: --- a/debian/rules +++ b/debian/rules @@ -36,6 +36,8 @@ NOSEARGS += $(shell dpkg --print-architecture | grep -q -v ppc64el || echo --exc export http_proxy=http://127.0.0.1:9/ export https_proxy=http://127.0.0.1:9/ +export PYBUILD_TEST_ARGS_python2=-k-Xtest_import_all_consistency + # Mega rule %: : # Explicit build system to avoid use of all-in-1 Makefile (just for a test - there are more tests to exclude for Python2). However, it seems that due to the fact that this package uses --buildsystem=python_distutils instead of pybuild this method does not seem to work. Are there any other ways to exclude some tests for Python2 to make this package build again? Kind regards Andreas. PS: Yaroslav, I think we formerly agreed that it is OK to move those basic packages to Debian Science team maintenance. I would like to move the packaging to Salsa and will follow your precondition to change only the needed things to not break any backports of yours. Is this OK? [1] https://bugs.debian.org/907806 -- http://fam-tille.de
