**** BEGIN LOGGING AT Thu Jun 04 02:59:59 2015 Jun 04 06:52:29 good morning Jun 04 07:18:36 good morning guys Jun 04 07:26:03 sup Jun 04 08:06:41 morning all Jun 04 08:28:33 hi bluelightning Jun 04 08:43:02 hi mckoan Jun 04 12:49:46 help Jun 04 12:55:00 akrem: what's the problem you are having? Jun 04 12:56:39 Sorry guys i was about to type /HELP so i typed help instead Jun 04 12:56:51 * Crofton|work laughs Jun 04 12:57:00 thanks bluelightning Jun 04 12:57:28 you're welcome I guess :) Jun 04 12:58:01 I am new to IRC Jun 04 12:59:28 I guess we all were at some point Jun 04 13:18:07 do_obfuscation[noexec] = '${@base_conditional("DISTRO_TYPE", "release", "0", "1", d)}' Jun 04 13:18:21 Is that going to work? Jun 04 13:18:28 for some reason it is not working Jun 04 13:18:38 it never does obfuscation Jun 04 13:20:03 it won't work, no Jun 04 13:20:24 the value of the noexec varflag isn't used, just the fact that it exists is enough to stop the task being executed Jun 04 13:20:35 to be honest that has always bothered me Jun 04 13:21:10 as an alternative you can conditionally use d.setVarFlag() from anonymous python instead Jun 04 13:21:54 but would the setvar make it null? Jun 04 13:22:25 this is a complete disaster Jun 04 13:22:43 we have been shipping our code in cleartext Jun 04 13:22:45 for ages now Jun 04 13:22:56 no-body picked this up Jun 04 13:23:14 I HATE code that makes sense but does not make sense Jun 04 13:23:27 so frustrating Jun 04 13:24:09 how are you supposed to guess if tras like this exist Jun 04 13:24:16 how are you supposed to guess if traps like this exist Jun 04 13:24:23 true could be false Jun 04 13:24:27 1 could be 0 Jun 04 13:24:29 you cant work like this Jun 04 13:24:49 this is a complete disaster Jun 04 13:25:51 I cannot decompile the dam electrons every time I want to make something work slightly different Jun 04 13:26:10 that has got to be the most stuped syntax I have ever seen Jun 04 13:28:10 pompomJuice: sounds like you need a testcase. Jun 04 13:28:58 for that I need money Jun 04 13:29:07 nobody has money to do test driven development Jun 04 13:29:14 except the americans Jun 04 13:29:26 but they mmilk the rest of the work, that is the only reason Jun 04 13:29:34 but they mmilk the rest of the world, that is the only reason Jun 04 13:29:36 so there's enough money to implement obfuscation, but not enough to test that it actually works? Jun 04 13:29:46 but that is my point Jun 04 13:30:04 the code looked like this: Jun 04 13:30:07 pompomJuice: it's likely been that way since it existed - I'm sorry if that's caused you problems; the best we can do is to fix it so it does match with expectations Jun 04 13:30:08 ## Uncomment this to disable obfuscation during debugging Jun 04 13:30:08 do_obfuscation[noexec] = "1" Jun 04 13:30:25 logix would dictate that setting that var to = "0" would cancel Jun 04 13:30:36 but no Jun 04 13:30:43 you have to decompile the electrons Jun 04 13:30:49 and get back to basics Jun 04 13:30:54 before you could modify that line Jun 04 13:31:42 the way the code currently works, you have to not set it in the first place, to be clear Jun 04 13:31:50 do_obfuscation[noexec] = '${@base_conditional("DISTRO_TYPE", "release", None, "1", d)}' Jun 04 13:31:53 would that work? Jun 04 13:31:56 No Jun 04 13:32:05 I want it conditional Jun 04 13:32:10 can you ahve those conditional? Jun 04 13:32:14 no, I've just explained that that won't work - you are still setting the flag, you are just setting it to "" Jun 04 13:32:22 then write an anoymous python snippet that uses setVarFlag to set it Jun 04 13:32:25 None is python's null? Jun 04 13:32:28 and yes, I also explained how to work around it Jun 04 13:32:44 i.e. use setVarFlag from anonymous python Jun 04 13:32:46 I suck at python Jun 04 13:32:54 I have no idea how to code in it Jun 04 13:33:13 while I have no idea to code in it... the community will invent 5 other scripting languages that I must learn Jun 04 13:33:16 I am furios Jun 04 13:33:17 well, then you should probably learn it. Jun 04 13:33:30 uugh Jun 04 13:33:39 I cannot believe what happened here Jun 04 13:34:18 in meta/recipes-core/images/build-appliance-image_*.bb there is an example where we do the reverse, i.e. we use delVarFlag to remove the flag, so that is also possible Jun 04 13:34:41 thanks Jun 04 13:34:44 let me go look at that Jun 04 14:13:06 I'v got a ptyhion recipe that is installing like this Jun 04 14:13:09 root@ettus-e300:~# ls /usr/lib/python2.7/site-packages/bitarray-0.8.1-py2.7-linux-x86_64.egg/bitarray/ Jun 04 14:13:26 any idea how to make it install sanely? Jun 04 14:18:31 changing from inherit distutils to setuptools solves the problem Jun 04 14:19:48 I'm still wondering if we need to have both of those classes Jun 04 14:20:49 well Jun 04 14:21:03 distutils led to fail, setuptools glorious success :) Jun 04 14:21:44 that would depend on what exactly you are building, but at least I recall someone saying one of the classes can handle both situations Jun 04 14:22:14 Crofton|work: btw, shouldn't you have named your meta-ettus sub-layers with a meta- prefix? Jun 04 14:22:22 I agree, it is very confusing Jun 04 14:22:27 arrrggghhhhhhh Jun 04 14:22:38 so f';ing meta Jun 04 14:22:42 I won't force you to, I'm just wondering why you didn't Jun 04 14:22:52 I didn't because it seemed redundant Jun 04 14:22:57 since I was already meta Jun 04 14:23:05 it's just rare to have layers showing up in the layer index without a meta- prefix Jun 04 14:23:15 or indeed, anywhere else Jun 04 14:23:30 saying meta-ettus/e300-bsp sounds so much better than meta-ettus-e100-bso Jun 04 14:23:45 I mean meta-ettus-meta-e300-bsp Jun 04 14:23:51 I mean meta-ettus/meta-e300-bsp Jun 04 14:23:57 it's what everyone else does ;) Jun 04 14:24:31 I still wonder why I did each product in a layer Jun 04 14:24:41 but I think I'll leve it this weay Jun 04 14:24:49 sure Jun 04 14:24:55 since the e100 layer makes a kernel that will not boot Jun 04 14:25:21 I've just approved the additional layer index entry in any case... would have done it this morning but the layer index was down, Michael has since fixed it Jun 04 14:25:22 yes, wehn I started sorting out what the layer index has, I lrealized I was starting to look like a radical Jun 04 14:25:28 thanks Jun 04 14:25:42 the old entry pointed at my github which wasn't updated Jun 04 14:25:45 and some fond it :) Jun 04 14:25:50 found Jun 04 14:26:00 btw anyone done a recipe for scipy? Jun 04 14:26:42 Crofton|work: I believe one of my colleagues is writing one if not right now then pretty soon Jun 04 14:27:11 I'm trying to see if the flowgraph really needs it, but it would be nice to have anyway Jun 04 14:27:23 I'll find out what his ETA is Jun 04 14:27:28 thanks Jun 04 14:27:42 I'm trying to figure out what it is doing Jun 04 14:27:58 taking something done for a PC and looking at gettin g it running on an e310 Jun 04 14:29:41 hmm, now those two entries sort at the top Jun 04 14:30:32 I feel worst about that Jun 04 14:31:24 I swear, I wasn't trying to get listsed hi Jun 04 14:31:33 why no machines for the e300 layer? Jun 04 14:32:24 hasn't been parsed yet Jun 04 14:32:38 parsing happens on a cron job every 3 hours Jun 04 14:32:57 one day someone will implement job scheduling so we can do it from the frontend Jun 04 14:33:04 no problem Jun 04 14:33:08 I figured it was thta Jun 04 14:55:22 can someone let me know if I'm understanding this process correctly? Sorry for the wall of text. Jun 04 14:55:22 When bitbake is about to run a task, it generates a checksum based off the task's inputs. These are bitbake variables, functions defined for that task, etc. The checksum is stored as a stamp file in the stamp directory. If a stamp file already exists with a matching checksum, and the file's timestamp isn't too old, then the task doesn't need to be rerun at all. If there isn't a matching stamp file or it is too old, the task is rerun. Jun 04 14:55:22 Certain tasks have corresponding _setscene tasks, which make use of sstate cache. If there is a _setscene version of the task, it is run before the main task. By default, these tasks calculate an sstate based off the name of the task, directories used by the task, etc. Bitbake then attempts to retrive an archive file with the sstate in its name. If the archive exists, it is unpacked and used as the results of the task, instead of having to recompile and generat Jun 04 14:57:24 consmith: that sounds correct, except the timestamp on the stamp file isn't a factor in the process Jun 04 14:57:51 it's all about the signature value which is computed from the task inputs (i.e. variable dependencies) Jun 04 14:58:53 and also, task signatures are all computed right at the start of the build rather than just before execution, otherwise the system wouldn't know whether it was correct to extract the output from sstate or actually execute the task Jun 04 14:59:49 interesting. do you know why the bitbake manual states that "As each task completes, a timestamp is written to the directory specified by the STAMP variable. On subsequent runs, BitBake looks in the build directory within tmp/stampsand does not rerun tasks that are already completed unless a timestamp is found to be invalid" then? Jun 04 15:00:17 how does it make a difference if the signatures are computed at the start or immediately before execution? I don't follow that part Jun 04 15:01:55 bluelightning, yeah, I could use an eta for scipy :) Jun 04 15:05:52 Crofton|work: I haven't talked with Alejandro yet but based on some notes I just found, it has a bunch of dependencies itself that need recipes, so I would imagine it'll take some time Jun 04 15:06:08 what depends? Jun 04 15:06:40 "lapack, blas, and atlas" according to this Jun 04 15:07:04 let me wack about Jun 04 15:07:11 won't build without them even though their wiki says it should, apparently Jun 04 15:07:15 unless I get distracted by real work Jun 04 15:30:36 bluelightning: the glossary entry for BB_STAMP_POLICY also references timestamp comparisons Jun 04 15:59:24 consmith: ok, that's news to me - looks like it's legacy functionality based on the accompanying note "Stamp policies are largely obsolete with the introduction of setscene tasks. " Jun 04 16:01:39 I see. thanks! so why do all the signatures need to be generated at the beginning? Jun 04 16:02:46 consmith: well, a task's signature of course depends on the signatures of all of the tasks it has dependencies upon Jun 04 16:03:34 consmith: plus, in order to determine whether we can fetch and extract the output of the task from sstate or not we need to calculate the signature first Jun 04 16:07:11 bluelightning: that makes sense, and I see in the source that it's done that way, but I'm just curious if there's a reason signatures couldn't be generated on demand individually as tasks are prepared to run. in other words, does the whole set of signatures need to be available before a single task can run, or could a task generate its signature (and those of its dependencies) before it runs Jun 04 16:09:06 consmith: we would have to integrate the setscene and normal runqueues for that to work Jun 04 16:09:50 consmith: plus we have the ability for setscene tasks to "cover" a task's dependent tasks in addition to the task itself Jun 04 16:10:39 I don't know if that fully explains it, there may be other considerations - RP may be able to elucidate further Jun 04 16:11:17 bluelightning: oh, so all of the setscene tasks run before any normal tasks are run, and at least one reason for that is because setscene tasks could potentially "cover" other tasks? Jun 04 16:11:41 yes Jun 04 16:12:04 fantastic. thanks for explaining that to me Jun 04 16:12:10 np Jun 04 16:12:20 that is exactly it. If we can pull all the ipks for example, we don't need the compiler or package tools Jun 04 16:13:17 that makes sense Jun 04 16:56:52 atlas is depressing Jun 04 16:59:50 atlas shrugged? Jun 04 16:59:53 ;) Jun 04 17:00:18 sorry, that probably isn't helpful Jun 04 17:04:11 https://www.youtube.com/watch?v=xxcLNHasPx4 <= more helpful that ayn rand Jun 04 17:24:12 look slike handwritten configure Jun 04 19:02:14 are stamp files used on both setscene and normal tasks? **** ENDING LOGGING AT Fri Jun 05 02:59:59 2015