kergoth / bb Goto Github PK

Currently, the behavior is focused on what got pulled into the build, but it'd be equally useful for traversing the limited runtime dependency graph to determine why something got installed into a rootfs.

Right now, when you run with -R, it traverses all the runtime deps at each level, rather than only the rdeps of the rdeps. If we filter that to the latter, we could use the command to look into the install deps rather than just what's being built/packaged.

-h/--help generally shows argv[0], which includes the dash (bb-list) rather than what the user will actually run (bb list).

This should include aspects of the old dependinfo command from the previous bb implementation. That is, it should show more than just DEPENDS and RDEPENDS, but be able to emit information about all types of dependencies from a recipe.

This would allow a user to simply see recipe file locations, as well as enable the user to do something like: gvim $(bb recipe-files foo)

This allows more flexibility with the editor and how it's opened.

Another possible option: a new flag like "-a this-layer" to bb edit that will automatically create the properly named bbappend file under the requested layer and add it to the editor. This would be useful for the new sub-command 'recipe-files' as well.

Currently, the subcommands are fairly independent, and do most of their work in their own process. As a result, each subcommand run from bb-shell (our interactive mode) ends up reparsing recipes (though pulled from cache after the first).

To implement this properly, and also pursue further integration with bitbake, I think we should pursue pushing some of the more useful subcommands to bb.command, thereby passing off the work to a running bitbake server.

For example, I haven't built qt4-embedded and got the following output. Preferably we could check for .../packages-split first and give a helpful error message instead of aborting if the directory doesn't exist.

warp-3% bb contents qt4-embedded
Parsing recipes..WARNING: No recipes available for:
/mentor/src/meibp-2013/meta-mentor/recipes/lttng-2.0/linux-omap4_3.1.0.bbappend
/mentor/src/meibp-2013/meta-mentor/recipes/liburcu/liburcu_0.6.7.bbappend
/mentor/src/meibp-2013/meta-oe/meta-systemd/meta-efl/recipes-efl/efl/entrance_svn.bbappend
/mentor/src/meibp-2013/meta-oe/meta-systemd/meta-multimedia/recipes-multimedia/musicpd/mpd_0.17.1.bbappend
/mentor/src/meibp-2013/meta-mentor/recipes/samba/samba_3.5.6.bbappend
/mentor/src/meibp-2013/meta-oe/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend
/mentor/src/meibp-2013/meta-mentor/recipes/lttng-2.0/linux-imx_3.0.15.bbappend
/mentor/src/meibp-2013/meta-atp/recipes/fuse/linux-imx_3.0.15.bbappend
/mentor/src/meibp-2013/meta-atp/recipes/systemd/linux-imx_3.0.15.bbappend
/mentor/src/meibp-2013/meta-mentor/recipes/boot-format/boot-format_git.bbappend
/mentor/src/meibp-2013/meta-mentor/recipes/lttng-2.0/linux-qoriq-sdk.bbappend
done.
Traceback (most recent call last):
File "/home/mwbrown/sub-bb/libexec/bb-contents", line 75, in
bbcmd.run_main(main)
File "/home/mwbrown/sub-bb/libexec/bbcmd.py", line 263, in run_main
sys.exit(main(sys.argv[1:]) or 0)
File "/home/mwbrown/sub-bb/libexec/bb-contents", line 71, in main
return contents(args.recipe)
File "/home/mwbrown/sub-bb/libexec/bb-contents", line 51, in contents
for package in sorted(os.listdir(pkgdir)):
OSError: [Errno 2] No such file or directory: '/mentor/src/meibp-2013/build/tmp/work/mx6q-mel-linux-gnueabi/qt4-embedded-4.8.1-r55.1/packages-split'

Paul's rewritten tinfoil to work with a bitbake server resulted in breakage all over bb, as I relied on certain details of the implementation and made various assumptions based on that. The new one has a slightly different, more limited API due to the client/server architecture, so bb needs fixing to use that.

Ideally, this would accept either before or after runtime_mapping_rename, that is, it should obey the PKG variable.

I was super happy with bb until morty, but moved to pyro and it seems to be broken now.
e.g.

