Monday, 2017-01-30

*** behanw <behanw!uid110099@gateway/web/> has quit IRC00:01
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has quit IRC00:03
*** moto-timo <moto-timo!~ttorling@> has joined #yocto00:04
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto00:04
*** aurele <aurele!> has quit IRC00:12
*** aurele <aurele!> has joined #yocto00:13
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC00:22
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto00:23
*** paulg <paulg!> has quit IRC00:23
*** clement_ <clement_!> has joined #yocto00:43
*** clement <clement!> has quit IRC00:43
*** clement_ is now known as clement00:43
*** aurele <aurele!> has quit IRC00:46
*** aurele <aurele!> has joined #yocto00:46
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC01:01
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto01:02
*** nighty <nighty!> has joined #yocto01:06
*** clement <clement!> has quit IRC01:13
*** clement <clement!> has joined #yocto01:13
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC01:46
*** clement_ <clement_!> has joined #yocto01:58
*** clement <clement!> has quit IRC01:58
*** clement_ is now known as clement01:58
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has joined #yocto02:02
*** maciejjo <maciejjo!> has quit IRC02:10
*** aurele <aurele!> has quit IRC02:15
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto02:15
*** aurele <aurele!> has joined #yocto02:15
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC02:17
*** maciejjo <maciejjo!> has joined #yocto02:22
*** maciejjo <maciejjo!> has quit IRC02:32
*** clement <clement!> has quit IRC02:43
*** clement_ <clement_!> has joined #yocto02:43
*** clement_ is now known as clement02:43
*** clement <clement!> has quit IRC02:44
*** clement <clement!> has joined #yocto02:48
*** clement <clement!> has quit IRC03:08
*** clement_ <clement_!> has joined #yocto03:08
*** clement_ is now known as clement03:08
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto03:18
*** maciejjo <maciejjo!> has joined #yocto03:24
*** maciejjo <maciejjo!> has quit IRC03:44
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC03:44
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto03:45
*** sgw_ <sgw_!~sgw_@> has joined #yocto04:09
*** dreyna__ <dreyna__!> has joined #yocto04:16
*** dreyna_ <dreyna_!> has joined #yocto04:34
*** dreyna__ <dreyna__!> has quit IRC04:38
*** pohly1 <pohly1!> has joined #yocto04:58
*** pohly <pohly!> has quit IRC05:00
*** maciejjo <maciejjo!> has joined #yocto06:01
*** hamis <hamis!~irfan@> has joined #yocto06:02
*** clement_ <clement_!> has joined #yocto06:06
*** clement <clement!> has quit IRC06:09
*** clement_ is now known as clement06:09
*** AndersD <AndersD!~anders@> has joined #yocto06:09
*** hamis <hamis!~irfan@> has quit IRC06:10
*** AndersD <AndersD!~anders@> has quit IRC06:12
*** clement_ <clement_!> has joined #yocto06:13
*** AndersD <AndersD!> has joined #yocto06:13
*** clement <clement!> has quit IRC06:14
*** clement_ is now known as clement06:14
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC06:15
*** hamis <hamis!~irfan@> has joined #yocto06:29
*** clement_ <clement_!> has joined #yocto06:41
*** clement <clement!> has quit IRC06:41
*** clement_ is now known as clement06:41
*** dreyna_ <dreyna_!> has quit IRC06:48
*** clement_ <clement_!> has joined #yocto06:50
*** clement <clement!> has quit IRC06:50
*** clement_ is now known as clement06:51
*** clement <clement!> has quit IRC07:01
*** clement_ <clement_!> has joined #yocto07:01
*** clement_ is now known as clement07:01
*** open-nandra <open-nandra!> has joined #yocto07:01
*** Talorno <Talorno!> has quit IRC07:02
*** agust <agust!> has joined #yocto07:03
*** clement <clement!> has quit IRC07:05
*** maciejjo <maciejjo!> has quit IRC07:05
*** clement <clement!> has joined #yocto07:06
marquizRP: yeah, i saw the fix07:07
marquizRP: when i had the chance to take a look at my git bicect results on saturday i noticed that you had already fixed the problem :)07:07
*** clement <clement!> has quit IRC07:21
*** clement <clement!> has joined #yocto07:26
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto07:27
*** linulin <linulin!> has quit IRC07:36
*** frsc <frsc!~frsc@> has joined #yocto07:37
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto07:38
*** linulin <linulin!> has joined #yocto07:38
*** phatina <phatina!> has quit IRC07:42
*** clement_ <clement_!> has joined #yocto07:43
*** clement <clement!> has quit IRC07:43
*** clement_ is now known as clement07:43
*** phatina <phatina!> has joined #yocto07:44
*** maciejjo <maciejjo!> has joined #yocto07:46
*** Guest27309 <Guest27309!> has quit IRC07:52
*** fl0v0 <fl0v0!> has joined #yocto07:56
*** maciejjo <maciejjo!> has quit IRC07:57
*** maciejjo <maciejjo!> has joined #yocto07:59
*** cordlandwehr is now known as CoLa|work08:01
*** t0mmy <t0mmy!> has quit IRC08:02
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto08:14
*** rajm <rajm!> has joined #yocto08:14
*** groleo <groleo!> has joined #yocto08:17
*** ant_work <ant_work!> has joined #yocto08:19
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto08:20
*** csanchezdll <csanchezdll!> has joined #yocto08:23
*** fl0v01 <fl0v01!> has joined #yocto08:23
*** t0mmy <t0mmy!~tprrt@> has joined #yocto08:25
*** fl0v0 <fl0v0!> has quit IRC08:25
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:27
*** mckoan|away is now known as mckoan08:28
*** toscalix <toscalix!~toscalix@> has joined #yocto08:29
*** egavinc <egavinc!> has joined #yocto08:31
*** psnsilva <psnsilva!> has joined #yocto08:34
*** nemunaire <nemunaire!> has quit IRC08:37
*** sameo <sameo!~samuel@> has joined #yocto08:37
*** open-nandra <open-nandra!> has quit IRC08:38
*** jku <jku!~jku@> has joined #yocto08:39
*** avalluri <avalluri!~avalluri@> has joined #yocto08:44
*** joseppc <joseppc!> has joined #yocto08:45
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto08:45
*** link <link!~link@> has joined #yocto08:45
*** link is now known as Guest101608:45
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC08:45
*** nemunaire <nemunaire!~nemunaire@2a01:e35:8bb7:3c60::a> has joined #yocto08:49
Guest1016Hi There. I got a question on oe_runmake. if I configure EXTRA_OEMAKE = "'CC=${CC}' ... bitbake says "not found" cause ${CC} is  the string "i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/home/..." and there is of course no file with this name08:49
Guest1016what am I doing wrong?08:50
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto08:51
*** Crofton <Crofton!~Crofton@> has joined #yocto08:53
RPmarquiz: sadly the times don't look much better for the changes :(08:54
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto08:55
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto08:55
*** morphis <morphis!> has joined #yocto08:57
*** graphiqs <graphiqs!> has joined #yocto09:01
*** ptizoom <ptizoom!> has quit IRC09:02
Guest1016Hi. is there anyone out there who could answer me a question?09:04
Guest1016about oe_runmake and its configuration09:05
*** AndersD <AndersD!> has quit IRC09:08
marquizRP: yup :(09:09
*** geoffrey_l <geoffrey_l!> has joined #yocto09:10
*** JoiF <JoiF!~jofr@> has joined #yocto09:11
Guest1016could you tell me whats going wrong when i do CC=${CC} like it is stated in the documentation but bitbake means "not found" ?09:12
jkuGuest1016: there's something else going wrong. That same construct is used in many yocto recipes09:14
Guest1016yeah i saw that and because of that i wonder09:15
Guest1016it looks like oe_runmake tries to start "i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/home/..."09:16
Guest1016and not i586-poky-linux-gcc with the parameters "-m32  -march=i586 --sysroot=/home/..."09:17
Guest1016you think it is a fault inside the environment of bitbake?09:18
jkuI doubt it09:18
jkuare you sure that is what's happening? can you pastebin the recipe and the log?09:19
Guest1016or the buildhost09:19
*** ed2 <ed2!Adium@nat/intel/x-zseqstaneibrdfzs> has joined #yocto09:21
*** AndersD <AndersD!> has joined #yocto09:22
*** Crofton <Crofton!~Crofton@> has quit IRC09:24
*** qt-x <qt-x!~Thunderbi@> has joined #yocto09:26
*** TobSnyder <TobSnyder!> has joined #yocto09:29
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC09:30
*** zeenix <zeenix!~zeenix@> has joined #yocto09:37
Guest1016what do you think about it?09:42
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC09:47
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto09:47
*** CTtpollard <CTtpollard!> has joined #yocto09:54
*** adca <adca!~adca@> has joined #yocto09:55
*** mdnneo <mdnneo!~umaucher@> has joined #yocto09:55
*** rburton <rburton!> has joined #yocto10:05
jkuGuest63917: I believe CC value is 'correct' as in the makefile is expected to cope with that and normally they do...10:08
jkuoops sorry, I mean Guest101610:08
Guest1016ah ok. but why it fails then10:09
Guest1016and what is not found10:10
Guest1016if i say CC=i586-poky-linux-gcc it compiles but stoppes caust the headerfiles arnt found10:11
jkuyour Makefile probably does something that expects CC to be a filename. I don't see anything that points to headers not being found10:11
Guest1016but that maybe another problem10:12
*** joshuagl <joshuagl!joshuagl@nat/intel/x-uyneojawwkweunae> has joined #yocto10:13
jkusorry I don't have great suggestions for a recipe workaround -- might be worth it to look in the Makefile, maybe it does something obviously weird with CC10:13
Guest1016that happens if i just give i586-poky-linux-gcc to CC.... without the other parameters10:13
rburtonis the makefile ignoring CFLAGS?10:14
* rburton has only partial context, just realise its cutting the first word of CC and dropping the sysroot arg.10:15
rburtonthe fix is to fix the makefile10:15
rburton'cos its broken10:15
jkurburton yes exactly this was the issue
* rburton had zen like autoconf understanding this weekend, and i think i solved the aclocal/old macros problem for good10:16
jkuand then you woke up?10:16
Guest1016hmm ok that could be. i havnt wrote the make file so i have to debug it somehow10:17
*** nighty <nighty!> has quit IRC10:18
Guest1016ok i will contact the author of the makefile cause this isnt my home ;)10:20
Guest1016many thanks for your help10:20
*** grma <grma!~gruberm@> has joined #yocto10:25
Guest1016you think ignorring the CFLAGS could cause that "not found"-error?10:27
Guest1016i am not that deep into makefiles10:28
*** avalluri <avalluri!~avalluri@> has quit IRC10:29
rburtonRP: i think you mean ${datadir}/doc not /gtk-doc in your libxml2 patch10:31
pohly1rburton: are you going to take the UEFI patch series? I somehow managed to misuse "git series" in the latest revision and accidentally dropped the "[PATCH v4 02/12] acpica: work around flex 2.6.2 code generation issue" patch - it should still be needed.10:31
pohly1I can send another revision, if you want.10:32
*** Biliogadafr <Biliogadafr!> has joined #yocto10:34
RPrburton: not sure I did, it had gtkdocs here10:35
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto10:39
*** Marex <Marex!~Marex@> has quit IRC10:42
rburtonweird, my native build is dropping files into …./usr/share/doc/libxml2-2.9.410:43
*** Marex <Marex!~Marex@> has joined #yocto10:43
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC10:44
RPrburton: I wonder if we have different tools installed?10:46
RPrburton: can we disable docs?10:46
rburtonRP: the docs are pregenerated so it just installs them10:47
RPrburton: sorry about the issues in mut btw, I think I solved things in my patches before I merged to master10:47
rburtonRP: yeah noticed it exploded but i've been feeling pretty dismal from saturday evening (and still do now)10:47
rburtonRP: have a look at ross/autoargh10:47
RPrburton: sorry to hear that :(10:47
RPrburton: "check that we have pkg-config in DEPENDS if pkgconfig is used" doesn't really match the description10:49
RPrburton: I like the idea10:50
rburtondamn i just squashed that and probably did it wrong10:50
rburtonha, yeah, squashed too much away!10:50
rburtontl;dr: if when we patch a m4 file we bump the '#serial' in it, aclocal —install will install ours for us10:51
rburtonjust need to test with gettext next10:51
RPrburton: I do like the idea although still wonder if we can get aclocal just to prefer our m4 files10:53
RPrburton: for some reason the gtk-doc in libxml2 was making it though the sysroot staging code but the others was getting removed without help. I therefore do think the patch was right...10:54
RPrburton: obviously not installing the stuff at all in the native case might be nicer again though10:55
*** berton <berton!~berton@> has joined #yocto11:00
*** Guest1016 <Guest1016!~link@> has quit IRC11:01
*** TobSnyder <TobSnyder!> has quit IRC11:03
*** TobSnyder <TobSnyder!> has joined #yocto11:04
RPrburton, ed2: Not sure where we're at with ed's patches? The ones in -next still trigger an oe-selftest failure. Have you a better set in -mut?11:11
rburtonmut has v311:13
rburtonlooking at the ab it may have worked a bit better11:13
rburtonTHIRTY SIX HOURS for selftest11:14
*** istarilucky <istarilucky!~rlucca@> has joined #yocto11:14
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto11:14
rburtonyeah the xml reporting stuff is broken11:14
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC11:16
*** mckoan is now known as mckoan|away11:19
ed2RP: yes, he has all my patches in ross/mut as far as I can see.11:19
ed2RP: they worked for me on Friday on mut, i.e. passed oe-selftest -r wic11:20
*** psnsilva <psnsilva!> has joined #yocto11:21
rburtonthe ab wasn't happy thogh11:21
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto11:22
corneldo_cleansstate() will call do_clean() also11:25
RPcornel: yes11:25
cornelthank you RP11:28
*** avalluri <avalluri!~avalluri@> has joined #yocto11:28
*** ZubairLK <ZubairLK!~Thunderbi@unaffiliated/zubairlk> has quit IRC11:39
pohly1rburton: please continue to ignore me ;-) My earlier comment about me having dropped a patch from the UEFI series was wrong, I merely compiled the recipe from meta-openembedded. I would never accidentally remove a patch, would I? Hmm...11:39
*** Snert__ <Snert__!> has quit IRC11:48
pohly1What happened to inclusion of shellcheck into OE-core? Some work was done on that, right?11:49
*** avalluri <avalluri!~avalluri@> has quit IRC11:51
rburtonpohly1: sorry not ignoring you on purpose :)11:51
*** Snert <Snert!> has joined #yocto11:52
rburtonpohly1: verify-bashisms in scripts, realised over the weekend its broken with tinfoil211:52
pohly1rburton: no worries. If you agree, perhaps merge the UEFI patches. I'll look at verify-bashisms and might fix it, if no-one else is working on it.11:54
rburtonpohly1: that would be good thanks11:54
rburtonRP: just fired a mut selftest on the new builder to see what it does11:54
rburtonnot convinced its in a happy place11:54
pohly1rburton: where did you get from? Google points to SF, which provides a "checkbashism" (no .pl suffix) file.11:59
rburtongood question12:01
rburtonit appears i ended up with a copy from debian's devscripts12:03
rburtonthat's not very sensible12:03
rburtonthere's another tool i was going to switch to but i can't recall the name right now12:05
*** JaMa <JaMa!~martin@> has joined #yocto12:06
*** morphis <morphis!> has quit IRC12:06
pohly1rburton: that's actually the one I was looking for, not checkbashism.12:07
*** morphis <morphis!> has joined #yocto12:07
pohly1Regarding checkbashism: the one from Debian seems to be better maintained.12:07
rburtoni must have copied the binary to my $HOME for testing and then forgot that i did that, sorry12:08
*** nighty <nighty!> has joined #yocto12:18
*** Talorno <Talorno!> has joined #yocto12:20
SaurIf I have RRECOMMENDS_${PN} = "foo" in recipe, and specifies COMPATIBLE_MACHINE = "armv7a" and I am building for MIPS, why does it fail with ERROR: Nothing RPROVIDES 'foo' (but RDEPENDS on or otherwise requires it). The package foo is optional and I do not need it for the MIPS build.12:21
rburtonbecause bitbake wants to build all recommends so they're present in the feeds12:21
rburtoncan you do RRECOMMENDS_${PN}_armv7a or similar?12:22
Saurrburton: I can, but the point is I do not want to care (it is a packagegroup). If the package is there, then fine use it, otherwise let it be... That is why I use the COMPATIBLE_MACHINE in since it is the one that knows if it can be built or not.12:23
SaurI do not see why RRECOMMENDS has to fail if the recipe does not exists.12:24
SaurThe whole point (to me) is that it marks an optional dependency...12:24
rburtonagreed, a patch seems like a good idea12:24
rburtonrecommrends/suggests should not fail if they can't be built because they've been excluded12:25
Saurrburton: Is there any difference if I RRECOMMEND something that does not exist at all? Typical example, if I RRECOMMEND something in a recipe in one layer that is provided by another layer, and that second layer is not included in my current build why does the build have to fail?12:27
*** paletteguy <paletteguy!~kopdal@> has joined #yocto12:36
ant_workRP: has the staging rework ended?12:37
*** t0mmy <t0mmy!~tprrt@> has quit IRC12:40
kanavinhaha, "cloud rot"12:41
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has joined #yocto12:41
kanavinalso: "The new dependency hell [...]   A "hello world" application based on one JavaScript framework has 759 JavaScript dependencies; this framework is described as "a lightweight alternative to Angular2".  There is no way he is going to package all 759 dependencies for this thing; the current distribution package-management approach just isn't going to work here. "12:42
kanavinYocto will probably hit this issue at some point as well :-/12:42
*** t0mmy <t0mmy!~tprrt@> has joined #yocto12:42
*** igor1 <igor1!~igor@> has joined #yocto12:43
ant_workRP: ah, again on deltask, I see you selectively drop do_populate_sysroot12:44
ant_workso this should simplify sstate, for any recipe I bet12:45
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has quit IRC12:53
*** t0mmy <t0mmy!~tprrt@> has quit IRC12:55
*** t0mmy <t0mmy!~tprrt@> has joined #yocto12:55
*** ojdo <ojdo!~ojdo@unaffiliated/ojdo> has joined #yocto12:59
*** mdnneo <mdnneo!~umaucher@> has quit IRC13:02
jkuthe openssl recipe does this during install: "ln -sf ${sysconfdir}/ssl/certs ${D}${libdir}/ssl/certs"13:05
*** t0mmy <t0mmy!~tprrt@> has quit IRC13:06
jkuthis works on target (link points to /etc/ssl/certs), but is broken for native: in a native sysroot the link points to "./../../../../../../work/x86_64-linux/openssl-native/1.0.2j-r0/recipe-sysroot-native/etc/ssl/certs" ...13:07
jkuthat is from _wayland-native_ recipe-sysroot-native-directory. The linked file doesn't even exist but even if it did, that looks really wrong (it's a completely different sysroot)13:10
jkuis there something wrong with how the link is created?13:10
*** marka <marka!~masselst@> has joined #yocto13:11
*** t0mmy <t0mmy!~tprrt@> has joined #yocto13:13
RPjku: I wonder if we broken this with rss13:16
pohly1maxin, anyone: I'm having problem getting libtasn1-native built with OE-core master. First it failed because of "yacc: command not found", after addding DEPENDS = "byacc-native" it fails with a syntax error error in ASN1.y.13:16
jkuRP: I think so13:18
RPjku: what is supposed to happen is the paths are meant to become relative in the relocation code13:18
*** Guest27309 <Guest27309!> has joined #yocto13:19
SaurRP: Maybe you can explain to me why an RRECOMMENDS on some non-existing recipe must lead to a build error? (And the non-existence can be caused by COMPATIBLE_MACHINE, BBMASK, the non-existing recipe being in another layer that is not part of the current build, or that it just does not exist yet).13:19
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC13:20
kanavinjku: if it's any consolation, after dnf I'm going to look at openssl 1.1, and the plan is to throw away existing recipe entirely :)13:21
maxinpohly1: haven't tested it.. will check now13:21
jkuRP not sure where that is, can you point me to right direction?13:21
pohly1maxin: that's with recipe specific sysroots. I'm currently checking whether libtasn1 for the target still builds.13:21
*** JosePerez <JosePerez!~jgperezc@> has joined #yocto13:22
RPSaur: RRECOMMENDS are treated as a package management feature and real dependencies as far as the build process is concerned. Yes, we could ignore them but it would lead to non-deterministic builds13:22
maxinpohly1: just did a libtasn1-native (4.10) with musl and it works as expected.13:23
*** dmoseley <dmoseley!> has joined #yocto13:23
RPjku: make_relative_symlink() in sstate.bbclass13:23
SaurRP: Hmm. In the specific case I have a RRECOMMENDS_${PN} = "foo" in recipe, and specifies COMPATIBLE_MACHINE = "armv7a" and I am building for MIPS and of course i get an error due to this. But it just seems wrong...13:24
RPSaur: I understand, however the alternative would be potentially large pieces of builds disappearing with no error/warning due to typos13:25
RPSaur: I prefer determinism13:25
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto13:26
pohly1maxin: which "yacc" implementation is called when building libtasn1-native? Is it perhaps the one from your host?13:26
*** avalluri <avalluri!~avalluri@> has joined #yocto13:26
pohly1DEPENDS = "bison-native" fixes the problem for me. byacc-native was something else.13:27
pohly1(byacc instead of just yacc).13:27
*** caiortp <caiortp!~inatel@> has joined #yocto13:28
SaurRP: Ok, in the general case I can understand your concern. But in the case of RRECOMMENDS on something that is excluded due to COMPATIBLE_MACHINE I think it is deterministic. Or am I missing something?13:28
kanavinRP: what is the difference between RRECOMMENDS and RDEPENDS then?13:29
maxinpohly: I have bison in my host.. probably that explains it (  bison --version bison (GNU Bison) 3.0.2)13:30
RPSaur: people often complain about this and COMPATIBLE_HOST and the distro features code. I'm sure we could create something which recurses up the build system try, disabling anything that depends on these things automatically. The trouble is user visibility into the process and knowing when to stop.13:30
kanavinRP: ah right, NO_RECOMMENDATIONS13:31
kanavinRP: I fixed this myself the other day :-/13:31
RPSaur: If we implement it, I can guarantee that things you want in your build would silently disappear and then you'd be getting upset that these were silently removed13:31
kanavinand already forgot :)13:31
RPkanavin: They are used by the package manager differently, for example installation of kernel modules verses builtin13:31
pohly1I wonder... should bitbake also sanitize "PATH", at least optionally? I.e. set up tmp/work/sysroot-native/bin etc. with symlinks to the assumed provided tools, then run with PATH containing only the "clean" directories?13:32
RPSaur: You might not like the current situation but its at least quite clear. The alternative would just be a nightmare to maintain. It would also be painful in bitbake's dependency code and I don't think we need more complexity there13:33
pohly1ASSUME_PROVIDED will make that a bit harder, though.13:33
RPpohly1: In one of my experiment patches, I created symlinks to speed up searching for binaries in PATH, reducing the number of stat calls needed13:34
RPpohly1: couldn't prove a speed increase though13:34
SaurRP: Could an alternative solution to the RRECOMMENDS + COMPATIBLE_MACHINE be a new bbclass that lets th package build as normal for compatible machines, but just creates an empty package for others? Obviously one cannot set COMPATIBLE_MACHINE then, but instead would set some other similar variable.13:34
RPSaur: no. Really not going there.13:35
pohly1RP: just getting the build to be less dependent on the host already would be worthwhile, IMHO, even if there is no speed increase.13:35
SaurRP: Well, the idea would be to inherit the class in the specific recipe, so that it is obvious what is happening.13:35
RPSaur: might as well just code the recommends in a common include/class file13:36
RPSaur: creating an empty package just to solve this is horrible13:37
kanavinrburton: continuing the python modules issue from last week, this is the dependency line I ended up with: python-core python-codecs python-netclient python-email python-threading python-distutils librepo python-shell python-subprocess libcomps libdnf python-sqlite3 python-compression python-pygpgme python-backports-lzma python-rpm python-iniparse python-json python-importlib python-curses python-argparse13:39
*** Crofton <Crofton!> has joined #yocto13:39
kanavinrburton: do you think that's a bit much, and just depending on python-modules is better?13:39
RPkanavin: not for target usage13:40
kanavinRP: yeah, this is in fact RDEPENDS_${PN}_class-target of dnf13:40
*** lamego <lamego!~jose@> has joined #yocto13:42
*** falk0n <falk0n!> has joined #yocto13:49
*** _Ben <_Ben!ae727009@gateway/web/freenode/ip.> has joined #yocto13:52
*** Nilesh_ <Nilesh_!uid116340@gateway/web/> has quit IRC13:54
*** Crofton <Crofton!> has quit IRC13:54
RPkanavin: I'd say its reasonable13:54
SaurIf I have an anonymous python function that calls bb.warn() it will produce a warning during recipe parsing that is prefixed with the recipe name, which is fine and what I want. However, it will also produce warnings later on during building, and they are not prefixed with anything. Is there some easy way to determine that it is the first case that is running and only produce the warning then?14:01
rburtoned2: test_qemu fails here for me with ross/mut14:10
*** florian_kc <florian_kc!> has joined #yocto14:10
rburtoned2: /dev/vda2 != /dev/root14:10
*** florian_kc <florian_kc!> has quit IRC14:10
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto14:10
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC14:11
ed2rburton: oh, again :( I'll look at it.14:13
ed2rburton: i tested wic multiple times with my patches on top of ross/mut on Friday. all oe-selftest wic test cases were passed.14:14
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC14:14
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@> has joined #yocto14:16
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has joined #yocto14:16
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto14:16
*** hamis <hamis!~irfan@> has quit IRC14:17
rburtoned2: should test_qemu expect a specific machine? i use intel-corei7-64 here.14:19
*** paulg <paulg!> has joined #yocto14:20
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC14:21
ed2rburton: I usually run tests on qemu* machines.14:22
ed2rburton: I'm not sure if intel-core7-64 images can be run on qemu. never tried14:23
rburtonthe test should either set machine if it has to, or adapt to cope14:23
ed2rburton: but it's not the case. that failure usually happens due to wrong WKS_FILE value.14:23
*** rburton <rburton!> has left #yocto14:24
*** t0mmy <t0mmy!~tprrt@> has quit IRC14:24
*** rburton <rburton!> has joined #yocto14:24
*** ZubairLK <ZubairLK!~Thunderbi@unaffiliated/zubairlk> has joined #yocto14:25
*** t0mmy <t0mmy!~tprrt@> has joined #yocto14:26
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto14:29
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC14:35
*** jku <jku!~jku@> has quit IRC14:36
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto14:37
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has quit IRC14:39
*** Crofton <Crofton!> has joined #yocto14:41
sgw_rburton: ed2: we recently added support for running meta-intel BSPs in QEMU14:46
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC14:48
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto14:49
*** ed2 <ed2!Adium@nat/intel/x-zseqstaneibrdfzs> has quit IRC14:50
*** ed2 <ed2!Adium@nat/intel/x-jcbmpjhjlavtduia> has joined #yocto14:50
*** Ramose__ <Ramose__!c05e2222@gateway/web/freenode/ip.> has joined #yocto14:55
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC14:57
Ramose__Hello, Just wanted to build qtwebkit package with QtMultimedia backend instead of gstreamer , what should should it requires in file ?14:58
*** AndersD <AndersD!> has quit IRC14:59
Strike5150Hello, how can I have a recipe depend on a user added through USERADD15:01
Strike5150I'm getting some host contamination warnings and I think its because the recipe doesn't have the user required by the files for ownership15:02
*** aV_V <aV_V!~aV_V@> has joined #yocto15:05
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto15:07
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto15:11
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has quit IRC15:11
marquizhmm, why does building core-image-sato fail with "| configure: error: unable to find usable PCRE library" in rpm(?)15:13
marquizdoes not seems to happen on all build hosts15:13
*** madisox <madisox!> has joined #yocto15:13
*** geoffrey_l_ <geoffrey_l_!> has joined #yocto15:18
*** geoffrey_l <geoffrey_l!> has quit IRC15:18
*** ed2 <ed2!Adium@nat/intel/x-jcbmpjhjlavtduia> has quit IRC15:19
SaurRP: I realized that creating an empty package was not needed at all, and rather defeated the purpose. However, here is the class that I did implement to solve my problem:
SaurRP: It allows me to set SUPPORTED_MACHINE instead of COMPATIBLE_MACHINE and then produces a package for the supported machines. For any other machines it will not produce an image and instead produces a warning.15:21
SaurRP: This makes RDEPENDS and RRECOMMENDS work with packages that inherits the class the way I want. :)15:21
*** jairglez <jairglez!~jairdeje@> has joined #yocto15:22
*** _Ben <_Ben!ae727009@gateway/web/freenode/ip.> has quit IRC15:22
*** grma <grma!~gruberm@> has quit IRC15:24
RPSaur: Whilst I'm sure it works for you, I'm not convinced we want to encourage things like that15:24
SaurRP: Well, it is a bit of a special case... :)15:25
*** clement_ <clement_!> has joined #yocto15:25
*** clement <clement!> has quit IRC15:25
*** geoffrey_l_ <geoffrey_l_!> has quit IRC15:25
*** geoffrey_l <geoffrey_l!> has joined #yocto15:25
*** clement_ is now known as clement15:25
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC15:26
*** clement <clement!> has quit IRC15:26
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto15:26
*** rubato <rubato!5469791e@gateway/web/freenode/ip.> has joined #yocto15:28
*** eduardas_m <eduardas_m!~eduardas_@> has joined #yocto15:29
CroftonSaur, conversations like that suggest an email to the architecture list would be nice to see if other peope have similar issues15:29
*** clement <clement!> has joined #yocto15:30
*** eduardas_m <eduardas_m!~eduardas_@> has quit IRC15:30
*** eduardas_m <eduardas_m!~eduardas_@> has joined #yocto15:31
*** nighty <nighty!> has quit IRC15:33
*** geoffrey_l_ <geoffrey_l_!> has joined #yocto15:34
*** geoffrey_l <geoffrey_l!> has quit IRC15:34
*** rbuchmann <rbuchmann!> has joined #yocto15:35
*** stephano <stephano!~stephano@> has joined #yocto15:35
*** nighty <nighty!> has joined #yocto15:36
*** bavery_fn <bavery_fn!~bavery@> has joined #yocto15:45
*** quandtum <quandtum!~quandtum@> has joined #yocto15:46
*** jairglez <jairglez!~jairdeje@> has quit IRC15:47
sgw_rburton: zeddii might have just found a long hidden native dependency of at-spi2-atk on glib-compile-schemas, I am working on a patch15:54
rburtoni wouldn't be surprised if some stealth deps on common host tools sneak out of the woodwork15:55
rburtonlike glib-native15:55
sgw_rburton: yup glib-2.0-native to be exact in this case, patch forthcoming15:56
*** stephano <stephano!~stephano@> has quit IRC15:56
*** _Ben <_Ben!81612d46@gateway/web/freenode/ip.> has joined #yocto15:58
rburtonyeah thats the one15:58
*** sjolley <sjolley!~sjolley@> has quit IRC15:59
*** grma <grma!> has joined #yocto16:01
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has quit IRC16:02
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:c8a6:17d:5ad6:1157> has quit IRC16:02
*** zeenix <zeenix!~zeenix@> has quit IRC16:05
*** Talorno <Talorno!> has quit IRC16:07
*** frsc <frsc!~frsc@> has quit IRC16:09
*** nbigaouette <nbigaouette!> has quit IRC16:10
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has joined #yocto16:17
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC16:19
*** likewise <likewise!~chatzilla@> has joined #yocto16:19
*** cdleonard <cdleonard!> has quit IRC16:25
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto16:25
*** darknighte <darknighte!~darknight@pdpc/supporter/professional/darknighte> has joined #yocto16:27
*** dv_ <dv_!~quassel@> has quit IRC16:27
*** dv_ <dv_!~quassel@> has joined #yocto16:28
*** geoffrey_l_ <geoffrey_l_!> has quit IRC16:33
*** sjolley <sjolley!~sjolley@> has joined #yocto16:34
*** paulg <paulg!> has quit IRC16:37
*** rubato <rubato!5469791e@gateway/web/freenode/ip.> has quit IRC16:39
*** aV_V <aV_V!~aV_V@> has quit IRC16:40
*** ant_work <ant_work!> has quit IRC16:40
*** radzy <radzy!> has quit IRC16:44
*** LocutusOfBorg <LocutusOfBorg!~Gianfranc@ubuntu/member/locutusofborg> has quit IRC16:46
*** eduardas_m <eduardas_m!~eduardas_@> has quit IRC16:48
pohly1I want to make some helper script available that wraps some commands in a native sysroot. I could make that a stand-alone recipe like "wic-tools" which then calls binaries installed in its recipe-sysroot-native. But how do I create the script itself, and where?16:49
*** grma <grma!> has quit IRC16:50
*** rajm <rajm!> has quit IRC16:50
pohly1The easiest solution would be to put it into $WORKDIR in do_compile, but then I must ensure that the tasks always runs (i.e. disable sstate). How can that be achieved?16:50
*** radzy <radzy!> has joined #yocto16:52
rburtonpohly1: why not just install from mytools-native into the native sysroot and depend on that where you need it?16:59
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto17:00
pohly1rburton: the path to the native sysroot into which mytools-native installs is very deep and user unfriendly.17:02
pohly1It's *not* mytools-native/1.0-r0/recipe-sysroot-native - that only has the tools mytools-native itself depends on.17:03
pohly1The file created in do_compile ends up in sysroot-destdir with a full absolute path beneath it.17:04
kergothyou shouldn't be manually calling anything in workdir, ever17:04
kergothwic-tools is a special case for image construction, but that isn't run manually either, it's run from another recipe17:05
kergothso the depth of the path is irrelevent17:05
rburtoni must be confused17:05
rburtonunderstandable because i'm feeling like death warmed up today17:05
*** Strike5150 <Strike5150!18de02de@gateway/web/freenode/ip.> has quit IRC17:05
rburtonso one downside of recipe sysroots is that deleting tmp/ takes FOREVER17:06
pohly1Before the recipe specific sysroot changes, it used to be kind of okay that one called binaries from tmp/sysroots/x86-64 directly on the build host. What's the right way of providing tools to the developer now?17:06
pohly1I guess that's my question...17:06
pohly1kergoth: ^^^17:06
JaMapohly1: are you using rm_work with rss? are you noticing some issues with it?17:06
JaMaI see all incremental builds failing in random places so I wonder if rm-work is cause of that17:07
*** paulg <paulg!> has joined #yocto17:07
pohly1JaMa: sorry, no idea.17:07
pohly1Haven't tried.17:07
pohly1Need to go now, back later...17:07
kergothmanually running files in the global sysroot was never a good idea. the fact that it happened to work was luck, not intention17:07
kergoththat said, writing wrapper scripts with accompanying recipes should be fairly straightforward..17:08
kergothi.e. a script in contrib that builds a corresponding recipe and adds its native sysroot to the PATH and runs the real underlying script17:08
* kergoth shrugs17:08
pohly1kergoth: yes, that's exactly what I try to achive, and it's currently not clear to me where that script should go and how to create it. Are there examples, besides runqemu (which isn't created)?17:09
pohly1Anyway, really need to go.17:09
rburtontoday's wee python hack:
kergothrunqemu isn't created, but it does depend on native recipes for its helpers, so is along similar lines17:10
kergothrburton: cute :)17:10
*** fl0v01 <fl0v01!> has quit IRC17:10
rburtonkergoth: was writing save/restore environ code and realised with is perfect17:11
*** quandtum <quandtum!~quandtum@> has quit IRC17:11
kergothi'm never quite sure how to feel about context managers that technically affect the entire process, but it does work fine generally17:12
rburtonyeah environ is a bit evil17:12
*** bavery_fn <bavery_fn!~bavery@> has quit IRC17:12
rburtontempted to fiddle the bits of OE that i'm calling so it doesn't have to touch it17:12
*** ed2 <ed2!Adium@nat/intel/x-dorpkjenjgusprlw> has joined #yocto17:13
*** Circuitsoft <Circuitsoft!4b92a52b@gateway/web/freenode/ip.> has joined #yocto17:15
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto17:15
*** ed2 <ed2!Adium@nat/intel/x-dorpkjenjgusprlw> has quit IRC17:16
CircuitsoftHello - my initramfs has a copy of my kernel in it.17:16
*** ed2 <ed2!Adium@nat/intel/x-dyosnsgjebdolsfp> has joined #yocto17:16
*** TobSnyder <TobSnyder!> has quit IRC17:16
CircuitsoftI ran "bitbake -g -u depexp core-image-mysys-initramfs" and while linux-yocto shows up in the list, it has no reverse depends.17:16
*** joseppc <joseppc!~josep@linaro/joseppc> has quit IRC17:16
*** pauldevguy <pauldevguy!~pauldevgu@> has joined #yocto17:22
*** dreyna_ <dreyna_!> has joined #yocto17:23
*** rbuchmann <rbuchmann!> has quit IRC17:27
*** dogisfat <dogisfat!d1765a78@gateway/web/freenode/ip.> has joined #yocto17:28
*** dreyna_ <dreyna_!> has quit IRC17:28
*** t0mmy <t0mmy!~tprrt@> has quit IRC17:29
*** djcobble <djcobble!c0373729@gateway/web/freenode/ip.> has joined #yocto17:37
*** jku <jku!> has joined #yocto17:38
RPrburton: I've noticed they take an age to delete too. So many hardlinks :(17:42
*** jamesp <jamesp!~jamesp@> has joined #yocto17:42
*** csanchezdll <csanchezdll!> has left #yocto17:44
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has quit IRC17:44
*** moto-timo <moto-timo!~ttorling@> has joined #yocto17:46
*** moto-timo <moto-timo!~ttorling@> has quit IRC17:46
*** moto-timo <moto-timo!~ttorling@fsf/member/moto-timo> has joined #yocto17:46
*** qt-x <qt-x!~Thunderbi@> has quit IRC17:47
*** graphiqs <graphiqs!> has quit IRC17:48
kanavinalimon: how do I get oeqa/runtime/ to run?17:50
kergothrburton, RP: wonder if rm_work should just become default at some point, at least then the removal is distributed over time17:50
kanavinalimon: it doesn't seem to be enabled anywhere in testimage.bbclass, and I don't know where else to look17:50
RPkergoth: If only rm_work wasn't a horrible hack :/. I keep trying to find a way to better integrate it but its hard :/17:51
*** JoiF <JoiF!~jofr@> has quit IRC17:52
RPkergoth: I'm a little disappointed at how much overhead rss is having :(17:52
RPkergoth: considering a patch to make the native .pc files relocateable and dropping .la files17:52
*** jairglez <jairglez!~jairdeje@> has joined #yocto17:52
RP(less files that then need sed treatment)17:52
* kergoth nods17:53
RPAlso, binutils link scripts are rather a mess with some odd paths we never use afaict17:53
fraydo we have anything in the system that still -needs- .la files?17:53
RPfray: I doubt it on linux17:54
alimonkanavin: atm is broke (previously too), it need to be fixed and enabled in the Autobuilder17:54
alimonkanavin: i think mariano have the task and a bug...17:54
khemI think dropping .la files in general is a good thing17:54 files are an out dated concept to support broken systems (AIX/Solaris/etc)17:55
RPkhem: we just run the risk of breaking by deviating from libtool's preferred way of working...17:55
frayso I'd hope we can safely drop them17:55
kergothdoes anyone care about libtool's preferred way of working? :)17:55
* fray hates autoconf, but libtool is 100x worse..17:55
frayalmost has bad a perl17:55
moto-timoonly 100% worse?17:56
RPkergoth: well, there is that :)17:56
alimonkanavin: for example the whole logic for install packages isn't needed, since we build the core-image-sato-sdk-ptest image17:56
* RP also wishes the gnupg people would start using pkgconfig17:56
RPkudos to anyone else who raises that on their mailing list btw ;-)17:56
kergothRP: would be nice to stop needing the sed replacements at all. pkgconfig sysroot and wrapper scripts should be able to cover 90% of it, if the wrappers are tweaked to go by their own location rather than needing sed replacements themselves17:57
kanavinalimon: okay, the reason I'm asking is that I just ported runtime/ to runtime/ :) and _ptest was next to be fixed :)17:57
khemRP: gentoo ditches libtool too, we cant be worse17:57
kanavinalimon: but I guess I can leave it alone then!17:58
RPkergoth: how do you relocate the wrapper scripts? :)17:58
alimonkanavin: yep17:58
kanavinalimon: and it probably won't even need to use package installation with dnf at all17:58
kergothRP: adjust them to go by $0 with relative paths, so they don't need it17:58
RPkergoth: seriously, the wrappers need to learn how to find their cwd to be able to solve that one17:58
kanavinalimon: what's mariano's nickname, I'd like him to see this conversation17:58
RPkergoth: right17:58
kergothi have recieps that do so without even needing to modify create_wrapper17:58
*** jairglez <jairglez!~jairdeje@> has quit IRC17:59
kergothwould obviously be a fairly substantial effort, lots of breakage to fix.. i'll see if i care enough..17:59
RPkergoth: if you want to feel sad about the enormity of it, "cat tmp/sysroots-components/x86_64/*/fixmepath"18:00
kergothpath relocation issues have always annoyed me. rather tempting to just wrap every binary that ends up in the sysroot bindir to use process namespaces to relocate via bind mount all a recipe's scripts to point at a path they're configured to run in18:00
kergothwouldn't need per-recipe wrapper construction to do that, in theory18:00
kergothi.e. —prefix=/oe, then mount the recipe's content there for the process18:01
kergothbit messy with per-recipe sysroots for deps, though, unless you mount the deps in predictible paths too18:02
kergoththat would be a rather interesting possibility, actually. avoid all the hard linking in favor of predictable process namespace mounts and PATH adjustment18:04
*** jairglez <jairglez!~jairdeje@> has joined #yocto18:04
kergothobviously only helps the native bits, still need the sysroot for linking18:04
* kergoth gets more coffee18:04
*** dreyna_ <dreyna_!> has joined #yocto18:05
kergoththough if you adjusted the mounts in a way that affected the toolchain, you could handle linking deps the way nix does. i.e. —with-some-lib=/oe/that-other-thing/lib18:06
kergothwonder how much overhead that would impose.. possibly not much, since the kernel / vfs would be doing most of the work18:07
justanotherboykanavin: just a question, did you modified the smart test with current master, it did changed a lot18:12
kanavinjustanotherboy: no, I'm currently basing my work on a version of master from December 20th18:13
kanavinjustanotherboy: I will rebase it, but it's a task in itself, because of rss and oeqa rework18:13
kanavinjustanotherboy: for now I have many other issues to solve still :)18:13
justanotherboykanavin: Indeed, is not THAT hard, but the current branch won't work18:14
justanotherboykanavin: dnf also needs createrepo to create the index, right?18:14
kanavinjustanotherboy: createrepo_c :)18:15
ed2rburton: I thought I saw this patchset in ross/mut at some point. Now I don't see it there anymore.18:15
ed2rburton: any problems with it?18:15
kanavinjustanotherboy: I've removed old python implementation and replaced it with the current C implementation18:15
kanavin(of createrepo)18:15
justanotherboykanavin: Nice that should speed index creation, just don't forget to add it to testimage class, I just discovered that we need for QA team.18:18
kergothhmm, could even do read only bind mounts for everything we don't want it to be able to write to..18:20
*** bavery_fn <bavery_fn!~bavery@> has joined #yocto18:21
khemdo we put the latest recipe report on wiki as well ? or just email18:21
kanavinjustanotherboy: I think that should cover it
justanotherboykanavin: indeed18:22
*** Guest27309 <Guest27309!> has quit IRC18:23
*** toscalix <toscalix!~toscalix@> has quit IRC18:25
ed2rburton: oe-selftest -r wic.Wic.test_qemu passed in my intel-corei7-64 target :(18:26
ed2rburton: I'm using your branch18:27
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC18:28
*** Guest27309 <Guest27309!> has joined #yocto18:28
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto18:29
*** redengin <redengin!~redengin@2601:600:9200:a356:4464:d262:4c20:d9de> has quit IRC18:39
*** redengin <redengin!~redengin@2601:600:9200:a356:225:22ff:fe3a:aa83> has joined #yocto18:39
ed2rburton: all wic tests passed18:40
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has quit IRC18:43
*** stephano <stephano!stephano@nat/intel/x-izhcozxmtjicnvcl> has joined #yocto18:44
RPed2: did the tests run in the same order? There is something not right :/18:49
ed2RP: i think unittest runs them in alphabetical order, so yes, the order should be the same.18:50
*** t0mmy <t0mmy!> has joined #yocto18:50
ed2RP: I've noticed one nasty behaviour of oe-selftest: it restores backup configs when test is interrupted by Ctrl+C. So, if I edit config files when tests are running and then press Ctrl+C all my changes disappear.18:53
ed2RP: I'm not saying this is the case here, but probably something similar, i.e. configuration issues.18:54
*** link <link!> has joined #yocto18:54
ed2RP: I hope they'll pass on AB as it uses clean configs (hopefully).18:54
*** link is now known as Guest1743518:54
ed2RP: I used clean new target for my experiment and all tests passed.18:56
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has joined #yocto18:57
*** jairglez <jairglez!~jairdeje@> has quit IRC19:01
*** jairglez <jairglez!~jairdeje@> has joined #yocto19:06
falk0n /quit19:10
*** falk0n <falk0n!> has quit IRC19:10
*** bluelightning <bluelightning!~paul@> has joined #yocto19:13
*** bluelightning <bluelightning!~paul@> has quit IRC19:13
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:13
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC19:14
*** istarilucky <istarilucky!~rlucca@> has quit IRC19:15
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto19:16
*** ash_charles <ash_charles!~acharles@2607:fad8:4:6:5aac:892e:cbe9:f7fc> has quit IRC19:19
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC19:24
*** mr_science <mr_science!> has joined #yocto19:26
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto19:26
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto19:27
*** jku <jku!> has quit IRC19:32
*** Guest87261 <Guest87261!~john@> has joined #yocto19:33
*** Guest27309 <Guest27309!> has quit IRC19:35
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto19:37
rburtoned2: <— worked for me ab too19:38
rburtoned2: for, for the ab too19:38
rburtonso no idea why it broke here19:38
ed2rburton: that's a great news. I thought I'll have to fix it again for the 3rd time :)19:39
ed2rburton: did you see my question about ?19:40
ed2rburton: did it break something?19:40
*** stephano <stephano!stephano@nat/intel/x-izhcozxmtjicnvcl> has quit IRC19:43
*** robert_ <robert_!~lyang1@> has joined #yocto19:47
*** robert_ is now known as Guest4303419:48
*** Guest63917 <Guest63917!~lyang1@> has quit IRC19:49
*** present <present!> has joined #yocto19:50
pohly1RP: could it be that bb.event.RecipeTaskPreProcess doesn't fire for native recipes?19:51
pohly1I see in "bitbake -c listtasks my-native-recipe" that there is a do_rm_work tasks, but "bitbake -g my-native-recipe" does not list it and it also doesn't run, i.e. the actual dependencies never got added.19:53
pohly1my-native-recipe inherits native.bbclass.19:53
pohly1I just checked with qemu-native, there it works :-/19:54
pohly1Hrmm. Need to dig deeper.19:54
*** Snert_ <Snert_!~snert_@> has quit IRC19:56
*** robert__ <robert__!~lyang1@> has joined #yocto20:05
*** Guest43034 <Guest43034!~lyang1@> has quit IRC20:06
*** hundeboll <hundeboll!> has quit IRC20:08
*** john1 <john1!> has joined #yocto20:11
*** Guest87261 <Guest87261!~john@> has quit IRC20:12
*** vmeson <vmeson!> has quit IRC20:20
*** vmeson <vmeson!> has joined #yocto20:20
*** nrossi <nrossi!uid193926@gateway/web/> has quit IRC20:23
*** igor1 <igor1!~igor@> has quit IRC20:24
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC20:27
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto20:28
*** jku <jku!> has joined #yocto20:35
*** pauldevguy <pauldevguy!~pauldevgu@> has quit IRC20:35
*** Snert_ <Snert_!~snert_@> has joined #yocto20:37
*** link <link!> has joined #yocto20:40
*** link is now known as Guest5605320:40
*** jku <jku!> has quit IRC20:41
*** hundeboll <hundeboll!> has joined #yocto20:45
*** hundeboll <hundeboll!> has joined #yocto20:45
*** marka <marka!~masselst@> has quit IRC20:46
*** justanotherboy <justanotherboy!mlopezva@nat/intel/x-gjeibnpczmydixet> has quit IRC20:48
*** justanotherboy <justanotherboy!mlopezva@nat/intel/x-iawnkwtlbyqfpdgn> has joined #yocto20:49
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC20:51
*** Guest56053 <Guest56053!> has quit IRC20:52
*** stephano <stephano!~stephano@> has joined #yocto20:52
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto20:56
*** falstaff <falstaff!> has quit IRC20:57
*** falstaff <falstaff!> has joined #yocto20:59
falstaffWhat does _ exactly do to a variable? I have a custom image class, along with a IMAGE_CMD_test. Now I created a distro test, and somehow this seems to interfere21:00
*** igor1 <igor1!~igor@> has joined #yocto21:00
*** sameo <sameo!~samuel@> has quit IRC21:00
*** sameo <sameo!~samuel@> has joined #yocto21:01
neverpanicNAME_foo replaces NAME whenever the special variable OVERRIDES contains foo21:01
bluelightningfalstaff: those are called "overrides"21:01
neverpanicThe distro name is one of the default overrides21:01
falstaffOh ok... So naming a image class test and a distro is then not a good idea I guess?21:02
bluelightningfalstaff: well, the image class name here isn't important, the name of the IMAGE_FSTYPES item you're creating is21:03
falstaffHm, afaik with IMAGE_CMD_test I created a name valid for IMAGE_FSTYPES?21:05
falstaffSo I did IMAGE_CLASSES += "image_type_test", IMAGE_FSTYPES = "test", and defined in image_type_test.bbclass IMAGE_CMD_test...21:06
*** voltbit <voltbit!~acid___@> has joined #yocto21:14
*** _Ben <_Ben!81612d46@gateway/web/freenode/ip.> has left #yocto21:21
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC21:23
*** ant_home <ant_home!> has joined #yocto21:24
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto21:24
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC21:30
*** tgraydon <tgraydon!~tgraydon@> has joined #yocto21:37
*** alimon <alimon!~alimon@> has quit IRC21:37
*** BaloneyGeek|work <BaloneyGeek|work!~bg14ina@kde/bgupta> has joined #yocto21:42
*** igor1 <igor1!~igor@> has quit IRC21:46
*** voltbit <voltbit!~acid___@> has quit IRC21:50
*** caiortp <caiortp!~inatel@> has quit IRC21:50
*** alimon <alimon!alimon@nat/intel/x-jawnpahcvxstltry> has joined #yocto21:53
*** stephano <stephano!~stephano@> has quit IRC22:07
*** vmeson <vmeson!> has quit IRC22:08
*** vmeson <vmeson!> has joined #yocto22:08
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC22:11
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto22:12
*** rburton <rburton!> has quit IRC22:17
*** joshuagl <joshuagl!joshuagl@nat/intel/x-uyneojawwkweunae> has quit IRC22:18
*** manuel_ <manuel_!~manuel@> has joined #yocto22:20
*** pohly1 <pohly1!> has quit IRC22:21
*** joseppc <joseppc!> has joined #yocto22:23
*** joseppc <joseppc!~josep@linaro/joseppc> has joined #yocto22:23
*** Biliogadafr <Biliogadafr!> has quit IRC22:25
*** Biliogadafr <Biliogadafr!> has joined #yocto22:26
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC22:39
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto22:40
*** sjolley <sjolley!~sjolley@> has quit IRC22:48
*** Biliogadafr <Biliogadafr!> has quit IRC22:52
*** paulg <paulg!> has quit IRC22:54
*** fmeerkoetter <fmeerkoetter!> has quit IRC23:01
*** bfederau <bfederau!> has quit IRC23:01
*** fmeerkoetter <fmeerkoetter!> has joined #yocto23:01
*** bfederau <bfederau!> has joined #yocto23:01
robstaif one says "yocto BSP" does that typically include the kernel image, or just the SDK?23:06
RProbsta: BSP usually means the hardware support piece23:07
*** present <present!> has quit IRC23:08
robstaRP: now i'm even more confused, could you clarify?23:08
robstawhat is the HW support piece23:08
RProbsta: the kernel, the graphics support (kernel modules, GL library), definition of what the hardware looks like (pci tools, i2c tools), type of bootloader etc23:09
robstaRP: so what's the correct name for image+bsp produced by a YP?23:11
robstaer, bsp+sdk23:12
RProbsta: I'd class the input metadata as the bsp, the output would be a sdk23:13
RProbsta: not everything has a neat name :/23:13
*** agust <agust!> has quit IRC23:17
robstaRP: i've heard PDK (platform development kit) being used and liked it23:23
RProbsta: that works23:24
*** JaMa <JaMa!~martin@> has quit IRC23:24
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has quit IRC23:26
*** ant_home <ant_home!> has quit IRC23:27
*** manuel_ <manuel_!~manuel@> has quit IRC23:27
*** stryx` <stryx`!~stryx@unaffiliated/stryx/x-3871776> has joined #yocto23:32
*** manuel_ <manuel_!> has joined #yocto23:36
*** nrossi <nrossi!uid193926@gateway/web/> has joined #yocto23:39
RPkhem: any thoughts on ?23:41
*** blueness <blueness!~blueness@gentoo/developer/blueness> has quit IRC23:56
*** blueness <blueness!~blueness@gentoo/developer/blueness> has joined #yocto23:57

Generated by 2.11.0 by Marius Gedminas - find it at!