Re: 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
Reply to: