**** BEGIN LOGGING AT Sat Mar 29 03:00:00 2014 Mar 29 10:47:25 morning Mar 29 10:48:07 JaMa, for the sstate-cache patch series, should I reply on the mailing list, "Tested-By:" or something like that ? Mar 29 10:54:30 kroon: yes you can, thanks Mar 29 11:11:40 I need help Mar 29 11:11:55 PREFERRED_VERSION_systemd = "204" Mar 29 11:12:06 in the latest move to yocto 1.5 on angstrom Mar 29 11:12:20 my image now suddenly contains a 208 systemd Mar 29 11:12:35 it should take my systemd_204 like before? Mar 29 11:14:51 ls there recipe with version 204 in any layer you have? Mar 29 11:15:11 no Mar 29 11:15:19 I had to copy a recipy and make it manually Mar 29 11:15:28 the reason for that is I am stuck on kernel < 3.0 Mar 29 11:15:45 and systemd started requiring 3.0 for some cgroup business Mar 29 11:16:00 So I have my own meta folder Mar 29 11:16:02 inside Mar 29 11:16:31 The previous guy had a systemd folder with systemd_v189.bbappend files Mar 29 11:16:47 then I added a systemd_204/systemd_204.bb Mar 29 11:16:51 this used to work Mar 29 11:16:56 now with bitbake 1.20 Mar 29 11:16:57 not anymore Mar 29 11:17:21 now it's picking the 208 from oe-core Mar 29 11:17:40 the 204 was a copy of 208 Mar 29 11:18:18 seems to me that the systemd_204 directory convention went away Mar 29 11:18:27 if it's in layer with higher priority then it should work even without P_V, I'm using the same Mar 29 11:18:43 The layer has priority 15 or somrthing Mar 29 11:18:55 yea it used to work Mar 29 11:19:06 currently migrating from 1.4 to 1.5 Mar 29 11:19:08 shit backfired Mar 29 11:19:10 I'm using it in dora Mar 29 11:19:12 now I am working over the weekend Mar 29 11:19:23 ok so it is working for you Mar 29 11:19:34 is your directory included in BBFILES ? Mar 29 11:19:52 probably not Mar 29 11:19:57 how do I do that? Mar 29 11:20:02 hmm Mar 29 11:20:31 could never understand that directory extend business Mar 29 11:20:47 the rest of bitbake seems to recurse just fine Mar 29 11:21:24 let me see what happnes when I cleansstate Mar 29 11:21:34 picking the 208 Mar 29 11:21:43 and has a strange autoinc in the version nr Mar 29 11:21:47 sounds like learning something over the weekend is in place :) Mar 29 11:22:06 hehe Mar 29 11:22:17 been crash coarsing this for months now Mar 29 11:22:23 this stuff is hard Mar 29 11:22:27 and cannot be rushed Mar 29 11:22:34 boss mand does not understand that Mar 29 11:23:51 \ /home/griftw/w/danny/setup-scripts/sources/meta-ctlab/recipes/systemd_204/systemd_204.bb Mar 29 11:23:55 there it is Mar 29 11:23:55 they rarely do Mar 29 11:24:05 PREFERRED_VERSION_systemd = "204" Mar 29 11:24:43 pompomJuice: show BBFILES from layer.conf Mar 29 11:24:43 any obvious issues Mar 29 11:25:20 BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend" Mar 29 11:25:35 ok, looks sane Mar 29 11:26:05 I was asking because most layers are using recipes-* (not recipes*) Mar 29 11:26:13 aah Mar 29 11:26:21 let me see if I can actually build the recipy Mar 29 11:26:26 aah problems Mar 29 11:26:37 cant Mar 29 11:26:43 not sure if i should be Mar 29 11:26:55 bitbake systemd_204 -c cleansstate Mar 29 11:27:16 that shouldn't work Mar 29 11:27:21 aah Mar 29 11:27:27 damn Mar 29 11:27:35 dont have time for this Mar 29 11:28:02 took me 3 days to figure out that optimizations in 4.7.3 or something caused errors in memset.S in the kernel Mar 29 11:28:13 now this Mar 29 11:28:26 also another strange issue Mar 29 11:28:42 image boot bails with you need CONFIG_LBDAF Mar 29 11:29:08 cause now mkfs.ext4 is now set to large_file by default Mar 29 11:29:34 and if you actually build that in it has no effect, you still need to disable the large_file manually with args... Mar 29 11:29:53 also Mar 29 11:29:55 with 1.5 Mar 29 11:30:02 I have had strange QA errors Mar 29 11:30:11 complaining about a .5 going back to a .0 Mar 29 11:30:26 but that is not my PR Mar 29 11:30:40 what's strange on that? have you read about PRSERV? Mar 29 11:30:46 hehe Mar 29 11:30:55 strange if you are thrown into the deep end Mar 29 11:31:00 I have not Mar 29 11:32:06 * JaMa thinks that upgrades like 1.4 -> 1.5 shouldn't be done be newbies (no offence) and should be prepared ahead (and not expect to do it on Friday before weekend) Mar 29 11:32:36 that's what experienced contractors are for :) Mar 29 11:35:00 * JaMa -> lunch Mar 29 11:35:12 hehe Mar 29 11:52:03 systemd/1_208+gitAUTOINC+255eb046a7-r0 Mar 29 11:52:05 what is that? Mar 29 11:52:14 there is no autoinc going on there Mar 29 11:53:15 PV = "208+git${SRCPV}" Mar 29 11:53:35 SRCREV = "255eb046a7bcb90e60a3a54302bc1250c1aed26a" Mar 29 11:53:44 II think something broke in the git fetcher Mar 29 11:56:03 pompomJuice: AUTOINC is part of SRCPV (it was called LOCALCOUNT before) Mar 29 11:56:17 pompomJuice: it makes git SHA-1s sortable when you're using shared PRSERV Mar 29 11:56:19 ok Mar 29 11:56:41 that's the same thing which appends .${AUTOPR} to your PR values Mar 29 11:56:41 I found a file Mar 29 11:57:10 meta-anstrom/conf/distro/angstrom-v2013.12.conf Mar 29 11:57:15 it contains Mar 29 11:57:23 PREFERRED_VERSION_systemd = "208%" Mar 29 11:57:35 is this one somehow prefferred over mine in conf/local.conf? Mar 29 11:57:43 https://wiki.yoctoproject.org/wiki/PR_Service Mar 29 11:57:53 use bitbake -e to find out Mar 29 11:58:59 ok this is new Mar 29 12:03:28 yea Mar 29 12:03:36 if I run bitbake with -e Mar 29 12:03:41 it clearly shows... Mar 29 12:03:45 PREFERRED_VERSION_systemd="208% Mar 29 12:03:52 it is using that directive Mar 29 12:04:14 it also shows the history of assignment Mar 29 12:04:32 you can use another override in local.conf to change it Mar 29 12:04:41 I have one Mar 29 12:04:48 that is what stopped working Mar 29 12:04:52 used to work Mar 29 12:05:04 PREFERRED_VERSION_mono-native = "3.2.8" Mar 29 12:05:04 PREFERRED_VERSION_mono = "3.2.8" Mar 29 12:05:04 PREFERRED_VERSION_systemd = "204" Mar 29 12:05:04 PREFERRED_VERSION_sqlite = "3080401" Mar 29 12:05:04 PREFERRED_VERSION_u-boot = "2010.06-psp04.04.00.01" Mar 29 12:05:04 PREFERRED_PROVIDER_u-boot = "u-boot" Mar 29 12:05:08 that is in my local.conf Mar 29 12:05:12 mono seems to work fine Mar 29 12:05:30 I hope Mar 29 12:05:31 acctually Mar 29 12:05:37 it wont boot because of this Mar 29 12:13:50 # $PREFERRED_VERSION_systemd [2 operations] Mar 29 12:13:50 # set /home/griftw/w/danny/setup-scripts/conf/local.conf:24 Mar 29 12:13:50 # "204" Mar 29 12:13:50 # set /home/griftw/w/danny/setup-scripts/sources/meta-angstrom/conf/distro/angstrom-v2013.12.conf:110 Mar 29 12:13:50 # "208%" Mar 29 12:13:50 # computed: Mar 29 12:13:51 # "208%" Mar 29 12:13:52 PREFERRED_VERSION_systemd="208%" Mar 29 12:13:53 shit Mar 29 12:14:00 how can I tell it not to take the biggest one? Mar 29 12:14:14 save me Mar 29 12:14:36 13:04:36 < JaMa> you can use another override in local.conf to change it Mar 29 12:14:50 O'RLY? Mar 29 12:14:55 what override might this be? Mar 29 12:15:14 any override will do Mar 29 12:15:51 where is this local.conf file? Mar 29 12:15:59 in the meta-ctlab? Mar 29 12:16:04 or in setup-scripts? Mar 29 12:19:17 if I do a bitbake -s I get -> systemd 1:204-r0 1:208+gitAUTOINC+255eb046a7-r Mar 29 12:35:53 not working Mar 29 12:35:56 tis is frustrating Mar 29 12:56:46 there must be a way you can tell bitbake how to compare preferred versions if more than one is declared? Mar 29 13:00:38 ok so my only option is to nuke that value in the angstrom meta Mar 29 13:00:45 what is the correct version control precess fgor this? Mar 29 13:00:48 make a new branch? Mar 29 13:00:57 what then of oebb update? Mar 29 13:13:12 pompomJuice, just patch angstrom locally, no ? Mar 29 13:32:19 pompomJuice: it's called overrides Mar 29 13:46:48 JaMa the overrides is not working Mar 29 13:46:52 that is what I have been trying to say? Mar 29 13:47:01 I put them in there they dont work Mar 29 13:47:04 I looked at the code Mar 29 13:47:07 its pretty dumb Mar 29 13:47:11 it just takes the first value it finds Mar 29 13:47:20 since angstrom is a first in alphabet it wins Mar 29 14:35:53 was chrony deleted? Mar 29 18:38:57 I wonder, whats the reason for that a separate zlib needs to be built for the sdk, instead of using the binaries created for the target ? Mar 29 19:13:07 or maybe thats not whats happening **** ENDING LOGGING AT Sun Mar 30 02:59:59 2014