| |
| |
| |
|
Page: 1 2 3 4 5 6 7
Comments:
<0> koen: August is Edin festival so its very expensive
<0> koen: June July weather is good normally
<0> koen: not coming to debconf?
<1> re
<2> wb florian_
<3> XorA|sleep: probly not to debconf
<3> XorA|sleep: generic holiday with the gf
<2> cu
<3> NOTE: Running task 678 of 864 (ID: 645, /home/koen/OE/monotone/org.openembedded.dev/packages/coreutils/coreutils-native_5.3.0.bb, do_configure)
<3> RP: nice new progress bar :)
<4> anyone knows an arm/ppc with 4-nics?
<5> zecke: uh, what do you need that for?! i have a ppc with pci and an arm machine too
<6> anyone hae a good reference to oss versus alsa?
<4> florian: oh right, I have a ppc with pci as well :}
<5> i would have add only one ;)
<5> the arm machine suffers from the fact that someone would need to finish the linux port to it first
<4> florian: these folks use a P4 as gateway, I would like to replace it with something else/more light weight (energy wise)
<5> zecke: that's what i use my ppc for :-) its an old motorola powerstack...
<5> and no, it does not run aix ;)
<7> Night
<3> zecke: loft + 2x minipci ethernet?
<4> koen: got a link to the loft site?
<3> http://www.giantshoulderinc.com/
<3> or get one of those ppc NAS thingies
<3> those are getting multiple nics as well
<3> well, multiple ports + hardware vlan tagging
<4> network outage ahead...
<3> koen outage ahead
<4> ibot: test
<8> Test Failed!
<3> 'night all
<4> setting up the net in the new office...
<6> I swear I saw an add for an ARM board with mulitple NIC's somewhere
<5> iirc the Manga machines (ARM) can have quite a lot nics
<4> later, I'm sent home
<9> florian: usb checked?
<5> greentux: not yet, sorry
<10> koen, my lightning talk was accepted
<3> Crofton|home: cool
<10> now I have to invent some slides :)
<10> I think I left i vague enough :)
<10> sounds like I will need to import some of these small power supplies also
<10> picopsu's
<10> Will you be at the "beer event"?
<3> Of course I'll be at the beer event :)
<3> and I'll also be at the way-too-early-breakfast the next day :)
<11> koen org.oe.dev * r48b0e... / (1 conf/distro/angstrom-2007.1-oabi.conf): angstrom-oabi: correct FEED_ARCHs
<3> I hate it when I can't sleep and think of stupid bugs
<3> I hate it even more that I can't remember them in the morning
<12> koen: Hopefully the progress bar will give the users some idea of what bitbake actually does too :)
<3> RP: indeed
<12> koen: Poky just saw a bit of activity :)
<3> cool
<3> I just wished people at ohand would use clearer commit messages: http://www.openembedded.org/bonsai/view/scm/6/
<3> RP: good news poky is now building angstrom-style stuff :)
<12> koen: Since the SCM knows which files you touched, arguably listing the package name is duplicate info...
<3> right
<3> but it makes <scm>2cl a bit useless
<3> grrr
<3> maemo.org is being broken
<13> ***uming a capable 2cl script, you should be able to extract the common path of the files in a given revision and prepend that to the log..
<3> true
<3> we'll figure something out when we start releasing tarball with changelogs :)
<12> koen: Lets hope angstrom style pays off :)
<12> If the autobuilder survives that set of changes, I'll be impressed...
<3> heh: http://www.oesf.org/forums/index.php?showtopic=22707&pid=150486&st=0&#entry150486
<3> MACHINE=foo bitbake bar-image
<13> i'd think itd be handy to convert the scm log to xml, then use xslt to make something sane out of it from there.. svn log --xml is our friend
<3> "sort of"
<3> the ciabot sends xml to cia
<12> kergoth: If not, the monotone devs would probably consider it...
<12> koen: re pdax builder, no comment :)
<13> its nice being able to take the log and easily generate html, rss, gnu changelog, out of it
<3> it always amuses me that opensource tools ***ume you are working on source
<3> and OE breaks all those ***umptions
<3> kergoth: any thoughts on http://mail.gnome.org/archives/gtk-devel-list/2007-January/msg00081.html ?
<12> 'night all
<13> koen: it really doesnt matter what the libtool in gtk is called, since its explicitly generated inside the source tree by configure and is run explicitly via LIBTOOL. it won't be obeying PATH, so whats available in the system is a non-issue, what is an issue, for us, is just ensuring that the correct m4 macros are used. having a prefixed libtool binary in /usr/bin makes perfect sense.. for anything that needs to use the system libtool directly..
<13> in oe, as far as i know, only the jpeg build uses the staging libtool rather than generating its own from the .m4, and thats only because we cant rebuild its configure
<3> so it should use $(LIBTOOL)
<3> since OE generate foo-bar-linux-libtool in ${S}
<13> oe sets LIBTOOL to our prefixed filename in ${S}, and upstream will be setting it to the non-prefixed version.. the buildsystem is safe for both versions of libtool.m4 as long as it uses $(LIBTOOL) in the makefiles.
<3> so http://www.openembedded.org/repo/org.openembedded.dev/packages/gtk+/gtk+-2.10.7/hardcoded_libtool.patch isn't needed
<3> export for building from svn when ./libtool isn't provided
<13> that should probably be ${LIBTOOL} in each place where ./libtool is, so it obeys the var that AC_PROG_LIBTOOL sets
<3> ok
<3> will send the gtk folks a patch with $(LIBTOOL)
<13> ***uming that LIBTOOL was defined before that point, of course
<13> ${LIBTOOL}, not $(LIBTOOL). those spots in configure.in are being run at configure time, not make time, afaict
<3> right
<3> now I'll got to sleep before I start even making less sense
<3> 'night all
<13> hehe
<14> i'm just curious, i've been really fighting with libtool is my own builds lately, i was going through OE but i can't really find what/if anything is changed, any hints on where i can start poking?
<13> look in packages/libtool/.. there are a few patches there that are necessary for crosscompilation with it
<13> mainly it ensures that the 'libdir' read out of .la files (normally paths like /usr/lib) dont end up as -L's on the link line
<14> yep, that's the biggest problem
<14> ld should be looking in $sysroot/usr/lib anyway
<13> i guess its for specific circumstances
<13> say you've got an uninstalled libtool lib (in the source tree, src/.libs)
<13> and it depends upon libs in the installed path (/usr/lib)
<14> well, say you've got for example gnome installed to /opt/gnome
<13> linking against its .la would ensure that the search path for the dependent libs is in the linker search path
<14> iguess it's supposed to help with -L/opt/gnome/lib
<14> but the pkg-config output from the .pc files usualy takes care of that anyway
<13> right, but only for a lib thats uninstalled.. since if it was installed, you'd already have hte -L/opt/gnome/lib to have found its .la in the first place
<13> has to be to find dependent stuff
<13> yeah, it often comes in from other stuff anyway
<13> libtool is a nightmare in general
<13> have you seen jlibtool? seemed worth looking into.. a C reimplementation of libtool
<14> i've been fighting it since i started the sysroot branch in last june
<13> cut build times on apr in half or something
<14> finally got locale generation without needing a emulator anyway
<13> less feature rich than the gnu one of course
<13> heh, i dont envy you
<14> jlibtool? will look
<13> its in the apr source tree, they have a --enable-experimental-libtool configure opt
<13> unfortunately its .la format isnt the same as libtools, so they wouldnt be able to interact on a system, you'd have to use one or the other for the whole machine
<14> i was actualy going to re-write libtool this weekend then i saw you guys talking about it, figured i'd ask
<13> i dont care that jlibtool is C, but it being a reimplementation means it /might/ be more maintainable
<13> having to patch libtool in multiple places due to the duplicate code is bad
<13> heh
<14> that thing is a mess
<13> looked to me like they were afraid to use shell functions for portability reasons
<14> well, i buess they wanted compatibility with ash
<14> s/buess/guess/
<14> either way, multiple scripts would have been a lot cleaner then one repetative one
<13> doesnt SuSv3 have shell functions? probably, they mustve wanted more compatibility than the simple unix specification even
<13> yeah, true
<13> and they had m4, they still couldve removed duplication in the pre-m4'd script via macros
<13> yet there's still duplication, its sad
<14> i didn't even think of that, but that's too true
<13> ah well, enough ranting
<14> later
<15> hrw|gone: :-) glad I reminded you, I still use my C3000 and would very much like Angstrom to be stable on it.
<16> morning
<17> What driver do I need for CF cards?
<17> I thought it would be ide-cs but apparently that doesn't work
<2> morning
<2> DataBeaver: cf connected to aTA controler?
<17> I suppose so?
<2> DataBeaver: then you need ata controler driver
<2> ide-cs is or pcmcia
<2> ide-cs is for pcmcia
<17> I thought the CF slot is more or less like pcmcia?
<2> cf slot yes
<2> but many embedded x86/arm boards use cf memory card connected directly to ATA controler
<17> hmh...
<17> WLAN card in the CF slot works though
Return to
#oe
or
Go to some related
logs:
problem pyhook encoding
wait_for_sysfs error i82365.0
T L E D R E A
update whitelist_clients
unbutu wiki breezy
jaaras
gentoo FreeFontPath: FPE /usr/share/fonts/misc refcount is 2, should be 1; fixin
#mysql
#css
pl2302 linux
|
|