how to get xvidcap functioning under porteus

[Slaxmax]

@slaxmax and wread:
Do you mean that you did not have to add dependencies at all under kde?

Exactly

[wread]

Genau!

[phhpro]

...

[francois]

Genau!

Ah! Précisément! Je comprends. Merci.

[phhpro]

...

[Ahau]

Francois,

Did you try re-downloading the package? I just tested it in 2.1 XFCE and it seemed to work fine. I'm wondering if maybe you got a partial download. The error message you got at first, "bash: /usr/bin/xvidcap: No such file or directory" is an odd one, because xvidcap would have to be present in the $PATH before bash would know to call xvidcap from /usr/bin/xvidcap. I've seen this very error when compiling stuff for ARM when I mix binaries compiled for incompatible architectures, which I believe is why fanthom started off his post asking if you were running a 64-bit package on a 32-bit system (or vice versa). This is not a QT dependency issue nor a GTK2 vs 3 issue (xvidcap is a gtk2 program, and gtk2 is included in all editions of porteus).

If re-downloading and installing the package doesn't work, give us the output of the following:

ldd /usr/bin/xvidcap

and

file /usr/bin/xvidcap

ldd is short for "list dynamic dependencies" and will tell us if there are any missing libraries. file will tell us what kind of a file this is, e.g.:
/usr/bin/xvidcap: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped


As fanthom said, it's better to compile from source against the current system to ensure compatibility. Compiling is not as daunting as it seems at first, and won't require the level of depth that phpro explained above, with looking at each library on an individual basis (that will undoubtedly teach you more about your system and allow you to create smaller and more customized modules but it's not necessary to get started with compiling). I wouldn't start with xvidcap as it's old source code, there's no slackbuild on SBo; the one I found was from alienbob in 2008 and would require patching to work with the newer glib. If there's interest in this package, I could put together a patch for it; I think folks have moved more to recordmydesktop or some other software for screen capture.

[fanthom]

Porteus gives you a power to organize your modules as you want. unfortunately this ability is it's curse at the same time (which is proven in this and many other threads) as unexperienced users are mixing ARCHs and REPOs then posting on the forum that something doesn't work.

i have an idea for next release: lets get rid of modules totally and stick to installpkg+save.dat. no activate/deactivate and every installatoion done through PPM. this way users wont be able to mess with xzm's and everything will just work like on every other linux distros.

[donald]

i have an idea for next release: lets get rid of modules

I hope this is a joke, right?

[wread]

@fanthom
Or better, why not building in an "arch-key" similar to permissions rwx? So a module would have kmrlx-code for kde, mate, razor, lxde and xfce? I would call it Porteus-Permissions. If the module fits all DE's, the Porteus Permission would be 1+2+4+8+16=31, if it runs only in kde it would be 16, etc. By activation, a warning would be given, if no DE match is present.

RFC....

[brokenman]

lets get rid of modules totally and stick to installpkg+save.dat

Advantages of modules
They mount quickly. They autoload on boot when we want.

Disadvantages of modules
We rely on (sometimes buggy) aufs.
It's format is only relevant for a few distros.

Advantages of .txz
They are installed and not mounted.
Better reliability and no whiteout files.
It opens up the entire slackware database of packages instantly.

Disadvantages of .txz
They don't load during boot
It would require a substantial rewrite of much of the porteus code.

Perhaps another thread should be started.

[francois]

Sorry for not coming back fast enough. I get my work week done in the first four days (mon-thur). Beside coming furtively on the forum these days, I cannot accomplish much. I was quite occupied this week.

I love porteus modules. I find them more simple to use than any other package system would they be as sophisticated as apt-get or pacman.

I have built some modules and installed porteus packages in different ways during my linux carreer (hum). I began in 2005. But it is just that I did not built bigger packages very often. One reason is that I am more of the conceptual type. Thus I used to be very good at mathematics, but really weak in accounting. To work linux you have to be very much focused and patient. Small errors will just beat you.

Fanthom with its first intervention just anwer my interrogation, and all the other have supplemented with interesting information that helped me reflect on package building.

Thanks to you all.

[phhpro]

...

[francois]

@phhpro:
Thanks for these deep thoughts. It is as if you have been working with porteus or its antecedent all your life.

[phhpro]

...

[francois]

Maybe you should tell us more about it here:
http://forum.porteus.org/viewtopic.php?f=48&t=408