| 00:25.07 | *** join/#oe nslu2-log (~nslu2-log@140.211.169.184) |
| 00:53.49 | *** join/#oe sgw_ (~sgw_@c-73-164-210-189.hsd1.or.comcast.net) |
| 01:07.41 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
| 02:48.04 | *** join/#oe RagBal (~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl) |
| 02:48.34 | *** join/#oe Rootert (~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl) |
| 03:00.15 | *** join/#oe nslu2-log (~nslu2-log@140.211.169.184) |
| 03:36.26 | *** join/#oe ensc_ (~irc-ensc@fedora/ensc) |
| 03:49.37 | *** join/#oe NileshKokane (uid116340@gateway/web/irccloud.com/x-ojqckgihpxwnypsa) |
| 03:49.39 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-ceqxdchxraebgdrh) |
| 04:10.31 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 04:28.14 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 04:29.01 | *** join/#oe phdeswer (~phdeswer@91-159-55-220.elisa-laajakaista.fi) |
| 05:38.32 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 06:07.10 | *** join/#oe AndersD (~anders@213-64-219-84-no126.business.telia.com) |
| 07:03.48 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 07:30.13 | *** join/#oe kurre2 (~tomimo@xdsl-83-150-88-111.nebulazone.fi) |
| 07:31.53 | *** join/#oe fabo (~fabo@linaro/fabo) |
| 08:01.00 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-tolsqotoluzeazoq) |
| 08:03.42 | *** join/#oe jku (jku@nat/intel/x-gqytuynbdypqtqkm) |
| 08:10.48 | mckoan | good morning |
| 08:13.09 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 08:13.23 | *** join/#oe fredcadete (d4a63893@gateway/web/freenode/ip.212.166.56.147) |
| 08:35.19 | *** join/#oe rburton (~Adium@35.106.2.81.in-addr.arpa) |
| 08:55.30 | *** join/#oe maxin (~maxin@194.136.86.45) |
| 09:03.25 | *** join/#oe bluelightning (~paul@ip5f5ae69b.dynamic.kabel-deutschland.de) |
| 09:03.34 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 09:18.51 | bluelightning | morning all |
| 09:21.36 | *** join/#oe jonathanmaw (~jonathanm@82-70-136-246.dsl.in-addr.zen.co.uk) |
| 09:21.41 | abelloni | why is the default tune for cortexa5 armv7a-neon? |
| 09:21.59 | abelloni | I think this is the worst possible one |
| 09:22.36 | bluelightning | anything useful in git blame? |
| 09:23.36 | Jin^eLD | mornin |
| 09:24.56 | abelloni | actually, this is the same for all cortex*.inc |
| 09:25.19 | abelloni | I'm not exactly sure why anybody would really want to use neon as the fpu |
| 09:25.56 | abelloni | especially since 1/ all socs don't have neon and 2/ an other FPU is available when you have neon |
| 09:28.02 | abelloni | and the last point being that neon is not ieee compliant, so gcc doesn't actually do any optimisations |
| 09:32.03 | *** join/#oe ao2 (~ao2@host138-106-dynamic.57-82-r.retail.telecomitalia.it) |
| 09:33.10 | abelloni | a11bdc36a1be18cc5aa14682b2a2c9ee83141f51 |
| 09:36.06 | bluelightning | JaMa: any thoughts? ^ |
| 09:37.23 | *** join/#oe tasslehoff (~Tasslehof@82.147.55.166) |
| 09:37.28 | abelloni | If that was for compatibility with existing feeds, then that is probably fine |
| 09:37.37 | abelloni | but it is an unfotunate choice |
| 09:39.40 | mago_ | morning |
| 09:41.35 | *** join/#oe belen (Adium@nat/intel/x-ahxxfqhyqspgqpui) |
| 09:42.44 | mago_ | bluelightning: why doesn't SRC_URI_ti33x += "myvalue" from a .bbappend append to SRC_URI? Why do I have to use SRC_URI_append_ti33x += "myvalue"? I read the bitbake manual, and it clearly states += should append to the variable (surrounded by spaces). What am I doing wrong here? |
| 09:43.14 | bluelightning | mago_: because overrides and += operate at different times, leading to a result which is not the one you want |
| 09:43.43 | bluelightning | mago_: += operates at the time the statement is parsed, the override is applied effectively at the end |
| 09:43.44 | mago_ | okay, so += will run before the original recipes SRC_URI = "" ? |
| 09:44.05 | mago_ | why are .bbappends parsed before .bb then? |
| 09:44.45 | bluelightning | mago_: so what you're saying is, *set* SRC_URI_ti33x to "myvalue" then later when overrides are processed, ti33x is (presumably) in OVERRIDES and thus that value completely overwrites SRC_URI |
| 09:45.11 | bluelightning | technically it gets set to " myvalue" due to the += |
| 09:45.44 | bluelightning | bbappends are absolutely not parsed before the main bb, it's the other way around |
| 09:46.17 | mago_ | ah, i see! |
| 09:46.30 | bluelightning | basically if you use overrides at all you need to use _append so that the override and the append actually work together |
| 09:46.50 | bluelightning | well, if you use overrides and you want to add to the existing value |
| 09:47.26 | ndec | hehe.. who thinks we have a fairly complex variables handling ;-) |
| 09:47.32 | bluelightning | oh, we definitely do |
| 09:48.03 | bluelightning | it's the unfortunate consequence of handling everything people want to handle (as well as borrowing concepts from probably more than one other system) |
| 09:48.27 | bluelightning | mago_: you'd also typically do ..._append = " myvalue" rather than ..._append += "myvalue" |
| 09:49.20 | mago_ | why? |
| 09:49.31 | bluelightning | since the += isn't going to do anything useful apart from adding the space, at which point you might as well just be explicit and then it's obvious |
| 09:49.38 | mago_ | it there a sanity-checker for this somewhere hidden in meta-oe-core/scripts? :) |
| 09:49.59 | bluelightning | not for this kind of thing no |
| 09:51.41 | bluelightning | there was some discussion on layer validation at OEDEM, potentially this sort of thing could go in there though it's less of an actual issue than the problems that script is proposed to pick up on (e.g. BSP layers that don't bother to use overrides and therefore make changes when the relevant machine isn't selected) |
| 09:51.48 | mago_ | bluelightning: another thing, if i want to append to a task for a specific machine, like so: do_install_append_mymachine() { .. } .. how would i do it if i want to apply the same override for 2 machines? do i need to duplicate the entire task? |
| 09:52.18 | bluelightning | there are several ways you could avoid that |
| 09:52.32 | bluelightning | you could have a common override set by both machines and then use that |
| 09:53.02 | bluelightning | or, you could move the content you're appending to a separate function and then call that from both machine appends |
| 09:53.38 | bluelightning | there are one or two other ways I can think of but they are less tidy |
| 09:54.43 | bluelightning | another thing you could consider is use conditionals in the appended function rather than conditional appends |
| 09:54.59 | *** join/#oe darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 09:55.34 | bluelightning | but then your bbappend would be affecting the function unconditionally which could be a bad thing |
| 09:55.52 | bluelightning | (affecting its signature, that is) |
| 09:58.28 | mago_ | okay |
| 09:58.34 | bluelightning | if you find yourself needing to do this in a few places the common override is probably the way to go |
| 09:58.55 | mago_ | i think moving the function body to a separate function and then calling that from each machive append appeals me the most |
| 09:59.52 | bluelightning | right, it's certainly straightforward |
| 09:59.59 | mago_ | yeah, the way we do it now is to override on the arch instead of the machine. it's OK since all our machines on the same arch are more or less the same boards. but if someone were to make a completely different board with that arch some day, we would be in trouble |
| 10:01.25 | *** join/#oe _ao2 (~ao2@host138-106-dynamic.57-82-r.retail.telecomitalia.it) |
| 10:01.35 | bluelightning | right, indeed |
| 10:05.21 | JaMa | abelloni: bluelightning: this commit didn't add neon, it just switched the default to more generic one to re-use binary feeds between different MACHINEs |
| 10:05.34 | JaMa | you need to git blame a bit deeper |
| 10:06.00 | *** join/#oe yann|work (~yann@LFbn-1-1026-146.w86-247.abo.wanadoo.fr) |
| 10:37.14 | *** join/#oe ldnunes (~ldnunes_@177.100.174.62) |
| 10:50.03 | *** join/#oe jackmitchell (~Thunderbi@109.224.219.180) |
| 11:02.14 | funman | JaMa: hello, just answered you about gnome-vfs |
| 11:05.24 | funman | I want to add a new library as a dependency to another package, should that be 2 commits (library, then dependency) or 1 ? |
| 11:07.39 | JaMa | funman: doesn't matter, but if 2 commits then library first :) |
| 11:07.48 | funman | eheh sure |
| 11:08.03 | funman | how do commits migrate (or not) from master-next to master? |
| 11:09.21 | JaMa | when there is no negative feedback and all my jenkins builds don't find any issues I cherry-pick OK commits from master-next to master |
| 11:15.19 | *** join/#oe Net147 (~Net147@unaffiliated/net147) |
| 11:16.11 | funman | hm weird: WARNING: QA Issue: vlc rdepends on libdvbpsi, but it isn't a build dependency? [build-deps] |
| 11:17.14 | *** join/#oe belen (Adium@nat/intel/x-nwyqiuhxrpegxhby) |
| 11:23.25 | *** join/#oe Net147 (~Net147@unaffiliated/net147) |
| 11:27.23 | JaMa | funman: why weird? |
| 11:27.34 | JaMa | funman: probably needs another PACKAGECONFIG for dvbpsi |
| 11:27.47 | *** join/#oe jku (jku@nat/intel/x-ekreokdlfzfqwwnx) |
| 11:27.59 | funman | weird because I had just added it, I probably started bitbake before writing my changes to vlc.inc |
| 11:28.06 | funman | now I don't see this error anymore |
| 11:41.11 | *** join/#oe wenzong (~wfan@106.120.101.38) |
| 11:49.44 | rburton | funman: presumably vlc auto-detected it |
| 11:56.04 | funman | yes |
| 12:11.44 | *** join/#oe tsramos (~tsramos@134.134.137.73) |
| 12:13.02 | mago_ | whats the recommended way of deploying oe images to a device? is there a generic tool? that handles stuff like tftp transfer, dfu, u-boot commands etc |
| 12:13.37 | bluelightning | I'm not sure if there is one generic tool, no |
| 12:14.23 | mago_ | we've written one for our devices, but we're having problems packaging it so the tools is version-matched with our dist releases |
| 12:14.53 | mago_ | basically, deploytool version X works with distro release Y |
| 12:18.09 | bluelightning | distro being your distro or host distro? |
| 12:18.18 | mago_ | my distro |
| 12:19.05 | bluelightning | I guess you'd have to expand on the problem because at the moment I'm not quite followin |
| 12:19.07 | bluelightning | g |
| 12:23.40 | mago_ | well, our tool to deploy images to devices runs u-boot commands on the device to initiate tftp transfers etc. we recently did some changes to the u-boot macro for deploying stuff, and changed the deployment tool to match that. It breaks backwards-compatibility, so the latest deployment tool is unable to deploy images to older u-boots (because it doesn't have the new macros). For this reason, we need to make sure |
| 12:23.42 | mago_ | users use the older version of the deployment tool on distro versions with the old u-boot, and the new deployment tool on the latest distro version. Basically, we want to make sure users use the correct deployment tool version for the distro version they are using |
| 12:23.57 | mago_ | one could argue that we shouldn't be breaking backwardscompatibility in the first place, but in this case we must do it |
| 12:25.45 | mago_ | i noticed dfu-util-native recipe in oe-core installs itself to ${DEPLOY_DIR_TOOLS}, what is the purpose of this folder? What would happen if I wrote a bitbake recipe that installs our deployment tool here, and make sure the PATH is setup to look for host tools here? |
| 12:28.11 | bluelightning | I think DEPLOY_DIR_TOOLS is something that was set up a long time ago but AFAIK it's very rarely used |
| 12:28.57 | bluelightning | you say it's in OE-Core but I don't see any reference to that var there other than setting it in bitbake.conf |
| 12:30.58 | mago_ | sorry, it's in meta-openembedded/meta-oe/.. |
| 12:31.23 | bluelightning | ah right, yes |
| 12:31.45 | bluelightning | so for a lot of this kind of thing elsewhere we are simply using the native sysroot |
| 12:31.59 | bluelightning | e.g. runqemu looks for tunctl there, wic looks for all the tools it needs there, etc. |
| 12:32.51 | mago_ | ah, okay. i see, so you have wrapper-scripts that setup PATH to point to native sysroot and then launch the app? |
| 12:34.12 | mago_ | our deployment tool is python-based, so ideally we would like a deployment tool native recipe that installs it into the native sysroot, RDEPENDS python-native. And then we would have a small shellscript in our meta-layer that just launches "$SYSROOT/python $SYSROOT/deployment-script.py"? |
| 12:40.39 | bluelightning | mago_: well not really, the assumption is that you have run the env setup script (e.g. oe-setup-build-env) first |
| 12:40.58 | bluelightning | and then you can get bitbake to tell you where the native sysroot is |
| 12:42.34 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 12:44.09 | mago_ | bluelightning: just so that i understand how runqemu works: 1) oe-setup-build-env is sourced, sets up PATH to bitbake and oe-core/scripts 2) user runs "runqemu", it launches bitbake to figure out SYSROOT and then launches qemu from that location 3) if user did not yet build qemu-native, runqemu will run bitbake to build it? |
| 12:44.43 | bluelightning | correct except for 3 |
| 12:44.54 | bluelightning | if it's not built, it'll just bail out and tell the user what they need to build |
| 12:45.31 | mago_ | ok, so in that case i can probably do the same for our deployment tool. Sounds good |
| 12:45.57 | bluelightning | you may find tinfoil useful rather than bitbake -e for grabbing var values btw |
| 12:46.23 | bluelightning | a bunch of our scripts do still use bitbake -e but tinfoil is neater (and a bit faster) |
| 12:46.43 | bluelightning | goes to find a suitable example |
| 12:46.48 | mago_ | ah, okay. great. I use bitbake -e in our buildscripts atm, will look into tinfoil instead |
| 12:48.20 | bluelightning | mago_: scripts/oe-pkgdata-util is probably worth looking at for an example of using tinfoil to just grab a variable value |
| 12:48.29 | mago_ | thank you |
| 12:49.24 | mago_ | bluelightning: .. but tinfoil is python only? i would prefer if python was not a host dependency |
| 12:49.35 | mago_ | .. but then again, bitbake is python *doh* :D |
| 12:49.46 | mago_ | (nvm) |
| 12:51.19 | mago_ | oe-core/scripts/oe-find-native-sysroot seem useful for me |
| 12:51.25 | bluelightning | heh |
| 12:51.30 | bluelightning | right yes there's that too |
| 12:51.57 | bluelightning | personally I prefer to write these kinds of scripts in python, shell is just a bit painful for anything non-trivial |
| 12:51.59 | bluelightning | but that's just me |
| 12:52.01 | bluelightning | brb |
| 12:52.50 | JaMa | funman: I've squashed those 2 vlc gnome-vfs commits in master-next, you don't need to resend |
| 12:54.43 | Crofton|work | needs to fight llvm some more |
| 12:57.22 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 13:25.43 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 13:27.05 | mago_ | if i BBCLASSEXTEND = "native" in a recipe that RDEPENDS_${PN} = "python-othermodule", do I have to specify RDEPENDS_${PN}_class-native = "python-othermodule-native" \ RDEPENDS_${PN}_class-target = "python-othermodule", or will this be implied by going native? |
| 13:27.25 | mago_ | (e.g will a native recipe automatically add -native to all RDEPENDS?) |
| 13:34.23 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 13:55.46 | *** join/#oe darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 13:58.14 | funman | JaMa: thanks |
| 14:00.20 | funman | JaMa: oops |
| 14:03.50 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 14:06.01 | *** join/#oe rob_w (~bob@ppp-88-217-105-136.dynamic.mnet-online.de) |
| 14:06.01 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 14:06.13 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 14:06.20 | *** join/#oe ohama (~ohama@cicolina.org) |
| 14:07.16 | *** join/#oe jackmitchell (~Thunderbi@109.224.219.180) |
| 14:07.27 | bluelightning | mago_: well, RDEPENDS don't really make sense in the native context |
| 14:08.02 | bluelightning | having said that, yes they are mapped |
| 14:17.39 | mago_ | bluelightning: why is not RDEPENDS applicable in native? they should just be treated as DEPENDS? |
| 14:24.43 | bluelightning | mago_: well, let's just assume they were applicable, leaving aside that RDEPENDS deals with packages and there is no packaging for native recipes |
| 14:26.25 | bluelightning | mago_: in that case if a-native RDEPENDS on b-native, then "runtime" would effectively be build time, since runtime for native is running things from the sysroot i.e. a-native's do_configure needs b-native's do_populate_sysroot |
| 14:26.33 | bluelightning | mago_: which is exactly what DEPENDS does |
| 14:27.32 | bluelightning | I've just tested, RDEPENDS has no effect on task dependencies for native recipes |
| 14:28.11 | mago_ | bluelightning: so if i want to make sure other python modules are installed into native sysroot for my python program, i should DEPENDS_class-native = "..." ? |
| 14:28.35 | mago_ | bluelightning: btw, do you know where the root-user account is created and why its home is set to /home/root and not /root (which is more common)? |
| 14:28.59 | bluelightning | mago_: I believe so yes |
| 14:30.22 | bluelightning | mago_: largely historical reasons; the idea was all home directories should be able to be together on their own partition/device |
| 14:30.40 | bluelightning | mago_: we have a variable ROOT_HOME that you can set to change it to /root in your distro config if you prefer |
| 14:34.07 | *** join/#oe jackmitchell (~Thunderbi@109.224.219.180) |
| 14:42.30 | *** join/#oe dv_ (~quassel@chello062178118086.5.14.vie.surfer.at) |
| 14:43.04 | *** join/#oe cbrake (~Thunderbi@cable2-pool191-cs-134.doycomm.com) |
| 14:43.50 | *** join/#oe denix (~denix@pool-108-51-169-48.washdc.fios.verizon.net) |
| 14:44.26 | *** join/#oe debris` (debris@shells.fnordserver.eu) |
| 14:44.36 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 14:45.27 | *** join/#oe AndersD (~anders@213-64-219-84-no126.business.telia.com) |
| 14:45.56 | *** join/#oe mnemoc (~amery@kwa.jpi.io) |
| 14:46.39 | *** join/#oe ftonello (~quassel@81.145.202.106) |
| 14:54.49 | *** join/#oe BlindMan (~othmar@chello080108122130.6.11.vie.surfer.at) |
| 14:58.46 | *** join/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 14:58.56 | *** part/#oe madisox (~madison@216-75-232-11.static.wiline.com) |
| 15:00.19 | *** join/#oe yann|work (~yann@LFbn-1-1026-146.w86-247.abo.wanadoo.fr) |
| 15:03.50 | *** join/#oe rburton1 (~Adium@35.106.2.81.in-addr.arpa) |
| 15:05.28 | mago_ | bluelightning: if i want to run python from the sysroot, do i manually need to setup the PYTHONPATH to point into the sysroot or is there a way i can run native python with the "correct" sysroot environment? |
| 15:05.34 | *** join/#oe berton (~fabio@201.22.227.56) |
| 15:07.02 | fray | can anyone point me where the code is that displays the list of layers with their git/SCM ids at the start of every build? |
| 15:10.14 | *** join/#oe jackmitchell (~Thunderbi@109.224.219.180) |
| 15:11.49 | funman | fray: repo status? |
| 15:12.08 | funman | (that would be with angstrom) |
| 15:13.12 | funman | . |
| 15:15.43 | bluelightning | mago_: just inherit pythonnative for that I think |
| 15:17.30 | *** join/#oe jku (~jku@212-149-207-214.bb.dnainternet.fi) |
| 15:30.58 | mago_ | bluelightning: hum, how does that work? isn't it a python thing? i mean if i just run python from the sysroot, it has nothing to do with my python module (where i've inherited pythonnative?) |
| 15:31.47 | bluelightning | mago_: I assumed you meant in the recipe context; are you trying to run it from outside? |
| 15:32.33 | mago_ | bluelightning: yeah, i'm trying to do that runqemu scheme we talked about :) basically 1) discover sysroot path using bitbake 2) run python-native with a native python-script (installed by a python recipe) |
| 15:34.18 | bluelightning | I'm not sure but I'm guessing you'd ensure PATH and PYTHONPATH and/or PYTHONHOME |
| 15:34.29 | bluelightning | (ensure they are set, I meant) |
| 15:35.08 | *** join/#oe rburton (~Adium@35.106.2.81.in-addr.arpa) |
| 15:35.11 | mago_ | okay. then i don't see the point in ever building python-native? since python is always on the host? |
| 15:36.43 | kergoth | python-native is *required* by python, to cross-compile we need a python we can run with a matching version and which obeys sysroot paths for the sys module. beyond that, its debatable |
| 15:36.47 | kergoth | yawns |
| 15:36.50 | Crofton|work | version sanity |
| 15:39.10 | *** join/#oe jku (~jku@d-lltyyyyyyyyyyyyyk-3.rev.dnainternet.fi) |
| 15:39.48 | fray | funman, no when you run bitbake ... it prints out the SCM information for each included layer |
| 15:40.14 | fray | i.e. |
| 15:40.18 | fray | TUNE_FEATURES = "m32 i586" |
| 15:40.19 | fray | TARGET_FPU = "" |
| 15:40.19 | fray | meta = "jethro:4a8f2f24adcb8bacd8c32ad7b3d6c2f0ac422603" |
| 15:40.57 | fray | I'm looking for the code that actually prints out those values |
| 15:41.11 | kergoth | fray: metadata_scm.bbclass, iirc |
| 15:41.45 | fray | (I've got some non-git branches.. and it's spitting out errors.. and I'm trying to determine if it's an OE bug or if it's a local bug) |
| 15:55.07 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 15:55.16 | *** join/#oe berton_ (~fabio@201.22.227.56) |
| 15:59.17 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 16:15.45 | *** join/#oe sgw_ (~sgw_@134.134.137.73) |
| 16:31.20 | *** join/#oe jku (~jku@d-lltyxzqsj--98wl3k-3.rev.dnainternet.fi) |
| 16:36.12 | *** join/#oe RP (~richard@5751f4a1.skybroadband.com) |
| 16:49.03 | *** join/#oe rob_w_ (~rob@ppp-88-217-105-136.dynamic.mnet-online.de) |
| 16:50.07 | *** join/#oe rburton1 (~Adium@35.106.2.81.in-addr.arpa) |
| 16:52.42 | *** join/#oe silviof1 (~silviof@ip5f5ba60a.dynamic.kabel-deutschland.de) |
| 16:52.47 | *** join/#oe ensc (~irc-ensc@fedora/ensc) |
| 16:53.59 | *** join/#oe BlindMan_ (~othmar@chello080108122130.6.11.vie.surfer.at) |
| 16:54.38 | *** join/#oe toutour_ (~toutour@causses.idest.org) |
| 16:55.23 | *** join/#oe Meuuh_ (~cmassiot@lea.openheadend.tv) |
| 16:57.08 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 16:58.21 | *** join/#oe rsalveti (sid117878@linaro/rsalveti) |
| 16:58.23 | *** join/#oe NightMonkey_ (~NightMonk@pdpc/supporter/professional/nightmonkey) |
| 16:58.52 | *** join/#oe deception (~deception@unaffiliated/deception) |
| 16:58.55 | *** join/#oe dv__ (~quassel@chello062178118086.5.14.vie.surfer.at) |
| 16:59.27 | *** join/#oe kergoth` (~kergoth@107.170.225.75) |
| 17:00.32 | *** join/#oe jackmitchell1 (~Thunderbi@109.224.219.180) |
| 17:01.30 | *** join/#oe dv_ (~quassel@chello062178118086.5.14.vie.surfer.at) |
| 17:01.37 | *** join/#oe KNERD_ (~KNERD@netservisity.com) |
| 17:08.36 | *** join/#oe darknighte (~darknight@pdpc/supporter/professional/darknighte) |
| 17:08.40 | *** join/#oe belen (Adium@nat/intel/x-wvochsidovxiikdo) |
| 17:09.57 | *** join/#oe sgw_ (~sgw_@c-73-164-210-189.hsd1.or.comcast.net) |
| 17:11.33 | *** part/#oe maxin (~maxin@194.136.86.45) |
| 17:14.05 | *** join/#oe realBigfoot (~realBigfo@192.55.55.41) |
| 17:14.10 | *** join/#oe anarsoul (~kvirc@S0106848dc7ec0367.vs.shawcable.net) |
| 17:15.09 | *** join/#oe zoli_ (zoli_@gateway/shell/linaro/x-igopsbpdwthetmkj) |
| 17:27.56 | *** join/#oe kristoffer (~kristoffe@ua-83-227-162-207.cust.bredbandsbolaget.se) |
| 17:29.02 | *** join/#oe berton (~fabio@201.22.227.56) |
| 17:55.51 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 17:56.39 | *** join/#oe darkschneider (~gab@93-32-59-44.ip32.fastwebnet.it) |
| 18:00.42 | *** join/#oe tsramos (~tsramos@134.134.139.77) |
| 18:03.21 | *** join/#oe belen (Adium@nat/intel/x-zfikemztenirqnqv) |
| 18:15.57 | *** join/#oe anarsoul (~kvirc@205.250.92.228) |
| 18:30.52 | *** join/#oe yann|work (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 18:36.59 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 18:47.16 | *** join/#oe ndec (~ndec@linaro/ndec) |
| 18:47.36 | *** join/#oe paulg (~paulg@CPE90724002db4e-CMbcc8101466a3.cpe.net.cable.rogers.com) |
| 19:05.30 | *** join/#oe tsramos (~tsramos@134.134.137.73) |
| 19:10.28 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 19:33.24 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 19:33.32 | *** part/#oe adelcast (~adelcast@130.164.62.82) |
| 19:35.39 | *** join/#oe adelcast (~adelcast@130.164.62.224) |
| 19:59.27 | *** join/#oe belen (~Adium@81.2.114.17) |
| 20:05.52 | *** join/#oe realBigfoot (~realBigfo@192.55.55.41) |
| 20:13.32 | *** join/#oe jku (~jku@212-149-207-214.bb.dnainternet.fi) |
| 20:19.15 | *** join/#oe jku (~jku@d-lltyyyyyyyyyyyyyk-3.rev.dnainternet.fi) |
| 20:42.50 | *** join/#oe stephano (~stephano@74-92-165-193-Oregon.hfc.comcastbusiness.net) |
| 20:47.04 | *** join/#oe bluelightning (~paul@ip5f5ae69b.dynamic.kabel-deutschland.de) |
| 20:47.04 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 20:50.38 | *** join/#oe ao2 (~ao2@host138-106-dynamic.57-82-r.retail.telecomitalia.it) |
| 20:58.46 | *** join/#oe jku (~jku@212-149-207-214.bb.dnainternet.fi) |
| 21:00.55 | *** join/#oe jackmitch|home (~Thunderbi@cpc2-slam8-2-0-cust880.2-4.cable.virginm.net) |
| 21:07.45 | *** join/#oe jku (~jku@d-lltyyyyyyyyyyyyyk-3.rev.dnainternet.fi) |
| 21:21.58 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 21:25.28 | *** join/#oe paulg (~paulg@OTWAON23-1279379696.sdsl.bell.ca) |
| 21:29.19 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 21:53.17 | *** join/#oe tsramos_ (~tsramos@134.134.139.77) |
| 22:10.09 | *** join/#oe rsalveti (sid117878@linaro/rsalveti) |
| 23:35.46 | *** join/#oe yann|work (~yann@nan92-1-81-57-214-146.fbx.proxad.net) |
| 23:40.29 | *** join/#oe rsalveti (sid117878@linaro/rsalveti) |
| 23:41.26 | *** join/#oe nerdboy (~sarnold@gatekeeper.gentoogeek.org) |
| 23:41.26 | *** join/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
| 23:44.32 | *** join/#oe Net147 (~Net147@unaffiliated/net147) |
| 23:50.43 | *** join/#oe nslu2-log (~nslu2-log@140.211.169.184) |
| 23:51.53 | *** join/#oe ftonello (~quassel@81.145.202.106) |