Monday, 2020-11-16

*** la_croix <la_croix!> has quit IRC00:06
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto00:13
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto00:18
*** B0ned1ger2 <B0ned1ger2!> has quit IRC00:27
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto00:27
*** B0ned1ger2 <B0ned1ger2!> has quit IRC00:33
*** mccc <mccc!> has quit IRC00:47
*** mccc <mccc!> has joined #yocto00:48
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto01:04
JPEWRP: Weird. I'll try again.01:08
*** B0ned1ger2 <B0ned1ger2!> has quit IRC01:09
*** paulg <paulg!> has quit IRC01:36
*** sakoman <sakoman!> has quit IRC01:37
*** paulg <paulg!> has joined #yocto01:48
*** sakoman <sakoman!> has joined #yocto01:50
*** mbulut <mbulut!> has quit IRC02:07
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto02:15
*** sakoman <sakoman!> has quit IRC02:26
*** oberstet <oberstet!~oberstet@> has quit IRC02:40
*** kaspter <kaspter!~Instantbi@> has joined #yocto02:43
*** paulg <paulg!> has quit IRC02:46
*** paulg <paulg!> has joined #yocto02:46
*** sakoman <sakoman!> has joined #yocto03:09
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:903e:ec14:9322:a5cf> has joined #yocto03:10
*** ahadi <ahadi!> has quit IRC03:10
*** ahadi <ahadi!> has joined #yocto03:12
*** sakoman <sakoman!> has quit IRC03:27
*** davisr_ <davisr_!davisr@gateway/vpn/protonvpn/davisr> has joined #yocto04:11
*** davisr <davisr!> has quit IRC04:14
*** dreyna <dreyna!~dreyna@2601:646:4201:e280:903e:ec14:9322:a5cf> has quit IRC04:22
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC04:24
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto04:31
*** stacktru1t <stacktru1t!> has quit IRC04:36
*** stacktru1t <stacktru1t!> has joined #yocto04:38
*** wooosaii <wooosaii!> has joined #yocto05:02
*** wooosaiii <wooosaiii!> has quit IRC05:04
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC05:11
*** cp- <cp-!> has quit IRC05:34
*** cp- <cp-!> has joined #yocto05:40
*** jobroe <jobroe!> has joined #yocto05:41
*** cp- <cp-!> has quit IRC05:51
*** cp- <cp-!> has joined #yocto05:56
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto06:03
*** B0ned1ger2 <B0ned1ger2!> has quit IRC06:08
*** ThomasD13 <ThomasD13!> has joined #yocto06:09
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto06:12
*** B0ned1ger2 <B0ned1ger2!> has quit IRC06:14
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto06:15
*** beneth <beneth!> has joined #yocto06:19
*** opello <opello!~opello@about/csharp/regular/opello> has quit IRC06:42
*** opello <opello!~opello@about/csharp/regular/opello> has joined #yocto06:42
*** AndersD <AndersD!> has joined #yocto06:43
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:02
*** pharaon2502 <pharaon2502!> has joined #yocto07:07
*** pohly <pohly!> has joined #yocto07:13
*** B0ned1ge_ <B0ned1ge_!> has joined #yocto07:13
*** B0ned1ger2 <B0ned1ger2!> has quit IRC07:16
*** SWAT <SWAT!~swat@ubuntu/member/swat> has joined #yocto07:20
*** frsc <frsc!> has joined #yocto07:30
*** mckoan|away is now known as mckoan07:35
mckoangood morning07:35
*** mckoan <mckoan!> has quit IRC07:35
*** mckoan <mckoan!~marco@unaffiliated/mckoan> has joined #yocto07:35
*** agust <agust!> has joined #yocto07:38
*** DanmerZ <DanmerZ!~op@> has joined #yocto07:40
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has joined #yocto07:44
*** fl0v0 <fl0v0!~fvo@> has joined #yocto07:57
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:81e0:bf3d:17e5:5b09> has joined #yocto08:06
*** kaspter <kaspter!~Instantbi@> has quit IRC08:09
*** kaspter <kaspter!~Instantbi@> has joined #yocto08:10
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC08:13
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has joined #yocto08:14
*** AndersD <AndersD!> has quit IRC08:18
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto08:26
*** oberstet <oberstet!~oberstet@> has joined #yocto08:28
*** eduardas <eduardas!~eduardas@> has joined #yocto08:37
eduardashello, yocto does not allow me to set INITRAMFS_IMAGE = "core-image-minimal-initramfs" for my armv7 kernel recipe08:39
*** Yumasi <Yumasi!> has joined #yocto08:40
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has quit IRC08:41
*** mbulut <mbulut!> has joined #yocto08:45
*** frsc <frsc!> has quit IRC08:46
*** rubdos <rubdos!~rubdos@2a02:578:859d:700:8b44:5716:382d:a7da> has joined #yocto08:47
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto08:48
eduardasis there no standard image recipe in poky that is usable for initramfs that can be run on an ARM platform?08:48
*** frsc <frsc!> has joined #yocto08:54
*** Yumasi <Yumasi!> has quit IRC08:55
*** ribalda <ribalda!sid306640@gateway/web/> has quit IRC08:58
*** ribalda <ribalda!sid306640@gateway/web/> has joined #yocto08:58
*** faba_ <faba_!> has joined #yocto08:59
*** Yumasi <Yumasi!> has joined #yocto09:00
*** leon-anavi <leon-anavi!~Leon@> has joined #yocto09:04
*** creich <creich!> has quit IRC09:13
*** creich <creich!> has joined #yocto09:14
*** alinucs <alinucs!> has quit IRC09:15
*** alinucs <alinucs!> has joined #yocto09:15
*** qschulz <qschulz!> has quit IRC09:16
*** Yumasi <Yumasi!> has quit IRC09:16
*** ptsneves <ptsneves!b0dd7824@> has joined #yocto09:20
*** Yumasi <Yumasi!> has joined #yocto09:21
*** qschulz <qschulz!> has joined #yocto09:22
*** dv <dv!~dv@> has joined #yocto09:26
dvI have IMAGE_INSTALL += "myrecipe". What if I have no "myrecipe" in my layer? How can I make it "recommended" to be able to build image without it without commenting out the line in my image file?09:28
LetoThe2nddv: where do you even have that? there are recommends for distro and machine, but not for images09:29
LetoThe2ndcompletely unrelated, shameless plug:
dvLetoThe2nd, I have it in my image .bb file... need to make it optional if recipe file is not exist09:30
LetoThe2nddv: sounds fishy. either your image needs it, or it doesn't. this would introduce different behaviours if a laer exists or not. I guess you can do with some black python magic, but i would strongly discourage it. plus, it tries to break the restriction of one recipe (even though just through pure exitence) affects another (the image)09:32
LetoThe2nddv: so my gut feeling (very strong!!!) is that your line of thinking is flawed somewhere.09:33
LetoThe2nddv: if at all, then this could go into the RRECOMMENDS for the distro your image builds for.09:34
*** Yumasi <Yumasi!> has quit IRC09:36
dvLetoThe2nd, yes. the layer with this recipe may not exist. why yocto doesn't have this simple feature?09:38
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:38
LetoThe2nddv: if you think that it needs this feature, then why don't you send a simple patch for the simple feature?09:39
LetoThe2nddv: seriously, i have outlined some problems with your approach, as given pointers how to address them.09:39
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto09:40
LetoThe2nddv: you could also try a cross-layer include in your image into the maybe-existing layer which adds it, and silently does nothing if its not there.09:40
LetoThe2nddv: but still i am convinced that the approach is just plain wrong.09:40
dvLetoThe2nd, how whould you do this if you don't like to create one more imtermediate layer?09:41
dvand without python black magic?09:41
eduardasboot halts for initramfs with "Warning: unable to open an initial console" even though I have devtmpfs enabled in kernel09:42
*** Yumasi <Yumasi!> has joined #yocto09:42
LetoThe2nddv: *sigh* i would not do that at all. if i bulid a speicifc image, then i expect it to have all the things that i set in IMAGE_INSTALL, and totally fail if it can't find them.09:42
eduardasinitramfs is built based on configs similar to poky-tiny09:43
dvLetoThe2nd, thanks09:43
eduardasnot sure what I'm doing wrong09:43
LetoThe2nddv: you're trying to abuse a feature that is not there. like i said, some RRECEOMMENDS trickery might do what you want - feel free to read up and meditate on
LetoThe2nddv: but it comes at the total drawback of anybody who gets to use this will be confused.09:45
ptsnevesif you want to do trickery you might as well create a dummy recipe which delivers the package but fails to install in the IMAGE_INSTALL if it is used09:49
ptsnevesthis way you can keep the IMAGE_INSTALL and you create a broken image if it is used...I might add this is really not a good idea though.09:50
dvptsneves, thank you!09:50
ptsnevesyou have an image recipe depending on a package you know will not be there it is normal that it fails. Working around that is not healthy09:51
dvSeems, I just have to write the manual for the users to comment-out one line in the image recipe if they are building without private layer09:51
ptsnevesoh and the dummy recipe can even have a bbfatal  in the install tasks if it is used.09:52
ptsnevesthere you could write out there is supposed to be a private layer providing a propper version of the recipe or a bbappen overwriting the task09:52
*** florian_kc is now known as florian09:54
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC10:05
*** dleppich <dleppich!~Thunderbi@> has joined #yocto10:07
yannRP: I'd like to talk about proper design of a yarn fetcher, git suggests you'd be the right person, is that correct ?10:07
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:e591:462d:1665:270> has joined #yocto10:07
yannwell, fetcher for bitbake, that is10:07
* LetoThe2nd just misread this as "a yann fetcher"... which is kind of funny.10:12
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto10:13
yannhey, getting people to fetch me is a nice idea to escape lockdown rules :)10:13
*** B0ned1ge_ <B0ned1ge_!> has quit IRC10:16
*** dv <dv!~dv@> has quit IRC10:24
*** B0ned1ger2 <B0ned1ger2!> has quit IRC10:24
*** ptsneves <ptsneves!b0dd7824@> has quit IRC10:27
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto10:28
*** Yumasi <Yumasi!> has quit IRC10:28
*** Yumasi <Yumasi!> has joined #yocto10:30
RPyann: that is probably right, yes :)10:33
*** ptsneves <ptsneves!b0dd7824@> has joined #yocto10:33
*** PaowZ <PaowZ!~vince@2a01:e35:2e3e:4ac0:3db0:901c:d6c5:9ec> has joined #yocto10:34
yannRP: the problem is they store the dependencies in a package.json which can include other files, and pinned versions of those in a separate yarn.lock file.  This has lead me to a nasty do_fetch stage that unpacks the source in tmpdir to run yarn there to get it to fetch the deps in its own cache (new dir under DL_DIR), and then do_unpack makes yarn use that cache.  This is a first thing that would want an improvement, and for which I lack further ideas, but10:39
yannthat's not the worst.10:39
RPyann: this has generally been the challenge with node, crates and so many of the modern approaches don't like to "declare" what they're doing :/10:40
yannThe problem I have is cleany separating the (git) fetch of the main package from the one of the deps.  Today our yarn fetcher derives from GitSM (which is arguably a ad-hoc design), and only rely on the donestamp from git, which causes issues (I guess I can overload those to add by-yarn.lock-cksum donestamps ), but that won't help separate from GitSM10:43
*** Yumasi <Yumasi!> has quit IRC10:44
yannIt would be better to let the recipe specify its normal source URI in the usual way, and then add a yarnlock:// URI, but the fact that file is usually shipped in main package, and requires all those package.json files, seems to bring to a deadend10:45
*** oberstet <oberstet!~oberstet@> has quit IRC10:46
RPyann: certainly gitsm can be used for inspiration but it did solve particular challenges submodules had so it may not be the way to solve for yarn10:48
RPyann: has anyone ever mentioned this upstream to the developers? Did they give any hints about how it could work? Did debian or other distros find a way to work around this?10:49
* RP is just throwing out ideas...10:49
*** Yumasi <Yumasi!> has joined #yocto10:50
yannwell, on Debian side we have the dh-make packaging helper which can extract dependency information from some of those metadata, but distro policy is "only one version of each package", which translates here in "all deps must be packaged first", and there is no "recursive dh-make" I know of which would do that10:54
yannanyway, those tools are only helpers and they occasionally guess wrong and their output needs manual tuning10:54
yannthe end result is that many complicated packages (eg. electron) just don't make in any distro - anyway they wouldn't be used by the devs in the target ecosystem10:56
yannI have no clue in the case of yarn if anyone approached them, but I'm not sure anything could be done anyway - this "independent package manager" thing seems quite trendy (did you notice Qt6 is going to have one too?)10:59
*** faba_ <faba_!> has quit IRC10:59
*** faba_ <faba_!~faba_@2a02:8109:a0c0:5428:a4ba:8286:463d:4e31> has joined #yocto10:59
RPyann: sounds like debian has the same problems bitbake has then :/11:00
yannyeah, everyone has them, noone packages electron :)11:00
RPyann: we might get to try and break new ground then...11:01
*** Yumasi <Yumasi!> has quit IRC11:05
yannGetting packages "properly packaged" one at a time to avoid duplication maybe does not make sense for yocto anyway. Apps use things like yarn.lock or npmsw to make sure the users get the same versions of their deps as they do to make sure it will work.  This is narrow-minded and notably disregards security management, and the end product is sort-of statically linked, which allows them to optimize the output somehow.11:08
yannI'm not sure of any major nodejs app packaged in Debian, for which we could check if there is any noticeable perf/ram-consumption downsides when compared to the statically-"linked" version11:11
RPyann: I thought we'd moved to a model where we tried just to ensure it was a "snapshot" of the source. The key thing wasn't deduplication but ensuring that a build in three years time would show the same thing, i.e. reproducibility11:11
*** Yumasi <Yumasi!> has joined #yocto11:11
RPyann: Have you looked at what rust is doing btw? That fetcher is out of tree but likely to merge in 3.311:11
yanndid not look, will have a look11:11
RPyann: paulbarker reviewed it and said it seemed to be doing the right things to be mirrorable and so on11:12
yannthe reproducibilty aspect is apparently well-handled by things like yarn.lock and npmsw11:12
* paulbarker reads...11:13
paulbarkerFor Rust there is the `cargo bitbake` tool which parses the Cargo.toml file containing metadata, dependencies, etc and then creates a recipe from that11:14
paulbarkerSo that parse step to find dependencies, etc happens in advance11:14
paulbarkerAnd the recipe encodes that data so the fetcher can be simple11:14
paulbarker`cargo-bitbake` is written in Rust so I won't point at it but I will link a couple of recipes and the fetcher11:15
paulbarkerRecipe for a Rust app with dependencies:
paulbarkeryann: ^^^11:17
yannthx paulbarker11:19
*** Yumasi <Yumasi!> has quit IRC11:26
*** Yumasi <Yumasi!> has joined #yocto11:31
*** berton <berton!> has joined #yocto11:43
*** dleppich <dleppich!~Thunderbi@> has quit IRC11:43
*** dleppich <dleppich!~Thunderbi@> has joined #yocto11:44
*** JaMa <JaMa!> has joined #yocto11:46
*** Yumasi <Yumasi!> has quit IRC11:47
*** dreyna <dreyna!> has joined #yocto11:48
RPpaulbarker: thanks! It does sound like its doing a reasonable job at handling things11:48
paulbarkerRP: I think it's pretty good. Proposing it to bitbake itself near the top of my todo list, I'll need to write a couple of test cases for it first11:49
paulbarkerRP: The fact that monkey patching it in via a bbclass works did shock me:
RPpaulbarker: it sounds like it'd be a good addition and is in reasonable shape11:50
RPpaulbarker: they dynamic patching you can do is actually scary. I keep quiet as I don't want to encourage it11:51
*** Yumasi <Yumasi!> has joined #yocto11:53
*** pharaon2502 <pharaon2502!> has quit IRC11:56
*** Yumasi <Yumasi!> has quit IRC12:07
*** Yumasi <Yumasi!> has joined #yocto12:13
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto12:26
*** Yumasi <Yumasi!> has quit IRC12:29
*** caiortp <caiortp!> has joined #yocto12:30
*** Yumasi <Yumasi!> has joined #yocto12:34
*** LetoThe2nd <LetoThe2nd!uid453638@gateway/web/> has quit IRC12:42
*** rfried <rfried!~rfried@> has joined #yocto12:48
rfriedHey. I have a package that is being build and I don't seem to find where it's configured for being included in the distribution.12:49
rfriedIs there a command I can use to figure that out ?12:49
rfriedI think it's probably a dependency of something, but I can't seem to figure out of what.12:49
nohithello, im trying to make my own distribution based on this
*** pharaon2502 <pharaon2502!> has joined #yocto12:51
nohiti have my own layer and this conf file
nohitbut when im trying to initialize the build enviroment with "DISTRO=atlinux-eglfs MACHINE=stm32mp1 source layers/meta-st/scripts/" i get this error message: [ERROR] No 'atlinux-eglfs.conf' file available in layers/meta-st12:53
qschulzrfried: easiest way is to either remove the recipe completely and see what fails to build, or add PACKAGE_EXCLUDE = "whatever" in your local.conf12:53
qschulznohit: wondering if your path shouldn't just be include conf/distro/openstlinux-eglfs.conf12:54
qschulz(the include is relative to **any** layers root12:54
nohitok ill try that, thanks12:54
qschulzwhat's the name of your conf file btw?12:55
qschulzare you also sure your layer is correctly named and added to bblayers.conf?12:55
rfriedqschulz: thanks.12:57
qschulznohit: and you've put it into meta-mylayer/conf/distro/ right?12:57
nohitpath correction didnt help12:59
*** faba_ <faba_!~faba_@2a02:8109:a0c0:5428:a4ba:8286:463d:4e31> has quit IRC13:02
ptsnevesI have libarchive depending on zstd. On another recipe X there is a DEPENDS on libarchive. I would expect that libzstd would be in the sysroot due to X depending on libarchive. The dependency even shows on the pn-depends. Even so randomly the libzstd needed by libarchive on linking is not available. Any ideas?13:02
yannhell guys, the dynamic patching to add a fetcher is just insanely useful (even though proper plugability would probably be preferable) - I slap myself for not thinking about it and maintaining a branch of the poky repo just for our yarn fetcher...13:03
qschulznohit: debug their layers/meta-st/scripts/ script, it;s not original poky13:04
*** faba_ <faba_!> has joined #yocto13:06
*** Yumasi <Yumasi!> has quit IRC13:09
*** Yumasi <Yumasi!> has joined #yocto13:15
nohitqschulz: seem that if i dont give the distro variable while initializing the build environment it works13:19
nohitif i just change it in local.conf13:20
*** B0ned1ger2 <B0ned1ger2!> has quit IRC13:27
*** B0ned1ge_ <B0ned1ge_!> has joined #yocto13:27
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto13:33
yannRP, paulbarker: I guess the approach for yarn has to be a bit different than for crate: I fear we cannot get into individual deps fetching without messing with how yarn internally manages them (of which I have near to no clue). I can see the upside of the approach, though13:38
RPyann: fair enough, I just thought it worth looking at. I don't know enough to help unfortunately13:47
*** Yumasi <Yumasi!> has quit IRC13:49
*** Yumasi <Yumasi!> has joined #yocto13:49
yanndoing something similar would be great though, I'll have a quick look just in case13:52
*** anoo1- is now known as help13:56
*** help is now known as Guest9919113:57
*** Guest99191 is now known as anoo113:57
*** sakoman <sakoman!> has joined #yocto14:01
*** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@> has joined #yocto14:21
*** Dracos-C- <Dracos-C-!~Dracos-Ca@> has joined #yocto14:22
*** dreyna <dreyna!> has quit IRC14:23
*** ssajal <ssajal!> has joined #yocto14:24
*** maudat <maudat!> has joined #yocto14:24
*** Dracos-Carazza <Dracos-Carazza!~Dracos-Ca@> has quit IRC14:25
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:26
*** Dracos-Carazza_ <Dracos-Carazza_!~Dracos-Ca@> has quit IRC14:26
*** ssajal <ssajal!> has quit IRC14:27
*** ssajal <ssajal!> has joined #yocto14:27
*** jobroe_ <jobroe_!> has joined #yocto14:29
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has joined #yocto14:29
*** jobroe <jobroe!> has quit IRC14:29
JPEWRP: Ah, accidentally sent that systemd patch against gatesgarth... pushed a V214:39
RPJPEW: thanks14:54
*** rcw <rcw!~rcwoolley@> has joined #yocto14:56
*** WillMiles <WillMiles!~Will@> has joined #yocto14:56
mcfriskhmm what about removing mozjs from polkit dependencies by using duktape as optional patch in yocto?14:57
JPEWmcfrisk: Ya, I think that would be better long term, since it looks like systemd is moving in the direction of polkit being mandatory. However, IMHO they still have the regression in behavior when not using polkit that needs to be fixed :/14:59
*** ThomasD13 <ThomasD13!> has quit IRC15:00
mcfrisksystemd requiring polkit, that ... is not good, hard to keep tone down15:01
JPEWmcfrisk: Ya, I'm not particularly thrilled either15:01
mcfriskhaving seen mozjs double in binary sizeon rootfs in past few years, now it also affects boot times...15:01
mcfriskJPEW: thanks for your patch!!15:03
JPEWmcfrisk: Ya. I *really* hope upstream takes it15:04
*** ericch <ericch!> has joined #yocto15:06
mcfriskJPEW: hope it helps, I reviewed the patches on systemd side. thanks again!15:13
*** caiortp <caiortp!> has quit IRC15:19
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto15:21
JPEWmcfrisk: Thanks!15:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC15:27
*** rcoote <rcoote!~rcoote@2a02:908:692:81c0:81e0:bf3d:17e5:5b09> has quit IRC15:30
ptsnevesHey guys in cmake.bbclass there is this line: echo "set( CMAKE_FIND_ROOT_PATH ${STAGING_DIR_HOST} ${STAGING_DIR_NATIVE} ${CROSS_DIR} )" >> ${WORKDIR}/toolchain.cmake15:32
ptsnevesThis is allowing a leakage of native libraries into the compilation if for some reason the STAGING_DIR_HOST does not have the library15:32
*** tepperson <tepperson!0cb623bc@> has joined #yocto15:33
ptsnevesi did a git log -S for this line but from what i see it is this way since 2010. Am i missing something?15:33
kergothptsneves: is that necessary to make it able to find the native *binaries*? or is that only for the libraries? binaries from the native sysroot are necessary..15:33
teppersonis there a way to use bmap-tools to resize the last partition to completely fill the target disk?15:33
kergothtepperson: doubtful, you have to resize the filesystem too, no? most folks just set up a service to do it on first boot afaik15:34
kergoth96boards-tools has one, for example15:34
ptsnevesptsneves The point is that i do not think it is correct in any way to have the native library path getting included into a cross compilation.15:34
kergothbut that's not correct. buildsystems *often* need to run host/native tooling to do their builds, or build *for* the host and then run those built tools to cross-compile15:35
kergothyou can't fully isolate15:35
kergothyou can prevent linking against or finding headers on the host, but tools are necessary15:35
ptsnevesdefitely. but i cannot see any reason why native libraries are needed to be included in a cross compilation gcc command15:36
teppersonkergoth: i thought wic write ./blabla/imagefile.wic /dev/whatever --resize=auto could accomplish this,(or does this only resize the partition15:36
kergothhmm, good question15:37
ptsneveskergoth the result is this15:43
ptsneves| /build/tmp/sysroots/x86_64-linux/usr/bin/i686-pc-linux-gnu/../../libexec/i686-pc-linux-gnu/gcc/i686-pc-linux-gnu/9.1.0/ld: /build/tmp/sysroots/x86_64-linux/usr/lib/ error adding symbols: file in wrong format15:43
*** rob_gries <rob_gries!> has joined #yocto15:45
rob_griesHello, I'm attempting to override avahi-daemon.conf with a .bbappend file in my meta-layer, but I cannot seem to override the file and only seem to be able to insert files into the directory via the bbappend file.15:48
ptsnevesfrom my understanding of the documentation this seems like a cmake shortcoming. Could it be that we could put the package configs in the target sysroot and thus not need the native root path ?15:48
*** berton <berton!> has quit IRC15:49
ptsnevesand the compiler of course...because otherwise cmake does not find the compiler15:49
JPEWrob_gries: I think that's a file provided by upstream, not in OE, so you can't override it that way?15:50
JPEWrob_gries: e.g. overriding a file in a bbappend only works for files provided in OE, not files installed by the recipe itself15:51
*** tgamblin <tgamblin!> has quit IRC15:51
rob_griesJPEW: ah that makes sense... What's the most recommended way to fix that?15:51
rob_griesJPEW: this is my bbappend file if it helps --
JPEWrob_gries: install over the upstream provided file in do_install_append()15:52
JPEWrob_gries: Looks like you have a comment to that effect...15:53
rob_griesJPEW: Yeah, I took it out because I was worried about the "multiple recipes affecting a single file problem" but I guess that does not apply to bbappends?15:54
JPEWrob_gries: Ya, as long as the original .bb was providing avahi-daemon.conf, replacing it with a different one in a .bbappend won't cause that problem15:55
*** dreyna <dreyna!> has joined #yocto15:55
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto15:56
kergothrob_gries: see recipetool appendfile and recipetool appendsrcfile15:56
*** berton <berton!> has joined #yocto15:56
kergoththe latter for files coming from oe or the upstream sources, the latter for files on target15:56
kergother, the former for files on target15:56
kergothjust a convenience around the bbappend setup15:56
*** tgamblin <tgamblin!> has joined #yocto15:56
rob_griesJPEW: Thanks, I'll try that out15:56
JPEWrob_gries: FWIW, we are also modifying avahi-daemon.conf, just with a patch on the upstream source.... it might be worth adding support for a custom avahi-daemon.conf in OE-core?15:57
JPEWnote: I like your idea better than patching :)15:57
rob_grieskergoth: are recipetool appendfile and recipetool appendsrcfile available in Yocto Jethro? (I know it's old, but the vendor (Qualcomm) of the BSP will not upgrade it)15:58
kergothoof. no idea :)15:58
*** B0ned1ge_ <B0ned1ge_!> has quit IRC15:59
wyrehi guys, I was trying to boot a yocto image from an sdcard into my embedded system and I'm having a message saying "Could not find a valid device tree"15:59
rob_griesJPEW and kergoth: Thanks, I have an idea what I shall try next.16:00
*** B0ned1ger2 <B0ned1ger2!> has quit IRC16:00
wyrewhat do you think could be the problem?16:01
rob_grieswyre: looks like your dtb is either not existent or invalid, you should check if the DTB is on the card. Also, you should check the path of where the bootcmd 'bootcmd_mmc' is looking for your dtb files16:03
*** eduardas <eduardas!~eduardas@> has quit IRC16:07
*** berton <berton!> has quit IRC16:09
*** tgamblin <tgamblin!> has quit IRC16:09
*** berton <berton!> has joined #yocto16:16
*** fitzsim <fitzsim!> has joined #yocto16:26
*** dleppich <dleppich!~Thunderbi@> has quit IRC16:30
*** kaspter <kaspter!~Instantbi@> has quit IRC16:30
*** kaspter <kaspter!~Instantbi@> has joined #yocto16:31
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto16:33
*** B0ned1ger2 <B0ned1ger2!> has quit IRC16:38
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC16:39
*** kaspter <kaspter!~Instantbi@> has quit IRC16:48
*** kaspter <kaspter!~Instantbi@> has joined #yocto16:48
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto16:57
*** mbulut <mbulut!> has quit IRC17:01
*** gsalazar <gsalazar!955a6fad@gateway/web/cgi-irc/> has quit IRC17:02
*** tgamblin <tgamblin!> has joined #yocto17:06
*** fl0v0 <fl0v0!~fvo@> has quit IRC17:09
*** vineela <vineela!~vtummala@> has joined #yocto17:10
*** tgamblin <tgamblin!> has joined #yocto17:13
*** goliath <goliath!> has quit IRC17:13
*** B0ned1ger2 <B0ned1ger2!> has quit IRC17:15
wyrecould I include some package manager in yocto?17:16
*** goliath <goliath!> has joined #yocto17:17
*** frsc <frsc!> has quit IRC17:19
*** micka <micka!> has quit IRC17:20
*** micka <micka!> has joined #yocto17:31
mckoanwyre: a package manager won't help with this issue though17:34
wyremckoan, which issue?17:35
mckoanwyre: usually the package manager is included by EXTRA_IMAGE_FEATURES += "package-management"17:35
mckoanwyre: the dtb above17:35
wyreoh, you mean the issue with dtb, yeah17:35
wyreno, that issue was solved17:35
mckoanwyre: great. MicroGEA is a good choice17:35
mckoanwyre: happy hacking, time to quit17:36
*** mckoan is now known as mckoan|away17:36
wyrethe problem was the U-boot couldn't find the default device tree of the kernel. But I've fixed this switching the default device tree with editenv17:37
wyreand which package manager will be added if I use that flag in building process?17:46
*** sakoman <sakoman!> has quit IRC17:46
zeddiidepends on what you've configured.17:48
zeddiisee PACKAGE_CLASSES ?= "package_rpm"17:48
zeddiiin your local.conf for option.17:48
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto17:52
*** tgamblin <tgamblin!> has quit IRC17:59
*** sakoman <sakoman!~steve@> has joined #yocto18:01
*** tgamblin <tgamblin!> has joined #yocto18:02
*** jobroe_ <jobroe_!> has quit IRC18:05
wyrezeddii, just deb and rpm classes are supported?18:19
wyreand what about the sources?18:19
zeddiithey are listed in your local.conf template. there's deb, rpm and ipk18:19
*** rob_gries <rob_gries!> has quit IRC18:21
*** megabread <megabread!~megabread@2a01:4b00:e031:2600:e591:462d:1665:270> has quit IRC18:26
wyrezeddii, so could I get a kind of Debian based on yocto?18:27
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC18:29
zeddiiyou could produce your own .debs, which are packaged based on the oe/yocto recipes. And you'd have your own package feed to grab packages from. The similarity is the package format, and that's about it. For updates, etc, you need to maintain your own feed.18:30
*** dmoseley` <dmoseley`!~user@> has joined #yocto18:30
*** dmoseley` <dmoseley`!~user@> has left #yocto18:30
wyrezeddii, so you could, for example, package your own kernel and manage it through the package manager?18:32
*** goliath <goliath!> has quit IRC18:32
*** goliath <goliath!> has joined #yocto18:33
zeddiiyes. of course, you picked the hardest thing to package / manage on target for upgrades :D But AFAIK in master, we have all the right changes to now have conflicting kernels, etc, if you do it via package updates.18:34
wyrezeddii, "to now have conflicting kernels"? what do you mean?18:36
wyreand what's the link to the repo?18:37
zeddiithe way the kernels were packaged in the past, you could only have one installed at a time, and that made some upgrades problematic. I think all the update-alernatives, symlinks, etc,18:37
zeddiiare right now, but I haven't done it in a while. So I can't say18:37
zeddiithere's no global repo, like debian, it would be your own.18:38
zeddiithe yocto mega manual discusses the setup, IIRC.18:38
wyreoh, I ask because you said "in master, we have all the right changes ..."18:38
zeddiimeaning I don't know about any older releases, since I haven't tested it. but what's in the master branch of oe-core should work.18:39
wyrezeddii, and what's that master branch of oe-core?18:41
zeddiiif you are cloning poky to build, you are getting it as part of that (meta/ and some other directories). which I assume you are, since you asked that question.18:42
wyrezeddii, well, I'm using the BSP provided by the manufacturer18:43
zeddiithen I have no idea :D18:43
zeddiiI'm sure they are bundling up some random version, but I can't comment on that.18:43
wyrezeddii, it mainly includes a vmware image for an Ubuntu where are these files18:43
wyreI'm considering to use the crops docker container 🤔18:44
*** dmoseley <dmoseley!~dmoseley@> has quit IRC18:45
*** dmoseley <dmoseley!~dmoseley@> has joined #yocto19:13
*** dmoseley` <dmoseley`!~user@> has joined #yocto19:13
*** dmoseley` <dmoseley`!~user@> has left #yocto19:13
*** Guest84242 <Guest84242!khemmatrix@gateway/shell/> has quit IRC19:16
*** Guest84242 <Guest84242!khemmatrix@unaffiliated/khem> has joined #yocto19:16
*** Guest84242 <Guest84242!khemmatrix@gateway/shell/> has joined #yocto19:16
*** Guest84242 is now known as khem19:16
*** roussinm <roussinm!> has joined #yocto19:18
*** mprokos <mprokos!> has joined #yocto19:21
*** mprokos is now known as rabbit991119:23
rabbit9911How is the workdir determined between machine specific packages and generic?19:24
rabbit9911Happy to look at the code that does this but can't find it.19:24
rabbit9911For instance if I check a MACHINE_FEATURE in a recipe does that change the WORKDIR?19:27
*** camus1 <camus1!~Instantbi@> has joined #yocto19:31
*** kaspter <kaspter!~Instantbi@> has quit IRC19:31
*** camus1 is now known as kaspter19:31
*** WillMiles <WillMiles!~Will@> has quit IRC19:35
khemrabbit9911: yes, it looks for MACHINE specific dependencies in recipe metadata and determines it. you can also force it via setting PACKAGE_ARCH explicitly in machine.19:36
rabbit9911khem: thanks! Do you know where that logic is?19:37
*** ptsneves <ptsneves!b0dd7824@> has quit IRC19:56
*** fitzsim <fitzsim!> has quit IRC19:58
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC20:16
rabbit9911khem: In base.bbclass I see some logic that checks the src_uri. I dont se anything that checks for MACHINE_FEATURES20:16
*** tepperson <tepperson!0cb623bc@> has quit IRC20:17
rabbit9911Would this imply that if you have a recipe that checks MACHINE_FEATURES you might want to set PACKAGE_ARCH = "${MACHINE_ARCH}"?20:17
rabbit9911Otherwise sharing a build directory would mean rebuilding that package for each MACHINE?20:18
*** B0ned1ge_ <B0ned1ge_!> has joined #yocto20:36
*** beneth <beneth!> has left #yocto20:38
*** B0ned1ger2 <B0ned1ger2!> has quit IRC20:39
*** B0ned1ge_ <B0ned1ge_!> has quit IRC20:41
*** faba_ <faba_!> has quit IRC20:51
*** bluelightning_ is now known as bluelightning20:54
*** bernardoaraujo <bernardoaraujo!uid179602@gateway/web/> has joined #yocto21:04
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto21:11
*** B0ned1ger2 <B0ned1ger2!> has quit IRC21:16
*** gpanders <gpanders!> has quit IRC21:18
*** gpanders <gpanders!> has joined #yocto21:20
*** mbulut <mbulut!> has joined #yocto21:32
*** roussinm <roussinm!> has quit IRC21:49
*** Ox861726f6c64 <Ox861726f6c64!~Ox861726f@gateway/tor-sasl/ox861726f6c64> has quit IRC21:52
*** ssajal <ssajal!> has quit IRC21:56
*** kpo_ <kpo_!> has quit IRC21:57
*** kpo_ <kpo_!> has joined #yocto21:58
*** pohly <pohly!> has quit IRC22:12
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto22:21
*** Yumasi <Yumasi!> has quit IRC22:30
RPzeddii: I think I've merged the wrong version of the kernel 5.10 patch. Could you send the delta I need please?22:33
*** rewitt <rewitt!~rewitt@unaffiliated/rewitt> has quit IRC22:35
*** Lihis <Lihis!> has quit IRC22:36
*** rewitt <rewitt!~rewitt@unaffiliated/rewitt> has joined #yocto22:36
*** B0ned1ge_ <B0ned1ge_!> has joined #yocto22:36
*** Lihis <Lihis!> has joined #yocto22:36
*** vineela <vineela!~vtummala@> has quit IRC22:36
*** warthog9 <warthog9!> has quit IRC22:36
*** clopez <clopez!> has quit IRC22:36
*** rperier <rperier!~quassel@unaffiliated/bambee> has quit IRC22:37
*** warthog9 <warthog9!> has joined #yocto22:37
*** stkw0 <stkw0!> has quit IRC22:37
*** qschulz <qschulz!> has quit IRC22:38
*** rperier <rperier!> has joined #yocto22:38
*** stkw0 <stkw0!> has joined #yocto22:38
*** clopez <clopez!> has joined #yocto22:38
*** qschulz <qschulz!> has joined #yocto22:39
*** B0ned1ger2 <B0ned1ger2!> has quit IRC22:39
*** B0ned1ge_ <B0ned1ge_!> has quit IRC22:41
*** leon-anavi <leon-anavi!~Leon@> has quit IRC22:42
*** odda <odda!> has joined #yocto22:44
*** vineela <vineela!~vtummala@> has joined #yocto22:44
*** B0ned1ger2 <B0ned1ger2!> has joined #yocto23:08
*** gpanders[m] <gpanders[m]!gpandersma@gateway/shell/> has left #yocto23:10
*** B0ned1ger2 <B0ned1ger2!> has quit IRC23:13
*** rcw <rcw!~rcwoolley@> has quit IRC23:15
*** rcw <rcw!~rcwoolley@> has joined #yocto23:16
*** vineela <vineela!~vtummala@> has quit IRC23:27
*** rcw <rcw!~rcwoolley@> has quit IRC23:53
*** fitzsim <fitzsim!> has joined #yocto23:57
*** kpo_ <kpo_!> has quit IRC23:59
*** kpo_ <kpo_!> has joined #yocto23:59

Generated by 2.17.2 by Marius Gedminas - find it at!