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