Re: 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 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)
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 <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 ;)
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.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: