| 00:01.33 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 01:23.27 | *** join/#oe thaytan (~thaytan@199.7.70.115.static.exetel.com.au) |
| 01:30.05 | *** join/#oe afournier (~admin@46.255.181.29) |
| 01:36.28 | *** join/#oe thaytan (~thaytan@199.7.70.115.static.exetel.com.au) |
| 01:45.59 | *** join/#oe ntl (~ntl@99-127-51-4.lightspeed.austtx.sbcglobal.net) |
| 02:06.40 | *** join/#oe vdehors (~vincent@LAubervilliers-656-1-235-184.w193-248.abo.wanadoo.fr) |
| 02:35.40 | *** join/#oe infobot (ibot@rikers.org) |
| 02:35.40 | *** 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 |
| 03:14.46 | *** join/#oe stefan1234 (~stefan@p4FF82E20.dip0.t-ipconnect.de) |
| 03:37.31 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 03:54.51 | *** join/#oe veli (veli@james.piipiip.net) |
| 04:08.11 | *** join/#oe gabrbedd (~gabrbedd@li680-65.members.linode.com) |
| 04:08.37 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 04:11.25 | *** join/#oe veli (veli@james.piipiip.net) |
| 04:13.25 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 05:12.57 | *** join/#oe clio (~andrej@85.159.109.222) |
| 05:44.36 | *** join/#oe roric (~roric@83.140.117.51) |
| 05:47.07 | *** join/#oe ntl (~ntl@99-127-51-4.lightspeed.austtx.sbcglobal.net) |
| 06:01.06 | *** join/#oe dvhart_ (~dvhart@134.134.139.76) |
| 06:20.07 | *** join/#oe hamis (~irfan@110.93.212.98) |
| 06:41.03 | *** join/#oe simosx (~simosx@ubuntu/member/simosx) |
| 06:52.29 | mckoan | good morning |
| 07:06.20 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-ieedmojkcinsysjm) |
| 07:17.03 | *** join/#oe phdeswer (~phdeswer@2001:2060:53:beef:6267:20ff:fe47:e16c) |
| 07:17.18 | *** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 07:18.36 | AlexVaduva | good morning guys |
| 07:26.03 | pompomJuice | sup |
| 07:27.16 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 07:39.35 | *** join/#oe phdeswer (~phdeswer@2001:2060:53:beef:6267:20ff:fe47:e16c) |
| 07:43.31 | *** join/#oe aragua (~aragua@91-224-149-44.tetaneutral.net) |
| 07:44.02 | *** part/#oe Noor (~noor@110.93.212.98) |
| 08:02.26 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 08:04.35 | *** join/#oe ant_work (~ant__@host222-188-static.61-79-b.business.telecomitalia.it) |
| 08:04.41 | *** join/#oe ant__ (~ant__@host222-188-static.61-79-b.business.telecomitalia.it) |
| 08:06.41 | bluelightning | morning all |
| 08:07.29 | *** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 08:08.10 | *** join/#oe ant__ (~ant__@host222-188-static.61-79-b.business.telecomitalia.it) |
| 08:11.38 | *** join/#oe stefan_schmidt (~stefan@pD9F79D6D.dip0.t-ipconnect.de) |
| 08:12.04 | *** join/#oe JaMa (~martin@ip-86-49-34-37.net.upcbroadband.cz) |
| 08:12.50 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 08:16.09 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 08:24.03 | *** join/#oe belen (Adium@nat/intel/x-qtdyekewetjvdrsl) |
| 08:28.33 | mckoan | hi bluelightning |
| 08:39.41 | *** join/#oe awe00 (~awe00@lon92-h02-128-78-240-105.dsl.sta.abo.bbox.fr) |
| 08:43.02 | bluelightning | hi mckoan |
| 09:06.32 | *** join/#oe RP (~richard@5751f4a1.skybroadband.com) |
| 10:00.33 | *** join/#oe belen (Adium@nat/intel/x-wksivxfubtdtaynn) |
| 10:25.46 | *** join/#oe belen1 (~Adium@192.198.151.43) |
| 10:37.55 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 11:26.53 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 11:57.29 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 11:59.11 | *** join/#oe belen (~Adium@192.198.151.43) |
| 12:02.21 | *** join/#oe belen1 (Adium@nat/intel/x-wxmqjthrtdkrsfqr) |
| 12:05.07 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 12:21.06 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 12:42.10 | *** join/#oe belen (~Adium@192.198.151.43) |
| 12:44.03 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 12:44.39 | *** join/#oe darkschneider (~gab@93-32-48-217.ip32.fastwebnet.it) |
| 12:47.38 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 12:49.23 | *** join/#oe akrem (~akrem@41.225.101.137) |
| 12:49.46 | akrem | help |
| 12:55.00 | bluelightning | akrem: what's the problem you are having? |
| 12:56.39 | akrem | Sorry guys i was about to type /HELP so i typed help instead |
| 12:56.51 | Crofton|work | laughs |
| 12:57.00 | akrem | thanks bluelightning |
| 12:57.28 | bluelightning | you're welcome I guess :) |
| 12:58.01 | akrem | I am new to IRC |
| 12:59.28 | bluelightning | I guess we all were at some point |
| 13:01.24 | *** join/#oe belen (~Adium@192.198.151.43) |
| 13:05.32 | *** join/#oe dfaught (~dfaught@cpe-70-123-104-72.tx.res.rr.com) |
| 13:12.56 | *** part/#oe akrem (~akrem@41.225.101.137) |
| 13:18.07 | pompomJuice | do_obfuscation[noexec] = '${@base_conditional("DISTRO_TYPE", "release", "0", "1", d)}' |
| 13:18.21 | pompomJuice | Is that going to work? |
| 13:18.28 | pompomJuice | for some reason it is not working |
| 13:18.38 | pompomJuice | it never does obfuscation |
| 13:20.03 | bluelightning | it won't work, no |
| 13:20.24 | bluelightning | the value of the noexec varflag isn't used, just the fact that it exists is enough to stop the task being executed |
| 13:20.35 | bluelightning | to be honest that has always bothered me |
| 13:21.10 | bluelightning | as an alternative you can conditionally use d.setVarFlag() from anonymous python instead |
| 13:21.55 | pompomJuice | but would the setvar make it null? |
| 13:22.25 | pompomJuice | this is a complete disaster |
| 13:22.43 | pompomJuice | we have been shipping our code in cleartext |
| 13:22.45 | pompomJuice | for ages now |
| 13:22.56 | pompomJuice | no-body picked this up |
| 13:23.14 | pompomJuice | I HATE code that makes sense but does not make sense |
| 13:23.27 | pompomJuice | so frustrating |
| 13:24.09 | pompomJuice | how are you supposed to guess if tras like this exist |
| 13:24.16 | pompomJuice | how are you supposed to guess if traps like this exist |
| 13:24.23 | pompomJuice | true could be false |
| 13:24.27 | pompomJuice | 1 could be 0 |
| 13:24.30 | pompomJuice | you cant work like this |
| 13:24.49 | pompomJuice | this is a complete disaster |
| 13:25.51 | pompomJuice | I cannot decompile the dam electrons every time I want to make something work slightly different |
| 13:25.54 | *** join/#oe Aethenelle (~Aethenell@166.175.187.17) |
| 13:26.10 | pompomJuice | that has got to be the most stuped syntax I have ever seen |
| 13:27.27 | *** join/#oe belen (Adium@nat/intel/x-hedtemsqstdxcjoz) |
| 13:28.10 | neverpanic | pompomJuice: sounds like you need a testcase. |
| 13:28.58 | pompomJuice | for that I need money |
| 13:29.07 | pompomJuice | nobody has money to do test driven development |
| 13:29.14 | pompomJuice | except the americans |
| 13:29.26 | pompomJuice | but they mmilk the rest of the work, that is the only reason |
| 13:29.34 | pompomJuice | but they mmilk the rest of the world, that is the only reason |
| 13:29.36 | neverpanic | so there's enough money to implement obfuscation, but not enough to test that it actually works? |
| 13:29.45 | *** join/#oe tsramos (~tsramos@134.134.139.72) |
| 13:29.46 | pompomJuice | but that is my point |
| 13:30.04 | pompomJuice | the code looked like this: |
| 13:30.07 | bluelightning | pompomJuice: it's likely been that way since it existed - I'm sorry if that's caused you problems; the best we can do is to fix it so it does match with expectations |
| 13:30.08 | pompomJuice | ## Uncomment this to disable obfuscation during debugging |
| 13:30.08 | pompomJuice | do_obfuscation[noexec] = "1" |
| 13:30.25 | pompomJuice | logix would dictate that setting that var to = "0" would cancel |
| 13:30.36 | pompomJuice | but no |
| 13:30.43 | pompomJuice | you have to decompile the electrons |
| 13:30.49 | pompomJuice | and get back to basics |
| 13:30.54 | pompomJuice | before you could modify that line |
| 13:31.42 | bluelightning | the way the code currently works, you have to not set it in the first place, to be clear |
| 13:31.50 | pompomJuice | do_obfuscation[noexec] = '${@base_conditional("DISTRO_TYPE", "release", None, "1", d)}' |
| 13:31.53 | pompomJuice | would that work? |
| 13:31.56 | neverpanic | No |
| 13:32.05 | pompomJuice | I want it conditional |
| 13:32.10 | pompomJuice | can you ahve those conditional? |
| 13:32.14 | bluelightning | no, I've just explained that that won't work - you are still setting the flag, you are just setting it to "" |
| 13:32.22 | neverpanic | then write an anoymous python snippet that uses setVarFlag to set it |
| 13:32.25 | pompomJuice | None is python's null? |
| 13:32.28 | bluelightning | and yes, I also explained how to work around it |
| 13:32.44 | bluelightning | i.e. use setVarFlag from anonymous python |
| 13:32.46 | pompomJuice | I suck at python |
| 13:32.54 | pompomJuice | I have no idea how to code in it |
| 13:33.13 | pompomJuice | while I have no idea to code in it... the community will invent 5 other scripting languages that I must learn |
| 13:33.16 | pompomJuice | I am furios |
| 13:33.17 | neverpanic | well, then you should probably learn it. |
| 13:33.30 | pompomJuice | uugh |
| 13:33.39 | pompomJuice | I cannot believe what happened here |
| 13:34.18 | bluelightning | in meta/recipes-core/images/build-appliance-image_*.bb there is an example where we do the reverse, i.e. we use delVarFlag to remove the flag, so that is also possible |
| 13:34.41 | pompomJuice | thanks |
| 13:34.44 | pompomJuice | let me go look at that |
| 13:42.31 | *** join/#oe Noor (~quassel@110.93.212.98) |
| 13:51.54 | *** join/#oe rob_w_ (~rob@ppp-46-244-173-114.dynamic.mnet-online.de) |
| 13:59.22 | *** join/#oe bradfa (~andrew@clr-vpn01.kodakalaris.com) |
| 14:02.24 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 14:11.40 | *** join/#oe joaohfreitas (~Thunderbi@187.106.4.47) |
| 14:13.06 | Crofton|work | I'v got a ptyhion recipe that is installing like this |
| 14:13.09 | Crofton|work | root@ettus-e300:~# ls /usr/lib/python2.7/site-packages/bitarray-0.8.1-py2.7-linux-x86_64.egg/bitarray/ |
| 14:13.26 | Crofton|work | any idea how to make it install sanely? |
| 14:18.31 | Crofton|work | changing from inherit distutils to setuptools solves the problem |
| 14:19.48 | bluelightning | I'm still wondering if we need to have both of those classes |
| 14:20.49 | Crofton|work | well |
| 14:21.03 | Crofton|work | distutils led to fail, setuptools glorious success :) |
| 14:21.44 | bluelightning | that would depend on what exactly you are building, but at least I recall someone saying one of the classes can handle both situations |
| 14:22.14 | bluelightning | Crofton|work: btw, shouldn't you have named your meta-ettus sub-layers with a meta- prefix? |
| 14:22.22 | Crofton|work | I agree, it is very confusing |
| 14:22.27 | Crofton|work | arrrggghhhhhhh |
| 14:22.38 | Crofton|work | so f';ing meta |
| 14:22.42 | bluelightning | I won't force you to, I'm just wondering why you didn't |
| 14:22.52 | Crofton|work | I didn't because it seemed redundant |
| 14:22.57 | Crofton|work | since I was already meta |
| 14:23.05 | bluelightning | it's just rare to have layers showing up in the layer index without a meta- prefix |
| 14:23.15 | bluelightning | or indeed, anywhere else |
| 14:23.30 | Crofton|work | saying meta-ettus/e300-bsp sounds so much better than meta-ettus-e100-bso |
| 14:23.45 | Crofton|work | I mean meta-ettus-meta-e300-bsp |
| 14:23.51 | Crofton|work | I mean meta-ettus/meta-e300-bsp |
| 14:23.57 | bluelightning | it's what everyone else does ;) |
| 14:24.31 | Crofton|work | I still wonder why I did each product in a layer |
| 14:24.41 | Crofton|work | but I think I'll leve it this weay |
| 14:24.49 | bluelightning | sure |
| 14:24.55 | Crofton|work | since the e100 layer makes a kernel that will not boot |
| 14:25.21 | bluelightning | I've just approved the additional layer index entry in any case... would have done it this morning but the layer index was down, Michael has since fixed it |
| 14:25.22 | Crofton|work | yes, wehn I started sorting out what the layer index has, I lrealized I was starting to look like a radical |
| 14:25.28 | Crofton|work | thanks |
| 14:25.42 | Crofton|work | the old entry pointed at my github which wasn't updated |
| 14:25.45 | Crofton|work | and some fond it :) |
| 14:25.50 | Crofton|work | found |
| 14:26.00 | Crofton|work | btw anyone done a recipe for scipy? |
| 14:26.42 | bluelightning | Crofton|work: I believe one of my colleagues is writing one if not right now then pretty soon |
| 14:27.12 | Crofton|work | I'm trying to see if the flowgraph really needs it, but it would be nice to have anyway |
| 14:27.23 | bluelightning | I'll find out what his ETA is |
| 14:27.28 | Crofton|work | thanks |
| 14:27.42 | Crofton|work | I'm trying to figure out what it is doing |
| 14:27.58 | Crofton|work | taking something done for a PC and looking at gettin g it running on an e310 |
| 14:27.59 | *** join/#oe diego_ (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 14:28.57 | *** join/#oe diego_ (~diego@5.90.6.30) |
| 14:29.20 | *** join/#oe diego_ (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 14:29.41 | bluelightning | hmm, now those two entries sort at the top |
| 14:30.32 | Crofton|work | I feel worst about that |
| 14:31.24 | Crofton|work | I swear, I wasn't trying to get listsed hi |
| 14:31.33 | Crofton|work | why no machines for the e300 layer? |
| 14:32.24 | bluelightning | hasn't been parsed yet |
| 14:32.38 | bluelightning | parsing happens on a cron job every 3 hours |
| 14:32.57 | bluelightning | one day someone will implement job scheduling so we can do it from the frontend |
| 14:33.04 | Crofton|work | no problem |
| 14:33.08 | Crofton|work | I figured it was thta |
| 14:46.50 | *** join/#oe simosx (~simosx@ubuntu/member/simosx) |
| 14:55.22 | consmith | can someone let me know if I'm understanding this process correctly? Sorry for the wall of text. |
| 14:55.22 | consmith | When bitbake is about to run a task, it generates a checksum based off the task's inputs. These are bitbake variables, functions defined for that task, etc. The checksum is stored as a stamp file in the stamp directory. If a stamp file already exists with a matching checksum, and the file's timestamp isn't too old, then the task doesn't need to be rerun at all. If there isn't a matching stamp file or it is too old, the task is rerun. |
| 14:55.22 | consmith | Certain tasks have corresponding _setscene tasks, which make use of sstate cache. If there is a _setscene version of the task, it is run before the main task. By default, these tasks calculate an sstate based off the name of the task, directories used by the task, etc. Bitbake then attempts to retrive an archive file with the sstate in its name. If the archive exists, it is unpacked and used as the results of the task, instead of having to recompile and generat |
| 14:56.13 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 14:57.24 | bluelightning | consmith: that sounds correct, except the timestamp on the stamp file isn't a factor in the process |
| 14:57.51 | bluelightning | it's all about the signature value which is computed from the task inputs (i.e. variable dependencies) |
| 14:58.53 | bluelightning | and also, task signatures are all computed right at the start of the build rather than just before execution, otherwise the system wouldn't know whether it was correct to extract the output from sstate or actually execute the task |
| 14:59.49 | consmith | interesting. do you know why the bitbake manual states that "As each task completes, a timestamp is written to the directory specified by the STAMP variable. On subsequent runs, BitBake looks in the build directory within tmp/stampsand does not rerun tasks that are already completed unless a timestamp is found to be invalid" then? |
| 15:00.17 | consmith | how does it make a difference if the signatures are computed at the start or immediately before execution? I don't follow that part |
| 15:01.55 | Crofton|work | bluelightning, yeah, I could use an eta for scipy :) |
| 15:05.40 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 15:05.52 | bluelightning | Crofton|work: I haven't talked with Alejandro yet but based on some notes I just found, it has a bunch of dependencies itself that need recipes, so I would imagine it'll take some time |
| 15:06.08 | Crofton|work | what depends? |
| 15:06.40 | bluelightning | "lapack, blas, and atlas" according to this |
| 15:07.04 | Crofton|work | let me wack about |
| 15:07.11 | bluelightning | won't build without them even though their wiki says it should, apparently |
| 15:07.14 | Crofton|work | unless I get distracted by real work |
| 15:16.46 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 15:18.28 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 15:30.36 | consmith | bluelightning: the glossary entry for BB_STAMP_POLICY also references timestamp comparisons |
| 15:59.24 | bluelightning | consmith: ok, that's news to me - looks like it's legacy functionality based on the accompanying note "Stamp policies are largely obsolete with the introduction of setscene tasks. " |
| 16:01.39 | consmith | I see. thanks! so why do all the signatures need to be generated at the beginning? |
| 16:02.37 | *** join/#oe dvhart_ (dvhart@nat/intel/x-qmtzcugfxqazhhjc) |
| 16:02.46 | bluelightning | consmith: well, a task's signature of course depends on the signatures of all of the tasks it has dependencies upon |
| 16:03.34 | bluelightning | consmith: plus, in order to determine whether we can fetch and extract the output of the task from sstate or not we need to calculate the signature first |
| 16:07.11 | consmith | bluelightning: that makes sense, and I see in the source that it's done that way, but I'm just curious if there's a reason signatures couldn't be generated on demand individually as tasks are prepared to run. in other words, does the whole set of signatures need to be available before a single task can run, or could a task generate its signature (and those of its dependencies) before it runs |
| 16:07.43 | *** join/#oe nerdboy (~sarnold@gatekeeper.gentoogeek.org) |
| 16:08.05 | *** join/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
| 16:09.06 | bluelightning | consmith: we would have to integrate the setscene and normal runqueues for that to work |
| 16:09.50 | bluelightning | consmith: plus we have the ability for setscene tasks to "cover" a task's dependent tasks in addition to the task itself |
| 16:10.39 | bluelightning | I don't know if that fully explains it, there may be other considerations - RP may be able to elucidate further |
| 16:11.18 | consmith | bluelightning: oh, so all of the setscene tasks run before any normal tasks are run, and at least one reason for that is because setscene tasks could potentially "cover" other tasks? |
| 16:11.41 | bluelightning | yes |
| 16:12.04 | consmith | fantastic. thanks for explaining that to me |
| 16:12.10 | bluelightning | np |
| 16:12.20 | RP | that is exactly it. If we can pull all the ipks for example, we don't need the compiler or package tools |
| 16:13.10 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 16:13.17 | consmith | that makes sense |
| 16:16.31 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 16:19.36 | *** join/#oe khem` (~khem@unaffiliated/khem) |
| 16:30.46 | *** join/#oe sarahsharp (sarah@nat/intel/x-fcjonszubpzotgft) |
| 16:38.39 | *** join/#oe dvhart_ (dvhart@nat/intel/x-zlqhmvsegzekfuur) |
| 16:56.52 | Crofton|work | atlas is depressing |
| 16:59.29 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 16:59.50 | bluelightning | atlas shrugged? |
| 16:59.53 | bluelightning | ;) |
| 17:00.18 | bluelightning | sorry, that probably isn't helpful |
| 17:04.11 | nerdboy | https://www.youtube.com/watch?v=xxcLNHasPx4 <= more helpful that ayn rand |
| 17:08.14 | *** join/#oe dvhart_ (~dvhart@134.134.137.73) |
| 17:24.12 | Crofton|work | look slike handwritten configure |
| 17:27.19 | *** join/#oe phdeswer (~phdeswer@193.185.223.3) |
| 17:53.13 | *** join/#oe dvhart_ (dvhart@nat/intel/x-njoofufzabzggifl) |
| 18:22.31 | *** join/#oe blilly (~blilly1@c-50-170-54-92.hsd1.wa.comcast.net) |
| 18:41.18 | *** part/#oe adelcast (~adelcast@130.164.62.82) |
| 18:42.20 | *** join/#oe adelcast (~adelcast@130.164.62.82) |
| 19:02.14 | consmith | are stamp files used on both setscene and normal tasks? |
| 19:12.35 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-iaqjjjdqlmtmlkdm) |
| 19:23.54 | *** join/#oe _dv_ (~quassel@chello062178118086.5.14.vie.surfer.at) |
| 19:59.07 | *** join/#oe sarahsharp (~sarah@134.134.139.76) |
| 20:15.21 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 20:59.13 | *** join/#oe awe00 (~awe00@37.165.46.18) |
| 21:02.41 | *** join/#oe yann (~dwitch@nan92-1-81-57-214-146.fbx.proxad.net) |
| 21:07.51 | *** join/#oe bluelightning (~paul@2001:8b0:258:7d7a:2ad2:44ff:fe40:9209) |
| 21:07.51 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 21:14.21 | *** join/#oe vmeson (~rmacleod@24-212-184-107.cable.teksavvy.com) |
| 21:22.53 | *** join/#oe roric (~roric@h196n19-vrr-a31.ias.bredband.telia.com) |
| 21:25.37 | *** join/#oe sarahsharp (~sarah@192.55.54.36) |
| 21:26.50 | *** join/#oe DJW|Home (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 21:58.12 | *** join/#oe awe00 (~awe00@78.250.90.96) |
| 21:58.53 | *** join/#oe Jay7 (jay@128-73-158-77.broadband.corbina.ru) |
| 22:01.09 | *** join/#oe dvhart_ (dvhart@nat/intel/x-kevhmpswgfrprcxg) |
| 22:18.50 | *** join/#oe s3v3n62mm2 (~s3v3n62mm@95.91.197.103) |
| 22:24.14 | *** join/#oe dlan (~dennis@116.228.88.131) |
| 22:24.14 | *** join/#oe dlan (~dennis@gentoo/developer/dlan) |
| 22:27.32 | *** join/#oe sarahsharp (~sarah@192.55.54.36) |
| 22:28.58 | *** join/#oe moto-timo (~timo@72.29.171.20) |
| 22:31.51 | *** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy) |
| 22:33.06 | *** join/#oe dl9pf (~quassel@opensuse/member/dl9pf) |
| 22:33.42 | *** join/#oe blilly (~blilly1@c-50-170-54-92.hsd1.wa.comcast.net) |
| 22:33.54 | *** join/#oe dvhart_ (dvhart@nat/intel/x-gjezwzuwbhtbqzuh) |
| 22:36.36 | *** join/#oe rsalveti (~rsalveti@162.243.213.221) |
| 22:36.52 | *** join/#oe moto_timo (~timo@fsf/member/moto-timo) |
| 22:37.52 | *** join/#oe eballetbo (eballetbo@pasanda.collabora.co.uk) |
| 22:38.35 | *** join/#oe PaulePanter (~paul@mail.gw90.de) |
| 22:41.47 | *** join/#oe uwe_mobile (~uwe@static.88-198-8-117.clients.your-server.de) |
| 22:43.53 | *** join/#oe slapin (~slapin@slapinbuild.ihdev.net) |
| 22:47.15 | *** join/#oe lumag_ (~lumag@ppp89-110-30-167.pppoe.avangarddsl.ru) |
| 22:49.09 | *** join/#oe s3v3n62mm (~s3v3n62mm@95.91.196.7) |
| 23:03.22 | *** join/#oe kido (~kido@unaffiliated/kido) |
| 23:06.42 | *** join/#oe stefan1234 (~stefan@p4FF8351F.dip0.t-ipconnect.de) |
| 23:19.31 | *** join/#oe lumag__ (~lumag@ppp89-110-24-116.pppoe.avangarddsl.ru) |
| 23:41.08 | *** join/#oe stefan1234 (~stefan@pD9F79B27.dip0.t-ipconnect.de) |