9755 2016-06-10 07:13:03 +0000 buildhistory-diff contains loads of PKGR spam when used with PRSERV 2016-07-29 15:59:35 +0000 1 1 7 Build System, Metadata & Runtime OE-Core Scripts and Tools unspecified x86 Multiple RESOLVED FIXED Medium+ enhancement 2.2 M2 1 jku eduard.bartosh jose.perez.carranza ross.burton david.israelx.rodriguez.castellanos --- --- No (bug/feature does not impact docs) oldest_to_newest 62889 0 jku 2016-06-10 07:13:03 +0000 When using PR service the buildhistory-diff output contains a lot of PKGR changes: In practice the mass of PKGR updates hide other important changes as they often account for 80% of all changes. I realise PKGR changes are sometimes important but at least for my work the negatives outweigh the positives. I could use "grep -v PKGR" but this often hides the package name: packages/core2-64-poky-linux/at-spi2-core/at-spi2-core-locale-ug: PKGR changed from r0.5 to r0.4 * PV changed from "2.18.3" to "2.20.2" In this case I would not know which package got a PV change if I used grep. I propose PKGR should be hidden unless "--report-all" is used (or alternatively a new flag is added to hide PKGR changes). 62892 1 ross.burton 2016-06-10 07:53:16 +0000 It's easy to identify PR service changes as they're all of the form rX.N -> rX.N+1, so these could be filtered out globally. A change from r1 to r2 is something that should be in the diff as that's done by the recipes. 63060 2 ross.burton 2016-06-16 16:44:23 +0000 Ed wanted a bit more clarification so here we go. Usually a PR (package revision) is of the form "r0", "r1", "r3" and so on, with r0 the default. Historically when a recipe was edited the PR would be bumped from r0 to r1 to r2. Now that we've said that there are two classes of users: those that care about PRs as they have package feeds and those that don't care. The former *really* care so the PR service was created for them, this ensure that *every* rebuild of a recipe causes the PR to increase. The latter don't care at all and the PR doesn't need to change. The PR service simply adds a ".n" suffix to the existing PR, so if a recipe says PR=r2 then the first build becomes r2.0, then r2.1, r2.2 and so on. These PR bumps are meaningless as they're simply markers of a build happening. Thus, buildhistory-diff should filter out PR changes which are simply of the form rN.X -> rN.X+1, such as r1.1 to r1.2. Changes such as r1 to r2 should still be displayed. 63067 3 eduard.bartosh 2016-06-16 17:00:37 +0000 Thank you for the explanations! Should filtering out be a default or should I add new flag? I'd say it's safer to add new flag than change default behavior. Any suggestions on option name? 63080 4 ross.burton 2016-06-16 21:48:19 +0000 I'd be happy with PR service bumps filtered out always, but add an option if you prefer. 63667 5 3270 eduard.bartosh 2016-07-06 12:20:35 +0000 Created attachment 3270 fix Jussi, can you check if this patch works for you? It strips only 0.1 increments and decrements as Ross suggested. 63702 6 jku 2016-07-07 07:56:30 +0000 (In reply to comment #5) > Created attachment 3270 [details] > fix > > Jussi, can you check if this patch works for you? > > It strips only 0.1 increments and decrements as Ross suggested. This failed with Traceback (most recent call last): File "/home/jku/src/poky/scripts/buildhistory-diff", line 100, in <module> main() File "/home/jku/src/poky/scripts/buildhistory-diff", line 84, in main changes = oe.buildhistory_analysis.process_changes(options.buildhistory_dir, fromrev, torev, options.report_all, options.report_ver) File "/home/jku/src/poky/meta/lib/oe/buildhistory_analysis.py", line 392, in process_changes changes.extend(compare_dict_blobs(path, d.a_blob, d.b_blob, report_all, report_ver)) File "/home/jku/src/poky/meta/lib/oe/buildhistory_analysis.py", line 372, in compare_dict_blobs if abs(float(vera) - float(verb)) == 0.1: ValueError: could not convert string to float: '2.1.11' when processing "packages/all-poky-linux/encodings/encodings-dbg". The encodings recipe has this curious thing in it: PR = "${INC_PR}.1" 63704 7 ross.burton 2016-07-07 08:16:43 +0000 " if abs(float(vera) - float(verb)) == 0.1:" Don't expect that versions are going to be floats, and also float arithmetic like that just doesn't work: float(0.2)-float(0.1) could easily equal 0.10000000001. You'll have to split the version on dots and see if all the parts match expect the final fragment where one is an int and the other is the same int +1. 63710 8 3273 eduard.bartosh 2016-07-07 09:28:51 +0000 Created attachment 3273 fix v2 Fair enough :) How about this one? 63757 9 eduard.bartosh 2016-07-08 14:49:19 +0000 sent for review to the mailing list: http://lists.openembedded.org/pipermail/openembedded-core/2016-July/123654.html 64264 10 eduard.bartosh 2016-07-21 14:53:51 +0000 implementation has been merged into oe-core master. 3270 2016-07-06 12:20:35 +0000 2016-07-07 09:28:51 +0000 fix file_9755.txt text/plain 797 eduard.bartosh ZGlmZiAtLWdpdCBhL21ldGEvbGliL29lL2J1aWxkaGlzdG9yeV9hbmFseXNpcy5weSBiL21ldGEv bGliL29lL2J1aWxkaGlzdG9yeV9hbmFseXNpcy5weQ0KaW5kZXggNDM1MzM4MS4uOTY1ZTAwNSAx MDA2NDQNCi0tLSBhL21ldGEvbGliL29lL2J1aWxkaGlzdG9yeV9hbmFseXNpcy5weQ0KKysrIGIv bWV0YS9saWIvb2UvYnVpbGRoaXN0b3J5X2FuYWx5c2lzLnB5DQpAQCAtMzU5LDYgKzM1OSwxMyBA QCBkZWYgY29tcGFyZV9kaWN0X2Jsb2JzKHBhdGgsIGFibG9iLCBiYmxvYiwgcmVwb3J0X2FsbCwg cmVwb3J0X3Zlcik6DQogICAgICAgICAgICAgICAgIGlmICcgJy5qb2luKGFsaXN0KSA9PSAnICcu am9pbihibGlzdCk6DQogICAgICAgICAgICAgICAgICAgICBjb250aW51ZQ0KIA0KKyAgICAgICAg ICAgIGlmIGtleSA9PSAnUEtHUicgYW5kIG5vdCByZXBvcnRfYWxsOg0KKyAgICAgICAgICAgICAg ICAjIHNraXAgaW5jcmVtZW50YWwgUEtHUiByZWNvcmRzDQorICAgICAgICAgICAgICAgIHZlcmEg PSBhc3RyLnNwbGl0KClbMF1bMTpdDQorICAgICAgICAgICAgICAgIHZlcmIgPSBic3RyLnNwbGl0 KClbMF1bMTpdDQorICAgICAgICAgICAgICAgIGlmIGFicyhmbG9hdCh2ZXJhKSAtIGZsb2F0KHZl cmIpKSA9PSAwLjE6DQorICAgICAgICAgICAgICAgICAgICBjb250aW51ZQ0KKw0KICAgICAgICAg ICAgIGNoZyA9IENoYW5nZVJlY29yZChwYXRoLCBrZXksIGFzdHIsIGJzdHIsIG1vbml0b3JlZCkN CiAgICAgICAgICAgICBjaGFuZ2VzLmFwcGVuZChjaGcpDQogICAgIHJldHVybiBjaGFuZ2VzDQo= 3273 2016-07-07 09:28:51 +0000 2016-07-07 09:28:51 +0000 fix v2 file_9755.txt text/plain 1172 eduard.bartosh ZGlmZiAtLWdpdCBhL21ldGEvbGliL29lL2J1aWxkaGlzdG9yeV9hbmFseXNpcy5weSBiL21ldGEv bGliL29lL2J1aWxkaGlzdG9yeV9hbmFseXNpcy5weQ0KaW5kZXggNDM1MzM4MS4uYjZjMDI2NSAx MDA2NDQNCi0tLSBhL21ldGEvbGliL29lL2J1aWxkaGlzdG9yeV9hbmFseXNpcy5weQ0KKysrIGIv bWV0YS9saWIvb2UvYnVpbGRoaXN0b3J5X2FuYWx5c2lzLnB5DQpAQCAtMzU5LDYgKzM1OSwyNCBA QCBkZWYgY29tcGFyZV9kaWN0X2Jsb2JzKHBhdGgsIGFibG9iLCBiYmxvYiwgcmVwb3J0X2FsbCwg cmVwb3J0X3Zlcik6DQogICAgICAgICAgICAgICAgIGlmICcgJy5qb2luKGFsaXN0KSA9PSAnICcu am9pbihibGlzdCk6DQogICAgICAgICAgICAgICAgICAgICBjb250aW51ZQ0KIA0KKyAgICAgICAg ICAgIGlmIGtleSA9PSAnUEtHUicgYW5kIG5vdCByZXBvcnRfYWxsOg0KKyAgICAgICAgICAgICAg ICB2ZXJzID0gW10NCisgICAgICAgICAgICAgICAgIyBzdHJpcCBsZWFkaW5nICdyJyBhbmQgZG90 cw0KKyAgICAgICAgICAgICAgICBmb3IgdmVyIGluIChhc3RyLnNwbGl0KClbMF0sIGJzdHIuc3Bs aXQoKVswXSk6DQorICAgICAgICAgICAgICAgICAgICBpZiB2ZXIuc3RhcnRzd2l0aCgncicpOg0K KyAgICAgICAgICAgICAgICAgICAgICAgIHZlciA9IHZlclsxOl0NCisgICAgICAgICAgICAgICAg ICAgIHZlcnMuYXBwZW5kKHZlci5yZXBsYWNlKCcuJywgJycpKQ0KKyAgICAgICAgICAgICAgICBt YXhsZW4gPSBtYXgobGVuKHZlcnNbMF0pLCBsZW4odmVyc1sxXSkpDQorICAgICAgICAgICAgICAg IHRyeToNCisgICAgICAgICAgICAgICAgICAgICMgcGFkIHdpdGggJzAnIGFuZCBjb252ZXJ0IHRv IGludA0KKyAgICAgICAgICAgICAgICAgICAgdmVycyA9IFtpbnQodmVyLmxqdXN0KG1heGxlbiwg JzAnKSkgZm9yIHZlciBpbiB2ZXJzXQ0KKyAgICAgICAgICAgICAgICBleGNlcHQgVmFsdWVFcnJv cjoNCisgICAgICAgICAgICAgICAgICAgIHBhc3MNCisgICAgICAgICAgICAgICAgZWxzZToNCisg ICAgICAgICAgICAgICAgICAgICAjIHNraXAgZGVjcmVtZW50cyBhbmQgaW5jcmVtZW50cw0KKyAg ICAgICAgICAgICAgICAgICAgaWYgYWJzKHZlcnNbMF0gLSB2ZXJzWzFdKSA9PSAxOg0KKyAgICAg ICAgICAgICAgICAgICAgICAgIGNvbnRpbnVlDQorDQo=