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) |