| 00:12.56 | *** join/#oe phdeswer_ (~phdeswer@91-159-55-220.elisa-laajakaista.fi) |
| 00:56.16 | *** join/#oe ynezz (ynezz@ibawizard.net) |
| 01:04.49 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 01:12.20 | *** join/#oe zxc678 (~zxc678@192.3.173.186) |
| 01:16.14 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 01:16.56 | *** join/#oe zxc678 (~zxc678@192.3.173.186) |
| 01:18.11 | *** join/#oe coolmouse (~coolmouse@113.201.253.71) |
| 01:18.53 | *** join/#oe coolmouse_ (~coolmouse@113.201.253.71) |
| 01:32.40 | *** join/#oe SoylentYellow (~SoylentYe@c-67-169-85-254.hsd1.ca.comcast.net) |
| 01:51.37 | *** join/#oe anarsoul (~anarsoul@S0106848dc7ec0367.vs.shawcable.net) |
| 02:13.03 | *** join/#oe evanmeagher (~MongooseW@73.71.33.109) |
| 02:13.37 | *** join/#oe Aethenelle (~Aethenell@107.138.98.226) |
| 02:18.01 | *** join/#oe zxc678 (~zxc678@192.3.173.186) |
| 02:32.03 | *** join/#oe zxc678 (~zxc678@192.3.173.186) |
| 02:46.10 | *** join/#oe Crofton|road (~balister@c-73-189-176-81.hsd1.ca.comcast.net) |
| 03:26.13 | *** join/#oe evanmeagher (~MongooseW@73.71.33.109) |
| 03:29.53 | *** join/#oe evanmeag_ (~MongooseW@73.71.33.109) |
| 03:34.01 | *** join/#oe evanmeagher (~MongooseW@73.71.33.109) |
| 03:37.59 | *** join/#oe oldtopman (~oldtopman@unaffiliated/oldtopman) |
| 04:27.19 | *** join/#oe evanmeagher (~MongooseW@73.71.33.109) |
| 05:02.21 | *** join/#oe AndersD (~anders@h83-209-191-235.dynamic.se.alltele.net) |
| 06:28.43 | *** join/#oe morphis (~morphis@p5086275C.dip0.t-ipconnect.de) |
| 06:30.12 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 06:31.12 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 07:11.19 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 07:33.48 | *** join/#oe phdeswer_ (~phdeswer@91-159-55-220.elisa-laajakaista.fi) |
| 07:47.47 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 07:52.59 | *** join/#oe jku (jku@nat/intel/x-qlhgegmrghnnfzir) |
| 07:53.33 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-utlybapkhfxnghgu) |
| 08:13.44 | mckoan | good morning |
| 08:22.13 | *** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 08:22.16 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 08:27.21 | mario-goulart | Morning! |
| 08:30.01 | mario-goulart | kergoth: maybe I'm doing something overengineered here. The documentation for DL_DIR says "You can safely share this directory between multiple builds on the same development machine.". Does that mean that multiple bitbake instances are able to share the same DL_DIR at the same time without race conditions? If that's the case, a simple read-write NFS share would do the trick, if I understand correctly. |
| 08:45.56 | *** join/#oe edbart (~ebartosh@192.198.151.45) |
| 08:47.37 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 08:51.20 | *** join/#oe rburton (~Adium@home.burtonini.com) |
| 08:51.40 | *** join/#oe balkamos (balkamos@unaffiliated/motley) |
| 09:01.42 | *** join/#oe joshuagl (~joshuagl@192.198.151.44) |
| 09:04.20 | bluelightning | mario-goulart: yes, the fetcher uses a lockfile to ensure one fetch task is fetching the same file at a time |
| 09:08.34 | *** join/#oe maxin (~maxin@2001:998:22:0:95b0:4d0a:2f3a:ed51) |
| 09:13.42 | *** join/#oe coolmouse (~coolmouse@124.89.111.46) |
| 09:15.29 | *** join/#oe yann|work (~yann@LFbn-1-1026-146.w86-247.abo.wanadoo.fr) |
| 09:16.41 | mario-goulart | bluelightning: Thanks! So a read-write NFS share would do the trick to share DL_DIR among multiple machines, right? |
| 09:17.31 | *** join/#oe coolmouse_ (~coolmouse@124.89.111.46) |
| 09:17.48 | *** join/#oe joseppc (~Josep@192.36.1.252) |
| 09:18.05 | *** join/#oe jonathanmaw (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk) |
| 09:18.38 | bluelightning | mario-goulart: should be OK so long as you don't get experimental with the NFS flags you enable |
| 09:21.02 | mario-goulart | bluelightning: excellent. Thanks a lot. |
| 09:21.39 | *** join/#oe vdehors (~vdehors@193.56.60.161) |
| 09:49.58 | *** join/#oe mago_ (~mago@88.131.56.168) |
| 09:52.49 | *** join/#oe simosx (~simosx@ubuntu/member/simosx) |
| 10:09.27 | *** join/#oe belen (~Adium@134.134.139.74) |
| 10:09.38 | *** join/#oe ecloud (quassel@nat/digia/x-ujpstbloqkviidyr) |
| 10:16.50 | mago_ | is there a tool that will, for each changed SRCREV in my layer recipes, lists a summary of changes for each corresponding package? |
| 10:26.41 | AndersD | b |
| 10:28.47 | *** join/#oe blitz00 (stefans@unaffiliated/blitz00) |
| 11:21.26 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 11:22.33 | *** join/#oe edbart (~ebartosh@192.198.151.45) |
| 11:31.22 | *** join/#oe cesdv (~cesdv@client-188-168-43-165.spb-teleport.ru) |
| 11:36.40 | *** join/#oe berton (~fabio@187.23.154.250) |
| 11:37.39 | *** join/#oe coolmouse (~coolmouse@113.200.25.79) |
| 11:38.59 | *** join/#oe coolmouse (~coolmouse@113.200.25.79) |
| 11:48.14 | *** join/#oe ldnunes (~ldnunes_@187.23.154.250) |
| 12:23.05 | *** join/#oe eengie (~eengie@static-108-40-78-74.bltmmd.fios.verizon.net) |
| 12:29.33 | *** join/#oe caiortp (~inatel@131.221.240.204) |
| 12:30.05 | eengie | kergoth: Do you have a moment to answer a question about binutils cross? |
| 12:30.12 | eengie | (or cross recipes in general)? |
| 12:35.46 | eengie | Or does anyone have experience setting up a recipe that only needs to exist on the build system as a tool for cross-compiling another recipe? |
| 12:38.52 | *** join/#oe coolmouse_ (~coolmouse@113.200.25.79) |
| 12:43.59 | eengie | Never mind... I think I got it sorted. I was getting an odd error about file format not recognized. Inheriting from cross got rid of that error. |
| 13:07.36 | *** join/#oe jonathanmaw (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk) |
| 13:10.11 | eengie | Well, except now it tosses out several warnings about "populate_sysroot not found". Is there a checklist for all the necessities of configuring a cross recipe? Trying to ferret out the hows-and-whys from one of these existing cross recipes is a bit much. |
| 13:17.22 | *** join/#oe vmeson (~rmacleod@24-212-184-107.cable.teksavvy.com) |
| 13:23.21 | *** join/#oe paulg_ (~paulg@128.224.252.2) |
| 13:35.31 | *** join/#oe JaMa (~martin@ip-86-49-34-37.net.upcbroadband.cz) |
| 13:47.02 | *** join/#oe gabrbedd (~beddingfi@li680-65.members.linode.com) |
| 14:07.07 | eengie | Actually...it looks like setting the recipe up to split itself into native and non-native was the better route than inheriting from cross. |
| 14:09.42 | *** join/#oe madisox (~madison@12.30.244.5) |
| 14:09.46 | *** part/#oe madisox (~madison@12.30.244.5) |
| 14:14.58 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 14:16.05 | *** join/#oe coolmouse_ (~coolmouse@113.200.25.79) |
| 14:18.25 | *** join/#oe CipherWizard (~cipherwiz@216-21-169-52.slc.googlefiber.net) |
| 14:20.48 | *** join/#oe belen (Adium@nat/intel/x-sicnecghapcvjwjo) |
| 14:54.02 | *** join/#oe mattsm (uid128834@gateway/web/irccloud.com/x-dshbllnufugvbspf) |
| 15:05.22 | *** join/#oe lag (lag@ubuntu/member/lag) |
| 15:05.46 | lag | How do you get bitbake to spit out the commands it's issuing to a given repo? |
| 15:05.59 | *** join/#oe Aethenelle (~Aethenell@199.15.128.78) |
| 15:06.18 | lag | For instance, it is currently picking up the wrong kernel defconfig in my set-up and I need to debug why this is happening |
| 15:10.04 | eengie | If you go look in the build/tmp-glibc/work/<arch>/<recipe>/<...>/temp directory, you can see the task list and log files for each. |
| 15:10.12 | eengie | You can also use the -e <recipe> to get a dump of all variables related to a recipe for sanity checking (for example, bitbake -e u-boot > u-boot.env) |
| 15:13.00 | *** join/#oe yann|work (~yann@LFbn-1-1026-146.w86-247.abo.wanadoo.fr) |
| 15:13.10 | eengie | lag: does that help? |
| 15:13.21 | lag | eengie: Just trying now |
| 15:14.25 | eengie | lag: there's also a --verbose flag I sometimes throw onto bitbake when running through specific tasks, but occasionally it's just repeating the same line of text N different ways. Sometimes it has also been helpful. |
| 15:15.38 | lag | eengie: I tried that, and --debug -- lots of information there, but doesn't show the commands used to build the package, nor the build output -- just bitbake's own debug/verbose churn |
| 15:27.22 | eengie | lag: I've had an experience where some of my files weren't being picked up because they weren't in directories the packager was expecting to include. For example one installed into /usr/local/<yadda...>/somedir but the packager was only grabbing it if it was a file or directory with files in it directly off /usr/local. The fix (for this autotools recipe) was to encourage the process using SYSROOT_PREPROCESS_FUNCS to tie in an extra |
| 15:30.06 | lag | eengie: Are you sure there is now way you can get OE to dump out the package's own compile log? Rather than obfuscating it and only providing the final few lines in the case of an error? |
| 15:32.02 | eengie | lag: Definitely not sure (I'm fairly new at this myself). ;-) So in your setup have you appended the kernel recipe and have a "files" folder with your own defconfig, but it's not being used for configuring the kernel? |
| 15:33.53 | lag | eengie: Pass |
| 15:34.22 | lag | eengie: This setup should be tried and tested -- but clearly I've done something wrong, and now I need to debug what |
| 15:44.15 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 15:53.44 | *** join/#oe belen (Adium@nat/intel/x-sdwbzzwlgkekyhqt) |
| 15:54.11 | eengie | lag: belive me I feel your pain on that one. I just added a copy from ${S} to ${D} into a recipe's install method and re-ran it only to find that somehow with that change it unpacked into its recipe folder. :-| |
| 16:07.01 | lag | eengie: Piece of ${PROFANITY} |
| 16:07.42 | georgem | blech, it's so annoying when recipes don't pass in explicit configure switches. Even worse when they ignore DISTRO_FEATURES. |
| 16:07.46 | eengie | lag: ERROR: Couldn't expand ${PROFANITY} ;-) |
| 16:08.30 | georgem | should fix gvfs but not sure he'll get around to it |
| 16:08.38 | eengie | have you tried including an scc file (rather than your defconfig) so that the kernel recipe will then use those variables? (i.e., the scc is really just "kconf hardware defconfig") |
| 16:09.11 | lag | eengie: No idea what SCC is? |
| 16:09.49 | lag | eengie: The annoying thing is, `bitbake virtual/kernel -f -c compile` passes |
| 16:10.02 | eengie | lag: It's just a file with extension "scc". I used it the other day to extend my kernel after seeing it in someone else's BSP layer. |
| 16:11.19 | lag | eengie: Do you know how to clean everything, so I'm starting again from scratch? |
| 16:11.55 | eengie | I usually do a -c cleanall |
| 16:12.20 | lag | eengie: I'll try that |
| 16:12.40 | lag | eengie: Only issue is, I won't know if it'll work until tomorrow, as it takes FOREVER |
| 16:15.15 | eengie | (sorry, meant for the recipe itself, so: bitbake -c cleanall virtual/kernel |
| 16:16.01 | kergoth | lag: if you want to wipe everything, all recipes, just wipe tmp and let it rebuild from sstate. shouldn't take long |
| 16:17.35 | lag | What I'm really trying to get the bottom of is why, do_configure and do_compile do the right thing i.e. use my own defconfig, and the do_package seems to want to collect objs from allyesconfig? |
| 16:18.19 | lag | kergoth: The wholes of build/tmp-glibc? |
| 16:18.23 | lag | whole* |
| 16:28.22 | *** join/#oe kbingham (~kbingham@cpc87017-aztw30-2-0-cust65.18-1.cable.virginm.net) |
| 16:30.02 | lag | Right, I've moved the build/ directory and I'm starting a-fresh |
| 16:30.08 | lag | kbingham: What you want Bingham ;) |
| 16:30.26 | kbingham | lag: Just lurking to laugh at you :) |
| 16:30.49 | lag | kbingham: Touche |
| 16:31.02 | kbingham | lag: (or provide insight where available ... but ya know) |
| 16:31.24 | lag | kbingham: How much of an OE guru are you? |
| 16:32.11 | kbingham | lag: I did some Yocto work on previous project |
| 16:32.23 | kbingham | ponders if the Y word is a swear word in this channel! |
| 16:32.40 | lag | kbingham: Same evil ;) |
| 17:02.04 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 17:14.53 | *** join/#oe CipherWizard (~cipherwiz@216-21-169-52.slc.googlefiber.net) |
| 17:21.02 | *** join/#oe jonathanmaw_ (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk) |
| 17:22.29 | *** join/#oe roxell_ (~roxell@c-c82171d5.07-21-73746f28.cust.bredbandsbolaget.se) |
| 17:23.33 | *** join/#oe jku (~jku@212-149-212-50.bb.dnainternet.fi) |
| 17:31.42 | *** join/#oe moto-timo (~ttorling@134.134.139.72) |
| 17:31.43 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 17:34.30 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 17:37.44 | *** join/#oe anarsoul|2 (~kvirc@205.250.92.228) |
| 17:38.40 | *** join/#oe Crofton (~balister@207-114-172-147.static.twtelecom.net) |
| 17:43.34 | *** join/#oe Crofton|road (~balister@c-73-189-176-81.hsd1.ca.comcast.net) |
| 17:50.08 | *** join/#oe belen (Adium@nat/intel/x-rydeedqhqhhqtnmi) |
| 18:00.37 | *** join/#oe moto-timo (~ttorling@134.134.139.72) |
| 18:00.37 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 18:03.44 | *** join/#oe joeythesaint (~joe@vegas.deserted.net) |
| 18:05.54 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 18:10.24 | *** join/#oe kristoffer (~kristoffe@ua-83-227-162-207.cust.bredbandsbolaget.se) |
| 18:35.40 | *** join/#oe yann|work (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 18:36.17 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 19:01.36 | Crofton | FYI: https://www.regonline.com/Register/Checkin.aspx?EventID=1809027https://www.regonline.com/Register/Checkin.aspx?EventID=1809027 |
| 19:02.01 | Crofton | byYP dev day, they mean intro class, with some more advanced stuff :) |
| 19:09.20 | *** join/#oe roxell (~roxell@linaro/roxell) |
| 19:13.08 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 19:17.47 | Crofton | /home/balister/sdks/release-4/sysroots/armv7ahf-vfp-neon-oe-linux-gnueabi/usr/include/boost/atomic/detail/ops_gcc_atomic.hpp:95:93: error: invalid memory model for '__atomic_load' |
| 19:17.48 | Crofton | <PROTECTED> |
| 19:18.03 | Crofton | I see this error compiling some source using an sdk built from fido |
| 19:18.11 | Crofton | the issue is in boost::atomic |
| 19:18.26 | Crofton | master can compile the file |
| 19:20.07 | Crofton | hmm, google suggests fix is in gcc |
| 19:40.21 | *** join/#oe alled (~icchw-017@131.221.240.204) |
| 19:50.30 | *** join/#oe moto-timo (ttorling@fsf/member/moto-timo) |
| 19:52.49 | *** join/#oe moto-timo (ttorling@fsf/member/moto-timo) |
| 19:55.38 | *** join/#oe Jefro1 (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 19:58.34 | *** join/#oe apelete (~apelete@rec31-1-78-194-210-47.fbxo.proxad.net) |
| 19:59.40 | *** join/#oe muep (~quassel@muep.iki.fi) |
| 20:00.18 | *** join/#oe muep_ (twingo@otitsun.oulu.fi) |
| 20:03.38 | *** join/#oe dos1 (~dos1@2a02:25aa:1:2002::1) |
| 20:03.44 | *** join/#oe dos1 (~dos1@unaffiliated/dos1) |
| 20:05.34 | *** join/#oe moto-timo (~ttorling@134.134.139.72) |
| 20:05.34 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 20:11.26 | *** join/#oe aloril_ (~aloril@dsl-tkubrasgw1-54fa3f-129.dhcp.inet.fi) |
| 20:27.48 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 20:29.46 | *** join/#oe joshuagl (~joshuagl@192.198.151.45) |
| 20:30.01 | *** join/#oe joshuagl (~joshuagl@192.198.151.45) |
| 20:31.29 | *** join/#oe yann|work (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 20:41.42 | *** join/#oe bottazzini (~realBigfo@192.55.55.41) |
| 20:48.26 | *** join/#oe ant_home (~ant__@95.236.250.16) |
| 20:52.41 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 21:02.23 | *** join/#oe evanmeagher (~MongooseW@204.14.158.162) |
| 21:22.07 | *** join/#oe phdeswer_ (~phdeswer@91-159-55-220.elisa-laajakaista.fi) |
| 21:24.32 | *** join/#oe rburton1 (~Adium@home.burtonini.com) |
| 21:37.12 | Jin^eLD | hmm, does the OE git fetcher cope with submodules? |
| 21:48.28 | kergoth | Jin^eLD: if you use gitsm:// instead of git://, yes. i think we did it this way for compatibility, but really it should be default IMO |
| 21:51.41 | Jin^eLD | "should be default" - what did you mean by that? |
| 21:52.11 | Jin^eLD | basically its a git repo that uses submodules; so I am supposed to use gitsm://mainrepo.git/ ? |
| 21:52.35 | kergoth | yes |
| 21:52.48 | Jin^eLD | ok, thanks |
| 21:53.04 | kergoth | i'm saying that instead of having to opt-in to submodule fetching by changing to gitsm, we should change the default at some future date to just always fetch submodules unless opted out with a url parameter |
| 21:53.28 | Jin^eLD | oh, that's what you meant |
| 21:53.30 | Jin^eLD | yes |
| 21:53.32 | Jin^eLD | that would be nice |
| 21:54.47 | Jin^eLD | are any other parameters needed? |
| 21:54.48 | Jin^eLD | cp: cannot stat `/mnt/openembedded/drumgizmo/downloads/git2/git.drumgizmo.org.drumgizmo.git/modules' |
| 21:54.56 | Jin^eLD | that's the error which I get when changing to gitsm:// |
| 21:56.40 | *** join/#oe rburton (~Adium@home.burtonini.com) |
| 21:58.01 | Jin^eLD | ah, I should clean the recipe |
| 22:04.38 | Crofton | meta-oe has Could not inherit file classes/gobject-introspection.bbclass |
| 22:04.40 | Crofton | issues |
| 22:06.18 | Crofton | gah layer sync issue |
| 22:17.11 | kergoth | Jin^eLD: yeah might need to cleanall the recipe first, haven't tried that. might want to open a bug for that particular use case. our fetcher tests are nowhere near comprehensive |
| 22:17.33 | kergoth | Jin^eLD: the annoying part with the tests is there's so much state that lies in DL_DIR, so you need to reproduce that state to cover all the use cases.. |
| 22:21.56 | Jin^eLD | I see... well cleaning did help, thats what the manual suggested, but do not know yet if it works, have to tune the configure script of the package first |
| 22:22.00 | Jin^eLD | trying to package drumgizmo |
| 22:39.45 | Jin^eLD | suhr: how's it going with disabling sse? :> |
| 22:39.48 | Jin^eLD | oops wrong window |
| 22:45.06 | bluelightning | Jin^eLD: you really need to label your windows ;) |
| 22:46.36 | *** join/#oe rburton (~Adium@home.burtonini.com) |
| 22:49.10 | Jin^eLD | bluelightning: I have none :) I run IRC in split mode in a terminal, I use the ancient BitchX client :) |
| 22:50.51 | kergoth | wow, old school. i haven't run that in years, since switching to irssi long ago |
| 22:51.05 | Jin^eLD | so basically I have to press some key combo to switch active channel :) |
| 22:53.31 | Jin^eLD | kergoth: yeah, I got used to it and could never switch |
| 23:44.24 | Jin^eLD | nite |