Re: mysterious preprocessor flag in compile line
Thanks again. I've fixed the issue and prepared a PR for upstream [1], so this should make other people's lives easier as well. Cheers, Nico [1] https://github.com/HowardHinnant/date/pull/590 On Thu, Jul 16, 2020 at 8:58 PM Andrey Rahmatullin wrote: > > On Thu, Jul 16, 2020 at 08:42:00PM +0200, Nico Schlömer wrote: > > Thanks Andrey for looking into this. How did you find out it comes > > from hhdate's CMakeLists.txt? > 1. I googled ONLY_C_LOCALE and found the project that uses it, the one > that includes that date.h, https://github.com/HowardHinnant/date > 2. I downloaded the source of Waybar but couldn't find it there. > 3. I uses apt-file to search for date.h but couldn't find it. > 4. I've opened the build log and checked the build-dep installation step > to find that it looks like you actually packaged > https://github.com/HowardHinnant/date > 5. I've dowbloaded the date sources and grepped them. > > -- > WBR, wRAR
Re: Salsa password reset
> https://wiki.debian.org/Salsa has the details of how to contact the salsa > admins. Very good, thank you -Nico On Thu, Jul 16, 2020 at 9:06 PM Sudip Mukherjee wrote: > > Hi Nico, > > On Thu, Jul 16, 2020 at 6:32 PM Nico Schlömer > wrote: > > > > I click on password reset, I get an email, I reset the password. So > > far no errors. > > I try to log in with the new password: Invalid Login or password. > > > > Tried that several times over. > > https://wiki.debian.org/Salsa has the details of how to contact the > salsa admins. > > -- > Regards > Sudip
Re: mysterious preprocessor flag in compile line
Thanks Andrey for looking into this. How did you find out it comes from hhdate's CMakeLists.txt? Cheers, Nico On Thu, Jul 16, 2020 at 8:29 PM Andrey Rahmatullin wrote: > > On Thu, Jul 16, 2020 at 08:04:20PM +0200, Nico Schlömer wrote: > > Hi everyone, > > > > I'm trying to build a package for waybar [1], and I'm running some > > test builds on a PPA. I'm inching close, but now there's something I > > cannot figure out: The build process adds the flag > > ``` > > -DONLY_C_LOCALE= > > ``` > > to the compile line, and that makes the build fail in the date.h > > dependency [2]. (It should be -DONLY_C_LOCALE=0 or -DONLY_C_LOCALE=1.) > > > > Any idea where `-DONLY_C_LOCALE=` might come from and how to remove it? > Please provide at the very least the source package contents next time. > I managed to find this comes from your (again, not published) > libhhdate-dev package though. Not sure why > ONLY_C_LOCALE=$,1,0> > becomes > ONLY_C_LOCALE= > But that's as far as I can go with the info provided. > > -- > WBR, wRAR
mysterious preprocessor flag in compile line
Hi everyone, I'm trying to build a package for waybar [1], and I'm running some test builds on a PPA. I'm inching close, but now there's something I cannot figure out: The build process adds the flag ``` -DONLY_C_LOCALE= ``` to the compile line, and that makes the build fail in the date.h dependency [2]. (It should be -DONLY_C_LOCALE=0 or -DONLY_C_LOCALE=1.) Any idea where `-DONLY_C_LOCALE=` might come from and how to remove it? Cheers, Nico [1] https://github.com/Alexays/Waybar [2] https://launchpadlibrarian.net/488841716/buildlog_ubuntu-focal-amd64.waybar_0.9.2-202007161952-0968218e-1focal1_BUILDING.txt.gz
Re: Salsa password reset
I click on password reset, I get an email, I reset the password. So far no errors. I try to log in with the new password: Invalid Login or password. Tried that several times over. (I hope that's clearer.) Cheers, Nico On Thu, Jul 16, 2020 at 7:11 PM Geert Stappers wrote: > > On Thu, Jul 16, 2020 at 05:29:55PM +0200, Nico Schlömer wrote: > > Hi everyone, > > > > I'm having problems logging in the salsa. Resetting the password > > appears to work, but I can't even log in with the new password after > > the successful update. > > Mmm, "but I can't even log in" contradicts "appears to work". > > > > Any suggestions? > > A fresh retry and reporting back how it went ... > > > > Groeten > Geert Stappers > -- > Silence is hard to parse >
problems with salsa
Hi everyone, I'm having problems logging in the salsa. Resetting the password appears to work, but I can't even log in with the new password after the successful update. Any suggestions? Cheers, Nico
Re: gbp import-orig --uscan: tar -t -a -f returns exit status 2
> Make it possible that the "problem" can be reproduced. Share the URL of the > git repository Clone from https://salsa.debian.org/science-team/gmsh and run ``` gbp import-orig --uscan ``` in the checkout. Cheers, Nico On Mon, Feb 3, 2020 at 8:51 PM Geert Stappers wrote: > > On Mon, Feb 03, 2020 at 08:00:47PM +0100, Nico Schlömer wrote: > ... > > Unfortunately, I only get > > ``` > > uscan: error: tar -t -a -f ../gmsh-4.5.2-source.tgz subprocess > > returned exit status 2 > ... > > ``` > > Curiously, when I tar from another location (same file, same md5sum), > > ``` > > tar -t -a -f /tmp/gmsh-4.5.2-source.tgz > > ``` > > it's all going fine. > > With `tar` is option "-t", infact subcommand "-t". > And the 't' is from "Table of content" > > > Please be aware that >tar -t -a -f ../gmsh-4.5.2-source.tgz > is not >tar -t -a -f /tmp/gmsh-4.5.2-source.tgz > > > > Any idea what could be the issue here? > > Make it possible that the "problem" can be reproduced. > Share the URL of the git repository > > > > Groeten > Geert Stappers > -- > Leven en laten leven >
gbp import-orig --uscan: tar -t -a -f returns exit status 2
Hi everyone, I'm trying to update a package via ``` gbp import-orig --uscan ``` Unfortunately, I only get ``` uscan: error: tar -t -a -f ../gmsh-4.5.2-source.tgz subprocess returned exit status 2 ``` I can confirm that this `tar` like gives the error ``` [...] gmsh-4.5.2-source/.clang-format tar: Unexpected EOF in archive tar: Error is not recoverable: exiting now ``` Curiously, when I tar from another location (same file, same md5sum), ``` tar -t -a -f /tmp/gmsh-4.5.2-source.tgz ``` it's all going fine. Any idea what could be the issue here? Cheers, Nico
Re: vtk8
vtk8 now builds on launchpad again. @Anton: You might want to try again. Make sure to have a reasonably recent version of xdmf installed (3.0+git20190531-4). @Alf: Not sure what you're trying to say. Cheers, Nico On Sun, Dec 22, 2019 at 6:17 PM Alf Gaida wrote: > > > % apt-file search vtkIOXdmf3 | grep -i > module > :( > paraview-dev: /usr/include/paraview-5.7/vtkIOXdmf3Module.h > python3-paraview: /usr/lib/python3/dist-packages/vtkmodules/vtkIOXdmf3.py > python3-paraview: > /usr/lib/python3/dist-packages/vtkmodules/vtkIOXdmf3Python.cpython-37m-x86_64-linux-gnu.so > > Am 22.12.19 um 16:04 schrieb Nico Schlömer: > > No idea about that, but for me it fails [1] with the new libproj 6 > > [2]. I have reported the bug [3] and will try to work around it. Will > > report back. > > > > Cheers, > > Nico > > > > [1] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/+build/18460977 > > [2] https://packages.ubuntu.com/focal/libproj-dev > > [3] https://gitlab.kitware.com/vtk/vtk/issues/17753 > > > > On Fri, Dec 20, 2019 at 9:12 PM Anton Gladky wrote: > >> Yes and it fails again: > >> > >> -- Enabling modules for OpenGL2. > >> CMake Error at CMake/vtkModuleTop.cmake:56 (message): > >> No such module "vtkIOXdmf3" needed by "vtkIOParallelXdmf3" > >> Call Stack (most recent call first): > >> CMake/vtkModuleTop.cmake:72 (vtk_module_check) > >> CMake/vtkModuleTop.cmake:79 (vtk_module_check) > >> CMakeLists.txt:104 (include) > >> > >> > >> Anton > >> > >> Am Fr., 20. Dez. 2019 um 14:07 Uhr schrieb Nico Schlömer > >> : > >>> Have you had the time to try again yet? > >>> > >>> Cheers, > >>> Nico > >>> > >>> On Mon, Nov 18, 2019 at 10:36 AM Nico Schlömer > >>> wrote: > >>>> I've pushed a tentative fix, but cannot verify since it build and used > >>>> to build on the PPA [1]. Best try it out yourself. > >>>> > >>>> Cheers, > >>>> Nico > >>>> > >>>> [1] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/+build/18120968 > >>>> > >>>> > >>>> > >>>> On Fri, Nov 15, 2019 at 7:56 PM Anton Gladky wrote: > >>>>> Hi Nico, > >>>>> > >>>>> it looks like the package does not build: > >>>>> > >>>>> CMake Error at CMake/vtkModuleTop.cmake:56 (message): > >>>>> No such module "vtkIOXdmf3" needed by "vtkIOParallelXdmf3" > >>>>> > >>>>> Could you please have a look? > >>>>> > >>>>> Thanks > >>>>> > >>>>> Anton > >>>>> > >>>>> Am Do., 10. Okt. 2019 um 21:21 Uhr schrieb Nico Schlömer > >>>>> : > >>>>>> Hi everyone, > >>>>>> > >>>>>> I've worked on VTK8 [1] and I think it's about ready to be included > >>>>>> into Debian. (More than two years after its release, unfortunately.) > >>>>>> There's a PPA with the latest build [2] if you want to try it out. > >>>>>> > >>>>>> Could anyone take a look? What would be the steps to get it into > >>>>>> Debian? > >>>>>> > >>>>>> Cheers, > >>>>>> Nico > >>>>>> > >>>>>> [1] https://salsa.debian.org/science-team/vtk8 > >>>>>> [2] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/ > >>>>>> > >>>>>> >
Re: vtk8
No idea about that, but for me it fails [1] with the new libproj 6 [2]. I have reported the bug [3] and will try to work around it. Will report back. Cheers, Nico [1] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/+build/18460977 [2] https://packages.ubuntu.com/focal/libproj-dev [3] https://gitlab.kitware.com/vtk/vtk/issues/17753 On Fri, Dec 20, 2019 at 9:12 PM Anton Gladky wrote: > > Yes and it fails again: > > -- Enabling modules for OpenGL2. > CMake Error at CMake/vtkModuleTop.cmake:56 (message): > No such module "vtkIOXdmf3" needed by "vtkIOParallelXdmf3" > Call Stack (most recent call first): > CMake/vtkModuleTop.cmake:72 (vtk_module_check) > CMake/vtkModuleTop.cmake:79 (vtk_module_check) > CMakeLists.txt:104 (include) > > > Anton > > Am Fr., 20. Dez. 2019 um 14:07 Uhr schrieb Nico Schlömer > : > > > > Have you had the time to try again yet? > > > > Cheers, > > Nico > > > > On Mon, Nov 18, 2019 at 10:36 AM Nico Schlömer > > wrote: > > > > > > I've pushed a tentative fix, but cannot verify since it build and used > > > to build on the PPA [1]. Best try it out yourself. > > > > > > Cheers, > > > Nico > > > > > > [1] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/+build/18120968 > > > > > > > > > > > > On Fri, Nov 15, 2019 at 7:56 PM Anton Gladky wrote: > > > > > > > > Hi Nico, > > > > > > > > it looks like the package does not build: > > > > > > > > CMake Error at CMake/vtkModuleTop.cmake:56 (message): > > > > No such module "vtkIOXdmf3" needed by "vtkIOParallelXdmf3" > > > > > > > > Could you please have a look? > > > > > > > > Thanks > > > > > > > > Anton > > > > > > > > Am Do., 10. Okt. 2019 um 21:21 Uhr schrieb Nico Schlömer > > > > : > > > > > > > > > > Hi everyone, > > > > > > > > > > I've worked on VTK8 [1] and I think it's about ready to be included > > > > > into Debian. (More than two years after its release, unfortunately.) > > > > > There's a PPA with the latest build [2] if you want to try it out. > > > > > > > > > > Could anyone take a look? What would be the steps to get it into > > > > > Debian? > > > > > > > > > > Cheers, > > > > > Nico > > > > > > > > > > [1] https://salsa.debian.org/science-team/vtk8 > > > > > [2] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/ > > > > > > > > > >
Re: vtk8
Have you had the time to try again yet? Cheers, Nico On Mon, Nov 18, 2019 at 10:36 AM Nico Schlömer wrote: > > I've pushed a tentative fix, but cannot verify since it build and used > to build on the PPA [1]. Best try it out yourself. > > Cheers, > Nico > > [1] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/+build/18120968 > > > > On Fri, Nov 15, 2019 at 7:56 PM Anton Gladky wrote: > > > > Hi Nico, > > > > it looks like the package does not build: > > > > CMake Error at CMake/vtkModuleTop.cmake:56 (message): > > No such module "vtkIOXdmf3" needed by "vtkIOParallelXdmf3" > > > > Could you please have a look? > > > > Thanks > > > > Anton > > > > Am Do., 10. Okt. 2019 um 21:21 Uhr schrieb Nico Schlömer > > : > > > > > > Hi everyone, > > > > > > I've worked on VTK8 [1] and I think it's about ready to be included > > > into Debian. (More than two years after its release, unfortunately.) > > > There's a PPA with the latest build [2] if you want to try it out. > > > > > > Could anyone take a look? What would be the steps to get it into Debian? > > > > > > Cheers, > > > Nico > > > > > > [1] https://salsa.debian.org/science-team/vtk8 > > > [2] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/ > > > > > >
Re: vtk8
I've pushed a tentative fix, but cannot verify since it build and used to build on the PPA [1]. Best try it out yourself. Cheers, Nico [1] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/+build/18120968 On Fri, Nov 15, 2019 at 7:56 PM Anton Gladky wrote: > > Hi Nico, > > it looks like the package does not build: > > CMake Error at CMake/vtkModuleTop.cmake:56 (message): > No such module "vtkIOXdmf3" needed by "vtkIOParallelXdmf3" > > Could you please have a look? > > Thanks > > Anton > > Am Do., 10. Okt. 2019 um 21:21 Uhr schrieb Nico Schlömer > : > > > > Hi everyone, > > > > I've worked on VTK8 [1] and I think it's about ready to be included > > into Debian. (More than two years after its release, unfortunately.) > > There's a PPA with the latest build [2] if you want to try it out. > > > > Could anyone take a look? What would be the steps to get it into Debian? > > > > Cheers, > > Nico > > > > [1] https://salsa.debian.org/science-team/vtk8 > > [2] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/ > > > >
vtk8
Hi everyone, I've worked on VTK8 [1] and I think it's about ready to be included into Debian. (More than two years after its release, unfortunately.) There's a PPA with the latest build [2] if you want to try it out. Could anyone take a look? What would be the steps to get it into Debian? Cheers, Nico [1] https://salsa.debian.org/science-team/vtk8 [2] https://launchpad.net/~nschloe/+archive/ubuntu/vtk8/
Re: uscan: version with dashes
That works, thank you! On Wed, Oct 2, 2019 at 5:23 PM Adam Borowski wrote: > > On Wed, Oct 02, 2019 at 02:13:27PM +0200, Nico Schlömer wrote: > > a package now uses dashes instead of dots in upstream release tar > > names. The watch file > > > opts=filenamemangle=s/.+\/trilinos-release-@ANY_VERSION@\.tar\.gz/trilinos-$1\.tar\.gz/ > > > uscan info: Newest version of trilinos on remote site is 12-14-1, > > local version is 12.12.1 > > uscan info:=> Only older package available from > > > > https://github.com/trilinos/Trilinos/archive/trilinos-release-12-14-1.tar.gz > > > How to replace the dashes with dots? > > uversionmangle=s/-/./g > > -- > ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, > ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. > ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, > ⠈⠳⣄ etc), let the drink age at least 3-6 months. >
uscan: version with dashes
Hello everyone, a package now uses dashes instead of dots in upstream release tar names. The watch file ``` version=4 opts=filenamemangle=s/.+\/trilinos-release-@ANY_VERSION@\.tar\.gz/trilinos-$1\.tar\.gz/ \ https://github.com/trilinos/Trilinos/tags .*/trilinos-release-@ANY_VERSION@\.tar\.gz ``` continues to work, but reports ``` uscan info: Newest version of trilinos on remote site is 12-14-1, local version is 12.12.1 uscan info:=> Only older package available from https://github.com/trilinos/Trilinos/archive/trilinos-release-12-14-1.tar.gz ``` How to replace the dashes with dots? Cheers, Nico
Fwd: ITP Mmg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > There seems to be no license text in the file. Usually one has both a license statement and a license paragraph, listing the license text. For example: Alright, thank you! -BEGIN PGP SIGNATURE- Version: FlowCrypt 6.9.3 Gmail Encryption Comment: Seamlessly send and receive encrypted email wsFcBAEBCAAGBQJdSUfrAAoJEJFPgzQ3IEx1x9oP/jXTjKoqLcJr/WpurKzT 99Nv6+x41V7j8Q0v7iRdysL3+38LV42cbL+rtAPPXYTLW1xfHs4TG/ssXeax wJOXzHsqPYMz0pSIjcdQ7R7vNOooxh26dTHlTntAR/GAawpyFmdT0QpaeaIQ +EwWbaaIfplxe2tXolvSxM+6JmRjuXIyymUn6kjH8G5+/30IkXtux4djOSR2 4ft/RA2EkNGrtd0Lm+Ezhj4GtKd/umcVLhVa/dbclIyV2kCc7MnHXryjZrP9 tlvK3ABvJt2HiakVQd7rLwdUzMy2rCyZfIlTok4uN/QLFGyFHQVaK57YHRrg +aJy343eOEzOOtA4EnK//JIRx/Y3UjI0FHEwMgyT15ZDHq/YitLqwX0VKOxG 00jyu/C1uu55JpiaAa/UFTCovV+y5qaiIKYN5wtUnxeYBug+cxL8z1jfqds5 n9CDBOT98UO6RzMSCqihKT1yT9fL8ySP/qB6f15TPX+hcwaIamgksDJFzyYk cOk792FZSpMREeIcS74fuQHd4asP8nruDOYCe8/nwD8wrYNMImJ1u5acKzEm Hj2g7Jw6oAWQg/IL0r9mc4PkEGSGbfHSuCNyd1Bb7qpZzqhcjJ9gRmMOnud7 0ZZR2+6EMneia/jOQQXwaSbKOiLbo8UWpYphkqC8ZQAQbhN6NfdldYSDWAtd 7P0B =aYMn -END PGP SIGNATURE- 0x914F833437204C75.asc Description: application/pgp-keys
Re: ITP Mmg
Thanks Mo for the hints.
>From the linitian hints, there's one I don't understand:
```
missing-license-paragraph-in-dep5-copyright lgpl (paragraph at line 6)
```
None of `LGPL`, `LGPL-3+`, `LGPL-3-or-later` works. What am I missing here?
Cheers,
Nico
On Tue, Aug 6, 2019 at 5:33 AM Mo Zhou wrote:
>
> Hi Nico,
>
> 1. libmmg-dev should depend on libmmg5 (= ${binary:Version})
> 2. mmg should depend on libmmg5 (= ${binary:Version})
> 3. lintian -EviI will tell you the rest problems
>
> On 2019-08-05 20:58, Nico Schlömer wrote:
> > I created a package [1] for Mmg [2], a great (scientific) mesh
> > generator and optimizer.
> >
> > Everything appears to work fine and I'd be happy about some feedback.
> >
> > Cheers,
> > Nico
> >
> >
> > [1] https://salsa.debian.org/science-team/mmg
> > [2] https://www.mmgtools.org/
ITP Mmg
I created a package [1] for Mmg [2], a great (scientific) mesh generator and optimizer. Everything appears to work fine and I'd be happy about some feedback. Cheers, Nico [1] https://salsa.debian.org/science-team/mmg [2] https://www.mmgtools.org/
Fwd: packaging stellar, gitlab-ci fails, wrong installation path?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > most likely appending -1. Yes, thank you, that was it. > Remove debian/*.install. Yup, that did the trick. I'd always thought that you need *.install files no matter what, thanks for the hint. Cheers, Nico On 2019-08-02 at 05:19, s...@svenhartge.de wrote: > Nico Schlömer wrote: > > > I'm starting to package Stellar, a tet mesh optimizer [1]. > > > The package is very basic, but still things are failing. I don't know why. > > > 1. The gitlab-ci build [2] fails with > > ``` > > Checking cache for default... > > FATAL: file does not exist > > Failed to extract cache > > ``` > > What does this mean? > > You can ignore this one. > > Salsa CI uses ccache to speed up compilation and stores this cache > internally. If there was never anything compiled before, the extraction > of the cache fails until it has been created once. > > The real failure is further down: > > | gbp:error: Non-native package 'stellar' has invalid version '1.0' > > Grüße, > Sven. > > -- > Sigmentation fault. Core dumped. -BEGIN PGP SIGNATURE- Version: FlowCrypt 6.9.3 Gmail Encryption Comment: Seamlessly send and receive encrypted email wsFcBAEBCAAGBQJdSIkyAAoJEJFPgzQ3IEx1VnUP+QDASf/jLKDMw69WawyS bGDFz3Rk8jdmARet3nyG+rXu0TUE4C3orDbdLJLUe1k8cfXvqd8S/h4ztUtD IvkKf1/Wa6ik+s6cr7d+O3fcYO87OUywETqcPM/S5uALupR3vyYDM96TE8CK 7iN8ZG+HONnOcBtY0rGQuzc5WrQutiifU20mjD/jEjxCWb/+XcibMYS5ptJE NCA1Z/BmSehJ7rXIeiZR6vvs4yNmXudKz91V06TlKZbvR12RX1G9EzV2ONNQ TtmSJIhMxESRG7Ma9/+ZLwajFdgGLz5WOgzJDgzaRBwruVWbQPFM6u1GgFPO m1gbO6m0jiSQUmg2QdReHiEOosIE0F+JK02lxCUHMy2s8QpMznjQl1zOBcjQ hWP71KTp2Sod3Z40xiFkUnNbJZYHw75PbtQ+ZC+8cZDqgSQ9crjBPZ3HmmrK +p57yBsUYgSiRaYDS3RfSr+0zPA660g6nk1WYuUoPhIGhOY0Msd55jojo9md OOJkTgquy5vvH7vcShExjo/ezMaKUlnz3dhfN9tLpjJCM+Lt2tQ00T1Mpwyl HaYdvdzTn82x5OMFwLsDv6pt9SPv1MQXHj82cRvsms415FJ7JXOysDGzxaFa AYyvgRkBGCWdgV2h0HdXUwqrrvgGfwdEjCzEyJHRtIlKddYFtfYBatO9ANDX HfNR =agON -END PGP SIGNATURE- 0x914F833437204C75.asc Description: application/pgp-keys
Re: packaging stellar, gitlab-ci fails, wrong installation path?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thanks Andrey for the reply. > No idea about that but "gbp:error: Non-native package 'stellar' has invalid version '1.0'" is a valid problem. Fair enough. What does it mean? How to fix it? > Have you ever built this package yourself? I'm sure the same problem will happen in any environment. That may very well be. I usually just upload my stuff to launchpad and see what happens; it's easier for me to remember than the local build process with pbuilder, debuilder, or whatever tools and environments are involved. > You have one subpackage yet you are using dh_install to move files to subpackages. Why do I have a subpackage? Where is that specified? Where do I use dh_install? All of these are implicit I suppose. Hints on how to fix those things are appreciated. Cheers, Nico -BEGIN PGP SIGNATURE- Version: FlowCrypt 6.9.1 Gmail Encryption Comment: Seamlessly send and receive encrypted email wsFcBAEBCAAGBQJdQux1AAoJEJFPgzQ3IEx15A0QAICfsqOpqgDKkXPpEzyz MDA0n4lK6NFgjPfVl4SDrJFciH5hzv9ntQx2TBK2VbXhsQoP7ST/R8hzCyPt XAnLcFsa5Rh/zpaH49zjARZWEdPciC3FyZ/rWpSvX+khSvXxyRb3rLwCroRT J5ARjDJyOL0pZzQMTOFGSeJVOFg55HeNtxHCXu2Il257d0CBTXqslSz68yWx a39i4GQQFUfrM3lr8C3rUbNPxnj0V9VMc7cu13FKoEaSQEuYLkCCAboS39E5 eUyUuf1psBraKf1zgNB2NoqfQ7CAq8qIcX0QjIOxONXNmwzUQVxlIzmjO1rl 8K5s+i3Yr1Rq386cWORMkBZeckCYxve59nzYPyqKk2nQZRKM9bVNCj31YqzW SGR8DKMZIFWEhIz8U10D86j0wyKrHNZ6O/hrHb6AxxUO3wTNaNGoF3NSV9cR UOL4VNSo165uv5O7ea60OMylVxFIZPSNGTCQka1OHSWVjJpOBjsc/6cdngO8 ybT8sDhTuWS+Xk6L7qWM/Z5tebG1uQxq9YDjVSky9BUWJ33p22oHSOj8MQLG GmX3KriSrmVoaV/d8kNHVHsQnDNyriG2swexawdGsL0PBg7hk0MtOepHPFOI 5FcwvEnk3zhKXdkfh8D40aNdnwG1c1Bnq2c5Ozargf6132inttgzwMqkSKB6 VKgP =dSJS -END PGP SIGNATURE- 0x914F833437204C75.asc Description: application/pgp-keys
packaging stellar, gitlab-ci fails, wrong installation path?
Hi everyone, I'm starting to package Stellar, a tet mesh optimizer [1]. The package is very basic, but still things are failing. I don't know why. 1. The gitlab-ci build [2] fails with ``` Checking cache for default... FATAL: file does not exist Failed to extract cache ``` What does this mean? 2. When building on launchpad, the installation fails [3]. It seems that the file is installed in the wrong place? Any hints? Cheers, Nico [1] https://people.eecs.berkeley.edu/~jrs/stellar/ [2] https://salsa.debian.org/science-team/stellar/-/jobs/248393 [3] https://launchpadlibrarian.net/435506092/buildlog_ubuntu-eoan-amd64.stellar_1.0-201908011436-eoan1_BUILDING.txt.gz
Re: repro: Uploading artifacts to coordinator... too large archive
Alright, thanks! On Fri, Jul 19, 2019 at 4:44 PM Sven Hartge wrote: > > Nico Schlömer wrote: > > > From the gmsh repro-build, I'm getting > > ``` > > /builds/science-team/gmsh/debian/output: found 38 matching files > > ERROR: Uploading artifacts to coordinator... too large archive > > id=227001 responseStatus=413 Request Entity Too Large status=413 > > Request Entity Too Large token=XzzUdm1f > > FATAL: too large > > ``` > > Anything one can do about that? > > Somehow the build results from the reprotest stage got very large, > triggering a safety check in Gitlab. Which surprises me, since other > larger projects like MariaDB use the pipelines without problems. > > Something smells fishy here. > > You can do two things in the interim period: > > a) disable the reprotest for now to get a clean pipeline until this is > sorted (see https://salsa.debian.org/salsa-ci-team/pipeline#basic-use on > how to skip a job) > b) and report this problem via > https://salsa.debian.org/salsa-ci-team/pipeline/issues to give it a > better visibility for the CI team. > > Grüße, > Sven. > > -- > Sigmentation fault. Core dumped. >
repro: Uploading artifacts to coordinator... too large archive
>From the gmsh repro-build, I'm getting ``` /builds/science-team/gmsh/debian/output: found 38 matching files ERROR: Uploading artifacts to coordinator... too large archive id=227001 responseStatus=413 Request Entity Too Large status=413 Request Entity Too Large token=XzzUdm1f FATAL: too large ``` Anything one can do about that? Cheers, Nico
Re: cannot find library libgmsh.so.4.4 needed by ...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Ah, I get it now! Because `${DEB_HOST_MULTIARCH}` is used in the
.install-files, they have to be treated with a special tool, dh-exec, that
takes the variables from debian/rules.
Thanks everyone!
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 6.9.1 Gmail Encryption
Comment: Seamlessly send and receive encrypted email
wsFcBAEBCAAGBQJdMY3tAAoJEJFPgzQ3IEx1btMP/1OV09y42MP+Hj95dwjI
0LZ/FQtCy6HaDi8a8lI91Q9YLPSD6lsladen9YrYb8d5STuZ8uThafIFcNSq
J2kTCXoh2m1FCXcVa2U5en5YxEXz7Nq4ANs+xabW+yGkNDt70pUd0ibBHmjE
hdpGd4XkrUzjPGhFcnDL0AB1CU1KHftRu3e+yIzHGZe3a9j/z8NJj6d475Ff
bQYhAOfY54xqAvYRNpdrDKILz3INBatpKnw5D7Wvy4hPwqMb0y25k/oFSoLB
SwYR1gJUGFYdjnUvEdH4O0IZgVSVVYNaltGm0VY9Exiy4M2uNnSaF3Ym30oW
5u81SJsSBiC1HgrBdl/0RvelJC7ztFbDtmRgozmdFSqQSDXooKDDXTyUQjd7
Zwj7H8BoORoV0pXVlEZpiJ1Af12QPogHUVcK0n24lSgkq295u02A9jdDL1mk
rryhjoj+LLrwn3aHlGtH998S6+ur6evIfZS7+pzlvf+EyYSFcouMSnLAPqEH
vzku/Zep2MTekEtt/0Kk8jvfO2Hlnbkt4m6Dhh5ax798hT5Q16jF1yXXR1WJ
aRQ3BSaS3mqfvBFURKM13WfR6MAiav0WuOq+/xu38FHZMftD4RV19pH20aQ5
cnOrqLjITou62yc4l3ijvawmKxMTYfD8ydYkGRhgDZ2CMt1RlYPexLuHlnCl
/JRm
=dN1d
-END PGP SIGNATURE-
0x914F833437204C75.asc
Description: application/pgp-keys
Re: cannot find library libgmsh.so.4.4 needed by ...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
>> debian/rules has
>> ```
>> DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
>> ```
>> so I thought (on respective machines), {DEB_HOST_MULTIARCH} equals
>> x86_64-linux-gnu. Not the case?
> No substitutions is done on debhelper config files, unless you use
> dh-exec, and you disabled that.
Just for clarity: debian/rules is a "debhelper config file"?
How did I disable dh-exec? I is that because I unset the executable bit on
the .install file? (This looked like a mistake really, and I haven't found
documentation on that either.)
I had always thought of debian/rules like a Makefile, and thought that when
I put
```
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
```
there, all ${DEB_HOST_MULTIARCH} get replaced by the rhs expression.
Cheers,
Nico
-BEGIN PGP SIGNATURE-
Version: FlowCrypt 6.9.1 Gmail Encryption
Comment: Seamlessly send and receive encrypted email
wsFcBAEBCAAGBQJdMXcQAAoJEJFPgzQ3IEx1goMP/jJb2DobgNRf/aCmJk7W
sEDKx7CGvtjxyq6bOJwbg1kceK9FEMgHO/eOz1eHdZlVLHhL2eKSZQsqU0ka
YlE2RtNN5v40G/3wM+/nNK5M7AOviL9BWsawzDXtfT94NMoxajLKthTflS6S
vdDsfAZpcZJjQFUk2s3jzqmEfHvAOxC1YcJKVG1lqrxRJ9qVGg/8tpGNSMfg
zcYcO6/pxhYoEbUhrcb80Cagg4EufTS1l2iFafDNi01d4RwCzaUHmmL6yz6I
uMxXu4DhEYOC9HAbSRGuYs2j2cH+llm16zzF4d0NOxyge3aEHk5mFsorQjv2
LeZv1NUpQs3T/rkYfx9dFFYV8wS6EixaeHeoMDXDeNnxERTEQJ09wXEVEPhX
qsANJ1G4jh8cTc/CXcuiF1IJZlJc7Gp5R8SlvA7f5siOs9uqC6OPAQ1cYODb
HHT/EvtEIO2HwBFTBftPK2+zFK7Jmxk2f2epBQI+WshouoJQN2Ba7xG70qqZ
mTyKExfjf9ldn2sWfCb8fU4NjDCn1RDmfoFv+fmqAXBjL5NDiopGdS7T62CK
gtXRo7IBGoLBOnoRi7y+QGFwzR8zLKfriUOTJw+yT78i5Zr1jDGTzpQNfN+z
K0PMOrguyZLbcjWTe/r0y/Wnz9UwbHuvZTRWGfvQSXtsh+Iq6L1SBgaJry0J
ufqp
=AayP
-END PGP SIGNATURE-
0x914F833437204C75.asc
Description: application/pgp-keys
Re: cannot find library libgmsh.so.4.4 needed by ...
> As a result, the library gets installed to usr/lib/${DEB_HOST_MULTIARCH}
> rather than usr/lib/x86_64-linux-gnu
debian/rules has
```
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
```
so I thought (on respective machines), {DEB_HOST_MULTIARCH} equals
x86_64-linux-gnu. Not the case?
On Mon, Jul 15, 2019 at 3:22 PM Sven Joachim wrote:
>
> On 2019-07-15 14:44 +0200, Nico Schlömer wrote:
>
> > Hi everyone,
> >
> > when upgrading gmsh to 4.4.0, I'm getting the build error
> > ```
> > [...]
> > dpkg-shlibdeps: error: cannot find library libgmsh.so.4.4 needed by
> > debian/gmsh/usr/bin/gmsh (ELF format: 'elf64-x86-64' abi:
> > '0201003e'; RPATH: '')
> > dpkg-shlibdeps: error: cannot continue due to the error above
> > Note: libraries are not searched in other binary packages that do not
> > have any shlibs or symbols file.
> > To help dpkg-shlibdeps find private libraries, you might need to use -l.
> > ```
> > see [1]. I'm not exactly sure why libgmsh.so.4.4 cannot be found; the
> > library is linked with
> > ```
> > -Wl,-soname,libgmsh.so.4.4 -o libgmsh.so.4.4.0
> > ```
> > Any hints?
>
> Probably that is a consequence of your commit a44d5ad253b8[1] which
> removed the executable bit from debian/*.install. As a result, the
> library gets installed to usr/lib/${DEB_HOST_MULTIARCH} rather than
> usr/lib/x86_64-linux-gnu, and dpkg-shlibdeps will not look in such a
> strange place.
>
> Cheers,
>Sven
>
>
> 1.
> https://salsa.debian.org/science-team/gmsh/commit/a44d5ad253b874869f643a02c7d3ca4f4b6c05c0
cannot find library libgmsh.so.4.4 needed by ...
Hi everyone, when upgrading gmsh to 4.4.0, I'm getting the build error ``` [...] dpkg-shlibdeps: error: cannot find library libgmsh.so.4.4 needed by debian/gmsh/usr/bin/gmsh (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') dpkg-shlibdeps: error: cannot continue due to the error above Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file. To help dpkg-shlibdeps find private libraries, you might need to use -l. ``` see [1]. I'm not exactly sure why libgmsh.so.4.4 cannot be found; the library is linked with ``` -Wl,-soname,libgmsh.so.4.4 -o libgmsh.so.4.4.0 ``` Any hints? Cheers, Nico [1] https://salsa.debian.org/science-team/gmsh/-/jobs/58
Re: gbp:error: upstream/4.4.0+ds1 is not a valid treeish
Indeed, thank you. On Sun, Jul 14, 2019 at 7:30 PM Balasankar "Balu" C wrote: > > Hi Nico, > > On 7/14/19 10:35 PM, Nico Schlömer wrote: > > Hi everyone, > > > > I'm trying to update gmsh [1], but the tests on salsa report > > ``` > > gbp:error: upstream/4.4.0+ds1 is not a valid treeish > > ``` > > This is because there is no tag named `upstream/4.4.0+ds1` in that repo. > Maybe you forgot to push a tag? > > Regards > Balu >
gbp:error: upstream/4.4.0+ds1 is not a valid treeish
Hi everyone, I'm trying to update gmsh [1], but the tests on salsa report ``` gbp:error: upstream/4.4.0+ds1 is not a valid treeish ``` See [2]. I have no idea why this comes up. Any hints? Cheers, Nico [1] https://tracker.debian.org/pkg/gmsh [2] https://salsa.debian.org/science-team/gmsh/-/jobs/221777
Re: C++ and Python package combined
Thanks Leo, If I interpret the build log [1] correctly, again the Python extension is build and linked with CMake, not `python setup.py install`. Also the package does some unusual trickery in assembling the setup.py file. Anyhow, thanks for the pointers. Cheers, Nico [1] https://buildd.debian.org/status/fetch.php?pkg=ros-vision-opencv=amd64=1.12.3%2Bds-1%2Bb2=1519637198=0 On Mon, Apr 9, 2018 at 3:51 PM Leopold Palomo-Avellaneda <l...@alaxarxa.net> wrote: > Nico, > > On 09/04/18 15:13, Nico Schlömer wrote: > > Thanks Leo, > > > > I've checked out ros-bond-core now and found that it's simpler than what > I > > have: The Python package is installed just like the rest of the library > > with CMake, plus there are no compiled Python extensions that would need > to > > link against the bond library. That's why d/rules can be so simple. > > Unfortunately, this doesn't help much with my problem. > > https://salsa.debian.org/science-team/ros-vision-opencv > > there's a python extension cv_bridge > > https://salsa.debian.org/science-team/ros-image-common > > Cheers, > > Leopold > > > > Cheers, > > Nico > > > > On Mon, Apr 9, 2018 at 1:18 PM Leopold Palomo-Avellaneda < > l...@alaxarxa.net> > > wrote: > > > >> On 06/04/18 16:38, Nico Schlömer wrote: > >>> Hi everyone, > >>> > >>> I would like to package a piece of software that includes both a C++ > >>> library and a Python package. When building locally from scratch, one > is > >>> supposed to > >>> > >>> * build and install the library first, > >>> (* then build and run the tests, compiling against what just has been > >>> installed,) > >>> * then build and install the Python package, compiling against what > >> just > >>> has been installed. > >>> > >>> If C++ library and Python packages came from two different sources, > >> things > >>> would be easy. It's not clear to me though how to first install one > part > >> of > >>> a source, and then another against it. Perhaps there are example > packages > >>> out there that do that already. > >>> > >>> Any hints? > >> > >> Nico, > >> > >> maybe it helps. The ROS robotics packages has a lot of examples of C++ > >> libraries > >> and Python code. They are located in salsa, for instance: > >> > >> https://salsa.debian.org/science-team/ros-bond-core > >> > >> Take one eye. Look any example of package that begins with ros- > >> > >> Best regards, > >> > >> Leopold > >> > >> > >> -- > >> -- > >> Linux User 152692 GPG: 05F4A7A949A2D9AA > >> Catalonia > >> - > >> A: Because it messes up the order in which people normally read text. > >> Q: Why is top-posting such a bad thing? > >> A: Top-posting. > >> Q: What is the most annoying thing in e-mail? > >> > > > > > -- > -- > Linux User 152692 GPG: 05F4A7A949A2D9AA > Catalonia > - > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > >
Re: C++ and Python package combined
Thanks Leo, I've checked out ros-bond-core now and found that it's simpler than what I have: The Python package is installed just like the rest of the library with CMake, plus there are no compiled Python extensions that would need to link against the bond library. That's why d/rules can be so simple. Unfortunately, this doesn't help much with my problem. Cheers, Nico On Mon, Apr 9, 2018 at 1:18 PM Leopold Palomo-Avellaneda <l...@alaxarxa.net> wrote: > On 06/04/18 16:38, Nico Schlömer wrote: > > Hi everyone, > > > > I would like to package a piece of software that includes both a C++ > > library and a Python package. When building locally from scratch, one is > > supposed to > > > > * build and install the library first, > > (* then build and run the tests, compiling against what just has been > > installed,) > > * then build and install the Python package, compiling against what > just > > has been installed. > > > > If C++ library and Python packages came from two different sources, > things > > would be easy. It's not clear to me though how to first install one part > of > > a source, and then another against it. Perhaps there are example packages > > out there that do that already. > > > > Any hints? > > Nico, > > maybe it helps. The ROS robotics packages has a lot of examples of C++ > libraries > and Python code. They are located in salsa, for instance: > > https://salsa.debian.org/science-team/ros-bond-core > > Take one eye. Look any example of package that begins with ros- > > Best regards, > > Leopold > > > -- > -- > Linux User 152692 GPG: 05F4A7A949A2D9AA > Catalonia > - > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? >
Re: C++ and Python package combined
> I guess you can set PKG_CONFIG_PATH and others appropriately.
That sounds like what I got to do. I'm just figuring out which paths I need
exactly. Can I use export in d/rules?
Cheers,
Nico
On Sat, Apr 7, 2018 at 10:24 AM Paul Wise <p...@debian.org> wrote:
> On Sat, Apr 7, 2018 at 4:04 PM, Nico Schlömer wrote:
>
> >> Which software is this?
> >
> > FEniCS/Dolfin [1]. (I'm preparing the upcoming release.)
>
> Has something changed to prevent the existing dh overrides from working?
>
> https://sources.debian.org/src/dolfin/2017.2.0.post0-3/debian/rules
>
> > The latter step relies on the libraries and headers already being
> installed on the system.
>
> I guess you can set PKG_CONFIG_PATH and others appropriately.
> I use these to bring ~/opt/ dirs into various paths:
>
> export
> PKG_CONFIG_PATH=$HOME/opt/lib/pkgconfig:$HOME/opt/share/pkgconfig${PKG_CONFIG_PATH:+:$PKG_CONFIG_PATH}
> export PATH=$HOME/opt/bin:$HOME/opt/games${PATH:+:$PATH}
> export MANPATH=$HOME/opt/share/man${MANPATH:+:$MANPATH}:
> export LD_LIBRARY_PATH=$HOME/opt/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
> export LIBRARY_PATH=$HOME/opt/lib${LIBRARY_PATH:+:$LIBRARY_PATH}
> export CPATH=$HOME/opt/include${CPATH:+:$CPATH}
> export C_INCLUDE_PATH=$HOME/opt/include${C_INCLUDE_PATH:+:$C_INCLUDE_PATH}
> export
> CPLUS_INCLUDE_PATH=$HOME/opt/include${CPLUS_INCLUDE_PATH:+:$CPLUS_INCLUDE_PATH}
> export
> OBJC_INCLUDE_PATH=$HOME/opt/include${OBJC_INCLUDE_PATH:+:$OBJC_INCLUDE_PATH}
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
>
Re: C++ and Python package combined
> Which software is this? FEniCS/Dolfin [1]. (I'm preparing the upcoming release.) > Does the upstream build system not take care of each of the steps? Like I said, upstream build instructions are: 1. Build and install the library. (Basically CMake + make install) 2. `cd python` and install the Python module (basically `python3 setup.py install`) The latter step relies on the libraries and headers already being installed on the system. Cheers, Nico [1] https://packages.debian.org/source/sid/dolfin On Sat, Apr 7, 2018 at 9:33 AM Paul Wise <p...@debian.org> wrote: > On Fri, Apr 6, 2018 at 10:38 PM, Nico Schlömer wrote: > > > I would like to package a piece of software > > Which software is this? > > > Any hints? > > Does the upstream build system not take care of each of the steps? > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise > >
C++ and Python package combined
Hi everyone, I would like to package a piece of software that includes both a C++ library and a Python package. When building locally from scratch, one is supposed to * build and install the library first, (* then build and run the tests, compiling against what just has been installed,) * then build and install the Python package, compiling against what just has been installed. If C++ library and Python packages came from two different sources, things would be easy. It's not clear to me though how to first install one part of a source, and then another against it. Perhaps there are example packages out there that do that already. Any hints? Cheers, Nico
"License": public-domain
Hi everyone, I sometimes see in d/copyright > Copyright: John Doe > License: public-domain e.g., [1]. However, these two statements contradict each other: public domain means exactly the _absence_ of copyright [2]. Specifically, public domain is _not_ open source [3]. In fact, it's not a proper license at all. I suspect that this is mostly due to an upstream misunderstanding of the term "public domain"; some people mistake it for "open source". Since Debian is usually quite careful when it comes to legal issues, I'm wondering what the official view point is here. Should there be a lintian error if the "license" is public domain and a copyright holder is specified? Should "public-domain" perhaps be prohibited in general? Cheers, Nico [1] https://anonscm.debian.org/git/debian-science/packages/mumps.git/tree/debian/copyright#n52 [2] https://www.gnu.org/philosophy/categories.en.html [3] https://opensource.org/node/878
Re: dpkg-shlibdeps: error: couldn't find library [...] needed by [...]
Thanks, Andrey, for the input. I've dug around a little more now and found that the reason for the error was the fact that the library that couldn't be found was indeed built, but was not part of a package. That's what dpkg-shlibdeps was complaining about. Thanks again, cheers, Nico On Mon, Jan 23, 2017 at 10:02 PM Andrey Rahmatullin <w...@debian.org> wrote: On Mon, Jan 23, 2017 at 08:25:24PM +, Nico Schlömer wrote: > to the CMake config, it all seems to configure and build fine. That is > until dpkg-shlibdeps enters the stage (right before installation): It's not "right before installation". The build process has nothing to do with installing packages. > dpkg-shlibdeps: error: couldn't find library libtrilinos_trilinosss.so.12 And where is that file? > I'm guessing what goes wrong here is that Debian tries to install > libtrilinos_amesos before its dependency libtrilinos_trilinosss. Nothing there installs anything. dpkg-shlibdeps processes ELFs to be included in the packages and tries to find their dependencies and convert them to package-level Depends. -- WBR, wRAR
dpkg-shlibdeps: error: couldn't find library [...] needed by [...]
Hi everyone, Still struggling with the binary-or-shlib-defines-rpath [1] here. After having added ``` -DCMAKE_SKIP_INSTALL_RPATH:BOOL=ON -DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=OFF ``` to the CMake config, it all seems to configure and build fine. That is until dpkg-shlibdeps enters the stage (right before installation): ``` dpkg-shlibdeps: error: couldn't find library libtrilinos_trilinosss.so.12 needed by debian/libtrilinos-amesos12/usr/lib/powerpc64le-linux-gnu/libtrilinos_amesos.so.12.11 (ELF format: 'elf64-powerpcle'; RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib') ``` See [2] for full detail. I'm guessing what goes wrong here is that Debian tries to install libtrilinos_amesos before its dependency libtrilinos_trilinosss. Any hints? Cheers, Nico [1] https://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html [2] https://launchpadlibrarian.net/303577535/buildlog_ubuntu-zesty-ppc64el.trilinos_12.11~20170123171154-786e32e1-1zesty1_BUILDING.txt.gz
Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)
Hm, I'm now getting errors from dpkg-shlibdeps (i.e., and installation time): ``` dpkg-shlibdeps: error: couldn't find library libtrilinos_trilinosss.so.12 needed by debian/libtrilinos-amesos12/usr/lib/powerpc64le-linux-gnu/libtrilinos_amesos.so.12.11 (ELF format: 'elf64-powerpcle'; RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib') ``` See [1] for full detail. (Btw, notice the RPATH settings from openmpi.) CMake I think installs the libraries in alphabetical order, so `libtrilinos_amesos.so.12.11` is handled before its dependency `libtrilinos_trilinosss.so.12` and cannot find the latter -- makes sense. What's the suggested workaround here? Cheers, Nico [1] https://launchpadlibrarian.net/303079195/buildlog_ubuntu-zesty-ppc64el.trilinos_12.11~20170119114916-33933755-1zesty1_BUILDING.txt.g z On Thu, Jan 19, 2017 at 3:03 PM Nico Schlömer <nico.schloe...@gmail.com> wrote: I can confirm that the RPATH is ``` RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib' ``` I'll just wait for the next ompi upload then. Cheers, Nico On Thu, Jan 19, 2017 at 2:10 PM Alastair McKinstry <mckins...@debian.org> wrote: On 19/01/2017 11:20, James Cowgill wrote: > Hi, > > On 18/01/17 22:39, Nico Schlömer wrote: >> I'm co-maintaining the Trilinos package [1] in Debian and recently found >> a bunch of new lintian warnings of the kind >> binary-or-shlib-defines-rpath [2]. It say in the description of the warning: >> ``` >> To fix this problem, look for link lines like: >> >> gcc test.o -o test -Wl,--rpath,/usr/local/lib >> >> or >> >> gcc test.o -o test -R/usr/local/lib >> >> and remove the -Wl,--rpath or -R argument. >> ``` >> Indeed, the Trilinos installation contains many of those lines, but they >> are necessary too. When executing the test binaries (which are compiled >> in the build tree alongside the libraries), they have to find the linked >> shared libraries. Messing with the rpath is necessary. >> >> That's not true later on when the libraries are _installed_, of course. >> For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which >> serves exactly that purpose. For some reason, lintian doesn't seem to be >> happy with that though. > The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake > itself inserts. It does not affect any rpaths manually added with other > -Wl,--rpath options. The culprit here is probably openmpi which adds all > of these rpath entries: > > $ mpicc -show > [...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath > -Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...] > > Maybe it shouldn't do that. The /usr//lib one is clearly useless and the > it seems that most of the libraries from > /usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into > /usr/lib/x86_64-linux-gnu anyway. > Agreed. Will remove these on the next upload. Best regards Alastair -- Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)
I can confirm that the RPATH is ``` RPATH: ':/usr//lib:/usr/lib/powerpc64le-linux-gnu/openmpi/lib' ``` I'll just wait for the next ompi upload then. Cheers, Nico On Thu, Jan 19, 2017 at 2:10 PM Alastair McKinstry <mckins...@debian.org> wrote: > > > On 19/01/2017 11:20, James Cowgill wrote: > > Hi, > > > > On 18/01/17 22:39, Nico Schlömer wrote: > >> I'm co-maintaining the Trilinos package [1] in Debian and recently found > >> a bunch of new lintian warnings of the kind > >> binary-or-shlib-defines-rpath [2]. It say in the description of the > warning: > >> ``` > >> To fix this problem, look for link lines like: > >> > >> gcc test.o -o test -Wl,--rpath,/usr/local/lib > >> > >> or > >> > >> gcc test.o -o test -R/usr/local/lib > >> > >> and remove the -Wl,--rpath or -R argument. > >> ``` > >> Indeed, the Trilinos installation contains many of those lines, but they > >> are necessary too. When executing the test binaries (which are compiled > >> in the build tree alongside the libraries), they have to find the linked > >> shared libraries. Messing with the rpath is necessary. > >> > >> That's not true later on when the libraries are _installed_, of course. > >> For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which > >> serves exactly that purpose. For some reason, lintian doesn't seem to be > >> happy with that though. > > The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake > > itself inserts. It does not affect any rpaths manually added with other > > -Wl,--rpath options. The culprit here is probably openmpi which adds all > > of these rpath entries: > > > > $ mpicc -show > > [...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath > > -Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...] > > > > Maybe it shouldn't do that. The /usr//lib one is clearly useless and the > > it seems that most of the libraries from > > /usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into > > /usr/lib/x86_64-linux-gnu anyway. > > > Agreed. Will remove these on the next upload. > > Best regards > Alastair > > -- > Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>, > https://diaspora.sceal.ie/u/amckinstry > Misentropy: doubting that the Universe is becoming more disordered. > > >
Re: question on binary-or-shlib-defines-rpath
Thanks Sean for the reply. > If so, it's probably a Lintian bug. I thought it might be. Just filed a bug for it [1]. Cheers, Nico [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851833 On Thu, Jan 19, 2017 at 12:50 AM Sean Whitton <spwhit...@spwhitton.name> wrote: Dear Nico, On Wed, Jan 18, 2017 at 10:39:47PM +0000, Nico Schlömer wrote: > That's not true later on when the libraries are _installed_, of course. For > this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which serves exactly > that purpose. For some reason, lintian doesn't seem to be happy with that > though. I believe that this Lintian tag checks only the contents of your final binary packages. Are you absolutely sure that you do not install any of these test suite files? If so, it's probably a Lintian bug. -- Sean Whitton
question on binary-or-shlib-defines-rpath
Hi everyone, I'm co-maintaining the Trilinos package [1] in Debian and recently found a bunch of new lintian warnings of the kind binary-or-shlib-defines-rpath [2]. It say in the description of the warning: ``` To fix this problem, look for link lines like: gcc test.o -o test -Wl,--rpath,/usr/local/lib or gcc test.o -o test -R/usr/local/lib and remove the -Wl,--rpath or -R argument. ``` Indeed, the Trilinos installation contains many of those lines, but they are necessary too. When executing the test binaries (which are compiled in the build tree alongside the libraries), they have to find the linked shared libraries. Messing with the rpath is necessary. That's not true later on when the libraries are _installed_, of course. For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which serves exactly that purpose. For some reason, lintian doesn't seem to be happy with that though. Any hints? Cheers, Nico [1] https://tracker.debian.org/pkg/trilinos [2] https://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html [3] https://cmake.org/cmake/help/v3.0/variable/CMAKE_SKIP_INSTALL_RPATH.html
Re: add missing pristine-tar
Thanks, this did the trick. On Fri, May 20, 2016 at 1:43 PM Mattia Rizzolo <mat...@debian.org> wrote: > On Fri, May 20, 2016 at 11:10:43AM +0000, Nico Schlömer wrote: > > Thanks for the hint. > > Unfortunately, it's not working dpt picks up an older version that > already > > is in pristine-tar and adds another commit for it (bug?), but leaves out > > the version for which there is no pristine-tar. > > > > Any other suggestions? > > If you already have a pristin-tar branch, just call > pristine-tar commit /path/to/tarball > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > more about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- >
header dependencies
Hi everyone, Say a package installs only headers, and in one of those, a header of another -dev package is #included. How to depend on the package? Cheers, Nico
change of username
Hi everyone, When I signed up some years ago, I got a user name with -guest appended. I guess that was the policy at the time. In any case, how can I change that? I wouldn't mind an entirely new account either, even if I have to sign up for all my groups again. Cheers, Nico
Re: add missing pristine-tar
Thanks for the hint. Unfortunately, it's not working dpt picks up an older version that already is in pristine-tar and adds another commit for it (bug?), but leaves out the version for which there is no pristine-tar. Any other suggestions? Cheers, Nico On Fri, May 20, 2016 at 12:34 PM Dominique Dumont <d...@debian.org> wrote: > On Friday 20 May 2016 10:19:19 Nico Schlömer wrote: > > I've got a git-managed repo where an upstream version was included (via > the > > upstream branch, merged into master), but adding a corresponding > > pristine-tar was omitted. How can I retroactively add a pristine-tar > > corresponding to an upstream release? > > Assuming you got the upstream version with uscan, you can try > > dpt missing-pristine-tar > > to update pristine-tar. > > dpt is provided by pkg-perl-tools > > Hope this helps > -- > https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ > http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org > >
add missing pristine-tar
Hi everyone, I've got a git-managed repo where an upstream version was included (via the upstream branch, merged into master), but adding a corresponding pristine-tar was omitted. How can I retroactively add a pristine-tar corresponding to an upstream release? Cheers, Nico
Re: building symbols
Thanks for your input! Cheers, Nico On Thu, Nov 19, 2015 at 1:27 PM Ghislain Vaillant <ghisv...@gmail.com> wrote: > On 19/11/15 11:55, Jakub Wilk wrote: > > * Nico Schlömer <nico.schloe...@gmail.com>, 2015-11-18, 22:52: > >> I'm building the symbols for all libraries in the Trilinos package. > >> Unfortunately, the documentation [1] isn't too verbose here. One thing > >> that has come to my attention, for example, is the fact that some > >> Trilinos libraries appear to contain lots of symbols; including some > >> (all?) of dependent libraries, e.g., > >> ``` > >> MPI::Op::Free()@Base > >> ``` > >> see [2] (towards the end of the build log). > >> This amounts to symbols files of several megabytes in size per > >> library. Perhaps something is going wrong at the linking stage? > >> Pointers to more documentation/tips and tricks are appreciated. > > > > My recommendation is to avoid using symbol files for complex C++ > > libraries. It's most likely not worth the effort. > > > > See this blog post series by Russ Allbery: > > http://www.eyrie.org/~eagle/journal/2012-01/007.html > > http://www.eyrie.org/~eagle/journal/2012-01/008.html > > http://www.eyrie.org/~eagle/journal/2012-02/001.html > > > > I second Jakub's opinion. > > Ghis > >
building symbols
Hi everyone, I'm building the symbols for all libraries in the Trilinos package. Unfortunately, the documentation [1] isn't too verbose here. One thing that has come to my attention, for example, is the fact that some Trilinos libraries appear to contain lots of symbols; including some (all?) of dependent libraries, e.g., ``` MPI::Op::Free()@Base ``` see [2] (towards the end of the build log). This amounts to symbols files of several megabytes in size per library. Perhaps something is going wrong at the linking stage? Pointers to more documentation/tips and tricks are appreciated. Cheers, Nico [1] https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols [2] https://launchpadlibrarian.net/226924938/buildlog_ubuntu-wily-amd64.trilinos_12.5~20151118181658-wily1_BUILDING.txt.gz
BSD-2-clause with header
Hi everyone, I'm packaging a software which includes the following license statement: ``` Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains certain rights in this software. . Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: . Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of the Corporation nor the names of the contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY SANDIA CORPORATION "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL SANDIA CORPORATION OR THE CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ``` This is exactly the 2-clause BSD, plus the header ``` Under the terms of Contract DE-AC04-94AL85000 with Sandia Corporation, the U.S. Government retains certain rights in this software. ``` Does the header count as copyright statement? Can we call this license BSD-2-clause? Cheers, Nico
Re: conditionally require dependency
Thanks again, Josch! The least painful thing for us to maintain is certainly the templating idea. I now created a control.in, rules.in, ready to serve as templates for the generation of the proper rules, control files. envsubst helps in getting the templates values in [1]. Cheers, Nico [1] https://bitbucket.org/fathomteam/moab/pull-requests/137/clean-up-debian-folder/diff#chg-debian/GNUmakefile On Mon, Oct 26, 2015 at 8:55 AM Johannes Schauer <jo...@debian.org> wrote: > Hi Nico, > > Quoting Nico Schlömer (2015-10-26 00:47:54) > > particularly those which have been released a while ago and are closed > > to adding now packages now. > > packages can be added via backports. > > > > - if you were talking about a *build* dependency, then you can generate > > these > > > before building by having a debian/control.in and turning that into > the > > > right debian/control depending on what you want to build > > > > Good idea. I'll look into it. > > remember that the other way I mentioned, having different git branches for > different target distributions would also apply for your use case. > > > > - alternatively, if you were talking about a *build* dependency you > > could use > > >build profiles to selectively enable or disable build dependencies > > > > Never heard of it. I'll check it out as well. > > This would work technically but there is no accepted way to do this in > practice > yet in Debian or Ubuntu. Build profiles allow you to select or unselect > build > dependencies depending on conditions you specify in the Build-Depends > line. So > technically it would be possible to say that a build dependency should > only be > used if the profiles "debian" and "unstable" are active and then when you > build > your source package you would have to take care to have the right profiles > active per build with the DEB_BUILD_PROFILES environment variable or with > the > -P option to dpkg-buildpackage. There is more info on > https://wiki.debian.org/BuildProfileSpec But remember that at this point > this > would just be another hack! While build profiles can be used this way to > support multiple distributions and releases with a single debian/control > file, > there is not yet any decision (or even the attempt to have it) of how the > build > profiles should be named for this use case. > > cheers, josch >
Re: conditionally require dependency
Hi Josch, Thanks a lot for your suggestions! The reason why we want different build dependencies (which is indeed what it is) for different versions is that we'd ideally like to support older releases of Debian/Ubuntu from one code base, particularly those which have been released a while ago and are closed to adding now packages now. > - if you were talking about a *build* dependency, then you can generate these > before building by having a debian/control.in and turning that into the > right debian/control depending on what you want to build Good idea. I'll look into it. > - alternatively, if you were talking about a *build* dependency you could use >build profiles to selectively enable or disable build dependencies Never heard of it. I'll check it out as well. Cheers, Nico On Sun, Oct 25, 2015 at 12:12 PM Johannes Schauer <jo...@debian.org> wrote: > Hi Nico, > > Quoting Nico Schlömer (2015-10-24 20:04:19) > > In [MOAB](https://bitbucket.org/fathomteam/moab/), we (optionally) > depend on > > a rather new version of the [Metis]( > https://packages.debian.org/sid/metis) > > package, and that's what's enforced in our debian/control, too. > > I cannot see any (build-)dependency on metis in your debian/control: > > https://bitbucket.org/fathomteam/moab/src/HEAD/debian/control?at=master > > > Now, we would like to provide MOAB for older versions of Debian/Ubuntu as > > well, and for those older distros would drop the optional Metis > dependency. > > Runtime dependency or build dependency? > > > How is this situation best handled? > > The best way to do this is to get your package into Debian. In that case > the > content of debian/control will be different in testing/unstable as well as > in a > backport that you can do for the current stable or oldstable. > > Your problem arises because you want a one-size-fits-all of your upstream > debian/control. Such a one-size-fits-all often doesn't exist but having a > one-size-fits all is also usually not required because the packaging data > including debian/control between different Debian releases can be (and > mostly > is) different. > > If you do not want to get your package into Debian (and through there into > Ubuntu) but instead provide Debian/Ubuntu packages yourself as the upstream > project, I see these options: > > - have one git branch for every Debian/Ubuntu release you want to support > and >let them have different debian/control content depending on what is > required > > - if you were talking about a *runtime* dependency earlier then you could > just >make it a Recommends > > - if you were talking about a *runtime* dependency but need a *strict* >dependency then you can generate this dependency during package build > time >using a substvar (see man deb-substvars) in your Depends line > > - if you were talking about a *build* dependency, then you can generate > these >before building by having a debian/control.in and turning that into the >right debian/control depending on what you want to build > > - alternatively, if you were talking about a *build* dependency you could > use >build profiles to selectively enable or disable build dependencies > > Note, that all of these suggestions are *not* the right way to do things in > case your package is in Debian or Ubuntu itself. In this case your problem > doesn't arise in the first plae. > > cheers, josch >
conditionally require dependency
Hi everyone, In [MOAB](https://bitbucket.org/fathomteam/moab/), we (optionally) depend on a rather new version of the [Metis](https://packages.debian.org/sid/metis) package, and that's what's enforced in our debian/control, too. Now, we would like to provide MOAB for older versions of Debian/Ubuntu as well, and for those older distros would drop the optional Metis dependency. How is this situation best handled? Cheers, Nico
package naming
Hi everyone, In Debian, I find packages such as ``` libzeep3.0 libzdb9 libzim0 ``` i.e., libraries with some number appended. What's the meaning of that number? Cheers, Nico
build flags handling
Hi everyone, I recently came across a package [1] which ideally would like to handle its own build flags (adding `-O3 -ffast-math` for speed, for example). What is the Debian policy on this? Cheers, Nico [1] https://packages.debian.org/sid/sound/mixxx -- 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/cak6z60db3qlxs-y1u8z672ur5k12ckxyyxx495gkwu_sp-+...@mail.gmail.com
Re: meaningful backtraces for crashes
Thanks Paul for the concise explanation. This helped me fixing the
error within minutes!
Cheers,
Nico
On Sun, Feb 1, 2015 at 4:37 AM, Paul Wise p...@debian.org wrote:
On Sat, Jan 31, 2015 at 8:40 PM, Nico Schlömer wrote:
For Mixxx [1], I would like for users to produce meaningful backtraces
in case of crashes (see [2]). What build options are needed or useful
for debugging purposes? What's the canonical way for adding them to
the Debian packages?
Until [1] gets implemented, you will need to use debhelper 9, add a
mixxx-dbg package to debian/control and override dh_strip to include
the --dbg-package parameter:
debian/compat:
9
debian/rules:
override_dh_strip:
dh_strip --dbg-package=mixxx-dbg
debian/control:
Build-Depends: debhelper (= 9)
Package: mixxx-dbg
Section: debug
Architecture: any
Priority: extra
Depends:
mixxx (= ${binary:Version}),
${misc:Depends}
Description: debug files for mixxx
This package contains debug information for mixxx
.
It can be used to debug mixxx using a debugger if it crashes due to
programming errors.
1. https://wiki.debian.org/AutomaticDebugPackages
--
bye,
pabs
https://wiki.debian.org/PaulWise
--
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/caktje6ggua9pdim8tbwp-be33+qf3gbb-mxf_+uxkkt5vh...@mail.gmail.com
--
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/cak6z60fhns1f58fat0fsg_7zh9ou80wwlgstjbg1sno3zkb...@mail.gmail.com
meaningful backtraces for crashes
Hi all, For Mixxx [1], I would like for users to produce meaningful backtraces in case of crashes (see [2]). What build options are needed or useful for debugging purposes? What's the canonical way for adding them to the Debian packages? Cheers, Nico [1] https://packages.debian.org/sid/sound/mixxx [2] https://bugs.launchpad.net/mixxx/+bug/1097703 -- 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/cak6z60ei8m1gtwzgsjywmdyqcesjylnjgntesalkpmf39ag...@mail.gmail.com
arch optimation for debian packages (here: soundtouch)
Hi all, The audio processing library SoundTouch [1,2] is a major CPU eater in many applications (see, e.g. [3]). I'm now asking myself to what degree we allow optimization for CPU arches in Debian (e.g., MMX, SSE). Cheers, Nico [1] https://packages.debian.org/sid/libsoundtouch-dev [2] http://www.surina.net/soundtouch/sourcecode.html [3] http://sourceforge.net/p/mixxx/mailman/message/33266074/ -- 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/CAK6Z60deaRn2yoyKEX5m=kncv0lke2fdtjpwev+s-ea0+1k...@mail.gmail.com
Re: doc-base errors, documentation installation
Can you also update the pristine-tar branch with your upstream tarballs as imported into the upstream branch? Done. `git-import-orig` helped me out here. I've push some changes on the split-c-f-cxx branch. I've created upstream pull requests for the patches you added. Let's see if they make it in for the 4.3.3 release. You should also add yourself to Uploaders field in the control file. Done. http://pkg-grass.alioth.debian.org/policy/policy.html#cme Great tip! I hadn't known about this one. This'll help me out on a number of other projects, too. Thanks! I fixed all errors and warnings in debian/control, except ``` Warning in 'source Vcs-Browser' value 'http://anonscm.debian.org/cgit/pkg-grass/netcdf.git': URL to debian system is not the recommended one ``` No idea what is recommended instead. Can you enlighten me? `lintian -I --show-overrides --pedantic -E path/to/netcdf.changes`. Will look at those later. Cheers, Nico On Thu, Jan 15, 2015 at 8:59 PM, Sebastiaan Couwenberg sebas...@xs4all.nl wrote: On 01/15/2015 07:57 PM, Nico Schlömer wrote: that you still have local changes not pushed to Alioth? Right; fixed now. Thanks for the push! Can you also update the pristine-tar branch with your upstream tarballs as imported into the upstream branch? I've push some changes on the split-c-f-cxx branch. First I updated the changelog for 4.3.3-rc3, I also updated the watch file to use GitHub releases, and added a gbp.conf to have git-buildpackage use pristine-tar by default. Once the split-c-f-cxx branch is merged back into master the debian-branch in gbp.conf needs to be updated to reflect this. My build of the package produced a lot of lintian issues that need to be addressed. You can see the full list with: `lintian -I --show-overrides --pedantic -E path/to/netcdf.changes`. You should also add yourself to Uploaders field in the control file. The control can also do with a restructuring by cme. See: http://pkg-grass.alioth.debian.org/policy/policy.html#cme I'm willing to help you with some of these issues, but I'm currently also working on updating the grass package for the 7.0 pre-releases. So I'd need to divide my attention a bit more to include netcdf too. Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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/54b81c0d.6090...@xs4all.nl -- 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/CAK6Z60cYNSKZdfJSWPxKOm_Kop1PUiJ=wwpkzt7dnea+ddw...@mail.gmail.com
Re: doc-base errors, documentation installation
`lintian -I --show-overrides --pedantic -E path/to/netcdf.changes`. This doesn't show anything serious for me: ``` $ lintian -I --show-overrides --pedantic -E netcdf_4.3.3~20150116-utopic2_source.changes E: netcdf changes: bad-distribution-in-changes-file utopic P: netcdf source: debian-watch-may-check-gpg-signature ``` What do you get? Cheers, Nico On Fri, Jan 16, 2015 at 10:20 AM, Nico Schlömer nico.schloe...@gmail.com wrote: Can you also update the pristine-tar branch with your upstream tarballs as imported into the upstream branch? Done. `git-import-orig` helped me out here. I've push some changes on the split-c-f-cxx branch. I've created upstream pull requests for the patches you added. Let's see if they make it in for the 4.3.3 release. You should also add yourself to Uploaders field in the control file. Done. http://pkg-grass.alioth.debian.org/policy/policy.html#cme Great tip! I hadn't known about this one. This'll help me out on a number of other projects, too. Thanks! I fixed all errors and warnings in debian/control, except ``` Warning in 'source Vcs-Browser' value 'http://anonscm.debian.org/cgit/pkg-grass/netcdf.git': URL to debian system is not the recommended one ``` No idea what is recommended instead. Can you enlighten me? `lintian -I --show-overrides --pedantic -E path/to/netcdf.changes`. Will look at those later. Cheers, Nico On Thu, Jan 15, 2015 at 8:59 PM, Sebastiaan Couwenberg sebas...@xs4all.nl wrote: On 01/15/2015 07:57 PM, Nico Schlömer wrote: that you still have local changes not pushed to Alioth? Right; fixed now. Thanks for the push! Can you also update the pristine-tar branch with your upstream tarballs as imported into the upstream branch? I've push some changes on the split-c-f-cxx branch. First I updated the changelog for 4.3.3-rc3, I also updated the watch file to use GitHub releases, and added a gbp.conf to have git-buildpackage use pristine-tar by default. Once the split-c-f-cxx branch is merged back into master the debian-branch in gbp.conf needs to be updated to reflect this. My build of the package produced a lot of lintian issues that need to be addressed. You can see the full list with: `lintian -I --show-overrides --pedantic -E path/to/netcdf.changes`. You should also add yourself to Uploaders field in the control file. The control can also do with a restructuring by cme. See: http://pkg-grass.alioth.debian.org/policy/policy.html#cme I'm willing to help you with some of these issues, but I'm currently also working on updating the grass package for the 7.0 pre-releases. So I'd need to divide my attention a bit more to include netcdf too. Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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/54b81c0d.6090...@xs4all.nl -- 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/cak6z60eds_bja6anf-f97hzcimmrrxbvf1rgucehlyzcleg...@mail.gmail.com
Re: doc-base errors, documentation installation
that you still have local changes not pushed to Alioth? Right; fixed now. –Nico On Thu, Jan 15, 2015 at 7:21 PM, Sebastiaan Couwenberg sebas...@xs4all.nl wrote: Hi Nico, On 01/15/2015 09:52 AM, Nico Schlömer wrote: I'd be great if you could have a look at the branch `split-c-f-cxx` on alioth to see if there are any obvious shortcomings. If we can fix those, we should be finally able to upgrade from the several years old 4.1.3. I only find netCDF 4.3.3-rc3 in the upstream branch, but no branch into which it's merged. The split-c-f-cxx branch still lists 4.3.2 in the changelog. 4.3.3-rc3 is also missing from the pristine-tar branch, which makes me suspect that you still have local changes not pushed to Alioth? `git push --all git push --tags` should push all local branches and tags back to Alioth. Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- 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/54b8051e.6030...@xs4all.nl -- 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/cak6z60feerqx93m6gjmeupjmls6bpw0qoi80zu_z7jssmvc...@mail.gmail.com
Re: doc-base errors, documentation installation
Hi Sebastiaan, all, Last night, netCDF 4.3.3-rc3 was released [1] with 4.3.3 to be expected very soon. I've been working on getting it to build with Debian for a while now (mostly pushing things upstream), and I'm thinking we're in a good shape right now. I'd be great if you could have a look at the branch `split-c-f-cxx` on alioth to see if there are any obvious shortcomings. If we can fix those, we should be finally able to upgrade from the several years old 4.1.3. All hints are much appreciated! Cheers, Nico [1] https://github.com/Unidata/netcdf-c/releases [2] http://www.unidata.ucar.edu/downloads/netcdf/netcdf-4_1_3/index.jsp On Thu, Jan 8, 2015 at 4:19 PM, Sebastiaan Couwenberg sebas...@xs4all.nl wrote: I see the file ``` libnetcdf-dev.doc-base ``` in the debian/ folder [1]. I suppose renaming that to ``` netcdf-doc.doc-base ``` will do the trick. Is that your intention, too? Yes. Although the warnings may need to be fixed with additional changes to the file. The Document field produces a warning because it doesn't conform to the specification (see /usr/share/doc/doc-base/doc-base.txt.gz): Legal characters for the document ID are lower case letters (a-z), digits (0-9), plus (+) or minus (-) signs, and dots (.) (the same characters allowed in package names).1 Using the (source) package name instead should fix the warning for the Document field. The paths in to the documentation files also need to be corrected to use /usr/share/doc/netcdf-doc/ instead of /usr/share/doc/netCDF/. Kind Regards, Bas -- 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/19806aa4c1748e9139818b2f86d1154f.squir...@webmail.xs4all.nl -- 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/CAK6Z60fSifowUUToO0ycHS02cTNTN1_MWF9Rai=nt3imev6...@mail.gmail.com
doc-base errors, documentation installation
Hi all! A small question on how to configure a Debian package with proper installation of user documentation. The package I'm looking at is netCDF [1] which – apart from the library and headers – installs the file ``` $ cat /usr/share/doc-base/netCDF Document: netCDF Title: NetCDF Manual Author: Russ Rew, Glenn Davis, Steve Emmerson, Harvey Davies, Ed Hartnett, Dennis Heimbigner, Ward Fisher Abstract: This manual describes what netCDF is, and how it can be used. Section: File Management Format: HTML Index: /usr/share/doc/netCDF/index.html Files: /usr/share/doc/netCDF/*.html ``` and of course a bunch of files in ``` $ ls /usr/share/doc/netCDF/* [...] ``` Up until now, I've always put all files of `/usr/share/doc/netCDF/*` into libnetcdf-doc, and the file `/usr/share/doc-base/netCDF` into the libnetcdf-dev package. With this, however, I'm getting ``` $ install-docs --verbose --check /usr/share/doc-base/netCDF Warning in `/usr/share/doc-base/netCDF', line 1: invalid value of `Document' field. Warning in `/usr/share/doc-base/netCDF', line 9: file `/usr/share/doc/netCDF/index.html' does not exist. Error in `/usr/share/doc-base/netCDF', line 9: all `Format' sections are invalid. ``` The second warning I understand, but I'm not sure how to best fix it. Move `/usr/share/doc-base/netCDF` into the doc package? The first warning and the error I don't understand. Ideas, anyone? Cheers, Nico [1] https://launchpadlibrarian.net/193981161/buildlog_ubuntu-utopic-amd64.netcdf_1%3A4.3.3~20150104-utopic1_UPLOADING.txt.gz -- 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/CAK6Z60fEHG_N9_Hf5iXi=ouav0uafzqqq7znbo3x4ovvdq0...@mail.gmail.com
Re: doc-base errors, documentation installation
I see the file ``` libnetcdf-dev.doc-base ``` in the debian/ folder [1]. I suppose renaming that to ``` netcdf-doc.doc-base ``` will do the trick. Is that your intention, too? –Nico [1] http://anonscm.debian.org/cgit/pkg-grass/netcdf.git/tree/debian?h=split-c-f-cxx On Thu, Jan 8, 2015 at 4:00 PM, Nico Schlömer nico.schloe...@gmail.com wrote: moving the doc-base file to libnetcdf-doc should be the right way forward. Alright, I'll see to that. I wanted to reproduce your problem, but was unable because the source package in git is different from the source you're working with. I'm working in [1], but replace the sources daily (locally) to make sure the next version of netCDF will build correctly, too. Once we have a netCDF release (in about two weeks, if the devs' projection is alright), I'll push it to alioth too. –Nico [1] http://anonscm.debian.org/cgit/pkg-grass/netcdf.git/log/?h=split-c-f-cxx On Thu, Jan 8, 2015 at 1:28 PM, Sebastiaan Couwenberg sebas...@xs4all.nl wrote: Hi Nico, First of all thanks for your work on NetCDF! The package I'm looking at is netCDF [1] which – apart from the library and headers – installs the file ``` $ cat /usr/share/doc-base/netCDF Interestingly there is no doc-base file in the souce package. Do you have local changes not yet available in the git repository? http://anonscm.debian.org/cgit/pkg-grass/netcdf.git Document: netCDF Title: NetCDF Manual Author: Russ Rew, Glenn Davis, Steve Emmerson, Harvey Davies, Ed Hartnett, Dennis Heimbigner, Ward Fisher Abstract: This manual describes what netCDF is, and how it can be used. Section: File Management Format: HTML Index: /usr/share/doc/netCDF/index.html Files: /usr/share/doc/netCDF/*.html ``` and of course a bunch of files in ``` $ ls /usr/share/doc/netCDF/* [...] ``` Up until now, I've always put all files of `/usr/share/doc/netCDF/*` into libnetcdf-doc, and the file `/usr/share/doc-base/netCDF` into the libnetcdf-dev package. With this, however, I'm getting The doc-base file should be in the same package as the documention it references, moving the doc-base file to libnetcdf-doc should be the right way forward. ``` $ install-docs --verbose --check /usr/share/doc-base/netCDF Warning in `/usr/share/doc-base/netCDF', line 1: invalid value of `Document' field. Warning in `/usr/share/doc-base/netCDF', line 9: file `/usr/share/doc/netCDF/index.html' does not exist. Error in `/usr/share/doc-base/netCDF', line 9: all `Format' sections are invalid. ``` The second warning I understand, but I'm not sure how to best fix it. Move `/usr/share/doc-base/netCDF` into the doc package? The first warning and the error I don't understand. Ideas, anyone? I wanted to reproduce your problem, but was unable because the source package in git is different from the source you're working with. Kind Regards, Bas -- 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/dc1865af115c87de23ff214a21d330eb.squir...@webmail.xs4all.nl -- 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/cak6z60f-gfdme0bkjvkojhnxmtud_jzkt1oz_ct8+nimn...@mail.gmail.com
Re: doc-base errors, documentation installation
moving the doc-base file to libnetcdf-doc should be the right way forward. Alright, I'll see to that. I wanted to reproduce your problem, but was unable because the source package in git is different from the source you're working with. I'm working in [1], but replace the sources daily (locally) to make sure the next version of netCDF will build correctly, too. Once we have a netCDF release (in about two weeks, if the devs' projection is alright), I'll push it to alioth too. –Nico [1] http://anonscm.debian.org/cgit/pkg-grass/netcdf.git/log/?h=split-c-f-cxx On Thu, Jan 8, 2015 at 1:28 PM, Sebastiaan Couwenberg sebas...@xs4all.nl wrote: Hi Nico, First of all thanks for your work on NetCDF! The package I'm looking at is netCDF [1] which – apart from the library and headers – installs the file ``` $ cat /usr/share/doc-base/netCDF Interestingly there is no doc-base file in the souce package. Do you have local changes not yet available in the git repository? http://anonscm.debian.org/cgit/pkg-grass/netcdf.git Document: netCDF Title: NetCDF Manual Author: Russ Rew, Glenn Davis, Steve Emmerson, Harvey Davies, Ed Hartnett, Dennis Heimbigner, Ward Fisher Abstract: This manual describes what netCDF is, and how it can be used. Section: File Management Format: HTML Index: /usr/share/doc/netCDF/index.html Files: /usr/share/doc/netCDF/*.html ``` and of course a bunch of files in ``` $ ls /usr/share/doc/netCDF/* [...] ``` Up until now, I've always put all files of `/usr/share/doc/netCDF/*` into libnetcdf-doc, and the file `/usr/share/doc-base/netCDF` into the libnetcdf-dev package. With this, however, I'm getting The doc-base file should be in the same package as the documention it references, moving the doc-base file to libnetcdf-doc should be the right way forward. ``` $ install-docs --verbose --check /usr/share/doc-base/netCDF Warning in `/usr/share/doc-base/netCDF', line 1: invalid value of `Document' field. Warning in `/usr/share/doc-base/netCDF', line 9: file `/usr/share/doc/netCDF/index.html' does not exist. Error in `/usr/share/doc-base/netCDF', line 9: all `Format' sections are invalid. ``` The second warning I understand, but I'm not sure how to best fix it. Move `/usr/share/doc-base/netCDF` into the doc package? The first warning and the error I don't understand. Ideas, anyone? I wanted to reproduce your problem, but was unable because the source package in git is different from the source you're working with. Kind Regards, Bas -- 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/dc1865af115c87de23ff214a21d330eb.squir...@webmail.xs4all.nl -- 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/CAK6Z60f8S-b8mH_Ey4BfkBiUD8QhtnFNQTso13ex=-ujvhw...@mail.gmail.com
Re: doc-base errors, documentation installation
``` $ install-docs --verbose --check /usr/share/doc-base/netcdf /usr/share/doc-base/netcdf: No problems found. ``` Thanks! –Nico On Thu, Jan 8, 2015 at 4:19 PM, Sebastiaan Couwenberg sebas...@xs4all.nl wrote: I see the file ``` libnetcdf-dev.doc-base ``` in the debian/ folder [1]. I suppose renaming that to ``` netcdf-doc.doc-base ``` will do the trick. Is that your intention, too? Yes. Although the warnings may need to be fixed with additional changes to the file. The Document field produces a warning because it doesn't conform to the specification (see /usr/share/doc/doc-base/doc-base.txt.gz): Legal characters for the document ID are lower case letters (a-z), digits (0-9), plus (+) or minus (-) signs, and dots (.) (the same characters allowed in package names).1 Using the (source) package name instead should fix the warning for the Document field. The paths in to the documentation files also need to be corrected to use /usr/share/doc/netcdf-doc/ instead of /usr/share/doc/netCDF/. Kind Regards, Bas -- 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/19806aa4c1748e9139818b2f86d1154f.squir...@webmail.xs4all.nl -- 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/cak6z60cyxs5byh3wyxwc_5lnnrxrj0j6v8ehjqpgc3puvye...@mail.gmail.com
debian/control: architecture restrictions for builds
Hi all, a quick question about architecture restrictions in `debian/control`. I have a large tarball which I configure and compile, and then break up into a number of Debian packages (similar to boost). Unfortunately, one of the components doesn't compile on 32-bit architectures, which means that the entire tarball build fails on 32-bit archs. Now, like I said, `debian/control` lists a number of packages, complete with ``` Package: libmyproject-subpackage-7 Architecture: any Section: libs [...] ``` Restricting the architecture to ``` Package: libmyproject-badsubpackage-7 Architecture: amd64 ``` only for that one subpackage doesn't cut it. Where do place the restriction though? –Nico -- 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/cak6z60ei4wpcedtejdrizqfxjece5rztpkj+psq1ypepdrh...@mail.gmail.com
Re: debian/control: architecture restrictions for builds
[Please please please use concrete package names. It's hard to reason about abstracts like libmyproject-subpackage-7, especially if information needed for a good judgment was missing in the mail, or well hidden between the lines.] That's a good hint; I'll do so in the future. Thanks! –Nico -- 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/cak6z60ejhn+ac0c61dm_r-7+-nbutxkmvxnwvo_7j91myjj...@mail.gmail.com
removing epoch slot
Hi all, the old netCDF package [1] has an epoch slot, 1, which seems entirely unnecessary. For the rewrite, it'd be nice if we could get rid of it. Is that common practice? Is there an upgrade path for it? Cheers, Nico [1] https://packages.debian.org/km/source/sid/mipsel/netcdf -- 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/cak6z60cj2arpgponhmgcwaz70ab3lo2e6rjht1afiamavsy...@mail.gmail.com
Re: removing epoch slot
From the changelog: * added 1: epoch due to old netcdf-doc package having epoch 1: -- Warren Turkal w...@penguintechs.org Thu, 5 Apr 2007 17:42:18 -0600 Aha! Well, that is indeed historical. Not sure what you are referring to by rewrite, but if the all the source/binary package names are different then you will be able to avoid the epoch. Nope, the package names stay the same. I guess then we will have to drag the epoch along with us... :/ --Nico On Tue, Jun 17, 2014 at 3:39 PM, Paul Wise p...@debian.org wrote: On Tue, Jun 17, 2014 at 9:35 PM, Nico Schlömer wrote: the old netCDF package [1] has an epoch slot, 1, which seems entirely unnecessary. For the rewrite, it'd be nice if we could get rid of it. Is that common practice? Is there an upgrade path for it? From the changelog: * added 1: epoch due to old netcdf-doc package having epoch 1: http://metadata.ftp-master.debian.org/changelogs/main/n/netcdf/unstable_changelog Not sure what you are referring to by rewrite, but if the all the source/binary package names are different then you will be able to avoid the epoch. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6ekafwg7zb4pkh4yrqvbkcp8kbd-7pmbht0rxr5tl4...@mail.gmail.com -- 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/CAK6Z60cEEeo4k568_b9t=9O=+Y=kj4wy0jo9+x5negqrdyy...@mail.gmail.com
Re: dh: default cmake options overridden
I had an upstream that was not handling the case when it was set to None properly and I guess you have the same issue. And indeed that was the case. Now fixed upstream. Thanks for the hint! --Nico On Wed, Jun 11, 2014 at 5:44 AM, Paul Wise p...@debian.org wrote: On Wed, Jun 11, 2014 at 2:16 AM, Nico Schlömer wrote: How could I best debug this (through debian/rules, maybe)? grep through the upstream cmake files looking for CMAKE_BUILD_TYPE, I had an upstream that was not handling the case when it was set to None properly and I guess you have the same issue. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/CAKTje6F+XvYB-8KnËat6e6h3hod-xdj-okhdj3a_5ker...@mail.gmail.com -- 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/cak6z60fisqob0qjkpapdipqiuo8ez634mr+sazgbxptdf9+...@mail.gmail.com
Re: dh: default cmake options overridden
As a follow-up on this, when I do
MESSAGE($ENV{CFLAGS})
in a CMakeLists.txt, I'm getting different results on different
Debian/Ubuntu distros.
On Precise (12.04), I'm seeing
```
-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security
```
on Trusty (14.04), I'm seeing
```
```
(nothing).
Is this expected?
Cheers,
Nico
On Wed, Jun 11, 2014 at 10:26 AM, Nico Schlömer
nico.schloe...@gmail.com wrote:
I had an upstream that was not handling the case when it was set to None
properly and I guess you have the same issue.
And indeed that was the case. Now fixed upstream. Thanks for the hint!
--Nico
On Wed, Jun 11, 2014 at 5:44 AM, Paul Wise p...@debian.org wrote:
On Wed, Jun 11, 2014 at 2:16 AM, Nico Schlömer wrote:
How could I best debug this (through debian/rules, maybe)?
grep through the upstream cmake files looking for CMAKE_BUILD_TYPE, I
had an upstream that was not handling the case when it was set to None
properly and I guess you have the same issue.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
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/CAKTje6F+XvYB-8KnËat6e6h3hod-xdj-okhdj3a_5ker...@mail.gmail.com
--
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/cak6z60f_9dzv7p_zfw-zqjmyvmuwsy4ostiyzapkg0bx30s...@mail.gmail.com
dh: default cmake options overridden
Hi all, if I understand correctly from [1], the default CMAKE_BUILD_TYPE used by dh should be RelWithDebInfo. I found that, when override_dh_auto_configure is not empty in debian/rules, e.g, override_dh_auto_configure: dh_auto_configure -- \ -DCMAKE_SKIP_RPATH:BOOL=ON -DENABLE_TESTS:BOOL=OFF the build type setting is discarded as well. Manually adding -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo helps of course. Is that something that is expected and intended? Are there other default flags that need to be added, or is there a way to add CMake variables without disturbing unrelated default settings? Cheers, Nico [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701233 -- 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/CAK6Z60cLQLGOF4GnNs13pRFd48BTGnyQ9VfU=u5vx7fpwkg...@mail.gmail.com
Re: dh: default cmake options overridden
It seems that, instead of the suggestion originally posted in [1], Debian's default CMake setting is `-DCMAKE_BUILD_TYPE=None`, and the specific flags are controlled by the environment variables (CFLAGS and friends). Now, Debian policy [2] advocates `-O2 -g -Wall` for compiling. Somehow, though, those flags don't end up on my compile lines [3]. How could I best debug this (through debian/rules, maybe)? Cheers, Nico [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701233 [2] https://www.debian.org/doc/debian-policy/ch-files.html#s-binaries [3] https://launchpadlibrarian.net/177295900/buildlog_ubuntu-utopic-amd64.netcdf_1%3A4.3.3~20140610-utopic1_UPLOADING.txt.gz On Tue, Jun 10, 2014 at 7:51 PM, Nico Schlömer nico.schloe...@gmail.com wrote: Hi all, if I understand correctly from [1], the default CMAKE_BUILD_TYPE used by dh should be RelWithDebInfo. I found that, when override_dh_auto_configure is not empty in debian/rules, e.g, override_dh_auto_configure: dh_auto_configure -- \ -DCMAKE_SKIP_RPATH:BOOL=ON -DENABLE_TESTS:BOOL=OFF the build type setting is discarded as well. Manually adding -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo helps of course. Is that something that is expected and intended? Are there other default flags that need to be added, or is there a way to add CMake variables without disturbing unrelated default settings? Cheers, Nico [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701233 -- 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/CAK6Z60fmoZAvSju-fNs=temqirjee-kquche5gmss-r3qib...@mail.gmail.com
package cmake build, shared and static libs
Hi all, I'd like to create a library package using dh with CMake, and I would like the build process to produce the library both statically and dynamically linked. CMake's rationale here is: Recompile the whole thing, because: In practice, most libraries have different defines and compiler flags for the shared vs. static cases. So you would have to build all your library objects twice anyways. http://www.cmake.org/Wiki/CMake_FAQ#Can_I_build_both_shared_and_static_libraries_with_one_ADD_LIBRARY_command.3F There are ways for building both versions, but they involve either (a) patching the CMake files of the package or (b) calling cmake twice (with BUILD_SHARED_LIBS:ON and BUILD_SHARED_LIBS:OFF, respectively). Patching is certainly not preferable, so I guess I'll have to go with (b). Are there other options? This seems to be a rather common task. Is there (or should there) be functionality for this in `dh`? Cheers, Nico -- 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/cak6z60fkualohrucpy8x14qc2-nzgpjacfkuxm05oqap8qv...@mail.gmail.com
force CMake over automake
Hi all, I've got a package here that supports both Cmake and automake configurations. How do I force the builder to use CMake in debian/rules? Cheers, Nico -- 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/cak6z60cohgczx_4elr-1hvf1ecy2kgsdmdrgevsq0oqcymt...@mail.gmail.com
Re: force CMake over automake
That works, thanks Daniel! --Nico On Thu, May 8, 2014 at 5:26 PM, Daniel Lintott dan...@serverb.co.uk wrote: Hi Nico, On 08/05/14 16:21, Nico Schlömer wrote: Hi all, I've got a package here that supports both Cmake and automake configurations. How do I force the builder to use CMake in debian/rules? From experimenting with a package very similar to the scenario your in I found the following worked: In debian/rules: dh $@ --buildsystem=cmake Regards, -- Daniel Lintott GPG Key: 4096R/5D73EC6E -- 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/CAK6Z60c+Rr=jsahemaob4laxf08nqn1nwstp+pkat6iths3...@mail.gmail.com
Re: CMake multiarch installation
INCLUDE(GNUInstallDirs) Thanks for the hint! Is this something that one would typically patch in on a Debian level or would it make sense to try and push this upstream as well? Cheers, Nico On Mon, May 5, 2014 at 4:19 PM, Gert Wollny gw.foss...@gmail.com wrote: On Mon, 2014-05-05 at 16:06 +0200, Nico Schlömer wrote: Does anyone have hints about how Debian manages to slip in the x86_64-linux-gnu part in the library install path? You have to add INCLUDE(GNUInstallDirs) to the CMakeLists.txt and use the according variables in the install command. cf: http://www.cmake.org/cmake/help/v2.8.12/cmake.html#module:GNUInstallDirs hope that helps, Gert -- 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/cak6z60cttametnedtqpbrfw4ppl6hut2ahvlnxhtocjwpny...@mail.gmail.com
Trilinos: to split or not to split
Hi all, I would like to hear your opinion on the following question: I'm packaging a rather large software, Trilinos, a collection of libraries (libbelos, libml, libaztecoo,...) for numerical high-performance computing. Upstream supports monolithic builds, i.e., the collection of libraries is assumed to be fully present on the system, and the user picks out what parts of it he or she wants to use. This makes for a very simple debian/rules and debian/control, cf. https://github.com/nschloe/debian-trilinos/blob/803866a4d552aced1e4b019f1be32217245ce7f4/debian/rules. Downsides of this include the size of the package, and the fact that the package name trilinos does not correspond with the library names (libbelos.*, libml.*,...). Given its subpackage structure, Felix helped out creating a packaging format that splits the build up into subpackages. Debian's shlibs magic takes care of the dependency hierarchy, but a couple of things problems need to be worked around https://github.com/nschloe/debian-trilinos/blob/split/debian/rules. Which approach is better suited for Debian in your opinion? Cheers, Nico -- 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/CAK6Z60fUwHeS+ADHe--q=0s2rf+zyucr_+sxlaeuhp94yu3...@mail.gmail.com
.la, .a files
Hi all, if a packages produces static libraries .a, .la, do they belong in liba or liba-dev? Cheers, Nico -- 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/CAK6Z60fCgGyco7q+C41n=pe_uQz+9zHuavgUPFSDh31W=uc...@mail.gmail.com
dh_installdocs: README.md
Hi all, dh_installdocs fails on me because the software has no file README, but README.md. ``` cp -a README debian/libnetcdfcxx/usr/share/doc/libnetcdfcxx cp: cannot stat 'README': No such file or directory ``` How to adapt debian/rules to accommodate for this? Cheers, Nico -- 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/cak6z60fdq2w2q9zaf7iazhv+dkqxexrlkjqgcgu6er1ct+w...@mail.gmail.com
dh, autoreconf, remember to run libtool --finish
Hi all, I'm packaging a project that uses autoreconf and on my local machine configures and builds fine with default options throughout. With the minimal debian/rules file https://github.com/nschloe/launchpad-submitter/blob/master/debian-netcdfcxx/rules, it all seems to work out fine. However, at the installation step, I get libtool: install: warning: remember to run `libtool --finish /usr/lib/x86_64-linux-gnu' [...] and the actual .a and .so files are not put where they belong. This leads to a failure at dh_install, https://launchpadlibrarian.net/171725911/buildlog_ubuntu-trusty-amd64.netcdfcxx_1%3A4.2.1~20140403-trusty3_FAILEDTOBUILD.txt.gz. Any idea what's going wrong here? Cheers, Nico -- 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/CAK6Z60dGQ6aEkicysOwnc+nf_gqp6N1fr=i8eJx9=eaioyd...@mail.gmail.com
Re: netcdf packages
Everything that is interesting in the current netcdf-bin is included in the C-library of netCDF. The only binaries included in the C++ and Fortran builds are configuration assistants that are losing their significance in the new CMake builds anyways. Hence, I'd say it's reasonable to make netcdfc-bin the new netcdf-bin. Cheers, Nico On Sat, Mar 29, 2014 at 8:37 AM, Eric L. ewl+debian+nospam2...@lavar.de wrote: Hi, On 28 March 2014 09:20:01 CET, Dominique Dumont d...@debian.org wrote: On Thursday 27 March 2014 22:21:55 Nico Schlömer wrote: The question is: how to avoid breaking the above package when upgrading netcdf to netcdf-c, netcdf-fortran, netcdf-cxx ? What about declaring netcdf-bin as dummy package depending on the 3 new ones, and ask (or file bugs against) the dependent package(r)s to change their dependencies. Eric I'm on debian-java, java maintainers, vdr maintainers and debian-mentors; no need to CC me on these lists. Thanks! -- 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/27a60a5d-44f9-41c2-b45e-52be470bf...@email.android.com -- 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/CAK6Z60fCu0eBoQz7Oqmy4RY=q6nnue6re4d605bikupdo8u...@mail.gmail.com
netcdf packages
Hi all, the Debian packages for netCDF http://www.unidata.ucar.edu/software/netcdf/ are currently at 4.1.3, a version released some three years ago http://www.unidata.ucar.edu/software/netcdf/release-notes-4.1.3.html. A bug report was filed against this a few months back https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735075, but no one stepped up to the task yet. The reason why the upgrade is not a trivial one is that the means of distribution of netCDF have changed somewhat. Fortran, C, and C++ interfaces used to be distributed in one source package netcdf, controlled by configuration options. Now, C, Fortran, and C++ interfaces are distributed in separate source packages. The C source works standalone, Fortran and C++ versions are interface packages. The question remains on how we can move this forward in a sensible way. One possibility is to split the existing netcdf package into three separate ones netcdf-c, netcdf-fortran, netcdf-cxx, to reflect the upstream structure. What is your opinion on this? To help the process, I've integrated a number of patches to netcdf-c upstream https://github.com/unidata/netcdf-c that fix the build system to work properly with Debian unstable/testing. Proof-of-concept debian packaging of netcdf-c is available from https://github.com/nschloe/netcdf-ubuntu/, built nightly on https://launchpad.net/~nschloe/+archive/netcdf-nightly/+packages. Cheers, Nico -- 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/CAK6Z60eydWNd5n1BXuifMtXbV=_zdr73q6qb+pxybuxvjvw...@mail.gmail.com
Re: library linking, missing libB.so
I consider this as an important[*] bug. People should not
know about the low level LAPACK/ BLAS implementation.
That's right. I already checked back with the CMake crowd (the
critical lines are automatically created by CMake) and we might find
ourselves in a little bit of a tricky situation here: If a library
libA is merely linked against libB, we of course don't want to know
about the implementation details of libB.
If the headers in libA-dev include something of libA-dev though,
libA-dev should depend on libB-dev. Correct?
If the headers of libB-dev only appear in the sources of libA, i.e.,
libA doesn't provide an interface to libB, libA-dev should *not*
depend on libB-dev. Correct?
Right now, the dependency structure in debian/control looks like
libA:
Depends: ${shlibs:Depends}, ${misc:Depends}
libA-dev:
Depends: libA (= ${binary:Version}), ${shlibs:Depends},
${misc:Depends}, libB-dev
Would you consider this sane? Will whatever magic acts in
${shlibs:Depends}, ${misc:Depends} be able to identify libB as a
dependency of libA?
Cheers,
Nico
On Mon, Mar 24, 2014 at 11:29 AM, Mathieu Malaterre ma...@debian.org wrote:
On Mon, Mar 24, 2014 at 11:18 AM, Nico Schlömer
nico.schloe...@gmail.com wrote:
Thanks for the hints!
If you have access to upstream source, simply set the target properties
with:
set_properties(target LINK_INTERFACE_LIBRARIES )
I might. The culprit right now are CMake property settings of the kind
```
set_target_properties(teuchosnumerics PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_RELWITHDEBINFO
teuchoscomm;teuchoscore;/usr/lib/liblapack.so;/usr/lib/libblas.so
IMPORTED_LOCATION_RELWITHDEBINFO
${_IMPORT_PREFIX}/lib/libteuchosnumerics.so.11.7
IMPORTED_SONAME_RELWITHDEBINFO libteuchosnumerics.so.11
)
```
where references to /usr/lib/liblapack.so (from lapack-dev) appear
needlessly. Those files are created automatically by CMake, but I'll
check if we can influence those in any way. Otherwise I'll just patch
the export files directly.
I would suggest you report this as a bug to 'teuchosnumerics' debian
package. I consider this as an important[*] bug. People should not
know about the low level LAPACK/ BLAS implementation.
[*] Technically this would make your package FTBFS in some case, so
severity 'serious' could even be used.
--
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/CAK6Z60fobTBTJQ=sevxinfvcdyce9ug6zfxv1o9zrljr-0x...@mail.gmail.com
Re: library linking, missing libB.so
Thanks for the hints!
If you have access to upstream source, simply set the target properties with:
set_properties(target LINK_INTERFACE_LIBRARIES )
I might. The culprit right now are CMake property settings of the kind
```
set_target_properties(teuchosnumerics PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES_RELWITHDEBINFO
teuchoscomm;teuchoscore;/usr/lib/liblapack.so;/usr/lib/libblas.so
IMPORTED_LOCATION_RELWITHDEBINFO
${_IMPORT_PREFIX}/lib/libteuchosnumerics.so.11.7
IMPORTED_SONAME_RELWITHDEBINFO libteuchosnumerics.so.11
)
```
where references to /usr/lib/liblapack.so (from lapack-dev) appear
needlessly. Those files are created automatically by CMake, but I'll
check if we can influence those in any way. Otherwise I'll just patch
the export files directly.
Cheers,
Nico
On Mon, Mar 24, 2014 at 10:12 AM, Mathieu Malaterre ma...@debian.org wrote:
On Sat, Mar 22, 2014 at 1:31 PM, Nico Schlömer nico.schloe...@gmail.com
wrote:
No, the 'linker' does not complain.
You're right, it is the CMake dependency checker. The linking is all
right, but there's something amiss with the CMake export files. I'll
investigate.
I think you should find online reference with those keywords cmake
transitive linking debian
If you have access to upstream source, simply set the target properties with:
set_properties(target LINK_INTERFACE_LIBRARIES )
--
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/cak6z60fssu+yb_bxzgrmrfciwrr+s5qsvas-jjhfxj_rd0e...@mail.gmail.com
Re: library linking, missing libB.so
No, the 'linker' does not complain. You're right, it is the CMake dependency checker. The linking is all right, but there's something amiss with the CMake export files. I'll investigate. Thanks for the comments! --Nico On Thu, Mar 20, 2014 at 3:31 PM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: Hi On 3/20/14, Nico Schlömer nico.schloe...@gmail.com wrote: I'm building a package for a library A that depends on another library, libB.so (from its dev-version). When installing library A, the package libb is installed, containing libB.so.7.2 and libB.so.7. When linking an executable against libA.so, the linker rightfully complains about a missing libB.so. No, the 'linker' does not complain. What is the correct fix here? You should check your build system. It seems to be broken. libB is an implementation details of libA. Application programmer linking to libA should *not* know about those low level technical details. Unless of course explicitely stated in the documentation and/or provided in the *.pc file (or cmake exported file). So unless you know what you are doing libB should not appear on the link line. In any case if you have an application using libA API, but complains about missing libB symbols, you have a case where libA is underlinked which is a serious issue and should not happen in debian package. -- 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/CAK6Z60etkwiZ-x-Z3dzhzORx04XV4fHscDt=fhdn9nfvrqe...@mail.gmail.com
header-only dependence
Hi all, I'm packaging a library libA which depends on a header-only library libB. Obviously I need libB to be present whenever I build an executable against libA. Where in debian/control will I have to fill in libB? Cheers, Nico -- 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/CAK6Z60foOwBy=-yk8hcjcncmtrw9avsntmuh0_jiwrw36b+...@mail.gmail.com
Re: header-only dependence
I'm packaging a library libA which depends on a header-only library libB. How? libA's CMake build script checks for libB and the public headers of libA #include libB headers. --Nico On Sat, Mar 22, 2014 at 2:21 PM, Andrey Rahmatullin w...@wrar.name wrote: On Sat, Mar 22, 2014 at 01:33:25PM +0100, Nico Schlömer wrote: I'm packaging a library libA which depends on a header-only library libB. How? -- WBR, wRAR -- 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/CAK6Z60eBtz8d88LF=WFyv=tkenprmcxxrcm0dcn4apf-5m4...@mail.gmail.com
Re: public extension linked with libpython* vs. -Wl,-no-undefined
Actually, you usually don't get these kind of warnings for Python extension modules. The warning is emitted only if a module has SONAME, and it typically doesn't. You might want to get rid of SONAMEs That indeed was the problem. Thanks! It's a CMake/SWIG build, and I now added a patch to set the NO_SONAME property to TRUE. All warnings are gone. --Nico On Tue, Mar 18, 2014 at 11:45 AM, Jakub Wilk jw...@debian.org wrote: * Russ Allbery r...@debian.org, 2014-03-17, 19:12: Understood, thanks! I'll just ignore the warnings of the type ``` dpkg-shlibdeps: warning: debian/python-pytrilinos/usr/lib/python2.7/dist-packages/PyTrilinos/NOX/_Abstract.so contains an unresolvable reference to symbol PyString_FromFormat: it's probably a plugin. ``` then. Yes. The it's probably a plugin part is basically trying to tell you to ignore this as long as the message is correct and it is a plugin. Python, PHP, and Apache modules all generally get this warning. Actually, you usually don't get these kind of warnings for Python extension modules. The warning is emitted only if a module has SONAME, and it typically doesn't. You might want to get rid of SONAMEs. But if fixing it turns out to be difficult, as Russ said, it's safe to ignore the warnings. -- Jakub Wilk -- 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/20140318104519.gd6...@jwilk.net -- 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/cak6z60f_kjjttjdohsaty_icvmkraiyymfr6cpxdhmq0b92...@mail.gmail.com
library linking, missing libB.so
Hi all, I'm building a package for a library A that depends on another library, libB.so (from its dev-version). When installing library A, the package libb is installed, containing libB.so.7.2 and libB.so.7. When linking an executable against libA.so, the linker rightfully complains about a missing libB.so. What is the correct fix here? Cheers, Nico -- 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/cak6z60c8yc17yqufc-8b-dhpxzhqnfkif3sqq2ecrc54n5+...@mail.gmail.com
Re: library linking, missing libB.so
which must depend on libB-dev.
libB-dev is indeed not explicitly listed as a dependency of libA-dev,
mostly because I was under the impression that ${shlibs:Depends} takes
care of this, cf. https://wiki.debian.org/IntroDebianPackaging. Is
that not the case?
Cheers,
Nico
On Thu, Mar 20, 2014 at 1:54 PM, Thibaut Paumard mlotpot.n...@free.fr wrote:
Le 20/03/2014 13:22, Nico Schlömer a écrit :
Hi all,
I'm building a package for a library A that depends on another
library, libB.so (from its dev-version). When installing library A,
the package libb is installed, containing libB.so.7.2 and libB.so.7.
When linking an executable against libA.so, the linker rightfully
complains about a missing libB.so.
What is the correct fix here?
Install libA-dev, which must depend on libB-dev.
Regards, Thibaut.
Cheers,
Nico
--
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/532ae4f5.1000...@free.fr
--
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/cak6z60ebmars2akfhvik_rgg5zunpj-pv+g9hjq29qsn2pz...@mail.gmail.com
public extension linked with libpython* vs. -Wl,-no-undefined
Hi all, I'm building a package with Python support and would like to reduce the number of warnings that dh_python2 gives me. One of them is public extension linked with libpython2.7 for a number of libraries. It is true that libpython2.7 is linked into them, $ readelf -d /path/to/_ML.so [...] 0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0] [...] but when I don't, builds with -Wl,-no-undefined will fail. What is the reason for discouraging explicit links with libpython*? Cheers, Nico -- 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/CAK6Z60evTKYA_=x8-k_y2z6ybvlceg7t8rp6dwfx79ysuxw...@mail.gmail.com
Re: public extension linked with libpython* vs. -Wl,-no-undefined
Understood, thanks! I'll just ignore the warnings of the type ``` dpkg-shlibdeps: warning: debian/python-pytrilinos/usr/lib/python2.7/dist-packages/PyTrilinos/NOX/_Abstract.so contains an unresolvable reference to symbol PyString_FromFormat: it's probably a plugin. ``` then. Cheers, Nico On Mon, Mar 17, 2014 at 6:28 PM, Jakub Wilk jw...@debian.org wrote: * Nico Schlömer nico.schloe...@gmail.com, 2014-03-17, 15:49: I'm building a package with Python support and would like to reduce the number of warnings that dh_python2 gives me. One of them is public extension linked with libpython2.7 for a number of libraries. It is true that libpython2.7 is linked into them, $ readelf -d /path/to/_ML.so [...] 0x0001 (NEEDED) Shared library: [libpython2.7.so.1.0] [...] but when I don't, builds with -Wl,-no-undefined will fail. What is the reason for discouraging explicit links with libpython*? The fundamental reason is that, except in unusual circumstances, this library won't be used. Python Policy §2.1 reads: some distributions link extensions to libpython, but this is not the case in Debian as symbols might as well be resolved by '/usr/bin/pythonX.Y' which is not linked to libpython. In the past there used to be also a strong practical reason against linking to libpython: every ELF dependency on libpython2.X was translated by dpkg-shlibdeps to package dependency on python2.X, which typically meant that your package ended up depending on multiple different Python versions. But theses days there's only one supported Python (2.X) version, so this is not such a big deal. BTW, there's a greater chance to meet a Python expert on debian-python@ than here. :-P -- Jakub Wilk -- 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/20140317172837.ga...@jwilk.net -- 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/cak6z60cfgb00mn3saor8hgsaeksvbkla0efgndqqsk-vhrx...@mail.gmail.com
