Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fetch2: Add module for ClearCase (ccrc://) #6

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Denwid
Copy link

@Denwid Denwid commented Jul 17, 2014

BitBake 'Fetch' clearcase implementation

The clearcase fetcher is used to retrieve files from a ClearCase (http://en.wikipedia.org/wiki/Rational_ClearCase) repository.

Usage in the recipe:

SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module"
SRCREV = "EXAMPLE_CLEARCASE_TAG"
PV = "${@d.getVar("SRCREV").replace("/", "+")}"

The fetcher uses the rcleartool or cleartool remote client, depending on which one is available.

Supported SRC_URI options are:

  • vob
    (required) The name of the clearcase VOB (with prepending "/")

  • module
    The module in the selected VOB (with prepending "/")

    The module and vob parameters are combined to create
    the following load rule in the view config spec:
    load

  • proto
    http or https

Related variables:

CCASE_CUSTOM_CONFIG_SPEC
        Write a config spec to this variable in your recipe to use it instead
        of the default config spec generated by this fetcher.
        Please note that the SRCREV loses its functionality if you specify
        this variable. SRCREV is still used to label the archive after a fetch,
        but it doesn't define what's fetched.

User credentials:

When using cleartool:
        The login of cleartool is handled by the system. No special steps needed.

When using rcleartool:
        In order to use rcleartool with authenticated users an `rcleartool login` is
        necessary before using the fetcher.

Signed-off-by: Dennis Meier meier.dennis@siemens.com
Reviewed-by: Roger Meier r.meier@siemens.com
Reviewed-by: Christian Liechti christian.liechti@siemens.com
Reviewed-by: Henrique Mendonca henrique.mendonca@siemens.com
Reviewed-by: Pascal Bach pascal.bach@siemens.com

Signed-off-by: Dennis Meier <meier.dennis@siemens.com>
Reviewed-by: Roger Meier <r.meier@siemens.com>
Reviewed-by: Christian Liechti <christian.liechti@siemens.com>
Reviewed-by: Henrique Mendonca <henrique.mendonca@siemens.com>
Reviewed-by: Pascal Bach <pascal.bach@siemens.com>
kergoth added a commit to kergoth/bitbake that referenced this pull request Aug 11, 2015
commit 00ca441614695b4261d8d4f31b7ef0e3e3784282
Merge: 8cc367d bb88c0f
Author: Christopher Larson <kergoth@gmail.com>
Date:   Thu Aug 22 16:42:42 2013 -0700

    Merge pull request openembedded#6 from staticshock/multi-line-strings

    Remove "keepend" and "excludenl" directives

commit bb88c0fd4ad2b7b9c8c4c73def2b3cb20c473ac3
Author: Anton Backer <olegov@gmail.com>
Date:   Sat Jul 13 01:24:15 2013 -0400

    Remove "keepend" and "excludenl" directives

    It looks like these were never actually used correctly, and were doing
    more harm than good. "keepend" on bbString, for instance, prevented
    proper nesting of ${@python} in strings. Similarly, a balanced pair of
    { } braces inside a shell function would force the function to terminate
    early if the closing brace was on its own line.

    So far I've seen absolutely no negative consequences from removing
    these, but a bunch of positive consequences.

    Fixes openembedded#1

commit 8cc367d01f4c699be5fcc072de59e6f2f14a138b
Merge: c58628c eec6b7f
Author: Christopher Larson <kergoth@gmail.com>
Date:   Thu Aug 22 09:46:46 2013 -0700

    Merge pull request openembedded#4 from staticshock/function-names

    Parse function names with nested vars

commit c58628ca517cd25985361fc0d27863521cc28a5d
Merge: dfb0f7c a890982
Author: Christopher Larson <kergoth@gmail.com>
Date:   Thu Aug 22 09:43:40 2013 -0700

    Merge pull request openembedded#5 from yoyko/master

    syntax: python expansion (${@...}) inside shell functions

commit a890982b7c33a6e363b12d6cb69e22b4bbc0f317
Author: Jozef Šiška <yoyo@ksp.sk>
Date:   Thu Aug 22 13:20:45 2013 +0200

    syntax: python expansion (${@...}) inside shell functions

    Signed-off-by: Jozef Šiška <jsiska@nuvotechnologies.com>

commit eec6b7f6f0472787929f424968f9a0d78ac4af08
Author: Anton Backer <olegov@gmail.com>
Date:   Fri Jul 12 22:16:01 2013 -0400

    Parse function names with nested vars

    For instance, pkg_postinst_${PN}

    Fixes openembedded#3

commit dfb0f7c0d51556448cba79b474b8c19b9cded9af
Author: Christopher Larson <chris_larson@mentor.com>
Date:   Fri Jun 1 18:57:13 2012 -0400

    syntax: add ?= flag def

    Signed-off-by: Christopher Larson <chris_larson@mentor.com>

commit 589a62a00709ca822a42327e7086008aba2d9933
Author: Christopher Larson <kergoth@gmail.com>
Date:   Fri Dec 9 22:25:47 2011 -0700

    ftplugin: set commentstring

    Signed-off-by: Christopher Larson <kergoth@gmail.com>

commit 7ffc80b3fb4ddf68cc5a69bdc63ab03d70c44f87
Author: Chris Larson <chris_larson@mentor.com>
Date:   Thu Jun 2 15:27:48 2011 -0700

    Handle +=/=+ for flags

    Signed-off-by: Chris Larson <chris_larson@mentor.com>

Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
@shr-project
Copy link
Contributor

We're not using github's pull-requests, please follow the README and send it to bitbake-devel ML.

halstead pushed a commit that referenced this pull request Aug 7, 2020
ERR unfortunately doesn't trigger for e.g. 'exit 1'. Unfortunately
the backtrace we generate in the EXIT trap won't be able to get the
correct line number for the first frame.

See http://gnu-bash.2382.n7.nabble.com/trap-echo-quot-trap-exit-on-LINENO-quot-EXIT-gt-wrong-linenumber-td3666.html

Therefore the metadata-relative backtrace will just not have the
first frame. Example:

| WARNING: /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057:1 exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
| 	#1: myclass_do_something, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line ?
| 	#2: do_something, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line 156
| 	#3: actually_fail, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line 144
| 	#4: my_compile_extra, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line 146
| 	#5: do_compile, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line 137
| 	#6: main, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line 180
|
| Backtrace (metadata-relative locations):
| 	#2: do_something, autogenerated, line 2
| 	#3: actually_fail, /home/laplante/repos/oe-core/meta/recipes-extended/libsolv/libsolv_0.7.14.bb, line 36
| 	#4: my_compile_extra, /home/laplante/repos/oe-core/meta/recipes-extended/libsolv/libsolv_0.7.14.bb, line 38
| 	#5: do_compile, autogenerated, line 3

Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
halstead pushed a commit that referenced this pull request Aug 10, 2020
ERR unfortunately doesn't trigger for e.g. 'exit 1'. Unfortunately
the backtrace we generate in the EXIT trap won't be able to get the
correct line number for the first frame.

See http://gnu-bash.2382.n7.nabble.com/trap-echo-quot-trap-exit-on-LINENO-quot-EXIT-gt-wrong-linenumber-td3666.html

Therefore the metadata-relative backtrace will just not have the
first frame. Example:

| WARNING: /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057:1 exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
| 	#1: myclass_do_something, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line ?
| 	#2: do_something, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line 156
| 	#3: actually_fail, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line 144
| 	#4: my_compile_extra, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line 146
| 	#5: do_compile, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line 137
| 	#6: main, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.85057, line 180
|
| Backtrace (metadata-relative locations):
| 	#2: do_something, autogenerated, line 2
| 	#3: actually_fail, /home/laplante/repos/oe-core/meta/recipes-extended/libsolv/libsolv_0.7.14.bb, line 36
| 	#4: my_compile_extra, /home/laplante/repos/oe-core/meta/recipes-extended/libsolv/libsolv_0.7.14.bb, line 38
| 	#5: do_compile, autogenerated, line 3

Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
halstead pushed a commit that referenced this pull request Aug 14, 2020
… shell funcs

Leverage the comments that emit_var writes and the backtrace that
the shell func writes to generate an additional metadata-relative
backtrace. This will help the user troubleshoot shell funcs much
more easily.

Example:

| WARNING: /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.68955:171 exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
| 	#1: myclass_do_something, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.68955, line 171
| 	#2: do_something, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.68955, line 166
| 	#3: actually_fail, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.68955, line 153
| 	#4: my_compile_extra, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.68955, line 155
| 	#5: do_compile, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.68955, line 141
| 	#6: main, /home/laplante/repos/oe-core/build/tmp-glibc/work/core2-64-oe-linux/libsolv/0.7.14-r0/temp/run.do_compile.68955, line 184
|
| Backtrace (metadata-relative locations):
| 	#1: myclass_do_something, /home/laplante/repos/oe-core/meta/classes/myclass.bbclass, line 2
| 	#2: do_something, autogenerated, line 2
| 	#3: actually_fail, /home/laplante/repos/oe-core/meta/recipes-extended/libsolv/libsolv_0.7.14.bb, line 36
| 	#4: my_compile_extra, /home/laplante/repos/oe-core/meta/recipes-extended/libsolv/libsolv_0.7.14.bb, line 38
| 	#5: do_compile, autogenerated, line 3
ERROR: Task (/home/laplante/repos/oe-core/meta/recipes-extended/libsolv/libsolv_0.7.14.bb:do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 542 tasks of which 541 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /home/laplante/repos/oe-core/meta/recipes-extended/libsolv/libsolv_0.7.14.bb:do_compile
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants