@# Quotes DB     useful, funny, interesting





Google
 
Web www.quotesdb.info
Undernet  |  EFnet  |  Quakenet  |  Freenode  |  Dalnet  |  Ircnet  |  Galaxynet
Page: 1 2 3 4 5 6



Comments:

<0> mr_nice_slacker: worked
<0> verify done
<0> ill get it over to the serial
<1> rpurdie * r bitbake/lib/bb/taskdata.py: taskdata.py: Fix so only warn about failed providers once.
<2> night
<3> bonjour !
<4> morning
<5> morning
<4> hi XorA
<4> RP: bitbake trunk + 'bitbake bootstrap-image' == nothing built
<5> hrw|work: speed optimsation :-)
<6> morning all
<4> yep
<5> hey RP
<4> RP: what I have to do to build image with trunk?
<6> hrw|work: bitbake bootstrap-image should work fine...



<6> hrw|work: What was the output from bitbake?
<4> RP: nope. it do boostrap-image/do_fetch then do_rootfs and fails due to lack of makedevs
<7> re
<6> hrw|work: So it did try to build something :)
<4> RP: will pastebin log
<6> hrw|work: Is this with a clean tmp?
<4> clean
<8> sounds like hrw may be hitting what i hit when i tried it last week
<4> btw - why .dev still has 2.4 zaurus kernels??
<6> kergoth: I checked the new dependency code into trunk on Sunday night so maybe, maybe not
<4> http://pastebin.ca/143944 is enough?
<8> ah, cool
<6> hrw|work: I'd like them left in case we need them for dev purposes...
<6> kergoth: It also has basic multithreading capability
<6> hrw|work: Is this the oz354 branch?
<4> RP: then we can take them from history - its SCM...
<4> RP: .dev
<6> hrw|work: It didn't build anything else?
<4> nope
<6> hrw|work: and you have the changes I checked into .dev for the new bitbake?
<4> RP: thats whole log - first it complain about lack of gcc295 for 2.4 kernels
<4> RP: probably now - checkouting .dev again due to monotone fscking
<4> RP: retrying with recent .dev
<6> hrw|work: Its as if the dependency code in image_ipk.bbcl*** is missing
<7> RP: hrw|work : I think I can continue the builds there
<6> kergoth: Try multithreading with bitbake head - it runs with poky :)
<9> nice zecke
<4> zecke: nice toys you find
<4> RP: now it goes
<8> RP: restarting the build with that set to 3.. *crosses fingers*
<4> RP: why it try openzaurus-sa at all when MACHINE=tosa? "NOTE: Removing failed build target openzaurus-sa"
<4> RP: same with few other !tosa kernels
<10> hrw|work: I suspect it evaluates all providers for virtual/kernel and removes the broken ones (e.g. ones requiring 2.95.3)
<7> now I need to transfer my scripts...
<4> koen: probably
<4> zecke: 'svn checkout'?
<4> NOTE: package gnu-config-native-0.1+cvs20050701-r4: task do_package: completed
<4> funny... native and packaging..
<10> and a good morning to all as well
<7> hrw|work: my build scripts, with auto cleanup, etc...
<4> hi koen too
<4> zecke: put them in svn or use rsync?
<7> hrw|work: I need to touch the sample local.conf
<4> native.bbcl*** should not set PACKAGES=""?
<4> hm.. it does it.
<4> RP: usbhost on cx00 is ohci-hcd?
<6> hrw|work: yes
<4> RP: hm. I want to autoload it on tosa but probably autoloading it on cx00 is not quite what we want?
<7> hrw|work: ATM I'm a bit scared we need to move the machine into a different net...
<6> koen, hrw|work: correct, it evaluates all providers - it computes the dependency tree in advance rather than on the fly
<6> hrw|work: It will conflict with usb gadgets like g_ether which people probably use more often
<4> module_autoload_ohci-hcd_tosa = "ohci-hcd"
<4> then
<5> hey
<6> hrw|work: that would do it
<5> ~lart wndows
<4> RP: kind of getting status of working tasks would be nice



