**** BEGIN LOGGING AT Tue Apr 12 02:59:58 2016 Apr 12 10:05:10 I have a very strange behaviour in relation to prserv Apr 12 10:05:15 imho its a bug, but I am not sure Apr 12 10:05:25 I summarized it here Apr 12 10:05:29 https://pastebin.mozilla.org/8867448 Apr 12 10:06:12 I thought prserv is supposed to always increment the revision in order to have an updatable system Apr 12 10:06:41 but I have a situation where the revision goes back.. like it would remember some state and return to it Apr 12 10:06:45 is this a bug? Apr 12 10:56:24 Jin^eLD: mixing sstate archives? Apr 12 10:58:35 it is a multimachine build... Apr 12 10:58:50 and hmm, when testing I was building only one machine Apr 12 10:59:02 I guess that was the problem? Apr 12 10:59:54 well, pr info gets encoded into the sstate Apr 12 11:00:03 that's the only time I've seen prserv going backwards Apr 12 11:00:14 when using sstate from a 'different' build Apr 12 11:01:16 let me retest by building all of the machines.. Apr 12 11:08:14 that did not help Apr 12 11:08:20 its a machine arch package Apr 12 11:08:43 I change conf for machine A, it gets bumped, machine B stays t 2.0 Apr 12 11:09:03 but i build both configs including package-index in the end Apr 12 11:09:13 then i change config of machine A back to how it was Apr 12 11:09:20 and PR will jump back to 2.0 Apr 12 11:18:46 question regarding devtool Apr 12 11:19:10 is it possible to define what exact bbappend is affected if I use modify-recipe? right now I can only specify the layer Apr 12 11:19:32 but a bbappend already exists, so it would be great if devtool modified that one. instead, it creates a new one, because it deduces a different file path Apr 12 11:19:49 err, update-recipe, not modify-recipe Apr 12 12:58:39 hello Apr 12 13:03:04 ~ugt Apr 12 13:03:05 it has been said that ugt is Universal Greeting Time. Created in #mipslinux, it is a rule that states that whenever somebody enters an IRC channel it is always morning, and it is always late when the person leaves. The local time of any other people in the channel, including the greeter, is irrelevant. http://www.total-knowledge.com/~ilya/mips/ugt.html Apr 12 18:15:36 JaMa: python-matplotlib built for me on qemux86_64... maybe recent changes fixed the do_compile glitch? Apr 12 19:38:34 kergoth: should git fetch be using git repo tarball from premirrors if configured ? Apr 12 19:38:47 kergoth: or will it always go to upstream git repo for getting it Apr 12 19:38:53 even first time Apr 12 19:39:02 premirrors works fine with mirror tarballs Apr 12 19:39:08 hmmm Apr 12 19:39:15 kergoth: somehow its not going there Apr 12 19:39:24 its finding it Apr 12 19:39:29 but not deciding to use it Apr 12 19:39:38 how can that be Apr 12 19:41:13 that shouldn't even be possible. if it successfully downloads the mirror tarball, and it's in DL_DIR, then it'll unpack it and use that as the git repo. it might still need to contact the remote git repository to update it, if the tarball is out of date, though Apr 12 19:42:09 its not getting to DL_DIR Apr 12 19:42:21 but fetch logs show that its able to access it Apr 12 19:42:29 and wget outside bb works ok too Apr 12 19:42:31 on same box Apr 12 19:42:43 Crofton|work: did you get around to look at devtools vs oe issue? Apr 12 19:43:47 denix: which revision of meta-ti works with jethro ? master/head ? Apr 12 19:44:17 khem: might try a test case of putting the premirror url to the git tarball as SRC_URI in a recipe, see what it does fetching it directly, maybe it'll give more useufl info? Apr 12 19:44:26 then it'd error rather than just falling back to a real fetch Apr 12 19:45:07 khem: did you do theBB_GENERATE_MIRROR_TARBALLS = "1" ? Apr 12 19:45:19 my site.conf looks like: Apr 12 19:45:24 BB_GENERATE_MIRROR_TARBALLS = "1" Apr 12 19:45:24 DL_DIR = "/home/dl9pf/.yocto/shared_downloads" Apr 12 19:45:42 then I move that over to webhost and set the premirror up like: Apr 12 19:46:00 PREMIRRORS = "\ Apr 12 19:46:00 git://.*/.* http://192.168.2.100/downloads/ \n \ Apr 12 19:46:00 ftp://.*/.* http://192.168.2.100/downloads/ \n \ Apr 12 19:46:00 http://.*/.* http://192.168.2.100/downloads/ \n \ Apr 12 19:46:00 https://.*/.* http://192.168.2.100/downloads/ \n\ Apr 12 19:46:01 " Apr 12 19:49:53 fischerm, one built Apr 12 19:49:59 name wasn't annoying Apr 12 19:55:58 dl9pf: do we need BB_GENERATE_MIRROR_TARBALLS = '11 Apr 12 19:56:02 BB_GENERATE_MIRROR_TARBALLS = "1" Apr 12 19:56:31 khem: yes. premirror only works on 'tarballs' . it does not recognize git *trees* Apr 12 19:56:45 so those mirror tarballs will be tarred git trees Apr 12 19:57:09 otherwise you will only premirror the tarballs but not the gits Apr 12 19:58:04 so you need to do a fresh build with BB_GENERATE_MIRROR_TARBALLS = "1" to generate the necessary git2.foo.bar.*.tar.bz2's Apr 12 19:58:16 isnt that just for generating the tars Apr 12 19:58:23 is it required for using it too ? Apr 12 19:58:37 not required for using it iirc Apr 12 19:58:46 bluelightning, awake? Apr 12 19:59:00 i just tend to keep it on and sync my dl_dir with the premirror once in a while Apr 12 20:00:06 Crofton|work: I am yes Apr 12 20:00:08 morning all Apr 12 20:00:28 dl9pf: so I am just using it Apr 12 20:00:31 its being generated Apr 12 20:00:39 already by a server Apr 12 20:01:05 yep Apr 12 20:01:35 iirc there is one glitch ... recipes using autorev won't be happy with the tarballs. Apr 12 20:01:40 installed an extensible sdk and failed, had to ook in log for perl module fail, restarting install fixes it? Apr 12 20:02:05 khem: what you could do is to do a PREMIRRORONLY fetch ... what was the name again ... Apr 12 20:02:26 BB_FETCH_PREMIRROR_ONLY Apr 12 20:02:40 hmm Apr 12 20:06:56 bluelightning, Required perl module(s) not found: Text::ParseWords Thread::Queue Data::Dump Apr 12 20:06:56 er Apr 12 20:07:01 while installing sdk-ext Apr 12 20:07:22 they are installed on machine I am installing sdk Apr 12 20:07:45 Crofton|work: that's odd... which distro? Apr 12 20:07:54 Fedora Apr 12 20:08:00 version? Apr 12 20:08:05 23 Apr 12 20:08:20 ok... I guess I will try to reproduce that here then Apr 12 20:08:30 regualr sdks are fine Apr 12 20:11:18 * Crofton|work stagger off to fool with a nwer repo Apr 12 20:12:30 regular SDKs don't have that check ;) Apr 12 20:15:15 ah Apr 12 20:15:21 yum says they are installed Apr 12 20:15:24 er dnf Apr 12 20:15:28 need to be modern Apr 12 20:15:58 I do not have /usr/lib/perl Apr 12 20:22:12 Crofton|work: erm... how do you have those modules installed and not have perl? Apr 12 20:22:23 I have perl Apr 12 20:22:41 Crofton|work: those are all of the modules we check for, so I would suspect the problem is it's unable to run perl for some reason Apr 12 20:23:15 [balister@thuvia ~]$ which perl Apr 12 20:23:15 /usr/bin/perl Apr 12 20:24:02 I have /usr/share/perl5 Apr 12 20:24:25 sdk install says: Can't locate Text/ParseWords.pm in @INC (you may need to install the Text::ParseWords module) (@INC contains: //usr/lib/perl/site_perl/5.22.1 //usr/lib/perl/vendor_perl/5.22.1 //usr/lib/perl/5.22.1 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/site_perl/5.22.1/ /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/site_perl/5.22.1 /usr/local/oecore-x86_64/sysroots/x86_64-oesd Apr 12 20:24:25 k-linux/usr/lib/perl/vendor_perl/5.22.1/ /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/vendor_perl/5.22.1 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/5.22.1/ /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/5.22.1 /usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/lib/perl/5.22.1 .) at -e line 1. Apr 12 20:36:01 bluelightning, I suspect they work on my machine, but something screws up the test in the sdk Apr 12 20:38:36 * armpit hmm SRCREV does not like spaces Apr 12 20:38:57 how can you get spaces in a rev? Apr 12 20:39:32 after the hash via cut&past Apr 12 20:40:07 and before the last " Apr 12 20:45:22 Crofton|work: they always build ... they just don't work Apr 12 20:45:34 define not work Apr 12 20:46:05 Crofton|work: some paths are not replaced so you get runtime link errors Apr 12 20:46:11 Crofton|work: on dev machine Apr 12 20:46:22 Crofton|work: just try if you can run devtool Apr 12 20:46:27 well, mine will not install Apr 12 20:46:36 ok, that looks similar Apr 12 20:46:44 mine installed and then didn't work Apr 12 20:47:04 I'll need to go to New Zealand and work with bluelightning in person Apr 12 20:47:41 Crofton|work: your cat may not approve that expense ;) Apr 12 20:48:03 true Apr 12 20:48:39 is this master or jethro btw? Apr 12 20:49:02 jethro's eSDK does have quite a number of bugs that I haven't got around to backporting fixes for Apr 12 20:49:58 bluelightning: master Apr 12 20:50:37 master here Apr 12 20:51:01 ok, that's a good start at least Apr 12 20:54:52 was the eSDK built on the same machine or another? Apr 12 20:56:56 mine was built on smae Apr 12 21:00:20 hey, is there a way to mask a .bbappend (e.g. if there is no .bb) ? Apr 12 21:00:53 basically tell bitbake to ignore a foo%.bbappend through entry in, lets say local.conf Apr 12 21:03:02 is that BBMASK ? Apr 12 21:03:17 that would be one way Apr 12 21:03:26 alternatively you could set BB_DANGLINGAPPENDS_WARNONLY = "1" Apr 12 21:03:57 bluelightning: ah, cool Apr 12 21:04:04 will try that Apr 12 21:35:54 Crofton|work: same here Apr 12 21:35:57 bluelightning: ^^^ Apr 12 21:36:39 fuck, finally brute force disabled Qt5 check on thrift and have recipe that should survive jama Apr 12 22:08:22 bluelightning, any chance you can point me at the perl checks so I can look them over? about done for the day here Apr 12 22:08:44 Crofton|work: they're in sanity.bbclass - search for the modules it reports Apr 12 22:09:10 thinking about it it could possibly be related to the environment within the installer being cleaned Apr 12 22:12:26 this is when the sdk is installed Apr 12 22:21:28 Crofton|work: yes... SDK installation consists of the normal extraction plus running bitbake to install the sstate artifacts Apr 12 22:21:43 and the first part of that run is the normal build sanity checks in sanity.bbclass Apr 12 22:22:38 one difference with a normal run of bitbake though is that the install script cleans the environment before running anything, possibly something is excluded that affects perl Apr 12 22:37:09 anyone played with myrepo for managing a colelction of layers? Apr 12 22:51:48 Crofton|work: i've used it locally quite a bit Apr 12 22:54:59 I'm lookig to see if I can replace repo with it Apr 12 22:56:08 it'd be a fair bit less flexible, no way to lock down a repository, etc, since it basically just wraps running git commands over multiple repositories, in my experience Apr 12 22:56:34 but depending on your requirements, it'd work fine Apr 12 22:57:10 i use it for my upstream yocto builds as an alternative to mucking with submodules, since i want to do my testing with branch heads to make sure our layers are working well with them Apr 12 22:57:36 or use it in concert with submodules, just as a quicker easier way to update them and operate against them.. Apr 12 23:02:00 hmm, I want to lock revs Apr 12 23:02:05 may not help **** ENDING LOGGING AT Wed Apr 13 02:59:58 2016