really no longer build mplayer-gui, Closes: #612473
the gui uses private, internal symbols of swscale
Shouldn't at least an alternative package (say, kmplayer) get pulled
in? Or shouldn't some package Replace: mplayer-gui?
I am afraid that the obsolete mplayer-gui package keeps
Am 21.02.2011 13:58, schrieb Adam D. Barratt:
Yes, the fix would need to be applied to unstable first, so we can
discover if any further issues occur.
libmms 0.6.2-2 has just entered testing without any complaints.
- Fabian
___
Am 04.03.2011 19:19, schrieb Jari Aalto:
Please add short options for typical command line use, like
Sorry, but we are not going to divert from upstream WRT user
interface. We want to avoid people ending up writing scripts that only
work on Debian with flac package version (= x.y) but on no
Am 07.03.2011 11:51, schrieb Alessio Treglia:
A 'wontfix' tag would be appropriate.
Feel free...
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
Am 08.03.2011 11:07, schrieb Reinhard Tartler:
would anyone support having mkvtoolnix in pkg-multimedia? It currently
has Christian Mariallat in the Maintainer field, and I think the package
would be better served if we had it in pkg-multimedia. Before actually
proposing this, I'm asking for a
Am 10.03.2011 15:11, schrieb Fabian Greffrath:
libmms 0.6.2-2 has just entered testing without any complaints.
Please go ahead with the stable upload.
the package is already prepared in the stable branch of our libmms git
repo. Please upload if you find some time. ;)
Ping
Am 16.03.2011 07:21, schrieb Adam D. Barratt:
Unfortunately the upload hit p-u-NEW after things had been frozen for
6.0.1; it will therefore not be processed until after 6.0.1 has been
released and will be included in 6.0.2.
Oh, come on. Isn't it possible to still get this into 6.0.1? It's
Am 17.03.2011 15:30, schrieb Gal Shalif:
+ [ ! -d doxy ] || tar -C doxy -cf - html | tar -C
debian/tmp/usr/share/doc/ffmpeg-doc -xf -
He, couldn't we simply copy the *directory* doxy/html (with cp -r)
instead of its *contents* doxy/html/* and be done with it?
- Fabian
Am 18.03.2011 14:59, schrieb Reinhard Tartler:
please file a wishlist report against libavdevice52.
Let's just enable it in git, or not?
- Fabian
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
Reinhard,
are there any *technical* reasons for our switch from ffmpeg to the
libav fork? What are the technical differences now and in the long
term? Will libav retain ABI-/API-compatibility with ffmpeg?
- Fabian
___
pkg-multimedia-maintainers
Am 21.03.2011 09:58, schrieb Reinhard Tartler:
Sure, feel free to go ahead (I forgot it for the last upload already)
Alright, what's the curent best practice for building with JACK
support? Adding libjack-dev to BD and be done with it or do we need
special-casing for JACK2?
Am 21.03.2011 11:00, schrieb Reinhard Tartler:
TBH no idea, I would need to look into that more closely as well. I
guess it's just a matter of adding the build dep and passing the right
line to configure.
I have added libjack-dev to Build-Depends and now ./configure shows
jack among the
Am 22.03.2011 12:57, schrieb Reinhard Tartler:
May I take this as indication that mplayer2 fails the 'is there interest
in pkg-multimedia' test?
Maybe we should relax our policy for packages targetted at
experimental. So single-maintainer approaches like this have a chance
to establish in
Hi Reinhard,
thanks for the insightful summary!
In related news, I have read that CrystalHD support has now been
merged into ffmpeg and mplayer: http://intr.overt.org/blog/?p=125
If this has also already been done in libav, then you really need to
advertise yourself a bit more. ;)
-
Am 24.03.2011 19:46, schrieb Faheem Mitha:
I backported ffmpeg 4:0.6.1-5 from unstable to squeeze. On running it,
I see the following warning
This requires quite a few steps. Could you please elaborate what
exactly you did? Do you still have other or older ffmpeg library
packages installed
Am 28.03.2011 11:10, schrieb Faheem Mitha:
ii libavcodec0d 0.cvs20060823-8 ffmpeg codec library
rc libavcodec51 3:20080706-0.3lenny2 library to encode decode
rc libavcodeccvs51 3:20070329-0.0etch1 library to encode decode
ii libavformat0d 0.cvs20060823-8 ffmpeg file format library
rc
Am 28.03.2011 11:39, schrieb Faheem Mitha:
Removing the packages listed above does not change the
WARNING: library configuration mismatch
Which version of the ffmpeg frontend do you use?
Does this error message only appear when you run the ffmpeg binary? Do
you run the one installed on the
Am 28.03.2011 12:13, schrieb Faheem Mitha:
According to the ffmpeg developers, this reflects a mismatch of
versions. Assuming they are correct, and this is not just blowing
smoke, then my feeling is that this is caused by insufficiently tight
package dependencies, so my suggestion would be to
Am 28.03.2011 12:39, schrieb Faheem Mitha:
Well, as long as you're sure disabling the bug won't mask real
problems. How do the ffmpeg developers feel about it?
I still don't understand how this warning could occur on your system
in the first place if all libraries are installed from the same
Am 28.03.2011 12:53, schrieb Fabian Greffrath:
I still don't understand how this warning could occur on your system
in the first place if all libraries are installed from the same
source, i.e. unstable. You really didn't rebuild anything yourself?
Sorry, I was wrong! I see this in unstable
Am 28.03.2011 13:18, schrieb Faheem Mitha:
That very verbose output is part of the warning. :-)
Yes, but you omitted it from your initial mail, which didn't make it
easier to find. ;)
Hmm. Did you confirm this was the problem by changing the config flags?
Yes, the culprit is that the
Am 28.03.2011 13:54, schrieb Faheem Mitha:
No I didn't. Look again. It is all there. I wouldn't truncate such a
warning. I said
My fault, sorry. I am tired today. ;)
Ok. So pointing this out to the ffmpeg people is a waste of time, in
your opinion?
siretart is already one of the ffmpeg
Am 28.03.2011 13:58, schrieb Reinhard Tartler:
I'm happy that Fabian agrees with me. I'll see if I can propose some
configure switch for 0.7, but TBH, the trick with building the libraries
in different flavors is a very Debian specific trick that cannot be
upstreamed easily. Nor am I convinced
Disable warning about library configuration mismatch
But with this patch it still prints the whole configuration parameters
for all libraries. Is this intented? what purpose does it serve?
___
pkg-multimedia-maintainers mailing list
Am 30.03.2011 11:01, schrieb Reinhard Tartler:
The configuration line is awfully long in Debian, at least
--enable-swscale can be dropped, let's check if we can drop some more.
Not many, apparently. Except for the compression libraries, support
for external libraries defaults to no:
Am 30.03.2011 02:01, schrieb Reinhard Tartler:
It helps upstream with understanding what libraries are involved in bug
reports.
Yes, but it still confuses users *without* bug reports each time they
start ffmpeg. :/
___
pkg-multimedia-maintainers
The current libquicktime in git fixes two issues that appear with
newer gtk+ libraries. Please upload ASAP.
Thanks,
- Fabian
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
Am 11.04.2011 05:31, schrieb Alessio Treglia:
Why not update to the latest upstream 1.2.x release?
Good question. ;)
I do not use libquicktime myself and am thus not very interested in
this package anymore. I just wanted to avoid it lying around with RC
bugs. I'd love to give it away if
Sorry, I am late to the party, but IMHO the switch from ffmpeg to
libav and the introduction of a new upstream release (i.e. 0.6.2) with
all its improvements should be mentioned.
- Fabian
___
pkg-multimedia-maintainers mailing list
/ directory
altogether from the release tarballs. Advanced users who might want to
build and test Debian packages from other sources but ours could then
still checkout an SVN snapshot of xvid and do as they prefer.
Best Regards,
Fabian Greffrath
[1] http://ftp-master.debian.org/new.html
[2] http
information subsequent to the
configure script, so maybe it could even get called from there...
Best Regards,
Fabian Greffrath
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org
Dear ftp-masters,
while I *highly appreciate* your timely acceptance of the vo-aacenc
package (AAC is an MPEG specification after all), I still fail to see
why very similar packages like lame are left unattended in the NEW
queue for 9 months now!
Best Regards,
Fabian Greffrath
Am
Am 19.04.2011 01:08, schrieb Sebastian Dröge:
Doing that now... the AAC and AMRWB encoders will be in the next release
after the one that will be released this or next week.
Great, thanks a lot!
BTW, which release, -bad or -ugly?
- Fabian
___
Hi Alexander,
Am 19.04.2011 02:15, schrieb Alexander Reichle-Schmehl:
Do you consider that a good way to start a productive discussion, or you
just want to dump some heat?
If it's the second, I recommend to stop reading here, and send all your
replies to /dev/null. Thanks in advance!
I did
Am 19.04.2011 04:45, schrieb Reinhard Tartler:
In the past months, I did a couple of pings to the DPL and
ftp-master. It doesn't make sense to reiterate everything in detail as
there is nothing 'solid' to report (otherwise I of course would have
reported it), but espc. Alexander and our DPL have
Am 16.05.2011 03:43, schrieb Reinhard Tartler:
I guess this should go the other way round, i.e., libjack-jackd2-dev |
libjack-dev
The former provides the latter and no matter which implementation you
chose, the shlibs variable will always point to the jack2 library.
Am 17.05.2011 08:24, schrieb Jonas Smedegaard:
Generally libraries for daemons should *not* recommend their daemon.
100% agreed!
- Fabian
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
Dear ftp-masters and pkg-multimedia team,
to pick up the discussion from 6 weeks ago (see below, sorry for
top-posting): Are there any news with regard to the acceptance of the
xvidcore, x264 and mjpegtools packages into Debian?
Our previous discussion at least led to the rejection of the
test
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
tags 629619 + patch
thanks
Please add audio/x-vorbis+ogg; and video/x-ogm+ogg; to the list of
supported MimeTypes in the vlc.desktop file and run
update-desktop-database (as root).
The attached patch is for the vlc.desktop file.
- Fabian
--- vlc-1.1.9/share/vlc.desktop 2011-02-09
reassign 630245 mimms
severity 630245 normal
notfound 630245 0.6-1
found 630245 3.2.1-2
thanks
Am 12.06.2011 23:00, schrieb Wesley J. Landaker:
The deprecation problem is a bug in mimms (written in python), not libmms
(written in C). It results in a warning message, and has nothing to do with
Am 18.06.2011 10:54, schrieb A Mennucc:
accordind to debian/copyright both source packages above are
tracking libav.org ... wouldn't it be better if the latter would be
used to track (and maybe package) the ffmpeg.org codebase ?
In this (or at least related) context...
Am 22.06.2011 10:45, schrieb Reinhard Tartler:
Neat, no? I'm busy preparing the Libav 0.7 release, then FFmpeg does a
git merge from libav.org and quickly publishes both 0.7 and 0.8.
Cool, uh?
I just don't get it.
Why does he merge back the code of the fork that split off of ffmpeg
for his
Am 22.06.2011 11:00, schrieb Reinhard Tartler:
He doesn't merge everything, only stuff that he likes.
But the release announcement says:
...it includes all changes from ffmpeg-mt and libav.
^^^^
___
Am 24.06.2011 10:16, schrieb Reinhard Tartler:
I'm therefore asking for comments on this before I create the new
libav-extra.git and delete the 'extra' branches from the libav.git
repository.
I see. On the one hand, the libav-extra packages do not share sources
with the libav packages (i.e.
To the attention of the libmatroska/libebml maintainers.
Original-Nachricht
Betreff: libebml 1.2.1 libmatroska 1.2.0 released
Datum: Sun, 26 Jun 2011 20:10:29 +0200
Von: Moritz Bunkus mor...@bunkus.org
An: matroska-us...@lists.matroska.org
Hey,
The Matroska team has released
Hi Derek,
please file a proper bug report with Debian's reportbug tool, e.g.
reportbug mplayer. As it is now, your bug report is unfortunately
quite useless for us.
- Fabian
Am 02.07.2011 18:21, schrieb VDR User:
Hi. I sent the following to boe...@inb.uni-luebeck.de but was then
told
Am 26.07.2011 11:33, schrieb Debian FTP Masters:
Changes: xvidcore (2:1.3.2-2) unstable; urgency=low
.
* document copyright and license of altivec assembler
I switched from nasm to yasm, which is missing in the changelog!
___
Andres,
interesting repackaging work, but wouldn't it have been sufficient for
most of the changes that you apply to just grab a recent VCS snapshot
and package that?
- Fabian
___
pkg-multimedia-maintainers mailing list
Am 28.07.2011 01:24, schrieb Pino Toscano:
currently[1], xvidcore does not compile on hurd-i386.
The problem is the lack of support for GNU/Hurd in configure;
the attached patch (which requires autoreconf) provides it.
Applied upstream, thanks!
- Fabian
Does anyone believe it makes sense to try getting libdvdcss accepted
into Debian?
- Fabian
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
Am 28.07.2011 11:23, schrieb Alessio Treglia:
Let's start working on it!
All done:
http://debian.greffrath.com/unstable/libdvdcss_1.2.10-0fab1.dsc
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
Am 28.07.2011 14:04, schrieb Christoph Egger:
Maybe some architecture-detection broke when adding hurd?
I don't think so. I have added kfreebsd-amd64 to the list of archs to
build-depend on yasm, so asm code is compiled für kfreebsd-amd64 now
but hasn't before.
So most probably either the
Am 28.07.2011 15:21, schrieb Fabian Greffrath:
So most probably either the build system or yasm itself fail to build
PIC code on kfreebsd-amd64.
Indeed, it is also explicitely disabled in FreeBSD:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/xvid/Makefile?rev=1.36
Am Donnerstag, den 28.07.2011, 21:16 +0200 schrieb Reinhard Tartler:
The link you've quoted from freebsd ports disables yasm on both amd64
and on i386:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/xvid/Makefile?rev=1.36
Shouldn't we consequently include any bsd architecture here, not
Am 29.07.2011 11:18, schrieb Reinhard Tartler:
I've compiled current git on asdfasdf.debian.net. Find the buildlog
below. I'm particularily nervous about the symbols diffs:
I'd say it looks good. As for the symbols diff, I have no idea where
it comes from, but it also appeared for the last
Am 30.07.2011 14:54, schrieb Fabian Greffrath:
I have investigated in this issue a bit last year and filed the
following bug report against kdemultimedia-kio-plugins:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592726
More background can be found there.
IIRC, the culprit was the lame
Am 02.08.2011 16:51, schrieb Reinhard Tartler:
patch is missing documentation
done.
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
Am 28.07.2011 19:35, schrieb A. Costa:
For the record, I've had this same install bug for about a month, even
when installing with 'aptitude':
[...]
So the bug is real enough. Last month F. Greffrath advised:
Adding = 2.4 in debian/pycompat
Assuming that would help, why not do it?
Am 07.08.2011 13:08, schrieb Jonas Smedegaard:
I therefore see no reason to elevate this particular to be a general
issue for Debian.
I do. Are you fine with escalating this issue on -devel?
- Fabian
___
pkg-multimedia-maintainers mailing list
Am 08.08.2011 09:38, schrieb Reinhard Tartler:
Does your proposed change to debian/pycompat fix it? If yes, just apply
the change and let's be done with it.
If not, what would need to be done to fix this properly? Then we could
start arguing if fixing it was worth the efford.
To be honest, I
Am 08.08.2011 10:44, schrieb Jonas Smedegaard:
We do not solve this issue by educating Debian packages more widely
about weird possible combinations of packages: Debian support upgrades
one stable release at a time - Debian do *not* support keeping around
old packages!
It is exact this point
Am 08.08.2011 22:05, schrieb Rogério Brito:
I will add a paragraph there about xvidcore+lame+x264. If anybody has any
comment, please let me know.
The paragraph about lame is already very well phrased IMHO. I think,
however, that in order to not confuse readers about the background of
these
Am 11.08.2011 05:22, schrieb Andres Mejia:
I have seen a commit with mp4v2 that disables building of the static
library. Though I know binaries in Debian are normally linked with
shared libraries, distributing the static library is beneficial to
users with different requirements for software
Am 08.08.2011 09:38, schrieb Reinhard Tartler:
Does your proposed change to debian/pycompat fix it? If yes, just apply
the change and let's be done with it.
There was already a XS-Python-Version field in debian/control that
said all, which is obviously wrong when it fails with python2.3. So
Does anyone feel like uploading faad2 from GIT? You may want to claim
your copyright as a package maintainer first (or should we simply put
the team there), since I only added myself to debian/copyright.
- Fabian
___
pkg-multimedia-maintainers
Am 11.08.2011 11:34, schrieb Jonas Smedegaard:
No.
All versions (available in Debian) indeed satisfies the package needs.
My god, how can one be so stubborn!
___
pkg-multimedia-maintainers mailing list
Am 11.08.2011 19:12, schrieb Jonas Smedegaard:
My god, how can one be so ignorant and disrespectful as to not listen to
the arguments put forward (or ask if those are not understood).
Talking about arguments, I have two arguments in the form of users
that have reported real issues with the
Montag, den 01.08.2011, 10:52 +0200 schrieb Fabian Greffrath:
Am 30.07.2011 14:54, schrieb Fabian Greffrath:
I have investigated in this issue a bit last year and filed the
following bug report against kdemultimedia-kio-plugins:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592726
More
Am 15.08.2011 03:48, schrieb Andres Mejia:
We could make these users build the libraries themselves, but then
they would also need to build all the build dependencies as well for
the library they need. This can be quite a burden on various
He? Why would I have to recompile a library's
Am 15.08.2011 09:42, schrieb Reinhard Tartler:
On Mon, Aug 15, 2011 at 08:55:47 (CEST), Fabian Greffrath wrote:
Am 15.08.2011 03:48, schrieb Andres Mejia:
We could make these users build the libraries themselves, but then
they would also need to build all the build dependencies as well
Am 15.08.2011 11:59, schrieb Reinhard Tartler:
I could imagien as valid use caseto produce a (partly) statically built
binary that works on a larger amount of distributions. But granted, we
are now in the speculation area.
Well, whatever, I am *not against* providing static libraries. I just
Hello,
Am 16.08.2011 01:38, schrieb Amandeep Singh:
I have 64 bit debian installed on my lenovo T400. I installed kino,
video editing tool. It complained, that I didn't have ffmpeg
installed. I tried installing it using apt-get install ffmpeg command.
But I got following error.
This is not a
Am 16.08.2011 13:52, schrieb Amandeep Singh:
Hey thanks. I would use the bug reporting tool next time. For your
info, I am running debian squeeze (latest version and fully updated).
And apt-get update didn't help.
You probably have some crap in your /etc/apt/sources.list. What does
apt-cache
Am 16.08.2011 21:59, schrieb Amandeep Singh:
Didn't help.
But sentences like this do not help either.
What exactly does aptitude print if you try to install ffmpeg?
What does apt-cache search libavdevice show?
What does apt-cache policy libavdevice* show?
Your sources.list looks reasonable.
Am 17.08.2011 13:49, schrieb Amandeep Singh:
$ apt-cache policy libavcodec52
libavcodec52:
Installed: 5:0.6.1+svn20101128-0.2
Candidate: 5:0.6.1+svn20101128-0.2
Version table:
*** 5:0.6.1+svn20101128-0.2 0
100 /var/lib/dpkg/status
4:0.5.2-6 0
500
Am 17.08.2011 13:49, schrieb Amandeep Singh:
On Wed, 2011-08-17 at 09:40 +0200, Fabian Greffrath wrote:
What exactly does aptitude print if you try to install ffmpeg?
$ apt-get install ffmpeg
^^^
BTW, aptitude != apt-get. Aptitude has an interactive
Am 19.08.2011 06:14, schrieb Micah Gersten:
mplayer2 is a very poor fork name used to confuse users.
it doesnt help that debian is using that name as a package:
http://packages.qa.debian.org/m/mplayer/news/20110817T173341Z.html
What else package name do you suggest for a software that calls
Hi,
thanks for the bug report.
Am 28.08.2011 14:53, schrieb Julian Hughes:
The same command with the same file works normally on amd64.
The same command with small files works normally on x86.
That's expected. Does it work if you recompile the package with
CFLAGS += -D_FILE_OFFSET_BITS=64
Am 29.08.2011 13:59, schrieb Reinhard Tartler:
Has been rejected for the vlc bugtracker. It seems that libdca does not
have a proper backtracker. Therefore, forwarding to the devel mailing
list might is more likely to reach people that could do something about
this.
Hello libdca developers,
I hope anyone is still listening?
Currently, a bug has been filed in the Debian Bug Tracker [1] about
dcadec failing to decode large files. The problem only occurs with
files larger than 2GB and only on i386 systems.
It was proposed to add
CFLAGS +=
Alright, then I guess there is nobody listening anymore... :(
Original-Nachricht
Betreff: Undelivered Mail Returned to Sender
Datum: Tue, 30 Aug 2011 11:34:16 +0200 (CEST)
Von: mailer-dae...@greffrath.com (Mail Delivery System)
An: fab...@greffrath.com
This is the mail system
Dear Dominik,
Am 23.09.2011 18:03, schrieb Dominik 'Rathann' Mierzejewski:
Dear All,
I'm sending this (Bcc) to Debian/Ubuntu package maintainers who are listed
under Original Maintainers on http://packages.ubuntu.com/oneiric/ffmpeg
and who seem to be doing something at least a bit related
Am 25.09.2011 11:05, schrieb Michael Cree:
x264 FTBFS from source on Alpha during the link of the shared library
because -fpic was not used in the compilation.
Why don't we just pass --enable-pic unconditionally for all shared
library builds?
- Fabian
Am 29.08.2011 16:33, schrieb Reinhard Tartler:
I'm personally not familiar enough with the code to make this decision,
and in fact, I suppose nobody in pkg-multimedia is.
I have rebuilt libdca once without and once with CFLAGS +=
-D_FILE_OFFSET_BITS=64 and created md5sums of all files in the
A more elegant fix is to add these build flags conditionally by means
of getconf, which adds the appropriate flags on i386 but adds nothing
new on amd64:
$ git diff
diff --git a/debian/rules b/debian/rules
index ad6f467..89a0069 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,8 @@
Am 05.10.2011 20:25, schrieb Reinhard Tartler:
I'm pretty sure that this would break compilation at least on i386. x264
ships with very sophisticated assembler optimizations that I'd expect to
break with that.
Does this also apply to other archs or is only i386 affected? In the
latter case I
/bugreport.cgi?bug=642810
The attached patch fixes this issue by considering alpha* as ALPHA in
the configure script.
Best Regards,
Fabian Greffrath
Author: Fabian Greffrath fabian+deb...@greffrath.com
Description: Debian's alpha buildds identify themselves as alphaev67,
so consider alpha* as ALPHA
Am 11.10.2011 01:10, schrieb Anti Spam User 3:
The following packages have unmet dependencies:
gnash-common : Depends: libavcodec53 (= 4:0.7-1) but it is not going
to be installed or
libavcodec-extra-53 (= 4:0.7-1) but it is not going to be installed
Depends: libavformat53 (= 4:0.7-1) but it is
Dear Michael,
thanks for presenting your - doubtless biased, but however - point of
view.
Am 11.10.2011 02:24, schrieb Michael Niedermayer:
In terms of features:
As far as I know, as an outsider, the reasons for the work were not
technical ones. Has the situation relaxed a bit in this
Hi,
Am 13.10.2011 23:17, schrieb Carl Eugen Hoyos:
Is this purely what you expect from Michael, or did you find anything in his
mail that made you believe it was written in a biased way?
(I ask because I was impressed how unbiased he wrote the message - I wouldn't
have been able to after what
Am 18.10.2011 16:52, schrieb Reinhard Tartler:
LAME 3.99 stable is now released and you can find sources there:
http://sourceforge.net/projects/lame/files/lame/3.99/
I have lost track a bit about what of our changes have been accepted
and commited upstream in this release. I think we can get
Am 24.10.2011 23:49, schrieb Matteo F. Vescovi:
Thanks for your advice... I've just committed the change you proposed.
So I'm also tagging this bug as pending, since it will be closed with
next upload.
I've seen you pass the --disable-optimize flag unconditionally for all
arches. Is this
Am 25.10.2011 09:13, schrieb Matteo F. Vescovi:
Since I'm not good in that and I really don't know how to split the
configure parameters depending on the arch, could you (or someone else
in the DMM Team) correct it?
Try this (but I don't know if armhf is already recognized by dpkg):
Am 25.10.2011 09:31, schrieb Matteo F. Vescovi:
OK, gonna try. Thanks a lot for the hint ;-)
You're welcome, don't forget to pass $(confflags) over to ./configure,
though. See the xvidcore package as an example for a straightforward
usage of this mechanism.
Am 25.10.2011 16:02, schrieb Matteo F. Vescovi:
Issue corrected. Thanks a lot, Fabian! :-)
Please, feel free to check if I made any big mistake in there.
I already made before... and corrected; it was my first time with it :-P
I'd say it looks reasonable under the assumption that
Am 25.10.2011 16:35, schrieb Fabian Greffrath:
I'd say it looks reasonable under the assumption that
DEB_HOST_ARCH_CPU is actually armhf on these machines.
It isn't:
$ dpkg-architecture -aarmhf 2 /dev/null | grep HOST_ARCH
DEB_HOST_ARCH=armhf
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=arm
To answer my own question: It has been applied twice, thus removing
our patch.
Am 02.11.2011 09:27, schrieb Fabian Greffrath:
Why do we still apply the build-on-hurd.patch (i.e. why is it possible
to apply it at all?), since it has been committed upstream some months
ago:
http
Am 03.11.2011 07:00, schrieb Sthu Deus:
Selected audio codec: [ffflac] afm: ffmpeg (FFmpeg FLAC audio)
If I read this correctly, then the internal ffmpeg flac decoder is
used to decode that file, not libflac, right?`Seems legit to reassign
this to either libavformat or mplayer2, any
reassign 647479 libavcodec53
found 647479 4:0.7.2-1
# the version is guessed, since the OP seems to use testing
thanks
Am 04.11.2011 09:25, schrieb Fabian Greffrath:
If I read this correctly, then the internal ffmpeg flac decoder is
used to decode that file, not libflac, right? Seems legit
201 - 300 of 921 matches
Mail list logo
