01:05.54 | *** join/#oe ericben (~ebenard@pac33-3-88-170-243-169.fbx.proxad.net) |
01:10.38 | *** join/#oe slonsiki (~slonsiki@69-12-177-67.dsl.static.sonic.net) |
01:32.55 | *** join/#oe johny_ (79321429@gateway/web/freenode/ip.121.50.20.41) |
01:32.57 | johny_ | hii |
01:33.08 | johny_ | can we give preferred provider fro .so files also? |
01:33.12 | johny_ | for* |
01:38.28 | johny_ | if two modules generates the the .so with same name, then is there any way to give PREFERRED PROVIDER for that so file? |
01:52.38 | *** join/#oe joshc (~joshc@rhlug/joshc) |
02:00.45 | *** join/#oe mario-goulart (~user@email.parenteses.org) |
02:06.58 | *** join/#oe liuyq (~liuyq0307@static-ip-225-98-134-202.rev.dyxnet.com) |
02:12.33 | *** join/#oe silviof2 (~silviof@ppp-188-174-41-83.dynamic.mnet-online.de) |
02:53.30 | *** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net) |
03:21.46 | *** join/#oe GunsNRose (~GunsNRose@182.148.69.223) |
03:32.47 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
03:56.47 | *** join/#oe _chase_ (~a0271661@192.94.92.11) |
05:05.31 | *** join/#oe clio (~andrej@85.159.109.222) |
05:05.58 | *** join/#oe ericben (~ebenard@pac33-3-88-170-243-169.fbx.proxad.net) |
05:14.54 | *** join/#oe rsalveti (~rsalveti@unaffiliated/rsalveti) |
06:51.16 | *** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net) |
07:09.34 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
07:09.51 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
07:16.07 | *** join/#oe stefan_schmidt_w (~stefan_sc@82.43.26.66) |
07:34.37 | suihkulokki | what's the polite time to wait for layer maintainer to respond to patch before ping? |
07:50.09 | *** join/#oe ant_work (~ant@host54-128-static.10-188-b.business.telecomitalia.it) |
07:53.48 | *** join/#oe bluelightning (~paul@83.217.123.106) |
07:53.48 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
08:00.52 | bluelightning | morning all |
08:01.57 | *** join/#oe GunsNRose (~GunsNRose@182.148.69.223) |
08:03.08 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
08:03.13 | *** join/#oe tsjsieb (~tsjsieb@5469C560.cm-12-2d.dynamic.ziggo.nl) |
08:05.12 | tsjsieb | Goodmorning |
08:05.44 | tsjsieb | I was used to change kernel configurations with 'bitbake virtual/kernel -c devshell' and than make menuconfig |
08:06.27 | tsjsieb | but these days it seems that the configure tasks isn't done yet when I do -c devshell, so I have to do manually a -c configure before it |
08:06.45 | tsjsieb | Is something recently changed that causes this? |
08:07.22 | tsjsieb | (recently als in this year / since a dylan ? ) |
08:09.54 | bluelightning | tsjsieb: you're better off using -c menuconfig I think |
08:12.03 | mckoan | good morning |
08:17.45 | *** join/#oe GunsNRose_ (~GunsNRose@118.114.150.132) |
08:28.57 | *** join/#oe andre_d (~andre_d@sushi.andred.org) |
08:30.39 | *** join/#oe GunsNRose (~GunsNRose@118.114.150.132) |
08:32.57 | *** join/#oe conditionzero (~Unknown@2001:6f8:12d9:13:1e4b:d6ff:fedb:207c) |
08:33.12 | *** join/#oe hsychla (~hsychla@2001:6f8:12d9:13:c058:b9bc:f6d:c251) |
08:35.10 | *** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:2869:e944:c96f:b8c1) |
08:40.31 | conditionzero | hi, after we updated bitbake from 1.19.0 to 1.19.1 bitbake will not build anymore and throws a python error: AttributeError: 'NoneType' object has no attribute 'rfind' |
08:41.32 | conditionzero | the error trace is about a page long and begins with: File "/var/wfailla/tplino-core/bitbake/lib/bb/runqueue.py", line 1354, in RunQueueExecuteTasks.execute(): |
08:44.10 | bluelightning | ndec: hi, btw I have a patch to add the sanity check you were suggesting: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=paule/fixes3&id=b4a4eb27138adc71036647c404fff2ebedd2c5c1 |
08:46.35 | tsjsieb | bluelightning: if I use that, than after configuring I can manually copy the .config file to my own layer (and use it as defconfig) |
08:47.10 | bluelightning | tsjsieb: right, you can do that with -c menuconfig |
08:49.09 | tsjsieb | and If I want to make an adjusmtent to a source file and create a patch, I used to use devshell for that aswell and than directly create an uImage from the devshell to test it |
08:52.09 | liveforeverx | Hi, all! This is a trace for conditionzero problem: https://gist.github.com/liveforeverx/a99ae205e6873a51cf06 |
08:52.53 | liveforeverx | Is this chat the right place to ask a question about this? |
08:53.42 | bluelightning | liveforeverx: certainly, I was just checking the code to see if I could see the offending rfind call |
08:54.31 | ndec | bluelightning: thanks! i had started something too.. but i didn't know about bb.utils.which() ;-) |
08:55.09 | ndec | bluelightning: i think we might want to remove 'and it is a security issue'. of course it is, but from bitbake/OE perspective we don't really care, no? |
08:56.14 | bluelightning | ndec: I thought about that... I'm trying to convey why this is a bad idea, rather than just being a requirement of our system |
08:56.42 | ndec | bluelightning: sure... but there are many other good advices that we can give to people too ;-) |
08:56.58 | ndec | the real problem with setuid in our case, is that it breaks the build. |
08:59.10 | bluelightning | ndec: well, if you feel strongly about not having it I can remove it |
09:00.52 | bluelightning | ndec: I just think as an industry we shouldn't turn a blind eye to such egregious behaviour ;) |
09:02.17 | ndec | bluelightning: hehe. i don't mind it that much, in fact. thanks for making the patch. any chance you can have it in dylan too? |
09:02.21 | *** join/#oe andre_d (~andre_d@82.220.1.204) |
09:03.15 | bluelightning | ndec: should be able to backport it yep |
09:03.24 | ndec | ok. hx. |
09:03.25 | ndec | thx. |
09:16.36 | bluelightning | liveforeverx: conditionzero: hmm... the traceback is unhelpful and looking at the instances of rfind we have, I can't see one that could throw that error... |
09:18.19 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
09:19.13 | *** join/#oe panda84kde (~diego@static-217-133-170-65.clienti.tiscali.it) |
09:22.19 | bluelightning | conditionzero: can you perhaps give me some more information that might help reproducing it? |
09:23.29 | conditionzero | bluelightning: thx for looking in to that, i will ask the guy who updated bitbake what he did maybe he knows more, he will be here in about 1 houre maybe a bit later, one other question. We have installed pserv server for our build systems. We are able to start a bitbake-prserv server on a specific port with a specific file and can get bitbake to communicate to that server. BUT AUTOINC and "${AUTOREV}" do not increase any numb |
09:23.29 | conditionzero | er even thogh we committed and pushed things to a repo. The only time this is working is when you change the recipe from AUTOINC to "${AUTOREV}". Can anyone help us to configure AUTOINC or AUTOREV ? |
09:24.23 | bluelightning | conditionzero: AUTOINC is just a placeholder we put into the value of SRCPV before packaging time, it shouldn't be anywhere in variable values / other configuration |
09:24.54 | bluelightning | conditionzero: if you want the recipe to rebuild properly when you update the repository, you must use SRCREV = "${AUTOREV}" |
09:26.21 | conditionzero | ok, i will try that, but the initial tests were not promising yesterday |
09:27.37 | *** join/#oe shoragan (~jlu@debian/developer/shoragan) |
09:34.24 | conditionzero | bluelightning, is it necessary to do a cleanall so autorev works ? |
09:34.38 | bluelightning | conditionzero: should not be necessary no |
09:34.57 | conditionzero | bluelightning, then it is not working |
09:35.40 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
09:36.12 | bluelightning | conditionzero: would you be able to pastebin your recipe? |
09:39.24 | liveforeverx | bluelightning: https://gist.github.com/liveforeverx/8430772df418c950b31e |
09:42.00 | ndec | bluelightning: btw, i don't know if you use 'Reported-by' tag in OE, but if you do, feel free to use Reported-by Nicolas Dechesne <nicolas.dechesne@linaro.org>. |
09:42.45 | bluelightning | ndec: ok I'll include that in the commit message, thanks |
09:43.11 | bluelightning | liveforeverx: ok, I'll try to set up an environment to reproduce that this afternoon |
09:43.52 | liveforeverx | bluelightning: Thanks |
09:50.46 | conditionzero | bluelightning, thx |
10:06.22 | *** join/#oe phdeswer (~phdeswer@194.157.27.2) |
10:36.42 | *** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:883a:3bdb:412e:7336) |
10:50.58 | pb_ | morning all |
10:53.17 | bluelightning | hi pb_ |
10:57.59 | pb_ | hi bluelightning |
11:11.18 | *** join/#oe lpapp (~lpapp@kde/lpapp) |
11:11.26 | *** part/#oe lpapp (~lpapp@kde/lpapp) |
11:11.35 | *** join/#oe lpapp (~lpapp@kde/lpapp) |
11:12.38 | lpapp | hi, the topic was modified in #yocto already, so you can take a look at the sample, but according to the freenode guidelines "If you're publishing logs on an ongoing basis, your channel topic should reflect that fact. Be sure to provide a way for users to make comments without logging,", a note would be nice in the topic about public logging. |
11:12.48 | lpapp | "http://freenode.net/channel_guidelines.shtml" |
11:15.28 | bluelightning | of those who are around these days only XorA and kergoth can change the channel topic |
11:16.25 | *** part/#oe lpapp (~lpapp@kde/lpapp) |
11:16.51 | XorA | I can, wow |
11:17.04 | XorA | well if someone of board wants to tell me a new one I shall change it |
11:25.48 | *** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:a42d:9405:806f:2cf1) |
11:30.07 | *** join/#oe likewise (~chatzilla@ip503cba31.speed.planet.nl) |
11:34.06 | *** join/#oe liveforeverx1 (~Adium@2001:6f8:12d9:13:209d:ab:c50e:aabf) |
11:38.41 | *** join/#oe Stygia (~gmpsaifi@0904ds6-noe.0.fullrate.dk) |
11:44.44 | *** join/#oe ldnunes (~ldnunes_@187.23.155.55) |
11:47.04 | conditionzero | bluelightning, i have an update , i have changed the recipe to SRCREV = "${AUTOREV}" |
11:47.52 | conditionzero | bluelightning, and PV = "AUTOINC", now it works when i preform a -c cleanall |
11:50.54 | liveforeverx1 | bluelightning: updated https://gist.github.com/liveforeverx/8430772df418c950b31e |
11:55.07 | pb_ | heh, did lpapp really join this channel just to complain about the topic? |
11:55.29 | pb_ | those kde guys, good grief. |
11:56.16 | likewise | gm |
11:57.50 | ant_work | pb_: heh few words |
11:58.42 | *** join/#oe joeythesaint (~jjm@206-248-190-39.dsl.teksavvy.com) |
12:02.44 | pb_ | hi likewise |
12:03.06 | *** join/#oe GunsNRose (~GunsNRose@182.139.169.64) |
12:03.20 | pb_ | hi ant_work |
12:06.35 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
12:10.22 | *** join/#oe zecke (~ich@91-65-247-193-dynip.superkabel.de) |
12:13.55 | bluelightning | conditionzero: PV = "AUTOINC" isn't necessary though, AFAIK there's nothing that would be looking for AUTOINC in the value |
12:14.13 | bluelightning | pb_: hey, I use kde :p |
12:16.14 | bluelightning | liveforeverx1: conditionzero: oh, I didn't notice... you were apparently missing PV = "x.y+git${SRCPV}" in your original recipe |
12:16.42 | ant_work | bluelightning: any bug for KDE upstream to complain with someone in particular? |
12:17.07 | ant_work | pb_: ^^ :p |
12:17.16 | bluelightning | ant_work: sorry, what do you mean? |
12:18.03 | ant_work | it shouldn't be terribly difficult to write a long list, thinking of it... |
12:18.53 | *** join/#oe panda84kde (~diego@static-217-133-170-65.clienti.tiscali.it) |
12:25.40 | *** join/#oe Vutral (~ss@mirbsd/special/Vutral) |
12:25.56 | *** join/#oe ldnunes (~ldnunes_@187.23.155.55) |
12:33.07 | liveforeverx1 | bluelightning: Thanks! Its working now |
12:33.17 | bluelightning | liveforeverx1: OK, great |
12:33.37 | bluelightning | perhaps we should be validating that people are setting the right variables for this... |
12:33.47 | bluelightning | the trick would be doing it in a way that doesn't hurt flexibility |
12:38.05 | *** join/#oe eren (~eren@unaffiliated/eren) |
13:08.23 | *** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:a510:d23b:105e:608) |
13:11.15 | *** join/#oe ldnunes (~ldnunes_@187.23.155.55) |
13:19.55 | *** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net) |
13:32.01 | *** join/#oe ldnunes (~ldnunes_@187.23.155.55) |
13:36.49 | ndec | hi. when desiging our own distro, is it common practice to add 'features' in DISTRO_FEATURES? or is DISTRO_FEATURE only meant to contain OE features, not custom one? same question for IMAGE_FEATURE? |
13:37.08 | ndec | basically, we need a mechanism to define our features, and it's not clear to me what's the best way to do that. |
13:37.20 | *** join/#oe ldnunes (~ldnunes_@187.23.155.55) |
13:43.26 | *** join/#oe hollisb (~hollisb@c-67-169-221-181.hsd1.or.comcast.net) |
13:46.56 | conditionzero | bluelightning, how do i change the order of the values in the ${SRCPV} variable |
13:48.04 | *** join/#oe RP_ (~richard@93-97-173-237.zone5.bethere.co.uk) |
13:48.27 | bluelightning | ndec: I think it's perfectly acceptable to define your own DISTRO_FEATURES if that helps you; if they might be of value to others it would be worth trying to standardise for everyone though |
13:49.01 | ndec | bluelightning: these are in fact features very specific to our distro. |
13:49.10 | bluelightning | conditionzero: can you explain why you want to do that? the incrementing number is at the start so that the values compare correctly |
13:49.36 | ndec | bluelightning: in fact i am not sure if these 'features' are DISTRO feature or IMAGE feature ;-) they are features, for sure... |
13:50.12 | ndec | our product is made of several devices. a mix of client, server, and a few related things. |
13:50.25 | bluelightning | ndec: do they affect the compilation/contents of other recipes or just what items/configuration ends up in the image? |
13:50.33 | ndec | the same components are included in each 'product' but with different features/config. |
13:50.48 | ndec | compilation is affected. |
13:51.15 | bluelightning | ok, it's DISTRO_FEATURES (or PACKAGECONFIG if it's on a per-recipe basis) in that case |
13:51.43 | bluelightning | but that does mean you effectively need to have different distro configs |
13:51.53 | ndec | good info. so IMAGE_FEATURE is only meant to decide which package are pulled or not, but they aren't supposed to impact compilation, right? |
13:52.12 | bluelightning | ndec: right |
13:52.25 | ndec | you mean 2 DISTRO? |
13:52.45 | ndec | ah yes, because DISTRO_FEATURES are set in the distro .conf... |
13:52.52 | bluelightning | ndec: IMAGE_FEATURES can also determine what post-processing is done on the image (e.g. debug-tweaks determines whether the root user has a blank password or not) |
13:53.00 | bluelightning | ndec: indeed |
13:53.49 | ndec | ok, so no need to create MYDISTRO_FEATURE variables, i just 'extend' the existing DISTRO_FEATURE. that i wasn't sure. |
13:55.17 | bluelightning | ndec: the only alternative without having that is separate recipes/packages that can be installed expressing the different configurations; or, turning it into a runtime configuration option (as we did with dropbear's "allow blank root password" option) |
13:55.44 | bluelightning | depends on the exact situation of course |
13:56.06 | ndec | we really need different 'images', it can't be runtime, but i will look at what was done for dropbear |
13:56.38 | ndec | and we can't split packages, because the same package (sometimes) are pulled into the 2 product, but with different compilation/configuration |
13:57.34 | ndec | also bluelightning, about PACKAGECONFIG, is it possible to 'set' a package PACKAGECONFIG outside of the package itself, like in the distro conf? or is that not recommended. |
13:58.11 | bluelightning | ndec: that's definitely supported and common; you just need to to PACKAGECONFIG_pn-recipename = "..." |
13:58.15 | ndec | iow, when a package offers 2 PACKAGECONFIG, where do i set which one i want? |
13:58.24 | ndec | ah. in the distro? |
13:58.29 | bluelightning | ndec: yes |
13:58.33 | ndec | good. thx. |
13:58.50 | ndec | i need to keep a copy of that conversation ;-) thanks. |
13:59.13 | bluelightning | np |
13:59.56 | ant_work | ndec, smthg sounds odd |
13:59.58 | ant_work | <ndec> and we can't split packages, because the same package (sometimes) are pulled into the 2 product, but with different compilation/configuration |
14:00.20 | ant_work | aren't those packages machine-specific? |
14:00.29 | ndec | no. |
14:00.51 | ndec | it's really different 'sotf' config. |
14:01.26 | ndec | let's say you have Gstreamer in both, but one will act as 'server', the other as 'client'. so you might want different configuration. |
14:01.37 | ndec | i just made up this example. |
14:02.24 | ndec | in fact, even for the kernel we want different configuration. though it's the same underlying machine, one device is 'headless', the other one has a display. |
14:03.24 | conditionzero | bluelightning, because we want it to be tag+r1.0+arch - after git changes -> tag+r1.1+arch ... but now it is 0+tag+r1.0+arch -after git changes -> 1+tag+r1.0+arch |
14:05.06 | bluelightning | conditionzero: when you say tag do you mean the tag name or the hash? |
14:05.24 | conditionzero | bluelightning, the tag name |
14:05.31 | bluelightning | ndec: ok it kind of does sound like a different distro config |
14:06.23 | bluelightning | conditionzero: how is the tag name getting in there at the moment? |
14:08.04 | conditionzero | bluelightning, it looks like this /sandbox-dev_0.1+r2.0+d201603aa8ba7c51ab6910faf26022a178856977-r2.0_i586.ipk but should look like this /sandbox-dev_0.1+r2.0+d201603aa8ba7c51ab6910faf26022a178856977_i586.ipk |
14:08.04 | *** join/#oe acidfu (~nib@24.37.17.210) |
14:08.05 | *** join/#oe acidfu (~nib@unaffiliated/acidmen) |
14:09.39 | ant_work | ndec: for a similar case we made machine.specific the couple of packages with different config options for video size |
14:10.15 | ndec | so 'fake' machine? |
14:10.27 | ant_work | no, many of them |
14:10.37 | ant_work | the problem is the with package management |
14:11.07 | ant_work | the first build will build foo-distro.xy.ipk with the config of that machine and following bitbake will not build it |
14:11.15 | *** join/#oe liveforeverx (~Adium@p57AE6B6B.dip0.t-ipconnect.de) |
14:11.23 | ndec | we don't use package managment, but i see the problem. |
14:11.35 | ant_work | same name for different binaries... |
14:11.47 | ant_work | different checksums... |
14:12.06 | ant_work | so you get foo-distro-machine_x.y.ipk |
14:12.40 | ant_work | btw the same happens automatically if you have a .bbappend in your layer sitting in a mcahine specific subdir |
14:13.16 | ant_work | http://cgit.openembedded.org/meta-handheld/tree/recipes-graphics/xorg-xserver |
14:15.01 | ant_work | well, bad example here... PACKAGE_ARCH = "${MACHINE_ARCH}" is in themainrecipe... |
14:15.27 | bluelightning | conditionzero: the number at the start is coming from SRCPV whereas the one at the end is from PR |
14:16.40 | bluelightning | conditionzero: I don't know that we currently support what you're trying to do, but I think we'd take patches to enable it |
14:16.47 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
14:17.12 | *** join/#oe GunsNRose (~GunsNRose@182.139.169.64) |
14:19.45 | ant_work | ndec: ah and well, in case of linux-yocto, there are interesting bindings to do between MACHINE_FEATURES and KERNEL_FEATURES |
14:19.49 | *** join/#oe SoylentY_ (~SoylentYe@129.10.181.81) |
14:20.08 | *** join/#oe hillct (~hillct@c-24-34-200-20.hsd1.ma.comcast.net) |
14:20.20 | ndec | we aren't there yet... we aren't using linux-yocto yet. |
14:20.29 | ndec | but we might want to move to that at some point. |
14:20.47 | *** join/#oe CMoH (~cipi@78.96.83.205) |
14:20.48 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
14:25.30 | ant_work | ndec: if it is 3.8 it's just matter of copying over the old defconfig and the patches |
14:30.41 | ndec | ant_work: hehe... you probably don't want to know which version it is ;-) |
14:30.52 | *** join/#oe zecke (~ich@91-65-247-193-dynip.superkabel.de) |
14:31.20 | ant_work | hm.. I started with the very first 2.6.3x Yocto ;) |
14:31.26 | ndec | ant_work: there is a '3' in the version, but not at the beginning! |
14:31.38 | bluelightning | :) |
14:31.59 | bluelightning | ndec: I just hope it's not in the middle ;) |
14:32.33 | ndec | no.. |
14:32.36 | ant_work | ndec: you would surely see it swallow your defconfig :p |
14:33.08 | ant_work | there are amazing kernel tools |
14:34.03 | *** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:d1c2:6815:cc39:6727) |
14:35.45 | ant_work | ndec: when I configured it the tool was not yet available but now it is expected that you can just supply the output of -c savedefconfig |
14:44.15 | *** join/#oe anarsoul (~anarsoul@178.124.194.242) |
14:48.09 | *** join/#oe GunsNRose (~GunsNRose@182.139.169.64) |
15:00.52 | *** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net) |
15:07.34 | *** join/#oe SoylentYellow (~SoylentYe@129.10.181.81) |
15:09.10 | *** join/#oe mrmcan (~mrcan@unaffiliated/mrcan) |
15:14.26 | *** join/#oe ldnunes (~ldnunes_@187.23.155.55) |
15:18.51 | *** join/#oe ynezz (ynezz@ibawizard.net) |
15:24.00 | *** join/#oe ynezz (ynezz@ibawizard.net) |
15:27.33 | *** join/#oe ldnunes (~ldnunes_@187.23.155.55) |
15:28.58 | *** join/#oe ynezz (ynezz@ibawizard.net) |
15:38.27 | *** join/#oe darkschneider (~gab@93-32-53-159.ip32.fastwebnet.it) |
15:43.24 | *** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:7d9e:c8d3:ba7f:a79c) |
15:45.46 | *** join/#oe mhnoyes (~mhnoyes@74-38-52-33.dr01.myck.or.frontiernet.net) |
15:45.46 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
15:55.13 | *** join/#oe panda84kde (~diego@static-217-133-170-65.clienti.tiscali.it) |
16:01.58 | *** join/#oe NightMonkey (~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) |
16:02.10 | *** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
16:04.25 | Crofton | bluelightning, I am going to propose theat OE hand out medals |
16:06.00 | bluelightning | Crofton: if we had a regular OEDEM we could have a ceremony and everything :) |
16:08.13 | XorA | mythical OEDEM |
16:08.14 | ndec | one team member reported that 'mate-terminal' is not supported in lib/oe/terminal.py. is that on purpose, or would you take a patch for it? (we have the patch already) |
16:08.46 | XorA | ndec: mate-terminal = gnome-terminal so I guess we should support it |
16:08.56 | bluelightning | ndec: I think we'd take it yep |
16:09.25 | *** join/#oe liveforeverx (~Adium@p57AE6B6B.dip0.t-ipconnect.de) |
16:10.06 | bluelightning | XorA: I'd love for it to happen, it's just it's kind of hard to get everyone in the same place... I guess it sort of happens informally at ELCE and FOSDEM at least on the European side (and somehow Crofton manages to convince his cat it's OK to spend money on the airfaire) |
16:10.27 | bluelightning | s/airfaire/airfare/ |
16:10.37 | ndec | bluelightning: ok. will send. |
16:10.38 | XorA | I assume the AGM will be at ELCE |
16:10.57 | XorA | would be the first I would ever make :_D |
16:11.05 | bluelightning | XorA: I've not heard that it's been decided but it usually is |
16:11.18 | Crofton | yes, that is convenient |
16:11.36 | XorA | Crofton: dont forget the announment time this year ;-) |
16:11.49 | XorA | zecke: must be getting bored of reminding |
16:11.57 | Crofton | We have talked about it |
16:12.10 | Crofton | I'm on holiday, when I get back I need to make sue stuff gets announced |
16:13.54 | XorA | has turned into a right busybody |
16:14.05 | XorA | Crofton: anyway apparently out channel topics are not freenode compliant |
16:14.26 | broonie | They don't have the requisite "All hail freenode"? |
16:14.37 | bluelightning | ah foo, I meant to forward fray's announcement for the public TSC meeting |
16:15.00 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
16:15.07 | Crofton | XorA, what? |
16:16.38 | XorA | <lpapp> hi, the topic was modified in #yocto already, so you can take a look at the sample, but according to the freenode guidelines "If you're publishing logs on an ongoing basis, your channel topic should reflect that fact. Be sure to provide a way for users to make comments without logging,", a note would be nice in the topic about public logging. |
16:16.39 | XorA | <lpapp> "http://freenode.net/channel_guidelines.shtml" |
16:17.42 | Crofton | rofl |
16:19.39 | *** join/#oe liveforeverx (~Adium@2001:6f8:12d9:13:103b:9d9c:909a:bf64) |
16:21.43 | XorA | thats it job done, can go back to worrying about running amiga games on C64 |
16:24.31 | zecke | XorA: what did I forget? I thought mickey didn't send the papers? |
16:24.57 | XorA | zecke: I was pointing out you generally remind the board to do the AGM |
16:25.47 | *** join/#oe mr_science (~sarnold@net-cf9a4e91.cst.impulse.net) |
16:25.48 | *** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy) |
16:29.36 | *** join/#oe apelete_ (~apelete@176-26-190-109.dsl.ovh.fr) |
16:34.12 | bluelightning | TSC / working group announcement sent |
16:44.44 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
16:44.46 | *** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net) |
16:47.03 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
16:56.48 | *** join/#oe darkschneider (~gab@93-32-51-10.ip32.fastwebnet.it) |
16:59.40 | *** join/#oe zenlinux (~sgarman@173-8-218-204-Oregon.hfc.comcastbusiness.net) |
17:02.24 | *** join/#oe SoylentY_ (~SoylentYe@c-24-128-79-27.hsd1.ma.comcast.net) |
17:17.18 | *** join/#oe zenlinux (~sgarman@c-50-139-96-211.hsd1.or.comcast.net) |
17:52.15 | *** join/#oe zecke_ (~ich@91-65-247-193-dynip.superkabel.de) |
18:28.05 | *** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net) |
18:46.13 | *** join/#oe zenlinux (~sgarman@c-50-139-96-211.hsd1.or.comcast.net) |
18:54.35 | *** join/#oe phdeswer_ (~phdeswer@a88-113-104-180.elisa-laajakaista.fi) |
18:57.52 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
19:07.55 | *** join/#oe stefan_schmidt (~stefan@host-78-149-134-157.as13285.net) |
19:30.48 | *** join/#oe liveforeverx (~Adium@p54BE610D.dip0.t-ipconnect.de) |
19:46.44 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
20:30.38 | *** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net) |
20:45.00 | mr_science | this has to be the worst document system ever... |
20:50.23 | *** join/#oe liveforeverx (~Adium@p54BE610D.dip0.t-ipconnect.de) |
21:00.19 | *** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
21:07.34 | *** join/#oe hillct (~hillct@c-24-34-200-20.hsd1.ma.comcast.net) |
21:19.01 | *** join/#oe zenlinux (~sgarman@c-50-139-96-211.hsd1.or.comcast.net) |
21:40.47 | pb_ | which document system is that? |
21:41.28 | mr_science | MQ1 |
21:42.10 | mr_science | not sure if it's about doc management, since all i see is the "training" interface |
21:42.31 | pb_ | hm. |
21:42.38 | pb_ | "The General Atomics MQ-1 Predator is an unmanned aerial vehicle (UAV)" |
21:42.45 | pb_ | it does sound like that would suck as a document system |
21:42.46 | mr_science | heh |
21:43.27 | mr_science | they use it to shove training docs at people and track that they've "signed off" on them... |
21:43.58 | mr_science | it's truly a POS, and i don't mean point-of-sale systemmm |
21:44.30 | mr_science | okay, time to go blow off a little steam... |
22:08.58 | *** join/#oe ant_home (~andrea@host88-64-dynamic.8-87-r.retail.telecomitalia.it) |
22:23.27 | *** join/#oe eren (~eren@unaffiliated/eren) |
22:32.40 | *** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net) |
22:35.53 | *** join/#oe liveforeverx (~Adium@p54BE610D.dip0.t-ipconnect.de) |
22:56.53 | *** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net) |
23:05.09 | *** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net) |
23:20.30 | *** join/#oe bluelightning (~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com) |
23:20.30 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
23:44.41 | *** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net) |