❦ 18 août 2013 20:17 CEST, Tom Lee <deb...@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
signature.asc
Description: PGP signature
