Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: problem with wget -O
20 views
Skip to first unread message
Roberto C. Sánchez
Jan 25, 2021, 1:50:04 PM1/25/21
to
On Mon, Jan 25, 2021 at 01:40:19PM -0500, Gene Heskett wrote:
> Greetings all;
>
> I don't know if this has been hashed out already, but the stretch version
> of wget is broken, does not accept the -O filename syntax.
>
Are you sure you have the right wget? It works for me:
root@debian:~# cat /etc/debian_version
9.13
root@debian:~# apt-cache policy wget
wget:
Installed: 1.18-5+deb9u3
Candidate: 1.18-5+deb9u3
Version table:
*** 1.18-5+deb9u3 500
500 http://security.debian.org stretch/updates/main amd64 Packages
500 http://ftp.us.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
root@debian:~# wget -q -O netinst.iso https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.7.0-amd64-netinst.iso
root@debian:~# ls
netinst.iso
Regards,
-Roberto
--
Roberto C. Sánchez
> Greetings all;
>
> I don't know if this has been hashed out already, but the stretch version
> of wget is broken, does not accept the -O filename syntax.
>
Are you sure you have the right wget? It works for me:
root@debian:~# cat /etc/debian_version
9.13
root@debian:~# apt-cache policy wget
wget:
Installed: 1.18-5+deb9u3
Candidate: 1.18-5+deb9u3
Version table:
*** 1.18-5+deb9u3 500
500 http://security.debian.org stretch/updates/main amd64 Packages
500 http://ftp.us.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status
root@debian:~# wget -q -O netinst.iso https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.7.0-amd64-netinst.iso
root@debian:~# ls
netinst.iso
Regards,
-Roberto
--
Roberto C. Sánchez
Gene Heskett
Jan 25, 2021, 1:50:05 PM1/25/21
to
Greetings all;
I don't know if this has been hashed out already, but the stretch version
of wget is broken, does not accept the -O filename syntax.
If there is a backport fix, what to I put in my sources.list to get it?
I don't know if this has been hashed out already, but the stretch version
of wget is broken, does not accept the -O filename syntax.
Thanks.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>
Greg Wooledge
Jan 25, 2021, 2:00:05 PM1/25/21
to
On Mon, Jan 25, 2021 at 01:45:34PM -0500, Roberto C. Sánchez wrote:
> On Mon, Jan 25, 2021 at 01:40:19PM -0500, Gene Heskett wrote:
> > I don't know if this has been hashed out already, but the stretch version
> > of wget is broken, does not accept the -O filename syntax.
Gene, you've been here a while, so you should know better than this.
> On Mon, Jan 25, 2021 at 01:40:19PM -0500, Gene Heskett wrote:
> > I don't know if this has been hashed out already, but the stretch version
> > of wget is broken, does not accept the -O filename syntax.
If you're reporting a problem with a command that you ran, please show
us the actual command *and* its full output (unless that output is
really large, in which case, just show the interesting parts).
> Are you sure you have the right wget? It works for me:
that has an ampersand (&) character in it, without quoting it.
Gene Heskett
Jan 25, 2021, 3:10:04 PM1/25/21
to
On Monday 25 January 2021 13:45:34 Roberto C. Sánchez wrote:
> On Mon, Jan 25, 2021 at 01:40:19PM -0500, Gene Heskett wrote:
> > Greetings all;
> >
> > I don't know if this has been hashed out already, but the stretch
> > version of wget is broken, does not accept the -O filename syntax.
>
> Are you sure you have the right wget? It works for me:
>
> root@debian:~# cat /etc/debian_version
> 9.13
> root@debian:~# apt-cache policy wget
> wget:
> Installed: 1.18-5+deb9u3
> Candidate: 1.18-5+deb9u3
> Version table:
> *** 1.18-5+deb9u3 500
> 500 http://security.debian.org stretch/updates/main amd64
> Packages 500 http://ftp.us.debian.org/debian stretch/main amd64
> Packages 100 /var/lib/dpkg/status
Same as mine ???gene@coyote:~$ apt-cache policy wget
> On Mon, Jan 25, 2021 at 01:40:19PM -0500, Gene Heskett wrote:
> > Greetings all;
> >
> > I don't know if this has been hashed out already, but the stretch
> > version of wget is broken, does not accept the -O filename syntax.
>
> Are you sure you have the right wget? It works for me:
>
> root@debian:~# cat /etc/debian_version
> 9.13
> root@debian:~# apt-cache policy wget
> wget:
> Installed: 1.18-5+deb9u3
> Candidate: 1.18-5+deb9u3
> Version table:
> *** 1.18-5+deb9u3 500
> 500 http://security.debian.org stretch/updates/main amd64
> Packages 500 http://ftp.us.debian.org/debian stretch/main amd64
> Packages 100 /var/lib/dpkg/status
wget:
Installed: 1.18-5+deb9u3
Candidate: 1.18-5+deb9u3
Version table:
*** 1.18-5+deb9u3 500
500 https://deb.debian.org/debian oldstable/main amd64 Packages
Installed: 1.18-5+deb9u3
Candidate: 1.18-5+deb9u3
Version table:
*** 1.18-5+deb9u3 500
100 /var/lib/dpkg/status
But I figured my luck would run out before I did.
From 97% done in contributed:
[ 97%] Building CXX object
modules/python2/CMakeFiles/opencv_python2.dir/__/src2/cv2.cpp.o
In file included
from /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:7:0,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:2080:
/home/gene/src/opencv_contrib-master/modules/phase_unwrapping/misc/python/pyopencv_phase_unwrapping.hpp:2:13:
error: ‘phase_unwrapping’ in namespace ‘cv’ does not name a type
typedef cv::phase_unwrapping::HistogramPhaseUnwrapping::Params
HistogramPhaseUnwrapping_Params;
^~~~~~~~~~~~~~~~
[...]
modules/python2/CMakeFiles/opencv_python2.dir/build.make:62: recipe for
target 'modules/python2/CMakeFiles/opencv_python2.dir/__/src2/cv2.cpp.o'
failed
make[2]: ***
[modules/python2/CMakeFiles/opencv_python2.dir/__/src2/cv2.cpp.o] Error
1
CMakeFiles/Makefile2:9717: recipe for
target 'modules/python2/CMakeFiles/opencv_python2.dir/all' failed
make[1]: *** [modules/python2/CMakeFiles/opencv_python2.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
Am I doomed, or is it fixable?
> -Roberto
Thanks Roberto.
Gene Heskett
Jan 25, 2021, 3:20:04 PM1/25/21
to
direct copy/paste from the opencv build instructions html page:
wget -O opencv.zip https://github.com/opencv/opencv/archive/master.zip
wget -O opencv_contrib.zip https://github.com/opencv/opencv_contrib/archive/master.zip
And from a previous message, I have exactly the same version number
that Just Works for someone else.
Roberto C. Sánchez
Jan 25, 2021, 3:20:04 PM1/25/21
to
area. As suggested by Greg, please provide the full command you are
attempting to execute and any output that results from it.
deloptes
Jan 25, 2021, 3:20:05 PM1/25/21
to
Gene Heskett wrote:
> But I figured my luck would run out before I did.
> From 97% done in contributed:
> [ 97%] Building CXX object
> modules/python2/CMakeFiles/opencv_python2.dir/__/src2/cv2.cpp.o
> In file included
> from
> /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:7:0,
Let me guess, you complained of wget trying to download the package and now
> But I figured my luck would run out before I did.
> From 97% done in contributed:
> [ 97%] Building CXX object
> modules/python2/CMakeFiles/opencv_python2.dir/__/src2/cv2.cpp.o
> In file included
> from
> /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:7:0,
you complain, being not able to build the package :)
This python stuff is tricky, Gene, why are you doing this to yourself?
Gene Heskett
Jan 25, 2021, 3:30:05 PM1/25/21
to
Greg Wooledge
Jan 25, 2021, 3:40:04 PM1/25/21
to
On Mon, Jan 25, 2021 at 03:13:55PM -0500, Gene Heskett wrote:
> Why Greg, do you seem to always blame the messenger?
Because the message is ripped up into pieces, and you're telling us
> Why Greg, do you seem to always blame the messenger?
only some half-remembered piece of it.
> direct copy/paste from the opencv build instructions html page:
> wget -O opencv.zip https://github.com/opencv/opencv/archive/master.zip
> wget -O opencv_contrib.zip https://github.com/opencv/opencv_contrib/archive/master.zip
be nice if you would show us the terminal session in which you ran the
command and got an error. Lacking that information, we can only guess
as to the many possible causes of the many possible errors.
Here is a short list of guesses.
1) You have a shell function or alias that overrides the wget command.
Diagnose this by running "type wget".
2) You do not have write permission on the current directory.
Diagnose this by running "id" and "ls -ld .".
The string "Permission denied" in the command's output would be a
strong indicator of this one.
3) You pasted the command from a source that has non-breaking spaces or
other non-ASCII garbage polluting the arguments.
4) You have run out of disk space.
Diagnose this by running "df .".
The string "No space left on device" would strongly indicate this one.
5) Quotas.
Gene Heskett
Jan 25, 2021, 3:40:05 PM1/25/21
to
cmake --build .
and the full output would be so big the server might reject it, I did show the initial trigger
event, and the end result, but there was several screens full elided in the middle, but if you
insist, from the initial trigger to the prompt:
[ 97%] Building CXX object modules/python2/CMakeFiles/opencv_python2.dir/__/src2/cv2.cpp.o
In file included
from /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:7:0,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:2080:
/home/gene/src/opencv_contrib-master/modules/phase_unwrapping/misc/python/pyopencv_phase_unwrapping.hpp:2:13:
error: ‘phase_unwrapping’ in namespace ‘cv’ does not name a typ
typedef cv::phase_unwrapping::HistogramPhaseUnwrapping::Params HistogramPhaseUnwrapping_Params;
^~~~~~~~~~~~~~~~
In file included
^~~~~~~~~~~~~~~~
from /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:8:0,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:2080:
/home/gene/src/opencv_contrib-master/modules/surface_matching/misc/python/pyopencv_ppf_match_3d.hpp:3:40:
error: ‘ppf_match_3d’ was not declared in this scope
template<> struct pyopencvVecConverter<ppf_match_3d::Pose3DPtr >
^~~~~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/surface_matching/misc/python/pyopencv_ppf_match_3d.hpp:3:64:
error: template argument 1 is invalid
template<> struct pyopencvVecConverter<ppf_match_3d::Pose3DPtr >
^
/home/gene/src/opencv_contrib-master/modules/surface_matching/misc/python/pyopencv_ppf_match_3d.hpp:16:21:
error: ‘ppf_match_3d’ was not declared in this scope
typedef std::vector<ppf_match_3d::Pose3DPtr> vector_Pose3DPtr;
^~~~~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/surface_matching/misc/python/pyopencv_ppf_match_3d.hpp:16:44:
error: template argument 1 is invalid
typedef std::vector<ppf_match_3d::Pose3DPtr> vector_Pose3DPtr;
^
/home/gene/src/opencv_contrib-master/modules/surface_matching/misc/python/pyopencv_ppf_match_3d.hpp:16:44:
error: template argument 2 is invalid
In file included
from /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:15:0,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:2080:
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:4:40:
error: ‘linemod’ was not declared in this scope
template<> struct pyopencvVecConverter<linemod::Match>
^~~~~~~
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:4:54: error:
template argument 1 is invalid
template<> struct pyopencvVecConverter<linemod::Match>
^
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:17:40:
error: ‘linemod’ was not declared in this scope
template<> struct pyopencvVecConverter<linemod::Template>
^~~~~~~
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:17:57: error:
template argument 1 is invalid
template<> struct pyopencvVecConverter<linemod::Template>
^
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:30:40:
error: ‘linemod’ was not declared in this scope
template<> struct pyopencvVecConverter<linemod::Feature>
^~~~~~~
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:30:56: error:
template argument 1 is invalid
template<> struct pyopencvVecConverter<linemod::Feature>
^
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:43:44:
error: ‘linemod’ was not declared in this scope
template<> struct pyopencvVecConverter<Ptr<linemod::Modality> >
^~~~~~~
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:43:61: error:
template argument 1 is invalid
template<> struct pyopencvVecConverter<Ptr<linemod::Modality> >
^
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:43:63: error:
template argument 1 is invalid
template<> struct pyopencvVecConverter<Ptr<linemod::Modality> >
^
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:56:21:
error: ‘linemod’ was not declared in this scope
typedef std::vector<linemod::Match> vector_Match;
^~~~~~~
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:56:35: error:
template argument 1 is invalid
typedef std::vector<linemod::Match> vector_Match;
^
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:56:35: error:
template argument 2 is invalid
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:57:21:
error: ‘linemod’ was not declared in this scope
typedef std::vector<linemod::Template> vector_Template;
^~~~~~~
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:57:38: error:
template argument 1 is invalid
typedef std::vector<linemod::Template> vector_Template;
^
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:57:38: error:
template argument 2 is invalid
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:58:21:
error: ‘linemod’ was not declared in this scope
typedef std::vector<linemod::Feature> vector_Feature;
^~~~~~~
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:58:37: error:
template argument 1 is invalid
typedef std::vector<linemod::Feature> vector_Feature;
^
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:58:37: error:
template argument 2 is invalid
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:59:25:
error: ‘linemod’ was not declared in this scope
typedef std::vector<Ptr<linemod::Modality> > vector_Ptr_Modality;
^~~~~~~
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:59:42: error:
template argument 1 is invalid
typedef std::vector<Ptr<linemod::Modality> > vector_Ptr_Modality;
^
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:59:44: error:
template argument 1 is invalid
typedef std::vector<Ptr<linemod::Modality> > vector_Ptr_Modality;
^
/home/gene/src/opencv_contrib-master/modules/rgbd/misc/python/pyopencv_linemod.hpp:59:44: error:
template argument 2 is invalid
In file included
from /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:21:0,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:2080:
/home/gene/src/opencv_contrib-master/modules/tracking/misc/python/pyopencv_tracking.hpp:2:9:
error: ‘TrackerCSRT’ does not name a type
typedef TrackerCSRT::Params TrackerCSRT_Params;
^~~~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/tracking/misc/python/pyopencv_tracking.hpp:3:9:
error: ‘TrackerKCF’ does not name a type
typedef TrackerKCF::Params TrackerKCF_Params;
^~~~~~~~~~
In file included
from /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:22:0,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:2080:
/home/gene/src/opencv_contrib-master/modules/stereo/misc/python/pyopencv_stereo.hpp:2:21:
error: ‘stereo’ was not declared in this scope
typedef std::vector<stereo::MatchQuasiDense> vector_MatchQuasiDense;
^~~~~~
/home/gene/src/opencv_contrib-master/modules/stereo/misc/python/pyopencv_stereo.hpp:2:44: error:
template argument 1 is invalid
typedef std::vector<stereo::MatchQuasiDense> vector_MatchQuasiDense;
^
/home/gene/src/opencv_contrib-master/modules/stereo/misc/python/pyopencv_stereo.hpp:2:44: error:
template argument 2 is invalid
/home/gene/src/opencv_contrib-master/modules/stereo/misc/python/pyopencv_stereo.hpp:4:40:
error: ‘stereo’ was not declared in this scope
template<> struct pyopencvVecConverter<stereo::MatchQuasiDense>
^~~~~~
/home/gene/src/opencv_contrib-master/modules/stereo/misc/python/pyopencv_stereo.hpp:4:63: error:
template argument 1 is invalid
template<> struct pyopencvVecConverter<stereo::MatchQuasiDense>
^
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp: In instantiation of ‘bool
pyopencv_to(PyObject*, T&, const ArgInfo&) [with T = cv::line_descriptor::KeyLine; PyObje =
_object]’:
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1599:24: required from ‘bool
pyopencv_to_generic_vec(PyObject*, std::vector<_Tp>&, const ArgInfo&) [with _Tp =
cv:ine_descriptor::KeyLine; PyObject = _object]’
/home/gene/src/opencv_contrib-master/modules/line_descriptor/misc/python/pyopencv_LSDDetector.hpp:7:56:
required from here
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:72:94: error: ‘to’ is not a member
of ‘PyOpenCV_Converter<cv::line_descriptor::KeyLine, void>’
bool pyopencv_to(PyObject* obj, T& p, const ArgInfo& info) { return PyOpenCV_Converter<T>::to(obj,
p, info); }
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp: In instantiation of ‘PyObject*
pyopencv_from(const T&) [with T = cv::line_descriptor::KeyLine; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1611:39: required from ‘PyObject*
pyopencv_from_generic_vec(const std::vector<_Tp>&) [with _Tp = cv::line_descript::KeyLine; PyObject
= _object]’
/home/gene/src/opencv_contrib-master/modules/line_descriptor/misc/python/pyopencv_LSDDetector.hpp:12:47:
required from here
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:75:75: error: ‘from’ is not a member
of ‘PyOpenCV_Converter<cv::line_descriptor::KeyLine, void>’
PyObject* pyopencv_from(const T& src) { return PyOpenCV_Converter<T>::from(src); }
~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp: In instantiation of ‘bool
pyopencv_to(PyObject*, T&, const ArgInfo&) [with T = cv::mcc::CChecker; PyObject = _objec’:
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:762:27: required from ‘static bool
PyOpenCV_Converter<cv::Ptr<_Tp> >::to(PyObject*, cv::Ptr<_Tp>&, const ArgInfo&)with T =
cv::mcc::CChecker; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:72:94: required from ‘bool
pyopencv_to(PyObject*, T&, const ArgInfo&) [with T = cv::Ptr<cv::mcc::CChecker>; PyObje = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1599:24: required from ‘bool
pyopencv_to_generic_vec(PyObject*, std::vector<_Tp>&, const ArgInfo&) [with _Tp =
cv:tr<cv::mcc::CChecker>; PyObject = _object]’
/home/gene/src/opencv_contrib-master/modules/mcc/misc/python/pyopencv_cchecker.hpp:9:56: required
from here
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:72:94: error: ‘to’ is not a member
of ‘PyOpenCV_Converter<cv::mcc::CChecker, void>’
bool pyopencv_to(PyObject* obj, T& p, const ArgInfo& info) { return PyOpenCV_Converter<T>::to(obj,
p, info); }
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp: In instantiation of ‘PyObject*
pyopencv_from(const T&) [with T = cv::mcc::CChecker; PyObject = _object]’:
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:755:29: required from ‘static PyObject*
PyOpenCV_Converter<cv::Ptr<_Tp> >::from(const cv::Ptr<_Tp>&) [with T = cv:cc::CChecker; PyObject =
_object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:75:75: required from ‘PyObject*
pyopencv_from(const T&) [with T = cv::Ptr<cv::mcc::CChecker>; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1611:39: required from ‘PyObject*
pyopencv_from_generic_vec(const std::vector<_Tp>&) [with _Tp = cv::Ptr<cv::mcc::hecker>; PyObject =
_object]’
/home/gene/src/opencv_contrib-master/modules/mcc/misc/python/pyopencv_cchecker.hpp:14:47: required
from here
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:75:75: error: ‘from’ is not a member
of ‘PyOpenCV_Converter<cv::mcc::CChecker, void>’
PyObject* pyopencv_from(const T& src) { return PyOpenCV_Converter<T>::from(src); }
~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
In file included from /usr/include/x86_64-linux-gnu/c++/6/bits/c++allocator.h:33:0,
from /usr/include/c++/6/bits/allocator.h:46,
from /usr/include/c++/6/string:41,
from /usr/include/c++/6/stdexcept:39,
from /usr/include/c++/6/array:39,
from /home/gene/src/opencv-master/modules/core/include/opencv2/core/cvdef.h:738,
from /home/gene/src/opencv-master/modules/core/include/opencv2/core/cvstd.hpp:51,
from /home/gene/src/opencv-master/modules/core/include/opencv2/core/utils/configuration.private.hpp:8,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:35:
/usr/include/c++/6/ext/new_allocator.h: In instantiation of ‘void
__gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up = cv::mcc::CChecker; _Args =
{}; _Tp cv::mcc::CChecker]’:
/usr/include/c++/6/bits/alloc_traits.h:475:4: required from ‘static void
std::allocator_traits<std::allocator<_CharT> >::construct(std::allocator_traits<std::allocator<_ChT>
>::allocator_type&, _Up*, _Args&& ...) [with _Up = cv::mcc::CChecker; _Args = {}; _Tp =
cv::mcc::CChecker; std::allocator_traits<std::allocator<_CharT> >::allocator_type
std::allocator<cv::mcc::CChecker>]’
/usr/include/c++/6/bits/shared_ptr_base.h:520:39: required from ‘std::_Sp_counted_ptr_inplace<_Tp,
_Alloc, _Lp>::_Sp_counted_ptr_inplace(_Alloc, _Args&& ...) [with _Args =}; _Tp = cv::mcc::CChecker;
_Alloc = std::allocator<cv::mcc::CChecker>; __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)
2u]’
/usr/include/c++/6/bits/shared_ptr_base.h:615:4: required
from ‘std::__shared_count<_Lp>::__shared_count(std::_Sp_make_shared_tag, _Tp*, const _Alloc&,
_Args&& ...) [with p = cv::mcc::CChecker; _Alloc = std::allocator<cv::mcc::CChecker>; _Args = {};
__gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]’
/usr/include/c++/6/bits/shared_ptr_base.h:1100:35: required from ‘std::__shared_ptr<_Tp,
_Lp>::__shared_ptr(std::_Sp_make_shared_tag, const _Alloc&, _Args&& ...) [with _Alc =
std::allocator<cv::mcc::CChecker>; _Args = {}; _Tp = cv::mcc::CChecker; __gnu_cxx::_Lock_policy _Lp
= (__gnu_cxx::_Lock_policy)2u]’
/usr/include/c++/6/bits/shared_ptr.h:319:64: [ skipping 2 instantiation contexts,
use -ftemplate-backtrace-limit=0 to disable ]
/usr/include/c++/6/bits/shared_ptr.h:635:39: required from ‘std::shared_ptr<_Tp1>
std::make_shared(_Args&& ...) [with _Tp = cv::mcc::CChecker; _Args = {}]’
/home/gene/src/opencv-master/modules/core/include/opencv2/core/cvstd_wrapper.hpp:146:43: required
from ‘cv::Ptr<_Tp> cv::makePtr(const A1& ...) [with _Tp = cv::mcc::CCheck; A1 = {}]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:761:23: required from ‘static bool
PyOpenCV_Converter<cv::Ptr<_Tp> >::to(PyObject*, cv::Ptr<_Tp>&, const ArgInfo&)with T =
cv::mcc::CChecker; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:72:94: required from ‘bool
pyopencv_to(PyObject*, T&, const ArgInfo&) [with T = cv::Ptr<cv::mcc::CChecker>; PyObje = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1599:24: required from ‘bool
pyopencv_to_generic_vec(PyObject*, std::vector<_Tp>&, const ArgInfo&) [with _Tp =
cv:tr<cv::mcc::CChecker>; PyObject = _object]’
/home/gene/src/opencv_contrib-master/modules/mcc/misc/python/pyopencv_cchecker.hpp:9:56: required
from here
/usr/include/c++/6/ext/new_allocator.h:120:4: error: invalid new-expression of abstract class
type ‘cv::mcc::CChecker’
{ ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included
from /home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_detector.hpp:32:0,
from /home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc.hpp:33,
from /home/gene/src/opencv_contrib-master/modules/mcc/misc/python/pyopencv_cchecker.hpp:1,
from /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:13,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:2080:
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:64:20: note:
because the following virtual functions are pure within ‘cv::mcc::CChecr’:
class CV_EXPORTS_W CChecker
^~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:83:26: note:
virtual void cv::mcc::CChecker::setTarget(cv::mcc::TYPECHART)
CV_WRAP virtual void setTarget(TYPECHART _target) = 0;
^~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:84:26: note:
virtual void cv::mcc::CChecker::setBox(std::vector<cv::Point_<float>
CV_WRAP virtual void setBox(std::vector<Point2f> _box) = 0;
^~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:85:26: note:
virtual void cv::mcc::CChecker::setChartsRGB(cv::Mat)
CV_WRAP virtual void setChartsRGB(Mat _chartsRGB) = 0;
^~~~~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:86:26: note:
virtual void cv::mcc::CChecker::setChartsYCbCr(cv::Mat)
CV_WRAP virtual void setChartsYCbCr(Mat _chartsYCbCr) = 0;
^~~~~~~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:87:26: note:
virtual void cv::mcc::CChecker::setCost(float)
CV_WRAP virtual void setCost(float _cost) = 0;
^~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:88:26: note:
virtual void cv::mcc::CChecker::setCenter(cv::Point2f)
CV_WRAP virtual void setCenter(Point2f _center) = 0;
^~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:90:31: note:
virtual cv::mcc::TYPECHART cv::mcc::CChecker::getTarget()
CV_WRAP virtual TYPECHART getTarget() = 0;
^~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:91:42: note:
virtual std::vector<cv::Point_<float> > cv::mcc::CChecker::getBox()
CV_WRAP virtual std::vector<Point2f> getBox() = 0;
^~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:92:25: note:
virtual cv::Mat cv::mcc::CChecker::getChartsRGB()
CV_WRAP virtual Mat getChartsRGB() = 0;
^~~~~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:93:25: note:
virtual cv::Mat cv::mcc::CChecker::getChartsYCbCr()
CV_WRAP virtual Mat getChartsYCbCr() = 0;
^~~~~~~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:94:27: note:
virtual float cv::mcc::CChecker::getCost()
CV_WRAP virtual float getCost() = 0;
^~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:95:29: note:
virtual cv::Point2f cv::mcc::CChecker::getCenter()
CV_WRAP virtual Point2f getCenter() = 0;
^~~~~~~~~
modules/python2/CMakeFiles/opencv_python2.dir/build.make:62: recipe for
target 'modules/python2/CMakeFiles/opencv_python2.dir/__/src2/cv2.cpp.o' failed
make[2]: *** [modules/python2/CMakeFiles/opencv_python2.dir/__/src2/cv2.cpp.o] Error 1
CMakeFiles/Makefile2:9717: recipe for target 'modules/python2/CMakeFiles/opencv_python2.dir/all'
failed
make[1]: *** [modules/python2/CMakeFiles/opencv_python2.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
gene@coyote:~/src/build$
target 'modules/python2/CMakeFiles/opencv_python2.dir/__/src2/cv2.cpp.o' failed
make[2]: *** [modules/python2/CMakeFiles/opencv_python2.dir/__/src2/cv2.cpp.o] Error 1
CMakeFiles/Makefile2:9717: recipe for target 'modules/python2/CMakeFiles/opencv_python2.dir/all'
failed
make[1]: *** [modules/python2/CMakeFiles/opencv_python2.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
> Regards,
Gene Heskett
Jan 25, 2021, 3:50:05 PM1/25/21
to
On Monday 25 January 2021 15:32:19 Greg Wooledge wrote:
> On Mon, Jan 25, 2021 at 03:13:55PM -0500, Gene Heskett wrote:
> > Why Greg, do you seem to always blame the messenger?
>
> Because the message is ripped up into pieces, and you're telling us
> only some half-remembered piece of it.
>
> > direct copy/paste from the opencv build instructions html page:
> >
> > wget -O opencv.zip
> > https://github.com/opencv/opencv/archive/master.zip wget -O
> > opencv_contrib.zip
> > https://github.com/opencv/opencv_contrib/archive/master.zip
>
> Those look safe enough to rule out the URL quoting issue. It would
> be nice if you would show us the terminal session in which you ran the
> command and got an error. Lacking that information, we can only guess
> as to the many possible causes of the many possible errors.
>
> Here is a short list of guesses.
>
> 1) You have a shell function or alias that overrides the wget command.
> Diagnose this by running "type wget".
>
Interesting:
> On Mon, Jan 25, 2021 at 03:13:55PM -0500, Gene Heskett wrote:
> > Why Greg, do you seem to always blame the messenger?
>
> Because the message is ripped up into pieces, and you're telling us
> only some half-remembered piece of it.
>
> > direct copy/paste from the opencv build instructions html page:
> >
> > wget -O opencv.zip
> > https://github.com/opencv/opencv/archive/master.zip wget -O
> > opencv_contrib.zip
> > https://github.com/opencv/opencv_contrib/archive/master.zip
>
> Those look safe enough to rule out the URL quoting issue. It would
> be nice if you would show us the terminal session in which you ran the
> command and got an error. Lacking that information, we can only guess
> as to the many possible causes of the many possible errors.
>
> Here is a short list of guesses.
>
> 1) You have a shell function or alias that overrides the wget command.
> Diagnose this by running "type wget".
>
gene@coyote:~/src/build$ type wget
wget is hashed (/usr/bin/wget)
gene@coyote:~/src/build$
What the heck does that mean?
no extra charge:
file /usr/bin/wget
/usr/bin/wget: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 2.6.32,
BuildID[sha1]=35ceae6f53de184f4f46494aa6bb872a6edb0010, stripped
> 2) You do not have write permission on the current directory.
> Diagnose this by running "id" and "ls -ld .".
uid=1000(gene) gid=1000(gene) groups=1000(gene),4(adm),5(tty),6(disk),7
(lp),8(mail),12(man),20(dialout),24(cdrom),25(floppy),27(sudo),29
(audio),33(www-data),44(video),46(plugdev),50(staff),100(users),102
(systemd-timesync),116(lpadmin),118(pulse),119(pulse-access),120
(scanner),122(colord),123(saned),125(nut)
gene@coyote:~/src/build$ ls -ld
drwxr-xr-x 19 gene gene 4096 Jan 25 14:05 .
> The string "Permission denied" in the command's output would be a
> strong indicator of this one.
> 3) You pasted the command from a source that has non-breaking spaces
> or other non-ASCII garbage polluting the arguments.
> 4) You have run out of disk space.
> Diagnose this by running "df .".
> The string "No space left on device" would strongly indicate this
> one.
df -h grep sda
/dev/sda5 1.8T 291G 1.4T 18% /
/dev/sda1 922M 183M 677M 22% /boot
/dev/sda3 46G 4.7G 39G 11% /var
>
> 5) Quotas.
Diagnostic for that?
Greg Wooledge
Jan 25, 2021, 4:00:05 PM1/25/21
to
On Mon, Jan 25, 2021 at 03:47:03PM -0500, Gene Heskett wrote:
> > 1) You have a shell function or alias that overrides the wget command.
> > Diagnose this by running "type wget".
> >
> Interesting:
> gene@coyote:~/src/build$ type wget
> wget is hashed (/usr/bin/wget)
> gene@coyote:~/src/build$
>
> What the heck does that mean?
It means you don't have a shell alias or function named wget. It also
> > 1) You have a shell function or alias that overrides the wget command.
> > Diagnose this by running "type wget".
> >
> Interesting:
> gene@coyote:~/src/build$ type wget
> wget is hashed (/usr/bin/wget)
> gene@coyote:~/src/build$
>
> What the heck does that mean?
means you've run wget at least once previously in the current interactive
shell, so that its location in the PATH list is cached.
> gene@coyote:~/src/build$ id
> uid=1000(gene) gid=1000(gene) groups=1000(gene),4(adm),5(tty),6(disk),7
> (lp),8(mail),12(man),20(dialout),24(cdrom),25(floppy),27(sudo),29
> (audio),33(www-data),44(video),46(plugdev),50(staff),100(users),102
> (systemd-timesync),116(lpadmin),118(pulse),119(pulse-access),120
> (scanner),122(colord),123(saned),125(nut)
>
> gene@coyote:~/src/build$ ls -ld
> drwxr-xr-x 19 gene gene 4096 Jan 25 14:05 .
> > 3) You pasted the command from a source that has non-breaking spaces
> > or other non-ASCII garbage polluting the arguments.
>
> How would that be diagnosed?
hex-dumping the command, extremely carefully.
> df -h grep sda
> /dev/sda5 1.8T 291G 1.4T 18% /
> /dev/sda1 922M 183M 677M 22% /boot
> /dev/sda3 46G 4.7G 39G 11% /var
this all looks fine, but it doesn't tell us anything about ~gene.
> > 5) Quotas.
>
> Diagnostic for that?
Why don't you just show us the wget command and its error message so
we can stop guessing?
Gene Heskett
Jan 25, 2021, 4:10:04 PM1/25/21
to
gene@coyote:~/src/build$ cd .. && wget -O opencv.zip https://github.com/opencv/opencv/archive/master.zip
Cannot specify both -k or --convert-file-only and -O if multiple URLs are given, or in combination
with -p or -r. See the manual for details.
Usage: wget [OPTION]... [URL]...
But the man page says it's legal.
Thanks Greg.
Greg Wooledge
Jan 25, 2021, 5:10:08 PM1/25/21
to
On Mon, Jan 25, 2021 at 04:07:33PM -0500, Gene Heskett wrote:
> gene@coyote:~/src/build$ cd .. && wget -O opencv.zip https://github.com/opencv/opencv/archive/master.zip
> Cannot specify both -k or --convert-file-only and -O if multiple URLs are given, or in combination
> with -p or -r. See the manual for details.
>
> Usage: wget [OPTION]... [URL]...
I tried to duplicate this myself, using buster, and using stretch (as
> gene@coyote:~/src/build$ cd .. && wget -O opencv.zip https://github.com/opencv/opencv/archive/master.zip
> Cannot specify both -k or --convert-file-only and -O if multiple URLs are given, or in combination
> with -p or -r. See the manual for details.
>
> Usage: wget [OPTION]... [URL]...
you previously reported this is on stretch). I was not able to do so
using only modifications of the command you gave. I tried replacing the
space after -O with a non-breaking space, and I tried using -O -opencv.zip
(hinted by the -p in the error message).
My next guess is that perhaps wget is receiving additional options from
somewhere other than your command line. Perhaps via an environment
variable, or something.
Apparently wget doesn't have any such env vars, but it does allow a
startup file, which it calls ".wgetrc". Or /etc/wgetrc.
So, after reading up on that, and experimenting a bit:
unicorn:/tmp/build$ cat ~/.wgetrc
convert-links = on
page-requisites = on
If I create a ~/.wgetrc file with at least those two lines in it, then
I get the same error you got.
Do you have a ~/.wgetrc file? If so, what's in it? If not, what's in
your /etc/wgetrc file (other than comments and blank lines)?
Gene Heskett
Jan 25, 2021, 5:40:04 PM1/25/21
to
Everything else is # commented.
Gene Heskett
Jan 25, 2021, 5:40:04 PM1/25/21
to
On Monday 25 January 2021 16:48:52 Darac Marjal wrote:
no_parent = on
follow_ftp = on
recursive = on
reclevel = 20
convert_links = on
Gene Heskett
Jan 25, 2021, 5:50:04 PM1/25/21
to
no_parent = on
follow_ftp = on
recursive = on
reclevel = 20
convert_links = on
and the only option that is not commented in /etc/wgetrc is the
follow_ftp = on
recursive = on
reclevel = 20
convert_links = on
passive_fpt = on
Gene Heskett
Jan 25, 2021, 6:00:05 PM1/25/21
to
> convert_links = on <-I took this line out and its working.
>
>
> Cheers, Gene Heskett
Gene Heskett
Jan 25, 2021, 6:10:04 PM1/25/21
to
[ 97%] Built target opencv_test_stereo
[ 97%] Built target gen_opencv_python_source
[ 97%] Building CXX object modules/python2/CMakeFiles/opencv_python2.dir/__/src2/cv2.cpp.o
In file included from /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:7:0,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:2080:
/home/gene/src/opencv_contrib-master/modules/phase_unwrapping/misc/python/pyopencv_phase_unwrapping.hpp:2:13:
In file included from /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:7:0,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:2080:
/home/gene/src/opencv_contrib-master/modules/phase_unwrapping/misc/python/pyopencv_phase_unwrapping.hpp:2:13:
error: ‘phase_unwrapping’ in namespace ‘cv’ does not name a type
typedef cv::phase_unwrapping::HistogramPhaseUnwrapping::Params HistogramPhaseUnwrapping_Params;
^~~~~~~~~~~~~~~~
typedef cv::phase_unwrapping::HistogramPhaseUnwrapping::Params HistogramPhaseUnwrapping_Params;
^~~~~~~~~~~~~~~~
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1599:24: required from ‘bool pyopencv_to_generic_vec(PyObject*,
std::vector<_Tp>&, const ArgInfo&) [with _Tp = cv::line_descriptor::KeyLine; PyObject = _object]’
/home/gene/src/opencv_contrib-master/modules/line_descriptor/misc/python/pyopencv_LSDDetector.hpp:7:56: required from here
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:72:94: error: ‘to’ is not a member
of ‘PyOpenCV_Converter<cv::line_descriptor::KeyLine, void>’
bool pyopencv_to(PyObject* obj, T& p, const ArgInfo& info) { return PyOpenCV_Converter<T>::to(obj, p, info); }
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp: In instantiation of ‘PyObject* pyopencv_from(const T&) [with T =
cv::line_descriptor::KeyLine; PyObject = _object]’:
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1611:39: required from ‘PyObject* pyopencv_from_generic_vec(const
std::vector<_Tp>&) [with _Tp = cv::line_descriptor::KeyLine; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:72:94: error: ‘to’ is not a member
of ‘PyOpenCV_Converter<cv::line_descriptor::KeyLine, void>’
bool pyopencv_to(PyObject* obj, T& p, const ArgInfo& info) { return PyOpenCV_Converter<T>::to(obj, p, info); }
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp: In instantiation of ‘PyObject* pyopencv_from(const T&) [with T =
cv::line_descriptor::KeyLine; PyObject = _object]’:
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1611:39: required from ‘PyObject* pyopencv_from_generic_vec(const
/home/gene/src/opencv_contrib-master/modules/line_descriptor/misc/python/pyopencv_LSDDetector.hpp:12:47: required from here
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:75:75: error: ‘from’ is not a member
of ‘PyOpenCV_Converter<cv::line_descriptor::KeyLine, void>’
PyObject* pyopencv_from(const T& src) { return PyOpenCV_Converter<T>::from(src); }
~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp: In instantiation of ‘bool pyopencv_to(PyObject*, T&, const ArgInfo&)
[with T = cv::mcc::CChecker; PyObject = _object]’:
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:75:75: error: ‘from’ is not a member
of ‘PyOpenCV_Converter<cv::line_descriptor::KeyLine, void>’
PyObject* pyopencv_from(const T& src) { return PyOpenCV_Converter<T>::from(src); }
~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp: In instantiation of ‘bool pyopencv_to(PyObject*, T&, const ArgInfo&)
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:762:27: required from ‘static bool PyOpenCV_Converter<cv::Ptr<_Tp>
>::to(PyObject*, cv::Ptr<_Tp>&, const ArgInfo&) [with T = cv::mcc::CChecker; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:72:94: required from ‘bool pyopencv_to(PyObject*, T&, const ArgInfo&)
[with T = cv::Ptr<cv::mcc::CChecker>; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1599:24: required from ‘bool pyopencv_to_generic_vec(PyObject*,
std::vector<_Tp>&, const ArgInfo&) [with _Tp = cv::Ptr<cv::mcc::CChecker>; PyObject = _object]’
/home/gene/src/opencv_contrib-master/modules/mcc/misc/python/pyopencv_cchecker.hpp:9:56: required from here
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:72:94: error: ‘to’ is not a member
of ‘PyOpenCV_Converter<cv::mcc::CChecker, void>’
bool pyopencv_to(PyObject* obj, T& p, const ArgInfo& info) { return PyOpenCV_Converter<T>::to(obj, p, info); }
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp: In instantiation of ‘PyObject* pyopencv_from(const T&) [with T =
cv::mcc::CChecker; PyObject = _object]’:
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:755:29: required from ‘static PyObject*
PyOpenCV_Converter<cv::Ptr<_Tp> >::from(const cv::Ptr<_Tp>&) [with T = cv::mcc::CChecker; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:72:94: error: ‘to’ is not a member
of ‘PyOpenCV_Converter<cv::mcc::CChecker, void>’
bool pyopencv_to(PyObject* obj, T& p, const ArgInfo& info) { return PyOpenCV_Converter<T>::to(obj, p, info); }
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp: In instantiation of ‘PyObject* pyopencv_from(const T&) [with T =
cv::mcc::CChecker; PyObject = _object]’:
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:755:29: required from ‘static PyObject*
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:75:75: required from ‘PyObject* pyopencv_from(const T&) [with T =
cv::Ptr<cv::mcc::CChecker>; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1611:39: required from ‘PyObject* pyopencv_from_generic_vec(const
std::vector<_Tp>&) [with _Tp = cv::Ptr<cv::mcc::CChecker>; PyObject = _object]’
cv::Ptr<cv::mcc::CChecker>; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1611:39: required from ‘PyObject* pyopencv_from_generic_vec(const
/home/gene/src/opencv_contrib-master/modules/mcc/misc/python/pyopencv_cchecker.hpp:14:47: required from here
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:75:75: error: ‘from’ is not a member
of ‘PyOpenCV_Converter<cv::mcc::CChecker, void>’
PyObject* pyopencv_from(const T& src) { return PyOpenCV_Converter<T>::from(src); }
~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
In file included from /usr/include/x86_64-linux-gnu/c++/6/bits/c++allocator.h:33:0,
from /usr/include/c++/6/bits/allocator.h:46,
from /usr/include/c++/6/string:41,
from /usr/include/c++/6/stdexcept:39,
from /usr/include/c++/6/array:39,
from /home/gene/src/opencv-master/modules/core/include/opencv2/core/cvdef.h:738,
from /home/gene/src/opencv-master/modules/core/include/opencv2/core/cvstd.hpp:51,
from /home/gene/src/opencv-master/modules/core/include/opencv2/core/utils/configuration.private.hpp:8,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:35:
/usr/include/c++/6/ext/new_allocator.h: In instantiation of ‘void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...)
[with _Up = cv::mcc::CChecker; _Args = {}; _Tp = cv::mcc::CChecker]’:
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:75:75: error: ‘from’ is not a member
of ‘PyOpenCV_Converter<cv::mcc::CChecker, void>’
PyObject* pyopencv_from(const T& src) { return PyOpenCV_Converter<T>::from(src); }
~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
In file included from /usr/include/x86_64-linux-gnu/c++/6/bits/c++allocator.h:33:0,
from /usr/include/c++/6/bits/allocator.h:46,
from /usr/include/c++/6/string:41,
from /usr/include/c++/6/stdexcept:39,
from /usr/include/c++/6/array:39,
from /home/gene/src/opencv-master/modules/core/include/opencv2/core/cvdef.h:738,
from /home/gene/src/opencv-master/modules/core/include/opencv2/core/cvstd.hpp:51,
from /home/gene/src/opencv-master/modules/core/include/opencv2/core/utils/configuration.private.hpp:8,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:35:
/usr/include/c++/6/ext/new_allocator.h: In instantiation of ‘void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...)
/usr/include/c++/6/bits/alloc_traits.h:475:4: required from ‘static void std::allocator_traits<std::allocator<_CharT>
>::construct(std::allocator_traits<std::allocator<_CharT> >::allocator_type&, _Up*, _Args&& ...) [with _Up = cv::mcc::CChecker;
_Args = {}; _Tp = cv::mcc::CChecker; std::allocator_traits<std::allocator<_CharT> >::allocator_type =
std::allocator<cv::mcc::CChecker>]’
/usr/include/c++/6/bits/shared_ptr_base.h:520:39: required from ‘std::_Sp_counted_ptr_inplace<_Tp, _Alloc,
_Lp>::_Sp_counted_ptr_inplace(_Alloc, _Args&& ...) [with _Args = {}; _Tp = cv::mcc::CChecker; _Alloc =
std::allocator<cv::mcc::CChecker>; __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]’
/usr/include/c++/6/bits/shared_ptr_base.h:615:4: required
from ‘std::__shared_count<_Lp>::__shared_count(std::_Sp_make_shared_tag, _Tp*, const _Alloc&, _Args&& ...) [with _Tp =
/usr/include/c++/6/bits/shared_ptr_base.h:520:39: required from ‘std::_Sp_counted_ptr_inplace<_Tp, _Alloc,
_Lp>::_Sp_counted_ptr_inplace(_Alloc, _Args&& ...) [with _Args = {}; _Tp = cv::mcc::CChecker; _Alloc =
std::allocator<cv::mcc::CChecker>; __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]’
/usr/include/c++/6/bits/shared_ptr_base.h:615:4: required
cv::mcc::CChecker; _Alloc = std::allocator<cv::mcc::CChecker>; _Args = {}; __gnu_cxx::_Lock_policy _Lp =
(__gnu_cxx::_Lock_policy)2u]’
/usr/include/c++/6/bits/shared_ptr_base.h:1100:35: required from ‘std::__shared_ptr<_Tp,
_Lp>::__shared_ptr(std::_Sp_make_shared_tag, const _Alloc&, _Args&& ...) [with _Alloc = std::allocator<cv::mcc::CChecker>; _Args
(__gnu_cxx::_Lock_policy)2u]’
/usr/include/c++/6/bits/shared_ptr_base.h:1100:35: required from ‘std::__shared_ptr<_Tp,
= {}; _Tp = cv::mcc::CChecker; __gnu_cxx::_Lock_policy _Lp = (__gnu_cxx::_Lock_policy)2u]’
/usr/include/c++/6/bits/shared_ptr.h:319:64: [ skipping 2 instantiation contexts, use -ftemplate-backtrace-limit=0 to
disable ]
/usr/include/c++/6/bits/shared_ptr.h:635:39: required from ‘std::shared_ptr<_Tp1> std::make_shared(_Args&& ...) [with _Tp =
cv::mcc::CChecker; _Args = {}]’
/home/gene/src/opencv-master/modules/core/include/opencv2/core/cvstd_wrapper.hpp:146:43: required from ‘cv::Ptr<_Tp>
cv::makePtr(const A1& ...) [with _Tp = cv::mcc::CChecker; A1 = {}]’
/usr/include/c++/6/bits/shared_ptr.h:319:64: [ skipping 2 instantiation contexts, use -ftemplate-backtrace-limit=0 to
disable ]
/usr/include/c++/6/bits/shared_ptr.h:635:39: required from ‘std::shared_ptr<_Tp1> std::make_shared(_Args&& ...) [with _Tp =
cv::mcc::CChecker; _Args = {}]’
/home/gene/src/opencv-master/modules/core/include/opencv2/core/cvstd_wrapper.hpp:146:43: required from ‘cv::Ptr<_Tp>
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:761:23: required from ‘static bool PyOpenCV_Converter<cv::Ptr<_Tp>
>::to(PyObject*, cv::Ptr<_Tp>&, const ArgInfo&) [with T = cv::mcc::CChecker; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:72:94: required from ‘bool pyopencv_to(PyObject*, T&, const ArgInfo&)
[with T = cv::Ptr<cv::mcc::CChecker>; PyObject = _object]’
/home/gene/src/opencv-master/modules/python/src2/cv2.cpp:1599:24: required from ‘bool pyopencv_to_generic_vec(PyObject*,
std::vector<_Tp>&, const ArgInfo&) [with _Tp = cv::Ptr<cv::mcc::CChecker>; PyObject = _object]’
/home/gene/src/opencv_contrib-master/modules/mcc/misc/python/pyopencv_cchecker.hpp:9:56: required from here
/usr/include/c++/6/ext/new_allocator.h:120:4: error: invalid new-expression of abstract class type ‘cv::mcc::CChecker’
{ ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_detector.hpp:32:0,
from /home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc.hpp:33,
from /home/gene/src/opencv_contrib-master/modules/mcc/misc/python/pyopencv_cchecker.hpp:1,
from /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:13,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:2080:
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:64:20: note: because the following
virtual functions are pure within ‘cv::mcc::CChecker’:
/usr/include/c++/6/ext/new_allocator.h:120:4: error: invalid new-expression of abstract class type ‘cv::mcc::CChecker’
{ ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_detector.hpp:32:0,
from /home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc.hpp:33,
from /home/gene/src/opencv_contrib-master/modules/mcc/misc/python/pyopencv_cchecker.hpp:1,
from /home/gene/src/build/modules/python_bindings_generator/pyopencv_custom_headers.h:13,
from /home/gene/src/opencv-master/modules/python/src2/cv2.cpp:2080:
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:64:20: note: because the following
class CV_EXPORTS_W CChecker
^~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:83:26: note: virtual void
cv::mcc::CChecker::setTarget(cv::mcc::TYPECHART)
CV_WRAP virtual void setTarget(TYPECHART _target) = 0;
^~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:84:26: note: virtual void
cv::mcc::CChecker::setBox(std::vector<cv::Point_<float> >)
^~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:83:26: note: virtual void
cv::mcc::CChecker::setTarget(cv::mcc::TYPECHART)
CV_WRAP virtual void setTarget(TYPECHART _target) = 0;
^~~~~~~~~
/home/gene/src/opencv_contrib-master/modules/mcc/include/opencv2/mcc/checker_model.hpp:84:26: note: virtual void
Thanks for reading this far.
deloptes
Jan 25, 2021, 6:20:05 PM1/25/21
to
Gene Heskett wrote:
> Because synaptic says what is it the debian repo's is 10 years old?
Well, at some point of time you stop repairing the car, you just drive it to
> Because synaptic says what is it the debian repo's is 10 years old?
the grave yard, no?
It would be cheaper to upgrade because if you upgrade at the end you will
have up to date system.
Vincent Lefevre
Jan 26, 2021, 4:50:05 AM1/26/21
to
On 2021-01-25 17:42:51 -0500, Gene Heskett wrote:
> On Monday 25 January 2021 17:04:23 Greg Wooledge wrote:
>
> > On Mon, Jan 25, 2021 at 04:07:33PM -0500, Gene Heskett wrote:
> > > gene@coyote:~/src/build$ cd .. && wget -O opencv.zip
> > > https://github.com/opencv/opencv/archive/master.zip Cannot specify
> > > both -k or --convert-file-only and -O if multiple URLs are given, or
^^ ^^ ^^^^^^^^^^^^^
> On Monday 25 January 2021 17:04:23 Greg Wooledge wrote:
>
> > On Mon, Jan 25, 2021 at 04:07:33PM -0500, Gene Heskett wrote:
> > > gene@coyote:~/src/build$ cd .. && wget -O opencv.zip
> > > https://github.com/opencv/opencv/archive/master.zip Cannot specify
> > > both -k or --convert-file-only and -O if multiple URLs are given, or
> > > in combination with -p or -r. See the manual for details.
> > >
> > > Usage: wget [OPTION]... [URL]...
[...]
> > >
> > > Usage: wget [OPTION]... [URL]...
> > Do you have a ~/.wgetrc file? If so, what's in it? If not, what's in
> > your /etc/wgetrc file (other than comments and blank lines)?
> gene@coyote:~$ cat .wgetrc
> no_parent = on
> follow_ftp = on
> recursive = on
> reclevel = 20
> convert_links = on
Note that convert_links is -k and you have "recursive = on", which
> > your /etc/wgetrc file (other than comments and blank lines)?
> gene@coyote:~$ cat .wgetrc
> no_parent = on
> follow_ftp = on
> recursive = on
> reclevel = 20
> convert_links = on
means multiple URLs. Then the use of -O on the command line explains
the error.
--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Vincent Lefevre
Jan 26, 2021, 4:50:05 AM1/26/21
to
On 2021-01-26 10:40:01 +0100, Vincent Lefevre wrote:
> On 2021-01-25 17:42:51 -0500, Gene Heskett wrote:
> > On Monday 25 January 2021 17:04:23 Greg Wooledge wrote:
> >
> > > On Mon, Jan 25, 2021 at 04:07:33PM -0500, Gene Heskett wrote:
> > > > gene@coyote:~/src/build$ cd .. && wget -O opencv.zip
> > > > https://github.com/opencv/opencv/archive/master.zip Cannot specify
> > > > both -k or --convert-file-only and -O if multiple URLs are given, or
^^ ^^
> On 2021-01-25 17:42:51 -0500, Gene Heskett wrote:
> > On Monday 25 January 2021 17:04:23 Greg Wooledge wrote:
> >
> > > On Mon, Jan 25, 2021 at 04:07:33PM -0500, Gene Heskett wrote:
> > > > gene@coyote:~/src/build$ cd .. && wget -O opencv.zip
> > > > https://github.com/opencv/opencv/archive/master.zip Cannot specify
> > > > both -k or --convert-file-only and -O if multiple URLs are given, or
^^ ^^
> > > > in combination with -p or -r. See the manual for details.
^^
> > > >
> > > > Usage: wget [OPTION]... [URL]...
> [...]
> > > Do you have a ~/.wgetrc file? If so, what's in it? If not, what's in
> > > your /etc/wgetrc file (other than comments and blank lines)?
> > gene@coyote:~$ cat .wgetrc
> > no_parent = on
> > follow_ftp = on
> > recursive = on
> > reclevel = 20
> > convert_links = on
>
> Note that convert_links is -k and you have "recursive = on", which
> means multiple URLs. Then the use of -O on the command line explains
> the error.
Actually the error message explicitly mentions -r, which is implied
> > > > Usage: wget [OPTION]... [URL]...
> [...]
> > > Do you have a ~/.wgetrc file? If so, what's in it? If not, what's in
> > > your /etc/wgetrc file (other than comments and blank lines)?
> > gene@coyote:~$ cat .wgetrc
> > no_parent = on
> > follow_ftp = on
> > recursive = on
> > reclevel = 20
> > convert_links = on
>
> Note that convert_links is -k and you have "recursive = on", which
> means multiple URLs. Then the use of -O on the command line explains
> the error.
by "recursive = on". So, as a summary, you simultaneously have the
equivalent of -k, -O and -r.
to...@tuxteam.de
Jan 26, 2021, 4:50:05 AM1/26/21
to
On Mon, Jan 25, 2021 at 05:38:04PM -0500, Gene Heskett wrote:
[...]
> > > posted at least once today:
> > > gene@coyote:~/src/build$ cd .. && wget -O opencv.zip
> > > https://github.com/opencv/opencv/archive/master.zip Cannot specify
> > > both -k or --convert-file-only and -O if multiple URLs are given, or
> > > in combination with -p or -r. See the manual for details.
> > >
> > > Usage: wget [OPTION]... [URL]...
> > >
> > > But the man page says it's legal.
[...]
> however I also have in my home dir, a .wgetrc, containing:
Ahhh, and here they are...
> no_parent = on
> follow_ftp = on
> recursive = on
...the "recursive", aka "-r"...
> reclevel = 20
> convert_links = on
...and the "--convert-links" aka "-k" options...
which conflict with your "-O" given on the command line. This was
pretty sly, to hide all that from us. You thought the dot in front
of the file would dupe us? ;-)
Now more seriously: try again, putting aside your .wgetrc. Or see
whether wget's man page offers an option to temporarily ignore
.wgetrc. And thank Greg (I hope I'm not mis-assigning) for mentioning
/etc/wgetrc and .wgetrc!
Side note: please don't mix your wget problems with your other build
problems. This is coufusing the hell of us all. And you don't want
to get help from confused people, do you?
To the build process itself, I just ventured a look to the Debian
package page [1] and some around. Oh boy. A package with > 20
dependencies, with a CMake build infrastructure and all that.
You are into something. Not that I am discouraging you to do it,
on the contrary. This is free software, and that's the gist of it,
after all.
But prepare yourself for a long journey. If I were you, I'd download
the Debian source package and build that, just to see how a successful
build looks like: the Debian infra will take care of installing the
build dependencies and all that.
Once that succeeds you will have more chops to tackle the big beast.
Good luck (and no, I can't help with monster C++/CMake projects).
- tomás
[...]
> > > posted at least once today:
> > > gene@coyote:~/src/build$ cd .. && wget -O opencv.zip
> > > https://github.com/opencv/opencv/archive/master.zip Cannot specify
> > > both -k or --convert-file-only and -O if multiple URLs are given, or
> > > in combination with -p or -r. See the manual for details.
> > >
> > > Usage: wget [OPTION]... [URL]...
> > >
> > > But the man page says it's legal.
> however I also have in my home dir, a .wgetrc, containing:
> no_parent = on
> follow_ftp = on
> recursive = on
> reclevel = 20
> convert_links = on
which conflict with your "-O" given on the command line. This was
pretty sly, to hide all that from us. You thought the dot in front
of the file would dupe us? ;-)
Now more seriously: try again, putting aside your .wgetrc. Or see
whether wget's man page offers an option to temporarily ignore
.wgetrc. And thank Greg (I hope I'm not mis-assigning) for mentioning
/etc/wgetrc and .wgetrc!
Side note: please don't mix your wget problems with your other build
problems. This is coufusing the hell of us all. And you don't want
to get help from confused people, do you?
To the build process itself, I just ventured a look to the Debian
package page [1] and some around. Oh boy. A package with > 20
dependencies, with a CMake build infrastructure and all that.
You are into something. Not that I am discouraging you to do it,
on the contrary. This is free software, and that's the gist of it,
after all.
But prepare yourself for a long journey. If I were you, I'd download
the Debian source package and build that, just to see how a successful
build looks like: the Debian infra will take care of installing the
build dependencies and all that.
Once that succeeds you will have more chops to tackle the big beast.
Good luck (and no, I can't help with monster C++/CMake projects).
- tomás
Gene Heskett
Jan 26, 2021, 6:30:05 AM1/26/21
to
page. You would think that would lead to such a common failure that it
would be documented.
And I went back thru the history and found some dependency fail this
might have cause, and which synaptic won't let me fix, broken held
packages but won't ident the clashes so they might be fixed. So I blew
away my .wgetrc and am pulling fresh copies of both.
Thanks for hanging in there till we actually found the problem. Much
appreciated everybody.
to...@tuxteam.de
Jan 26, 2021, 7:20:04 AM1/26/21
to
On Tue, Jan 26, 2021 at 12:30:39PM +0100, Nicolas George wrote:
> Greg Wooledge (12021-01-25):
> > Gene, you've been here a while, so you should know better than this.
>
> Where's the incentive at knowing better when one gets more help by
> making no efforts?
I think this is a bit unfair. I humbly suggest to enhance such generic
> Greg Wooledge (12021-01-25):
> > Gene, you've been here a while, so you should know better than this.
>
> Where's the incentive at knowing better when one gets more help by
> making no efforts?
rants with some concrete help, at the very least.
Cheers
- t
l0f...@tuta.io
Jan 26, 2021, 7:40:04 AM1/26/21
to
Hi,
26 janv. 2021 à 10:44 de to...@tuxteam.de:
> And thank Greg (I hope I'm not mis-assigning) for mentioning
> /etc/wgetrc and .wgetrc!
>
Let's not forget Darac Marjal who was the first (by a few minutes) actually ;)
Best regards,
l0f4r0
26 janv. 2021 à 10:44 de to...@tuxteam.de:
> And thank Greg (I hope I'm not mis-assigning) for mentioning
> /etc/wgetrc and .wgetrc!
>
Best regards,
l0f4r0
Greg Wooledge
Jan 26, 2021, 7:40:04 AM1/26/21
to
On Tue, Jan 26, 2021 at 06:27:40AM -0500, Gene Heskett wrote:
> The thing I don't get was that is the direct command from their buildit
> page. You would think that would lead to such a common failure that it
> would be documented.
Nobody should have to guess that the reader has a custom ~/.wgetrc file
> The thing I don't get was that is the direct command from their buildit
> page. You would think that would lead to such a common failure that it
> would be documented.
with multiple non-default options set to "on". It is completely unfair
to put the blame for this on the writers of documentation that involves
downloading files.
It would be like... reading a cookbook that tells you how to bake cookies,
but complaining that the cookbook does not take into account that your
oven's temperature control is in Kelvin instead of degrees Fahrenheit.
Vincent Lefevre
Jan 26, 2021, 8:50:05 AM1/26/21
to
On 2021-01-26 06:27:40 -0500, Gene Heskett wrote:
> The thing I don't get was that is the direct command from their
> buildit page.
If they did not specify a --no-config option, their buildit page
> The thing I don't get was that is the direct command from their
> buildit page.
is buggy.
Vincent Lefevre
Jan 26, 2021, 9:00:04 AM1/26/21
to
On 2021-01-26 07:36:46 -0500, Greg Wooledge wrote:
> On Tue, Jan 26, 2021 at 06:27:40AM -0500, Gene Heskett wrote:
> > The thing I don't get was that is the direct command from their buildit
> > page. You would think that would lead to such a common failure that it
> > would be documented.
>
> Nobody should have to guess that the reader has a custom ~/.wgetrc file
> with multiple non-default options set to "on". It is completely unfair
> to put the blame for this on the writers of documentation that involves
> downloading files.
Having non-default options in a .wgetrc file is the point of a
> On Tue, Jan 26, 2021 at 06:27:40AM -0500, Gene Heskett wrote:
> > The thing I don't get was that is the direct command from their buildit
> > page. You would think that would lead to such a common failure that it
> > would be documented.
>
> Nobody should have to guess that the reader has a custom ~/.wgetrc file
> with multiple non-default options set to "on". It is completely unfair
> to put the blame for this on the writers of documentation that involves
> downloading files.
.wgetrc file. :-)
But perhaps wget should not read a config by default. This is
what GNU grep did by no longer supporting GREP_OPTIONS: if a
user wants default options, he can create an alias (with a name
different from any common utility). For instance, for grep,
I have a "gr" alias: it is shorter to type and doesn't break
the default usage of grep (which may be needed in scripts and
in commands from documentation).
Celejar
Jan 26, 2021, 9:10:04 AM1/26/21
to
On Tue, 26 Jan 2021 14:51:30 +0100
Vincent Lefevre <vin...@vinc17.net> wrote:
> On 2021-01-26 07:36:46 -0500, Greg Wooledge wrote:
> > On Tue, Jan 26, 2021 at 06:27:40AM -0500, Gene Heskett wrote:
> > > The thing I don't get was that is the direct command from their buildit
> > > page. You would think that would lead to such a common failure that it
> > > would be documented.
> >
> > Nobody should have to guess that the reader has a custom ~/.wgetrc file
> > with multiple non-default options set to "on". It is completely unfair
> > to put the blame for this on the writers of documentation that involves
> > downloading files.
>
> Having non-default options in a .wgetrc file is the point of a
> .wgetrc file. :-)
>
> But perhaps wget should not read a config by default. This is
Or alternatively, build scripts that use standard tools should
Vincent Lefevre <vin...@vinc17.net> wrote:
> On 2021-01-26 07:36:46 -0500, Greg Wooledge wrote:
> > On Tue, Jan 26, 2021 at 06:27:40AM -0500, Gene Heskett wrote:
> > > The thing I don't get was that is the direct command from their buildit
> > > page. You would think that would lead to such a common failure that it
> > > would be documented.
> >
> > Nobody should have to guess that the reader has a custom ~/.wgetrc file
> > with multiple non-default options set to "on". It is completely unfair
> > to put the blame for this on the writers of documentation that involves
> > downloading files.
>
> Having non-default options in a .wgetrc file is the point of a
> .wgetrc file. :-)
>
> But perhaps wget should not read a config by default. This is
explicitly disable configuration file reading, e.g.:
wget --no-config ...
Celejar
David Wright
Jan 28, 2021, 11:10:05 AM1/28/21
to
On Tue 26 Jan 2021 at 06:27:40 (-0500), Gene Heskett wrote:
> On Tuesday 26 January 2021 04:47:27 Vincent Lefevre wrote:
> > On 2021-01-26 10:40:01 +0100, Vincent Lefevre wrote:
> > > On 2021-01-25 17:42:51 -0500, Gene Heskett wrote:
> > > > On Monday 25 January 2021 17:04:23 Greg Wooledge wrote:
> > > > > On Mon, Jan 25, 2021 at 04:07:33PM -0500, Gene Heskett wrote:
> > > > > > gene@coyote:~/src/build$ cd .. && wget -O opencv.zip
> > > > > > https://github.com/opencv/opencv/archive/master.zip Cannot
> > > > > > specify both -k or --convert-file-only and -O if multiple URLs
> > > > > > are given, or
> On Tuesday 26 January 2021 04:47:27 Vincent Lefevre wrote:
> > On 2021-01-26 10:40:01 +0100, Vincent Lefevre wrote:
> > > On 2021-01-25 17:42:51 -0500, Gene Heskett wrote:
> > > > On Monday 25 January 2021 17:04:23 Greg Wooledge wrote:
> > > > > On Mon, Jan 25, 2021 at 04:07:33PM -0500, Gene Heskett wrote:
> > > > > > gene@coyote:~/src/build$ cd .. && wget -O opencv.zip
> > > > > > https://github.com/opencv/opencv/archive/master.zip Cannot
> > > > > > specify both -k or --convert-file-only and -O if multiple URLs
> > > > > > are given, or
> > > > > > in combination with -p or -r. See the manual for details.
> > > > > > Usage: wget [OPTION]... [URL]...
> > >
> > > [...]
> > >
> > > > > Do you have a ~/.wgetrc file? If so, what's in it? If not,
> > > > > what's in your /etc/wgetrc file (other than comments and blank
> > > > > lines)?
> > > >
> > > > gene@coyote:~$ cat .wgetrc
> > > > no_parent = on
> > > > follow_ftp = on
> > > > recursive = on
> > > > reclevel = 20
> > > > convert_links = on
> > >
> > > Note that convert_links is -k and you have "recursive = on", which
> > > means multiple URLs. Then the use of -O on the command line explains
> > > the error.
> >
> > Actually the error message explicitly mentions -r, which is implied
> > by "recursive = on". So, as a summary, you simultaneously have the
> > equivalent of -k, -O and -r.
>
> The thing I don't get was that is the direct command from their buildit
> page. You would think that would lead to such a common failure that it
> would be documented.
Perhaps file a bug against that page. It appears that they were using
> > >
> > > [...]
> > >
> > > > > Do you have a ~/.wgetrc file? If so, what's in it? If not,
> > > > > what's in your /etc/wgetrc file (other than comments and blank
> > > > > lines)?
> > > >
> > > > gene@coyote:~$ cat .wgetrc
> > > > no_parent = on
> > > > follow_ftp = on
> > > > recursive = on
> > > > reclevel = 20
> > > > convert_links = on
> > >
> > > Note that convert_links is -k and you have "recursive = on", which
> > > means multiple URLs. Then the use of -O on the command line explains
> > > the error.
> >
> > Actually the error message explicitly mentions -r, which is implied
> > by "recursive = on". So, as a summary, you simultaneously have the
> > equivalent of -k, -O and -r.
>
> The thing I don't get was that is the direct command from their buildit
> page. You would think that would lead to such a common failure that it
> would be documented.
-O merely to avoid overwriting master.zip with the second instance of
wget. The manpage expressly advises against doing that: "Use of -O is
not intended to mean simply "use the name file instead of the one in
the URL". They should just use mv after each wget to place the zip
files where they want them.
> And I went back thru the history and found some dependency fail this
> might have cause, and which synaptic won't let me fix, broken held
> packages but won't ident the clashes so they might be fixed. So I blew
> away my .wgetrc and am pulling fresh copies of both.
default, but rename it and then use it with --config= when appropriate.
Cheers,
David.
Greg Wooledge
Jan 28, 2021, 11:20:04 AM1/28/21
to
On Thu, Jan 28, 2021 at 10:06:25AM -0600, David Wright wrote:
> Perhaps file a bug against that page. It appears that they were using
> -O merely to avoid overwriting http://master.zip with the second instance of
> Perhaps file a bug against that page. It appears that they were using
> wget. The manpage expressly advises against doing that: "Use of -O is
> not intended to mean simply "use the name file instead of the one in
> the URL". They should just use mv after each wget to place the zip
> files where they want them.
If -O is bad, then what are you supposed to use instead?
> not intended to mean simply "use the name file instead of the one in
> the URL". They should just use mv after each wget to place the zip
> files where they want them.
If you need to "use mv after each wget", how do you know the name of the
file that wget used? And why can't you simply tell wget to use the
filename you *want* it to be written to? Why would you need to do this
weird two-step process?
Gene Heskett
Jan 28, 2021, 3:10:05 PM1/28/21
to
exists, wget should assume a bad copy was previously obtained, and
should then very cheerfully over write the existing file.
The full instructions apparently will only work with an old ubuntu
install, so needs updated for debian:
copy/paste from opencv install web page
---------------------------------
Build core modules
# Install minimal prerequisites (Ubuntu 18.04 as reference)
sudo apt update && sudo apt install -y cmake g++ wget unzip
# Download and unpack sources
wget -O opencv.zip https://github.com/opencv/opencv/archive/master.zip
unzip opencv.zip
# Create build directory
mkdir -p build && cd build
# Configure
cmake ../opencv-master
# Build
cmake --build .
Build with opencv_contrib
# Install minimal prerequisites (Ubuntu 18.04 as reference)
sudo apt update && sudo apt install -y cmake g++ wget unzip
# Download and unpack sources
wget -O opencv.zip https://github.com/opencv/opencv/archive/master.zip
unzip opencv.zip
unzip opencv_contrib.zip
# Create build directory and switch into it
mkdir -p build && cd build
# Configure
cmake -DOPENCV_EXTRA_MODULES_PATH=../opencv_contrib-master/modules ../opencv-master
# Build
cmake --build .
-------------------------
But while I've been thru that from square 0 several times, scrolling back
thru the history discloses many failures due to not finding stuff on
debian while doing the first cmake. Needless to say, I've not done any
install.
Blowing all that way, and using git, gets me 476 megs of src, so
mkdir build && cd build,
then the configure line is next:
cmake ../opencv
But: I think I forgot to blow away the older build dir
I did, redone it, and now it almost works, but with lots of fails from
missing deps I cannot fix with synaptic.
And I apparently cannot run grep to properly detect the failed string
from the configure steps output, the
cmake ../opencv | grep -i failed -
command does not have any valid, contains "Failed" output. But the
scrollback has a dozen or more instances including a total failure for
anything related to gtk2+ or gtk3+
No use trying a build.
So I installed, with synaptic, as much of opencv as it would let me,
which excludes the -dev packages.
Now what, there is no trace of it in the menu's, anyplace.
I saw, on you-tube, opencv doing some great stuff in collaboration with
linuxcnc, like automatic edge finding by actually commanding the machine
to move, doing it very quickly at the machines top speed. We allready
have utilities that allow us to place a workpiece to be carved on the
machines table without regard to how square it is with the table as we
can rotate the co-ordinate map to match the workpieces orientation. But
finding those two locations to use as a reference either needs a very
expensive touch probe, or a camera and lots of fidgity teeny moves to
find those reference points. The camera can with this ability to move
the machine, reduce an half hours setup time using the $1000 probe to
find these reference points used for the correction calculations, to 2
or so minutes using the camera instead of the touch probe.
So, now that I have as much of it installed as synaptic allows, back to
the lcnc list to see if the needed additions to the lcnc *.ini file can
be shared.
Until then, lets put this thread to rest. wget was fixed by blowing away
my /home/me/.wgetrc
Brian
Jan 28, 2021, 4:00:05 PM1/28/21
to
On Thu 28 Jan 2021 at 15:02:47 -0500, Gene Heskett wrote:
> Until then, lets put this thread to rest. wget was fixed by blowing away
> my /home/me/.wgetrc
wget wasn't fixed, but your setup was. Now we can all live happily
> Until then, lets put this thread to rest. wget was fixed by blowing away
> my /home/me/.wgetrc
ever after. :)
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
even though it is urged on by the words of Ed Howdershelt and others.
No need for killing.
--
Brian.
David Wright
Jan 29, 2021, 12:00:05 PM1/29/21
to
On Thu 28 Jan 2021 at 11:10:48 (-0500), Greg Wooledge wrote:
> On Thu, Jan 28, 2021 at 10:06:25AM -0600, David Wright wrote:
> > Perhaps file a bug against that page. It appears that they were using
> > -O merely to avoid overwriting http://master.zip with the second instance of
> > wget. The manpage expressly advises against doing that: "Use of -O is
> > not intended to mean simply "use the name file instead of the one in
> > the URL". They should just use mv after each wget to place the zip
> > files where they want them.
>
> If -O is bad, then what are you supposed to use instead?
--no-config has already been mentioned by a couple of people.
> On Thu, Jan 28, 2021 at 10:06:25AM -0600, David Wright wrote:
> > Perhaps file a bug against that page. It appears that they were using
> > -O merely to avoid overwriting http://master.zip with the second instance of
> > wget. The manpage expressly advises against doing that: "Use of -O is
> > not intended to mean simply "use the name file instead of the one in
> > the URL". They should just use mv after each wget to place the zip
> > files where they want them.
>
> If -O is bad, then what are you supposed to use instead?
There's also -nc which makes the command fail if the output
file already exists. There's even --backups which can move
existing files out of the way. I think wget has options
enough for most people's taste.
> If you need to "use mv after each wget", how do you know the name of the
> file that wget used? And why can't you simply tell wget to use the
> filename you *want* it to be written to?
screen. When writing a script, one might check for a pre-existing
file (before) or discover the new file's name from stderr (after).
I looked at the instructions in question at
https://docs.opencv.org/master/d7/d9f/tutorial_linux_install.html
and it wasn't clear to me whether the Code examples were designed
as Instructions to follow or Scripts to cut/paste.
> Why would you need to do this
> weird two-step process?
but puts cd foo || exit in a script; or trains one's fingers
to type "mv -i" and "rm -i" as a matter of habit.
BTW I downloaded one of the files Gene mentioned by typing
$ wget https://github.com/opencv/opencv/archive/master.zip
and ended up with master.zip.1 because I had downloaded an
unrelated project from git 3 weeks ago. Renaming was the
usual result of relying on wget's reasonable defaults.
Cheers,
David.
David Wright
Jan 29, 2021, 12:30:05 PM1/29/21
to
On Thu 28 Jan 2021 at 15:02:47 (-0500), Gene Heskett wrote:
> On Thursday 28 January 2021 11:10:48 Greg Wooledge wrote:
> > On Thu, Jan 28, 2021 at 10:06:25AM -0600, David Wright wrote:
> > > Perhaps file a bug against that page. It appears that they were
> > > using -O merely to avoid overwriting http://master.zip with the
> > > second instance of wget. The manpage expressly advises against doing
> > > that: "Use of -O is not intended to mean simply "use the name file
> > > instead of the one in the URL". They should just use mv after each
> > > wget to place the zip files where they want them.
> >
> > If -O is bad, then what are you supposed to use instead?
> >
> > If you need to "use mv after each wget", how do you know the name of
> > the file that wget used? And why can't you simply tell wget to use
> > the filename you *want* it to be written to? Why would you need to do
> > this weird two-step process?
>
> for a change, I am 100% with Greg W., in fact, if the file already
> exists, wget should assume a bad copy was previously obtained, and
> should then very cheerfully over write the existing file.
No thanks. (And it doesn't do that.) But then, I don't spend my
> On Thursday 28 January 2021 11:10:48 Greg Wooledge wrote:
> > On Thu, Jan 28, 2021 at 10:06:25AM -0600, David Wright wrote:
> > > Perhaps file a bug against that page. It appears that they were
> > > using -O merely to avoid overwriting http://master.zip with the
> > > second instance of wget. The manpage expressly advises against doing
> > > that: "Use of -O is not intended to mean simply "use the name file
> > > instead of the one in the URL". They should just use mv after each
> > > wget to place the zip files where they want them.
> >
> > If -O is bad, then what are you supposed to use instead?
> >
> > If you need to "use mv after each wget", how do you know the name of
> > the file that wget used? And why can't you simply tell wget to use
> > the filename you *want* it to be written to? Why would you need to do
> > this weird two-step process?
>
> for a change, I am 100% with Greg W., in fact, if the file already
> exists, wget should assume a bad copy was previously obtained, and
> should then very cheerfully over write the existing file.
time "nuking" files on my system.
> […]
> But: I think I forgot to blow away the older build dir
> Until then, lets put this thread to rest. wget was fixed by blowing away
> my /home/me/.wgetrc
At first glance, it looked like a reasonable file to use with --config=,
on the right occasions.
Cheers,
David.
rhkr...@gmail.com
Jan 29, 2021, 12:40:05 PM1/29/21
to
On Friday, January 29, 2021 12:20:21 PM David Wright wrote:
> On Thu 28 Jan 2021 at 15:02:47 (-0500), Gene Heskett wrote:
> > for a change, I am 100% with Greg W., in fact, if the file already
> > exists, wget should assume a bad copy was previously obtained, and
> > should then very cheerfully over write the existing file.
>
> No thanks. (And it doesn't do that.) But then, I don't spend my
> time "nuking" files on my system.
+1
> On Thu 28 Jan 2021 at 15:02:47 (-0500), Gene Heskett wrote:
> > for a change, I am 100% with Greg W., in fact, if the file already
> > exists, wget should assume a bad copy was previously obtained, and
> > should then very cheerfully over write the existing file.
>
> No thanks. (And it doesn't do that.) But then, I don't spend my
> time "nuking" files on my system.
0 new messages