| 00:01.00 | tharvey | it globs but it uses BBPATH not PWD |
| 00:01.20 | tharvey | khem, about the QA Issue with gcc - that causes bitbake to error out - am I missing something? |
| 00:02.20 | khem | no |
| 00:02.31 | khem | I think you have QA strict |
| 00:03.43 | tharvey | warning as errors you mean? looking for where that would be defined |
| 00:03.46 | khem | yeah |
| 00:03.58 | khem | whats in your INHERIT |
| 00:04.58 | CMoH-notebook | yup, bblayers are really cool as well as bbappend |
| 00:04.58 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 00:05.17 | CMoH-notebook | are they stable? |
| 00:05.38 | tharvey | my INHERIT is package_ipk, debian, sanity, recip_sanity, devshell, insane |
| 00:05.39 | khem | CMoH-notebook: yes |
| 00:05.51 | tharvey | you saying most people don't inherit insane? |
| 00:06.32 | khem | tharvey: actually that error makes sense |
| 00:06.37 | khem | but you can live by |
| 00:07.10 | tharvey | its just a QA check so the packages build, but it causes bitbake to return an error code that my build script catches |
| 00:07.27 | tharvey | so I guess I should disable insane for those packages or fix the packages |
| 00:07.40 | tharvey | was just surprised to find them fail the QA check like that |
| 00:07.41 | khem | yeah |
| 00:08.04 | *** join/#oe russ (~russ@206.29.188.235) |
| 00:08.05 | khem | QA checks are nice to err on |
| 00:08.24 | *** join/#oe shoragan_ (~shoragan@sicherheitsschwankung.de) |
| 00:15.00 | *** join/#oe celeron55 (~perttu@a91-155-42-12.elisa-laajakaista.fi) |
| 00:19.23 | *** join/#oe khem (~khem@99-57-141-118.lightspeed.sntcca.sbcglobal.net) |
| 00:24.03 | CIA-68 | 03Khem Raj <raj.khem@gmail.com> 07master * r466148c26e 10openembedded.git/recipes/chumby/chumby-firmware_1.2.bb: |
| 00:24.03 | CIA-68 | chumby-firmware_1.2.bb: Fix typo in COMPATIBLE_MACHINE |
| 00:24.03 | CIA-68 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 00:27.06 | grg | khem, python-numpy needs a COMPATIBLE_ARCH=arm, but it doesn't look like it exists. Any hints? |
| 00:31.14 | grg | and firefox is compatible with i{3,4,5,6}86,powerpc,arm |
| 00:32.18 | khem | grg: there is something called COMPATIBLE_HOST |
| 00:32.52 | khem | you could do COMPATIBLE_HOST = "arm.*" for numpy |
| 00:33.12 | grg | khem, cool |
| 00:33.52 | khem | and COMPATIBLE_HOST = '(powerpc|arm|i.86.*)' for firefox |
| 00:34.38 | *** join/#oe shoragan_ (~shoragan@sicherheitsschwankung.de) |
| 00:34.42 | khem | COMPATIBLE_HOST = '(powerpc|arm|i.86).*' |
| 00:34.47 | khem | seems to be right |
| 00:41.18 | Crofton|work | numpy is another recipe that has been broken recently |
| 00:42.13 | Crofton|work | on some machines |
| 00:43.30 | Tartarus | rt |
| 00:43.31 | Tartarus | er |
| 00:43.45 | Tartarus | grab the mips patches I can only assume exist? :) |
| 00:43.47 | Tartarus | for firefox |
| 00:44.08 | Tartarus | to me, compatible and "happens to build right now" aren't the same thing |
| 00:44.25 | Tartarus | stuff that's very specific to a given HW platform due to being ties to the HW makes sense |
| 00:45.57 | grg | well, the fixes i just sent are for fixing do_unpack problems due to machine/arch specific patch dirs |
| 00:46.25 | Tartarus | Yeah |
| 00:46.40 | Tartarus | still, what I'm saying applies. Someone else can argue the other direction |
| 00:46.53 | Tartarus | But to me, compatible* is a heavy tool |
| 00:47.17 | Tartarus | and means "never going to be work outside of ..." |
| 00:47.32 | grg | i agree with what you're saying, but there isn't really a good alternative. i don't have an interest in fixing every package for my arch |
| 00:47.50 | grg | i have no plans to run firefox on a 300mhz mipsel, for instance |
| 00:48.02 | Tartarus | So, why did you hit this then? |
| 00:48.05 | Tartarus | bitbake world? |
| 00:48.08 | grg | yup |
| 00:48.13 | Tartarus | So don't do that. |
| 00:48.19 | grg | i want bitbake world as a regression test |
| 00:48.32 | grg | it will be a very powerful thing |
| 00:49.07 | Tartarus | in what way? |
| 00:49.11 | khem | Tartarus: I think its fine if some package can work but does not work yet on a given arch |
| 00:49.19 | khem | its better to state that clearly |
| 00:49.33 | Tartarus | khem: That's fine too, but that's not what COMPATIBLE* means to me anyhow |
| 00:49.39 | grg | well if i do a bitbake world on the testing branch each week then its rather obvious to see what has broken in the past week |
| 00:49.53 | khem | if some mips folks need firefox they can fix it and take it out |
| 00:49.58 | grg | its just casting a wider net for testing |
| 00:50.07 | Tartarus | build testing |
| 00:50.11 | khem | Tartarus: that I would agree |
| 00:50.11 | Tartarus | not usable testing |
| 00:50.20 | grg | its a start |
| 00:50.35 | khem | Tartarus: may be there could be some other var which says on what arch it works |
| 00:50.46 | grg | i cant test usability without buildability. and buildability uncovers large numbers of problems already |
| 00:50.56 | khem | semantically it will be exactly same as comaptible_host |
| 00:51.04 | Tartarus | grg, right |
| 00:51.30 | Tartarus | So I'd say you've run into software that should be fixed to compile |
| 00:51.34 | Tartarus | Or proven it can't be |
| 00:51.47 | Tartarus | world will build a lot of stuff you'll never build on your 300mhz mipsel |
| 00:51.59 | Tartarus | But otoh maybe you would try fennec |
| 00:52.00 | grg | i have finite resources. i cant get distracted by everything. |
| 00:52.03 | Tartarus | So you'd need to fix firefox anyhow |
| 00:52.21 | Tartarus | grg, So fix firefox as it's a rather easy one to get past your current problem |
| 00:52.40 | Tartarus | did it before, for mips |
| 00:53.00 | khem | ideally the approach should be to fix the package |
| 00:53.10 | *** join/#oe waite (~quassel@c-24-91-81-44.hsd1.ma.comcast.net) |
| 00:53.11 | khem | is such cases |
| 00:53.21 | grg | Tartarus, well if i do that, i should then add mips.* to compatible_host. Because sh4,blackfin,etc is not supported |
| 00:53.40 | Tartarus | So fix sh4 too |
| 00:53.46 | Tartarus | And maybe you do want to COMPATIBLE_OS it |
| 00:53.54 | Tartarus | Of course everything just about might need that :) |
| 00:54.00 | grg | :) |
| 00:54.58 | Tartarus | wonders if jsautoconf.h could be generated with qemu-$arch |
| 00:56.03 | Tartarus | I guess what I'm trying to say is that if you think bitbake world should build something useful, I don't like the idea of saying "oh, we masked out N recipes too rather than port them", without some plan to get back to actually porting them |
| 00:56.17 | Tartarus | You can argue that maybe nios2 is never going to be "fast" enough |
| 00:56.20 | Tartarus | But not MIPS |
| 00:56.59 | grg | I understand your point, but i'm not going to fix every error i come across |
| 00:57.28 | Tartarus | So please come up with a plan to fix them later or try and get someone else to fix them later |
| 00:58.35 | Tartarus | Debian for example looks to have that file for mipsel already |
| 00:58.58 | Tartarus | http://packages.debian.org/hu/lenny/mipsel/libmozjs-dev/filelist |
| 00:59.25 | CIA-68 | 03Cliff Brake <cbrake@bec-systems.com> 07master * rf20e70e0a4 10openembedded.git/recipes/nodejs/nodejs_0.2.1.bb: nodejs: add native support |
| 00:59.41 | Tartarus | (So I guess I'm trying to say if we want a model where bitbake world works, we should try for the debian version of everything builds everywhere as much as is possible) |
| 01:00.07 | JDuke127 | hi , when i try to compile sgx with "bitbake omap3-sgx-modules" , i got error on_compile bc_cat.c:490: error: implicit declaration of function 'omap_rev_lt_3_0' , how to fix this problem ? any solution ? |
| 01:02.25 | CMoH-notebook | do bbappend recipes only work within a bblayer? or is it parsed when simply placed in BBFILES? |
| 01:03.26 | kergoth` | it doesn't have to be a layer, the two pieces of functionality are independent, it uses the filename alone to determine which are appended to which, not the directory structure |
| 01:04.06 | CMoH-notebook | hmm... when was it implemented? i have the git from 2010-09-08 |
| 01:04.27 | kergoth` | git log --grep=append |
| 01:04.29 | kergoth` | is your friend |
| 01:04.34 | CMoH-notebook | kk :) |
| 01:06.26 | CMoH-notebook | yeah, i don't have it |
| 01:07.24 | kergoth | its in master, not 1.10 |
| 01:07.27 | kergoth | just so you know |
| 01:08.08 | CMoH-notebook | ty - i'll fix things |
| 01:13.45 | *** join/#oe GNUtoo|laptop (~gnutoo@host245-55-dynamic.180-80-r.retail.telecomitalia.it) |
| 01:13.45 | *** join/#oe kerim (~kerim@81.214.22.138) |
| 01:15.26 | *** join/#oe russ_ (~russ@206.29.188.235) |
| 01:19.52 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 02:02.09 | *** join/#oe GNUtoo|laptop (~gnutoo@host245-55-dynamic.180-80-r.retail.telecomitalia.it) |
| 02:04.42 | *** join/#oe mithro (~tim@unaffiliated/mithro) |
| 02:30.05 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 02:37.09 | *** join/#oe kevinsc1 (~a0214685@nat/ti/x-lfbzwwqdvtmsqncv) |
| 02:40.57 | *** join/#oe russ_ (foobar@ip70-176-251-1.ph.ph.cox.net) |
| 02:50.00 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 02:50.00 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 03:06.39 | grg | khem, as far as i can tell, the bad libbfd.a comes from emacs |
| 03:06.56 | grg | which has some funky treedir thing |
| 03:12.35 | *** part/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 03:17.49 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 03:17.49 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 03:43.50 | JDuke127 | hi , when i try to compile sgx with "bitbake omap3-sgx-modules" , i got error on_compile bc_cat.c:490: error: implicit declaration of function 'omap_rev_lt_3_0' , how to fix this problem ? any solution ? |
| 03:48.22 | grg | JDuke127, you should post to the mailing list with complete logs. Maybe someone there will be able to help. |
| 03:48.26 | *** part/#oe sorvats (~sorvats@201.250.156.27) |
| 03:49.30 | *** join/#oe gchiii (~gchiii@adsl-76-255-12-150.dsl.mrdnct.sbcglobal.net) |
| 03:50.21 | khem | JDuke127: arch/arm/plat-omap/include/plat/cpu.h |
| 03:50.30 | khem | thats where it is defined |
| 03:56.53 | *** join/#oe borg_ (~olaf@p54869904.dip0.t-ipconnect.de) |
| 03:58.19 | JDuke127 | ok |
| 03:58.22 | JDuke127 | i send it now |
| 03:59.50 | JDuke127 | do_compile logs? |
| 04:00.52 | grg | khem, emacs was a red herring. it just has a libbfd.a with the same checksum in its work dir because it copied it from staging |
| 04:03.39 | JDuke127 | ok i got it |
| 04:03.44 | JDuke127 | now i put it on pastebin |
| 04:04.05 | JDuke127 | grg , http://pastebin.com/SV8i88kt |
| 04:04.09 | JDuke127 | khem |
| 04:04.31 | JDuke127 | <khem> JDuke127: arch/arm/plat-omap/include/plat/cpu.h , i put |
| 04:06.19 | grg | i think khem's point was that on_compile bc_cat.c should be including cpu.h somehow |
| 04:06.41 | JDuke127 | hmm let me look |
| 04:10.11 | JDuke127 | ok |
| 04:10.19 | JDuke127 | grg , http://pastebin.com/aggLfKKA |
| 04:10.29 | JDuke127 | my bc_cat.c file |
| 04:13.23 | JDuke127 | i add this ? #include <arch/arm/plat-omap/include/mach/cpu.h> |
| 04:16.44 | *** join/#oe koobe_ (~koobe@dsl-trebrasgw2-fe4df900-31.dhcp.inet.fi) |
| 04:18.16 | grg | JDuke127, that doesn't look right. Most likely, the kernel makefile(s) should have added arch/arm/plat-omap/include to your include path, and you would have a machine independent include that will pull in the machine dependent file |
| 04:18.31 | grg | e.g. its quite possible you actually want to include <mach/hardware.h> |
| 04:19.09 | grg | does bc_cat.h include anything? |
| 04:20.15 | *** join/#oe kgilmer (~kgilmer@adsl-76-231-184-89.dsl.pltn13.sbcglobal.net) |
| 04:25.17 | JDuke127 | i ve found some error on OMAP Rules.make |
| 04:25.36 | grg | wrong include path? |
| 04:25.37 | JDuke127 | GRAPHICS_INSTALL_DIR=$(HOME)/INVALIDVAL |
| 04:26.01 | JDuke127 | what must i do for that ? |
| 04:26.40 | grg | i don't have an omap, nor do i have the package you are having problems with.... sorry, my assistance can only be of a general nature. |
| 04:26.58 | JDuke127 | /home/kadirbasol/INVALIDVAL/GFX_Linux_KM: No such file or directory. |
| 04:27.10 | JDuke127 | now i tried to make , make myself |
| 04:27.12 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 04:27.27 | JDuke127 | maybe i dont do bitbake will do it in future if compile success? |
| 04:29.28 | JDuke127 | brb |
| 04:32.54 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 05:00.24 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 05:00.47 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 05:10.58 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 05:13.10 | *** join/#oe akumar (~mm4@122.170.27.202) |
| 05:21.01 | *** join/#oe mrc3 (~mrc3@nat/ti/x-bpvotjbcxeyfgbnz) |
| 05:27.38 | *** join/#oe tasslehoff (~Mich@84.49.231.147) |
| 05:42.00 | *** join/#oe d_th (~dth@a89-182-139-35.net-htp.de) |
| 05:48.59 | *** join/#oe svolpe (~Gerrath@unaffiliated/gerrath) |
| 05:49.01 | ka6sox | bugzilla and tinderbox might be offline for a teensy while |
| 05:54.40 | *** join/#oe r0ck_ (b49530f6@gateway/web/freenode/ip.180.149.48.246) |
| 05:55.21 | r0ck_ | hi i am facing problem with bitbake |
| 05:55.45 | r0ck_ | i am behind a proxy and i am unable to download cross compliers and things |
| 05:55.53 | r0ck_ | what to do ? |
| 05:56.04 | r0ck_ | i am stuck for about 2 days |
| 05:56.15 | r0ck_ | please someone help me |
| 05:56.17 | r0ck_ | ?? |
| 05:56.57 | r0ck_ | i want cross complier for gumstix |
| 05:57.05 | r0ck_ | please help me? |
| 05:58.54 | r0ck_ | ???? |
| 05:59.11 | r0ck_ | anyone ?????????? |
| 05:59.24 | ka6sox | 11pm in California...7am in .eu |
| 05:59.47 | ka6sox | patience will probably be the best thing now. |
| 05:59.55 | ka6sox | back to working on the servers. |
| 06:02.14 | r0ck_ | ???? |
| 06:02.20 | r0ck_ | any one alive?? |
| 06:04.34 | *** join/#oe methril (~methril@189.27.129.125.dynamic.adsl.gvt.net.br) |
| 06:05.45 | CIA-68 | 03Yann Dirson <ydirson@altern.org> 07master * r287f5ec79c 10openembedded.git/recipes/git/git_1.7.0.2.bb: (log message trimmed) |
| 06:05.46 | CIA-68 | git: split space-hungry rarely-used commands into -perltools and -large packages. |
| 06:05.46 | CIA-68 | This trims the main package by ~75%, and split of all perl scripts allows |
| 06:05.46 | CIA-68 | to spare the installation of perl, which is no small bargain either. |
| 06:05.46 | CIA-68 | Note that git-remote-http triggers a strange bug (OE#5465), so it is not |
| 06:05.46 | CIA-68 | split out for now. |
| 06:05.46 | CIA-68 | Also drop cpio dependency, which has been unneeded since a number of git |
| 06:05.47 | CIA-68 | 03Graham Gower <graham.gower@gmail.com> 07master * r71d25fe210 10openembedded.git/recipes/mupdf/ (3 files in 2 dirs): |
| 06:05.48 | CIA-68 | mupdf_0.6.bb: remove recipe. |
| 06:05.48 | CIA-68 | This is now an old release. Much better to use git version instead, |
| 06:05.49 | CIA-68 | as the release tarballs get moved once a new release occurs. |
| 06:05.54 | CIA-68 | Signed-off-by: Graham Gower <graham.gower@gmail.com> |
| 06:05.54 | CIA-68 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 06:05.54 | CIA-68 | 03Graham Gower <graham.gower@gmail.com> 07master * recebb10a37 10openembedded.git/recipes/mythfront/mythfront-config.bb: |
| 06:05.54 | CIA-68 | mythfront-config.bb: Fix do_unpack for machines other than epia. |
| 06:05.55 | CIA-68 | Signed-off-by: Graham Gower <graham.gower@gmail.com> |
| 06:05.55 | CIA-68 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 06:05.56 | CIA-68 | 03Yann Dirson <ydirson@altern.org> 07master * r50fc7462c4 10openembedded.git/recipes/git/git_1.7.0.2.bb: |
| 06:05.56 | CIA-68 | git: replace remaining broken hardlinks with symlinks. |
| 06:05.57 | CIA-68 | Signed-off-by: Yann Dirson <ydirson@altern.org> |
| 06:05.57 | CIA-68 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 06:05.58 | CIA-68 | 03Graham Gower <graham.gower@gmail.com> 07master * rcffcd879fd 10openembedded.git/recipes/opkg/opkg.inc: (log message trimmed) |
| 06:05.58 | CIA-68 | opkg: disable GPLv3 code. |
| 06:06.11 | CIA-68 | 03Yann Dirson <ydirson@altern.org> 07master * r2823e121e8 10openembedded.git/recipes/git/ (git-native_1.7.0.2.bb git.inc git_1.7.0.2.bb): (log message trimmed) |
| 06:06.11 | CIA-68 | git: activate gitk. |
| 06:06.11 | CIA-68 | It does not work perfectly (complains about possible problems in the tcl |
| 06:06.11 | CIA-68 | package), and buttons are huge, but it allows to browse history. |
| 06:06.12 | CIA-68 | git-gui OTOH does not start at all, it only complains that tk is not |
| 06:06.13 | CIA-68 | correctly installed, so it is commented out. |
| 06:06.13 | CIA-68 | Signed-off-by: Yann Dirson <ydirson@altern.org> |
| 06:06.24 | r0ck_ | ?? |
| 06:09.53 | CIA-68 | 03Michal Minar <i@minami.cz> 07master * rf52590bd49 10openembedded.git/recipes/grub/ (grub-0.97/grub-support-256byte-inode.diff grub_0.97.bb): (log message trimmed) |
| 06:09.54 | CIA-68 | grub 0.97: fixing broken 256byte-inodes patch |
| 06:09.54 | CIA-68 | * original patch causes termination of grub with floating point exception, |
| 06:09.54 | CIA-68 | when operating upon ext2 partitions |
| 06:09.54 | CIA-68 | * the bug description came from: |
| 06:09.54 | CIA-68 | http://bugs.gentoo.org/show_bug.cgi?id=220687 |
| 06:09.55 | CIA-68 | * fixed patch was done by RB <aoz.syn@gmail.com> |
| 06:11.29 | *** join/#oe GNUtoo|laptop (~gnutoo@host245-55-dynamic.180-80-r.retail.telecomitalia.it) |
| 06:11.48 | CIA-68 | 03Khem Raj <raj.khem@gmail.com> 07master * rde6f06e7d5 10openembedded.git/recipes/libnl/ (libnl2_git.bb libnl_1.1.bb): |
| 06:11.48 | CIA-68 | libnl: Update the homepage url and download urls |
| 06:11.48 | CIA-68 | * Move the git recipe to tip of git. |
| 06:11.48 | CIA-68 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 06:16.03 | *** join/#oe CMoH-office (~cipi@unaffiliated/c-moh) |
| 06:19.28 | *** join/#oe vps (~vitus@145.253.169.210) |
| 06:24.35 | tasslehoff | khem: morning |
| 06:25.23 | tasslehoff | thought I'd see if the latest patches fixed my sdk-issue, but which patches from you and/or ericben|away should I use? |
| 06:26.25 | grg | Is there some simple way of determining which recipe staged which file(s) while using rm_work? |
| 06:27.53 | CIA-68 | 03Rui Miguel Silva Seabra <rms@1407.org> 07org.openembedded.dev * ra08ed37b1e 10openembedded.git/recipes/omnewrotate/omnewrotate_svn.bb: |
| 06:27.54 | CIA-68 | omnewrotate: bump SRCREV |
| 06:27.54 | CIA-68 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 06:27.55 | CIA-68 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rc8a0ee39a2 10openembedded.git/recipes/linux/ (21 files in 2 dirs): |
| 06:27.55 | CIA-68 | linux-openmoko-2.6.34: upgrade to 2.6.34.7 and add patch for lower power consumption in suspend |
| 06:27.55 | CIA-68 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 06:32.00 | *** join/#oe JaMa (~martin@161-24.13.24.78.awnet.cz) |
| 06:33.45 | *** join/#oe kgilmer (~kgilmer@adsl-76-231-184-89.dsl.pltn13.sbcglobal.net) |
| 06:37.31 | mckoan | good morning |
| 06:57.11 | *** join/#oe Heinervdm_ (~thomas@pD9E16705.dip.t-dialin.net) |
| 06:58.29 | *** join/#oe Heinervdm (~thomas@pD9E16705.dip.t-dialin.net) |
| 06:58.48 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 07:05.55 | *** join/#oe josh__ (~josh@174-17-226-5.phnx.qwest.net) |
| 07:08.11 | *** join/#oe pb__ (~pb@blundell.swaffham-prior.co.uk) |
| 07:10.13 | *** join/#oe cyberdeck (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 07:10.16 | *** join/#oe kristoffer (~kristoffe@c-27dee555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 07:16.35 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * re9375f6ec6 10openembedded.git/recipes/netbase/netbase_4.21.bb: |
| 07:16.35 | CIA-68 | netbase: bump PR after 56fa8d7ad350fcbb5dedaa80c656da0bb59a2e7b |
| 07:16.35 | CIA-68 | caught by angstrom testlab: http://gitorious.org/angstrom/angstrom-testlab/commit/2cca591bdb5110fe2bd0f090092645d02c6b8e1a |
| 07:16.37 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r924c62c1c4 10openembedded.git/recipes/alsa/alsa-state.bb: |
| 07:16.37 | CIA-68 | alsa-state: bump PR after 56fa8d7ad350fcbb5dedaa80c656da0bb59a2e7b |
| 07:16.37 | CIA-68 | caught by angstrom testlab: http://gitorious.org/angstrom/angstrom-testlab/commit/bfa0eab7743be68515c730d86fd6cb9b30eb5ef2 |
| 07:23.51 | *** join/#oe dth_ntb (~dth@a89-182-2-103.net-htp.de) |
| 07:30.33 | *** join/#oe CMoH-notebook (~cipi@95.76.71.81) |
| 07:30.33 | *** join/#oe CMoH-notebook (~cipi@unaffiliated/c-moh) |
| 07:31.21 | hrw | morning |
| 07:32.02 | hrw | grg: check files in pstage dir? |
| 07:41.28 | grg | hrw, thanks, will play tomorrow |
| 07:43.17 | *** join/#oe Proxyles (~henrik@c-9f93e255.56-4-64736c14.cust.bredbandsbolaget.se) |
| 07:44.46 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 07:55.54 | *** join/#oe dos1 (~dos@emn90.internetdsl.tpnet.pl) |
| 07:55.54 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 07:56.11 | ericben | hi |
| 07:57.02 | tasslehoff | ericben: morning. I applied the patches I suspected were relevant. compiling now. |
| 07:57.26 | *** join/#oe GarthPS (~quassel@92.102.66.79) |
| 07:57.43 | ericben | tasslehoff: you can take khem's patch ++ mine for gdb-cross-sdk until I manage to get gdb link ncurses libs statically |
| 07:59.02 | hrw | for information: I will add Linaro gcc into OpenEmbedded |
| 07:59.19 | tasslehoff | ericben: that's the only one I didn't pull in :). I changed mpfr, gmp and gcc-cross. |
| 08:00.15 | ericben | well for the others, khem's patch fixe the problem |
| 08:00.29 | ericben | hrw: interesting, their bench on arm seems promising |
| 08:00.50 | hrw | ericben: I know, I work for them |
| 08:01.01 | ericben | yes I've seen you effort on the packagin ;) |
| 08:01.54 | ericben | if one day you can ask linaro's marketing to write a what is linaro for dummies, this would be great as I still don't understand the goals of this project |
| 08:06.50 | hrw | my view is that Linaro is doing all to make ARM work faster and make platform less complicated |
| 08:07.14 | hrw | ARM kernel compared to x86 kernel is totally other world |
| 08:07.31 | hrw | lot of platform related code, kernels bound to machines |
| 08:07.54 | hrw | on x86 you can build kernel which will boot and work on most of machines. on arm you can't |
| 08:08.10 | hrw | but Linaro works on making single kernel work on many ARM devices |
| 08:08.52 | tasslehoff | ericben: after compiling with khem's patch from .dev, my sdk only contains libmpfr for arm. is the upstream patch not the latest version? |
| 08:16.17 | ericben | hrw: do you think this is a critical feature to be able to boot one kernel on many ARM devices ? |
| 08:16.53 | ericben | except for having a ubuntu for ARM easy to install |
| 08:17.26 | ericben | my understanding is that most products manufacturer customize their kernel which makes it platform dependent |
| 08:18.25 | ericben | anyway, I hope Linaro's kernel will bring better support of i.MX51 in the mainline kernel, especially for video & multimedia features |
| 08:19.58 | ericben | tasslehoff: khem's patch make all these libs compiled statically in gcc |
| 08:20.08 | soltys | morning |
| 08:20.39 | tasslehoff | ericben: ah, so I shouldn't find the files in my sdk. |
| 08:21.34 | ericben | do a readelf -d on gcc & cc1plus in the sdk to check |
| 08:24.47 | tasslehoff | ericben: cc1plus lists mpfr and gmp as needed |
| 08:25.29 | tasslehoff | ericben: I tried cleaning gmp, mpfr, gcc-cross and my toolchain-recipe. now recompiling |
| 08:26.15 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r284286b126 10openembedded.git/recipes/xorg-lib/ (7 files in 2 dirs): |
| 08:26.15 | CIA-68 | pixman 0.19.4: add latest release from the unstable series |
| 08:26.15 | CIA-68 | * forward port the overlapped blit patches |
| 08:26.15 | CIA-68 | * add NEON optimization for 16bpp |
| 08:26.15 | CIA-68 | * fix fast path flags for PAD |
| 08:27.17 | ericben | tasslehoff: clean & build gdb-cross-sdk |
| 08:33.00 | *** join/#oe B_Lizzard (~havoc@athedsl-430041.home.otenet.gr) |
| 08:36.49 | *** join/#oe florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 08:36.49 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:43.04 | florian | good morning |
| 08:43.26 | mckoan | hi florian |
| 08:43.34 | florian | hi mckoan |
| 08:45.02 | tasslehoff | ericben: it still needs those libraries shared. could I be missing a patch? |
| 08:45.50 | ericben | tasslehoff: I'll retest and let you know |
| 08:48.31 | ericben | tasslehoff: here cc1plus ont needs libc.so.6 |
| 08:48.37 | ericben | only needs |
| 08:48.59 | ericben | so there is something wrong in your tree$ |
| 08:50.33 | tasslehoff | ericben: and you don't have any local patches / patches not in .dev yet? |
| 08:51.05 | ericben | only khem's commit 03ba2d4f86360abbcfed2a7350a93d3b3777f280 |
| 08:52.30 | tasslehoff | ericben: where/how can I find that one? |
| 08:52.37 | tasslehoff | find/apply |
| 08:52.53 | ericben | using git |
| 08:53.47 | ericben | or you go through cgit generate the patch and apply it on your tree http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=03ba2d4f86360abbcfed2a7350a93d3b3777f280 |
| 08:54.32 | tasslehoff | ericben: that much I understood :-). so this is a commit in upstream but not yet in .dev, that I can (somehow) pull? |
| 08:54.35 | tasslehoff | thanks |
| 08:55.39 | ericben | it is in dev |
| 08:55.47 | ericben | git cherry pick the commit |
| 08:56.17 | tasslehoff | ericben: yeah. I see I already have it... I'm tempted to throw out my TMPDIR and rebuild everything. |
| 08:56.51 | ericben | tasslehoff: did you remove my patches ? |
| 08:57.04 | ericben | and only keep khem's one |
| 08:57.25 | tasslehoff | ericben: yes. was that a bad move? |
| 08:59.06 | ericben | tasslehoff: maybe you also need to rebuild gmp-native libelf-native libmpc-native and mpfr-native then gcc-cross-sdk |
| 08:59.18 | ericben | else the static libs are not yet built |
| 08:59.56 | tasslehoff | ericben: ok. should I keep your patches, or do I only need khem's? |
| 09:00.05 | ericben | only khem's one |
| 09:30.04 | *** join/#oe rsalveti (~rsalveti@201.82.70.219) |
| 09:31.31 | tasslehoff | ericben: that did the trick :) |
| 09:31.39 | tasslehoff | thanks for the coaching |
| 09:32.10 | hrw | ~curse new patch.bbclass |
| 09:32.10 | ibot | May the fleas of a thousand camels infest your most sensitive regions, new patch.bbclass ! |
| 09:37.02 | *** join/#oe Proxyles (~henrik@95.209.184.77.bredband.tre.se) |
| 09:44.05 | *** join/#oe pvanhoof (~pvanhoof@217.22.63.163.static.hosted.by.easyhost.be) |
| 10:25.32 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 10:40.12 | *** join/#oe xeon-enouf (~xeon-enou@unaffiliated/xeon-enouf) |
| 11:04.34 | *** join/#oe kristoffer (~kristoffe@c-27dee555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 11:13.01 | *** join/#oe Crofton (~balister@pool-96-240-180-126.ronkva.east.verizon.net) |
| 11:18.26 | *** join/#oe woglinde (~heinold@g225005123.adsl.alicedsl.de) |
| 11:19.58 | *** join/#oe GNUtoo|laptop (~gnutoo@host245-55-dynamic.180-80-r.retail.telecomitalia.it) |
| 11:30.10 | *** join/#oe cjjnjust (~cjjnjust@2001:da8:100e:4797:223:8bff:fe76:39db) |
| 11:43.38 | CIA-68 | 03Steffen Sledz <sledz@dresearch.de> 07org.openembedded.dev * r0a543300de 10openembedded.git/recipes/libunwind/libunwind.inc: |
| 11:43.38 | CIA-68 | libunwind: unbreak native build |
| 11:43.38 | CIA-68 | Signed-off-by: Steffen Sledz <sledz@dresearch.de> |
| 11:44.28 | *** join/#oe otavio (~otavio@debian/developer/otavio) |
| 11:47.43 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 12:03.00 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 12:06.44 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 12:08.31 | CIA-68 | 03Sergey Stasishin <stasishin@speechpro.com> 07org.openembedded.dev * r48031c31dd 10openembedded.git/recipes/live555/live555.inc: live555: Packaging live555MediaServer too. |
| 12:08.33 | *** join/#oe ldnunes (~ldnunes@189.114.111.55) |
| 12:12.43 | *** join/#oe cjjnjust (~cjjnjust@2001:da8:100e:4797:223:8bff:fe76:39db) |
| 12:20.24 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 12:31.11 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 12:33.16 | *** join/#oe rob_w (~bob@pD95ECF13.dip.t-dialin.net) |
| 12:36.23 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 12:45.44 | *** join/#oe rednul_ (~rednul@host-174-45-250-246.bln-mt.client.bresnan.net) |
| 12:53.10 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 13:07.08 | CIA-68 | 03Michael Lippautz <michael.lippautz@gmail.com> 07org.openembedded.dev * r7dda7044c7 10openembedded.git/ (3 files in 3 dirs): |
| 13:07.08 | CIA-68 | x-load/igep0020.conf: Unbreak x-load for igep0020 machine. |
| 13:07.08 | CIA-68 | * x-load is needed since e2b9225af36b2979b255634f79ceecea482601a7 |
| 13:07.08 | CIA-68 | Signed-off-by: Michael Lippautz <michael.lippautz@gmail.com> |
| 13:07.08 | CIA-68 | Acked-by: Eric Bénard <eric@eukrea.com> |
| 13:09.44 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 13:11.44 | *** join/#oe waite (~quassel@206.83.81.178.ptr.us.xo.net) |
| 13:15.19 | *** join/#oe udovdh (~udovdh@pindarots.xs4all.nl) |
| 13:27.51 | *** join/#oe xobs (~smc@cm234.psi175.maxonline.com.sg) |
| 13:33.00 | *** join/#oe dth_ntb (~dth@212.23.103.23) |
| 13:43.32 | *** join/#oe grund (~grund@firebug.buglabs.net) |
| 13:46.08 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 13:49.51 | *** join/#oe kevinsc (~a0214685@nat/ti/x-vlsfrnqwmyolpheu) |
| 13:52.04 | *** join/#oe rschus (~rschus@103.176.73-86.rev.gaoland.net) |
| 13:53.34 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 13:56.02 | *** join/#oe koobe_ (~koobe@dsl-trebrasgw2-fe4df900-31.dhcp.inet.fi) |
| 13:58.47 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 14:03.57 | *** join/#oe etrunko (~edulima@187.75.148.141) |
| 14:11.25 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 14:17.42 | *** join/#oe Proxyles (~henrik@95.209.136.37.bredband.tre.se) |
| 14:22.31 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
| 14:24.55 | *** join/#oe aafuentes (~mswl@140.87.117.91.dynamic.mundo-r.com) |
| 14:26.18 | *** join/#oe dos1 (~dos@adfx17.neoplus.adsl.tpnet.pl) |
| 14:26.18 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 14:29.08 | *** join/#oe stefan_schmidt (~stefan@p5B03577C.dip.t-dialin.net) |
| 14:29.54 | woglinde | hi stefan |
| 14:30.02 | stefan_schmidt | hi woglinde |
| 14:30.14 | stefan_schmidt | hi all |
| 14:37.09 | kergoth | damn, i want pdb to have ipython's interface with tab completion |
| 14:38.08 | woglinde | pdb? |
| 14:38.20 | kergoth | python debugger |
| 14:38.27 | woglinde | hm oh |
| 14:38.30 | woglinde | never used it |
| 14:38.48 | kergoth | i haven't used it much, working on doing so |
| 14:38.52 | kergoth | can be quite handy |
| 14:38.59 | woglinde | fighting with busybox again? |
| 14:39.54 | kergoth | not sure how a python debugger would help with busybox :) |
| 14:42.47 | woglinde | args bitbake |
| 14:42.48 | woglinde | sorry |
| 14:42.56 | woglinde | I am tired |
| 14:42.58 | woglinde | somehow |
| 14:43.35 | kergoth | hehe |
| 14:43.41 | kergoth | looking into memory usage |
| 14:43.51 | *** join/#oe pH5 (~ph5@e178213135.adsl.alicedsl.de) |
| 14:44.10 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 14:46.50 | woglinde | *g* |
| 14:46.53 | woglinde | haha |
| 14:46.56 | woglinde | yeah 2 gig |
| 14:48.50 | kergoth | yeah, its a tad excessive |
| 14:49.13 | kergoth | i'm wondering if it would help to store the cache in an sql database, rather than pickling/unpickling the giant dict to/from memory/disk |
| 14:49.32 | kergoth | then that 150+mb pile of dicts would stay out of ram -- but i don't know how well itd perform |
| 14:49.38 | woglinde | hm dont we already have a sqlite stuff? |
| 14:49.41 | kergoth | will have to see if RP has played with that |
| 14:49.56 | kergoth | persist_data uses sqlite, for things like the rev incrementing for SRCREV stuff |
| 14:50.06 | kergoth | the metadata cache is just a pickled dictionary |
| 14:52.29 | *** join/#oe kergoth` (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 14:52.34 | woglinde | re kergoth |
| 14:52.53 | kergoth | hey other me |
| 14:52.57 | kergoth | kicks windows box |
| 14:53.17 | woglinde | hm mentor needs you to use windows |
| 14:54.37 | Tartarus | not exactly, heh |
| 14:55.07 | kergoth` | naw, thats my own box i'm kicking |
| 14:55.12 | kergoth` | :) |
| 14:55.48 | kergoth` | landscapers decided to start using a wood chipper and chainsaw to break up a tree about 20 feet from our window at 6:30am this morning |
| 14:55.51 | kergoth` | shakes fist |
| 14:56.09 | kergoth` | glad i was getting up anyway |
| 14:56.16 | kergoth` | ooh |
| 14:56.23 | kergoth` | apparently ipython *does* have an enhanced pdb shell |
| 14:56.27 | kergoth` | ipython -pdb will do it |
| 14:56.32 | kergoth` | tests |
| 14:56.51 | kergoth` | ah.. hmm |
| 14:57.23 | kergoth` | that'll only load it on seeing an exception, though. would need to manually force it to run programmatically from the code |
| 15:02.39 | denix | khem: I don't think this is necessary: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=466148c26e4ce92d708e9b4e4368c4cd6fc87a0b |
| 15:02.58 | woglinde | hi denix |
| 15:03.08 | denix | woglinde: hey |
| 15:05.28 | denix | kergoth: have you looked at do_unpack()? let me know what kind of help/data you need from me... :) |
| 15:05.44 | kergoth | been wrapped up in a task for work |
| 15:05.56 | kergoth | the thing is, urldata is initialized from SRC_URI |
| 15:06.09 | woglinde | denix simplify do_unpack? |
| 15:06.11 | kergoth | so it makes no sense that it would magically get entries from SRC_URI modifications that weren't applied |
| 15:06.40 | kergoth | look at bitbake/lib/bb/fetch/__init__.py |
| 15:06.49 | kergoth | see the init() and urldata stuff |
| 15:07.17 | kergoth | the new unpack uses urldata, so that's where the problem must lie, or its in the metadata's calls to bb.fetch.init() somehow (but doubtful) |
| 15:08.50 | denix | woglinde: http://thread.gmane.org/gmane.comp.handhelds.openembedded/36703/focus=37192 |
| 15:09.03 | denix | kergoth: I'll take a look at urldata code |
| 15:09.37 | kergoth | denix: as a workaround, you could change it to iterate over SRC_URI directly again, without reverting the rest of the cleanup commit, just change that one behavior back |
| 15:09.46 | denix | kergoth: basically it fails for me with amend stuff, but for Frans it's slithly different - with SRC_URI_<mach> |
| 15:10.11 | denix | kergoth: let me try that |
| 15:10.17 | kergoth | SRC_URI_<mach> shouldn't leak into SRC_URI unless <mach> is in overrides, so this is why it makes no sense that itd end up trying to unpack it in the non-mach case |
| 15:10.26 | kergoth | they're two separate variables |
| 15:10.36 | kergoth | so i dont see how it could end up in the urldata |
| 15:10.39 | kergoth | makes no sense |
| 15:11.42 | denix | kergoth: maybe my case makes more sense to you... :) |
| 15:12.20 | kergoth | perhaps, but it may have its roots in the same behavior |
| 15:13.09 | denix | basically, original recipe sets SRC_URI="somesources${RC}.tgz" and RC="", but then in amend.inc I set RC to something else and it tries to unpack both with -rc and without... |
| 15:13.58 | kergoth | hmm, that one does make more sense |
| 15:14.12 | kergoth | the thing with amend.inc is, the amend.inc is loaded during the anonymous python function execs |
| 15:14.29 | kergoth | so if an anonymous python function ran before the amend.bbclass one which did a bb.fetch.init() against SRC_URI ... |
| 15:14.32 | kergoth | you see the problem |
| 15:14.44 | kergoth | best to switch back to SRC_URI direct usage for the time being I think |
| 15:14.53 | kergoth | bb.fetch needs a rework anyway |
| 15:15.15 | denix | is it bb.fetch problem? or is it shared with unpack? |
| 15:15.36 | denix | as it only fetches the correct file, but tries to unpack both... |
| 15:15.42 | kergoth | yes.. and? |
| 15:16.00 | kergoth | bb.fetch also maintains the urldata from the SRC_URI |
| 15:16.11 | kergoth | the whole concept of which is wrong |
| 15:16.23 | kergoth | the do_unpack cleanup made it use that urldata rather than SRC_URI directly |
| 15:16.47 | kergoth | so again, revert that portion of the unpack cleanup for now, and in the long run urldata will go away in favor of something less crappy |
| 15:16.48 | denix | does do_fetch use bb.fetch? |
| 15:16.52 | kergoth | ... |
| 15:17.00 | kergoth | of course it does, thats all it uses |
| 15:17.04 | kergoth | what else would it use? |
| 15:17.15 | kergoth | so does unpack, because bb.fetch is what knows where the local paths are for the urls |
| 15:17.18 | denix | then I wonder why do_fetch works fine |
| 15:17.38 | kergoth | don't know, don't give a shit |
| 15:17.43 | denix | :) |
| 15:17.54 | denix | fine, I won't bother you any more :) |
| 15:17.57 | kergoth | like i said, the whole concept is flawed, its not surprising there's issues with it |
| 15:17.58 | *** join/#oe kgilmer (~kgilmer@adsl-76-231-184-89.dsl.pltn13.sbcglobal.net) |
| 15:18.04 | kergoth | so go back to not using it |
| 15:18.12 | kergoth | i thought it was functional, but clearly it can't be trusted |
| 15:18.14 | denix | I'll try that, thanks |
| 15:18.26 | kergoth | np, thanks for your patience, didn't expect any breakage |
| 15:19.20 | kergoth | it seems like urldata was intended to be a sort of a cache of the broken up urls |
| 15:19.33 | woglinde | hi kgilmer |
| 15:19.36 | kergoth | but come on, breaking up a url isn't exactly system intensive, and if it needed to be cached, it could be done much much cleaner than it is |
| 15:19.45 | kergoth | and, it doesn't cache based on the SRC_URI contents |
| 15:19.46 | kgilmer | hi woglinde |
| 15:19.54 | kergoth | so changing it doesn't invalidate the cached information |
| 15:19.57 | kergoth | its just a mess |
| 15:20.01 | woglinde | kgilmer in sf now? |
| 15:20.14 | kgilmer | yep |
| 15:20.18 | kgilmer | leaving this afternoon woglinde |
| 15:20.23 | kergoth | also, bb.fetch is tightly bound to the metadata, which is just stupid |
| 15:20.34 | kergoth | why can't i construct a fetcher and pass it a url and a destination path, and some options, and have it fetch? |
| 15:20.40 | kergoth | it doesn't need to poke at metadata variables itself.. |
| 15:20.51 | kergoth | </rant> |
| 15:21.09 | denix | good point about the independent fetcher... |
| 15:22.26 | kergoth | the concept of fetching is pretty basic, its a utility module, not tied into bitbake or oe at all, really.. |
| 15:22.29 | kergoth | heh |
| 15:22.32 | kergoth | anyway.. |
| 15:22.55 | kergoth | it should be pretty straightforward to switch back the iteration |
| 15:23.03 | kergoth | just look at the cleanup commit to see how it was done previously |
| 15:23.09 | kergoth | if you don't get to it i'll take a look in a while |
| 15:23.28 | *** join/#oe akumar1 (~mm4@122.170.27.202) |
| 15:26.09 | *** join/#oe hoj (~hoj@75-147-191-205-Washington.hfc.comcastbusiness.net) |
| 15:33.38 | *** join/#oe B_Lizzard (~havoc@athedsl-430041.home.otenet.gr) |
| 15:35.40 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 15:38.32 | *** join/#oe dth_ntb (~dth@a89-182-139-35.net-htp.de) |
| 15:39.05 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 15:42.30 | *** join/#oe hollisb (~hollisb@c-24-20-193-174.hsd1.or.comcast.net) |
| 15:43.22 | *** part/#oe grund (~grund@firebug.buglabs.net) |
| 15:56.26 | CIA-68 | 03Cliff Brake <cbrake@bec-systems.com> 07org.openembedded.dev * r80cfc923d7 10openembedded.git/recipes/qgears/ (3 files in 2 dirs): qgears: add recipe (used to test perf) |
| 15:57.36 | *** join/#oe kgilmer (~kgilmer@us-0271-s0-1-0.oracle.com) |
| 15:59.44 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 16:03.07 | *** join/#oe anarsoul (~anarsoul@86.57.155.118) |
| 16:05.04 | *** join/#oe woglinde_ (~heinold@f052066151.adsl.alicedsl.de) |
| 16:05.27 | *** join/#oe andyj (~andy@174-31-132-3.tukw.qwest.net) |
| 16:15.21 | *** join/#oe dth_ntb (~dth@a89-182-139-35.net-htp.de) |
| 16:21.12 | *** join/#oe grund (~grund@firebug.buglabs.net) |
| 16:25.29 | Crofton|work | anyone have any thoughts on theis python-pyqt build failure |
| 16:25.31 | Crofton|work | http://pastebin.com/KkzY9s31 |
| 16:25.40 | *** join/#oe dos11 (~dos@adku226.neoplus.adsl.tpnet.pl) |
| 16:25.40 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
| 16:28.01 | *** part/#oe grund (~grund@firebug.buglabs.net) |
| 16:31.33 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 16:41.53 | *** join/#oe pcacjr (~pcacjr@187.59.125.211) |
| 16:41.53 | *** join/#oe pcacjr (~pcacjr@unaffiliated/pcacjr) |
| 16:43.01 | *** join/#oe tmbinc (abcd@83.141.3.59) |
| 16:43.28 | CIA-68 | 03Thomas Zimmermann <ml@vdm-design.de> 07org.openembedded.dev * rd2d7afd76a 10openembedded.git/recipes/python/python-pybluez_0.18.bb: |
| 16:43.28 | CIA-68 | python-pybluez: update to version 0.18 |
| 16:43.28 | CIA-68 | Signed-off-by: Thomas Zimmermann <ml@vdm-design.de> |
| 16:52.54 | *** join/#oe Russ (~russ@149-149-169-215-142.nat.asu.edu) |
| 16:54.29 | Heinervdm | Crofton|work: http://bugs.calibre-ebook.com/ticket/1935 it seems that's an error with qt 4.4.3 |
| 16:55.57 | Crofton|work | thanks |
| 16:56.00 | Crofton|work | good tip :) |
| 17:01.47 | Crofton|work | eFfeM_work, pig |
| 17:01.50 | Crofton|work | er |
| 17:01.51 | Crofton|work | ping |
| 17:03.30 | broonie | heh |
| 17:04.49 | Crofton|work | broonie, a friend of mine thinks he can change the sample rate on the TI beagle codec via i2c |
| 17:04.55 | Crofton|work | does this amke sense to you? |
| 17:05.13 | broonie | He posted to the ALSA list overnight? |
| 17:05.31 | Crofton|work | hmm |
| 17:05.33 | Crofton|work | not sure |
| 17:05.38 | Crofton|work | Al Fayez? |
| 17:05.55 | broonie | Yes. |
| 17:06.01 | Crofton|work | He's a wireless engineer by education, not an embedded guy |
| 17:06.02 | Crofton|work | :) |
| 17:06.22 | broonie | I don't know if the hardware is capable of it but he's completely off base WRT implementation. |
| 17:06.26 | Crofton|work | notes that he is a wireless guy also |
| 17:06.30 | Crofton|work | heh :) |
| 17:06.35 | *** join/#oe svolpe (~Gerrath@unaffiliated/gerrath) |
| 17:06.45 | broonie | He wants to write directly to the registers of the CODEC, ignoring the whole "driver" thing we've got going. |
| 17:06.56 | Crofton|work | he is "hacking" becuase I suspect he is desrperate to make something work for his professor |
| 17:07.04 | broonie | I was leaving that one to Liam t answer since it's TI stuff. |
| 17:07.45 | Crofton|work | it would be really handy for me also to set the clock to odd values |
| 17:08.00 | Crofton|work | maybe I should see if alsa list is available via gmane |
| 17:08.22 | Crofton|work | He's basically a good guy, just out of his area of expertise |
| 17:08.47 | Crofton|work | speaking of over his had |
| 17:09.05 | Crofton|work | I am going to copy this python recipe and change the src uri and see if it works :) |
| 17:09.15 | broonie | It's in gmane, yes. |
| 17:09.38 | broonie | He also needs to fix his MUA to do the word wrapping thing. |
| 17:10.15 | Crofton|work | dev or user? |
| 17:11.04 | broonie | devel |
| 17:12.13 | Crofton|work | libsamplerate eats his processor :) |
| 17:12.24 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 17:12.59 | Crofton|work | hearts gmane |
| 17:13.19 | Crofton|work | jesus, he posted from aol webmail |
| 17:13.43 | broonie | Quite. |
| 17:13.56 | broonie | (this was also part of why I didn't rush to answer) |
| 17:14.06 | *** join/#oe mhnoyes (~mhnoyes@184-12-248-50.dr01.myck.or.frontiernet.net) |
| 17:14.08 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 17:14.39 | Crofton|work | I have the thunderbird plugin that lets me know these things for the same reason |
| 17:15.03 | broonie | I don't have a plugin I just notice the stuff rendering very poorly in mutt/vim. |
| 17:15.14 | Crofton|work | well, I'll watch the thread and if he gets any good suggestions I can always walk over and beat him |
| 17:20.05 | Crofton | fark |
| 17:20.15 | Crofton | pyqt-4.4.3 is ancient |
| 17:20.27 | Crofton | looks like current version is 4.7.7 |
| 17:22.36 | ericben | Crofton: see http://www.pyside.org/ this is written by nokia because of the licensing issues with pyqt |
| 17:23.38 | Crofton|work | what is the licensing issue? |
| 17:24.07 | ericben | pyqt : Unlike Qt, PyQt v4 is not available under the LGPL. You can purchase the commercial version of PyQt here. |
| 17:24.12 | ericben | http://www.riverbankcomputing.co.uk/software/pyqt/intro |
| 17:24.44 | ericben | cf 3rd faq here : http://www.pyside.org/faq/ |
| 17:24.51 | Crofton|work | so gpl only? |
| 17:25.47 | ericben | gpl v2 & v3 |
| 17:26.26 | ericben | http://www.riverbankcomputing.co.uk/software/pyqt/license |
| 17:27.06 | Crofton | ok |
| 17:28.05 | ericben | that's not a major problem for many usage, only for closed source applications developers |
| 17:28.15 | Crofton|work | yeah |
| 17:28.28 | *** join/#oe anarsoul (~anarsoul@80.249.83.140) |
| 17:28.41 | Crofton|work | i am not concerned about that, just that I be able to build gnuradio :) |
| 17:29.05 | Crofton|work | trying a hack to build 4.4.4 with tarball from another site |
| 17:38.28 | julianpid | Hi |
| 17:38.53 | julianpid | How can I prevent OE from stripping my binaries in a specific package ? |
| 17:42.13 | ericben | julianpid: PACKAGE_STRIP = "no" |
| 17:43.27 | julianpid | thx |
| 17:43.28 | Tartarus | but why? |
| 17:43.35 | Tartarus | You can debug by installing the -dbg package |
| 17:43.53 | Tartarus | I say since that's the common reason for not wanting to strip :) |
| 17:44.04 | julianpid | I know |
| 17:44.17 | Tartarus | ok |
| 17:44.52 | julianpid | I'm building a package containings linux headers out of a linux build tree |
| 17:45.24 | *** part/#oe tsaaps (~tsaaps@alpha7.isip.uni-luebeck.de) |
| 17:45.35 | julianpid | and it contains some very simple binaries |
| 17:46.00 | julianpid | I don't want to create a kernel-blah-headers-dbg package |
| 17:46.13 | julianpid | that would be extremely stupid |
| 17:47.20 | julianpid | and useless |
| 17:55.13 | ericben | any opinion on : http://patchwork.openembedded.org/patch/3013/ ? |
| 17:55.45 | ericben | I think actual order of things there can be wrong in many case |
| 17:56.36 | kergoth_ | that sounds questionable to me |
| 17:57.05 | kergoth_ | hmm |
| 17:57.23 | ericben | example here : http://patchwork.openembedded.org/patch/3012/ I need to chown the directories else the daemon can't write it's pid & log file |
| 17:58.07 | ericben | actually after opkg install update-rc tries ot launch the daemon which fails because it can't write it's pid file |
| 17:58.07 | ericben | as the chown is after update-rc |
| 17:58.07 | kergoth_ | ah, yes, makes sense |
| 17:58.17 | kergoth_ | that seems reasonable to me, then |
| 17:59.39 | kergoth_ | anyone have an opinion on http://github.com/kergoth/bitbake/commit/867153dd26fdcf31b28355b743a1ac0cbc57498d ? |
| 18:03.15 | *** join/#oe Martin-B (~martin@pool-59-67-198-89.dbd-ipconnect.net) |
| 18:03.29 | *** join/#oe dth (~dth@a89-182-139-35.net-htp.de) |
| 18:03.51 | ericben | ouch still have to walk a lot through the code to understand this kind of stuff :-) |
| 18:05.46 | woglinde_ | re |
| 18:13.56 | *** join/#oe woglinde_ (~heinold@f052067164.adsl.alicedsl.de) |
| 18:17.41 | khem | denix: yes that commit is needed otherwise this package is building for my machine efikamx too |
| 18:20.38 | *** join/#oe CMoH|notebook (~cipi@95.76.71.81) |
| 18:20.38 | *** join/#oe CMoH|notebook (~cipi@unaffiliated/c-moh) |
| 18:21.08 | denix | khem: parentheses are used for grouping, to refer back to it later. is it used that way? dropping parentheses in COMPATIBLE_MACHINE used to work before, afaik |
| 18:21.36 | *** join/#oe timtimred (~meh@79-69-142-201.dynamic.dsl.as9105.com) |
| 18:22.05 | kergoth_ | it's just a regex.. |
| 18:23.02 | denix | kergoth: right. so shouldn't matter if it's "machine" or "(machine)" |
| 18:23.08 | khem | denix: it works I just though () was better |
| 18:23.26 | khem | for readability for me |
| 18:23.53 | denix | khem: just wanted to confirm I'm not missing something... :) |
| 18:24.36 | khem | ok |
| 18:25.02 | khem | kergoth: with pstage and rm_work if my build breaks and I relaunch it |
| 18:25.10 | khem | the rm_work and staging is done again |
| 18:25.18 | khem | I think its not needed |
| 18:26.41 | khem | kergoth: and it runs do_rm_work and do_rm_work_all |
| 18:26.58 | khem | whats different between these two |
| 18:27.13 | kergoth_ | denix: right |
| 18:27.30 | kergoth_ | _all is an empty task that ensures rm_work is run not just on the current recipe, but all its deps too |
| 18:27.34 | kergoth_ | same pattern as used in fetchall, etc |
| 18:27.46 | *** join/#oe fraxinas (~quassel@p4FD667AD.dip.t-dialin.net) |
| 18:28.53 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r816a1bfcfe 10openembedded.git/recipes/gstreamer/gst-plugin-gles_git.bb: gst-plugin-gles: bump SRCREV |
| 18:28.57 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r92240950cd 10openembedded.git/recipes/enblend/enblend-enfuse_4.0.bb: enblend-efuse: add 4.0 |
| 18:28.58 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r7bb9447c70 10openembedded.git/recipes/enblend/ (plotutils/01_configure_ac.patch plotutils_2.6.bb): plotutils: add 2.6 |
| 18:29.02 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r674e40568a 10openembedded.git/recipes/gstreamer/gstreamer_0.10.30.bb: gstreamer: add 0.10.30 |
| 18:29.03 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r739fd513b2 10openembedded.git/recipes/gstreamer/gst-plugins-base_0.10.30.bb: gst-plugins-base: add 0.10.30 |
| 18:29.15 | khem | kergoth_: what are different scheduler policies available in bitbake for tasks |
| 18:29.32 | kergoth_ | speed and completion, and of course the default, which is a useless order |
| 18:29.41 | kergoth_ | completion works to complete a recipe before moving on to the next |
| 18:29.47 | kergoth_ | speed orders based on # of dependencies for the task |
| 18:30.06 | khem | so speed might defer rm_work for a given recipe |
| 18:30.33 | kergoth_ | yep, so you'd use more disk space during the build |
| 18:30.35 | kergoth_ | same end result |
| 18:30.38 | kergoth_ | just intermediate difference |
| 18:30.41 | khem | kergoth: ok |
| 18:30.42 | kergoth_ | completion is slower |
| 18:31.24 | *** join/#oe timtimred (~meh@79-69-167-65.dynamic.dsl.as9105.com) |
| 18:31.27 | khem | kergoth_: for already built recipes its doing do_setscene->do_package_stage_all->do_build->do_rm_work->do_rm_work_all |
| 18:33.57 | khem | kergoth_: when I relaunch the build thats what I see I thought it should not do anything second time |
| 18:34.12 | khem | kergoth_: NOTE: Removing stamps: /scratch/oe/stamps/armv7a-oe-linux-gnueabi/udns-0.0.9-r0. |
| 18:34.25 | khem | second time around I wonder why bb is doing that |
| 18:34.31 | kergoth_ | it won't re-run setscne and package_stage the second time around. not sure about rm_work |
| 18:34.40 | kergoth_ | its possible there's an issue with the task ordering |
| 18:34.50 | khem | where I can see that it completed all tasks for this recipe in last invocation |
| 18:34.58 | kergoth_ | is rm_work nostamp? |
| 18:35.05 | *** part/#oe dth (~dth@a89-182-139-35.net-htp.de) |
| 18:35.14 | khem | kergoth_: what do u mean |
| 18:35.53 | kergoth_ | nevermind, likely doesn't apply here. pstage will refuse to use an existing ipk if the task graph differs from previous |
| 18:36.11 | kergoth_ | so if you have a task that might or might not run before/after package_stage, what gets captured will vary |
| 18:36.22 | kergoth_ | those things usually need to be pushed either before or after |
| 18:36.25 | kergoth_ | so it stops varying |
| 18:38.42 | khem | it removed stamps for almost all ipks in second run |
| 18:39.05 | khem | and then restaged them |
| 18:39.13 | khem | not very effective |
| 18:39.40 | kergoth_ | never seen that |
| 18:39.45 | kergoth_ | does it only do that with rm_work? |
| 18:40.01 | khem | I think so I have not tried without rm_work |
| 18:42.22 | khem | do_setscene -> do_package_stage_all -> do_build -> do_rm_work -> do_rm_work_all |
| 18:42.25 | khem | thats the order |
| 18:42.37 | khem | or task executed for a recipe second time around |
| 18:43.04 | kergoth_ | yeah, that shouldn't happen, afaik. setscene isn't nostamp |
| 18:43.53 | khem | before all that it decides to remove the ipk from staging at very beginning of run |
| 18:44.08 | khem | do_setscene could be asking for it ? |
| 18:44.15 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 18:44.46 | khem | do_setscene[selfstamp] = "1" |
| 18:44.57 | kergoth_ | ah, right, i forgot about that.. |
| 18:45.02 | kergoth_ | crazy voodoo |
| 18:46.28 | khem | base_scenefunction checks for stamp |
| 18:46.48 | khem | if it does not exist then it calls do_clean |
| 18:47.23 | khem | actually it checks for .needclean |
| 18:50.05 | khem | kergoth: there is a handler to update stamps in rm_work |
| 18:50.10 | khem | when will it be called |
| 19:10.36 | *** join/#oe mang (~laurdel@onegrandcircle.com) |
| 19:24.31 | *** join/#oe rob_w_ (~bob@pD95EC183.dip.t-dialin.net) |
| 19:27.41 | hrw | hi |
| 19:28.12 | hrw | someone know who broke patch task by appending to patches/series instead of rewriting it? |
| 19:28.45 | florian | hey hrw |
| 19:28.53 | florian | is not guilty |
| 19:29.34 | hrw | old way of checking which patches apply to new version (bitbake -b recipe.bb -cpatch) does not work anymore |
| 19:30.24 | hrw | btw - if someone uses Ubuntu 10.10 then ARM cross compiler is in archive - ready to use |
| 19:32.45 | kergoth_ | most likely it was me, when I cleaned up and reorganized unpack and patch |
| 19:32.49 | kergoth_ | should be easy enough to fix |
| 19:33.14 | kergoth_ | though i don't recall any behavior change like that offhand |
| 19:33.38 | *** join/#oe timtimred (~meh@79-69-167-65.dynamic.dsl.as9105.com) |
| 19:34.06 | kergoth_ | alternatively, it could be the commit that switched to using symlinks for patches |
| 19:34.56 | kergoth_ | yeah, there it is |
| 19:35.26 | kergoth_ | hmm |
| 19:36.20 | kergoth_ | okay, not sure which did it, try some reversion and see |
| 19:36.30 | khem | hrw: are you using quilt-native ? |
| 19:39.57 | hrw | khem: got it built as part of build |
| 19:40.23 | khem | hrw: bitbake -b recipe.bb -cpatch works for me |
| 19:40.54 | hrw | khem: add unapplying patch in a middle and call -cpatch twice |
| 19:41.53 | khem | hrw: you mean unapply by hand |
| 19:42.14 | *** join/#oe vanous (~vanous@212.119.227.2) |
| 19:42.18 | hrw | khem: edit recipe, add nonworking patch to src_uri. call -cpatch twice |
| 19:42.47 | hrw | second run will get "all good" + nonworking + "all good" in series |
| 19:42.55 | khem | hmmm |
| 19:43.02 | hrw | remove nonworking patch from src_uri, call -cpatch |
| 19:43.13 | hrw | you will get "all good" + nonworking + "all good" + "all good" in series |
| 19:43.27 | hrw | so patch task will fail |
| 19:44.51 | hrw | anyway need to go - daugher still not sleep so time to read some fG$#@%^@GSGS failytales |
| 19:51.39 | *** join/#oe mario-goulart (~user@67.205.85.241) |
| 20:01.09 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * ra6aa9eae24 10openembedded.git/recipes/orc/orc_0.4.9.bb: orc: update to 0.4.9 |
| 20:09.01 | khem | kergoth_: I think we should remove the series file at the beginning of do_patch |
| 20:09.05 | khem | what do u think |
| 20:10.51 | kergoth_ | pretty sure Clean() updates the internal knowledge of the patch stack in the class, we should be able to see if the patch is already there in Import and avoid re-importing it |
| 20:10.55 | kergoth_ | at least, i think that was the concept |
| 20:11.05 | kergoth_ | its been a while since i worked on that stuff |
| 20:12.21 | khem | is Clean called implicitly on unfinished do_patch |
| 20:12.32 | khem | second time around |
| 20:14.07 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 20:14.43 | khem | kergoth: hmm I see |
| 20:15.08 | khem | code around line 107 in patch.bbclass |
| 20:19.02 | ericben | Tartarus: concerning gdb-cross-sdk, I've hacked something which is using static libncurses libtinfo libz and libexpat (even if the problem was only with libncurses & libtinfo) : is this ok or should I limit to only libncurses & libtinfo ? |
| 20:19.59 | Tartarus | No, that sounds good |
| 20:20.04 | Tartarus | libexpat is a pain sometimes :) |
| 20:20.26 | ericben | it's not easy to hack gdb's config & makefiles as most of them are generated by do_compile and not by do_build |
| 20:21.27 | Tartarus | Same way we hacked gcc should work |
| 20:21.40 | Tartarus | since gdb/gcc/binutils have the same horrible set of not fun "do our configure in do compile" stuff |
| 20:22.20 | khem | kergoth_: if some recipe defines patchdir like mplayer_svn then Clean will be called which will unapply all patches applied so far |
| 20:22.28 | khem | seem wrong to me |
| 20:22.30 | kergoth_ | no |
| 20:22.50 | khem | patchset.Clean() will be called isnt it |
| 20:22.54 | kergoth_ | Clean runs within the patchdir, a new patch series, it unapplies the patches *in the patchdir* |
| 20:22.57 | kergoth_ | and only the first time |
| 20:23.09 | kergoth_ | it doesn't unapply the patches with a patchdir of ${S} |
| 20:23.13 | kergoth_ | which is the default |
| 20:23.19 | kergoth_ | patchdir is always set, just not always overridden |
| 20:23.20 | ericben | Tartarus: I didn't manage to do it the way you did for gcc, I added a do_configure_append and I'm doing the change using sed here |
| 20:23.42 | kergoth_ | patchdir is the root of a new quilt patch setup, a new patches dir, new series |
| 20:23.49 | khem | kergoth_: right but classes is empty when we enter the loop first time |
| 20:23.58 | kergoth_ | as it should be |
| 20:24.06 | khem | so first time it will go into that if and run clean |
| 20:24.07 | kergoth_ | it runs clean at the first patch for each patchdir |
| 20:24.13 | kergoth_ | yes, as it should |
| 20:24.16 | khem | ok |
| 20:24.22 | kergoth_ | its supposed to unapply all patches forcibly before applying the new series |
| 20:24.29 | kergoth_ | otherwise how would it applied a modified patch? |
| 20:24.32 | khem | that means in patchset.Clean() I can nuke series |
| 20:24.33 | kergoth_ | it has to unapply the old series first |
| 20:24.50 | khem | may be not |
| 20:24.57 | kergoth_ | ? |
| 20:25.16 | ericben | Tartarus: I see, in gdb the libs are clearly named in Makefile.tpm and Makefil.in, that's not the case in gdb as using curses or others depends on parameters passed to configure |
| 20:25.22 | kergoth_ | unapplying the old series is the only way to ensure you're applying the current patch series against a pristine tree |
| 20:25.24 | khem | kergoth_: in Import we create symlinks and append to series file |
| 20:25.30 | kergoth_ | yep |
| 20:25.37 | kergoth_ | it should be safe to wipe series at clean time, yeah |
| 20:25.39 | kergoth_ | i *think* |
| 20:25.49 | khem | so first pop all patches |
| 20:25.54 | kergoth_ | then wipe series |
| 20:25.55 | khem | and then delete series |
| 20:25.57 | kergoth_ | then come the imports |
| 20:25.57 | kergoth_ | yeah |
| 20:26.05 | khem | ok |
| 20:26.10 | kergoth_ | in theory |
| 20:26.18 | khem | now are there separate series files for each patchdir |
| 20:26.29 | kergoth_ | yes, but you don't have to worry about it |
| 20:26.33 | kergoth_ | its a new instance of the class in each one |
| 20:26.50 | kergoth_ | so a new path, new series path, the class doesn't need to know, other than being passed in the root its operating against |
| 20:27.18 | kergoth_ | hmm |
| 20:27.37 | CIA-68 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r1f5fb1e223 10openembedded.git/recipes/mozilla/ (2 files in 2 dirs): firefox 3.6.8: fix build from ARMv4T, patch stolen from debian |
| 20:27.41 | khem | kergoth_: ok so say I have $WORKDIR/ and WORKDIR/foo as my patchdirs |
| 20:27.45 | khem | for a recipe |
| 20:28.04 | khem | so there will be $WORKDIR/patches/series and WORKDIR/foo/patches/series |
| 20:28.07 | kergoth_ | yep |
| 20:28.23 | kergoth_ | two instances of QuiltTree, with $WORKDIR as dir for the first, nad $WORKDIR/foo for the dir for the second |
| 20:28.32 | khem | i c |
| 20:28.46 | khem | ok then I think removing series file in Clean would work |
| 20:28.49 | kergoth_ | it was the only i could think that would make sense |
| 20:28.58 | kergoth_ | for the patchdir implementation, i mean |
| 20:29.44 | khem | kergoth_: yeah but it will be mess to play with a tree which has multiple patchdirs |
| 20:29.55 | kergoth_ | not really |
| 20:30.00 | khem | kergoth_: one could step on others toes |
| 20:30.05 | khem | if they modify common files |
| 20:30.09 | kergoth_ | oh, i see what you mean, yeah, that is a problem |
| 20:30.18 | kergoth_ | ideally quilt would support the notion directly |
| 20:30.23 | kergoth_ | and we could just put that in the series file |
| 20:30.29 | khem | as long as you dont have to generate a new patch for that recipe bb takes care of it |
| 20:30.29 | kergoth_ | not much we can do about it though |
| 20:30.31 | khem | you are happy |
| 20:30.35 | kergoth_ | and very few recipes use the thing anyway |
| 20:30.38 | kergoth_ | nods |
| 20:30.43 | khem | only 1 I found |
| 20:30.45 | khem | mplayer |
| 20:31.09 | kergoth_ | another alternative would be to modify the patch file to adjust the paths into the patchdir, which would avoid the issue |
| 20:31.13 | kergoth_ | but is less trivial to implement |
| 20:31.22 | kergoth_ | would need to parse the diff format, at least part of it |
| 20:31.23 | khem | agree |
| 20:31.38 | khem | let me test the series removal think |
| 20:31.40 | khem | thing |
| 20:31.41 | kergoth_ | k |
| 20:32.31 | khem | do we prefer unlink to delete a file or something else |
| 20:33.42 | khem | ah oe.path.remove |
| 21:09.36 | *** part/#oe hoj (~hoj@75-147-191-205-Washington.hfc.comcastbusiness.net) |
| 21:11.17 | khem | we have two versions of libnl |
| 21:11.32 | khem | are there ABI differences between two |
| 21:11.36 | khem | they seem to be conflicting |
| 21:11.49 | woglinde | khem yes |
| 21:11.53 | khem | some packages depend on libnl and some on libnl2 |
| 21:12.19 | khem | woglinde: hmmm |
| 21:12.27 | khem | we cant select one or other |
| 21:12.41 | khem | woglinde: do u have some more info on the differences |
| 21:13.43 | woglinde | no |
| 21:13.53 | woglinde | sorry |
| 21:14.05 | khem | no other distros ship libnl2 |
| 21:14.16 | khem | who needs libnl2 and why |
| 21:16.47 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
| 21:17.09 | *** join/#oe pb__ (~pb@blundell.swaffham-prior.co.uk) |
| 21:38.54 | loadammo | Is there some simple way to package my kernel up into a named package rather than 'kernel-image' ? Tried adding a PACKAGES + FILES_myname="/boot/uImage" to my recipe bu it's only got module related stuff in it.. Seems like I've got an ordering problem or something. |
| 21:39.13 | Crofton|work | my VIRT is up to 220M now, was about 150 when I started watching it |
| 21:39.17 | Crofton|work | doh |
| 21:39.39 | Tartarus | loadammo, what do you mean? |
| 21:39.47 | Tartarus | We intentionally do kernel-image rather than kernel-${MACHINE} |
| 21:40.14 | loadammo | I've got two kernels for the same machine, one with inintramfs, one without -- when you build each one it clobbers the packages for the other |
| 21:40.35 | Tartarus | So then you want to take a look at how linux-kexecboot and linux-preboot recipes work |
| 21:40.44 | Tartarus | That's how OE supports initramfs using kernels |
| 21:41.20 | loadammo | Our kernel doesn't support kexec, and the preboot stuff doesn't fit our model. I'll just patch kernel.bbclass I guess. |
| 21:41.27 | loadammo | thanks |
| 21:45.47 | *** join/#oe playya__ (~playya@unaffiliated/playya) |
| 21:48.27 | Tartarus | Right |
| 21:48.34 | Tartarus | What I'm saying is that those are recipes to look at and modify |
| 21:48.56 | Tartarus | Since they implement the template of kernel + initramfs |
| 21:49.41 | Tartarus | If you've gone and modified things such that your kernel + initramfs are built together with one recipe file rather than two, yes, kernel.bbclass needs some hacking |
| 21:49.48 | Tartarus | Or it did before when I did such a thing |
| 21:50.05 | Tartarus | (since your kernel recipe needs a little hacking too, unless you aren't having any modules in the initramfs) |
| 21:53.48 | *** join/#oe dth_ntb (~dth@a89-182-139-35.net-htp.de) |
| 21:56.55 | *** join/#oe mickey|away (~mickey@80.81.242.146) |
| 22:02.55 | *** join/#oe Spz0 (~a@97-120-161-26.ptld.qwest.net) |
| 22:13.24 | *** join/#oe aafuentes (~mswl@140.87.117.91.dynamic.mundo-r.com) |
| 22:16.23 | *** join/#oe methril_work (~methril@201.35.65.90) |
| 22:27.38 | *** join/#oe methril_work (~methril@201.35.65.90) |
| 22:40.33 | CIA-68 | 03Michael Smith <msmith@cbnco.com> 07master * r6aadf6cfe9 10openembedded.git/recipes/gtk+/ (gtk+-2.14.2/no-demos.patch gtk+_2.14.2.bb): |
| 22:40.33 | CIA-68 | gtk+ 2.14.2: add BBCLASSEXTEND = "native" |
| 22:40.33 | CIA-68 | Get this ancient recipe working again. |
| 22:40.33 | CIA-68 | Signed-off-by: Michael Smith <msmith@cbnco.com> |
| 22:40.44 | CIA-68 | 03Michael Smith <msmith@cbnco.com> 07master * rd4e8b7241d 10openembedded.git/recipes/musicbrainz/ (2 files in 2 dirs): |
| 22:40.44 | CIA-68 | libmusicbrainz: fix build when prefix = "" |
| 22:40.44 | CIA-68 | Signed-off-by: Michael Smith <msmith@cbnco.com> |
| 22:56.31 | *** join/#oe kerim (~kerim@81.214.22.138) |
| 23:01.52 | *** join/#oe JaMa (~martin@161-24.13.24.78.awnet.cz) |
| 23:04.51 | aafuentes | hi, do you know a tutorial to use distcc to compile oe? |
| 23:09.06 | Tartarus | distcc no, icecc yes |
| 23:10.07 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
| 23:10.34 | aafuentes | does it work better icecc Tartarus ? |
| 23:10.47 | Tartarus | same concept but different implementation |
| 23:11.37 | aafuentes | i found the page on the wiki, thanks Tartarus ;) |
| 23:42.07 | *** join/#oe waite (~quassel@c-24-91-81-44.hsd1.ma.comcast.net) |
| 23:44.31 | *** join/#oe tharvey (~tharvey@adsl-76-205-222-173.dsl.snlo01.sbcglobal.net) |