Re: Bug#907806: How to disable tests for Python2 only?

[Andreas Tille <andreas@an3as.eu>]

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