Multiarch and architecture specific headers
Hello there, I am looking for a solution to fix the following bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707754 A package I maintain contains a configuration header (vpConfig.h) which differ depending on the architecture we are (here the dependencies are not the same on i386 and powerpc). So far, the only solution I can think of is moving this header into /usr/include/ and patching the .pc file accordingly. I saw that some packages are already putting headers in this directory but I never heard of this strategy on the Debian wiki. Is this considered good practice? Is there another solution to deal with this bug? Thanks, -- Thomas Moulard（ムラー トマ） CNRS-AIST JRL (Joint Robotics Laboratory), UMI3218/CRT, Tsukuba, Japan http://thomas.moulard.net | GPG Key Id: 516FC68F31496D58 Add me on LinkedIn: http://www.linkedin.com/in/moulard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADNCw2YvXwB+NboCd_YWPPHkH+g1m=hkva-tenfo5ycpdxn...@mail.gmail.com
Re: Multiarch and architecture specific headers
On Tue, May 14, 2013 at 9:56 AM, Russ Allbery wrote: > Thomas Moulard writes: > >> A package I maintain contains a configuration header (vpConfig.h) which >> differ depending on the architecture we are (here the dependencies are >> not the same on i386 and powerpc). > >> So far, the only solution I can think of is moving this header into >> /usr/include/ >> and patching the .pc file accordingly. > > There should be no need to modify the *.pc file. (Indeed, I think that > would be incorrect.) /usr/include/ is part of the default search > path for the compiler for exactly this purpose. Hum I see. However, the headers are located into include/visp/* and not include/* so still I think patching the .pc containing already -I/usr/include/visp to append -I/usr/include/`dpkg-architecture -qDEB_HOST_MULTIARCH` is necessary... >> I saw that some packages are already putting headers in this directory >> but I never heard of this strategy on the Debian wiki. > > That's mostly because multiarch for -dev packages isn't really > well-documented yet. But I believe this is the right approach. Ok, then I will go with this. Thank you for your help and the links toward the doc, -- Thomas Moulard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadncw2bkrg3+mk4g7+biy1z7scf-ttctia98gcj1me5m+4r...@mail.gmail.com
How to handle a package triggering ice or segv during build?
Dear all, the ViSP[1] software I maintain is causing GCC[2,3] and Doxygen[4] to crash on some platforms. It is difficult for me to fix or to report these issues as: 1. I am neither a DD or a DM, 2. I do not have access to these architectures by myself. I was wondering if opening a bug (on the Debian BTS) for GCC and Doxygen is acceptable in this case? Another question is: do DM have SSH access to Debian machines to validate packages on various architectures? [1] http://packages.qa.debian.org/v/visp.html [2] https://buildd.debian.org/status/fetch.php?pkg=visp&arch=mipsel&ver=2.7.0-4&stamp=1371023299 [3] https://buildd.debian.org/status/fetch.php?pkg=visp&arch=sparc&ver=2.7.0-2&stamp=1367014144 [4] https://buildd.debian.org/status/fetch.php?pkg=visp&arch=armel&ver=2.7.0-4&stamp=1371101186 Best, -- Thomas Moulard（ムラー トマ） -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cadncw2zjjorsvhzgx+a0uy_8_qtmqgyhebspglqgap_8b...@mail.gmail.com
Re: How to handle a package triggering ice or segv during build?
On Mon, Jun 17, 2013 at 2:31 AM, Jakub Wilk wrote: > * Thomas Moulard , 2013-06-14, 15:50: > >> the ViSP[1] software I maintain is causing GCC[2,3] and Doxygen[4] to >> crash on some platforms. > > > Why does it build documentation on the buildds? You put documentation in a > separate arch:all package, so that sounds wasteful. > > But anyway... Actually I think so too but I am a bit reluctant to process the Doxygen documentation locally then copy it into the package (mainly because it will easy to forget updating the documentation). If you are aware of a package that could serve as a reference for Doxygen documentation packaging then I would gladly mimic its behavior in my package. >> It is difficult for me to fix or to report these issues as: >> 1. I am neither a DD or a DM, >> 2. I do not have access to these architectures by myself. >> >> I was wondering if opening a bug (on the Debian BTS) for GCC and Doxygen >> is acceptable in this case? > > > In theory, yes. In practice, neither GCC nor Doxygen maintainers have time > (or goodwill...) to debug these issues for you, so you'll be asked to it > provide more information. So you might as well skip the bugfiling part until > you collected enough information. :) > > The correct course of action is: Ask your sponsor to debug the problems for > you. If that doesn't work, ask for help on ports' mailing lists > (debian-mips@, debian-sparc@, debian-arm@). Thank you for all the advices. I asked my usual sponsor about having access to porteboxes. I will try to isolate the issues, see if this is not an intermittent problem and report a minimal case if possible/necessary. I may also post on the different mailing-lists if I cannot find a reasonable solution. Best, -- Thomas Moulard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADNCw2aFrms7R4cO=att0girnhq8nct0k2k9snv-wu4hylq...@mail.gmail.com
Re: How to handle a package triggering ice or segv during build?
On Mon, Jun 17, 2013 at 1:34 PM, Paul Wise wrote: > On Mon, Jun 17, 2013 at 8:53 AM, Thomas Moulard wrote: > >> Actually I think so too but I am a bit reluctant to process the >> Doxygen documentation locally >> then copy it into the package (mainly because it will easy to forget >> updating the documentation). >> If you are aware of a package that could serve as a reference for >> Doxygen documentation packaging >> then I would gladly mimic its behavior in my package. > > I think you may have misunderstood what Jakub was saying. > > Since the documentation is built and placed into an architecture all > package, there is no need for the buildds to also build the > documentation and then discard it since the buildds do not build > architecture all packages. > > So what you need to do is move the building of the documentation into > the build-indep debian/rules target (instead of the build target). > That way it will not be built and thrown away on the buildds. Ok, I understand now. I investigated a bit and wrote this patch [1]. However, [2] and [3] seem to imply there is more do to than this simple patch. Could you confirm whether these information are obsolete or not? (this patch works for me in pbuilder / when I call dpkg-buildpackage -B) [1] http://anonscm.debian.org/gitweb/?p=debian-science/packages/visp.git;a=commitdiff;h=6994be42b1aa3e5d700187fd432a09abb4e542e4;hp=0361f28d746259e3131928c12786e90b7aace299 [2] http://asylum.madhouse-project.org/blog/2012/01/26/buildd-workarounds/ [3] http://nthykier.wordpress.com/2011/11/11/build-arch-for-everyone/ -- Thomas Moulard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADNCw2YsbwaVPq7m3saup=ye2hb1gf+cc36zwsw22ccm+i4...@mail.gmail.com
How to handle a package requiring external test data for its test suite?
Dear all, I am currently packaging a computer vision software[1] which test suite requires external data (images). Considering the weight of the images (~75Mb) compared to the package size (a few Mb) they decided to distribute them separately. Right now, 30% of the tests are failing due to the lack of this dataset. Following a remark on another thread[2], I would like to get your opinion about the best course of action regarding this matter. Should I repack the software after including this dataset? Is the voluminous size a problem? Another option would be to skip the tests which are requiring this dataset. Note: the dataset is mainly composed of video sequences stored as pgm images. [1] http://packages.qa.debian.org/v/visp.html [2] http://lists.debian.org/debian-mentors/2013/06/msg00140.html Thanks, -- Thomas Moulard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADNCw2YQ9m5sZPWST4fK90AjBvBjgmNLesoOU-kEsRZ=rfp...@mail.gmail.com
Re: How to handle a package requiring external test data for its test suite?
On Tue, Jun 18, 2013 at 9:36 PM, Jakub Wilk wrote: > * Charles Plessy , 2013-06-18, 08:33: > >> Have you considered running the tests with autopkgtest ? >> >>http://dep.debian.net/deps/dep8/ >> >> Then, you can either download the data or install it from a separate data >> package. > > > No, you can't assume that Internet connectivity will be available to your > tests. There's no such guarantee. > > (Leaving aside privacy concerns for now...) Ok, so considering the previous answers: - I packaged the reference data into a new page (visp-image-data) - I added the dependency and now the test suite is running fine - I added a autopkgtest to check that a simple program can be compiled after installing the packages. However I am not aware of a way to run a CMake test suite against installed software so I let it go for now. Thanks again for you help. -- Thomas Moulard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CADNCw2bmNfKrx1u+=u1_2cq48cjxwzhxrypf0fi-6jpyw41...@mail.gmail.com
What is the correct fix for this piuparts related issue?
Dear all, I recently uploaded a binary incompatible new version of the ViSP C++ library. We have in testing a package libvisp2.8_2.8.0-5.1 and in unstable a package libvisp2.9_2.9.0-2 piuparts testing2sid check now fails, see: https://piuparts.debian.org/testing2sid/fail/libvisp-dev_2.9.0-2.log Preparing to unpack .../libvisp2.9_2.9.0-2_amd64.deb ... Unpacking libvisp2.9:amd64 (2.9.0-2) ... dpkg: error processing archive /var/cache/apt/archives/libvisp2.9_2.9.0-2_amd64.deb (--unpack): trying to overwrite '/usr/share/visp/data/wireframe-simulator/circles2.bnd', which is also in package libvisp2.8:amd64 2.8.0-5.1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Preparing to unpack .../multiarch-support_2.19-5_amd64.deb ... Unpacking multiarch-support (2.19-5) over (2.19-4) ... Errors were encountered while processing: /var/cache/apt/archives/libvisp2.9_2.9.0-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) 2m29.1s ERROR: Command failed (status=100): ['chroot', '/srv/piuparts.debian.org/tmp/tmpk7TUWx', 'apt-get', '-yf', 'dist-upgrade'] Apparently, libvisp2.8 and libvisp2.9 provides the same file which is obviously an issue if one tries to install the two packages side by side. In this particular case, should libvisp2.9 declare a break+replace on libvisp2.8 or is there another better solution to solve this issue? Thanks, -- Thomas Moulard -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CADNCw2Ypj7OJ6kizn1E3Nk=pxos10s1r78dbqmijjkn_qru...@mail.gmail.com
