<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>54103</bug_id>
          
          <creation_ts>2004-06-16 10:59 0000</creation_ts>
          <short_desc>version bump to fix amd64 squashfs-tools-2.0</short_desc>
          <delta_ts>2004-12-18 00:34:43 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>Applications</component>
          <version>unspecified</version>
          <rep_platform>AMD64</rep_platform>
          <op_sys>All</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>3.14159@gmx.net</reporter>
          <assigned_to>embedded@gentoo.org</assigned_to>
          <cc>alpha@gentoo.org</cc>
    
    <cc>embedded@gentoo.org</cc>
    
    <cc>mips@gentoo.org</cc>
    
    <cc>phillip@lougher.demon.co.uk</cc>
    
    <cc>ppc@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>3.14159@gmx.net</who>
            <bug_when>2004-06-16 10:59:27 0000</bug_when>
            <thetext>Hi,

squashfs authors assume that an int is as wide as a pointer and mksquashfs breaks on all platforms where this isn&apos;t true.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>3.14159@gmx.net</who>
            <bug_when>2004-06-16 11:00:00 0000</bug_when>
            <thetext>Created an attachment (id=33390)
squashfs2.0-amd64.diff
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kugelfang@gentoo.org</who>
            <bug_when>2004-06-16 11:48:39 0000</bug_when>
            <thetext>Thomas: did you do that patch on your own ? Or is it tested patch from a different source ?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>3.14159@gmx.net</who>
            <bug_when>2004-06-16 11:58:48 0000</bug_when>
            <thetext>i wrote this patch myself. it works fine here.
it basically takes away the int-&gt;ptr cast and uses the integer as offset to a base pointer, so it should be safe.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kugelfang@gentoo.org</who>
            <bug_when>2004-06-19 10:43:28 0000</bug_when>
            <thetext>Honestly i don&apos;t like your patch. It&apos;s a ugly hack. Also the whole code of mksquashfs looks _very_ ugly. Casting unsigned int to pointers and back, using (unsigned int *) for the purpose of (void **). Thats not nearly 64bit clean.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>3.14159@gmx.net</who>
            <bug_when>2004-06-20 03:41:10 0000</bug_when>
            <thetext>after my patch applied gcc doesn&apos;t report any pointer to integer of different size casts any more. what would you consider a &quot;clean&quot; solution? (except for recoding the whole tool *sigh*) i did not want to modify the code, so that a long int is used instead of a int, so that a pointer would fit into it, because that would have caused larger changes, but is perhaps a cleaner solution. i would be willing to do this if you request it. using pointer-&gt;integer-&gt;pointer casts is not that evil in C if you do it right IMO.

PS: sorry for bad english, vodka is evil ;)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kugelfang@gentoo.org</who>
            <bug_when>2004-06-20 10:04:29 0000</bug_when>
            <thetext>Don&apos;t get me wrong, i appreciate your work, and it is probably an appropriate solution. I just got back, but i think i will apply the patch lateron.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>solar@gentoo.org</who>
            <bug_when>2004-06-22 10:24:12 0000</bug_when>
            <thetext>Any reason this would be a amd64 bug and not an outright 64bit bug?
