If I go to http://recipes.yoctoproject.org/rrs/recipes/1.9/All/ and search for libsoup I see that libsoup is at version 2.46.0. However, clicking on the libsoup link takes you to http://recipes.yoctoproject.org/rrs/recipedetail/858/ which shows 2.46.0 at the top but also shows a 2.46.0 to 2.50.0 commit on April 27th.
There's also suspicious rise in "unknown" upstream versions. According to the page header Yocto 1.9 has almost 100 unknown recipes more than 1.8. libsoup is a good example: the 1.8 recipe list shows upstream version 2.50.0 but the current (1.9 M1) does not list a upstream version for libsoup.
I noticed a pattern. Last week a lot of my packages were correctly saying there's upgrades due. They were merged, and now the report is listing the *old* version and "unknown" state. For example, libx11 was telling me last week it was at 1.6.2 and I should upgrade to 1.6.3. Now that upgrade has been merged and the report still says 1.6.2, unknown status.
I solved the issue was related to PgSQL DB transaction abort due to field length exceeded.
I'm still seeing this for tzdata and tzcode. Summary reports they are at 2015a, details say they are at 2015e.
Another instance is http://recipes.yoctoproject.org/rrs/recipedetail/991/ where summary says current version 1.03ii (which is a git tag in the upstream repo?!), but detail says 1.1.
Same issue here http://recipes.yoctoproject.org/rrs/recipedetail/1000/
And also speex: http://recipes.yoctoproject.org/rrs/recipedetail/749/ Seems like the packages suffering from this are only those with alphabetic characters in the version (but not all of them).
This was REOPENED
Created attachment 2932 [details] screenshot with openssh example Here's another example: openssh was just updated from 7.1p1 to 7.1p2, and the summary page is very confused.
Recipes summary page in the meantime says openssh is at 7.1p1 (incorrect) and up-to-date (correct).
Another example - acpid shows as "Not updated" at http://recipes.yoctoproject.org/rrs/recipes/2.1/M2/ however clicking through to http://recipes.yoctoproject.org/rrs/recipedetail/1/ shows its status as "Up-to-date".
Paul, that is for an old milestone (M2), if you switch over to the newest milestone (M3), then it will be correct. Generally, I have no idea why that milestone picker is there, and what it is supposed to do, and it doesn't seem to even work anyway. I'm only interested in recipe situation right now, not any kind of historical statistics, and that kind of works, but is not totally robust either.
Agreed with Alex FWIW. Historical data isn't that useful and is confusing. I suspect that's where a lot of the mismatches come from - the main UI showing a milestone that had just passed whereas the details page shows the current state.
M2 is the milestone that it picked for me, in which case is it picking the wrong milestone for the current date?
(In reply to comment #14) > M2 is the milestone that it picked for me, in which case is it picking the > wrong milestone for the current date? I fixed the cause of this behavior was a wrong assumption of me. The patch are now in the ML [1], i'll continue this week to fix all the errors in the RRS. [1] https://lists.yoctoproject.org/pipermail/yocto/2016-March/029201.html
All the issues minus sgmlspl-native, cdrtools-native and openssh, was due to a bad date picker in the rrs page, i fixed the date picker now works. Also i fixed the openssh problem, i'll review the sgmlspl-native and cdrtools-native like Alexander said is due to a wrong version comparison.
I'm still seeing mismatches, e.g. tzdata reports 2016a in the summary, 2016a in the details. And source URI in the details points to 2015e!
(In reply to comment #17) > I'm still seeing mismatches, e.g. tzdata reports 2016a in the summary, 2016a > in the details. And source URI in the details points to 2015e! Read that as '2016c in the details'
I fixed all the issues i found related to the versions mismatch now the web should be in a correct state. Some of this issues are related of some parsing errors using tinfoil, more investigation is needed in this area.