Hi,
the problem does not occur on lenny. However, if I install the
following stable packages to my squeeze system I still see the bug:
libavcodec51_0.svn20080206-18+lenny1_amd64.deb
libavformat52_0.svn20080206-18+lenny1_amd64.deb
libcaca0_0.99.beta14-1_amd64.deb
libcucul0_0.99.beta14-1_amd64.deb
Ciao ragazzi,
Our wiki page [1] still strongly recommends to use the source format
1.0: is this the time to update that?
[1] http://wiki.debian.org/DebianMultimedia/Sponsoring
--
Alessio Treglia ales...@alessiotreglia.com
Debian Ubuntu Developer | Homepage: http://www.alessiotreglia.com
0FEC
On Tue, Aug 24, 2010 at 23:05:46 (CEST), Jonas Smedegaard wrote:
On Tue, Aug 24, 2010 at 10:24:25PM +0200, Rémi Duraffort wrote:
Le mardi 24 août 2010 à 09:33:56, Jonas Smedegaard a écrit :
[sent again, to proper mailinglist this time]
On Tue, Aug 24, 2010 at 07:08:32PM +,
Processing commands for cont...@bugs.debian.org:
reassign 399292 mplayer,kwin,kde-window-manager
Bug #399292 [mplayer,kwin] mplayer: MPlayer rc1 can't be properly scaled by WM
on start
Bug reassigned from package 'mplayer,kwin' to 'mplayer,kwin,kde-window-manager'.
thanks
Stopping processing
On Wed, Aug 25, 2010 at 08:37:48 (CEST), Timo Juhani Lindfors wrote:
Hi,
I can confirm that if I compile upstream svn r32011 on armel I do not
see the bug. However, the playback is then a lot slower than on
Debian. Maybe it gets configured somehow differently and thus avoids
the bug but
Hi all
Following IOhannes m zmoelnig and Hans-Christoph Steiner (both
subscribed to this list and both now members of the pkg-mutlimedia team)
I would like to join the forces to bring some Pure Data related packages
into Debian and to help with the maintenance of those. I hope to do this
in
ow...@bugs.debian.org (Debian Bug Tracking System) writes:
TBH, I have no idea about if there are any buildds for
armel/experimental at all. I'd suggest asking on #debian-buildd or on
their mailing list.
It seems mplayer is not built since ffmpeg fails to build:
CC libavcodec/aacdec.o
Hey Roman,
Glad to see you joining in!
A couple minor details on your ITP bug report:
- in the description, I've been using Pd then using Pure Data in
the long description so both are findable via search. Since its
written text, I think we can use the more common written forms of Pd
On Wed, Aug 25, 2010 at 17:37:33 (CEST), Timo Lindfors wrote:
F ow...@bugs.debian.org (Debian Bug Tracking System) writes:
TBH, I have no idea about if there are any buildds for
armel/experimental at all. I'd suggest asking on #debian-buildd or on
their mailing list.
It seems mplayer is not
Processing commands for cont...@bugs.debian.org:
reopen 594093
Bug #594093 {Done: Reinhard Tartler siret...@tauware.de} [mplayer] mplayer:
wrong byteorder on 16-bit displays with -vo x11 (-vo sdl works)?
'reopen' may be inappropriate when a bug has been closed with a version;
you may need to
reopen 594093
thanks
/tmp/ccv13sip.s:6567: Error: selected processor does not support `ubfx
ip,r2,#6,#2'
make[1]: *** [libavcodec/aacdec.o] Error 1
make[1]: Leaving directory
`/build/buildd-ffmpeg_0.6-2-armel-ldBGDA/ffmpeg-0.6/debian-neon'
make: *** [build-stamp-neon] Error 2
which
clone 594093 -1
reassign -1 src:ffmpeg
found -1 4:0.6-1
severity -1 important
retitle -1 FTBFS/armel: neon flavor requires 'ubfx' instruction
reassign 594093 mplayer
fixed 594093 2:1.0~rc4~try1.dsfg1-1
thanks
On Wed, Aug 25, 2010 at 21:49:54 (CEST), Loïc Minier wrote:
tags 594093 + patch
Processing commands for cont...@bugs.debian.org:
clone 594093 -1
Bug#594093: mplayer: wrong byteorder on 16-bit displays with -vo x11 (-vo sdl
works)?
Bug 594093 cloned as bug 594417.
reassign -1 src:ffmpeg
Bug #594417 [mplayer] mplayer: wrong byteorder on 16-bit displays with -vo x11
(-vo
Your message dated Wed, 25 Aug 2010 22:56:47 +0200
with message-id 87sk22pg1c@faui44a.informatik.uni-erlangen.de
and subject line Re: Bug#594395: mplayer-gui: fails to install because trying
to overwrite '/usr/bin/gmplayer'
has caused the Debian Bug report #594395,
regarding mplayer-gui:
On Wed, Aug 25, 2010, Reinhard Tartler wrote:
Hm, why can't we unconditionally turn on armv7-a for the neon flavor?
I'd prefer not overriding the toolchain defaults, only overriding the
minimum set of things.
For instance, it could be selecting a special core.
--
Loïc Minier
Your message dated Thu, 26 Aug 2010 01:17:06 +
with message-id e1oor5w-xn...@franck.debian.org
and subject line Bug#591287: fixed in libmatroska 1.0.0-1
has caused the Debian Bug report #591287,
regarding libmatroska: New upstream version available
to be marked as done.
This means that
On Wed, Aug 25, 2010 at 23:13:27 (CEST), Loïc Minier wrote:
On Wed, Aug 25, 2010, Reinhard Tartler wrote:
Hm, why can't we unconditionally turn on armv7-a for the neon flavor?
I'd prefer not overriding the toolchain defaults, only overriding the
minimum set of things.
For instance, it
17 matches
Mail list logo
