IRC log for #oe on 20130730

00:08.41*** join/#oe infobot (~infobot@rikers.org)
00:08.41*** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel
00:21.13*** join/#oe Vutral (ss@mirbsd/special/Vutral)
00:31.32davornerdboy, I built yocto instead, thought that might work, but nope, when trying to boot rpi-basic-image, ACT lights up for a few seconds and that's it, no display output or anything. it's probably not booting given that the ethernet-related LEDs remain off even when powering up the RPi with a network cable attached
00:42.59*** join/#oe Rootert (~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl)
00:43.29*** join/#oe RagBal (~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl)
01:07.16*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
01:21.52*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
01:28.55*** join/#oe liuyq (~liuyq0307@static-ip-225-98-134-202.rev.dyxnet.com)
01:29.42*** join/#oe liuyq (~liuyq0307@static-ip-225-98-134-202.rev.dyxnet.com)
01:40.17*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
01:46.13*** join/#oe johny_ (79321429@gateway/web/freenode/ip.121.50.20.41)
01:46.17johny_hi
01:50.09johny_i have build aminimal image and ogt rootfs, when i execute ldd <some .so file> it is showing that it is linking to some of system libraries... is it correct? for example
01:50.41johny_ldd libsqlite3.so giving me this result
01:50.42johny_<PROTECTED>
01:51.03johny_why it is using my system libs? it should not happen as of my understanding..
01:51.11johny_any body has any idea on this.?
01:55.56*** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net)
02:07.19*** join/#oe silviof1 (~silviof@ppp-93-104-14-226.dynamic.mnet-online.de)
02:08.10*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
02:36.48*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
02:38.39johny_i have build aminimal image and ogt rootfs, when i execute ldd <some .so file> it is showing that it is linking to some of system libraries... is it correct? for example
02:38.45johny_ldd libsqlite3.so giving me this result
02:38.51johny_linux-gate.so.1 =>  (0xf76f1000)         libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf76ca000)         libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf76af000)         libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7505000)         /lib/ld-linux.so.2 (0xf76f2000)
02:38.56johny_any body has any idea on this.?
02:39.03*** join/#oe andre_d (~andre_d@82.220.1.204)
02:49.02*** join/#oe liuyq (~liuyq0307@static-ip-225-98-134-202.rev.dyxnet.com)
02:53.08*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
03:05.24*** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginmedia.com)
03:10.55*** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net)
03:49.19*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
04:22.04*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
04:35.43*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
05:06.14*** join/#oe ericben (~ebenard@pac33-3-88-170-243-169.fbx.proxad.net)
05:17.34*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
05:21.51*** join/#oe zecke (~ich@91-65-247-193-dynip.superkabel.de)
05:21.54*** join/#oe rsalveti (~rsalveti@unaffiliated/rsalveti)
05:23.24*** join/#oe clio (~andrej@85.159.109.222)
05:27.44*** join/#oe cbrake (~cbrake@oh-67-76-203-50.sta.embarqhsd.net)
05:38.41*** join/#oe liuyq (~liuyq0307@static-ip-225-98-134-202.rev.dyxnet.com)
05:48.23*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
05:51.39*** join/#oe tasslehoff (~tasslehof@77.40.182.98)
05:53.29*** join/#oe mario_ (~mario@HSI-KBW-046-005-171-212.hsi8.kabel-badenwuerttemberg.de)
06:02.03*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
06:16.47*** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:c96c:42a9:7f81:8407)
06:21.09*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
06:27.18*** join/#oe mario_ (~mario@HSI-KBW-046-005-171-212.hsi8.kabel-badenwuerttemberg.de)
06:35.50*** join/#oe blindvt (~brf@91-119-58-15.dynamic.xdsl-line.inode.at)
06:57.31*** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net)
06:59.43*** join/#oe dos11 (~dos@unaffiliated/dos1)
07:01.03*** join/#oe mario_ (~mario@projekte.imos.net)
07:08.45*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
07:18.27*** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginmedia.com)
07:26.21*** join/#oe darknighd (~darknight@nat-wv.mentorg.com)
07:26.31*** join/#oe darknighte (~darknight@pdpc/supporter/professional/darknighte)
07:31.28*** join/#oe stefan_schmidt_w (~stefan_sc@82.43.26.66)
07:34.33*** join/#oe fgretief (~chatzilla@41.0.38.138)
07:38.11*** join/#oe silvio_ (~silvio@93-57-17-124.ip162.fastwebnet.it)
07:39.27*** join/#oe xmlich02 (~imlich@2001:67c:1220:80c:21c:c0ff:fe18:9398)
07:40.37*** join/#oe BlindMan (~othmar@chello212017108125.6.11.vie.surfer.at)
07:45.14*** join/#oe ant_work (~ant@host54-128-static.10-188-b.business.telecomitalia.it)
07:47.28*** join/#oe panda84kde (~diego@static-217-133-170-65.clienti.tiscali.it)
07:54.13*** join/#oe bluelightning (~paul@83.217.123.106)
07:54.13*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
07:55.27*** join/#oe ao2 (~ao2@host5-148-dynamic.3-87-r.retail.telecomitalia.it)
07:58.14bluelightningmorning all
08:01.07silviofhi morning bluelightning
08:01.11silviofmorning #oe
08:02.42bluelightningmorning silviof
08:10.54silviofI work on firefox-22 and have a license file with more than 10 licenses. How should I handle these?
08:12.55bluelightningsilviof: if those are all of the licenses that apply they'll all need to be listed in LICENSE separated by &
08:13.48silviofbluelightning: okay
08:13.57*** join/#oe ao2 (~ao2@87.13.159.77)
08:15.49*** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian)
08:20.59silvio_morning all, hi bluelightning, hi silviof
08:21.39bluelightninghi silvio_
08:23.00silviofhi silvio_
08:46.57*** join/#oe phdeswer_ (~phdeswer@a88-113-104-180.elisa-laajakaista.fi)
08:58.34*** join/#oe blitz00 (~stefans@unaffiliated/blitz00)
08:59.04*** join/#oe cbrake (~cbrake@oh-67-76-203-50.sta.embarqhsd.net)
09:01.20*** join/#oe eren (~eren@unaffiliated/eren)
09:01.28*** join/#oe ao2 (~ao2@host189-149-dynamic.6-87-r.retail.telecomitalia.it)
09:13.57*** join/#oe BlindMan (~othmar@chello212017108125.6.11.vie.surfer.at)
09:27.01erenhi all
09:27.39silviofhi eren
09:33.54bluelightninghi eren
09:35.13*** join/#oe ao2 (~ao2@host64-79-dynamic.57-82-r.retail.telecomitalia.it)
09:40.15pb_morning all
09:40.17*** join/#oe max (~max@host167-68-dynamic.54-79-r.retail.telecomitalia.it)
09:40.52*** join/#oe pepermint (~pepermint@host167-68-dynamic.54-79-r.retail.telecomitalia.it)
09:41.05erenmorning pb_
09:42.14bluelightninghi pb_
09:44.16pb_hi eren, bluelightning
09:44.58mckoangood (late) morning
09:49.43*** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:1c28:a977:6da8:42a5)
10:07.02*** join/#oe ao2 (~ao2@host60-146-dynamic.6-87-r.retail.telecomitalia.it)
10:09.49ant_workpb_: I can imagine our rburton and bluelightning dazzled by the huge patchset
10:11.12pb_ant_work: re the bluez thing, you mean?
10:12.58ant_worknot specifically, this time seems harder than usual
10:13.33erenI'm lost on read-only-rootfs suppot
10:13.38erenwill there be any documentation about it?
10:13.50pb_it does seem as though Saul is having a bit of a hard time putting the right bits in his branch for some reason.
10:14.01erenI mean, in the technical side, how it is implemented, how it can be used, etc
10:14.11pb_but, well, rburton and bluelightning are professionals, I'm sure they can cope.
10:14.26erenand we can help them :P
10:14.44pb_eren: "how it can be used" is easy, it is for root filesystems that you can't write to (squashfs etc)
10:15.02pb_it should just be a case of setting the appropriate IMAGE_FEATURE when you generate your rootfs.
10:15.06erensure, I am wondering about the implementation actually
10:15.16erenit's hard to deduce from the commits
10:16.38pb_well, there are various parts to it, but the basic idea is that any parts of the filesystem that need to be written to have a tmpfs bind-mounted on top of them.
10:16.58pb_I'm not quite sure whether there is any plan to unify this with the unionfs stuff that's used for live images, or whether they will always remain separate.
10:17.18pb_you can imagine that live images are, in some sense, just a special case of RoRs and possibly ought to be using the same mechanics.
10:17.51ant_workeren: I have tested one RO cramfs couple of months ago
10:18.15ant_worksee, the NOR is locked and it was indeed RO ;)
10:18.30ant_workeren: it was just a core-image-base
10:18.39erenpb_: well, tmpfs bind-mounted on top of them?
10:18.54*** join/#oe mrmcan (~mrcan@unaffiliated/mrcan)
10:19.12ant_workeren: wrt volatiles/tmpfs seems things have changed/are changing
10:40.10*** join/#oe ao2 (~ao2@host143-140-dynamic.3-87-r.retail.telecomitalia.it)
10:40.28ensc|wro nfs rootfs are really nasty to handle in userspace because the 'ro' flag is not exported by statvfs(). So systemd's ConditionPathIsReadWrite does not work and (unpatched) busybox 'test -w' fails too :(
10:52.53*** join/#oe CMoH (~cipi@unaffiliated/c-moh)
11:06.27*** join/#oe JaMa|Off (~martin@ip-62-24-80-145.net.upcbroadband.cz)
11:07.58*** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:c8f0:5499:84a5:c9fc)
11:14.18*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
11:40.06*** join/#oe ldnunes (~ldnunes_@187.23.155.55)
11:40.47*** join/#oe DJW|Home (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginmedia.com)
11:55.33*** join/#oe joeythesaint (~jjm@128.224.252.2)
12:10.51*** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:b06f:462e:9398:2639)
12:30.53*** join/#oe ao2 (~ao2@2001:1418:117::1)
12:52.15*** join/#oe silviof1 (~silviof@ppp-188-174-179-148.dynamic.mnet-online.de)
12:57.03*** join/#oe silviof2 (~silviof@ppp-188-174-147-50.dynamic.mnet-online.de)
13:01.41*** join/#oe silviof3 (~silviof@ppp-93-104-168-44.dynamic.mnet-online.de)
13:03.23*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
13:06.58*** join/#oe apelete_ (apelete@nat/intel/x-dkighsalselklrbq)
13:08.20*** join/#oe silviof4 (~silviof@ppp-93-104-162-97.dynamic.mnet-online.de)
13:10.08*** join/#oe silviof (~silviof@ppp-93-104-184-172.dynamic.mnet-online.de)
13:18.02*** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes)
13:29.03*** join/#oe silviof (~silviof@ppp-188-174-129-34.dynamic.mnet-online.de)
13:42.36*** join/#oe Stygia (~gmpsaifi@0904ds6-noe.0.fullrate.dk)
13:50.56*** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:a093:97d4:8c10:8555)
14:03.11*** join/#oe ao2 (~ao2@2001:1418:117::1)
14:14.50*** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian)
14:19.45*** join/#oe SoylentYellow (~SoylentYe@129.10.181.81)
14:39.34*** join/#oe Crofton-bot (~supybot@pool-108-44-87-78.ronkva.east.verizon.net)
14:39.42*** join/#oe Crofton|work (~balister@pool-108-44-87-78.ronkva.east.verizon.net)
14:52.51*** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net)
14:59.40martiertany ideas on why my kernel has its load address set differently when built through OE and manually using the OE built toolchain?
14:59.40*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
15:00.23martiertwhen building out of oe I get Load Address: 0x80008000, while in oe I get 0x00008000, which is strange
15:00.26*** join/#oe hollisb (~hollisb@192.94.38.34)
15:01.38martiertsame defconfig, same commit and no u-boot-mkimage relocation stuff
15:01.47*** join/#oe dvhart (~dvhart@static-50-53-108-147.bvtn.or.frontiernet.net)
15:03.03mckoanbluelightning: is it time for TSC / Workgroup meeting?
15:05.12bluelightningmckoan: it's in 1 hour
15:05.19bluelightningmckoan: (well, 55 minutes)
15:05.20Crofton|work+1
15:05.27mckoanso 18:00 CEST
15:05.27Crofton|workbluelightning, the bot should be good to go
15:05.43*** join/#oe tomz2 (~trz@c-68-53-177-94.hsd1.in.comcast.net)
15:05.55bluelightningCrofton|work: great, I guess you'll be around to operate it? (since I don't know how...)
15:06.06Crofton|workok
15:06.08Crofton|workI should be
15:06.08mckoanbluelightning: but in London now it's 16 (GMT)
15:06.11bluelightnings/guess/hope/ :)
15:06.28Crofton|workI got home late last night
15:06.30bluelightningmckoan: London is in BST now not GMT :)
15:06.51mckoanbluelightning: aha! now I understand, sorry
15:07.57mckoanhttp://www.worldtimebuddy.com/utc-to-bst-converter
15:08.00*** join/#oe rburton (~rburton@35.106.2.81.in-addr.arpa)
15:11.03*** join/#oe liveforeverx (~Adium@89.204.130.253)
15:14.17*** join/#oe zenlinux (~sgarman@c-24-20-145-95.hsd1.or.comcast.net)
15:36.06pb_martiert: I guess you should diff the linker scripts and the final link command line to see what's going on.
15:42.45martiertpb_: Which linker scripts are you thinking of? the ones in the kernel, or someone in oe?
15:43.31pb_The ones in the kernel
15:44.49martiertyes, I can do that. Do you know if there are anyting in oe which is changing the way it's linked though? cause I though we were doing unset CFLAGS CXXFLAGS LDFLAGS when building the kernel
15:47.03pb_I can't think of anything.  But if it behaves differently, and you're using the same tools, then it stands to reason that there must be something.
15:47.25martierttrue, but I'll try that, and see if the link line is weird
15:47.47martiertthansk
15:49.11martiertjust thought it was so weird, so maybe someone had seen something similar. being that the only difference is the first 8, which is a lot of bytes, but still only one number:P
15:55.40bluelightninghey all, just a reminder: in about 5 minutes we'll be starting the public TSC meeting in this channel
15:56.55bluelightninghttp://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg32103.html
15:59.19*** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net)
16:00.47bluelightningmorning Jefro
16:00.54fraymorning
16:01.17Jefrobluelightning good morning
16:01.38Jefroseems quiet here.  too quiet...
16:01.51sgw_Morning
16:02.07mckoanmorning all
16:02.58Crofton|workbluelightning, let me know when you want to start
16:03.02bluelightningJefro: probably a little bit late for me to be asking but do you have an agenda for this meeting?
16:03.16bluelightningCrofton|work: we should be starting now
16:03.30Crofton|workshall I start the bot then?
16:03.49bluelightningCrofton|work: yes please
16:03.51Crofton|work#startmeeting
16:03.52Crofton-botMeeting started Tue Jul 30 16:03:52 2013 UTC.  The chair is Crofton|work. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:03.52Crofton-botUseful Commands: #action #agreed #help #info #idea #link #topic.
16:04.01Crofton|workthe url has some docs
16:04.19Crofton|workyou can use the topic command for agenda items
16:04.41Jefrobluelightning yes, in just a sec - poll for new issues and I'll put them on the agenda before posting
16:04.54frayWelcome.. Jefro is our normal TSC note taker.. he is just finishing up the base agenda items now..
16:04.56Crofton|workgive me an action item to work with ka6sox to find a way to upload minutes to the oe website
16:05.01fraybut while he does so, new issues are welcome..
16:05.46frayour normal first task is to identify the meeting chair..  So we should probably do that quickly..
16:06.16fraykoen msg'd me a couple of minutes ago that he'd be right back..
16:06.46frayI believe Khem, Bluelightning and myself are here.
16:06.51*** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey)
16:06.55frayRP is on vacation
16:08.03fraywhile the others get setup.  Let me explain what we're trying to do today.
16:08.08frayhttp://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg32103.html
16:08.38frayAs mentioned in the email from Paul (on behalf of the entire Technical Steering Committee) we want to work on evoling the role of the OE-TSC.
16:09.12frayWe thought that starting to have at open meetings with the users (not just oe members) would be a good start.
16:10.25mckoanfray: I agree, but depends on how much users care about meetings ;-)
16:10.29bluelightningthe idea is to get other folks in the community more involved in the "taskforce" type operations that the TSC have been taking on
16:11.01frayand that is one of the purposes of this meeting as well.  Many people aren't going to care.  So if after we're done it wasn't useful.  We likely won't do it again.. (or at least not in this format)
16:11.29Crofton|workI feel this is a good habit to get into, and expect people to become more involved over time
16:11.55darknighteis monitoring the meeting
16:12.03frayThe TSC needs to change it's role from being a group of people leading specific implementation/work products into an actual technical steering committee who can help the community at large...
16:12.19*** join/#oe mr_science (~sarnold@net-cf9a4e91.cst.impulse.net)
16:12.19*** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy)
16:13.18bluelightningfray: so we're 13 mins in, I'd say you're probably chairing ;)
16:13.28fraysounds good to me.  :)
16:13.42*** join/#oe denix0 (~denys@192.94.92.11)
16:13.46frayWe normally just allow someone to take the lead as the chair of the meeting.. so I guess it's my turn
16:14.07denix0re
16:14.07fraywhile Jefro finishes up on the formal agenda.  The first item in the list was to introduce some of the 'janitor' items.
16:14.38frayFor a while the TSC has been seeing a list of items grow (and luckily shrink) that cover various cleanup and janitorial tasks.
16:14.58frayWe're like to introduce a more formal way for people to find outstanding cleanup tasks and be able to work on them.
16:15.02Crofton|workfray, say #topic Janitor Items
16:15.05JefroTSC agenda is here: http://pastebin.com/KMhtNHpC
16:15.23fray#topic Janitor items
16:15.49frayOn the pasted agenda, there are two links referenced:
16:15.54frayhttp://openembedded.org/index.php/OpenEmbeddedJanitors
16:16.10bluelightningthat page is kind of ancient ;)
16:16.19fraya wiki page started to help people idenfiy and discuss Janitorial work..  so far it's not been used much, but it also isn't well know..
16:16.24frayand yes.. ancient in many ways..
16:16.52frayand for those that pay attention to the Yocto Project bugzilla, various bugs get tagged with an owner, cc that contains 'janitor' to help identify future work.
16:16.57frayhttp://bit.ly/11sfn5Y
16:17.16bluelightningright, the Yocto Project has also been tracking janitor items: https://wiki.yoctoproject.org/wiki/Janitors
16:17.24fraybluelightning thanks, I missed that URL
16:17.56bluelightningI'll be honest though, that list has remained largely static for quite some time, so it's not really achieving much
16:18.22erenas a newly joined contributer, I want to make a comment on Janitor jobs
16:18.27erenis it possible?
16:18.28bluelightningi.e. usually "janitor" type items are a way of bringing new contributors up-to-speed on a project, but that hasn't really been happening
16:18.35bluelightningeren: certainly :)
16:18.37frayeren, please..
16:18.52erenI didn't know about the url on OpenEmbedded wiki, which are more likely to be janitor jobs
16:19.09erenthe jobs in Yocto page are a bit complex for newly joined people
16:19.29bluelightningthe first item on the OE page is no longer valid, I'm about to remove it
16:19.32erenI would suggest chosing some mechanical jobs at first and collect them on wiki
16:19.49frayeren, I was assigned the task to start working on publicising janitorial tasks, but alas, the implementation side of my work has gotten in the way..
16:19.50erenand add a link to how to contribute/send patches to ML :)
16:20.22fraySo this is really the first opportunity for most people to see what we thing is a good way to get people involved and help those looking for something to do, with a possible list.
16:20.45*** join/#oe hillct (~hillct@c-24-34-200-20.hsd1.ma.comcast.net)
16:20.46fraywe also want ot make sure that if people find inconsistencies, things that need cleanup -- there is a way for them to post about them and add it to the list of future work
16:21.07frayeren, I agree..
16:21.14*** join/#oe soltys (soltys@84-10-244-33.dynamic.chello.pl)
16:21.15erenthere was a page on how to send patches that bluelightning posted when I asked
16:21.17fraywe'll add that to the todo
16:21.20erenbut I cannot find it on wiki
16:21.23bluelightningeren: right, we should definitely do that, good idea... FYI this page is up-to-date: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
16:21.33erenI guess adding keywords would help
16:21.43erenbluelightning: ah! that's on OE then, I was looking at Yocto wiki
16:22.12bluelightningwe should probably have back-links from the Yocto Project wiki to that page
16:22.38erenyeah, I guess so
16:22.42bluelightningand yes, mediawiki often requires explicit keywords because its searching is somewhat simplistic
16:22.45mckoanI didn't know janitor wiki page too
16:22.45fraythis leads me to one of the janitor tasks that is sorely needed.  We need help keeping the wiki up to date, along with making it easier for new users to find what they need..
16:23.01bluelightningindeed
16:23.05denix0+1
16:23.17fraythere is still a lot of oe-classic information that we need to ensure people understand is older..
16:23.41bluelightningFWIW most of the outdated info is at least marked as such with a bold notice at the top of the page
16:23.42mckoankeep doc stuff up to date is definitely the first thing to do
16:23.48bluelightningbut that's only step one of course :)
16:23.48frayyup
16:24.18Jefro#action Crofton_work talk with ka6sox about uplaoding to the website
16:24.28erenyou can add old oe variables that we need to be careful about in Styleguide?
16:24.31erenor packaging guide?
16:25.19fray#action update janitor page with up-to-date information, make sure it's referenced on the main page
16:25.50denix0Jefro: what exactly do you mean? do you mean loosening restrictions on wiki?
16:26.08bluelightningeren: hmm... we do maintain this, not sure if it helps in that regard: http://www.openembedded.org/wiki/Migrating_metadata_to_OE-Core
16:26.26bluelightningeren: we also have a migration section in the YP reference manual for releases
16:26.46bluelightningeren: that at least covers changes people need to make to their recipes/configuration
16:27.20fraylooks at the clock.. is there more discussion on this or should we move on
16:27.28erenbluelightning: ah yep, that would definitely help
16:27.28Crofton|workdenix, getting things setup so I can rsync the minutes directly yo a server
16:27.50denix0Crofton|work: got it
16:28.13bluelightningfray: I think we should probably move on, but we should carry on thinking/working on the janitor list
16:28.23*** join/#oe davest (Adium@nat/intel/x-dfynalpalbvmlore)
16:28.35frayyes please.. anyone has any suggestions contact the TSC and/or post on the oe list(s)..
16:28.58frayI would think that all of the oe items, wiki, oe-core, meta-oe could likely use something like this.. or even a common page divided by area..
16:29.03frayok.. on to the next thing..
16:29.18fray3a.. role of the TSC.. we already covered this a bit, and some may have seen the discussion on the oe-members list.
16:29.32Crofton|workfray, use #topic :)
16:30.03fray#topic 3a.. role of the TSC
16:30.33frayWe want to work on transitioning from a group trying to figure out what is needed and working on getting us there.. to thinking about strategic direction and long term vision.
16:30.42Jefrowonders how he didn't know about meetbot before
16:31.01frayWe're looking from feedback from both oe users and members on our role.
16:31.40denix0Jefro: you were the bot! :)
16:31.47*** join/#oe dos11 (~dos@unaffiliated/dos1)
16:31.55frayjust to be clear our own plans for the TSC do not include meeting just for the sake of it.  We do want to actually accomplish something.
16:32.08Crofton|work+1
16:32.09frayfeedback?
16:32.10denix0Jefro: we didn't have you at the board meetings, so we needed to find something... :)
16:32.53Crofton|workotavio, made me figure it out :)
16:32.59mckoanfray: of course, but people not used to meet with TSC may need time to adapt to it
16:34.45bluelightningmckoan: right, this may take some time for us all to get used to :)
16:34.52fray;)
16:35.02*** join/#oe zenlinux (~sgarman@c-50-139-96-211.hsd1.or.comcast.net)
16:35.40frayI think many, if not all of the TSC members in the last couple of years had a vested interest in bootstrapping oe-core..  We are well beyond that point now.. so in my opinion, it's time for the group to evolve..
16:36.32fraysince I don't see much feedback, I'll ask this in another way.. does anyone -disagree- with the TSC changing it's role more toward a medium vision/long term vision, and technical dispute resolution group..
16:36.42fray(we also help with some infrastructure decisions and issues as well..)
16:36.49*** join/#oe challinan (~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net)
16:37.18rburtontoken statement to show some form of participation: no, i don't disagree with that. :)
16:37.20kergothI'm 100% in favor of strategic direction and long term vision being a focus
16:37.39Jefrofray I had a question. The TSC also manages many technical projects. What happens to those?
16:37.54frayThat was my next question..  :)
16:38.45Crofton|workwhat are these technical projects?
16:39.39frayin the past we've done some of the janitorial tasks, helped with the merge of code from meta-oe to oe-core...
16:40.19fraywe had mentioned in past meetings that this type of work transition to more of a working group format.  Which we may or may not be directly involved with... but which we -will- need community involvement
16:40.47kergothfrom a user perspective (not being in the tsc in some time), one thing that's bugged me about how the tsc has been working is the fact that agenda items seem to stick around indefinitely without seeing any form of completion. maybe its mostly those projects, but it gives one an impression ofa  lack of progress, reading the notes, imo
16:41.23frayin many cases, that is exactly it.. the items were on-going "projects"
16:42.14Jefrokergoth that may be partly my bug presentation-wise
16:42.42Jefrodiscussion points != projects. I can present it more as a project manager would if that helps.
16:42.56bluelightningkergoth: this is one of the reasons for us asking for wider involvement in those projects, since some of them have been difficult for us to make progress on on our own; usually it's not for lack of decisions, but lack of time to work through changes
16:44.19mckoandiscussion points are often too synthetic
16:45.02mckoanwho read them from outside of TSC oftern don't realize their actual purpose
16:45.27mckoanmaybe a little lack of description/documentation
16:45.44bluelightningfor instance, we've been struggling with trying to get the last few bbappends/overlayed recipes from meta-oe for some time now, and it's been *really* hard to get people to help with that
16:45.47frayyes.. and I think vision fits into a better way of doing what we have been (from the outside) while a working group would be better for actual 'work' and involvement
16:46.43bluelightningI'll admit that that particular thing is something I personally feel strongly about, perhaps it bothers others less
16:49.13fray(sorry my network is glitching here...)
16:49.30frayIs there an output of this discussion, at this point?
16:50.26mckoanthe main problem with adopt these big changes is that there usually aren't guidelines, apart for those wrote by bluelightning (afaik)
16:50.26*** join/#oe fray_ (~mhatle@206.144.70.9)
16:50.41fraywe need to better convey the points as to their meaning, tsc role change is generally accepted, working groups (right approach, wrong or TBD?)
16:50.50bluelightningfray: we haven't stated as such, but if there are items that the TSC would normally take on, we need to get them identified and find a way of pulling in interested folks to get them resolved
16:51.01frayagreed
16:51.08bluelightningfray: TBD probably
16:51.13frayok..
16:51.17kergothworking groups seem like a decent approach to pursue the actual implementation of the decisions
16:51.18Crofton|worklist conclusions as #info or #action
16:51.19fraywe've got about 9 minutes left..
16:51.20kergothshrugs
16:51.38frayI'd like to continue and we can come back to this if there is time..
16:51.44fray#topic 3b - eglibc
16:51.54frayThis is more of an FYI topic to folks.. it's working that we need to continue to track.
16:52.15fray_If you are not already aware, the eglibc work is being merged into the glibc proper.
16:52.16fray_http://www.eglibc.org/archives/patches/msg01299.html
16:52.26*** join/#oe dvhart (dvhart@nat/intel/x-wkyqcdmqvlkmbekr)
16:52.30mckoanthis topic is freightening me, someone could give more information?
16:52.42fray_This may affect us via the configuration of eglibc, mklibs phase out, etc..
16:52.45mckoanwhy is this migration required?
16:53.01fray_IF these items are needed by people, they will need to get involved with the upstream eglibc project.. express what they need and likely help maintain the work
16:53.10khemwell nothing to worry about mckoan
16:53.12fray_The migration is happening by the current maintainers of the eglibc project.
16:53.25pb_mckoan: mostly because the original need for eglibc has basically evaporated, and maintaining two competing forks of the same code is a waste of time.
16:53.26fray_All of the code that can be, is going to be merged into glibc itself..
16:53.28khemwe use certain features in OE which are less used
16:53.30fray_pb_ exactly
16:53.36erenpb_: Ulrich?
16:53.41khemand therefore we either pick up maintaining them or they go away
16:53.51fray_Ulrich is no longer the maintainer of glibc AFAIK
16:53.52bluelightningkhem: I'm not completely clear, will this mean the items in DISTRO_FEATURES_LIBC cease to exist, or are reduced, or no change there?
16:54.02erenI guess that was *one of* the reasons behind eglibc fork
16:54.10mckoanfray: link catched thx, I'll read it later
16:54.14khembluelightning: I will upstream the patches into glibc
16:54.22khemand maintain them ther e
16:54.34fray_bluelightning at present, the items in the distro_features_libc, which correspond to their 'option group' support will be affected without someone coming in to maintain the work
16:54.37denix0eren: Ulrich is gone long time ago
16:54.53khemhowever it would be better to have some sense of userbase
16:54.55bluelightningkhem: excellent, thank you... so the impact on us should be relatively minor then?
16:54.57fray_Option groups, in eglibc, are the way to disable functionality in order to save space.  (Very much like how uclibc is configurable)
16:55.08khemif there are few use cases then it may not be worth the time
16:55.29khembluelightning: yes impact to us is minor given we have prevelant usecases
16:55.39khemhowever this is an item for 2.19 release
16:55.45fray_it's unclear at present how many people actual use the option groups, (our LIBC configuration).  Based on previous responses to queries the numbers are small enough that the eglibc maintainers will be deprecating support over the next release or so.. (think 6-12 months)
16:56.19darknighteeren: fray_ : AFAIK, Ulrich's departure is part of what has opened the door to the merging of eglibc/glibc.
16:56.24fray_we're trying to make sure this doesn't come as a surprise to anyone.. and if the functionality is absolutely needed, we (the OE project) will need to either take over maintenance and/or take the patches outselves..
16:56.26fray_darknighte correct
16:56.28khemfray_: yes if userbase is smaller then merging this into glibc might not be as appealing
16:57.04khemI think most impacted distro in OE universe would be poky tiny
16:57.14fray_concerns/comments.. we should move to the oe-core list on this....
16:57.27bluelightningright, it was raised there but there wasn't a lot of discussion IIRC
16:57.32fray_khem, thats the one I know of at least.. my commercial distro may be affected as well..
16:57.44khemfray_: I see.
16:57.59fray_the hardest part in this is gauging usage..  if nobody cares then removing the functionality really shouldn't matter..
16:58.10khemI will initiate an email thread on oe-core/oe-devel and seek feedback on this feature
16:58.13fray_but we need to avoid removing it, and then having a huge backlash..
16:58.15pb_It's fairly hard to see why anybody would rationally care.
16:58.42fray_pb_ there still are some memory constrained systems, but that is becoming significantly less 'normal' then it was evern 2 years ago
16:58.43darknightepb_: there's always someone with their special case.
16:58.43bluelightningI was hoping for response from Darren since he dug into this in excruciating detail during his work on poky-tiny
16:58.44khempb_: hard to say, I dont know what everybody uses
16:58.50pb_I can imagine there are people using that feature due to inertia or "because it's there", but I find it fairly hard to believe there are many (perhaps even any) users whose lives would be seriously spoiled by not having it.
16:59.01bluelightningdvhart ^
16:59.02darknightepb_: question is how loud they scream and how hard it is to get them to work around it.
16:59.10khemthen there is uclibc too
16:59.11pb_fray_: well, right, but anybody with serious memory contraints is probably not using any form of glibc anyway.
16:59.19khemfor smaller root file systems
16:59.24khemso I kind of agree
16:59.26dvhartbluelightning, hey
16:59.29dvhartjust joined
16:59.34dvhartwhat am I looking for?
16:59.36fray_I have customers who are.. they are able to pair glibc down to the size of a 'larger' uclibc system..
16:59.42khemdvhart: poky tiny
16:59.47darknighteseems like it would make sense to drop it and see who screams.
16:59.48bluelightningdvhart: we've been discussing the potential removal of eglibc option groups and its possible impact on setups such as poky-tiny
16:59.51frayok.. time check.. 1 minute to go on my clock
16:59.55darknightewith fair warning of course.
16:59.56denix0eren: http://lwn.net/Articles/488847/
16:59.59khemwhat impact will it have if we threw away LIBC_FEATURES
17:00.23dvhartright, so fray responded to that pretty well I thought
17:00.30dvhartthose are core to poky-tiny
17:00.35dvhartwithout them we have two options
17:00.35khemcan you consider uclibc instead ?
17:00.38dvhart1 static linking
17:00.40dvhart2 uclibc
17:00.50fray_ok.. so we have remaing projects in progress status and infrastructure.. do we want to skip these or try to cover them quickly..
17:00.58khemstatic linking with eglibc/glibc is more or less unsupported
17:01.13khemfray_: we can skip
17:01.13bluelightningfray_: let's cover them very quickly
17:01.18fray_ya.. static linking also results in a (more then one binary) system using -more- memory
17:01.18erendenix0: thanks!
17:01.19bluelightningor skip :)
17:01.29Crofton|worklet me know when you are done
17:01.33*** join/#oe fgretief (~chatzilla@196-215-192-74.dynamic.isadsl.co.za)
17:01.34dvhartThere is also this little gem :-) http://www.linuxjournal.com/article/5457
17:01.35fray_isn't a fan of uclibc in a commercial setting either
17:02.04dvhartfray, khem, I haven't done enough research to fully understand the impact/compatibility/etc of using uclibc
17:02.06mckoanuclibc should exist only as option
17:02.20dvhartI don't know where it breaks down, what it's lacking, which corners it cuts, etc
17:02.23fray_ya.. the mklibs optimization may be impacted as well.. (likely won't be easy anymore)
17:02.24bluelightningdvhart: I didn't realise you'd been working on this angle over a longer time period ;)
17:02.29dvhartand frankly, the fact that I don't know, means I don't want to use it
17:02.32dvhartbluelightning, ;-)
17:02.40khemdvhart: this predates NPTL
17:02.44fray_ok.. further discussion we can do off meeting.. we're past the hour
17:03.01dvhartit was an odd sort of project when IBM was dabbling in embedded
17:03.04khemand maintainer's dislike for static libc
17:03.05fray_lets take two minutes to cover the project status and then call it done.
17:03.06bluelightningfray_:  OK, thanks for chairing
17:03.10fray_#topic 4a - oe-core release
17:03.23dvhartok, I think I'm interrupting here
17:03.36fray_We are currently aligning with the Yocto Project for the most part (and they are in turn aligning with us)..
17:03.55fray_We're looking at roughly October for the next release, with a stablization period prior to release.
17:04.15fray_I don't have further information, Richard is usually the one who has more detailed plans..
17:04.44darknightefray_: any significant changes expected?
17:04.51fray_my personal expectations is a lot of the large churn should be done by late august
17:05.06fray_darknighte not that I know of.  The big changes (toolchain specifically) are already in place..
17:05.29darknightefray_: that's what I was hoping.
17:05.31fray_I know there are some bitbake (webhob) and other changes in progress, but I don't think they will be terribly disruptive..
17:05.54frayOn to the next..
17:06.02fray#topic 4b - meta-oe appends/overlay
17:06.11frayBluelightning -- ?
17:06.23bluelightningno status change on that
17:06.50fray_this is something I think we'd like to be a regular working group topic..
17:07.05fray_merging meta-oe to oe-core.. and working on places where there may be functional differences.. for alignment..
17:07.10fray_#topic 4c - python 3
17:07.33fray_there are two items here.. one is introducing python 3 into oe-core (as a recipe), which I believe Khem is currently sending to the list..
17:07.45darknighteagrees with fray_ on the working group topic idea for meta-oe
17:07.47fray_the other is eventually moving bitbake to python3.  We've said that will not happen prior to the current release..
17:08.02fray_(october) but likely will be an issue for early in the next development cycle
17:08.09fray_khem, anything to add?
17:08.21pb_when you say "moving to", do you mean "working with" or "requiring"?
17:08.37fray_moving to -- as the required python version for bitbake
17:09.16fraymoving on..
17:09.24darknighteThere will almost certainly be significant pushback on the move to python 3.
17:09.27kergothnote that we might be able to keep supporting 2.x with 3to2 if need be
17:09.55fray_darknighte we're aware of that.. we (oe) need to figure out if even next release is an appropriate time to do thsi
17:09.58fray#topic 4d - release status notification
17:10.03bluelightningkergoth: pb_: AFAIK RP's thinking was that it wouldn't be practical but I don't know if he was looking at 3to2
17:10.19darknightefray_: I agree.  Just want to air the obvious...
17:10.26frayRP, prior to vacation was trying to provide regular status information to the list.  We expect this to resume..
17:10.36frayand I think that's it.. we're going to skip #5
17:11.27frayfinal comments.. if people think this is useful.. we'd like to do something like it approx once a month.. (or if thats too often, once every other month)
17:11.35Crofton|workI think a lot of people will be on vacation over the next month btw
17:12.07frayok.. meeting done!  Thanks all
17:12.20Crofton|work#endmeeting
17:12.21darknighteAs Crofton|work says, I think a lot of people will be out.
17:12.21Crofton-botMeeting ended Tue Jul 30 17:12:21 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
17:12.21Crofton-botMinutes:        oe/2013/oe.2013-07-30-16.03.html
17:12.21Crofton-botMinutes (text): oe/2013/oe.2013-07-30-16.03.txt
17:12.21Crofton-botLog:            oe/2013/oe.2013-07-30-16.03.log.html
17:12.24fray12 minutes over.. :/  we'll work on doing it better next time
17:12.25bluelightningthanks all
17:12.34*** join/#oe tgall_foo (~tgall@linaro/tgall-foo)
17:12.38darknightefray: almost a linear offset from when it got started, no?
17:12.43fray_darknighte ya.. we might factor that into NOT doing it next month
17:12.50fray_darknighte :)
17:12.56darknighteindeed ;)
17:13.05mckoanthanks all
17:13.31mckoanare you going to post minute on ML?
17:13.49darknightemckoan: I think Crofton|work was planning to post them to the website...
17:14.45mckoanthanks
17:14.49Crofton|workI will send to Jefro and will work with ka6sox so I can rsync them somewhere
17:15.17mckoanCrofton|work: today worked as the meta-bot ;-)
17:15.54denix0mckoan: that would be Crofton-bot...
17:16.10dvhartfray, are you subscribed to the eglibc mailing list? If so, would you mind replying to the thread on the libc option groups, adding me to Cc, with something like "Darren, how would this impact poky-tiny?" to give me an entry point into the discussion?
17:16.31mckoandenix0: yep :-D
17:16.44darknightedenix0: ahh, but Crofton|work is the meta-bot to take the Crofton-bot capture and post it via Jefro...
17:16.55denix0dvhart: who needs an introduction? :)
17:17.04fray_dvhart I have responded in the past..  you should be able to just jump in though..
17:17.06dvhartdenix0, I'm not subscribed
17:17.11fray_I can find a few of them and point you to the list archive
17:17.16dvhartso I need a way to respond to the thread
17:17.16denix0darknighte: it's a meta-world!
17:17.29fray_http://www.eglibc.org/archives/patches/msg01299.html  thats the current thread..
17:17.31dvhartI don't see a way to do that from the archives...
17:17.33erendvhart: you will probably miss some e-mails from people who do not reply to "all"
17:17.44dvharteren, I *will* subscribe
17:17.53erenah okkie :)
17:17.54dvhartbut I was not subscribed when the thread started
17:18.05erenyeah, I guess someone needs to CC you in the thread
17:18.10fray_http://www.eglibc.org/archives/patches/msg01274.html
17:18.12dvhartright, that :-)
17:18.21erenor you can get Thread-ID and inject that header to your mail :P
17:18.44dvhartI was looking for the Thread-ID and didn't find it
17:18.46fray_my follow up to that last was sending the email to the oe-core list asking about eglibc usage
17:18.47erensure, there is no Message-ID or Reply-To in web interface, better get CCed, hehe
17:19.03dvhartfray_, right, I figured I should respond directly to the eglibc list
17:20.34mr_scienceanybody currently building/using nginx?
17:21.13mr_sciencei could only find recipes in some oe-rascal repo (not even sure what a rascal is)
17:21.42fray_darren, I forwarded you three emails from that original thread, complete with message id's
17:21.58fray_ignore them if you've already figured out how
17:22.05mr_scienceof course it has its own funky configure setup and doesn't build at all in oe-classic...
17:22.14dvhartheh, OK, I'll see if I can find a mailer that will let me hand edit the thread-id....
17:22.25fray_make that 4.. ;)
17:22.37mckoanhave a nice rest of the day
17:22.38bluelightningmr_science: hmm... haven't heard of anyone working on that at least discussion I've seen
17:22.55bluelightningmr_science: a recipe for it would be welcome in meta-webserver though FWIW
17:23.38erenbuilding nginx should be straightforward, btw?
17:24.08erendepends on which modules you want to enable, which would include lots of PACKAGECONFIG variables, hehe
17:25.33erenis anyone packaging it?
17:27.18bluelightningbbl
17:28.55mr_scienceeren: i don't think so...
17:29.41mr_sciencebuilding would be straightforward if it didn't use such a funky config setup full of oddball hardcoded paths
17:30.11mr_scienceso i'll need to patch a few things before i can say much more...
17:31.09mr_sciencejust trying to make sure someone else hasn't already done it
17:31.12erenmr_science: well configure script seems to work
17:37.54Crofton|workJefro, minutes are on the way
17:38.39Jefrook, thanks
17:39.03Crofton|workhmm, topic did nothing
17:40.11*** join/#oe martiert_ (~martin@59.37-191-128.fiber.lynet.no)
17:43.03mr_scienceeren: which version?
17:43.52mr_sciencei looked at 1.3.0 a little in oe-classic yesterday and it barfed on pretty much all the deps
17:44.22mr_sciencemaybe the configure script was fixed in later versions?
17:46.43*** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl)
17:47.12erenmr_science: latest stable, 1.4.2
17:47.14erenhttp://nginx.org/en/download.html
17:47.50erenand it has a little documentation on how to configure the source: http://nginx.org/en/docs/configure.html
17:52.38mr_sciencethe version i used only looked in one standard place and a few oddball paths
17:54.20mr_scienceanyway, the combination of older bitbake/oe-classic was not a good match for the way nginx configure works
17:54.45erenI guess it needs to be re-packaged
17:55.29mr_sciencethe --with-zlib=path options expect path to be the source tree
17:56.36erenoh
17:56.43mr_scienceyou can fake it with --with-zlib=${STAGING_INCDIR) but then make wants to run configure again to force everything to build static
17:57.05mr_sciencebrittle homegrown juju
17:57.51mr_scienceprobably why nobody's done it yet...
17:58.09mr_sciencethey think "oh that's simple" until they try it
18:03.47erenhm, I'm wondering how ubuntu did it
18:04.23erenhm. it's 1.2.6, raring release
18:08.30erenmr_science: there is nothing fancy on ubuntu package, btw
18:11.25*** join/#oe martiert_ (~martin@59.37-191-128.fiber.lynet.no)
18:12.58*** join/#oe liveforeverx (~Adium@p5B06DE81.dip0.t-ipconnect.de)
18:14.20mr_scienceboth ubuntu and gentoo have their patches...  for native builds
18:14.23*** part/#oe davest (Adium@nat/intel/x-dfynalpalbvmlore)
18:14.48mr_sciencebut it won't understand sysroot without some help
18:19.29*** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian)
18:29.58*** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net)
18:30.30mr_scienceeren: once i have something that builds i'll stick it on github
18:31.01erenmr_science: okkie
18:31.54*** join/#oe liveforeverx (~Adium@p5B06DE81.dip0.t-ipconnect.de)
18:33.30*** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey)
18:39.45andre_dHi, how can I see which package or recipe installed a certain file in my final image? (I'm interested in /etc/inittab, and in this case it's probably sysvinit-inittab, but am wondering if there is a generic way to find out?)
18:41.39kergothlooks into creating a systemd service for chen qi's r/o script(s) to try using those bits on a systemd image
18:46.59*** join/#oe dijenerate (~dijenerat@65.48.221.118)
18:48.56*** join/#oe ao2 (~ao2@2001:1418:117::1)
19:09.29*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
19:12.19mr_scienceandre_d: don't know of a way on the build side, just opkg search /path/to/file on the running system
19:12.38mr_sciencenot that that question doesn't come up regularly...
19:12.46*** join/#oe zecke_ (~ich@91-65-247-193-dynip.superkabel.de)
19:23.03*** join/#oe KNERD (~KNERD@24.175.249.177)
19:48.46martiertI have just tried to figure out why oe sets load address to 00008000, while the same kernel sets load address 0x80008000 if built manually outside oe. I see the kernel links with zreladdr=00008000 inside oe
19:48.51martiertany ideas on where that flag is set?
19:48.59martierttried git grep in oe-core, but found nothing:s
19:49.52denix0martiert: <machine>.conf?
19:52.00martiertdenix0: <machine>.conf only sets UBOOT_ENTRYPOINT and UBOOT_LOADADDRESS to 0x80008000
19:52.18martiertbut the u-boot-mkimage is not run, so there is no relocation going on
19:57.44otavio:-)
19:57.46otavioHi folks
19:58.02otavioI had a day full of meetings, so I end missing the TSC one. I am sorry
20:06.58mr_scienceotavio: if you provide cookies, I won't tell...
20:07.15otaviomr_science: hehe
20:13.11pb_martiert: check your run.do_compile for clues, I guess
20:14.40martiertpb_: I figured out the problem, but not the solution. I have appended linux-yocto_3.4 kernel, and in that append, I specify a sha sum for the git repo, as well as add a file://defconfig to the SRC_URI. The defconfig is copied over, but doesn't seem to be used
20:16.43martiertany idea why it's not used?
20:18.24*** join/#oe aloril (~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi)
20:19.56frayotavio, we should have good notes from it.. and we expected people to be unable to join, so all feedback and comments to the oe list(s) are welcome
20:20.20fray(we did minutes a bit differently with this format of a meeting.. so Crofton|work was helping get them uploaded to Wiki)
20:21.30otavio;-)
20:21.42otavioAppreciated :-)
20:22.56mr_sciencemartiert: did it build the commit you specified?
20:27.41*** join/#oe liveforeverx (~Adium@p5B06DE81.dip0.t-ipconnect.de)
20:27.56*** join/#oe rcf (~rcf@178-117-146-93.access.telenet.be)
20:34.55pb_martiert: oh, right.  I think linux-yocto has some crazy special tooling, but I'm afraid I have no idea how it's meant to work.
20:35.03pb_maybe ask the #yocto dudes
20:35.03martiertmr_science: yes, and it copies the correct defconfig file, but doesn't copy it into .config
20:36.28martiertpb_: ok, I'll ask them then
20:40.54mr_sciencemartiert: looks like the linux-omap3.inc we're using does a "require" to pull in both those pieces
20:41.13martiertmr_science: from meta-ti?
20:41.23mr_sciencerequire recipes/linux/[setup|copy]-defconfig.inc
20:41.44mr_scienceno, this is arago/oe-classic
20:42.39mr_sciencei would hope current linux-yocto is a bit less klugey but i can't say i've looked at it yet
20:43.10denix0mr_science: that's in meta-ti as well
20:44.25martiertmr_science: ok, do_configure in linux.bbclass does a cp ${WORKDIR}/defconfig ${B}/.config, so looks like it does what it should
20:44.43denix0mr_science: although linux-omap3.inc was in classic arago only... but that was a special case
20:45.10mr_sciencemartiert: is it really your defconfig in workdir?
20:45.12denix0martiert: what's the problem? are you still looking for the load address?
20:45.37martiertdenix0: yes
20:46.35martiertmr_science: yes, there is at least a zero diff
20:46.43denix0martiert: what BSP are you using?
20:47.10mr_scienceokay, just checking...
20:47.32martiertdenix0: I'm making one myself
20:52.26*** join/#oe liveforeverx (~Adium@p5B06DE81.dip0.t-ipconnect.de)
20:54.39martiertseems like I fixed it by doing it in a do_configure_prepend, Guess I coudl also set B = "${S}" in my linux-yocto_3.4.bbappend
20:55.30mr_sciencesounds about right
20:56.03mr_sciencei had a similar "collision" replacing a package file from a bbappend
20:56.19mr_sciencenot kernel-specific really...
20:57.09martiertexcept now it's complaining about an unclean directory during kernel_configcheck. Guess I'll have to look at that code next
20:58.44bluelightningerm, I'm not sure you should be trying to set B = ${S}
20:58.51bluelightningit's set separately on purpose
20:59.27mr_sciencemartiert: did you put your defconfig in a machine subdir?
20:59.35bluelightningmartiert: I'd really recommend you consult zeddii in #yocto or email the mailing list and cc him (Bruce Ashfield)
21:00.14martiertok, I'll ask on #yocto then:) mr_science: Yes
21:01.14mr_scienceokay, now i'm curioous...
21:04.17mr_sciencemartiert: looks like linux-rpi-3.6.11 uses the same method
21:04.49mr_scienceie, do_configure_prepend and install their own defconfig into workdir/defconfig
21:05.18bluelightningthat shouldn't be necessary though
21:05.30bluelightningit really is supposed to pick up the defconfig in SRC_URI as I understand it
21:05.37mr_sciencetell djwillis then
21:05.52mr_sciencei haven't hacked that recipe yet ;)
21:06.22mr_sciencealso, the kernel_configure_variable thing looks handy
21:07.31mr_sciencemartiert: maybe you could get by with setting some kernel_configure_variable options in your kernel recipe?
21:08.02mr_scienceas long as there aren't too many things you need to change...
21:10.27mr_sciencemartiert: one more...   does your recipe inherit both kernel and siteinfo?
21:13.54*** join/#oe eFfeM1 (~frans@c73189.upc-c.chello.nl)
21:18.44mr_sciencebefore i completely dissect the apache stuff, anybody know how i enable mod_proxy?
21:18.55*** join/#oe SoylentY_ (~SoylentYe@c-24-128-79-27.hsd1.ma.comcast.net)
21:19.11mr_sciencei don't see a separate recipe anywhere in my local trees...
21:21.29*** join/#oe liveforeverx (~Adium@p5B06DE81.dip0.t-ipconnect.de)
21:44.18*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
21:47.21*** join/#oe zenlinux (~sgarman@c-50-139-96-211.hsd1.or.comcast.net)
21:49.07*** join/#oe W1N9Zr0 (~W1N9Zr0@24-246-93-30.cable.teksavvy.com)
21:49.29mr_scienceman, every time i get into something like this i wonder what i'm missing...
21:50.54mr_scienceeg, given the kernel recipe config options, seems like apache should have something similar for selecting modules and other stuff
21:51.14mr_sciencejust feels like i'm always missing something...
21:53.00*** join/#oe shawn286 (~Tiberius@unaffiliated/shawn156)
21:53.24mr_sciencefeel free to whack me with the clue-stick at any time...
22:00.14bluelightninghmm, I'm not sure how apache extra modules are enabled
22:00.40bluelightning(and that's a bit sad because it was me who worked on that recipe)
22:01.25bencoh:]
22:01.39bencohguess we should dissect your brain then
22:03.57bluelightninghey, I need that brain :)
22:04.00mr_scienceyup, looking at some recipes and the apache configure output
22:04.29mr_sciencelooks like i definitely need to enable some things we need
22:05.37mr_sciencethen there's tuning the whole mpm config for 600 MB of ram...
22:05.54mr_sciencemaybe i should go back and look at nginx again...
22:07.12bluelightningapache is kind of heavy for a lot of embedded type applications for sure
22:08.19bencohnginx definitely fits better for most embedded plateforms :)
22:08.56bluelightningwe don't yet have an nginx recipe as discussed earlier, but for simpler configurations we have a number of alternative smaller web servers in meta-webserver
22:09.11bluelightninge.g. hiawatha and cherokee
22:09.47*** join/#oe ant_home (~andrea@host218-250-dynamic.17-79-r.retail.telecomitalia.it)
22:10.11mr_sciencecurrently running lighttpd but one of the devs apparently needs reverse proxy support
22:10.14bencohmr_science: btw, I'm currently building/using nginx, if you want a recipe
22:10.28bencoh(it relies on the cross patch)
22:11.00mr_sciencebencoh: pointer?
22:11.40mr_sciencei have a (currently nonfunctional) recipe i lifted from rascal, but it needs some luv to make it work
22:12.13bencohI'm using a different one (with a different patch), currently building and working on both x86 and arm
22:12.22bencoh(others should work too)
22:12.42bencohbased on http://forum.nginx.org/read.php?29,179478
22:12.42mr_scienceare those publicly visible somewhere?
22:13.11bencohlemme pastebin that ... it's not public for the time being, but nothing really secret (just a private repo)
22:14.03mr_sciencelooks like the op disabled the problematic parts of configure...
22:14.16bencohmr_science: http://pastebin.notk.org/pastebin.php?show=d386380f4 http://pastebin.notk.org/pastebin.php?show=d16cfcf79
22:14.33mr_science--without-pcre --without-http_gzip_module ...
22:14.46mr_sciencejeez, *i* could've done that...
22:14.56bencohI'm building mine with pcre
22:15.07bencoh(and gzip)
22:15.08mr_sciencegood
22:15.48bencohthe important part of the ml mail is the patch
22:16.13mr_sciencelooks amazing close to what was in my head...
22:16.21mr_science*amazingly even
22:16.44bencoh:)
22:17.26bencohwhat's really amazing (sic) is that this thing is more than 2 years old ... and vanilly nginx is still not cross-friendly
22:21.51mr_sciencei noticed, and had the same "amazing" thoughts in my head...
22:22.07mr_scienceso stop putting them there!
22:22.17mr_sciencedons his foil hat
22:22.43bencoh:))
22:25.41mr_scienceis that really for 1.0.11 ?
22:26.12mr_sciencedid you avoid the newer stuff on purpose?
22:26.50bencohI first wrote this recipe 1.5years old and didn't have time to test it against newer versions
22:27.00bencohs/old/ago/
22:27.07mr_scienceah
22:27.18mr_sciencei started making a 1.3.0 last night
22:27.44mr_sciencealso noticing 1.3.11 is the latest in portage on my laptop
22:27.46bencohwow, 1.0.11 really was latest-stable at that time :))
22:28.23bencohI guess I should give 1.4.2 a try, some day
22:28.44mr_scienceso maybe i'll just migrate everything to 1.4 then
22:29.00mr_sciencenotice any hard deps in the new stuff?
22:29.34bencohhaven't checked yet
22:30.03*** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner)
22:31.23mr_sciencefrom what i saw last night it's pretty much pcre and few more-or-less "normal" things
22:31.43mr_scienceso i guess we'll see...
22:34.36*** join/#oe jkridner|work (~jkridner@nat/ti/x-djissblsvblyvvxy)
22:39.16mr_sciencei can't believe i just did that...
22:40.29bencohdid you take care of the different data types ?
22:40.42mr_scienceafter look at the local config stuff in the nginx and apache2 source trees, i just went back to lighttpd and went "oh nice, autotools for a change..."
22:40.50bencoh:D
22:41.28bencohfrom what I've seen (quite a few years of porting/crossbuilding), autotools still is one of the most friendly ... which is ... scary :)
22:41.41mr_scienceyeah...
22:42.04mr_sciencei can't remember ever saying that about autotools before
23:07.19*** join/#oe dos11 (~dos@unaffiliated/dos1)
23:29.45*** join/#oe mwester (~mwester@nslu2-linux/mwester)
23:51.16*** join/#oe shawn286 (~Tiberius@unaffiliated/shawn156)
23:55.45*** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.