IRC log for #oe on 20090917

00:07.07*** join/#oe xjqian (n=gordon@96-35-202-243.dhcp.stls.mo.charter.com)
00:27.21*** join/#oe mithro (n=tim@unaffiliated/mithro)
00:54.23*** join/#oe scruggs (n=chris@99.195.97.146)
01:20.54*** join/#oe rsalveti (n=rsalveti@189.70.20.221)
01:52.37*** join/#oe emachado (n=edjunior@201.82.64.173)
01:58.16*** join/#oe BenLauDC (n=benlau@221.125.8.105)
01:58.34*** join/#oe HellDragon (i=jd@Wikipedia/HellDragon)
02:01.28*** join/#oe fraxinath (n=quassel@p54AA4BB6.dip.t-dialin.net)
02:02.38*** join/#oe biliquai (n=biliquai@61.6.64.6)
02:40.33*** join/#oe jeaneus (n=orb@pool-173-71-43-116.dllstx.fios.verizon.net)
02:50.07*** join/#oe mekius (n=mekius@enlightenment/developer/mekius)
02:54.45m4tso i ran into a known bug with newer versions of findutils
02:54.56m4tand the recommended fix was to add 'gl_cv_func_wcwidth_works=yes' to config.site
02:55.01m4tis there another way to do this?
02:57.09m4teg. a configure.ac patch?
02:58.21m4toh gnulib/m4/wcwidth.m4 has it
03:05.30m4tmy patch fixes
03:05.31m4t-      *no) REPLACE_WCWIDTH=1 ;;
03:05.31m4t+      *no) ;;
03:05.33m4t:-)
03:11.49*** join/#oe ctusar (n=ctusar@c-71-58-119-148.hsd1.pa.comcast.net)
03:17.53kergothm4t OE's site/* files are used to provide defaults for autoconf tests in a consistent fashion.
03:18.00*** join/#oe Laibsch1 (n=Laibsch@p5B3B17E9.dip.t-dialin.net)
03:22.28m4tkergoth thanks
03:34.04*** join/#oe mrc3 (n=ddiaz@189.157.107.237)
04:13.13CIA-103Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r43690fb819 10openembedded.git/conf/distro/include/preferred-xorg-versions-X11R7.4.inc:
04:13.13CIA-1preferred-xorg-versions-X11R7.4.inc: Lock PREFERRED_VERSION_dri2proto ?= "1.1"
04:13.13CIA-1* With dri2proto 2.0 recipe being added now it gets picked up
04:13.13CIA-1this recipes needs newer version of xorg-utils so we tie down
04:13.13CIA-1the version of dri2proto to 1.1
04:13.17CIA-1Signed-off-by: Khem Raj <raj.khem@gmail.com>
04:13.19CIA-103Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * rf43c3adb4b 10openembedded.git/recipes/ (22 files in 2 dirs): (log message trimmed)
04:13.22CIA-1glib-2.0-native_2.21.4.bb: New recipe for native glib 2.21.4
04:13.25CIA-1* Build shared library instead of static.
04:13.26CIA-1* with libint.a the link order matters and generally for uclibc
04:13.28CIA-1targets we append -lintl to LDFLAGS and sometime it gets specified
04:13.30CIA-1before the objects and symbols do not get pulled in. Better we
04:13.32CIA-1generate shared object so the linking order does not matter
04:13.34CIA-103Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * r249fc51167 10openembedded.git/recipes/clutter/clutter.inc:
04:13.37CIA-1clutter.inc: Add omap5912osk to COMPATIBLE_MACHINE
04:13.39CIA-1Signed-off-by: Khem Raj <raj.khem@gmail.com>
04:13.43CIA-103Khem Raj <raj.khem@gmail.com> 07org.openembedded.dev * rcb86af0943 10openembedded.git/recipes/proxy-libintl/ (2 files in 2 dirs):
04:13.48CIA-1proxy-libintl-20080418: Add the patch to compile as shared library
04:13.51CIA-1* Keep generating .a file.
04:13.52CIA-1Signed-off-by: Khem Raj <raj.khem@gmail.com>
04:16.13*** join/#oe kozak (n=kozak@122.166.48.72)
04:19.27czr_good mornink
04:42.39khemczr_: good morning
04:43.03czr_hey khem
04:43.21czr_is waiting for coffee to get a spurt of energe to do some kernel slicing and dicing
04:56.03khemczr_: which part of world are you in
04:56.16czr_khem, finland. you?
04:56.24khemI am in US
04:56.41czr_thought so (explains the timing of the commits :-)
04:57.22khemDo you work for nokia :)
04:57.43czr_heh. not everybody here works for nokia :-). no. I have worked on couple of projects for them though (maemo-related)
04:58.08khemI read somewhere that they are largest employer there
04:58.34czr_well, we don't have so many large companies to start with :-). so it's not difficult :-)
04:59.08khemczr_: maemo stuff in OE seems to be stale
04:59.12czr_http://www.uranus.fi/en/jobseekers/jobs/open.php?id=19982 that's a good list of top 100 companies in finland and their industries
04:59.29czr_probably so yes. although don't look at me, I haven't touched maemo for couple of years now :-)
04:59.47khemI regret that I never made to scandinavia when I lived in germany
05:00.53czr_I should travel more as well. Although I visited the states a month ago or so
05:01.42*** join/#oe tio (i=c0a314e7@gateway/web/freenode/x-dwlfxzlbjhsbclyf)
05:01.45tiohello
05:01.47tiogood morning
05:01.59tioi wanted to ask how to change the kernel version i'm using
05:02.27khemczr_: which city were you in here
05:02.36khemtio: which machine ?
05:03.00tiolinux
05:03.10czr_khem, we (me and gf) were staying near Savannah (GA) where my mother lives, we also travelled around there and went to orlando for couple of days.
05:03.29khemnice
05:03.38khemtio: did I ask OS ?
05:03.46czr_it wasn't bad. hot but nice (compared to finland anything is hot :-)
05:04.35czr_khem, where in the us are you?
05:04.41khemCA
05:04.59czr_ah. never visited that part :-)
05:05.07tioasking the board i'm working @ khem
05:05.21khemyes
05:05.36tiobeagleboard
05:06.05khemtio: which version is it compiling now
05:06.23tio2.6.29
05:06.29tioi want to use 2.6.24
05:06.47tiobecause i want to use csl-2008q3
05:08.36tiowith it
05:10.13khemtio: remove DEFAULT_PREFERENCE_beagleboard = "1" from linux-omap_2.6.29.bb
05:11.44khemI doubt .24 will be any good on beagle
05:12.36tiowill there be some problem?
05:12.45tiousing .24 on beagle
05:13.33khembeagle is newer than .24
05:13.43tiook
05:13.57tio.26 will work then?
05:14.07khemno idea
05:14.18czr_tio, why do you insist using older kernels?
05:14.21tiook
05:14.23czr_+on
05:14.40tioactually for the newer version i have to chnage the toolchain
05:14.51tioi want to use csl-2008q3 only
05:14.55grgi wouldn't use anything older than .28 on a beagleboard. The most recent omap linux tree is best
05:15.01*** join/#oe rob_w (n=bob@p549BDEBB.dip.t-dialin.net)
05:15.10czr_tio, build the kernel with a different toolchain than you use for other stuff?
05:15.33czr_although I have no idea how to tell oe to do that, but I'm sure it's possible.
05:15.43tiook
05:23.16*** join/#oe tasslehoff (n=Mich@120.80-203-104.nextgentel.com)
05:35.50*** join/#oe rob_w_ (n=bill@p549BDEBB.dip.t-dialin.net)
05:36.56rob_w_IMAGE_FSTYPES = "jffs2 tar.bz2" i ve but it doesnt create the tar one .. any hints ?
05:47.35*** join/#oe de_manuel_pi (n=cryolab2@rob.rz.htw-dresden.de)
05:47.42khemrob_w_: use MAGE_FSTYPES = "jffs2 tar"
05:48.10*** part/#oe de_manuel_pi (n=cryolab2@rob.rz.htw-dresden.de)
05:48.30rob_w_tryed that before .. (if you meant IMAGE_FSTYPES)
05:50.45czr_hmph. kernel works but fails to run init from nfsroot.
05:53.19khemrob_w_: it works here
05:53.44khemczr_: did you forget to enable NFS in kernel
05:53.57czr_khem, no. it mounts nfs root :-).
05:54.11khemok then whats the error
05:54.31khemrob_w_: which machine/distro
05:55.00czr_khem, http://pastebin.com/m3a41da36 I'm thinking it's something to do with library versions or something, but it's weird. the same rootnfs works with vendor kernel.
05:55.04rob_w_ppc440e-angstrom-linux/
05:55.54czr_I'll dump some traffic on nfs-server side to see what's happening, don't worry too much :-)
05:56.37m4trob_w_ just curious, what kind of ppc440e board is it? vendor/model?
05:56.39czr_btw, is cliff barke around on irc?
05:57.34rob_w_m4t, its a custom board , vendor can be found under elotec-systems.eu
05:58.03khemczr_: enable DEBUG_USER
05:58.23czr_khem, yeah, will do that after I check out what happens on nfs server :-)
05:58.35khemczr: he is but right now its 2 am where he lives :)
05:59.13m4trob_w_ interesting, thanks
05:59.16czr_ah, what's his nick?
05:59.34rob_w_m4t, if you are interested in it ,, feel free to get back to me
05:59.53czr_khem, btw if you're not too busy, would you mind checking out the sane-toolchain.inc-patch that I sent on the oe-list yesterday? it's a trivial small thingy
06:00.02rob_w_m4t, they use eldk for the development but i want it tobe oe !
06:00.17khemczr_: Its in already
06:00.24czr_ah, cool. thanks.
06:00.27khemthanks for it
06:00.51rob_w_am rebuilding now the image with only tar .. lets see what happens
06:00.55czr_np
06:02.03khemrob_w_: which machine conf file are you using
06:02.12khemi,e NACHINE=?
06:03.04khemcanyonlands or sequoia
06:03.10*** join/#oe rob_w (n=bill@p549BCCDF.dip.t-dialin.net)
06:03.12m4they khem, http://pastebin.com/d43431ce9, those are some of the packages i added or updated
06:04.30khemsend the patch m4t to the list if you would like to contribute the changes here
06:04.39m4tyup
06:04.49m4ti will aim for this weekend
06:05.01m4ti need to clean up some tarballs etc. from various recipes/ dirs
06:05.12m4tthere are some i couldnt get, too, that arent on there
06:05.19khemcool I will  be happy to review them
06:05.21m4ti was going for grep, gzip, bzip2, gnupg, ...
06:05.40m4tbut i decided to just use busybox builtins for compression, and i guess gnupg is 'fine' where it is for now
06:05.44khemrob_w_: I think I see your problem
06:06.26khemadd this to your local.conf IMAGE_FSTYPES_local = "jffs2 tar"
06:07.02khemactual override wont work because machine confs say IMAGE_FSTYPES = "jffs2"
06:07.08m4tgnupg 1.4.10 and perl 5.10 would be great
06:07.24khemhmmm m4t yeah busybox is handu
06:07.28khemhandy
06:08.30m4tthere are a couple security fixes for udev 1.24, irssi, postfix 2.2.x, and a few others
06:08.43m4toh and lynx
06:09.03khemthats nice
06:10.36m4tyea
06:11.26khemm4t: are you in Germany ?
06:11.27m4tsome of the new versions have fixed dependencies and oe_conf_extra per kergoth's missingdeps.bbclass
06:11.33m4tnope, us
06:11.52khemcool which city
06:13.19kergothm4t: it's working for you?  note that it's not perfect, because some libtool/pkg-config crap can pull in indirect deps.  so if your app links against libfoo, and libfoo links against libbar, some crappy setups will result in the app linking against both foo and bar, so the dep checker would report both.  hard to avoid that, though, short of patching libtool and the pkg-config scripts, or using -Wl,--as-needed everywhere
06:14.05khemkergoth: I think as-needed is better way to go
06:14.18khemand we can blacklist packages along the way which dont behave
06:14.19m4ti am down south
06:14.25kergothi agree, but sadly it's not that easy, because the argument only affects libs after it on the commandline
06:14.33kergothand not all buildsystems put LDFLAGS before thel ibs
06:14.51kergothso it wont always be used everywhere
06:15.11khemkergoth: we can force gcc to emit it properly for linking
06:15.12czr_hmmm. khem, nfs side seems ok (I see uclibc loaded (0.9.28 = vendor version)), but I get unimplemented system call: http://pastebin.com/m1491fa7d
06:15.22kergothkhem: by default, missingdeps.bbclass disables itself when you aren't using --as-needed.  i had m4t enable it forcibly for his testing
06:15.29czr_I think I've disabled 16-bit compatibility syscalls from the kernel embedded optimizations, so I'll try to enable them now
06:15.46kergothkhem: well, arguably the behavior where it only affects following libs is good, because there are cases where you might want to force inclusion of a lib, and not let it leave it out..
06:15.57kergothshrugs
06:16.45kergothhttp://gist.github.com/187895 is the class, for the curious
06:16.54*** join/#oe eFfeM (n=frans@j192117.upc-j.chello.nl)
06:18.02*** join/#oe sgh (n=quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk)
06:18.14khemkergoth: then they might use -Wl.--no-as-needed <lib> --Wl, --as-needed
06:18.37kergoththat's true, so you're thinking just change the default.. that's a good idea
06:18.38khembut we have to take a stance if we want to use as-needed
06:18.47khemyes
06:19.05kergothi can't see any reason why not.  there's no reason an app should have to care about what its libs are using
06:19.26khemexactly
06:19.53kergothunless you're on solaris or something, in which case good luck...
06:19.56kergoth:)
06:20.09khemslowaris is dead elephant
06:20.17kergoththankfully
06:20.34kergothwell, to be fair, it was pretty nice on sparcs, but holy crap did it suck on x86
06:20.38czr_starts looking for the ivories
06:21.19khemkergoth: truly I liked alpha better when it comes to that age
06:21.26kergothnods
06:21.41kergothdidn't those usually run digital unix?
06:21.46khemthey did
06:21.55khemand also there was some lnx ports
06:22.06kergothused to have to do tech support for all these unix variants when he worked at digi.... those serial port cards with 300+ ports for dumb terminals, pre-ethernet
06:22.18kergoth12 yera old openserver boxes and shit..
06:22.20kergothshudders
06:22.26khemheh
06:22.30*** join/#oe ArteK (n=Artur@81.15.241.96)
06:23.12czr_I met a guy from the largest finnish online banner company. He said that they were stuck with linux on alphas because nothing else could handle the traffic
06:23.29czr_however, after a while I learned that they learned stock apache, so that explains the load pretty much ;-)
06:23.47czr_they used even.
06:23.53khemremembering past I thought SGI boxes running IRIX were cool
06:24.03khemout of my sheer love for mips
06:24.24kergothhehe
06:25.12khemIRIX has so many enhancements that even today linux lacks
06:25.25czr_so does windows.
06:25.27czr_hides & runs
06:26.11khemwindows is nice for multimedia what I think today
06:26.38czr_I haven't used windows for ages. primarily I mean. it just feels wrong.
06:26.53czr_it only takes 20 seconds on the windows "command line" to get me mad.
06:27.54czr_hmm. is there an easy way to test whether a binary or .so is pre-EABI or EABI?
06:28.04czr_hmm. file should know, right?
06:28.06khemoh well I try to get OE build working on my Macbook Pro these days
06:28.35khemczr_: you could dump the ELF headers
06:28.50czr_I'd need a cross readelf for that though.
06:28.50khemwith readelf -e or somesuch
06:28.57czr_nods
06:29.11khemyes or you can build one for target and install it
06:29.18czr_the embedded options didn't make the problem go away, so I'm thinking that I'm actually trying to run pre-eabi stuff on the kernel.
06:29.29czr_well, the target is still running vendor nfsroot.
06:29.34czr_I'd rather not touch that quite yet
06:29.43khemczr_: enable OABI in kernel
06:29.55czr_yes :-)
06:30.20khemI think that could be a problem
06:30.37khemwhat version of vendor kernel do they have on box
06:30.42czr_2.6.26.6
06:30.51czr_same one that I'm building since the vendor patches are against that.
06:31.03czr_I might try to forward port the patches later, but that's not a priority right now
06:31.04khemhmm then I doubt it is OABI nfsroot but anything is possible
06:31.35khemcan you put libuClibc.so binary from vendor rfs somewhere
06:31.42khemI can inspect it
06:31.58czr_yup. enabling oabi didn't help.
06:32.05czr_give me a sec.
06:32.08*** join/#oe tsjsieb (n=tsjsieb@dejongbeheer.nl)
06:32.21khemhow about enabling THUMB
06:32.28czr_that's already done ages ago
06:32.41czr_did you see the pastebin with user_debug enabled?
06:32.51czr_http://pastebin.com/m1491fa7d this one.
06:34.07czr_http://koltsoff.com/pub/4khem/
06:34.14czr_that has uclibc and busybox
06:34.19czr_(vendor nfsroot versions)
06:34.44*** part/#oe tio (i=c0a314e7@gateway/web/freenode/x-dwlfxzlbjhsbclyf)
06:35.14*** join/#oe mayhem (i=c0a314e7@gateway/web/freenode/x-bbghxgcgknopmshs)
06:35.29czr_hmm. it's eabi (readelf -e says so).
06:35.36mayhemi'm getting this error when i'm trying to build
06:35.37mayhemPlease set a valid MACHINE in your local.conf
06:35.47mayhemthough i have set omap-3430sdp
06:35.52mayhemin my conf file
06:36.13czr_mayhem, did you check that there's a proper conf for that machine under conf/machine/ ?
06:36.18czr_(under openembedded/)
06:37.04mayhemi'll just check it
06:41.19*** join/#oe jin (i=4c5ee787@gateway/web/freenode/x-jrbpkdpqunlcgntf)
06:41.22mayhemwhat regarding this error
06:41.23jinhello
06:41.24mayhemError, Your PACKAGE_ARCHS field contains duplicates. Perhaps you set PACKAGE_EXTRA_ARCHS twice accidently through some tune file?
06:41.50jini just did bitbake nano & copy it to SD card
06:42.11jinAnd booting from beagleboard and opkg install ~~.ipk
06:42.28jinthen i got package nano md5sum mismatch
06:42.42jini got error message
06:42.53jini did opkg update
06:42.59jinand opkg upgrade
06:43.08jinbut it does not working
06:43.31jinanyone know this issue?
06:43.33*** join/#oe de_manuel_pi (n=cryolab2@rob.rz.htw-dresden.de)
06:43.52khemjin: you need to run some image build
06:44.01mayhemError, Your PACKAGE_ARCHS field contains duplicates. Perhaps you set PACKAGE_EXTRA_ARCHS twice accidently through some tune file?
06:44.07mayhemwhat about this error
06:44.22khemmayhem: which machine/distro
06:44.36khemczr_: you seem to be dying in mmap
06:44.37mayhemomap-3430sdp
06:44.44mayhemdistro
06:44.46mayhemtilinux
06:44.54czr_khem, cool :-)
06:45.01khemI dont see such a machine omap-3430sdp
06:45.09khemin distro/machines
06:45.17czr_what I did now was I built a small hello world (static) with the cross gcc, then copied that as /sbin/init, and it runs ok.
06:45.25czr_so I'll just ignore the vendor rootfs for now
06:45.41mayhemit is khem
06:46.00czr_unless you have some ideas how to get it to work easily. google isn't finding anything useful for me.
06:46.11khemmayhem: which branch are you on
06:46.14jini'm sorry but i don't understand "run some image build"
06:46.29jinnow i using beagleboard & angstrom
06:46.39mayhemwhat do ypu mean by branch @ khem
06:46.43mayhemyou*
06:48.52pb____czr_: the error in that pastebin you posted is indeed what you'd get trying to run oabi binaries on an eabi kernel. ef90005a is sys_mmap in oabi, but that instruction should never appear in an eabi binary.
06:49.31czr_hmm. weird. but my kernel has oabi now.
06:49.41czr_and the error doesn't go away. and readelf says that uclibc.so is eabi.
06:49.47khemmayhem: you need to run package_update_index_ipk task
06:50.20czr_pb____, don't worry about it though. I'm replacing the vendor rootnfs with something that OE builds.
06:50.27khemhi pb____
06:50.35czr_what's the easiest/smallest tar-based image I can build with micro?
06:50.52pb____micro-base-image
06:51.16czr_thanks.
06:51.39khemjin: you need to run package_update_index_ipk task
06:51.59khemmayhem: I mean OE branch
06:52.25pb____czr: the file sizes I get for that are:
06:52.27pb____-rw-r--r-- 1 pb pb 671528 2009-09-16 15:05 micro-micro-base-image-uclibc-ipk-20090916-nslu2be.rootfs.tar.gz
06:52.43pb____-rw-r--r-- 1 pb pb  6881039 2009-09-16 15:36 micro-micro-base-image-eglibc-ipk-20090916-nslu2be.rootfs.tar.gz
06:52.43czr_pb____, uclibc?
06:52.50czr_ah yes. /me be bling.
06:52.54czr_blind even. and bad typist.
06:53.10czr_ugh, the eglibc is huge :-)
06:53.18pb____the eglibc build does seem a bit massive, I don't know what's going on there.
06:53.28czr_I guess it is including everything.
06:53.36pb____personally I am only using the uclibc one at the moment so I am not too bothered :-}
06:53.38czr_so it's more or less same as glibc I guess.
06:53.42czr_nods
06:53.47czr_I'm building an eglibc one right now
06:53.58pb____even for plain glibc that file size seems a bit excessive.
06:54.41pb____oh, crazy eglibc, it's shipping all the timezone data in libc6.ipk
06:54.53pb____and ldconfig, even though that's meant to be disabled for miro
06:54.55pb____micro
06:54.55czr_it wants to take over the world.
06:55.15khemjin: you can do bitbake package-index
06:55.22jinoh
06:55.25jinok
06:55.36jinthanks now i try
06:55.40pb____I think the eglibc packaging must just be busted.  you might be better off with plain glibc at the moment.
06:56.06czr_well, I'll figure it out as I go.
06:56.07khempb____: hmmm thats prolly wrong I remember someone adding it
06:56.29pb____khem: adding what?  the timezone data?
06:56.34khemyeah
06:56.43khemit should be a separate package
06:57.17mayhemkhem: should run this task first package_update_index_ipk??
06:58.25*** join/#oe Longfield (n=valentin@lsa1pc7.epfl.ch)
06:58.32czr_hmm. does timezone stuff go into eglibc-localedata-x-y?
06:58.47pb____no, that's for the locale data (!)
06:58.54czr_hmm. right. :-)
06:58.55*** join/#oe grma (n=gruberm@chello212186029093.tirol.surfer.at)
06:59.00pb____timezones are separate :-}
06:59.11pb____it does look like both eglibc and glibc just stuff them into libc6.ipk at the moment, actually
06:59.21pb____I guess the glibc packaging needs a bit of reworking for micro
06:59.33pb____99% of the contents of libc6.ipk is erroneous and should not be there.
06:59.44czr_ah. libc6_2.10-r6.1_armv5te.ipk = 2208578 bytes
07:00.24jinkhem: i did bitbake package-index and got Packages, Packages.filelist, packages.gz, Packages.stamps in /oe/tmp/deploy/glibc/ipk folder
07:00.43pb____right, that's almost exactly the size that I get
07:01.14jinkhem: i just installed OE and try bitbake nano
07:01.27jinit did well with no error
07:01.30khempb____: I plan to look at eglibc packaging in coming days
07:01.52khemwhen I will also add cross locale generation capability
07:01.54jinkhem: what else i have to do?
07:02.00czr_yeah, all of the timezone stuff is included here as well.
07:02.00pb____the ldconfig thing is just wrong in eglibc-package.inc.  I guess you could copy the right bits from glibc-package, which should save 500k or so before compression.
07:02.13pb____then there's the timezone thing, and a load of extraneous libs.
07:02.14*** join/#oe rob_w_ (n=bill@p549BF3A4.dip.t-dialin.net)
07:02.33czr_also, I find some weird progs, under libexec: POSIX_V6_ILP32_OFF32 and 5 other similar progs
07:02.50czr_although I guess it's only one executable and linked with multiple names
07:03.10czr_anyhow, I guess I can still use this for testing, so it's not a biggie.
07:03.13czr_thanks all :-0
07:04.32khempb____: ok the USE_LDCONFIG stuff
07:05.32pb____right
07:05.49khemmay be it could be a separake ipk
07:07.24*** join/#oe thebohemian (n=rschus@p5DDC76E1.dip.t-dialin.net)
07:09.44pb____yes, that would be ok
07:09.56pb____nobody seems particularly keen to have that feature but it certainly wouldn't hurt anything.
07:10.12jinkhem: do i have to copy package* to SD card with nano_2.0~.ipk?
07:16.15czr_hmm. should micro have a getty or something?
07:16.35czr_http://pastebin.com/m63944b71
07:16.47czr_that's it. no login nothing.
07:19.28*** join/#oe fpga (n=s@92.62.56.51)
07:22.32*** join/#oe Pr0t0N (n=lcintrat@93.2.234.140)
07:23.24czr_ah. my /dev/ is almost empty. weird.
07:23.37czr_so no tty devices on which to start getty.
07:27.43*** join/#oe cyberdeck (n=cyberdec@iss66.vlsi.informatik.tu-darmstadt.de)
07:27.59pb____it's meant to be populated at runtime by mdev, I think
07:28.12pb____not sure offhand whether the standard micro-base-image includes a getty.  quite likely not since many devices are headless.
07:28.22*** join/#oe Christos_N|Work (n=chatzill@gw7.mycosmos.gr)
07:29.33pb____ah yes, it should be running getty on ttyS0
07:30.31pb____looking at your pastebin output, it never seems to be getting to runlevel 5 for some reason.
07:31.21czr_yes. but well. there's no ttyS0 (there's ttyNS0 in theory, but /dev/ contains this: http://pastebin.com/m6d9d5b9d )
07:31.49czr_it runs all of the rcS stuff, but I guess that getty starts at that point and something confuses someone since I get no output after that
07:32.18czr_if I remove the sleep from S50debug.sh, then the output will be cut as well. so someone is trying to do something, but seeing as /dev/ isn't populated properly.. nothing will work.
07:32.54khemczr_: I think you are hitting the mmap bug in uclibc 0.9.28
07:33.06khemhttp://lists.uclibc.org/pipermail/uclibc/2007-March/038326.html
07:33.12czr_khem, you mean the vendor rootnfs?
07:33.21khemczr_: yes
07:33.26czr_cool. thanks a lot.
07:33.41khemand they might have wired NR_mmap in their kernel to get around the issue
07:34.40czr_hmm. that would also mean that the kernel that they ship in binary form is not the same that I'm getting with 2.6.26.6. and their patches. how shocking..
07:34.55czr_nokia used to do that all the time with maemo-devices.
07:35.34czr_khem, I gave up on the vendor rootnfs though. using micro-base now. but having some issues (as you might have noticed above)
07:36.18khemczr_: I generally use console-image
07:36.25khemworks well for me
07:36.31czr_is it much larger?
07:36.36khemsort of
07:36.50czr_I'll start building it. will report later. thanks
07:36.54khem4Mb rfs IIRC
07:36.55pb____khem: how would the lack of that uclibc patch cause the "obsolete syscall" diagnostic?  I can't immediately think why that could be related.
07:37.18khembur takes quite a while to compile because bluez pulls in all sort of crap
07:37.39czr_ah. and I see that there's stuff coming from xorg as well
07:37.45czr_and gtk..
07:37.47czr_oh my.
07:38.03khempb____: uclibc precompiled code is calling the old mmap syscall but czr_ 's new kernel does not have the call
07:38.09pb____khem: right, but that would not cause this error
07:38.11khemthats my guess
07:39.01czr_btw, what's OE's stance on adding new machines with kernel patches which are GPLv2 but the vendor is not actively pushing them into vanilla?
07:39.03czr_(or even arm)
07:39.13czr_because that's what I'm working with atm.
07:39.23pb____simply calling a syscall which isn't implemented would not elicit that message; it means specifically that you have a calling standard mismatch.
07:40.38khempb____: yes I think old mmap was left OABI in kernel
07:41.01pb____old_mmap is only implemented for oabi, yes.
07:41.24pb____but, my point is that calling sys_old_mmap would not cause the error message in question.
07:41.28khemin uclibc with EABI the call passed the sysnum in r7
07:41.49CIA-103Steve Sakoman <steve@sakoman.com> 07stable/2009 * rbdf9269286 10openembedded.git/recipes/ebtables/ebtables_2.0.6.bb:
07:41.49CIA-1ebtables: fix GNU_HASH error
07:41.49CIA-1Signed-off-by: Koen Kooi <koen@openembedded.org>
07:41.49CIA-1Acked-by: Denys Dmytriyenko <denis@denix.org>
07:43.54khemhmmm looking at czr_ s uclibc it seems its OABI
07:44.15khembecause all syscalls are passing the syscall number as argument to swi
07:44.33czr_hmm. but I have oabi support in kernel..
07:44.39czr_plus, readelf says it's eabi.
07:45.15czr_anyhow guys, don't spend any time on it :-).
07:46.00*** join/#oe ZaPPaS (n=moritz@buero2.pi5.physik.uni-stuttgart.de)
07:46.30khemczr_: your uclibc is OABI Flags:                             0x202, has entry point, GNU EABI, software FP
07:48.56czr_hmm. 0x202 = oabi?
07:49.02khemczr_: for EABI it has to have flags |= (EABI_VER << 28)
07:49.07khemyes
07:49.18czr_ah. I see. I was just looking at the "GNU EABI".
07:49.28khemyes
07:49.45khemso You need to have full OABI support in kernel
07:49.55khemor even compile the kernel with oabi
07:50.02khemtoolchain
07:50.34khembut better use all pieces from OE you will feel better
07:50.35czr_ah. I don't care about oabi actually that much. I built with EABI and enabled OABI support but I guess that's not quite enough.
07:50.38khembecause it will work
07:50.40czr_yeah. OE <3.
07:50.59khemanyway time to sleep here
07:51.03khemgood night
07:51.07czr_night, thanks a bunch
07:55.25*** join/#oe aloril (n=aloril@dsl-tkubrasgw3-fe7ef900-153.dhcp.inet.fi)
08:02.49*** join/#oe rob_w (n=bill@p549BF3A4.dip.t-dialin.net)
08:04.13*** join/#oe pvanhoof (n=pvanhoof@84.192.192.186)
08:06.59*** join/#oe dth (n=Dieter@p4FDEB586.dip.t-dialin.net)
08:26.05*** join/#oe kristoffer (n=kristoff@95.209.172.44)
08:34.27*** join/#oe ant_work (n=andrea@host214-85-static.34-85-b.business.telecomitalia.it)
08:36.23*** join/#oe florian_kc (n=fuchs@port-217-146-132-69.static.qsc.de)
08:36.41pb____florian_kc: good morning!
08:37.13floriangood morning
08:38.08ant_workdenix: ping
08:38.22ant_work(morning channel btw :)
08:38.30florianhi ant_work
08:38.53dthgood morning , florian
08:39.07floriandth: hi
08:41.02pb____florian: do you plan to attend the oedem in november?  I am just trying to count up the final numbers.
08:41.37florianpb____: oh... yes I do. Forgot to answer your mail again :-}
08:42.58pb____florian: righto, excellent.  thanks.
08:43.53CIA-103Brijesh Singh <bksingh@ti.com> 07org.openembedded.dev * r05a753b24b 10openembedded.git/recipes/gstreamer/gst-player_svn.bb: gst-player: add recipe for a simple gstreamer player
08:43.54CIA-103Brijesh Singh <bksingh@ti.com> 07org.openembedded.dev * r33e67dff77 10openembedded.git/recipes/ti/ (2 files in 2 dirs):
08:43.54CIA-1gstreamer-ti: remove mp3 cap from gst_ti auddec1 element.
08:43.54CIA-1* Default TSPA codec does not have mp3 decoder and this patch removes the mp3 decoder caps from auddec1 element. This will help playbin on auto-detecting mp3 decoder when dsp decoder is not available.
08:43.57CIA-103Brijesh Singh <bksingh@ti.com> 07org.openembedded.dev * rcac885572c 10openembedded.git/recipes/ti/ (2 files in 2 dirs): gstreamer-ti: import omapfbsink in gst_ti and add support for hw accelerated framecopy based on dmai transport buffers. The new element is registered as "omapdmaifbsink"
08:44.01CIA-103Brijesh Singh <bksingh@ti.com> 07org.openembedded.dev * r0624cfcd88 10openembedded.git/ (conf/checksums.ini recipes/ti/ti-cs1-omap3530_1.0.1.bb): ti-cs1-omap35330: update SR_URI
08:44.11florianpb____: yw
08:47.56mike_cwis it possible to make changes to source code in tmp/work/* then re-bitbake that package without wiping those changes out?
08:48.29pb____with care, yes.  try "bitbake -f -c compile"
08:48.45mckoanpb____: would be possible to have more details on OEDEM ?
08:50.35mike_cwpb____: thx. looks like that worked
08:52.59*** join/#oe noglitch (n=Miranda@mail.atmel.fr)
09:04.16*** join/#oe Gnutoo (n=gnutoo@host98-153-dynamic.51-79-r.retail.telecomitalia.it)
09:09.22*** join/#oe user2 (n=3MX@87-205-136-142.adsl.inetia.pl)
09:10.48*** join/#oe dth (n=Dieter@p4FDEF3CA.dip.t-dialin.net)
09:13.08*** join/#oe lrg (n=lrg@host81-136-218-57.in-addr.btopenworld.com)
09:14.59*** join/#oe thaytan (n=jan@192.18.8.1)
09:29.21*** join/#oe ispcb (i=5f984970@gateway/web/freenode/x-nwndqqxywzwbekpo)
09:30.42ispcbtest
09:32.19ispcbahem... first time here. Can I ask a question?
09:33.42tasslehoffispcb: I'm also new, but I'm pretty sure you can just ask without asking to ask :)
09:34.25rob_wso if i ve a PREFERRED_VERSION in a machine conf but the build pulls even  a lower version , something has overwritten my config  ?
09:34.57mckoanispcb: ~ask
09:35.01ispcbok. the question may be simple ... I am doing "bitbake -b zip_2.32.bb" which needs (like many other receipes) sha256sum
09:35.20ispcbthe problem is sha25sum is not available
09:35.31ispcband I have to do bitbake -b shasum before
09:35.34ispcbby hand
09:35.39ispcbis it normal?
09:36.04rob_wispcb: bitbake zip will build you the latest zip with all your dependancy's
09:38.05XorAispcb: never use bitbake -b
09:38.14ispcbok ?
09:38.16ispcb..
09:38.23XorAispcb: it is for experts only
09:39.01XorAbitbake <provider> what non experts should be doing
09:39.46ispcbanother way to ask the same question: When doing "bitbake zip_2.32.bb" shouldn't the sha256sum be build before (as a dependency) ?
09:40.33ispcbXorA : thanks for the advice!
09:40.35XorAispcb: bitbake zip is the correct form of that command
09:40.57XorAispcb: or bitbake zip-2.32 if you need to use a non default version
09:41.08ispcbok I got that but I have the sha256sum problem with any other receipe that uses sha256sum
09:41.14XorAispcb: and that will build sha256sum
09:41.22ispcbok
09:41.27ispcbI will give it a try
09:41.34XorAispcb: all dependencies in the tree are built before the target
09:41.43ispcbthat's what I tought
09:41.51XorA-b breaks that
09:42.12ispcbthan that should be it ... I followed closely the documentation from OE :)
09:43.10ispcbXorA : no further questions. Thanks again for your time!
09:44.30XorAispcb: no problem, the more happy users the better for me
09:47.55*** join/#oe xranby (n=user@labb.zafena.se)
09:47.59rob_wXorA, what was the command to show the depency list of a specific target ?
09:48.39XorArob_w: bitbake -g
09:50.48CIA-103Xerxes RÃ¥nby <xerxes@zafena.se> 07org.openembedded.dev * r718a561ceb 10openembedded.git/recipes/llvm/ (3 files in 2 dirs):
09:50.48CIA-1llvm 2.7: New recipe.
09:50.48CIA-1llvm-native 2.7: Likewise.
09:57.12*** join/#oe Gnutoo (n=gnutoo@host98-153-dynamic.51-79-r.retail.telecomitalia.it)
10:13.57rob_wNOTE: checking PREFERRED_PROVIDER_glibc-2.6.1
10:13.57rob_wNOTE: checking PREFERRED_PROVIDER_glibc-2.6.1-r35.0
10:13.57rob_wNOTE: selecting glibc to satisfy runtime libsegfault due to PREFERRED_PROVIDER_virtual/libc = glibc
10:14.14rob_wwhat does my beloved bitbake telling me with this ?
10:14.52pb__rob_w: it's just conversational, you can almost certainly ignore it.
10:16.03rob_wsatifying a runtime libsegfault . sounds horrible
10:16.15florian:-)
10:19.32rob_wbut thanks pb__ for the clarification
10:20.00pb__what it actually means is that bitbake has encountered something which RDEPENDS on libsegfault, and it has decided to build glibc in order to obtain libsegfault because that's what you have selected as your preferred provider for glibc.
10:21.09rob_wso is that the initial depend which pulls in glibc as such ?
10:28.03pb__no, the dependency on libsegfault must be coming from some kind of debug tool package
10:28.14rob_wok
10:37.29*** join/#oe jkridner|work1 (n=a0321898@nat/ti/x-tvffbcticogvjenv)
10:54.54*** part/#oe ArteK (n=Artur@81.15.241.96)
11:00.55*** join/#oe tsjsieb_ (n=tsjsieb@dejongbeheer.nl)
11:07.04*** join/#oe fpga (n=s@92.62.56.51)
11:10.31*** join/#oe MWelchUK_work_ (n=welchma@65.91.2.71)
11:15.16*** join/#oe mike_cw_ (n=quassel@host81-150-231-126.in-addr.btopenworld.com)
11:15.54*** join/#oe rsalveti_ (n=rsalveti@200.184.118.136)
11:19.34*** join/#oe rob_w (n=bill@p549BF3A4.dip.t-dialin.net)
11:26.07lrgpb__: could you put my name down for oedem ?
11:28.02pb__lrg: sure thing
11:28.50lrgpb_:thanks. XorA and I will probably travel down together (maybe drive)
11:32.19rob_whow big of a party is oedem usually ?
11:38.53*** join/#oe Christos_N|Work (n=chatzill@gw7.mycosmos.gr)
11:39.32Crofton|workrob_w, we work late :)
11:39.54rob_whmm i see
11:39.57rob_w;-)
11:44.54ant_workfinally googled to see what's the buzz about that Zippy...an expansion board like a BUGvonHippel
11:56.54*** join/#oe rsalveti (n=rsalveti@200.184.118.130)
12:00.34*** join/#oe de_manuel_pi (n=cryolab2@rob.rz.htw-dresden.de)
12:00.41*** join/#oe mickey|fsomeetin (n=M@c120.apm.etc.tu-bs.de)
12:02.37pb__mckoan: I am still working on some of the details, but if there is anything in particular that you want to know, feel free to ask and I will see what I can do.
12:08.22*** join/#oe MostAwes1meDude (n=simpson@c-67-170-134-1.hsd1.or.comcast.net)
12:09.28ant_workmckoan: take coffee and spaghetti with you...
12:09.41czr_peeks
12:10.18XorAant_work: we have both of those in plenty :-D
12:10.20*** join/#oe MostAwesomeDude (n=simpson@c-67-170-134-1.hsd1.or.comcast.net)
12:12.41*** join/#oe emachado (n=edjunior@201.82.64.173)
12:15.39*** join/#oe guillaum1 (n=gl@AMontsouris-153-1-1-117.w86-212.abo.wanadoo.fr)
12:18.14*** join/#oe marcosmamorim (n=marcos@bd21096b.virtua.com.br)
12:20.06*** join/#oe alecrim (n=alecrim@192.100.104.170)
12:22.27*** join/#oe mario-goulart (n=user@67.205.85.241)
12:27.36*** join/#oe jpieper (n=jpieper@207-180-187-171.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)
12:28.08*** join/#oe sgh (n=quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk)
12:34.39mckoanpb__: thx, I basically need to know the location in order to book an hotel
12:35.03mckoanpb__: something clean, cheap, nearby
12:37.44pb__mckoan: the most likely location is postcode cb1 3js, which is on the east side of the city.
12:38.45pb__fallback location is th1's office which is on the science park, postcode cb4 0fy I think
12:39.44*** join/#oe pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB)
12:40.04mckoanpb__: do you have the address please?
12:40.38mckoanneed to discover an hotel in the nearby using google maps
12:41.24mckoanpb__: maybe you know where other developers are staying there?
12:42.07Crofton|workhttp://wiki.openembedded.net/index.php/Oedem/2009
12:42.20*** join/#oe vo5 (n=vo@bd21096b.virtua.com.br)
12:42.23Crofton|workmckoan, can you put some suggestions on this page?
12:43.03czr_hmm. for some reason mdev -s doesn't setup my devices properly.
12:43.18czr_maybe I'll just replace it quickly.
12:43.48tasslehoffhmm. the display says 640x480@59Hz
12:43.54pb__czr_: that is odd, it just reads from sysfs
12:44.07czr_it does? where from?
12:44.17czr_.26 didn't yet have /sys/dev/{char,block}.
12:44.22pb__mckoan: first one is coldhams lane, the second one is science park, milton road.  the postcodes are probably easier for looking up on google maps though.
12:44.28czr_I just backported that from .27 to .26, but mdev -s still doesn't do them.
12:44.46mckoanCrofton|work: I created contents in such page :-D
12:45.17pb__czr_: I imagined from /sys/block/* and /sys/char/* but I have never actually checked
12:45.54czr_well, iterating the info from there is error-prone and quite complex. that's why the /sys/dev/ thingy was added in .27. makes bootstrapping the devnodes much easier
12:46.06czr_but, I'll try to hack something together and test it out, no biggie.
12:46.17pb__yeah, I don't think mdev uses /sys/dev yet
12:46.29pb__at least, not in any version I've seen.  might be that way in the latest eleet busybox I guess.
12:47.07pb__could try stracing mdev -s, that'd give a clue as to what's wrong
12:47.21czr_I can't get a console on the target ;-)
12:47.34pb__heh, just hack the initscript to run mdev under strace
12:47.38czr_http://pastebin.com/m7304a676 <- this is what /sys/dev/char/ looks like on a PC. very nice thing to iterate.
12:48.09czr_well, I'll do the strace if I fail otherwise (i have an idea I want to try out)
12:48.11*** part/#oe tasslehoff (n=Mich@120.80-203-104.nextgentel.com)
12:49.20*** join/#oe jpieper (n=jpieper@207-180-187-171.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)
12:50.47czr_ah yes. the reason why the target didn't advance to runlevel 5 was that it didn't have a tty to start getty on
12:51.54czr_(it works now)
12:56.06czr_http://www.freewrt.org/trac/changeset/3708 found this, but it seems ancient.
12:56.29*** join/#oe tnrdvc (n=taner@88.249.6.230)
12:58.31mckoanpage updated http://wiki.openembedded.net/index.php/Oedem/2009 although I still find it not very useful
13:06.04*** join/#oe jpereira (n=jpereira@unaffiliated/jpereira)
13:09.35*** join/#oe vo5 (n=vo@bd21096b.virtua.com.br)
13:09.42*** join/#oe cminyard (n=cminyard@pool-173-57-157-176.dllstx.fios.verizon.net)
13:10.00Crofton|workpb_, what company do you work for?
13:15.29pb__czr_: doh, that seems like it must be a bug in init
13:15.42pb__Crofton|work: www.reciva.com
13:16.18Crofton|workwhat's up with the abandoned airfield west of cambridge?
13:17.11Crofton|work509 Coldhams Ln?
13:18.08*** join/#oe vivijim (n=vivijim@unaffiliated/vivijim)
13:19.45pb__Crofton|work: right
13:19.52pb__which airfield are you thinking of, Bourn?
13:20.14Crofton|workjust trying to work out the location :)
13:20.28Crofton|workthe abandoned one on the way to the science park
13:20.36pb__if so, I don't think it's actually abandoned: it was a bomber base during world war II and I think it has been used for GA/light aircraft since then
13:20.42Crofton|workobviously an airfiled, but stuff on the runways
13:20.48Crofton|workah
13:20.50pb__hm, let me have a look at google maps and see if I can figure out which one you are looking at
13:20.56pb__can you give me a grid reference for it?
13:22.04Crofton|workon the a428
13:22.27Crofton|workhttp://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=citrix&sll=52.248456,0.081968&sspn=0.029375,0.061798&ie=UTF8&ll=52.217494,-0.042229&spn=0.058791,0.123596&t=h&z=13
13:22.35*** join/#oe ant__ (n=andrea@85.34.85.214)
13:22.56pb__right, that is bourn airfield
13:23.15pb__http://en.wikipedia.org/wiki/Bourn#RAF_Bourn
13:23.36Crofton|workthanks :)
13:24.00Crofton|workOEDEM will be at 509 Coldhams Ln?
13:24.09pb__most likely, yeah
13:24.22Crofton|workthe other location is quite far from town
13:24.47pb__I think they're about the same distance.
13:25.25*** join/#oe marcosmamorim (n=marcos@bd21096b.virtua.com.br)
13:26.06*** join/#oe marcosmamorim (n=marcos@bd21096b.virtua.com.br)
13:26.37XorApb__: is that the same place that the webserver dudes are/were?
13:26.57CIA-103Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r2f514aa042 10openembedded.git/recipes/ffmpeg/ffmpeg_svn.bb: ffmpeg svn: sync with git version to fix versioning
13:27.01CIA-103Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r6d3ad5fb21 10openembedded.git/recipes/linux/ (19 files in 4 dirs): linux-omap 2.6.31: add extra EHCI and USB patches from http://arago-project.org/git/people/?p=ajay/omap-usb-driver.git;a=summary
13:27.02CIA-103Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * ra0818d6ec7 10openembedded.git/conf/machine/omap3-touchbook.conf: omap3-touchbook: also generate squashfs files
13:28.03czr_pb__, I might take a better look at it later, trying to build a uclibc version now.
13:28.19mckoanpb__: what about Appletree House Bed and Breakfast‎ in Coldhams Lane?
13:31.51Crofton|workpb_, is this correct?
13:32.01*** join/#oe stefan_schmidt (n=stefan@c120.apm.etc.tu-bs.de)
13:32.41*** join/#oe Christos_N (n=Christos@ppp-94-66-24-88.home.otenet.gr)
13:33.05*** join/#oe ctusar (n=ctusar@router2.videon-central.net)
13:34.06Crofton|workhttp://maps.google.com/maps/ms?hl=en&ie=UTF8&msa=0&msid=101521096530279421199.000473c5fc6d86d6f952a&ll=52.192838,0.176382&spn=0.00096,0.001931&t=h&z=19
13:34.18Crofton|workthat might help make my other statement make sense
13:34.24Crofton|workanyone can edit the map
13:35.57mckoanCrofton|work: pb__ : how can you get there from railway stn?
13:36.19*** join/#oe alecrim (n=alecrim@189.2.128.130)
13:38.25Crofton|workhttp://www.cambridgeshire.gov.uk/transport/
13:38.31mckoanpb__: looks like it is a B&B http://www.allenbell.co.uk/
13:39.11mckoanCrofton|work: of course, but a few details may be useful
13:40.16XorAwe can just form a tent city near venue :-)
13:48.12*** join/#oe vo5 (n=vo@bd21096b.virtua.com.br)
13:48.29pb__Crofton|work: nearly, you need to go a couple of hundred metres northwest
13:48.53pb__http://maps.google.com/maps/ms?hl=en&ie=UTF8&msa=0&msid=101521096530279421199.000473c5fc6d86d6f952a&t=h&ll=52.195256,0.172487&spn=0.000914,0.00239&z=19
13:49.21pb__mckoan: the citi 1 bus runs nearby, takes about 25 minutes from the rail station
13:49.53pb__failing that, take any bus into the city centre and then take bus 16 which runs right outside our building (but only once per hour)
13:49.57pb__citi 1 is every ten minutes
13:50.35pb__XorA: not sure which webserver dudes you're thinking of.  zeus?
13:50.39pb__they were at the science park
13:51.02XorApb__: yeah zeus, I forgot their name
13:51.10XorApb__: Ive been to that building
13:53.56Croftonttp://maps.google.com/maps/ms?ie=UTF&msa=0&msid=
13:53.56Crofton101521096530279421199.000473c5fc6d86d6f952a
13:54.01Croftondo you get the edit button?
13:54.30pb__no
13:54.48Crofton|workgrumbles
13:55.00Crofton|workstupid google maps
13:55.36XorAat least google maps inability to show hills is not an issue in cambridge :-)
13:55.43pb__heh
13:55.46pb__we do have one hill
13:55.58XorApb__: thats a molehill :-D
13:56.38XorAeneded up walking up a steep nasty hill on sat because I couldnt see it was a hill on the map :-D
13:59.19pb__mckoan: yeah, there are several B&Bs in the area.
13:59.43pb__there is also a holiday inn express a few hundred metres from our office
14:00.43pb__in the centre of town there is a crowne plaza, a devere, and a doubletree.
14:01.34pb__there are a couple of other holiday inns scattered around the city as well, one near the train station and one on the north edge.  plus a "premier inn" which has just opened and which I had never heard of before
14:02.28pb__plus various other smaller independent hotels.
14:06.07*** join/#oe woglinde (i=woglinde@78.52.237.64)
14:07.42*** part/#oe de_manuel_pi (n=cryolab2@rob.rz.htw-dresden.de)
14:12.35*** join/#oe emachado_ (n=edjunior@201.82.64.173)
14:26.53*** join/#oe ArteK (n=Artur@81.15.241.96)
14:28.34*** join/#oe thebohemian (n=rschus@p5DDC76E1.dip.t-dialin.net)
14:29.09*** join/#oe vo5 (n=vo@189.33.9.107)
14:33.47*** join/#oe thebohemian (n=rschus@p5DDC76E1.dip.t-dialin.net)
14:35.24mckoanhave a nice rest of the day
14:41.30*** join/#oe CosmicPenguin (n=nobody@66-162-99-237.static.twtelecom.net)
14:44.36*** join/#oe aloisiojr (n=aloisio@200.184.118.130)
14:44.42*** join/#oe fpga (n=s@92.62.56.51)
14:51.23cbrakesakoman: I think the overo branch needs mickey's fix: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=306ae77b3bd17c9a7e04227fc6b7b2d66c264476
14:52.34sakomancbrake: what are the symptoms with the previous binutils?
14:52.56sakomanI've been using the overo brnach and haven't noticed any problems!
14:53.18cbrakesakoman: I got a "wrong kernel version" on a clean build yesterday
14:53.41cbrakesakoman: not sure if that is what fixed it, but I seem to recall some discussion on #oe about it
14:53.43sakomaninteresting!  I did clean builds of all my images this weekend with no issue!
14:54.01cbrakesakoman: indeed, very interesting
14:54.08sakomanbut I was going to do a merge with oe.dev today anyway, so will pick it up then
14:54.22sakomanhopefully it doesn't break my stuff :-)
14:54.30cbrakesakoman: :-)
14:54.57*** join/#oe rkirti (n=oespirit@203.199.213.3)
14:55.03sakomanI usually lose a day or two f productivity every time I do a merge :-)
14:55.20cbrakesakoman: yeah, moving forward is not free!
14:55.22sakomanbut I wait to push to the overo branch till I am back in business :-)
14:55.32Crofton|workcbrake, my understanding is Angstrom does not use the sane-toolchain stuff
14:56.15*** join/#oe de_manuel_pi (n=cryolab2@rob.rz.htw-dresden.de)
14:57.05XorACrofton|work: you are correct
14:57.18cbrakeCrofton|work: sakoman: here is the error message: http://pastebin.ca/1569695
14:57.49cbrakeanyone know what causes "FATAL: kernel too old" error messages when building glibc?
14:58.19CroftonI think there is a fix for that, but it is a different one
14:58.34*** join/#oe hoj (n=jfaith@75-147-191-205-Washington.hfc.comcastbusiness.net)
14:58.45cbrakesearches history ...
14:59.17cbrakeahh: http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=18158e33775356f5d166908d253159b05125a2fb
14:59.23sakomancbrake: wow, that is a new one to me!
15:00.01XorAlinux-libc-headers 2.6.31 has the needed patch applied
15:00.13*** join/#oe zecke (n=ich@ALyon-551-1-58-11.w90-0.abo.wanadoo.fr)
15:00.13XorAbut I have had time to check my build actually works
15:00.18XorAhavent
15:01.20XorAc
15:02.19XorAor actually I did accidently check it last night
15:02.26XorAforgot I booted my zoo,m2
15:02.34pb__that seems like a weird patch.  why doesn't angstrom just set OLDEST_KERNEL to 2.6.24?
15:03.21sakomanwonders why his builds worked
15:03.46pb__yeah, my micro builds seem to work fine as well.
15:03.55pb__I don't quite understand what the issue is that angstrom is trying to solve with that patch.
15:04.08XorAdoesnt either, have to ask koen
15:04.16pb__kind of seems like something else must be broken somewhere but I don't really know what.
15:04.44pb__zecke: good evening
15:05.30XorAsome machines set OLDEST_KERNEL would that interfere?
15:05.54pb__distro beats machine
15:07.21pb__still, if that patch makes it work for angstrom, and it isn't broken for anybody else, I guess it isn't worth worrying about.
15:09.49sakomanjust did a merge with oe.dev, we'll see if it breaks anything for me
15:09.56ant__pb__: the patch works (angstrom/dev/glibc/armv5te)
15:10.06ant__tested two builds
15:11.18pb__ant__: very good
15:11.43sakomantested 10 builds on 2 machines, removing tmp first and had no issues prior to the patch
15:12.02sakomanwe'll see what happens post patch now
15:12.59ant__pb__: 2.6.26 fwiw
15:13.56cbrakeI really don't like anonymous wikis (or anonymous anything for that matter) http://wiki.openembedded.net/index.php?title=Getting_started&diff=1678&oldid=1671
15:15.13pb__doh
15:15.26ant__bbl
15:16.43XorAcbrake: its pretty universal feature on wikis, if its not about pr0n its probably wrong
15:17.42*** join/#oe JaMa (n=martin@161-24.13.24.78.awnet.cz)
15:18.29cbrakeXorA: most of the effort on our wiki seems to be cleaning up spam.  It seems like it would be a small thing to ask editors to create an account.
15:23.03*** join/#oe freddy (n=freddy@hotel742.server4you.de)
15:26.00Crofton|workheh
15:26.10Crofton|workI wonder why someone would make that change
15:26.39Crofton|workI have no problem requiring a login to edit the OE wiki
15:26.50Crofton|workbbl, lunch
15:35.06*** join/#oe dos1 (n=dos@unaffiliated/dos1)
15:39.18mike_cw_can i force opkg to install a local package instead of getting a newer version from angstrom? it was working this morning!
15:39.35mike_cw_-force-downgrade doesn't work
15:41.06*** join/#oe ich (n=ich@ALyon-551-1-58-11.w90-0.abo.wanadoo.fr)
15:46.26*** join/#oe santamarta (n=Juanjo@195.Red-213-96-224.staticIP.rima-tde.net)
15:46.27otavioCould people take a look and ack a pull from our repository? I'm with those changes done locally for long time and want to stop bothering about them and merge them all. Please take a look at https://projetos.ossystems.com.br/git/?p=users/otavio/org.openembedded.dev.git;a=summary
15:47.59*** join/#oe Sleep_Walker (n=Sleep@193.179.96.131)
15:49.10*** join/#oe rsalveti (n=rsalveti@200.184.118.130)
15:50.38*** join/#oe aloisiojr (n=aloisio@200.184.118.130)
16:02.09*** join/#oe darion76 (n=darion76@92-49-226-115.dynamic.peoplenet.ua)
16:02.50*** join/#oe gt1 (n=a0868890@nat/ti/x-fyrjuucjwgfqtolh)
16:10.14*** join/#oe rob_w_ (n=bill@p549BD7DD.dip.t-dialin.net)
16:14.01khem|afkotavio: use __always_inline instead of __inline__ what issues do you have without this patch
16:14.46khemotavio: -fPIC for libgpg-error's CFLAGS
16:14.50khemlooks ok
16:16.17khemotavio:
16:16.18khemAvoids overwriting Python's built-in `str' in get_devtable_list
16:16.30khemis this just a  cleanup
16:17.59khemother ones look ok to me
16:19.01*** join/#oe xxiao (i=c058a822@gateway/web/freenode/x-oybedxrlzbncuorj)
16:24.49RPkhem: http://git.pokylinux.org/cgit.cgi/poky/log/?h=canadian
16:28.42*** join/#oe james_lan (n=james@ip68-102-173-52.ks.ok.cox.net)
16:32.19*** join/#oe vo5 (n=vo@bd21096b.virtua.com.br)
16:39.00pb__khem: ld.so doesn't work without always_inline
16:39.14pb__see the logs for this channel, we had a long discussion about it at the time
16:43.11Gnutookhem, mips ?
16:43.21Gnutoo+ uclibc ?
16:43.45Gnutoowithout the patch?
16:45.29khempb__: it works well here on arm thats why i was wondering
16:45.40pb__it fails on mips, at least, and I think it only works on arm by chance
16:47.21Gnutoopb__, I had this issue,we debuged it and mario goulard pushed in the patch from the uclibc repository
16:47.30Gnutoos/pb__/khem
16:47.51Gnutoothe patch was made a little bit after the release...so
16:48.00Gnutoothat's why we have this problem
16:52.30pb__right
16:53.57pb__I think that patch is fine, you can land it in the .dev tree.
16:54.05pb__the gpg-error one is a bit startling.
16:57.00pb__I just ran a build of libgpg-error here and it does seem to be coming out PIC without your patch.  If that isn't working for you then it seems like maybe you have a generic libtool malfunction.
16:57.26pb__and, if that's the case, it would be better fixed in libtool rather than patching the individual packages.
16:58.01pb__the image.bbclass one looks fine to me, might be worth asking mickey|fsomeetin to bless it with his python skills
16:59.41pb__x11r7.5, presumably fine though the existence of that whole file seems a bit premature.
17:04.09CIA-103Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rfd8af199bb 10openembedded.git/recipes/linux/ (5 files in 4 dirs): linux-omap 2.6.31: add some more display fixes
17:04.18*** part/#oe darion76 (n=darion76@92-49-226-115.dynamic.peoplenet.ua)
17:04.21*** join/#oe mario-goulart (n=user@67.205.85.241)
17:15.09otaviokhem: uclibc fails on mips
17:15.30otaviokhem: yes, str is a cleanup but worth IMO
17:16.50otaviopb__: the 7.5 is nice to have since the pieces that are being tested can be enables and allow for a on going development besed on the new Xorg modules
17:16.58otaviopb__: to avoid duplicated work
17:17.17otaviopb__: gpg-error fails in mips as well
17:17.39pb__right, I'm happy enough with the x11r7.5 thing, it just seems a bit odd to have an include file for a release that doesn't exist yet.
17:17.52pb__regarding the gpg-error thing, as I wrote above it seems like that would be better fixed in libtool.
17:18.12pb__or possibly in gpg-error's use of libtool; which file exactly was getting built as non-pic?
17:18.57otaviopb__: I don't recall anymore
17:19.16otaviopb__: I sent it long time ago and kept it for pushing and never did
17:19.31otaviopb__: well; i droped it for now and then will push the rest then
17:19.35pb__okay.  I think it would be worth doing some more investigation before landing that patch in the tree.
17:19.43pb__yes, the others look fine
17:20.32otaviodone
17:20.37CIA-103Mario Domenech Goulart <mario@ossystems.com.br> 07org.openembedded.dev * r8a40ec536f 10openembedded.git/recipes/uclibc/ (2 files in 2 dirs):
17:20.37CIA-1uClibc: use __always_inline instead of __inline__
17:20.37CIA-1Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
17:20.39CIA-103Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * rd96238b177 10openembedded.git/ (8 files in 4 dirs):
17:20.42CIA-1xf86-video-geode: update to 2.11.4.1
17:20.44CIA-1Since it is a bugfix release we updated from 2.11.2 to 2.11.4.1 and
17:20.46CIA-1also set this as preferred version for the distros using the upcoming
17:20.48CIA-1Xorg 7.5 release or the 7.4 (updates).
17:20.50CIA-1Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
17:20.52CIA-103Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r7daf6b3e17 10openembedded.git/recipes/pcmanfm/ (files/auto_mount.patch pcmanfm_0.5.bb):
17:20.55CIA-1pcmanfm: fix automounting support
17:20.57CIA-1Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
17:21.01CIA-103Otavio Salvador <otavio@ossystems.com.br> 07org.openembedded.dev * r4fdfbf9af2 10openembedded.git/conf/distro/include/preferred-xorg-versions-X11R7.5.inc:
17:21.04CIA-1preferred-xorg-versions-X11R7.5.inc: bump xf86-video-intel to 2.6.3
17:21.06CIA-1Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
17:21.10CIA-103Mario Domenech Goulart <mario@ossystems.com.br> 07org.openembedded.dev * r55f42a3dd5 10openembedded.git/classes/image.bbclass:
17:21.15CIA-1Avoids overwriting Python's built-in `str' in get_devtable_list
17:21.17CIA-1Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
17:21.30otavioand thx :-)
17:41.10m4theh so i rm'd deploy/uclibc/ipk/ppc.../*
17:41.18m4tto try to rebuild everything
17:41.30m4tbut staging is/was still populated
17:41.44m4tin the future, is there a better way to clean that up for a rebuild?
17:45.07*** join/#oe emachado (n=edjunior@201.82.64.173)
17:52.15*** join/#oe thaytan (n=jan@212.2.179.114)
17:52.20*** join/#oe chouimat (n=quassel@CPE002129b5a060-CM0011e6c40c15.cpe.net.cable.rogers.com)
18:07.22CIA-103Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rb4aa04a13f 10openembedded.git/recipes/ti/gstreamer-ti_svn.bb: gstreamer-ti: only patch in omapfb for armv7a
18:09.04CIA-103Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rfde321de55 10openembedded.git/recipes/u-boot/u-boot.inc: u-boot: if there's a fw-env in SRC_URI build and install tools as well
18:09.05CIA-103Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r8d8b1db7fc 10openembedded.git/recipes/powervr-drivers/libgles-omap3.inc: libgles-omap3: switch to FLIP wsegl
18:09.06CIA-103Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r6092bf2816 10openembedded.git/contrib/angstrom/sort.sh: angstrom feed sorter: add omap3-touchbook support
18:14.06*** join/#oe oneshel (n=jim@c-98-216-198-0.hsd1.nh.comcast.net)
18:19.08*** join/#oe emachado (n=edjunior@201.82.64.173)
18:20.43khemGnutoo: which version of gcc were you using and was it for mips only ?
18:20.58Gnutookhem, yes mips only
18:21.02*** join/#oe toi (n=pleemans@d5153128F.static.telenet.be)
18:21.07GnutooI'll check the gcc version
18:21.11khemGnutoo: the change is semantically same for compiler to unless you had a buggy compiler I would not expect any changes
18:21.18m4tkhem ^^ any quick suggestions? i wanted to rebuild all to make sure deps are being used correctly etc
18:21.20khemin generated code
18:21.33m4tnow im running into a bunch of problems because i rm'd the ipk without cleaning up staging
18:22.00khemyou can bitbake -b recipe.bb -c clean
18:22.03m4tyea
18:22.07khemthen bitbake recipe
18:22.11m4tyes...
18:22.12khemit should get the deps
18:22.14Gnutoomaybe 4.2.4 not shure
18:22.23m4twhat if i rm'd staging?
18:22.43m4ti mean, how do i completely rebuild everything except the toolchain
18:22.53m4t-native -cross etc.
18:22.58khemm4t: if you have packaged staging then it should be able to reconstruct staging from ipks
18:23.35*** join/#oe fpga (n=s@89.112.93.57.pppoe.eltel.net)
18:23.40otaviokhem: we tested with many versions while debugging it. 4.2.4, 4.3.<something> and other that I don't recall. mario-goulart do you remember which versions we tested?
18:23.41khemm4t: you mean just the target recipes ?
18:24.01m4ttmp/deploy/uclibc/ipk/ppc405 is what i rm'd
18:24.07m4tand khem, yea target recipes
18:24.20m4ti pretty much rebuilt everything
18:24.25mario-goulartreads the backlog
18:24.37m4tbut i got rid of libgcc and libssp too ;/
18:24.58m4tand now gettext is mising libiconv headers (oh no)
18:25.26m4ti might have it fixed
18:25.47m4tthe only thing is....i'd much rather have it link, during compilation, to the .ipk that will be installed on my target
18:26.10m4trather than using the stray libs and headers etc. that remained after i removed the .ipk from deploy/uclibc/ipk/ppc405
18:26.15khemotavio: the patch is good actually I am more intested in the fact that it could have smeared on another problem
18:27.12*** join/#oe toi (n=pleemans@d5153128F.static.telenet.be)
18:27.14*** join/#oe stephank (n=traveler@2002:52c5:cf78:7:21c:c4ff:fece:ea94)
18:27.15mario-goulartkhem, otavio you are talking about the uclibc patch (use __always_inline instead of __inline__)?
18:27.18m4twhat has happened is that a package will build, because it finds the libaries/headers, but when it comes time to build the actual .cpio image, it craps out, because the .ipk that originally populated staging is missing
18:27.32khemmario-goulart: yes
18:27.53*** join/#oe xjqian (n=gordon@mscitspubwlgw.wustl.edu)
18:28.02Gnutookhem, mario-goulart, is the one who commited the patch
18:28.10Gnutoohi marcosmamorim
18:28.12Gnutoooops
18:28.17khemm4t: I think your build became inconsistent I would say rebuilt all
18:28.20Gnutoohi mario-goulart
18:28.35mario-goulartHi Gnutoo
18:28.42mario-goulartkhem: I've tested it with gcc 4.3.2, 4.1.2 and 4.2.4.
18:28.44m4theh khem, when you say 'all', do you also imply my cross compiler toolchain and native utilities?
18:29.05khemm4t: to be safe yes
18:29.13m4tawesome
18:29.18khemmario-goulart: what was original problem
18:29.53m4twell thats no problem. its mostly a deterministic build, but said build requires me to chpax a few things before they wind up in staging etc.
18:30.23m4ti should really enable pax_softmode, would make things like this a bit easier
18:30.24mario-goulartkhem: dynamicaly linked applications segfault on mips when using uclibc
18:31.27khemmario-goulart: ok which means the function did not get inlined and a call was made before ld could do function calls
18:31.33khemwhich is usually the case
18:32.23khemmario-goulart: However __inline__ is defined same as __always_inline
18:32.34khemso why it did not get propagated in mips
18:32.37m4thrm khem, well, that might enable me to try adding that syscall udev > 124 needs
18:32.46m4tie. uclibc/kernel header patch
18:32.56khemyes are you on arm ?
18:33.35m4toh, no
18:33.40m4ti could try to port it over to ppc
18:33.44khemwell then you dont worry about it
18:34.03CIA-103Thomas Zimmermann <zimmermann@vdm-design.de> 07shr/import * re02daee84e 10openembedded.git/ (2 files in 2 dirs):
18:34.03CIA-1Blueman: Add depencies (startup-notification 0.9 from org.oe.dev)
18:34.03CIA-1Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
18:34.03CIA-103Thomas Zimmermann <zimmermann@vdm-design.de> 07shr/import * r999a29eaa1 10openembedded.git/recipes/vagalume/vagalume_0.7.1.bb:
18:34.04CIA-1Vagalume: Depend on gst-plugin-mad only if ENTERPRISE_DISTRO is not set
18:34.06khemI thought ppc already wired the ppoll and pselect syscalls
18:34.08CIA-1Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
18:34.10CIA-103Martin Jansa <martin.jansa@gmail.com> 07shr/import * r73dc33009c 10openembedded.git/ (18 files in 9 dirs):
18:34.10khembut I may be mistaked
18:34.13CIA-1Synchronize subversion stuff with oe.org.dev compiled fine now.
18:34.15CIA-1Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
18:34.17CIA-103Thomas Zimmermann <zimmermann@vdm-design.de> 07shr/import * r7b2c538f9a 10openembedded.git/ (conf/checksums.ini recipes/blueman/blueman_1.10.bb):
18:34.22CIA-1Blueman: add reciepe (just for development, because runtime depencies aren't fullfilled)
18:34.24CIA-1Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
18:34.36RPhugs his new SDK tarballs
18:34.47m4ti did run into the error where udev spewed a bunch of logs related to one syscall
18:34.52m4tlets see
18:35.24m4t./udev/udevd.c:fdcount = ppoll(pfd, nfds, NULL, &orig_mask);
18:35.30khemRP: I havent looked at the patches yet. I plan to see them later today
18:35.32m4ti think that is the line from udev-141
18:35.53otavioRP: :-)
18:36.26RPkhem: Its taken a few core changes particularly the layout stuff but I'm really pleased with the result. Id be intersted in come other eyes on it...
18:36.47khemRP: yeah and we should get it into OE as well
18:37.04otavioRP: those are patches for SDK producing?
18:37.17RPotavio: yes
18:37.28mario-goulartkhem: I actually haven't checked how they are defined.  It is weird that they are the same.  Probably there are some redefinition specific for mips?
18:37.47*** join/#oe emachado (n=edjunior@201.82.64.173)
18:38.05khemmario-goulart: include/sys/cdefs.h defines __always_inline
18:38.08*** join/#oe Soopaman1 (n=soopaman@69.172.107.180)
18:38.17khemand __inline__ is gnu extension which is same as __inline
18:38.27mario-goularthmmmm
18:38.37RPkhem: Yes, I'd love to see this in OE. I've kept everything in a new namespace which should help integration
18:39.13CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r3ecdded38a 10openembedded.git/conf/distro/include/ (shr-autorev-unstable.inc shr-autorev.inc): shr-autorev*: Soem auto and some fixed revs for upcoming SHR merge (from SHR)
18:39.14CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r80c55c2574 10openembedded.git/recipes/shr/e-wm-theme-illume-shr_git.bb: e-wm-theme-illume-shr: Add recipe (from SHR)
18:39.15CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r0393c7cc15 10openembedded.git/recipes/shr/e-wm-sysactions-shr_git.bb: e-wm-sysactions-shr: Add recipe (from SHR)
18:39.17CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * ra318f679fc 10openembedded.git/recipes/shr/libphone-utils_git.bb: bphone-utils: Add recipe (from SHR)
18:39.20CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * re8622747c6 10openembedded.git/recipes/shr/ (22 files in 2 dirs): initscripts-shr: Add SHR initscripts (from SHR)
18:39.23CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * ra86973493b 10openembedded.git/recipes/shr/alsa-scenarii-shr_git.bb: alsa-scenarii-shr: Add recipe (from SHR)
18:39.26CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r08678a65e4 10openembedded.git/recipes/shr/etk-theme-shr_git.bb: etk-theme-shr: Add recipe (from SHR)
18:39.31CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r2ff4462e97 10openembedded.git/recipes/shr/e-wm-menu-shr_git.bb: e-wm-menu-shr: Add recipe (from SHR)
18:39.34CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r0c186bfb52 10openembedded.git/recipes/efl1/ (13 files): illume-keyboard*: A bunch of illume keyboard layouts. (from SHR)
18:39.38*** join/#oe florian (n=fuchs@f049077025.adsl.alicedsl.de)
18:40.13otavioRP: where are the patches available?
18:40.38florianre
18:41.03otaviokhem: the end result is that this is a backport from a uclibc upstream fix. So it is much better to discuss it on their ml then in OE ;-)
18:41.20RPotavio: http://git.pokylinux.org/cgit.cgi/poky/log/?h=canadian
18:41.22otaviokhem: they did it in their git master and we backported it
18:41.29RPotavio: Undergoing testing atm...
18:41.49khemotavio: yes  I know but I wanted a better understanding
18:42.45otaviokhem: it took a mounth for us to get it working ;-)
18:44.19otavioRP: are you intending to make  a branch for people play with it in OE?
18:44.48RPotavio: I don't think I've got the time for that :/
18:45.14khemotavio: I see
18:45.20RPotavio: We'll see but I'm extremely sort of time atm
18:45.40*** join/#oe vo5 (n=vo@bd21096b.virtua.com.br)
18:45.48otavioRP: :(
18:46.12otaviodon't intend to get used to poky to play with it :-)
18:46.22otavioRP: ok
18:46.27RPotavio: Poky and OE have the same core ;-)
18:55.48khemotavio: mario-goulart I see that the fix correctly now
18:56.12khemthe fix is correct
18:57.07khemuclibc is defining it __GNUC_PREREQ as minimum supported version so basically it will be defined to  __inline __attribute__ ((__always_inline__))
18:57.11khemwhich makes sense
18:57.20khempush it to .dev
18:58.32*** join/#oe emachado (n=edjunior@201.82.64.173)
18:59.48*** join/#oe timtimred (n=meh@79-75-195-84.dynamic.dsl.as9105.com)
19:01.33khemRP: this canadian branch seems to be long lasting one
19:02.02RPkhem: hmm, its not intended to be
19:02.16RPkhem: How do you mean long lasting?
19:03.02khemRP: I mean will you keep it alive or merge is to poky trunk
19:03.12RPkhem: It will be merged back soon
19:03.17khemok
19:03.27khemRemove layout_* variables I like it
19:04.57RPkhem, otavio: http://pastebin.ca/1569976 is the email I just sent to the list
19:05.10RP(pasted here since I know what the list repsonse time is like :/ )
19:06.18mickey|fsomeetingo for it
19:06.29CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r83688479d4 10openembedded.git/recipes/efl1/e-wm-illume-dict-pl_git.bb: e-wm-illume-dict-pl: Polish dict for the illume keyboard (from SHR)
19:06.30CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * rdd9df493e1 10openembedded.git/recipes/shr/e-wm-theme-illume-sixteen_git.bb: e-wm-theme-illume-sixteen: Add recipe (from SHR)
19:06.30CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * r60a6249237 10openembedded.git/recipes/shr/e-wm-theme-illume-niebiee_git.bb: e-wm-theme-illume-niebiee: Add recipe (from SHR)
19:06.32CIA-103Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * rd56ffbe90a 10openembedded.git/recipes/shr/ (2 files): elementary-theme-*: Elementary themes (from SHR)
19:07.43khemRP: SDK_ARCH is same as HOST_ARCH in logic so I think you could make it SDK_HOST_ARCH
19:08.39RPpb__: Are these nominations to go to the list or to you privately? When you say arrange a vote, is that at OEDEM or are we adding internet members to the e.V. first?
19:09.06XorARP: internet voting should be allowed at the EGM
19:09.09RPkhem: True, I just followed what OE already has for that
19:09.22XorARP: thats the whole purpose of the EGM
19:09.23RPXorA: ah, true
19:10.04XorA~curse libsdl
19:10.05ibotMay you be reincarnated as a Windows XP administrator, libsdl !
19:10.06khemXorA: is info available for internet voting somewhere on wiki
19:10.07*** join/#oe emachado (n=edjunior@201.82.64.173)
19:10.38XorAkhem: no, I guess someone needs to agenda it at the EGM
19:11.36CIA-103Martin Jansa <martin.jansa@gmail.com> 07shr/import * r4220590e12 10openembedded.git/ (7 files in 3 dirs):
19:11.36CIA-1Rebased glamo patch from Andrzej Zaborowski http://repo.or.cz/w/mplayer/glamo.git (just -vo glamo without vidix driver stub), bump mplayer revision
19:11.36CIA-1Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
19:11.37khemRP: I think you could rename crosssdk.bbclass to cross-sdk.bbclass and nativesdk.bbclass -> native-sdk.bbclass
19:12.11khemand cross-canadian.bbclass could be called canadian-cross-sdk.bbclass
19:12.34*** join/#oe brolin (n=brolin@iner.udea.edu.co)
19:13.07khemcanadian-cross does nt deal with SDK only I guess so canadian-cross.bbclass is ok
19:13.55RPkhem: cross-sdk causes a namespace clash with existing gcc/binutils recipe names and I wished to avoid it ;-)
19:15.38khemI think you can use the existing ones with your work
19:15.45khemwho will use them after your patch
19:16.15RPkhem: right, it just allows easier merging
19:16.24khemok
19:16.27khemmakes sense
19:18.35*** part/#oe ArteK (n=Artur@81.15.241.96)
19:19.56*** join/#oe pleemans (n=toi@d54C2A96D.access.telenet.be)
19:22.15khemRP: task-sdk-host.bb has mixture of -nativesdk and -cross-canadian packages
19:22.45khemwhy is that
19:22.49khemhttp://git.pokylinux.org/cgit.cgi/poky/commit/?h=canadian&id=cd1e4062a813ae91586d4baaafc252a8ba910831
19:23.33RPkhem: They all run on SDK_ARCH so why not?
19:23.59RPkhem: We want things like pkgconfig as well as our canadian compiler
19:24.44khemRP: so why not have pkgconfig-cross-canadian
19:24.59RPkhem: pointless ;-)
19:25.09khemyeah
19:25.44khempkgconfig-nativesdk is already a canadian-cross
19:27.38khemRP: in the same commit above you removed gdb-cross-nativesdk but did not add gdb-cross-canadian
19:28.09RPkhem: gdb is broken atm, thanks for the reminder! :)
19:28.45khemI think the patches look sane to me
19:29.06RPkhem: Imagine how users might install an sdk - a core (nativesdk), a target specific part (gcc/bintutils/gdb) and a target rootfs
19:29.33RPkhem: I like the idea of at least being able to make that split in theory
19:29.38RPkhem: cool :)
19:30.05khemRP: why would one need tools on target I can understand libgcc libstdc++ etc.
19:30.39RPkhem: target specific as in cross-canadian tools
19:30.47khemah I see
19:31.20khemfor users host arch and target arch are what they care
19:31.30khembuild_arch is only for builders
19:31.35khemlike oe and poky
19:31.38RPkhem: right
19:31.59RPkhem: The SDK also includes its own glibc now which is an improvement really
19:32.13khemyes saw that
19:32.14RPno more strange glibc compatibility issues...
19:32.43RPkhem: Merging with OE wise, I worry about the layout changes
19:32.55RPIf we can get that in, the rest is easy...
19:33.21khemRP: yeah but I think that change should go first if it be
19:33.33khemthen sdk changes may follow
19:33.37RPkhem: right
19:33.49khemright now .dev is in good shape relatively
19:34.00khemso its best time for you to get your stuff in if you like
19:34.07khemI can help in testing it out
19:34.35RPkhem: right. Time wise I'm going to hit a wall at the end of this week with travel though :(
19:34.45RPhas been rushing to at least get it into poky
19:35.01khemI see
19:38.12khemRP: you can push Remove layout_* variables patch
19:38.19khemand we can stabilize it on .dev
19:38.33khemI think micro changes the layout
19:38.50khemso that will need to be handled
19:39.07RPkhem: I'll see if I can massage it to fit OE but no promisies time wise :/
19:39.43khemok
19:41.12*** join/#oe Soopaman (n=soopaman@69.172.107.180)
19:48.16*** join/#oe likewise (n=chatzill@82-171-51-231.ip.telfort.nl)
19:50.00likewisecan someone run bitbake openocd-native. It fails during configure on my x86 32-bit 9.04.
19:54.23likewiseactually, it's libftdi
19:54.26*** join/#oe Soopaman (n=soopaman@69.171.149.94)
19:54.42khemwhats the error
19:55.04CIA-103Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r62b5c01bde 10openembedded.git/ (conf/checksums.ini recipes/gstreamer/gst-rtsp_0.10.4.bb):
19:55.04CIA-1gst-rtsp: add 0.10.4
19:55.04CIA-1* vala and python binding haven't been enabled, they most likely require some patching
19:55.05CIA-103Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r2d899b917c 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev
19:55.46khemavoid those merge messages in org.openembedded.dev
19:55.53khemhistory folks
19:59.57likewisekhem: Hi. Do you mean we can avoid merges to appear in GIT?
20:02.33khemyes
20:02.52khemdont push directly from oven
20:03.17khemnobody is interested to know about your local merges
20:03.28khemit clutters the history
20:04.57khemI found rebase very powerful
20:05.12khemand I hardly use git merge
20:05.25khemusually git pull will merge
20:06.29khemgit fetch;git reabase origin/org.openembedded.dev
20:06.56likewisekhem: ah, I never use git merge. I use --rebase. I'm a GIT noob, so this is all by pure accident :-)
20:07.09*** join/#oe bluelightning (n=blueligh@pdpc/supporter/professional/bluelightning)
20:07.48khemyou are on right path :)
20:08.01khemsome one should tell koen
20:08.12khemI see many merge messages from him
20:08.31khemI also did this for sometime but then I figured it otu
20:08.58cbrakegit pull --rebase also works for me
20:11.55*** join/#oe xjqian (n=gordon@mscitspubwlgw.wustl.edu)
20:18.06*** join/#oe drasar (n=maik@r4bd31.net.upc.cz)
20:19.21*** join/#oe JaMa (n=martin@161-24.13.24.78.awnet.cz)
20:21.20khemcbrake: yes
20:21.55khemmy command reminds me always that I am rebasing to right remote branch :)
20:22.55*** join/#oe sgh_ (n=quassel@0x4dd5bf76.adsl.cybercity.dk)
20:23.06cbrakenod, explicit is good somethings
20:25.59*** join/#oe drasar (n=maik@r4bd31.net.upc.cz)
20:26.15khemit seems my son pulled the laptop cable at home I cant login anymore
20:28.09*** join/#oe sgh__ (n=quassel@0x4dd5bf76.adsl.cybercity.dk)
20:28.27*** join/#oe aloisiojr (n=aloisio@200.184.118.130)
20:29.01Crofton|workqgit is also useful for looking at history
20:32.04*** part/#oe drasar (n=maik@r4bd31.net.upc.cz)
20:39.11*** join/#oe john3909 (n=jsynesio@99-26-125-126.lightspeed.sndgca.sbcglobal.net)
20:42.27CIA-103Stanislav Brabec <utx@penguin.cz> 07org.openembedded.dev * r33cee05869 10openembedded.git/recipes/autoconf/ (6 files in 4 dirs):
20:42.27CIA-1autoconf: Fixed calling of perl and m4:
20:42.27CIA-1* removed path_prog_fixes.patch
20:42.27CIA-1* set needed ac_cv_* variables for non-native builds
20:42.27CIA-1* depend on perl
20:42.29CIA-1* for more see http://thread.gmane.org/gmane.comp.handhelds.openembedded/26476
20:44.14*** join/#oe ant__ (n=andrea@host176-250-dynamic.0-87-r.retail.telecomitalia.it)
20:47.46*** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net)
20:50.02*** part/#oe santamarta (n=Juanjo@195.Red-213-96-224.staticIP.rima-tde.net)
20:53.48*** join/#oe nhg (n=a0864305@nat/ti/x-gtpklpnsncmdqwgu)
21:00.45CIA-103Graeme Gregory <dp@xora.org.uk> 07org.openembedded.dev * rb0a80126c9 10openembedded.git/recipes/libsdl/ (files/libsdl-1.2.11-pagesize.patch libsdl-x11_1.2.11.bb): libsdl-x11_1.2.11.bb : remove asm/page.h as its no longer there
21:05.22*** join/#oe sgh_ (n=quassel@0x4dd5bf76.adsl.cybercity.dk)
21:06.33CIA-103Martin Jansa <martin.jansa@gmail.com> 07shr/import * r3b1f42c691 10openembedded.git/recipes/mplayer/files/ (configh configmak):
21:06.33CIA-1Fix mplayer build with HAVE_NEON 0
21:06.33CIA-1Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
21:08.11*** part/#oe nhg (n=a0864305@nat/ti/x-gtpklpnsncmdqwgu)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.