| Age | Commit message (Collapse) | Author | Files |
|---|
|
|
|
* This helps uclibc systems where ldconfig is optional, in particular 3rd-party
systems like OpenWRT.
* Per RFC on the list.
|
|
packages this doesn't change much but for cross/sdk/native packages the distinction is important (from poky)
|
|
whole functionality ideally needs rewriting but this fixes various important issues with SDK generation
|
|
Also replace long since unused old_shlibs_dir (from poky)
|
|
version from bitbake now
|
|
the package task doesn't create chains of .debug directories (from poky)
|
|
ASSUME_PROVIDED.
* List of <shlib_file_name>:<package>[_<version>] mappings. This info will
be appended to one inferred by automatic shlib tracking code. So, it would be
possible to have correct package dependencies even for libraries in
ASSUME_PROVIDED.
|
|
functionality in a multimachine safe way instead (from poky).
|
|
packaged function from base.bbclass rather than our own (from poky)
|
|
using ALLOW_EMPTY instead of ALLOW_EMTPY_pkg (from poky)
|
|
- do not transform a symlink to a directory into a directory on copy
- preserve the mode when copying a directory
|
|
of moving files (from poky). The copyfile function will be moved to bitbake in due course.
|
|
New file: packages/mono/mono-mcs-intermediate_1.2.5.1.bb
Compiles mono in native mode with standard prefix, then tars up the
resulting tree and puts the tarfile into staging
New file: packages/mono/mono_files.py
Automatically generated using collect-path.py (attached to this mail)
and contains a list that maps file patterns to package names (and
contained assemblies, see below).
New file: classes/mono.bbclass
Has a helper function for the list that maps file patterns to package
names and assemblies (see below). Also has a function mono_do_clilibs
and inserts that function into PACKAGEFUNCS. This function calls
mono_find_provides_and_requires which finds out (through calls to
monodis --assembly and monodis --assemblyref) which assemblies are
provided and required by a particular package. mono_do_clilibs then
puts the information about provided assemblies into
${STAGING_DIR}/clilibs/${packagename}.list and information about the
required packages into ${PKGDEST}/{packagename}.clilibdeps where it
will later be picked up by the modified read_shlibdeps.
Originally I had dependency resolution through the partial list in
mono_files.py but obviously this doens't scale, so I implemented the
new method with mono_do_clilibs. The benefit is now that I don't really
need the extra information in mono_files.py anymore and can in
principle get rid of mono_get_file_table and related code. Instead it
should be possible to modify collect-paths.py to output bitbake .inc
code (e.g. PACKAGES = "..." and a whole lot of FILES_... = "...")
instead of python code. There's still the minor problem of how to
handle the .mdb files, that's why I didn't implement it yet but instead
opted for an approach that I knew would work. (Debian just puts
the .mdb files into the individual packages, while I would argue that
they do belong into corresponding -dbg packages.)
Modified file: classes/package.bbclass
In read_shlibdeps I folded the two identical code blocks dealing with
*.shlibdeps and *.pcdeps into one and added *.clilibdeps (generated by
mono_do_clilibs above).
Modified file: packages/mono/mono_1.2.5.1.bb
Add the mono-mcs-intermediate workaround. Add a whole lot of python
code in populate_packages_prepend in order to split up the packages
based on information from mono_files.py (via mono.bbclass'
mono_get_file_table). As I said above a lot of this code can hopefully
be replaced in the future.
|
|
up/optimise PACKAGES checks a bit
|
|
some unneeded complexity (from poky)
|
|
|
|
|
|
|
|
when multiple -dev or -dbg packages are generated and when a single one is generated (from poky)
|
|
|
|
certain dependency chainhandling in both ipkg and dpkg (from poky)
|
|
generate (PACKAGES != ) removing needless dependencies (from poky)
|
|
correct operation with bitbake 1.8.x. Old behaviour is maintained in a special legacy anonymous function in base.bbclass. The patch is an improved version of the one discussed on the mailing list.
|
|
|
|
- if package contain libraries which are not used outside then add PRIVATE_LIBS
variable with names of them to not generate shlibs for them.
|
|
"inherit package_ipk package_tar" and seems to interfere with do_split_packages
|
|
|
|
|
|
causing python
traceback spew during population
|
|
migration
|
|
|
|
I do not know does this is best way of fixing it but it is better to have it in
repository then having rootfs images without libc.
|
|
${HOST_PREFIX}objdump
package.bbclass : make use of the OBJDUMP variable rather than
calling ${BUILD_PREFIX}objdump inside do_shlibs. As the original
usage was faulty and ended up calling host objdump which works
for some arm targets but not all.
|
|
RRECOMMENDS, from Poky
* poky rev 823: 'package.bbclass: depchains: don't -destructively- set the pkg's RRECOMMENDS.'
* poky rev 824: 'base.bbclass: depchains: don't -destructively- set the pkg's RRECOMMENDS.'
|
|
packages. The way it selects the principle package name needs totally reworking as the current code is flawed but apply a workaround for now (this is unrelated to other changes to package.bbclass)
|
|
packages. The way it selects the principle package name needs totally reworking as the current code is flawed but apply a workaround for now (this is unrelated to other changes to package.bbclass)
|
|
then package_write which actually generates the packages. The two stage approach allows us to avoid circular dependency issues from classes like debian.bbclass. As the data being emitted into pkgdata/ changed, you need to either wipe tmp or rerun the do_package tasks (wipe the do_package stamps). Everything will repackage anyway due to the new task.
|
|
functional changes (from poky)
|
|
barfing
package.bbclass: likewise
|
|
* people should really watch out with introducing regressions
|
|
people are reporting
~lart kergoth for introducing this regression
|
|
* Add package "depchains". This facilitates, for example, ensuring that if
A depends upon B, then A-dev will RRECOMMENDS B-dev, and the same for the
-dbg packages.
|
|
other packages.
|
|
|
|
* Avoid premature use of the PKG_* variables. We don't need to make use of
the debian.bbclass (or otherwise) renamed package names until the very end
of the packaging. This was necessary in order to enhance my
depchain/correspondantdeps stuff, and doesn't seem to harm anything.
|
|
* Fix bug which caused non-detection.
* Make visible error message for such condition.
* But still recover and continue for now, while we don't
have all occurances fixed in metadata. Note that while
content of the package will be ok, metadata can be wrong.
So, recover behavior should not be relied upon, this going to
be fatal condition later.
Oked-by: RP, hrw
|
|
* Factor out "strippedness" substring as FILE_UNSTRIPPED_MATCH.
* Allow FILE_UNSTRIPPED_MATCH to be overriden, useful to support
other executable formats.
* Also, don't complain if .debug directory already exist
(can heppen if manually run BB tasks, e.g. for debugging).
|
|
Make legitimize_package_name also convert <U0123> style encoding of
unicode codepoints into their utf-8 representation, as in glibc locale
files.
|
|
|
