**** BEGIN LOGGING AT Tue Apr 07 02:59:57 2020 Apr 07 04:01:09 New news from stackoverflow: What is the use of SECTION variable in a recipe Apr 07 12:31:44 Good morning everybody Apr 07 12:35:31 mous16: A bit of a stretch calling it morning in my time zone, but good day :) Apr 07 12:39:37 Which is the correct way to have a more recent version of a recipe in my build? It's a general question, but i.e. I'm on sumo, that ships cmake 3.10; i would like to use cmake 3.12 instead, as shipped in thud. How should I proceed? Apr 07 12:39:42 Digging my problem with packagegroup-machine-base depending on versionned kernel-image, but not getting rebuilt when that version changed, I concluded package.bbclass is mapping package names too aggressively: I see no reason of replacing in dependency relationships eg. "kernel-image" by "kernel-image-5.3.8" when the latter does "Provides: kernel-image", and when the dependency is unversionned. Any reason this would be wrong ? A Q&D test https://pastebin.com/ Apr 07 12:39:42 JLDKyCid Apr 07 12:41:01 mous16: Try taking the recipe from a later Yocto release, and put it in a local layer. I don't think that using a newer cmake should give much problems, but you have to try and see. Apr 07 12:41:24 Now there are probably some remaining dep-rewrite cases missing the proper dependency, like this packagegroup was - so I left a bb.note to help hunting for those Apr 07 12:41:56 * yann realizes that the Q&D part of the patch has gone since he composed the message Apr 07 12:42:02 erbo: thanks, I was not so confident about that move. I'll try it as soon as I can Apr 07 12:43:46 mous16: you could also look into if it's possible to move to a newer yocto release, sumo is getting a bit dated :) Apr 07 12:47:33 erbo: I'm building a system using boot2qt layer, and that's based on sumo. I'm a bit scared of changing release, mostly because I'm still not so confident on yocto Apr 07 12:50:13 mous16: I don't know the details of your project, but meta-boot2qt supports much later releases than sumo Apr 07 12:59:49 erbo: I missed that, i'll investigate. Old stuff it's not my favorite kind of stuff :-) Apr 07 13:02:55 New news from stackoverflow: How to fix:- libmxnet.so: cannot open shared object file: No such file or directory Apr 07 13:51:10 qschulz: I finally understand why I had an issue on python3 rdepends with openvswitch. I was doing EXTRA_OECONF_pn-openvswitch += in my distro instead of EXTRA_OECONF_append_pn-openvswitch Apr 07 13:56:12 Now I believe there is an issue in EXTRA_OECONF of openvswitch.inc. EXTRA_OECONF += PYTHON=python3 seems incorrect to me because the generated shebang is incorrect (#! python3) Apr 07 14:07:03 ebail: its possible that was added to use the right python during the buiid, and whoever did that didn't notice that it also changed the hashbangs Apr 07 14:08:02 non-cross-friendly tools that do that need to be fixed twice: once to tell it what py to build with and maybe then again during do_install to fixup the hashbangs Apr 07 14:25:25 rburton: yes ovs use python3 variable provided. For instance: https://github.com/openvswitch/ovs/blob/master/utilities/ovs-test.in Apr 07 14:26:05 ebail. I can tell you that OVS has been tested extensively in python3 only images. Apr 07 14:27:07 you'd be better of asking on the meta-virt mailing list, that's where you'll get the right people to have a look. none of them are really in here. Apr 07 14:27:12 Hey guys I'm having some issues with devtool not building my kernel module whenever I change the source code, can someone help? Let me quickly pastebin what I got... Apr 07 14:28:36 thecomet: quick guess, are you sure your devtool workspace is in conf/bblayers.conf? Apr 07 14:29:03 https://pastebin.com/ijzVPW0M Apr 07 14:29:19 How do I check that qschulz? Apr 07 14:29:21 zeddii: thanks for your answer. I will do so Apr 07 14:29:47 My issue is it builds fine the first time, but it doesn't detect any changes thereafter Apr 07 14:30:25 I ran "devtool modify afrgb-stm32mp1", then "devtool build afrgb-stm32mp1" Apr 07 14:31:09 If I inspect the resulting afrgb-stm32mp1.ko module, the changes I made to afrgb-stm32mp1.c were not compiled Apr 07 14:31:16 * zeddii sees the subscribe notification ;) Apr 07 14:33:36 qschulz: I searched the file conf/bblayers.conf for "afrgb" and there is no occurrence. The directory /workspace/sources/afrgb-stm32mp1 looks correct though Apr 07 14:36:12 Are you using the file:// or the git repo in your SRC_URI? Apr 07 14:36:43 I'm using the file:// Apr 07 14:37:00 As in, I'm directly modifying afrgb-stm32mp1/files/afrgb-stm32mp1.c Apr 07 14:37:02 thecomet: I do not know if devtool watches over the oe-local-files directory for changes which I assume is where your Makefile and .c are Apr 07 14:37:34 thecomet: but quick question, why are you not modifying the files directly in your fs without devtool and build with bitbake afrgb-stm32mp1? Apr 07 14:37:40 The github link is commented out so yocto should ignore that, right? Apr 07 14:37:50 thecomet: yes Apr 07 14:38:09 thecomet: wait Apr 07 14:38:19 thecomet: which file are you modifying? Apr 07 14:38:26 I was told that using devtool is slightly faster because bitbake always parses all of the recipes, and I also wanted an easy way to deploy using devtool deploy-target Apr 07 14:38:29 the exact path to the file? Apr 07 14:38:43 Relative to the .bb file, files/afrgb-stm32mp1.c Apr 07 14:39:10 thecomet: try modifying the one in workspace/sources/afrgb-stm32mp1 Apr 07 14:41:00 Okay that worked Apr 07 14:41:46 workspace/sources/afrgb-stm32mp1/afrgb-stm32mp1.c symlinks to workspace/sources/afrgb-stm32mp1/oe-local-files/afrgb-stm32mp1.c Apr 07 14:42:30 Am I understanding this correctly? I need to devtool modify my recipe, make my changes inside the workspace, and then do devtool finish? Apr 07 14:42:34 to apply the changes back? Apr 07 14:46:51 How does that work if SRC_URI is a github link? Apr 07 14:48:50 i've not done that devtool workflow, but if you commit to that repo you should be able to go back into it later and add another remote, branch, push, open a pull request? Apr 07 14:49:56 (probably want to turn of rm_work? i don't know if that will clean your $WORKDIR/git/ or not) Apr 07 14:50:26 off* Apr 07 14:50:55 I'm trying to make building/testing a kernel module on the target as fast as possible Apr 07 14:51:06 thecomet: https://www.yoctoproject.org/docs/3.0.1/sdk-manual/sdk-manual.html#sdk-devtool-use-devtool-upgrade-to-create-a-version-of-the-recipe-that-supports-a-newer-version-of-the-software Apr 07 14:51:08 the way i've done that is with out of tree builds Apr 07 14:51:08 thecomet: I'm not sure devtool was thought for your usecase honestly. file from SRC_URI are usually config files in some ways or files to install on the rootfs. I don't know how devtool is going to work in your case. But usually, you have a git repo, you devtool modify it, you do the changes, commit the changes, and then some devtool finish with some options to create the patches. add the patches to SRC_URI Apr 07 14:52:11 thecomet: as fast as possible? call the makefile yourself? Apr 07 14:52:43 Yeah I think I'll have to. But that has other problems, because I need to pass in the kernel source directory plus the kernel configuration Apr 07 14:52:56 and that information is scattered all over the place in yocto's build directory Apr 07 14:53:02 zcat /proc/config.gz? :) Apr 07 14:53:13 That's the config of my host, not of the target Apr 07 14:53:18 (from the target) Apr 07 14:53:33 Damn we didn't enable that :/ Apr 07 14:53:37 YPTM: Jan-Simon is on Apr 07 14:54:05 thecomet: you need the kernel config for a module? Apr 07 14:54:21 or a reasonable approximation most of the time? Apr 07 14:54:23 thecomet: maybe try devshell and execute make from there Apr 07 14:54:51 This is the first time I'm hearing of devshell, let me google a bit Apr 07 14:54:54 devshell exports all variables used in a recipe, so most of whatever you need should be there Apr 07 14:55:15 bitbake -c devshell Apr 07 14:55:52 Do I need to finish devtool first? Apr 07 14:56:38 Is there a "devtool abort" lol Apr 07 14:56:40 YPTM: armin is on Apr 07 14:56:43 devtool reset Apr 07 14:56:54 is there a "nocache" or similar flag to force grabbing the SRC_URI directly every time? for an internal server so it doesn't seem _too_ awful Apr 07 14:57:30 opello: what do you want to do? what's your issue? Apr 07 14:58:07 qschulz: filename stays the same, its containing directory is versioned; best i saw was setting downloadfilename to include the versioined path element Apr 07 14:58:08 opello: is it because you are downloading a tarball from somewhere and it changes but not the URL to it? Apr 07 14:58:20 the url changes, just not the filename :( Apr 07 14:58:50 YPTM: Scott Murray is on Apr 07 14:58:57 opello: if the URL changes, SRC_URI changes and then triggers a fetch... So.. I don't really understand Apr 07 14:59:29 Sweet, devshell is exactly what I need qschulz Apr 07 15:00:35 hm, it may be my configuration, but i have SOURCE_MIRROR_URL that is the "build server's" DL_DIR, which has the file, and my local environment used that, which is "out of date" Apr 07 15:00:55 How do you get the changes you make inside devshell back into the original recipe? Apr 07 15:01:32 YPTM: Joshua Watt here Apr 07 15:01:46 YPTM: Randy MacLeod joined. Apr 07 15:02:00 opello: so you changed the actual content of a file on a server but not the filename right? Apr 07 15:02:15 fyi: YPTM zoom meeting: https://zoom.us/j/990892712 Apr 07 15:03:23 New news from stackoverflow: Yocto bootloader do_configure fails Apr 07 15:03:46 qschulz: no, sorry; the last build run on the server used a different SRC_URI that terminated in the same file name (containing directory contains the version number), but, my local build, with an updated recipe's SRC_URI fell to the SOURCE_MIRROR_URL URL instead of the SRC_URI URL (so it used the last server build download instead of the latest) Apr 07 15:05:38 the fetch log shows it using the SOURCE_MIRROR_URI, if i turn that off i believe the problem will be resolved, but it's a common development workflow, it's like because the file names are not different, and the SOURCE_MIRROR_URL doesn't provide the SRC_URI context for a particular file, confusion can occur Apr 07 15:05:47 SOURCE_MIRROR_URL* Apr 07 15:06:37 opello: My brain might be fried because I'm confused by what your setup is Apr 07 15:06:49 qschulz: sorry :( Apr 07 15:06:55 opello: I'll try. Apr 07 15:07:35 opello: buildserver runs a build. Fetches the srouces for recipe my-recipe and put the sources into DL_DIR of the buildserver. Apr 07 15:07:59 opello: dev-desktop runs a build. It has SOURCE_MIRROR_URL pointing to DL_DIR of the buildserver. Apr 07 15:08:30 opello: correct? Apr 07 15:09:27 zeddii: https://lists.yoctoproject.org/g/meta-virtualization/message/5248 Apr 07 15:09:36 qschulz: yep Apr 07 15:09:42 zeddii: https://lists.yoctoproject.org/g/meta-virtualization/message/5248 Apr 07 15:11:00 cool.thanks. IIRC the Wind River guys tested OVS/libvirt and others against python3 only, so hopefully they will see it and comment. Apr 07 15:13:50 opello: so... what's the issue from there? Apr 07 15:15:04 qschulz: buildserver built 1.0, i'm working on 2.0; archive my environment pulled from SOURCE_MIRROR_URL was 1.0 despite my change to the recipe's SRC_URI (and updating the checksums) Apr 07 15:15:35 (a little contrived, but exemplifies the case) Apr 07 15:23:18 opello: I still don't understand but two things. If it's a tarball and the name is identical between buildserver and workstation even though the content of the tarball is differnet. Bad. Very bad. Don't do that Apr 07 15:23:46 opello: are you sure it's source_mirror_uri and not pre_mirror that is set to your buildseevr DL_DIR? Apr 07 15:26:09 qschulz: i have ip being used in two places (SSTATE_MIRRORS and SOURCE_MIRROR_URL), the fetch log says: For url returning Apr 07 15:28:41 opello: can you give me the SRC_URI of the incriminated file? Apr 07 15:29:39 opello: I'm now assuming you have "http://IP/mysoft/1.0/tarball.gz" in one recipe and "http://IP/mysoft/2.0/tarball.gz" in another? Apr 07 15:29:50 qschulz: yeah, basically Apr 07 15:30:09 opello: put the version in the filename Apr 07 15:30:31 heh, yeah; downloadfilename=? Apr 07 15:30:43 seems like the 'best' workaround Apr 07 15:30:48 opello: are you maintaining this tarball? Apr 07 15:31:37 qschulz: me? no, if that were the case it wouldn't be horribly named :) but another team and complexity ... hopefully this deployment all goes away at some point Apr 07 15:32:08 opello: yeah, well https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#http-ftp-fetcher Apr 07 15:32:18 indeed, that's exactly what downloadfilename is for :) Apr 07 15:33:31 so put the version in there :) if you have it in the recipe, something like ${BP} Apr 07 15:38:22 qschulz: is it reasonable to use a directory? or does it have to land in the file name? Apr 07 15:40:01 is it possible to override a SRC_URI from another .bb by using a .bbappend in another repo? Apr 07 15:41:05 so far i'm just changing the SRC_URI in the original .bb before running bitbake but now i'm trying to get it defined somewhere in git for future builds Apr 07 15:41:41 i don't have direct write access to the original repo, though will submit a patch there when i get it just right Apr 07 15:42:10 SRC_URI is just a variable, so you can definitely change it. Apr 07 15:42:48 its easier of course if it doesn't have a whack of patches, etc, but its doable regardless Apr 07 15:43:52 yeah, it's pretty straightforward, original recipe is just a git checkout and a build pretty much, and my customization is a slight fork of that repo Apr 07 15:44:29 so SRC_URI = "git://my.git.url" in the .bbappend should override the original recipe's SRC_URI? Apr 07 15:45:07 this build takes a couple hours so just double checking before i wing it lol Apr 07 15:50:26 RP: review reminder: https://patchwork.openembedded.org/patch/171053/ Apr 07 15:54:35 fury: yes. you can check by yourself by changing it and run bitbake -e myrecipe | grep -e "^SRC_URI" Apr 07 15:57:15 opello: Convention is recipe-major.minor.tar.gz (or whatever the extension) I think and you should have only a directory in there which is recipe-major.minor which then contains everything. In that case, no downloadfile and S is correctly set by default Apr 07 15:57:24 awesome Apr 07 15:57:28 thanks! Apr 07 16:02:51 qschulz: using a directory as the first downloadfile element did not resolve the issue :/ but i think i have a workaround now Apr 07 16:07:58 moto-timo: Would you be able to make a dunfell branch in meta-python2? Apr 07 16:09:01 paulbarker: do you want to take your MAINTAINERs conversation to the oe-architecture mailing list? Apr 07 16:09:28 opello: downloadfilename=${BP}? Apr 07 16:10:48 qschulz: that seems maybe nicer, i constructed it so that i could recover the original name (basically included ${PV} as part of a prefix) Apr 07 16:16:15 Hey. I'm attempting to run vpnc on a RPi. It can't seem to bind to port 500 despite root, but when specifying another port, I'm running into `vpnc: can't initialise tunnel interface:1`. Debug output here: https://pastebin.com/seMYytfh Apr 07 16:19:28 hi guys, im having problem with package striping. I hope someone has some idea how i can achieve that my package is striped and installed in rootfs and in case of SDK build that is installed unstriped? Apr 07 16:19:59 Running strace, I'm seeing the following error `? ERESTARTNOHAND (To be restarted if no handler)` which doesn't seem to documented well. Full strace: https://pastebin.com/qv8eF2d4 Apr 07 16:21:07 how can I tell if prelinking worked correctly? Prelinking core-image-minimal on zeus (aarch64 target) gives no size change before and after prelinking and there are a lot of "architecture not supported" warnings. See https://paste.gnome.org/pcchbr5c6 (from log.do_imaage) Apr 07 16:21:36 nhartman: Yocto handles stripping debug symbols into a -dbg package, which should automatically be included in the SDK Apr 07 16:21:54 ecclescake: prelink doesn't alter size at all does it? Apr 07 16:22:12 mine didn't, should it not? Apr 07 16:22:34 s/nhartman/Vik71 Apr 07 16:22:56 tlwoerner: Not immediately but I may loop back on it after 3.1 is out Apr 07 16:23:06 nhartman: hah, sorry Apr 07 16:23:06 Well in recipe INHIBIT_PACKAGE_STRIP = "1" is set Apr 07 16:23:48 Vik71: Ok, so make sure the recipes build system (make, autotools, meson, cmake, whatever) isn't already stripping it Apr 07 16:24:22 Well in recipe INHIBIT_PACKAGE_STRIP = "1" is set, so I end up with huge libraries in rootfs. So if i set this option to 0, than libs are striped but im missing debug symbols in SDK libs Apr 07 16:24:43 Vik71: Ah, ok... hmm Apr 07 16:25:41 Vik71: Well, I think for starters, you want that variable set to 0, then the problem is why it's not including the symbols in the SDK Apr 07 16:27:10 JPEW yes true, i tried to set INHIBIT_PACKAGE_DEBUG_SPLIT= "0" to force that debug symbols are in separated file Apr 07 16:27:54 Vik71: Are you able to share the recipe in a pastebin? Apr 07 16:28:57 well, it's vivante recipe from fsl-bsp-release Apr 07 16:30:59 this is a linkhttps://github.com/toradex/meta-fsl-bsp-release/blob/toradex_morty-4.9.51-8qm_beta2-bring_up/imx/meta-bsp/recipes-graphics/imx-gpu-viv/imx-gpu-viv-v6.inc Apr 07 16:31:15 here is a link https://github.com/toradex/meta-fsl-bsp-release/blob/toradex_morty-4.9.51-8qm_beta2-bring_up/imx/meta-bsp/recipes-graphics/imx-gpu-viv/imx-gpu-viv-v6.inc Apr 07 16:31:16 <[Sno]> otavio: 2nd part up lsdk-20.04 update is ready :) Apr 07 16:40:15 Vik71: Ah, thats packaging pre-built binaries, so I'm not sure there is much you can do Apr 07 16:42:15 Vik71: I think you are probably stuck with the large binaries in the rootfs :( Apr 07 16:43:55 thx JPEW, well maybe as workaround I can create different image type just for SDK build so i don't strip these libraries Apr 07 17:04:51 @JPEW do you maybe know is it possible to have post install script to run after libs are installed and to strip them? Apr 07 17:05:47 so why doesn't the standard stripping work? Apr 07 17:14:08 rburton: Not sure Apr 07 17:14:46 rburton: Best guess: The original recipe writes didn't bother to make it work correctly and just disabled stripping? Apr 07 17:21:05 <[Sno]> otavio: is remove after dunfell release not an option? Apr 07 17:33:54 New news from stackoverflow: How to add source files to PN-src package in yocto Apr 07 18:00:17 I've got an issue using Go from an SDK I'm building. Not sure if it's me or a poky problem. The SDK includes the cross go compiler *binary* in $SYSROOTS/x86_64-mydistro-linux/usr/lib/go/kpg/tool/linux_amd64. However there is no Go stdlib nor can I find a nativesdk package to provide it. Apr 07 18:02:09 But, in $SYSROOTS/arm7at2hf-neon-vendor-linux-genueabi/usr/lib/go, there is the stdlib *src* and *pkg* for arm-linux. But no compiler binaries. Apr 07 18:07:44 The SDK builds in a GOROOT of $NATIVE_SYSROOT/usr/lib/go, which does not work, as there is no stdlib there. Apr 07 18:09:05 I was able to compile go code, but I needed to set GOROOT to "$TARGET_SYSROOT/usr/lib/go" and then set GOTOOLDIR to "$NATIVE_SYSROOT/usr/lib/go/pkg/tool/linux_amd64" Apr 07 18:10:34 is the yocto sdk broken for go? (zeus 22.0.2) Or am I missing something that would put the go stdlib in $NATIVE_SYSROOT? Apr 07 18:40:10 I'm not seeing how to get testresults.json from oe-selftest, and oe-test both fails to even run (doesnt add the bitbake libdir to sys.path) and fails due to a lack of testdata.json Apr 07 21:36:48 armpit: thanks, merged Apr 07 21:37:59 kergoth: should be there as tmp/log/oeqa/testresults.json Apr 07 21:58:50 YPTM: Sorry I missed the meeting today :( Apr 07 22:45:26 alejandrohs: you are excused. Strange times Apr 08 00:03:27 hola Apr 08 00:03:45 iam trying to understand the runqemu approach Apr 08 00:04:14 is there any exhaustive material on how this works? Apr 08 00:08:22 if possible i want to run it outside the yocto enviroment in total Apr 08 00:08:30 building yocto in a dockers container Apr 08 00:08:38 preferably running the tests outside Apr 08 01:09:42 stefandxm: I dont think theres any documentation other than the code itself which is inside scripts/runqemu, it does rely on the data grabbed from bitbake, so you would still need to do that to get the required variables about the system it'll run, a lot of those are inside the qemuboot.conf file on your deploy directory, which are set on the qemuboot class, you can easily share directories between Apr 08 01:09:44 the container and your host which would allow you to do something similar to that Apr 08 01:15:46 thats fair Apr 08 01:16:10 ponder i want to run 10x tests in parallel taking days Apr 08 01:16:38 hmm, should work Apr 08 01:16:50 sorry, was thinking loud :) Apr 08 01:18:29 but main question remains tho. albeit its my own fault Apr 08 01:18:51 runqemu documentation? i had some difficulties with it yesterday Apr 08 01:22:13 i see now our shell scripts do not export stuff Apr 08 01:22:48 but pondering this works Apr 08 01:23:19 we should be able to stage the qemuboot.conf right? Apr 08 01:23:23 with the image? Apr 08 01:23:50 (iam a bit out of the loop, just a programmer :) Apr 08 01:29:15 technically the qemuboot.conf would still be generated within the build, so inside the container Apr 08 01:30:01 stefandxm: but if you share the build directory of such container with your host, you can run the same environment that was used to build on your host Apr 08 01:30:15 and it would grab the correct qemuboot.conf automatically Apr 08 01:31:23 thats just AN approach that comes to mind cant say its the most efficient possible Apr 08 01:32:45 so what I'm saying is you dont have to stage it, from outside the container you can just use the one created inside Apr 08 01:33:15 yeah we have mounted into the dockers container Apr 08 01:33:29 i want to stage it Apr 08 01:33:48 but i do it manually with some python scripts Apr 08 01:34:03 you would have to source the oe-env from outside and then nothing stops you from running runqemu at that point Apr 08 01:34:05 its mostly because i want many short-tests Apr 08 01:34:14 yeah Apr 08 01:34:23 as in you are using testimage? Apr 08 01:34:27 yes Apr 08 01:34:44 i think i will attack runqemu and make it more permanent to our test system Apr 08 01:35:34 in the end i guess its all qemu system right? Apr 08 01:36:10 stefandxm: please dont attack our code Apr 08 01:36:12 the reason for staging is because our generic testing system runs 1-~10 tests Apr 08 01:36:13 jk Apr 08 01:36:35 and we do a dry run, quick test, quick test * 2 Apr 08 01:36:39 and then some longer tests Apr 08 01:36:47 you can define different test suites Apr 08 01:37:00 yeah, but the tests depend on evironment Apr 08 01:37:12 not talking about the shell environment but databases/perpherials etc Apr 08 01:37:33 a complete test takes 2 weeks :o Apr 08 01:38:40 its nothing advanced. just staging :) Apr 08 01:39:01 in this case the yocto image is an edge device Apr 08 01:39:05 or, even several Apr 08 01:39:16 and each image depends on a production enviroment Apr 08 01:41:10 yocto in total.. i have no idea :D Apr 08 01:41:22 for what we are using it for it seems a bit over engineered Apr 08 01:41:45 maybe its time for some separation Apr 08 01:41:51 but it works great :) Apr 08 01:41:58 I think its achievable, my one suggestion would just be not to deviate too much from upstream, in case some behavior changes and that way you don thave to rebase your work Apr 08 01:42:16 indeed Apr 08 01:42:26 i will do full copy in the staging though Apr 08 01:42:36 since you never know what triggers an issue Apr 08 01:42:50 with yocto so many stages can create new behaviour Apr 08 01:43:34 but we are in desperate need of emulator to get to valgrind etc Apr 08 01:43:42 the hardware is just not fast enough Apr 08 01:43:58 When building offline, I notice that yocto really wants to contact a git server in the case of recipes using tags for SRCREV. I see the advice is to "use SHAs instead, silly" but I would like to leave my recipes looking pretty. Is there a way I can get it not to try and fetch tags when offline (e.g. BB_NO_NETWORK)? Apr 08 01:44:54 I understand the problems around tags potentially changing definition upstream, but if I'm building offline I don't 100% care about that from a developer perspective, since I'd have imagined offline builds to use local versions of tags Apr 08 01:49:07 alejandrohs: you work on yocto? Apr 08 01:49:15 dp: sorry i dont know Apr 08 02:12:30 stefandxm: I mean tecnically we all contribute to it Apr 08 02:14:34 alejandrohs: i just adressed you because of the original comment of yours :) but you are a maintainer no? Apr 08 02:14:48 we are very happy with yocto Apr 08 02:15:23 iam working for a company trying to get away from some lock ins Apr 08 02:15:36 and personally iam an avid open source contributor Apr 08 02:15:45 having some projects on my own Apr 08 02:16:46 but we are new to yocto :) Apr 08 02:17:24 and while trying to do some stuff yourself until you learn i love the synergy of asking questions when it can help you Apr 08 02:35:39 New news from stackoverflow: Config parsing error on xl create for Xen Guest DomU **** ENDING LOGGING AT Wed Apr 08 03:00:04 2020