Bug#652527: pbuilder: No hook option for after .debs are written
I would really like to see this feature added. I have a similar setup to #5 using Jenkins/pbuilder and it would be great to have hooks that can execute after the results are written. I've locally added executehooks H near the end of pbuilder-buildpackage, which is working well for me. Jonathan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
On 10/14/12 21:56, Reinhard Tartler wrote: Something like this commit should do the trick: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/x264.git;a=commitdiff;h=ceab497a30560db9db7bf6ded594400f76a2686a This is not finished, though. It still needs documentation in README.Debian. I'm also thinking about included a wrapper script that sets LD_LIBRARY_PATH. And it is of course totally untested, so feedback more than welcome. I've built this package and can confirm that the library works using a dlopen() approach. I was wondering about pkg-config support for the 10 bit library, a second .pc file looks like it could come from a bit of search/replace on the original. Regards, Jonathan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667573: [x264-devel] Bug#667573: x264: 10 bit builds
On 10/17/12 09:28, Reinhard Tartler wrote: The fact that Jonathan confirms that dlopen()'ing the second library works confirms that both libraries are ABI compatible for practical reasons. Jonathan, what problem would a 2nd pkg-config file solve? There were a few things that were in my mind, primarily around writing portable code: * Detect the presence of the 10 bit version in a configure.ac (the version number won't tell you this) * Retrieve the location to dlopen() from (will every distro put it in the same place?) Anyway - maybe I'm getting ahead of myself and simply having the 10 bit version available is good enough. I'm very happy that it now builds in the official package. Regards, Jon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667573: x264: 10 bit builds
On 13/10/12 04:59, Reinhard Tartler wrote: Oh I see what you did there. I don't think that's gonna work in debian. TBH, I think we should just install the 10 bit libx264.so binary into the regular libx264-NN package and document it properly in ./usr/share/doc/libx264-NN/README.Debian. On the second thought, we could even install some wrapper into /usr/bin that starts the passed on argument with proper LD_LIBRARY_PATH. In any case, I don't see the point in adding new source or binary packages. Trouble is, when you do a 10 bit build you end up with a library of the same name and installing to the same location as the 8 bit one. I'm no expert on the debian packaging, but I could not see a way of renaming the 10 bit .so (dh_install won't do it). There might well be a neat way of achieving this. You have to re-run the configure script with different options to create the 10 bit version, and that's well beyond what I know how to do in the rules file. Regards, Jonathan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667573: x264: 10 bit builds
On 10/11/12 21:07, Jason Garrett-Glaser wrote: Would dlopen() work to hack around this sort of limitation? I recall seeing a hack for x264cli that allowed both 8-bit and 10-bit encoding by doing this. Jason Certainly a dlopen() approach works adequately for me now. It is just that my approach to generating an installable package is ugly. I had considered two different approaches, 1) Install a parallel build of x264 in a new directory hierarchy and knowing that path, open the .so with dlopen(). 2) Try to modify the configure scripts and makefile to in order to produce libx264-10bit.so that could be placed in the usual install location alongside the 8 bit version. The name of the built libraries could be controlled by a configure option. You would still need a dlopen() based approach in some cases but the location of the library would no need to be specified. I ended up doing 1) simply because it was easier, but I feel that 2) might actually be a better solution, as everything could live in standard locations. Regards, Jonathan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667573: x264: 10 bit builds
On 10/12/12 09:15, Nicolas George wrote: Le primidi 21 vendémiaire, an CCXXI, Fabian Greffrath a écrit : How about Debian's alternatives system? I think it is easier to use and more consistent than a LD_LIBRARY_PATH hack. AFAIK, the alternative system requires root privileges to change the selected alternative, whereas LD_LIBRARY_PATH can be changed by any user on a per-encode basis. Several encodes can be started with different LD_LIBRARY_PATH, and therefore different bit depth. The only limitation with that system is that a single process is limited to a single bit depth. Of course, the alternative system could be used on top of that, to allow to configure the default bit depth, when no LD_LIBRARY_PATH is specified. I agree. There are different cases here, mine was the most complex where I need to decide at runtime if 8 or 10 bit was needed. As others have said this can be achieved by using a suitable arrangement of dlopen() to select the required library. From a debian packaging point of view, the key thing is what is the correct way to package up and install the 10 bit version alongside the 8 bit. From an x264 perspective, is there anything that needs to be done to the build system to support this in a clean way. Regards, Jonathan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667573: x264: 10 bit builds
On 10/12/12 03:41, Reinhard Tartler wrote: I do not know about x264cli, but I can confirm that if ffmpeg is dynamically linked with libx264.so.$version, then using LD_LIBRARY_PATH to control which build is loaded allows to select between 8-bits and 10-bits at run-time. That's indeed something that I could do in the Debian package: Install a regular libx264.so in /usr/lib, and a 10bit in /usr/lib/x264-10bit/libx264.so in addition, and document how to use it in some README.Debian file. Not really nice, but I guess better than nothing. Thanks for pointing out this option. Here is my somewhat incomplete attempt at doing just that. It was more involved than I expected. https://github.com/jrosser/x264-10bit-deb Regards, Jonathan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667573: x264: 10 bit builds
It would be really good to get a proper solution to this. I currently require 8 bit and 10bit of x264 to be available to the same application at the same time. A typical use case would be simultaneously encoding 10bit 4:2:2 and 8 bit 4:2:0 versions of the same source video, this cannot be achieved with linkage to a single x264 library. [Alternatively an application that can encode in either 8 or 10 bit modes is equally difficult to write] I have resorted to building my own custom .deb for the 10 bit version which installs to /usr/x264-10bit/... then a plug-in architecture and dlopen() allow one executable to dynamically link against both the 8 and 10bit versions and keep both sets of symbols isolated from each other. This is all fairly horrible, but works I don't see the 8 or 10 bit versions as been alternatives (overloaded terminology, sorry!), I need them to be able to co-exist. Anyway, just some input to help define what might be useful for a 10bit x264 package. Jonathan Rosser Lead Research Engineer BBC Research Development -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667573: x264: 10 bit builds
On 11/10/12 21:07, Jason Garrett-Glaser wrote: It'd be very difficult to do this; we'd effectively have to version every single symbol so that they don't collide, then template all the appropriate code. It'd be a lot of work and I don't know anyone willing to do it. Indeed - that would be a mammoth task. Jonathan, until tihs is resolved, I would suggest you to compiled x264 as static library and link your applications against that build. Inconvenient, but I don't see a better solution right now. Would dlopen() work to hack around this sort of limitation? I recall seeing a hack for x264cli that allowed both 8-bit and 10-bit encoding by doing this. I'm doing a dlopen() trick now and it works very well for my case. The reason I replied to the original Debian bug report is that I consider what I've done to be a bit of an ugly hack. (My packages install a parallel version of x264 into /usr/x264-10bit/). It would be good to come up with a way of installing the 8 and 10 bit versions properly alongside each other. I had considered modifying the configure script to allow the name of the built libraries to be changed via a configure flag. I'd have provided an alternative name for the 10 bit build. Anyway - It is interesting to consider what the right thing to do is, and how applications that want to do 8 or 10 bit interchangeably should be constructed. Regards, Jonathan. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678508: libpion-net-dev: internal dependancies are exposed via the pkg-config Libs: line
Package: libpion-net-dev Version: internal dependancies exposed via pkg-config Severity: important libpion-net-dev exposes all of the internal dependancies of the pion-net library through its pkgconfig file, this is a case of overlinking. See *.private in man pkg-config. pkg-config --libs pion-net -Wl,-z,defs -pthread -Wl,-E -lpthread -ldl -licui18n -licuuc -licudata -lboost_thread-mt -lboost_system-mt -lboost_filesystem-mt -lboost_regex-mt -lboost_date_time-mt -lboost_signals-mt -lboost_iostreams-mt -lssl -lcrypto -lz -lbz2 -llog4cpp -lpion-common -lpion-net As can be seen in the system information below, the dependancies of libpion-net-dev are insufficient to satisfy the linker flags presented by pkg-config. Here is an example failed build from pbuilder of a project which links against pion-net: CXXLD ipp_sdicapture /usr/bin/ld: cannot find -licui18n /usr/bin/ld: cannot find -licuuc /usr/bin/ld: cannot find -licudata /usr/bin/ld: cannot find -lboost_system-mt /usr/bin/ld: cannot find -lboost_filesystem-mt /usr/bin/ld: cannot find -lboost_regex-mt /usr/bin/ld: cannot find -lboost_signals-mt /usr/bin/ld: cannot find -lboost_iostreams-mt /usr/bin/ld: cannot find -lbz2 collect2: ld returned 1 exit status The dependancies shown in the system information below do not install the those libraries, some are simply missing icui18n, icuuc, icudata, bz2 others look wrong: dpkg -L libboost-system1.46.1 /. /usr /usr/lib /usr/lib/libboost_system.so.1.46.1 /usr/share /usr/share/doc /usr/share/doc/libboost-system1.46.1 /usr/share/doc/libboost-system1.46.1/NEWS.Debian.gz /usr/share/doc/libboost-system1.46.1/copyright /usr/share/doc/libboost-system1.46.1/README.Debian.gz /usr/share/doc/libboost-system1.46.1/changelog.Debian.gz /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/libboost-system1.46.1 libboost_system1.46.1 does not contain the actual shared library, or depend on a package that does. Therefore in a pbuilder environment, the boost shared libs do not get installed, and the build fails as shown above. I think there are two problems: 1) Too much information about internal libraries is leaked through the pkg-config file 2) The libpion-net-dev dependencies are incompatible with the information in the pkg-config file. The leaked internal libraries are not installed, so linkage fails for builds of packages that use pion-net in clean environments such as pbuilder. -- System Information: Debian Release: 6.0.5 APT prefers stable APT policy: (700, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpion-net-dev depends on: pn libboost-date-time1.42 none(no description available) pn libboost-filesystem1.4 none(no description available) ii libboost-iostreams1.42 1.42.0-4 Boost.Iostreams Library pn libboost-regex1.42.0 none(no description available) pn libboost-signals1.42.0 none(no description available) pn libboost-system1.42.0 none(no description available) pn libboost-thread1.42.0 none(no description available) ii libbz2-1.0 1.0.5-6+squeeze1 high-quality block-sorting file co ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libgcc11:4.4.5-8 GCC support library pn libpion-common-3.0 none(no description available) pn libpion-common-dev none(no description available) pn libpion-net-3.0none(no description available) ii libssl0.9.80.9.8o-4squeeze12 SSL shared libraries ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime libpion-net-dev recommends no packages. Versions of packages libpion-net-dev suggests: pn libpion-net-doc none (no description available) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678433: libpion-net-dev: missing dependancy on liblog4cpp5-dev
Package: libpion-net-dev Severity: important Building an application which links against pion-net, using libpion-net-dev results in an error like CXXlib_ipp_apps_common_la-process_common.lo In file included from /usr/include/pion/net/TCPServer.hpp:20:0, from /usr/include/pion/net/HTTPServer.hpp:22, from /usr/include/pion/net/WebServer.hpp:21, from webapi.h:11, from process_common.cpp:22: /usr/include/pion/PionLogger.hpp:150:32: fatal error: log4cpp/Category.hh: No such file or directory This is because PionLogger.hpp includes the log4cpp header, and liblog4cpp5-dev is not a dependancy of libpion-net-dev. This error is particularly troublesome when using tools such as pbuilder to build packages that make use of pion-net. Debian Release: 6.0.5 APT prefers stable APT policy: (700, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpion-net-dev depends on: pn libboost-date-time1.42 none(no description available) pn libboost-filesystem1.4 none(no description available) ii libboost-iostreams1.42 1.42.0-4 Boost.Iostreams Library pn libboost-regex1.42.0 none(no description available) pn libboost-signals1.42.0 none(no description available) pn libboost-system1.42.0 none(no description available) pn libboost-thread1.42.0 none(no description available) ii libbz2-1.0 1.0.5-6+squeeze1 high-quality block-sorting file co ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libgcc11:4.4.5-8 GCC support library pn libpion-common-3.0 none(no description available) pn libpion-common-dev none(no description available) pn libpion-net-3.0none(no description available) ii libssl0.9.80.9.8o-4squeeze12 SSL shared libraries ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime libpion-net-dev recommends no packages. Versions of packages libpion-net-dev suggests: pn libpion-net-doc none (no description available) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678435: libpion-net-dev: missing dependancy on libssl-dev
Package: libpion-net-dev Severity: important libpion-net-dev does not depend on libopenssl-dev CXXlib_ipp_apps_common_la-process_common.lo In file included from /usr/include/boost/asio/ssl/context_base.hpp:20:0, from /usr/include/boost/asio/ssl/basic_context.hpp:25, from /usr/include/boost/asio/ssl.hpp:18, from /usr/include/pion/net/TCPConnection.hpp:18, from /usr/include/pion/net/TCPServer.hpp:22, from /usr/include/pion/net/HTTPServer.hpp:22, from /usr/include/pion/net/WebServer.hpp:21, from webapi.h:11, from process_common.cpp:22: /usr/include/boost/asio/ssl/detail/openssl_types.hpp:19:26: fatal error: openssl/conf.h: No such file or directory Files included in pion-net from boost eventually include openssl/conf.h, which is provided by libopenssl-dev. This prevents building of packages that use pion-net with tools such as pbuilder as libssl-dev is not correctly installed into the pbuilder environment. Debian Release: 6.0.5 APT prefers stable APT policy: (700, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libpion-net-dev depends on: pn libboost-date-time1.42 none(no description available) pn libboost-filesystem1.4 none(no description available) ii libboost-iostreams1.42 1.42.0-4 Boost.Iostreams Library pn libboost-regex1.42.0 none(no description available) pn libboost-signals1.42.0 none(no description available) pn libboost-system1.42.0 none(no description available) pn libboost-thread1.42.0 none(no description available) ii libbz2-1.0 1.0.5-6+squeeze1 high-quality block-sorting file co ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libgcc11:4.4.5-8 GCC support library pn libpion-common-3.0 none(no description available) pn libpion-common-dev none(no description available) pn libpion-net-3.0none(no description available) ii libssl0.9.80.9.8o-4squeeze12 SSL shared libraries ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime libpion-net-dev recommends no packages. Versions of packages libpion-net-dev suggests: pn libpion-net-doc none (no description available) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
