| 00:31.19 | *** join/#oe fray (U2FsdGVkX1@gate.crashing.org) |
| 01:19.19 | *** join/#oe Vutral (~ss@mirbsd/special/Vutral) |
| 01:28.01 | *** join/#oe sr105|away (~sr105@65349hfc19.tampabay.res.rr.com) |
| 01:30.13 | *** join/#oe Vutral (~ss@mirbsd/special/Vutral) |
| 01:38.34 | *** join/#oe SoylentYellow (~quassel@curie.ece.neu.edu) |
| 02:40.38 | akbennett | khem, different variants of qemu-system-arm -machine virt -hdc core-image-minimal-qemuarm.ext3 -kernel zImage-qemuarm.bin -append "root=/dev/sda1" |
| 02:48.06 | Crofton|work | is there a runqemu script |
| 02:48.13 | Crofton|work | I'm not familiar with wemu |
| 02:49.14 | Crofton|work | look in ./oe-cire/scripts |
| 02:49.19 | akbennett | Crofton|work, yeah, need to get a build environment set back up |
| 02:49.32 | akbennett | Crofton|work, to see the invocation line |
| 02:50.20 | Crofton|work | https://github.com/openembedded/oe-core/blob/master/scripts/runqemu |
| 02:57.28 | *** join/#oe s3v3n62mm2 (~s3v3n62mm@p3EE2F09E.dip0.t-ipconnect.de) |
| 03:07.26 | khem | akbennett: clone oe-core then cd oe-core; . ./oe-init-build-env; bitbake qemu-helper-native meta-ide-support;runqemu qemuarm <path/to/your/kernel> </path/to/your/rfs.ext3> nographic |
| 03:07.44 | *** join/#oe Vutral (~ss@mirbsd/special/Vutral) |
| 03:21.56 | *** join/#oe pompomJuice (~pompomJui@41.0.38.138) |
| 03:21.59 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 03:24.12 | *** join/#oe Vutral (~ss@mirbsd/special/Vutral) |
| 03:32.39 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 04:02.43 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 04:27.47 | *** join/#oe hbeck (~hbeck@38.114.125.83) |
| 04:48.49 | *** part/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
| 04:48.50 | *** join/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
| 04:53.51 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 05:13.36 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 05:13.56 | *** join/#oe clio (~andrej@85.159.109.222) |
| 05:30.28 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 05:51.02 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 06:05.18 | *** join/#oe tasslehoff (~tasslehof@77.40.182.98) |
| 06:37.53 | *** join/#oe KNERD (~KNERD@24.175.253.226) |
| 06:49.33 | *** join/#oe lamikr (~lamikr@145.247.15.238) |
| 06:51.39 | *** join/#oe g1zer0 (~gizero@host168-65-static.12-87-b.business.telecomitalia.it) |
| 07:00.05 | mckoan | good morning |
| 07:02.00 | *** join/#oe ant_work (~ant__@host54-128-static.10-188-b.business.telecomitalia.it) |
| 07:09.12 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 07:11.11 | *** join/#oe woglinde (~henning@fb-n15-11.unbelievable-machine.net) |
| 07:13.59 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-lgqcrhobeokofedz) |
| 07:20.24 | koen | RP: how do RRECOMMENDS work for *-replacement-native recipes? |
| 07:20.58 | koen | RP: git needs ca-certs to work with https://, which are in RRECOMMENDS_libcurl |
| 07:21.20 | RP | koen: its not seeing that dependency? |
| 07:21.21 | koen | but building git-replacement-native doesn't install ca-certs into sysroot |
| 07:22.46 | RP | koen: I have a suspicion that since we set PACKAGES to "", native recipes haven't been seeing their R* depends :/ |
| 07:23.28 | koen | I wish git-send-email wasn't written in perl |
| 07:23.37 | koen | then I could just forget making git-perltools work |
| 07:24.39 | koen | RP: would adding ca-carts to DEPENDS in curl.bb with a comment explaining why be acceptable as short term fix? |
| 07:24.56 | RP | koen: a DEPENDS_append_class-native would be ok |
| 07:25.13 | RP | koen: well, make it an RDEPENDS |
| 07:25.49 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 07:28.34 | *** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net) |
| 07:31.08 | koen | RDEPENDS works for -native? |
| 07:31.47 | koen | if so, my commit message and comment are bogus :) |
| 07:33.32 | RP | koen: RDEPENDS_<pkg> probably doesn't since PACKAGES="" however RDEPENDS probably does |
| 07:53.23 | *** join/#oe shajeen (~shajeen@1.23.183.166) |
| 08:30.29 | *** join/#oe phdeswer (~phdeswer@194.157.27.2) |
| 08:31.04 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 08:34.14 | *** join/#oe bluelightning (~paul@83.217.123.106) |
| 08:34.15 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 08:35.11 | bluelightning | morning all |
| 08:38.10 | RP | koen: I think we need to file a bug about this issue but I've tried locally and its not something we can fix easily :( |
| 08:41.34 | mckoan | gm bluelightning, all |
| 08:42.06 | RP | koen: Filed as https://bugzilla.yoctoproject.org/show_bug.cgi?id=6317 |
| 08:42.55 | koen | thanks |
| 09:27.10 | koen | RP: more bad news: we probably need to run postinsts for some -native* packages |
| 09:28.12 | RP | koen: they probably need something adding specifically around sstate rather than the postinst |
| 09:29.21 | RP | koen: pixbufcache.bbclass does that for example |
| 09:29.34 | koen | I'll have a look at ca-certs after lunch |
| 09:30.32 | *** join/#oe stefan_schmidt (~stefan@p2003004809487532F2DEF1FFFE6228F7.dip0.t-ipconnect.de) |
| 09:30.52 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 09:31.24 | RP | koen: you may be able to copy the class-nativesdk do_install_append for that |
| 09:45.54 | woglinde | hi bluelightning |
| 09:48.01 | *** join/#oe blitz00 (~stefans@89.122.246.95) |
| 09:48.01 | *** join/#oe blitz00 (~stefans@unaffiliated/blitz00) |
| 09:48.34 | JaMa|Off | which recipe should now provide libgcc*so*? |
| 10:17.40 | koen | RP: patch for ca-certs sent |
| 10:17.59 | koen | RP: what command did you run to make git-native fail with perl enabled? |
| 10:20.54 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 10:21.18 | *** join/#oe kristoffer (~kristoffe@c-e882e253.171-2-64736c10.cust.bredbandsbolaget.se) |
| 10:24.55 | RP | koen: I think it was in Saul's email? |
| 10:26.14 | *** join/#oe sulky (~sulky@gateway/shell/cadoth.net/x-dfzvhubscphqnymq) |
| 10:26.33 | bluelightning | hi woglinde |
| 10:42.27 | koen | RP: git-difftool |
| 10:42.38 | koen | RP: but I want to know the highlevel command that triggered it |
| 10:43.19 | RP | koen: I think Saul just picked one one of the perl binaries |
| 10:43.24 | RP | er, scripts |
| 10:45.09 | koen | are they supposed to work without using some perl-native wrapper? |
| 11:43.26 | muppe | ok, sorry to bother you all with this issue but it is really driving me nuts. I am struggling with OpenGL SW emulation (mesa) with virtual frame buffer on ARM device. It all worked fine couple of months ago with Yocto danny branch stuff using xserver 1.11.2 and mesa-dri/mesa-demos in IMAGE_INSTALL. It seems that I am missing something or something is misconfigured. For example, "glxinfo" gives me: "Error: couldn't find RGB GLX visual or fbconfig". |
| 11:44.30 | muppe | I found out that there has been a related bug in Ubuntu at some point but not sure if it has anything to do with this one. |
| 11:44.49 | woglinde | muppe hm do you need the fullblown gl or would be egl enough? |
| 11:45.19 | muppe | I think we had a fullblown version that worked earlier. |
| 11:45.37 | muppe | in distro features I have "opengl" |
| 11:45.49 | muppe | and x11 |
| 11:54.20 | *** join/#oe sulky (sulky@gateway/shell/cadoth.net/x-sqmahtkwnjouszye) |
| 12:05.35 | *** join/#oe SoylentYellow (~quassel@curie.ece.neu.edu) |
| 12:15.26 | *** join/#oe sulky (sulky@gateway/shell/cadoth.net/x-gmslwfvbmoxgxkhh) |
| 12:16.54 | muppe | woglinde: I have Xvfb working as it should (I can open xterm and see it on a VNC client) but OpenGL stuff is not working |
| 12:24.15 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 12:30.51 | *** join/#oe adelcast (~adelcast@130.164.62.249) |
| 12:45.34 | *** join/#oe ldnunes (~ldnunes_@177.194.208.225) |
| 12:45.40 | woglinde | muppe hm sorry I have no idea |
| 12:45.51 | muppe | ok |
| 12:51.57 | *** join/#oe fray (U2FsdGVkX1@gate.crashing.org) |
| 13:04.56 | woglinde | muppe maybee the danny branch is too old |
| 13:05.01 | woglinde | try with dora |
| 13:05.43 | woglinde | muppe btw. why you need really opengl it should be really slow in arm sw |
| 13:12.25 | muppe | woglinde: it worked on Danny but after updating to Dylan it stopped working. |
| 13:13.01 | muppe | I need OpenGL because of Qt quick |
| 13:13.36 | muppe | OpenGL + Xvfb is a temp solution but it would still be nice to get it working. |
| 13:24.24 | woglinde | muppe hm hm |
| 13:24.43 | woglinde | muppe because you are sticked to qt4 instead of qt5 with egl support? |
| 13:25.13 | muppe | I am using qt5.1.1 but not the very latest 5.2 |
| 13:25.37 | *** join/#oe s3v3n62mm (~s3v3n62mm@p3EE2F09E.dip0.t-ipconnect.de) |
| 13:25.38 | muppe | that was also the case with the danny stuff I used earlier. |
| 13:29.17 | woglinde | what arm platform you are using? |
| 13:29.25 | woglinde | I would try egl hw support |
| 13:29.42 | woglinde | instead of full gl support in sw |
| 13:30.05 | muppe | I don't have a GPU on the device. Need to use SW emulation. |
| 13:30.24 | woglinde | oh okay |
| 13:30.27 | woglinde | strange device |
| 13:30.45 | muppe | :) |
| 13:31.10 | woglinde | sorry then, I have no idea how fbdriver and gl works together |
| 13:31.16 | woglinde | till later maybee |
| 13:31.27 | muppe | ok, thanks anyway. |
| 13:32.26 | *** join/#oe hillct (~hillct@cpe-071-070-219-043.nc.res.rr.com) |
| 13:36.16 | *** join/#oe blitz00 (~stefans@86.121.18.4) |
| 13:36.16 | *** join/#oe blitz00 (~stefans@unaffiliated/blitz00) |
| 13:40.19 | andre_d | Hi! Does DISTRO affect the sstate checksums? I.e. will the same recipe if used in different DISTROs be recompiled for each distro? And where can I find out about these things? I had a quick look at sstatesig.py but am no python expert and it doesn't seem straight forward to figure out what exactly counts as input to the sstate has generator |
| 13:42.41 | bluelightning | andre_d: it likely will yes |
| 13:43.15 | bluelightning | andre_d: you can use bitbake-dumpsig and bitbake-diffsigs to inspect and compare signatures |
| 13:44.08 | bluelightning | (.sigdata files in tmp/stamps) |
| 13:46.09 | andre_d | bluelightning: thanks! |
| 13:48.13 | *** join/#oe adelcast (~adelcast@130.164.62.249) |
| 13:57.28 | *** join/#oe madisox (~madisox@nat/cisco/x-sexlbfwiqxshcobb) |
| 13:58.54 | *** join/#oe _chase_ (~a0271661@nat/ti/x-eqdgnxyaiivtncha) |
| 14:04.53 | *** join/#oe oneQubit (~oneQubit@c-69-138-31-87.hsd1.md.comcast.net) |
| 14:05.41 | *** join/#oe woglinde (~henning@24-134-58-61-dynip.superkabel.de) |
| 14:10.49 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 14:17.24 | *** join/#oe g1zer0 (~gizero@host168-65-static.12-87-b.business.telecomitalia.it) |
| 14:23.09 | *** join/#oe hillct (~hillct@cpe-071-070-219-043.nc.res.rr.com) |
| 14:25.47 | abelloni | hi, quick question |
| 14:25.52 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 14:25.57 | abelloni | The text of a license changed |
| 14:26.16 | abelloni | but using bitbake -c clean foo then bitbake foo |
| 14:26.37 | abelloni | I'm still getting the old text in ./tmp/deploy/licenses/foo/ |
| 14:27.20 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 14:27.25 | abelloni | is that possible to force it to take the new one without cleaning tmp ans sstate-cache ? |
| 14:29.41 | bluelightning | abelloni: I'm pretty sure that text comes from the generic license that matches up with the LICENSE value, rather than the source |
| 14:31.46 | abelloni | yes it is |
| 14:31.55 | abelloni | that is eactly the text that changed |
| 14:31.59 | abelloni | exactly |
| 14:32.05 | *** join/#oe hrw (~hrw@redhat/hrw) |
| 14:32.23 | abelloni | I have a bunch of licenses in a folder of my layer |
| 14:32.55 | abelloni | I've added LICENSE_PATH += "${LAYERDIR}/licenses" to my layer.conf |
| 14:37.42 | bluelightning | abelloni: so it's the do_populate_lic task for the recipe that does the copy, if you force that to run again (bitbake -c populate_lic -f recipename) then it will run it again |
| 14:38.27 | woglinde | bluelightning do we have some generic mechanism to disable certain tty's for systemd? |
| 14:38.31 | *** join/#oe Guest63370 (~boo@2001:41d0:52:100::3b1) |
| 14:38.50 | bluelightning | woglinde: I think we might do yes, I don't know it off the top of my head |
| 14:39.09 | Crofton|work | koen, in the rrd patch, you use the broken auto sepo class and change some S to B's |
| 14:39.18 | Crofton|work | does that mean you tried and fialed to fix it? |
| 14:39.31 | koen | yes |
| 14:39.51 | koen | I wasn't sure if I should keep it completely broken and use the class or fix it up a bit and use the class |
| 14:40.26 | woglinde | bl hm okay |
| 14:40.40 | abelloni | bluelightning: exactly what I was looking for, thanks ! |
| 14:40.52 | woglinde | because system inspect the kernel cmdline and uses the console in there |
| 14:49.01 | *** join/#oe jero_ (~boo@2001:41d0:52:100::3b1) |
| 14:49.41 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 14:59.09 | *** join/#oe _chase_ (~a0271661@nat/ti/x-goneauuejdkvxmtf) |
| 15:01.27 | *** join/#oe bluelightning_ (~paul@83.217.123.106) |
| 15:01.29 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 15:07.21 | woglinde | hm hm how to prevent systemd to logging to the serial console |
| 15:17.05 | WarheadsSE | woglinde: cmdline changes |
| 15:18.08 | woglinde | warheadsse hmhm yes I read it |
| 15:18.35 | woglinde | WarheadsSE the problem is to let systemd not log to a specfic console |
| 15:19.27 | koen | define 'log' |
| 15:19.34 | koen | you mean 'output messages' |
| 15:19.42 | koen | or 'point journalctl to it' ? |
| 15:20.01 | woglinde | koen now it comes tricky we dont use journal |
| 15:20.14 | koen | so you don't really mean 'log' |
| 15:20.15 | woglinde | plain old busybox-syslog |
| 15:20.23 | woglinde | the systemd log |
| 15:20.26 | woglinde | yes sorry |
| 15:20.46 | koen | add 'quiet' to your cmdline, that should make most of it go away |
| 15:20.56 | koen | if not, rework your console= bits |
| 15:21.31 | woglinde | to make it more complicate kernel log would be okay |
| 15:22.11 | WarheadsSE | Well, if you are using systemd.. you're using journald, you're just not using it for *storage* |
| 15:22.39 | woglinde | WarheadsSE haha nope you can complete disable journald and use only syslog |
| 15:23.04 | WarheadsSE | mm, I suppose if you disabled it entirely from the systemd recipe |
| 15:23.05 | woglinde | WarheadsSE but systemd greps the console from kernel cmdline and pushes stuff there |
| 15:23.17 | WarheadsSE | Yeah: quiet. |
| 15:23.58 | woglinde | but looks like systemd is to unflexibel in this way |
| 15:24.23 | koen | sysv did the same |
| 15:24.28 | koen | output to the bits in console= |
| 15:25.59 | woglinde | hm so lets hope disabling the getty on the serial is enough for not crashing the machine |
| 15:36.51 | *** join/#oe Vutral (~ss@mirbsd/special/Vutral) |
| 15:43.00 | WarheadsSE | Yeah, you might see some open on that |
| 15:43.49 | WarheadsSE | Since systemd will likely detect @ start a getty @ console= |
| 15:53.56 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 15:57.02 | *** join/#oe bluelightning_ (~paul@83.217.123.106) |
| 15:57.02 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 15:58.51 | *** join/#oe adelcast (~adelcast@130.164.62.249) |
| 16:03.01 | fray | is here.. |
| 16:04.06 | RP | is here |
| 16:04.36 | bluelightning | isn't it early? |
| 16:04.51 | fray | OHHH the meeting was moved.. |
| 16:04.56 | fray | duh, I didn't look at my calendar today |
| 16:05.01 | bluelightning | the calendar invite says it's not for another 2 hrs |
| 16:05.10 | fray | Yes.. I'm 2 hours early.. :) |
| 16:06.25 | RP | oh, I see :/ |
| 16:18.38 | *** join/#oe _chase_1 (~a0271661@nat/ti/x-ldzsmvqqkgvtnmrw) |
| 16:18.42 | *** join/#oe HerbKuta (88a69c40@gateway/web/freenode/ip.136.166.156.64) |
| 16:19.17 | *** part/#oe HerbKuta (88a69c40@gateway/web/freenode/ip.136.166.156.64) |
| 16:24.42 | jkelly | What is the recommended way to do a quick kernel rebuild, repackage and image generation after adding a driver or otherwise making a small edit to the .config file? If I up the priorities, I get a whole new 3 hour build, and if I don't I can't seem to get new kernels or new images. |
| 16:25.47 | woglinde | jkelly bitake -c cleansstate linux or maybe linux-something_else depending on the machine |
| 16:25.52 | woglinde | bitbake linux |
| 16:26.08 | *** join/#oe mwester (~mwester@209-142-159-63.dyn.centurytel.net) |
| 16:26.08 | *** join/#oe mwester (~mwester@nslu2-linux/mwester) |
| 16:26.59 | jkelly | Thanks---I'll give it a try. |
| 16:27.31 | woglinde | jkelly are using the standard yocto kernel? |
| 16:30.41 | jkelly | It looks like it is kernel.org |
| 16:33.21 | *** join/#oe joaohfreitas (~joaohfrei@187-072-184-065.static.ctbctelecom.com.br) |
| 16:34.58 | joaohfreitas | RP: Hi, lost patch http://lists.openembedded.org/pipermail/openembedded-core/2014-May/092329.html |
| 17:10.06 | *** join/#oe nitink1 (~nitink@134.134.139.70) |
| 17:13.12 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 17:16.27 | *** join/#oe florian (~fuchs@sign-4db604b9.pool.mediaWays.net) |
| 17:16.27 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 17:17.40 | *** join/#oe sr105|away (~sr105@65349hfc19.tampabay.res.rr.com) |
| 17:27.29 | *** join/#oe Shawn286 (~Shawn@unaffiliated/shawn156) |
| 17:29.16 | *** join/#oe phdeswer (~phdeswer@a88-112-199-213.elisa-laajakaista.fi) |
| 17:44.21 | *** join/#oe dvhart (dvhart@nat/intel/x-mfaxnjzzoqemzcvb) |
| 17:50.23 | koen | tsc today? |
| 17:54.57 | bluelightning | koen: yep, in ~5 mins |
| 17:58.26 | khem | hi guys |
| 17:58.29 | khem | I am here |
| 17:59.47 | bluelightning | I'm here |
| 17:59.54 | RP | is here |
| 18:00.05 | bluelightning | fray: you around as well? |
| 18:00.44 | *** join/#oe HerbKuta (88a69c40@gateway/web/freenode/ip.136.166.156.64) |
| 18:03.15 | bluelightning | so I don't think we have an agenda, but there were a bunch of suggestions in Jefro's email |
| 18:03.39 | bluelightning | basically further discussion on things that came out of OEDAM |
| 18:04.16 | fray | is here.. |
| 18:04.24 | fray | sorry got delayed on something else |
| 18:04.37 | fray | I agree, going over the OEDAM is likely the best topic for today |
| 18:05.02 | *** join/#oe jefro__ (a689d02e@gateway/web/freenode/ip.166.137.208.46) |
| 18:05.09 | bluelightning | hi jefro__ |
| 18:05.45 | bluelightning | so we're currently starting the public OE TSC / Workgroup meeting in case anyone's wondering what's going on ;) |
| 18:05.51 | bluelightning | all are welcome to participate |
| 18:05.57 | jefro__ | Blue lightning hiya |
| 18:06.00 | fray | FYI -- http://openembedded.org/wiki/OEDAM#Minutes |
| 18:06.40 | bluelightning | ok, so does someone want to chair? |
| 18:07.01 | fray | fails to step back... |
| 18:07.03 | fray | I can |
| 18:07.06 | bluelightning | go for it :) |
| 18:07.29 | fray | ok.. so first topic then is the OEDAM meeting minutes.. any other topics? |
| 18:07.57 | RP | may as well give the headsup here, I'm thinking of trying to kill off binconfig.bbclass where we can, basically deleting -config scripts from recipes one by one. I'll put a proper proposal to the list in due course but OE-Core at least looks relatively clean for it. This will include patching in pkgconfig into software the upstreams don't seem to want patches |
| 18:09.11 | fray | RP should we discuss that, or just a heads up? |
| 18:09.35 | RP | fray: just a headsup unless anyone has something they particularly want to add |
| 18:09.46 | koen | binconfig.bbclass is already rewriting most of the -config bits anyway |
| 18:10.18 | RP | koen: right, there are just a load I think we can kill off now entirely, enough of the world is using pkgconfig |
| 18:10.19 | fray | my only concern is simply falling back to the host and introducing host contamination by calling those scripts instead.. |
| 18:10.41 | RP | fray: thankfully the linker complains extremely loudly about that :) |
| 18:10.42 | fray | otherwise I think directly suing pkgconfig makes way more sense then effectively wrapping it |
| 18:10.55 | fray | RP, "your welcome" ;) |
| 18:11.21 | kergoth | That sounds like a good janitorial-type task. It has to be dealt with on a case-by-case basis, and is likely not a huge priority. |
| 18:11.52 | fray | Ohh I frogot.. is someone logging the discussion for notes? |
| 18:12.27 | RP | kergoth: I had a go at fixing the OE-Core recipes and it causes a surprising amount of head scratching but I'm allergic to m4 ;-) |
| 18:12.28 | bluelightning | the bot isn't here, but I don't think we'll have trouble finding logs |
| 18:12.48 | jefro__ | of someone could just send a capture to me afterward I'll post to the ml |
| 18:12.50 | kergoth | m4 quoting is the devil |
| 18:12.55 | RP | top two of http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/t222 if anyone is interested |
| 18:12.57 | bluelightning | jefro__: I'll take that AR |
| 18:12.58 | kergoth | do i need 3 [] here or 4? |
| 18:13.35 | RP | kergoth: I fell for the pkg-config in an if statement trap |
| 18:13.59 | fray | :) |
| 18:14.06 | fray | Ok.. anything else on that, or should we move on to OEDAM? |
| 18:14.13 | RP | move on |
| 18:14.22 | fray | ok.. then.. |
| 18:14.24 | fray | again the URL: |
| 18:14.27 | fray | http://openembedded.org/wiki/OEDAM#Minutes |
| 18:14.40 | fray | we encourage people to read what was discussed and ask questions, either here or on the mailing list.. |
| 18:15.15 | RP | would like to mention that we are in serious need of help with the developer experience and workflow part |
| 18:15.20 | fray | RP, bluelightning, others how should we go over this.. I know we want to cover the 'usage' documentation item.. anything else explicitly? (perhaps the meta-openembedded maintainers) |
| 18:15.41 | RP | The system works well for a subset of people but not all users and I think for OE to move further, that needs to be addressed |
| 18:15.56 | khem | We havent yet cleaned up S != B |
| 18:16.15 | koen | for lava: we just had a reorg in linaro that split the lava team into a product team and a lab team, which should improve the development process |
| 18:16.48 | fray | lets just go in order of the notes then.. |
| 18:16.51 | fray | Lava... |
| 18:17.00 | fray | for those who don't know this is a test infrastructure that Linaro is using.. |
| 18:17.00 | koen | khem: today I fixed all the S!=B issues we hit in the linaro autobuilder, |
| 18:17.16 | fray | there has been put forth the idea to use it to help test OpenEmbedded.. |
| 18:17.35 | bluelightning | I'm still puzzled about this "2k tests in 1.6" - we don't have 2000 tests |
| 18:17.45 | fray | so some early work has been done to try to automatically boot and kick off tests.. |
| 18:17.46 | khem | RP: some way of integrating Eclipse and toaster |
| 18:17.59 | khem | thinking of hardcore developers say QT guys |
| 18:18.03 | koen | bluelightning: grep ptest | wc -l? |
| 18:18.07 | khem | they want to use QT Creator |
| 18:18.09 | fray | bluelightning it's Linaro that has 2k tests from what I understand.. I know we don't.. unless you could each test in same ltp, or posix.. or... |
| 18:18.34 | broonie | Linaro either has way more or way less than 2k tests depending on what you're counting. |
| 18:18.41 | bluelightning | fray: I guess we should clarify what is meant there |
| 18:19.11 | fray | so for the lava work, it was decided (and some folks volunteered) to help connect the autobuilder output to the lava environment.. help get some reference system (singular) booting and some type of testing working as a proof of concept.. |
| 18:19.15 | fray | after that we'll see where it goes.. |
| 18:20.58 | fray | ok.. so someone should clarify the 2k tests in the notes (or just remove the 2k number).. the key is porting tests takes resources.. ones that have not volunteered at this point.. :) |
| 18:21.10 | fray | but we're getting to a proof of concept that this is something useful.. |
| 18:21.19 | bluelightning | fray: what is meant by porting tests though? |
| 18:21.38 | fray | making them run in the lava environment.. which may require work in lava, or oe.. |
| 18:21.58 | khem | As I understand lava is able to launch ptests |
| 18:22.08 | koen | shouldn't be hard to write a bbclass that generates the json and yaml for it |
| 18:22.12 | khem | as long as it prints pass/fail |
| 18:22.37 | fray | thats the next step.. but someone has to do the work.. and at present I don't think anyone has volunteered.. |
| 18:22.53 | fray | so from that statement, I think we need to ask for people who are interested to talk with us.. |
| 18:23.06 | jefro__ | The 2k number was mentioned at oedam, I thought it referred to linaro test cases |
| 18:23.11 | RP | fray: join the mailing list |
| 18:24.05 | fray | RP, exactly.. which list do we point people toward for this? |
| 18:24.32 | bluelightning | fray: the automated-testing@yoctoproject.org one |
| 18:24.41 | fray | ok.. |
| 18:24.43 | bluelightning | https://lists.yoctoproject.org/listinfo/automated-testing |
| 18:24.54 | fray | I'm going to move to the next topic in the interest of time.. |
| 18:24.58 | fray | Ongoing role of the TSC.. |
| 18:25.00 | RP | jefro__: this isn't on https://www.yoctoproject.org/tools-resources/community/mailing-lists |
| 18:25.05 | fray | quick summary: |
| 18:25.26 | jefro__ | hmm, I'll fix |
| 18:25.38 | fray | <PROTECTED> |
| 18:26.19 | fray | Some concerns have been raised (off list, and not during OEDAM) about the membership of the TSC being heavily "Yocto Project" or Intel or corporate biased.. the feedback from those present is that we're doing a good job seperating our TSC role from that of our employer.. |
| 18:26.31 | fray | with that said, if anyone sees it differently please call us on it.. |
| 18:26.53 | *** join/#oe staylor (~staylor@mail.au-zone.com) |
| 18:26.58 | fray | Future actions, the board is going to ask to see if anyone wants to join the TSC (May?) |
| 18:27.18 | fray | if not, there will be a general revote of the existing slate, otherwise a more general elections will take part.. |
| 18:27.27 | RP | Something we should check with the TSC people: Are we all happy continuing? |
| 18:27.38 | fray | Yes.. |
| 18:27.46 | bluelightning | I'm happy |
| 18:27.55 | RP | is ok |
| 18:27.57 | koen | I'm going to step down at the next election |
| 18:28.03 | fray | For those that were present we all I believe indicated we were find with continuing on.. (speaking for myself I am, but if someone more qualified comes along, I'm willing to step down).. |
| 18:28.23 | fray | koen, ok.. so we will want someone new to step in for your current role.. |
| 18:28.34 | *** join/#oe nitink (nitink@nat/intel/x-uxprbyjdjywxwrss) |
| 18:28.38 | RP | I think Martin did say he might be willing to step up if someone wanted to step down |
| 18:28.48 | fray | if more then one person wants to step forward, we'll certainly entertain that as well.. |
| 18:28.59 | RP | although it was hard to tell over the phone :) |
| 18:29.34 | fray | he said he was interested, but didn't feel the need to replace any existing member.. (I'm sure I'm paraphrasing.... and he can correct the record if we're incorrect) |
| 18:30.18 | RP | We should let the board know and let them take it from there |
| 18:30.27 | fray | final thing that was mentioned, somewhat as an aside to this process.. the board is creating a mock budget, and will be soliciting donations in the future.. for things like infrastructure costs, stickers (trade shows), and paying for travel to places like FOSDEM.. |
| 18:30.43 | fray | RP, yes.. so action item.. Koen will be stepping down at next election.. |
| 18:30.56 | fray | RP, will you (or Koen?) send that note to Phillip? |
| 18:31.49 | RP | fray: I can |
| 18:31.51 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 18:32.34 | fray | ok.. then on to the next (IMHO most important) item.. the "Why is embedded still hard?" topic |
| 18:32.54 | fray | this really revolved around best practices, learning curve, and how to continue to improve what we have.. |
| 18:33.01 | RP | fray: depends on who is asking that question |
| 18:33.26 | fray | one of the things that we are asking people, we want to come up with a lists of tasks (use-cases) that people need to do with the system, and then ask folks to document their own person workflows.. |
| 18:33.30 | RP | I think that is part of the problem since the answer depends on that users expectations and requirements |
| 18:33.50 | fray | we then have some people who want to agregate that into either a best practices -- or into a list of things we need to improve.. (likely both) :) |
| 18:34.10 | fray | RP, exactly.. user expectations, requirements are huge here.. and we all only know of our own subset.. |
| 18:35.08 | paulbarker | (jumping is as I've been lurking) - i've got a bunch of updated workflow scripts i can publish along with a few notes, remind me to do that if i forget! |
| 18:35.24 | bluelightning | paulbarker: that would be great! |
| 18:35.47 | fray | yes.. that would be good.. |
| 18:35.52 | RP | joaohfreitas: merged FYI, thanks |
| 18:36.09 | RP | paulbarker: that sounds extremely useful, please do! |
| 18:36.38 | fray | Anyone have anything else to add to the workflow discussion? much of the notes are our overall brain storming and talking.. but the discrete action is to ask people to tell us what they do with OE, and then how they do it.. |
| 18:37.07 | paulbarker | i've put it on my todo list now so i shouldn't forget |
| 18:37.17 | bluelightning | "app developers don't care" - I think that needs expanding |
| 18:37.39 | fray | ahh.. app developers don't (or shouldn't) care about using all of bitbake/oe |
| 18:37.47 | bluelightning | right, that was my assumption |
| 18:37.58 | fray | they should care about compiling, debugging, and even deployment of their application |
| 18:38.03 | bluelightning | but it shouldn't be taken to mean there's nothing we can do for them ;) |
| 18:38.13 | fray | correct.. I'll edit that and expand.. |
| 18:38.17 | bluelightning | thanks |
| 18:39.35 | bluelightning | I think the important thing at this point is we need to take a bit of a step back and work out what needs doing |
| 18:40.12 | fray | yes.. |
| 18:40.13 | bluelightning | it would be easy for us to think of areas where we know things could be improved and only touch those bits, with issues from people like app developers remaining unadressed |
| 18:41.05 | fray | so again the request is for people to tell us what workflows they use, how they get things done.. and then eventually document the actual steps.. |
| 18:41.23 | fray | to clarify the document steps is very much a bullet list of I do this, then this, then this, then this...... |
| 18:41.43 | bluelightning | the trouble is some of those people aren't really well-represented in our community, so I think it would really help if people could gather feedback from them within their own organisations (or encourage them to submit feedback) |
| 18:42.05 | fray | yes |
| 18:42.17 | fray | should we move to the next topic? |
| 18:42.23 | bluelightning | I think so yep |
| 18:42.26 | fray | increasing layer quality... |
| 18:42.53 | fray | the key thing here is that each layer should have a maintainer file, with maintainers that reply.. if that doesn't happen.. then we should work to find replacements.. |
| 18:43.05 | fray | (that specifically goes with OpenEmbedded layers).. |
| 18:43.09 | RP | A README file |
| 18:43.11 | fray | we should set an example for non OE layers.. |
| 18:43.16 | fray | yes.. README.. sorry.. |
| 18:43.26 | *** join/#oe hillct (~hillct@cpe-071-070-219-043.nc.res.rr.com) |
| 18:43.29 | koen | so |
| 18:43.38 | fray | view is maintainership == quality.. (or at least an initial view of quality) |
| 18:43.43 | RP | the README can point at a maintainers file |
| 18:43.45 | koen | what can we do about layers that violate policies and/or good practices? |
| 18:44.03 | fray | if they're within the OE family (or YP) then we should work to get them corrected.. |
| 18:44.07 | koen | e.g. meta-freescale breaks heavily because they poke at the armhf tunes |
| 18:44.12 | RP | koen: do you have a proposal and some specific examples of issues? |
| 18:44.24 | fray | outside, there isn't much we can do -- but it's a good thing if we can document what problems are common and suggest alternatives.. |
| 18:44.30 | koen | the intel emgd layers set preferred versions in the machine file |
| 18:44.33 | koen | etc |
| 18:45.12 | RP | koen: with those two being Yocto Project compatible, I'd suggest the first thing to do is flag the issues to them |
| 18:45.19 | koen | I did |
| 18:45.27 | RP | koen: are there open bugs? |
| 18:45.36 | *** part/#oe WarheadsSE (~WarheadsS@50.164.115.22) |
| 18:45.40 | bluelightning | maybe some sort of layer lint tool (e.g. incorporating kergoth's leaky-layer script above) where the results get linked / reported out on the layer index would help? |
| 18:45.45 | koen | otavios response was basically "that's your opinion" |
| 18:45.54 | bluelightning | s/above/discussed in #yocto/ |
| 18:46.21 | fray | this again is where the concept of file good and bad examples and lets trying to use them as best practices comes into play |
| 18:46.29 | bluelightning | koen: as I said earlier if we have no documentation on that kind of policy we can't expect everyone to abide by it |
| 18:47.01 | bluelightning | if there's contention, that's what we (the TSC) are supposed to be here to help resolve |
| 18:47.08 | RP | koen: I think with Yocto Project Compatible things there are ways we can raise these discussions. The next step would be to open a bug and ensure I know about the issue |
| 18:47.18 | koen | RP: I'm close to killfiling yocto bugzilla things |
| 18:47.21 | koen | too much spam |
| 18:47.33 | koen | like that intel dude with comics sans in his sig |
| 18:47.50 | bluelightning | koen: I don't see that, I use text only ;) |
| 18:48.17 | RP | koen: he is trying to help get various old bugs cleaned up so his intentions are good at least |
| 18:48.46 | RP | koen: if its getting too much, perhaps let him know that |
| 18:48.53 | koen | after some reorg a lot of bugs were tagged NEEDINFO because the new guys didn't bother to read the bugs |
| 18:49.14 | khem | koen: |
| 18:49.30 | khem | these are linaro bugs or yp |
| 18:49.36 | RP | koen: Give me a list of the bugs and I can look into those |
| 18:49.43 | koen | so at this point bugzilla only annoys the crap out of me |
| 18:49.57 | koen | RP: one is the infamous kiosk mode for hob :) |
| 18:50.17 | RP | koen: well, we can probably get you out of the cc of things you don't care about any longer |
| 18:50.34 | RP | koen: it doesn't change the fact that the bugzilla is a good tool to try and resolve the issues you've mentioned with those layers |
| 18:50.41 | bluelightning | koen: be that as it may, it is the mechanism we have for tracking issues, and it's best to have them filed or they will likely get forgotten |
| 18:51.02 | koen | I guess I'm holding it wrong then |
| 18:51.39 | bluelightning | koen: maybe you should think less of it bugging you and more of it bugging the people who are supposed to be fixing the issues ;) |
| 18:51.49 | RP | it does work both ways :) |
| 18:52.26 | koen | that reminds me |
| 18:52.28 | RP | koen: seriously, I do watch nearly all the bugs in there at some point and this is the first I've heard of the emgd version issue in meta-intel |
| 18:52.43 | RP | koen: I think that can be fixed relatively simply too |
| 18:52.47 | koen | if someone mentions a git hash in a commit, can we at least try to make it an OE git hash instead of a poky one? |
| 18:53.18 | fray | 7 minutes to the hour.. |
| 18:53.26 | bluelightning | I can only speak for myself and say I always do that... |
| 18:53.43 | koen | RP: sure, drop the PREFERRED_VERSIONs from the machine.conf and document them in the README |
| 18:53.43 | RP | koen: short of me checking every single commit, I'm not sure how we'll enforce that :/ |
| 18:53.54 | bluelightning | in the YP bugzilla though, poky revisions are used unless noted otherwise |
| 18:54.03 | RP | koen: and break the EMGD builds on the autobuilder? Sure. |
| 18:54.06 | koen | RP: it would help to refuse pulls based on poky git |
| 18:54.09 | fray | RP we could have pre commit hooks.. but I'm not sure it's wroth it |
| 18:55.01 | koen | RP: I've looked at emgd heavily the past few weeks and it was broken for a long time in 'dora' |
| 18:55.02 | RP | koen: I suspect it would help you and cause pain for a significant number of others |
| 18:55.22 | koen | due to linux-yocto problems not pulling in the emgd branch thing |
| 18:55.54 | koen | so I'm not sure if it's actually working in master |
| 18:55.57 | RP | koen: That doesn't change what I said above |
| 18:56.20 | RP | koen: if it isn't working in master then that is bad. It doesn't mean intentionally breaking it is right |
| 18:56.37 | khem | as long as there are no SHA cross-references I think pulls might be ok |
| 18:56.40 | koen | so what's the process of making it 'official' that MACHINE.confs are forbidden to set DISTRO vars? |
| 18:57.01 | RP | We need a set of layer guidelines |
| 18:57.25 | RP | the Yocto Project Compatible ones are probably a start and I'd like to try and extend those a little soon |
| 18:57.28 | kergoth | Wouldn't careful use of DEFAULT_PREFERENCE / COMPATIBLE_MACHINE be an alternative to the version preferences in the machine, where appropriate? |
| 18:57.38 | RP | to include things like checksum changes with addition of BSP layers |
| 18:57.53 | fray | we need to also help inform people what are distro vars, what are machine, etc.. thats not something that I've seen well captured.. partially because we were waiting for a large enough ecosystem on layers to help dictate what we need to specify |
| 18:57.59 | fray | (IMHO we're there now..) |
| 18:57.59 | koen | kergoth: yes, but not in the BSP layers |
| 18:58.12 | RP | kergoth: yes, there are some ways to fix that, not least that emgd uses a spealist machine arch these days |
| 18:58.31 | bluelightning | the long of the process I think is: document policies -> agree on them -> write tools to verify they are being followed -> report on layers following them or not |
| 18:58.32 | RP | its just a quesiton of ensuring those versions are only enabled with that arch code |
| 18:58.44 | bluelightning | we're at step 1 - document policies |
| 18:58.47 | kergoth | koen: bsp layer is appropriate if the thing really isn't buildable for a given machine, or is broken for it. it should be marked as skipped for such a case |
| 18:59.06 | fray | so I'd suggest we take step 1 to the list(s) and get feedback on what policies, for layers, need to be put in place.. |
| 18:59.17 | RP | koen: I'm going to disagree slightly and say that some policy in there is ok, as long as its isolated to specific machines in a distro compatible way |
| 18:59.23 | bluelightning | fray: I have opened a bug on variable classification in the docs, FYI |
| 18:59.26 | koen | kergoth: meta-ti has an anoymymous method that says "the GL driver is hardfloat, won't work" at parse time |
| 18:59.29 | fray | ok |
| 18:59.53 | RP | koen: so can we *please* start collecting bugs on these issues |
| 19:00.16 | koen | kergoth: there are situations where you don't case about certain drivers (or refuse to support them) and don't want the BSP to poke at things |
| 19:00.17 | RP | koen: it will not change overnight but as we spread awareness, it will get fixed |
| 19:01.16 | koen | s/case/care/ |
| 19:02.12 | fray | ok we're 2 minutes after at this point.. |
| 19:02.38 | fray | I'd suggest we call the meeting over.. and move further discussion to the channel (outside of the TSC) or to the mailing list.. |
| 19:03.01 | RP | can stick around a bit longer but I agree |
| 19:03.02 | fray | as for the remaining items from the OEDAM.. I think they're more future looking so they may not really need to be discussed, but we could cover them in the next regularly scheduled meeting (next month) |
| 19:04.26 | fray | ok meeting over for today, any objections? |
| 19:04.36 | koen | nope |
| 19:04.39 | RP | fray: not from me |
| 19:04.43 | bluelightning | ok with me |
| 19:05.09 | fray | we have concensus (unless khem objects) :) |
| 19:05.20 | khem | adjourn |
| 19:05.25 | jefro__ | Thanks everyone |
| 19:06.00 | nitink | koen: emgd is not ported to v3.14 kernel |
| 19:06.26 | nitink | all the BSPs using EMGD driver are currently at v3.10 linux yocto kernel |
| 19:07.16 | nitink | koen: and these work fine with current meta-intel master with daisy/master poky/oecore |
| 19:07.25 | bluelightning | jefro__: log is in your email btw |
| 19:08.41 | koen | nitink: it's about PREFERRED_VERSION_xorgstuff |
| 19:09.17 | RP | koen: Is that an issue if its put into an emgd specific package architecture? |
| 19:09.27 | jefro__ | bluelightning got it, thanks! |
| 19:09.57 | koen | RP: kinda sorta |
| 19:10.27 | koen | RP: it's locked at an xorg version that is incompatible with most of the x stuff in OE |
| 19:10.42 | RP | koen: ok, so that is a different issue :/ |
| 19:11.15 | koen | and since it has pcie and usb, that is *($*(@@ annnoying |
| 19:11.19 | RP | koen: and its not something that is any of our control (not nitink's or anyone we know) |
| 19:11.56 | RP | koen: but this isn't like the machine is forcing other things to that version so I don't think this violates any layer guidelines |
| 19:12.25 | RP | koen: trying to enforce a layer guideline to change the emgd binaries simply isn't going to go anywhere |
| 19:12.50 | RP | and I say this as someone who prior to Yocto worked on the Poulsbo graphics driver at Intel :/ |
| 19:13.53 | Crofton|work | RP, I'm not following closely, but we need to make sure that you can use multiple BSPS in one build |
| 19:15.14 | RP | Crofton|work: due to some hard work in meta-intel you can, you can even build emgd and non-emgd versions of those machines |
| 19:15.16 | koen | RP: the emgd arch made is less annoying, but it still is distro policy |
| 19:15.56 | Crofton|work | at any rate, we need to get this stuff down so BSP creators know where they will get pushback |
| 19:15.57 | RP | koen: I do not see any way around this other than simply not shipping them at all |
| 19:16.26 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 19:16.33 | RP | koen: seriously, I did my best to help things with the emgd arch stuff. I cannot see anything more that can be done but proposals would be welcome |
| 19:17.04 | koen | RP: so 'emgd' is special and allowed to break rules, fine |
| 19:17.11 | koen | document that in the README |
| 19:17.24 | RP | koen: It is not breaking "THE RULES" |
| 19:18.03 | koen | preferred_version is distro territory, except for kernel and bootloader |
| 19:18.24 | Crofton|work | harware vendor makes our life hard, news at 11 |
| 19:18.36 | RP | koen: I disagree in this case specifically because they've setup an arch specific feed |
| 19:18.46 | RP | koen: I need to step afk. If the emgd machines bother you don't use them |
| 19:27.38 | *** join/#oe KNERD (~KNERD@24.175.253.226) |
| 19:49.28 | *** join/#oe Jafura (~Jean-Fran@host-213-213-229-139.brutele.be) |
| 20:04.08 | *** join/#oe hillct (~hillct@cpe-071-070-219-043.nc.res.rr.com) |
| 20:07.27 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 20:08.53 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 20:13.30 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 20:19.52 | *** join/#oe tgall_foo (~tgall@31.221.68.180) |
| 20:19.53 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 20:46.16 | *** join/#oe florian (~fuchs@sign-4db604b9.pool.mediaWays.net) |
| 20:46.17 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 20:54.10 | khem | is gstreamer-0.10 support dropped from QT5.3+ upstream |
| 20:57.46 | *** join/#oe nitink1 (~nitink@134.134.137.71) |
| 20:59.17 | *** join/#oe nitink2 (nitink@nat/intel/x-noatqickxsrgztri) |
| 21:21.32 | *** join/#oe ant_home (~andrea@host234-253-dynamic.10-79-r.retail.telecomitalia.it) |
| 21:36.26 | *** join/#oe bluelightning (~paul@2001:8b0:258:7d7a:5e51:4fff:febb:401d) |
| 21:36.26 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 21:53.41 | *** join/#oe RP (~richard@5751f4a1.skybroadband.com) |
| 22:12.35 | *** join/#oe nitink (~nitink@134.134.139.70) |
| 22:44.46 | *** join/#oe _chase_ (~a0271661@nat/ti/x-pqjvlfdgwmescypz) |
| 22:46.18 | *** join/#oe oneQubit_ (~oneQubit@c-69-138-31-87.hsd1.md.comcast.net) |
| 23:06.29 | *** join/#oe nitink1 (nitink@nat/intel/x-dikadjlomfcqamon) |
| 23:19.40 | *** join/#oe andre_d (~andred@212.17.57.101) |
| 23:24.45 | *** join/#oe sr105|away (~sr105@65349hfc19.tampabay.res.rr.com) |
| 23:54.26 | *** join/#oe nitink (~nitink@134.134.139.76) |
| 23:55.04 | *** join/#oe Leatherface_ (~leatherfa@2001:470:dd7d:0:7827:4238:83c7:eb29) |
| 23:59.08 | *** join/#oe muppe (~Marko@ip050-115.seclan.com) |