| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10
Comments:
<0> Omg 47 revs in one day
<1> pfff, that's nothing
<2> rpurdie org.oe.dev * rb4cecac3... /packages/linux/linux-openzaurus_2.6.17.bb: linux-oz-2.6.17: Update to lastest ASoC and fix c7x0 so audio input (mic) now works. Recl***ify several patches.
<1> RP: ah cool, more merged patches
<1> RP: I guess I have to pick a new .bb to show at FOSDEM 2007 ;)
<3> Ive set SRCDATE to 20060627 due to Opie working well at that date, but SRCDATE is also used for matchbox, gpe.. How can i specify what versions to use for different?
<3> shouldnt we split up SRCDATE into sub variables, like opie_srcdate, matchbox_srcdate..
<4> I remember there was some bitbake variable for that...
<3> The best solution were if one could set preferred version CVS+20060627 and then set for each package
<3> if no preferred version was set It could drag using SRCDATE
<4> PREFERRED_VERSION exists
<3> yeah I know, but Can i set preferred version and when I use CVS+20060627 make it understand to not use SRCDATE but instead drag 20060627
<4> I used that once to setup a specific CVS gpe-calendar version.
<4> oh...
<4> hmm... lemme think :)
<3> My problem is basicly this, lets say that opie works fine for 20060627 but gpe works fine in 20060727..how can I make that work?
<3> setting SRCDATE would mean that both Opie and Gpe would get same CVS date
<3> so one of them would be broken
<4> PREFERRED_VERSION_gpe-calendar = "CVS+20060627" for example, should work I guess, doing it off my head though
<3> Does it break down the line into, oki he wasnt version CVS with date 20060627, no matter what SRCDATE says?
<3> wasnt=wants
<4> i understand your question, but i believe in this case it depends on the .bb file for the package
<4> well, as a last resort, you can hack one... :)
<3> Just alot of packages to fix :)
<4> ouch
<3> all opie, gpe and matchbox packages for instance
<4> can't you bitbake them separately? are they interdependent?
<3> Well, I guess I can. But it would be great if bitbake could translate CVS+DATE = use CVS package and download this DATE
<3> that way SRCDATE is a general setting but it can be overriden if PREFERRED_VERSION is set
<4> maybe not
<4> duh
<4> SRCDATE_minimo=20050401
<4> like that? :)
<4> distro uses that
<3> it does?
<3> opie,gpe,matchbox availabel also?
<3> what distro uses it?
<4> see for example: /stuff/org.openembedded.dev/conf/distro/preferred-gpe-versions-2.6.inc
<4> i got one randomly :)
<3> goodie, think that will work. Thx
<4> :)
<3> mickey you there?
<2> kristoffer org.oe.dev * rab0d2fe5... /conf/distro/ (preferred-opie-cvs-versions.inc jlime-donkey.conf): (log message trimmed)
<2> distro/preferred-opie-cvs-versions.inc: Addition of new opie cvs file
<2> * Uses SRCDATE_<package> where SRCDATE=Opie_Version. This is used
<2> when version (1.2.1/1.2.2) isnt the best option and a secure
<2> CVSDATE is preferred. Please drop this is theres an
<2> better option, had no luck with using preferred_version.
<2> distro/jlime-donkey.conf: Changes to reflect Opie-cvs package.
<4> Kristoffe: hey, the SRCDATE_* thing worked then?
<3> yeah it did :)
<4> cool!
<5> i am curious since a relativly stale bug is getting so much attention now
<5> when did unstable-CVSDATE become a valid version?
<5> and i promise no more generic closures for stale bugs
<4> emte: maybe it should be put in big letters: we warned you, unstable and CVSDATE is UNSTABLE.
<4> i have to confess I fell into that trap :) I thought like: "nah, they're just kidding"
<4> hehe
<5> thejapa, thats not really relevant in this case
<4> oh, sorry then :)
<5> my comments when i closed the bug were not really right, it was just a generic response to someone using unstable
<5> it was also 3 months old without a reply
<5> i should have given the actual solution and closed it
<5> which was the fact they were using the wrong kernel
<5> but i suppose greif over one out of ~10 clossures isnt too bad
<4> :)
<4> huh, can't you comment on the bug even after it's closed?
<5> yeah
<5> http://bugs.openembedded.org/show_bug.cgi?id=971
<5> is the culprit if your curious
<5> it is rather sad that a bug tagged as seveare as "blocker" was not replied to
<5> anyway bbl
<6> NAiL: ssmtp is your package?
<2> lenehan org.oe.dev * rfc5d933... /packages/man/man_1.5p.bb:
<2> man 1.5p: Disable parallel make or it fails due to trying to link object
<2> files into the final executable before they have completed building.
<2> lenehan org.oe.dev * ra8c0e4e... /packages/conserver/conserver_8.1.2.bb:
<2> conserver 8.1.2: Use EXTRA_OEMAKE to change the install command so that it
<2> does not try and call the host strip command in do_install.
<7> night
<2> lenehan org.oe.dev * rfa8ae021... /packages/conserver/ (conserver.inc conserver_8.1.14.bb conserver_8.1.2.bb): conserver 8.1.14: Add the latest version of conserver.
<2> lenehan org.oe.dev * r7edf4... /packages/conserver/ (conserver.inc conserver_8.1.14.bb conserver_8.1.2.bb):
<2> conserver: Include the example files in the documentation package
<2> instead of leaving them unpackaged.
<2> lenehan org.oe.dev * rfb62df8... /packages/conserver/ (5 files in 2 dirs):
<2> conserver: Add a proper init script for conserver and use a default file to
<2> set the port number so that it does not require an entry in /etc/services to
<2> run.
<2> lenehan org.oe.dev * rb99cad... /packages/quagga/ (4 files):
<2> quagga: Make the default files, which are used for local administrator
<2> settings, as configuration files.
<8> morning
<9> Morning CoreDump|home
<8> hi there hvontres
<2> coredump org.oe.oz354x * rea144b9... /packages/altboot/ (altboot_1.0.6.bb altboot_1.0.7.bb): altboot: Update to 1.0.7 final
<2> coredump org.oe.dev * re89051... /packages/altboot/ (6 files in 3 dirs): altboot: Update to 1.0.7 final
<9> hey, I see you put in a new altboot.. does that work with 2.6 poodle?
<8> yep
<9> ~seen RP
<10> rp is currently on #gpe #oe #openzaurus #handhelds.org, last said: '(when in headset mode)'.
<9> RP: I tried to use the current corgi configutation on poodle. When I try to load the modules, I get this error:
<9> insmod: cannot insert `/lib/modules/2.6.17/kernel/sound/soc/snd-soc-core.ko': Unknown symbol in module (-1): No such file or directory
<9> RP: Am I correct to asume that the machine specific stuff is in corgi.c?
<9> CoreDump|home: neato. I guess its time to do another pull..:)
<8> the -rc series from .dev had poodle support for quite some time now ;)
<9> CoreDump|home: Arrrgh- not the .dev branch...:)
<9> CoreDump|home:It's a shame about the sonund not working... other than that the 2.6 stuff looks great.
<8> indeed
<9> and it looks like we are really close too... half of the alsa module load ok
<9> CoreDump|home:too bad dual booting was kind of a bust... no suspend is a real showstopper..
<8> you mean dualbooting w/ kexec?
<11> spitz+kexec=dual boot with 2.4 kernel :-)
<11> (would even be Sharp ROM-able if you were so inclined)
<12> morning
<9> CoreDump|home: yes. Tried to kexec and then altboot to sd. but it would freeze up on suspend...:(
<12> ~lart sharp for usb host in tosa
<8> hvontres|home: :\
<8> morning hrw
<9> hrw: Morning...not happy with your sharp/tosa :)
<12> CoreDump|home: use 'update-alternative' cl***!
<12> ;D
<8> hrw: I can't for fluxbox
<12> CoreDump|home: altboot?
<8> dunno actually as postinst works fine ;)
<12> CoreDump|home: u-a do the same and I think that it should be used ;)
<12> hrw@bitbake:~/devel/build/3541$ for machine in c7x0 spitz akita;do echo "MACHINE = \"$machine\"" > conf/auto.conf;echo "MACHINE = \"$machine\"";bitbake -cclean gpe-image opie-image bootstrap-image;bitbake gpe-image opie-image bootstrap-image ;done
<12> hmm... will switch it to bbrebuild next time - faster
<12> quote from sig:
<12> catholic god himself invented autotools just for amusement
<12> first there was the great flood, then the plague, now autotools
<13> well - x86 builds seem borked
<13> its nothing to do with my fedora 5 rig
<12> jkp_: ;(
<13> i installed debian in a brand new VM and went from there
<13> and i got the same errors
<13> hrw: its extremely frustrating...if i can just get a working combination for the toolchain!
<13> how can we resolve this issue?
<13> is there a bug tracker for OE?
<12> bugs.openembedded.org
<13> are there more devs than those that hang out in here?
<13> someone already filed it
<13> http://bugs.openembedded.org/show_bug.cgi?id=1000
<13> ]right, i updated the bug, but im wanting to try and help out solving it
<13> is there anyone who might be able to spend some time on it with me later today?
<12> not me - too much work at work
<13> hrw: thanks
<13> ill be back on in a bit, ill shout again and see if anyone else is able
<13> hope im not pestering but this will be for the benefit of all in the end i ghuess
Return to
#oe
or
Go to some related
logs:
#css
#web
#lgp
#qemu
php6+$_get
#perl
gentoo uevents
#lisp
#openzaurus
#web
|
|