dl9pf changed the topic of #yocto to: Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Channel logs available at https://www.yoctoproject.org/irc/ and https://libera.irclog.whitequark.org/yocto/ | Having difficulty on the list, or with someone on the list? Contact YP community mgr Nicolas Dechesne (ndec)
goliath has quit [Quit: SIGSEGV]
qschulz has quit [Quit: qschulz]
qschulz has joined #yocto
jwillikers has quit [Remote host closed the connection]
Johnsv has quit [Quit: Ping timeout (120 seconds)]
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #yocto
Net147 has joined #yocto
Net147 has quit [Changing host]
Ad0 has quit [Ping timeout: 252 seconds]
OutBackDingo has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
OutBackDingo has joined #yocto
Ad0 has joined #yocto
FredO has quit [Quit: Leaving]
<yates> regarding sysroot population and the tmp/sysroots-components, what if a package reported in a task's "NOTE: Installed into sysroot:" log is under more than one subdirectory of tmp/sysroots-components?
<yates> or is that arranged so that it never happens? (looks like it)
<yates> and what is the tmp/sysroots-components/<some-foldr>/<some-sysroot-folder>/sysroot-providers used for? it looks like some "keyng" mechanism, but i don't quite get it
<yates> are most people east of the U.S.?
<moto-timo> yates: we’re global, but historically a lot of folks have been EU
<moto-timo> I’m pacific time zone
<yates> i see
<yates> still early for you, then...
<moto-timo> If 7pm is early
<moto-timo> To me that’s 12+ hours into my day
_whitelogger has joined #yocto
<yates> i'm EST, and I started roughly the same time. but i've had lots of breaks...
<yates> this "work-from-home" paradigm has made my schedule quite crazy!
<yates> and being 63 i can't seem to sleep a full 7 or 8 hours anymore..
sakoman has quit [Quit: Leaving.]
gioyik has quit [Ping timeout: 276 seconds]
tlwoerner has quit [Ping timeout: 260 seconds]
tlwoerner has joined #yocto
tlwoerner has quit [Client Quit]
tlwoerner has joined #yocto
zpfvo has quit [Ping timeout: 265 seconds]
zpfvo has joined #yocto
nsdrude[m] has joined #yocto
nsdrude[m] is now known as hereiam[m]
Vonter has quit [Ping timeout: 268 seconds]
zeddiii has joined #yocto
zeddii has quit [Ping timeout: 240 seconds]
amitk has joined #yocto
zeddiii has quit [Ping timeout: 265 seconds]
ThomasD13 has joined #yocto
gioyik has joined #yocto
agrue has quit [Ping timeout: 268 seconds]
agrue has joined #yocto
tre has joined #yocto
<JosefHolzmayr[m]> yo dudX
Tyaku has joined #yocto
leon-anavi has joined #yocto
frieder has joined #yocto
mckoan|away is now known as mckoan
<mckoan> good morning
rfuentess has joined #yocto
<JosefHolzmayr[m]> any pointers on how to actually get the public sstate mirror to kick in? i'm tinkering around for demonstration purposes, and even on a completely unmodified dunfell build, not a single hit appears.
Guest27 has joined #yocto
gioyik has quit [Quit: WeeChat 3.1]
<JosefHolzmayr[m]> even when checking out the 3.1.10 tag and setting the path accordingly, i get found 3 - missed 1148
<RP> JosefHolzmayr[m]: You need master with that variable I mentioned
<JosefHolzmayr[m]> RP: you mentioned something? where?
<RP> JosefHolzmayr[m]: It doesn't work with dunfell as there is no read only hash equivalence data to match (except there is no, it just can't work with dunfell)+
<RP> s/no/now/
<JosefHolzmayr[m]> RP: ah missed that one. my bad. so this essentially means that after the hashequiv server has been turned on, all prior usecases have been invalidated. correct?
manuel1985 has joined #yocto
<RP> JosefHolzmayr[m]: since we enabled it, it did stop sstate working from the AB until we had this as well
<JosefHolzmayr[m]> RP: okay, i think i got it. just trying to understand the current situation (as i can't show/tell/explain things that i don't at least have a basic grasp of myself)
gsalazar has joined #yocto
xmn has quit [Quit: ZZZzzz…]
gsalazar has quit [Read error: Connection reset by peer]
gsalazar has joined #yocto
<JosefHolzmayr[m]> RP: it seems to work now, thanks.
<RP> JosefHolzmayr[m]: np, trying to help :)
prabhakarlad has joined #yocto
<JosefHolzmayr[m]> 13 minutes core core-image-minimal. not bad.
<mckoan> JosefHolzmayr[m]: sounds great. Are you going to discuss it in the next Twitch?
<JosefHolzmayr[m]> mckoan: don't think so
<Tyaku> Hi, I come again about my libraries issues. I have a recipe A that provide a static library (.a) and header files. (The header files appear in workdir/sysroot-destdir/usr/include/matter and library in workdir/sysroot-destdir/usr/lib). The recipe B arrive to build using the library of recipe A, but now my problem is when i set "#include 'file'" in the sources of recipe B) "No such file or directory".
<Tyaku> On the CMake project of recipe B, i have include directories set as "/usr/include/matter"
<qschulz> Tyaku: I assume the CFLAGS/LDFLAGS/CXXFLAGS/CPPFLAGS/whatever that are passed by Yocto aren't used in your cmake or overridden by it
<Tyaku> And during the build, I see the "-I/usr/include/matter"
<qschulz> Tyaku: yeah, that's most likely incorrect
<Tyaku> But I think it search on "computer" paths (not sure).
<qschulz> yup looks like it
<Tyaku> So the correct way is not to define the include directories in the CMakeList.txt, but in the recipe ?
<Tyaku> With the variables that you said
<qschulz> use whatever the build system is giving you
<JosefHolzmayr[m]> Tyaku: the key is to not have the include pathes absolute, but having them automatically determined so that the outer build environment can adjust them as needed.
<olani[m]> Or use -I=/usr/include/matter if you have to do it like that. The = is replaced with whatever is given to gcc as sysroot and ignored otherwise. I would not recommend it as the preferred solution, but it works.
<JosefHolzmayr[m]> olani: interesting "dirty" trick, but agreed, absolutely not recommened, at least not without extensive comments explaining it.
<Tyaku> Currently during the build it use -I/usr/include/matter and it still don't find the files, but as qschulz said, i think it search on "host computer" directories instead of the "/usr/include/matter" in Yocto dirs
<olani[m]> Josef Holzmayr (TheYoctoJester): Sometimes you have makefiles that have to work in several build environments and pkg-config is not available.
<Tyaku> I looking how to do it properly, I found some examples https://stackoverflow.com/questions/54722712/bitbake-cannot-find-the-header-file-of-another-recipe but i'm looking for examples base on CMake Project
<JosefHolzmayr[m]> olani: yeah i completely agree. but the '=' character is so hard notice and so little revealing in itself that i would request the maintainer to have an extensive comment right next to it, if the process actually depends on this behaviour.
<mckoan> JosefHolzmayr[m]: therefore would you mind sharing the local.conf you used to test it ?
camus1 has joined #yocto
<olani[m]> Tyaku: The "correct" way would be to install a pkg-config file from recipe A and use whatever CMake uses to read such files to find the correct paths.
camus has quit [Quit: camus]
camus1 is now known as camus
<JosefHolzmayr[m]> mckoan: https://hastebin.com/abasapogeh.makefile
<mckoan> JosefHolzmayr[m]: thank you
<JosefHolzmayr[m]> np
<Tyaku> olani[m] Jesus, it's terrible, when I search on internet I don't find examples about these basic things: A recipe that build using a library + headers from another recipe using CMake.
<olani[m]> Tyaku I'm afraid I do not know CMake, but https://github.com/metabrainz/libmusicbrainz both consumes and generates pkg-config files (.pc)
<olani[m]> and has a recipe in meta-openembedded
<JosefHolzmayr[m]> yeah the main source for your headaches is probably that you wrangling two sides in one. i' suggest to first make a recipe that uses some random, already existing library. and then, in a second step, make a recipe that mimics the library behaviour with your own.
florian has joined #yocto
bantu_ has quit [Quit: bantu_]
bantu has joined #yocto
kayterina has joined #yocto
<RP> kanavin: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/1587/steps/14/logs/stdio - another render node issue - at least it shows the error though!
dgriego has quit [Ping timeout: 268 seconds]
dgriego has joined #yocto
<Tyaku> Did someone know how to generate .pc files (for pkg-config) on yocto ? The docs says: "The pkg-config class provides a standard way to get header and library information. This class aims to smooth integration of pkg-config into libraries that use it.
<Tyaku> During staging, BitBake installs pkg-config data into the sysroots/ directory. By making use of sysroot functionality within pkg-config, this class no longer has to manipulate the files."
<Tyaku> So is it supposed to be automatic if we just inherit from pkgconfig ?
<olani[m]> That inherit only ensures that the native pkg-config tool is available to your build.
<olani[m]> Each package can generate pkg-config in its own build system. Looking at libmusicbrainz that is done with CONFIGURE_FILE here https://github.com/metabrainz/libmusicbrainz/blob/master/CMakeLists.txt#L42
<olani[m]> The files should be installed to /usr/lib/pkgconfig. If you do this right the pc file will be included in the sysroot for dependent recipes.
<Tyaku> My first project is not CMake based, only the second that use the library :/
<RP> kanavin: https://autobuilder.yoctoproject.org/typhoon/#builders/56/builds/1581/steps/14/logs/stdio looks the same, maybe it is opensuse specific?
<olani[m]> The pc file is not complicated, take something like https://github.com/metabrainz/libmusicbrainz/blob/master/libmusicbrainz5.pc.cmake and clean it up for your library. Documentation for pkg-config starts here https://www.freedesktop.org/wiki/Software/pkg-config/
camus has quit [Ping timeout: 252 seconds]
<olani[m]> If I remember correctly you install some headers to /usr/include/matter and a static library to /usr/lib, then your pc file could look like... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/62bbb6476fac3209901e717c333c4a59410038fc)
<olani[m]> Going to libmusicbrainz again they use FIND_PACKAGE on line https://github.com/metabrainz/libmusicbrainz/blob/master/CMakeLists.txt#L34 to find a cmake module(?) defined here https://github.com/metabrainz/libmusicbrainz/blob/master/cmake/modules/FindLibXml2.cmake that use pkg-config to read data from the libxml2.pc file.
camus has joined #yocto
<Tyaku> So, for the first step, I just have to put the .pc in the folder of my recipe where I put "external files / patches". Then just inherit "pkgconfig" and the job should be done ? I see the pkgconfig.bbclass and it seems to create the pkgconfig directory (but i'm not sure).
<olani[m]> The pc file has to be installed to ${D}${libdir}/pkgconfig in recipe A. It should then automagically be available in the sysroot of reciepe B.
<olani[m]> You only need to inherit pkgconfig in recipe B
<Tyaku> In workdir/image or workdir/sysroot-destdir I don't have the folder with pkgconfig file.
<olani[m]> Which recipe?
<olani[m]> If it is not in recipe A workdir/image you have not installed it correctly
<olani[m]> pc-files are handled as header files in the way that they are not bitbake files but files that are part of the package build.
<Tyaku> it is not supposed to be automatic if we inherit "pkgconfig.bbclass" ? https://github.com/openembedded/openembedded/blob/master/classes/pkgconfig.bbclass
Vonter has joined #yocto
<olani[m]> The pkgconfig.bbclass file that I use do not install any pc-files
<Tyaku> Nop, Let me check my local file ..
<Tyaku> I'm using hardknot, but i'm looking the content to see if it differs
<olani[m]> I'm also on hardknott and my pkgconfig.bbclass is only a single line
<Tyaku> Yep me too
<Tyaku> >_<
<Tyaku> Ok, so i'm going to manualy configure it.
<Tyaku> install*
<olani[m]> I would do all of that in the project makefile. Then you can also make sure that the paths in the pc file matches the paths where the headers and libs are installed. GNU coding standards say (paraphrased) that pc-files should be generated at the install stage so they always match the values of $prefix and so on used at make install.
<rburton> Tyaku: pkgconfig.bbclass simply pulls in a build dependency, it doesn't know (and cannot) know how to install pkgconfig files
goliath has joined #yocto
<Tyaku> Currently it didn't work during the build of recipe B, because find_package() is looking for .cmake files (different structure from .pc), after some research find_package() don't use the .pc files, we have to use pkg_check_modules() or pkg_search_module() instead. But as I understand the objective of this is *just* to set the includes/cflags/... as defined in the configuration file provided by Receipe A (the
<Tyaku> library recipe). But for my initial problem, not sure it will change something because I had in my CMakeList the include directories configured to /usr/include/matter, The files I'm looking for exists in this (workdir/image and workdir/sysroot-destdir), during the build it was not finding the header file because I think it search on computer folder.
coldspark29[m] has joined #yocto
mckoan is now known as mckoan|away
<Tyaku> Well... I find the correct include folder: "-I${STAGING_DIR_TARGET}/${includedir}/matter"
<olani[m]> Using pkgconfig files will help you with those paths. Or you can use the -I= flag I mentioned above.
<Tyaku> Yep, But only if the .pc file use the correct directory (so not /usr/include/matter, but with ${STAGING_DIR_TARGET}). I think I will see how to integrate pkgconfig but later. Currently I focus on building a software that use a library.
<rburton> Tyaku: what is the library you're building?
<Tyaku> This is the CHIP library.
<Tyaku> Yes,
<rburton> hilarious/tragic that a corporate sponsors library designed to be used everywhere is so tricky to build/integrate
<Tyaku> Currently I think it's not their objective to make a library "easy to use".
<qschulz> rburton: have you checked the companies in the alliance? I am not surprised.. AT ALL :)
<rburton> qschulz: one glorious day they'll catch up
<rburton> (i'm not surprised *at all*
<Tyaku> This library use the GN build system witch is not realy supported by yocto yet, so just for it, i had to pass by a gn.bbclass that a good guy made. (based on chromium in meta-browser but yeah)
<Tyaku> Why GN build system ? That's the question, maybe because of Mr Google.
<rburton> its less how to build the actual stuff, it's more the integration after that
<rburton> it should be installing things like pkgconfig files, cmake files, something
Guest27 has quit [Ping timeout: 256 seconds]
xmn has joined #yocto
Belsirk has joined #yocto
Guest27 has joined #yocto
rfuentess has quit [Remote host closed the connection]
Ad0 has quit [Ping timeout: 265 seconds]
zeddii has joined #yocto
Ad0 has joined #yocto
jwillikers has joined #yocto
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #yocto
<Tyaku> If my library from receipe A have a lot of directories for includes and i want to put their content in /usr/include/matter, is there a recursive syntaxt to create folder & install files ? I'm sure this is not the good way: https://pastebin.com/5tattJin
xmn has quit [Ping timeout: 240 seconds]
nerdboy has quit [Ping timeout: 265 seconds]
<Tyaku> The include folder need to keep the same hierarchy as the rest ..
<rburton> Tyaku: doesnt matter have an install function for that
<Tyaku> Matter is not made to work with yocto directly.
<rburton> this isn't yocto-specific
<qschulz> Tyaku: probably better to tweak the cmake of CHIP/matter/gn to install to the includedir of your choice
<rburton> software being able to install is a fundamental thing
<Tyaku> And the only tutorial about building matter exemples/lib/.. for yocto are using the toolchain.
<rburton> ok the building documentation has made me laugh/cry
<Tyaku> matter/chip use GN. I can check how to do this
<rburton> they appear to assume that you're building on-target, not installing, and just linking directly against the build tree
<rburton> which is frankly terrifying
<Tyaku> Yes, the project is mainly "building from target" or you can cross-compile (in exemple folder)
<rburton> no wonder it has 1.6K issues
<rburton> the shortcut for recursive install is mkdir -p. which creates all parents if needed. ie mkdir ${D}${bindir} will make ${D}/usr before ${D}/usr/bin
<qschulz> rburton: install -D does this too IIRC
<rburton> yeah, or that
<rburton> as this is terrible build infra i'd honestly say if it saves you time, cp -r and chown root:root afterwards.
<rburton> (i'd normally say never do that)
<qschulz> mmmm install -d does too: "treat all arguments as directory names; create all components of the specified directories"
<qschulz> so whatever :p
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
<olani[m]> Tyaku: Your not supposed to need STAGING_DIR_TARGET in the pc file. But maybe there is something in your package that defeats the OE setup.
<Tyaku> olani[m]: Currently I don't use .pc file (i focussed on building my software, I will see this later). So currently in the recipe B I set TARGET_CFLAGS with -I${STAGING_DIR_TARGET}/${includedir}/matter
<Tyaku> Just for information, I succesfully arrived to build and helloword app, that use the library and some includes from recipe A (chip/matter) and call a function from this library to display some logs.
<olani[m]> Tyaku: That's fine, I just thought you said you needed STAGINIg_DIR_TARGET in the pc file above.
<Tyaku> [1616581530.038811][601:601] CHIP:-: TestingTask started!
<Tyaku> Ok, But what I did is not good: 1. Because i only installed the includes from directories that i need to run the helloworld... 2. Because i have to do this install process directly in the recipe ... (as rburton remark, there is an issue to do it directly in CHIP GN Build system). 3. I don't use pkg-config.
<rburton> matter doesn't set a pkgconfig file, so ignore that
<olani[m]> Yeah, I did not realize that this was a package that was not your own. I'd say having install statements in the recipe is fine in this case.
<olani[m]> Have you tried using #include <matter/header.h> instead of using -I flags?
mihai- has joined #yocto
mihai- has quit [Remote host closed the connection]
mihai has quit [Read error: Connection reset by peer]
bunk has quit [Ping timeout: 252 seconds]
Guest27 has quit [Ping timeout: 256 seconds]
<Tyaku> olani[m]: There is no such file, but in fact I put 4 include_directories because I don't control how the elements are included. In libCHIP.a, there are files where the #include start from "src" folder, sometimes it's from "lib" folder, sometimes it's from a generated folder [..]
jmiehe has joined #yocto
<JosefHolzmayr[m]> reminder, its less than an hour until ndec_ and me will be live for you at https://events.linuxfoundation.org/mentorship-session-its-not-just-about-embedded-the-yocto-project/
vmeson has joined #yocto
tre has quit [Remote host closed the connection]
<olani[m]> Tyaku: header.h was just an example. If you install the files to /usr/inlcude/matter it should be possible to #include them with matter/ prefix. That way you get nice namespacing and do not need the -I-flag
zyga-mbp has joined #yocto
<rburton> personally i'd be asking the matter support channels how you're meant to install it
bunk has joined #yocto
bunk has quit [Client Quit]
Tyaku has quit [Quit: leaving]
Tyaku has joined #yocto
Tyaku has quit [Client Quit]
Tyaku has joined #yocto
Tyaku has quit [Client Quit]
Tyaku has joined #yocto
frieder has quit [Ping timeout: 268 seconds]
frieder has joined #yocto
<user_123> Hi
bunk has joined #yocto
<user_123> I have one question regarding usage of sharepoint/one drive in Yocto instead of ftp links
<user_123> How to use share point sharepoint OR ondrive links in yocto
<user_123> and store the supporting file for image build in these
whuang0389 has joined #yocto
<ThomasD13> Hi, maybe a dumb question: When I create my own machine configuration, is it possible to specify there the kernel which should be used? I would like to get away from all the kernel-recipes of my vendor TI
<Tyaku> About CHIP/Matter, I found that they have something related to pkg-config in their sources. https://github.com/project-chip/connectedhomeip/tree/master/build/config/linux I'm going to check, it's possible that the .py script build it
<qschulz> ThomasD13: yes,PREFERRED_PROVIDER_virtual/kernel = "<linux-recipe>" and/or PREFERRED_VERSION_virtual/kernel = "<linux-recipe-version>"
<JPEW> We are seeing a problem where a packagegroup doesn't rebuild when a package it pulls in bumps major versions; this causes it to look for the old library version when restored from sstate (e.g. libfoo0 when the new one is libfoo1) and causes a build failure. Does this sound famililar?
<JPEW> It seems like it might have been fixed in a more recent version of Yocto and I'd like to backport the fix but I cannot seem to find it
<ThomasD13> thanks qschulz! A second question: The vendor add a lot of patches and config fragments for their kernel version. Can I somehow prevent the application of these patches via my own (maybe with higher priority) layer? Is that a "clean" way to do it?
dmoseley has quit [Quit: ZNC 1.8.2 - https://znc.in]
<manuel1985> Hello all. I intend to runqemu with kernel parameters supplied using bootparams=. Then I have systemd service which starts the ptest tests when the condition is fulfilled. Basically, on my devmachine I want to do a "kas shell -c runqemu bootparams=runtests kas-config.yml" and have qemu boot up and run the tests.
<manuel1985> What are your opinions? Are there better ways to do this?
<manuel1985> Is there existing functionality I can leverage?
vd has quit [Quit: Client closed]
<qschulz> ThomasD13: if you use a differnet kernel recipe, the patches and config fragments won't apply to your new recipe
<qschulz> ThomasD13: if we're talking about vendor-kernel-specific changes to non-kernel recipes, I think you better start from scratch and ditch your vendor layer and start your own :)
<Tyaku> I'm watching webbinar :)
<tlwoerner> wow, this is pretty stupid. i'm trying to register for ndec_ and JosefHolzmayr[m] talk, but because my company's name isn't in their preset dropdown list, it won't let me register
vd has joined #yocto
<tlwoerner> so in order to register i'll have to pick a name of a company that i don't actually work for, one that's in their prepopulated list
<tlwoerner> i chose "yocto project" ;-)
gsalazar_ has joined #yocto
gsalazar has quit [Ping timeout: 252 seconds]
<ndec_> tlwoerner: heh..
dmoseley has joined #yocto
sakoman has joined #yocto
<ThomasD13> qschulz, thanks, I have to think about it. Not sure which mess is less :)
<qschulz> ThomasD13: it all depends how much you need from the vendor BSP layer. Usually it's machine conf file, kernel, and bootloader stuff. Those you can manually import in your own layer
ThomasD13 has quit [Ping timeout: 252 seconds]
fray has quit [Ping timeout: 265 seconds]
fray has joined #yocto
koty0f has joined #yocto
dmoseley has quit [Quit: ZNC 1.8.2 - https://znc.in]
koty0f_ has joined #yocto
koty0f has quit [Ping timeout: 252 seconds]
koty0f_ has quit [Client Quit]
koty0f_ has joined #yocto
koty0f_ is now known as koty0f
koty0f has quit [Client Quit]
koty0f has joined #yocto
fray has quit [Ping timeout: 252 seconds]
fray has joined #yocto
whuang0389 has quit [Quit: Client closed]
Tyaku has quit [Quit: leaving]
kayterina has quit [Remote host closed the connection]
gsalazar_ is now known as gsalazar
frieder has quit [Ping timeout: 268 seconds]
Belsirk has quit [Remote host closed the connection]
manuel1985 has quit [Quit: Leaving]
nerdboy has quit [Ping timeout: 260 seconds]
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #yocto
nerdboy has joined #yocto
nerdboy has joined #yocto
nerdboy has quit [Changing host]
koty0f has quit [Ping timeout: 268 seconds]
zpfvo has quit [Remote host closed the connection]
dev1990 has joined #yocto
amitk has quit [Ping timeout: 252 seconds]
florian has quit [Quit: Ex-Chat]
jmiehe has quit [Quit: jmiehe]
behanw has joined #yocto
vd has quit [Ping timeout: 256 seconds]
gsalazar has quit [Ping timeout: 265 seconds]
Guest53 has joined #yocto
leon-anavi has quit [Quit: Leaving]
bunk has quit [Quit: leaving]
<fray> the case on the right looks a lot like someone turned on the static user id code
<fray> but it's not on, one ht left
* RP suspects an sstate hash issue with the static-group/passwd files from meta-selftest
<fray> lol, there we go.. has static group/passwd seems odd
<RP> fray: perhaps the task checksum isn't accounting for that being turned on
<fray> maybe, I hadn't thought of that..
<RP> fray: the selftest static files use 522 as the number
<fray> looks like anon pthing is updating the configs. So maybe this is hiding it from the hash processing
<fray> 'er.. anon python
<RP> hmm, I'd expect the code to be able to see the result
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
troth has joined #yocto
koty0f has joined #yocto
bunk has joined #yocto
vd has joined #yocto
<vd> do you usually find conf fragments in conf/include/* or does it have to be specific like conf/distro/include?
dmoseley has joined #yocto
<RP> vd: depends on the context
mranostaj has quit [Ping timeout: 268 seconds]
<vd> RP: I'm customizing the build, like adding OVERRIDES, changing IMAGE_LINK_NAME and a few other things based on BB_CURRENT_MC for various multiconfig. It is currently in the distro, but it doesn't feel right
dmoseley has quit [Ping timeout: 260 seconds]
<RP> vd: those do sound like distro things
<RP> rburton, JPEW, sgw: Could someone have a look at and ack "create-spdx.bbclass: Search all license directories for license" please?
<vd> RP: like setting IMAGE_LINK_NAME "${IMAGE_BASENAME}" so that it's simpler to reference (and embed) an image into another. Where would you put such configuration? conf/distro/include/mybuild.inc?
<vd> (IMAGE_LINK_NAME = *)
<RP> vd: it is part of your distro setup
<RP> I mean you can put it where you like but it is really distro config
<vd> ok. I was a bit confused with the fact that image/machine/distro must be orthogonal, I felt like I couldn't easily test another distro like poky with my images, but I guess flexibility has its limits
<vd> what I mean is that by referencing IMAGE_LINK_NAME (thus IMAGE_BASENAME) in my image recipes, they kinda become distro specific, but well you're right it's part of my distro anyway.
<RP> vd: your images are probably strongly tied to your distro but as you say, at some point it isn't generic
<vd> indeed
mranostaj has joined #yocto
<vd> especially since they do require to inherit a few class, which makes them even less generic
* vd says goodbye to core-image-minimal
<vd> The meaning of "distro" in OpenEmbedded is often a concern, I guess one must see it more as a "build" configuration in fact.
dmoseley has joined #yocto
<RP> distro is the policy/configuration effectively
dmoseley has left #yocto [#yocto]
<RP> kanavin: how are the deprecation fixes looking?
<vd> so "ideally" image/distro/machine should be orthogonal, but it's rarely the case in the real world, right?
<JPEW> vd: You can keep them pretty orthagonal... it can take a little work though
<RP> vd: it definitely can be done, it likely just isn't worth it to you for your images
<vd> ok, thanks a lot.
<kergoth> I wouldn't go as far as to say it's rarely the case. Fairly common for new users to take shortcuts in that area until/if they realize the benefits of it, however
dmoseley has joined #yocto
agrue has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
agrue has joined #yocto
<JosefHolzmayr[m]> RP: concerning the sstate thing from earlier - should qemu also be pulled?
<RP> JosefHolzmayr[m]: depends if your configuration matches what the autobuilder builds
<JosefHolzmayr[m]> RP: hmmm
dmoseley_ has joined #yocto
dmoseley_ has quit [Client Quit]
dmoseley_ has joined #yocto
<JosefHolzmayr[m]> seems i missed the assume provided for libsdl2
dmoseley_ has quit [Client Quit]
manuel has joined #yocto
<manuel> Hi all! I'm creating an image for qemux86-64. When finishing the build, bitbake spends quite some time in do_image_tar. Is that necessary, when the image is only run in qemu?
<manuel> I understand qemu accesses the .ext3 file
manuel is now known as manuel1985
<JosefHolzmayr[m]> manuel: probably not exactly necessary.
manuel1985 is now known as manuel
<JosefHolzmayr[m]> what do you defined as "quite some time"?
<manuel> A minute or so
<manuel> Can I disable it?
<JosefHolzmayr[m]> IMAGE_FSTYPES = "ext3" in local.conf to try. in the long run you might want to derive your own qemu version as MACHINE and set it there.
koty0f has quit [Quit: Konversation terminated!]
<manuel> Thanks!
zyga-mbp has joined #yocto
zyga-mbp has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jmiehe has joined #yocto
Starfoxxes has joined #yocto
dmoseley_ has joined #yocto
dmoseley_ has quit [Client Quit]
florian has joined #yocto
vd has quit [Quit: Client closed]
vd has joined #yocto
jmiehe has quit [Quit: jmiehe]
<RP> kergoth: an interesting dilemma: DESCRIPTION_abc = "Refer to ${DESCRIPTION}", OVERRIDES = "abc", getVar("DESCRIPTION")
<RP> Only "works" today since package.bbclass flattens variable references badly in emit_packagedata and I just tried to fix that
alex88 has quit [Ping timeout: 240 seconds]
alex88_ has joined #yocto
amitk has joined #yocto
<vd> multiple overrides works, right? FOO_append_a_b is applied if and only if OVERRIDES contains both "a" and "b", correct?
<RP> vd: yes
* RP takes a wild guess that changing the way DESCRIPTION and SUMMARY work at M4 would not go down well
leon-anavi has joined #yocto
<ant__> RP: sigh..like IMAGE_FSTYPE...all is set in a random class...
dmoseley_ has joined #yocto
dmoseley_ has quit [Client Quit]
vd has quit [Quit: Client closed]
<ant__> well, the original sinner was IMAGE_FSTYPES_collie :)
<RP> fray: I think I found the issue for the user corruption and a fix that hopefully doesn't break too much else
* RP sends a patch out
<fray> excellent.. I'll tkae a look
bluearc has joined #yocto
amitk has quit [Ping timeout: 268 seconds]
dmoseley_ has joined #yocto
dmoseley_ has quit [Client Quit]
<RP> The trouble was the pkgdata was identical for both dynamic and static cases with the recent do_package reproducibility improvements so it matched them up and accelerated the build with it
dmoseley_ has joined #yocto
dmoseley_ has quit [Client Quit]
leon-anavi has quit [Quit: Leaving]
<fray> Ya,.. I can't say I completely undertand the fix, but I think I get the general idea..
Dracos-Carazza has quit [Quit: ZNC 1.8.2 - https://znc.in]
Dracos-Carazza has joined #yocto
Guest53 has quit [Quit: Client closed]
yannd has joined #yocto
otavio has quit [Remote host closed the connection]
jwillikers has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
otavio has joined #yocto
gioyik has joined #yocto
florian has quit [Ping timeout: 268 seconds]
goliath has quit [Quit: SIGSEGV]
gioyik has quit [Ping timeout: 276 seconds]