Friday, 2015-09-18

kergothand a fresh do_configure copies the files fine, i suspect a race00:05
* kergoth tries again00:05
kergothsometimes i wish bitbake handled REPLACES, for cases where one recipe is a superset of another, but i can see that causing possible problems with the sysroot content changing under something that depends on the files00:08
*** thePower <thePower!jennyNeutr@2607:b400:24:4001:e4ee:bfe:624a:fac9> has joined #yocto00:11
xulferkergoth:  So I should just throw AUTOREV into PV as well?00:17
kergothno, as i said, SRCPV goes there00:17
kergothit's SRCREV-based, which already includes autorev as appropriate00:17
kergothe.g. PV .= "+git${SRCPV}"00:18
kergothsee the metadata, there are lots of examples00:18
xulferah okay.  thanks again.00:18
kergothaha, and shadow failed again. if i bitbake -c configure shadow, it works, but a bitbake core-image-minimal fails in do_configure for shadow00:20
kergothsomething must be mucking around with the manifests, because configuredeps is correct in the failed case, and bitbake -c configure shadow after the failure continues to fail00:21
kergother, check that, it just worked running configure explicitly after hte failure, bah00:21
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC00:25
*** SoylentYellow <SoylentYellow!~SoylentYe@> has quit IRC00:27
*** roric <roric!> has joined #yocto00:31
kergothaha, got it00:31
*** lpax <lpax!~lpax@unaffiliated/lpax> has quit IRC00:32
kergothin the non-gplv3 case, target gettext's macros aren't available, since we don't want the old gplv2 gettext macros cluttering up things. the problem with that is, aclocal_copy_aclocals only picks up direct native deps of target recipes, and gettext-native doesn't provide the macros, gettext-minimal-native does, which is depended on by gettext-native.00:32
kergothadding gettext-minimal-native to DEPENDS_GETTEXT, so it gets included explicitly and directly, resolves the issue00:33
*** Pixionus <Pixionus!~Pixionus@unaffiliated/pixionus> has joined #yocto00:35
*** staylor <staylor!> has quit IRC00:42
*** roric <roric!> has quit IRC00:53
*** Pixionus <Pixionus!~Pixionus@unaffiliated/pixionus> has quit IRC00:56
*** roric <roric!> has joined #yocto01:09
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has joined #yocto01:19
*** dreyna4529 <dreyna4529!~dreyna@> has quit IRC01:22
*** Snert <Snert!> has joined #yocto01:24
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has quit IRC01:25
*** seebs <seebs!> has quit IRC01:43
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has joined #yocto01:57
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has quit IRC01:59
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has joined #yocto02:00
*** simmel80___ <simmel80___!> has joined #yocto02:04
*** simmel80__ <simmel80__!> has quit IRC02:07
*** sri <sri!> has quit IRC02:10
*** sri <sri!> has joined #yocto02:11
*** sri is now known as Guest3966502:11
*** aehs29 <aehs29!~aehernan@> has left #yocto02:22
*** thePower <thePower!jennyNeutr@2607:b400:24:4001:e4ee:bfe:624a:fac9> has quit IRC02:26
*** sjolley <sjolley!sjolley@nat/intel/x-ewdmbzehesaofxpw> has quit IRC02:27
*** roric <roric!> has quit IRC02:29
Marexkhem: thanks for the nios2 review ;-)02:39
*** seebs <seebs!> has joined #yocto02:39
*** staylor <staylor!~staylor@> has joined #yocto02:41
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto02:51
kergothugh, what the hell02:55
kergothwe remove incompatible licenses from the manifest02:55
kergoththis is a *terrible* idea02:55
kergothif i set gplv3 as not allowed, and a gplv3 package somehow gets into the image, the last thing i want the code to do is *lie* to me about it, hiding the incompatible licenses from the manifest02:56
kergothno, the opposite, i want the build to stop if something i say isn't allowed ends up in my filesystem02:56
* kergoth adds a plan of attack to fix this properly02:57
* kergoth adds todo to open a bug tomorrow02:57
kergothThis boggles my mind, that we'd do this. it's a licensing-related lawsuit waiting to happen02:58
* kergoth rolls eyes02:58
*** dreyna4529 <dreyna4529!~dreyna@> has joined #yocto03:03
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-wcfwctexhbhfprds> has quit IRC03:03
*** staylor <staylor!~staylor@> has quit IRC03:15
*** staylor <staylor!~staylor@> has joined #yocto03:20
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC03:25
*** dreyna4529 <dreyna4529!~dreyna@> has quit IRC03:27
*** staylor <staylor!~staylor@> has quit IRC03:37
*** sjolley <sjolley!~sjolley@> has joined #yocto03:49
*** AndersD <AndersD!> has joined #yocto04:56
*** kanupatar <kanupatar!79f4c042@gateway/web/freenode/ip.> has joined #yocto05:05
kanupatarhi guys05:05
kanupatarHow can I get my yocto version. I have the complete yocto zip.05:05
kanupatarbitbake -v tells its is 1.22.005:06
*** malkauns_ <malkauns_!> has left #yocto05:08
*** malkauns_ <malkauns_!> has joined #yocto05:08
*** roric <roric!> has joined #yocto05:22
Marexuh, zip ?05:29
Marexdid you check for example meta-yocto/conf/distro/poky.conf for DISTRO_VERSION ?05:30
*** hamis <hamis!~irfan@> has joined #yocto05:32
*** sujith_h <sujith_h!~sharidas@kde/developers/sujithh> has joined #yocto06:02
*** marek__ <marek__!> has joined #yocto06:04
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto06:20
*** TobSnyder <TobSnyder!> has joined #yocto06:21
*** dreyna4529 <dreyna4529!> has joined #yocto06:23
*** jku <jku!> has joined #yocto06:24
*** jku <jku!> has joined #yocto06:25
*** khem <khem!~khem@unaffiliated/khem> has quit IRC06:25
*** pohly <pohly!> has joined #yocto06:32
*** roric <roric!> has quit IRC06:36
*** Biliogadafr <Biliogadafr!~User@> has joined #yocto06:39
*** ant_work <ant_work!> has joined #yocto06:43
*** dreyna4529 <dreyna4529!> has quit IRC06:44
*** drou <drou!c32a382b@gateway/web/freenode/ip.> has joined #yocto06:47
drouhi guys06:47
*** stiandre <stiandre!~stiandre@> has joined #yocto06:51
*** belen <belen!Adium@nat/intel/x-gswemfrhrtouilbw> has joined #yocto06:52
*** maxin <maxin!~maxin@2001:998:22:0:3d3e:792b:956f:ac87> has joined #yocto06:53
*** CromFr <CromFr!~CromFr@> has quit IRC06:56
*** kageja <kageja!~kageja@> has joined #yocto06:56
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto06:57
*** CromFr <CromFr!~CromFr@> has joined #yocto06:58
*** Biliogadafr is now known as BiliogadafrBY07:01
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:09
*** bboozzoo <bboozzoo!> has quit IRC07:18
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:28
*** cristianiorga <cristianiorga!~cristiani@> has joined #yocto07:29
*** fl0v0 <fl0v0!> has joined #yocto07:32
*** kanupatar <kanupatar!79f4c042@gateway/web/freenode/ip.> has quit IRC07:33
*** rfolino <rfolino!> has joined #yocto07:35
*** Amynka <Amynka!~amy@gentoo/developer/amynka> has quit IRC07:35
*** Quetesh <Quetesh!> has joined #yocto07:36
*** Quetesh is now known as Amynka07:36
*** Amynka <Amynka!~amy@gentoo/developer/amynka> has joined #yocto07:36
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC07:39
*** aime-Pierre <aime-Pierre!> has joined #yocto07:43
*** likewise <likewise!> has quit IRC07:46
*** malkauns_ is now known as malkauns07:55
*** nighty-_ <nighty-_!> has joined #yocto08:07
*** jonte <jonte!~Jonte@> has quit IRC08:16
*** gunnarx <gunnarx!~gan@> has joined #yocto08:22
*** mago__ <mago__!~mago@> has quit IRC08:23
gunnarxI'm preparing an example, maybe bug-report, for a funky behavior.  What do you propose I base it on?  current tip of master, tip of some other branch, or some tag?08:24
*** mago_ <mago_!~mago@> has joined #yocto08:25
gunnarxI'll just choose current tip of fido then...08:29
*** mckoan|away is now known as mckoan08:31
mckoangood morning08:31
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:31
*** ntl <ntl!> has quit IRC08:35
*** rburton <rburton!> has joined #yocto08:37
*** ntl <ntl!> has joined #yocto08:46
*** belen <belen!Adium@nat/intel/x-gswemfrhrtouilbw> has quit IRC08:57
*** aime-Pierre <aime-Pierre!> has quit IRC09:03
*** aime-Pierre <aime-Pierre!~Thunderbi@> has joined #yocto09:08
*** niteshnarayanlal <niteshnarayanlal!~Nitesh@fedora/niteshnarayanlal> has left #yocto09:24
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC09:28
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto09:29
*** grma_ <grma_!> has joined #yocto09:38
*** grma <grma!> has quit IRC09:39
*** parrot <parrot!~chankitx@> has quit IRC09:42
*** grma <grma!> has joined #yocto09:45
*** grma_ <grma_!> has quit IRC09:45
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC09:46
-YoctoAutoBuilder- build #497 of nightly-multilib is complete: Success [build successful] Build details are at
*** [Sno] <[Sno]!> has quit IRC10:18
*** [Sno] <[Sno]!> has joined #yocto10:37
*** JaMa <JaMa!> has joined #yocto10:50
*** ntl <ntl!> has quit IRC10:51
*** ntl <ntl!> has joined #yocto11:04
[Sno]otavio: I figured out why java crashes - - it was the MCJIT limitation which compiles modules and not functions and can't recompile11:14
[Sno]so first function is compiled fine and all following "get_function_address" calls result in null pointers11:15
[Sno]I have to add a new module for each java function to be compiled ...11:16
*** drou <drou!c32a382b@gateway/web/freenode/ip.> has quit IRC11:19
*** belen <belen!~Adium@> has joined #yocto11:20
*** bboozzoo <bboozzoo!> has joined #yocto11:23
*** [Sno] <[Sno]!> has quit IRC11:25
*** grma <grma!> has quit IRC11:26
*** grma <grma!> has joined #yocto11:33
*** ntl <ntl!> has quit IRC11:43
*** [Sno] <[Sno]!> has joined #yocto11:54
*** ntl <ntl!> has joined #yocto11:57
*** anselmolsm <anselmolsm!~anselmols@> has joined #yocto11:58
*** dmoseley <dmoseley!> has quit IRC12:13
*** dmoseley <dmoseley!> has joined #yocto12:17
*** caiortp <caiortp!~inatel@> has joined #yocto12:29
*** stiandre <stiandre!~stiandre@> has quit IRC12:36
*** stiandre <stiandre!~stiandre@> has joined #yocto12:36
*** IvanSB <IvanSB!> has joined #yocto12:45
*** lpax <lpax!~lpax@unaffiliated/lpax> has joined #yocto12:54
*** tmcguire <tmcguire!~tmcguire@> has joined #yocto12:59
*** tmcguire__ <tmcguire__!~tmcguire@> has quit IRC12:59
*** lamego <lamego!~jose@> has joined #yocto12:59
*** JaMa <JaMa!> has quit IRC13:03
*** egavinc <egavinc!> has quit IRC13:13
*** tsramos <tsramos!~tsramos@> has joined #yocto13:20
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto13:22
*** tsramos <tsramos!~tsramos@> has quit IRC13:23
*** kageja <kageja!~kageja@> has quit IRC13:26
*** stiandre <stiandre!~stiandre@> has quit IRC13:26
*** tsramos <tsramos!~tsramos@> has joined #yocto13:26
*** sjolley <sjolley!~sjolley@> has quit IRC13:50
*** fl0v01 <fl0v01!> has joined #yocto13:52
*** AndersD <AndersD!> has quit IRC13:53
*** fl0v0 <fl0v0!> has quit IRC13:54
*** fl0v01 is now known as fl0v013:55
*** jvaduva <jvaduva!~jvaduva@> has quit IRC13:57
*** gunnarx <gunnarx!~gan@> has quit IRC13:59
*** madisox <madisox!> has joined #yocto13:59
*** lpax_ <lpax_!~lpax@> has joined #yocto14:03
*** lpax <lpax!~lpax@unaffiliated/lpax> has quit IRC14:05
*** tasslehoff <tasslehoff!~Tasslehof@> has quit IRC14:08
*** rfolino <rfolino!> has quit IRC14:11
*** mckoan is now known as mckoan|away14:16
*** BiliogadafrBY <BiliogadafrBY!~User@> has quit IRC14:20
*** Biliogadafr <Biliogadafr!~User@> has joined #yocto14:21
*** afxez0r <afxez0r!afxez0r@nat/intel/x-wyfozgcyfstfzxln> has joined #yocto14:24
*** Biliogadafr <Biliogadafr!~User@> has quit IRC14:26
*** marek__ <marek__!> has quit IRC14:29
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-pznewstppkzwfoig> has joined #yocto14:32
*** acidfoo <acidfoo!~nib@> has quit IRC14:33
*** Aethenelle <Aethenelle!~Aethenell@> has quit IRC14:35
*** staylor <staylor!~staylor@> has joined #yocto14:36
*** ant_work <ant_work!> has quit IRC14:37
*** sjolley <sjolley!sjolley@nat/intel/x-nxvdoxnudxhkhhaw> has joined #yocto14:39
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto14:46
*** acidfoo <acidfoo!~nib@> has joined #yocto14:47
*** gatisp <gatisp!~gp@> has quit IRC14:47
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC14:48
*** aehs29 <aehs29!~aehernan@> has joined #yocto14:57
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto15:03
*** acidfoo <acidfoo!~nib@> has quit IRC15:04
*** acidfu <acidfu!~nib@> has joined #yocto15:04
*** hamis <hamis!~irfan@> has quit IRC15:05
*** Aethenelle <Aethenelle!~Aethenell@> has joined #yocto15:06
*** JaMa <JaMa!> has joined #yocto15:09
*** aj_c <aj_c!Alex_Joya@nat/intel/x-qrkbsoqvcmyhtimn> has joined #yocto15:14
kergothbluelightning: any thoughts on ? i could see 'oe.scriptutils: also send WARNING to stderr' being potentially objectionable just due to it being different than bitbake proper15:16
jmesmonIs there a way to disable generation of the sstate-cache? I've got one automated builder that exists to test full rebuilds without sstate, and I'd like to avoid some of the disk space hit the sstate-cache takes.15:16
aj_cI sent a patch to core-oe  but someone made me a correction, actually the correction it makes sense so I'm rewritten the patches. should I uploaded the patch again or just reply to the same subject?15:17
jmesmonaj_c: I don't see any note about _disable_ing in that page. Is there some keywork I'm missing?15:19
*** lamego <lamego!~jose@> has quit IRC15:20
*** aime-Pierre <aime-Pierre!~Thunderbi@> has quit IRC15:20
kergothaj_c: re-submit the series with 'PATCHv2' instead of 'PATCH', generally. there's a commandline argument for it. ideally also list the changes in v2 in the 0/N email.15:20
*** dasabhi <dasabhi!> has joined #yocto15:21
JaMajmesmon: I've sent patch to oe-core to allow this, but it wasn't ever merged15:22
bluelightningkergoth: doesn't bitbake output errors on stderr these days?15:23
kergothbluelightning: yes, but recipetool & friends don't :)15:24
kergothhence the patches15:24
jmesmon:( so far I've avoided using a patched up oe-core.15:24
kergothJaMa, jmesmon: hmm, wonder if overriding SSTATETASKS would work15:24
bluelightningkergoth: ah right, I see... sorry my brain's a bit fried today :(15:24
kergothno worries, it's friday :)15:24
kergothi might submit an RFC to send WARNING to stderr for bitbake, its debatable. i do think it makes sense, though, less for scripts to grep out15:25
kergothi ran into this with newappend, as i wanted it highly scriptable, so you could grab the new append from its stdout without having to grep out the log warnings and crap15:25
kergothin this case the logs aren't the primary output for the user, they really do belong out of band15:26
*** shoragan <shoragan!~shoragan@debian/developer/shoragan> has quit IRC15:26
jmesmonkergoth: ah, somehow just force it to be empty? what would be the best way to do that? I suppose just setting it with `SSTATETASKS=""` in local.conf won't be sufficient because bbclasses will later append to it.15:28
*** kageja <kageja!~kageja@> has joined #yocto15:28
kergothI *think* the series is probably worth submitting to the list, possibly without the warnings commit, though, and send that as an RFC15:28
kergothjmesmon: indeed. could try SSTATETASKS_forcevariable = "". no idea if it'll work, but might be worth trying15:28
kergoththat is, the forcevariablew ill work, but whether emptying SSTATETASKS will have hte desired effect, that i don't know15:29
kergothin theory it should15:29
LocutusOfBorg1hi, I need to make a recipe of a tool that has a custom Makefile. do you have any bbclass helper to just set the CC includes and cross stuff and call $(MAKE) clean/install and so on?15:29
* LocutusOfBorg1 usually writes a cmake script prior to write a recipe15:30
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has joined #yocto15:31
*** kageja_ <kageja_!~kageja@> has joined #yocto15:31
kergothLocutusOfBorg1: that's already done where it's possible to do so. we export env vars for CFLAGS, CC, etc, and then run make -e, which lets the env vars override the makefiles. not pretty, but *usually* works. even better than that would be to read the makefiles in question and hand craft an EXTRA_OEMAKE to pass just the variables in that it obeys, rather than forcing the env vars to flow in with -e15:31
kergothLocutusOfBorg1: make install isn't run by default, because without autotools or similar, there's no standard in regular makefiles for how to make it install into an alternate root15:31
kergothwith automake, it's DESTDIR15:32
*** kageja_ <kageja_!~kageja@> has joined #yocto15:32
kergothbut not all hand-crafted buildsystems use that15:32
kergothso you'll need to write a do_install15:32
LocutusOfBorg1actually I just discovered that the makefile seems to be not using $(CC)15:32
kergothyou'll want to read through its makefiles regardless, to see what vars it obeys, make sure it's not doing anything crazy, make sure it has vars for the target paths that we can override (e.g. prefix/bindir/mandir/etc), and make sure it has an eequivalent to DESTDIR15:32
kergothheh, tahts even worse :)15:32
LocutusOfBorg1kergoth, sure, I know that, the problem actually was the build, for the install I don't care too much :)15:32
kergothsounds like you'll need to patch it up15:32
* kergoth nods15:33
LocutusOfBorg1yes, thanks15:33
kergothsometimes we practically have to rewrite the things15:33
LocutusOfBorg1I was looking at the run.do_compile and I discovered it was "correct"15:33
kergothsometimes devs don't make the best build engineers :)15:33
kergothlots of blind copying and pasting around of things15:33
LocutusOfBorg1trust me as a debian developer I know this so well :)15:33
LocutusOfBorg1usually I write a build system and push it upstream15:33
kergothahh yes, desktop distros have the same issues with getting their vars obeyed15:34
*** lamego <lamego!jose@nat/intel/x-aqqpmxgldmlhyttt> has joined #yocto15:34
kergothparticularly optimizations and whatnot15:34
LocutusOfBorg1but for $dailyjob doing this stuff is costly15:34
LocutusOfBorg1but meh, needed :)15:34
LocutusOfBorg1btw I did create an alias called "rebuild" that does bitbake -ccleanall $1 && bitbake $1, do you have any bitbake tool that does already this?15:35
kergothremember that that won't necessarily rebuild from scratch, if sstate is around it'll use it15:35
*** kageja <kageja!~kageja@> has quit IRC15:35
LocutusOfBorg1trus story15:35
LocutusOfBorg1true :)15:35
kergothif you just want to force it to build from scratch and don't care about possible remnants from the previous build, you can force it to build without cleaning by doing e.g. bitbake -C configure $115:36
kergothbut if you do worry about remnants, you can force a build from scratch by keeping your cleanall and then doing the -C15:36
LocutusOfBorg1the latter :)15:36
kergoth-C flags configure as 'tainted', forcing it to run the task even if it thinks it doesn't need to15:36
LocutusOfBorg1I use -C when I play with custom Makefiles :)15:36
kergothah :)15:36
LocutusOfBorg1yes sure15:36
*** maxin <maxin!~maxin@2001:998:22:0:3d3e:792b:956f:ac87> has quit IRC15:36
kergothyeah, there's no better way to clean and rebuild still15:36
kergothbitbake has new syntax other than -c btw, which is pretty cool15:37
kergothbitbake foo:do_clean bar:do_configure15:37
LocutusOfBorg1usually yes, specially when I move kernel modules to builtin15:37
kergothso i've been thining about writing a custom bitbake scheduler which forces do_clean* to run first15:37
LocutusOfBorg1oh... something new15:37
kergoththen you could bitbake foo:do_clean foo15:37
kergothand it'd do what you'd expect15:37
kergothcurrently it wont..15:37
kergothorder would be undefined15:37
LocutusOfBorg1actually I do this when I want to clean things
*** dasabhi <dasabhi!> has quit IRC15:38
*** psnsilva <psnsilva!~psnsilva@> has joined #yocto15:42
*** lpax_ <lpax_!~lpax@> has quit IRC15:44
*** simmel80___ <simmel80___!> has quit IRC15:46
*** lpax_ <lpax_!~lpax@> has joined #yocto15:46
kergothdenix: what's the status of 4.1 kernel in meta-ti, is it fully supported?15:52
*** sjolley <sjolley!sjolley@nat/intel/x-nxvdoxnudxhkhhaw> has quit IRC15:53
*** stwcx <stwcx!> has quit IRC15:54
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC15:54
*** fl0v0 <fl0v0!> has quit IRC15:57
*** IvanSB <IvanSB!> has quit IRC16:00
*** aehs29 <aehs29!~aehernan@> has left #yocto16:01
*** benjamirc <benjamirc!besquive@nat/intel/x-zjnlwldulcezirei> has joined #yocto16:04
*** IvanSB <IvanSB!> has joined #yocto16:09
*** joseppc <joseppc!> has quit IRC16:11
*** sujith_h <sujith_h!~sharidas@kde/developers/sujithh> has left #yocto16:20
*** lpax_ <lpax_!~lpax@> has quit IRC16:21
*** TobSnyder <TobSnyder!> has quit IRC16:23
*** lpax_ <lpax_!~lpax@> has joined #yocto16:26
*** belen <belen!~Adium@> has quit IRC16:31
*** gabrbedd <gabrbedd!> has quit IRC16:34
*** stwcx <stwcx!~stwcx@> has joined #yocto16:34
*** lpax_ <lpax_!~lpax@> has quit IRC16:36
*** berton <berton!~fabio@> has joined #yocto16:37
kergothHas anyone else tried doing a non-gplv3 build recently?16:40
kergothI'm wondering if the gettext failure is something specific to my environment16:41
* kergoth tries a build without any layers but oe-core16:41
*** lpax_ <lpax_!~lpax@> has joined #yocto16:41
kergothRP: - thoughts?16:42
*** aehs29 <aehs29!~aehernan@> has joined #yocto16:44
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC16:45
*** aehs29 <aehs29!~aehernan@> has left #yocto16:45
*** nerdboy <nerdboy!> has joined #yocto16:50
*** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:50
*** LocutusOfBorg1 <LocutusOfBorg1!> has quit IRC16:50
*** SoylentYellow <SoylentYellow!> has joined #yocto16:51
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto16:52
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC16:52
*** bluelightning_ is now known as bluelightning16:52
RPkergoth: We do run a limited gplv3 build on the AB16:53
RPkergoth: that would seem to make sense FWIW16:53
kergothk. i'll do some checks without local changes to check sanity, and if i keep hitting the shadow build failures without this, will see about submitting upstream16:53
*** pohly <pohly!> has quit IRC16:54
* kergoth ponders16:57
* kergoth checks the AB16:58
*** jku <jku!> has quit IRC17:01
* kergoth wonders why it's succeeding there, if his logic about shadow and gettext is accurate, must be missing something, digging further17:01
RPkergoth: I did mean to go and look at one of my patches after your feedback btw, only to realise it slipped into master before I altered it :(17:03
RPkergoth: I did adjust the other one, just wanted to mention I'd not intentionally ignored the feedback, just screwed up at patch juggling :/17:03
kergothno worries, i just figured you might have decided against use of re for performance reasons17:07
* kergoth didn't actually test that anyway, just threw it out as a possibilit17:07
* kergoth goes to get food17:08
*** aj_c <aj_c!Alex_Joya@nat/intel/x-qrkbsoqvcmyhtimn> has quit IRC17:12
*** psnsilva <psnsilva!~psnsilva@> has quit IRC17:14
*** kageja_ <kageja_!~kageja@> has quit IRC17:14
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has quit IRC17:15
denixkergoth: yes, 4.1 should be fully working now. we are about to make a release with it, but it's fido based. so if you have any issues, especially against master, please report17:15
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto17:15
*** aj_c <aj_c!Alex_Joya@nat/intel/x-fsmoxknjtpmyllzn> has joined #yocto17:16
kergothah, cool, new processor sdk release coming soon?17:19
kergothwill do17:19
*** IvanSB <IvanSB!> has quit IRC17:20
denixkergoth: well, processor sdk is a public name :) I'm making an internal sdk release, which then becomes a processor sdk... everything should be in meta-ti/meta-arago, plus the standard oe-core/meta-oe and few other layers17:30
kergothah, right. cool17:30
kergothclearly unfamiliar with the process :)17:30
*** LocutusOfBorg1 <LocutusOfBorg1!> has quit IRC17:44
*** rburton1 <rburton1!> has joined #yocto17:47
*** ftonello <ftonello!~quassel@> has quit IRC17:47
*** rburton <rburton!> has quit IRC17:48
*** raykinsella78 <raykinsella78!rkinsell@nat/intel/x-pznewstppkzwfoig> has left #yocto17:54
*** sjolley <sjolley!sjolley@nat/intel/x-zubprblvnmeuievs> has joined #yocto17:58
*** aj_c <aj_c!Alex_Joya@nat/intel/x-fsmoxknjtpmyllzn> has quit IRC17:59
*** JaMa <JaMa!> has quit IRC18:03
*** lamego <lamego!jose@nat/intel/x-aqqpmxgldmlhyttt> has quit IRC18:04
*** lamego <lamego!~jose@> has joined #yocto18:04
*** aj_c <aj_c!~Alex_Joya@> has joined #yocto18:08
*** Cardoe <Cardoe!~Cardoe@gentoo/developer/Cardoe> has joined #yocto18:29
*** dasabhi <dasabhi!> has joined #yocto18:34
dasabhihey guys i am getting the following error when i try to use bitbake to make an image18:40
dasabhi mv: target '3.8.7' is not a directory18:40
dasabhi| creation of pre-processed config data failed18:40
dasabhi| config of "standard/clanton" failed18:40
dasabhiany one know a fix for this?18:40
seebsRP, or possibly other people: Has anyone used meta-mingw with gcc 5.2 yet? I'm assuming "no" since the bbappends are still all numbered 4.9.18:41
seebsI've worked around the obvious-ish things, and now I'm getting mysterious failures which are actually not mysterious at all, in which host cc is not defining _WIN32, leading to #error directives. And I am wondering whether I have missed an obvious step that's supposed to set that up.18:42
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC18:44
bluelightningdasabhi: this may help:
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:59
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto19:08
*** dreyna4529 <dreyna4529!> has joined #yocto19:09
dasabhihey so i used bitbake -c devshell linux-yocto-clanton19:10
dasabhiand i used make oldconfig in the new shell19:10
dasabhiand then just used make19:10
dasabhiit looks like it compiled succesfully19:10
dasabhibut i have no idea where this kernel image is19:10
dasabhiany one have any ideas?19:10
*** JaMa <JaMa!> has joined #yocto19:15
kergothjust running make probably isn't going to accomplish what you want19:25
kergothHmm, how did the errno import end up missing from the fetch fix, i did test builds here..19:25
* kergoth scratches head19:25
*** colrack <colrack!~colrack@> has joined #yocto19:31
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:5e51:4fff:febb:401d> has joined #yocto20:09
*** bluelightning <bluelightning!~paul@2001:8b0:258:7d7a:5e51:4fff:febb:401d> has quit IRC20:09
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto20:09
*** lamego <lamego!~jose@> has quit IRC20:12
*** lamego <lamego!~jose@> has joined #yocto20:19
*** aehs29 <aehs29!~aehernan@> has joined #yocto20:21
aehs29khem`: hey can I pm you?20:21
*** berton <berton!~fabio@> has quit IRC20:34
*** nemequ <nemequ!> has quit IRC20:43
dasabhihey i just succuessfully used bitbake to compile a kernel....20:50
dasabhiso...where in the file system is the kernel>20:50
dasabhikernel image**20:50
*** grma <grma!> has quit IRC20:54
kergothdasabhi: see the yocto project documentation. it goes the same place the images go, under tmp/deploy/images21:14
*** IvanSB <IvanSB!> has joined #yocto21:17
*** thePower <thePower!jennyNeutr@2607:b400:24:8002:d4a:1561:8b1a:a4eb> has joined #yocto21:18
dasabhikergoth: i ran the file command on these images and one of them said21:19
dasabhikergoth: : x86 boot sector21:19
dasabhikergoth: is that the kernel image? its called bzImage-clanton...something something21:19
kergothyes, bzImage is a kernel image21:19
dasabhikergoth: ty :)21:20
dasabhikergoth: breh21:20
*** dasabhi <dasabhi!> has quit IRC21:21
*** dlerner <dlerner!> has quit IRC21:27
RPseebs: I've not tried 5.2 with mingw, no21:28
seebsSo, there were a few things that were pretty easy to fix, and apparently it's generally-known that libgomp may not work in mingw32 right now, so I could turn that off.21:35
seebsThen I ran into a bunch of warnings about how mingw headers could only be used with mingw32 targets. I note that it's just "gcc" being called to build these, and I think that's host gcc. Is that the problem, or is this something else?21:35
*** nighty-_ <nighty-_!> has quit IRC21:38
kergothsometimes I wonder if we should let recipetool default to the workspace layer, and auto-create it, instead of requiring the user specify the layer all the time21:41
kergothjust to give them somewhere local to do their work, then they can move it somewhere permanent21:41
kergothi end up creating a meta-local with yocto-layer and adding it to my build with bitbake-layers and then run recipetool against that, when doing development21:42
kergothreally common pattern for me21:42
*** caiortp <caiortp!~inatel@> has quit IRC21:42
*** khem` <khem`!~khem@unaffiliated/khem> has quit IRC21:47
*** gabrbedd <gabrbedd!> has joined #yocto21:48
*** LocutusOfBorg1 <LocutusOfBorg1!> has joined #yocto21:53
*** dorileo <dorileo!~dorileo@> has quit IRC21:54
*** anselmolsm <anselmolsm!~anselmols@> has quit IRC21:55
*** aoibhinn <aoibhinn!sid95825@gateway/web/> has joined #yocto21:56
*** aoibhinn is now known as aoibhinnditori21:57
*** fmeerkoetter <fmeerkoetter!> has quit IRC22:01
*** bfederau <bfederau!> has quit IRC22:01
*** fmeerkoetter <fmeerkoetter!> has joined #yocto22:01
*** bfederau <bfederau!> has joined #yocto22:01
*** thePower <thePower!jennyNeutr@2607:b400:24:8002:d4a:1561:8b1a:a4eb> has quit IRC22:02
*** tsramos <tsramos!~tsramos@> has quit IRC22:13
*** rperier <rperier!~quassel@ubuntu/member/rperier> has quit IRC22:18
*** smartin_ <smartin_!> has quit IRC22:19
*** rperier <rperier!~quassel@2001:41d0:52:100::44a> has joined #yocto22:22
*** smartin_ <smartin_!> has joined #yocto22:25
*** lamego <lamego!~jose@> has quit IRC22:28
*** rburton1 <rburton1!> has quit IRC22:46
*** khem` <khem`!~khem@unaffiliated/khem> has joined #yocto22:48
kergothoh, i see. it's target -> target -> native that gets halted, not target -> native -> native22:54
kergoththen why is this failing at times..22:54
bluelightningkergoth: that's what devtool add is for though22:55
kergothI'm not creating a new recipe, though, particularly not for external sources. 90% of the time i need to modify how something is building / fix a bug in an existing recipe22:56
bluelightningright, then devtool modify is your friend :)22:56
kergothusually via metadata, not source modification22:56
bluelightningso how does recipetool come into it?22:56
kergothall the many commands for appending / altering a recipe?22:57
kergoththats what half of its subcommands are for22:57
bluelightningFYI I'm preparing a patchset for devtool/recipetool/ext SDK; the WIP is on paule/extsdk-devtool-fixes22:57
kergothi'm saying i have to create a layer for it to do its work in22:57
kergothsince i don't want to shove untested stuff into my main layers yet22:57
bluelightninghmm, I guess I see your point22:57
kergothso my thought was what if recipetool defaulted to workspace the same as devtool, and had an option to specify a non-default layer to operate against22:58
*** challinan <challinan!> has quit IRC22:58
kergothnot sure if that'd be good or not, just a possibility to consider22:58
kergothmight be overloading the purpose of workspace22:58
* kergoth shrugs22:58
bluelightningit's all about what makes sense for the overall workflow(s)22:58
kergothrandom idea from my long list of random oe/yocto ideas :P22:58
kergothyeah, speaking of, do we have a list of use cases we're looking to cover?22:59
*** lpax_ <lpax_!~lpax@> has quit IRC22:59
bluelightningI'm not sure I wrote a list; Richard kind of wrote something in an RFC a while back which was the basis for my mental model of things23:00
kergothanyway, had just noticed a common pattern in my workflows of: yocto-layer create local 1; bitbake-layers add-layer meta-local; <some command to mess with bbappends in meta-local> during development, then migrate the changes, if appropriate, to their final destinations23:00
* kergoth nods23:00
*** aehs29 <aehs29!~aehernan@> has left #yocto23:01
kergothe.g. i got sick of my debugging prints in autotools_copy_aclocals changing all my signatures, when i only cared about shadow, so i used recipetool newappend to create an append for shadow and shoved autotools_copy_aclocals () override or autotools_copy_aclocals_append () there while i was debugging it23:01
kergoth(shadow is what was exhibiting my gettext failures with non-gplv3)23:02
bluelightningit sounds like we need a way to turn on those debug messsages through vars23:02
kergothbut i readily admit my workflow might be different than most23:02
bluelightningor maybe they should always be there and you just see them with -D or in the logs23:02
bluelightningI'd be interested in an outline of what you typically do if you have time to post something to the list :)23:03
kergothI can't imagine the need is a common one, i hate to add overhead by sprinkling debugs for unusual cases23:03
kergothbut then, i don't want to leave commented out bb.warn's around, like we have in that function right now..23:03
* kergoth is a bit torn on that23:04
bluelightningI've had similar issues myself... signatures changing just through adding debug messages is pretty annoying23:04
bluelightningthough fortunately not something I hit too often23:04
kergothyeah, i guess keeping the debug messages in would avoid that, but i kind of shy away from too many of those after our experiences with bitbake -D becoming almost completely useless due to the excessive number of messages about non-unusual events..23:06
bluelightningright, yes... to be honest I almost never use -D due to that23:07
bluelightningit's improved, but still doesn't seem to print things I typically need to see23:07
bluelightningI don't think anyone who's looked at it is quite sure how to best improve it though, least of all me23:08
kergothI'd like to focus on logging messages for unusual or unlikely events, and then only add debug informational messages to add context, with an eye toward what it'll be used for23:08
kergoththe parsing messages are clearly to answer the 'did my recipe / config file get parsed'? question, but that's better answered with other tools nowadays, particularly with variable history tracking and whatnot23:09
kergothso those really don't serve much purpose anymore23:09
* kergoth ponders23:09
bluelightningyeah, that makes sense... at least we could increase the debug level required to make those show up23:09
*** KvH <KvH!> has joined #yocto23:10
kergothwtf. i just did bitbake -f shadow:do_configure23:12
kergothand it's running shadow:do_compile after the configure23:12
kergoththat's not what i told you to do23:12
*** KvH_ <KvH_!> has quit IRC23:14
*** stwcx <stwcx!~stwcx@> has quit IRC23:30
*** staylor <staylor!~staylor@> has quit IRC23:32
*** staylor <staylor!> has joined #yocto23:32
*** thePower <thePower!jennyNeutr@2607:b400:b4:2200:78b0:6dcc:7ce0:9bb4> has joined #yocto23:38
*** madisox <madisox!> has quit IRC23:40

Generated by 2.11.0 by Marius Gedminas - find it at!