Hello, Am Donnerstag, 20. Februar 2014 schrieb Achim Gratz:
Christian Boltz writes:
If the image metadata contains the build date, I'd consider this a bug. Please open a bugreport [1] ;-) (The file's timestamp (as shipped in the tarball) is a good replacements for the build date.)
It's been some time since I looked at this. It may not have been a date but something else leaked from the build environment into the metadata, I don't remember exactly.
It would be good to know the details, even if it doesn't change much if for example the hostname of the build host leaks in instead of the timestamp ;-)
Fixing this will probably not avoid the rebuild itsself, but OBS will notice that the package is unchanged, and will throw away the just-build package instead of releasing it as a "new" version.
Yes. The comparison was done for the whole file, even though the actual image data was (and always will be) identical.
The comparison (usually) works on the file level (it can't "look" at an image to compare it). Nevertheless, there are some exceptions where some file differences are ignored. For example, LaTeX adds a random build id when creating a PDF file - IIRC this random id is ignored. In theory the comparison could be changed to compare pixels instead of bits and bytes. But it is much easier to compare on the file level, so the better solution is to ensure the next build creates the exact same files.
[1] against KDE - this is not a tumbleweed bug
Wouldn't this be an OBS bug? The build uses something like imagemagick (I'm fuzzy on those details, too) to convert from the source to several derivative formats. Then the OBS build process compares the full files, not just the image data, to find that yes, each time that conversion is done a different image was created. This is true at some level, but for all practical purposes these images should be treated as unchanged from any other build if only the metadata differs.
Well, pointing fingers sounds easy, but can be quite difficult ;-) I'd expect that ImageMagick creates the same output when you give it the same input files and parameters. If not, it would count as a ImageMagick bug. It could also be that the KDE build calls ImageMagick with a parameter that differs on every build (or it doesn't add a parameter to enforce a fixed value (for example for the timestamp) in the metadata), which would make it a KDE bug. Yes, in theory you could also call it a OBS bug - but "comparing two different files says they are different" doesn't sound too much like a bug to me ;-) so changing the comparison to ignore the metadata is the last thing I would think about (and in some cases metadata might even be important) You'll probably have to check the build log for the command that creates the always-different file, and then test (maybe locally) if this command really creates a different file each time. BTW: Been there, done that - I had to fix a similar problem in the AppArmor documentation some time ago. Regards, Christian Boltz -- Wenn du beim Autofahren ein "komisches Geraeusch" hoerst und stehen- bleibst (ohne das Geraeusch naeher identifizieren zu koennen!), dann schraubst du ja auch nicht einfach mal auf Verdacht an der Nockenwelle rum, wenn's doch nur am leeren Tank liegen koennte! [David Haller in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org