04:34.56 | *** join/#oe ibot (ibot@rikers.org) |
04:34.56 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Bugtracker: http://bugs.openembedded.org and http://tinderbox.openembedded.org for compile issues | Repository: git.openembedded.org/openembedded and repo.or.cz/r/openembedded.git as ro mirror | This is not a distro or machine support channel | ADMIN STATUS: GIT DOWN |
04:47.01 | *** join/#oe ka6sox (~ka6sox@nslu2-linux/ka6sox) |
05:25.04 | *** join/#oe bala_holmes (~7aa4bab8@gateway/web/freenode/x-zfrdksoiunxvibud) |
05:32.50 | *** join/#oe polyonymous (~hacker@g230193061.adsl.alicedsl.de) |
05:38.11 | *** join/#oe xjqian (~gordon@mir-nil-pat-118-150.wustl.edu) |
06:07.50 | *** join/#oe roopar (~roopati@nat/ti/x-nmkzhgbaygshgpfx) |
06:13.25 | *** join/#oe siji (~siji@122.170.9.183) |
06:15.59 | siji | Hi All |
06:16.24 | siji | I am trying to enable mouse support for the console in Angstrom |
06:16.44 | siji | and Created one receipe and IPK for gpm |
06:16.55 | siji | gpm -general Purpose mouse |
06:17.04 | siji | But still it's not working |
06:17.12 | siji | so any idea where am wrong ? |
06:24.34 | *** join/#oe tasslehoff (~Mich@147.84-49-231.nextgentel.com) |
06:53.52 | *** join/#oe jovox (~jovox@h151n1c1o279.bredband.skanova.com) |
06:54.19 | aditya_1111 | anyone know why the python package for angstrom might be missiing termios? |
06:54.23 | aditya_1111 | among other modules |
07:04.19 | aditya_1111 | * sigh * |
07:06.03 | *** join/#oe jovox_ (~jovox@h128n2c1o279.bredband.skanova.com) |
07:18.20 | *** join/#oe Heinervdm (~thomas@pD9E14984.dip.t-dialin.net) |
07:29.01 | *** join/#oe thebohemian (~rschus@p5DDC1B4A.dip.t-dialin.net) |
07:34.25 | *** join/#oe jovox (~jovox@h128n2c1o279.bredband.skanova.com) |
07:34.54 | jovox | morning |
07:36.02 | mckoan | good morning |
07:36.05 | *** join/#oe Hasse_ (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
07:37.53 | *** join/#oe tsjsieb (~tsjsieb@dejongbeheer.nl) |
07:38.47 | jovox | I asked about this yesterday but still havn't solved it so I'll try again.. I got two "identical" (manufactor say they are and lspci/lshw looks pretty identical) machines. The problem is that the network is only working in one of them using the same image. I'm moving the CF-card between the machines. On one of the machines it seems like it can't identify the nics at all. I need some suggestions on where to start troubleshooting this |
07:40.20 | mckoan | jovox: if network is only working in one of them using the same image, looks like the problem is the hardware |
07:43.54 | jovox | yeah.. but I tried with a another "rescue" distro and that one work on both machines |
07:44.31 | jovox | and it's 4 out of 5 machine that doesnt work |
07:44.49 | jovox | and manufactor says all five should be identical |
07:45.23 | jovox | but lspci tells me I have the same nics on all five |
07:47.41 | eFfeM-work | you're not trying them at the same time are you ? |
07:48.01 | jovox | same time? |
07:48.49 | jovox | I got them on my desk and just move the cf card between them.. do yeah, pretty much the same time |
07:51.04 | jovox | But it's clear something is different between them |
07:53.08 | *** join/#oe siji (~siji@122.170.9.183) |
07:57.50 | siji | help me pls |
08:02.37 | eFfeM-work | jovox: i think the issue is with your hw and your setup |
08:03.05 | eFfeM-work | jovox: if the machines one way or another get the same mac address this could well be a problem |
08:03.25 | eFfeM-work | your cf card contains u-boot which often sets the mac address |
08:03.55 | jovox | I don't have any network cable connected so thats now the issue |
08:04.47 | jovox | I just booted the rescue image on two machines. It's loading the same driver on both of them (one of them is the one that does not work with my image). |
08:05.00 | eFfeM-work | ah ok, thought from your message that you had (as you ssaid the network was only working iwth one machine) |
08:05.46 | jovox | ok, to be more clear it's the nics there are not being identified |
08:05.48 | eFfeM-work | jovox, guess you need to check if there is debugging code in your nic driver that you can enable to pinpoint the problem |
08:06.20 | eFfeM-work | they are there, lspci sees them, but somehow they are not accepted or some other error shows up |
08:06.45 | jovox | yes |
08:10.03 | *** join/#oe dth (~dieter@p4FDECEE6.dip.t-dialin.net) |
08:10.54 | jovox | The rescue image image is using an older version of the r8169 module.. |
08:11.10 | *** join/#oe sgh (~quassel@cpe.ge-0-2-0-950.faaqnqu1.customer.tele.dk) |
08:11.29 | jovox | it's using 2.2 while mine is 2.3 |
08:11.55 | jovox | it looks like onw can set the debuglevel for it |
08:12.02 | jovox | will see if that gives anything |
08:12.04 | eFfeM-work | maybe then try the old one |
08:12.10 | jovox | yes |
08:12.14 | eFfeM-work | indedd typically you can set some debug level |
08:15.08 | *** join/#oe mikeul (~509888f5@gateway/web/freenode/x-vepjsohtpdkaaldn) |
08:16.42 | *** join/#oe thaytan (~jan@ppp59-167-167-201.static.internode.on.net) |
08:29.15 | *** join/#oe spaetz (~spaetz@195.190.188.219) |
08:29.37 | spaetz | If I need the python "urlparse" module. Where is that provided? |
08:29.56 | spaetz | It doesn't seem to be installed by default and there is no python-urlparse recipe |
08:30.49 | Jin^eLD | <PROTECTED> |
08:31.12 | Jin^eLD | or do you mean not for building but for the target? |
08:31.21 | spaetz | right, it is part of the standard library, but we don't install the full standard library by default. Right for the target |
08:31.21 | Jin^eLD | s/building/host/ |
08:31.34 | Jin^eLD | ah, sorry |
08:31.36 | Jin^eLD | :) |
08:31.54 | spaetz | np :) |
08:32.26 | *** join/#oe Pr0t0N (~lcintrat@93.2.234.35) |
08:37.21 | *** join/#oe dth (~dieter@p4FDECEE6.dip.t-dialin.net) |
08:44.14 | *** join/#oe lrg (~lrg@slimlogic.co.uk) |
08:50.52 | *** join/#oe grma (~gruberm@chello212186029093.tirol.surfer.at) |
09:00.51 | *** join/#oe mekius (~mekius@enlightenment/developer/mekius) |
09:02.43 | *** join/#oe woglinde (~heinold@g225144255.adsl.alicedsl.de) |
09:10.58 | *** join/#oe mekius (~mekius@enlightenment/developer/mekius) |
09:15.18 | *** join/#oe pvanhoof (~pvanhoof@d54C0C0BA.access.telenet.be) |
09:26.29 | *** join/#oe bala_holmes (~7aa4bab8@gateway/web/freenode/x-ywcekiqlnzbbwvta) |
09:31.03 | *** join/#oe cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net) |
09:31.36 | *** join/#oe recalcati (~5e51e963@gateway/web/freenode/x-vrobcwslgcpdcclt) |
09:31.46 | recalcati | godd morning |
09:32.33 | mckoan | recalcati: dog morning |
09:32.58 | recalcati | the compilation was succesful. |
09:33.09 | recalcati | right morning |
09:35.14 | mckoan | recalcati: good to know :-D |
09:38.46 | CIA-2 | 03Michael Lippautz <michael.lippautz@gmail.com> 07org.openembedded.dev * reb2093fa76 10openembedded.git/recipes/lighttpd/lighttpd.inc: |
09:38.47 | CIA-2 | lighttpd: Add configuration to CONFFILES. |
09:38.47 | CIA-2 | Signed-off-by: Michael Lippautz <michael.lippautz@gmail.com> |
09:40.22 | *** join/#oe bala_holmes (~7aa4bab8@gateway/web/freenode/x-ufsckvjzmtsrfmjq) |
09:41.00 | CIA-2 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rb34c4a2a27 10openembedded.git/recipes/xorg-lib/ (6 files in 2 dirs): pixman git: update to 0.17.13, update NEON patches |
09:42.56 | *** join/#oe grma (~gruberm@chello212186029093.tirol.surfer.at) |
09:45.41 | *** join/#oe dth_ntb (~dieter@a89-182-221-79.net-htp.de) |
09:46.21 | CIA-2 | 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r96b8c73a38 10openembedded.git/recipes/xorg-lib/ (2 files in 2 dirs): pixman git: revert a commit that breaks thumb, reported by Martin Jansa |
09:48.25 | *** join/#oe MWelchUK_work (~welchma@65.91.2.71) |
09:48.37 | bala_holmes | Hi, I have mailed my patches to dev list, I like to know status through pwclient. Help me, how to use pwclient, and conf files required? |
09:49.24 | *** join/#oe fpga (~s@92.62.56.51) |
09:50.05 | *** join/#oe rob_w (~bob@p549BE138.dip.t-dialin.net) |
09:55.22 | *** join/#oe hrw|gone (~hrw@chello089078170228.chello.pl) |
10:02.52 | *** join/#oe Openfree` (~Openfreer@116.228.88.98) |
10:29.53 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
10:31.14 | ao2 | mickeyl, if you have a min can you look at http://bugs.openembedded.org/show_bug.cgi?id=5385 please? Thanks. And, should I give fso2-* a try? I plan to put my hands on openezx again this weekend. |
10:32.44 | *** join/#oe siji (~siji@122.170.9.183) |
10:33.19 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r527c307f33 10openembedded.git/recipes/mplayer/mplayer_git.bb: |
10:33.20 | CIA-2 | mplayer_git: use same SRC_URI for all, additional patch in glamo repo won't hurt as it's enabled only in EXTRA_OECONF |
10:33.20 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
10:35.44 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
10:35.53 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r1b95116648 10openembedded.git/recipes/libxml/libxml2_2.7.7.bb: |
10:35.54 | CIA-2 | libxml2: add version 2.7.7 |
10:35.54 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
10:35.55 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r4cf9229119 10openembedded.git/conf/distro/include/sane-srcrevs-fso.inc: frameworkd: bump SRCREV |
10:37.23 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
10:46.09 | *** join/#oe Sleep_Walker (~Sleep@nat/novell/x-yzobhgwvzzfiafhq) |
10:49.15 | *** join/#oe ade|desk (~ade|desk@195.153.131.254) |
10:52.00 | siji | hey all, Still am looking for a solution for mouse with in console |
10:53.52 | *** join/#oe fpga (~s@92.62.56.51) |
10:54.49 | dm8tbr | attach a mouse! |
10:57.42 | siji | :) |
10:58.12 | siji | it's already attached :( |
10:58.14 | mickeyl | ao2: i will take a look. we're currently in transition phase, that means some of the services in fso2 are read for primetime (usage, device, data, tdld), but some others are not yet finished (gsm,gps). Unfortunately fso2 has not seen any integration work for EZX, since I did not know whether it would be in a state that justifies this work (as you know). It should not be complicated to bring fso2 to openezx, in fact due to it being C, it should run much better |
10:58.14 | mickeyl | than FSO1 ever did. If you are serious about "finishing" the kernel, then I volunteer to spend some time on the integration when i'm back from austria (1th of April). |
11:01.47 | *** join/#oe likewise (~likewise@82-171-51-231.ip.telfort.nl) |
11:03.28 | hrw | morning |
11:03.36 | likewise | gm |
11:07.21 | ao2 | mickeyl, I'll let you know then, for now I keep testing with fso1 which should be faster for prototyping, I mean to edit .py files directly on target rootfs, this should work, shouldn't it? |
11:07.50 | mickeyl | correct |
11:08.21 | mickeyl | that's the beauty of fso1, with fso2 we're again in develop-compile-test mode |
11:08.30 | ao2 | what image do you suggest me to use? fso-zhone-image? or -paroli? |
11:08.33 | mickeyl | can't get both the cake and eat it though ;) |
11:08.39 | mickeyl | paroli is dead |
11:08.51 | mickeyl | for integration work I'd use zhone |
11:08.56 | mickeyl | it's simpler than full SHR |
11:09.00 | ao2 | thanks again |
11:09.03 | mickeyl | np |
11:09.12 | Ainulindale | paroli is dead? |
11:09.18 | ao2 | mickeyl, I'll get back to you when I have something |
11:09.19 | Ainulindale | I thought it wasn't |
11:09.24 | *** join/#oe Laibsch (~Laibsch@p5B3B268E.dip.t-dialin.net) |
11:12.23 | mickeyl | ao2: awesome, thanks |
11:12.42 | mickeyl | Ainulindale: i don't see anyone working on it except the pyneo guys |
11:13.00 | mickeyl | that counts for me as dead ;) |
11:13.15 | mickeyl | by now they probably ripped out fso support ;) |
11:15.07 | Ainulindale | mickeyl: heh |
11:19.56 | mickeyl | hmm |
11:20.01 | mickeyl | guadec this year in netherlands |
11:20.28 | mickeyl | i should've proposed a paper for when it was on the canarian islands rather than for this year :D |
11:20.31 | mickeyl | oh well... |
11:20.46 | *** join/#oe dcordes (~dccordes@unaffiliated/dcordes) |
11:21.36 | *** join/#oe Heinervdm_ (~thomas@pD9E14984.dip.t-dialin.net) |
11:21.41 | Crofton | rofl |
11:21.46 | eFfeM-work | siji, console as text console, or do you mean x windows |
11:21.54 | Crofton | mickeyl, it shows you spent time in grad school |
11:22.20 | eFfeM-work | mickeyl: don't complain about having the opportunity to go to the netherlands ;-) |
11:22.22 | siji | I want to enable it with out X |
11:22.33 | Crofton | eFfeM-work, I was thinking that also :) |
11:22.56 | siji | am having one clutterr apps , which is running on eglnative |
11:23.14 | eFfeM-work | actually lots of Germans enjoy to come to the netherlands, look at our coasts in summer or Venlo on saturday |
11:23.42 | eFfeM-work | siji: if you run clutter you run some form of windowing sw (guess X, don't know about egl) |
11:23.44 | mickeyl | well |
11:24.05 | mickeyl | there's this urban legend about dutch and germans not really having the right chemistry ;) |
11:24.25 | eFfeM-work | mickey actually i think dutch beaches are more pop with germans than the canarian isles |
11:24.32 | *** join/#oe _Sat_Man (~satman@83.141.3.41) |
11:24.32 | eFfeM-work | mickeyl: only if it comes to soccer |
11:24.34 | mickeyl | hehe |
11:25.05 | siji | not exactly , Eglnative means it's running on FB |
11:25.09 | siji | frame buffer |
11:25.14 | *** join/#oe dent (U2FsdGVkX1@linux.fjfi.cvut.cz) |
11:25.18 | *** join/#oe jkridner (~a0321898@pdpc/supporter/active/jkridner) |
11:25.19 | *** join/#oe signal11_ (esteban@gnv.quaddro.net) |
11:25.27 | *** join/#oe valhalla_ (~valhalla@81-174-24-67.dynamic.ngi.it) |
11:25.30 | *** join/#oe Blinder_ (~othmar@h081217021188.dyn.cm.kabsi.at) |
11:25.33 | siji | And I read some where that gpm will solve my prblm |
11:25.37 | *** join/#oe janinges (j@ninge.net) |
11:25.38 | eFfeM-work | siji but i have problems with mouse and kbd sometimes too with beagle, no idea what causes it, guess it is a usb thingie (beagle has some more usb flakes that my nslu2 did not have) |
11:25.42 | eFfeM-work | no idea on gpm |
11:25.51 | siji | ok |
11:26.24 | siji | but here my keyboard and mouse is working fine with beagle , i mean X is detecting those |
11:26.32 | siji | by using usb hub |
11:26.53 | siji | ok , what i did that i created one reciepe for gpm |
11:27.12 | *** join/#oe NeverBest (~nb@d216-232-103-156.bchsia.telus.net) |
11:27.14 | eFfeM-work | ah ok, well don't know gpm so can't really help you with that (and 35 km away from my beagle) |
11:27.32 | siji | ok |
11:32.53 | *** join/#oe mekius (~mekius@enlightenment/developer/mekius) |
11:33.30 | *** join/#oe mrc3_ (~ddiaz@189.157.114.15) |
11:34.14 | *** join/#oe alphaone (~alphaone@2001:638:602:af01::1) |
11:34.32 | *** join/#oe Splat1 (~Splat1@rf1.splat1.com) |
11:34.46 | *** join/#oe XorA|gone (~XorA@www.xora.org.uk) |
11:35.04 | *** join/#oe guillaum1 (~gl@AMontsouris-153-1-75-57.w90-2.abo.wanadoo.fr) |
11:35.30 | *** join/#oe likewise_ (~likewise@82-171-51-231.ip.telfort.nl) |
11:36.05 | *** join/#oe thebohemian (~rschus@p5DDC1B4A.dip.t-dialin.net) |
11:37.39 | siji | eFFew-work,as i told u while creating ipk |
11:37.56 | siji | OE generated only gpm*-dev and gpm*-dbg |
11:38.03 | siji | is it fine |
11:39.43 | siji | i mean , i think normaly it will generate three ipk files right? |
11:42.18 | *** join/#oe dcordes (~dccordes@unaffiliated/dcordes) |
11:43.32 | CIA-2 | 03Tom 'TAsn' Hacohen <tom@stosb.com> 07org.openembedded.dev * rbdeef9865b 10openembedded.git/recipes/shr/e-wm-config-illume2-shr_git.bb: |
11:43.32 | CIA-2 | e-wm-config-illume2-shr: Added shr-e-gadgets to RDEPENDS |
11:43.32 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
11:43.52 | CIA-2 | 03Tom 'TAsn' Hacohen <tom@stosb.com> 07org.openembedded.dev * r06fc7fa5e1 10openembedded.git/recipes/shr/shr-e-gadgets_git.bb: |
11:43.52 | CIA-2 | shr-e-gadgets: new recipe for e17 gadgets |
11:43.52 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
11:48.13 | siji | eFFew-work, u there |
11:48.22 | siji | I have enabled it in ubuntu |
11:48.25 | siji | working fine |
11:48.35 | siji | but now need to enable it with Angstrom |
11:48.51 | siji | can pls have a look on my receipe |
11:52.11 | mikeul | siji, I think you're spelling eFFeM-work nick wrong, maybe it's not jumping out at him. |
11:56.22 | *** join/#oe otavio (~otavio@debian/developer/otavio) |
11:58.36 | *** join/#oe mario-goulart (~user@67.205.85.241) |
12:05.47 | eFfeM-work | siji, actually was afk for lunch |
12:06.24 | eFfeM-work | if you post it somewhere i can have a peek at your recipe (but really the log has the interesting stuff |
12:06.48 | eFfeM-work | siji: beware of messages like NOTE; file /a/b/xyz is not in any package |
12:06.59 | eFfeM-work | and yes, I would expect also a non-dev pkg |
12:12.11 | *** join/#oe zecke (~ich@123-192-181-204.dynamic.kbronet.com.tw) |
12:12.43 | siji | ya |
12:12.45 | siji | wil do |
12:18.17 | *** part/#oe spaetz (~spaetz@195.190.188.219) |
12:20.12 | siji | <eFfeM-work>, u there |
12:21.00 | *** join/#oe meindian523 (~easwarh@unaffiliated/easwar) |
12:26.04 | *** join/#oe filip (~filip@filip.math.uni.lodz.pl) |
12:26.08 | filip | hi |
12:26.08 | *** join/#oe fpga (~s@92.62.56.51) |
12:26.15 | filip | who can I bug about http://bugs.openembedded.org/show_bug.cgi?id=5413 ? |
12:27.34 | eFfeM-work | siji: what's up |
12:27.55 | siji | hey i was talking in Clutter IRC |
12:28.32 | siji | and clutter eglnative is only enabled for tslib |
12:28.39 | siji | means only for touch screen |
12:29.09 | siji | evdev is not supported my eglnative clutter |
12:31.51 | eFfeM-work | ah ok, that explains things |
12:32.54 | siji | so now let me try to add a patch on clutter ;) |
12:33.01 | siji | anyway thanks alot |
12:36.42 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
12:38.35 | methril_work | morning |
12:39.35 | *** part/#oe meindian523 (~easwarh@unaffiliated/easwar) |
12:46.37 | eFfeM-work | siji: gl & have fun :-) |
12:46.47 | siji | :) |
12:50.46 | *** join/#oe mickeyl (~mickey@openmoko/coreteam/mickey) |
12:52.54 | *** join/#oe rob_w (~bob@p549BE138.dip.t-dialin.net) |
13:00.41 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rb2df355282 10openembedded.git/recipes/xorg-lib/ (13 files): |
13:00.41 | CIA-2 | pixman: add pixman.inc, unify recipes, remove do_stage from few old versions, add 0.17.12 with positive D_P |
13:00.41 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
13:04.25 | *** join/#oe rob_w (~bob@p549BE138.dip.t-dialin.net) |
13:05.30 | *** join/#oe jpieper (~jpieper@209-6-37-232.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) |
13:07.19 | *** join/#oe MWelchUK_work (~welchma@65.91.2.71) |
13:11.27 | *** join/#oe jkridner (~a0321898@pdpc/supporter/active/jkridner) |
13:23.15 | *** join/#oe hexor (~thehexa@189-19-251-152.dsl.telesp.net.br) |
13:26.55 | *** join/#oe BenLauDC (~benlau@221.125.8.44) |
13:29.52 | FOM | Anyone up for an oe build question today? Google is being most unhelpful :-( |
13:30.24 | *** join/#oe mikeul (~509888f5@gateway/web/freenode/x-bvqtqkelvafuxebz) |
13:31.21 | FOM | On two different machines, when building OE, running task 441, that's recipes/udev/attr_2.4.44.bb, in the do_install() function, something goes crazy and spawns multiple 'make' processes that choke the machine. Ideas? |
13:32.19 | *** join/#oe alecrim (~alecrim@189.2.128.130) |
13:45.33 | RP | morning all |
13:45.41 | woglinde | hi tp |
13:45.43 | woglinde | ups rp |
13:50.15 | *** join/#oe jpieper (~jpieper@209-6-37-232.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) |
13:50.32 | pb_ | hi rp |
13:50.36 | woglinde | hi pb |
13:50.40 | pb_ | hi woglinde |
13:50.42 | *** join/#oe mekius (~mekius@enlightenment/developer/mekius) |
13:52.35 | *** join/#oe rsalveti (~rsalveti@200.184.118.130) |
14:03.20 | *** join/#oe kristoffer (~kristoffe@95.209.191.141.bredband.tre.se) |
14:06.08 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r1405e1aabe 10openembedded.git/recipes/tasks/task-shr-feed.bb: |
14:06.08 | CIA-2 | task-shr-feed: add shr-theme-02 |
14:06.08 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
14:06.18 | CIA-2 | 03Jesus McCloud <bernd.pruenster@gmail.com> 07org.openembedded.dev * r2ed9ffad20 10openembedded.git/recipes/shr/ (3 files): |
14:06.18 | CIA-2 | shr-theme-o2: new recipes for o2 theme |
14:06.18 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
14:06.31 | *** join/#oe GNUtoo|oeee (~GNUtoo@host237-136-dynamic.2-87-r.retail.telecomitalia.it) |
14:07.54 | *** join/#oe jpieper (~jpieper@209-6-37-232.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) |
14:15.28 | *** join/#oe aloisiojr (~aloisio@200.184.118.130) |
14:16.00 | *** join/#oe kergoth_ (~clarson@ip24-251-170-95.ph.ph.cox.net) |
14:16.06 | *** join/#oe th1_ (~th@pdpc/supporter/professional/th1) |
14:18.32 | mickeyl | hmm |
14:18.36 | mickeyl | was that pixman update tested? |
14:18.42 | mickeyl | | arm-oe-linux-gnueabi-libtool: link: cannot find the library `/data/pkg/oe/dream/tmp/staging/armv6-novfp-oe-linux-gnueabi/usr/lib/libpixman-1.la' or unhandled argument `/data/pkg/oe/dream/tmp/staging/armv6-novfp-oe-linux-gnueabi/usr/lib/libpixman-1.la' |
14:23.02 | mickeyl | BBCLASSEXTENDS seems to have broken -b |
14:23.14 | mickeyl | mickey@amethyst:/local/pkg/oe/dream$ bitbake -b ../openembedded/recipes/xorg-lib/pixman_0.17.12.bb |
14:23.14 | mickeyl | ERROR: Parsing error data_fn virtual:native:/data/pkg/oe/openembedded/recipes/xorg-lib/pixman_0.17.12.bb and fn /data/pkg/oe/openembedded/recipes/xorg-lib/pixman_0.17.12.bb don't match |
14:25.12 | RP | mickeyl: I think that is fixed on master at least |
14:26.05 | mickeyl | hmm, kj |
14:30.24 | hrw | s/master/HEAD/ |
14:32.06 | *** join/#oe robtow (~rob@64.62.142.114) |
14:33.31 | *** join/#oe mikc (~mick@delta360.server4you.de) |
14:35.25 | mikc | Hi, I am working on the integration of the i.MX25 card from Freescale in OpenEmbedded. I am not sure on the right way of handling the kernel patches for this board |
14:37.22 | mikc | They are distributed by Freescale as part of a LTIB release, and are packaged in a 2M tar.bz2 file |
14:38.26 | mikc | Should I integrate the file in recipes/linux/linux-2.6.28/mx25_3stack/ , or decompress it first? |
14:38.50 | hrw | do not use '_' in machine name |
14:38.50 | RP | mikc: Can you not just use a URL to it or the patches? |
14:38.58 | MWelchUK_work | mikc, It might be worth checking they haven't pushed the support back already. |
14:39.02 | mikc | sorry, I meant - |
14:40.02 | MWelchUK_work | mikc, They seem to push patches back, but not always exactly as they appear in LTIB |
14:43.03 | *** join/#oe eFfeM (~eFfeM_wor@atwork-193.r-212.178.107.atwork.nl) |
14:44.01 | *** join/#oe Moz (~me@81.179.238.144) |
14:44.05 | mikc | MX25 is not in mainline kernel |
14:44.19 | MWelchUK_work | Really? |
14:44.30 | MWelchUK_work | mikc, http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=8c25c36f33157a2e2a1fcd60b6dc00feace80631 |
14:49.00 | mikeul | what does "psp" mean in 'linux-omap-psp-2.6.32'? |
14:52.39 | mickeyl | JaMa: pixman 0.16.2 no longer builds for me after the update |
14:53.57 | mikc | Hmm... There is no mx25_3stack_defconfig in official, but commits referring to i.mx25. Do you know if this sfr/linux-next tree will be pulled ? |
14:55.53 | mickeyl | RP: any plans to backport the fix? |
14:56.00 | mickeyl | RP: or do we require master now? |
14:56.03 | mickeyl | or HEAD |
14:56.05 | mickeyl | or whatever |
14:56.38 | hrw | tomorrow will be 6 years since my first OE contribution |
14:56.42 | hrw | time flies |
14:56.45 | mickeyl | indeed |
14:58.45 | CIA-2 | 03Steffen Sledz <sledz@dresearch.de> 07org.openembedded.dev * rf583e41692 10openembedded.git/recipes/linux/linux-2.6.24/hipox/defconfig: |
14:58.45 | CIA-2 | linux-2.6.24: enable ftdi_sio module for hipox machine |
14:58.46 | CIA-2 | Signed-off-by: Steffen Sledz <sledz@dresearch.de> |
15:00.11 | *** join/#oe dth_ntb (~dieter@p4FDECEE6.dip.t-dialin.net) |
15:01.18 | mikc | RP: I don't have a mirror at hand to host these easily |
15:05.03 | XorA | mikeul: Platform Support Package |
15:08.50 | kergoth | hrw: seriously? damn.. what's the project's age as a whole now, a bit more than that? |
15:08.58 | kergoth | wonders where the time goes |
15:09.15 | mikc | Is such a big pack of patches likely to be accepted in OE? |
15:10.13 | mikc | Or should I definitely find a way to mirror them somewhere? |
15:10.13 | MWelchUK_work | mikc, I picked the wrong tree- they are in torvalds tree as well. |
15:10.32 | mikc | really? ow I missed that |
15:10.58 | *** join/#oe claudiuM (~claubu@157.27.141.18) |
15:12.21 | mikc | it recent :/ I just pulled and it appeared |
15:12.39 | mikc | (I pulled yesterday from stable....) |
15:12.58 | MWelchUK_work | mikc, it might not have gone back with that name, or if it's like the ppc stuff, there may be a common defconfig for multiple boards. |
15:13.45 | *** part/#oe thebohemian (~rschus@p5DDC1B4A.dip.t-dialin.net) |
15:13.50 | mikc | let's give it a try... |
15:14.12 | mikc | OK, so it is not the same way as in LTIB |
15:14.22 | mikc | I'll look at that |
15:15.33 | MWelchUK_work | mikc, probably not. I think they have an internal team that hack things together for the LTIB, then a team that cleans it up for mainline |
15:16.08 | MWelchUK_work | mikc, clearly the community may also object to how things have been done and thus changes must be made. |
15:16.16 | *** join/#oe oneshel (~jim@c-98-216-198-0.hsd1.nh.comcast.net) |
15:16.52 | RP | mickeyl: I didn't release 1.8 was broken. I would like people to start using master tbh |
15:16.53 | broonie | MWelchUK_work: For i.MX? Freescale have no involvmenet with mainline. |
15:17.04 | RP | There is no good reason not to anymore |
15:17.05 | *** join/#oe eFfeM (~eFfeM_wor@atwork-193.r-212.178.107.atwork.nl) |
15:17.30 | mikc | it looks like it is pengutronix.de who pushes that. i.MX25 3DS appears in menuconfig |
15:17.44 | MWelchUK_work | broonie, ok, it's someone else then |
15:17.45 | broonie | Yes, pengutronix are upstream as far as the kernel is concerned. |
15:18.00 | MWelchUK_work | Hence why the patches are probably very different. |
15:18.31 | broonie | Well, they do frequently base their work on the FSL stuff but sometimes that's not so good. |
15:18.49 | broonie | The FSL i.MX2x stuff is basically abandoned at this point, their newer stuff is much more mainlinable. |
15:22.47 | mikc | hum..error: linux/fec.h: No such file or directory |
15:23.10 | mikc | I should have missed something... |
15:23.26 | mickeyl | RP: ok, same error in HEAD |
15:24.10 | RP | mickeyl: That is odd as I regularly use -b |
15:26.16 | RP | mickeyl: I wonder if there is something odd about that recipe? :/ |
15:26.25 | Jin^eLD | mhm.. I added curl to my RDEPENDS but no matter what I do it does not end up on the rootfs... am I missing something? |
15:26.33 | *** join/#oe rob_w (~bob@p549BB638.dip.t-dialin.net) |
15:26.41 | RP | Jin^eLD: check the package and see if its a dependency? |
15:26.45 | mikc | MWelchUK_work: thanks for the help |
15:26.51 | RP | Jin^eLD: RDEPENDS variable being overwritten somewhere? |
15:26.55 | MWelchUK_work | mikc, np |
15:27.12 | Jin^eLD | RP: nope, not for this package, for instance, I had "file" in RDEPENDS and it got installed correctly |
15:27.20 | Jin^eLD | so puzzled about why it is ignoring curl |
15:28.22 | Jin^eLD | although now I see that for some reason nothing from RDEPENDS from this package is being taken.. grml |
15:29.30 | Jin^eLD | curl was even built, the ipk is available |
15:29.48 | RP | check the package that is meant to depend on it |
15:30.11 | RP | Also, bitbake -b X -e | grep ^RDEPENDS |
15:30.28 | RP | Jin^eLD: There isn't an RDEPENDS and an RDEPENDS_$packagename set are there? |
15:30.51 | Jin^eLD | RP: no, only RDEPENDS = "blah" |
15:32.14 | Jin^eLD | lets see what grep spits out... |
15:32.44 | hrw | kergoth: 2003-06-02 21:19:02 was "Initial repository create" by you |
15:33.00 | kergoth_ | ah. |
15:33.04 | hrw | http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=bda361cba6cf49d92d21f44c87a9d2f13511d551 |
15:33.16 | kergoth_ | so nearly 7 years.. boggles the mind |
15:33.36 | Jin^eLD | RP: there are indeed several RDEPENDS and RDEPENDS_packagename when I do the grip thing |
15:33.37 | Jin^eLD | http://pastebin.mozilla.org/709123 |
15:33.41 | Jin^eLD | total of 3 |
15:34.02 | Jin^eLD | is it because of inheriting update-rc.d? |
15:34.15 | RP | Jin^eLD: most likely, I've seen that before |
15:34.35 | Jin^eLD | hm, so what do you suggest? RDEPENDS_${PN} += "curl"? |
15:34.42 | RP | Jin^eLD: yes |
15:34.56 | RP | Jin^eLD: Looking at the log that is exactly your problem |
15:35.09 | Jin^eLD | thanks |
15:35.14 | RP | kergoth_: Scary timescales :) |
15:36.06 | *** part/#oe mikc (~mick@delta360.server4you.de) |
15:36.42 | RP | kergoth_: It was May that year I got a Zaurus iirc |
15:37.05 | hrw | I got Zaurus in Feb 2004 |
15:37.10 | RP | September I cracked the 2.6 kernel boot problem |
15:37.21 | RP | and the rest is history |
15:38.13 | kergoth_ | I don't remember exactly when I got mine, it was a ways before oe started though, during the developer program |
15:38.44 | hrw | kergoth: you started OpenZaurus and then migrated it to be OpenEmbedded |
15:38.52 | kergoth_ | yeah |
15:38.57 | hrw | s/migrated it/migrated it's build system/ |
15:39.27 | kergoth_ | OZ existed for a while before this, originally just a modified rom, then everything building in a buildroot.. pretty sure it was the first buildroot with kconfig :) |
15:39.33 | kergoth_ | gets all nostalgic |
15:39.46 | hrw | I got OE booting on sl5500 |
15:40.10 | RP | kergoth_: I jumped straight into the c760 zaurus ;-) |
15:40.13 | hrw | you guys gave me r/w due to that |
15:40.20 | oneshel | I remember my sl5500 and C700 :) |
15:40.55 | hrw | I remember day when people on #oe congratulated me getting c760 and I did not had idea what they are talking about |
15:41.16 | kergoth_ | hehe |
15:41.19 | hrw | until I read oesf forums to notice that one guy from Australia gave me c760+wifi |
15:41.20 | khem | gm all |
15:41.35 | Jin^eLD | RP: that did work, thanks again |
15:41.47 | kergoth_ | I think I still have an sl5600 with stickers on it saying its not supposed to hit the public, EVER |
15:42.00 | RP | Jin^eLD: np, been there before. We should make that easier to catch (e.g. by banning RDEPENDS on its own) |
15:42.01 | hrw | kergoth: ;D |
15:43.19 | Jin^eLD | RP: but RDEPENDS on its on in a recipe is valid? in this case it was just not processed correctly? |
15:43.34 | RP | Jin^eLD: its valid but conflicts with what that class does |
15:43.38 | Jin^eLD | i.e. I should not switch to always using RDEPENDS_${PN}... |
15:43.42 | Jin^eLD | I see... |
15:43.42 | RP | Jin^eLD: and its also not recommened |
15:43.53 | *** join/#oe kroylar (~kroylar@cpe-76-175-27-8.socal.res.rr.com) |
15:43.53 | RP | you should be using RDEPENDS_${PN}, always |
15:44.13 | Jin^eLD | oh ok, will fix my recipes then |
15:44.52 | RP | kergoth_: I remember in 2003 when you announced it would take about a year to get OE going. That seemed like an eternity to me |
15:45.21 | kergoth_ | Jin^eLD: INHERIT += "recipe_sanity"; bitbake -c recipe_sanity somerecipe may be of use, checks for certain common issues / potential cleanups |
15:45.48 | mickeyl | RP: no, breaks for me for every recipe with classextends |
15:45.56 | pb_ | RP: recipe_sanity already checks for plain RDEPENDS |
15:46.00 | mickeyl | are you sure you don't have some noncommitted diffs? |
15:46.00 | Jin^eLD | kergoth: ah, cool, thanks |
15:46.34 | RP | mickeyl: when you said HEAD, was this the 1.8 branch or master? |
15:46.58 | mickeyl | master |
15:47.12 | RP | mickeyl: Something odd is going on :( |
15:47.18 | RP | There shouldn't be any differences like that |
15:48.25 | RP | pb_: great, that sounds like a good start |
15:48.28 | kergoth_ | RP: I wonder if in the future we should merge version branches back into master on a regular basis to keep things from deviating in both directions. its pretty common, i think thats how the git folks do their maint branch |
15:52.25 | RP | kergoth_: or we stop having long lived branches. 1.8 has been around way too long |
15:52.34 | kergoth_ | well, that too ;) |
15:52.54 | RP | kergoth_: I see 1.10 being a lot less painful in that regard |
15:53.10 | RP | Just need to get on and do it... |
15:53.29 | RP | I'd just want to merge the layers patch really |
15:53.33 | RP | has been thinking a lot about stamps issues |
15:53.49 | RP | I can see a case for dropping stamps and replacing them with checksums |
15:54.14 | kergoth_ | I like the idea of per task output tracking and such that you proposed, but I expect it will be awfully invasive. what I suggested could be done entirely in the metadata in a weekend of work |
15:54.26 | kergoth_ | ponders |
15:54.57 | RP | kergoth_: I just don't want to start on a solution which fixed 25% of the problem, then leaves us facing a wall :/ |
15:55.20 | RP | kergoth_: I'm kind of resigned to the fact we'll need to change bitbake in some way to make it work better |
15:55.33 | RP | and that isn't a bad thing as long as we do it properly |
15:55.38 | kergoth_ | basically, I want what e2factory has, damnit |
15:55.44 | kergoth_ | but with the stuff we have that it doesn't |
15:55.45 | kergoth_ | :) |
15:55.54 | RP | kergoth_: this is what I want too |
15:56.12 | RP | hence my desire to thrown away stamps entirely and replace with checksums |
15:56.22 | RP | The stamp code is so so broken :/ |
15:56.26 | kergoth_ | I could see using e2factory for bringup or something, but it just doesn't have what we have |
15:56.31 | kergoth_ | agreed |
15:56.38 | kergoth_ | then the hacks on top of it for pstage just made it messier |
15:56.42 | kergoth_ | necessary, but messy |
15:56.58 | RP | right |
15:57.13 | RP | I tried to push the model we had, the cracks appeared |
15:57.30 | filip | can I draw attention to a specific buzilla entry somehow? |
15:57.33 | kergoth_ | the worry I have with checksums is that more than just the output of dependent tasks feeds into the task |
15:57.42 | kergoth_ | metadata does as well, and we don't track what variables are used by what tasks |
15:58.14 | RP | kergoth_: I have an idea about this - why not checksum the actual functions we run for a given task? |
15:58.57 | kergoth_ | that's not enough. |
15:58.57 | kergoth_ | that covers changing the function, not changing the variables that it uses |
15:59.29 | RP | kergoth_: if you cover the expanded version? |
15:59.49 | RP | ignoring the fact that we'd have to avoid the different paths changing things |
15:59.49 | kergoth_ | and what about d.getVar()? |
16:00.24 | RP | Hmm, I'm primarily thinking of shell functions |
16:00.45 | kergoth_ | python tasks are tasks too, you need a way to handle both, if you plan to replace stamps |
16:00.48 | RP | kergoth_: I think we're going to end up with this and a list of variables |
16:01.14 | RP | kergoth_: Well, encapsulating any data into the checksum is better than the current stamps approach ;-) |
16:01.24 | kergoth_ | that's a pain to maintain, but does work |
16:01.33 | RP | kergoth_: right |
16:02.03 | RP | kergoth_: I'd love a better idea but thats what I'm currently thinking |
16:02.09 | kergoth_ | the problem i see is, if you use a whitelist, the failure mode is use of bad content, particularly for pstage |
16:02.17 | kergoth_ | blacklist, the failure mode is just re-executing the task |
16:02.24 | kergoth_ | if you see what i mean |
16:02.33 | RP | I do and I agree |
16:02.48 | RP | There are only 400 ish variables so how hard can it be :) |
16:03.30 | kergoth_ | I'd say more if I wasn't restrained by NDA |
16:03.37 | kergoth_ | but it is viable |
16:06.25 | marekp | anyone who knows how to activate CONFIG_FB_CFB_SYS_COPYAREA (and friends) in the kernel config? i'm using devshell and i modify .config before the build, that normaly works fine, but somehow this options get overwritten, i don't know why... |
16:08.10 | Jin^eLD | marekp: I do not remember exactly anymore, either I had to copy .config to the appropriate defconfig place, and/or also one directory up (I think ther is a copy of it there that comes from the recipe) |
16:08.26 | Jin^eLD | it's been too long.. but something like that |
16:12.12 | marekp | yea i know what file (../defconfig) you mean, so i have to overwrite it maybe |
16:12.37 | marekp | ok i try that, thanks |
16:12.52 | mckoan | I have a doubt about the recipe recipes/linux/linux_2.6.28.bb |
16:13.02 | mckoan | SRC_URI = "${KERNELORG_MIRROR}/pub/linux/kernel/v2.6/linux-2.6.28.tar.bz2 \ ${KERNELORG_MIRROR}/pub/linux/kernel/v2.6/patch-${PV}.10.bz2;patch=1 \ file://defconfig" |
16:13.13 | Jin^eLD | marekp: yes, thats what I meant, you copy your newly generated .config over the ../defconfig file |
16:13.26 | mckoan | what is the value of ${PV} here? |
16:13.43 | hrw | 2.6.28 of course |
16:14.18 | mckoan | yes sorry |
16:14.24 | hrw | recipe name is PN-PV.bb and linux_2.6.28.bb does not change PV in recipe |
16:14.45 | hrw | http://marcin.juszkiewicz.com.pl/2010/03/19/how-time-flies/ btw |
16:14.58 | mckoan | I don't know why I saw patch-${PV}.10.bz2 but I read patch-2.6.28-${PV}.10.bz2 |
16:15.10 | hrw | happens |
16:15.48 | mckoan | hrw: happy anniversary |
16:15.55 | hrw | thx |
16:16.24 | hrw | will spend most of time on visiting furniture shops probably |
16:17.37 | marekp | btw. i had to modify the .config because normal recipe is not creating a working kernel for my at91sam9260... the architecture is not set to AT91 and some other options are missing... what i dont understand is, that the defconfig in the image directory (output) seems to look perfect, but i did not trace down on that. |
16:17.51 | mckoan | hrw: I also thought to celebrate 30th anniversary of the bought of my first computer :-D |
16:17.55 | mckoan | http://en.wikipedia.org/wiki/ZX80 |
16:18.51 | kergoth_ | RP: thoughts on http://github.com/kergoth/OpenEmbedded/commits ? |
16:20.57 | hrw | stupid question I have |
16:21.13 | RP | kergoth_: The siteinfo one is interesting - I think CONFIG_SITE should be moved into autotools but we should still inherit it in base |
16:21.14 | hrw | why there are adduser and useradd commands? |
16:21.23 | hrw | cannot one of them be symlink to other? |
16:21.34 | RP | kergoth_: I remember trying this a while back and did see a lot of subtle breakage without it :/ |
16:21.35 | kergoth_ | RP: it's only used by a handful of recipes other than autotools, though |
16:21.43 | pb_ | hrw: they do different things. iirc, adduser is a frontend to useradd. |
16:21.51 | kergoth_ | I grepped and added the inherit to anyone using its variables or functions, in that commit |
16:21.53 | RP | kergoth_: I guess you searched and caught them all? |
16:22.00 | RP | kergoth_: fair enough |
16:22.09 | khem | hrw: debian does not prefer useradd but RH does |
16:22.23 | mckoan | hrw: I asked the same question many times |
16:22.46 | kergoth_ | RP: how does that split look as a starting point? we can always move things from there, but it makes it a bit easier to get your head around, I think |
16:22.48 | mckoan | or better I should say I wondered the sme many times |
16:22.57 | hrw | in OE land we have useradd from shadow but adduser in tinylogin |
16:23.18 | mckoan | hrw: and I NEVER rmember which one is my favourite |
16:23.32 | RP | kergoth_: the webbrowser on this machine is braindead and choked on the larage patch, one second :) |
16:23.37 | kergoth_ | haha, oops |
16:25.15 | khem | hrw: yes useradd comes fro shadow |
16:25.32 | kergoth_ | useradd/adduser always confuses me, i know one is a frontend to the other, but i can never, ever remember which to use |
16:25.36 | kergoth_ | that naming was idiotic |
16:25.37 | RP | kergoth_: I totally agree with those patches |
16:25.50 | RP | kergoth_: One thing though - can we time them with the same changes in Poky, please :) |
16:25.55 | *** join/#oe kristoffer (~kristoffe@95.209.78.208.bredband.tre.se) |
16:25.57 | kergoth_ | sure, that's fine with me |
16:26.15 | RP | kergoth_: You can add my Acked-by and push if you like ;-) |
16:27.00 | hrw | kergoth_: mine too |
16:27.11 | kergoth_ | okay, thanks |
16:27.15 | khem | hrw: useradd implements SUS behaviour so its same on all distros but adduser is a convinience script which can vary on distros |
16:27.32 | RP | kergoth_: I'd like to see most of utils.bbclass moving into a bitbake based python library like bb.utils |
16:27.33 | kergoth_ | RP: should I go ahead and push today then? will you pull it into poky today, or do you want to hold off? |
16:27.36 | kergoth_ | agreed |
16:27.45 | RP | kergoth_: go for it, I'll do Poky to match |
16:28.11 | kergoth_ | okay, let me do a couple final sanity checks, then i'll push it |
16:28.12 | hrw | kergoth_: if you are afraid of breakage then commit on Monday |
16:28.29 | hrw | this will give you (and us) trouble free weekend ;) |
16:28.34 | kergoth_ | hehe |
16:28.43 | kergoth_ | I should be around this weekend, though, I don't mind babysitting |
16:29.18 | *** join/#oe NvrBst (~nb@d216-232-103-156.bchsia.telus.net) |
16:30.23 | hrw | "Use of this historical codebase is strongly discouraged" - tinylogin d: |
16:32.03 | hrw | someone here has non-Debian based distro running? |
16:32.18 | Jin^eLD | hrw: Fedora 12 here |
16:32.51 | *** join/#oe mekius (~mekius@enlightenment/developer/mekius) |
16:32.52 | hrw | Jin^eLD: which language is 'adduser' written in? |
16:32.57 | kergoth_ | just fired up a centos 5.4 VM, but is still getting the necessary packages installed |
16:33.17 | Jin^eLD | hrw: let me see |
16:33.26 | hrw | after ending cooperation with OpenedHand I dropped all Fedora VM images |
16:34.20 | Jin^eLD | hrw: I'll fetch the sources of the rpm, /usr/sbin/adduser is a binary file but I would assume c or c++, or were you thinking of it as in "what script language"? |
16:34.22 | *** join/#oe robtow (~rob@12.156.66.34) |
16:34.31 | woglinde | hrw *g* |
16:34.59 | hrw | woglinde: those crazy people which wanted to run Poky on FedoraCore4... |
16:35.07 | Jin^eLD | hrw: so.. is the info "it's an ELF" enough for you or do you want me to check what sources they are using? |
16:35.35 | hrw | would be nice to grab source |
16:36.12 | Jin^eLD | it's from the shadow-utils package, let me see... |
16:36.38 | hrw | Jin^eLD: 0.10 or newer? |
16:36.54 | Jin^eLD | shadow-utils-4.1.4.2-2.fc12.x86_64 |
16:37.04 | Jin^eLD | I'm fetching the source rpm now |
16:37.23 | hrw | thx |
16:37.28 | Jin^eLD | np |
16:38.08 | Jin^eLD | URL: http://pkg-shadow.alioth.debian.org/ |
16:38.08 | Jin^eLD | Source0: ftp://pkg-shadow.alioth.debian.org/pub/pkg-shadow/shadow-%{version}.tar.bz2 |
16:38.17 | Jin^eLD | and version is Version: 4.1.4.2 |
16:38.24 | hrw | so we go back to base ;D |
16:38.32 | Jin^eLD | and there are 4 patches used |
16:38.57 | Jin^eLD | I can put the spec file online if you want to see what they are using/doing |
16:39.13 | hrw | would be great |
16:39.25 | Jin^eLD | try http://www.deadlock.dhs.org/jin/shadow-utils.spec |
16:39.26 | hrw | officially I do not know anything about rpm packages |
16:39.35 | hrw | got it |
16:39.40 | Jin^eLD | I could say the same about .deb packages :> |
16:40.15 | Jin^eLD | if you want those patches too I could extract the source rpm and tar it up for you |
16:40.39 | hrw | would be nice |
16:40.43 | hrw | you know my email |
16:40.53 | Jin^eLD | I'll just put it onlone, will be faster |
16:40.57 | Jin^eLD | if you dont mind |
16:41.01 | hrw | sure, fine |
16:41.37 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
16:42.30 | hrw | ha! shadow has contrib/ dir with adduser stuff |
16:42.33 | Jin^eLD | try http://www.deadlock.dhs.org/jin/shadow-utils-fc12.tar its everything extracted from the source rpm, including the original sources |
16:43.21 | hrw | got it |
16:43.48 | Jin^eLD | k |
16:45.28 | filip | does Koen hang around here? |
16:45.37 | filip | s/hang/hang out/ |
16:46.03 | Jin^eLD | ~seen koen |
16:46.06 | ibot | koen <n=koen@s55917625.adsl.wanadoo.nl> was last seen on IRC in channel #oe, 827d 6h 39m 43s ago, saying: 'I forgot to commit that portion yesterday'. |
16:46.11 | filip | aww |
16:46.16 | filip | it's been a while |
16:46.31 | hrw | ~seen _koen_ |
16:46.31 | ibot | hrw: i haven't seen '_koen_' |
16:46.36 | filip | I need him to look at one bug |
16:46.41 | hrw | filip: /join #beagle |
16:46.45 | filip | in gtk+ |
16:47.11 | filip | hrw: thanks for the hint :) |
16:47.57 | hrw | filip: nie ma za co |
16:48.16 | filip | ;) |
16:51.04 | *** join/#oe bkero (~freenode@osuosl/staff/bkero) |
16:53.31 | JaMa | mickeyl: do you have log? |
16:54.28 | *** join/#oe robtow (~rob@12.156.66.34) |
16:55.35 | mickeyl | JaMa: : http://vala.pastebin.com/PmXNGtx5 |
16:57.49 | JaMa | mickeyl: EXTRA_OECONF = "--disable-gtk" as in 0.17 should be enough, but I'm curious why this issue is shown only now |
16:59.52 | mickeyl | thanks |
17:00.27 | JaMa | I'll push it now |
17:00.36 | hrw | ln -s useradd $RPM_BUILD_ROOT%{_sbindir}/adduser - nice way Fedora ;D |
17:01.14 | *** join/#oe matgnt (~matthias@z0701.wist.uni-linz.ac.at) |
17:07.17 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r68710643f0 10openembedded.git/recipes/xorg-lib/pixman_0.16.2.bb: |
17:07.17 | CIA-2 | pixman_0.16.2: disable gtk (as done in 0.17.*, to break circular dependency gtk+->cairo->pixman->gtk+ and also libtool issue |
17:07.17 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
17:08.23 | woglinde | hrw lol |
17:13.21 | hrw | have a nice weekend everybody |
17:30.10 | marekp | hi anyone that as experience with gpe-dm ? in my case, it is starting a lot of xserver instances until my memory is used up. |
17:31.46 | RP | kergoth_: Are you still planning to land those patches today? |
17:37.37 | *** join/#oe mnabil (~mnabil@41.234.71.95) |
17:41.55 | *** join/#oe chouimat (~mathieu@kde/developer/chouinard) |
17:43.07 | CIA-2 | 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * re0503768af 10openembedded.git/classes/base.bbclass: |
17:43.07 | CIA-2 | base.bbclass: Add note about base_path_relative |
17:43.07 | CIA-2 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
17:43.08 | CIA-2 | 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * r89b7e43371 10openembedded.git/ (7 files in 2 dirs): |
17:43.08 | CIA-2 | Initial split of base.bbclass |
17:43.08 | CIA-2 | Acked-by: Richard Purdie <rpurdie@linux.intel.com> |
17:43.08 | CIA-2 | Acked-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |
17:43.08 | CIA-2 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
17:43.09 | CIA-2 | 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * ra215c2f283 10openembedded.git/ (13 files in 10 dirs): |
17:43.09 | CIA-2 | Don't inherit siteinfo in base.bbclass |
17:43.11 | CIA-2 | Acked-by: Richard Purdie <rpurdie@linux.intel.com> |
17:43.11 | CIA-2 | Acked-by: Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> |
17:43.11 | CIA-2 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
17:43.40 | kergoth | RP: k, done |
17:47.04 | RP | kergoth: cool :) |
17:47.20 | chouimat | hi |
17:47.48 | RP | hi chouimat |
17:48.08 | *** join/#oe mrc3_ (~ddiaz@189.157.114.15) |
17:48.15 | chouimat | grrr not allowed to irc from new job's office :( |
17:48.59 | RP | chouimat: sounds like a challenge? ;-) |
17:49.37 | chouimat | RP: let's just I'm working from home today and I'm not sure I will renew the contract in June |
17:50.11 | RP | chouimat: fair enough |
17:50.56 | *** join/#oe MWelchUK (~martyn@82.152.154.75) |
17:51.01 | chouimat | it's more application development than system development ... and the team who designed the platform I have to work with should be killed |
17:52.34 | chouimat | RP: the best computer on my desk is wasted by running XP and outlook ... the linux box I got is a nice 400Mhz P2 or P3 ... |
17:54.49 | kergoth_ | pb_: ping |
17:54.54 | pb__ | kergoth: yo |
17:55.40 | kergoth_ | pb__: for multi-version in one recipe, I'm thinking a "BBVERSIONS" which lists them *all*, rather than a BBVERSIONEXTEND which adds to the original, since the former would allow 'nano.bb', ignoring the default 1.0 variant. thoughts? |
17:55.41 | *** join/#oe jmpdelos (~polk@outgoing.delos.com) |
17:56.08 | pb__ | kergoth: yeah, that would work. I had been thinking in terms of a wildcard expression of some kind. |
17:56.10 | chouimat | ok to see why when I use gtk the window show on this crappy device but xlib directly doesn't work |
17:56.35 | kergoth_ | hmm, that could work too, alternatively we could generate the list of versions with a snippet |
17:56.44 | pb__ | kergoth: I guess you could make it a regex, which would allow you to either enumerate specific versions as alternatives, or have a more general match. |
17:57.00 | pb__ | the nice thing about a wildcard is that you don't necessarily have to update the .bb every time a new version gets released. |
17:57.35 | pb__ | bbiab, gotta go collect my daughter from town |
17:57.54 | kergoth_ | true, but wouldn't it have to contact the remote server at parse time to get the list, unless you want it to match 1.<anything>, and let the version preference control whether it'll be used.. but it could create extranious datastore instances for versions that don't really exist if you do that |
17:58.00 | RP | The question is where the data this regexp works against is generated? |
17:58.05 | kergoth_ | right |
17:58.17 | RP | parser fetching over networks causes problems |
17:58.23 | RP | been there, done that :/ |
17:58.32 | RP | How many people like SRCREV? :) |
17:58.32 | kergoth_ | if its just a space separated list, it leaves it up to the metadata to determine how to generate that list |
17:58.37 | kergoth_ | guh :) |
17:58.43 | RP | kergoth_: agreed |
17:59.12 | kergoth_ | so, is it agreed that its more useful to do a BBVERSIONS and drop the base datastore from the variants if set, as opposed to a BBVERSIONEXTEND? |
17:59.18 | kergoth_ | what do you think? |
17:59.36 | pb__ | kergoth: well, in my particular use-case, the versions would all be nailed down externally in a .conf file of some kind. but yeah, I guess you do have a bit of an issue around what to do if the user doesn't specify a version. |
17:59.47 | pb__ | -> |
17:59.56 | RP | pb_: skip the file? |
18:00.10 | kergoth_ | hmm |
18:00.21 | RP | kergoth_: I can see a list being a more sane implementation in this case |
18:00.23 | kergoth_ | well, it could pull bbversions from the finalised store, so you could use a _pn-whatever override |
18:00.40 | RP | kergoth_: What have we created? :) |
18:00.55 | kergoth_ | hehe |
18:01.12 | RP | FOO_pn-bar_virtclass-native_pv-1.0 = "X" |
18:01.19 | kergoth_ | haha |
18:01.49 | kergoth_ | i'd still like to see a new file format, or a variatn of this one, which allows override blocks |
18:01.51 | kergoth_ | 1.0 ( |
18:01.52 | kergoth_ | a = b |
18:01.53 | kergoth_ | c = d |
18:01.54 | kergoth_ | ) |
18:02.01 | kergoth_ | 2.0 ( native ( a = 42 ) ) |
18:02.04 | kergoth_ | or something |
18:02.32 | RP | hmm, .bb2 ? |
18:02.40 | kergoth_ | yeah, perhaps |
18:02.54 | RP | Change the override character to % as well? |
18:03.04 | kergoth_ | while we're at it, change how +=/=+/.=/=./_prepend/_append work too |
18:03.48 | RP | add a -= operator |
18:03.56 | RP | kergoth_: How would you change them? |
18:04.19 | kergoth_ | oh, i really want values to be able to be python objects, with typing, too |
18:04.20 | RP | add something to allow variable to be deleted as well... |
18:04.21 | kergoth_ | </pipe dream> |
18:04.56 | kergoth_ | just imagine for a in d.getVar("SOMELIST", True) with no .split() crap ;) |
18:05.07 | khem | Can we also add version deps like x-1.2 DEPENDS y-3.4 |
18:05.11 | kergoth_ | but when exported, gets str()d into something useful for shell |
18:05.26 | RP | khem: We could do that now, its a bitbake internals issue |
18:05.39 | RP | khem: I made the parser accept the syntax years ago |
18:05.51 | khem | ok cool |
18:05.58 | khem | I will try it out |
18:06.05 | RP | khem: It doesn't do anything ;-) |
18:06.12 | khem | heh |
18:06.18 | RP | khem: but it won't break the parser which is great for backwards compatibility |
18:06.31 | khem | oh can we add OBSOLETES |
18:06.50 | RP | kergoth_: nice idea :) |
18:07.07 | RP | kergoth_: Seriously though, how would you change the += .+ _prepend ? |
18:08.11 | kergoth_ | I'm not sure, but the some things being lazy and others being immediate causes confusion in general |
18:08.16 | kergoth_ | include/require/inherit also |
18:08.18 | khem | e.g. if recipe b obsoletes a it then bitbake should not build a if b is already built |
18:08.19 | kergoth_ | needs further thought |
18:08.57 | kergoth_ | I've often thought that we could make all classes inherited between the config metadata and the class, always before. if the class wants to do something based on a varaible the recipe sets, it can just do so more lazily |
18:09.28 | RP | kergoth_: right, hmm |
18:09.30 | MWelchUK | Hi guys, gypsy_svn is failing to download. |
18:09.33 | khem | kergoth: may be we should add a preprocess step |
18:09.50 | RP | MWelchUK: Use the git repo from freedesktop.org |
18:10.16 | RP | OH svn services are slowly being killed off |
18:10.20 | khem | to evaluate variable assignments |
18:10.45 | MWelchUK | RP, OK, cheers. |
18:12.52 | *** join/#oe jovox (~jovox@h142n3c1o279.bredband.skanova.com) |
18:13.03 | *** join/#oe jd (~jd@modemcable207.134-202-24.mc.videotron.ca) |
18:13.03 | *** join/#oe jd (~jd@Wikipedia/HellDragon) |
18:14.52 | RP | git push poky |
18:15.00 | RP | gah :) |
18:19.33 | *** join/#oe etrunko (~edulima@187.106.19.157) |
18:23.32 | kergoth_ | hmm |
18:23.43 | kergoth_ | RP: I can't recall, does it work to do SOMEVAR_oneoverride_anotheroverride? |
18:35.20 | *** join/#oe woglinde_ (~heinold@g229044177.adsl.alicedsl.de) |
18:39.46 | *** join/#oe Hasse (~quassel@0x5552e721.adsl.cybercity.dk) |
18:41.22 | *** join/#oe dth_ntb (~dieter@p4FDECEE6.dip.t-dialin.net) |
18:49.36 | soxet | how is FILESPATHBASE searched? libpam-base-files.bb is failing with 256. SRC_URI = "file://pam.d/*" but the files that it wants are in libpam-base-files |
18:50.23 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rbad798fb3b 10openembedded.git/conf/distro/include/sane-srcrevs.inc: (log message trimmed) |
18:50.23 | CIA-2 | EFL: bump SRCREV |
18:50.23 | CIA-2 | * Ecore_data/Ecore_txt was removed so few OLD apps/libs are not |
18:50.24 | CIA-2 | buildable anymore |
18:50.24 | CIA-2 | * etk/epsilon will be moved to obsolete |
18:50.24 | CIA-2 | * other recipes only updated DEPENDS where possible |
18:50.24 | CIA-2 | * more info: |
18:50.26 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r049e78d95f 10openembedded.git/recipes/efl1/epdf_svn.bb: |
18:50.26 | CIA-2 | epdf: disable deprecated etk |
18:50.26 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
18:50.27 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r4ed7c11430 10openembedded.git/conf/distro/shr.conf: |
18:50.27 | CIA-2 | shr: use binutils 2.20.1 |
18:50.28 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
18:50.28 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rcfd545deb8 10openembedded.git/recipes/efl1/esmart_svn.bb: |
18:50.29 | CIA-2 | esmart: drop epsilon dependency, then we won't get thumb |
18:50.29 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
18:51.16 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r7b52a85404 10openembedded.git/recipes/tasks/ (5 files): |
18:51.16 | CIA-2 | tasks: remove etk/epsilon from task recipes |
18:51.17 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
18:51.44 | pb__ | re |
18:52.21 | pb__ | kergoth: actually, thinking about that multi-version thing more, I guess you would/could still have a default version specified in the .bb if the user doesn't pick another, just to make "bitbake foo" work. |
18:53.21 | *** part/#oe woglinde_ (~heinold@g229044177.adsl.alicedsl.de) |
18:54.19 | kergoth_ | bitbake foo would work either way, the question is just whether or not we keep the default version / variant |
18:54.26 | kergoth_ | what I'm thinking is, if y> |
18:54.26 | kergoth_ | > |
18:54.41 | kergoth_ | I'm thinking if you want that, you could list it in the variable |
18:55.13 | kergoth_ | hmmm |
18:57.35 | kergoth_ | RP: thoughts on the add of PV to overrides for bbversions? base.bbclass or bitbake? with bitbake, it could combine the variants, add 1.0-virtclass-native to overrides for each combination |
18:57.48 | kergoth_ | ponders |
18:58.29 | kergoth_ | pb__: I figured the default version would be used for the case where the variable isn't set, but what i was wondering was whether to retain the default version + default datastore when the user *does* set it, and I think its agreed that the answer is "no" |
18:59.44 | pb__ | kergoth: it is fairly important to me that you be able to build multiple versions of the same package in a single bitbake run. |
19:00.33 | kergoth_ | i don't see a problem with that, its no different than the extendclass stuff |
19:00.39 | pb__ | kergoth: but, there is no need to retain the default version if it isn't going to be built. |
19:01.16 | kergoth_ | the question was one of usability, not ram usage. does the variable list versions in addition to default, or list all versions you want generated |
19:01.58 | pb__ | ah, I see. well, I still feel that the variable should be a regex, not a simple list :-} |
19:02.21 | kergoth_ | well, as i said earlier probably after you left, the problem is what to apply the regex against |
19:02.26 | kergoth_ | poking at upstream at parse time is .. iffy |
19:02.59 | pb__ | right, but I don't think it should be necessary to poke at upstream; you just need to match it against the version that has been requested by the user. |
19:03.19 | *** join/#oe mnabil (~mnabil@41.234.71.95) |
19:03.46 | kergoth_ | but as you already said, its critical to be able to build multiple versions in one run, so how do you make the determination of which versions the user requested? |
19:03.53 | kergoth_ | and where? at parse time, that information isn't yet available |
19:04.20 | pb__ | the user needs to supply it via either dependencies or the command line. "bitbake foo-1.2 foo-1.3" for example. |
19:05.22 | kergoth_ | yes, but again, the question is how to mak ethat determination. you'd have to examine the runqueue |
19:05.27 | kergoth_ | which isn't generated until after the parse |
19:05.32 | kergoth_ | yet parse time is where variants are generated |
19:05.41 | kergoth_ | you'd have to make more fundamental changes |
19:06.35 | kergoth_ | hmm |
19:07.29 | pb__ | yes, it would require some changes to how bitbake thinks about versions. |
19:09.41 | kergoth_ | well, to support BBVERSIONS = "1.0.0 2.0.7 2.0.9 git" or something can work today, using the same mechanisms as bbclassextend. we can always enhance the bbversions varaible to support wildcards/regexes |
19:14.09 | *** join/#oe woglinde (~heinold@g229044177.adsl.alicedsl.de) |
19:15.26 | kergoth_ | ponders |
19:15.48 | *** join/#oe woglinde_ (~heinold@g229044162.adsl.alicedsl.de) |
19:18.47 | pb__ | yeah, true |
19:24.36 | soxet | ok libpam-base-files does not build possibly because I have prepended my overlay files path to FILESPATHBASE. I fixed it by setting SRC_URI = "file://libpam-base-files" instead of the pam.d/* glob |
19:26.38 | sakoman | is anyone else seeing bizzare behaviour after today's base.bbclass checkin? |
19:26.57 | kergoth_ | what sort of behavior? |
19:27.08 | kergoth_ | seems fine here, so far anyway :) |
19:27.51 | sakoman | for example: openssl-native is rebuilt with every bitbake command |
19:28.17 | sakoman | i.e. if I bitbake tslib, openssl-native is rebuilt from scratch |
19:28.27 | kergoth_ | as far as i know it didn't actually change anything, only moved things around |
19:28.59 | sakoman | if I do a bitbake openssl-native it completes successfully, but then is rebuilt again on the next bitbake command! |
19:29.22 | kergoth_ | hmm |
19:29.33 | *** join/#oe d_t_h (~dieter@p4FDEC35B.dip.t-dialin.net) |
19:29.51 | kergoth_ | odd |
19:29.54 | kergoth_ | looking into it |
19:30.09 | oneshel | anyone have an example of using 'test' in a u-boot script? |
19:32.37 | *** join/#oe Hasse (~quassel@0x5552e721.adsl.cybercity.dk) |
19:33.34 | kergoth_ | sakoman: going to bitbake -e openssl-native before and after the change, see what differs |
19:36.06 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r185e4f64ec 10openembedded.git/recipes/images/shr-image.inc: |
19:36.06 | CIA-2 | shr-image: use install_linguas |
19:36.06 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
19:36.06 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r02d4ca6802 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: |
19:36.06 | CIA-2 | preferred-shr-version: update automake to 1.11.1 |
19:36.07 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
19:36.07 | CIA-2 | 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rd6f29aecf1 10openembedded.git/recipes/efl1/ (ecore-native_svn.bb ecore.inc ecore_svn.bb): |
19:36.07 | CIA-2 | ecore: convert BBCLASSEXTEND |
19:36.08 | CIA-2 | * different EXTRA_OECONF weren't used for -native as the diff seems |
19:36.08 | CIA-2 | rather unintentional when OECONF was updated only in non-native |
19:36.09 | CIA-2 | version, feel free to add it if really needed |
19:36.09 | CIA-2 | Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> |
19:38.30 | *** join/#oe woglinde (~heinold@g225073133.adsl.alicedsl.de) |
19:39.24 | *** join/#oe sgh (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
19:48.13 | mickeyl | pb__: master? |
19:50.46 | *** join/#oe sgh_ (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
19:57.27 | *** join/#oe sgh (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
19:57.47 | *** join/#oe mekius (~mekius@enlightenment/developer/mekius) |
20:00.00 | *** join/#oe Laibsch (~Laibsch@p5B3B268E.dip.t-dialin.net) |
20:02.43 | kergoth_ | Anyone have any thoughts on possibly moving the add of the override to OVERRIDES in bitbake rather than the classes, for bbclassextend / bbversions? |
20:02.52 | kergoth_ | isnt sure how he feels about it |
20:04.20 | sakoman | kergoth_: do you see the same openssl issue? |
20:05.04 | kergoth_ | working on something for work at the moment, hold |
20:05.14 | sakoman | OK |
20:07.27 | *** join/#oe mnabil (~mnabil@41.234.71.95) |
20:13.58 | pb__ | mickeyl: good evening |
20:14.54 | *** join/#oe mpr (~mpr@aggr.com) |
20:14.54 | *** join/#oe kerute (~kerute@kerunix.com) |
20:14.54 | *** join/#oe dijenerate (~dijenerat@64.210.44.37) |
20:14.54 | *** join/#oe CSMan (~csman@unaffiliated/csman) |
20:14.54 | *** join/#oe CosmicPenguin (~nobody@129-46-14-212.qualcomm.com) |
20:14.54 | *** join/#oe kgilmer (~kgilmer@firebug.buglabs.net) |
20:14.54 | *** join/#oe kurre (~tomimo@xdsl-83-150-88-111.nebulazone.fi) |
20:14.54 | *** join/#oe tharvey (~tharvey@adsl-76-205-222-173.dsl.snlo01.sbcglobal.net) |
20:14.54 | *** join/#oe Try`0xff (~Tryum@e-corporation.info) |
20:14.54 | *** join/#oe akheron (~akheron@lilja.asteriski.fi) |
20:14.55 | *** join/#oe CIA-2 (cia@208.69.182.149) |
20:14.57 | *** join/#oe filip (~filip@filip.math.uni.lodz.pl) |
20:15.00 | *** join/#oe gt3 (~geetha@nat/ti/x-wrjthybwzvuhjcbh) |
20:15.00 | *** join/#oe ChrisD1 (~ChrisD@dsl-217-155-59-204.zen.co.uk) |
20:15.00 | *** join/#oe PuffTheMagic (~quassel@unaffiliated/puffthemagic) |
20:15.00 | *** join/#oe Zygo (startkeylo@startkeylogger.hungrycats.org) |
20:15.00 | *** join/#oe pitillo (~pitillo@84.123.96.129.dyn.user.ono.com) |
20:15.00 | *** join/#oe BillK (~BillK@203-206-49-109.dyn.iinet.net.au) |
20:15.00 | *** join/#oe borg_ (~olaf@80.149.17.21) |
20:15.00 | *** join/#oe keith (meshuga@adsl-69-87-6-143.dsl.irvnca.interirc.net) |
20:15.20 | *** join/#oe vivijim (~vivijim@pasanda.collabora.co.uk) |
20:15.20 | mickeyl | hi pb__ |
20:15.24 | mickeyl | i have something very strange going on |
20:15.28 | *** join/#oe mpr (~mpr@aggr.com) |
20:15.31 | mickeyl | i will show you a small exceprt of source code |
20:15.41 | mickeyl | which runs fine on i686 |
20:15.46 | mickeyl | but crashes with a null pointer on arm |
20:16.01 | mickeyl | perhaps you spot something obvious that would be dangerous on arm |
20:16.10 | *** join/#oe janinge (j@ninge.net) |
20:16.26 | mickeyl | pb__: please have a brief look at https://bugzilla.gnome.org/show_bug.cgi?id=613343 |
20:22.34 | broonie | mickeyl: Looks like the sim entry copy is doing something unfortunate? |
20:24.09 | mickeyl | broonie: no, it is null beforehand |
20:24.39 | mickeyl | it is null right after |
20:24.46 | mickeyl | fso_gsm_abstract_at_command_to_int () |
20:24.54 | mickeyl | err, wrong |
20:24.57 | mickeyl | entry = (...) |
20:25.15 | mickeyl | and i can't really see what could go wrong there :/ |
20:25.27 | broonie | Eh, 683 is the first one where a nil is reported? |
20:26.04 | broonie | Oh, hang on. The code doesn't tie in with the log message. |
20:26.31 | mickeyl | yeah, sorry, it was one debugging run earlier :/ |
20:26.37 | mickeyl | didn't change the behaviour though |
20:26.39 | pb__ | mickeyl: ok, I'll have a look |
20:26.44 | mickeyl | pb__: thanks |
20:26.52 | broonie | It does mean that it's harder to tie the error report in with teh code :/ |
20:26.55 | mickeyl | every g_message ("atcommands.vala:678: number = %p", |
20:26.55 | mickeyl | number) was ok |
20:27.11 | mickeyl | every g_message ("atcommands.vala:681: number = %p, |
20:27.11 | mickeyl | name = %p", entry.number, entry.name); showed nil for number |
20:27.39 | pb__ | right, so it gets number wrong when you read it out of entry? |
20:27.40 | mickeyl | i have since then change the arguments, but it's always the 2nd argument in the newly born struct that stays null |
20:27.47 | mickeyl | yeah |
20:27.59 | mickeyl | if i manually set it after the init |
20:27.59 | mickeyl | like |
20:28.07 | mickeyl | entry.number = "foo"; |
20:28.09 | mickeyl | then it stays ok |
20:28.10 | pb__ | what does free_smartphone_gsm_sim_entry_copy() look like? |
20:28.46 | pb__ | er, sorry, _init() not _copy() |
20:29.58 | *** join/#oe hillct_ (~hillct@cpe-069-134-049-165.nc.res.rr.com) |
20:30.30 | mickeyl | one second, it's in another library... |
20:31.39 | mickeyl | http://vala.pastebin.com/FWwR1hZc |
20:32.30 | mickeyl | uuuuuuuh |
20:32.50 | mickeyl | hmm |
20:32.57 | pb__ | hm, that doesn't look very good |
20:33.03 | mickeyl | that's somewhat strange |
20:33.07 | pb__ | <PROTECTED> |
20:33.16 | pb__ | surely the argument to strdup() should be "numbe", not the old value |
20:33.37 | mickeyl | wah |
20:34.46 | mickeyl | ok, so the init func is completely bogus |
20:35.07 | pb__ | yeah, it is hard to see how that code could work correctly on any arch |
20:35.24 | mickeyl | hmm |
20:35.36 | mickeyl | let me diff that with the code that gets generated on my desktop |
20:35.46 | pb__ | it is fairly clear from inspection that the "numbe" argument doesn't go anywhere: it's only used in that one g_return_if_fail(). |
20:36.07 | pb__ | right, good plan |
20:36.22 | mickeyl | ah! |
20:36.24 | mickeyl | void free_smartphone_gsm_sim_entry_init (FreeSmartphoneGSMSIMEntry *self, gint index, const char* name, const char* number) { |
20:40.55 | mickeyl | ok, while that's a good find, i wonder how that can happen |
20:41.02 | mickeyl | it's the same vala version |
20:41.09 | mickeyl | just one is compiled by OE |
20:41.15 | mickeyl | and the other one compiled manually |
20:41.24 | mickeyl | (vala-native, actually) |
20:42.46 | pb__ | that is rather weird. might be worth diffing the config.status files to see if the oe version is picking up any bogosity from the site files. |
20:42.57 | mickeyl | oh yeah |
20:44.40 | *** join/#oe Hasse (~quassel@0x5552e721.adsl.cybercity.dk) |
20:45.44 | mickeyl | i'm afraid it's quite cluttered :/ |
20:45.45 | mickeyl | http://pastebin.ca/1846041 |
20:46.31 | pb__ | hrm. different autoconf versions, I guess |
20:46.40 | pb__ | or different versions of some .m4 file or other |
20:46.42 | mickeyl | yeah |
20:46.52 | mickeyl | hmm, the variables part might be interesting |
20:47.00 | mickeyl | -max_cmd_len='1572864' |
20:47.00 | mickeyl | +max_cmd_len='98304' |
20:47.06 | mickeyl | should not hurt though |
20:47.55 | pb__ | yeah. that is weird, but seems like it ought to be harmless. |
20:48.12 | pb__ | rest of the vars look ok to me |
20:48.21 | mickeyl | hmm, k |
20:48.33 | pb__ | so... dunno. very strange. |
20:48.57 | mickeyl | let me check whether it swallows every last character of struct inits |
20:49.05 | mickeyl | i guess it should blow up in that case |
21:02.14 | pb__ | heh, I wonder why our landlord thought it was a good idea to install a 130dB siren in our computer room. |
21:05.08 | mickeyl | wah, that's a tad bit on the loud side |
21:06.46 | mickeyl | pb__, broonie: thanks for helping. playya_ and me just found it. the problem is actually in our code, the code we had seen was generated from a Vala source that is generated itself from specs... and as a matter of fact the spec-generator in the preferred version (0.1.3) that is in OE had the bug cutting the last char from the signature :)) |
21:08.57 | *** join/#oe GNUtoo (~GNUtoo@host237-136-dynamic.2-87-r.retail.telecomitalia.it) |
21:09.43 | *** join/#oe EsbenH (~EsbenH@0x55532124.adsl.cybercity.dk) |
21:09.45 | CIA-2 | 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * re399e99d25 10openembedded.git/recipes/dnsmasq/ (dnsmasq-dbus_2.52.bb dnsmasq.inc dnsmasq_2.52.bb): |
21:09.45 | CIA-2 | dnsmasq: add version 2.52 |
21:09.45 | CIA-2 | Fixes CVE-2009-2957 and CVE-2009-2958 among other things. |
21:09.45 | CIA-2 | Signed-off-by: Roman I Khimov <khimov@altell.ru> |
21:09.50 | playya_ | mickeyl, the strange thing is that it strdups the self.number |
21:09.55 | CIA-2 | 03Roman I Khimov <khimov@altell.ru> 07org.openembedded.dev * r6476a15dfc 10openembedded.git/recipes/dnsmasq/ (dnsmasq.inc files/init): |
21:09.55 | CIA-2 | dnsmasq: add status check to init file |
21:09.55 | CIA-2 | Signed-off-by: Roman I Khimov <khimov@altell.ru> |
21:11.10 | playya_ | it seems to be a follow up |
21:11.23 | playya_ | it tries to replace itself |
21:11.42 | playya_ | maybe we should file a bug for this case |
21:18.55 | *** join/#oe GNUtoo (~GNUtoo@host237-136-dynamic.2-87-r.retail.telecomitalia.it) |
21:19.33 | mickeyl | yeah |
21:19.43 | mickeyl | Vala should really warn us |
21:19.51 | mickeyl | a self assignment does not make sense usually |
21:24.42 | *** join/#oe robtow (~rob@12.156.66.34) |
21:27.18 | CIA-2 | 03Michael 'Mickey' Lauer <mickey@vanille-media.de> 07org.openembedded.dev * redfd4c4dd6 10openembedded.git/recipes/vala-dbus-binding-tool/ (2 files): vala-dbus-binding-tool: 0.1.3 -> 0.1.4 |
21:33.56 | woglinde | hm by the way, can someone please delete my gettext-branch it isnt needed anymore |
21:35.16 | *** join/#oe Torne (torne@rockbox/developer/Torne) |
21:38.43 | *** part/#oe Torne (torne@rockbox/developer/Torne) |
21:38.49 | MWelchUK | oestats seems to be failing for me, but I'm not sure why. |
21:39.53 | MWelchUK | I thought it was because I was trying to use "tinderbox.openembedded.org" instead of "http://tinderbox.openembedded.net", but that doesn't seem to work for me either :-s |
21:44.20 | MWelchUK | Ah! I'm using bitbake master - think this is a known issue. |
21:44.35 | *** join/#oe robtow (~rob@12.156.66.34) |
21:44.47 | kergoth_ | bitbake has nothing to do with that |
21:44.59 | kergoth_ | its a class in oe |
21:46.27 | MWelchUK | kergoth_, http://www.mail-archive.com/bitbake-dev@lists.berlios.de/msg00723.html |
21:47.56 | *** join/#oe MWelchUK (~martyn@82.152.154.75) |
21:48.47 | kergoth_ | ahh right, i stand corrected :) |
21:50.46 | *** join/#oe hansdampf (~moritz@rgnb-4d0413e6.pool.mediaWays.net) |
21:50.52 | MWelchUK | kergoth_, I think I'll start using 1.8 branch for now :-) |
21:52.20 | *** part/#oe EsbenH (~EsbenH@0x55532124.adsl.cybercity.dk) |
21:52.22 | JaMa | kergoth_: hehe :P |
21:53.38 | kergoth_ | argh.. |
21:53.46 | kergoth_ | kicks bitbake/lib/bb/cache.py |
22:03.25 | kergoth_ | sakoman: if i bitbake openssl-native, then bitbake openssl-native again, it does nothing. i'll try building tslib |
22:03.33 | kergoth_ | hmmm |
22:03.40 | kergoth_ | wait, nevermind, bad test |
22:03.44 | kergoth_ | grumbles |
22:06.59 | *** join/#oe ant__ (~andrea@host66-229-dynamic.58-82-r.retail.telecomitalia.it) |
22:09.38 | *** join/#oe nevarrie (~jgrant@206.55.114.249) |
22:10.03 | *** join/#oe mekius (~mekius@enlightenment/developer/mekius) |
22:22.07 | pb__ | mickeyl: aha, very good |
22:22.58 | ant__ | hey pb__ |
22:23.53 | pb__ | hi ant__ |
22:24.05 | mickeyl | waves goodbye -- see you in a week after our small vacation |
22:24.48 | kergoth_ | sakoman: k, looking into it |
22:26.02 | pb__ | mickey|vacation: enjoy |
22:26.08 | mickey|vacation | thanks |
22:29.37 | ant__ | pb__: I'm amazed by the hot thread running on linux-arm-kernel about armv6 vs. highmem. Very interesting bug-chase... |
22:30.41 | ant__ | ...and this time Russel got bitten by Nicolas and Catalin ;) |
22:31.24 | ant__ | that's indeed a 'hierarchical' mailing list |
22:31.28 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
22:37.10 | pb__ | heh. I haven't read the linux-arm-kernel list for about five years. |
22:39.29 | RP | pb__: Be thankful ;-) |
22:39.46 | RP | kergoth_: Yes, we have expand multiple overrides as long as they're in the right order |
22:40.05 | RP | kergoth_: Whether it should be added to OVERRIDES in bitbake or by the class, good question |
22:40.19 | RP | kergoth_: In the class case there wasn't much complexity by doing it in the class |
22:40.21 | ant__ | pb__: I had to approach it, was waiting for the LZMA patches |
22:40.21 | kergoth_ | I think i'll go with the classes for now, to keep the code in bitbake a bit simpler |
22:40.25 | kergoth_ | nods |
22:40.46 | RP | kergoth_: For versions I suspect it adds a lot of complexity? |
22:40.58 | RP | kergoth_: or are you writing a class for this? |
22:41.23 | ant__ | pb__: now that we talk, I remember we lack support for cpio.lz and co. |
22:41.31 | kergoth_ | not *that* much complexity, i had a version where each set of variants built on top of the previous one for constructing combined overrides and combined values for the returned dictionary |
22:41.42 | kergoth_ | but it definitely added some code |
22:41.43 | ant__ | I mean, LZO will be soon replacing gz |
22:43.19 | ant__ | iirc this is the suggested compressor for initramfs and kernel, for arm |
22:43.34 | RP | kergoth_: right, I can imagine that |
22:44.56 | kergoth_ | got bit when he had a version that didn't return a "" entry, and various other little quirks he didn't account for at first :) |
22:45.37 | pb__ | ant__: yeah, I don't think that'd be very hard to do. |
22:45.39 | RP | kergoth_: heh, that class extend code wasn't big but it certainly was scary :) |
22:45.54 | pb__ | bedtime now |
22:45.56 | pb__ | night all |
22:46.38 | kergoth_ | :) |
22:46.42 | kergoth_ | night pb__ |
22:46.51 | RP | 'night pb__ |
22:46.54 | ant__ | 'nite |
22:47.40 | RP | kergoth_: I'm going to apply this base.bbclass split to poky, then get some sleep ;-) |
22:48.21 | kergoth_ | sakoman ran into an issue, its rebuilding things it doesn't have to, very weird, consdiering it just moves bits, shouldn't change anything |
22:48.24 | kergoth_ | is looking into it |
22:48.27 | *** join/#oe ash_ (~ash@s64-180-61-141.bc.hsia.telus.net) |
22:49.23 | ash_ | hi. I'm a user of OE. |
22:49.32 | RP | kergoth_: Have you seen it too? |
22:49.52 | ash_ | a recent patch came through for the cmake.bbclass from Roman |
22:49.54 | kergoth_ | just did, yeah. bitbake openssl-native; bitbake openssl-native -- it builds it both times |
22:50.05 | kergoth_ | scans the classes in the hopes that its obvious :) |
22:50.46 | kergoth_ | found it |
22:50.58 | RP | kergoth_: I'm curious... |
22:51.07 | ash_ | I have tried applying the patch on machine as it was suggested I 'ack' it |
22:51.35 | ash_ | the patch seems to do what it is supposed to...what is involved in Ack-ing it? |
22:52.04 | XorA | ash_: just reply to the list and put Acked-by: You Name <eail@blah> |
22:52.10 | RP | ash_: Reply to the patch on the mailing list with an Acked-by line as per the linux kernel development model. Please ensure you understand what that means |
22:53.07 | ash_ | okay - thanks for the explanation. I had looked on the OE site for guidance but I didn't think to look at Linux |
22:54.30 | CIA-2 | 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * r1369fef494 10openembedded.git/classes/base.bbclass: |
22:54.30 | CIA-2 | base: erk, don't remove do_setscene from EXPORT_FUNCTIONS, silly |
22:54.30 | CIA-2 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
22:54.36 | kergoth | RP: had to adjust EXPORT_FUNCTIONS when things moved, but apparently got overzealous :P |
22:54.51 | RP | kergoth: ah |
22:55.00 | RP | kergoth: makes sense |
22:55.22 | ant__ | RP: an easy question for you: in bitbake.conf we have IMAGE_DEPENDS_cpio.lzma = "lzma-native". In initramfs-kexecboot-image.bb we set IMAGE_FSTYPES = "cpio.gz cpio.lzma" and EXTRA_IMAGEDEPENDS = "". |
22:55.36 | ant__ | RP: it was noted that if buildhost had no lzma installed, the creation would fail. |
22:55.52 | ant__ | so DEPENDS = "lzma-native" was added in the image.bb |
22:56.28 | ant__ | I would think this DEPENDS is superfluous |
22:57.52 | kergoth_ | sakoman: should be fine now. |
22:59.48 | RP | ant__: It shouldn't need that, correct |
22:59.54 | ant__ | RP: so if we add LZO support in bitbake.conf, should we still explicit the dependecy from lzo-native? |
22:59.55 | RP | ant__: sounds like something else is wrong |
23:00.02 | ant__ | ahrg |
23:01.22 | *** join/#oe playya (~playya@unaffiliated/playya) |
23:04.55 | kergoth_ | whew, think this is finally working as hoped |
23:05.23 | kergoth_ | maybe |
23:09.19 | kergoth_ | damnit |
23:10.18 | RP | kergoth: still problems? |
23:10.24 | kergoth_ | just realized this is completely hosed with the in recipe checksums.. no override specific flags ;) |
23:10.30 | kergoth_ | other than that, works great |
23:10.48 | kergoth_ | hmm, at least, i don't think flags get merged when overrides are applied |
23:10.53 | kergoth_ | looks |
23:10.59 | RP | kergoth: ah, the BBVERSIONS stuff |
23:11.05 | kergoth_ | yeah |
23:11.15 | kergoth_ | the other bits seem fine |
23:12.02 | kergoth_ | bb.data.update_data is one really lame function name |
23:12.24 | RP | kergoth: but a very clever function :) |
23:13.15 | RP | kergoth: base change pushed into poky too |
23:13.21 | RP | pretty much anyway |
23:13.34 | RP | I'll try and properly sync things up better at some point :/ |
23:13.48 | kergoth_ | data_smart says its __setitem__ is deprecated |
23:13.50 | kergoth_ | but update_data uses it |
23:13.52 | kergoth_ | haha |
23:14.10 | RP | kergoth: you expect consistency? ;-) |
23:14.22 | kergoth_ | i know, crazy talk.. |
23:14.58 | kergoth_ | thinks about making update_data merge override var flags into the main var's flags |
23:16.45 | RP | kergoth: Doesn't it do something like that already? |
23:17.02 | RP | I thought renameVar did it? |
23:17.17 | kergoth_ | it doesn't use renameVar :P |
23:17.20 | kergoth_ | maybe thats the answer then |
23:17.38 | kergoth_ | oh, wait, maybe i'm blind |
23:17.40 | kergoth_ | :) |
23:17.46 | kergoth_ | hmm |
23:18.01 | kergoth_ | nope, it doesn't. the only place in that file that uses it is expandKeys |
23:18.03 | kergoth_ | tests |
23:18.30 | RP | ah, I must have fixed the expandKeys failure |
23:21.05 | *** join/#oe tmartins__ (~zero@187.37.50.223) |
23:23.02 | kergoth_ | RP: renamevar only manipulates the prepend/append flags for that, doesn't merge the flags of the old var into the new |
23:25.54 | kergoth_ | mutters |
23:27.34 | RP | kergoth_: if you rename first update_data should handle it |
23:28.27 | *** join/#oe sgh (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
23:28.31 | kergoth_ | I don't see any code in either update_data or renamevar to merge flags |
23:28.58 | kergoth_ | hrm |
23:30.34 | kergoth_ | also only renames vars which have content, so you can't just SRC_URI_2.0.7[md5sum] without also giving SRC_URI_2.0.7 a value. /me hacks around it for now |
23:30.40 | RP | kergoth_: I'm pretty sure it does |
23:31.23 | CIA-2 | 03Geetha T <geethat@ti.com> 07org.openembedded.dev * r3dbea75bd6 10openembedded.git/conf/machine/omapzoom36x.conf: omapzoom36x.conf: Machine config for OMAP Zoom36x |
23:31.24 | CIA-2 | 03Geetha T <geethat@ti.com> 07org.openembedded.dev * r01b04b9a77 10openembedded.git/recipes/u-boot/u-boot_git.bb: u-boot_git: Added support for OMAPZoom36x |
23:31.25 | CIA-2 | 03Graeme Gregory <dp@xora.org.uk> 07org.openembedded.dev * raa4f6eb2b5 10openembedded.git/recipes/linux/linux-omap-zoomsync/omapzoom2/logo_linux_clut224.ppm: linux-omap-zoomsync : make logo more generic now recipe has 2 machines |
23:31.26 | CIA-2 | 03Geetha T <geethat@ti.com> 07org.openembedded.dev * rc31ca1edca 10openembedded.git/recipes/linux/ (2 files in 2 dirs): linux-omap-zoomsync_2.6.32: Added support for OMAPZoom36x |
23:31.27 | CIA-2 | 03Graeme Gregory <dp@xora.org.uk> 07org.openembedded.dev * rccb23a493e 10openembedded.git/contrib/angstrom/sort.sh: |
23:31.27 | CIA-2 | contrib/angstrom/sort.sh : add the new omapzoom36x machine |
23:31.27 | CIA-2 | Signed-off-by: Graeme Gregory <dp@xora.org.uk> |
23:31.28 | CIA-2 | 03Graeme Gregory <dp@xora.org.uk> 07org.openembedded.dev * r85561b7406 10openembedded.git/recipes/x-load/x-load_git.bb: |
23:31.28 | CIA-2 | x-load_git.bb : fix minor mistake in omapzoom36x version |
23:31.28 | CIA-2 | This also needs the u-boot snapshot to exist. |
23:31.28 | CIA-2 | Signed-off-by: Graeme Gregory <dp@xora.org.uk> |
23:31.29 | CIA-2 | 03Geetha T <geethat@ti.com> 07org.openembedded.dev * rfe529294f9 10openembedded.git/recipes/x-load/x-load_git.bb: x-load_git: Added support for OMAPZoom36x |
23:32.33 | *** join/#oe alecrim (~alecrim@189.2.128.130) |
23:36.48 | *** join/#oe Laibsch (~Laibsch@p5B3B268E.dip.t-dialin.net) |
23:39.10 | likewise | gm Laibsch |
23:40.57 | *** join/#oe sgh (~quassel@0x4dd5bf76.adsl.cybercity.dk) |
23:42.09 | RP | 'night all |
23:42.17 | kergoth_ | night |
23:42.51 | *** join/#oe pirho (debian-tor@gateway/tor-sasl/pirho) |
23:45.37 | sakoman | thanks kergoth_ ! I'll pull & give it a try |
23:48.30 | kergoth | goes to unbork do_clean... :P |
23:48.33 | kergoth | shakes head at self |
23:51.17 | *** join/#oe mekius (~mekius@enlightenment/developer/mekius) |
23:53.22 | CIA-2 | 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * rbcf8d1320f 10openembedded.git/classes/utility-tasks.bbclass: |
23:53.23 | CIA-2 | utility-tasks: unbork do_{clean,rebuild,mrproper,distclean} |
23:53.23 | CIA-2 | Signed-off-by: Chris Larson <chris_larson@mentor.com> |
23:53.45 | kergoth | considers some cleanups |
23:55.00 | *** join/#oe gnutoo_ (~GNUtoo@host237-136-dynamic.2-87-r.retail.telecomitalia.it) |
23:57.04 | kergoth | argh |
23:57.21 | kergoth | i thought i had this fixed, but i guess not, now its not obeying my preferred version for the native variant |
23:57.21 | kergoth | g |
23:57.22 | kergoth | rr |
23:58.39 | *** join/#oe toborguru (~quassel@c-67-176-13-111.hsd1.co.comcast.net) |
23:59.15 | toborguru | Hey all |