On 03/08/17 14:07, James Cowgill wrote:
Source: ffmpeg
Version: 7:3.3.3-1
Severity: important
Tags: sid buster
X-Debbugs-CC: debian-...@lists.debian.org, binut...@packages.debian.org
Hi,
I was looking at the Ubuntu proposed migration pages for ffmpeg and
noticed that the autopkgtest failed on a
Package: brp-pacu
Version: 2.1.1+git20111020-5
Severity: serious
brp-pacu build-depends on libgtkdatabox-0.9.2-0-dev | libgtkdatabox-dev
. Debian autobuilders only look at the first option.
libgtkdatabox-0.9.2-0-dev is now an obsolete package (no longer built by
the libgtkdatabox source).
P
Package: kodi
Severity: important
The xbmc packages have been turned into transition package to kodi but
the transition packages are uninstallable due to the unversioned
breaks/replaces in kodi. Please version the breaks/replaces so they only
apply to the real packages and not the transition p
Package: openni
Version: 1.5.4.0-13
Severity: important
In raspbian we run checks on built debs for armv7 tagged binary
packages. Your package was detected by these checks and on further
investigation. it seems that the following flags for all arm builds
(whether Debian armel, Debian armhf or
Severity 794724 grave
tags 794724 +stretch sid
thanks
The libtinyxml transition has now happened in stretch and sid. This bug
needs to be fixed so that crtmpserver-dev is installable again and
crtmpserver-libs does not depend on obsolete packages.
_
On 12/02/15 00:29, Sebastian Ramacher wrote:
Hi Peter,
Rasbperry Pi 2 has now been released and, if I read the news correctly,
it supports NEON instructions. Should we revert the changes or do they
need any modifications?
That is a question that will need some experimentation/testing to ans
Sebastian Ramacher wrote:
I've applied your patch, tweaked it to use --derives-from rather than --is
implemented this change, written a changelog entry (which may be more
verbose than actually needed, feel free to cut it down if you want when
bringing the change into Debian) and am now running a
Sebastian Ramacher wrote:
there was a request to change the handling of the Raspberry Pi in the
libav package. Could you please explain the changes applied to the
Raspbian version?
In raspbian we have a checker that runs after all our autobuilds (and I
manually run a similar check when I do man
peter green wrote:
Found 756777 1.0.2-6
Thanks
I've just tested and found that building with gcc/g++ 4.8 fixes the
build. Using 4.8 also requires switching from strong to regular stack
protector. This
can be done with the following
export
CC=gc
Package: dirac
The dirac package seems pretty unloved. It's only ever had one upstream
version in debian and all of the recent uploads have been "team
uploads", mostly tweaking the packaging with a handful of FTBFS fixes.
The package fails to build on armhf with gcc-4.9 with a testsuite
segf
ector-strong
export DEB_CXXFLAGS_MAINT_APPEND=-fstack-protector
If noone proposes a better soloution in the next couple of days I'll
wrap this
in appropriate conditional logic and upload it as a NMU.
Sebastian Ramacher wrote:
On 2014-10-13 03:29:19, peter green wrote:
peter green wrote:
A testsuite log is attatched
Sorry forgot to actually attatch it, doing so now.
## --- ##
## test suite: dirac. ##
## --- ##
testsuite: command line was:
$ ./testsuite
## -- ##
## ChangeLog. ##
## -- ##
| 2009-02-10 14
Found 756777 1.0.2-6
Thanks
| Checking encode and decode of colourbars
|
| 2: colourbars FAILED (colourbars.at:7)
|
I've just reproduced this locally with both sid's version in sid and
jessie's version in jessie. So this doesn't appear to be related to t
mpg123 currently does not understand that arm64 is a 64bit
architecture causing FTBFS.
The attached patch fixes the failure.
I've just uploaded this patch to debian-ports arm64 unreleased.
Since we are currently in the process of trying to push arm64 into
debian proper we would appreciate
The underlying problem seems to be.
configure: *** checking feature: rtmp library ***
configure: *** for plug-ins: rtmp ***
checking for RTMP... no
configure: Package 'gnutls', required by 'librtmp', not found
configure: *** These plugins will not be built: rtmp
It would appear that despite the m
user debian-...@lists.debian.org
usertags 700276 +arm64
retitle 700276 dirac: FTBFS on x32 and arm64 Needs autotools update
thanks
Dirac also ftbfs on arm64, the reason for the ftbfs is different
(outdated config.sub rather than outdated libtool) but the fix is the
same, use dh-autoreconf to up
Tags 751856 +patch
thanks
peter green wrote:
This should be a better patch:
https://git.libav.org/?p=libav.git;a=commitdiff;h=34fb994d9340313b0d247899a4a7a97cc010df92;hp=e780c3daafe0588e035e752c771ebfcd2201746a
Can you verify that patch works for you?
The build without neon is
Reinhard Tartler wrote:
I'm now attempting to disable NEON to see
if that makes the package build.
This should be a better patch:
https://git.libav.org/?p=libav.git;a=commitdiff;h=34fb994d9340313b0d247899a4a7a97cc010df92;hp=e780c3daafe0588e035e752c771ebfcd2201746a
Can you verify that pat
Package: libav
Version: 6:10.1-1
Severity: important
I've been trying to build libav for arm64 (in a user mode qemu chroot),
I removed opencv, frei0r and x264 from build-depends to break the look
(as suggested in README.source)
gcc -I. -I/libav-10.1 -D_FORTIFY_SOURCE=2 -D_ISOC99_SOURCE
-D_FILE
Package: x264
Version: 2:0.142.2389+git956c8d8-4
Tags: patch
Version 2:0.142.2389+git956c8d8-2 of the x264 package introduced the use
of the compiler flag -fno-aggressive-loop-optimizations to
fix/workaround a problem (leading to a segfault) when the code was
built with gcc 4.8.
However -fn
Riku Voipio wrote:
I think nofpu would good for raspian. Any lost audio quality would
unnoticable on the Rasberry's analog audio output ;)
Peter, what's the recommended way to recognize raspbian in debian/rules
?
dpkg-vendor --derives-from raspbian
__
On Sun, Mar 02, 2014 at 09:06:44AM -0500, Reinhard Tartler wrote:
That sounds like if the mpg123 package should use:
on armel: --with-cpu=arm_nofpu
on armhf: --with-cpu=arm_fpu
Does this make sense to everybody?
Seems sane to me. armv7 devices without neon are relatively uncommon so
whi
Taihei Momma wrote:
But the processor decoded the first instruction as 2-byte (thumb?),
Note that debian armhf builds C code in thumb2 mode by default.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http
Thomas Orgis wrote:
So, I got conversion to float implemented now and tested with the
generic_nofpu decoder on x86-64. It _should_ of course work with ARM,
too;-) If you'd like to check the current snapshot of mpg123,
http://mpg123.org/snapshot/mpg123-20140220132548.tar.bz2 ,
you hopefu
Reinhard Tartler wrote:
I mean line 55
I've just looked at ./configure --help and AIUI there are four possible
values of --with-cpu for arm systems
--with-cpu=generic_fpu Use generic processor code with floating
point arithmetic
--with-cpu=generic_nofpu Use generic processor code
Reinhard Tartler wrote:
With this explanation, I think it would help a lot to all armhf users
if the following line was restricted to the armel port:
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mpg123.git;a=blob;f=debian/rules;h=afb018502621352914e757338a2dace6b65522cb;hb=HEAD#l25
Umm
Reinhard Tartler wrote:
Dear ARM porters,
Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738981
for full context. I've uploaded a patch proposed by Riku that AFAIUI
makes mpg123 really slow on all arm targets, while unbreaking it on
some others.
As one of the maintainers of the mp
Package: mplayer
Severity: important
Version: 2:1.0~rc4.dfsg1+svn34540-1
Mplayer seems to be building with -march=native on hurd, -march=native
is not appropriate for distro packaging as it makes the results of the
build dependent on what cpu happens to be in the build machine.
I have not inv
Package: tsdecrypt
Severity: serious
Tags: patch
Version: 8.0-1
tsdecrypt's build system appears to assume that the package is being
built with the intention of running it on the same machine it is being
built on. As such it uses -march=native and depending on detection code
sets several other
Package: toonloop
Severity: serious
Version: 2.2.0-1
Tags: patch
Toonloop fails to build with boost 1.54
checking for boostlib >= 1.35... yes
checking whether the Boost::Program_Options library is available... yes
checking for exit in -lboost_program_options... yes
checking whether the Boost::Fi
I'd like to mark this as "won't fix" because we're dropping the scons
build system. The latest version of supercollider 3.5.x (which I'm
currently asking debian-multimedia maintainers to upload) uses cmake
instead which is much less mess.
Supercollider 1:3.5.2-1 was uploaded just before the fr
ble
Usually qreal is double (which is why it works), but on ARM systems qreal
is float instead.
This causes sc to fail to build on ARM systems.
---
There is a similar problem with some reference parameters in QcMultislider
.cpp which I have added the fix for to this patch -- Peter Green
---
QtCollide
Package: audacious
Version: 3.2-2
Severity: normal
Tags: patch
In version 3.2-2 the optimisation level was dropped on sparc to work
arround a compiler bug. This compiler bug has now been fixed and i've
confirmed the package builds without the workaround so please remove it
in the next upload (
I pulled that change into another 1.13 release, it is a bit different from your
patch. Could you (peter?) test
http://mpg123.org/download/mpg123-1.13.8.tar.bz2 if it builds now?
I extrated the tarball on an armhf system and did ./configure and make
and it seemed to build successfully. I have
Package: mpg123
Version: 1.13.7-6
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: armhf
mpg123 FTBFS on armhf with the following errors.
/bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../src -I../../src -I../../src/libmpg123 -DOPT_ARM
Package: mpg123
Version: 1.13.7-6
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: armhf
mpg123 FTBFS on armhf with the following errors.
/bin/bash ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../src -I../../src -I../../src/libmpg123 -DOPT_ARM
Package: jmeters
Version: 0.2.1-1
Severity: serious
Tags: patch
The new version of jmeters builds using -march=native. Using
-march=native chooses the target CPU based on the CPU of the build
machine and as such is completely unsuitable for building packages for
distribution by debian. Further
/bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I..-Wall
-ggdb -g -O2 -DSKINDIR=\"/usr/share/audacious\" -g -O2 -c -o plugin_main.lo
plugin_main.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wall -ggdb -g -O2
-DSKINDIR=\"/usr/share/audacious\" -g -O2 -c plugin
Source: audacious
Version: 3.2-1
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
audacious FTBFS on sparc with an internal compiler error. This has been reported
to the gcc maintainers at http://bugs.debian.org/659793 but past experinace
Reopen 657814
found 657814 2.1.18-2
thanks
* Use autoreconf at build time to fix FTBFS. (Closes: #657814)
Umm, it seems you regenerated the autotools stuff but didn't
apply/include the rest of the patch. Predictablly the package still
FTBFS on armel and armhf.
Audacious failed to build on sparc with an internal compiler error.
https://buildd.debian.org/status/fetch.php?pkg=audacious&arch=sparc&ver=3.2-1&stamp=1327623171
unfortunately the build log is a pain to read as the package uses a
paralell build.
Could someone try and reproduce this. If yo
sorry. the real changes are in
configure.ac, src/Makefile.ac and
Author: Peter Green
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want
Can anyone test if the attached patch improves anything?
I just tried the following on armhf
Replaced debian/patches/0009-fix_FTBFS_with_ffmpeg_debian.patch
with the version from http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=656502
Added Adapt_to_libav_API_changes.patch from the sam
retitle 654428 blender: FTBFS: uses i386/amd64 specific register definitions on
all architectures
thanks
Christoph Egger wrote:
Your package failed to build on the buildds:
More accurately it built successfullyy on the i386 buildd but failed
on all the other buildds that tried to build it (the
usr/lib/ returned exit code 1
>make: *** [binary] Error 2
>dpkg-buildpackage: error: debian/rules binary gave error exit status 2
>root@debian:/projectm-2.0.1+dfsg#
Description: remove pulse/browser.h include
pulseaudio no longer seems to ship a header with this name
Author
tags 570848 +patch
thanks
Patch is attatched, just add it to the quilt series.
Index: ams-2.0.1/src/canvasfunction.cpp
===
--- ams-2.0.1.orig/src/canvasfunction.cpp 2010-02-23 14:49:01.0 +
+++ ams-2.0.1/src/canvasfuncti
a new version of makefile.patch which removes the use of -march=native
is attatched.
Patch is applied because autotools are not used by upstream author. Patch setting prefix=/usr and fix install commands.
Index: zita-convolver/libs/Makefile
=
retitle 559747 zita-convolver: must not use -march=native
thanks
zita-convolver appears to be using -march=native , there are two
problems with this
1: It's not supported on most debian architectures (hence a load of
build failures)
2: Even on architectures where it is supported it's totally
48 matches
Mail list logo
