| 00:03.19 | *** join/#oe zecke (~ich@123-192-181-204.dynamic.kbronet.com.tw) |
| 00:03.39 | khem | heh thanks kergoth |
| 00:05.28 | kergoth | ugh, the way we do our event handlers is .. ick |
| 00:17.35 | khem | kergoth: where do we use the event handlers atm |
| 00:17.48 | khem | do we use it for error handling |
| 00:19.09 | kergoth_ | khem: event handlers are used in a number of places in the metadata. events are fired when tasks start, complete, etc |
| 00:21.11 | *** join/#oe raster (raster@enlightenment/developer/raster) |
| 00:22.13 | khem | kergoth: ah I see. |
| 00:23.30 | *** join/#oe marcosmamorim (~marcos@187.35.34.1) |
| 00:29.59 | *** join/#oe marcosmamorim1 (~marcos@201-68-179-164.dsl.telesp.net.br) |
| 00:30.46 | *** join/#oe zenlinuxPDX_ (~sgarman@c-76-115-42-183.hsd1.or.comcast.net) |
| 00:38.09 | kergoth | grumbles |
| 00:39.56 | kergoth | this is odd. |
| 00:39.57 | kergoth | h |
| 00:39.57 | kergoth | m |
| 00:40.00 | kergoth | m |
| 00:43.16 | *** join/#oe mithro (~tim@unaffiliated/mithro) |
| 00:43.58 | *** join/#oe marcosmamorim (~marcos@201-68-206-232.dsl.telesp.net.br) |
| 00:44.46 | *** join/#oe rsalveti (~rsalveti@187.113.105.33) |
| 00:52.12 | *** join/#oe marcosmamorim1 (~marcos@201-68-113-94.dsl.telesp.net.br) |
| 01:03.32 | *** join/#oe marcosmamorim (~marcos@201-68-109-219.dsl.telesp.net.br) |
| 01:18.30 | *** join/#oe jd (~jd@modemcable207.134-202-24.mc.videotron.ca) |
| 01:18.31 | *** join/#oe jd (~jd@Wikipedia/HellDragon) |
| 01:29.42 | *** join/#oe marcosmamorim (~marcos@201-42-211-11.dsl.telesp.net.br) |
| 02:01.07 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 02:02.58 | *** join/#oe marcosmamorim1 (~marcos@201-13-197-171.dial-up.telesp.net.br) |
| 02:11.35 | *** join/#oe fraxinath (~quassel@cl-2561.ham-01.de.sixxs.net) |
| 02:13.33 | *** join/#oe LANman247 (~none@41.117.244.66.bay.smithvilledigital.net) |
| 02:15.36 | *** join/#oe marcosmamorim (~marcos@201-68-138-135.dsl.telesp.net.br) |
| 02:15.43 | kergoth | er. |
| 02:16.21 | kergoth | holds off a moment to do more testing |
| 02:16.40 | kergoth | I think I *may* have just cut the initial parse time to 1/5th of what it is today |
| 02:23.46 | *** join/#oe marcosmamorim1 (~marcos@201-68-206-227.dsl.telesp.net.br) |
| 02:41.14 | *** join/#oe covalence (~covalence@ip68-110-78-186.ph.ph.cox.net) |
| 02:45.47 | covalence | Anyone ever have problems building rpm-native? Specifically magic file problems, specifically "file: could not find any magic files! |
| 02:45.47 | covalence | make: *** [magic.mgc] Error 1" under build/tmp/work/x86_64-linux/rpm-native-4.4.2.3-r15/rpm-4.4.2.3/file/magic |
| 02:47.44 | *** join/#oe methril_home (~methril@189.27.130.232.dynamic.adsl.gvt.net.br) |
| 02:48.22 | covalence | The file command without the "-C -m magic" option (eg file magic) shows that "magic" is indeed a magic text file. ;) |
| 02:49.40 | *** join/#oe marcosmamorim (~marcos@201-43-208-202.dsl.telesp.net.br) |
| 02:55.18 | *** join/#oe mrc3_ (~ddiaz@189.157.110.236) |
| 03:12.42 | *** join/#oe zenlinuxPDX (~sgarman@c-76-115-42-183.hsd1.or.comcast.net) |
| 03:15.13 | *** join/#oe methril_home (~methril@189.27.129.144.dynamic.adsl.gvt.net.br) |
| 03:15.36 | *** join/#oe EiNSTeiN__ (~einstein@216.252.89.207) |
| 03:18.09 | kergoth | aha, i see.. |
| 03:23.41 | *** join/#oe borg_ (~olaf@p54869096.dip0.t-ipconnect.de) |
| 03:26.04 | *** join/#oe marcosmamorim1 (~marcos@201-43-34-136.dsl.telesp.net.br) |
| 03:31.17 | covalence | Interesting...if i use the file executable from the src directory (4.04 it works) but verison 5.04 in the staging directory does not work with the provided magic file. |
| 03:31.35 | covalence | Must be some version incompatibility between 5.X and 4.X |
| 03:33.27 | *** join/#oe hd (~jd@modemcable207.134-202-24.mc.videotron.ca) |
| 03:33.28 | *** join/#oe hd (~jd@Wikipedia/HellDragon) |
| 03:46.19 | *** join/#oe marcosmamorim (~marcos@201-27-171-204.dsl.telesp.net.br) |
| 04:03.19 | *** join/#oe zecke (~ich@123-192-181-204.dynamic.kbronet.com.tw) |
| 04:29.16 | *** join/#oe playya (~playya@unaffiliated/playya) |
| 04:31.35 | *** join/#oe hufnus_cicq (~hufnus_ci@69-12-177-67.dsl.static.sonic.net) |
| 05:00.01 | *** join/#oe aditya_1111 (~Aditya@c-69-143-196-44.hsd1.md.comcast.net) |
| 05:11.03 | *** join/#oe zecke (~ich@123-192-181-204.dynamic.kbronet.com.tw) |
| 05:35.03 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
| 05:37.48 | *** join/#oe mrc3_ (~ddiaz@189.157.110.236) |
| 05:51.48 | *** join/#oe thebohemian (~rschus@p5DDC37D2.dip.t-dialin.net) |
| 06:08.31 | CIA-2 | 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * rc1aab90e5e 10openembedded.git/removal.txt: (log message trimmed) |
| 06:08.31 | CIA-2 | removal.txt: proposal to remove ClamAV versions < 0.95 in April |
| 06:08.31 | CIA-2 | http://www.clamav.net/lang/en/2009/10/05/eol-clamav-094/ |
| 06:08.31 | CIA-2 | Without database updates AV is almost completely useless, and |
| 06:08.32 | CIA-2 | starting on April 15 2010 ClamAV < 0.95 will get no db updates, |
| 06:08.32 | CIA-2 | so there is no reason to support that versions. |
| 06:08.33 | CIA-2 | Signed-off-by: Roman I Khimov <khimov@altell.ru> |
| 06:10.39 | *** join/#oe playya (~playya@unaffiliated/playya) |
| 06:49.02 | CIA-2 | 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * r2f196b1407 10openembedded.git/recipes/openssl/ (8 files in 2 dirs): |
| 06:49.02 | CIA-2 | openssl: add version 1.0.0 |
| 06:49.02 | CIA-2 | * DEFAULT_PREFERENCE = "-1", since it might break apps |
| 06:49.02 | CIA-2 | * enable engines build (and package those separately) |
| 06:49.02 | CIA-2 | Signed-off-by: Roman I Khimov <khimov@altell.ru> |
| 06:50.20 | *** join/#oe Heinervdm (~thomas@pD9E17570.dip.t-dialin.net) |
| 07:14.29 | *** join/#oe fpga (~s@92.62.56.51) |
| 07:16.26 | *** join/#oe cyberdeck (~cyberdeck@iss66.vlsi.informatik.tu-darmstadt.de) |
| 07:21.10 | *** join/#oe siji (~siji@122.170.9.183) |
| 07:28.04 | *** join/#oe _ProtoN_ (~lcintrat@93.2.234.35) |
| 07:49.15 | *** join/#oe mckoan (~marco@unaffiliated/mckoan) |
| 07:50.15 | zecke | thebohemian: sigh... kmail crashed twice when replying... |
| 07:53.13 | thebohemian | zecke: oh |
| 07:55.10 | *** join/#oe fpga (~s@92.62.56.51) |
| 07:55.10 | mckoan | good morning |
| 08:05.55 | *** join/#oe Longfield (~valentin@lsa1pc7.epfl.ch) |
| 08:11.50 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:14.25 | *** join/#oe ant_work (~andrea@host214-85-static.34-85-b.business.telecomitalia.it) |
| 08:16.32 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
| 08:20.13 | *** join/#oe marcosmamorim (~marcos@201-27-173-214.dsl.telesp.net.br) |
| 08:20.55 | hrw | morning |
| 08:21.33 | *** join/#oe zub (U2FsdGVkX1@linux.fjfi.cvut.cz) |
| 08:28.53 | *** join/#oe zub (U2FsdGVkX1@linux.fjfi.cvut.cz) |
| 08:40.55 | *** join/#oe Sleep_Walker (~Sleep@nat/novell/x-gkxcqxjutgaxyspr) |
| 08:43.42 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 08:51.00 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 08:53.25 | *** join/#oe eFfeM (~eFfeM_wor@atwork-193.r-212.178.107.atwork.nl) |
| 08:55.43 | CIA-2 | 03Sebastian Spaeth <Sebastian@SSpaeth.de> 07org.openembedded.dev * rf902b356c7 10openembedded.git/conf/distro/include/sane-srcrevs.inc: |
| 08:55.43 | CIA-2 | sane-srcrevs: bump shr-settings |
| 08:55.43 | CIA-2 | Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de> |
| 08:59.00 | *** join/#oe fpga (~s@92.62.56.51) |
| 08:59.27 | ant_work | morning |
| 08:59.34 | hrw | hi ant_work |
| 08:59.41 | hrw | ant_work: how goes kexecboot stuff? |
| 09:00.00 | ant_work | well, we are ok on armv5te |
| 09:00.09 | ant_work | it seems beagle is not yet ready.. |
| 09:00.13 | ant_work | kernel issues |
| 09:00.49 | ant_work | (we still have no power man with 2.6.34 on Zaurus...) |
| 09:00.52 | ant_work | btw |
| 09:00.59 | ant_work | ftp://elsie.nci.nih.gov/pub/tzdata2010f.tar.gz |
| 09:01.07 | ant_work | ^^ was removed* |
| 09:01.15 | ant_work | in favor of 2010g |
| 09:01.18 | hrw | g was released |
| 09:01.19 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r6a665a12bb 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: |
| 09:01.19 | CIA-2 | shr: prefer glib-2.0_2.23.6 |
| 09:01.19 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 09:01.21 | CIA-2 | 03Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de> 07org.openembedded.dev * rb98084cc22 10openembedded.git/recipes/tcpdump/ (files/configure.patch tcpdump_4.0.0.bb): |
| 09:01.21 | CIA-2 | tcpdump: fixed build with newer autoconf-2.65 |
| 09:01.21 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 09:01.21 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rf02d3d040e 10openembedded.git/recipes/xorg-xserver/xserver-xorg_git.bb: |
| 09:01.22 | CIA-2 | xserver-xorg: bump SRCREV |
| 09:01.22 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 09:01.33 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r50b10afbda 10openembedded.git/conf/distro/include/sane-srcrevs.inc: |
| 09:01.33 | CIA-2 | EFL: another SRCREV bump, more efreet fixes and illume2/illume-keyboard fixes reported by Tom 'TAsn' Hacohen |
| 09:01.33 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 09:01.35 | ant_work | hrw: because of that crazy ussian changes ;) |
| 09:01.44 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rcc25e6b8ba 10openembedded.git/ (3 files in 3 dirs): |
| 09:01.45 | CIA-2 | mesa-dri_7.8: add patch with glamo support and prefer it with SHR |
| 09:01.45 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 09:01.45 | hrw | ant_work: did you saw CONFIG_EXT4_USE_FOR_EXT23 option? |
| 09:01.57 | ant_work | hm..not yet |
| 09:02.14 | hrw | maybe it is after .33 stuff |
| 09:02.32 | hrw | but will give you smaller kernel |
| 09:02.36 | ant_work | well, for nand we are still on jffs2, waiting ubifs |
| 09:02.52 | ant_work | do you suggest ext4 for SD/CF ? |
| 09:03.06 | ant_work | or usb disks? |
| 09:03.28 | ant_work | I onlyread about ext4 bugs ... |
| 09:03.45 | hrw | no no no |
| 09:03.56 | ant_work | he |
| 09:04.10 | hrw | this makes ext4.ko to handle ext2 ext3 filesystems as ext2/ext3 |
| 09:04.17 | hrw | less code in kernel |
| 09:04.25 | ant_work | yea, one for all |
| 09:04.32 | hrw | I am using ext4 on all my machines for some time now |
| 09:04.39 | ant_work | issues? |
| 09:04.56 | hrw | none so far |
| 09:05.13 | hrw | CONFIG_EXT4_USE_FOR_EXT23 should be in .33 anyway |
| 09:05.29 | ant_work | now hat you say..perhaps is already used in the 2.6.33 |
| 09:05.52 | hrw | not in linux-kexecboot 2.6.33 |
| 09:06.28 | hrw | bb in few |
| 09:06.59 | ant_work | ok, thyx for the pointer |
| 09:13.17 | *** join/#oe sgh (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 09:15.57 | sgh | Apparently no version of xf86-input-elographics can compile agains xserver-xorg 1.7.3. Do anyone know which combination of xserver-xorg and xf86-input-elographics that works ? |
| 09:19.06 | *** join/#oe GNUtoo|oeee (~GNUtoo@host115-202-dynamic.21-79-r.retail.telecomitalia.it) |
| 09:23.50 | *** join/#oe mimecar (~mimecar@84.126.167.148.dyn.user.ono.com) |
| 09:23.58 | mimecar | hi |
| 09:24.07 | mimecar | are the OE forum down? |
| 09:25.17 | zecke | mimecar: there is no OE forum. |
| 09:26.07 | mimecar | from www.oesf.org |
| 09:26.35 | mimecar | ok |
| 09:26.46 | zecke | mimecar: sorry, you ask the wrong kind of people. :) |
| 09:27.07 | mimecar | thanks for your reply zecke |
| 09:27.15 | mimecar | I'll search better ;) |
| 09:27.18 | ant_work | hrw: about that ext2-3-4 driver: http://www.linuxquestions.org/questions/slackware-14/dev-root-ext4-fs-being-mounted-ext2-fs-797354/ |
| 09:27.54 | zecke | mimecar: the story is, they took the name "Open Embedded" and put Software Foundation at the end, besides taking our name there is no relationship |
| 09:28.22 | mimecar | I thought both webs were related |
| 09:29.15 | ant_work | mimecar: it's just most Zaurus developers form there migrated here |
| 09:29.36 | hrw | ~oesf |
| 09:29.36 | ibot | somebody said oesf was rumour has it, oesf is newer name of ZUG - it provides forum for Zaurus/Ipaq/Simpad/etc users (see zug). It has nothing in common with OpenEmbedded (except for the first two letters), see http://www.oesf.org/ |
| 09:29.55 | hrw | ~factinfo oesf |
| 09:29.55 | ibot | oesf -- created by Laibsch <n=Laibsch@V49b2.v.pppool.de> at Sun Oct 22 20:07:44 2006 (1255 days); it has been requested 5 times, last by hrw, 19s ago. |
| 09:31.21 | mimecar | ok |
| 09:31.51 | hrw | ant_work: kexecboot kernel mounts cards just to read kernels from them - not to store something |
| 09:32.29 | ant_work | yes, it's up to the target kernel to be able to read the fs |
| 09:33.19 | ant_work | but this sounds wrong... |
| 09:33.20 | ant_work | So, for a EXT4FS root partition, kernel try to use EXT3FS, EXT2FS and finally EXT4FS driver. In your case, the EXT4FS driver also support EXT2. After EXT3FS driver gracious protest that this baby is not his problem, EXT4FS driver accept to mount the root partition AS EXT2. |
| 09:33.33 | *** join/#oe cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net) |
| 09:33.57 | ant_work | I'll do some tests |
| 09:36.23 | CIA-2 | 03Sebastian Spaeth <Sebastian@SSpaeth.de> 07org.openembedded.dev * rd59fe293e2 10openembedded.git/conf/distro/include/sane-srcrevs.inc: |
| 09:36.23 | CIA-2 | sane-srcrevs: bump SHR's phone* applications to current |
| 09:36.23 | CIA-2 | Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de> |
| 09:36.33 | CIA-2 | 03Sebastian Spaeth <Sebastian@SSpaeth.de> 07org.openembedded.dev * rfb3a5d2a52 10openembedded.git/: Merge branch 'org.openembedded.dev' of ssh+git://git@git.openembedded.net/openembedded into org.openembedded.dev |
| 09:36.34 | ant_work | hrw: about devtmps...being that kexecboot recreates the device nodes..I think it's superfluous. Any opinion? |
| 09:36.43 | CIA-2 | 03Sebastian Spaeth <Sebastian@SSpaeth.de> 07org.openembedded.dev * re282c6c3ce 10openembedded.git/conf/distro/include/sane-srcrevs.inc: |
| 09:36.43 | CIA-2 | sane-srcrevs: bump e-wm-config-illume-shr to current |
| 09:36.43 | CIA-2 | The old version had a press delay of 0, which automatically made apps start when scrolling the illume background, it seems. |
| 09:36.43 | CIA-2 | Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de> |
| 09:37.11 | ant_work | hrw: *devtmpfs of course |
| 09:38.43 | *** join/#oe dth_ntb (~dieter@p4FDEF969.dip.t-dialin.net) |
| 09:43.47 | ant_work | oh... I read in kexec mailing-list they are working on uImage |
| 09:43.50 | hrw | ant_work: did not used devtmpfs yet |
| 09:43.54 | ant_work | "It seems that ARM's and SH's uImage are always uncompressed so it might |
| 09:43.56 | ant_work | be good to check for this." |
| 09:44.05 | ant_work | always ? |
| 09:46.20 | ant_work | in kernel.bbclass we have : if test -e arch/${ARCH}/boot/compressed/vmlinux ; then |
| 09:46.36 | ant_work | uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C none ... |
| 09:46.46 | ant_work | else |
| 09:46.49 | ant_work | <PROTECTED> |
| 09:47.23 | *** join/#oe mithro (~tim@unaffiliated/mithro) |
| 09:47.59 | ant_work | who would not use the compressed/vmlinux ? |
| 10:04.25 | GNUtoo|oeee | hi,I still have that for m4 under angstrom: |
| 10:04.27 | GNUtoo|oeee | | configure.ac:25: require Automake 1.11.1, but have 1.10.3 |
| 10:04.37 | GNUtoo|oeee | i've preferred 1.11.1 tough |
| 10:04.49 | GNUtoo|oeee | and cleaned old automake and bitbaken 1.1.11 |
| 10:05.04 | GNUtoo|oeee | but still automake likes to 1.10.3 |
| 10:05.58 | *** join/#oe dth_ntb (~dieter@a89-182-199-148.net-htp.de) |
| 10:08.57 | GNUtoo|oeee | *linkes |
| 10:12.32 | *** join/#oe mario-goulart (~user@67.205.85.241) |
| 10:14.10 | hrw | angstrom uses 1.10.3 |
| 10:14.47 | GNUtoo|oeee | I saw that but m4 wants 1.1.11 |
| 10:15.39 | GNUtoo|oeee | recipes/m4/m4_1.4.14.bb |
| 10:19.10 | GNUtoo|oeee | basically prefering 1.1.11 on nativ and non-native |
| 10:19.23 | GNUtoo|oeee | anc cleaning 1.1.10 |
| 10:19.37 | GNUtoo|oeee | and rebuiliding automake |
| 10:19.44 | GNUtoo|oeee | and native |
| 10:19.53 | GNUtoo|oeee | and cleaning and rebuilding m4 |
| 10:19.56 | GNUtoo|oeee | didn't change a thing |
| 10:22.59 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 10:26.48 | RP | morning all |
| 10:30.10 | hrw | hi RP |
| 10:31.03 | hrw | mimecar: it is bad that oesf.org died but I think that it was expected as amount of zaurus users changes each month |
| 10:32.02 | mimecar | that's true |
| 10:32.56 | mimecar | the're new devices currently, with better features |
| 10:33.02 | *** join/#oe Hasse_ (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
| 10:34.21 | hrw | and today phones often works better then zaurus devices for some tasks |
| 10:35.10 | mimecar | you can find wifi , BT or GPS on mobile phones |
| 10:35.18 | hrw | I moved from c760 to se k750i phone with my PIM tasks, then added n810 to it for web/chat/walknavigation |
| 10:35.20 | mimecar | on zaurus you got wifi with a cf card |
| 10:35.46 | hrw | then moved to nokia e66 phone and stopped using k750i and n810. now I have nokia n900 |
| 10:35.56 | hrw | mimecar: I had 3 wifi cf cards |
| 10:36.07 | hrw | two 802.11b and one 802.11g |
| 10:36.16 | mimecar | n900 it's a nice device |
| 10:36.32 | hrw | thats reminds me one thing - I found SL-6000L docking station in basement |
| 10:36.47 | hrw | yes, it is. software suxx in many places but hw is nice |
| 10:37.17 | *** join/#oe Openfree` (~Openfreer@116.228.88.98) |
| 10:37.56 | mimecar | I've my "old" zaurus, C1000, and it works ok for my needs |
| 10:38.13 | mimecar | I've test develop some apps, but it's not posible |
| 10:39.55 | hrw | c1000 is not so old ;D |
| 10:40.31 | hrw | and is one of those which I did not had at home ;) |
| 10:40.46 | mimecar | xD |
| 10:40.56 | GNUtoo|oeee | strange... |
| 10:40.58 | mimecar | it's my ebook reader |
| 10:41.09 | GNUtoo|oeee | bitbake m4 pulls automak 1.10.3 |
| 10:42.03 | GNUtoo|oeee | but preferred version is set to 1.11.1 |
| 10:43.18 | mimecar | GNUtoo|oeee, prefered version on bitkabe recipie, don't you? |
| 10:44.17 | CIA-2 | 03Sebastian Spaeth <Sebastian@SSpaeth.de> 07org.openembedded.dev * rd36c91f616 10openembedded.git/conf/distro/include/sane-srcrevs.inc: |
| 10:44.17 | CIA-2 | sane-srcrevs: bump libphone-ui-shr again |
| 10:44.17 | CIA-2 | THe previous one turned out to contain a flawed commit that is reverted now. |
| 10:44.17 | CIA-2 | Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de> |
| 10:45.21 | GNUtoo|oeee | in local.conf |
| 10:46.42 | mimecar | GNUtoo|oeee, I think you should update recipie |
| 10:47.16 | GNUtoo|oeee | which one? |
| 10:48.09 | mimecar | m4 recipie |
| 10:48.30 | mimecar | if you want it use automake 1.11.1 |
| 10:48.52 | GNUtoo|oeee | ok |
| 10:48.54 | GNUtoo|oeee | thanks a lot |
| 10:49.06 | mimecar | backup original recipie first |
| 10:50.16 | *** join/#oe tsjsieb (~tsjsieb@194.109.164.83) |
| 10:52.15 | GNUtoo|oeee | there is noting interesting inside it,also: |
| 10:52.42 | GNUtoo|oeee | (version) are not enforced as far as I know |
| 10:53.40 | *** join/#oe raster (~raster@enlightenment/developer/raster) |
| 10:54.11 | GNUtoo|oeee | maybe I'll downgrade m4 |
| 11:03.33 | GNUtoo|oeee | ok downgrading m4 seem to work |
| 11:05.39 | mimecar | cool |
| 11:06.57 | MWelchUK_work_ | GNUtoo|oeee, I down graded m4 and autoconf I think. Did a clean build last night - didn't get any problems from that change... |
| 11:08.34 | ant_work | GNUtoo|oeee: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=bc13fe86a5b8f2c1aaa40bde39d7a2de1ccd48f3 |
| 11:08.52 | ant_work | this should have solved the issue, isn't? |
| 11:15.17 | *** join/#oe fpga (~s@92.62.56.51) |
| 11:29.22 | *** join/#oe fpga1 (~s@92.62.56.51) |
| 11:36.05 | *** join/#oe nazgee (~android@91.198.246.64) |
| 11:38.11 | nazgee | hello guys (and girls?). I am trying to bitbake latest Angstrom x11-image, and it fails on tzcode-native_2010f.bb |
| 11:38.41 | nazgee | as it can not fetch fetch http://mirrors.openembedded.org//tzdata2010f.tar.gz |
| 11:38.59 | nazgee | is there anything wrong with this sources? |
| 11:39.30 | nazgee | It should not be the firewall problem, as I am using open network, with no restrictions |
| 11:39.57 | nazgee | but it is strange, that ftp and http server does not respond |
| 11:40.22 | mimecar | can you download that file with PC? |
| 11:40.28 | nazgee | nope |
| 11:40.32 | nazgee | and can you? |
| 11:40.37 | nazgee | 404 ERR |
| 11:41.35 | nazgee | http://www.angstrom-distribution.org/unstable/sources/tzdata2010f.tar.gz seems to fail either |
| 11:41.38 | mimecar | I don't |
| 11:41.46 | mimecar | it looks that file is missing |
| 11:41.53 | nazgee | well. That seems to be the problem than ;] |
| 11:42.10 | nazgee | mimecar: how is it resolved usually? |
| 11:42.49 | mimecar | it's a server error |
| 11:42.56 | nazgee | should i get this package from somewhere else, or just wait patiently? |
| 11:43.01 | mimecar | you can wait or download that file froma mirror |
| 11:43.35 | nazgee | shouldn't be all mirrors listed in reciepe, so bb would ahndle this automatically |
| 11:43.35 | nazgee | ? |
| 11:44.28 | nazgee | just for the record - this problem persists for about 30hrs now |
| 11:44.44 | nazgee | (if i am not screwed by my very disturbed memory) |
| 11:50.56 | mimecar | nazgee, is there a bug report? |
| 11:51.12 | nazgee | mimecar: nope |
| 11:51.28 | nazgee | at least not yet |
| 11:52.02 | mimecar | then, the problem will persist more |
| 11:52.14 | nazgee | heh ;] |
| 11:52.34 | nazgee | i culd have figure this out myself |
| 11:52.52 | nazgee | but i thought that such issues are resolved on-flight |
| 11:52.54 | nazgee | ;] |
| 11:53.28 | mimecar | god mode on :P |
| 11:57.05 | ant_work | ok..see here |
| 11:57.06 | ant_work | http://blog.gmane.org/gmane.comp.time.tz |
| 11:57.24 | ant_work | fwiw Gentoo mirrors removed the source it seems |
| 11:57.57 | ant_work | ...Those wanting to avoid version thrash |
| 11:57.58 | ant_work | may want to wait for data2010h... |
| 11:59.44 | nazgee | well. probably not me, as i have to force my build going |
| 11:59.57 | nazgee | thank you |
| 12:00.04 | ant_work | just grab a copy around then, and recreate the md5 |
| 12:00.53 | ant_work | but 3-4 releases in a month is a bit silly.... |
| 12:01.29 | nazgee | yup. speed makes me dizzy :) |
| 12:01.51 | nazgee | dhould i issue a bug report? |
| 12:01.55 | nazgee | *should |
| 12:02.47 | ant_work | well, good idea, I don't see any specific maintainer for that recipe |
| 12:03.28 | ant_work | I'd just post on the ML, no need to open a bug |
| 12:05.18 | *** join/#oe marex (~marex@eduroam99.ms.mff.cuni.cz) |
| 12:05.22 | nazgee | damn it. I could have waited a while ;] I've just opened a bug report ;] |
| 12:05.35 | ant_work | np |
| 12:06.05 | *** join/#oe slapin (~slapin@fan.ossfans.org) |
| 12:06.14 | slapin | hi, all! |
| 12:06.24 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 12:06.35 | ant_work | the fact is bugs appears on openembedded-commits ML, not so much visibility there |
| 12:06.52 | *** join/#oe Openfree` (~Openfreer@116.228.88.98) |
| 12:07.32 | ant_work | would'n it be better have them landing in openembedded-devel? |
| 12:09.04 | slapin | As ther is more attention on toolchain pieces now, is it possible to look into possibility to make profiling glibc recipe? It will make more accurete results from things like gprof. Any thoughts? |
| 12:09.09 | slapin | RP: |
| 12:09.25 | broonie | ant_work: The counterargument ist hat too much automated stuff just results in people unsubscribing, or otherwise not reading, the ML. |
| 12:10.29 | ant_work | well, having all the git patches posted here did sometimes hog the ML |
| 12:10.45 | ant_work | I don't think a dozen of bugs per monmth could make it worst |
| 12:11.37 | *** part/#oe mimecar (~mimecar@84.126.167.148.dyn.user.ono.com) |
| 12:11.50 | ant_work | broonie: sometimes oe-dev was similar to linux-arm-kernel |
| 12:11.55 | ant_work | :D |
| 12:12.32 | MWelchUK_work_ | hrw, I had to make a minor tweak to busybox-alt, but the proper-tools part built fine overnight. |
| 12:12.44 | nazgee | ant_work: don't ask me, as it is not up to me ;] On the other hand, I am not a bb/oe developer, but staying on-time with all the mails there is a bit... overwhelming ;] |
| 12:12.51 | hrw | cool |
| 12:13.19 | MWelchUK_work_ | hrw, still need to run test it though |
| 12:13.53 | *** join/#oe pb__ (~pb@host86-159-44-123.range86-159.btcentralplus.com) |
| 12:14.40 | broonie | There's also the discussion on them and stuff as well; half the problem is that bugmail from BTSs is rarely good for human reading or intended for replies. |
| 12:15.18 | ant_work | nazgee: done |
| 12:15.44 | ant_work | broonie: right |
| 12:16.45 | pb__ | hi all |
| 12:16.58 | MWelchUK_work_ | pb_, lo |
| 12:17.26 | ant_work | pb__: wb |
| 12:17.52 | nazgee | ant_work: thanks |
| 12:19.53 | GNUtoo|oeee | ant_work, nice thanks a lot |
| 12:20.06 | GNUtoo|oeee | MWelchUK_work_, I downgraded only m4 and it worked |
| 12:20.20 | MWelchUK_work_ | hrw, think we need to include nfs-utils as well. They seem to be needed for nfs mounting. |
| 12:21.22 | hrw | ok |
| 12:21.24 | MWelchUK_work_ | GNUtoo|oeee, ok. Is your build up-to-date enough to have the modification ant_work mentioned in it (i.e. does that not fix it)? |
| 12:25.14 | GNUtoo|oeee | MWelchUK_work_, it's not |
| 12:25.16 | *** join/#oe GNUtoo (~GNUtoo@host115-202-dynamic.21-79-r.retail.telecomitalia.it) |
| 12:25.58 | GNUtoo|oeee | I'm at dca5bfe78fe4336ef28326a57e3826f97c139942 |
| 12:26.04 | MWelchUK_work_ | Ok, I'l probably remove my tweak tonight and try building the updated tree. |
| 12:26.53 | RP | hi pb__ |
| 12:27.15 | RP | slapin: I don't see why we can't have some option to enable it. I'm not familiar enough with the specifics to comment though |
| 12:27.21 | RP | pb__: Did you see my gcc-runtime recipe? |
| 12:28.15 | ant_work | GNUtoo|oeee: I rebuilt last night with the actual GNU toolchain |
| 12:28.23 | GNUtoo|oeee | ok |
| 12:28.38 | ant_work | only issues where with fetching sources :) |
| 12:28.44 | hrw | MWelchUK_work_: btw - does your system has networking working properly? |
| 12:28.48 | GNUtoo|oeee | nice |
| 12:28.53 | hrw | MWelchUK_work_: /var/run/dhclient.eth1.pid: interface name too long (max 26) |
| 12:29.00 | hrw | MWelchUK_work_: thats what I got |
| 12:31.20 | MWelchUK_work_ | I get "can't create /var/lib/dhcp/dhclient.eth0.leases: No such file or directory" |
| 12:31.29 | hrw | mkdir /var/lib/dhcp/ |
| 12:32.04 | MWelchUK_work_ | hrw, and hwclock has differing parameters so the script isn't working right. |
| 12:32.42 | MWelchUK_work_ | hrw, guess that should be added to the dhcp recipe. |
| 12:33.03 | hrw | yep |
| 12:33.13 | hrw | MWelchUK_work_: I will try ifupdown 0.6.10 |
| 12:33.52 | MWelchUK_work_ | is just building a different image, so fiddling will have to wait a few minutes. |
| 12:35.58 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 12:36.47 | *** join/#oe alecrim (~alecrim@189.2.128.130) |
| 12:39.19 | *** join/#oe zecke (~ich@123-192-181-204.dynamic.kbronet.com.tw) |
| 12:42.05 | GNUtoo | hi, about security in oe: http://pastebin.com/PsDGsyfk |
| 12:42.56 | GNUtoo | I'll check if there is version n in oe after my last pull |
| 12:43.41 | GNUtoo | http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?id=2f196b1407bd290a4a96d81e99534ccf04b33f1a |
| 12:43.43 | GNUtoo | ok nice |
| 12:43.57 | MWelchUK_work_ | hrw, /var/lib/dhcp3/ exists, I assume that this is a naming thing. |
| 12:44.05 | GNUtoo | but default preference = -1 |
| 12:47.12 | MWelchUK_work_ | hrw, lol - look in recipes/dhcp/dhcp3.inc |
| 12:47.51 | MWelchUK_work_ | In compile: -D_PATH_DHCLIENT_DB=\"/var/lib/dhcp/dhclient.leases\" |
| 12:48.02 | MWelchUK_work_ | In install: install -d ${D}/var/lib/dhcp3 |
| 12:48.24 | hrw | auch |
| 12:48.58 | *** join/#oe methril_work (~Rafael@201.35.65.90) |
| 12:50.27 | hrw | the problem suxx even more because my test device has broken ethernet |
| 12:52.00 | nazgee | hrw: it makes thing easier to test, if you cant do it anyway, doesn't it? |
| 12:52.07 | nazgee | ;] |
| 12:52.25 | hrw | nazgee: I have wifi on board |
| 12:52.41 | *** join/#oe methril_home (~methril@189.27.132.92.dynamic.adsl.gvt.net.br) |
| 12:53.13 | *** join/#oe alecrim (~alecrim@189.2.128.130) |
| 12:53.36 | nazgee | hrw: cool. i'm juts curious- what board are u using? |
| 12:53.49 | hrw | bug 2.0 |
| 12:54.34 | slapin | is it possible ot override busybox config just in overlay, without changing busybox package? |
| 12:54.52 | nazgee | hrw: nice one |
| 12:55.07 | MWelchUK_work_ | slapin, AFAIK, no. |
| 12:55.30 | *** join/#oe jkridner (~a0321898@pdpc/supporter/active/jkridner) |
| 12:55.48 | MWelchUK_work_ | slapin, At a minimum you would need to copy the busybox recipe into the overlay. |
| 12:57.00 | MWelchUK_work_ | and the ancillary files the recipe relies on. |
| 12:59.45 | *** join/#oe Laibsch (~Jen00@p5B3B28C5.dip.t-dialin.net) |
| 13:00.04 | *** part/#oe Laibsch (~Jen00@p5B3B28C5.dip.t-dialin.net) |
| 13:01.13 | ant_work | hrw: what should I understand from such a license? http://people.dsv.su.se/~fk/beatrix_download.html |
| 13:01.28 | ant_work | may I try to commit a recipe? |
| 13:01.45 | ant_work | seems forbidden at first sight :/ |
| 13:02.13 | *** join/#oe mickeyl (~mickey@openmoko/coreteam/mickey) |
| 13:02.28 | RP | Half the cross-sdk recipes inherit sdk twice? :/ |
| 13:02.40 | RP | the gcc directory is so depressing :( |
| 13:04.06 | MWelchUK_work_ | ant_work, I would suggest that writing a recipe, as long as no patches are required, would be ok - for personal use, as anyone building that recipe will be downloading it themselves. You shouldn't ship a binary version though. |
| 13:04.17 | MWelchUK_work_ | ant_work, and I'm not a lawyer... |
| 13:04.31 | ant_work | patches will be required for sure... |
| 13:04.56 | MWelchUK_work_ | Then, I'd probably contact them and see what they say. |
| 13:05.01 | ant_work | well, I can try to contact the author |
| 13:05.05 | ant_work | yep |
| 13:05.30 | hrw | ant_work: I would not publish recipe even ;d |
| 13:05.49 | ant_work | hrw: I see... |
| 13:09.07 | *** join/#oe zecke (~ich@123-192-181-204.dynamic.kbronet.com.tw) |
| 13:14.15 | MWelchUK_work_ | ok.... |
| 13:14.17 | MWelchUK_work_ | http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?id=f1bcec322799f46d752fb8f524284efe4fcf7de4 |
| 13:16.28 | MWelchUK_work_ | sakoman_, This ^^^ seems to result in an error when doing dhcp. |
| 13:17.50 | ant_work | hrw: any example offhand of a such non-redistributable recipe we have in OE? |
| 13:17.55 | ant_work | if |
| 13:18.33 | hrw | no |
| 13:18.37 | ant_work | I'd like to show to the author it's just metadata (with LICENSE field) |
| 13:31.14 | eFfeM | RP, agree with your gcc remarks, the reason i (hesitatedly) suggested a cleanup is e.g. the existence of the gcc-4.3.*/debian dirs that are not used at all |
| 13:31.41 | RP | eFfeM: those would be valid cleanups |
| 13:31.53 | RP | eFfeM: I think its the removing versions that makes some people nervous |
| 13:32.03 | eFfeM | is not going to burn his fingers again in removing anything |
| 13:32.07 | RP | Having said that I just removed everything before 4.2 from Poky... |
| 13:32.42 | eFfeM | RP, understood that, but that is where stable branches and rev control systems are for |
| 13:33.03 | MWelchUK_work_ | RP eFfeM, I guess if people want old versions arround, there should at least be a comment in the recipe explaining explicitly why that version is required... |
| 13:33.17 | RP | eFfeM: That issues isn't going to get a resolution and I'd hate it for the toolchain cleanups to depend on it |
| 13:33.21 | eFfeM | feels that gcc 3, being from 2004, does not really belong in a dev head in 2010, but eFfeM seems to be alone there |
| 13:33.32 | eFfeM | MWelchUK_work_: agree |
| 13:33.44 | RP | eFfeM: Not alone, I just understand why people need the old versions |
| 13:34.02 | RP | eFfeM: I did leave a 2005 CSL toolchain in poky as if I remove it, I break two machines :( |
| 13:34.23 | hrw | RP: nokia tablets which no one use? |
| 13:34.32 | RP | hrw: right |
| 13:34.41 | RP | hrw: I haven't decided what to do with them yet ;-) |
| 13:34.52 | eFfeM | RP, if it is clear that people still need it, fine, but to me it seems some things are just left because no-one bothers to even check if they are used |
| 13:35.04 | hrw | RP: you maintain poky and you do not have 770 nor n800 so drop them from Poky |
| 13:35.20 | RP | hrw: I do have an 800 actually ;-) |
| 13:35.25 | *** join/#oe CSMan (~csman@unaffiliated/csman) |
| 13:35.35 | RP | hrw: its even on the desk but not used in a while :/ |
| 13:35.36 | eFfeM | if they are not actively maintained, i have doubts on keeping things around |
| 13:35.37 | hrw | RP: you bought/got one? |
| 13:35.51 | RP | hrw: a long time ago, yes |
| 13:35.59 | RP | hrw: My dad has a 770 too... |
| 13:36.00 | hrw | RP: as I remember that your n800dev had to go back |
| 13:36.27 | RP | hrw: this is a release device I bought with developer discount so its mine ;-) |
| 13:36.42 | hrw | ok |
| 13:37.19 | hrw | I was considering trying 2.6.34-rc2 on n810 but have other things to do |
| 13:37.59 | RP | hrw: The code for those machines in poky is rather old :( |
| 13:38.18 | RP | will have to clean out the machines at some point |
| 13:38.34 | hrw | RP: OE is not more fresh I think |
| 13:38.57 | hrw | MWelchUK_work_: pump works better then dhcp-client for me here |
| 13:42.48 | *** join/#oe BenLauDC (~benlau@221.125.8.44) |
| 13:43.04 | ant_work | hrw: about stable/2009, please ack my patch about initramfs image. The second patch for zaurus updater would be also fine, though packaged-staging is broken in stable too... |
| 13:43.21 | ant_work | both from .dev |
| 13:43.34 | hrw | ok, will take a look |
| 13:43.45 | ant_work | I plan some invasive changes for .dev |
| 13:45.31 | ant_work | it's better to let stable 'as it was' and make the jffs2 images compatible with Narcissus (e.g. no sharp headers) |
| 13:45.50 | ant_work | ubifs oneday, perhaps... |
| 13:47.45 | hrw | MWelchUK_work_: please pull and rebase |
| 13:47.52 | CIA-2 | 03Marcin Juszkiewicz <marcin@buglabs.net> 07org.openembedded.dev * rb762948c49 10openembedded.git/recipes/tasks/task-proper-tools.bb: |
| 13:47.52 | CIA-2 | task-proper-tools: added more applications |
| 13:47.52 | CIA-2 | Part of work was done by Martyn Welch, part by me. |
| 13:47.52 | CIA-2 | Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |
| 13:47.57 | CIA-2 | 03Marcin Juszkiewicz <marcin@buglabs.net> 07org.openembedded.dev * r920132b42d 10openembedded.git/recipes/ifupdown/ (7 files in 2 dirs): |
| 13:47.57 | CIA-2 | ifupdown: update to 0.6.10 and do not ship /etc/network/interfaces |
| 13:47.57 | CIA-2 | Init script was renamed to ifup like it is in ifupdown-ubuntu |
| 13:47.57 | CIA-2 | Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |
| 13:48.17 | MWelchUK_work_ | hrw, fine with pump - as long as it works... |
| 13:48.37 | hrw | MWelchUK_work_: it is very quiet by default also |
| 13:48.42 | *** join/#oe fpga (~s@92.62.56.51) |
| 13:49.36 | GNUtoo | hi eFfeM, you're against old recipes, that's great,but what about compat distro? like sharprom-compat or maemos-compat? |
| 13:49.49 | GNUtoo | how are they handled? |
| 13:50.40 | GNUtoo | and how should they be handled? different branches? |
| 13:52.03 | broonie | I guess there's an old vs. unreferenced issue here. |
| 13:54.05 | MWelchUK_work_ | hrw you've removed openrdate? |
| 13:55.04 | MWelchUK_work_ | I assume that ifupdown-ubuntu actually isn't needed? |
| 13:55.04 | ant_work | broonie: you are our audio master...is linux ready to have very low latencies? It's a bit I don't compare Asio vs. Jack |
| 13:56.46 | hrw | MWelchUK_work_: I used ifupdown 0.6.10 on bug20 and it works |
| 13:56.54 | hrw | MWelchUK_work_: sorry for openrdate - will add it |
| 13:57.15 | hrw | MWelchUK_work_: I had 3 copies of that file |
| 13:57.38 | hrw | MWelchUK_work_: openrdate is in task-proper-tools which I pushed |
| 13:58.01 | broonie | ant_work: With suitable hardware combinations and configurations reasonably low latency should be achievable. |
| 13:58.54 | broonie | ant_work: Not sure what asio is but jack is essentially a pro audio soft mixing/routing/algorithms stack (a bit like pulse but for higher end setups. |
| 13:59.01 | ant_work | Well, I dream about a midi controller like this: http://www.bgmi.it/?a=showproduct&b=1 |
| 13:59.06 | MWelchUK_work_ | There are a few others that I had in that you didn't include - I'll hold them in my patch for now - we wanted to replace all the functionality provided by the standard busybox build, just in case... |
| 13:59.16 | ant_work | broonie: this is the sound-core |
| 13:59.36 | *** join/#oe rob_w (~bob@217.237.177.190) |
| 13:59.53 | ant_work | http://www.bgmi.it/?a=showproduct&b=2 |
| 14:00.08 | rob_w | is it safe to delete tmp/deploy/glibc/pstage ? or what is its content for ? |
| 14:00.46 | broonie | ant_work: "sound-core"? |
| 14:00.49 | ant_work | broonie: instead of XP embedded, I'm hoping a quick arm + linux virtual instrument. But I fear about midi/audio |
| 14:00.50 | broonie | -> meeting, back in an hour |
| 14:01.07 | broonie | ant_work: People are doing pro audio systems based on Linux, and phones... |
| 14:01.24 | ant_work | so it's linux,. not QNx or such |
| 14:01.34 | ant_work | realtime OS |
| 14:01.40 | *** part/#oe thebohemian (~rschus@p5DDC37D2.dip.t-dialin.net) |
| 14:02.31 | ant_work | rob_w: you see..this is the only dir to keep if you want to rebuild from packaged-staging :) |
| 14:02.33 | XorA | some of the most expensive mixing desks run linux :D |
| 14:03.08 | ant_work | XorA: I had a short talk on #beagle and some said latency *is* an issue |
| 14:03.19 | rob_w | so if i want to form a image out of the packaged stuff .. |
| 14:03.32 | *** join/#oe rsalveti (~rsalveti@200.184.118.130) |
| 14:04.36 | rob_w | ant_work, so normally if i kick to build a image i dont need it , right ? |
| 14:04.42 | ant_work | XorA: the hw they sell is not so special (for XP): ATOM cpu + Behringer audio card |
| 14:05.04 | XorA | latency is always an issue, you need to be more specific |
| 14:05.29 | ant_work | XorA: you see, the original Hammond has NO latency at all (tonewheels are spinning) |
| 14:05.44 | ant_work | aso the phase of the sinusoids is the same |
| 14:06.09 | ant_work | if you introduce dekays (or use samples) you have phase-shift effects |
| 14:06.14 | ant_work | *delays |
| 14:06.15 | XorA | ant_work: ah, yes, using digital instruments you need to remeber about the startup times |
| 14:06.50 | XorA | ant_work: Cubase actually has the ability to delay channels to fix the latency, this obviously doesnt help if you play live |
| 14:07.12 | ant_work | btw I'm absolutely beginner with that keyboards :D |
| 14:07.32 | ant_work | I'm more a midi-player ;) |
| 14:08.07 | XorA | same here :-D |
| 14:08.26 | XorA | has a novation bass station, that is it |
| 14:10.44 | ant_work | I'll put back my rack of expanders the day my son will be able to understand they are not percussions :/ |
| 14:11.31 | mckoan | ha s Novation Xio-49 :-D |
| 14:11.37 | eFfeM | GNUtoo was afk, i feel that actively maintained distro's in dev should aim to use the latest versions of a recipe (unless there is a good reason not to, I can imagine for u-boot, kernel, gcc and a few other recipes there might be reasons. Old/legacy/unmaintained distro's probably should be in a stable or maintenance branch |
| 14:11.48 | eFfeM | but that is my opinion, not of others |
| 14:12.28 | GNUtoo | ok |
| 14:13.36 | rob_w | so , what happens if i remove tmp/deploy/glibc/pstage/* ? |
| 14:13.52 | ant_work | mckoan: nice one, bad has not 61 keys |
| 14:14.45 | ant_work | rob_w: if you want to do a clean rebuild, wipe all in tmp |
| 14:14.45 | eFfeM | i can imagine that some additional care is needed for recipes on which the build process heavily depends, but I really don't see the point of having multiple versions of abiword, or opie recipes for 1.2.2, 1.2.3 and 1.2.4 |
| 14:15.11 | ant_work | rob_w: if you let the pstage dir the rebuild will be faster |
| 14:15.15 | eFfeM | again, my opinion, others thing differently |
| 14:15.25 | GNUtoo | eFfeM, ok |
| 14:15.34 | rob_w | i just want to get some space free and pstage holds all all those ipk`s again |
| 14:15.49 | mckoan | ant_work: when I need more keys I use my Yamaha P80 |
| 14:15.52 | GNUtoo | eFfeM, were should we document why old version are needed? |
| 14:15.58 | rob_w | k nevermind .. i dump it |
| 14:16.03 | ant_work | mckoan: bummer! |
| 14:16.08 | ant_work | :) |
| 14:16.14 | mckoan | ant_work: ;-) |
| 14:16.25 | GNUtoo | eFfeM, for instance there are 2 wesnoth version,the 1.4x could be needed for 320x240 screen size |
| 14:16.32 | ant_work | you see, I'm tempted to learn playing organ |
| 14:17.30 | GNUtoo | I bet there is no place to document that |
| 14:18.04 | eFfeM | GNUtoo, don't know wesnoth; could imagine the 1.6.5 version could be made to support different res |
| 14:18.29 | GNUtoo | eFfeM, it can,but it would need some work,for instance modifying the themes files |
| 14:18.41 | CIA-2 | 03Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> 07org.openembedded.dev * rf0c802f046 10openembedded.git/recipes/ifupdown/ifupdown_0.6.10.bb: |
| 14:18.41 | CIA-2 | ifupdown: install init script as executable |
| 14:18.41 | CIA-2 | Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |
| 14:18.56 | eFfeM | actually every once in a while I bump into an issue that I need a different kernel defconfig or some additional variants (eg for profiling) |
| 14:18.57 | *** join/#oe guillaum1 (~gl@AMontsouris-153-1-95-251.w90-2.abo.wanadoo.fr) |
| 14:19.03 | GNUtoo | if this is done,it would need to be submited upstream |
| 14:19.34 | eFfeM | GNUtoo if the 1.6 version does not do 320x240 and the 1.4 version does, that is a good reason to keep it around |
| 14:19.46 | GNUtoo | ok |
| 14:19.46 | eFfeM | i have no problems in keeping versions around if there is a good reason for it |
| 14:19.53 | ant_work | mckoan: you too have realtime knowledge, do you think it is feasible to synch midi and audio with cheap hardware? |
| 14:19.57 | eFfeM | but frankly speaking sometimes i think it is just lazyness |
| 14:20.03 | eFfeM | for some recipes |
| 14:20.16 | GNUtoo | ok |
| 14:21.00 | eFfeM | btw I can also understand that there are two (or more) variants of a recipe, eg like we have with opkg where there is a nocurl variant |
| 14:21.22 | ant_work | ~lart opkg/ipkg |
| 14:21.22 | ibot | takes out a cattle prod and gives opkg/ipkg a good jolt |
| 14:21.52 | GNUtoo | eFfeM, I think we need to document what's needed and why,that could help us get rid of the rest |
| 14:22.09 | eFfeM | e.g. now if want bluetooth you also get bt media profile (or whatever it is called) and include gstreamer, which is pretty pointless if all you want is use BT serial profile to connect to a GPS |
| 14:22.47 | GNUtoo | yes I understand that |
| 14:22.52 | eFfeM | GNUtoo, tried to start that discussion a few times, but gave up, the force against it is too strong |
| 14:23.07 | *** join/#oe Ithinuel_at_anan (~ecdesktop@LRouen-151-73-15-250.w80-13.abo.wanadoo.fr) |
| 14:23.09 | GNUtoo | else all double recipes would be machine arch |
| 14:23.13 | eFfeM | people coming with legacy distros or recipes unknown to oe |
| 14:23.25 | GNUtoo | ok |
| 14:23.41 | GNUtoo | could we make theses people document what is needed and why? |
| 14:23.52 | GNUtoo | I bet that's impossible |
| 14:24.50 | mckoan | ant_work: depends on what do you mean with "cheap hw", I know companies using ARM based boards to manage MIDI |
| 14:26.19 | ant_work | mckoan: http://www.bgmi.it/?a=showproduct&b=2 |
| 14:26.29 | ant_work | imagine to excange this |
| 14:28.34 | *** join/#oe tmartins (~zero@187.37.63.127) |
| 14:28.56 | eFfeM | GNUtoo :-) |
| 14:30.53 | eFfeM | GNUtoo I'll happily go over the tree and remove dead recipes (where dead == not pinned by anyone and not latest) but got too much headwind |
| 14:31.06 | GNUtoo | indeed |
| 14:31.10 | GNUtoo | not a good idea |
| 14:31.13 | eFfeM | this is still an agenda point for TSC |
| 14:31.19 | GNUtoo | ok |
| 14:31.29 | eFfeM | if only for the 28 glib recipes |
| 14:31.35 | GNUtoo | keep in mind the idea of documenting why old recipes are needed |
| 14:31.39 | eFfeM | anyway, I have up on this |
| 14:31.43 | GNUtoo | that could be usefull |
| 14:32.04 | ant_work | eFfeM: now that you mention it, I think there is a minor packaging issue with the last glib |
| 14:32.16 | ant_work | iirc a couple of dbg.py are not packaged |
| 14:32.21 | GNUtoo | another way to do it would be to put a warning |
| 14:32.28 | GNUtoo | like this file will be removed in 1 month |
| 14:32.39 | GNUtoo | in gentoo they hard mask the file |
| 14:32.52 | GNUtoo | and then after a time they remove it |
| 14:33.01 | GNUtoo | both ideas could be combined |
| 14:33.20 | GNUtoo | becuase removing things wihout a plan would not be good |
| 14:33.25 | eFfeM | GNUtoo, there are several options possible, but apparently some people are so mordicus against it that I feel it is pointless to even try it |
| 14:33.29 | ant_work | GNUtoo: the point is someone outside in the wild could use a specific recipe w/out our knowledge. Sure they'll find all in the old branches |
| 14:33.38 | ant_work | eFfeM: ^ |
| 14:33.41 | GNUtoo | I know |
| 14:34.01 | GNUtoo | I wonder if theses people sync against .dev |
| 14:34.08 | ant_work | I doubt |
| 14:34.09 | GNUtoo | or how they work |
| 14:35.25 | eFfeM | ant_work: I understand that but if you have a recipe unknown to OE (and yes, i have a few) then it is your problem not oe's problem |
| 14:35.47 | eFfeM | submit them or create your own branch where you leave the versions that you need |
| 14:35.51 | eFfeM | or put them in a local overlay |
| 14:36.04 | GNUtoo | I know only how buglabs work,they use an oe overlay but they use stable |
| 14:36.37 | eFfeM | ask ubuntu if you can have gcc 3 in the feeds of 10.04 :-) |
| 14:36.59 | mckoan | ant_work: yes, would be possible |
| 14:37.02 | eFfeM | anyway really need to go now probably online @home in a few hrs |
| 14:37.09 | GNUtoo | in that case they build against oe.stable and the overlay is their recipes |
| 14:37.21 | GNUtoo | so basically they keep their recipe in sync with oe.stable |
| 14:37.29 | GNUtoo | they also use jalimo |
| 14:37.33 | GNUtoo | mmm |
| 14:37.34 | ant_work | mckoan: great. In that case I can think about buying the chassis' |
| 14:37.57 | ant_work | the two waterfall manuals are tempting... |
| 14:37.59 | GNUtoo | and their recipes are public but not all in oe |
| 14:38.22 | kergoth_ | morning |
| 14:38.43 | GNUtoo | in that case if they sync,I bet they have to keep their recipes in sync with oe.stable |
| 14:38.52 | GNUtoo | and they sync |
| 14:39.12 | GNUtoo | in the case where a company doesn't sync,why bother? |
| 14:40.20 | RP | hi kergoth_ |
| 14:40.21 | kergoth_ | thinks we need to somehow make it easier for companies to sync.. it's a pain, involving manual work, every time, today |
| 14:41.01 | RP | kergoth_: The main reason - why do people need to change OE? |
| 14:41.02 | GNUtoo | ok,how should we do that? |
| 14:41.04 | kergoth_ | RP: last night I noticed that the initial bitbake parse time was about 4 times slower than 1.8.. changing the anonfuncs to not use exec_func brought it back to 1.8 levels -- i suspect the python function logging bits |
| 14:41.41 | kergoth_ | just as an fyi :) |
| 14:41.56 | RP | kergoth_: Can you show me the patch you used please? |
| 14:41.57 | GNUtoo | btw sho is involved in security and know well openssl and has some little time |
| 14:41.58 | GNUtoo | ? |
| 14:42.14 | ant_work | RP: I can add that the (now disappeared) 1.10 was indeed faster parsing and building the runqueue |
| 14:42.29 | kergoth_ | RP: it's on the head of master, I changed all exec/eval to use utility functions in bb.utils, with the context stored there |
| 14:42.31 | MWelchUK_work_ | hrw, I get a missing checksum on ifupdown-0.6.10 |
| 14:42.40 | RP | ant_work: It should be the same as master. If its not, we should fix that |
| 14:42.47 | kergoth_ | RP: can always revert if it causes problems, but i have builds going, seems functional |
| 14:42.54 | hrw | shit |
| 14:43.08 | ant_work | oh, I'm still on 1.8.18, master had some nasty python issues last time I tried |
| 14:43.46 | ant_work | JaMa: should remember better |
| 14:44.42 | MWelchUK_work_ | hrw, http://pastebin.com/4EAUiSN9 |
| 14:45.11 | kergoth | ant_work: please test master if you have a chance, we'd like to get any remaining issues fixed so we can get a release out at some point |
| 14:45.12 | hrw | thx |
| 14:45.25 | ant_work | kergoth: sure |
| 14:46.23 | RP | ant_work: We fixed Jama's issues |
| 14:46.59 | ant_work | great to hear |
| 14:47.14 | RP | kergoth_: Does this go back to executing each anonymous function in turn? |
| 14:47.19 | ant_work | it was some math function iirc |
| 14:47.39 | kergoth_ | RP: for now, can easily change it back, was busy trying to get it to stop exploding |
| 14:47.55 | kergoth_ | there were some assumptions made in various places about things being global rather than local |
| 14:48.21 | CIA-2 | 03Martyn Welch <martyn.welch@ge.com> 07org.openembedded.dev * re398449f66 10openembedded.git/recipes/ifupdown/ifupdown_0.6.10.bb: |
| 14:48.21 | CIA-2 | ifupdown: added checksums |
| 14:48.21 | CIA-2 | Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |
| 14:48.29 | RP | kergoth_: :( |
| 14:48.37 | MWelchUK_work_ | hrw, Think this might fix the hwclock error at boot: http://pastebin.com/xbuhGh3k |
| 14:48.41 | kergoth_ | RP: well, i prefer 1m30s to 5m parse time. |
| 14:48.47 | kergoth_ | maybe we can speed it up past that, sure |
| 14:49.32 | RP | kergoth_: You've merged several different problems here :/ |
| 14:50.20 | kergoth_ | there's no reason they need to all run in their own little worlds, and the __builtins__ is no longer necessary. |
| 14:50.28 | kergoth_ | the methodpool injects into the shared global context now |
| 14:50.50 | RP | kergoth_: if that were true, the combined function thing would still be working |
| 14:50.55 | kergoth_ | huh? |
| 14:51.19 | kergoth_ | making anonfuncs run as one exec again is about 2 minutes of work |
| 14:51.20 | kergoth_ | probably less |
| 14:51.59 | RP | kergoth_: you just said above it had to be removed due to assumptions made in various places about things being global rather than local? |
| 14:52.05 | kergoth_ | what? |
| 14:52.10 | kergoth_ | no |
| 14:52.24 | kergoth_ | those assumptions are why i had to spend so much time getting it to stop shitting itself |
| 14:52.35 | kergoth_ | now i can spend a small amount of time tweaking further |
| 14:53.04 | RP | I guess I don't understand why the common function thing was removed if it wasn't the problem |
| 14:53.19 | RP | anyhow, lets see if we can really find out what caused the slowdown |
| 14:53.42 | kergoth_ | What part of "i was making it stop exploding" fails to sink in? |
| 14:54.17 | kergoth_ | And if you'd bothered to read the patch, you'd have seen that its not a problem to add it |
| 14:54.35 | hrw | MWelchUK_work_: does it works with busybox? |
| 14:54.53 | RP | kergoth_: obviously I'm just too think to understand this |
| 14:55.13 | MWelchUK_work_ | hrw, it seems to on BusyBox v1.13.2 |
| 14:55.31 | MWelchUK_work_ | Though my local time zone currently is utc :-) |
| 14:56.17 | MWelchUK_work_ | and it errors if I try "hwclock --defnotthere" |
| 14:58.20 | RP | kergoth_: "trying to stop it exploding" does not give me any information about how it was exploding. I can guess it may have involved the merged function somehow but I'm not physic so I can't know how. This is why I'm asking |
| 14:58.39 | kergoth_ | RP: I recall now why I did it this way to get it working. To utilize better_exec requires the text of the function and the filename, neither of which are available given the information stored in anonfuncs |
| 14:59.12 | kergoth_ | so I did it this way for the time being, figured we could go back and either add a basic_exec or add more info to the anonfuncs. |
| 14:59.29 | RP | kergoth_: Thanks. That reply is a bit more helpful :) |
| 14:59.30 | kergoth_ | so there's your answer. i did it to get the fucking thing to work, like i said |
| 15:00.12 | RP | kergoth_: Asking why is a valid question and its not becuase I'm not reading the patch ;-) |
| 15:00.15 | kergoth_ | Ideally, we'd do it so you get usable errors when an anonfunc fails |
| 15:00.23 | kergoth_ | but the way we were doing it before, that wasn't the case |
| 15:01.03 | kergoth_ | of course, ideally we'd have usable errors in all exec/eval's, but we don't have enough information in either expand() or bb.event today |
| 15:01.14 | RP | if you know how the function name is contructed you can work back to find it but I agree its not ideal |
| 15:02.01 | RP | kergoth_: Another part of the aim of that code was to get meaningful error logs on python failures |
| 15:02.16 | RP | A 4 times parsing slowdown is not acceptable of course |
| 15:02.26 | RP | the odd thing is I don't see that in Poky :/ |
| 15:02.39 | RP | or I can make poky 4 times faster which would be impressive |
| 15:03.17 | *** join/#oe Sleep_Walker (~Sleep@193.179.96.131) |
| 15:03.36 | kergoth_ | I suspect you can bring back the slowdown by making it use exec_func again. there's no need for it to do so though, its not a function, or a task, its just exec_func was our only python code execution tool at that time, its a remnant from early days |
| 15:04.12 | RP | exec_func is a wrapper around better_exec with logging? |
| 15:04.26 | *** join/#oe covalence (~covalence@m5d0e36d0.tmodns.net) |
| 15:04.35 | RP | If exec_func is really that slow I'd like to understand why |
| 15:04.55 | kergoth_ | agreed |
| 15:11.28 | kergoth_ | tests merged anonfunc execution |
| 15:14.21 | *** join/#oe rsalveti (~rsalveti@200.184.118.130) |
| 15:16.22 | *** join/#oe tmartins__ (~zero@187.37.63.127) |
| 15:24.59 | *** part/#oe Ithinuel_at_anan (~ecdesktop@LRouen-151-73-15-250.w80-13.abo.wanadoo.fr) |
| 15:25.54 | *** join/#oe mrc3_ (~ddiaz@189.157.110.236) |
| 15:25.55 | broonie | ant_work: Latency is going to be non-zero but there's no intrinsic problem with Linux that doesn't exist with any other OS. |
| 15:28.13 | MWelchUK_work_ | hrw, ifupdown is failing to create "${mandir}/man8" |
| 15:28.35 | hrw | moment |
| 15:29.28 | MWelchUK_work_ | hrw, I added "install -d ${mandir}", which also failed as /usr/share doesn't exist? |
| 15:29.55 | CIA-2 | 03Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> 07org.openembedded.dev * re2331268d0 10openembedded.git/recipes/ifupdown/ifupdown_0.6.10.bb: |
| 15:29.56 | CIA-2 | ifupdown: fix do_install |
| 15:29.56 | CIA-2 | Signed-off-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |
| 15:30.15 | MWelchUK_work_ | hrw, Ah :-) |
| 15:30.57 | kergoth_ | RP: seems like precompiling the objects at parse time gets you about 90% of the improvement that merging gets you, without confusing the error output. still playing around, will see |
| 15:31.13 | kergoth_ | experiments |
| 15:31.16 | *** join/#oe Crofton (~balister@rrcs-96-10-208-67.midsouth.biz.rr.com) |
| 15:31.26 | kergoth_ | hey Crofton |
| 15:32.09 | Crofton | hey |
| 15:41.00 | kergoth | grumbles |
| 15:41.39 | hrw | bye all |
| 15:41.58 | MWelchUK_work_ | hrw, s'later |
| 15:42.03 | hrw | MWelchUK_work_: I got devs to test results of our work on devices ;D |
| 15:42.47 | MWelchUK_work_ | just has himself. |
| 15:47.12 | kergoth_ | hmm, looks like a compiled code object retains its knowledge of the filename, should be able to make that optional for better_exec if it's one |
| 15:48.17 | *** join/#oe hrw|gone (~hrw@chello089078170228.chello.pl) |
| 15:57.41 | kergoth_ | wonder how much work it'd take to get the line numbers in python exec errors adjusted to be real line numbers in the files.. probably just need to compile at ast time where possible and pass around the lineno field as the starting line number |
| 15:58.17 | kergoth_ | sadly, code object's co_firstlineno field is read only.. heh |
| 16:02.35 | *** join/#oe pvanhoof (pvanhoof@217.22.63.169.static.hosted.by.easyhost.be) |
| 16:02.51 | mickeyl | pb_: |
| 16:03.04 | mickeyl | NOTE: Running task 469 of 475 (ID: 14, /local/pkg/oe/openembedded/recipes/linux/linux-leviathan_git.bb, do_package) |
| 16:03.04 | mickeyl | sh: arm-oe-linux-gnueabi-depmod-2.6: command not found |
| 16:03.13 | mickeyl | could that be responsible for the broken module depends atm.? |
| 16:03.53 | *** join/#oe zazenrasta (~zaz@adsl-074-244-082-076.sip.asm.bellsouth.net) |
| 16:04.37 | *** join/#oe cminyard (~cminyard@pool-173-57-145-237.dllstx.fios.verizon.net) |
| 16:08.48 | mickeyl | Crofton: ping |
| 16:09.04 | Crofton | pong |
| 16:09.15 | mickeyl | Crofton: hi. ka6sox needs your ssh key |
| 16:09.18 | Crofton | k |
| 16:09.24 | mickeyl | you have his email? |
| 16:09.41 | Crofton | can you send it to me |
| 16:09.44 | mickeyl | his nickname @ gmail.com |
| 16:09.50 | Crofton | thanks |
| 16:12.09 | RP | kergoth_: Did you see that function name mangling function? |
| 16:12.31 | RP | kergoth_: for anonymous methods - that included the line number in the function name |
| 16:12.33 | kergoth | function name mangling function? you mean the fn.translate() used for the anonfuncs? |
| 16:12.36 | kergoth | yes, i know |
| 16:12.56 | RP | kergoth_: I had wondered about parsing the tracebacks and using that to offset the line numbers |
| 16:13.56 | kergoth | sounds pretty hackish, would think it would be better to pass the starting lineno to the better_* functions the way realfile is |
| 16:14.14 | RP | kergoth_: yes, that would be better :) |
| 16:14.44 | kergoth | just pushed a resurrection of the merged anonfuncs, for the time being. still looking into the alternative though |
| 16:15.07 | kergoth | merged is now cutting the time from 1m21s to 1m20s, roughly |
| 16:15.58 | RP | kergoth: The reason I added that code was that the previous version was using all the concatenated python which broken on the whitespace |
| 16:16.29 | kergoth | yeah, this is obviously an improvement, using a function for each anonfunc |
| 16:16.37 | RP | kergoth_: I also wanted the methodpool to start being useful and avoid recompiling functions all the time |
| 16:18.18 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
| 16:18.21 | kergoth | regardless, the intent of the patch was to consolidate the eval/exec bits, the performance change and merge/not merge was incidental |
| 16:18.33 | kergoth | gets caffeine |
| 16:19.00 | RP | kergoth_: I know, its all a balancing act |
| 16:19.25 | kergoth | we need to find a way to make this less brittle. it'd help if we had real unit and performance tests to catch regressions :\ |
| 16:19.59 | RP | kergoth: Yes, it would help. Using OE/Poky as a testsuite is less than ideal |
| 16:25.30 | *** join/#oe kergoth_ (~clarson@ip24-251-170-95.ph.ph.cox.net) |
| 16:29.54 | *** join/#oe hansdampf (~moritz@rgnb-4d04bda8.pool.mediaWays.net) |
| 16:32.40 | *** join/#oe Sleep_Walker (~Sleep@193.179.96.131) |
| 16:35.26 | *** join/#oe ant_home (~andrea@host207-251-dynamic.8-87-r.retail.telecomitalia.it) |
| 16:42.14 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
| 16:42.40 | *** join/#oe mrc3_ (~ddiaz@189.157.110.236) |
| 16:47.02 | CIA-2 | 03Michael 'Mickey' Lauer <mickey@vanille-media.de> 07org.openembedded.dev * re36460c470 10openembedded.git/recipes/linux/ (linux-leviathan/defconfig linux-leviathan_git.bb): |
| 16:47.02 | CIA-2 | linux-leviathan: fix suspend/resume |
| 16:47.02 | CIA-2 | Note to self: hand-editing defconfig and multistate configs doesn't match |
| 16:47.31 | ant_home | kergoth: 'bitbake -p console image' takes: |
| 16:47.43 | ant_home | with 1.8.18 real 3m51s |
| 16:48.26 | ant_home | testing master |
| 16:48.56 | ant_home | :) 2m33s |
| 16:49.31 | *** join/#oe dth (~dieter@p4FDED439.dip.t-dialin.net) |
| 16:53.45 | *** join/#oe mario-goulart (~user@67.205.85.241) |
| 16:56.57 | covalence | Has anyone ever dealt with taking SRPM sources and cross-compiling them as well as utilizing the cross-compiled binary RPM in a staging directory? |
| 16:57.55 | Tartarus | Converting an SRPM + spec to OE recipes isn't hard, manually |
| 16:58.02 | Tartarus | So long as you speak both :) |
| 16:59.39 | covalence | I noticed an old version of libaio was doing just that and using the rpm_core and base_srpm classes to build the SRPM, but they manually did a staging task to explicitly install develpment headers and libraries. Would it be possible to just plain install the RPM into the staging directory, maybe an additional rpm2cpio command for the do_staging task? |
| 17:01.12 | Tartarus | Ah, I've not played with that stuff before |
| 17:01.43 | Tartarus | So that's a different thing |
| 17:02.09 | Tartarus | The problem with re-using binary RPMs is that we don't know that they will be compatible with what we build |
| 17:02.28 | Tartarus | One could make a new distro conf and do things to ensure that it worked |
| 17:02.53 | Tartarus | I think there's an example or two in OE now of compatible with ____ external distribtuions |
| 17:03.18 | Tartarus | And I'm pretty sure that there's companies somewhere that have taken $<commerical linux dist> and wrapped OE around it |
| 17:29.50 | *** join/#oe Hasse_ (~quassel@0x5552e721.adsl.cybercity.dk) |
| 17:35.57 | covalence | Yeah, that is basically what I would like to do ;) |
| 17:37.50 | incandescant | any Bitbake DSL experts in the house? |
| 17:38.58 | incandescant | I have a bbclass that has some Python functions and I'd like to expand some data from the datastore and save them as variables with class scope |
| 17:39.09 | incandescant | can anyone point me at how to do that? |
| 17:39.11 | Tartarus | covalence: Well, it can done, yes :) It takes time tho |
| 17:40.18 | *** join/#oe Sleep-Walker (~Sleep@193.179.96.131) |
| 17:42.53 | covalence | Tartarus: Yeah...I am finding that out now ;) |
| 17:46.27 | kergoth_ | incandescant: bb.data.setVar() to set variables, bb.data.getVar() to get them. if you want to adjust the metadata with python, create a python function with no name (anonymous), those are run at the end of the recipe parsing process, so you can use them to make adjustments to the metadata. see the bbclasses, they're used in a number of places, including base.bbclass |
| 17:48.06 | kergoth_ | incandescant: an alternative for setting just one variable with python would be to 'def' a python function and call it from the variable. FOO = "${@myfunc(d)}" |
| 17:48.37 | incandescant | kergoth_: thanks :-) |
| 17:48.46 | *** join/#oe Noctambulist (~Sleep@193.179.96.131) |
| 17:53.23 | kergoth_ | incandescant: np |
| 17:54.59 | kergoth_ | incandescant: also note that currently classes that are inherited by 'inherit' rather than INHERIT (which end up in the configuration metadata) are essentially injected at that exact point into the recipe metadata. it doesn't remain separate, so there is no "class scope" at the moment. I'd like to change that, moving those classes into a layer between the config metadata and the recipe, but that's not how it happens tdoay |
| 17:55.06 | kergoth_ | s/tdoay/today/ |
| 17:55.52 | incandescant | kergoth_: I inferred as much from your response, but thanks for clarifying! |
| 17:56.02 | incandescant | kergoth_: I can certainly see a use to a class scope |
| 17:58.38 | kergoth_ | there's a bit of confusion in our format, some things feel imperative, others feel declarative. the immediate operation of inherit is one of those, in my opinion |
| 18:11.47 | *** join/#oe Ironnads (~Ironnads@host81-159-87-1.range81-159.btcentralplus.com) |
| 18:12.38 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 18:21.31 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
| 18:25.07 | florian | re |
| 18:33.29 | ka6sox | hi, is git working? |
| 18:37.48 | *** join/#oe eFfeM1 (~Frans@j200125.upc-j.chello.nl) |
| 18:39.58 | JaMa | ka6sox: just git pulled successfully |
| 18:52.30 | *** join/#oe Crofton (~balister@pool-96-240-168-177.ronkva.east.verizon.net) |
| 18:55.41 | *** join/#oe kristoffer (~kristoffe@109.58.10.203.bredband.tre.se) |
| 18:57.32 | ka6sox | JaMa, thanks. |
| 19:00.24 | Crofton | ka6sox, you need a key? |
| 19:01.20 | CIA-2 | 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * rb055e9c76e 10openembedded.git/recipes/postfix/ (postfix.inc postfix_2.0.20.bb postfix_2.2.12.bb): |
| 19:01.20 | CIA-2 | postfix: convert to INC_PR |
| 19:01.20 | CIA-2 | Signed-off-by: Roman I Khimov <khimov@altell.ru> |
| 19:01.20 | CIA-2 | 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * rd7ff8f75b3 10openembedded.git/recipes/spamassassin/ (11 files in 2 dirs): (log message trimmed) |
| 19:01.20 | CIA-2 | spamassassin: new recipe |
| 19:01.21 | CIA-2 | SpamAssassin is a very powerful and fully configurable spam filter with |
| 19:01.22 | CIA-2 | numerous features including automatic white-listing, RBL testing, Bayesian |
| 19:01.22 | CIA-2 | analysis, header and body text analysis. It is designed to be called from |
| 19:01.23 | CIA-2 | a user's .procmail or .forward file, but can also be integrated into a |
| 19:01.23 | CIA-2 | Mail Transport Agent (MTA). |
| 19:01.31 | CIA-2 | 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * rd378fb6c96 10openembedded.git/recipes/update-rc.d/update-rc.d_0.7.bb: |
| 19:01.32 | CIA-2 | update-rc.d: allow native build via BBCLASSEXTEND |
| 19:01.32 | CIA-2 | Makes it possible to use BBCLASSEXTEND for native in packages inheriting |
| 19:01.32 | CIA-2 | update-rc.d. |
| 19:01.32 | CIA-2 | Signed-off-by: Roman I Khimov <khimov@altell.ru> |
| 19:02.28 | CIA-2 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r29dc4e1f84 10openembedded.git/recipes/gnome/system-tools-backends_2.8.3.bb: system-tools-backends 2.8.3: reinstate policykit support |
| 19:19.49 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r270bd65066 10openembedded.git/recipes/shr/ (phoneui-shr-theme-neo_git.bb phoneui-shr-theme-o2_git.bb): phoneui-shr-theme: bump SRCREV for o2 and neo theme |
| 19:42.05 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
| 20:04.18 | *** join/#oe marex (~marex@vasut.kolej.mff.cuni.cz) |
| 20:19.20 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r8c1753f14b 10openembedded.git/recipes/linux/ (2 files in 2 dirs): |
| 20:19.20 | CIA-2 | linux-openmoko-2.6.32: update defconfig, add BT support, more watchdogs |
| 20:19.20 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
| 20:30.44 | *** join/#oe dth (~dieter@p4FDED439.dip.t-dialin.net) |
| 20:33.14 | pb_ | mickeyl: good evening |
| 20:35.27 | *** join/#oe rob_w (~bob@p549BC231.dip.t-dialin.net) |
| 20:42.14 | *** join/#oe rsalveti_ (~rsalveti@187.77.196.39) |
| 20:52.17 | CIA-2 | 03Adrian Alonso <aalonso00@gmail.com> 07org.openembedded.dev * r26aa41630f 10openembedded.git/recipes/imagemagick/ (files/openm4-autoconf-fix.patch imagemagick_6.3.5-10.bb): (log message trimmed) |
| 20:52.17 | CIA-2 | imagemagick_6.3.5-10.bb: openm4 fix |
| 20:52.17 | CIA-2 | * m4/openmp.m4 (AC_OPENMP): Do not define with Autoconf 2.62 or newer. |
| 20:52.17 | CIA-2 | 2008-12-03 Ralf Wildenhues <[EMAIL PROTECTED]> |
| 20:52.18 | CIA-2 | Bruno Haible <[EMAIL PROTECTED]> |
| 20:52.18 | CIA-2 | * ref: http://www.mail-archive.com/bug-gnulib@gnu.org/msg12387.html |
| 20:52.19 | CIA-2 | Signed-off-by: Adrian Alonso <aalonso00@gmail.com> |
| 21:04.35 | *** join/#oe ant_home (~andrea@host131-186-dynamic.60-82-r.retail.telecomitalia.it) |
| 21:13.13 | *** join/#oe rsalveti (~rsalveti@200.184.118.130) |
| 21:13.29 | *** join/#oe thaytan (~jan@ppp59-167-167-201.static.internode.on.net) |
| 21:30.17 | mickeyl | pb_: hi pb_ |
| 21:30.30 | mickeyl | <mickeyl> NOTE: Running task 469 of 475 (ID: 14, /local/pkg/oe/openembedded/recipes/linux/linux-leviathan_git.bb, do_package) |
| 21:30.30 | mickeyl | <mickeyl> sh: arm-oe-linux-gnueabi-depmod-2.6: command not found |
| 21:30.30 | mickeyl | <mickeyl> could that be responsible for the broken module depends atm.? |
| 21:34.08 | *** join/#oe marcosmamorim (~marcos@201-27-172-20.dsl.telesp.net.br) |
| 21:40.35 | *** join/#oe marcosmamorim (~marcos@201-68-111-124.dsl.telesp.net.br) |
| 21:53.09 | *** join/#oe marcosmamorim1 (~marcos@201-68-108-238.dsl.telesp.net.br) |
| 22:02.37 | *** join/#oe playya (~playya@unaffiliated/playya) |
| 22:09.50 | *** join/#oe jd (~jd@bas1-montreal33-1279639532.dsl.bell.ca) |
| 22:09.50 | *** join/#oe jd (~jd@Wikipedia/HellDragon) |
| 22:21.07 | *** join/#oe marcosmamorim (~marcos@201-43-152-129.dsl.telesp.net.br) |
| 22:25.34 | *** join/#oe hd (jd@bas1-montreal33-1279639532.dsl.bell.ca) |
| 22:25.35 | *** join/#oe hd (jd@Wikipedia/HellDragon) |
| 22:25.49 | *** join/#oe marcosmamorim (~marcos@201-68-179-158.dsl.telesp.net.br) |
| 22:29.41 | *** join/#oe marcosmamorim1 (~marcos@189-46-191-224.dsl.telesp.net.br) |
| 22:36.10 | *** join/#oe Martin-B (~martin@pool-39-67-198-89.dbd-ipconnect.net) |
| 22:36.12 | *** join/#oe jd (~jd@modemcable207.134-202-24.mc.videotron.ca) |
| 22:36.12 | *** join/#oe jd (~jd@Wikipedia/HellDragon) |
| 22:41.45 | *** join/#oe Laibsch1 (~Laibsch@219.127.212.210) |
| 22:42.17 | *** part/#oe Laibsch1 (~Laibsch@219.127.212.210) |
| 22:55.06 | *** join/#oe marcosmamorim (~marcos@201-43-35-76.dsl.telesp.net.br) |
| 22:55.56 | CIA-2 | 03Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * rcd25de5ea0 10openembedded.git/recipes/eglibc/ (eglibc_2.10.bb eglibc_2.11.bb eglibc_2.9.bb eglibc_svn.bb): |
| 22:55.56 | CIA-2 | eglibc: Apply branch fixes. |
| 22:55.56 | CIA-2 | * Use the latest tip of the respective branches |
| 22:55.56 | CIA-2 | which have received bug fixes. |
| 22:55.56 | CIA-2 | * Move svn recipe to latest. |
| 22:55.57 | CIA-2 | Signed-off-by: Khem Raj <raj.khem@gmail.com> |
| 22:58.43 | *** join/#oe EiNSTeiN__ (~einstein@216.252.89.207) |
| 23:01.46 | *** join/#oe marcosmamorim (~marcos@187.35.32.43) |
| 23:04.54 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
| 23:08.36 | *** join/#oe marcosmamorim1 (~marcos@187.35.34.192) |
| 23:17.27 | *** join/#oe jd (~jd@modemcable207.134-202-24.mc.videotron.ca) |
| 23:17.27 | *** join/#oe jd (~jd@Wikipedia/HellDragon) |
| 23:48.24 | marex | mickeyl, hi, you around ? |
| 23:49.08 | mickeyl | ya |
| 23:53.08 | *** join/#oe raster (raster@enlightenment/developer/raster) |
| 23:54.26 | *** join/#oe hansdampf (~moritz@rgnb-4d04bd40.pool.mediaWays.net) |