Sorry for that :/ I'm merging stuff from shr/merge branch where its already used and it sliped through. Should I commit SRCPV->SRCREV now, or is it ok for now as there is also DEFAULT_PREFERRENCE = -1

Hi again.. there is more SRCPVs in stuff I merged.. (which weren't probably built before and hopefully aren't built now) Do I have to kill all SRCPV there? .. bitbake patches are prepared, waiting for

* there was ${WORKDIR}} * zone.tab, iso1366.tab is removed in eglibc/eglibc-package.bbclass --- recipes/tzdata/tzdata.inc | 13 ++++++++++--- recipes/tzdata/tzdata_2009s.bb | 3 +++ 2 files changed, 13

Even better fix for builders with BB_GIT_CLONE_FOR_SRCREV enabled.

As Bernhard probably hasn't old archive I tried it here /home/downloads/OE/SDL_mixer-1.2.9 $ ls -lR > lslR.txt /home/downloads/OE/SDL_mixer-1.2.9 $ cd ../SDL_mixer-1.2.9.new/ /home/downloads/OE/SDL_mi

* After 29c7d3351f43678c6e93b707b301832009f64b31 modules are not in install directory but in package, packages-split * modules*.tgz is created BEFORE this, so it contains non stripped modules * for mo

* Change name of old modules*.tgz file to modules*-dbg.tgz * Run do_strip_modules in PKGDEST for every package and then in PKGD, from where .tgz will be created, just because I haven't found where do_

I haven't found any notice about SDL_mixer on that news link (only SDL_image-1.2.9), Refreshed date on sources, can be sort of bug fix even without actuall source change, ie if Makefile don't want to

Again yes! that's what is written bellow line: SDL_image 1.2.9 has been released with a quick bug fix for Mac OS X and iPhone: So what you just copy&pasted is changelog between SDL_image-1.2.8 and SDL

After longer IRC discussion with mwester I was persuaded to write some summary of what SRCPV do and what's bad on SRCPV+BB_GIT_CLONE_FOR_SRCREV combination. SRCPV usage in svn recipes is safe, because

Sorry, I didn't intend to make all srcrevs in sane-srcrevs.inc. I should write it a bit longer: "should have some hash stored somewhere ie in sane-srcrevs.inc (which is included probably in all sane d

RP or someone else: What do you think about proposed implementation? Another table with localcount for every revision built, not only for last one. And table with last revisions with branch and machin

No if you're using LOCALCOUNT_OVERRIDE Yes if you're using AUTOREV without SRCPV. What about enabling LOCALCOUNT_OVERRIDE by default. Nothing change for everybody (only harmless constant '0+' in PV).

Why do you need to change PV,PR if you bump LOCALCOUNT? I see only 1 step in one place (SRCREV+LOCALCOUNT in sane-srcrevs or recipe). And as long as its in the same file, it can be a bit less error-pr

But this isn't any worse with SRCPV or is it? Now you need to bump SRCREV *and* PR with every SRCREV change unless PV changed. And SRCREV *and* PV if PV changed (maybe you also reset PR). With LOCALCO

Sorry, we discussed it with RP and after previous patches of this bbclass it looked clear to me. But if you look only on this last commit it is not clear at all. First do_deploy was called in ${D} dir

Hi, just out of curiosity, does your opkg also ship with update-alternatives script included in package? Haven't you problem with it, ie not respecting virtual/update-alternatives set for distribution

I'm not sure what update-alternatives-dpkg in OE does different grep -R virtual/update-alternatives conf/distro shows only mamona.conf using dpkg Even with fixes merged upstream we should block instal

Did you remove 'r' intentionally or is it a typo? I was trying to make svnr consistent in OE tree and only few recipes were using svn without 'r' http://cgit.openembedded.net/cgit.cgi/openembedded/com

I would like to create new file conf/distro/include/sane-providers.inc where we could store all default providers. Every distro should include this file and probably should drop own PREFERRED_PROVIDER