Porting DKMS package from ubuntu to debian shows compilation errors
When I ported the hdmi_audio dkms package from ubuntu to debian (since ubuntu
package hard-coded kernel version checking) and install, it shows many
compilation errors.
Did I missed some library include path / compile parameters for building the
dkms module?
Alan
Source code:
http://intel.archive.canonical.com/pool/public/o/oem-audio-i915-baytrail-dkms/
DKMS package installation messages:
# dpkg -i oem-audio-i915-baytrail-dkms_0.20150605_all.deb
(Reading database ... 148856 files and directories currently installed.)
Preparing to unpack oem-audio-i915-baytrail-dkms_0.20150605_all.deb ...
--
Deleting module version: 0.20150605
completely from the DKMS tree.
--
Done.
Unpacking oem-audio-i915-baytrail-dkms (0.20150605) over (0.20150605) ...
Setting up oem-audio-i915-baytrail-dkms (0.20150605) ...
Loading new oem-audio-i915-baytrail-0.20150605 DKMS files...
First Installation: checking all kernels...
Building for 3.18.21
Building for architecture amd64
Building initial module for 3.18.21
Error! Bad return status for module build on kernel: 3.18.21 (amd64)
Consult /var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/make.log for
more information.
dpkg: error processing package oem-audio-i915-baytrail-dkms (--install):
subprocess installed post-installation script returned error exit status 1
Processing triggers for initramfs-tools (0.120) ...
Errors were encountered while processing:
oem-audio-i915-baytrail-dkms
# cat /var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/make.log
DKMS make.log for oem-audio-i915-baytrail-0.20150605 for kernel 3.18.21 (amd64)
Sun Sep 27 16:29:28 HKT 2015
make -C /lib/modules/3.18.21/build
M=/var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build modules
make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make
rule.
make[1]: Entering directory '/usr/local/src/kernel/linux-3.18.21'
CC [M]
/var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/hdmi_audio/intel_mid_hdmi_audio.o
In file included from include/linux/printk.h:261:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/platform_device.h:14,
from
/var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/hdmi_audio/intel_mid_hdmi_audio.c:29:
/var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/hdmi_audio/intel_mid_hdmi_audio.c:
In function ‘snd_intelhad_pcm_prepare’:
include/linux/dynamic_debug.h:64:16: warning: format ‘%d’ expects argument of
type ‘int’, but argument 3 has type ‘ssize_t’ [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro
‘DEFINE_DYNAMIC_DEBUG_METADATA’
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/printk.h:267:2: note: in expansion of macro ‘dynamic_pr_debug’
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^
/var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/hdmi_audio/intel_mid_hdmi_audio.c:1478:2:
note: in expansion of macro ‘pr_debug’
pr_debug("period_size=%d\n",
^
include/linux/dynamic_debug.h:64:16: warning: format ‘%d’ expects argument of
type ‘int’, but argument 3 has type ‘size_t’ [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:76:2: note: in expansion of macro
‘DEFINE_DYNAMIC_DEBUG_METADATA’
DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt); \
^
include/linux/printk.h:267:2: note: in expansion of macro ‘dynamic_pr_debug’
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^
/var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/hdmi_audio/intel_mid_hdmi_audio.c:1481:2:
note: in expansion of macro ‘pr_debug’
pr_debug("buffer_size=%d\n", snd_pcm_lib_buffer_bytes(substream));
^
/var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/hdmi_audio/intel_mid_hdmi_audio.c:
In function ‘snd_intelhad_pcm_pointer’:
/var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/hdmi_audio/intel_mid_hdmi_audio.c:1546:6:
warning: unused variable ‘l’ [-Wunused-variable]
u32 l[4];
^
In file included from include/linux/printk.h:261:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/platform_device.h:14,
from
/var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/hdmi_audio/intel_mid_hdmi_audio.c:29:
/var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/hdmi_audio/intel_mid_hdmi_audio.c:
In function ‘hdmi_audio_probe’:
include/linux/dynamic_debug.h:64:16: warning: format ‘%d’ expects argument of
type ‘int’, but argument 3 has type ‘u64 *’ [-Wformat=]
static struct _ddebug __aligned(8) \
^
include/linux/dynamic_debug.h:76:2: note: in expansion
Re: Byte swapped /usr/share?
On Sat, Sep 26, 2015 at 02:35:56PM +0100, Colin Watson wrote:
> > Depends: ${astrometry-data}, ${misc:Depends}
> >
> > and generate substitution for ${astrometry-data} appropriate for the host
> > architecture in debian/rules.
>
> ... especially if you use DEB_HOST_ARCH_ENDIAN to do it. See
> dpkg-architecture(1).
Shouldn't that be DEB_TARGET_ARCH_ENDIAN?
Another option nobody mentioned is not doing the byte-swapping in a
postinst script in-place, but rather have the original file installed
with a different filename than intended, and in the postinst script make
a copy to the final destination and byte-swap if necessary.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen
signature.asc
Description: Digital signature
Re: Byte swapped /usr/share?
On Sun, Sep 27, 2015 at 10:58:24AM +0200, Guus Sliepen wrote: > > ... especially if you use DEB_HOST_ARCH_ENDIAN to do it. See > > dpkg-architecture(1). > > Shouldn't that be DEB_TARGET_ARCH_ENDIAN? No, "target" makes sense only in the context of building cross-compilers. -- WBR, wRAR signature.asc Description: PGP signature
Bug#800144: python-requests-toolbelt -- Useful classes and functions to be used with python-requests
Package: wnpp Severity: wishlist Owner: Zygmunt Krynicki * Package name: python-requests-toolbelt Version : 0.4.0 Upstream Author : Ian Cordasco * URL : http://toolbelt.readthedocs.org * License : Apache Programming Lang: Python Description : Useful classes and functions to be used with python-requests Requests Toolbelt is a collection of utilities that some users of python-requests might need but do not belong in requests proper. The library is actively maintained by members of the requests core development team, and so reflects the functionality most requested by users of the requests library. - This package is a new dependency of twine - I intend to maintain it the same way as all the other python packages I'm working on, as a part of DPMT + PAPT (here DPMT).
Bug#800153: ITP: octave-interval -- real-valued interval arithmetic for Octave
Package: wnpp Severity: wishlist Owner: Oliver Heimlich * Package name: octave-interval Version : 1.1.0 Upstream Author : Oliver Heimlich * URL : http://octave.sourceforge.net/interval/ * License : GPL Programming Lang: Octave, C++ Description : real-valued interval arithmetic for Octave The interval package for real-valued interval arithmetic allows to evaluate functions over subsets of their domain. All results are verified, because interval computations automatically keep track of any errors. These concepts can be used to handle uncertainties, estimate arithmetic errors and produce reliable results. Also it can be applied to computer-assisted proofs, constraint programming, and verified computing. The implementation is based on interval boundaries represented by binary64 numbers and is conforming to IEEE Std 1788-2015, IEEE standard for interval arithmetic. The package will be maintained by the DebianOctaveGroup and, upstream, by the Octave Forge Community. The package is a reference implementation of the recently published IEEE standard for interval arithmetic. It may be used as a free replacement for the proprietary INTLAB toolbox. The latter has been widely used in education for computer arithmetic, for example in the book “Introduction to Interval Analysis” (2009) by Ramon E. Moore, R. Baker Kearfott, and Michael J. Cloud. In contrast to libmpfi and python-mpmath this package provides more functionality, but is limited to the binary64 data type. Some efforts to package have already been made, see http://anonscm.debian.org/cgit/pkg-octave/octave-interval.git/
Re: [DDEB] Status on automatic debug packages (2015-08-24)
Dnia 2015-09-20, nie o godzinie 19:38 +0200, Niels Thykier pisze:
[ cut ]
> > I added DH_BUILD_DDEBS = 1 to d/rules, changed dh_strip to use
> > --ddeb-migration and not -dbg-package, and removed *-dbg from
> > d/control.
> > After building I got python-pyopencl{3}-dbgsym*.dbg.
> > Those packages contained only /usr/lib/debug/.build-id/*.debug
> > files,
> > without /usr/lib/python*/dist-packages/*.so.
> >
>
> Indeed, as I concluded above in reply to Jean-Michel, this is the
> intentional behaviour - at least for now.
>
> > Is there something missing?
> > Files *.so with debugging symbols are built (there are lines
> > PYBUILD_DESTDIR_python2-dbg=debian/python-pyopencl-dbg/ in d/rules)
> > so IMO it's (just?) case of adding those to *-dggsym.deb files.
> >
> > Best regards.
> >
>
> I am open to adding those at a later stage. Though at this point, I
> would really like to get ddebs into unstable, before we scope creep
> it
> any further.
Thanks for explanation.
For now I'll leave manual debug packages for Python.
At the same time - current DH with pybuilder build all necessary files
so as soon as DDEBs take Python-specific files into consideration
I'm ready to switch.
Best regards.
--
Tomasz Rybak GPG/PGP key ID: 2AD5 9860
Fingerprint A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
signature.asc
Description: This is a digitally signed message part
Re: Porting DKMS package from ubuntu to debian shows compilation errors
On Sun, Sep 27, 2015 at 10:44 AM, laalaa wrote: > In file included from > /var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/i915/i915_drv.c:33:0: > /var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/i915/i915_drv.h:277:2: > error: unknown type name ‘drm_local_map_t’ > drm_local_map_t *sarea; > ^ Looks like the code you are compiling isn't compatible with the version of the Linux kernel that you are compiling against. I would try to find a newer version of the code or report this issue to the person who is responsible for maintaining oem-audio-i915-baytrail. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Porting DKMS package from ubuntu to debian shows compilation errors
On 2015-09-27 at 10:43, Paul Wise wrote: > On Sun, Sep 27, 2015 at 10:44 AM, laalaa wrote: > >> In file included from >> /var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/i915/i915_drv.c:33:0: >> /var/lib/dkms/oem-audio-i915-baytrail/0.20150605/build/i915/i915_drv.h:277:2: >> error: unknown type name ‘drm_local_map_t’ >> drm_local_map_t *sarea; >> ^ > > Looks like the code you are compiling isn't compatible with the > version of the Linux kernel that you are compiling against. I would > try to find a newer version of the code or report this issue to the > person who is responsible for maintaining oem-audio-i915-baytrail. Or possibly find an _older_ version of the code; it doesn't seem impossible that this module might have been updated for kernel changes which are more recent than what's in kernel 3.18.21. In fact, that seems reasonably likely. I have headers for 4.0.0-2, 4.1.0-1, and 4.1.0-2 installed, and they all define drm_local_map_t in include/drm/drm_legacy.h; if kernel 3.18.21 defines it elsewhere (such that the includes in this module don't find it) or doesn't define it, that would explain the observed behavior. Unfortunately I don't have immediate access to a set of headers for the 3.18-era kernel, so I can't easily check that myself, but it shouldn't be hard for you to check it on your build machine. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: binNMU or reproducible builds (choose only one)
On Thu, Sep 24, 2015 at 6:09 PM, Henrique de Moraes Holschuh wrote: > Let's answer that one, and if the answer is "lets drop binNMUs", then we can > work towards source-based auto-NMUs being at least as easy to use/trigger as > binNMUs currently are. I guess automated source-NMUs would be useful for automatic rebuilds of architecture all binary packages too, which is occasionally needed. -- bye, pabs https://wiki.debian.org/PaulWise
Re: binNMU or reproducible builds (choose only one)
2015-09-27 17:54 GMT+02:00 Paul Wise : > On Thu, Sep 24, 2015 at 6:09 PM, Henrique de Moraes Holschuh wrote: > >> Let's answer that one, and if the answer is "lets drop binNMUs", then we can >> work towards source-based auto-NMUs being at least as easy to use/trigger as >> binNMUs currently are. > > I guess automated source-NMUs would be useful for automatic rebuilds > of architecture all binary packages too, which is occasionally needed. At Tanglu, we can use such a tool, which basically just adds a new changelog entry to the package (generating a new source package) and then has dak import it. This only works with source format 3.0 though (otherwise we would have to edit a .diff, which is even more ugly), and there could be some drawbacks of this approach, since a few packages need to run custom scripts taking the version number in the changelog into account. So far, we haven't found issues with this, though. But since not every package is using the 3.0 source package format, and sometimes it's just easier to do manual uploads to catch everything, doing sourceful rebuild uploads like in Ubuntu is still the most common way for us to rebuild things. Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Bug#800312: RFH: unpaper -- post-processing tool for scanned pages
Package: wnpp Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I request assistance with maintaining the unpaper package in Debian. When the unpaper 6.1 is built in Debian unstable against ffmpeg it fails to load the png files from its own tests folder. I already filled an upstream bug about this: https://github.com/Flameeyes/unpaper/issues/39 Upstream however seems to be unresponsive ATM and my C skills are very rusty. :-( I suspect that there's some incompatibility between ffmpeg and libav. Upstream builds against libav and in Debian we use ffmpeg. Thank you, Thomas Koch -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWCB7nAAoJEAf8SJEEK6Za0OAP/RqPFKq4EUcpdegW8UHCZCnD wPeJk6lwSz0ikDw9kXti3n6WBetr1A8ufjWFraLGB2bxiT6zopemldCNmRjLarlz CpS49reFC0YuUUQNrDuIlO/Gxl4egYhSkR5O+FrsRNZZP6h8pRVlNRXaMLFx+LIn aJ3P0mqr8od7bUbzc8q1ziOtahDhLPE4sERm4CICyYijlY9jG6ac/1XZEYxDKyvp ST1yOTveACD6NNMgPLd1qs3JWgOi8BOl2asr+Qu4dc7HJddVU0s7p4+TxaxgRBXc C3tpnbgOlmWgroRacxO7mVYvUOxIfR3LomQul1Tfx6NCjDROKgy2V9weNLnEg7N4 DPWvwsKM2Oa9Y7QeKOcWdrpVZ1lbOOh0KaeMyoJXJmd9KQq4j+39C1iHDwBReXq8 WYfiaWEVZSD9YRFcWXRu3Dll8qSjHUYIjbb6ae3Q5EPJnRFQm2W09LUMJv3ExkNc Kn660lxE+DAJERuZENnaL9Cx98jvBNTTK7i8DyDAxU70xTvAEgzEU4uuJbVLLh4k NFjkXKv5i9CUqnahwUaQrekQO8am/rzYtgZ+yxgN1zFbobbh1AJ+lnu0L6a+vwrQ ijt6k+CJWCMM7QJNeLex96B7vRecIv9TQi/R9DU+qimDGt4l9vG0fUUFpOOaaUHZ S10eq2qMkaCJ/TZaxXrN =Dy4g -END PGP SIGNATURE-
Re: Byte swapped /usr/share?
Guus Sliepen wrote: > Another option nobody mentioned is not doing the byte-swapping in a > postinst script in-place, but rather have the original file installed > with a different filename than intended, and in the postinst script make > a copy to the final destination and byte-swap if necessary. That would result in two copies of the (likely large) data on end-user systems, which seems far worse than having two copies in the Debian archive. - Josh Triplett
Bug#800330: ITP: postgis-java -- Geographic objects support for PostgreSQL -- JDBC support
Package: wnpp Severity: wishlist Owner: Bas Couwenberg * Package name: postgis-java Version : 2.1.7.1 Upstream Author : PostGIS Developers * URL : https://github.com/postgis/postgis-java * License : LGPL-2.1+ Programming Lang: Java Description : Geographic objects support for PostgreSQL -- JDBC support PostGIS adds support for geographic objects to the PostgreSQL object-relational database. In effect, PostGIS "spatially enables" the PostgreSQL server, allowing it to be used as a backend spatial database for geographic information systems (GIS), much like ESRI's SDE or Oracle's Spatial extension. PostGIS follows the OpenGIS "Simple Features Specification for SQL". This package contains JDBC support for PostGIS. libpostgis-java is required for osmosis, and used to be built from the postgis source package, but upstream has split it off into a separate project since PostGIS 2.2. The new postgis-java source package will be maintained in the Debian GIS team along with postgis itself.
ITP: sleepyhead -- Software for sleep tracking with focus on CPAP treatment
Control: retitle -1 ITP: sleepyhead -- Software for sleep tracking with focus on CPAP treatment Owner: sergi...@sergiodj.net * Package name: sleepyhead Version : 0.9.8 (git branch) Upstream Author : Mark Watkins * URL : http://sourceforge.net/projects/sleepyhead/ * License : GPLv3 Programming Lang: C++ Description : Software for sleep tracking with focus on CPAP treatment Further comments: the package bundles some libraries, so it will need to be adjusted to meet DFSG. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