Anybody run these changes by upstream?
If not Thomas Weidner could you please do so. (thanks in advance)
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>kugelfang@gentoo.org</who>
            <bug_when>2004-06-22 10:43:10 0000</bug_when>
            <thetext>Nope, no reason for amd64 only patch. Reassigning to maintainer.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>phillip@lougher.demon.co.uk</who>
            <bug_when>2004-07-03 19:12:59 0000</bug_when>
            <thetext>I&apos;m the author of mksquashfs.  I&apos;ve known about the pointer-&gt;int problem for some time (it was a piece of sloppy coding done in a hurry to implement a feature a user wanted).  There is another 64 bit bug in the program.  I didn&apos;t know that a long on 64 bit machines was 8 bytes long.  This breaks the call to the zlib compress/uncompress routines.  I&apos;ll release a new version with both bug fixes.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>3.14159@gmx.net</who>
            <bug_when>2004-07-04 03:47:37 0000</bug_when>
            <thetext>in which way? i used images created with &quot;my&quot; mksquashfs without problems</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dragonheart@gentoo.org</who>
            <bug_when>2004-09-03 16:31:41 0000</bug_when>
            <thetext>squashfs2.0-r2.tar.gz released now. Please see if it works and remind me in a week or two if I haven&apos;t commited a version bump.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>3.14159@gmx.net</who>
            <bug_when>2004-09-04 05:04:24 0000</bug_when>
            <thetext>tested it with a few kb and 1.1 GB squashfs filesystem. works fine here.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>dragonheart@gentoo.org</who>
            <bug_when>2004-09-06 22:20:08 0000</bug_when>
            <thetext>squashfs-tools-2.0_p2.ebuild added to correspond to squashfs2.0-r2.tar.gz

Arch tests - please do your best. src_test routine has been added for arch testing. The src_test routine that requires a squashfs in the kernel (or module) and FEATURES=-userpriv (needed to mount filesystems)

Phillip I added you here so you could see what architectures is does/doesn&apos;t work on.

-------------------
For 64 bit arch maintainers - suggest removing pre-alpha *64 keywords - The text below if from a file in the latest version.

Information for amd64 users
---------------------------

All previous releases of Squashfs (2.0-alpha and older) generate incorrect
filesystems on amd64 machines.  These filesystems work correctly on amd64
machines, but cannot be mounted on non-amd64 machines.  Likewise, filesystems
generated on non amd64 machines could not be mounted on amd64 machines.
This bug was caused by the different size of the &quot;time_t&quot; definition used in
SquashFS filesystem structures.

This bug is now fixed in this release.  However, all amd64 filesystems
generated by previous releases will not be mountable on amd64 machines
with this release.  If you have pre-existing amd64 generated filesystems,
it is important that you recreate the filesystem.  This can be performed
by mounting the filesystem using a kernel with the original patch
(i.e. a 2.0-alpha or older patch) and running the SquashFS 2.0
(i.e. this release) mksquashfs tool to create a new SquashFS filesystem.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gustavoz@gentoo.org</who>
            <bug_when>2004-09-07 06:44:58 0000</bug_when>
            <thetext>sparc stable, looks tasty.
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>vapier@gentoo.org</who>
            <bug_when>2004-09-23 05:31:38 0000</bug_when>
            <thetext>a bunch of arches have this stable now</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>corsair@gentoo.org</who>
            <bug_when>2004-12-18 00:34:43 0000</bug_when>
            <thetext>also stable on ppc64 since some time</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>33390</attachid>
            <date>2004-06-16 11:00 0000</date>
            <desc>squashfs2.0-amd64.diff</desc>
            <filename>squashfs2.0-amd64.diff</filename>
            <type>text/plain</type>
            <data encoding="base64">ZGlmZiAtcnUgc3F1YXNoZnMyLjAvc3F1YXNoZnMtdG9vbHMvbWtzcXVhc2hmcy5jIHNxdWFzaGZz
