❦ 18 août 2013 20:17 CEST, Tom Lee <debian@tomlee.co> :
>> Glad to see you are working on this package.
>>
>> debian/control: why do you depend explicitely on such a version of GCC?
>> The README states gcc 4.7+ but your version excludes GCC as in Wheezy.
>>
>
> I chose to use the version that I built with (though in retrospect I
> don't think I should've had that tilde in there), thinking that if
> it's in testing now it should be readily available on unstable, but I
> didn't think about wheezy.
>
> I've updated the Build-Depends to look like this:
>
> Build-Depends: debhelper (>= 8.0.0), gcc (>= 4.7.0~) ...
Since gcc version is something like 4.7.5-2, you can either go for (>=
4.7) or (>= 4.7.0-3~). The second form is needed only if you need at
least this precise version as released in Debian. The ~ is here to
accomodate backports. You should use the first form, I think: the
required version of gcc does not depend on the packaging.
>> capnproto-doc.docs, capnproto-doc.install, capnproto.install have some
>> odd contents. For .install, it would be the first time I see a directory
>> without a wildcard in it. Maybe this works but this seems unusual to me.
>>
>
> Hm. I don't create a separate -doc package -- is this necessary for
> landing this package? If not, I'd be inclined to remove the *-doc.*
> files all together.
OK, I didn't look carefully enough. I assumed there was a package with
documentations. You don't have to have such a package if the
documentation is not shared between packages or is small.
> I actually got the directory-without-a-wildcard thing from the protobuf package:
>
> tom@desktop:~/Source/protobuf-2.4.1$ cat debian/protobuf-compiler.install
> usr/bin
>
> Seems to work fine, but I can change it if it's at odds with the usual
> style.
OK, I didn't know this was possible. If it works, keep it.
>> In C++, the symbols file will change depending on the
>> architecture. Therefore, you should use demangled names by using
>> c++filt. See: https://wiki.debian.org/UsingSymbolsFiles
>>
>
> I followed the instructions on the wiki page, but there still seems to
> be some mangled names in the symbols file, e.g. the first few lines
> here:
[...]
Unfortunately¸ this C++ voodoo is a bit magic for me. We can pass the
package as is and wait for builders to build for all archs and see what
the symbols on other archs look like.
>> I am unable to compile the package on a clean chroot. The unittests
>> fail:
>>
>> <snip>
>>
>
> Weird -- I'll try that out myself & see if I can figure out what's
> going wrong.
I'll try again at home, I am on my laptop currently with limited
Internet access. Did you use something like pbuilder/cowbuilder? If
not, you should. But I don't see how this could lead to such a
backtrace.
--
printk("What? oldfid != cii->c_fid. Call 911.\n");
2.4.3 linux/fs/coda/cnode.c
Attachment:
signature.asc
Description: PGP signature