Attached you will find an ebuild and changelog for camstream 0.26.2. Camstream
is a program for acessing v4l video devices, with added features for phillips
I suggest media-video/camstream for final placement. This ebuild depends on qt,
png and jpeg libraries.
Created attachment 6901 [details]
Created attachment 6902 [details]
Changelog for camstream-0.26.2.ebuild
Created attachment 6903 [details]
camstream-0.26.2.ebuild - fixed and working
Fully tested with emerge. Fixed bad install locations by explicity installing
files in ebuild.
seems this is a duplicate of my #10777 - they are a bit different, though. The
dependencies... and you have workarounds for problems I did not have and vice
*** Bug 10777 has been marked as a duplicate of this bug. ***
I didn't have any of the problems I saw with your ebuild. I know mine worked
fine on mystem after ignoring the Makefiles during install, although this might
cause some problems later if it's not updated properly and there are new files
in the next version.
The dependancies are from the configure script and are autodetected. They don't
really need to be there but I thought it was in good form to just have them. I
would think that either png or jpg are needed for the configure script to work
properly so it might be a good idea to inform the user that one of them has to
be installed. It don't know how maybe people have such a meager system that
*wouldn't* have those libraries, but it could be good to just in case.
It looks like the other bug has been marked duplicate so I could add this to
mine and resubmit if requested.
About your version:
I don't see any paths to uic or moc at all in configure which you try to fix in
your unpack function.
In src_install you don't install the caminfo and ftpput binaries. Why?
If we think that /usr/share/camstream/ is a fine place for the icons (without
the program version), we can just drop the unpack function completely.
I think your $RDEPEND is simply wrong - if someone installs a binary package, it
will not even require the Qt library. I doubt this would work :-)
About the $DEPENDS - Qt >= 3 already requires jpeg and png support. And, btw, I
think the entries you made without using them later are completely useless -
correct me if I am wrong.
About the $KEYWORDS - have you verified that it does not work for ppc, sparc or
alpha? If no, I would suggest "~x86".
So, here's my next try - it works fine for me, please verify.
Created attachment 7082 [details]
My next try
I still have a problem with /usr/local/bin/moc and /usr/local/bin/uic. Are we
working from the save version of the code? My ebuild is for 0.26.2.
I've added caminfo and ftpput to the dobin lines. It seems I just forgot them.
I guess I screwed up with the RDEPEND line. It has been removed and all deps
have been put into the DEPEND line since RDEPEND defaults to that. I haven't
written an ebuild for a while so I guess I missed that.
Keywords have been fixed as well. That was left over from a template I was
copies the original ebuild from I think.
I'm submitting a new verion with these fixes after this message is posted.
Created attachment 7090 [details]
fixed missed install binaries, DEPEND and KEYWORDS
Did you really read my comments the last time and have a look at my version of
1. I think the IUSE and DEPEND are still wrong. You do not check for any USE
variables, so you should not put them into IUSE.
2. You are having a problem with wrong paths found by configure? Then, please,
tell me where they come from. I don't have this problem. What is the error
message you get when you don't provide an own src_compile function?
I don't find the text you try to replace by sed.
kursawe@zaphod kursawe $ tar xzf /usr/portage/distfiles/camstream-0.26.2.tar.gz
kursawe@zaphod kursawe $ cd camstream-0.26.2
kursawe@zaphod camstream-0.26.2 $ grep uic configure
kursawe@zaphod camstream-0.26.2 $
3. The LICENSE should be GPL2, I think. The program links with libccvt which is
GPL2, so it must have this license, aswell, as far as I understand the GPL.
4. the DEPEND should have a "*" at the end, at least according to
Could you please state precisely where your problems are when you take my
ebuild, put it into your portage tree, create the digest and emerge it?
Yes, I did read your comments in the last message and attempted to use your ebuild. It failed the same way that mine did the first time I tried it. Look at the files in camstream-0.26.2/camstream after you unpack it. You can see that I'm fixing the files in there, which is where the ebuild fails on my system. I only have qt installed on my system to use this program (which my ebuild installed as a dependancy), but maybe you have uic and moc in /usr/local/bin so you aren't getting a failure at that point. I just used freedist for the license as I couldn't find a COPYING or LICENSE file in the source. I'll put it as GPL-2 since you pointed that out. I can't do much more now since I'm at work, but I'll update some more things. I didn't know about that policy document that you pointed out and I'll read that closely and fix up the ebuild tonite.
Created attachment 7108 [details]
"works for me and I think it's correct" camstream ebuild
This is my final submission of this ebuild. If you still think it's incorrect
please fix it to your liking. It works for my system fine and installs
everything correctly as far as I can tell. As for the DEPEND and IUSE flags,
they seem correct to me, although I can't seem to get a concensus on what
should be in IUSE from the gentoo-dev list.
Hope this is fine and any fixes are appreciated.
Ok, so you were talking about that configure script below the camstream
directory, not that in the main one... got that wrong, sorry, reading can be
What is your $PATH? The configure script you are complaining about searches for
moc and uic in different locations and, in the line you "fix", it sets the path
to /usr/local/bin/... just if it did not find them in any of those locations.
On my system, it finds them in the right place:
checking how to run the C++ preprocessor... g++ -E
checking whether gcc needs -traditional... no
checking for moc... /usr/qt/3/bin/moc
checking for uic... /usr/qt/3/bin/uic
checking location of Qt header files... /usr/qt/3/include
checking location of Qt library... /usr/qt/3/lib
It searches in the following places:
so - do you have any idea why it does not find them on your system?
About the rest:
I think the IUSE is still wrong. There should be only USE flags you actually
check for, nothing implicit. If you don't think so, have a look at other
ebuilds, like that of qt-3.1.1.
In the DEPEND, according to the policy document we should use a * at the end.
I am just wondering why I can't find something like that on ebuild(5)?
econf needs no "|| die"
Why don't you use emake instead of make? Did you experience problems with
My summary: When you change GPL2 to GPL-2 in my ebuild, it is IMNSHO fine. Looks
like your personal problem that uic and moc are not found - I tried my ebuild on
two different machines and had no problem. Neither of them had moc or uic in
The configure script can't find moc and uic on my system because the default install location for the qt ebuild that installed on my system is /usr/qt/3. I'm not sure about older qt versions, but I looked at /etc/profile.env and there was the variable QTDIR defined, which I assume is defined for all versions of of qt which points to the root of the install so that's what I replaced the /usr/local/bin/ paths of the configure script with. From your email it looks like you think I'm doing it the other way around, but it's early and I just woke up so I might be seeing things backwards too :) Look at bit closer at the sed commands and you will see that's what I am doing. From the email I sent to gentoo-dev, some people say I use only contains optional features the package uses (and not required) some say it contains all features the package uses. From what IUSE *will* be used for, it seems to me that it should contain all of them, since it will be used to recompile packages after the USE flags change. So if a person had -png later, emerge will search for any package which has IUSE="png" in it and rebuild that package. For required packages they are already listed in DEPEND so the package should be rebuilt automatically since that dependancy information is already there and wouldn't have to be listed again. I couldn't see which * at the end of the depend line you are talking about. Do you mean at the end of the package names in DEPEND or a single * at the end of DEPEND? Maybe you can point out which section/line of the policy document says that. I use make instead of emake after the parallell build failed. I don't think this is a problem with my machine as I attempt to only use ebuilds for installed packages and only installed qt as a dependancy for this ebuild (ie. it installed when I tested this ebuild). I would think my system is as stock as it can get for a gentoo distribution. I've written and have a few ebuilds in gentoo already so I can say I know how to write them, but your scrutiny has made me look closer at things. One thing I can think is that you might have installed qt from source without using the ebuild, which is why you don't have a problem finding moc and uic due to the fact old versions might be left over in the /usr/local/bin directories.
I can only repeat the last thing I told you:
"I tried my ebuild on
two different machines and had no problem. Neither of them had moc or uic in
About the IUSE... maybe that's ok for png and maybe jpeg, but for glibc and qt?
Definitely not. That's what dependencies are for, that is nothing optional.
The "*" - that refers to the first paragraph of 2.2 of the policy document.
btw, it would be very nice if you could use a line feed from time to time when
About the path-to-moc problem: Hey, of course I had a look at the
camstream/configure, where else do you think did I get the search path this
script checks from? And it already checks $QTDIR/bin, even if you don't patch
anything. I have no idea why it breaks on your system, I don't see any reason
for it. Have a close look at the source of the configure script and please tell
me what I did not see :-)
There must be a reason for that, even if I fear it will be a "funny" one.
put my version into CVS, try to attract testers :-)
Closing this as WORKSFORME
Burton, I finally found out why uic/moc were not found. See bug 31940.