| |
| |
| |
|
Page: 1 2 3 4 5 6
Comments:
<0> koen, btw one weird idea. But how hard would it be to incorperate tgz as a package cl***?
<1> hh.org hasn't done badly from my efforts. LED, backlight, w100fb, rtc, sd and quite a few other things got merged with some help from me :)
<1> Kristoffer: It already is ;-)
<0> RP, I just wish they would give up and merge their stuff with vanilla and not use leftside hacks..
<0> RP, tgz not tar.gz :D
<1> Kristoffer: The hh.org problem was that nobody was prepared to deal with making the code mainline quality
<2> Kristoffer: 'tar' already exists
<0> RP, most likely. But its a pity. Like for instance Im using alot of code from Alex Lange that is quite nice. But perfectly wasted on a side-stream branch.
<1> Kristoffer: I totally agree. If you need any advice on getting code into mainline, ask me as I have experience with most of the maintainers and a fairly good track record ;-)
<0> RP, Im trying to work my way through russells watchful eyes currently. First time I ever had to clean out whitespaces :D Im waiting for him to give me the final go ahead to submit. Where does it usually get submitted? Through russell ..?
<2> L-A-K -> patchtracker
<1> Kristoffer: It depends what you're submitting. If its arch/arm, it goes to Russell's patch tracker
<2> that &*&$%*@ patch-tracker doesn't understand gpg signing
<1> Kristoffer: As an idea of my patch turnover with the OZ project: http://www.rpsys.net/openzaurus/patches/archive/ :)
<0> RP, yeah currently everything is related to arch/arm. I've submitted patches and fixed those things he had opinions about. Once he "accepts" it though. Does he push it further or do I submit it to the patch tracker?
<2> Kristoffer: you submit it
<1> You submit to the patch tracker and he takes it from there
<1> Kristoffer: Have a look at the patch tracker as you can see the things other people have submitted
<0> RP, thats alot of patches :D how many years of work?
<2> you can scare a lot of people by showing them an linux-openzaurus.bb
<2> 2.6.7 is ~2 years old, right?
<1> Kristoffer: Since June 2004
<1> koen: Nov 2004 :)
<0> RP, nice :D
<0> RP, currently what works and what doesnt on the Spitz?
<3> ~lart local.conf
<2> Kristoffer: http://wiki.openzaurus.org/KernelInfo26#SL-Cxx00 and http://rpsys.net/openzaurus/
<2> RP: iirc overlay is the only 'missing' thing, right?
<4> koen: voltage control, cpufreq
<1> koen: that and cpu frequency scaling on pxa270
<2> heh
<2> cpufreq is doing funky stuff for pcmcia on the hx and h2200
<1> koen: good or bad "funky stuff"?
<2> the worst part: I wrote that pcmcia driver :)
<2> RP: resetting the card on freq changes
<0> lol
<1> koen: this would be why I haven't touched that posioned challis :)
<1> koen: Does it work on the c7x0?
<2> the ts on my h2200 is emulating a pre-mikearthur tosa-ts when doing cpufreq
<2> RP: I think it does
<2> I love the 'conservative' governor
<2> hrw|furied: could you add the update libsndfile to the feeds if you have time?
<5> how can I avoid recompiling the gcc-3.4.4 cross compiler? ***UME_PROVIDED doesn't seem to work
<4> koen: is it in oz354x?
<5> I say: ***UME_PROVIDED += "virtual/arm-linux-gcc-3.4.4", have that in my path, but bitbake still insists that it wants to build it.
<5> arm-linux-gcc-3.4.4 is in /usr/local/arm/3.4.4/bin ...
<5> Is there some other "magic" that I'm missing?
<6> did anyone mess w/ autoconf-native-2.59-r3 in .oz354x recently?
<6> ignore that =)
<5> ok, so I suppose that ***UME_PROVIDED is broken as well
<6> zecke: you might wanna add "bzip2" to your "sanity" thingy
<7> CoreDump|home: adding bzip2-native to ***UMED_PROVIDED
<3> damn it...why does bitbake segfault on me if I don't use the shell...
<7> segfault?
<3> zecke: yes, segfault
<7> miscompiled python?
<3> bitbake something /home/papercrane/oe/oz354.build
<3> zsh: 28512 segmentation fault bitbake something
<3> works fine with -i....
<3> echo "build something; exit" | bitbake -i
<3> been this way for a long, long time
<3> I suppose I could try recompiling python...
<3> of course portage is working fine for me ;-)
<6> dualcore rocks
<3> I don't have that, just an athlon64
<3> much faster than my old athlon
<8> freyther org.oe.dev * rf1283b89... / (1 cl***es/sanity.bbcl***): cl***es/sanity.bbcl***: Check for bzip2 in the path as well
<7> CoreDump|home: done
<7> later
<6> zecke: thanks
<4> ~curse my buildbox
<9> May the fleas of a thousand camels infest your most sensitive regions, my buildbox !
<3> AHAH!!!
<3> dies on import psyco
<4> JustinP: psyco and amd64?
<3> it was doing this before I had an amd64
<3> and I'm not running a 64-bit OS....
<3> whoa...psyco wasn't in my world apparently....that's probably my problem. 1.2 installed 1.5.1 available
<3> yep, that was it
<3> updated psyco and it worked
<3> strange that it worked for -i....
<4> happy you
<10> JustinP: you got freeze to work?
<3> NAiL: heh, no...I tried but it was built without the multimachine stuff in mind
<3> NAiL: I wrote my own version as a command in the shell
<10> ah, heh
<3> NAiL: I tried to do it with python in freeze.bb but I was having problems getting what I needed
<3> it's not 100%, though as I'm missing certain core native bbfiles apparently....
<4> 2/cr
<3> aha....
<4> cu
<3> errr....different....
<3> going to miss -native, damn
<3> NAiL: so you were a user of freeze?
<10> openslug/debianslug/etc used to use freeze when we did a release
<3> I see
<3> I want to use it to just build what I have already built
<3> (update feed)
<10> yeah
<3> I think I have a working version done
<3> some superfluous code in it now....
<3> but oh well
<3> just testing
<3> ~pray
<9> May the penguin be with you...
<3> pfff
<3> NAiL: if you're interested: http://oe.reversefold.com/bitbake-freeze.patch
<10> you got it working proper?
<3> well...it takes some manual work
<3> set PKGDIR to the checkout/packages dir in your local.conf
<3> leave BBFILES including everything
<3> then: bitbake -i
<3> freezr
<3> freeze
<3> it will write out frozen-packages.conf in your local.conf (***uming your layout is the same as mine...this should also be configurable...)
<3> in the same dir as your local.conf, that is
<3> should be easy to change
<3> I had problems including the conf file so I just copied its contents into my local.conf
<3> and it's building stuff now ;-)
<10> good ;-)
<3> NAiL: well, the path thing is easy to fix if it doesn't work for you, right at the beginning of the freeze() function
<8> nail org.oe.dev * rfd426656... / (3 files in 3 dirs): litestream: Add package. litestream is a shoutcast-compatible streamer, but tiny and a lot less dependencies
<8> nail org.oe.dev * re9fa5... / (1 packages/icecast packages/nonworking/icecast): icecast: Move to nonworking
<8> nail org.oe.dev * rd6b1d... / (1 packages/meta/slugos-packages.bb): slugos-packages: Add litestream to feeds
<8> pfalcon org.oe.dev * re0057fe4... / (7 files in 4 dirs):
<8> rocksndiamonds: New package, a game, Boulderdash/Emerald Mine/Supaplex/Sokoban clone.
<8> * Initial draft recipe version, but already works.
<8> * Too big even for VGA devices (window size is hardcoded in game).
<8> * Data storage formats are non-optimal (pcx/uncompressed level files).
<8> * Packaging crude, need to be split up.
<8> * Nice game.
<11> morning
<12> morning
<12> koen: hi
<11> ~lart gdm for 400M of logs
Return to
#oe
or
Go to some related
logs:
ubuntu cups pdf from gimp
KDE seems to be already running
qdvdauthor breezy
#physics
gentoo locate update
#css
+flash slideshow on myspace
apt-get install rsyslog
#lisp
gentoo _h_errno GLIBC_2.0
|
|