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