**** BEGIN LOGGING AT Fri Jul 26 02:59:57 2013 Jul 26 07:34:36 what's the polite time to wait for layer maintainer to respond to patch before ping? Jul 26 08:00:52 morning all Jul 26 08:05:12 Goodmorning Jul 26 08:05:44 I was used to change kernel configurations with 'bitbake virtual/kernel -c devshell' and than make menuconfig Jul 26 08:06:27 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 Jul 26 08:06:45 Is something recently changed that causes this? Jul 26 08:07:22 (recently als in this year / since a dylan ? ) Jul 26 08:09:54 tsjsieb: you're better off using -c menuconfig I think Jul 26 08:12:03 good morning Jul 26 08:40:31 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' Jul 26 08:41:32 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(): Jul 26 08:44:10 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 Jul 26 08:46:35 bluelightning: if I use that, than after configuring I can manually copy the .config file to my own layer (and use it as defconfig) Jul 26 08:47:10 tsjsieb: right, you can do that with -c menuconfig Jul 26 08:49:09 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 Jul 26 08:52:09 Hi, all! This is a trace for conditionzero problem: https://gist.github.com/liveforeverx/a99ae205e6873a51cf06 Jul 26 08:52:53 Is this chat the right place to ask a question about this? Jul 26 08:53:42 liveforeverx: certainly, I was just checking the code to see if I could see the offending rfind call Jul 26 08:54:31 bluelightning: thanks! i had started something too.. but i didn't know about bb.utils.which() ;-) Jul 26 08:55:09 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? Jul 26 08:56:14 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 Jul 26 08:56:42 bluelightning: sure... but there are many other good advices that we can give to people too ;-) Jul 26 08:56:58 the real problem with setuid in our case, is that it breaks the build. Jul 26 08:59:10 ndec: well, if you feel strongly about not having it I can remove it Jul 26 09:00:52 ndec: I just think as an industry we shouldn't turn a blind eye to such egregious behaviour ;) Jul 26 09:02:17 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? Jul 26 09:03:15 ndec: should be able to backport it yep Jul 26 09:03:24 ok. hx. Jul 26 09:03:25 thx. Jul 26 09:16:36 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... Jul 26 09:22:19 conditionzero: can you perhaps give me some more information that might help reproducing it? Jul 26 09:23:29 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 Jul 26 09:23:29 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 ? Jul 26 09:24:22 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 Jul 26 09:24:54 conditionzero: if you want the recipe to rebuild properly when you update the repository, you must use SRCREV = "${AUTOREV}" Jul 26 09:26:21 ok, i will try that, but the initial tests were not promising yesterday Jul 26 09:34:24 bluelightning, is it necessary to do a cleanall so autorev works ? Jul 26 09:34:38 conditionzero: should not be necessary no Jul 26 09:34:57 bluelightning, then it is not working Jul 26 09:36:12 conditionzero: would you be able to pastebin your recipe? Jul 26 09:39:24 bluelightning: https://gist.github.com/liveforeverx/8430772df418c950b31e Jul 26 09:42:00 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 . Jul 26 09:42:45 ndec: ok I'll include that in the commit message, thanks Jul 26 09:43:11 liveforeverx: ok, I'll try to set up an environment to reproduce that this afternoon Jul 26 09:43:52 bluelightning: Thanks Jul 26 09:50:46 bluelightning, thx Jul 26 10:50:58 morning all Jul 26 10:53:17 hi pb_ Jul 26 10:57:59 hi bluelightning Jul 26 11:12:37 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. Jul 26 11:12:48 "http://freenode.net/channel_guidelines.shtml" Jul 26 11:15:28 of those who are around these days only XorA and kergoth can change the channel topic Jul 26 11:16:51 I can, wow Jul 26 11:17:04 well if someone of board wants to tell me a new one I shall change it Jul 26 11:47:04 bluelightning, i have an update , i have changed the recipe to SRCREV = "${AUTOREV}" Jul 26 11:47:52 bluelightning, and PV = "AUTOINC", now it works when i preform a -c cleanall Jul 26 11:50:54 bluelightning: updated https://gist.github.com/liveforeverx/8430772df418c950b31e Jul 26 11:55:07 heh, did lpapp really join this channel just to complain about the topic? Jul 26 11:55:29 those kde guys, good grief. Jul 26 11:56:16 gm Jul 26 11:57:50 pb_: heh few words Jul 26 12:02:44 hi likewise Jul 26 12:03:19 hi ant_work Jul 26 12:13:55 conditionzero: PV = "AUTOINC" isn't necessary though, AFAIK there's nothing that would be looking for AUTOINC in the value Jul 26 12:14:13 pb_: hey, I use kde :p Jul 26 12:16:14 liveforeverx1: conditionzero: oh, I didn't notice... you were apparently missing PV = "x.y+git${SRCPV}" in your original recipe Jul 26 12:16:42 bluelightning: any bug for KDE upstream to complain with someone in particular? Jul 26 12:17:07 pb_: ^^ :p Jul 26 12:17:16 ant_work: sorry, what do you mean? Jul 26 12:18:03 it shouldn't be terribly difficult to write a long list, thinking of it... Jul 26 12:33:07 bluelightning: Thanks! Its working now Jul 26 12:33:17 liveforeverx1: OK, great Jul 26 12:33:37 perhaps we should be validating that people are setting the right variables for this... Jul 26 12:33:47 the trick would be doing it in a way that doesn't hurt flexibility Jul 26 13:36:49 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? Jul 26 13:37:08 basically, we need a mechanism to define our features, and it's not clear to me what's the best way to do that. Jul 26 13:46:56 bluelightning, how do i change the order of the values in the ${SRCPV} variable Jul 26 13:48:27 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 Jul 26 13:49:01 bluelightning: these are in fact features very specific to our distro. Jul 26 13:49:10 conditionzero: can you explain why you want to do that? the incrementing number is at the start so that the values compare correctly Jul 26 13:49:36 bluelightning: in fact i am not sure if these 'features' are DISTRO feature or IMAGE feature ;-) they are features, for sure... Jul 26 13:50:12 our product is made of several devices. a mix of client, server, and a few related things. Jul 26 13:50:25 ndec: do they affect the compilation/contents of other recipes or just what items/configuration ends up in the image? Jul 26 13:50:33 the same components are included in each 'product' but with different features/config. Jul 26 13:50:48 compilation is affected. Jul 26 13:51:15 ok, it's DISTRO_FEATURES (or PACKAGECONFIG if it's on a per-recipe basis) in that case Jul 26 13:51:43 but that does mean you effectively need to have different distro configs Jul 26 13:51:53 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? Jul 26 13:52:12 ndec: right Jul 26 13:52:25 you mean 2 DISTRO? Jul 26 13:52:45 ah yes, because DISTRO_FEATURES are set in the distro .conf... Jul 26 13:52:52 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) Jul 26 13:53:00 ndec: indeed Jul 26 13:53:49 ok, so no need to create MYDISTRO_FEATURE variables, i just 'extend' the existing DISTRO_FEATURE. that i wasn't sure. Jul 26 13:55:17 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) Jul 26 13:55:44 depends on the exact situation of course Jul 26 13:56:06 we really need different 'images', it can't be runtime, but i will look at what was done for dropbear Jul 26 13:56:38 and we can't split packages, because the same package (sometimes) are pulled into the 2 product, but with different compilation/configuration Jul 26 13:57:34 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. Jul 26 13:58:11 ndec: that's definitely supported and common; you just need to to PACKAGECONFIG_pn-recipename = "..." Jul 26 13:58:15 iow, when a package offers 2 PACKAGECONFIG, where do i set which one i want? Jul 26 13:58:24 ah. in the distro? Jul 26 13:58:29 ndec: yes Jul 26 13:58:33 good. thx. Jul 26 13:58:50 i need to keep a copy of that conversation ;-) thanks. Jul 26 13:59:13 np Jul 26 13:59:56 ndec, smthg sounds odd Jul 26 13:59:59 and we can't split packages, because the same package (sometimes) are pulled into the 2 product, but with different compilation/configuration Jul 26 14:00:20 aren't those packages machine-specific? Jul 26 14:00:29 no. Jul 26 14:00:51 it's really different 'sotf' config. Jul 26 14:01:26 let's say you have Gstreamer in both, but one will act as 'server', the other as 'client'. so you might want different configuration. Jul 26 14:01:37 i just made up this example. Jul 26 14:02:24 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. Jul 26 14:03:24 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 Jul 26 14:05:06 conditionzero: when you say tag do you mean the tag name or the hash? Jul 26 14:05:24 bluelightning, the tag name Jul 26 14:05:31 ndec: ok it kind of does sound like a different distro config Jul 26 14:06:23 conditionzero: how is the tag name getting in there at the moment? Jul 26 14:08:04 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 Jul 26 14:09:39 ndec: for a similar case we made machine.specific the couple of packages with different config options for video size Jul 26 14:10:15 so 'fake' machine? Jul 26 14:10:27 no, many of them Jul 26 14:10:37 the problem is the with package management Jul 26 14:11:07 the first build will build foo-distro.xy.ipk with the config of that machine and following bitbake will not build it Jul 26 14:11:23 we don't use package managment, but i see the problem. Jul 26 14:11:36 same name for different binaries... Jul 26 14:11:47 different checksums... Jul 26 14:12:06 so you get foo-distro-machine_x.y.ipk Jul 26 14:12:40 btw the same happens automatically if you have a .bbappend in your layer sitting in a mcahine specific subdir Jul 26 14:13:16 http://cgit.openembedded.org/meta-handheld/tree/recipes-graphics/xorg-xserver Jul 26 14:15:01 well, bad example here... PACKAGE_ARCH = "${MACHINE_ARCH}" is in themainrecipe... Jul 26 14:15:27 conditionzero: the number at the start is coming from SRCPV whereas the one at the end is from PR Jul 26 14:16:40 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 Jul 26 14:19:45 ndec: ah and well, in case of linux-yocto, there are interesting bindings to do between MACHINE_FEATURES and KERNEL_FEATURES Jul 26 14:20:20 we aren't there yet... we aren't using linux-yocto yet. Jul 26 14:20:29 but we might want to move to that at some point. Jul 26 14:25:30 ndec: if it is 3.8 it's just matter of copying over the old defconfig and the patches Jul 26 14:30:41 ant_work: hehe... you probably don't want to know which version it is ;-) Jul 26 14:31:20 hm.. I started with the very first 2.6.3x Yocto ;) Jul 26 14:31:25 ant_work: there is a '3' in the version, but not at the beginning! Jul 26 14:31:37 :) Jul 26 14:31:59 ndec: I just hope it's not in the middle ;) Jul 26 14:32:33 no.. Jul 26 14:32:36 ndec: you would surely see it swallow your defconfig :p Jul 26 14:33:08 there are amazing kernel tools Jul 26 14:35:45 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 Jul 26 16:04:25 bluelightning, I am going to propose theat OE hand out medals Jul 26 16:06:00 Crofton: if we had a regular OEDEM we could have a ceremony and everything :) Jul 26 16:08:13 mythical OEDEM Jul 26 16:08:14 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) Jul 26 16:08:46 ndec: mate-terminal = gnome-terminal so I guess we should support it Jul 26 16:08:55 ndec: I think we'd take it yep Jul 26 16:10:06 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) Jul 26 16:10:27 s/airfaire/airfare/ Jul 26 16:10:37 bluelightning: ok. will send. Jul 26 16:10:38 I assume the AGM will be at ELCE Jul 26 16:10:57 would be the first I would ever make :_D Jul 26 16:11:05 XorA: I've not heard that it's been decided but it usually is Jul 26 16:11:18 yes, that is convenient Jul 26 16:11:36 Crofton: dont forget the announment time this year ;-) Jul 26 16:11:49 zecke: must be getting bored of reminding Jul 26 16:11:57 We have talked about it Jul 26 16:12:10 I'm on holiday, when I get back I need to make sue stuff gets announced Jul 26 16:13:54 * XorA has turned into a right busybody Jul 26 16:14:05 Crofton: anyway apparently out channel topics are not freenode compliant Jul 26 16:14:26 They don't have the requisite "All hail freenode"? Jul 26 16:14:37 ah foo, I meant to forward fray's announcement for the public TSC meeting Jul 26 16:15:07 XorA, what? Jul 26 16:16:38 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. Jul 26 16:16:39 "http://freenode.net/channel_guidelines.shtml" Jul 26 16:17:41 rofl Jul 26 16:21:43 thats it job done, can go back to worrying about running amiga games on C64 Jul 26 16:24:31 XorA: what did I forget? I thought mickey didn't send the papers? Jul 26 16:24:57 zecke: I was pointing out you generally remind the board to do the AGM Jul 26 16:34:12 TSC / working group announcement sent Jul 26 20:45:00 this has to be the worst document system ever... Jul 26 21:40:47 which document system is that? Jul 26 21:41:28 MQ1 Jul 26 21:42:10 not sure if it's about doc management, since all i see is the "training" interface Jul 26 21:42:31 hm. Jul 26 21:42:38 "The General Atomics MQ-1 Predator is an unmanned aerial vehicle (UAV)" Jul 26 21:42:45 it does sound like that would suck as a document system Jul 26 21:42:46 heh Jul 26 21:43:27 they use it to shove training docs at people and track that they've "signed off" on them... Jul 26 21:43:58 it's truly a POS, and i don't mean point-of-sale systemmm Jul 26 21:44:30 okay, time to go blow off a little steam... Jul 27 02:12:45 oi **** ENDING LOGGING AT Sat Jul 27 02:59:58 2013