Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #231122 > unrolled thread

Re: problem with wget -O

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: problem with wget -O Roberto C. Sánchez <roberto@debian.org> - 2021-01-25 19:50 +0100
    Re: problem with wget -O Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-25 20:00 +0100
      Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-25 21:20 +0100
        Re: problem with wget -O Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-25 21:40 +0100
          Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-25 21:50 +0100
            Re: problem with wget -O Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-25 22:00 +0100
              Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-25 22:10 +0100
                Re: problem with wget -O Darac Marjal <mailinglist@darac.org.uk> - 2021-01-25 22:50 +0100
                  Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-25 23:40 +0100
                  Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-25 23:40 +0100
                    Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-26 00:00 +0100
                      Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-26 00:10 +0100
                    Re: problem with wget -O <tomas@tuxteam.de> - 2021-01-26 10:50 +0100
                      Re: problem with wget -O l0f4r0@tuta.io - 2021-01-26 13:40 +0100
                        Re: problem with wget -O <tomas@tuxteam.de> - 2021-01-26 14:50 +0100
                Re: problem with wget -O Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-25 23:10 +0100
                  Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-25 23:50 +0100
                    Re: problem with wget -O Vincent Lefevre <vincent@vinc17.net> - 2021-01-26 10:50 +0100
                      Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-26 12:30 +0100
                        Re: problem with wget -O Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-26 13:40 +0100
                          Re: problem with wget -O Vincent Lefevre <vincent@vinc17.net> - 2021-01-26 15:00 +0100
                            Re: problem with wget -O Celejar <celejar@gmail.com> - 2021-01-26 15:10 +0100
                        Re: problem with wget -O Vincent Lefevre <vincent@vinc17.net> - 2021-01-26 14:50 +0100
                        Re: problem with wget -O David Wright <deblis@lionunicorn.co.uk> - 2021-01-28 17:10 +0100
                          Re: problem with wget -O Greg Wooledge <wooledg@eeg.ccf.org> - 2021-01-28 17:20 +0100
                            Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-28 21:10 +0100
                              Re: problem with wget -O Brian <ad44@cityscape.co.uk> - 2021-01-28 22:00 +0100
                              Re: problem with wget -O David Wright <deblis@lionunicorn.co.uk> - 2021-01-29 18:30 +0100
                                Re: problem with wget -O rhkramer@gmail.com - 2021-01-29 18:40 +0100
                            Re: problem with wget -O David Wright <deblis@lionunicorn.co.uk> - 2021-01-29 18:00 +0100
                    Re: problem with wget -O Vincent Lefevre <vincent@vinc17.net> - 2021-01-26 10:50 +0100
      Re: problem with wget -O Nicolas George <george@nsup.org> - 2021-01-26 12:40 +0100
        Re: problem with wget -O <tomas@tuxteam.de> - 2021-01-26 13:20 +0100
    Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-25 21:10 +0100
      Re: problem with wget -O Roberto C. Sánchez <roberto@debian.org> - 2021-01-25 21:20 +0100
        Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-25 21:40 +0100
      Re: problem with wget -O deloptes <deloptes@gmail.com> - 2021-01-25 21:20 +0100
        Re: problem with wget -O Gene Heskett <gheskett@shentel.net> - 2021-01-25 21:30 +0100
          Re: problem with wget -O deloptes <deloptes@gmail.com> - 2021-01-26 00:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#231189

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
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).

-- 
Vincent Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#231190

On Tue, 26 Jan 2021 14:51:30 +0100
Vincent Lefevre <vincent@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
explicitly disable configuration file reading, e.g.:

wget --no-config ...

Celejar

[toc] | [prev] | [next] | [standalone]

#231188

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
is buggy.

-- 
Vincent Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#231234

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
> > > > > > 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
-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.

FWIW I would not leave such a potent set of options in .wgetrc as my
default, but rename it and then use it with --config= when appropriate.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#231236

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?

[toc] | [prev] | [next] | [standalone]

#231241

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.

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
wget -O opencv_contrib.zip 
https://github.com/opencv/opencv_contrib/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

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>

[toc] | [prev] | [next] | [standalone]

#231242

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
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)

As we have seen recently, a strong democracy can withstand the mob,
even though it is urged on by the words of Ed Howdershelt and others.
No need for killing.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#231271

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
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

Sorry, "blowing away", not "nuking".

At first glance, it looked like a reasonable file to use with --config=,
on the right occasions.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#231272

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

[toc] | [prev] | [next] | [standalone]

#231267

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.
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?

When running wget interactively, the name gets written on the
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?

For similar reasons that one types   cd foo   at the console,
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.

[toc] | [prev] | [next] | [standalone]

#231174

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.

-- 
Vincent Lefèvre <vincent@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)

[toc] | [prev] | [next] | [standalone]

#231181

[Multipart message — attachments visible in raw view] — view raw

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?

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#231182

[Multipart message — attachments visible in raw view] — view raw

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
rants with some concrete help, at the very least.

Cheers
 - t

[toc] | [prev] | [next] | [standalone]

#231132

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
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
        500 http://security.debian.org stretch/updates/main amd64 
Packages
        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.

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>

[toc] | [prev] | [next] | [standalone]

#231134

On Mon, Jan 25, 2021 at 03:00:40PM -0500, Gene Heskett wrote:
> 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
> 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
>         500 http://security.debian.org stretch/updates/main amd64 
> Packages
>         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?
> 
It looks like you are working way to hard and in the completely wrong
area.  As suggested by Greg, please provide the full command you are
attempting to execute and any output that results from it.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

#231141

On Monday 25 January 2021 15:10:35 Roberto C. Sánchez wrote:

> On Mon, Jan 25, 2021 at 03:00:40PM -0500, Gene Heskett wrote:
> > 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
> > 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 500 http://security.debian.org stretch/updates/main amd64
> > Packages
> >         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_cust
> >om_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/p
> >ython/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?
>
> It looks like you are working way to hard and in the completely wrong
> area.  As suggested by Greg, please provide the full command you are
> attempting to execute and any output that results from it.
>
The command is from that same web page:
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$

> Regards,
>
> -Roberto

Thanks Roberto.

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>

[toc] | [prev] | [next] | [standalone]

#231136

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
you complain, being not able to build the package :)

This python stuff is tricky, Gene, why are you doing this to yourself?

[toc] | [prev] | [next] | [standalone]

#231137

On Monday 25 January 2021 15:09:22 deloptes wrote:

> 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_cust
> >om_headers.h:7:0,
>
> Let me guess, you complained of wget trying to download the package
> and now you complain, being not able to build the package :)
>
> This python stuff is tricky, Gene, why are you doing this to yourself?

Because synaptic says what is it the debian repo's is 10 years old?


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>

[toc] | [prev] | [next] | [standalone]

#231156

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
the grave yard, no?
It would be cheaper to upgrade because if you upgrade at the end you will
have up to date system.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web