~/test/bb/bin/bb show DISTRO
Traceback (most recent call last):
  File "/home/genius/test/bb/libexec/bb-show", line 202, in <module>
    bbcmd.run_main(main)
  File "/home/genius/test/bb/libexec/bbcmd.py", line 310, in run_main
    sys.exit(main(sys.argv[1:]) or 0)
  File "/home/genius/test/bb/libexec/bb-show", line 198, in main
    return show(args)
  File "/home/genius/test/bb/libexec/bb-show", line 158, in show
    tinfoil = bbcmd.Tinfoil(output=sys.stderr)
  File "/home/genius/test/bb/libexec/bbcmd.py", line 34, in __init__
    self.localdata = self.cooker.data
AttributeError: 'NoneType' object has no attribute 'data'

Is this what you meant with your comment that most of bb is broken due to Tinfoil?

I guess it's a major effort to rewrite bb.
Is it dead?

Currently, it depends on the current layout of the repository, so would not run correctly when "installed", but there would be value in being able to package it up for distros.

My current thought is to diff the most recently written/modified sstate archives for a given recipe, or something similar, for when something was rebuilt and you suspect it shouldn't have been. Not ideal, I realize, since the most recent two archives might be from different machines, or similar, but something along these lines could be beneficial.

For developers working on a single image for extended periods, it would be handy to be able to specify a default scope (e.g. core-image-atp) for the sub-commands, possibly via env var. Within the bb interactive shell you could also have a command to set the scope (e.g. change from core-image-atp to core-image-base).

First, a non-recursive invocation:

$ bb whatdepends ncurses core-image-minimal
Parsing recipes..done.
virtual/update-alternatives
util-linux
attr
$

which seems to suggest there are three things that depend on ncurses: v/u-a (for brevity), util-linux and attr. But a recursive invocation is confusing, since it shows ncurses indented below v/u-a, and bzip2 coming out of nowhere and being displayed at the same level as ncurses:

$ bb whatdepends -r ncurses core-image-minimal
Parsing recipes..done.
virtual/update-alternatives
  ncurses
    util-linux
      mtd-utils
        u-boot-denx
      e2fsprogs
    attr
      acl
  bzip2
    pcre
      slang
        libnewt
          virtual/update-alternatives
            shadow
            module-init-tools
            kmod
              pciutils
$

It's as if ncurses depends on v/u-a and vice versa, which forces more output than you'd expect.

I know you are aware of this: [1] Just put this issue here for completeness. (and yes I would be happy to test a newer version)

I was hit by this bug from Jethro 2.0.1 to Jethro 2.0.2.
Currently investigating if there was really an upgrade to Python 3 from 2.0.1 to 2.0.2.
[1] https://www.mail-archive.com/[email protected]/msg31101.html

Should resolve this error:

$ bb whatdepends sysvinit
Traceback (most recent call last):
  File "/scratch/sandbox/bb/libexec/bb-whatdepends", line 8, in <module>
    import bbcmd
  File "/scratch/sandbox/bb/libexec/bbcmd.py", line 22, in <module>
    from bb.cookerdata import CookerConfiguration, ConfigParameters
ImportError: No module named cookerdata

I'm not happy with the output format, and I'm not convinced the ability to search both recipes and packages simultaneously actually adds any value anyway. Revisit possibilities for the output format.

When not in your build directory, bitbake explains:
Error: must run bitbake from under your build directory

However, bb only says:
The BBPATH variable is not set

It would be helpful to new users if the bb error were more like the bitbake error. :-)

bb list and bb search could use an option to cause the version info and/or filename (which usually contains version info) to be output along with the recipe name. Outputting the layer name with the filename would be handy too.

If more than one version is available within the given scope, this option should list all available versions of a given recipe (if possible).

From IRC conversation:

1. does the bb shell mode prevent the initial delay of the bb commands?

kergoth: right now it doesn't, since each command is a separate executable script, they don't share anything in memory. of course, after the first, it's pulling from cache, but there's still an extra delay, no performance benefit to the interactive mode right now. we need to think about how to fix that. one way would be to push more of the command handling back into the bitbake daemon process and let the commands use the bitbake server.

This should include both task level and recipe level build and runtime dependencies, as a reverse form of the to-be-implemented showdepends command. Some of the work done for bb-search should be useful for this.