Mi4wLmFtZDY0L3NxdWFzaGZzLXRvb2xzL21rc3F1YXNoZnMuYwotLS0gc3F1YXNoZnMyLjAvc3F1
YXNoZnMtdG9vbHMvbWtzcXVhc2hmcy5jCTIwMDQtMDUtMjEgMDA6MTg6MTIuMDAwMDAwMDAwICsw
MjAwCisrKyBzcXVhc2hmczIuMC5hbWQ2NC9zcXVhc2hmcy10b29scy9ta3NxdWFzaGZzLmMJMjAw
NC0wNi0xNiAxOTo0Nzo0Mi40MTAxODAwMDAgKzAyMDAKQEAgLTYyLDYgKzYyLDcgQEAKIGludCB0
b3RhbF9jb21wcmVzc2VkID0gMCwgdG90YWxfdW5jb21wcmVzc2VkID0gMDsKIAogaW50IGZkOwor
dW5zaWduZWQgY2hhciogcmVhZF9idWZmZXJfYmFzZTsKIAogLyogc3VwZXJibG9jayBhdHRyaWJ1
dGVzICovCiBpbnQgbm9JID0gMCwgbm9EID0gMCwgY2hlY2tfZGF0YSA9IDAsIGJsb2NrX3NpemUg
PSBTUVVBU0hGU19GSUxFX1NJWkUsIGJsb2NrX2xvZzsKQEAgLTg1MywxMCArODU0LDE0IEBACiAJ
cmV0dXJuIHN0YXJ0X2J5dGVzOwogfQogCit2b2lkIHNldHVwX3JlYWRfYnVmZmVyKHZvaWQqIHAp
Cit7CQorCXJlYWRfYnVmZmVyX2Jhc2UgPSAodW5zaWduZWQgY2hhciopIHA7Cit9CiAKIHVuc2ln
bmVkIGNoYXIgKnJlYWRfZnJvbV9idWZmZXIodW5zaWduZWQgaW50ICpzdGFydCwgdW5zaWduZWQg
aW50IGF2YWlsX2J5dGVzKQogewotCXVuc2lnbmVkIGNoYXIgKnYgPSAodW5zaWduZWQgY2hhciAq
KSAqc3RhcnQ7CisJdW5zaWduZWQgY2hhciAqdiA9IHJlYWRfYnVmZmVyX2Jhc2UgKyAqc3RhcnQ7
CiAJKnN0YXJ0ICs9IGF2YWlsX2J5dGVzOwkKIAlyZXR1cm4gdjsKIH0KQEAgLTkyMyw3ICs5Mjgs
OCBAQAogc3RydWN0IGZpbGVfaW5mbyAqZHVwbGljYXRlKHVuc2lnbmVkIGNoYXIgKihnZXRfbmV4
dF9maWxlX2Jsb2NrKSh1bnNpZ25lZCBpbnQgKiwgdW5zaWduZWQgaW50KSwgdW5zaWduZWQgaW50
IGZpbGVfc3RhcnQsIGludCBieXRlcywgdW5zaWduZWQgaW50ICoqYmxvY2tfbGlzdCwgaW50ICpz
dGFydCwgaW50IGJsb2Nrcywgc3RydWN0IGZyYWdtZW50ICoqZnJhZ21lbnQsIGNoYXIgKmZyYWdf
ZGF0YSwgaW50IGZyYWdfYnl0ZXMpCiB7CiAJdW5zaWduZWQgc2hvcnQgY2hlY2tzdW0gPSBnZXRf
Y2hlY2tzdW0oZ2V0X25leHRfZmlsZV9ibG9jaywgZmlsZV9zdGFydCwgYnl0ZXMpOwotCXVuc2ln
bmVkIHNob3J0IGZyYWdtZW50X2NoZWNrc3VtID0gZ2V0X2NoZWNrc3VtKHJlYWRfZnJvbV9idWZm
ZXIsICh1bnNpZ25lZCBpbnQpIGZyYWdfZGF0YSwgZnJhZ19ieXRlcyk7CisJc2V0dXBfcmVhZF9i
dWZmZXIoZnJhZ19kYXRhKTsKKwl1bnNpZ25lZCBzaG9ydCBmcmFnbWVudF9jaGVja3N1bSA9IGdl
dF9jaGVja3N1bShyZWFkX2Zyb21fYnVmZmVyLCAwLCBmcmFnX2J5dGVzKTsKIAlzdHJ1Y3QgZmls
ZV9pbmZvICpkdXBsX3B0ciA9IGJ5dGVzID8gZHVwbFtjaGVja3N1bV0gOiBmcmFnX2R1cHNbZnJh
Z21lbnRfY2hlY2tzdW1dOwogCiAKQEAgLTEwNDMsNyArMTA0OSw4IEBACiAKIAljbG9zZShmaWxl
KTsKIAlpZih3aG9sZV9maWxlKSB7Ci0JCWlmKGR1cGxpY2F0ZV9jaGVja2luZyAmJiAoZHVwbF9w
dHIgPSBkdXBsaWNhdGUocmVhZF9mcm9tX2J1ZmZlciwgKHVuc2lnbmVkIGludCkgY19idWZmZXIs
IGZpbGVfYnl0ZXMsICZibG9ja19saXN0cCwgJnN0YXJ0LCBibG9ja3MsICZmcmFnbWVudCwgYnVm
ZiwgZnJhZ19ieXRlcykpID09IE5VTEwpIHsKKwkJc2V0dXBfcmVhZF9idWZmZXIoY19idWZmZXIp
OworCQlpZihkdXBsaWNhdGVfY2hlY2tpbmcgJiYgKGR1cGxfcHRyID0gZHVwbGljYXRlKHJlYWRf
ZnJvbV9idWZmZXIsIDAsIGZpbGVfYnl0ZXMsICZibG9ja19saXN0cCwgJnN0YXJ0LCBibG9ja3Ms
ICZmcmFnbWVudCwgYnVmZiwgZnJhZ19ieXRlcykpID09IE5VTEwpIHsKIAkJCSpkdXBsaWNhdGVf
ZmlsZSA9IFRSVUU7CiAJCQlnb3RvIHdyX2lub2RlOwogCQl9CmRpZmYgLXJ1IHNxdWFzaGZzMi4w
L3NxdWFzaGZzLXRvb2xzL3JlYWRfZnMuYyBzcXVhc2hmczIuMC5hbWQ2NC9zcXVhc2hmcy10b29s
cy9yZWFkX2ZzLmMKLS0tIHNxdWFzaGZzMi4wL3NxdWFzaGZzLXRvb2xzL3JlYWRfZnMuYwkyMDA0
LTA1LTE5IDAxOjE3OjI5LjAwMDAwMDAwMCArMDIwMAorKysgc3F1YXNoZnMyLjAuYW1kNjQvc3F1
YXNoZnMtdG9vbHMvcmVhZF9mcy5jCTIwMDQtMDYtMTYgMTk6NDk6MjguNzQwMDE2MDAwICswMjAw
CkBAIC00MjAsNyArNDIwLDcgQEAKIAlwcmludGYoIlJlYWQgZXhpc3RpbmcgZmlsZXN5c3RlbSwg
JWQgaW5vZGVzIHNjYW5uZWRcbiIsIGZpbGVzKTsKIAogCWlmKGlub2RlLmlub2RlX3R5cGUgPT0g
U1FVQVNIRlNfRElSX1RZUEUpIHsKLQkJaWYoKGRpcmVjdG9yeV90YWJsZSA9IHNxdWFzaGZzX3Jl
YWRkaXIoZmQsICEoKGludCkgcm9vdF9uYW1lKSwgc0Jsay0+ZGlyZWN0b3J5X3RhYmxlX3N0YXJ0
ICsgaW5vZGUuc3RhcnRfYmxvY2ssCisJCWlmKChkaXJlY3RvcnlfdGFibGUgPSBzcXVhc2hmc19y
ZWFkZGlyKGZkLCAhcm9vdF9uYW1lLCBzQmxrLT5kaXJlY3RvcnlfdGFibGVfc3RhcnQgKyBpbm9k
ZS5zdGFydF9ibG9jaywKIAkJCQkJCWlub2RlLm9mZnNldCwgaW5vZGUuZmlsZV9zaXplLCBzQmxr
LCBwdXNoX2RpcmVjdG9yeV9lbnRyeSkpID09IE5VTEwpIHsKIAkJCUVSUk9SKCJyZWFkX2ZpbGVz
eXN0ZW06IENvdWxkIG5vdCByZWFkIHJvb3QgZGlyZWN0b3J5XG4iKTsKIAkJCWdvdG8gZXJyb3I7
Cg==
</data>        

          </attachment>
    </bug>

</bugzilla>