IRC log for #oe on 20120502

00:00.29*** join/#oe igeiser (~igeiser@pool-71-162-255-190.phlapa.fios.verizon.net)
00:34.19*** join/#oe msm (~msm@99-47-177-27.lightspeed.austtx.sbcglobal.net)
00:42.03*** join/#oe nitink (~nitink@134.134.139.76)
01:01.43*** join/#oe sgw (~sgw@c-71-193-189-117.hsd1.wa.comcast.net)
01:36.43*** join/#oe risca (~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net)
02:06.18*** join/#oe devzero_ (devzero@xdsl-78-35-53-231.netcologne.de)
02:08.19*** join/#oe rsalveti (~rsalveti@177.99.132.224)
02:08.20*** join/#oe rsalveti (~rsalveti@linaro/rsalveti)
02:18.54*** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net)
02:57.18*** join/#oe JaMa (~martin@94.230.152.246)
02:58.33*** join/#oe silviof1 (~silviof@ppp-93-104-165-130.dynamic.mnet-online.de)
03:05.30*** join/#oe blupp (~blupp@dslb-188-099-251-231.pools.arcor-ip.net)
03:10.03*** join/#oe pwgen_8 (~ew@daimi-pat.daimi.au.dk)
03:34.46*** join/#oe notespace3 (~notespace@barracuda.ventureresearch.com)
04:14.19*** join/#oe ensc_ (~irc-ensc@p54ADDAD5.dip.t-dialin.net)
04:23.49*** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net)
04:44.28*** join/#oe cheng (~cheng@115.133.208.164)
04:58.32chengcan i use opnembedded to build a cross native compiler on my dm8168 arm board?
05:20.08*** join/#oe snkt (~snkt@122.170.104.85)
05:22.42*** join/#oe erwt (~erwt@122.170.104.85)
05:23.09*** join/#oe cheng (~cheng@115.133.208.164)
05:23.41*** join/#oe garble (~thomas@2001:420:4:eb65:e291:f5ff:fe94:3e86)
05:35.57*** join/#oe _tasslehoff_ (~Tasslehof@84.49.231.147)
05:38.32*** join/#oe jkridner (~jason@pdpc/supporter/active/jkridner)
05:43.46*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
05:53.06*** join/#oe rsalveti (~rsalveti@177.99.132.224)
05:53.10*** join/#oe rsalveti (~rsalveti@linaro/rsalveti)
06:07.45*** join/#oe mertsas (~martin@nat/cisco/x-hjdwvfuzjbezwtat)
06:10.16*** join/#oe silviof1 (~silviof@host-188-174-185-49.customer.m-online.net)
06:10.17_tasslehoff_Function failed: Fetcher failure for URL: 'file://var-run.conf'. Unable to fetch URL from any source <- this from base-files_3.0.14.bb, that hasn't changed since january and doesn't mention a var-run.conf.
06:10.32_tasslehoff_is confused
06:12.48JaMamaybe some .bbappend does
06:13.20*** join/#oe rob_w (~bob@93.104.205.194)
06:13.20*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
06:17.11*** join/#oe Zagor (~bjst@46.35.227.87.static.tab.siw.siwnet.net)
06:17.12*** join/#oe Zagor (~bjst@rockbox/developer/Zagor)
06:20.35mckoangood morning
06:21.33_tasslehoff_is unconfused, but a bit ashamed :)
06:22.33*** join/#oe erwt (~erwt@122.170.104.85)
06:22.50*** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net)
06:23.25*** join/#oe clio (~andrej@85.159.109.222)
06:26.22*** join/#oe vitus (~vitus@145.253.169.210)
06:31.22eFfeM_workhm, meta-oe head does not work with yocto 1.2 :-(
06:31.46JaMause meta-oe/denzil
06:33.02*** join/#oe snkt (~snkt@122.170.104.85)
06:33.07_tasslehoff_a case of two .bbappends setting FILESEXTRAPATHS :=
06:35.06*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
06:39.35eFfeM_workJaMa: ah, thanks
06:40.38eFfeM_workbtw anyone knows if there is a (non-classic) recipe for fastcgi ? does not seem to be in yocto 1.2 or meta-oe
07:07.58*** join/#oe lamikr (lamikr@nat/nokia/x-yhptrvbomtlihsyj)
07:08.11*** join/#oe garble (~thomas@2001:420:4:eb65:b93c:7d29:9b2e:c807)
07:14.23*** join/#oe clio (~andrej@85.159.109.222)
07:21.29*** join/#oe florian (~fuchs@port-217-146-132-69.static.qsc.de)
07:21.31*** join/#oe florian (~fuchs@Maemo/community/contributor/florian)
07:30.22*** join/#oe ant_work (~andrea@host6-80-static.42-85-b.business.telecomitalia.it)
07:36.41*** join/#oe rschus (~rschus@fb-n15-11.unbelievable-machine.net)
07:37.14*** join/#oe lamikr (lamikr@nat/nokia/x-hidqilukkjuutbhz)
07:40.04*** join/#oe morphis (~morphis@dslb-088-070-132-153.pools.arcor-ip.net)
07:59.50_tasslehoff_if more than one .bbappend supply a file, how do I control which one is chosen?
08:00.22_tasslehoff_does the order of paths in FILESEXTRAPATHS matter?
08:00.48JaMayes it does
08:22.51*** join/#oe rschus1 (~rschus@fb-n15-11.unbelievable-machine.net)
08:26.08*** join/#oe ensc|w (~ensc@www.sigma-chemnitz.de)
08:26.37*** join/#oe ensc (~irc-ensc@fedora/ensc)
08:31.50*** join/#oe bluelightning (~paul@83.217.123.106)
08:31.50*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
08:32.40*** join/#oe ericbutters (~kuhne@business-213-023-195-122.static.arcor-ip.net)
08:33.32ericbuttershi.. i did "bitbake -f firefox" and then i want to rebuild my images, so i call "bitbake" but i get: ERROR: Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.
08:37.42ericbuttersah i need to run "bitbake myimage" ..
08:38.12ericbutterstz.. holidays ;)
08:38.55*** join/#oe clio (~andrej@85.159.109.222)
08:39.45*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
08:44.13bluelightningmorning all
08:44.39kenwsgood morning
08:45.50ericbuttersanyone used fullscreen extension for firefox?
08:46.27*** join/#oe morphis (~morphis@dslb-088-070-132-153.pools.arcor-ip.net)
09:01.26*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
09:50.43*** join/#oe _tasslehoff_ (~Tasslehof@84.49.231.147)
09:56.08*** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net)
10:00.38*** join/#oe pepermint (~pepermint@host64-201-dynamic.10-188-r.retail.telecomitalia.it)
10:12.06pb_hi all
10:26.12florianhi pb_
10:27.25mckoanhi pb_, florian, all
10:27.59florianhi mckoan
10:55.41*** join/#oe mickey_office (~mickey@e182221015.adsl.alicedsl.de)
10:57.40*** join/#oe lamikr (lamikr@nat/nokia/x-pvuqryobashvtjac)
11:20.12*** join/#oe pretec (~Matthias@port-92-195-19-28.dynamic.qsc.de)
11:22.10pb_so, koen rejoins the tsc.  that's a bit of a shame.
11:23.32JaMawhy?
11:25.35*** join/#oe dijenerate (~dijenerat@173.225.251.175)
11:42.21florianhum well...
11:42.40florianJaMa: he is not good for PR
11:43.10XorAPR is the boards job :-D
11:43.41florianwell true, but the tsc acts in the public as well, controls resources etc.
11:44.17*** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes)
11:45.10*** join/#oe SlashV (~SlashV@ip176-146-172-82.adsl2.static.versatel.nl)
11:50.47ynezzhm, some of us didn't even noticed, that he has quit the tsc :p
11:58.45JaMaflorian: but he is very good for patches right? so from my POV it's better to have good devs then good PR
11:58.56*** join/#oe dv_ (~quassel@chello080108009040.14.11.vie.surfer.at)
12:04.51pb_well, one can send patches without being on the TSC.
13:11.54*** join/#oe ibot (~ibot@rikers.org)
13:11.54*** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel
13:12.26*** join/#oe challinan (~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net)
13:17.19brooniefinds himself re-adding stuff that was already present in oe-classic to try to boostrap mea-oe.
13:17.22brooniemeta-oe
13:17.35broonieOn the bright side, there's a little bit more documentation than there is for angstrom
13:26.35*** part/#oe tasslehoff (~Tasslehof@147.84-49-231.nextgentel.com)
13:39.26*** join/#oe cheng (~cheng@175.140.179.93)
13:40.22*** join/#oe dos11 (~dos@unaffiliated/dos1)
13:59.47*** join/#oe CMoH (~cipi@unaffiliated/c-moh)
14:03.12*** join/#oe bitkiller (~bitkiller@189.58.123.195.dynamic.adsl.gvt.net.br)
14:04.36*** join/#oe devzero_ (devzero@xdsl-89-0-77-40.netcologne.de)
14:08.52*** join/#oe hollisb (~hollisb@c-67-169-221-181.hsd1.or.comcast.net)
14:10.23*** join/#oe hollisb_ (~hollisb@c-67-169-221-181.hsd1.or.comcast.net)
14:44.33*** join/#oe eFfeM (~frans@a2038.upc-a.chello.nl)
14:57.13*** join/#oe fray (U2FsdGVkX1@gate.crashing.org)
15:01.18*** part/#oe Zagor (~bjst@rockbox/developer/Zagor)
15:07.02*** join/#oe nitink (nitink@nat/intel/x-hjxrimdxohsxswdq)
15:19.34*** join/#oe jmpdelos (~polk@delos.delos.com)
15:20.41*** join/#oe kristoffer (~kristoffe@c-c3dde555.010-30-6c6b7012.cust.bredbandsbolaget.se)
15:24.47*** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey)
15:28.48*** join/#oe dos11 (~dos@unaffiliated/dos1)
15:31.16ensc|wis there a clean way (except going manually into the source cache dir and pruning files there) how the downloaded files from SRC_URI can be removed?  E.g. I have trouble with tcf-agent whose license text has been changed recently and the old file is lingering around at a lot of installations.
15:32.32JaMasomething like -c cleanall?
15:33.29JaMaor you need to do it automatically with each "upgrade" build?
15:34.50ensc|wJaMa: thx, cleanall seems to be enough
15:35.40kergoththat reminds me, we really need to get file:// files from SRC_URI added to the appropriate checksums. otherwise you're forced to manually cleansstate when changing them. worse yet, if using SSTATE_MIRRORS, there's no way to tell it not to re-fetch the shared state archive
15:38.28JaMakergoth: are checksums of e.g. http:// files now part of sstate hash?
15:38.47kergothno idea
15:39.01kergothi doubt it, though, but that would be good too
15:39.22kergothwe've talked about this before, its just i happened to get bitten by it while hacking on external-csl-toolchain the other day (modified SUPPORTED)
15:39.26kergothheh
15:39.51JaMayup especially with PRSERV stuff (if it will end manuall PR bumps)
15:40.18kergothgood point
15:40.28kergothhmm, would think it wouldn't be hard to do, actually..
15:40.43*** join/#oe zenlinux_ (~sgarman@12.70.159.234)
15:41.12kergothadd a ConfigParsed handler to checksum file:// files and store those in a variable or variables, add that to SRC_URI vardeps, and similarly suck in the various SRC_URI md5sum/shasum flags
15:41.22kergothhm
15:41.38JaMaprobably good to add it soon in release cycle as it will invalidate whole sstate cache :)
15:41.56kergoth'll try doing a quick prototype and see how it behaves
15:59.12*** join/#oe W1N9Zr0 (~W1N9Zr0@24-212-193-98.cable.teksavvy.com)
16:04.04*** join/#oe CMoH (~cipi@unaffiliated/c-moh)
16:28.13*** join/#oe pespin (~pespin@172.pool85-50-83.dynamic.orange.es)
16:36.14kenwsis looking at the 64bithack.patch that gets applied to the GCC and wonders why --disable-multilib isn't used instead
16:38.11*** join/#oe Ironnads (~Ironnads@host109-152-218-189.range109-152.btcentralplus.com)
16:38.34kenwsThe patch seems strange. In case someone would enable multilib the locations for the m32 and m64 libs would be the same
16:38.47kenwskhem: RP: Any hints? : )
16:40.01frayI've had a request from a customer of mine.. they would like -more- verbose bitbake information from the build..  basically when a task finishes, they'd like the contents of log file printed to the screen..
16:40.05fray(even better if it was live)
16:40.21frayis there any way to do this, or would this be a custom UI?  If it's a custom UI, any pointers to how to do this work?
16:40.55kenwsfray: what about the -v switch to bitbake?
16:41.25bluelightningfray: I'm having a hard time imagining that being usable with multiple threads running, but I'm sure it would be possible...
16:41.26denisATeukreaindeed or -DDD
16:41.42fray-DDD isn't it..
16:41.46denisATeukreaok
16:41.53fraythey don't want more spew from bitbake.. they want the logs of the build in context
16:42.00denisATeukreaah ok
16:42.41fraybluelightning I don't disagree.. the use-case specifically is "I want to do bitbake -c compile rpm"  and I want the logs printed to the screen so I can immediate see what worked or didn't and inspect them..  they don't want to have to go digging through the tmp.../work/... directory structure to find the right files..
16:42.53fraythis also allows them to see an overall build captured in a single log file for grepping..
16:42.59frayI'd certainly not advocate it be a default UI
16:43.26fray(I also suspect using this, you'd likely turn off parallel bitbake tasks.. but it could still be useful w/o it)
16:44.01bluelightningOK... it kind of sounds like something that could be implemented as a command line option to the default ui
16:44.46fraythat is what I was thinking.. but I don't have any experience with the UI to be able to do that..
16:45.04frayI'm really not sure fi they prefer "live" listing, or when the task is complete (successfull or not) it just dump the results
16:45.09frayI'm not even sure if live is a possibility
16:47.11*** join/#oe hbeck (~hbeck@38.114.125.89)
16:47.29frayBTW what is the default UI?
16:49.15*** join/#oe flo_lap (~fuchs@sign-4db6aa73.pool.mediaWays.net)
16:49.15*** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian)
16:49.47bluelightningfray: knotty
16:50.03frayok..  I think I see where the error logs are printed
16:50.12*** join/#oe mr_science (~sarnold@net-cf9a4e91.cst.impulse.net)
16:50.12*** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy)
16:50.32frayI see it checking bb.build.TaskFailed.. is there a TaskSucceeded?
16:51.37frayapparently there is, it's listed in the uihelper.py...
16:53.21mario-goulartHi.  Is anybody having problem with log4j1.2-native? I'm getting this error: http://paste.debian.net/167021/
16:54.13RPfray: look at knotty.py, its straight forward to add something in there which would cat the log at task completetion
16:54.34RPfray: since its the UI that writes to the screen, the multiple process problem shouldn't be an issue in that case
16:55.17RPkenws: We build a toolchain per multilib and this was the simplest way to avoid some nasty logic figuring things out
16:55.34kenwsRP: I think the reason for the 64bithack.patch is the libstdc++. With --disable-multiarch the libstdc++ would still be placed in lib64 which is not what you want.
16:55.37RPkenws: we are working on something better but its not been ready for master yet
16:56.02RPkenws: there are a variety of bad things that code can do
16:57.01kenwsRP: I think deleting the MULTILIB_OSDIRNAMES MULTILIB_DIRNAMES variables from the i386/t-linux64 should also achive this
16:57.53kenwsThis causes the GCC to support just one flavour (m32 or m64) even if you enable multilib
16:57.55RPkenws: ultimately we're going to write out the multilib configuration into there
16:58.57kenwsRP: Hm, I'm afraid I don't get it. Are you saying that you want oe to support multilib in the future?
17:00.25RPkenws: we support multilib now with a toolchain per multilib. This doesn't let us build a toolchain for use on target that will support multilib though
17:01.07kenwsRP: alright, so far I'm with you
17:01.59RPkenws: if we fix the gcc configuration to match the full set of multilibs, it will work on target which is a good idea IMO
17:02.07RPkenws: sorry, I need to go :(
17:02.40kenwsRP: ok, thanks so far. Maybe you could check the irc log later again
17:04.49fraybluelightning how does hob watch the task log directly in the UI?
17:05.36bluelightningfray: AFAIK it works in the same way as knotty, by listening for events
17:06.03frayyes.. but what actually watches the logs..
17:06.13fraysince they appear to be displayed live, and not on the succeeded or failed event
17:06.31fraymy assumption is that something captures the event.logfile on task start.. adds it to the tree..
17:06.39fraybut I'm curious how it's being run...
17:07.11bluelightningI wasn't aware that it actually looked at the log for a task unless it failed
17:07.35frayin the UI on hob, I swear you get a tree view of all of the tasks and you can expand and watch them... live even
17:08.07bluelightningyeah, but that's just a list of what tasks have run and are running; that's solely based on the events
17:08.22frayyes.. it's the printing of hte logs part I'm wondering how it's implemented
17:08.46bluelightningif it is printing the actual logs of individual tasks that's functionality I haven't seen
17:08.50fraysince I can do the same event processing in the knotty ui (or any other ui).. but I don't know how to watch a file "live" based on the events.. I do see how to do it after the task has finished though
17:10.27frayI can't run hob unfortunately, or I would run it and verify what I remember
17:10.45fray(hob complains it can't run remote due to TCP/IP netowrking for ORBit)
17:15.13bluelightninghmm, that's a bit sad
17:18.08*** join/#oe zxdx (~zxdx@178.120.60.76)
17:18.32frayhey if I manually run dbus it starts to work!
17:19.35bluelightningfray: actually you're right, it does include the task output in the tree
17:19.48bluelightningfray: maybe the code is in runningbuild.py?
17:20.28frayI note that most of the ui/hob.py code seems to just be very basic... where is the majority of the implementation?
17:21.43frayHmm the new hob doesn't see to let you see the log live, only once the task is done
17:22.05frayis hob1 still available?
17:22.26bluelightningfray: in the git history only
17:22.28bluelightningAFAIK
17:22.40frayok.. I can back off to a prior release and double check this
17:23.41*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
17:24.15frayHmm.. scrolling through the logs is -really- slow.. (I'm on a remote x-term.. so I don't know if that is an artifact of being remote or not)
17:24.32fray(remote over an 802.11g link)
17:24.53fraysays 54Mbit/s rate.. ;)
17:25.32bluelightningah, well latency could be the issue there
17:25.50frayI suspect gtk isn't optimizaing the scrolling.. but actually trying to display -everything-
17:26.30bluelightningX11-over-ssh performance on a local LAN with machines right next to eachother is pretty poor if you ask me, let alone wireless
17:26.48frayya..  thats what I'm stuck with.. the amchines are in the server lab next door
17:28.02bluelightningok I gotta run, may be back online later
17:30.31*** join/#oe silviof1 (~silviof@host-188-174-181-140.customer.m-online.net)
17:38.18*** join/#oe johncylee (~john@114-32-34-65.HINET-IP.hinet.net)
17:38.39*** join/#oe jkridner_ (~jason@pdpc/supporter/active/jkridner)
17:39.43*** join/#oe johncylee (~john@114-32-34-65.HINET-IP.hinet.net)
17:56.24kenwsRP: khem: I think what the GCC folks are saying is that even if you disable multilib the libstdc++ will be placed in lib64 during the install step. Because that's where 64bit libs go for linux targets according to the FHS. If you don't like this but want to use linux as a target you have to patch the toolchain which is what 64bithack.patch attempts to do. One solution would be to have a distinctive OE target that doesn't support multilib and has 64bit libs under lib
17:56.24kenws. Another hack would be to just delete the MULTILIB_* variables from the gcc/config/i386/t-linux64. The advantage over the current 64bithack.patch would be that no one could ever build a broken multilib toolchain. Even easier, we could just this: http://paste.ubuntu.com/962860.
17:56.31*** join/#oe mickeyl (~mickey@openmoko/coreteam/mickey)
17:56.43mickeylflorian:  which channel?
17:57.19kenwsI'm currently testing this patch against meta-linaro and it's looking good
17:58.18*** join/#oe JaMa (~martin@94.230.152.246)
18:00.07florianmickeyl: #oe-board is the one we used the last time iirc
18:01.56mickeylk
18:21.13*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
18:21.18*** join/#oe jmpdelos (~polk@delos.delos.com)
18:32.26*** join/#oe tasslehoff (~tasslehof@145.79-161-31.customer.lyse.net)
18:46.35*** join/#oe fullstop (~quassel@64-121-54-104.c3-0.tlg-ubr1.atw-tlg.pa.cable.rcn.com)
18:57.29*** join/#oe dijenerate (~dijenerat@72.51.108.124)
19:36.13*** join/#oe e-ffi (~cybercom@HSI-KBW-134-3-115-142.hsi14.kabel-badenwuerttemberg.de)
19:58.28*** join/#oe eFfeM1 (~frans@a2038.upc-a.chello.nl)
19:59.00*** join/#oe fray (U2FsdGVkX1@gate.crashing.org)
20:21.18*** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust101.2-4.cable.virginmedia.com)
20:21.18*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
20:28.28*** join/#oe dijenerate (~dijenerat@65.48.164.104)
20:48.37*** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029)
21:14.19JeremyClarksonHey all.  I'm trying to include a custom kernel module in a custom image (based on omap3-console-image, and I'm getting an error resolving conffiles.  Apparently an existing conffile (that is different from the new one) already exists.  What does this mean, in general terms?  (I've been googling, but I'm still confused.)  Thanks in advance.
21:21.24*** join/#oe risca (~risca@wi-secure-6897.cc.umanitoba.ca)
21:26.47*** join/#oe ant__ (~andrea@host61-186-dynamic.60-82-r.retail.telecomitalia.it)
21:35.44*** join/#oe CMoH (~cipi@95.76.68.223)
21:35.45*** join/#oe CMoH (~cipi@unaffiliated/c-moh)
21:46.06*** join/#oe Russ (foobar@ip68-106-254-4.ph.ph.cox.net)
22:08.45*** join/#oe bluelightning (~paul@cpc2-lewi17-2-0-cust101.2-4.cable.virginmedia.com)
22:08.46*** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning)
22:08.49khemJeremyClarkson: which conffile ?
22:09.19JeremyClarksonkhem: device_table
22:15.28khemhmmm are you using latest oe
22:15.37khemthis issue was dealt with in angstrom
22:15.41khemiirc anyway
22:16.04JeremyClarksonI beleive i
22:16.14JeremyClarksonI believe I'm using the 2011.3 branch
22:16.25khemoh hmm
22:19.59JeremyClarksonI suspect my do_install task is bad.  I tried removing it (to use the default module task, but it wouldn't build)
22:27.35khemcheck if there are other samples of external modules in tree
22:27.38khemand follow the steps
22:28.16JeremyClarksonok
22:30.21*** part/#oe cminyard (~cminyard@pool-173-57-151-210.dllstx.fios.verizon.net)
22:33.37*** join/#oe cminyard (~cminyard@pool-173-57-151-210.dllstx.fios.verizon.net)
22:34.41*** join/#oe metaxa (metaxa@members.bombshellz.net)
22:39.00*** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst)
23:04.45*** join/#oe ericben (~ebenard@pac33-2-82-240-38-71.fbx.proxad.net)
23:22.04*** join/#oe bluelightning_ (~paul@cpc2-lewi17-2-0-cust101.2-4.cable.virginmedia.com)
23:22.04*** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning)
23:30.00*** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net)
23:51.45*** join/#oe Crofton (~balister@32.168.14.8)
23:57.14*** join/#oe dijenerate (~dijenerat@173.225.251.175)

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