Slow is better than never

The package tvtime, (a debian package) is a software which displays tv from USB television tuners ( through V4L2 ). I wanted to make something that would allow me grab a few frames in sequence for those times when I am watching something and get called away to the phone. It is an old package and I think it hasn't been worked on since 2008 2005 ( except for debian package maintainers and unbuntu ). It compiles fine from source and even though it doesn't complain, it needs libxv-dev to actually compile and work without error, even though it doesn't grab that on a "sudo apt-get build-dep tvtime". It also has some alsa issues and that is what I am dealing with right now. The interesting thing that made me feel stupid and then immediately smarter is the fact that forever I have been doing "sudo apt-get source program" and then doing "sudo chown motey:motey -R program/". All of the sudden it occurred to me that perhaps I could just do "apt-get source program" and avoid that wasted step. How silly of me to have done this so many times.

I am not sure whether I am still being stupid, but I compiled tvtime and it runs but no sound, so I looked at the differences and it needed some patches. I applied the three ubuntu patches in the debian section, in the order of the file "series" and it did not complain. I configured (./configure) and did a make. It complained about missing some connections to audiolib.c which seemed odd, I tried a couple things and then just punted. I did "gcc -c audiolib.c" added "-lasound" to the final link, as well as "audiolib.o" it compiled and audio worked as expected, but it should have done that automagically if the patches were correct IMHO.

Audiolib.c uses printf to stdout for a message indicating connection between alsa and USB audio, but the rest of tvtime uses fprintf with stderr for messages. Not any big deal, just and inconsistency. It uses V4L2 to get frames. At the moment I am learning quilt as an extension to handling patches with patch and diff . I really want to know why the patches don't work and how it needs to be changed or documented, like "You must run configure after applying patches" or some such thing.

I suppose it is just compulsive behavior, but if the facility is there and I can't figure out how it is used, it is a puzzle to be solved. I have done debian packaging and understand that aspect, as well as make, automake, configure, gcc or g++, dependencies, and I18n, shell, Python, and many other dependent knowledge elements. The link to HolgerLevsen at debian seems it would contain some well structured information and so I will search that tree for some useful knowledge and background. My version of quilt is 0.48, and somebody ( from a Google search ) is looking at jumping to version 3?, That seems a bit odd. Running quilt from the debian directory of the downloaded source indicates the patches that would be applied , which come from the file patches/series. That make sense that they need to be applied in order as it would be a total f5g mess otherwise.

After some RTFM and "man quilt" ( that is a funny concept ), I see it is done by "quilt push -a", which applies the patches. You wouldn't to use the word apply here :). Anyway, it is too late to change the language or even argue about names as they are instantiated in too many minds as a dependency. I copied the patches directory to the base and applied, but it would seem that a relative path would suffice somewhere, but perhaps it isn't that elegant yet. Looking through the patches with kompare showed changes to Makefile.am, which seem to be correct to compile with the additions, and yet it doesn't work? I will probably use "make -d &>" and debug to see what it thinks it is doing. It seems to miss that -lasound and compile dependency and it shouldn't IMHO.

There is an Ubuntu packing guide that may provide some clues.

0 comments:

Automated Intelligence

Automated Intelligence
Auftrag der unendlichen LOL katzen