41 replies to this topic

[popeye2]

Hi,
I understood. You will not have time and leisure to support obsolete images, I fully agree.

I don't know if open source allows revocation of old sources. At least some commercial projects may rely on availability of these releases (and made their changes themselves public available)- what will happen if if they just linked the foreign sources , e.g. from openpli, and it would not be possible to build their (modified) image any longer?.
For (afaik) non commercial projects like openpli it is pretty easy, to revoke their code (and link their sources to third party code repositories). For open souce STB community it isn't a pleasure. And commercial projects will not diclose their GPLed modifications, when the original sources are not available any longer, as well. So it will run into a vicious circle.
So please, keep the code. Marking it obsolete is a good idea, however.

@mrk72 what package do you miss?

[pieterg]

The code is always kept, we're using git as you found out.

So if you fix all git revs, instead of using AUTOREV, you can build an exact replica of an old image.
But you'd have to gather some knowledge about openembedded and bitbake in order to be able to do that.

[WanWizard]

And commercial projects will not diclose their GPLed modifications...

All projects, commercial or otherwise, HAVE to disclose their modifications, it is required by the GPL license.

[popeye2]

Hi,
is there a chance to find a suitable git hash version, when the recipe (obviously) is using latest version (for unstable release) instead of hashed version (for stable release I try to rebake)?. There are tons of openpli2 binaries out there, but do they have a log of used sources packages and revisions?
thanks

[MiLo]

Here's an online log. Just click to the version you want, and fill in its revision hash as SRCREV in the include file that sets all the revisions.
http://openpli.git.s...igma2;a=summary

But that's just the technical answer to your question. It would help a lot if you'd just explain what you are trying to accomplish, and what you want to use.

[popeye2]

Hi,
in a first step I want to reproduce an image from sources for vuplus duo, along with understanding what the tools are doing. For the future I have not decided yet to build my own modifications, or just testing new ideas. My last sw development experience is ~10 years ago, so not to become rusty, I'm here

[popeye2]

To precise my question, given e.g. a stable binary published openpli release, how can I find all associated source revisions? Is there a release note ("nightly build from May xx, 2012, using latest sources or tagged sources from xx.yy.zzz" ...).
I only know CVS, which allows main development tree and release (tagged) branches. I don't see it up to now in GIT. But maybe I do not have enough knowledge about GIT yet ...

Edited by popeye2, 14 May 2012 - 20:11.

[pieterg]

git commit hashes are contained in the package versions, so if you have the image (or feed) you can reconstruct it.

If you don't, you have to check the commitlogs, and find the latest commit for a certain date.
Only for the limited number of AUTOREV packages of course.

But if you ask me, not worth the trouble.

[popeye2]

>But if you ask me, not worth the trouble.

Yes, we had the discussion above and probably you're right. It is my way of learning by doing by fighting it out. So I did neither consider broken source repos, nor auorev build instructions.Always thought of tagged (and fixed) versions to build an image, tested etc. (as it might be in commercial Linux builds like Suse or Debian) ...I learned now it is a constant work in progress...

[pieterg]

yes, for an automatic daily build, you really want to use AUTOREV.

[MiLo]

in a first step I want to reproduce an image from sources for vuplus duo, along with understanding what the tools are doing.

Just start with the "master" branch and build from that. At least you can be pretty sure it will actually deliver something. With the obsolete 2.0 branch you'll spend many a day hunting for source packages that have been removed from their sites and similar problems that won't help you learn anything...

[popeye2]

Hi,
I tried to find out all autorev recipes with this command

popeye2@naegele-pc:~/src/pli/openembedded/recipes> find .|xargs grep "inherit gitpkgv"
./libdreamdvd/libdreamdvd.bb:inherit gitpkgv
./aio-grab/aio-grab.bb:inherit gitpkgv
./dreambox/gst-plugin-dvbmediasink.bb:inherit gitpkgv
./enigma2/enigma2.bb:#inherit gitpkgv
./enigma2/enigma2-skins.bb:inherit gitpkgv
./enigma2/enigma2-plugins.bb:inherit gitpkgv
./tuxbox/libtuxtxt.bb:inherit gitpkgv
./tuxbox/tuxtxt-enigma2.bb:inherit gitpkgv
./openpli/hotplug-e2-helper.bb:inherit gitpkgv
./openpli/enigma2-plugin-skins-magic.bb:inherit gitpkgv
./openpli/usbtunerhelper.bb:inherit gitpkgv
./openpli/enigma2-plugin-extensions-xmltvimport.bb:inherit gitpkgv
./openpli/enigma2-pliplugins.bb:inherit gitpkgv
./ambx/python-pyambx.bb:inherit gitpkgv
./ambx/enigma2-plugin-extensions-ambx.bb:inherit gitpkgv
./ambx/ambx.bb:inherit gitpkgv
[1]+  Terminated			  find . | xargs grep inherit

Given this, a lot of recipes need to be fixed to a special git hash instead of "latest"
arghhh...

ok, try 2.1 Makefile

Edited by popeye2, 15 May 2012 - 08:50.

[pieterg]

well, only a hand full of the 1000+ packages, wouldn't call that a lot
BTW don't forget the svn packages.
Just check the conf/distro/include/unstable-openpli-versions.inc

Edited by pieterg, 15 May 2012 - 09:15.

[popeye2]

a few packages cause a lot of hand work ...

BTW. where i can find latest makefile 2.1? I see there are 8 pages in this forum pinned at the top, and some attached Makefile mods. So where to start?

Edited by popeye2, 15 May 2012 - 11:41.

[blzr]

here you go:
http://openpli.svn.s...le-2.1?view=log

[pieterg]

I see there are 8 pages in this forum pinned at the top, and some attached Makefile mods. So where to start?

http://openpli.org/f...post__p__274469

[popeye2]

Thanks.
I'm missing make clean ...
Installing Makefile in same dir as Makefile 2.0, nothing happens, but a few echos. And there is no make clean in Makefile-2.1.
Something like

:clean
rm -f ./bitbake; rm -f build*; rm-f ./cache; rm -f ./openembedded

would help ...

[MiLo]

It isn't a true Makefile anyway, it's just a bunch of shell scripts. The actual building is done by Bitbake, not make.

[popeye2]

sure.
But the recipes weren't updated when upgrading from Makefile 2.0 to 2.1.
So just a piece of user friendlyness to add ...

Edited by popeye2, 15 May 2012 - 19:59.

[popeye2]

Hi, Makefile 2.1 worked for me during the night,
but it failed building the image.
What packet do I miss? Is there a Linux zip-command available?

| /home/popeye2/src/pli/build-vuduo/tmp/work/vuduo-oe-linux/openpli-enigma2-image-1.0-r0/temp/run.do_rootfs.11294: line 111: zip: command not found

thanks