| 00:17.06 | *** join/#oe playya_ (~playya@unaffiliated/playya) |
| 00:34.58 | *** join/#oe mickey|zzZZzz (~mickey@80.81.242.146) |
| 01:07.13 | *** join/#oe raster (~raster@enlightenment/developer/raster) |
| 01:08.03 | *** join/#oe rednul_ (~rednul@host-98-127-6-7.bln-mt.client.bresnan.net) |
| 01:14.24 | *** join/#oe methril (~methril@189.27.132.66.dynamic.adsl.gvt.net.br) |
| 01:20.16 | *** join/#oe scruggs (~scruggs@72-161-108-247.dyn.centurytel.net) |
| 01:50.16 | *** join/#oe william_zhang (~william@58.247.126.174) |
| 02:04.42 | *** join/#oe scruggs (~scruggs@72-161-108-247.dyn.centurytel.net) |
| 02:13.56 | *** join/#oe hansdampf (~moritz@rgnb-4d04bacd.pool.mediaWays.net) |
| 02:15.38 | *** join/#oe Ironnads (~Ironnads@host86-185-172-99.range86-185.btcentralplus.com) |
| 02:17.44 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |
| 02:34.30 | *** join/#oe thaytan (~jan@121.91.189.61) |
| 03:39.48 | *** join/#oe Ox83 (~Ox83@c-24-130-249-162.hsd1.ca.comcast.net) |
| 03:58.21 | *** join/#oe user2 (~3MX@24-247-212-228.dhcp.bycy.mi.charter.com) |
| 04:07.42 | *** join/#oe Laibsch (~Laibsch@p5B3B2CA3.dip.t-dialin.net) |
| 05:12.20 | *** join/#oe zecke (~ich@193-4-248-222.static.metronet.is) |
| 05:33.36 | *** join/#oe polyonymous (~hacker@g230193078.adsl.alicedsl.de) |
| 06:08.40 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
| 07:21.11 | *** join/#oe BillK (~BillK@124-148-236-121.dyn.iinet.net.au) |
| 07:25.06 | Jin^eLD | morning |
| 07:25.20 | *** join/#oe thaytan (~jan@119.12.44.186) |
| 07:30.13 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r09a79a497f 10openembedded.git/recipes/opkg/ (opkg.inc update-alternatives-merge.inc): (log message trimmed) |
| 07:30.14 | CIA-2 | opkg: don't run merger in case when /usr/lib/ipkg is link |
| 07:30.14 | CIA-2 | * if there is link /usr/lib/ipkg -> /usr/lib/opkg, then merger will |
| 07:30.14 | CIA-2 | create backups of "both" alternatives directories, but they will be |
| 07:30.14 | CIA-2 | both the same /usr/lib/opkg/alternatives, then it will try to merge |
| 07:30.14 | CIA-2 | with output that every file is the same, sofar no real harm. |
| 07:30.15 | CIA-2 | * Problem is after successfull merge, when it removes |
| 07:35.55 | *** join/#oe Hasse_ (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 07:37.47 | *** join/#oe Hasse_ (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 07:42.02 | *** join/#oe dvermd (~roudoudou@78.234.93.192) |
| 07:42.33 | *** join/#oe mlip2 (~mlip2@62.218.44.194) |
| 07:50.33 | *** join/#oe hd (~jd@modemcable207.134-202-24.mc.videotron.ca) |
| 07:50.33 | *** join/#oe hd (~jd@Wikipedia/HellDragon) |
| 07:51.05 | *** join/#oe hd (~jd@modemcable207.134-202-24.mc.videotron.ca) |
| 07:51.05 | *** join/#oe hd (~jd@Wikipedia/HellDragon) |
| 08:04.50 | mckoan | good morning |
| 08:05.08 | *** join/#oe blindvt` (~b@62-99-204-228.c-vdreihufeisengasse.xdsl-line.inode.at) |
| 08:06.28 | *** join/#oe cyberdeck (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 08:08.41 | blindvt` | Spyzer, re your cooker problem; This http://paste.debian.net/61924/ should avoid that python errors from bitbake |
| 08:11.12 | *** join/#oe Longfield (~valentin@lsa1pc7.epfl.ch) |
| 08:13.21 | *** join/#oe glenn_ (~glenn@213.49.132.19) |
| 08:13.26 | *** join/#oe frank7d (~frank@91-2.3-213.fix.bluewin.ch) |
| 08:16.32 | blindvt` | kergoth, sent you that above hunk with some more detail for your consideration. Basically, Spyzer somehow ended up with a BBPATH that points to no .bb and got the backtrace mentioned in the mail. The patch would bail gracefully instead of trying to continue. |
| 08:18.20 | *** join/#oe Heinervdm (~thomas@pD9E167AC.dip.t-dialin.net) |
| 08:19.23 | *** join/#oe mickey|office (~Mickey@dialbs-092-079-168-007.static.arcor-ip.net) |
| 08:22.23 | mlip2 | morning |
| 08:29.02 | *** join/#oe rednul_ (~rednul@host-98-127-6-7.bln-mt.client.bresnan.net) |
| 08:45.16 | *** join/#oe EsbenH (~EsbenH@77.233.226.4) |
| 08:45.42 | marekp | morning |
| 08:47.03 | *** join/#oe fpga (~s@92.62.56.51) |
| 08:47.44 | marekp | anyone, i have trouble getting ipkg running on my target, it does not find basic modules (like tempfile), possible i made something wrong, is there some tutorial ? |
| 08:48.57 | dm8tbr | isn't it opkg nowadays? |
| 08:49.19 | *** join/#oe DJWillis (~djwillis@cpc1-bath2-0-0-cust327.aztw.cable.virginmedia.com) |
| 08:49.23 | marekp | oh... so thats my fail |
| 08:50.05 | marekp | all the tutorials i worked through where pointing at ipkg... i had no clue, sorry |
| 08:50.26 | dm8tbr | i'm not sure. my morning coffee didn't kick fully in yet |
| 08:50.56 | marekp | i just tried typing opkg into the target console, and i greeted me without errors |
| 08:51.14 | marekp | :) thanks |
| 08:52.14 | dm8tbr | oic, then hack away! |
| 08:56.48 | *** join/#oe fpga (~s@92.62.56.51) |
| 08:58.16 | *** join/#oe ZaPPaS (~moritz@weinberg.pi5.physik.uni-stuttgart.de) |
| 09:04.02 | *** join/#oe MWelchUK_work (~welchma@65.91.2.71) |
| 09:05.02 | *** join/#oe Hasse_ (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 09:05.05 | *** join/#oe MWelchUK_work (~welchma@65.91.2.71) |
| 09:07.44 | *** join/#oe BillK (~BillK@203-166-237-86.dyn.iinet.net.au) |
| 09:09.02 | *** join/#oe pvanhoof (~pvanhoof@d54C0C0BA.access.telenet.be) |
| 09:10.54 | *** join/#oe glicka (~glicka@dialup-4.233.194.182.Dial1.Manchester1.Level3.net) |
| 09:12.12 | *** part/#oe glicka (~glicka@dialup-4.233.194.182.Dial1.Manchester1.Level3.net) |
| 09:13.27 | *** join/#oe RP__ (~richard@93-97-173-237.zone5.bethere.co.uk) |
| 09:13.34 | *** join/#oe glicka (~glicka@dialup-4.233.194.182.Dial1.Manchester1.Level3.net) |
| 09:13.50 | *** part/#oe glicka (~glicka@dialup-4.233.194.182.Dial1.Manchester1.Level3.net) |
| 09:16.24 | *** join/#oe zecke (~ich@siminn-int-gw.on-waves.com) |
| 09:21.03 | *** join/#oe mlip2 (~mlip2@62.218.44.194) |
| 09:22.06 | hrw | morning |
| 09:22.13 | soltys | morning |
| 09:22.34 | hrw | o czeÅÄ soltys |
| 09:23.17 | soltys | ;) |
| 09:23.19 | mckoan | hi hrw |
| 09:23.39 | hrw | eFfeM: what about moving task-nas-server-openmoko to separate recipe? this way openmoko distros can built it if need? |
| 09:24.00 | soltys | nas on om ?:) |
| 09:25.23 | Heinervdm | hrw: openmoko it self doesn't build imags anymore |
| 09:25.45 | Heinervdm | and shr doesn't use this recipe |
| 09:26.34 | hrw | soltys: what about freerunner in space? |
| 09:27.35 | soltys | hrw: dunno |
| 09:28.26 | *** join/#oe TAsn (~tasn@109-186-16-130.bb.netvision.net.il) |
| 09:29.44 | hrw | soltys: read http://www.datenfreihafen.org/~stefan/weblog/archives/2010/02/index.html then |
| 09:30.08 | soltys | ok |
| 09:32.10 | soltys | hrw: interesting |
| 09:36.16 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 09:41.17 | *** join/#oe rob_w (~bob@p549BB63C.dip.t-dialin.net) |
| 09:41.37 | TAsn | Hey, what recipe is responsible for en_US.UTF-8 ? |
| 09:41.51 | XorA | glibc |
| 09:43.31 | TAsn | and the created package should be /eglibc-binary-localedata-en-us_2.10...version... ? |
| 09:46.30 | TAsn | ? |
| 09:52.12 | *** join/#oe kristoffer (~kristoffe@94.191.201.55.bredband.tre.se) |
| 09:54.16 | *** join/#oe gilligan_ (~gilligan@p5B17F33E.dip.t-dialin.net) |
| 09:59.51 | CIA-2 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r5a3429c62d 10openembedded.git/recipes/mozilla/firefox_3.6.bb: firefox 3.6: bump PR for package.bbclass strip problem |
| 09:59.52 | CIA-2 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r39e7c169d8 10openembedded.git/recipes/qt4/ (4 files in 2 dirs): qt4: bump PR for package.bbclass strip problem |
| 10:07.06 | *** part/#oe mlip2 (~mlip2@62.218.44.194) |
| 10:16.48 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 10:17.17 | *** join/#oe noglitch (~Miranda@mail.atmel.fr) |
| 10:21.49 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 10:23.29 | *** join/#oe dth_ntb (~dieter@a89-183-73-173.net-htp.de) |
| 10:25.15 | *** join/#oe GNUtoo (~GNUtoo@host192-8-dynamic.9-87-r.retail.telecomitalia.it) |
| 10:28.50 | *** join/#oe Ironnads (~Ironnads@host86-183-195-90.range86-183.btcentralplus.com) |
| 10:30.16 | Jin^eLD | I have FILES_${PN}-util = "${bindir}/js" in my recipe, still I get: the following files were installed but not shipped in any package: /usr/bin/js, what am I missing? |
| 10:31.13 | zecke | Jin^eLD: PACKAGES += ${PN}-util ? |
| 10:31.26 | *** join/#oe cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net) |
| 10:31.49 | Jin^eLD | ah crap! thank you |
| 10:32.08 | Jin^eLD | :) |
| 10:35.18 | *** join/#oe glenn_ (~glenn@213.49.132.19) |
| 10:37.59 | *** join/#oe claudiuM (~claubu@host146-184-dynamic.8-87-r.retail.telecomitalia.it) |
| 10:50.49 | CIA-2 | 03Graeme Gregory <dp@xora.org.uk> 07org.openembedded.dev * r5f52f56fd8 10openembedded.git/recipes/udev/attr_2.4.44.bb: attr_2.4.44.bb : uclibc needs a -lintl to compile |
| 10:59.11 | mckoan | <PROTECTED> |
| 11:01.20 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r7dccaf76a7 10openembedded.git/conf/distro/include/sane-srcrevs.inc: elementary-theme-gry: bump SRCREV |
| 11:01.56 | BlindMan | hi Jin^eLD |
| 11:02.06 | Jin^eLD | hi |
| 11:10.16 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |
| 11:29.59 | *** join/#oe rob_w (~bob@p549BB63C.dip.t-dialin.net) |
| 11:38.06 | *** join/#oe Hasse_ (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 11:43.05 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |
| 11:43.10 | *** join/#oe mario-goulart (~user@67.205.85.241) |
| 12:05.01 | *** join/#oe zecke (~ich@siminn-int-gw.on-waves.com) |
| 12:10.12 | *** join/#oe gugus (hugues@mail.hiegel.fr) |
| 12:24.41 | *** join/#oe B_Lizzard (~havoc@athedsl-429019.home.otenet.gr) |
| 12:27.35 | *** join/#oe mickey|office (~Mickey@dialbs-092-079-168-007.static.arcor-ip.net) |
| 12:35.21 | Jin^eLD | zecke: this time again, something simialr :) I have PACKAGES += ${PN}-tests and I have FILES_${PN}-tests = "${datadir}/dss/dsstests" but somehow the dsstests file still ends up in the main package? what am I missing this time? :) |
| 12:35.52 | pb_ | Jin^eLD: PACKAGES =+ "${PN}-tests" |
| 12:36.15 | Jin^eLD | oops.. so with the other recipe it worked just by accident |
| 12:36.34 | Jin^eLD | thanks |
| 12:41.14 | Jin^eLD | pb_: that did not help though... NOTE: Not creating empty archive for dss-tests-0.7.7-r9.5 |
| 12:41.55 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
| 12:42.08 | Jin^eLD | is the order important, i.e. who gets listed first? |
| 12:42.40 | Jin^eLD | or should I list FILES_${PN} manually myself? |
| 12:48.02 | Jin^eLD | yep, seems that was it |
| 12:48.39 | hrw | no |
| 12:49.14 | Jin^eLD | no? hmm well after I specified FILES_${PN} in addition to the other custom packages, things went where they were supposed to |
| 12:49.30 | Jin^eLD | what's the "correct" way of solving this? |
| 12:50.15 | hrw | prepend to PACKAGES not append |
| 12:50.25 | hrw | as bitbake goes in order |
| 12:50.39 | hrw | and FILES_${PN} should not be overwritten |
| 12:50.56 | Jin^eLD | ok.. thanks, let me try.. I did suspect that but somehow went the FILES_ way |
| 12:50.59 | *** join/#oe Sleep_Walker (~Sleep@nat/novell/x-zzpqvhucuixmubmz) |
| 12:55.50 | hrw | ok, I have two patches which can break people or not. autoconf + automake pokyified |
| 12:56.16 | hrw | builds should work anyway so I will push |
| 12:56.28 | CIA-2 | 03Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> 07org.openembedded.dev * rb6faf3681a 10openembedded.git/recipes/automake/ (5 files): |
| 12:56.28 | CIA-2 | autoconf: merged Poky changes (BBEXTENDCLASS + new staging) |
| 12:56.28 | CIA-2 | Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |
| 12:56.38 | CIA-2 | 03Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> 07org.openembedded.dev * r15ab483e62 10openembedded.git/recipes/autoconf/ (6 files): |
| 12:56.38 | CIA-2 | autoconf: merged Poky changes (BBEXTENDCLASS + new staging) |
| 12:56.38 | CIA-2 | Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |
| 13:01.25 | *** join/#oe pvanhoof (~pvanhoof@d54C0C0BA.access.telenet.be) |
| 13:01.52 | eFfeM | hrw, was in meetings all morning, wrt openmoko: & nas: seemed a weird combination anyway |
| 13:02.01 | hrw | ok |
| 13:02.48 | eFfeM | actually it is a task which is a collection of tasks and apparently more or less orphaned too |
| 13:03.12 | eFfeM | but this is also a case that a specific machine has a specific need |
| 13:03.48 | eFfeM | the real solution is probably to fix dfu-util (and make it use usb iso usb-compat |
| 13:06.41 | hrw | rigth |
| 13:06.57 | Jin^eLD | hrw: thanks, prepending worked just fine |
| 13:07.13 | hrw | pb_: we are using gnu-config from 2005 - any idea why we did not updated? |
| 13:09.41 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
| 13:10.08 | pb_ | hrw: I guess simply because the old one was working adequately well. The rate of change in gnu-config is pretty slow and, unless you need support for a new cpu or something, there is generally not much to be gained by upgrading it. |
| 13:10.41 | hrw | ok |
| 13:14.42 | hrw | wow. one of gnu-config patches was manually updated by me nearly 5 years ago... time flies |
| 13:16.22 | hrw | so I met OE ~6 years ago |
| 13:16.41 | hrw | 18th March 2004 was first OEML contribution |
| 13:19.18 | *** join/#oe rsalveti (~rsalveti@200.184.118.130) |
| 13:19.30 | *** join/#oe sicu (~sicu@cm-84.208.94.5.getinternet.no) |
| 13:32.00 | *** join/#oe mr_nice (~nice@95-90-75-53-dynip.superkabel.de) |
| 13:37.51 | *** join/#oe stefan_schmidt (~stefan@p5B03595B.dip.t-dialin.net) |
| 13:38.19 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 13:41.29 | *** join/#oe aloisiojr (~aloisio@200.184.118.130) |
| 13:45.26 | kergoth | blindvt`: BBPATH isn't what points to .bb files, BBFILES is. Thanks for the patch, though, we definitely want to avoid that backtrace. appreciate your taking the time to find the cause |
| 13:52.34 | hrw | ok, time for gnu-config push |
| 13:53.04 | CIA-2 | 03Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> 07org.openembedded.dev * rd0d9ad50a4 10openembedded.git/recipes/gnu-config/ (gnu-config-native_20050701.bb gnu-config_20050701.bb): |
| 13:53.04 | CIA-2 | gnu-config: merge Poky improvements (BBCLASSEXTEND, new staging) |
| 13:53.04 | CIA-2 | Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |
| 13:53.14 | CIA-2 | 03Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> 07org.openembedded.dev * r5463fa1e85 10openembedded.git/recipes/gnu-config/gnu-config/uclibc.patch: |
| 13:53.14 | CIA-2 | gnu-config: remove not used uclibc.patch |
| 13:53.14 | CIA-2 | Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |
| 13:58.10 | *** join/#oe GNUtoo (~GNUtoo@host192-8-dynamic.9-87-r.retail.telecomitalia.it) |
| 14:03.02 | blindvt` | kergoth, BBFILES point to .bb, yes. Either of BBPATH="" or BBFILES=/nothing_in_there and variations thereof would trip this, so perhaps BBFILES should also be printed (I thought the common mistake would be an improperly set BBPATH but that's of course not always true) |
| 14:03.27 | kergoth | nods, fair enough |
| 14:03.30 | *** join/#oe palisv (~patrik@static-213.88.151.242.addr.tdcsong.se) |
| 14:06.36 | pb_ | Jin^eLD: yes, the order is important: that is why you need to use =+ not += |
| 14:09.37 | Jin^eLD | ooh, I did not notice that subtle difference, was using _prepend then, thanks once more |
| 14:12.08 | *** join/#oe BenLauDC (~benlau@221.125.8.18) |
| 14:13.03 | *** join/#oe Spyzer (~abhishek@210.212.53.135) |
| 14:13.08 | *** join/#oe MWelchUK_work_ (~welchma@65.91.2.71) |
| 14:17.47 | *** join/#oe Sleep_Walker (~Sleep@nat/novell/x-epynfjkrwkhfukio) |
| 14:19.34 | *** join/#oe bin1010 (~mia@129.62.151.74) |
| 14:25.25 | *** join/#oe SDuensin_ (~Scott@mobile-166-137-136-108.mycingular.net) |
| 14:27.07 | CIA-2 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r5a9223eab9 10openembedded.git/recipes/e17/exalt_svn.bb: exalt: convert to new style staging |
| 14:27.08 | CIA-2 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rb154373858 10openembedded.git/recipes/e17/e-wm_svn.bb: e-wm: convert to new style staging |
| 14:29.31 | *** part/#oe SDuensin_ (~Scott@mobile-166-137-136-108.mycingular.net) |
| 14:34.26 | *** join/#oe bin1010 (~mia@129.62.151.74) |
| 14:34.52 | *** join/#oe Longfield (~valentin@lsro1accesspoint1.epfl.ch) |
| 14:37.23 | *** join/#oe pb___ (~pb@88-109-183-94.dynamic.dsl.as9105.com) |
| 14:37.48 | *** join/#oe mrc3 (~ddiaz@122.181.11.126) |
| 14:41.13 | *** part/#oe EsbenH (~EsbenH@77.233.226.4) |
| 14:54.02 | *** join/#oe timtimred (~meh@79-77-193-46.dynamic.dsl.as9105.com) |
| 14:54.04 | hrw | another 2 recipes less to parse |
| 14:55.25 | hrw | bonus will be move people to file-native 5.04 |
| 14:57.52 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 14:58.43 | CIA-2 | 03Graeme Gregory <dp@xora.org.uk> 07org.openembedded.dev * rdb935da155 10openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc: |
| 14:58.43 | CIA-2 | angstrom-2008-preferred-versions.inc : downgrade udev for uclibc |
| 14:58.43 | CIA-2 | udev 141 is known good on uclibc, I know there are patches to hack up |
| 14:58.43 | CIA-2 | 151 to work. But for now I would prefer to have a known good stable we |
| 14:58.43 | CIA-2 | can upgrade. |
| 14:58.50 | CIA-2 | 03Graeme Gregory <dp@xora.org.uk> 07org.openembedded.dev * r3b35dfffa8 10openembedded.git/conf/distro/angstrom-2008.1.conf: |
| 14:58.50 | CIA-2 | angstrom-2008.1.conf : increment angstrom uclibc usage to the latest point rel. |
| 14:58.50 | CIA-2 | There were problems compiling later gnome/polkit/conkit stuff that this |
| 14:58.50 | CIA-2 | release fixes. To not deviate too far from glibc builds we need to |
| 14:58.50 | CIA-2 | update. |
| 15:00.37 | *** join/#oe florian (~user@Maemo/community/contributor/florian) |
| 15:01.05 | florian | re |
| 15:01.28 | XorA | hrw: heh, file 5.04 combined with the other update means no-ones builds are stripped :-) |
| 15:02.26 | Romke | dammit |
| 15:03.20 | Romke | I think I screwed up something :D |
| 15:03.20 | hrw | ok, will set default to 4.21 then |
| 15:03.22 | Romke | I tried creating a recipe for linux-2.6.33 with a defconfig for the sbc6020, but do_stage seems to fail |
| 15:03.24 | DJWillis | XorA: yep, magic gone 'no magic' ;-) |
| 15:04.02 | hrw | XorA: target or host binaries are not stripped? |
| 15:04.05 | *** join/#oe fpga (~s@92.62.56.51) |
| 15:04.33 | XorA | hrw: target |
| 15:04.41 | XorA | hrw: see the thread on mailing list |
| 15:04.49 | XorA | hrw: 150M firefox libs :-D |
| 15:05.12 | hrw | ok, need to build for target first |
| 15:05.45 | JaMa | Romke: try to clean that recipe before building |
| 15:06.07 | hrw | 16:05 hrw@home:devel$ build/micro/tmp/staging/x86_64-linux/bin/file |
| 15:06.07 | hrw | file: File 5.4 supports only version 7 magic files. `/home/hrw/devel/build/micro/tmp/staging/x86_64-linux/share/misc/magic.mgc' is version 4 |
| 15:06.11 | hrw | fun |
| 15:06.27 | hrw | ~curse file upstream for 5.4 == 5.04 |
| 15:06.28 | ibot | May the fleas of a thousand camels infest your most sensitive regions, file upstream for 5.4 == 5.04 ! |
| 15:07.17 | hrw | ok, file native fails to deliver magic.mgc |
| 15:07.20 | *** join/#oe sicu (~sicu@cm-84.208.94.5.getinternet.no) |
| 15:07.36 | XorA | hrw: its moved to usr/share/misc/magic.mgc |
| 15:07.53 | hrw | XorA: and it is there - 8 bytes |
| 15:08.00 | XorA | ooops |
| 15:08.01 | hrw | will fix file 5.04 |
| 15:08.17 | XorA | should be about 1.7M |
| 15:08.20 | Romke | JaMa: it fails again |
| 15:08.31 | hrw | XorA: I know - it was such one with 4.21 |
| 15:08.40 | JaMa | Romke: aren't you using stable branch? |
| 15:08.47 | Romke | yes, I am |
| 15:08.57 | Romke | http://tinderbox.openembedded.org/builds/62439/ |
| 15:08.59 | JaMa | Romke: then read ML and kernel.bbclass log from oe.dev |
| 15:09.17 | Romke | ML? |
| 15:09.25 | JaMa | Romke: openembedded-devel@ |
| 15:09.27 | gilligan_ | hm.. anyone here building oe for beagleboard ? trying to build xserver-xorg fails because HAL is not available |
| 15:09.34 | hrw | Romke: and then extract needed changes from .dev, test them in stable/2009 and post them for inclusion |
| 15:09.59 | Romke | mkay |
| 15:10.07 | JaMa | gilligan_: which xserver version? |
| 15:10.24 | gilligan_ | JaMa, xserver-xorg_1.7.4.bb |
| 15:10.37 | JaMa | gilligan_: I was the last one changing xserver wrt HAL.. so maybe I've broken something :/ |
| 15:10.51 | *** join/#oe Tryum (~Tryum@e-corporation.info) |
| 15:10.54 | JaMa | gilligan_: do you have error log? |
| 15:11.02 | Romke | hehe |
| 15:11.13 | JaMa | gugus: is the problem that hal wasn't built before xserver? |
| 15:11.13 | Romke | I guess I found my answer in the mailinglist indeed |
| 15:11.17 | JaMa | gilligan_: ^ |
| 15:11.37 | gilligan_ | JaMa, yeah i suppose it's a screwed up dependency thing |
| 15:12.16 | gilligan_ | JaMa, not much interesting stuff to log really ... "configure: error: HAL hotplug API requested, but HAL is not installed" |
| 15:12.26 | gilligan_ | JaMa, building hal manually now and then trying again |
| 15:13.01 | JaMa | gilligan_: show me please bitbake -e xserver-xorg |
| 15:13.37 | JaMa | gilligan_: this DISTRO_XORG_CONFIG_MANAGER ?= "hal" and RDEPENDS = "${DISTRO_XORG_CONFIG_MANAGER}", should make hal available |
| 15:14.07 | gilligan_ | hang on |
| 15:14.08 | JaMa | but I should probably add ${DISTRO_XORG_CONFIG_MANAGER} also to DEPENDS |
| 15:14.32 | gilligan_ | eh..yeah |
| 15:14.40 | gilligan_ | it's not a runtime dependency only |
| 15:15.24 | JaMa | but doesn't bitbake always build RDEPENDS before package too? |
| 15:16.13 | hrw | rdepends? not have to |
| 15:16.22 | JaMa | at least it's the case I usually see while building, but maybe with more bb threads it's not the rule |
| 15:16.32 | hrw | DEPENDS needs to be staged before. RDEPENDS do not have to |
| 15:16.39 | JaMa | hrw: thanks, I'll add it to DEPENDS |
| 15:16.47 | gilligan_ | in that case there would be little use in using rdepends and depends |
| 15:17.13 | gilligan_ | hence please add hal to xorg DEPENDS |
| 15:17.31 | hrw | if xorg links to hal then it is depends |
| 15:17.44 | *** join/#oe rednul_ (~rednul@host-98-127-6-7.bln-mt.client.bresnan.net) |
| 15:17.59 | hrw | XorA: rebuilt from clean file-native 5.04 and magic.mgc has 1.7MB |
| 15:18.20 | gilligan_ | hrw, dunno if it does.. all i know is configure fails right now because hal is missing |
| 15:18.28 | hrw | log? |
| 15:20.11 | gilligan_ | where does bitbake save logs ? lost the relevant output from scrollback after bitbake -e xserver-xorg ... |
| 15:20.48 | Romke | ~hail JaMa |
| 15:20.49 | ibot | ACTION bows down to JaMa and chants, "I'M NOT WORTHY!!" |
| 15:20.50 | gilligan_ | oh..it was independent for each package iirc |
| 15:20.56 | Romke | it works |
| 15:21.28 | Romke | I could use the pointer after a day of work |
| 15:23.56 | *** join/#oe denix|air (~denys@32.165.10.81) |
| 15:26.40 | *** join/#oe Longfield (~valentin@lsa1pc7.epfl.ch) |
| 15:26.57 | gilligan_ | hrw, http://pastebin.com/3q4JsSGs |
| 15:27.23 | gilligan_ | hrw, log of failed xserver-xorg configure |
| 15:27.37 | hrw | 1thx |
| 15:27.46 | JaMa | hrw: there is small problem with moving DISTRO_XORG_CONFIG_MANAGER to DEPENDS in case you want just libudev :/ |
| 15:28.20 | hrw | --enable-config-hal was given so HAL was checked |
| 15:28.22 | JaMa | hrw: for RDEPENDS libudev was enough, but to DEPENDS I have to put udev right? |
| 15:28.24 | gilligan_ | hrw, after that I ran 'bitbake hal' and tried 'bitbake x11-image' again and xserver-xorg builds fine (or well.. still running) |
| 15:29.05 | hrw | JaMa: right |
| 15:29.20 | hrw | JaMa: it dl() libudev not links to it? |
| 15:29.27 | JaMa | hrw: but then I'll get whole udev as runtime dependency? |
| 15:29.34 | gilligan_ | hrw, well is --enable-config-hal intended or not ? I assume angstrom uses hal |
| 15:30.10 | hrw | JaMa: no |
| 15:30.32 | hrw | gilligan_: I am not X11 mastah |
| 15:30.50 | JaMa | hrw: I have to check if it links to it (because I have both hal/libudev disabled in my builds) |
| 15:31.06 | broonie | Gah. How do I persuade OE to build a compiler with EABI support? |
| 15:31.18 | gilligan_ | hrw, too bad.. me neither ;-D |
| 15:31.44 | Romke | dammit |
| 15:32.17 | Romke | the AT91 PATA driver is included in the kernel, but doesn't seem to be working :/ |
| 15:32.38 | XorA | broonie: DISTRO=angstrom-2008.1 |
| 15:33.40 | Jin^eLD | hmm, anyone seen this problem with building uboot from oe dev http://pastebin.mozilla.org/705525 |
| 15:33.40 | broonie | XorA: That's what I'm using. Turns out it's installed a compiler into cross after only initial which confused me. |
| 15:36.34 | hrw | | configure: error: cannot compute suffix of object files: cannot compile |
| 15:36.34 | hrw | | See `config.log' for more details. |
| 15:36.34 | hrw | | make[1]: *** [configure-target-libgcc] Error 1 |
| 15:36.34 | hrw | | make[1]: Leaving directory `/home/hrw/devel/build/micro/tmp/work/armv5te-oe-linux-gnueabi/gcc-cross-initial-4.4.2-r2.1/gcc-4.4.2/build.x86_64-linux.arm-oe-linux-gnueabi' |
| 15:36.38 | hrw | arhg |
| 15:37.50 | Jin^eLD | what is this git read-tree 1 failed with signal 128, output: fatal: Not a valid object name 1 ? did something change in the uboot trunk or what is it? |
| 15:38.58 | kergoth | SRCREV not set, likely, afaik |
| 15:39.02 | kergoth | yawns |
| 15:39.22 | Jin^eLD | let me pull again, maybe I am not at the latest oe.dev rev... |
| 15:43.12 | hrw | lets restart |
| 15:44.46 | dm8tbr | pointers appreciated as to how I make sure that includes are found for an recipe correctly. currently I get "glib.h: No such file or directory" - I built that by hand and also added it to DEPENDS just in case |
| 15:45.07 | dm8tbr | this is fennec_hg.bb jftr |
| 15:47.43 | dm8tbr | meh, the issue might be different it is looking for build//angstrom-dev/staging/i686-linux/usr/bin/libIDL-config-2 which is actually in build/angstrom-dev/staging/i686-linux/usr/bin/armv7a-angstrom-linux-gnueabi/libIDL-config-2 |
| 15:50.55 | *** join/#oe alecrim (~alecrim@189.2.128.130) |
| 15:50.58 | dm8tbr | why would bitbake get that wrong? |
| 15:52.26 | zecke | dm8tbr: it has nothing to do with bitbake. |
| 15:53.13 | dm8tbr | zecke: ok, where do I have to look then? at the fennec recipe, the libidl recipe? |
| 15:53.23 | zecke | dm8tbr: How did you determine "looking" for? strace? |
| 15:53.41 | hrw|gone | bye |
| 15:53.53 | dm8tbr | zecke: it's in the output for a failed bitbake -b fennec |
| 15:54.44 | dm8tbr | before it wouldn't even go past the configure, but then I built the libraries configure was missing using bitbake |
| 15:55.02 | zecke | dm8tbr: check classes/mozilla.bbclass |
| 15:55.25 | zecke | dm8tbr: from a quick glance, it appears that we use pkg-config to ask for the path of libIDL-config-2 |
| 15:55.51 | XorA | wonders if avr32 kernel developers have a special toolchain |
| 15:57.38 | dm8tbr | zecke: excuse my ignorance but I'm rather unfamiliar with the whole oe/bitbake structure. how would I go and troubleshoot that? |
| 15:57.58 | dm8tbr | and all that because I wanted a working fennec build... |
| 15:58.31 | dm8tbr | jftr the fennec package I got from the regular feed looked rather broken |
| 15:59.34 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r175f25a8e3 10openembedded.git/recipes/linux/ (3 files in 2 dirs): |
| 15:59.34 | CIA-2 | linux-openmoko-2.6.32: simplified JBT6k74 driver as WSOD fix |
| 15:59.34 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 15:59.35 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r517816ac3c 10openembedded.git/recipes/shr/ (initscripts-shr/mountdevsubfs.sh initscripts-shr_0.0.1.bb): |
| 15:59.35 | CIA-2 | initscripts-shr: create /dev/pts, /dev/shm if they doesn't exist (devtmpfs doesn't create them for us and ssh login fails later due to missing PTYs) |
| 15:59.35 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 15:59.36 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r899adeeaab 10openembedded.git/recipes/tasks/task-shr-minimal.bb: |
| 15:59.36 | CIA-2 | task-shr-minimal: we need MACHINE_ARCH, because task-base and MACHINE_TASK_PROVIDER are machine specific |
| 15:59.36 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 15:59.37 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r98278bf81f 10openembedded.git/recipes/xorg-xserver/xorg-xserver-common.inc: |
| 15:59.37 | CIA-2 | xorg-xserver-common: move DISTRO_XORG_CONFIG_MANAGER from RDEPENDS to DEPENDS, because configure checks hal availability. Thanks to gilligan for reporting. |
| 15:59.38 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 15:59.38 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r0d6078ea08 10openembedded.git/recipes/ (dri/libdrm_git.bb mesa/mesa-dri_git.bb): |
| 15:59.54 | CIA-2 | mesa-dri, libdrm: use distro override to force same PV for om-gta01 and om-gta02 |
| 15:59.54 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 16:00.05 | gilligan_ | does anyone know if qemu-arm will be of any use for trying beagleboard images ? |
| 16:00.40 | zecke | dm8tbr: fennec_hg.bb is doing a "inherit mozilla", which means the textual content of "classes/mozilla.bbclass" is copied into the recipe. |
| 16:00.59 | gilligan_ | at least qemu-arm lists cortex-a8 as cpu model.. can't be all bad ;) |
| 16:01.56 | dm8tbr | nuhu, expect me back with more questions during the weekend. I'll try to wrap my head around that then |
| 16:02.21 | zecke | dm8tbr: eeek. okay. Troubleshooting. Figure out who is coming up with the "bad" path. The first stop should be config.log of the fennec build |
| 16:02.38 | dm8tbr | I won't put up with an horribly slow firefox3 if I could have a better performing firefox mobile... |
| 16:03.19 | dm8tbr | roger that. lot's of grep ahead :) |
| 16:05.30 | zecke | dm8tbr: yeah, the config.log is quite easy. I would try to figure out if it is a) something we pass with a --option to ./configure or b) firefox figures it out by itself |
| 16:05.51 | dm8tbr | ok |
| 16:09.13 | *** join/#oe glenn_ (~glenn@213.49.132.19) |
| 16:28.58 | *** join/#oe dth (~dieter@p4FDED3BA.dip.t-dialin.net) |
| 16:31.52 | *** join/#oe reachfh (~reachfh@123-204-77-220.adsl.dynamic.seed.net.tw) |
| 16:49.45 | *** join/#oe kristoffer (~kristoffe@109.58.55.145.bredband.tre.se) |
| 16:54.50 | *** join/#oe dth_ntb (~dieter@p4FDED3BA.dip.t-dialin.net) |
| 17:04.10 | *** join/#oe toi (~toi@d54C2A96D.access.telenet.be) |
| 17:06.14 | broonie | Dammit, this compiler still doesn't claim to do EABI. |
| 17:09.07 | *** join/#oe ademarez (~ademarez@188.126-14-84.ripe.coltfrance.com) |
| 17:11.44 | ademarez | Hi all, |
| 17:12.47 | ademarez | I experience a strange problem when trying to use my QT4 application in angstrom (both QT4 and GCC are the standard versions from angstrom) : I cannot run my app, and I have the error message : /lib/libgcc_s.so.1: version 'GCC_4.1.0' not found (required by /usr/lib/libQtScriptE.so.4) |
| 17:13.36 | ademarez | (despite I compiled everything in a "single shot", with GCC 4.3.3) |
| 17:13.55 | ademarez | does anyone know where it could come from ? (is it a bug ?) |
| 17:23.54 | *** join/#oe kerute (~kerute@kerunix.com) |
| 17:35.07 | *** join/#oe Ox83 (~Ox83@c-24-130-249-162.hsd1.ca.comcast.net) |
| 17:35.56 | CIA-2 | 03Antonio Ospite <ospite@studenti.unina.it> 07org.openembedded.dev * r04fa0decdc 10openembedded.git/recipes/meta/meta-toolchain.bb: |
| 17:35.57 | CIA-2 | meta-toolchain: Show the host system in toolchain archive name |
| 17:35.57 | CIA-2 | Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> |
| 17:35.57 | CIA-2 | Signed-off-by: Tom Rini <tom_rini@mentor.com> |
| 17:48.34 | Tartarus | hey khem? |
| 17:56.54 | *** join/#oe darion76 (~darion76@92-49-210-198.dynamic.peoplenet.ua) |
| 18:07.47 | *** join/#oe Hasse_ (~quassel@0x5552e721.adsl.cybercity.dk) |
| 18:11.56 | kergoth | grumbles |
| 18:12.23 | Jin^eLD | somehow my rootfs got populated by unstripped libraries... how did that happen? |
| 18:13.46 | kergoth | It's a bug, I'll push a fix in a moment |
| 18:14.06 | Jin^eLD | oh ok, cool |
| 18:14.15 | Jin^eLD | I'll be here to test it then |
| 18:15.16 | *** join/#oe jmpdelos (~polk@outgoing.delos.com) |
| 18:16.30 | *** join/#oe jmpdelos_ (~polk@outgoing.delos.com) |
| 18:16.48 | CIA-2 | 03Chris Larson <clarson@kergoth.com> 07org.openembedded.dev * r9ce55ea62b 10openembedded.git/classes/package.bbclass: |
| 18:16.48 | CIA-2 | Revert "package.bbclass: when running 'file', be explicit about the path to the magic" |
| 18:16.49 | CIA-2 | Drop this for now, as apparently the magic file location varies with 'file' |
| 18:16.49 | CIA-2 | version. I'll just patch file to find it relative to the binary location |
| 18:16.49 | CIA-2 | instead. |
| 18:16.49 | CIA-2 | This reverts commit 1b5e7041ae3b26b7e59c76bd2f2fd72e35492940. |
| 18:16.55 | kergoth | Jin^eLD: that should do it. |
| 18:17.01 | Jin^eLD | thanks |
| 18:17.07 | kergoth | np |
| 18:18.40 | *** join/#oe dvermd (~roudoudou@78.234.93.192) |
| 18:19.23 | *** join/#oe jmpdelos__ (~polk@outgoing.delos.com) |
| 18:21.50 | *** join/#oe jmpdelos (~polk@outgoing.delos.com) |
| 18:45.09 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * red51f18cde 10openembedded.git/recipes/xinput-calibrator/ (4 files): |
| 18:45.10 | CIA-2 | xinput-calibrator: add version 0.6.0 and also git version from misclick branch |
| 18:45.10 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 18:45.19 | *** join/#oe jmpdelos_ (~polk@outgoing.delos.com) |
| 18:46.50 | *** join/#oe jmpdelos__ (~polk@outgoing.delos.com) |
| 18:53.10 | blindvt | kergoth, seen me s/!=None// hunks? |
| 18:56.04 | blindvt | file. btw.. version specific patches. From a short glance, i did not manage to find precedence for how would i express for foo-47.11 apply bar-0.8.15-if-foo-47.11.patch ? |
| 18:56.08 | kergoth | didn't, sounds good though |
| 18:57.12 | blindvt | kergoth, perhaps i forgot to send it out? mompls.. |
| 19:00.17 | blindvt | kergoth, oh, and i'm contemplating a \"parser.add_option( "-C", "--kconfig", help = "emit kconfig",\" inspired by your (rightful) complaint^Wnote to the libtool list, fyi |
| 19:00.28 | *** join/#oe GNUtoo|oeee (~GNUtoo@host192-8-dynamic.9-87-r.retail.telecomitalia.it) |
| 19:04.44 | *** join/#oe Heinervdm (~thomas@pD9E14E50.dip.t-dialin.net) |
| 19:05.17 | blindvt | kergoth, story was like: find ./ -name "*.py" -exec sed -i -e "s/\!=[[:space:]]*None:/:/g" {} +; && git commit -s -a -m '*: trim != None:' && yes | git send-email --to $kergoth HEAD^..HEAD |
| 19:06.58 | blindvt | kergoth, but i'm apparently unable to find the box that i used to generate it :( Anyway. PLease push if you feel like (it works fine for me for my oe setup, if that counts as testing) |
| 19:07.58 | *** join/#oe vadmeste (~hannken@41.224.210.223) |
| 19:08.02 | blindvt | kergoth, and yes, you're really in my .profile.local by now ;) |
| 19:08.47 | blindvt | kergoth, although you seem to (still?) have a box where your GIT_ points to MV, so perhaps check them.. :) |
| 19:09.44 | kergoth | isn't at MV, and doesn't have access to anything of MV. |
| 19:10.21 | vadmeste | Hey, I need to understand why I should set vm.mmap_min_addr to 0.. Can anyone respond me ? |
| 19:10.59 | kergoth | i really hate computers. |
| 19:11.51 | broonie | kergoth: Apparently the feeling's mutual :) |
| 19:11.57 | kergoth | indeed |
| 19:12.39 | Jin^eLD | :) |
| 19:13.31 | blindvt | ;P |
| 19:14.36 | *** join/#oe mlip2 (~mlip2@85-127-232-139.dynamic.xdsl-line.inode.at) |
| 19:18.32 | blindvt | kergoth, be assured that i share your feelings in this respect. Thing is, if no-one fixes them they won't get any better. Think LFS, threads or NLS. Plain PITA, but if they cry for crap like that?.. |
| 19:22.01 | *** join/#oe woglinde (~heinold@f052066080.adsl.alicedsl.de) |
| 19:28.38 | *** join/#oe eFfeM1 (~frans@j200125.upc-j.chello.nl) |
| 19:31.34 | hrw|gone | kergoth: any plans to restore df32920678d15c86897b50b752b937210a01edea commit? |
| 19:32.34 | hrw | vadmeste: qemu <0.12 (so any OE one) require that to get binary locale generation working |
| 19:33.12 | hrw | kergoth: thats about using md5/sha256 from Python instead of calling commands |
| 19:34.12 | woglinde | hrw uh why was it switched? |
| 19:34.19 | blindvt | hrw, md5 is already in there, no? and sha256sum is just a matter of seeing if the hasher supports it else fallback to a bb internal sha256 impl in C that gets linked in |
| 19:35.21 | hrw | blindvt: 80 md5pipe = os.popen('PATH=%s md5sum %s' % (bb.data.getVar('PATH', data, True), localpath)) |
| 19:35.31 | woglinde | hm |
| 19:35.33 | hrw | blindvt: we call commands like before |
| 19:35.41 | woglinde | qgit dont find this revision |
| 19:36.06 | *** join/#oe mr_nice (~nice@95-90-75-53-dynip.superkabel.de) |
| 19:36.54 | hrw | commit df32920678d15c86897b50b752b937210a01edea |
| 19:36.54 | hrw | Author: Ross Burton <ross@openedhand.com> |
| 19:36.55 | hrw | Date: Fri Jan 15 08:30:33 2010 +0000 |
| 19:37.02 | hrw | was reverted in: |
| 19:37.07 | blindvt | hrw, wasn't there some try:\nimport md5 block int here that was supposed to handle that? Dunno offhand |
| 19:37.08 | hrw | commit 22ee98e2fc4d58de61184332e41b9a44c949ed17 |
| 19:37.09 | hrw | Author: Chris Larson <chris_larson@mentor.com> |
| 19:37.09 | hrw | Date: Thu Feb 25 13:11:28 2010 -0700 |
| 19:37.16 | woglinde | hm oh |
| 19:37.22 | woglinde | didnt update |
| 19:37.24 | woglinde | since then |
| 19:37.25 | woglinde | *g* |
| 19:37.48 | blindvt | hrw, or s/md5/hashlib/ or however it's called |
| 19:38.12 | hrw | blindvt: I know, I had hands in that code in Poky time |
| 19:41.49 | blindvt | hrw, http://bugs.python.org/msg45775 so this should now be available about everywhere i guess |
| 19:44.04 | *** join/#oe reithi_ (~5dccba5d@gateway/web/freenode/x-rmikhaoptgivuxga) |
| 19:45.08 | reithi_ | hello |
| 19:45.13 | reithi_ | <PROTECTED> |
| 19:45.14 | blindvt | hrw, let's just move the pipe fallback to lib/bb/oh_dear/sha256.freakin-python-issue935454.py and import that (deriving hashlib) as 256sum-er |
| 19:45.25 | *** join/#oe zecke (~ich@193-4-248-222.static.metronet.is) |
| 19:45.40 | woglinde | jo zecke |
| 19:45.43 | hrw | reithi_: we all did |
| 19:45.53 | woglinde | hrw *g* |
| 19:46.06 | reithi_ | I like to build a qte image |
| 19:46.17 | woglinde | sure |
| 19:46.19 | woglinde | do it |
| 19:46.21 | blindvt | i wouldn't want to |
| 19:46.21 | reithi_ | is opie the place to start ? |
| 19:46.26 | woglinde | no |
| 19:46.31 | hrw | was new 6 years ago and that was not fun |
| 19:46.32 | woglinde | opie is based on qt2 |
| 19:47.02 | blindvt | hrw, i'm new #here now and it is. Everthing's jazz :) |
| 19:47.11 | reithi_ | so is there a receipe using qte 453 |
| 19:47.24 | woglinde | we are at 4.6 too |
| 19:47.53 | reithi_ | great |
| 19:48.10 | woglinde | if you want |
| 19:48.14 | woglinde | with gles support |
| 19:48.21 | reithi_ | so how to build a rootfs image ? |
| 19:48.34 | woglinde | look under recipes/qt4 |
| 19:48.47 | woglinde | hm? |
| 19:49.05 | reithi_ | ok I will do |
| 19:49.13 | woglinde | an image likes to contains a rootfs |
| 19:49.14 | reithi_ | thx so far |
| 19:49.27 | woglinde | so building a rootfs-image is missleading |
| 19:49.50 | reithi_ | ok |
| 19:50.11 | reithi_ | I build an console image so far |
| 19:50.31 | reithi_ | now i need qte with fb support |
| 19:51.19 | woglinde | look at recipes/images |
| 19:51.28 | woglinde | how to make your custom image |
| 19:51.36 | woglinde | or make console-image |
| 19:51.43 | woglinde | and install qte packages afterward |
| 19:51.45 | woglinde | via opkg |
| 19:52.16 | reithi_ | thats what i did so far ;-) |
| 19:53.28 | reithi_ | but I thougth there may be something existing so far |
| 19:55.19 | reithi_ | however I'll have a look and try to make a custom one |
| 19:55.47 | reithi_ | thx woglinde |
| 19:57.32 | *** part/#oe reithi_ (~5dccba5d@gateway/web/freenode/x-rmikhaoptgivuxga) |
| 19:58.00 | *** join/#oe hillct (~hillct@cpe-069-134-049-165.nc.res.rr.com) |
| 19:59.56 | *** join/#oe RuudA (~ruud@dhcp-077-250-177-205.chello.nl) |
| 20:08.41 | *** join/#oe dth (~dieter@p4FDED3BA.dip.t-dialin.net) |
| 20:19.56 | *** part/#oe mlip2 (~mlip2@85-127-232-139.dynamic.xdsl-line.inode.at) |
| 20:27.13 | kergoth | hmm. |
| 20:28.15 | *** part/#oe darion76 (~darion76@92-49-210-198.dynamic.peoplenet.ua) |
| 20:28.36 | woglinde | jo kergoth |
| 20:33.14 | hrw|gone | bye |
| 20:33.50 | woglinde | nite hrw |
| 20:33.55 | *** join/#oe Martin-B (~martin@pool-152-65-198-89.dbd-ipconnect.net) |
| 20:41.31 | CIA-2 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r23009a6ecf 10openembedded.git/recipes/u-boot/ (3 files in 2 dirs): (log message trimmed) |
| 20:41.31 | CIA-2 | u-boot: removed environment patches |
| 20:41.31 | CIA-2 | removed 0006-cmd_itest.c-also-support-environment-variables-as-a.patch |
| 20:41.31 | CIA-2 | this one was rejected upstream as the functionality was already in hush |
| 20:41.31 | CIA-2 | reworked 0007-cmd_setexpr-allow-memory-addresses-and-env-vars-in-e.patch |
| 20:41.32 | CIA-2 | the setenv part was rejected upstream as the functionality was already in hush |
| 20:41.33 | CIA-2 | took that part out of the patch. |
| 20:41.34 | CIA-2 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * rf0da6033e6 10openembedded.git/recipes/tasks/task-nas-server.bb: (log message trimmed) |
| 20:41.35 | CIA-2 | task-nas-server removed the openmoko part |
| 20:41.35 | CIA-2 | removed the openmoko part from the nas server task |
| 20:41.35 | CIA-2 | this part only drags in dfu-util which does not build under most distro's |
| 20:41.35 | CIA-2 | openmoko users are very unlikely to run a NAS on their device, and even |
| 20:41.36 | CIA-2 | if they want to and need dfu-util, they can easily install afterwards |
| 20:41.36 | CIA-2 | (and dfu-util is not even nas related, so it does not really belong in this task) |
| 20:41.37 | CIA-2 | 03Frans Meulenbroeks <fransmeulenbroeks@gmail.com> 07org.openembedded.dev * r9c022f7728 10openembedded.git/ (2 files in 2 dirs): |
| 20:41.37 | CIA-2 | linux/linux-davinci/hawkboard added netfilter modules to defconfig |
| 20:42.23 | CIA-2 | added netfilter modules to hawkboard defconfig |
| 20:42.23 | CIA-2 | these are needed in order to build nas-server-image |
| 20:42.23 | CIA-2 | Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> |
| 20:44.52 | Tartarus | Oh my |
| 20:45.01 | Tartarus | qemu gcc 3.x checks are insane... |
| 20:45.14 | Tartarus | Is 3.2.x and 3.3.x supposed to work on the old magic 0.9.x versions? |
| 20:45.29 | Tartarus | It's listed in the gcc check fn, but still saying "Only some 3.4.x's will work" |
| 20:48.00 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 20:48.06 | florian | re |
| 20:49.40 | Tartarus | hey florian |
| 20:49.53 | woglinde | hi florian |
| 20:50.11 | *** join/#oe mickey|zzZZzz (~mickey@openmoko/coreteam/mickey) |
| 20:51.12 | *** join/#oe mickey|zzZZzz (~mickey@80.81.242.146) |
| 20:55.29 | eFfeM1 | as brought up by graham on the ML: why do we keep svn-updates.dpatch in the gcc 4.3.[1-4] dirs ? |
| 20:56.08 | eFfeM1 | saw the 4.4 versions are gone |
| 20:56.47 | Tartarus | Probably because someone didn't notice they weren't used anymore, and then just left them there |
| 20:57.00 | *** join/#oe B_Lizzard (~havoc@athedsl-429019.home.otenet.gr) |
| 20:57.06 | Tartarus | It should become svn-updates-4.whatever-uses-it.dpatch, in the files/ dir |
| 20:57.10 | Tartarus | And nuke all of the extra copies |
| 20:57.29 | Tartarus | (Of course then someone will ask about dropping all of the various very old versions, say pre 4.2.4 at least) |
| 21:01.39 | Tartarus | hrw|gone: Do you recall why you added gcc-3.3.x / 3.2.x to the qemu gcc logic? |
| 21:01.58 | Tartarus | hrw|gone: Well, 3.2.x.. |
| 21:04.19 | *** join/#oe Crofton (~balister@66-207-65-47.bark.dmt.ntelos.net) |
| 21:04.42 | eFfeM1 | Tartarus: actually they are not used at all |
| 21:04.59 | Tartarus | I assume, but could be wrong, that at some point it was used |
| 21:05.08 | Tartarus | But if it's never ever been used, hey, that's an even easier fix :) |
| 21:05.17 | eFfeM1 | frans@linux-suse:~/oe/openembedded/recipes/gcc> grep svn-updates * |
| 21:05.17 | eFfeM1 | frans@linux-suse:~/oe/openembedded/recipes/gcc> |
| 21:05.28 | Tartarus | Yeah, but does that catch the rename? |
| 21:05.38 | Tartarus | (packages/ to recipes/) |
| 21:05.48 | Tartarus | git grep it, with some magic flags |
| 21:06.24 | eFfeM1 | Tartarus: don't understand, if there is no recipe in recipes/gcc using it, then it is pointless to keep it around isn't it ? |
| 21:06.47 | Tartarus | Right. But it's good to know (for the comments) when it should have been deleted |
| 21:06.51 | eFfeM1 | btw as several people reacted on graham's email I expected that someone already fixed it |
| 21:07.23 | eFfeM1 | will try some git magic :-) |
| 21:09.47 | eFfeM1 | seems they are just copied over |
| 21:13.17 | eFfeM1 | hmm, better leave it as is, i think i've but enough karma on the line last few weeks, better not risk getting the whole community over me if something still accidently breaks, will drop an email though guess gcc patches should go to the review procedure anyway |
| 21:14.39 | Crofton | eFfeM, best become an expert on gcc first :) |
| 21:17.05 | eFfeM1 | Crofton :-) |
| 21:20.17 | *** join/#oe kergoth_ (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 21:24.29 | XorA | * We currently have two bytes left at this point until we |
| 21:24.29 | XorA | <PROTECTED> |
| 21:24.46 | XorA | yes it does let us know, let us know that the avr32 kernel dudes are smoking something :-( |
| 21:25.45 | *** join/#oe denix|air (~denys@166.196.110.42) |
| 21:26.25 | *** join/#oe ant__ (~andrea@host1-50-dynamic.5-87-r.retail.telecomitalia.it) |
| 21:32.03 | *** join/#oe otavio (~otavio@debian/developer/otavio) |
| 21:34.17 | woglinde | hi ant |
| 21:34.27 | XorA | is actually stunned |
| 21:34.41 | woglinde | xora why? |
| 21:34.58 | XorA | woglinde: I dont think anyone is compiling avr32 |
| 21:35.06 | XorA | they are just randomely checking in patches |
| 21:35.14 | XorA | or there is some magic secret version of binutils |
| 21:35.26 | woglinde | xora some people tried the over the last weeks |
| 21:35.39 | XorA | woglinde: I dont mean in OE, I mean kernel developers |
| 21:36.00 | woglinde | hm oh |
| 21:36.10 | woglinde | I think avr32 is dead for them |
| 21:36.16 | woglinde | as its for atmel |
| 21:36.31 | XorA | I just cant beleive this patch, and it comes from atmel |
| 21:36.39 | woglinde | oh wau the n810 survied 3 weeks with out power |
| 21:36.56 | woglinde | hehe aks ulf |
| 21:36.59 | woglinde | ups ask |
| 21:38.19 | ant__ | hello woglinde |
| 21:38.22 | ant__ | hi XorA |
| 21:38.39 | XorA | should have stayed as a windows kernel developer :_D |
| 21:39.20 | Romke | windows kernel developer? |
| 21:39.26 | Romke | are you serious? :P |
| 21:39.54 | Romke | i would like to kill somebody at embest by the way |
| 21:40.03 | woglinde | xora hm you would have missed a lot of fun |
| 21:40.21 | Romke | i follow their manual, and the CF card still doesn't work |
| 21:40.35 | woglinde | romke hm? |
| 21:40.56 | Romke | yeah |
| 21:41.06 | Romke | i've got an SBC6020 at the office |
| 21:41.10 | woglinde | why shouldn't a cf card not work? |
| 21:41.27 | Romke | with an at91sam9g20 cpu |
| 21:41.52 | Romke | but only one ethernet interface works |
| 21:41.58 | Romke | the cf card doesn't work |
| 21:42.10 | Romke | only three out out 7 USART's work |
| 21:42.24 | Romke | usb seems to work |
| 21:43.27 | Romke | i've got 2.6.33 kernel, with all the driver options they state in their manual enabled |
| 21:43.31 | Romke | but it still doesn't work |
| 21:43.43 | woglinde | hm |
| 21:43.50 | Romke | which makes me want to kill the bloody chinese who wrote the manual :P |
| 21:43.58 | woglinde | for x86 hardware I would say check the bios |
| 21:44.07 | Romke | yeah |
| 21:44.08 | woglinde | otherwis maybee hardware is broken |
| 21:44.17 | Romke | the stock kernel works |
| 21:44.37 | Romke | recognices the CF card 'nd stuff |
| 21:44.52 | Romke | but i can't even extract the sources provided on the cd |
| 21:45.10 | woglinde | lol? |
| 21:45.21 | woglinde | vanilla kernel works out of the box? |
| 21:45.25 | Romke | no |
| 21:45.28 | Romke | not vanilla kernel |
| 21:45.32 | Romke | the kernel they proviced |
| 21:45.35 | Romke | provided* |
| 21:45.37 | woglinde | ah yeah |
| 21:45.53 | Romke | but they didn't provide the patches they used |
| 21:45.59 | woglinde | uh |
| 21:46.04 | woglinde | thats not good |
| 21:46.06 | Romke | if any |
| 21:46.19 | zecke | woglinde: hey! |
| 21:46.29 | woglinde | jo zecke |
| 21:46.36 | Romke | which would mean that i would have to run diff over their source and the vanilla source |
| 21:49.00 | Romke | work, work, hack, hack |
| 21:49.16 | Romke | well, i'll live |
| 21:49.28 | Romke | being the intern ftw |
| 21:49.51 | *** join/#oe thaytan (~jan@121.91.41.2) |
| 21:50.04 | Romke | i have virtually no time restrictions :+ |
| 21:51.09 | khem | Tartarus: hello looking for me still ? :) |
| 21:51.12 | khem | hi all |
| 21:52.14 | Romke | hello |
| 21:53.42 | Tartarus | yeah |
| 21:53.54 | woglinde | hi khem |
| 21:53.54 | Tartarus | khem: You didn't really reply to my suggestions for eglibc packaging :) |
| 21:54.29 | Tartarus | Do you want any/all of that? And if so, are you planning to do the glibc-packaging.bbclass -> eglibc-packaging.inc easy stuff? |
| 21:54.39 | Tartarus | (ie resync the -dev packages, add libmemwhatever) |
| 21:56.23 | kergoth | grr, stupid "build within a path that has a symlink" bug |
| 21:56.32 | kergoth | forgot about that one :) |
| 21:56.34 | Tartarus | heh |
| 21:57.27 | denix | kergoth: btw, what exactly causes that bug? |
| 21:57.52 | Crofton | I think some of the autotools scripts have issues with that |
| 21:58.00 | kergoth | iirc its the difference between $PWD and the specified path. i think it was autoconf that compares the two to check somethingorother |
| 21:58.01 | Crofton | so it is not really an OE specific issues |
| 21:58.04 | kergoth | nods |
| 21:59.04 | denix | right |
| 21:59.43 | kergoth | someday should look into how much work itd be to fix.. thats one of those long standing little quirks |
| 21:59.46 | kergoth | heh |
| 22:00.59 | denix | now I remember this - GNUmakefile: Too many levels of symbolic links |
| 22:01.47 | Tartarus | khem: Ah, dead disks suck. |
| 22:01.57 | Tartarus | khem, I'll see what I can do for some patches and maybe even testing ;) |
| 22:02.44 | denix | Tartarus: you mentioned you have pstage outside of temp in your setup... |
| 22:03.04 | Tartarus | correct |
| 22:03.19 | denix | Tartarus: but not deploy. does the build from pstage work if you nuke tmp dir? |
| 22:03.32 | kergoth | it does, yes |
| 22:03.44 | denix | don't you need real ipks also? |
| 22:03.56 | kergoth | pstage packages include the binary packages for the target. |
| 22:04.14 | Tartarus | Yeah |
| 22:04.24 | khem | Tartarus: re. eglibc I said that its going to diverge even more |
| 22:04.32 | Tartarus | My hell-build is doing every package step for a "full" build from just the caches of previous deps |
| 22:04.44 | kergoth | has thought about just capturing the do_install into the pstage package and let packaging go from that, to keep packaging changes from invalidating pstage packages, though |
| 22:04.51 | khem | and so having common include or something for glibc might not be fruitful in long run |
| 22:04.55 | Tartarus | khem: Right, so no generic'ing of glibc's bbclass. But there's stuff they need |
| 22:04.59 | Tartarus | Er |
| 22:05.03 | Tartarus | Stuff in there eglibc needs |
| 22:05.31 | khem | Tartarus: may be having a generic class for libc would be better including eglibc/glibc/uclibc |
| 22:05.44 | *** join/#oe robtow (~rob@dsl092-218-034.sfo2.dsl.speakeasy.net) |
| 22:05.46 | khem | because eglibc's build will tend more towards uclibc |
| 22:05.53 | Tartarus | khem: Perhaps, yes. It really depends on what common stuff there really is.. |
| 22:06.16 | khem | Tartarus: packaging for eglibc and glibc will remain same to a certain extent |
| 22:06.23 | Tartarus | khem: But my questions are (a) are you going to fix/resync -dev and add libmemwhateverthat is or should I and (b) what do you think about adding *libc-pic packages? |
| 22:06.43 | khem | yeah sync is good |
| 22:06.46 | khem | go ahead |
| 22:06.48 | Tartarus | k |
| 22:06.58 | khem | we should take the goodies |
| 22:07.00 | khem | for free |
| 22:07.01 | Tartarus | Doing an initial set of builds now |
| 22:07.08 | Tartarus | Will resync, rebuild and post some stuff tomorrow |
| 22:07.17 | khem | Tartarus: sounds gr8 |
| 22:07.44 | robtow | sakoman - tried your R11 "Gnome image"; still have the same problem |
| 22:08.32 | sakoman | robtow: sorry to hear that :-( |
| 22:09.05 | robtow | sakoman - using brand new "Fire" module, on a new Tobi - isn't that your setup? |
| 22:09.31 | sakoman | yes |
| 22:09.33 | robtow | Also got a friend's Canon Rebel XT - so I think I have duplicated your setup pretty closely |
| 22:09.41 | sakoman | remind me what your issue is? |
| 22:10.17 | robtow | Getting error from gPhoto2 when trying to take pix or list files via USB from either a Canon G10 or a Rebel. |
| 22:10.36 | robtow | Tried both the latest Gumstix image, and your Gnome R11. |
| 22:11.34 | robtow | "usb 1-1: BOGUS urb flags, 1 --> 0" appears on the console, three times. |
| 22:11.55 | sakoman | robtow: I'll have to try again sometime this week, perhaps there has been bit rot since the last time I used it |
| 22:11.59 | robtow | Hmm. |
| 22:12.48 | robtow | sakoman - has it been a while since you did <gphoto2 --capture-image" with your Canon Rebel attached to the Fire module? |
| 22:13.24 | sakoman | I'm not sure I *ever* did anything from the command line! |
| 22:13.35 | robtow | Ah. Hmm! |
| 22:13.51 | sakoman | I mostly just tried the GUI features and things seemed to work |
| 22:13.57 | robtow | nods> |
| 22:14.43 | sakoman | on a deadline for a client, so no time to test today |
| 22:15.06 | zecke | sakoman: you are keeping gnome uptodate? could you take a look at the gnome-screensaver package? there was a small security incident and I think our version is unpatched. |
| 22:15.22 | robtow | I understand :-) I'll struggle ahead as I can. One question, though - from the GUI did you only do list and download, or did you also do capture? |
| 22:15.49 | sakoman | robtow: just list and download, not capture |
| 22:16.18 | Crofton | robtow, when I get bored (hahahaha) I have a small nikon I would like to try with ghoto |
| 22:16.20 | khem | zecke: we should form a security team |
| 22:16.26 | sakoman | zecke: as I have time I update things |
| 22:16.30 | khem | zecke: I would be part of it |
| 22:16.43 | sakoman | but haven't looked at screensaver recently |
| 22:17.00 | robtow | Thanks, sakoman (altho' even list is not working from gPhoto2). |
| 22:17.14 | Crofton | yay, my plane has landed |
| 22:17.21 | robtow | sakoman - which gui program did you use for list & download? |
| 22:17.24 | zecke | khem: we should, would you have regular time for such an activity? My work life is coming in peeks making such things harder. |
| 22:17.35 | robtow | Crofton - which model Nikon? |
| 22:18.03 | Crofton | robtow, not sure, it was a compact cam, and the lcd viewfinder is broken |
| 22:18.09 | khem | zecke: I wud devote some time per week. |
| 22:18.15 | Crofton | used AA batteries |
| 22:18.33 | Crofton | khem, zecke forming a team to try and keep up with security would be a good thing |
| 22:18.47 | robtow | Crofton - it probably only works with list & xfer, not capture; most of the point and shoot cameras are like that - the G10 is unusual in that regard. |
| 22:18.49 | Crofton | robtow, it will be a while before I can look at it though |
| 22:19.14 | Tartarus | I can say from having done it before, security stuff is time consuming as hell :( |
| 22:19.15 | robtow | <nods> |
| 22:19.22 | Tartarus | Depending on how proactive you want to be |
| 22:19.27 | khem | zecke: job + 2 kids keeps me busy and job does use OE so its all in my own time |
| 22:19.38 | Tartarus | ie I had to make a script to dump the CVE db and do a diff, daily |
| 22:19.40 | robtow | I *have* to get gPhoto2 to work with the gumstix. Sigh. I had it working with the Beagleboard. |
| 22:19.43 | Crofton | it would still be a start getting some contact poepl together |
| 22:19.47 | Tartarus | And then give me the info on what changed |
| 22:19.51 | khem | Tartarus: eh I remember your MV days ;) |
| 22:20.03 | zecke | khem: cool, then we should do it. My primary goal would be to get the nr. of known issues down to zero. |
| 22:20.19 | zecke | khem: should we aim to get on the distro security lists too? |
| 22:20.20 | robtow | I tried both USB paorts on the Gumstix; got a mini-A to mini-B cable today. |
| 22:20.26 | khem | zecke: right. I will scan thru your list and see what we can do |
| 22:20.47 | khem | zecke: that wud be good idea |
| 22:20.51 | Crofton | ok, I need to get ready to go hopefully we board soon |
| 22:20.52 | sakoman | robtow: I think I was using gthumb |
| 22:21.05 | Tartarus | khem, zecke, are you guys thinking of fixing all of the old applicable versions or don't know yet? |
| 22:21.16 | Tartarus | That was one of the time consuming parts |
| 22:21.27 | robtow | sakoman - I'll give that a try... |
| 22:21.36 | khem | Tartarus: probably we should only fix active recipes first |
| 22:21.50 | khem | which means the recipes used in current distro's |
| 22:21.51 | zecke | Tartarus: no, most likely latest. Either by bumping the version or finding a patch. |
| 22:21.59 | khem | and go from there |
| 22:22.00 | Tartarus | That will help a little bit |
| 22:22.14 | zecke | Tartarus: how did you map CVE entry to package name of your distro? |
| 22:22.28 | Tartarus | zecke: Couldn't automate that part |
| 22:22.41 | khem | heh yeah its a manual think |
| 22:22.42 | Tartarus | There wasn't at the time any standard format for that kind of info in the CVE |
| 22:22.58 | Tartarus | So one of my morning tasks was to check the emails I had generated |
| 22:23.03 | khem | Tartarus: what was your primary source to detect the issues |
| 22:23.09 | zecke | one could probably cheat and use the HOMEPAGE field. |
| 22:23.14 | Tartarus | khem, to find new CVEs? |
| 22:23.19 | khem | Tartarus: yes |
| 22:23.21 | Tartarus | zecke: In the CVE or the recipes? |
| 22:23.23 | Tartarus | sec.. |
| 22:23.42 | Tartarus | lemme see if I have this around still |
| 22:23.44 | Tartarus | I hope I do |
| 22:24.10 | Tartarus | Bingo'ish |
| 22:24.14 | Tartarus | http://cve.mitre.org |
| 22:24.21 | Tartarus | There's a link there, somewhere, to a daily dump of the db |
| 22:24.23 | khem | zecke: we could add CVE number to patch |
| 22:24.38 | khem | zecke: then we could deduce from the SRC_URI and files:// |
| 22:24.39 | Tartarus | I cron'd, diff,ed old to new and then did a for loop to dump each new CVE into an email |
| 22:24.45 | Tartarus | Then procmail'd that to a folder |
| 22:25.04 | zecke | khem: right now my sources would be RSS for FreeBSD, Gentoo, Debian. For FreeBSD I have a script. For most of the packages I have 1:1 mapping, for others I have a map (e.g. pcre2 -> libpcre) |
| 22:25.08 | zecke | khem: good idea. |
| 22:25.44 | zecke | khem: so far I have only opted to make big upgrade. but applying the patch is a more conversative approach. |
| 22:25.45 | Tartarus | That'll catch when we've got stuff in common |
| 22:25.46 | khem | doesnt use RSS so much |
| 22:25.49 | Tartarus | Which might be good enough to start with |
| 22:26.07 | Tartarus | Get us out of the real bad place and decide if we want more work still |
| 22:26.31 | khem | pokes at akregator |
| 22:26.38 | robtow | sakoman - gThumb sees the Canon Rebel, but throughs an error. |
| 22:27.00 | Tartarus | Aw, looks like I might not have been smart enough to archive that particular script |
| 22:27.13 | robtow | "An error ocurred in the io-library ('Unspecified error'): No error description available. |
| 22:27.17 | zecke | Tartarus: one issue is with the CVE. I could reserve a number now, and disclose in a year. Would the CVE still show up at the time of the diclosure? |
| 22:27.33 | Tartarus | zecke: The DB is only disclosed stuff |
| 22:27.42 | Tartarus | Sometimes with a minor (unintentional) lag |
| 22:27.58 | Tartarus | So yes, from time to time I'd see stuff show up that was an otherwise "old" looking number |
| 22:28.33 | Tartarus | And, iirc, I did things this way since the various summary pages they did have didn't catch that stuff well, or at least it was a pain to read (no rss feed of it, at least at the time) |
| 22:28.57 | Tartarus | So I went from reload the daily updates page, open all links, to generate my own daily diffs in an email |
| 22:29.30 | robtow | Time for a lunch break. |
| 22:30.30 | Tartarus | So, unrelated, anyone think the firefox deps are good enough now that bitbake firefox, on an empty TMPDIR will work? |
| 22:30.44 | Tartarus | I think I've got the "right" parallel make stuff done for it and need to test :) |
| 22:31.18 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
| 22:31.24 | kergoth | hmm. |
| 22:31.27 | khem | Tartarus: yeah bitbake it may be you will figure out missing dependencies too as a bonus |
| 22:32.45 | Tartarus | khem: heh |
| 22:32.53 | Tartarus | Only so many cpu cycles per hour :) |
| 22:34.13 | zecke | https://cassandra.cerias.purdue.edu/CVE_changes/ that is nice |
| 22:36.09 | Tartarus | Yeah, that's the site I got tired of :) |
| 22:36.52 | zecke | it might be easier to stand on the shoulders of debian, gentoo and FreeBSD. They filter relevant software |
| 22:36.58 | Tartarus | If I had it to do over, I'd see if I could get ahold of someone and add some rss feeds |
| 22:37.10 | Tartarus | zecke: I'd strongly recommend that as a first pass |
| 22:37.28 | khem | nice |
| 22:37.29 | Tartarus | And maybe try prodding the commerical folks to make sure they're pushing any relevant security stuff up too |
| 22:37.48 | Tartarus | That might help cover older backports at least |
| 22:38.58 | zecke | the most difficult part in my script is version comparison... i thought bitbake's stuff would help me but it does not. |
| 22:40.25 | Tartarus | Again, depends on how through you need to be on being up to date / fixed. |
| 22:40.50 | Tartarus | The min version broken stuff depends on who had time to check what, in some cases |
| 22:41.14 | Tartarus | So at some point you need to just check your version, to be really sure |
| 22:42.38 | zecke | khem: nice that we agree on the first target. We should keep a log too? For stuff where we apply a patch we put the cve name in the filename. What about stuff like my wireshark upgrade from yesterday. It is fixing several CVEs but I didn't mention that in the commit message. |
| 22:43.02 | *** join/#oe rob_w (~bob@p549BB63C.dip.t-dialin.net) |
| 22:43.07 | khem | yeah having it in commit message will help too |
| 22:43.15 | *** join/#oe bkero-ZNC (~freenode@s69-163-39-14.in-addr.arpa.static.dsn1.net) |
| 22:43.17 | khem | so adding CVE number in commit message and recipes |
| 22:43.27 | khem | and probably keep a doc on wiki |
| 22:43.55 | zecke | khem: doc in wiki? sorted by date? like a changelog? |
| 22:44.30 | *** join/#oe jackpot (~jackpot@216.58.130.98) |
| 22:45.28 | Tartarus | Keep in mind the version X comes out, then CVE Y is announced later |
| 22:45.38 | Tartarus | Any info you have at the time is good, of course |
| 22:45.54 | Tartarus | But if we want some form of real definitive info, a google doc or wiki table or something |
| 22:46.01 | grg | how do you decide which versions of a recipe get a backported fix? |
| 22:46.29 | grg | there are going to be cases where it is relevant for many versions that are in use in the tree |
| 22:46.30 | Tartarus | grg: At the moment, the thought is most recent and distros can fix older if needed |
| 22:46.43 | grg | ok. that makes sense |
| 22:46.51 | Tartarus | Since from experience the backport to 10 versions thing is time consuming :( |
| 22:46.56 | zecke | grg: or is the question upgrade vs. patch? |
| 22:47.16 | grg | zecke, yes. Both are going to happen, i suspect. |
| 22:47.46 | *** join/#oe _diego_ (~diego@host-78-14-230-154.cust-adsl.tiscali.it) |
| 22:48.00 | zecke | grg: yeah, specially right now. E.g. vim 7.0 has a sec issue with ftp in one plugin. In this case updating vim 7.2 just makes more sense |
| 22:48.18 | khem | zecke: I think and upgrade should be preferred to patch prolly |
| 22:48.30 | grg | vim has ftp support? wtf? |
| 22:48.43 | khem | vim has to compete with emacs |
| 22:48.46 | zecke | grg: a plugin |
| 22:48.47 | grg | ha! |
| 22:49.00 | zecke | vim has plugins? ;) |
| 22:49.08 | grg | yeah :) |
| 22:49.53 | grg | for me, vim has been feature complete since v5 |
| 22:50.41 | Tartarus | heh |
| 22:50.50 | ant__ | grg: hi. I foun dout that updating libopkg to 522 broke opie-packagemanager. I have no idea of both packages. Question: did opkg have some major header split lately? |
| 22:51.26 | Tartarus | I think that for public OE, esp the dev branch, the end choice is going to be update to latest and just patch when there is no latest yet or we're really behind and update would be hard |
| 22:51.40 | Tartarus | The stable branches will need their own security work |
| 22:51.42 | grg | ant__, yeah. I cleaned up a bunch of headers in r504 |
| 22:52.01 | ant__ | ah, ok, thx for confirming |
| 22:52.18 | ant__ | btw it's the single package failing atm |
| 22:52.18 | grg | ant__, opkg frontends will not be compatible with both 0.1.7 and 0.1.8 |
| 22:52.31 | *** join/#oe robtow (~rob@dsl092-218-034.sfo2.dsl.speakeasy.net) |
| 22:52.45 | grg | ant__, and if i have the time, the interface will change again. |
| 22:52.58 | khem | ant__: did you solve your klibc issue ? |
| 22:53.02 | ant__ | grg: Iìll have to ask bluelightning to bump opie packagemanager |
| 22:53.09 | ant__ | khem: well, some of |
| 22:53.09 | khem | ant__: sorry I did not have much time for past couple of weeks |
| 22:53.11 | ant__ | it build now |
| 22:53.19 | khem | ant__: ok nice |
| 22:53.28 | zecke | khem: the biggest issues are probably: OpenSSL and gnutls... both have issues |
| 22:53.34 | ant__ | the fact is klibc still eeds linux headers to compile |
| 22:53.35 | khem | zecke: agree |
| 22:53.47 | ant__ | headers_install is used only on the deploy side |
| 22:53.48 | khem | ant__: yes infact it needs a raw linux tree |
| 22:53.51 | khem | not staged one |
| 22:53.53 | ant__ | but |
| 22:53.58 | zecke | khem: i will have to sleep now. |
| 22:54.03 | ant__ | hpa promised he'd work on this |
| 22:54.10 | khem | zecke: gn |
| 22:54.19 | zecke | khem: if you feel like, you could send an announcement mail with the ideas we have? if not I can draft such an email during the day |
| 22:54.48 | khem | zecke: ok if you dont see an email when you wake up then you know you have to do it :) |
| 22:54.48 | ant__ | khem: http://www.zytor.com/pipermail/klibc/2010-February/002483.html |
| 22:55.17 | robtow | sakoman - I'm going to try your Gnome R8 version. |
| 22:57.21 | khem | ant__: yeah in parts problem wrt klibc in OE is that we dont put same source tree for kernel in staging and klibc build uses it |
| 22:57.26 | ant__ | khem: well, was first msg in the thread |
| 22:57.35 | ant__ | khem: exactly |
| 22:58.18 | khem | ant__: one solution we could use is that we could build linux-libc-headers and stage them which can then be symlinked during klibc build and we dont have to do install_headers step in klibc build |
| 22:58.40 | ant__ | somewhere hpa said the libc headers are not enough :/ |
| 22:58.40 | khem | is there anything else it needs from kernel source tree ? |
| 22:58.55 | khem | oh well |
| 22:59.09 | ant__ | ah..no..here |
| 22:59.10 | ant__ | http://gentoo-portage.com/AJAX/Ebuild/95599/View |
| 22:59.13 | khem | I wonder why we muck with staged kernel tree |
| 22:59.34 | khem | probably some packages need the headers in old place |
| 23:00.20 | *** join/#oe Ironnads (~Ironnads@host86-183-195-90.range86-183.btcentralplus.com) |
| 23:00.50 | khem | needs to eat |
| 23:01.28 | ant__ | khem: possibly best is wait for 1.5.16 |
| 23:01.54 | ant__ | and see if then klibc builds against headers_install headers |
| 23:02.28 | ant__ | guten appetit! |
| 23:03.41 | zecke | RP__: ping? |
| 23:04.34 | RP__ | zecke: pong? |
| 23:05.05 | zecke | RP__: sorry, to ask.. For a package with upstream version 2.0.36rc1, I'm going to pick 2.0.35+2.0.36rc1 as PV? |
| 23:05.29 | RP__ | zecke: Sounds good since we don't support ~ (yet) |
| 23:06.06 | ant__ | RP: wrt those strings, remember the vercmp in bitbake |
| 23:06.14 | ant__ | cannot cope |
| 23:06.17 | kergoth | fights with BBCLASSEXTEND+amend.inc.. setting bbclassextend via an anonymous python function makes things very confused :) |
| 23:06.33 | RP__ | kergoth: I saw your patch for that and worried |
| 23:06.42 | RP__ | ant__: We need to fix that |
| 23:06.47 | kergoth | it confuses the whole based vs d logic |
| 23:06.52 | kergoth | is working on it.. |
| 23:07.29 | RP__ | kergoth: I never really intended code to be able to do that |
| 23:07.40 | kergoth | hehe |
| 23:07.46 | kergoth | amend.inc is twisted, i know, but incredibly useful |
| 23:08.09 | kergoth | I'm thinking about giving bitbake a better mechanism to inject files to be parsed like that, instead of having to do it itself, and resulting in multiple finalise()s |
| 23:08.16 | kergoth | maybe just an env var listing extra files to pull in |
| 23:08.17 | kergoth | thoughts? |
| 23:08.56 | RP__ | You have to have multiple finalises though? |
| 23:09.20 | kergoth | well, if you want anonymous python functions in the amend.inc to function, anyway |
| 23:09.31 | kergoth | ponders |
| 23:09.38 | RP__ | kergoth: I don't think I understand what ammend.inc does ;-) |
| 23:09.48 | kergoth | It's like 3 lines of code :) |
| 23:10.10 | kergoth | It searches FILESPATH for an amend.inc file. If it finds it, it parses it into the datastore with bb.parse.handle() |
| 23:10.14 | kergoth | that's all there is to it |
| 23:10.34 | kergoth | makes it easy to maintain recipe alterations out of band, in another overlay, or local to the build dir, or whatever |
| 23:10.44 | kergoth | eases the pain of oe syncs |
| 23:10.57 | *** part/#oe jackpot (~jackpot@216.58.130.98) |
| 23:11.22 | kergoth | mkdir -p build/files/nano; echo 'BBCLASSEXTEND = "native"' >> build/files/nano/amend.inc; bitbake nano-native |
| 23:11.25 | kergoth | heh. |
| 23:12.01 | RP__ | kergoth: I'd actually been thinking of something similar recently - being able to do "require ${EXTRACONFFILES}" in the distro config |
| 23:13.12 | RP__ | The pathological EXTRACONFFILES = "" would be interesting though |
| 23:13.19 | kergoth | heh |
| 23:13.24 | RP__ | and require would need to be able to take a list |
| 23:13.56 | RP__ | kergoth: My main worry is the searching of FILESPATH rather than BBPATH |
| 23:14.04 | RP__ | Do we do that for includes anyway? |
| 23:14.11 | RP__ | in .bb files? |
| 23:14.13 | kergoth | no? |
| 23:14.20 | kergoth | that just prepends ${FILE_DIRNAME} to bbpath temporarily |
| 23:14.40 | kergoth | using filespath, i can have version or revision specific amend.incs easily, also |
| 23:15.04 | RP__ | kergoth: Right, that makes sense and I understand the attraction |
| 23:15.33 | RP__ | kergoth: It doesn't let you split the files into a separate tree though, right? |
| 23:15.40 | kergoth | not sure what you mean by that |
| 23:16.15 | RP__ | kergoth: So have a plain OE checkout in some directory and a set of ammend.inc files in another |
| 23:16.28 | kergoth | that works fine, if you manipualt eFILESPATHBASE |
| 23:16.28 | kergoth | w |
| 23:16.28 | kergoth | hi |
| 23:16.43 | kergoth | rearchitected filespath this way for a reason :) |
| 23:16.53 | kergoth | blah, this computer is possessed at times, i swear |
| 23:16.53 | RP__ | kergoth: but you don't do that atm? |
| 23:17.00 | kergoth | not sure what you mean |
| 23:17.27 | Tartarus | It's just that it doesn't play nice with another set of funny automagic stuff :) |
| 23:17.32 | RP__ | Can you have multiple FILESPATHBASE ? |
| 23:17.45 | Tartarus | RP__: you set FILESPATHBASE to a bunch of things |
| 23:17.49 | kergoth | FILESPATHBASE is a colon separated list |
| 23:17.57 | RP__ | kergoth: right |
| 23:17.59 | kergoth | just as FILESPATHPKG and OVERRIDES are |
| 23:17.59 | kergoth | F |
| 23:17.59 | kergoth | I |
| 23:17.59 | kergoth | LE |
| 23:18.03 | kergoth | FILESPATH is constructed from all of them |
| 23:18.04 | RP__ | makes lots of sense |
| 23:18.19 | RP__ | needs to get this into Poky |
| 23:18.37 | RP__ | suspects it kills parsing time though? |
| 23:18.48 | Tartarus | amend.inc hurts a little |
| 23:18.58 | Tartarus | have to reparse the specific dirs you have one for |
| 23:19.05 | kergoth | dangit, where's that link someone put on the mailing list that set FILESPATHBASE based on BBPATH/COLLECTIONS |
| 23:19.11 | RP__ | did a lot of work to remove FILESPATH from all parsing paths a while aho |
| 23:19.37 | kergoth | well, for every recipe that has one, it does an extra bb.parse.handle() for it |
| 23:19.54 | RP__ | kergoth: Its finding whether it has one thats the hit |
| 23:20.22 | RP__ | file for file in amendfiles if os.path.exists() |
| 23:20.28 | RP__ | is slow :( |
| 23:21.24 | kergoth | it also checks each of those paths when checking the status of the cache |
| 23:21.33 | kergoth | since it adds them all to __depends, to ensure that creating one invalidates the cache for the recipe |
| 23:21.34 | kergoth | :\ |
| 23:21.42 | RP__ | kergoth: ouch |
| 23:21.51 | RP__ | kergoth: I can guess why... |
| 23:21.53 | kergoth | worth the cost, though, for many, due to the improvement on the maintenance. |
| 23:22.06 | kergoth | I'd love to find a better way to manage it, but how.. |
| 23:23.29 | *** join/#oe Martin-B (~martin@pool-152-65-198-89.dbd-ipconnect.net) |
| 23:24.16 | RP__ | kergoth: You include all ammend.inc files? |
| 23:24.27 | kergoth | currently only the first, but i think moving to all is a better bet |
| 23:24.28 | kergoth | o |
| 23:24.28 | kergoth | the |
| 23:24.28 | kergoth | r |
| 23:24.36 | kergoth | otherwise the user "overriding" an amend.inc will lose distro changes, or whatever |
| 23:24.42 | kergoth | which is unlikely what they expect |
| 23:24.45 | kergoth | heh |
| 23:24.47 | RP__ | kergoth: hmm, right |
| 23:24.56 | RP__ | there goes that optimisation ;-) |
| 23:25.07 | kergoth | left it as is for consistency with the rest of OE for now, but changing it is on his oe issues list |
| 23:26.02 | RP__ | kergoth: For speed, being clever with the path building code may help |
| 23:26.22 | CIA-2 | 03Holger Hans Peter Freyther <zecke@selfish.org> 07org.openembedded.dev * r8f81a0fcff 10openembedded.git/ (3 files in 3 dirs): vorbis-tools: Upgrade to 1.2.0 |
| 23:26.23 | CIA-2 | 03Holger Hans Peter Freyther <zecke@selfish.org> 07org.openembedded.dev * r32b8772ca7 10openembedded.git/ (conf/checksums.ini recipes/gd/gd_2.0.33.bb): |
| 23:26.24 | CIA-2 | gd: Upgrade from 2.0.33 to 2.0.36RC1 |
| 23:26.24 | CIA-2 | * Move the checksums into the recipe |
| 23:26.24 | CIA-2 | * Pick 2.0.35+2.0.36rc1 as the name to remain easily upgradable |
| 23:26.24 | CIA-2 | * This should resolve: |
| 23:26.24 | CIA-2 | http://portaudit.FreeBSD.org/6e099997-25d8-11dc-878b-000c29c5647f.html |
| 23:26.25 | CIA-2 | http://portaudit.FreeBSD.org/4e8344a3-ca52-11de-8ee8-00215c6a37bb.html |
| 23:26.25 | CIA-2 | 03Holger Hans Peter Freyther <zecke@selfish.org> 07org.openembedded.dev * ra68d07365b 10openembedded.git/ (4 files in 3 dirs): (log message trimmed) |
| 23:26.26 | CIA-2 | wireshark: Upgrade from 1.0.5 to 1.2.6 |
| 23:26.26 | CIA-2 | Update the ieee80215.patch. The original commit message is so weak |
| 23:26.27 | CIA-2 | it is not saying why the wpan_nofcs variant is to be used. I'm |
| 23:26.27 | CIA-2 | respecting the original patch author here but it would be better |
| 23:26.28 | CIA-2 | to have nice commit messages. My feeling tells me that we should |
| 23:26.28 | CIA-2 | drop this patch as there is no indication why this patch is a good |
| 23:26.32 | RP__ | kergoth: For example if foo/ doesn't exist there is no point in checking for foo/A foo/B and foo/C |
| 23:27.12 | kergoth | hmm, thats a possibility |
| 23:27.33 | RP__ | kergoth: I'm sure I did that with the overrides in FILESPATH thing |
| 23:27.51 | RP__ | kergoth: but back then, FILESPATH wasn't a parsing issue |
| 23:28.09 | RP__ | kergoth: so if X didn't exist we could just drop it entirely |
| 23:28.24 | kergoth | the evaluation of FILESPATH already excludes the dirs that don't exist, so amend.inc will never see them |
| 23:28.32 | kergoth | iirc, anyway. |
| 23:28.49 | kergoth | Local test: bitbake -p w/ amend.bbclass inherited = 2m26s |
| 23:28.54 | kergoth | bitbake -p w/o amend.bbclass inherited = 2m20s |
| 23:28.55 | RP__ | kergoth: I think I did that... |
| 23:28.57 | kergoth | i think I'll live. |
| 23:29.06 | RP__ | kergoth: but that will break your cache ;-) |
| 23:29.13 | kergoth | hm? |
| 23:29.24 | kergoth | oh.. hmm. |
| 23:29.28 | RP__ | Add an amend.inc in an override dir? |
| 23:30.12 | RP__ | Its not as slow as I thought as you're not using the full list of paths I expected ;-) |
| 23:30.17 | kergoth | yeah, that case is probably broken at the moment. |
| 23:30.20 | *** join/#oe grg (~grg@eth7090.sa.adsl.internode.on.net) |
| 23:30.49 | kergoth | 6s for total parse time is hardly worth complaining about given the convenience added, but lets see how bad it gets once the filespath includes them all... :) |
| 23:31.45 | RP__ | kergoth: You're talking a 5% speed loss... |
| 23:32.13 | RP__ | kergoth: we've done a lot for a lot less than that before :/ |
| 23:33.08 | Tartarus | We'd take it faster if we can get it :) |
| 23:33.16 | kergoth | well, clearly some people think its worth it, given the number of people and companies already using it |
| 23:33.18 | Tartarus | How many collections was that too? |
| 23:33.22 | kergoth | but yeah, by all means, improve it if we can |
| 23:34.22 | RP__ | kergoth: I'm not saying its a bad improvement, just highlighting why it causes a slow down so we can mitigate it if possivle |
| 23:34.49 | RP__ | spent a lot of time looking into stuff like this a while ago :/ |
| 23:37.23 | kergoth | Well, if we had a version specific override, an amend.inc per recipe per collection would be likely be sufficient, so it could be done via bbpath/collections/bblayers. |
| 23:41.06 | RP__ | kergoth: I'll give it some thought. I'm wondering if some kind of central mechanism for this kind of thing might not work better... |
| 23:41.23 | Tartarus | Oh yeah, once again, anyone |
| 23:41.42 | Tartarus | Given that LIBC={eglibc,glibc,uclibc} why do we have minimal and minimal-uclibc? |
| 23:41.55 | kergoth | Well, like I said earlier, its definitely something that would do better by moving at least part of it into bitbake. The question is how. |
| 23:42.01 | Tartarus | kicks his uclibc minimal build off before doing libc packaging stuff |
| 23:42.04 | kergoth | hmm |
| 23:42.06 | RP__ | kergoth: How about a global find of any ammend.inc files feeding into some magic somewhere |
| 23:42.18 | RP__ | kergoth: with a custom caching system... |
| 23:42.44 | kergoth | hmm. |
| 23:43.08 | RP__ | That should be faster than 6s |
| 23:44.49 | kergoth | I hate to hardcode the amend.inc thing into bitbake, but putting that find anywhere in the metadata would lead to cache nightmares |
| 23:44.50 | kergoth | meh |
| 23:45.14 | zecke | lol fetchmail 6.3.8 is not fetchable :( |
| 23:45.31 | *** join/#oe methril (~methril@189.27.128.117.dynamic.adsl.gvt.net.br) |
| 23:45.36 | *** join/#oe raster (~raster@enlightenment/developer/raster) |
| 23:45.57 | RP__ | kergoth: I'm thinking of a BBAMEND = "amend.inc" BBAMENDPATH="basepath1:basepath2" |
| 23:46.05 | RP__ | kergoth: or something |
| 23:46.57 | RP__ | kergoth: Just thinking out loud... |
| 23:46.57 | kergoth | that'd work. similar to what i was thinking earlier, just with the traversal moved into bitbake too to avoid the performance problems.. its a good idea, though how it associates the amend.incs to the recipes could be an interesting question |
| 23:47.00 | kergoth | nods |
| 23:47.09 | kergoth | hmm. |
| 23:47.21 | RP__ | kergoth: Its like what I did with BBCLASSEXTEND |
| 23:47.37 | RP__ | Its generic but had to be in bitbake to make sense |
| 23:48.16 | RP__ | kergoth: I will leave you to ponder :) |
| 23:48.23 | RP__ | 'night all! |
| 23:48.43 | kergoth | meh, i can't fix amend.inc+BBCLASSEXTEND without requiring the creation of the extra createCopy() that used to be done only for non-null bbclassextend |
| 23:48.46 | kergoth | hrmph |
| 23:48.48 | kergoth | night |
| 23:52.34 | *** join/#oe JDuke128 (~51d6168a@gateway/web/freenode/x-fbbvckufsrgtjrzo) |
| 23:52.35 | JDuke128 | hi , did someone know any raw data reading from other usb device ? i just need to read some data from keyboard from usb layer that will be controlled by beagleboard ? someone know ? |