-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
On Sun, Oct 25, 2015 at 08:16:46PM +0100, Georges Khaznadar wrote: > - I was touched by the issue which you already mentioned : building the > core of Kicad depends on "calling home" to sourceforge, to get the > release 1.54.0 of Boost libraries. No, that is not what I mentioned. The git repository I used was using Debian's packaged boost, which is correct. What I wrote about was that the default module library configuration is filled with github references, which means that it will connect to github when CvPCB is started. The libraries are installed in /usr/share, which is good, but they should also be used by default. Github module libraries should not be enabled by default. I noticed some files related to avhttp that were created during the build, which suggested that there was some downloading going on there as well. Downloading things from the internet during package build is also not allowed, so I hope you are correct that this doesn't happen. > I quilt-patched the file CMakeModules/download_boost.cmake to make it > work quite like the script download_avhttp.cmake in the same > directory: instead of downloading Boost's archive from Internet, a > local copy is used. I shall include this copy into the debian source > package, by adding one operation more in the script get-kicad.sh No, this is not good. To avoid code duplication, we should use the version that is packaged by Debian, not something that is shipped in our own source package. The source I was compiling complained that not using the bundled boost was not guaranteed to work, but it does work fine. > Another possibly annoying task would be to check whether the Boost > package from upstream must be stripped down a little to make it > DFSG-compliant, without touching files which are unseful for Kicad's > build. You can skip that; the package should not use their bundled version anyway, so it is not a problem if it's not DFSG free. Since you're repackaging the tarball anyway, you can just remove the bundled boost. > Another task, probably lighter if I can do it wisely, is to constrain > Kicad to comply with the FHS, that is, put architecture-independant data files > in /usr/share, architecture-dependent stuff in /usr/lib, and user-level > commands in /usr/bin. That would be nice, but I think it's not a priority. At the moment, KiCAD is uninstallable in unstable. If there is a package that works, IMO it should be uploaded as soon as possible. Making things nice can be done in a later upload. To be clear: the module library path and (if it happens) build-time downloading of sources must be fixed before uploading. File paths can be fixed later. > I read that you found hardcoded data locations in Kicad's core source. > Do you estimate that changing the hardcoded paths will be a long task? I searched for where they were, but couldn't find them so far. Once the source location is found, changing them to a different path should be trivial. Thanks, Bas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWLS9IAAoJEJzRfVgHwHE6v6UP/jVvJvaGuEjYv60amURUDqRG EWtH65SAvteD9rgOsNuP4QYX1qQ3V7Ncr/FYHvRozZeaP52gjxbTU4gbv/RNCyVi 3auYXhgLU4WBorgzSq5ke8fSjYXR2k39n+J26sEeHP5KWhismef78GOit08z1wpN HButeh6oiHbkYXli13yBs8BskiXbg1KU/WLwfwVpGvWEWGXcCYU/Nu/tCK+JTIIo lW6K26ofnVJ5oZuDVdde7W80ptLRyVmaEc4n4vY8rfoQaZhpaiv8/LddDCinPKii VxzAPUVZNaBN4Vn5pml3zRIMFYQ6vngam5ngEW6bqToPMxRaA0YI++JD4z17N7wO yF5K2/Khyh7kymyC2u+epMKYRK3btH1bowW7dd1R7xSncSvdv+2jJS1wx66Eul6Y CP1sTPMx2/SsYLAFAVun7Iw+E0PvADkymd2Cu+bvlioY3vINzKX1vxaUbyhAZkMI 7HIPbtAn/6LcdIfRNZnS/3lc/DcFUNQjUlKtp0ITZG526FJjCpoGAvPHCRiftcH1 hkSLDldUt6MjghmeTPQv+LYnB46s6FEtZRdJQM++f8YCIIyxGC9yuQ/kShS7N1Wc jtZXcU71raTqqCglOaJqa+tLjIyWZ7H3bsKtnwb7XQjSmOYKleDHnw0oHbFmRryY iLEp1wupYL1EU0IOlzXw =oTym -----END PGP SIGNATURE-----