<4> RP: it is hard to find what is doing from output
<6> hrw|work: It would. We really need to get some kind of UI to report it nicely though...
<10> some curses gui with seperate boxes for the various tasks?
<1> hrw org.oe.oz354x * rda9e7689... / (1 packages/linux/linux-openzaurus.inc): linux-openzaurus: added dummy do_rm_work to not remove WORKDIR because wlan-ng stuff needs it
<1> hrw org.oe.oz354x * rd2658c57... / (4 files in 2 dirs): linux-openzaurus: autoload USB Host on Tosa
<11> Hi
<11> Is it possible to habe two different ld-linux.so.2 on a system and that one binary is using the standard one and another binaries are using a speacial ld-linux.so.2? Does exist an envirnment variable for that?
<10> hrw|work: iirc the 2.4 kernels are still present for sharprom-compatible stuff
<5> hrw|work: how to make rm_work happen after do_deploy in zaurus-updater.bb as rm_work breaks the build for that .bb
<4> XorA: hmm will pluck it from branch
<4> argh.. pluck is not perfect yet...
<10> XorA: did you see gpe-fbpanel already?
<5> koen: florian was talking about it a couple of days ago, did he checkin when I wasnt looking?
<4> hrw@bitbake:~/devel/oe/org.openembedded/packages/linux$ mtn pluck -r65cddc99c679a5ae5c62989d9fc821a6dcc878d6
<10> XorA: yes
<4> mtn: applied changes to workspace
<4> hrw@bitbake:~/devel/oe/org.openembedded/packages/linux$ mtn dif .
<4> #
<4> # no changes
<4> ;((
<6> With the new bitbake, you could declare do_latebuild as the default task and insert do_rmwork between do_build and do_latebuild
<5> koen: that in gpe cvs, I dont tend to monitor that
<10> XorA: http://projects.linuxtogo.org/plugins/scmsvn/viewcvs.php/trunk/base/gpe-fbpanel/?root=gpe
<10> hrm
<10> I suspect that will give an 'access denied'
<5> koen: no group
<10> XorA: ah well, florian put it in the experimental svn repo for gpe
<5> koen: goodo, his changes sounded rockin
<10> XorA: svn co svn://projects.linuxtogo.org/gpe/trunk/base/gpe-fbpanel
<4> koen: fork of fbpanel for gpe?
<10> hrw|work: it seems that way
<10> hrw|work: I discovered it this morning
<10> I'll ask florian when he's online
<4> RP: 2.6.16/.dev differ from 2.6.1.6/.oz354x in few patches: /zlib_inflate-r3.patch /logo_rotate_fix-r1.patch /poodle_partsize-r0.patch /jffs2_longfilename-r1.patch
<11> okay solved the pr
<11> oblem
<4> RP: building with multitask bitbake need more diskspace when rm_work used
<1> pH5 org.oe.dev * rd5edb15... / (10 files in 5 dirs):
<1> udev: add 097
<1> - drop support for kernels <2.6.15, udevsynthesize replaced by udevtrigger
<1> - split out libvolume_id into its own package
<1> - I set PKG_libvolume-id-dev="libvolume-id-dev" because otherwise
<1> libvolume-id-dev would be renamed to libvolume-id0, too.
<1> - DEFAULT_PREFERENCE="-1", it's not run-time tested yet.
<5> koen: florian has added autotools, and support for .desktop files from what he said to me
<10> hey mikearthur
<12> hey koen
<4> RP: can you check it? I want to push some changes from branch to dev
<5> hey mikearthur
<12> yo XorA
<6> hrw|work: I'll have a look shortly
<6> hrw|work: Sadly, more diskspace is a side effect
<4> cr
<4> RP: acceptable it must be
<4> RP: accepted by users I mean
<1> hrw org.oe.dev * rb20eb0... / (1 packages/linux/linux-openzaurus_2.6.17.bb): linux-openzaurus: bump PR to get dependencies in modules recreated for feeds
<1> pH5 org.oe.dev * ra1c2d0d... / (1 packages/udev/udev.inc packages/udev/udev_097.bb): udev: stop overwriting description in udev.inc
<1> hrw org.oe.dev * rf2f012d... / (1 packages/linux/linux-openzaurus.inc): linux-openzaurus: added dummy do_rm_work to not remove WORKDIR because wlan-ng stuff needs it
<1> pH5 org.oe.dev * rc58d6c1d... / (1 packages/udev/udev_097.bb): udev: add description for libvolume_id
<6> hrw|work: Yes, I hadn't thought of that problem. I guess we need an option to force the older more linear behaviour
<4> RP: number-of-tasks=1 should be fine?
<6> hrw|work: I suspect it will still jump from task to task a bit...
<6> hrw|work: Its all to do with the task weighting algorithm and I have some ideas which might improve that based on this comment...
<10> RP: does it really needs to run (or print) all the do_fetch stuff?
<4> RP: clean/rm_work/fetch can be anytime, unpack/patch/configure/compile take diskspace
<4> time to pluck some things but first meeting :(
<12> any ideas why I'd be getting this times a hundred?
<12> /usr/bin/jade:../rsvg-docs.sgml:14:16:E: element "BOOK" undefined
<12> package librsvg-2.6.5
<13> 1-2h wasted now
<7> mikearthur: what was the result/conclusion of the /usr/lib/libXau.so from yesterday?


Name:

Comments:

Please enter the result of the sum 63 + 46 (to avoid spam):






Return to #oe
or
Go to some related logs:

is fixboot harmful
CentOS5 Optiplex 320
#gentoo
ubuntu ppoa
#suse
#ldap
script remote di chanel dalnet
Knoppix lock-session
perl use warning
#php



Home  |  disclaimer  |  contact  |  submit quotes