<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-05-12 17:40 GMT+02:00 Daniel Hoffend <span dir="ltr"><<a href="mailto:dh@dotlan.net" target="_blank">dh@dotlan.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've the strong feeling that this is not the right approach.</blockquote><div><br>Well, it's a dirty hack at best but it solves the problem.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> My guess is that dpkg-source is doing some kind of strange magic to ensure the "php textfile" is in the right format or ends with a newline whatever.<br></blockquote><div><br></div><div>There's also the [   59s] running debian transformer... step in <a href="https://obs.kolabsys.com/package/live_build_log/home:timotheus:branches:Kolab:Development/composer/Debian_8.0/i586">https://obs.kolabsys.com/package/live_build_log/home:timotheus:branches:Kolab:Development/composer/Debian_8.0/i586</a> build log . I think this is also where the newline might get added, but perhaps you're right and OBS (ab?)use of dpkg-source is the reason.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Here's a hexdump before and during build:<br>
<br>
# before<br>
<br>
-rw-r--r-- 1 griffon griffon 1029319 May  7 10:24 composer.phar<br>
<br>
$ hexdump composer.phar | tail -n 3<br>
00fb4b0 2ede 808f bce5 30a8 9e1d b3ff 3c76 0285<br>
00fb4c0 0000 4700 4d42 0042<br>
00fb4c7<br>
<br>
# during build<br>
<br>
-rw-r--r--. 1 root root 1029320 May 12 15:12 composer.phar<br>
<br>
$ hexdump debian/composer.phar | tail -n 3<br>
00fb4b0 2ede 808f bce5 30a8 9e1d b3ff 3c76 0285<br>
00fb4c0 0000 4700 4d42 0a42<br>
00fb4c8<br>
<br>
<br>
So yes, the filesize seems to be 2 byte off, but also the last 2 bytes are different 0042 vs 0a42.</blockquote><div><br>The file is one byte off, the linefeed aka newline byte (0a) is inserted at the end of the file. hexdump displays 0042 for formatting reasons, but in fact 42 is the last byte in the original file. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Something is odd tbh. So removing one byte seems to be okay to get the filesize right but still the file has changed.<br></blockquote><div><br></div><div>Well, the md5 checksums match, so the file is almost certainly the same or we are extremely unlucky and ran into md5 collision.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What wonders me is the fact that composer.phar is listed in debian/source/include-binaries and therefore shouldn't be touched when dpkg-source is extracting the debian package. But it seems that dpkg-source is modifing the cause it things it's a textfile and ensure the newlines are correct (especially the last).<br></blockquote><div><br></div><div>I don't think that the file is modified in any other way than the added newline at the end because of the matching md5 sums. Also the Ubuntu package is propably biult right when using Ubuntu toolchain (where the package source originates from) and it is safe to assume that the newline doesn't get added then. Therefore I would suspect OBS magic.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Maybe we can find the right way to get this composer package done right in this obs mix.<br></blockquote><div><br>Perhaps, I guess it would help a lot if we could get the source package generated by OBS and inspect it, or add verbosity to the OBS steps. Does anyone know how to do that?<br><br></div><div>Regards,<br><br><br></div><div>Mateusz.<br></div></div></div></div>