Thursday, 2019-09-26

*** sjolley_ <sjolley_!> has joined #yocto00:54
*** sjolley_ <sjolley_!> has quit IRC01:11
*** learningc <learningc!> has joined #yocto01:25
*** BobPungartnik <BobPungartnik!~BobPungar@> has quit IRC01:38
*** kaspter <kaspter!~Instantbi@> has quit IRC01:39
*** camus <camus!~Instantbi@> has joined #yocto01:39
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto01:40
*** camus is now known as kaspter01:41
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC01:58
*** JaMa <JaMa!> has joined #yocto02:11
*** pdemier <pdemier!> has joined #yocto02:33
*** Lihis <Lihis!> has quit IRC03:03
*** clopez <clopez!> has quit IRC03:04
*** Lihis <Lihis!> has joined #yocto03:05
*** clopez <clopez!> has joined #yocto03:06
*** sgw <sgw!~sgw@> has joined #yocto03:17
*** rburton <rburton!> has quit IRC03:37
*** Domin1k <Domin1k!c1669b04@> has joined #yocto04:07
*** sgw <sgw!~sgw@> has quit IRC04:08
*** georgem_ <georgem_!~georgem@> has joined #yocto04:20
*** georgem <georgem!~georgem@> has quit IRC04:20
*** User_ <User_!> has joined #yocto04:28
*** learningc <learningc!> has quit IRC04:32
*** learningc <learningc!> has joined #yocto04:32
*** User_ <User_!> has quit IRC04:33
*** comptroller <comptroller!> has quit IRC04:56
*** comptroller <comptroller!> has joined #yocto05:01
*** kroon <kroon!~kroon@> has joined #yocto05:08
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has quit IRC05:09
*** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has joined #yocto05:21
*** ECDHE_RSA_AES256 <ECDHE_RSA_AES256!~quassel@unaffiliated/ecdhe> has joined #yocto05:22
*** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has quit IRC05:26
*** comptroller <comptroller!> has quit IRC05:27
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto05:27
*** AndersD <AndersD!> has joined #yocto05:33
*** comptroller <comptroller!> has joined #yocto05:36
*** Domin1k <Domin1k!c1669b04@> has quit IRC05:39
*** comptroller <comptroller!> has quit IRC05:52
*** agust <agust!> has joined #yocto06:00
*** comptroller <comptroller!> has joined #yocto06:05
*** sjolley_ <sjolley_!> has joined #yocto06:09
*** sjolley_ <sjolley_!> has quit IRC06:16
*** comptroller <comptroller!> has quit IRC06:17
*** AndersD <AndersD!> has quit IRC06:19
*** comptroller <comptroller!> has joined #yocto06:21
*** AndersD <AndersD!> has joined #yocto06:21
*** frsc <frsc!> has joined #yocto06:22
*** learningc <learningc!> has quit IRC06:23
*** learningc <learningc!> has joined #yocto06:24
*** thomasd13 <thomasd13!> has joined #yocto06:25
*** TobSnyder <TobSnyder!> has joined #yocto06:34
*** learningc <learningc!> has quit IRC06:35
*** dreyna <dreyna!> has quit IRC06:39
*** comptroller <comptroller!> has quit IRC06:42
*** jmiehe <jmiehe!> has joined #yocto06:49
*** comptroller <comptroller!> has joined #yocto06:59
*** learningc <learningc!> has joined #yocto07:06
*** alessioigor <alessioigor!~alessioig@> has quit IRC07:08
RPJPEW: that does seem to have helped...07:14
*** pdemier <pdemier!> has quit IRC07:21
*** yacar_ <yacar_!> has joined #yocto07:22
*** PinkSnake <PinkSnake!51ff1123@> has joined #yocto07:25
*** alessioigor <alessioigor!~alessioig@> has joined #yocto07:28
*** tprrt <tprrt!~tprrt@> has joined #yocto07:31
*** kanavin_ <kanavin_!~kanavin@> has quit IRC07:31
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto07:36
*** learningc <learningc!> has quit IRC07:38
*** learningc <learningc!> has joined #yocto07:40
*** mckoan|away is now known as mckoan07:49
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto07:58
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto08:00
yoctiNew news from stackoverflow: YOCTO : How to add LIBSOC library to my Linux image <>08:05
*** diego_r <diego_r!> has joined #yocto08:07
*** Bunio_FH <Bunio_FH!> has quit IRC08:10
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC08:11
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto08:14
alessioigorjwessel: ping08:17
alessioigorjwessel: I would like merge our patches but I don't have idea how to do it: I never did it before. Could you help me, please?08:19
*** Saur <Saur!pkj@nat/axis/x-kuvdaoaeglpurope> has quit IRC08:25
*** yacar_ <yacar_!> has quit IRC08:29
yoctiNew news from stackoverflow: How to run a shell script while compiling a recipe in Yocto <> || Node-red with Yocto Os <>08:35
*** rburton <rburton!> has joined #yocto08:40
*** Bunio_FH <Bunio_FH!> has joined #yocto08:45
*** yacar_ <yacar_!> has joined #yocto08:49
RPalessioigor: apply both in your git tree, then "squash" them. I find "git rebase -i" helpful08:53
alessioigorRP: Thanks for help. Could you suggest me how "squash" commit messages, please? How I should do with the two Signed-off-by?09:05
LetoThe2ndRP: rebase -i FTW09:05
RPalessioigor: edit the message so that it includes details for both commits and probably include both signoffs in this case (since I know which commits these are)09:13
RPalessioigor: you could just send both patches in series09:13
alessioigorRP: I would prefer "squash" to avoid noise during a hypothetical bisect session.09:15
* alessioigor hopes to have done a good job squashing the two commits...09:39
RPalessioigor: fair enough09:40
alessioigorRP: Thanks09:40
iceaway_In our production boards, we want a root filesystem that we keep as small as possible, but a large data partition. I would prefer not to include this data partition in the .wic-image, as it does not make sense to write 15GB of nothing in production. Would it be sensible to instead have a script that runs at startup, which checks if the partition is there, and if not, creates and formats it on the fly?09:48
iceaway_Is there any kind of support for this in Yocto/POky?09:48
*** iceaway_ <iceaway_!~pelle@> has quit IRC09:49
*** yacar_ <yacar_!> has quit IRC09:49
iceawayStrange, I managed to have two simultaneus connections to freenode. No wonder my nickname was "busy".09:49
LetoThe2ndiceaway: that would just be a neatly written systemd unit09:50
LetoThe2ndprobably with something like Before=mount.service or such09:50
iceawayLetoThe2nd: Sounds reasonable. Not using systemd at the moment though, but I guess a regular init script would work as well?09:51
LetoThe2ndor WantedBy=local-fs.target09:51
LetoThe2ndiceaway: whatever, it'd just advise to make sure it really runs and is checked before the usual mount mechanisms kick in09:52
iceawayLetoThe2nd: Yes will check that!09:52
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:57
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:02
*** lfa <lfa!~lfa@> has joined #yocto10:03
yoctiNew news from stackoverflow: yocto jetson nano image with nvidia sdk binaries: Unable to find file cuda-repo-ubuntu1604-10-0-local-10.0.326-410.108_1.0-1_amd64.deb <> || How to conditionally install and ship files in yocto bb recipe? <>10:05
*** Saur <Saur!pkj@nat/axis/x-uienismpsqbfwfai> has joined #yocto10:12
*** learningc <learningc!> has quit IRC10:17
*** yann|work <yann|work!~yann@> has joined #yocto10:20
*** learningc <learningc!~learningc@> has joined #yocto10:34
yoctiNew news from stackoverflow: Unable to stream RTSP from VLC on Yocto-based distribution <>10:35
*** goliath <goliath!> has joined #yocto10:36
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:37
*** warthog9 <warthog9!> has quit IRC11:00
*** warthog9 <warthog9!> has joined #yocto11:01
*** yacar_ <yacar_!> has joined #yocto11:04
*** vlo86 <vlo86!> has joined #yocto11:13
yoctiNew news from stackoverflow: How to fix error 501 while using yocto build tool? <>11:35
*** MiskaX <MiskaX!zkm6aym95u@2001:2060:72::3> has quit IRC11:36
*** berton <berton!~berton@> has joined #yocto11:39
*** Klanticus <Klanticus!~quassel@> has quit IRC11:43
*** Klanticus <Klanticus!~quassel@> has joined #yocto11:44
vlo86A very basic question for which I could not find a direct answer by googling. I'm trying to add cmake to my image. I've added "inherit cmake" to the app recipe, and "IMAGE_INSTALL_append = " cmake cmake-native"" to /build/conf/local.conf. When baking the image I'm getting an error: " rdepends upon non-existent task11:44
vlo86do_package_write_ipk in poky-thud/meta/recipes-devtools/cmake/". If I remove the IMAGE_INSTALL_append directive, bitbake claims "cmake: command not found". Any advice would be appreciated =)11:44
*** berton <berton!~berton@> has quit IRC11:45
*** berton <berton!~berton@> has joined #yocto11:46
LetoThe2ndvlo86: you are mixing up things. IMAGE_INSTALL += "cmake" adds cmake to the image. inherit cmake in a recipe says that this recipe need cmake for its build and install process. and thrid, adding cmake-native to IMAGE_INSTALL is outright wrong.11:47
vlo86So stating IMAGE_INSTALL_append = " cmake" should be enough in my local.conf?11:48
LetoThe2ndvlo86: to get cmake on the target, yes. not that cmake by itself is of much use on the target, and generally compiling in-target is ... meh.. but yes.11:49
vlo86Right, I guess my first problem was the "cmake: command not found" during bitbaking/cross-compiling my library. So I ended up trying to add cmake to my image to see whether that helps.11:51
LetoThe2ndvlo86: outright wrong that sounds, young padawan11:51
vlo86Learning all the time =)11:51
thomasd13Whats the proper way to update an eSDK installation? Should I just rm the previous installation directory, and installing the new one?11:53
PinkSnakethomasd13 install the new SDK in the same path11:55
thomasd13PinkSnake without removing the previous one before?11:56
PinkSnakethomasd13 The script will ask you if you want to :)11:56
PinkSnakejust make a try ;)11:57
thomasd13Cool ;)  thank you11:57
*** tgamblin <tgamblin!~tgamblin@> has joined #yocto12:03
fullstopIs there any sort of guide on adding a boring makefile shared library recipe?  I've gone through the documentation and have my shared library building with -Wl,-soname= and that all seems to work.  My library is and do_compile creates a symlink from that to  During package qa, though, somehow the -dev package has as the shared library and not the symlink, causing the build to fail.12:06
fullstopI'm not trying to do rocket surgery here, it's a really simple makefile12:06
LetoThe2ndfullstop: simple makefiles are often rocket science, because they often break crosscompiling in awful ways12:07
fullstopLetoThe2nd: These particular makefiles, oddly enough, have _only_ been used to cross compile.12:08
LetoThe2ndfullstop: i'd say, look at the "adding a new recipe" section in the dev or ref manuel (can't remember which one), there is a makefile recipe example12:08
fullstopIt's not building it for the wrong arch.. I'm just not understanding what yocto wants.12:08
LetoThe2ndfullstop: hence, look at the example :)12:08
*** coretec <coretec!d43ed5a2@> has joined #yocto12:09
fullstopIf I remember correctly that example is for a binary and not a library, but I'll check again.12:09
*** anujm <anujm!~anujm@> has joined #yocto12:11
coretecHi, i have a question regarding yocto 2.7 (Warrior).12:11
coretecThe mega-manual states under 24.9.11 "ADT Removed: The Yocto Project Eclipse IDE Plug-in is still supported and is not affected by this change."12:12
coretecHowever under 24.15.2 it states: "Eclipseâ„¢ Support Removed".12:12
coretecWhich one is correct, or am i missinterpreting these statements?12:12
kroonfullstop, I'd assume its the do_install that should create the symlink, no ?12:12
thomasd13coretec I tried to work with Eclipse ADT - Got no success12:12
fullstopkroon: yes, it does, although I believe that it could happen at the end of do_compile as well.12:12
LetoThe2ndcoretec: if in doubt, consider anything eclipse related as unsupported and nonfunctional12:13
LetoThe2ndcoretec: there are reports now and then of people making it work, but do not *expect* it. officially, it has been deprecated.12:13
coretecLetoThe2nd why is this the case ? I find this a very handy feature for some of my users.12:13
LetoThe2ndcoretec: insert coin12:13
LetoThe2ndcoretec: there have been many attempts to find somebody who actually maintains and supports it over the years, and all failed. hence, the emergency brake has been pulled.12:14
thomasd13coretec which advantages does the ADT-plugin offer?12:15
fullstopThis is probably important, and it's something that I don't understand: WARNING: libblock-1.0-r0 do_package: libname-dev-1.0 was registered as shlib provider for, changing it to libname-1.0 because it was built later12:15
coretecLetoThe2nd: Thank you for the clarification12:15
LetoThe2ndcoretec: yw.12:15
fullstopcat's out of the bag, package is actually called libblock, I was trying to keep that anonymous for some reason.12:15
coretecthomasd13: Well my application developers seem to be unable to work without eclipse or any other full feature IDE :)12:17
LetoThe2ndcoretec: then either hire sombody to make things work for them, or invest in training them to use other tools :)12:18
thomasd13coretec I setup Eclipse in such a way that it works with eSDK together. For on target debugging, I wrote a script which deploys the executable on the target and start a gdbserver12:20
coretecLetoThe2nd: Well yeah, guess i have to12:20
thomasd13I don't know if this is enough or ADT offered more12:20
coretecthomasd13: what do you mean by eSDK ?12:21
*** yacar_ <yacar_!> has quit IRC12:21
thomasd13extensible sdk12:21
coretecthomasd13: and i think ADT is also deprecated, its only the SDK now right12:21
fullstopokay, I think that I see what is going on.  How do I keep .so files out of the -dev package?  How does the build system know which files to put in -dev?12:24
LetoThe2ndfullstop: usually by setting FILES_${PN}-dev and FILES_${PN} accordingly12:25
LetoThe2ndfullstop: yet i'd say this means that the install stage of that lib is b0rk3d12:25
fullstopWell, the install stage is done entirely in do_install() since there is no "install" target in the makefile12:26
fullstopso if it's borked I've borked it myself12:26
qschulzfullstop: FILES_${PN} has libdir/*.so.* and FILES_${PN}-dev has libdir/*.so IIRC12:26
fullstopqschulz: are -dev packages supposed to have shared libraries in them?12:27
qschulzI think the point is PN has the shared library and -dev has the symlink .so to .so.x.y.z12:27
fullstopand PN does not have a symlink?12:28
qschulzSOLIBS, SOLIBSDEV, FILES_SOLIBSDEV is what is handling this12:28
qschulzwell it can, but it can't be named lib*.so and not in libdir12:29
qschulzby default12:29
fullstopso confusing12:29
qschulzyou could technically have N different versions of the same library on the system12:29
qschulzif all of them installed lib*.so symlink, Yocto wouldn't know which one to take12:30
fullstopgot it12:30
fullstopmaybe.  :-)12:31
*** learningc <learningc!~learningc@> has quit IRC12:32
fullstopI created the symlink during the do_install phase but did not install it to libdir.. this built and packaged without warning/error, but the -dev package has no symlink.12:32
*** georgem_ is now known as georgem12:32
qschulzfullstop: could you explain again your issue then :)?12:40
fullstophaha, give me a second.. let me see if my latest change actually worked or not.12:40
fullstopI'm on warrior if this makes a difference12:40
fullstopokay, failed again.  One second.12:41
fullstopokay, here's the recipe (somewhat made anonymous):
fullstopthe FILES_ lines are new12:43
fullstopThe makefile builds lib/ in S, with the soname set correctly in the elf headers12:44
fullstopAnd, in short, I just want this thing to build so that I can use this library with other recipes.12:45
fullstopwhen I set FILES_${PN}-dev to include lib*.so the symlink is .. ignored?  It ends up being the actual library and not a symlink.12:47
LetoThe2ndi just want a dollar for each time i hear "i jsut want ..." in here :)12:48
fullstopI'm coming from buildroot, so the GIT_VERSION thing isn't right just yet, it will eventually pop the git hash into the source.12:48
qschulzLetoThe2nd: everything is always supposed to be simple in people's mind :) (at least always in mine, and then it's not simple at all :D)12:48
*** palate <palate!~palate@unaffiliated/palate> has joined #yocto12:48
fullstopLetoThe2nd: :-)12:48
fullstopI understand that it's not simple, but I also don't want it to be magic.12:49
LetoThe2ndfullstop: as usual bitbake -e is your friend12:49
LetoThe2ndfullstop: i guess things jsut are not what you think in reality12:49
fullstopIsn't that how learning works?12:49
qschulzfullstop: SOEXT=".so" is that expected?12:50
fullstopqschulz: let me see if that is still used.12:50
qschulzwhat I expect is that this line creates a AND a with SONAME=12:50
qschulzthen, ln -s ${PN}.so.${PV} lib/${PN}.so is a noop12:50
fullstopIt's not used by my makefile12:50
JPEWRP: Perhaps report_unihash should raise bb.fatal if the tid is not in self.setscenetasks?12:51
fullstopback up a sec..12:51
fullstopoe_runmake should create (symlink) and, yes?12:51
qschulzdoes your Makefile create those?12:52
fullstopno.  It creates
fullstopand I took care of the symlink in do_install12:52
fullstopbut I can easily have the makefile create the symlink if that actually makes a difference.12:52
qschulzwell, apparently not since it's  not a symlink :D12:52
fullstopIt is a symlink, though.12:52
fullstop15 Sep 26 08:41 ->
fullstopit's only when it's added to the -dev package when it is suddenly not.12:53
qschulzah fuck12:53
qschulzwhat does install do on a symlink?12:53
qschulzdoes it copy the symlink or the reference?12:53
fullstoplet me do it manually and see12:54
fullstopthe reference12:54
fullstopso I need to cp instead of install?12:54
qschulznot necessarily12:55
qschulzyou can use ln to install the symlink directly in ${D}12:56
qschulzfyi, you might hit errors wrt to how symlinks are handled in Yocto.
qschulznot everything will work12:56
qschulzfrom what I gather, ln -s ${PN}.so.${PV} ${D}{libdir}/${PN}.so should work12:58
qschulz(you don't need a '/' between ${D} and ${libdir} or ${includedir} btw :)12:58
fullstopright, I had the absolute symlink error before, that's how I got this far.12:59
fullstopI have to say ${D}${libdir} doesn't look as nice as ${D}/${libdir}13:00
*** coretec <coretec!d43ed5a2@> has quit IRC13:00
qschulzfullstop: matter of taste, I hate seeing paths in logs with two // :)13:00
*** ECDHE_RSA_AES256 is now known as ecdhe13:03
fullstopqschulz: LetoThe2nd: thanks for the help, it's behaving as expected now.13:04
fullstopthanks for putting up with me.  :-)13:04
RPJPEW: just realised we have a problem with the way the mixin interacts with the OE-core class extension13:06
rburtonfullstop: ever considered using a proper build system instead of bare make? :)13:07
fullstoprburton: bah!  I've used the same makefile for years now!13:07
rburtonwell if its not a versioned library you don't need to install a symlink, its just that FILES* defaults to assuming versioned and symlinks13:08
rburtonas that's typical13:08
fullstopI understand now that I had two ways of getting past this.  Three if you count changing from make.13:09
fullstopI have a love/hate relationship with cmake right now.13:09
rburtoneasiest is to write a makefile that behaves like a typical library: install, symlink, etc.13:10
rburtonsoname, version, etc.13:10
rburtonthen if you do switch to a proper build system you can do it seamlessly, and everyone else who sees your library knows what to expect.13:10
rburtonif you want to keep it unversioned then is useful13:11
fullstopthanks, rburton13:12
rburtoni endorse meson if you want to replace make ;)13:12
qschulzrburton: let me jump on the library train then :)13:12
RPJPEW: its a class inheritance order problem:
*** vmeson <vmeson!> has joined #yocto13:13
qschulzrburton: we have recipe A with a binary which has NEEDED but in recipe alsalib we have only which is provided13:13
qschulzFor me, this is the opposite as what's explained in the link you pasted, right?13:14
rburtonqschulz: that NEEDED is wrong13:14
rburtonhow did that happen13:14
rburtonthe linker will follow symlinks to get the full versioned name13:14
RPJPEW: is a bigger issue on how we handle this :/13:15
RPJPEW: currently its writing out junk filenames, this fixes that but opens a new barrel of problems13:15
JPEWRP: oj?13:15
JPEWRP: oh?13:15
qschulzrburton: tell that to the ultra big corporation who sent us this binary, they do it for almost all their NEEDED :)13:16
rburtonthey're idiots13:16
qschulzis it really?13:17
rburtonits a horrible way of avoiding version conflicts but assumes you'll have dev packages installed13:17
RPJPEW: should sigdata files show unihashes or task hashes?13:17
qschulzrburton: exactly, how is it handled normamlyl this kind of conflicts?13:17
rburtonclosed source blob i presume?13:17
qschulzrburton: yes13:18
rburtoni'd start with 1) moan at vendor13:18
JPEWRP: Are you talking about the text dump of the hash contents? Unihash I would expect.13:18
rburtoni wonder if you can tweak the linkage13:18
qschulzWhat is the proper way for people providing binaries to avoid version conflicts? (I'm curious now :))13:19
RPJPEW: right, but then the computed value and the actual hash don't match which is confusing13:19
rburtonqschulz: the binaries should have defined version needs. its not like has been changing hugely over the years.13:20
JPEWRP: In the name of the file?13:20
RPJPEW: and/or its contents13:20
qschulzrburton: that would mean a binary per combination of NEEDED library versions right?13:20
rburtonqschulz: many libraries don't actually change their library version that much13:20
qschulzfor this company, that is absolutely not scalable.13:20
*** yacar_ <yacar_!> has joined #yocto13:21
RPzeddii: around? How long will we need to get that ppc fix in from stable?13:22
qschulzrburton: back to Yocto :) I could patchelf the thing in Yocto but it feels not right.13:24
tgamblinrburton: I'm combing over the systemd.bbclass file regarding the nativesdk bug we've been discussing via email. I see a commit from khem last month that changed the way the do_install[postfuncs] to limit their use to target (not native) builds, but I'm not 100% on what the right fix would be to avoid effectively reverting what khem did13:25
rburtontgamblin: run it for target and nativesdk?13:26
JPEWRP: The dependent task hashes in the sigdata are already unihash... I'd lean toward naming the sigdata with the unihash also. Perhaps there is a way we can make it easy to cross reference for users (symlinks or the like?)13:26
rburtontgamblin: or reverse the logic: RMINITDIR_class-native = ""13:27
RPJPEW: we perhaps should write the unihash and the hash to the files13:27
tgamblinrburton: the latter sounds cleaner. I'll have a look at that13:28
JPEWRP: Ya, that would work too.... those aren't ever actually hashed in their entirety correct (i.e. adding more things won't change the actual hashes)?13:29
RPJPEW: the data is pulled out so no, we're free to add data13:30
JPEWRP: I can work up a patch to do that if you want13:31
khemrburton: tgamblin I dont think extending it to anything besides target makes sense13:32
rburtoniirc, systemd isn't enabled in nativesdk distro features so that purge code would go and clean the files away, which is what we want13:33
khemare we shipping system services in nativesdk that should be run on sdk host ?13:33
rburtonthere are recipes that ship service files that don't serve any purpose in a nativesdk13:33
rburtonand we can either 1) delete them in every recipe or 2) just make the class remove them13:33
RPJPEW: I think we need to look into that, the patches in -next show its fragile13:34
khemI see, ok I was thinking that we want to ship them which would be disaster13:34
RPJPEW: also can we please fix the module error when the hashserv connection fails? :)13:34
JPEWRP: Yes13:35
*** vmeson <vmeson!> has quit IRC13:35
tgamblinkhem: my original patch was to have the dnf recipe remove them, but rburton pointed out that multiple recipes experience it, meaning a fix for the systemd.bbclass file instead13:36
khemrburton: so what we then do is enforce sysvinit for nativesdk always ?13:36
tgamblinerr, the dnf fix would add them, rather13:36
rburtonkhem: there's no need for service files in nativesdk at all13:36
rburtonso i wouldn't be surprised if the init scripts are being deleted already13:36
RPJPEW: I did spot one other problem - the keys in unitaskhashes have the full paths in - which is why the eSDK ignores them13:37
*** comptroller <comptroller!> has quit IRC13:38
khemrburton: yes thats what I thought but my only concern is that it starts accounting for hashes to rebuild nativesdk-llvm etc when DISTRO_FEATURE changes from sysvinit to systemd13:38
rburtonthe distro features for nativesdk is tightly controlled13:38
rburtonDISTRO_FEATURES_NATIVE ?= "x11 ipv6 xattr"13:39
rburtonDISTRO_FEATURES_NATIVESDK ?= "x11"13:39
rburtonso not sure how changing the features caused a rebuild of native code13:39
khemin that case I think add RMINITDIR_class-nativesdk = " rm_sysvinit_initddir rm_systemd_unitdir "13:39
RPJPEW: patch for that is ready for testing13:40
kheminverting the logic would enable it for cross classes as well so thats not good so lets be surgical13:40
*** WillMiles <WillMiles!> has joined #yocto13:41
tgamblinMakes sense to me13:41
tgamblinI'll test it then cc you guys on the patch13:42
*** TobSnyder <TobSnyder!> has quit IRC13:46
*** comptroller <comptroller!> has joined #yocto13:47
tgamblinthanks for the clarification!13:48
*** Klanticus <Klanticus!~quassel@> has quit IRC13:50
*** Klanticus <Klanticus!~quassel@> has joined #yocto13:51
*** thomasd13 <thomasd13!> has quit IRC13:51
khemtgamblin:I would like you to try a case where you replace systemd with sysvinit in DISTRO_FEATURES and see what all ends up rebuilding especially in nativesdk recipes13:52
khemtypical case I have is nativesdk-clang13:52
rburtonmaybe we shoud have a selftest for that13:52
khemdoes this cause it to rebuild13:53
rburtontoolchain shouldn't rebuild with distro feature changes13:53
khemit shouldn't but it did atleast the native case was causing clang-native to rebuild13:53
khemso now it would be prudent to check if this would now happen for nativesdk13:54
khemas well if we re-add the post funcs13:54
*** alessioigor <alessioigor!~alessioig@> has quit IRC13:55
*** alessioigor <alessioigor!~alessioig@> has joined #yocto13:55
*** Klanticus <Klanticus!~quassel@> has quit IRC13:56
*** Klanticus <Klanticus!~quassel@> has joined #yocto13:57
*** sjolley_ <sjolley_!> has joined #yocto14:06
*** kroon <kroon!~kroon@> has quit IRC14:08
JPEWRP: I think I might set the hashserver timeout to 20 seconds by default for better user experience. Does that sounds OK? You might need to change it on the AB14:09
*** AndersD <AndersD!> has quit IRC14:09
RPJPEW: yes, I'm ok with that14:12
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC15:00
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto15:02
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC15:07
*** kpo <kpo!> has joined #yocto15:07
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto15:08
kpohey, I've got a question - I need to add secondary (e.g. gid >= 1000) group "users" with bitbake, however after inheriting extrausers and adding GROUPADD_PARAM += "users" it creates group "users" with gid 100. Is there any way to explicitly tell extrausers to add group with some gid?15:11
frayyou can specify int eh parameters to groupadd exactly what you want/need15:12
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC15:12
frayI believe you can do users -g 100015:14
kpothanks fray, checking it out right now - will report back :)15:14
kpoi missed -g, and wrote "users 1000", probably that was it15:15
kpoa few minutes for build and I'll get back15:16
qschulzwhy is ntp taking ages to compile and install? I gathered that it's doing a config.status --recheck in both tasks and it takes really an awfully big amount of time... why is this needed in the first place since it's done in configure?15:24
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto15:29
kpofray: unfortunately it didn't work - I'm on thud btw15:31
*** kroon <kroon!> has joined #yocto15:31
kpoi've tried gid 1000 and 3000, no difference - cat /etc/group | grep users shows 100 :(15:31
kpohowever, when I run "groupadd users2 -g 3000" on the running system  it works perfectly15:33
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC15:35
*** andycooper <andycooper!uid246432@gateway/web/> has quit IRC15:41
RPzeddii: around?15:42
rburtonqschulz: sounds like ntp is broken15:42
*** kanavin <kanavin!~kanavin@> has joined #yocto15:42
*** sjolley_ <sjolley_!> has quit IRC15:45
*** yacar_ <yacar_!> has quit IRC15:48
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto15:54
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC15:57
*** yann|work <yann|work!~yann@> has quit IRC16:00
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto16:05
*** vlo86 <vlo86!> has quit IRC16:09
*** vlo86 <vlo86!> has joined #yocto16:10
alessioigorI'll receive a board with two type of CPU (a big Intel CPU and a little ARM cpu) soon. Is it possible to produce an image with both compilers?16:11
*** armpit <armpit!~armpit@2601:202:4180:a5c0:40e0:1cd6:848:14bf> has quit IRC16:13
*** vlo8695 <vlo8695!551700fe@gateway/web/cgi-irc/> has joined #yocto16:16
*** mckoan is now known as mckoan|away16:17
*** jmiehe <jmiehe!> has quit IRC16:23
__angelohi, i have a module built from yocto, in recipes-kernel/linux/ and would like to apply patch only for a certain version of kernel, is this possible ?16:26
*** Bunio_FH <Bunio_FH!> has quit IRC16:29
*** kroon <kroon!> has quit IRC16:29
zeddii__angelo, not easily. that's why out of tree modules can be problematic. best to just make the code check the version in the code and use the version #ifdefs16:31
*** kroon <kroon!> has joined #yocto16:32
zeddiibut if you are inheriting (directly or indirectly) linux-kernel-base, it does have get_kernelversion_headers16:37
RPzeddii: got a second to talk about this ppc issue?16:38
zeddiii'm sitting in a conference room @ Linaro Connect, and will have to present a demo in a few minutes. but until they call on me, I'm here :D16:39
qschulzrburton: wdym? in general or on my local builds?16:39
zeddiiRP is the ppc issue the fsl one that I saw bugzilla updates about ?16:40
RPzeddii: I see you replied in the bug16:40
RPzeddii: sorry, I'm behind now :)16:40
RPzeddii: that leaves the strace issue, did you get anywhere with that?16:41
zeddiinot a solution, but I was interruped. I've talked to a few people about it here, so I have some ideas to try (I fly home tonight).16:41
RPzeddii: ok. These issues block M4 and M4 is next week which is why I'm asking questions16:42
zeddiiI haven't been getting any optimistic feedback about a really quick solution, but I'll write something up ASAP.16:42
RPzeddii: thanks16:42
RPzeddii: meanwhile I'll get the stable updates tested16:42
*** litb <litb!> has joined #yocto16:43
litbis it correct that .bbappend files must be in the same directory as those .bb files that are appended16:43
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC16:43
RPlitb: no16:43
litbi.e  a recipes-extended/foo/ file can only be appended by a recipes-extended/foo/foo.bbappend  ?16:43
litbsomewhere I think I read that16:43
RPits wrong16:44
litbI wanted to do a  appends/recipes-*/*/*.bbappend   folder because I find it's clearer if one knows all appends are at a single place and not scattered around16:45
litbis this a good idea?16:45
zeddiiRP: but since that issue is with the fsl board, we need to bump the SRCREVs for the reference boards, I didn't send that, but can .. I just can't boot them.16:45
zeddiibut the patch is definitely in my tree.16:45
RPzeddii: if you could please, we should probably just bump and test they build...16:45
zeddiiyup. my script can do it. So I'll do it and send it.16:46
litbthe problem is that PAM's sshd and PAM's su file don't load the . So I need a bbappend to modify those files before they get packaged16:46
RPzeddii: thanks16:46
fraylitb, this is how I've done it in the past.  Edited the components via a bbappend and make sure that bbappend only modifies if my custom distribution is enabled..16:47
fraythat conforms to the YP best practices and keeps things clearly as 'your' change16:48
frayI do wish we had a better way to handle those sort of configuration files, but I don't know of one at this point.16:48
litbfray, ah so  far  I'm not checking whether my distribution is enabled16:53
frayya, so any user of your layer will get your change (unconditionally) which can cause issues and is not best practice..16:53
frayWhat I usually do is something like.. (looking for an example)16:53
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:54
fraylook at the openssh_8.%.bbappend .. it uses a system conditition to determine to active or not, which then pulls in nothing or file16:54
frayin thi case, it's using just a variable..16:54
fraybut with your own distro, you could select on the distro name (part of the distro name) or a distro feature..16:55
fray(or an override even)16:55
zeddiiRP: sent. you'll see there are two patches. the fix we want is in with the v5.2.17, and I didn't want the reference boards ahead of qemu*, so I sent one to oe-core the other to yocto. but they are both 5.2.1716:57
zeddiiand have the fix16:57
litbfray, ah thanks17:00
litbI see that you put your override in a "normal" recipes-folder17:00
litbwould you see it as bad idea to put all overrides below a "appends/" folder? (and put appends/ in BBFILES in the layer conf)17:01
fraythat will work, but it makes it harder for somone new to come in and find the tiems..  if you use the same structure as the layer (recipes) you are appending, it's been easier to maintain in mye xperience..17:01
frayI have seen cases where people do:17:01
frayrecipes-.../    and appends/recipe-.../recipe.bbappend17:01
frayso they've moved appends, but they keep the diretory structure.. but it's much more rare then the regular case17:02
litbah I see. I'll stick with the regular rules then.17:02
* litb undoes his git mv ..17:02
fraythere is another case BTW.. if you may be bbappending layers that are optional..17:03
frayappending -to- layers....17:03
frayyou need to use a dynamic configuration for that17:03
frayyou can see the 'dynamic-layers' directory, under that is a directory per 'optional' layer.. and then regular structure under that17:04
fraythat shows how to setuo the 'BBFILES_DYNAMIC'17:04
litbdynamic layers? head explodes. still need to look into that17:05
frayya, in that (complex) example.. meta-gnome [gnome-layer] is optional.. but if it's there, the distro configures things in it17:06
litbfray, this sentence  in the manual appears to be broken: "Use the BBFILES_DYNAMIC variable to avoid .bbappend files whose corresponding .bb file is in a layer that attempts to modify other layers through .bbappend but does not want to introduce a hard dependency on those other layers."17:12
*** tprrt <tprrt!~tprrt@> has quit IRC17:12
litbI think it should read "Use the BB_FILES_DYNAMIC variable to have a layer that attempts to modify other layers ... but does not want to introduce a hard dependency..." ?17:14
*** dreyna <dreyna!> has joined #yocto17:15
*** diego_r <diego_r!> has quit IRC17:17
frayyes..  you should suggest that to the docs people17:18
JPEWlitb: Send a patch please17:19
*** Bunio_FH <Bunio_FH!> has joined #yocto17:20
*** Bunio_FH <Bunio_FH!> has quit IRC17:21
*** Bunio_FH <Bunio_FH!> has joined #yocto17:21
*** gaulishcoin <gaulishcoin!> has joined #yocto17:37
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto17:55
*** emg <emg!~emg@> has joined #yocto17:58
emgI've added samba to my build but I don't have winbind. Looking at it looks like I should have a winbind.service and /sbin/winbindd etc. but nothing from FILES winbind seems to be present.18:00
emgWhat am I missing/doing wrong? How do I make sure those get added to my image?18:01
*** andycooper <andycooper!uid246432@gateway/web/> has joined #yocto18:04
*** jacques2 <jacques2!~jacques@nslu2-linux/jacques> has joined #yocto18:09
*** linuxjacques <linuxjacques!~jacques@nslu2-linux/jacques> has quit IRC18:10
kergothemg: recipes can emit multiple binary packages. its up to you to install those packages in your imagew iwth IMAGE_INSTALL or equivalent. in this case, you'd need to install 'winbind', as that's what's in PACKAGES and referenced in FILES_18:11
tgamblinkhem: I've been running into build failures trying to run that test on nativesdk-clang. I am seeing the failure in on my local machine, even though I have the patch, but this may just be my build machine18:13
tgamblinThat being said, I tested with nativesdk-dnf with systemd and then sysvinit in DISTRO_FEATURES and did not see any rebuilds18:13
emgkergoth: when I add winbind to my RDEPENDS_${PN} = "... in my packagegroup... ^U I swear that I tried that and it didn't work and now here it's working. I'm beginning to doubt my sanity18:15
emgkergoth: thank you18:15
*** sjolley_ <sjolley_!> has joined #yocto18:17
*** sjolley_ <sjolley_!> has quit IRC18:26
*** frsc <frsc!> has quit IRC18:27
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:29
*** armpit <armpit!~armpit@> has joined #yocto18:29
*** kroon <kroon!> has quit IRC18:44
khemtgamblin:I thought I laid that monster to rest18:58
khemtgamblin:do you have multiple python installs on your machine18:58
khemit is a shortcomping in clang build I know18:58
tgamblinkhem: it could just be my build machine, not sure yet. I have python and python3 in /usr/bin18:58
kergothHm, wonder if anyone has looked into creating a script to automate merging a bbappend+filespath into the main recipe for upstream submissions19:04
frayI've thought about it, but couldn't figure out a way to do it in the cases where things were based on distro, machine or other flags..19:06
*** litb <litb!> has quit IRC19:06
*** comptroller <comptroller!> has quit IRC19:07
tgamblinkhem: actually I have three versions installed19:11
*** Klanticus <Klanticus!~quassel@> has quit IRC19:12
*** Klanticus <Klanticus!~quassel@> has joined #yocto19:12
*** comptroller <comptroller!> has joined #yocto19:25
kergothHmm, yeah, wouldn't be able to merge those. Need to brush up on the available functions in the recipetools and scriptools/utils modules19:26
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC19:28
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has joined #yocto19:29
*** vlo86 <vlo86!> has quit IRC19:32
*** mcfrisk <mcfrisk!> has quit IRC19:33
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC19:43
RPnrossi: any idea on (also happened as
RPJPEW: autobuilder hashequiv tests looked better again, just this selftest failure to fix now19:47
*** PinkSnake <PinkSnake!51ff1123@> has quit IRC19:48
RPThat one at least reproduces19:48
*** rcw <rcw!~rcw@> has joined #yocto19:56
*** sjolley_ <sjolley_!> has joined #yocto20:00
*** Bunio_FH <Bunio_FH!> has quit IRC20:17
*** armpit <armpit!~armpit@> has quit IRC20:18
*** leitao <leitao!~leitao@2620:10d:c092:200::1:b3f8> has quit IRC20:19
*** mrc3 <mrc3!~mrc3@linaro/mrc3> has joined #yocto20:20
*** tgamblin <tgamblin!~tgamblin@> has quit IRC20:21
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto20:21
khemRP: what are these strace failures ?20:52
khemRP:are they new ?20:53
RPkhem: 5.2 kernel20:53
khemI think the kernel API changes in 5.2 are biting us20:54
RPkhem: and see the linked 1350620:54
yoctiBug 13556: normal, High, 2.8 M4, bruce.ashfield, NEW , [2.8 M3 RC1] strace failure in ptest20:54
khemchanges to clock_t and time_t20:54
RPkhem: its not that, its some specific freezer patches around ptrace20:54
khemRP: do you want to try
RPkhem: if someone sends a patch, sure :)20:57
RPkhem: I think we did test tip of git and it didn't help20:57
khemOK I can do that tell me how can I run the given self test alone20:57
RPkhem: it should be in 1350620:58
RPkhem: the test would be to run qemux68-64-ptest on the branch with the upgarde20:58
RPkhem: the tip of git was pre-release20:59
khemwill need poky not oe-core right ?21:04
RPkhem: right21:05
khemRP:preparing a patch and I will submit it via poky-contrib21:12
khemto AB21:12
khemon top of master-next lets see :)21:12
khemRP: one issue I am seeing is version-going-backwards when I switch from musl to glibc on some packagegroups, these packagesgroups have different packages being pulled based on which libc is in play21:13
khemRP: packagegroups are 'all' types but then we conditionalize them based on libc seems wrong to me21:14
RPkhem: right, that is bad :(21:15
*** berton <berton!~berton@> has quit IRC21:15
RPtrue allarch are very hard/rare21:16
RPJPEW: thanks for the patches :)21:19
*** yann|work <yann|work!> has joined #yocto21:19
JPEWRP: No problem. It was nice that they ended up being straight forward21:20
RPJPEW: yes, nice when that happens!21:20
JPEWI've probably angered some ancient god with that statement and untold wrath will befall me now :)21:21
RPJPEW: that selftest was simple when I finally understood what was wrong too21:21
khemRP: is there a way to address it ?21:21
*** WillMiles <WillMiles!> has quit IRC21:21
RPJPEW: I think they've been angry with me for a month or two already ;-)21:21
RPJPEW: If you want insight into our next problem, the warnings on: :(21:22
khemsome of oe AB I have musl world build and glibc world build share sstate and buildhistory21:22
RPJPEW: Ignore the nativesdk bit, its missing shadow which setscenes later21:22
RPkhem: it won't hurt sstate its just saying you couldn't have a working shared package feed21:22
RPkhem: making them non-all arch is probably the only solution21:23
khemRP: yeah which is logical I think21:23
RPmy tweak/fixes in -next are a right mess. I think I have to sort them into sensible patches tomorrow...21:24
RPJPEW: current build is fun as its using hashequiv with larger code changes21:25
JPEWRP: Does it look like it's helping?21:25
RPJPEW: Its seems to be running quite quickly but hard to say :)21:26
*** rcw <rcw!~rcw@> has quit IRC21:26
RPJPEW: we need to enable reproducibile builds by default next to really start to make a difference21:26
JPEWRP: Ya, that would be awesome.... are there any images other than core-image-minimal and core-image-sato that the AB uses?21:27
RPJPEW: quite a few (full-cmdline, sato-sdk, -dev, weston and more)21:27
RPand world builds21:28
RPkhem: FWIW we turned that test off on our buildhistory21:32
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC21:35
khemRP: you mean version-going-backward QA test ?21:37
RPkhem: yes21:37
khemhmm maybe its a better option21:37
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC21:37
*** sjolley_ <sjolley_!> has quit IRC21:37
*** sjolley_ <sjolley_!> has joined #yocto21:38
RPkhem: its fine if you're maintaining a package feed but we're not and don't have the people to right now21:38
khemwould you be open for patches to mark these packagegroups as non-all ?21:39
RPkhem: how many are there?21:40
RPkhem: I'm hoping its just one or two21:40
*** sjolley_ <sjolley_!> has quit IRC21:44
khemyes its os-release, packagegroup-core-tools-debug, packagegroup-core-standalone-sdk-target packagegroup-self-hosted21:48
RPthat is more than I'd hoped :(21:49
RPkhem: os-release doesn't look libc specific?21:50
RPkhem: the others I don't mind changing after looking at them...21:51
*** agust <agust!> has quit IRC22:05
*** pdemier <pdemier!> has joined #yocto22:05
*** tesaddict <tesaddict!> has joined #yocto22:14
khemRP: cool, os-release is also doing the switch back so maybe it has some dependency somehow ... I will hunt it down22:14
tesaddictHow is it going guys? I was wondering what is the best practice to modify a few drivers within recipes-kernel22:15
tesaddictSpecifically from meta-atmel. I can directly make changes, but I realize this is bad practice22:15
RPkhem: it may be you've configured it to add a dependency? Is this with poky or nodistro or ???22:17
*** gaulishcoin <gaulishcoin!> has quit IRC22:20
*** sjolley_ <sjolley_!> has joined #yocto22:31
*** tgamblin <tgamblin!> has joined #yocto22:31
*** sjolley_ <sjolley_!> has quit IRC22:37
khemRP: I know the problem is I define different DISTRO for musl22:41
khemand DISTRO is one of the elements in there for os-release22:41
RPkhem: right, that would explain it22:41
khemthat I think I need to address differently22:41
RPkhem: reality is that you'd likely have different package feeds for glibc and musl so this may not be a problem for allarch22:44
* RP should sleep22:44
khemthat is true though22:44
khemyes should I send a RESTful API cmd :)22:45
RPkhem: :)22:49
*** rburton <rburton!> has quit IRC23:04
*** armpit <armpit!~armpit@2601:202:4180:a5c0:40e0:1cd6:848:14bf> has joined #yocto23:12
*** MiskaX <MiskaX!> has joined #yocto23:13
*** JaMa <JaMa!> has quit IRC23:27
*** stephano <stephano!stephano@nat/intel/x-wxqftanpnkmnytgf> has joined #yocto23:32
*** stephano <stephano!stephano@nat/intel/x-wxqftanpnkmnytgf> has quit IRC23:41
*** tesaddict <tesaddict!> has quit IRC23:53

Generated by 2.11.0 by Marius Gedminas - find it at!