<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugzilla.yoctoproject.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.6"
          urlbase="https://bugzilla.yoctoproject.org/"
          
          maintainer="it-coreprojects-helpdesk@linuxfoundation.org"
>

    <bug>
          <bug_id>16494</bug_id>
          
          <creation_ts>2026-11-11 18:14:30 +0000</creation_ts>
          <short_desc>bitbake-setup fetcher logging is terrible</short_desc>
          <delta_ts>2026-11-12 15:42:21 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>7</classification_id>
          <classification>Build System, Metadata &amp; Runtime</classification>
          <product>BitBake</product>
          <component>bitbake</component>
          <version>unspecified</version>
          <rep_platform>x86</rep_platform>
          <op_sys>Multiple</op_sys>
          <bug_status>IN PROGRESS REVIEW</bug_status>
          <resolution></resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>Medium+</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>6.2 M1</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Richard Purdie">richard.purdie</reporter>
          <assigned_to name="Richard Purdie">richard.purdie</assigned_to>
          <cc>adrian.freihofer</cc>
    
    <cc>alex.kanavin</cc>
    
    <cc>ccasciato</cc>
    
    <cc>poky.bs.watcher</cc>
    
    <cc>poky.watcher</cc>
    
    <cc>randy.macleod</cc>
          
          
          <cf_os>---</cf_os>
          <cf_regression_type>---</cf_regression_type>
          
          <cf_docchange>No (bug/feature does not impact docs)</cf_docchange>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>107378</commentid>
    <comment_count>0</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2026-11-11 18:14:30 +0000</bug_when>
    <thetext>$ bitbake-setup --setting default top-dir-prefix /tmp/pokybuild/ --setting default top-dir-name poky-tiny --setting default dl-dir /foobar --setting default common-sstate no --global-settings /tmp/pokybuild/settings.conf init --skip-selection machine --skip-selection distro --setup-dir-name build --non-interactive poky-master poky machine/qemux86-64 distro/poky-tiny
NOTE: Bitbake-setup is using /tmp/pokybuild/poky-tiny as top directory.
/tmp/pokybuild/poky-tiny looks like a new top directory. If you would like to use a different directory, answer &quot;n&quot; below and either:
	1) Change the default bitbake-setup settings:
		bitbake-setup settings set default top-dir-prefix &lt;PATH&gt;
		bitbake-setup settings set default top-dir-name &lt;NAME&gt;
	2) Pass one or more options on the command line to change the top level directory in that invocation only:
		bitbake-setup --setting default top-dir-prefix &lt;PATH&gt; ...
		bitbake-setup --setting default top-dir-name &lt;NAME&gt; ...

A common site.conf file will be created, please check it is correct before running builds
    /tmp/pokybuild/poky-tiny/site.conf

NOTE: Looking up config poky-master in configuration registry
NOTE: Skipping a selection of machine, as requested on command line. The resulting bitbake configuration may require further manual adjustments.
NOTE: Skipping a selection of distro, as requested on command line. The resulting bitbake configuration may require further manual adjustments.
NOTE: Run &apos;bitbake-setup init --non-interactive poky-master poky&apos; to select this configuration non-interactively.

Initializing a setup directory in
    /tmp/pokybuild/poky-tiny/build
Fetching layer/tool repositories into /tmp/pokybuild/poky-tiny/build/layers
    bitbake
ERROR: cannot access local variable &apos;lf&apos; where it is not associated with a value


The actual error is that DL_DIR of /foobar is not writable!

I&apos;m filing as the logging output/error is terrible in multiple ways and we should improve this.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>107379</commentid>
    <comment_count>1</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2026-11-11 18:19:57 +0000</bug_when>
    <thetext>I&apos;ve sent a fix for the lf not being set issue, but the bigger question is why there isn&apos;t any traceback shown here?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>107380</commentid>
    <comment_count>2</comment_count>
    <who name="Alexander Kanavin">alex.kanavin</who>
    <bug_when>2026-11-11 18:35:58 +0000</bug_when>
    <thetext>At some point it was decided that it&apos;s better to show a clean error message contained in the exception, and skip the stack trace that caused it (unless in debug mode):

https://git.openembedded.org/bitbake/commit/?id=9fb6b0011bae34a7c1feb53281e13364d85ddee8

We might want to revisit that idea...</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>107381</commentid>
    <comment_count>3</comment_count>
    <who name="Richard Purdie">richard.purdie</who>
    <bug_when>2026-11-11 20:25:17 +0000</bug_when>
    <thetext>Copying Adrian, I think we might want to undo this as it is actively breaking usability, I&apos;d rather have the ugly tracebacks to be honest</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>107390</commentid>
    <comment_count>4</comment_count>
    <who name="Randy MacLeod">randy.macleod</who>
    <bug_when>2026-11-12 15:42:21 +0000</bug_when>
    <thetext>RP has a patch.</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>