| 00:00.05 | *** join/#oe zenlinuxPDX (~sgarman@c-76-105-143-140.hsd1.or.comcast.net) |
| 00:02.17 | *** join/#oe angelox_123 (~Angelo@201-95-129-46.dsl.telesp.net.br) |
| 00:24.23 | *** join/#oe GNUtoo|laptop (~gnutoo@host55-144-dynamic.54-79-r.retail.telecomitalia.it) |
| 00:29.47 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
| 00:29.55 | *** join/#oe kerim (~kerim@81.214.22.138) |
| 00:34.52 | khem | grg: hi |
| 00:35.01 | grg | khem, yo |
| 00:35.17 | khem | grg: now bitbake world is parsable |
| 00:35.27 | grg | ooooh |
| 00:35.28 | khem | grg: I know you have a powerful machine |
| 00:35.32 | grg | :) |
| 00:35.42 | khem | so when it has some free cycles give it a shot |
| 00:35.48 | grg | can do |
| 00:36.08 | khem | there are 82500 tasks dont be intimidated |
| 00:36.52 | khem | you can do it for whatever distro/machine combo you use |
| 00:37.23 | khem | my laptop has been churning bits for over 16 hrs now |
| 00:37.29 | grg | i'm just reading docs today anyway. I'm sure the workstation needs some exercise |
| 00:37.42 | khem | cool |
| 00:38.12 | khem | you can also do bitbake -k world and save the results |
| 00:38.18 | khem | and see what all fails |
| 00:39.21 | grg | khem, whatever happened to the cooker.log file? |
| 00:39.42 | khem | that was bitbake master |
| 00:40.12 | grg | ive just done a git pull in my bitbake and oe trees |
| 00:40.47 | grg | so there will be no massive log file stored somewhere? I have to pass the output of bitbake through tee or something? |
| 00:42.38 | khem | yeah |
| 00:43.02 | khem | bitbake -k world | tee world.log |
| 00:43.19 | grg | yup, i just kicked that off |
| 00:43.32 | grg | with 'time' out the front |
| 00:43.41 | grg | i hate it when i forget to time long jobs |
| 00:46.52 | khem | thats good. |
| 00:46.57 | khem | what distro/machine ? |
| 00:48.18 | grg | khem, qemumipsel/minimal |
| 00:48.28 | khem | ok nice |
| 00:48.33 | *** join/#oe Jay7 (jay@93-81-71-231.broadband.corbina.ru) |
| 00:48.36 | khem | I do it on arm/minimal |
| 00:49.20 | grg | i'm sure i'll get more failures than for arm |
| 00:49.35 | grg | there's a lot of omap only stuff around |
| 00:50.03 | grg | hmmm... hope i don't smash my workplace net quota... |
| 00:50.36 | grg | khem, how big is your sources dir? |
| 00:53.34 | ka6sox-work | grg, are you working on omap? |
| 00:53.45 | grg | ka6sox, no. mipsel |
| 00:54.16 | grg | have played with beagleboard in the past, not recently though |
| 00:55.15 | ka6sox-work | oh, understood. |
| 00:56.18 | grg | khem, i have 64886 tasks |
| 01:00.06 | *** join/#oe mithro (~tim@unaffiliated/mithro) |
| 01:03.03 | khem | grg: you dont have rm_work enabled do you ? |
| 01:03.11 | grg | nope |
| 01:03.17 | khem | thats why |
| 01:05.17 | grg | khem, i have 130gb free on my tmp dir, am i likely to fill my drive without rm_work? |
| 01:05.26 | khem | grg: most likely |
| 01:05.43 | grg | hmm |
| 01:06.27 | khem | grg: I would suggest add this |
| 01:06.33 | khem | INHERIT += "insane sanity angstrom-mirrors recipe_sanity testlab devshell rm_work" |
| 01:06.42 | khem | to your local.conf |
| 01:09.29 | grg | khem, here's my local.conf http://pastebin.ca/1936217 - anything else i should change before i restart? |
| 01:11.28 | khem | grg: also add |
| 01:11.31 | khem | QA_LOG = "1" |
| 01:11.44 | khem | PSTAGING_DISABLED = "1" |
| 01:12.24 | khem | somehow pstaging and staging_qa did not go well wth rm_work |
| 01:12.33 | khem | when one restarted the build |
| 01:12.39 | khem | so just disable it |
| 01:12.42 | khem | if not used |
| 01:13.02 | grg | ok |
| 01:13.15 | grg | i suppose i should check if i've got any local commits too... |
| 01:13.30 | khem | I dont think you need TARGET_FPU = "soft" |
| 01:13.45 | khem | thats ok |
| 01:14.03 | khem | your local commits need to validate with bitbake world anyway |
| 01:14.06 | khem | :) |
| 01:15.23 | grg | yes, but chances are my changes fix things that are broken, but in less than ideal ways |
| 01:16.01 | grg | TARGET_FPU=soft should be faster than using the kernel fpu emulation, at least on mips |
| 01:16.20 | grg | (so i read on the mipslinux mailing list once upon a time) |
| 01:19.41 | khem | thats true |
| 01:20.19 | khem | for qemu it does not matter |
| 01:21.52 | grg | i actually don't run inside qemu at all |
| 01:22.28 | CMoH | hey. why is prefix=/usr instead of / when staging an install? |
| 01:23.14 | grg | CMoH, binaries and libraries generally get installed in /usr/lib and /usr/bin, not /lib and /bin |
| 01:23.48 | khem | CMoH: you can choose to flatten the tree |
| 01:23.51 | CMoH | yeah, but shouldn't bindir, libexec and such take care of that? prefix should point to the root of the filesystem |
| 01:24.18 | khem | see micro.conf |
| 01:25.36 | khem | grg: ok cool if u have real hardware |
| 01:27.38 | khem | CMoH: no |
| 01:28.03 | khem | CMoH: the same packages are installed in / on hurd |
| 01:28.13 | khem | on lnx generally /usr is preferred |
| 01:29.05 | CMoH | yeah, i see; my mistake |
| 01:29.36 | khem | grg: did you restart the build |
| 01:29.48 | grg | khem, yep |
| 01:30.37 | grg | khem, when will oe support hurd? |
| 01:30.41 | grg | :P |
| 01:31.01 | CMoH | well, so how can i reach with prefix=/usr the folder /etc with cmake? |
| 01:32.20 | *** join/#oe kgilmer (~kgilmer@dsl254-120-154.nyc1.dsl.speakeasy.net) |
| 01:35.07 | CMoH | bloody idiotic cmake |
| 01:36.56 | *** join/#oe mithro (~tim@unaffiliated/mithro) |
| 01:37.36 | CMoH | is there any irc channel where it's safe to write AAARGHH |
| 01:40.13 | khem | grg: cool so how many task does it show now |
| 01:40.26 | khem | grg: and regarding hurd I believe never |
| 01:40.33 | grg | 82357 |
| 01:40.40 | khem | same as me |
| 01:40.54 | grg | did hurd ever fix that 2gb partition size limit? |
| 01:44.55 | *** join/#oe kergoth (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 01:49.03 | khem | grg: you will need this patch |
| 01:49.05 | khem | http://pastebin.com/CJc0vMxp |
| 01:49.29 | khem | this lot of TI stuff is weird licence |
| 01:49.38 | khem | not really convenient |
| 01:50.23 | grg | khem, shouldn't it be excluded because i'm not building for a COMPATIBLE_MACHINE? |
| 01:50.37 | khem | ah could be |
| 01:52.32 | khem | grg: my machine was not in compatible machines but it still poopoo'ed on me |
| 01:52.57 | grg | i suppose since we have the same number of tasks that the tasks are going to be the same |
| 01:54.12 | khem | well keep going and see what all breaks |
| 01:54.26 | khem | you are using bitbake -k anyway |
| 01:54.53 | khem | this should fails and sit in a corner still bitbake world will progress |
| 02:01.03 | *** join/#oe aloisiojr (~aloisio@187.113.161.75) |
| 02:19.51 | *** join/#oe mnabil_ (~mnabil@41.234.71.146) |
| 02:25.52 | *** join/#oe kerim (~kerim@81.214.22.138) |
| 02:31.08 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 02:42.13 | *** join/#oe jkridner_ (~jason@pdpc/supporter/active/jkridner) |
| 02:43.57 | *** join/#oe Guest12314123 (4c5f604a@gateway/web/freenode/ip.76.95.96.74) |
| 03:12.52 | *** join/#oe borg__ (~olaf@p548681D8.dip0.t-ipconnect.de) |
| 03:25.49 | *** join/#oe GNUtoo|laptop (~gnutoo@host55-144-dynamic.54-79-r.retail.telecomitalia.it) |
| 03:27.59 | *** part/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 03:34.07 | htns | i'm getting an error building libpam-base-files, install : cannot stat `/home/richard/oe/tmp/work/armv5te-angstrom-linux-gnueabi/libpam-base-files-1.0-r6/pam.d/*': No such file or directory. It looks like the pam files are not in pam.d but instead being copied one directory up. the bb file has SRC_URI="file://pam.d/*" so is the problem caused by bitbake not copying to the right place? |
| 03:38.49 | *** join/#oe russ (foobar@ip70-176-251-1.ph.ph.cox.net) |
| 03:39.58 | kergoth | htns: libpam-base-files unpacks fine with current oe. |
| 03:40.39 | htns | kergoth, is there something in my environment that could be causing this problem? |
| 03:42.20 | htns | i assume it is bitbake that is copying the SRC_URI pam.d/* to workdir/... instead of workdir/...pam.d/ |
| 03:47.35 | htns | kergoth, in your build, do the files from libpam-base-files/pam.d/* show up in a pam.d directory in the workdir/libpam-base-files-1.0-r6/pam.d/? |
| 03:49.02 | *** join/#oe mnabil_ (~mnabil@41.234.68.245) |
| 03:49.52 | *** join/#oe gchiii (~gchiii@adsl-76-255-12-150.dsl.mrdnct.sbcglobal.net) |
| 03:57.07 | htns | i'm using bitbake top of tree 992e460f24d4da707c76d6e6d74d3684c9646279 . is that a problem? |
| 04:06.35 | kergoth | bitbake is irrelevent. unpacking is controlled by code in base.bbclass in oe |
| 04:06.43 | kergoth | bibake just runs tasks, thats all, it doesn't care what the tasks do |
| 04:31.06 | *** join/#oe koobe_ (~koobe@dsl-trebrasgw2-fe4df900-31.dhcp.inet.fi) |
| 04:35.30 | *** join/#oe GNUtoo|laptop (~gnutoo@host55-144-dynamic.54-79-r.retail.telecomitalia.it) |
| 04:45.17 | *** join/#oe konne (~Miranda@85.183.99.11) |
| 04:57.05 | *** join/#oe vanous (~vanous@194.228.223.3) |
| 05:02.34 | htns | yeah, i can't make sense of it. seems consistent, i had the same problem with base-files |
| 05:13.06 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
| 05:15.27 | *** join/#oe mrc3_ (~mrc3@nat/ti/x-iekzopbkyavkevnf) |
| 05:31.24 | *** join/#oe russ (foobar@ip70-176-251-1.ph.ph.cox.net) |
| 06:08.42 | *** join/#oe B_Lizzard (~havoc@athedsl-428632.home.otenet.gr) |
| 06:10.24 | eFfeM_work | hi |
| 06:12.14 | *** join/#oe vps (~vitus@145.253.169.210) |
| 06:22.37 | *** join/#oe dth (~dth@a89-183-4-212.net-htp.de) |
| 06:24.33 | ka6sox-work | morning |
| 06:36.17 | eFfeM_work | ka6sox any progress on the freenx stuff? didn't have time to peek in it myself, too much other things at hand |
| 06:36.38 | *** join/#oe kerim (~kerim@81.214.22.138) |
| 06:36.41 | *** part/#oe fahad (8bb5d022@gateway/web/freenode/ip.139.181.208.34) |
| 06:37.03 | eFfeM_work | khem, btw was reading the backlog, I'll see if I can kick off building world with dev head on our build server; let it use some of those idle cycles; machine calamari, distro minimal |
| 06:38.22 | eFfeM_work | btw 1.8.18 with oe testing does not seem to work any more: |
| 06:38.34 | eFfeM_work | OTE: <type 'exceptions.SyntaxError'>:EOL while scanning string literal (<string>, line 1) while evaluating: ${@oe.utils.ifelse(bool(d.getVar('MACHINE', True)), '${MACHINE}', 'BASE_PACKAGE_ARCH')} ERROR: Error in executing: /home/hudson/jobs/FM_test/workspace/openembedded/recipes/ncftp/ncftp_3.2.0.bb |
| 06:38.46 | eFfeM_work | get a lot of these |
| 06:39.23 | *** join/#oe sgh (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 06:49.10 | *** join/#oe Heinervdm (~thomas@pD9E14C40.dip.t-dialin.net) |
| 06:54.46 | *** join/#oe rednul_ (~rednul@host-174-45-250-246.bln-mt.client.bresnan.net) |
| 06:56.20 | eFfeM_work | khem, did you get world parsing without unmet dependency errors ? |
| 06:56.25 | eFfeM_work | first thing I get is: |
| 06:56.26 | eFfeM_work | ERROR: '['/home/hudson/jobs/FM_world/workspace/openembedded/recipes/powervr-drivers/bc-cube_0.2.0.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'libgles-omap3-x11wsegl' but it wasn't found in any PACKAGE or RPROVIDES variables |
| 06:57.21 | eFfeM_work | this package does not exist :-( |
| 06:59.53 | eFfeM_work | c |
| 07:00.39 | eFfeM_work | other Q: |
| 07:00.50 | eFfeM_work | can recipe names have two underscores in them? |
| 07:06.28 | *** join/#oe joshin1 (~josh@174-22-228-93.phnx.qwest.net) |
| 07:11.08 | *** join/#oe Proxyles (~henrik@c-9f93e255.56-4-64736c14.cust.bredbandsbolaget.se) |
| 07:14.24 | ka6sox-work | eFfeM_work, are you using hudson to manage builds? |
| 07:14.37 | eFfeM_work | yes |
| 07:14.45 | ka6sox-work | how do you like it? |
| 07:15.02 | eFfeM_work | actually only recently started to use it, I have not too much experience with it, but initial impression is ok |
| 07:15.33 | ka6sox-work | good to hear... |
| 07:15.56 | eFfeM_work | you're using it too? or maybe involved in development of it? |
| 07:16.30 | ka6sox-work | no, I'm interested in using it for one of the projects I mangle. |
| 07:17.34 | eFfeM_work | <PROTECTED> |
| 07:18.00 | eFfeM_work | and it had some cycles left |
| 07:18.18 | ka6sox-work | ya, this project I hear a lot of complaints about the autobuilder... |
| 07:18.31 | *** join/#oe dth_ntb (~dth@a89-182-5-188.net-htp.de) |
| 07:18.45 | ka6sox-work | it feels like the devs are standing in front of a microwave oven and yelling HURRY! |
| 07:19.05 | eFfeM_work | for now I can use the spare resources to do some tests for the testing branch |
| 07:19.20 | ka6sox-work | ah... |
| 07:19.56 | eFfeM_work | trying to set up some tests while my project is compiling |
| 07:20.25 | *** join/#oe ericben|away (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net) |
| 07:22.47 | *** join/#oe ron (~ron@nat/cisco/x-yyemyhpkxbugddii) |
| 07:35.47 | hrw | morning |
| 07:35.48 | hrw | http://www.youtube.com/watch?v=Eq3CuMDXaPs |
| 07:48.37 | eFfeM_work | hi hrw |
| 07:49.36 | eFfeM_work | hrw, guess you will know, can recipes have two _' s in the name ? |
| 07:50.45 | *** join/#oe methril (~methril@189.27.136.66.dynamic.adsl.gvt.net.br) |
| 07:54.58 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 07:55.25 | hrw | should not have |
| 07:55.40 | hrw | as name is parsed as PN_PV.bb |
| 07:55.58 | hrw | so it you use two _ in recipe filename you will have to set PN/PV in recipe |
| 07:56.00 | *** join/#oe otavio (~otavio@debian/developer/otavio) |
| 07:57.09 | *** join/#oe fahad (8bb5d022@gateway/web/freenode/ip.139.181.208.34) |
| 07:57.21 | fahad | hi all |
| 07:57.48 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 08:01.32 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 08:03.57 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:08.58 | *** join/#oe kristoffer (~kristoffe@c-96dde555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 08:14.22 | eFfeM_work | hrw was afk, but that was what I thougth as well |
| 08:14.23 | eFfeM_work | frans@frans-desktop:~/workspace/openembedded.git/recipes$ ls */*_*_*bb |
| 08:14.23 | eFfeM_work | clutter/clutter-box2d_0.10.0_git.bb ntpclient/ntpclient_2007_365.bb |
| 08:14.23 | eFfeM_work | ntpclient/ntpclient_2003_194.bb rpm2cpio/rpm2cpio-native_1.2_2.bb |
| 08:15.19 | eFfeM_work | ntpclient sets PV, not PN (but still uses PN) |
| 08:16.30 | eFfeM_work | rpm2cpio does not touch PV and PN |
| 08:18.18 | eFfeM_work | clutter does not seem to do anything either |
| 08:23.15 | *** join/#oe matgnt (~matthias@p4FCF18CC.dip0.t-ipconnect.de) |
| 08:25.26 | florian | good morning |
| 08:25.48 | vps | gm |
| 08:25.59 | ericben | good morning |
| 08:26.24 | ericben | eFfeM_work: hi Frans, are you using hudson for your autobuilder at work ? |
| 08:26.32 | eFfeM_work | yes |
| 08:26.47 | eFfeM_work | just started to use it |
| 08:27.08 | ericben | ok, how to you handle the fact that bitbake returns 1 even on success which makes hudson believe the build failed ? |
| 08:27.19 | eFfeM_work | not yet |
| 08:27.27 | ericben | ok :) |
| 08:27.35 | eFfeM_work | we have just recently started using it, we're still on the learning curve |
| 08:29.06 | ericben | ok, I launched one build this night and I'm first doing a bitbake -c fetchall to check all sources are ok, then a bitbake myimage. And hudson stopped everything after the fatchall (which was a success) because bitbake returne 1 |
| 08:31.20 | eFfeM_work | ericben: if you want to you can ignore the error code I guess |
| 08:31.30 | ericben | if hudson can parse the log for x failed and return error only if x > 0 this would be great |
| 08:31.44 | eFfeM_work | do something like (bitbake fetchall ; bitbake recipe) |
| 08:31.48 | ericben | eFfeM_work: yes but in that case you don't know it has failed unless you check tinderbox |
| 08:31.50 | eFfeM_work | wiht () so it is in a subshell |
| 08:31.52 | eFfeM_work | true |
| 08:32.10 | eFfeM_work | then fix bitbake :-) |
| 08:32.48 | ericben | well, considering I'm using python as an evolved shell I'm far from being abel to understand bitbake's code ;-) |
| 08:34.25 | ericben | http://wiki.hudson-ci.org/display/HUDSON/Log+Parser+Plugin may be the solution |
| 08:37.54 | eFfeM_work | ericben: that log plugin seems nice, didn't get to looking at plugins |
| 08:38.04 | eFfeM_work | (well, i did, but only a few) |
| 08:51.49 | *** join/#oe vanous1 (~vanous@194.228.223.3) |
| 08:59.55 | *** join/#oe Noor (8bb5d022@gateway/web/freenode/ip.139.181.208.34) |
| 09:00.21 | Noor | Hi all |
| 09:01.16 | Noor | is there an replacement for STAGING_BINDIR_CROSS variable just like we have bindir for STAGING_BINDIR |
| 09:02.41 | ericben | eFfeM_work: in fact bitbake return 1 because there was something marked as an error (ERROR: Multiple .bb files are due to be built which each provide virtual/psplash) but this error is not critical so the build is successful |
| 09:03.03 | eFfeM_work | ah ok, got some of these too |
| 09:03.31 | ericben | so bitbake is doing his job properly and the problem is that I didn't put a prefered provider for psplash :) |
| 09:04.07 | ericben | this kind of tool helps to improve quality, only to have the green light on the build status page :-) |
| 09:04.22 | eFfeM_work | well I tried bitbake world triggered by what khem said before, but I still get errors on unmet dependencies :-( (using dev head) |
| 09:04.45 | eFfeM_work | ericben: we have not yet much experience with it, but it looks like quite a good and useful tool |
| 09:12.36 | *** join/#oe GarthPS (~quassel@92.102.66.79) |
| 09:22.18 | eFfeM_work | Noor: no idea |
| 09:23.54 | Noor | eFfeM_work: OK |
| 09:24.36 | Noor | there is a variable bindir_cross but the value is different from STADING_BINDIR_CROSS |
| 09:25.50 | fahad | hi |
| 09:25.56 | fahad | i have one question |
| 09:26.09 | fahad | i am merging native and non-native recipes |
| 09:26.49 | fahad | the non-native recipe has its native recipe in its depends |
| 09:27.14 | fahad | and the native recipe has another recipe in its depends with += |
| 09:27.47 | fahad | how should i tackle this in the combined recipe? |
| 09:31.09 | ericben | any idea on how to fix this : ERROR: '['/home/hudson/test-oe/workspace/cpuimx25/openembedded/recipes/qt4/qt4-embedded-gles_4.6.3.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'qt4-embedded-gles' but it wasn't found in any PACKAGE or RPROVIDES variables of any buildable targets. |
| 09:32.07 | vps | fahad: I wrote a mail to you on the mailinglist |
| 09:32.32 | *** join/#oe konne (~Miranda@85.183.99.11) |
| 09:32.41 | vps | Basically you use DEPENDS_pn-glib-1.2 += "glib-1.2-native" |
| 09:33.09 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 09:33.33 | vps | So you may modify the dependencies seperately |
| 09:39.33 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 09:47.25 | CIA-2 | 03Enrico Scholz <enrico.scholz@sigma-chemnitz.de> 07org.openembedded.dev * r10a92f2524 10openembedded.git/recipes/ncurses/ (ncurses-5.7/libtermcap.so ncurses_5.7.bb): (log message trimmed) |
| 09:47.25 | CIA-2 | ncurses: use linker scripts for libncurses(w) |
| 09:47.25 | CIA-2 | Some software (e.g. util-linux-ng) assumes that symbols from -ltinfo |
| 09:47.25 | CIA-2 | will be added when it is linked against -lncurses. This breaks when |
| 09:47.25 | CIA-2 | linkerflags are containing --no-copy-dt-needed-entries which is the case |
| 09:47.26 | CIA-2 | e.g. in Fedora 13+. |
| 09:47.27 | CIA-2 | This patch replaces the libncurses.so symlink with a linkerscript which |
| 09:48.52 | CIA-2 | 03Enrico Scholz <enrico.scholz@sigma-chemnitz.de> 07org.openembedded.dev * r7fce8ef127 10openembedded.git/recipes/ncurses/ncurses_5.7.bb: |
| 09:48.52 | CIA-2 | ncurses: fixed PR |
| 09:48.52 | CIA-2 | Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de> |
| 09:48.59 | fahad | vps: thanks Vitus, i didn't know that you can use this override in this way |
| 09:49.26 | eFfeM_work | ericben: rm the recipe? this is apparently work in progress |
| 09:49.31 | vps | Just found it the other day in base.bbclass :-) |
| 09:49.32 | fahad | i will update the recipes and see how it works |
| 09:49.55 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 09:50.10 | eFfeM_work | ti/koen seems to be adding quite some stuff that requires recipes that are not committed :-( |
| 09:50.18 | eFfeM_work | eg: ERROR: '['/home/hudson/jobs/FM_world/workspace/openembedded/recipes/powervr-drivers/bc-cube_0.2.0.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'libgles-omap3-x11wsegl' but it wasn't found in any PACKAGE or RPROVIDES variables |
| 09:50.26 | ericben | eFfeM_work: I was thinking of a MACHINE_FEATURES egl ? |
| 09:51.37 | ericben | and then tuning DEFAULT_PREFERENCE depending on MACHIN_FEATURE. Do you think this is possible ? |
| 09:51.48 | ericben | koen seems to be your big firend ;-) |
| 09:51.48 | vps | fahad: sorry, it's bitbake.conf. (OVERRIDES = "local:${MACHINE}:${DISTRO}:${TARGET_OS}:${TARGET_ARCH}:build-${BUILD_OS}:fail-fast:pn-${PN}") |
| 09:52.34 | *** join/#oe CMoH|office (~cipi@89.238.251.90) |
| 09:52.55 | fahad | vps: thanks |
| 09:54.00 | eFfeM_work | ericben: i think you got some errors before (so did I) and these are the followup |
| 09:54.07 | eFfeM_work | indeed virtual/egl might play a role |
| 09:57.29 | *** join/#oe CMoH|office (~cipi@89.238.251.90) |
| 09:58.17 | ericben | eFfeM_work: is there a way to enable a recipe based on a MACHINE_FEATURES ? |
| 09:58.26 | eFfeM_work | I have no idea |
| 09:59.24 | *** join/#oe nar__ (~nar@c-76-103-154-204.hsd1.ca.comcast.net) |
| 09:59.27 | nar__ | helu |
| 10:01.37 | ericben | simple solution : only libgles-omap3.inc provides virtual/egl, but it also have a COMPATIBLE_MACHINE , so we could copy this COMPATIBLE_MACHINE to each recipe which has a DEPEND on virtual/egl ? |
| 10:02.08 | *** join/#oe dm8tbr (~dm8tbr@cl-922.sto-01.se.sixxs.net) |
| 10:05.32 | hrw | no |
| 10:05.50 | hrw | ericben: there could be out-of-tree providers of virtual/egl for other machines |
| 10:06.48 | ericben | hrw: yes. Do you know if there is a way to enalbe a recipe based on a MACHINE_FEATURE ? |
| 10:07.39 | ericben | or is there a clever solution for this problem ? |
| 10:08.42 | eFfeM_work | hrw I feel that if there is an out-of-tree provider it should be mentioned somewhere |
| 10:09.18 | eFfeM_work | i do not find it desirable to have a tree with broken dependencies which are only there for people having stuff out-of-tree that they apparently do not want to share |
| 10:11.38 | *** join/#oe likewise (~chatzilla@82-170-243-215.ip.telfort.nl) |
| 10:11.40 | nar | hmm |
| 10:13.25 | hrw | ericben: define enable |
| 10:14.10 | ericben | hrw: equivalent of COMPATIBLE_MACHINE |
| 10:14.16 | ericben | but based on a FEATURE |
| 10:15.00 | likewise | gm |
| 10:15.09 | likewise | SOC_FAMILY discussion? :-) |
| 10:15.15 | eFfeM_work | hi likewise |
| 10:15.25 | ericben | in fact in qt4-embedded-gles I think the problems comes from the fact that this recipe adds PROVIDES += "qt4-embedded" which means it will trigger the problem for each person who do bitbake qt4-embedded but hasn't an Omap3 |
| 10:15.30 | hrw | ericben: I do not see a usecase |
| 10:15.32 | likewise | hello eFfeM_work |
| 10:15.53 | likewise | hello hrw, long time no see. How's Ubuntu work? |
| 10:16.00 | ericben | hrw: ok in that case how to prevent this : ERROR: '['/home/hudson/test-oe/workspace/cpuimx25/openembedded/recipes/qt4/qt4-embedded-gles_4.6.3.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'qt4-embedded-gles' but it wasn't found in any PACKAGE or RPROVIDES variables of any buildable targets. |
| 10:16.22 | ericben | ERROR: '[]' RDEPENDS/RRECOMMENDS or otherwise requires the runtime entity 'virtual/egl' but it wasn't found in any PACKAGE or RPROVIDES variables |
| 10:17.46 | hrw | likewise: fine, bootstrapped their toolchain finally |
| 10:18.20 | hrw | let me pull |
| 10:18.51 | pb_ | ericben: I guess that should be fixed in bitbake. It ought to just ignore the unbuildable PROVIDEr. |
| 10:19.32 | eFfeM_work | likewise: i see a use for SOC_FAMILY but COMPATIBLE_MACHINE could be used there as well afaik |
| 10:19.48 | eFfeM_work | and the way it was added is not an example on how things should be done |
| 10:19.55 | eFfeM_work | but it should work for all, and not only for TI |
| 10:42.40 | *** join/#oe GNUtoo|laptop (~gnutoo@host55-144-dynamic.54-79-r.retail.telecomitalia.it) |
| 10:56.40 | *** join/#oe B_Lizzard (~havoc@athedsl-428632.home.otenet.gr) |
| 10:58.57 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 11:03.38 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 11:07.40 | ericben | pb_: ok I'll submit a patch for a temporary fix for OE as I'm not enough skilled for hacking bitbake. |
| 11:08.03 | pb_ | righto |
| 11:08.41 | Crofton | ok, let's see in ncurses behaves better today |
| 11:12.07 | Jin^eLD | what's the procedure of submitting patches? I looked through the OE wiki but I guess I missed it |
| 11:12.26 | pb_ | generate a patch, send it to the mailing list |
| 11:12.27 | *** part/#oe orjanf (~onfg@h51baff8c.k3918.sta.perspektivbredband.net) |
| 11:12.54 | ericben | Jin^eLD: git format-patch then git send-email --to openembedded-devel@lists.openembedded.org |
| 11:12.54 | Jin^eLD | pb_: any special topic [bla] tags or guidelines or something? |
| 11:13.55 | ericben | http://wiki.openembedded.net/index.php/Commit_log_example http://wiki.openembedded.net/index.php/Styleguide |
| 11:14.08 | ericben | and more generaly : http://wiki.openembedded.net/index.php/Category:Policy |
| 11:14.08 | eFfeM_work | Jin^eLD: git send-email will use the first line of the patch as subject |
| 11:14.20 | Jin^eLD | ok thanks |
| 11:14.44 | eFfeM_work | especially http://wiki.openembedded.net/index.php/Commit_Policy |
| 11:16.37 | florian | Why does kernel.bbclass set CC and LD in the compile command instead of setting CROSS_COMPILE? |
| 11:16.42 | eFfeM_work | Jin^eLD: you're welcome |
| 11:17.16 | pb_ | florian: mostly so that KERNEL_CCSUFFIX works, I think |
| 11:17.29 | pb_ | (It does set CROSS_COMPILE as well, iirc.) |
| 11:19.21 | *** join/#oe EiNSTeiN_ (~einstein@unaffiliated/einstein/x-615171) |
| 11:19.43 | florian | I just ran into a kernel that fails because it fails to find the correct ar. |
| 11:21.26 | Crofton_|work | damn util-linux-ng is still failing |
| 11:22.21 | *** join/#oe EiNSTeiN_ (~einstein@unaffiliated/einstein/x-615171) |
| 11:23.15 | Crofton_|work | trying to clean ncurses now ... |
| 11:23.21 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
| 11:27.17 | Crofton_|work | trying to clean ncurses now ... |
| 11:32.07 | Crofton_|work | that doesn't work either |
| 11:45.42 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 12:04.01 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
| 12:20.50 | Noor | is it possible in new style staging that something is being staged but nt deplyed for non-native packages |
| 12:22.24 | *** join/#oe chase (~chase@nat/ti/x-uhmnqkrxdqyukslt) |
| 12:30.18 | Crofton_|work | is enrico around/ |
| 12:40.14 | emjayb | anyone has an idea on how to use base_conditional to return a value containing a variable? like @base_conditional("FOO", "a", "VAR", d) where VAR='b' |
| 12:43.17 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 12:57.19 | likewise | Noor: good question |
| 12:58.09 | florian | pb_: you are right, on top of kernel.bbclass CROSS_COMPILE gets set... |
| 12:58.36 | florian | But I do not see why it doesn't seem to be defined any more later. |
| 12:59.23 | florian | hi Jin^eLD |
| 12:59.44 | Jin^eLD | hi florian |
| 13:06.06 | Noor | likewise: I was converting llvm2.7 recipe to new style staging |
| 13:07.25 | Noor | I observed this behavior in that recipe it is staging some file which are in deply folder |
| 13:08.27 | Noor | and when I add it in image filder using ${D} I get some errors "ERROR: QA Issue with llvm2.7-dev: package llvm2.7-dev contains bad RPATH /home/nahsan/SB/open_comm/tmp/work/armv7a-angstrom-linux-gnueabi/llvm2.7-2.7-r1.r8/llvm-2.7/build/lib in file /home/nahsan/SB/open_comm/tmp/work/armv7a-angstrom-linux-gnueabi/llvm2.7-2.7-r1.r8/packages-split/llvm2.7-dev/usr/bin/llvm2.7/tblgen" |
| 13:08.44 | Noor | in do_package task |
| 13:10.33 | *** join/#oe mickey|office (~Mickey@business-092-079-168-007.static.arcor-ip.net) |
| 13:11.28 | *** join/#oe mickey|office (~Mickey@openmoko/coreteam/mickey) |
| 13:12.35 | *** join/#oe hansdampf (~moritz@212.77.183.87) |
| 13:22.29 | *** join/#oe koobe_ (~koobe@dsl-trebrasgw2-fe4df900-31.dhcp.inet.fi) |
| 13:30.37 | likewise | Noor: An RPATH may not refer to the tmp/work directory AFAIK, so you are packaging files from the wrong location. (I am not the packaging expert here, this is semi-guessing.) |
| 13:37.44 | *** join/#oe kevinsc (~a0214685@nat/ti/x-yavcyokfnbgearxz) |
| 13:44.00 | *** join/#oe dos1 (~dos@etc223.neoplus.adsl.tpnet.pl) |
| 13:44.08 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 13:50.32 | Tartarus | kicks openjade-native |
| 13:50.58 | Tartarus | khem: ping |
| 13:51.01 | *** join/#oe celeron55 (~perttu@a91-155-42-12.elisa-laajakaista.fi) |
| 14:01.44 | *** join/#oe kgilmer (~kgilmer@firebug.buglabs.net) |
| 14:07.35 | *** join/#oe Spz0 (~a@97-120-153-16.ptld.qwest.net) |
| 14:11.43 | *** join/#oe aditya_1010 (~Aditya@pool-96-241-213-103.washdc.fios.verizon.net) |
| 14:14.23 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 14:15.04 | *** join/#oe aditya_10101 (~Aditya@pool-96-241-213-103.washdc.fios.verizon.net) |
| 14:17.06 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 14:19.28 | *** join/#oe aditya_1010 (~Aditya@pool-96-241-213-103.washdc.fios.verizon.net) |
| 14:25.22 | *** join/#oe kevinsc1 (~a0214685@nat/ti/x-fvnakanaatrqetrj) |
| 14:27.19 | Crofton | ensc, ping |
| 14:37.07 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 14:41.52 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 14:42.19 | *** join/#oe jkridner (~jason@pdpc/supporter/active/jkridner) |
| 14:44.58 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 14:52.31 | khem | eFfeM_work: what all are unmet dependencies you get |
| 14:53.08 | *** part/#oe mike_s (~kvirc@213.218.221.154) |
| 14:53.15 | *** join/#oe mike_s (~kvirc@213.218.221.154) |
| 14:53.23 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 14:57.23 | ensc|w | Crofton: pong |
| 14:57.48 | Crofton | ensc, the problem went away :) |
| 14:57.53 | ensc|w | ok, good |
| 14:58.07 | anarsoul | hi there |
| 14:58.13 | Crofton | we thought the fix might break an ubuntu build |
| 14:58.21 | anarsoul | I'm getting gettext-native build failure, here's build log: http://pastebin.com/AAQLtAR3 |
| 14:58.26 | Crofton | but cleaning all ncurses fixed it |
| 14:58.36 | anarsoul | is it known issue or something new? |
| 14:59.01 | ensc|w | Crofton: yes; staging fails to convert the symlink into a regular file |
| 14:59.03 | khem | hi Tartarus |
| 15:00.00 | Tartarus | hey khem |
| 15:00.00 | Crofton | ensc|w, thanks for figuring out the solution |
| 15:00.07 | Tartarus | Do you have openjade-native in your ASSUME_PROVIDED? |
| 15:01.19 | khem | I dont think so |
| 15:01.27 | Tartarus | ok |
| 15:01.37 | khem | are you seeing xalan-j fail ? |
| 15:01.51 | Tartarus | no, i got a crazy mangle in one of the openjade-native's Makefiles |
| 15:01.59 | Tartarus | I think it's just bad luck... |
| 15:02.07 | khem | yeah could be |
| 15:02.44 | khem | actually xalan-j when building from scratch does not build |
| 15:02.52 | khem | it has some goody DEPENDS problem |
| 15:03.15 | khem | it builds in a bunch becuase someone elese stages it before xalan-j needs it |
| 15:03.36 | khem | anarsoul: its a problem on your build machine |
| 15:04.21 | *** join/#oe mnabil_ (~mnabil@41.234.70.110) |
| 15:04.35 | anarsoul | khem: hm, how to solve it? |
| 15:05.16 | anarsoul | will run revdep-rebuild, but doubts that it will found something |
| 15:05.28 | khem | anarsoul: Dont know see your distro mailing lists |
| 15:05.36 | khem | seems buggy zlib |
| 15:05.58 | anarsoul | it's zlib-1.2.5 |
| 15:05.59 | khem | anarsoul: if you have ASSUME_PROVIDED then dont use them |
| 15:06.13 | anarsoul | I don't use ASSUME_PROVIDED |
| 15:06.14 | khem | 1.2.5 should have fixed it |
| 15:10.21 | anarsoul | khem: libxml and zlib are OK on my build machine |
| 15:11.28 | anarsoul | and revdep-rebuild (gentoo tool to find binaries and libraries broken by a package update) found no problems |
| 15:12.29 | florian | pb_: found it... OE isn't guilty. Its an evil modification of the Makefile |
| 15:19.55 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 15:31.39 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 15:44.15 | anarsoul | khem: so, should I file a bug about this build failure? |
| 15:47.04 | khem | florian: some stuff gpephone related is not fetchable anymore |
| 15:48.30 | khem | /recipes/gpephone/libiac_svn.bb, do_fetch) failed with 256 |
| 15:49.46 | khem | anarsoul: you can add -lz to LDFLAGS of gettext-native as workaround |
| 15:49.56 | khem | may be that will help |
| 15:50.26 | *** join/#oe rednul_ (~rednul@host-174-45-250-246.bln-mt.client.bresnan.net) |
| 15:50.36 | khem | oh its already there |
| 15:52.11 | khem | florian: also this one recipes/gpephone/libgpephone_svn.bb, do_fetch) failed with 256 |
| 15:52.55 | khem | it seems all gpephone svn recipes dont fetch anymore. is the svn server decommissioned ? |
| 15:53.37 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
| 15:56.34 | anarsoul | khem: I suspect it happens because oe tries to link with some system libraries, not built by oe |
| 15:56.48 | Tartarus | khem: run-qemu.sh, what does that assume on the host, anything? |
| 15:57.12 | Tartarus | Going to quick test some of these native-sdk-images once it's done |
| 15:57.29 | ericben | anyone can confirm that usr/lib/python2.6/config can be removed from python-distutils ? |
| 15:58.49 | mickey|office | hmm |
| 15:58.58 | mickey|office | i don't think so |
| 15:59.16 | mickey|office | iirc distutils needs the config otherwise can no longer compile extension modules |
| 15:59.43 | mickey|office | i could be wrong though, it's been ages since i looked at that stuff |
| 15:59.48 | ericben | on ubuntu there is only : Makefile and a link to libpython2.6.so.1 |
| 16:00.18 | khem | Tartarus: it needs bridge-utils |
| 16:00.25 | khem | installed and setup |
| 16:00.36 | khem | if you want qemu to boot with networking |
| 16:00.37 | ericben | ok in doubt, I let it, I just remove the win* files from distutils and the big libpython2.6.a from the coinfig directoy. In the end I get a ~400kB packages which is far better than before |
| 16:00.45 | khem | <PROTECTED> |
| 16:00.46 | khem | svn: Can't open file '/svn/gpephone/trunk/format': Permission denied |
| 16:01.08 | ericben | thanks mickey|office updated patch will follow for ack on the ml |
| 16:01.12 | florian | khem: hrm nasty... no the server is still there but maybe some things changed moving it to fusionforge |
| 16:01.14 | Tartarus | khem, k, thanks |
| 16:01.14 | mickey|office | ericben: cool, thanks |
| 16:01.38 | khem | Tartarus: read thru the file I have tried to document what one would need |
| 16:01.46 | florian | khem: since noone is working on it i'm tempted to move the whole gpephone stuff to obsolete |
| 16:01.48 | ericben | btw, to remove the files, I added a do_install_append which does rm the files. Is this the right way to do it ? |
| 16:01.48 | khem | Tartarus: it still might have some cruft |
| 16:01.56 | khem | florian: most welcome |
| 16:02.40 | khem | you being gpephone developer have the say :) |
| 16:03.38 | florian | just being realistic... would be fine with me. if you don't do it i'll do it in a free minute |
| 16:04.05 | mickey|office | ericben: well, it's probably more maintainable than patching configure.ac, so i'd say yes |
| 16:04.13 | *** join/#oe awozniak (~awozniak@adsl-76-205-222-173.dsl.snlo01.sbcglobal.net) |
| 16:04.24 | khem | florian: should the whole directory be moved to obsolete |
| 16:06.06 | florian | khem: yes |
| 16:06.09 | hrw | can someone do 'git rm -r obsolete nonworking' instead? |
| 16:06.37 | florian | hmm no, I wouldn't do this |
| 16:07.21 | khem | florian: ok. will do |
| 16:07.32 | khem | and settle it in |
| 16:14.45 | *** join/#oe matgnt (~matthias@p4FCF18CC.dip0.t-ipconnect.de) |
| 16:16.21 | *** join/#oe CosmicPenguin (~nobody@rrcs-67-52-130-30.west.biz.rr.com) |
| 16:19.54 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 16:22.06 | *** join/#oe GarthPS (~quassel@92.102.66.79) |
| 16:32.02 | *** join/#oe GNUtoo|laptop (~gnutoo@host55-144-dynamic.54-79-r.retail.telecomitalia.it) |
| 16:49.16 | *** join/#oe chouimat (~mathieu@CPE002129b5a060-CM0011e6c40c15.cpe.net.cable.rogers.com) |
| 16:49.16 | *** join/#oe chouimat (~mathieu@kde/developer/chouinard) |
| 16:56.14 | GNUtoo|laptop | hmmm, what's that: |
| 16:56.16 | GNUtoo|laptop | *** %n in writable segment detected *** |
| 16:57.46 | *** join/#oe kays (~kays@188.3.18.222) |
| 16:59.11 | ensc|w | GNUtoo|laptop: printf has a writable msg string which contains %n |
| 16:59.31 | ensc|w | e.g. 'char buf[] = "%n"; printf(buf, &n);' |
| 16:59.36 | GNUtoo|laptop | ah? |
| 16:59.44 | GNUtoo|laptop | ok |
| 17:00.03 | GNUtoo|laptop | is it problematic? |
| 17:00.12 | ensc|w | it's a security issue |
| 17:00.18 | GNUtoo|laptop | ah ok |
| 17:00.48 | ensc|w | you can workaround it (when buffer must be rw) by remapping it read-only after filling it with content |
| 17:01.14 | GNUtoo|laptop | ok but I dont' even know which package emited that during the build |
| 17:01.24 | GNUtoo|laptop | the target is armv7 |
| 17:03.26 | ensc|w | it might be emitted by a native tool; I am not sure whether -D_FORTIFY has such a check or whether it is done at runtime only |
| 17:04.10 | GNUtoo|laptop | ok |
| 17:04.23 | GNUtoo|laptop | so the security issue is in the native tool and not on target? |
| 17:04.58 | ensc|w | yes |
| 17:05.05 | CIA-2 | 03Peter Klassen <pklassen@web.de> 07org.openembedded.dev * r944bbfa83f 10openembedded.git/recipes/xorg-xserver/xserver-xorg-conf_0.1.bb: |
| 17:05.05 | CIA-2 | xserver-xorg-conf: add xorg.conf for palmpre machine |
| 17:05.05 | CIA-2 | Signed-off-by: Peter Klassen <pklassen@web.de> |
| 17:05.05 | CIA-2 | Acked-by: Simon Busch <morphis@gravedo.de> |
| 17:05.33 | GNUtoo|laptop | ok thanks a lot |
| 17:05.36 | CIA-2 | 03Simon Busch <morphis@gravedo.de> 07org.openembedded.dev * rfef2ddd336 10openembedded.git/recipes/xorg-xserver/xserver-xorg-conf_0.1.bb: |
| 17:05.36 | CIA-2 | Revert "xserver-xorg-conf: add xorg.conf for palmpre machine" |
| 17:05.36 | CIA-2 | This reverts commit 944bbfa83fedd417eb87daefd5f94ac8eb524a0a. |
| 17:06.30 | GNUtoo|laptop | ouch |
| 17:06.33 | GNUtoo|laptop | I'll talk to morphis |
| 17:10.12 | kays | Hello all, I am new at openembedded and I want to create my own image with my selected packages only. Is there any howto which defines creating a new distro and building a new image? |
| 17:10.25 | GNUtoo|laptop | 2 solutions: |
| 17:10.32 | GNUtoo|laptop | look at existing images and modify it |
| 17:10.36 | GNUtoo|laptop | or look at the manual |
| 17:12.09 | kays | manual says just copy the existing distro conf and do changes, then use it. but what kind of changes? |
| 17:12.46 | kays | I think there should be a howto which shows the relationships between configs directories. |
| 17:13.09 | kays | I couldnt see the big picture, just travelling in files and directories. |
| 17:13.23 | kays | What is going on when I enter "bitbake anything".. |
| 17:13.55 | kays | People says openembedded is the best but nobody direct me to see the best features :) |
| 17:15.47 | CIA-2 | 03Peter Klassen <pklassen@web.de> 07org.openembedded.dev * rf641c14f2d 10openembedded.git/recipes/xorg-xserver/ (xserver-xorg-conf/palmpre/xorg.conf xserver-xorg-conf_0.1.bb): |
| 17:15.47 | CIA-2 | xserver-xorg-conf: add xorg.conf for palmpre machine |
| 17:15.47 | CIA-2 | Signed-off-by: Peter Klassen <pklassen@web.de> |
| 17:15.47 | CIA-2 | Acked-by: Simon Busch <morphis@gravedo.de> |
| 17:18.22 | *** join/#oe svolpe (~Gerrath@unaffiliated/gerrath) |
| 17:19.24 | *** join/#oe mickeyl (~mickey@80.81.242.146) |
| 17:21.23 | *** join/#oe hansdampf (~moritz@212.77.183.87) |
| 17:23.09 | khem | kays: see under images |
| 17:23.20 | khem | kays: those are final images it can build |
| 17:23.27 | khem | then see under conf/distro |
| 17:23.33 | khem | those are distros it supports |
| 17:23.39 | khem | then see under conf/machine |
| 17:23.49 | khem | those are machines which can be used |
| 17:24.03 | *** join/#oe eFfeM (~frans@j200125.upc-j.chello.nl) |
| 17:27.29 | *** join/#oe chouimat (~mathieu@CPE002129b5a060-CM0011e6c40c15.cpe.net.cable.rogers.com) |
| 17:27.29 | *** join/#oe chouimat (~mathieu@kde/developer/chouinard) |
| 17:28.43 | *** join/#oe chouimat (~mathieu@kde/developer/chouinard) |
| 17:33.15 | kays | images, distros and machines are can be called by bitbake directly? In wiki examples just machines are called directly. |
| 17:34.18 | kergoth_ | what do you mean by "called"? |
| 17:34.34 | kergoth_ | a machine is just a variable. the MACHINE variable is set to a value, and bitbake.conf includes conf/machine/${MACHINE}.conf |
| 17:36.53 | kays | ok I got it |
| 17:37.20 | *** join/#oe celeron55_ (~perttu@a91-155-42-12.elisa-laajakaista.fi) |
| 17:37.21 | kays | debug messages show some usefull messages |
| 17:37.23 | kergoth_ | if you mean what you specify on the bitbake commandline, you specify a provider -- a recipe, basically, though recipes can PROVIDES multiple things |
| 17:37.39 | kergoth_ | MACHINE and DISTRO are just ways to break up the metadata in a logical way |
| 17:37.43 | kergoth_ | so that things are orthagonal |
| 17:38.04 | kergoth_ | distro controls policy, machine controls the hardware you're targeting, and both are generally independent of the recipes themselves |
| 17:38.33 | kergoth_ | this is why just about any DISTRO can support any MACHINE, and the recipes generally support any combination of those |
| 17:38.38 | kergoth_ | (within limits, of course) |
| 17:38.55 | kays | hm yes, thanks |
| 17:39.15 | kays | It is working now |
| 17:39.23 | kergoth_ | I realize we're really lacking some good high level conceptual documentation |
| 17:39.40 | kergoth_ | the user manual is well and good, but its more reference material with a bit of tutorialish stuff, not much architectural |
| 17:39.58 | kays | I agree |
| 17:40.24 | kergoth_ | i'd love to see that change, but my writing is pretty weak personally. ideall we'd have some technical writers contributing to the project |
| 17:40.30 | kergoth_ | open source projects tend to emphasize the code too much |
| 17:40.38 | kergoth_ | not enough support is given to those wanting to contribute in other ways |
| 17:41.09 | koobe_ | what kind of policy does the distro control? |
| 17:41.15 | kergoth_ | http://free-electrons.com/pub/video/2010/elc/elc2010-osier-mixon-documentation.ogv is apt |
| 17:42.06 | kergoth_ | koobe_, well, it's convention. from a technical standpoint its just an other variable, associated config file, and entry in OVERRIDES (which allows conditional variable definitions or modifications based on the distro, and distro specific config files) |
| 17:42.07 | *** join/#oe tzanger_ (~tzanger@gromit.mixdown.ca) |
| 17:42.13 | *** join/#oe betheg_ (unkown@unaffiliated/betheg) |
| 17:42.18 | *** join/#oe nar__ (~nar@c-76-103-154-204.hsd1.ca.comcast.net) |
| 17:42.50 | kergoth_ | in reality it tends to control things like target filesystem layout, packaging method used, as well as high level features (see the DISTRO_FEATURES variable) like ipv6 |
| 17:44.03 | kergoth_ | if you think about it like traditional linux distros, the distribution controls layout, packaging, as well as "distributionisms" -- things like, say, /etc/network/interfaces vs /etc/sysconfig/, chkconfig vs update-rc.d, etc |
| 17:44.18 | kergoth_ | of course, today, pretty much every oe based distro uses the same debian-like distributionisms, but that doesn't have to be the case |
| 17:44.33 | koobe_ | does it pin down any versions of the packages/recipes? |
| 17:44.45 | kergoth_ | yeah, distro usually does that too |
| 17:44.54 | kergoth_ | as well as preferences for providers |
| 17:44.59 | kergoth_ | e.g. uclibc vs glibc vs eglibc |
| 17:45.40 | koobe_ | is it feasible to fork or inherit a distribution, to customize some of the things you described, without having to specify them all? |
| 17:45.47 | kergoth_ | yeah, absolutely |
| 17:45.50 | kergoth_ | well, sort of |
| 17:46.00 | kergoth_ | you could create your own distro config file that includes angstroms, for example |
| 17:46.10 | kergoth_ | but the difficulty lies in the previously mentioned conditional variable definitions in the metadata |
| 17:46.18 | kergoth_ | if some recipe does FOO_angstrom = "bar" |
| 17:46.22 | koobe_ | how about the overrides, they'd be for angstrom only? |
| 17:46.24 | kergoth_ | and you arenj't named angstrom, you won't pick that up |
| 17:46.25 | kergoth_ | right |
| 17:46.26 | kergoth_ | exactly |
| 17:46.40 | kergoth_ | downside to having machine and distro specific things in recipes |
| 17:46.51 | *** join/#oe hansdampf (~moritz@212.77.183.87) |
| 17:47.09 | koobe_ | can you arbitrarily specify any overrides, could I force the angstrom overrides to be used in addition to those of my 'fork'? |
| 17:47.20 | kergoth_ | sort of, yeah |
| 17:47.30 | kergoth_ | what you could do is add/inject "angstrom" directly into OVERRIDES |
| 17:47.36 | kergoth_ | even though your distro is still there. |
| 17:47.41 | kergoth_ | ideally in the correct order so yours are preferred to theirs |
| 17:47.59 | kergoth_ | i find it helps to visualize this stuff if you think of it as a layering mechanism for the metadata |
| 17:48.09 | kergoth_ | implemented in two ways: order of config file inclusion, and overrides application |
| 17:48.20 | kergoth_ | its designed such that more specific information always overrides less specific information |
| 17:48.36 | kergoth_ | so the machine version of a varaible always overrides the target architecture version, which in turn overrides the global default |
| 17:50.00 | kays | good explanations, thanks kergoth_ |
| 17:50.05 | kergoth_ | np |
| 17:50.18 | koobe_ | ok, it definitely helps to understand that even the distro doesn't do any magic but builts on top of the same mechanism as the other settings. |
| 17:50.29 | koobe_ | thanks for the clarifications |
| 17:50.32 | kergoth_ | np |
| 17:51.07 | kergoth_ | i keep meaning to try writing up some architectural documentation, based upon the original design we put together when the project was started |
| 17:51.15 | kergoth_ | so people can see why it went in the direction it did |
| 17:53.44 | kays | It will be really helpful, all configs and bb files scare new users :) |
| 17:55.24 | kergoth_ | it was one of the primary goals to create the collaborative repository of metadata that we have today -- ensuring that people with entirely different target hardware and goals could collaborate and share improvements, rather than just having a common starting point (as you would if you, say, copied buildroot as a starting point and ran with it) |
| 17:58.05 | koobe_ | the thing I like most are the orthogonality of recipes and targets, and the fact that the external dependencies are minimal, resulting in repeatability of builds. |
| 17:58.17 | *** join/#oe hansdampf (~moritz@212.77.183.87) |
| 17:58.58 | kergoth_ | that's actually one of the biggest problems with oe quality today. external dependencies are minimal, but it can still bite us in the ass. nature of crosscompilation and autoconf. if we miss something in one of them, it'll just happily run off and do somethin gbased on the existance of a file on the build machine |
| 17:59.00 | kergoth_ | pain in the ass |
| 18:00.51 | Crofton | if it was easy, OE wouldn't exist |
| 18:01.05 | kergoth_ | well said |
| 18:05.26 | *** join/#oe toi (~toi@d54C2AA76.access.telenet.be) |
| 18:06.23 | CIA-2 | 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * r8cfa7531a0 10openembedded.git/ (8 files in 3 dirs): |
| 18:06.24 | CIA-2 | Per the TSC decision, make packaged-staging default |
| 18:06.24 | CIA-2 | For now, just ensures its inherited. In the future, we can merge / simplify |
| 18:06.24 | CIA-2 | staging.bbclass with packaged-staging.bbclass as appropriate. |
| 18:06.24 | CIA-2 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 18:06.47 | khem | kergoth_: I have issue with packages staging |
| 18:06.54 | khem | it does not go well with staging_qa |
| 18:07.02 | khem | when using rm_work |
| 18:07.07 | Tartarus | khem: how so? |
| 18:07.11 | kergoth_ | i'm using all 3 of those right now |
| 18:07.14 | khem | when I restart unfinished job |
| 18:07.24 | khem | it tries to run and exits randomly |
| 18:07.29 | khem | with error 256 |
| 18:07.44 | khem | I use rm_work |
| 18:07.57 | khem | staging_qa |
| 18:08.15 | khem | and then it starts using pstaging |
| 18:08.21 | khem | fine |
| 18:08.36 | khem | but dies on one of staging_qa on any recipe |
| 18:08.52 | khem | then I run qa_staging for that recipe individually works |
| 18:09.05 | nar_ | Hmm |
| 18:09.08 | khem | and its always the case |
| 18:09.15 | khem | but it dies on random recipe |
| 18:09.55 | khem | plus those huge messages about using staging package bla bla are ugly too |
| 18:10.35 | kergoth_ | you'd rather sit in ignorance, not knowing if it used a pstage package or not? |
| 18:10.52 | khem | no I would infact like to know |
| 18:10.58 | khem | but not all packages on one line |
| 18:11.06 | Tartarus | What message do you mean then? |
| 18:11.15 | khem | ah I pasted it |
| 18:11.17 | kergoth_ | it doesn't show all packages on one line |
| 18:11.21 | khem | couple of days ago |
| 18:11.23 | kergoth_ | it says its using this ipk |
| 18:11.24 | kergoth_ | that's it |
| 18:11.44 | khem | lemme dig the pastebin |
| 18:11.53 | khem | kergoth_: I asked you about it remember and you said you dont know |
| 18:12.01 | khem | it went away when I disabled pstage |
| 18:12.05 | kergoth_ | so open a bug |
| 18:12.09 | kergoth_ | clearly its not by design |
| 18:17.16 | *** join/#oe anarsoul (~anarsoul@80.249.95.150) |
| 18:17.17 | khem | I cant find that pastebin now |
| 18:17.48 | Tartarus | There's one print that can get long |
| 18:17.52 | Tartarus | But it's long intentionally |
| 18:18.22 | *** join/#oe stefan_schmidt (~stefan@p5B03367E.dip.t-dialin.net) |
| 18:18.34 | Tartarus | Or did I not push that change up? heh |
| 18:19.18 | Tartarus | yeah, heh, oops |
| 18:19.29 | Tartarus | I suspect you're talking about bb.note("Staging package found, using it for %s." % file) |
| 18:19.35 | khem | Yes |
| 18:19.39 | Tartarus | But I need to change that to bb.note("Staging package found, using %s for %s." % (stagepkg, file)) |
| 18:19.43 | khem | and it lists all the packages in one line |
| 18:19.50 | Tartarus | Ah, no |
| 18:19.57 | Tartarus | You're confusing some other output from pstaging |
| 18:20.07 | khem | could be |
| 18:20.14 | khem | I have disabled it now |
| 18:20.18 | kergoth_ | his message had no NOTE: on it, iirc |
| 18:20.19 | Tartarus | stagemanager-ipkg and co is not quiet |
| 18:20.24 | kergoth_ | it was from the stagemanager |
| 18:20.25 | kergoth_ | yeah |
| 18:20.26 | khem | anyway I build from scratch for most of time |
| 18:20.30 | khem | so pstaging is not for me |
| 18:20.30 | kergoth_ | those should be shut up a bit |
| 18:20.36 | kergoth_ | uh? |
| 18:20.41 | kergoth_ | no, that's not the only benefit of it |
| 18:21.00 | *** join/#oe hansdampf (~moritz@212.77.183.87) |
| 18:21.00 | kergoth_ | and it's already been decided at the TSC to be mandatory |
| 18:21.05 | kergoth_ | so if you want to hack something locally, feel free |
| 18:21.21 | khem | kergoth_: thats fine I am not objecting to the change |
| 18:21.37 | kergoth_ | if you want clean to work right, you should be using pstage |
| 18:22.34 | kergoth_ | grumbles |
| 18:23.24 | kergoth_ | khem, can always just touch classes/packaged-staging.bbclass in your build dir. |
| 18:26.25 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 18:26.37 | florian | re |
| 18:34.33 | khem | Tartarus: kergoth_ this is the output I was referrring to |
| 18:34.35 | khem | http://pastebin.com/6SBcSgVy |
| 18:35.05 | khem | pastebin shows lines but infact its single line |
| 18:35.12 | khem | and I see this happening a lot |
| 18:35.28 | *** join/#oe sicu (~sicu@ti0090a380-dhcp0332.bb.online.no) |
| 18:35.29 | khem | when I restart a build which stopped in middle due to an error or something |
| 18:35.52 | Tartarus | So, OK.. |
| 18:36.15 | khem | I couldnt figure out who is spewing those messages |
| 18:36.27 | Tartarus | Did you do a -c clean somewhere? |
| 18:36.28 | khem | it seemed pretty useless info to me |
| 18:36.33 | Tartarus | THat's PSTAGE_LIST_CMD |
| 18:36.59 | khem | may be we should only show it with verbose build |
| 18:37.30 | khem | I did do clean and saw it |
| 18:37.36 | khem | ad also without clean |
| 18:37.38 | *** join/#oe hansdampf (~moritz@212.77.183.87) |
| 18:37.58 | khem | I could have taken it but staging_qa fails were so annoying |
| 18:38.34 | khem | I think staging_qa info is not stored inside stage ipk |
| 18:38.45 | Tartarus | Yes, that's possible |
| 18:39.00 | khem | and that is run mixes |
| 18:39.11 | Tartarus | It sounds like staging_qa needs to be fixed up to ensure it happens inside of the pstaging covered window |
| 18:39.20 | khem | right |
| 18:41.55 | Tartarus | Ah, hmm |
| 18:42.25 | Tartarus | classes/insane.bbclass:addtask qa_staging after do_populate_sysroot before do_build |
| 18:42.50 | Tartarus | That needs to be .... before do_package_stage |
| 18:42.59 | Tartarus | now that it's default we can make these changes, yay |
| 18:43.14 | Tartarus | sound right kergoth_? |
| 18:43.41 | kergoth_ | yeah, sounds right to me |
| 18:43.46 | khem | yes to me as well |
| 18:44.28 | khem | what if someone disable pstage |
| 18:44.28 | Tartarus | best if someone else pushes it, i've been bad and forgot to start a local branch for all this libtool crap :) |
| 18:44.29 | Tartarus | khem, yes, don't do that :) It's mandatory now. |
| 18:45.28 | khem | Tartarus: hmm iron fist |
| 18:45.48 | khem | many people may not like it that way |
| 18:46.02 | Tartarus | Yes, and that's why there's a TSC |
| 18:46.14 | khem | heh |
| 18:46.28 | Tartarus | I'm very serious |
| 18:46.28 | khem | kergoth_: would you push it ? |
| 18:46.35 | khem | you have 2 acks |
| 18:46.45 | kergoth_ | doing so now |
| 18:46.53 | Tartarus | we have a TSC so this isn't arbitrary changes, it's technical steering of the project |
| 18:46.57 | khem | Tartarus: how about stopping that loooong line spew |
| 18:47.28 | Tartarus | khem, yes, we need to figure out why that's leaking |
| 18:47.32 | CIA-2 | 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * r8cbafd29ff 10openembedded.git/classes/insane.bbclass: |
| 18:47.32 | CIA-2 | insane.bbclass: run qa_staging before do_package_stage, rather than do_build |
| 18:47.32 | CIA-2 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 18:47.48 | Tartarus | ret = os.system("PATH=\"%s\" %s | grep %s" % (path, list_cmd, pkgname)) |
| 18:47.50 | Tartarus | is how it's used |
| 18:48.04 | Tartarus | opkg spewing to stderr too? |
| 18:49.27 | khem | I dont know |
| 18:49.38 | khem | ret = os.system("PATH=\"%s\" %s | grep %s" % (path, list_cmd, pkgname)) |
| 18:49.41 | khem | hmmm |
| 18:49.47 | kergoth_ | should stop using os.system, make it use oe_popen instead, swallow the output |
| 18:49.55 | khem | right |
| 18:50.07 | Tartarus | Lots of os.system in pstaging |
| 18:50.13 | Tartarus | Wanna go translate 'em over now? :) |
| 18:50.46 | khem | kergoth_: yes good idea |
| 18:50.49 | khem | while you are at it |
| 18:50.55 | kergoth_ | in reality, i think stdout/stderr from python tasks should just be swallowed in recent bitbake. python tasks can use bb.msg or logging to send messages to the UI thread |
| 18:50.56 | khem | I can then start using it |
| 18:51.02 | khem | and see if something more is needed |
| 18:51.05 | kergoth_ | any other output should be made explicit |
| 18:51.34 | khem | kergoth_: this message is from bb of 7th September |
| 18:51.49 | kergoth_ | i'm talking about what should be done, not what is done :P |
| 18:51.58 | khem | heh ok |
| 18:52.09 | *** join/#oe hansdampf (~moritz@212.77.183.87) |
| 19:02.27 | *** join/#oe hansdampf (~moritz@212.77.183.87) |
| 19:05.27 | kergoth_ | tests a fix |
| 19:06.40 | kergoth_ | khem, right now master captures and stores the output of a python task in a log file, and displays the log file when it fails |
| 19:06.49 | kergoth_ | but the python task *also* sends its output to the ui directly |
| 19:06.55 | kergoth_ | so you end up seeing tracebacks twice |
| 19:06.56 | kergoth_ | :| |
| 19:07.06 | khem | right I was seeing that |
| 19:07.35 | kergoth_ | this is why i think it should just silence the stdout/stderr from python tasks |
| 19:07.48 | kergoth_ | if we want to add logging of the output, we can use the logging module to do that now, in exec_func_python |
| 19:07.52 | kergoth_ | heh |
| 19:08.35 | *** join/#oe hansdampf (~moritz@212.77.183.87) |
| 19:10.27 | kergoth_ | hmm, i wonder |
| 19:11.27 | eFfeM | khem how,s your bitbake world going? I started one on our autobuilder, it is at task 5800 or 72000 or so; used -k though so not sure what exactly I missed (but it will tell me after the weekend or so when it is finished |
| 19:12.12 | eFfeM | ka6sox if you're there: |
| 19:12.15 | eFfeM | NOTE: package binutils-2.20.1-r10.1: task do_rm_work_all: Succeeded NOTE: Tasks Summary: Attempted 557 tasks of which 478 didn't need to be rerun and 0 failed |
| 19:12.32 | eFfeM | will try be too can also try a different package if you want me to |
| 19:14.02 | CIA-2 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r3e7bc6b4bc 10openembedded.git/recipes/js/files/ (5 files in 3 dirs): |
| 19:14.02 | CIA-2 | js: renamed files dir to more appropriate name js |
| 19:14.02 | CIA-2 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 19:14.03 | CIA-2 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r141f355dcc 10openembedded.git/recipes/js/ (files/libtermcap.patch js_1.5.bb): |
| 19:14.03 | CIA-2 | js: fixed libtermcap |
| 19:14.03 | CIA-2 | the new ncurses does not have libtermcap |
| 19:14.04 | CIA-2 | this patches -ltermcap into -lncurses |
| 19:14.04 | CIA-2 | also added ncurses to DEPENDS |
| 19:14.05 | CIA-2 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 19:14.06 | CIA-2 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r976ab4b458 10openembedded.git/recipes/pulseaudio/ (3 files in 2 dirs): (log message trimmed) |
| 19:14.06 | CIA-2 | pulseaudio: made 0.9.21 compile for armv4 and armv5 too |
| 19:14.06 | CIA-2 | there was some armv6 asm in here. |
| 19:14.07 | CIA-2 | Fortunately the function with much inline asm was only |
| 19:14.07 | CIA-2 | called for armv6 or higher so this is ifdef'd out for all |
| 19:14.08 | CIA-2 | armv4 and armv5 variants. |
| 19:14.08 | CIA-2 | Also there was a single instruction but the code also had a C |
| 19:14.11 | *** join/#oe dth_ntb (~dth@a89-183-4-212.net-htp.de) |
| 19:14.55 | khem | eFfeM: I am at 12000 |
| 19:16.54 | eFfeM | ah ok |
| 19:17.24 | eFfeM | got some errors upfront though, hope the patch from eric will solve these (virtual/egl related) |
| 19:17.39 | khem | saw those |
| 19:17.41 | eFfeM | btw machine=calamari distro=minimal |
| 19:17.53 | khem | my machine is armv7 |
| 19:18.03 | khem | so probably it did not bail out as it did for you |
| 19:18.07 | khem | ok |
| 19:18.22 | khem | I am going to restart with pstaging |
| 19:18.29 | eFfeM | i figured armv7 is probably more tested (especially beagle/angstrom combo), that does not give those problems |
| 19:18.34 | eFfeM | ah pstaging is also fun |
| 19:18.41 | khem | yeah but mine is not omap |
| 19:19.13 | eFfeM | ah ok |
| 19:19.14 | khem | ericben: you have my ack for the virtual/egl fix with koen's suggestions |
| 19:19.29 | ericben | khem: ok thanks |
| 19:19.30 | eFfeM | mine too, I was already happy with the original patch |
| 19:19.42 | ericben | I think the way to fix it is wrong but this will remove the log |
| 19:20.09 | eFfeM | and if koen's suggestions make it more acceptable and make the problem go away for now I am happy with it |
| 19:20.21 | khem | yes I know |
| 19:20.44 | ericben | I have omap3503 board on my desk and with this fix, I will have bins with gles libs on it |
| 19:21.25 | eFfeM | actually what I would like to see is something like MACHINE_FEATURES |
| 19:22.03 | eFfeM | and if a device does not have certain capabilities (e.g. a display or sound) certain things can be left out |
| 19:22.34 | eFfeM | e.g. no gst if you only want/have/support bluetooth for serial devices |
| 19:22.47 | ericben | yes, but from what I understood MACHINE_FEATURES can't be used too "disable" a package |
| 19:23.24 | ericben | this can be used to not install it in the image but this won""t remove the log we see for qqt4-embedded-gles |
| 19:24.01 | khem | actually some packages might be machine specific |
| 19:24.28 | khem | so as we have some packages which are built machine specific we can have packages which are not built for a given machine |
| 19:24.32 | khem | on same logic |
| 19:24.38 | kergoth_ | ericben, of course it can. task-base has many conditionals that pull in things into its deps based on machine and distro features |
| 19:25.07 | *** join/#oe hansdampf (~moritz@212.77.183.87) |
| 19:25.16 | khem | starts a build with pstaging |
| 19:26.25 | stefan_schmidt | eFfeM: kudos for being the one who finally touched the pulseaudio problem for armv4+5 |
| 19:27.05 | ericben | kergoth_: OK, in fact here the message seems to be caused by the fact that qt4-embedded-gles says PROVIDES = "qt4-embedded" but depends on virtual/egl so when an image requires qt4-embedded, qt4-embedded-gles is among the packages which can be built and only fails because bitbake remove it as it can find the virtual/egl dependency |
| 19:27.38 | *** join/#oe bluelightning (~bluelight@93-96-131-185.zone4.bethere.co.uk) |
| 19:27.38 | *** join/#oe bluelightning (~bluelight@pdpc/supporter/professional/bluelightning) |
| 19:28.26 | eFfeM | stefan_schmidt: thanks :-) |
| 19:28.47 | eFfeM | couldn't find any patches in debian or so, so decided to dig into it myself |
| 19:28.50 | ericben | so what I tried to do at the beginning it to try to have qt4-embedded-gles not answer when someone want to builds qt4-embedded for a machine which don't have egl but I failed here. |
| 19:29.19 | ericben | eFfeM: yes, this bug is still open in pulseaudio's buglist I think last time I checked it |
| 19:29.44 | eFfeM | yes, it was assigned half a year ago then became silent |
| 19:29.50 | eFfeM | probably I should mail them |
| 19:30.31 | khem | ericben: PROVIDES_omap3 = "qt4-embedded" in qt4-embedded-gles |
| 19:30.41 | khem | that sort of thing did not help |
| 19:33.15 | *** join/#oe GarthPS (~quassel@92.102.66.79) |
| 19:33.17 | ericben | khem: didn't try that. I didn't want to do something omap3 centric because someone told me that peoples could have virtual/egl providers in external overlays. |
| 19:33.46 | CIA-2 | 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * rc11ebb7499 10openembedded.git/classes/packaged-staging.bbclass: |
| 19:33.46 | CIA-2 | packaged-staging: use oe_run rather than os.system |
| 19:33.46 | CIA-2 | This ensures that the output of the stage manager is swallowed, rather than |
| 19:33.46 | CIA-2 | shown unnecessarily to the user. |
| 19:33.46 | CIA-2 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
| 19:33.55 | kergoth_ | khem, see if that takes care of it |
| 19:34.13 | ericben | now the fix is omap3 centric but when you add a new architecture providing egl (example i.MX51), you only have to change one file. |
| 19:36.06 | khem | kergoth_: ok |
| 19:36.09 | ericben | eFfeM: http://www.pulseaudio.org/ticket/790 |
| 19:38.18 | khem | ericben: thats ok because of someone has provided in external repo it still will be honored |
| 19:38.57 | khem | ericben: infact efikamx is already added to OE :) |
| 19:39.04 | khem | which is i.MX51 I believe |
| 19:40.26 | ericben | khem: yes but not all the GLES layer which is quite a pain to work with |
| 19:41.19 | anarsoul | can anyone take a look on this bug?: http://bugs.openembedded.org/show_bug.cgi?id=5473 |
| 19:42.31 | khem | anarsoul: thats not OE issue I told you earlier |
| 19:42.43 | khem | anarsoul: its something missing in libraries on your build box |
| 19:43.04 | eFfeM | ericben, I know |
| 19:43.37 | kergoth_ | hmm, should move these bits wrapping popen into a lib/oe/ module, with a proper exception class for the command failure |
| 19:44.20 | eFfeM | ericben: i'm not on their list and not looking forward for administrative issues or registering for their trac so send an email to lennart with the patch |
| 19:45.36 | khem | anarsoul: you have /usr/lib/libxml2.so and /home/anarsoul/work/openembedded/jlime/tmp/sysroots/i686-linux/usr/lib/libxml2.so both listed on commandline |
| 19:45.53 | *** join/#oe Martin-B (~martin@pool-239-66-198-89.dbd-ipconnect.net) |
| 19:45.53 | khem | anarsoul: you have to figure out why /usr/lib/libxml2.so creeps in |
| 19:47.58 | anarsoul | khem: uh, I'm not familiar with debugging bitbake recipes :\ |
| 19:48.07 | *** join/#oe mnabil_ (~mnabil@41.234.69.102) |
| 19:48.55 | khem | anarsoul: its your chance |
| 19:49.52 | anarsoul | khem: ok :) how to start? is there any guide for oe newbies? |
| 19:49.55 | khem | look into wiki.openembedded.org |
| 19:51.06 | anarsoul | ok |
| 19:51.36 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 19:51.53 | Crofton | is the guy working on the omniorb recipe around? |
| 19:52.22 | eFfeM | nah, he's in pakistan and only around during his day |
| 19:52.47 | Crofton | ok |
| 19:52.58 | Crofton | That recipe is cranky |
| 19:52.59 | eFfeM | he is with mentor, maybe discuss with Tartarus, I think he directed them to some recipes to cleanup |
| 19:53.04 | eFfeM | not sure about details |
| 19:53.19 | Tartarus | Anything -native and with legacy staging |
| 19:53.24 | Crofton | yeah, need to make sure they have a way to make sure you can build CORBA apps afterwards |
| 19:53.45 | Crofton | Tartarus, unless they can test, that one is best left alone |
| 19:53.57 | eFfeM | that was my issue with some of the recipes, I had no way to test them properly and for some of the recipes maybe they should go |
| 19:53.57 | Crofton | it really needs to be as a cross thing anyway |
| 19:54.01 | eFfeM | like the uicmoc ones |
| 19:54.13 | Crofton | well, I use this one occasionally |
| 19:54.21 | Crofton | and some did submit the patch to update it |
| 19:54.26 | Tartarus | Well, they've been checking pstaing before and afterwards |
| 19:54.29 | *** join/#oe thaytan (~jan@ppp59-167-167-201.static.internode.on.net) |
| 19:54.34 | Tartarus | So things should be no more broken than before |
| 19:54.43 | Crofton | it is the omniidl program I worry about |
| 19:55.06 | eFfeM | it was also my impression that they check quite well, but there is quite some work of them piling up in patchwork |
| 19:55.20 | Crofton | basically, two months from now, I don't want to have to go backwards ... |
| 19:55.39 | eFfeM | and didn't have too much time last week for them as school has started again, so I need to spent time on things like giving courses and supervising labs |
| 19:55.47 | Tartarus | Well, how do you test it today? |
| 19:56.14 | eFfeM | ka6sox-work: after doing the le build I also did the be build (without cleaning tmp) build also fine |
| 19:56.18 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 19:56.21 | Crofton | I have a build that uses it |
| 19:56.32 | Crofton | but there is a collection and I am not setup to test |
| 19:56.59 | Crofton | basically, I am just pointing out that if it gets broke, no one may notice for a while |
| 19:57.09 | Crofton | but |
| 19:57.15 | Crofton | it will get noticed |
| 19:57.50 | *** join/#oe vanous (~vanous@ip-85-161-55-1.eurotel.cz) |
| 19:57.54 | Tartarus | Well, imho, if there's nothing in tree and we're just doing janitor type changes |
| 19:58.01 | Tartarus | That's just the way it falls down |
| 19:58.14 | Tartarus | If there's any in tree way to test, i'd be quite happy to have them make sure it still works |
| 19:58.32 | ka6sox-work | eFfeM, thanks... |
| 19:58.52 | eFfeM | basically what I did when I pushed their changed, I build them and for the native recipes I tried to find all users and build those |
| 19:59.23 | eFfeM | fairly timeconsuming and boring though (like the japanese things) |
| 20:00.50 | *** join/#oe stefan__ (~stefan@p5B03738F.dip.t-dialin.net) |
| 20:01.21 | *** join/#oe pH5 (~ph5@e178233242.adsl.alicedsl.de) |
| 20:01.24 | ka6sox-work | ya, sounds like an automated build system would help :D |
| 20:02.16 | Jay7 | will do such system soon :) |
| 20:04.02 | ericben | I setup a hudson server yeesterday : http://hudson-ci.org/ simple to install (apt ...) and to setup, seems to be a good solution (eFfeM also has one) |
| 20:04.31 | Tartarus | heh |
| 20:04.42 | Tartarus | hudson has its own set of issues :( |
| 20:04.50 | eFfeM | like ? |
| 20:04.53 | ericben | ah, which ones ? |
| 20:04.59 | eFfeM | i would like to learn them |
| 20:05.17 | eFfeM | for now I am quite happy with it |
| 20:05.29 | Tartarus | For us anyhow, it's checking out the sources twice |
| 20:05.36 | Tartarus | memory overhead sucks |
| 20:05.56 | ericben | checking sources for OE or for java projects ? |
| 20:05.58 | Tartarus | (adding about 1GB) |
| 20:06.02 | Tartarus | checking out OE |
| 20:06.17 | ericben | using a shell script or a git plugin in hudson ? |
| 20:06.33 | Tartarus | svn |
| 20:07.26 | ericben | ah ok, here I did everything in the shell and din't use their scm functionnalities. |
| 20:08.12 | ericben | I didn't check the overhead, the machine have 12GB of RAM so that's not a big problem I think |
| 20:08.45 | Tartarus | heh |
| 20:08.48 | Tartarus | We have boxes like that |
| 20:08.51 | Tartarus | But virtualize 'em |
| 20:09.00 | Tartarus | So what hudson sees needs a min of 6GB |
| 20:09.06 | Tartarus | in order to have a good number of bitbake threads |
| 20:10.04 | *** join/#oe sicu (~sicu@ti0090a380-dhcp0332.bb.online.no) |
| 20:10.45 | ericben | ok, an other solution was buildbot : http://buildbot.net/trac I have to test it on the second build machine before making the final choice |
| 20:11.00 | Tartarus | yeah |
| 20:11.05 | Tartarus | Haven't used buildbot in a long while |
| 20:11.19 | Tartarus | Depends really on what your users need |
| 20:11.49 | ericben | well, I'm the user :-) |
| 20:12.21 | Tartarus | heh |
| 20:12.24 | ericben | I'm not in a wordlwide company ;-) |
| 20:12.25 | Tartarus | And no one else? |
| 20:12.49 | ericben | only one other person. |
| 20:13.15 | eFfeM | ericben, I'm interested in your trac findings |
| 20:13.33 | ericben | eFfeM : you mean buildbot ? |
| 20:13.44 | eFfeM | I didn't use their git either, just did a shellscript that did a git pull |
| 20:13.49 | eFfeM | ericben: yes, meant buildbot |
| 20:15.14 | ericben | oe has the script in contrib/buildbot and last week someone here setup it. But he told me that bitbake alwasy returned 1, si I tried hudson to see if I could datect success of failure based on the log and I also got failures because of the gles error which will be fixed once I push the patch ass this was not bitbake's fault |
| 20:16.09 | ericben | sorry for the double characters, my notebook's keyboard is slowly failing (or my fingers ;-) |
| 20:17.27 | ericben | eFfeM: I'll keep you informed, our second build machine has finished all it's memory & hd tests so I'll setup it next week |
| 20:17.34 | eFfeM | cool |
| 20:18.43 | *** join/#oe vanous (~vanous@ip-85-161-44-182.eurotel.cz) |
| 20:19.25 | ericben | can I push the gles patch or should I wait for Koen's feedback ? |
| 20:19.40 | *** join/#oe sicu (~sicu@ti0090a380-dhcp0332.bb.online.no) |
| 20:20.23 | ericben | Tartarus: for http://bugs.openembedded.org/show_bug.cgi?id=5474 I don't understand your comment : should readprofile end in /sbin (as util-linux-ng) or /usr/sbin (as busybox does) ? |
| 20:21.17 | anarsoul | khem: gettext uses libcroco from host system for some reason |
| 20:21.33 | anarsoul | and there's libxml2.la in libcroco-0.6.la |
| 20:21.36 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
| 20:22.02 | Tartarus | ericben: Oh, i got it backwards:( |
| 20:22.08 | Tartarus | usr/sbin is correct |
| 20:22.27 | ericben | ok so it's util-linux-ng which needs to be fixed |
| 20:22.37 | Tartarus | yes |
| 20:22.41 | ericben | ok |
| 20:22.41 | Tartarus | would have done that myself |
| 20:22.44 | Tartarus | it's pretty easy |
| 20:23.21 | *** join/#oe matgnt (~matthias@p4FCF18CC.dip0.t-ipconnect.de) |
| 20:23.27 | ericben | yes but I didn't understood what you said : "It looks like busybox is in the wrong here" , as I met this problem this afternoon also |
| 20:24.01 | Tartarus | i'll go clarify |
| 20:24.08 | ericben | dont worry |
| 20:24.16 | ericben | now it's clear ;-) |
| 20:26.07 | Tartarus | yeah, but i need to make the bug clear too :) |
| 20:30.01 | eFfeM | ericben: as if i recall correctly compatible_machine is used in a regexp maybe you can give a regexp that says omap3 but not 3503 or so |
| 20:30.08 | eFfeM | for virtual/egl |
| 20:31.25 | ericben | eFfeM: will see once I give again power to the 3503 board which is not very high in the priority list |
| 20:32.03 | ericben | thanks for the idea |
| 20:32.52 | eFfeM | yw |
| 20:33.02 | anarsoul | khem: fixed, where I should send patch? openmoko-devel ml? |
| 20:35.17 | *** join/#oe awozniak (~awozniak@adsl-76-205-222-173.dsl.snlo01.sbcglobal.net) |
| 20:37.46 | khem | anarsoul: thats was quick |
| 20:37.51 | khem | send to oe ml |
| 20:38.36 | anarsoul | khem: which one? oe-devel? |
| 20:38.58 | ericben | anarsoul: git send-email --to openembedded-devel@lists.openembedded.org ... |
| 20:39.05 | anarsoul | ok |
| 20:39.06 | anarsoul | :) |
| 20:39.41 | khem | hmm broadcom opersources there wireless drivers |
| 20:40.08 | khem | anarsoul: whats was the fix |
| 20:40.10 | khem | btw. |
| 20:40.34 | stefan__ | khem: now everyone needs to look at nvidia for being the last one getting it :D |
| 20:40.37 | anarsoul | khem: just added --with-included-libcroco to EXTRA_OECONF |
| 20:40.46 | anarsoul | in gettext_0.18.bb |
| 20:41.35 | khem | anarsoul: ok it needs testing I guess |
| 20:41.41 | khem | stefan__: yea :) |
| 20:41.51 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 20:42.01 | anarsoul | khem: I'm building bootstrap-image right now |
| 20:42.33 | anarsoul | I'll send patch if build will succeed |
| 20:42.39 | khem | ok |
| 20:42.52 | khem | you shoul dbuild x11-image too |
| 20:43.21 | khem | Tartarus: now can I just move deploy did out of tmpdir |
| 20:43.26 | anarsoul | khem: ok |
| 20:43.44 | khem | Tartarus: and it will populate my deleted tmpdir |
| 20:43.48 | khem | on next run |
| 20:45.11 | Tartarus | Here's my local.conf snippets |
| 20:45.19 | Tartarus | TMPDIR = "/home/trini/work/OE-upstream/tmp.${LIBC}.${DISTRO}" |
| 20:45.29 | Tartarus | # Keep pstage out of TMPDIR |
| 20:45.29 | Tartarus | PSTAGE_DIR = "/home/trini/work/OE-upstream/pstage.${LIBC}.${DISTRO}" |
| 20:45.57 | Tartarus | LIBC and DISTRO are both in extrawhite for me |
| 20:48.47 | khem | cool |
| 20:49.09 | khem | Tartarus: next time I will change my local.conf to move pstaging out of tmpdir |
| 20:54.54 | Tartarus | So... |
| 20:55.01 | Tartarus | You should be able to just mv it now |
| 20:55.06 | Tartarus | Change local.conf |
| 20:55.08 | Tartarus | And go |
| 20:55.20 | khem | oh it wont chicken out on dir change |
| 20:55.21 | *** join/#oe andyj (~andy@c-76-28-141-180.hsd1.wa.comcast.net) |
| 20:55.25 | Tartarus | I haven't done as extensive torture testing on oe.dev as I have in our own little domain :) |
| 20:55.27 | khem | well let my current run finish |
| 20:55.42 | Tartarus | khem: Yes, another of the big wins for pstaging is that it's relocatable |
| 20:55.53 | khem | ok |
| 20:56.04 | khem | I wish opkg could handle cross packages :) |
| 21:04.28 | eFfeM | khem, Tartarus, if you really want to test pstage things, you should move it out of tmp and change TMPDIR, that will trigger issues with absolute paths in pstage packages |
| 21:05.39 | Tartarus | eFfeM, yes, that's harder to automate without a little more knowledge |
| 21:05.48 | Tartarus | and part of why I haven't moved the torture tests to contrib/ :) |
| 21:06.21 | Tartarus | (actually, its just harder w/o something to generate local.conf, or some extrawhite variable'ing) |
| 21:09.39 | *** join/#oe vanous (~vanous@robe.ludik.cz) |
| 21:09.58 | Crofton | ericben, do you have commit access? |
| 21:11.17 | stefan__ | khem: eFfeM: I joined the bitbake world fun. Started a build for bug20 on our buildhost. |
| 21:11.26 | eFfeM | :-) |
| 21:11.49 | eFfeM | Crofton he has |
| 21:13.18 | ericben | Crofton: yes |
| 21:13.39 | kgilmer | such a controversy, that 'bitbake world' business stefan__ |
| 21:13.48 | ericben | but I still prefer patches to be reviewed for a while before pushing directly |
| 21:13.53 | Crofton | ok |
| 21:13.59 | Crofton | I'm noticed that problem |
| 21:14.06 | Crofton | just want to make sure it does get in |
| 21:15.20 | stefan__ | kgilmer: ah well, getting the whole metadata in better shape is a worthy goal. Its just a longterm goal :) |
| 21:15.35 | khem | stefan__: good |
| 21:15.47 | khem | stefan__: run bitbake -k world |
| 21:15.55 | khem | so you capture many errors in one run |
| 21:16.08 | stefan__ | khem: yup, doing this already |
| 21:16.25 | kgilmer | yep stefan__ |
| 21:16.29 | khem | cool |
| 21:17.46 | khem | stefan__: do you have powerful box |
| 21:18.22 | khem | it ran for 24 hours for 15000 tasks our of 82000 odd that were lined up for me :) |
| 21:18.32 | stefan__ | khem: Using the 8 core i7 buildhost from work. *psst* don't tell kgilmer and jconnolly ;) |
| 21:19.02 | khem | wow thats something |
| 21:19.12 | kgilmer | ha stefan__ |
| 21:19.13 | khem | my laptop is a core2duo |
| 21:19.15 | kgilmer | that's what it's for :) |
| 21:19.32 | kgilmer | the worst if it sits there idle stefan__ |
| 21:19.39 | stefan__ | khem: yup, makes fun working on it. If not the lag from .de to .us would be that bad over the VPN |
| 21:19.57 | Crofton | just make sure to break stuff at a slower rate than we can fix it ... |
| 21:20.07 | stefan__ | kgilmer: yup, thats how I see it as well. Can still be niced if other stuff is mor eimportant |
| 21:20.13 | stefan__ | important |
| 21:20.18 | khem | Crofton: :) dont worry |
| 21:20.32 | khem | I will make sure |
| 21:21.08 | CIA-2 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * rf24466c861 10openembedded.git/recipes/perl/libxml-libxml-perl_1.70.bb: |
| 21:21.09 | CIA-2 | libxml-libxml-perl: added dependency for XML::NamespaceSupport |
| 21:21.09 | CIA-2 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 21:21.09 | CIA-2 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r04ce0aa3ae 10openembedded.git/recipes/perl/ (libxml-twig-perl_3.33.bb libxml-twig-perl_3.35.bb): |
| 21:21.09 | CIA-2 | libxml-twig-perl: updated to 3.35, changed uri to fetch from cpan |
| 21:21.09 | CIA-2 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 21:21.10 | CIA-2 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r535925c83f 10openembedded.git/recipes/perl/libimage-size-perl_3.230.bb: |
| 21:21.10 | CIA-2 | libimage-size-perl: added |
| 21:21.11 | CIA-2 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 21:21.17 | khem | stefan__: are u in .us |
| 21:21.37 | stefan__ | stefan__: nope, in .de, but BugLabs is in NYC |
| 21:21.45 | khem | stefan__: ah I see |
| 21:22.33 | khem | stefan__: run it in screen session and check back tomorrow :) |
| 21:22.49 | stefan__ | khem: sure, thats what I'm always doing :) |
| 21:23.07 | khem | cool. |
| 21:24.13 | khem | stefan__: with such a monster system I am sure you will be able to finish the job |
| 21:24.25 | khem | could you put the logs somewhere for others to look into |
| 21:24.30 | khem | so we can fix the failures |
| 21:24.49 | khem | may be tee the output to a log file |
| 21:25.11 | khem | btw. whats your DISTRO and MACHINE |
| 21:25.23 | stefan__ | khem: good point, let me cancel it and setup tinderbox reporting |
| 21:25.35 | stefan__ | khem: angstrom 2008 and bug20 |
| 21:25.40 | khem | stefan__: ok |
| 21:25.59 | khem | stefan__: along with tinderbox still world.log would be nice |
| 21:26.07 | khem | bitbake -k world | tee world.log :) |
| 21:26.23 | stefan__ | khem: sure, can do this as well |
| 21:26.59 | khem | thanks |
| 21:27.43 | khem | ericben: did you commit your fix for omap3 and gles |
| 21:28.18 | eFfeM | calling it a day |
| 21:28.52 | ericben | khem: should I wait for koen's ack ? |
| 21:28.59 | ericben | if not I push it |
| 21:29.08 | khem | I think you did what he wanted |
| 21:29.14 | ericben | ok |
| 21:30.24 | CIA-2 | 03Eric Bénard <eric@eukrea.com> 07org.openembedded.dev * re0535b507e 10openembedded.git/recipes/ (13 files in 6 dirs): (log message trimmed) |
| 21:30.24 | CIA-2 | fix bitbake ERRORS for machine not having virtual/egl |
| 21:30.24 | CIA-2 | * several recipes depend on virtual/egl which currently has only one |
| 21:30.24 | CIA-2 | provider : powervr-drivers/libgles-omap. This provider sets |
| 21:30.24 | CIA-2 | COMPATIBLE_MACHINE to a few TI based machines. |
| 21:30.25 | CIA-2 | When building for machines which don't provide virtual/egl, we get |
| 21:30.26 | CIA-2 | the following errors : |
| 21:30.48 | khem | stefan__: may be you should get this fix too |
| 21:30.49 | tharvey | I don't see really any log entires in the 'docs' tree - what tool would one use to edit the usermanual source? seems cumbersome to edit xml directly |
| 21:31.10 | khem | tharvey: vi :) |
| 21:31.32 | stefan__ | khem: Get what fixed? |
| 21:31.44 | khem | one that ericben just committed |
| 21:31.54 | khem | e0535b507e |
| 21:31.55 | tharvey | khem, heh... perhaps thats why it never gets edited |
| 21:32.11 | tharvey | what recipe ends up building the targets in docs/usermanual? |
| 21:33.05 | ericben | tharvey: docs/usermanual/README says : make <type> |
| 21:33.40 | tharvey | yes, I understand that but I've never done a manual 'make' in my docs/usermanual dir yet they are built, so I'm asking what recipe did that? |
| 21:34.07 | tharvey | I'm looking at following the same example OE uses for docs for something else so I'm trying to understand it |
| 21:35.17 | ericben | here they are not built despite being in a sourcetree which is daily used |
| 21:35.46 | CIA-2 | 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r77282c2a3a 10openembedded.git/recipes/tasks/task-sdk-gpephone.bb: |
| 21:35.46 | CIA-2 | task-sdk-gpephone.bb: Move to obsolete |
| 21:35.46 | CIA-2 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 21:35.47 | CIA-2 | 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r1fb5aa22f4 10openembedded.git/recipes/tasks/task-gpephone.bb: |
| 21:35.47 | CIA-2 | task-gpephone.bb: Move to obsolete |
| 21:35.47 | CIA-2 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 21:35.49 | CIA-2 | 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r911e4f043a 10openembedded.git/recipes/gpephone/ (110 files in 22 dirs): |
| 21:35.49 | CIA-2 | gpephone: Move to obsolete |
| 21:35.49 | CIA-2 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 21:37.15 | stefan__ | khem: http://tinderbox.openembedded.net/builders/Stefan%20Schmidt/ |
| 21:37.37 | stefan__ | khem: Still thinking how I will handle the world.log as the machine sits in a private network |
| 21:38.31 | khem | hmmm you can upload that to some common location |
| 21:38.56 | khem | but I will keep an eye on tinderbox |
| 21:38.58 | stefan__ | khem: yeah, after every turn |
| 21:39.23 | stefan__ | I was thinking if I could somehow have it public even during the build |
| 21:39.37 | khem | oh thats not needed |
| 21:39.49 | khem | after complete run lets see what we got |
| 21:39.53 | khem | and then we fix things |
| 21:40.00 | khem | and cycle repeats |
| 21:41.23 | khem | eventually if we do bitbake world regularly then we should have few errors and it will be a good stress for cross compilers |
| 21:41.26 | *** join/#oe crockettj_ (96a90f85@gateway/web/freenode/ip.150.169.15.133) |
| 21:41.28 | stefan__ | khem: ok, thats easy, will do thsi for now |
| 21:41.36 | stefan__ | :) |
| 21:55.03 | *** join/#oe mickeyl (~mickey@openmoko/coreteam/mickey) |
| 22:00.11 | *** join/#oe CMoH|notebook (~cipi@95.76.71.81) |
| 22:19.30 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
| 22:21.09 | *** join/#oe andyj (~andy@c-76-28-141-180.hsd1.wa.comcast.net) |
| 22:21.09 | *** join/#oe kgilmer (~kgilmer@firebug.buglabs.net) |
| 22:21.09 | *** join/#oe chase (~chase@nat/ti/x-uhmnqkrxdqyukslt) |
| 22:21.09 | *** join/#oe jpieper (~jpieper@209-6-37-232.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) |
| 22:28.19 | *** join/#oe gimp__ (421da1d2@gateway/web/freenode/ip.66.29.161.210) |
| 22:30.47 | gimp__ | Hi guys, I've used a gumstix, beagleboard, and Davinci (montavista)in the past, one thing I miss that montavista had but Angstrom doesn't (by default?) is the native commandline tools. Instead everthing is left up to busybox. Is it feasible to change the bitbake receipies to NOT use busybox and cross compile the native tools? |
| 22:31.56 | kergoth_ | the native tools already exist |
| 22:32.06 | kergoth_ | you can install them on top of busybox, and they'll be used in preference to the busybox ones |
| 22:32.18 | kergoth_ | see task-proper-tools in recipes/meta/ or recipes/tasks/, i forget which |
| 22:35.46 | gimp__ | thank you kergoth |
| 22:38.24 | Crofton_|work | goes to look that one up alos |
| 22:38.34 | Crofton_|work | kergoth_, the IMAGE FEATURE seems to work |
| 22:38.48 | Crofton_|work | still need to see if oprofile finds the .debug stuff though |
| 22:44.33 | likewise | khem: whee, I have programmed the e500v2 SPE engine :-) |
| 22:45.04 | likewise | thinks he's the second person on earth who ever did that. The first works in a cubicle at Freescale :-) |
| 22:45.26 | Crofton_|work | what does that mean? |
| 22:49.46 | *** join/#oe NovceGuru (novceguru@server1.jsreedinc.com) |
| 22:49.47 | hollisb | it means he used some SIMD instructions |
| 22:49.57 | Crofton_|work | rofl |
| 22:50.21 | Crofton_|work | they must be awful hard to use .... |
| 22:51.47 | hollisb | apparently |
| 23:03.50 | *** join/#oe andyj (~andy@c-76-28-141-180.hsd1.wa.comcast.net) |
| 23:03.50 | *** join/#oe chase (~chase@nat/ti/x-uhmnqkrxdqyukslt) |
| 23:03.50 | *** join/#oe jpieper (~jpieper@209-6-37-232.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) |
| 23:06.30 | *** join/#oe kergoth (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 23:06.48 | khem | likewise: hmm cool |
| 23:06.55 | khem | likewise: what did you write |
| 23:07.03 | khem | some media encoder |
| 23:07.04 | kergoth | works on ditching this silly EventException in bitbake |
| 23:07.22 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 23:07.25 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
| 23:08.10 | khem | hey grg |
| 23:08.18 | grg | khem, mornin' |
| 23:08.28 | khem | how are you doing |
| 23:08.37 | grg | good |
| 23:08.44 | likewise | khem: no the e500e SPE is SIMD but with multiple=2 ... I wrote a sample averaging algorithm, expected a 200-450% speedup, but ending up with 60%. |
| 23:08.51 | grg | bitbake world looks like it finished 1063m50.894s |
| 23:09.01 | khem | grg: wow |
| 23:09.33 | khem | grg like 17 hrs |
| 23:09.50 | Crofton_|work | sounds hard to use .... |
| 23:10.07 | khem | Crofton_|work: it will get leaner |
| 23:10.19 | khem | grg: do you have your logs around |
| 23:10.21 | kergoth | grg: that's all? |
| 23:10.25 | Crofton_|work | I mean the spe thingy |
| 23:10.31 | likewise | hollisb, Crofton_|work: it's just that this SIMD instruction set doesn't have any examples on Internet, AFAICF |
| 23:10.33 | kergoth | last time i tried world i think it ran for 3 or 4 days.. course not the fastest box int he world :) |
| 23:10.49 | grg | khem, world.log is 70mb |
| 23:10.50 | khem | likewise: your algorithm needs improvement |
| 23:11.08 | khem | grg: hmm ok I wonder if you can share it somewehre |
| 23:11.35 | grg | khem, i really need to get some hosting in my office... i don't even have control of the modem... |
| 23:11.45 | khem | eh ok |
| 23:11.54 | khem | grg: did you enable tindrbox |
| 23:12.00 | likewise | khem: apparently, but the data layout in memory doesn't allow for both cache and SPE optimization. |
| 23:12.04 | grg | khem, yes, its all in tinderbox |
| 23:12.14 | khem | grg: ok gimme task id |
| 23:12.19 | kergoth | kicks bitbake a few times |
| 23:12.36 | khem | likewise: hmm in what way |
| 23:12.47 | khem | like is it some alignments are different |
| 23:12.48 | likewise | kergoth: does that help? I never knew ;-) |
| 23:13.07 | Crofton_|work | you used to have to buy more RAM to use bitbake |
| 23:13.18 | grg | khem, last one is 85990 |
| 23:13.27 | kergoth | likewise: no, but it makes me feel better :) |
| 23:13.38 | grg | careful, it might kick back |
| 23:13.55 | grg | world.log.bz2 is only 3.8mb |
| 23:14.03 | grg | much more manageable |
| 23:14.12 | khem | grg: email it to me |
| 23:14.23 | grg | khem, can do |
| 23:15.12 | likewise | khem: I have N buffers of M signed 16-bit samples. Each buffer is contiguous in memory. The resulting buffer consists of averaged samples, i.e. sample #0 is the average of all samples #0 in the N buffers. |
| 23:15.55 | khem | this would be a cake walk for neon :) |
| 23:16.01 | likewise | khem: I know :-) |
| 23:16.37 | likewise | I have implemented both a outer loop over the buffers, inner loop over the samples. and vice versa in SPE. |
| 23:16.49 | khem | thats cool |
| 23:17.07 | likewise | The latter wins, despite cache trashing |
| 23:17.45 | khem | you can interchange the loops for experiment |
| 23:17.45 | Crofton_|work | likewise, shouldn't you be in bed? |
| 23:18.02 | khem | SPE keeps him awak |
| 23:18.15 | likewise | Crofton_|work: I work best during times that you do :-) |
| 23:18.44 | likewise | khem: ranting to you keeps me awake. |
| 23:19.05 | likewise | :-) |
| 23:20.28 | khem | likewise: are these buffers put one after another |
| 23:20.56 | khem | likewise: may be add some alignment to make thm cache line aligned |
| 23:26.09 | likewise | khem: I'll post the code to you. Code Bounty: 1 US$ for each percentage of speed improvement over my current code :-) |
| 23:29.19 | khem | likewise: heh ok |
| 23:29.35 | khem | for bounty I will send you a separate formula |
| 23:29.37 | khem | ;) |
| 23:30.13 | likewise | khem: hmm,wonder if qemu does e500v2 SPE ... |
| 23:30.33 | likewise | if you like bounty: do the pirate puzzle, heard of that? |
| 23:30.49 | khem | likewise: yes I know that puzzle |
| 23:30.54 | khem | :) |
| 23:31.08 | khem | qemu does not do spe |
| 23:31.25 | khem | or may be it does |
| 23:32.28 | likewise | ah well, I can provide SSH access to a P1020 board |
| 23:35.32 | *** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net) |
| 23:37.51 | khem | likewise: sure |
| 23:43.24 | likewise | commented and posted the code, do with it whatever you want (including nothing at all and deleting it) |
| 23:44.35 | khem | likewise: got it |
| 23:44.38 | khem | heh lemme see |
| 23:44.57 | khem | do you have a system with compiler |
| 23:45.30 | khem | grg: lot of error in your log are fetch errors |
| 23:45.32 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 23:45.42 | khem | grg: those should be easy ones |
| 23:47.22 | khem | some of them use arm inline asm for mips :) thats obviously wrong |
| 23:49.02 | khem | cpuburn-neon seems more like arm only recipe it should be ignored for mips |
| 23:49.08 | kergoth | hrm |
| 23:49.22 | kergoth | bitbake's exception handling still bugs me a bit |
| 23:50.50 | grg | khem, quake1 failed in do_fetch. Well that' |
| 23:50.56 | grg | s going to have top be fixed |
| 23:51.33 | grg | quakeforge is being actively developed again now... maybe we need a recuipe for that |
| 23:51.48 | kergoth | hmm |
| 23:52.30 | khem | kergoth: yes bitbake does not die gracefully |
| 23:52.38 | kergoth | i'm sick of seeing the same message like 12 times |
| 23:52.41 | kergoth | yes, i know, the function failed |
| 23:52.43 | kergoth | and the task failed |
| 23:52.44 | kergoth | and.. |
| 23:52.45 | kergoth | bite me |
| 23:53.09 | khem | infact it leaves its belly open and all it has gulped is spitted |
| 23:53.52 | kergoth | the only time i want to see an exception traceback is if a python task raised an uncaught exception, or an event handler did, cause that just means something is broken |
| 23:53.57 | kergoth | other than that, go away |
| 23:54.20 | likewise | khem: An Indian saying? :-) |
| 23:54.56 | kergoth | think i've successfully killed this silly and unnecessary "event exception" thing |
| 23:55.00 | kergoth | thats a step in the right direction.. |
| 23:55.02 | likewise | khem: I'll see about that machine access when I feel less like to going to bed. |
| 23:55.03 | kergoth | still more to be done though |
| 23:55.08 | likewise | kergoth: rm -rf bitbake* ? |
| 23:55.22 | kergoth | i'm thinking the whole exec_func*/exec_task thing could use a rework |
| 23:55.52 | kergoth | hrm |
| 23:56.15 | kergoth | what makes it hard to wrap my head around is the fact that an exceptioni could be raised in the server, UI, or worker threads |
| 23:58.05 | khem | likewise: One improvement I hav in mind already |