Am Saturday 18 September 2010 schrieb Vincent Untz:
Le vendredi 17 septembre 2010, à 23:03 +0200, Gerald Pfeifer a écrit :
On Mon, 30 Aug 2010, Cristian Rodríguez wrote:
Over the weekend, I did a review of this as well:
a) doxygen didnt make it easier (fixed in sr#46588) b) gtk-doc injects its current version into XML and HTML files (bnc#635376) c) massive usage of __DATE__ __TIME__ proposed alternatives in #bnc635351
d) still images, pdf's and other documents, either generated by htmldoc, dvips (etc..) set the current creation/modification date on generated docs to the build time instead of the source file's.
Thanks. Looking at the updates my test machine running FACTORY has seen over the last ten days, this is really a lot. Hopefully those initiatives of yours will help cut this down!
20100909: 725 packages to upgrade, 26 new, 3 to remove, 3 to change arch. Overall download size: 767.3 MiB. After the operation, additional 15.5 MiB will be used.
20100913: 1225 packages to upgrade, 4 new, 1 to change arch. Overall download size: 1009.8 MiB. After the operation, additional 17.6 MiB will be used.
20100917: 709 packages to upgrade, 7 new, 1 to change arch. Overall download size: 589.6 MiB. After the operation, additional 4.6 MiB will be used.
Is there any way we can automatically extract the build-compare output (which is at the end of the build logs), and have some place where we could look at that for packages that haven't changed during rebuilds?
The build-compare output in its current form is pointless as you only see the first file in the first rpm that's different. That very often a changed buildid in a random binary - that won't help you fix the problem, because if the debuginfo is different, the buildid has to change. The real question then is, why is the debuginfo different. And very often it's a strange string containg the date or host. I don't think we should harm so many build processes to save another 100 MB, but we should concentrate on getting factory deltas working. This would still mean 1225 packages to upgrade, but the download size would be around 50MB (and it would eat up more CPU). Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org