6087 2014-04-01 09:43:26 +0000 Incorrect number of packages built in image dashboard (for clean builds only) 2014-04-11 05:35:44 +0000 1 1 7 Build System, Metadata & Runtime Toaster toaster unspecified x86 Multiple VERIFIED FIXED 09 April 2014: Set documentation flag to "No." Medium normal 1.6 M5 1 belen.barros.pena farrell.wymore alexandru.damian belen.barros.pena cristiana.voicu david.reyna jessica.zhang srifenbark Yuan.Sun2 --- --- No (bug/feature does not impact docs) oldest_to_newest 42015 0 belen.barros.pena 2014-04-01 09:43:26 +0000 I am seeing a mismatch between the number of packages built reported in the build dashboard and the number of entries in the build packages table, but only in clean builds. I am wondering if this is related to the package entries with size -1 (i.e. the entries collected only for dependency reporting purposes). Are they being counted in the number of packages built in the build dashboard? 42054 1 farrell.wymore 2014-04-01 16:20:28 +0000 These numbers do indeed appear to be inconsistent but i'm not sure where the problem is. Here is a summary: 1) On the dashboard page, 'Packages included' is exactly the number of rows in the target_installed_packages table for a single target. In my example, this number is 29. 2) Again on the dashboard page, 'Packages built' is exactly the number or rows in the package table for a single build. In my example, this number is 6146. 3) The Packages page for this build indicates 3686 packages in my example. Looking at the package table in the database, there are 2460 packages with no installed_name, size is -1, installed_size of 0, no version, no license, no description. These entries do have names and ids. So its clear where the package page (paginator) is getting it's number: 6146 - 2460 = 3686; by ignoring the anomalous package entries. So the question is: should the computation of 'Packages built' not include these anomalous package entries? Should the package page (paginator) include the anomalous entries? Or, should the anomalous entries be in the db at all? 42056 2 belen.barros.pena 2014-04-01 16:43:25 +0000 (In reply to comment #1) > These numbers do indeed appear to be inconsistent but i'm not sure where the > problem is. Here is a summary: > > 1) On the dashboard page, 'Packages included' is exactly the number of rows > in the target_installed_packages table for a single target. In my example, > this number is 29. > 2) Again on the dashboard page, 'Packages built' is exactly the number or > rows in the package table for a single build. In my example, this number is > 6146. > 3) The Packages page for this build indicates 3686 packages in my example. > > Looking at the package table in the database, there are 2460 packages with > no installed_name, size is -1, installed_size of 0, no version, no license, > no description. These entries do have names and ids. So its clear where the > package page (paginator) is getting it's number: 6146 - 2460 = 3686; by > ignoring the anomalous package entries. > > So the question is: should the computation of 'Packages built' not include > these anomalous package entries? The answer is no, the 'Packages built' computation should not include the anomalous package entries. The anomalous package entries correspond to packages that are not built: the entries exist only in order to be able to provide the full dependency chain. Without them, the dependency information in Toaster would be incomplete. Should the package page (paginator) include > the anomalous entries? No, same reason as above. > Or, should the anomalous entries be in the db at all? Yes, we do need them: without them, we would have incomplete dependency information. Although we might argue if the packages table is the right place to store them, but that's a different issue :) The number of packages built in the image dashboard has to be calculated in the same way as in the built packages table (i.e. excluding packages not built recorded only for dependency information purposes). I hope this explains 42411 3 david.reyna 2014-04-09 04:15:33 +0000 commit 10297261219d4373843b31e8aaaed094fcbcf605 42447 4 srifenbark 2014-04-09 13:21:58 +0000 This bug had no impact to docs. Setting to "No." Scott 42587 5 Yuan.Sun2 2014-04-11 05:35:44 +0000 Verified in 046a9ea30356daf4f3f8f4ddfc5b57fcfd85a27f.