| 00:37.58 | *** join/#oe likewise (~likewise@145.132.74.106) |
| 01:56.15 | *** join/#oe aloril (~aloril@dsl-tkubrasgw1-54fa3f-129.dhcp.inet.fi) |
| 02:05.57 | *** join/#oe aloril (~aloril@dsl-tkubrasgw1-54fa3f-129.dhcp.inet.fi) |
| 02:38.53 | *** join/#oe likewise (~likewise@145.132.74.106) |
| 02:44.24 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-bsocomtdvxrzslqo) |
| 02:48.49 | *** join/#oe DJW|Home (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 03:12.12 | *** join/#oe evanmeagher (~MongooseW@c-73-71-33-109.hsd1.ca.comcast.net) |
| 04:39.41 | *** join/#oe likewise (~likewise@145.132.74.106) |
| 05:08.45 | *** join/#oe AndersD (~anders@213-64-218-130-no126.business.telia.com) |
| 05:26.21 | *** join/#oe AndersD (~anders@213-64-218-130-no126.business.telia.com) |
| 05:53.28 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 06:14.52 | *** join/#oe ecloud (quassel@nat/digia/x-awhdaltskzrnujav) |
| 06:40.40 | *** join/#oe likewise (~likewise@145.132.74.106) |
| 06:43.37 | *** join/#oe jku (jku@nat/intel/x-rjfsixdhblhhaouy) |
| 06:47.35 | *** join/#oe ao2 (~ao2@cl-35.trn-01.it.sixxs.net) |
| 06:57.36 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-hwfjnlhythgsylpb) |
| 07:05.03 | *** join/#oe ant_work (~ant__@95.236.248.154) |
| 07:05.48 | *** join/#oe ant_work (~ant__@95.236.248.154) |
| 07:09.37 | *** join/#oe edbart (~ebartosh@192.198.151.43) |
| 07:17.21 | *** join/#oe melonipoika_ (~jose@194.9.252.237) |
| 07:18.39 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 07:58.32 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 08:13.37 | mckoan | good morning |
| 08:26.39 | *** join/#oe mckoan (~marco@unaffiliated/mckoan) |
| 08:28.37 | *** join/#oe stefan_schmidt (~stefan@p2003004809258C2EF2DEF1FFFE6228F7.dip0.t-ipconnect.de) |
| 08:33.10 | *** join/#oe ecloud_ (~quassel@192.89.120.58) |
| 08:33.36 | *** join/#oe joseppc (~Josep@sestofw01.enea.se) |
| 08:38.56 | *** join/#oe Nilesh_ (3ba0cf05@gateway/web/freenode/ip.59.160.207.5) |
| 08:41.25 | *** join/#oe likewise (~likewise@145.132.74.106) |
| 08:43.27 | Nilesh_ | while attempting to open devshell I get Error:https://paste.kde.org/pjzpmytke ... any clue? |
| 08:55.34 | *** join/#oe abruanese (abruanese@2600:3c03::f03c:91ff:fe55:c675) |
| 08:58.12 | *** join/#oe maxin (~maxin@2001:998:22:0:68c6:9205:baf2:6148) |
| 09:00.06 | mckoan | Nilesh_: No space left on device |
| 09:01.07 | Nilesh_ | mckoan: its 16gb though |
| 09:03.08 | Nilesh_ | is that not enough? |
| 09:07.00 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 09:30.23 | *** join/#oe melonipoika (~jose@194.9.252.237) |
| 09:54.27 | *** join/#oe dv (~quassel@62.178.118.86) |
| 10:02.58 | *** join/#oe JaMa (~martin@ip-86-49-34-37.net.upcbroadband.cz) |
| 10:34.29 | *** join/#oe shoragan_ (~shoragan@chimeria.ext.pengutronix.de) |
| 10:34.29 | *** join/#oe shoragan_ (~shoragan@debian/developer/shoragan) |
| 10:37.19 | *** join/#oe likewise (~likewise@145.132.74.106) |
| 10:37.33 | *** join/#oe joseppc (~Josep@sestofw01.enea.se) |
| 10:37.44 | *** join/#oe ecloud_ (~quassel@192.89.120.58) |
| 10:40.04 | *** join/#oe dlan (~dennis@gentoo/developer/dlan) |
| 11:28.45 | *** join/#oe melonipoika_ (~jose@194.9.252.237) |
| 11:29.41 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-xrxmmhgdzfllfgqb) |
| 11:32.25 | *** join/#oe melonipoika (~jose@194.9.252.237) |
| 11:32.52 | *** join/#oe ldnunes (~ldnunes_@187.23.154.250) |
| 11:45.39 | *** join/#oe berton (~fabio@187.23.154.250) |
| 11:51.26 | *** join/#oe melonipoika (~jose@194.9.252.237) |
| 12:03.28 | *** join/#oe caiortp (~inatel@131.221.240.204) |
| 12:29.36 | *** join/#oe vmeson (~rmacleod@128.224.252.2) |
| 12:30.22 | *** join/#oe vdehors (~vdehors@193.56.60.161) |
| 12:35.56 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 12:49.15 | *** join/#oe kscherer (~kscherer@128.224.252.2) |
| 13:04.08 | *** join/#oe georgem (~georgem@216.21.169.52) |
| 13:07.21 | *** join/#oe infobot (ibot@rikers.org) |
| 13:07.21 | *** 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:37.52 | *** join/#oe behanw (uid110099@gateway/web/irccloud.com/x-dpyzrcqbhzqwhaey) |
| 13:52.46 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 14:06.58 | georgem | Hrm. I guess setcap doesn't working in pseudo? |
| 14:12.29 | *** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 14:19.43 | *** join/#oe madisox (~madison@12.30.244.5) |
| 14:19.45 | *** part/#oe madisox (~madison@12.30.244.5) |
| 14:36.58 | *** join/#oe dvhart (~dvhart@134.134.139.83) |
| 14:37.30 | *** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 15:01.13 | *** join/#oe evanmeagher (~MongooseW@73.71.33.109) |
| 15:12.02 | *** join/#oe melonipoika_ (~jose@194.9.252.237) |
| 15:12.26 | *** join/#oe jchonig (~quassel@firewall.honig.net) |
| 15:17.54 | *** join/#oe abruanes- (abruanese@2600:3c03::f03c:91ff:fe55:c675) |
| 15:18.56 | *** join/#oe hrww (~hrw@redhat/hrw) |
| 15:19.14 | *** join/#oe flynn378__ (sid63564@gateway/web/irccloud.com/x-cbqmlukztntmqkyj) |
| 15:20.24 | *** join/#oe ndec (~ndec@linaro/ndec) |
| 15:21.17 | *** join/#oe systmkor_ (~systmkor@unaffiliated/systmkor) |
| 15:21.54 | *** join/#oe aloril_ (~aloril@dsl-tkubrasgw1-54fa3f-129.dhcp.inet.fi) |
| 15:40.57 | *** join/#oe Aethenelle (~Aethenell@199.15.128.75) |
| 15:47.10 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 15:50.55 | Jin^eLD | hmm, who exactly apart from the kernel itself may depend on "kernel-base"? I can |
| 15:50.59 | Jin^eLD | 't find it |
| 15:51.04 | Jin^eLD | tried -e and such |
| 15:53.40 | *** join/#oe Aethenelle (~Aethenell@199.15.128.78) |
| 16:02.09 | *** join/#oe CipherWizard (~cipherwiz@216-21-169-52.slc.googlefiber.net) |
| 16:10.03 | *** join/#oe dvhart (~dvhart@134.134.139.83) |
| 16:22.16 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 16:30.59 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 16:33.37 | *** join/#oe Nilesh_ (uid116340@gateway/web/irccloud.com/x-eoxmywjhmirouukm) |
| 16:34.38 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 16:34.52 | khem | is calix.com spamming anyone else besides me ? |
| 16:35.47 | khem | I understand you are using a review system but configure it properly please !! |
| 16:55.20 | *** join/#oe Aethenelle (~Aethenell@199.15.128.78) |
| 17:01.57 | *** join/#oe kristoffer (~kristoffe@ua-83-227-162-207.cust.bredbandsbolaget.se) |
| 17:13.29 | *** join/#oe scot (~scot@130.164.62.160) |
| 17:18.46 | *** join/#oe pb_ (~pb@mail.pbcl.net) |
| 17:22.44 | *** join/#oe dvhart (~dvhart@134.134.139.83) |
| 17:25.16 | otavio | Is someone willing to review some Wayland rework patches to support XWayland? |
| 17:26.28 | kergoth | that sounds nice. id on't know enough about wayland to review it, though :) |
| 17:27.13 | kergoth | Anyone want to take a quick glance at my wks.in prototype? I'm mainly looking for a yes/no on whether this direction is completely crazy or not, before I submit the RFC patches to the list -- https://gist.github.com/kergoth/630fc46f774281fd68c82fb9492e0bf8 |
| 17:27.16 | *** join/#oe Net147 (~Net147@unaffiliated/net147) |
| 17:27.36 | kergoth | i think it has value, not hardcoding things like serial console tty in the .wks file for wic would be nice |
| 17:27.37 | kergoth | heh |
| 17:32.46 | otavio | kergoth: agreed however I'd name .in files as bbin or similar |
| 17:32.55 | otavio | .in means autoconf for me |
| 17:32.56 | otavio | kkk |
| 17:33.50 | kergoth | it's a pretty common convention for generated files to go from .in -> no .in, even outside of autoconf. i.e. foo.pc.in -> foo.pc. but it's a fair point, given it's using bitbake variable expansion rather than some other templating mechanism, .bbin or similar could make sense |
| 17:34.44 | kergoth | i thought about leveraging some other templating scheme, but it'd mostly end up translating metadata variables to template fields anyway, so seemed a pointless indirection :) |
| 17:35.29 | otavio | agreed and using a bb.in schema makes sense |
| 17:50.55 | *** join/#oe sgw_ (sgw_@nat/intel/x-xgbgisghyqwlagdw) |
| 17:55.00 | *** join/#oe vdehors_ (~vdehors@bob75-2-81-56-46-209.fbx.proxad.net) |
| 17:55.36 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 17:56.26 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 18:18.31 | armpit | khem, I got the spam too. everyone in commits to oe |
| 18:18.57 | armpit | we should ask them for $$$. they are using OE |
| 18:21.05 | khem | otavio: sure I can review it |
| 18:21.22 | khem | armpit: yeah would be good for folks to support the project |
| 18:21.39 | otavio | khem: great! https://www.dropbox.com/sh/vx1qlei0hl5gxe0/AACElM_DnSepXE6gUT7bbUvAa?dl=0 |
| 18:22.10 | otavio | khem: I will be sending it tomorrow but a pre-patchset review would be nice so we avoid many revisions |
| 18:23.46 | khem | otavio: 0002-weston-Remove-XWayland-dependencies-on-PACKAGECONFIG.patch why remove DEPS |
| 18:24.36 | khem | hmm I see so we have it covered with x11 DISTRO_F |
| 18:25.27 | otavio | khem: yes; it avoids duplication and removed the need to keep it in sync |
| 18:25.41 | otavio | khem: also it is pointless as the x11 is required anyway |
| 18:26.15 | khem | use export XDG_RUNTIME_DIR=/var/run/user/`id -u`/ |
| 18:28.38 | khem | patchset looks good elsewhere |
| 18:32.13 | armpit | khem, I just sent a note about calix to the advocacy team to go chase the lead |
| 18:32.44 | Crofton|work | +1 |
| 18:34.09 | otavio | khem: great |
| 18:34.13 | khem | also send a note to calix on spam, that would be preferred |
| 18:37.15 | otavio | khem: fixed 0002 |
| 18:37.20 | otavio | khem: please take a look |
| 18:38.31 | Crofton|work | https://jobs-calix.icims.com/jobs/3280/senior-software-engineer---embedded---platform/job |
| 18:45.45 | *** join/#oe darknighte (~darknight@pdpc/supporter/professional/darknighte) |
| 18:59.06 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 19:31.10 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 19:35.06 | *** join/#oe mago__ (~mago@105.24-247-81.adsl-static.isp.belgacom.be) |
| 19:40.44 | mago__ | hey. can anyone explain the relationship between poky and openembedded core? i was under the impression that poky is a reference distro ontop of oe-core, yet when i look at the poky repo (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/) i see it has its own copy of both bitbake and oe-core (poky/meta dir). Why are these not submodules? it seems like they have been "copied" into poky, so essentially a fork of |
| 19:40.45 | mago__ | oe-core and upstream bitbake? |
| 19:41.09 | kergoth | poky is both a reference distro and a repository which is an integration of components |
| 19:41.19 | kergoth | the poky repo is oe-core + bitbake + meta-poky/meta-yocto |
| 19:41.21 | fray | submodules are a pain to deal with.. so Poky has decided to include a copuy of the components.. |
| 19:41.39 | kergoth | i think the confusion sets in because the components aren't structured the same |
| 19:41.40 | fray | if you look at the git tree the copy is commented to the oe-core (and bitbake) commit ids.. |
| 19:41.46 | kergoth | i.e. it's meta, not oe-core/meta in poky.git |
| 19:43.00 | mago__ | seems like a really weird way of doing it, essentially cherry-picking each commit from oe-core into poky? |
| 19:43.20 | fray | it's all automated |
| 19:43.21 | kergoth | it's actually fairly common |
| 19:43.28 | fray | and I agree.. it is fairly common.. |
| 19:43.31 | kergoth | there are a lot of tools for puling vendor or third party sources directly into a git repo |
| 19:43.33 | fray | the hatred for submodules is far and wide |
| 19:43.39 | kergoth | if you don't want to, there are tools like submodules, repo, or mr |
| 19:43.53 | kergoth | if you do, there are tools like combo-layer, git-subtree, git-subrepo, piston, braid, peru, etc |
| 19:44.02 | fray | ya.. in the OE/YP world, I'm using to seeing 'repo' and just direct inclusion.. |
| 19:44.07 | fray | (combo-layer effectively) |
| 19:44.22 | kergoth | there's some use of submodules too, but mostly dabblers, not projects |
| 19:44.32 | mago__ | kergoth: are you saying poky/meta isn't just a certain rev of oe-core/meta? |
| 19:44.34 | fray | ya, I've never seen anyone use submodules for real projects.. |
| 19:44.44 | kergoth | mago__: no, that's exactly what it is |
| 19:44.45 | fray | poky/meta tracks oe-core/meta.. |
| 19:44.52 | mago__ | k |
| 19:45.01 | kergoth | and again, there a ton of tools to do this, including external sources directly in a local repository |
| 19:45.01 | mago__ | (i use repo myself) |
| 19:45.15 | kergoth | the value is it's truly self-contained, and you don't have to deal with teh overhead of submodules |
| 19:45.21 | fray | however, submodules have the problem where you have to constantly update them -- and just pulling one tree doesn't give you the info you need... so you have to pull it all down.. it's painful and easy to screw up |
| 19:45.31 | kergoth | yeah, the overhead of updating the main repo every time is a pain |
| 19:45.35 | kergoth | which is where repo comes in, since it can track branches |
| 19:45.54 | fray | product I work on is based on bitbake/oe-core/meta-yocto(poky)/etc.. but we keep it seperate, and do somethign similar to repo |
| 19:46.05 | fray | kergoth, exactly.. tracking branches is the useful part.. |
| 19:46.13 | kergoth | personally, i like to use repo for components of a single project, where they're being actively developed, and something like subtree/subrepo/combo-layer for vendor / third party sources for my projects, so i'm less reliant on them, an dupdate overhead is less of an issue |
| 19:46.23 | kergoth | but everyone has their workflow preferences.. |
| 19:46.32 | fray | yup |
| 19:47.27 | kergoth | e.g. i use peru (not unlike braid/piston/subtree/subrepo, just not bound to the scm) for my dotfiles, for example. those are largely unchanged from upstream and i don't update them enough for the overhead to be problematic, and the repository ends up entirely self contained for anyone cloning it, which is convenient |
| 19:48.58 | kergoth | I really hate that I always spot certain bugs only *after* I submit the patches to the list for review |
| 19:49.01 | kergoth | so annoying |
| 19:49.36 | kergoth | think i might start sending them directly to myself first, just to review the code one last time in a different context |
| 19:49.55 | mago__ | what would you say is the value added by meta-poky & meta-yocto-bsp? is it the genericx86 machines? |
| 19:50.09 | kergoth | no, meta-yocto/meta-poky is the aforementioned reference distribution |
| 19:50.45 | kergoth | meta-yocto-bsp is its reference bsps largely for testing/demos, afaik. most folks don't use meta-yocto-bsp in my experience, they use the layers from the chip manufacturers |
| 19:50.52 | kergoth | shrugs |
| 19:50.58 | mago__ | okay |
| 19:50.59 | fray | yup.. maps what I do |
| 19:51.26 | mago__ | would it be suitable to base a new distro on poky? for example inherit the poky distro config? |
| 19:51.26 | fray | we replace the meta-poky with our own distribution configuration.. and the bsps, with our own as well.. but we allow people to select meta-yocto/meta-poky if they want that specific distribution config |
| 19:51.30 | kergoth | TI, intel, freescale, xilinx, etc all provide their own BSP layers, and I trust them to support their own hardware well |
| 19:51.38 | fray | mago__ yes people do that all the time |
| 19:51.49 | fray | kergoth, you have more faith is semi's them I do.. ;) |
| 19:51.51 | kergoth | mago__: you could, yes, or just copy the bits you care about. the goal is poky doesn't add a ton on top of nodistro |
| 19:52.13 | kergoth | fray: heh, well, i trust them with regard to the support of the hardware, less to do the right thing with regard to yocto |
| 19:52.31 | kergoth | some of those layers need more review to make sure they're playing well with others and doing the Right Thing |
| 19:52.39 | fray | you still trust them more then I do.. I've not had great hardware/software support from semis.. (any semi) |
| 19:52.59 | fray | unless you are buying $ millions in parts, you get 'best effort', often 'worst effort' support.. :P |
| 19:53.26 | fray | (board vendors on the otherhand seem to be a little better -- but they still have the "don't have a clue as to how to do the right thing w/in the yocto project/OE environment) |
| 19:53.28 | kergoth | heh, that's a fair point. there can be a fair bit of difference between the sdks shipped to customers and those in the open source layers, too |
| 19:53.36 | kergoth | nods |
| 19:53.37 | fray | yup |
| 19:54.13 | kergoth | it is fairly common to have to, as a distro / integrator, do a bunch of fixups to the ti/intel/etc layers. which is irritating, since there's no clean way for a distro to exert control over the machine without violating our principles |
| 19:54.30 | kergoth | don't want to fork them, and doing machine hacks in the distro conf is ugly.. |
| 19:55.02 | kergoth | at the moment meta-mentor has its setup scripts supporting local.conf fragments per-machine, and does the fixups there for the most part, configuration wise, so it's user-visible and outside the distro itself |
| 19:55.05 | kergoth | not ideal either, though |
| 19:55.39 | kergoth | need to split that off into a meta-mentor-bsp repo with individual layers per-machine/per-bsp one of these days |
| 19:56.22 | mago__ | kergoth: we do it by supplying machine config includes from our distro, which in turn includes bsp-layer configs. in our includes, we can also fix things |
| 19:56.35 | mago__ | would that be a violation of the principles? |
| 19:59.55 | kergoth | it's not ideal, but that's another option to get the job done. ideally distro/machine/image are completely orthogonal axes, crossing those boundaries violates that, but you have to be realistic. |
| 20:00.25 | kergoth | the reason i did it in the scripts was i saw it as more about the mentor embedded linux *product* than the mentor embedded linux *distro* |
| 20:00.28 | kergoth | shrugs |
| 20:00.41 | kergoth | as with anything else, there are multiple options, in this case none are really elegant |
| 20:02.02 | mago__ | yeah, i think in a real world product, everything is not orthogonal |
| 20:02.38 | kergoth | it should be, but 1) it's not always possible, and 2) deadlines often lead to questionable quality stuff at times, have to deal with the realities |
| 20:02.49 | kergoth | one hopes that one has time to clean up that crap and submit things upstream after the release, though :) |
| 20:02.57 | kergoth | is currently working on the submission backlog at mentor for 2.2 |
| 20:09.04 | *** join/#oe moto-timo (~ttorling@134.134.139.76) |
| 20:09.04 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 20:11.24 | *** join/#oe josep (~jhunt@c-a625e655.010-118-73746f7.cust.bredbandsbolaget.se) |
| 20:15.55 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 20:23.31 | *** join/#oe awozniak (~awozniak@71-93-61-178.static.snlo.ca.charter.com) |
| 20:24.48 | *** join/#oe ensc|w_ (~ensc@fedora/ensc) |
| 20:25.03 | *** join/#oe marex-cloud_ (sid137234@gateway/web/irccloud.com/x-xvyaedjwrduoqmgz) |
| 20:25.10 | *** join/#oe roxell_ (~roxell@c-c82171d5.07-21-73746f28.cust.bredbandsbolaget.se) |
| 20:25.39 | *** join/#oe abelloni_ (~abelloni@2a01:e35:8bf1:a7c0:a288:b4ff:fe25:8918) |
| 20:26.03 | *** join/#oe moto-timo (~ttorling@134.134.139.76) |
| 20:26.03 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 20:26.34 | *** join/#oe moto-timo (~ttorling@134.134.139.76) |
| 20:26.34 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 20:28.31 | *** join/#oe radhus__ (~radhus@sevh.radhuset.org) |
| 20:28.31 | *** join/#oe rsalveti_ (sid117878@linaro/rsalveti) |
| 20:30.20 | *** join/#oe wenzong (~wfan@106.120.101.38) |
| 20:31.12 | *** join/#oe fray (~mhatle@192.40.192.95) |
| 20:31.32 | *** join/#oe Crofton|work (~balister@pool-108-44-118-32.ronkva.east.verizon.net) |
| 20:32.25 | *** join/#oe moto-timo (~ttorling@134.134.139.76) |
| 20:32.25 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 20:32.31 | *** join/#oe wfan_ (~wfan@106.120.101.38) |
| 20:32.56 | *** join/#oe caiortp (~inatel@131.221.240.204) |
| 20:33.32 | *** join/#oe adelcast (~adelcast@130.164.62.82) |
| 20:34.59 | *** join/#oe moto-timo (~ttorling@134.134.139.76) |
| 20:34.59 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 20:43.24 | *** join/#oe moto-timo (~ttorling@134.134.139.76) |
| 20:43.24 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 20:44.40 | kergoth | ponders |
| 20:57.37 | *** join/#oe roxell (~roxell@linaro/roxell) |
| 20:58.54 | *** join/#oe ant_home (~ant__@host122-91-dynamic.45-79-r.retail.telecomitalia.it) |
| 21:04.50 | *** join/#oe dvhart (~dvhart@134.134.137.71) |
| 21:11.40 | *** join/#oe DJWillis (~djwillis@cpc2-trow6-2-0-cust204.aztw.cable.virginm.net) |
| 21:12.02 | *** join/#oe oldtopman (~oldtopman@unaffiliated/oldtopman) |
| 21:13.04 | *** join/#oe ndec (~ndec@linaro/ndec) |
| 21:16.40 | *** join/#oe moto-timo (~ttorling@134.134.139.76) |
| 21:16.41 | *** join/#oe moto-timo (~ttorling@fsf/member/moto-timo) |
| 21:36.52 | *** join/#oe dvhart (dvhart@nat/intel/x-hfxtlqdshbtctydf) |
| 21:52.47 | *** join/#oe evanmeagher (~MongooseW@50.1.57.30) |
| 22:01.27 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 22:19.25 | *** join/#oe mattsm (uid128834@gateway/web/irccloud.com/x-ogcvvptztffwhxim) |
| 22:19.58 | *** join/#oe Aethenelle (~Aethenell@166.170.222.7) |
| 22:58.23 | *** join/#oe Crofton (~balister@pool-108-44-118-32.ronkva.east.verizon.net) |
| 23:00.25 | *** join/#oe Crofton|work (~balister@pool-108-44-118-32.ronkva.east.verizon.net) |
| 23:20.39 | *** join/#oe anarsoul (~kvirc@205.250.92.228) |
| 23:31.46 | *** join/#oe likewise (~likewise@145.132.74.106) |
| 23:40.20 | *** join/#oe dvhart (~dvhart@134.134.139.83) |
| 23:44.57 | *** join/#oe JaMa (~martin@ip-86-49-34-37.net.upcbroadband.cz) |