Re: 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 git@salsa.debian.org:science-team/scikit-learn.git
as I said, smth is finicky with ssh for me for salsa:
$> gbp clone git@salsa.debian.org:science-team/scikit-learn.git
gbp:info: Cloning from 'git@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 <upstream_tarball>
> 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 ;)
Cheers,
--
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
Reply to: