Re: Bug#567863: RFP: Handbrake - video transcoder
On Mo, Okt 10, 2011 at 07:12:23 (CEST), Rogério Brito wrote: > Hi there. > > I'm just including the Multimedia team, as they don't seem to be subscribed > to this bug. > > > On Oct 09 2011, Ralf Jung wrote: >> > Can't be packaged as x264 video codec and aac and mp3 audio codec aren't >> > free. >> How can that be, I can decode and encode mp3 and view MPEG4 videos without >> problems, installing only packages from the debian repositories...? > > Ralf, I think that when Christian wrote that, we didn't have x264 and lame > in the main archive. Things have changed since this bug was originally > filed. > > Once we have faac (if it's acceptable for our archive), then it would be > lovely to have a new version of handbrake (e.g., from their git tree) in the > archive, as it is a frontend for multimedia libraries that quite possibly > passes the "useable by mom and dad" usability test, especially since it > comes with sensible presets. I don't think we'll ever have faac in Debian because of its license. See https://bugs.edge.launchpad.net/ubuntu/+source/faac/+bug/374900 for details. Luckily, we have vo-aacenc (http://packages.debian.org/sid/main/libvo-aacenc0), which is the aac encoder from android and can encode aac just fine. >> As far as I know, Handbrake does not even implement any of this. It uses >> gstreamer, ffmpeg and others. > > Well, it does implement some things, like, for instance, their decombing > routines, which is very nice for some interlaced and almost-interlaced > things. > > As a side-effect, this decombing of theirs results in variable frame rates, > which potentially feeds fewer frames to x264 (or whatever encoder is in > question), making the bitrates tend to lower. > > Another side-effect that people may not appreciate because they run fast > architectures is that outputting fewer frames, some slower video cards > (e.g., in a powerpc machine) can have a fighting chance of playing some > videos. > > I don't know of any implementation of handbrake's decombing algorithm in > other software (e.g., ffmpeg/libav, mplayer, mplayer2, gstreamer etc.) Does > anyone know? > > The other transcoders (arista, transmaggedon) are jokes regarding the amount > of configurability that they allow. I agree that Handbrake is a really great tool. Actually, I did take a look at the sources and found out, that it would require a lot of efford to get it into debian. The reason is that the ship a lot of patched libraries that we already have in debian. I don't think this code duplication is acceptable for the Debian system. As for this RFP, I think any potential packager should identify the included libraries and start upstreaming the included patches. Then, try to build them against the libraries that Debian already ships. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#644873: marked as done (unmet dependencies: libavcodec53 : Depends: libavutil51 (< 4:0.7.2-99) but 5:0.8-0.1 is to be installed)
Your message dated Mon, 10 Oct 2011 08:12:26 +0200 with message-id <877h4dxtmd@faui43f.informatik.uni-erlangen.de> and subject line Re: Bug#644873: unmet dependencies: libavcodec53 : Depends: libavutil51 (< 4:0.7.2-99) but 5:0.8-0.1 is to be installed has caused the Debian Bug report #644873, regarding unmet dependencies: libavcodec53 : Depends: libavutil51 (< 4:0.7.2-99) but 5:0.8-0.1 is to be installed to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 644873: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644873 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: libavcodec53 Severity: grave apt-get -s install libavcodec53 The following packages have unmet dependencies: libavcodec53 : Depends: libavutil51 (< 4:0.7.2-99) but 5:0.8-0.1 is to be installed or libavutil-extra-51 (< 4:0.7.2.99) but it is not going to be installed The Package: libavutil51(4:0.7.2-1) is currently available at the package servers. http://packages.debian.org/wheezy/libavcodec53 told me in the list of related packages: * dep: multiarch-support Transitional package to ensure multiarch compatibility * dep: libavutil51 (<< 4:0.7.2-99) Libav utility library or libavutil-extra-51 (<< 4:0.7.2.99) Libav utility library dep: libavutil51 (>= 4:0.7.2-1) or libavutil-extra-51 (>= 4:0.7.2) * dep: libc0.1 (>= 2.7) [kfreebsd-amd64, kfreebsd-i386] didn't get this? Two "version areas"? By the way I tried to install gnash: 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 regards -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- On So, Okt 09, 2011 at 23:56:12 (CEST), spa...@freenet.de wrote: > Package: libavcodec53 > Severity: grave > > apt-get -s install libavcodec53 > > The following packages have unmet dependencies: > libavcodec53 : Depends: libavutil51 (< 4:0.7.2-99) but 5:0.8-0.1 is to be > installed or ^ > libavutil-extra-51 (< 4:0.7.2.99) but it is not > going to be installed > Please remove any references of debian-multimedia.org from your sources.list and try again. regards, -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 --- End Message --- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#567863: RFP: Handbrake - video transcoder
Hi there.
I'm just including the Multimedia team, as they don't seem to be subscribed
to this bug.
On Oct 09 2011, Ralf Jung wrote:
> > Can't be packaged as x264 video codec and aac and mp3 audio codec aren't
> > free.
> How can that be, I can decode and encode mp3 and view MPEG4 videos without
> problems, installing only packages from the debian repositories...?
Ralf, I think that when Christian wrote that, we didn't have x264 and lame
in the main archive. Things have changed since this bug was originally
filed.
Once we have faac (if it's acceptable for our archive), then it would be
lovely to have a new version of handbrake (e.g., from their git tree) in the
archive, as it is a frontend for multimedia libraries that quite possibly
passes the "useable by mom and dad" usability test, especially since it
comes with sensible presets.
> As far as I know, Handbrake does not even implement any of this. It uses
> gstreamer, ffmpeg and others.
Well, it does implement some things, like, for instance, their decombing
routines, which is very nice for some interlaced and almost-interlaced
things.
As a side-effect, this decombing of theirs results in variable frame rates,
which potentially feeds fewer frames to x264 (or whatever encoder is in
question), making the bitrates tend to lower.
Another side-effect that people may not appreciate because they run fast
architectures is that outputting fewer frames, some slower video cards
(e.g., in a powerpc machine) can have a fighting chance of playing some
videos.
I don't know of any implementation of handbrake's decombing algorithm in
other software (e.g., ffmpeg/libav, mplayer, mplayer2, gstreamer etc.) Does
anyone know?
The other transcoders (arista, transmaggedon) are jokes regarding the amount
of configurability that they allow.
Regards,
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#644873: unmet dependencies: libavcodec53 : Depends: libavutil51 (< 4:0.7.2-99) but 5:0.8-0.1 is to be installed
Package: libavcodec53 Severity: grave apt-get -s install libavcodec53 The following packages have unmet dependencies: libavcodec53 : Depends: libavutil51 (< 4:0.7.2-99) but 5:0.8-0.1 is to be installed or libavutil-extra-51 (< 4:0.7.2.99) but it is not going to be installed The Package: libavutil51(4:0.7.2-1) is currently available at the package servers. http://packages.debian.org/wheezy/libavcodec53 told me in the list of related packages: * dep: multiarch-support Transitional package to ensure multiarch compatibility * dep: libavutil51 (<< 4:0.7.2-99) Libav utility library or libavutil-extra-51 (<< 4:0.7.2.99) Libav utility library dep: libavutil51 (>= 4:0.7.2-1) or libavutil-extra-51 (>= 4:0.7.2) * dep: libc0.1 (>= 2.7) [kfreebsd-amd64, kfreebsd-i386] didn't get this? Two "version areas"? By the way I tried to install gnash: 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 regards -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: mplayer2 FTBFS on sparc
On Sun, Oct 09, 2011 at 10:50:39PM +0200, Kurt Roeckx wrote:
> On Sun, Oct 09, 2011 at 09:46:02PM +0200, Reinhard Tartler wrote:
> > On So, Okt 09, 2011 at 21:05:56 (CEST), Jurij Smakov wrote:
> >
> > > I thought about it, and I don't really see why we would keep the
> > > linux32 wrapper on the buildds. It made sense in the past, when we
> > > supported sparc32 and really wanted to guarantee that if a package
> > > has CPU type autodetection, we would get the code which works on both
> > > sparc32 and sparc64 machines. These days it probably just leads to a
> > > ton of unnecessarily-unoptimized binaries in the archive.
> >
> > Indeed, please notify me (e.g., with a wishlist bugreport) when the
> > buildds get changed, because I have to revert this change then:
>
> I basicly have 2 questions:
> - Do all sparc porters agree that I should drop the linux32 from
> the buildds? And will people fix things if it breaks?
I just checked what "old" binary objects I have in my /usr/bin and
/usr/lib, and found that in /usr/bin there are no such binaries, and
only a handful of libs in /usr/lib:
jurij@debian:/usr/lib$ for i in *; do file $i | grep 'ELF' | grep -v 'V8\+';
done | awk -F: '{print $1}'
libcroco-0.6.so.3.0.1
libgsm.so.1.0.12
libnfnetlink.so.0.2.0
libopenjpeg-2.1.3.0.so
libvorbisidec.so.1.0.2
jurij@debian:/usr/lib$
Based on that, I don't think that there will be any significant impact
(famous last words :-).
> - Do you still plan to have a (full) release of sparc for wheezy, or will
> you try to move to sparc64?
Personally, I'm not involved in any way with the sparc64 port, so I
don't know what the current status or plans with respect to wheezy
are (I also don't have any special reasons to be opposed to it
either). I guess that Aurelien is pretty much the only person who can
answer that.
Best regards,
--
Jurij Smakov ju...@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: mplayer2 FTBFS on sparc
On Sun, Oct 09, 2011 at 09:46:02PM +0200, Reinhard Tartler wrote: > On So, Okt 09, 2011 at 21:05:56 (CEST), Jurij Smakov wrote: > > > I thought about it, and I don't really see why we would keep the > > linux32 wrapper on the buildds. It made sense in the past, when we > > supported sparc32 and really wanted to guarantee that if a package > > has CPU type autodetection, we would get the code which works on both > > sparc32 and sparc64 machines. These days it probably just leads to a > > ton of unnecessarily-unoptimized binaries in the archive. > > Indeed, please notify me (e.g., with a wishlist bugreport) when the > buildds get changed, because I have to revert this change then: I basicly have 2 questions: - Do all sparc porters agree that I should drop the linux32 from the buildds? And will people fix things if it breaks? - Do you still plan to have a (full) release of sparc for wheezy, or will you try to move to sparc64? Kurt ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: mplayer2 FTBFS on sparc
On Sun, Oct 09, 2011 at 07:49:04PM +0200, Reinhard Tartler wrote: > Moreover, > Jurij suggests that mplayer2 should be compiled with -mcpu=ultrasparc > anyway. The upstream configure script will do that when running under a > 64bit kernel. However, this piece of information is 'hidden' on the > buildds by the use of linux32. I think in the general case you should not pass -mcpu or -march to gcc. Kurt ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
buen` regalo`
Esta es una buena noticia para usted, le deseamos un felizEsta es una buena noticia para ustedweb : bodoeo.comhay muchos tipos de cámaras digitales, teléfonos laptop.mobile, motos .todos nuestros productos son nuevos y originales, pero podemos ofrecer el mejor precio para ustedsaludos 2011-10-10 3:56:05___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: mplayer2 FTBFS on sparc
On So, Okt 09, 2011 at 21:05:56 (CEST), Jurij Smakov wrote: > On Sun, Oct 09, 2011 at 07:49:04PM +0200, Reinhard Tartler wrote: >> >> I've copied it here: >> http://people.debian.org/~siretart/tmp/mplayer2_2.0-134-g84d8671-6_sparc.build >> >> > I think the problem is that mplayer2 build system does CPU type >> > autodetection. The failed build used -mcpu=v8, however if I run it on >> > my machine (SunBlade 1000), I see that it compiles with >> > -mcpu=ultrasparc. If compilation on sperger used -mcpu=ultrasparc as >> > well, then it does not tell us anything, and it will fail again on >> > buildds. >> >> Well spotted, you are totally right, sperger used '-mcpu=ultrasparc'. >> >> > It looks like -mcpu=ultrasparc should always be used, because we do >> > not support earlier machines anymore. For example, our system binaries >> > report: >> > >> > jurij@debian:~/mplayer/mplayer2-2.0-134-g84d8671$ file /bin/ls >> > /bin/ls: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version >> > 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, >> > BuildID[sha1]=0xdef701c1cd7c87aa36fb4955a5cd430e9f2bd1d1, stripped >> > >> > which is what is produced when -mcpu=ultrasparc is used. With -mcpu=v8 >> > one gets: >> > >> > jurij@debian:~/mplayer/mplayer2-2.0-134-g84d8671$ file mixer.o >> > mixer.o: ELF 32-bit MSB relocatable, SPARC, version 1 (SYSV), not stripped >> > >> > I think the right way to fix it is to turn off (possibly broken) CPU >> > type autodetection and always use -mcpu=ultrasparc. >> >> Upon inspecting the upstream configure script further, I think I now >> understand (more) what's going on. The configure script checks with >> uname -a the architecture, and enables vis and ultrasparc if it finds >> 'sparc64'. And indeed, sperger fails in the same way if I build with >> 'linux32', exactly like on the buildd. >> >> Which still leaves us with the observation that the mentioned change in >> binutils broke the package build. Further inspection of the patch made >> my find the following 'workaround': When I pass this to configure: >> >> --extra-cflags='-Wa,-Av8' >> >> then this flag is added to the compiler flags. And indeed, this unbreaks >> the compilation, now even with -mcpu=v8. I wonder why gcc doesn't pass >> it on his own behalf? > > I've filed a bug against binutils (http://bugs.debian.org/644856) Thanks, the description seems pretty accurate to me. >> So, how do we proceed from here? I think I'll upload this change, but to >> me it seems that this is only a workaround and not a real fix. Moreover, >> Jurij suggests that mplayer2 should be compiled with -mcpu=ultrasparc >> anyway. The upstream configure script will do that when running under a >> 64bit kernel. However, this piece of information is 'hidden' on the >> buildds by the use of linux32. > > I thought about it, and I don't really see why we would keep the > linux32 wrapper on the buildds. It made sense in the past, when we > supported sparc32 and really wanted to guarantee that if a package > has CPU type autodetection, we would get the code which works on both > sparc32 and sparc64 machines. These days it probably just leads to a > ton of unnecessarily-unoptimized binaries in the archive. Indeed, please notify me (e.g., with a wishlist bugreport) when the buildds get changed, because I have to revert this change then: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/mplayer2.git;a=commit;h=992bf949037d0fafb69e87cbcc57393e528ef265 -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: mplayer2 FTBFS on sparc
On Sun, Oct 09, 2011 at 07:49:04PM +0200, Reinhard Tartler wrote: > > I've copied it here: > http://people.debian.org/~siretart/tmp/mplayer2_2.0-134-g84d8671-6_sparc.build > > > I think the problem is that mplayer2 build system does CPU type > > autodetection. The failed build used -mcpu=v8, however if I run it on > > my machine (SunBlade 1000), I see that it compiles with > > -mcpu=ultrasparc. If compilation on sperger used -mcpu=ultrasparc as > > well, then it does not tell us anything, and it will fail again on > > buildds. > > Well spotted, you are totally right, sperger used '-mcpu=ultrasparc'. > > > It looks like -mcpu=ultrasparc should always be used, because we do > > not support earlier machines anymore. For example, our system binaries > > report: > > > > jurij@debian:~/mplayer/mplayer2-2.0-134-g84d8671$ file /bin/ls > > /bin/ls: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version > > 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, > > BuildID[sha1]=0xdef701c1cd7c87aa36fb4955a5cd430e9f2bd1d1, stripped > > > > which is what is produced when -mcpu=ultrasparc is used. With -mcpu=v8 > > one gets: > > > > jurij@debian:~/mplayer/mplayer2-2.0-134-g84d8671$ file mixer.o > > mixer.o: ELF 32-bit MSB relocatable, SPARC, version 1 (SYSV), not stripped > > > > I think the right way to fix it is to turn off (possibly broken) CPU > > type autodetection and always use -mcpu=ultrasparc. > > Upon inspecting the upstream configure script further, I think I now > understand (more) what's going on. The configure script checks with > uname -a the architecture, and enables vis and ultrasparc if it finds > 'sparc64'. And indeed, sperger fails in the same way if I build with > 'linux32', exactly like on the buildd. > > Which still leaves us with the observation that the mentioned change in > binutils broke the package build. Further inspection of the patch made > my find the following 'workaround': When I pass this to configure: > > --extra-cflags='-Wa,-Av8' > > then this flag is added to the compiler flags. And indeed, this unbreaks > the compilation, now even with -mcpu=v8. I wonder why gcc doesn't pass > it on his own behalf? I've filed a bug against binutils (http://bugs.debian.org/644856) > So, how do we proceed from here? I think I'll upload this change, but to > me it seems that this is only a workaround and not a real fix. Moreover, > Jurij suggests that mplayer2 should be compiled with -mcpu=ultrasparc > anyway. The upstream configure script will do that when running under a > 64bit kernel. However, this piece of information is 'hidden' on the > buildds by the use of linux32. I thought about it, and I don't really see why we would keep the linux32 wrapper on the buildds. It made sense in the past, when we supported sparc32 and really wanted to guarantee that if a package has CPU type autodetection, we would get the code which works on both sparc32 and sparc64 machines. These days it probably just leads to a ton of unnecessarily-unoptimized binaries in the archive. > I personally don't have a sparc machine, nor the time or enough > knowledge to drive this further. My main concern is to have mplayer2 in > testing, which my change fulfills. Dear sparc porters, please advise, > ideally in form of patches, how to improve the mplayer2 package. I'm > pretty sure the patches would also apply to the mplayer package. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: mplayer2 FTBFS on sparc
On So, Okt 09, 2011 at 15:45:07 (CEST), Jurij Smakov wrote: > On Sun, Oct 09, 2011 at 10:03:47AM +0200, Reinhard Tartler wrote: >> On Sa, Okt 08, 2011 at 19:34:47 (CEST), Jurij Smakov wrote: >> >> > On Sat, Oct 08, 2011 at 06:51:49PM +0200, Kurt Roeckx wrote: >> >> On Sat, Oct 08, 2011 at 03:21:50PM +0200, Reinhard Tartler wrote: >> >> > Hi, >> >> > >> >> > I've noticed that mplayer2 2.0-134-g84d8671-7 failed to build on sparc, >> >> > and I'm quite puzzled why. There are no code changes compared to >> >> > 2.0-134-g84d8671-6, which did build on the very same buildd 'lebrun': >> >> > >> >> > https://buildd.debian.org/status/logs.php?pkg=mplayer2&arch=sparc >> >> > >> >> > Could anyone please have a look and explain me what's going on? Is there >> >> > anything to fix in the package? (porters CC'ed with this mail). >> >> >> >> -7 was build with binutils_2.21.53.20110922-1, gcc-4.6_4.6.1-13, >> >> dpkg-dev_1.16.1 >> >> -6 was build with binutils_2.21.53.20110805-1, gcc-4.6_4.6.1-7, >> >> dpkg-dev_1.16.0.3 >> >> >> >> I suspect that one of those changes broke it for you. >> > >> > As I mentioned to Reinhard on irc (not sure whether he noticed), this >> > commit looks suspicious, as it introduces the "hardware compatibility" >> > error message, seen during failed build: >> > >> > http://repo.or.cz/w/binutils.git/commitdiff/24f272de258d79c9d959143a8fd626b9961a8ac0 >> >> I did but had to leave from irc. >> >> Funny thing, a manual build in sperger's sid chroot did succeed. I used: >> >> binutils (2.21.90.20111004-1) >> gcc-4.6 (4.6.1-13) >> dpkg (1.16.1) > > Do you have the logs from the sperger build? I've copied it here: http://people.debian.org/~siretart/tmp/mplayer2_2.0-134-g84d8671-6_sparc.build > I think the problem is that mplayer2 build system does CPU type > autodetection. The failed build used -mcpu=v8, however if I run it on > my machine (SunBlade 1000), I see that it compiles with > -mcpu=ultrasparc. If compilation on sperger used -mcpu=ultrasparc as > well, then it does not tell us anything, and it will fail again on > buildds. Well spotted, you are totally right, sperger used '-mcpu=ultrasparc'. > It looks like -mcpu=ultrasparc should always be used, because we do > not support earlier machines anymore. For example, our system binaries > report: > > jurij@debian:~/mplayer/mplayer2-2.0-134-g84d8671$ file /bin/ls > /bin/ls: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version > 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, > BuildID[sha1]=0xdef701c1cd7c87aa36fb4955a5cd430e9f2bd1d1, stripped > > which is what is produced when -mcpu=ultrasparc is used. With -mcpu=v8 > one gets: > > jurij@debian:~/mplayer/mplayer2-2.0-134-g84d8671$ file mixer.o > mixer.o: ELF 32-bit MSB relocatable, SPARC, version 1 (SYSV), not stripped > > I think the right way to fix it is to turn off (possibly broken) CPU > type autodetection and always use -mcpu=ultrasparc. Upon inspecting the upstream configure script further, I think I now understand (more) what's going on. The configure script checks with uname -a the architecture, and enables vis and ultrasparc if it finds 'sparc64'. And indeed, sperger fails in the same way if I build with 'linux32', exactly like on the buildd. Which still leaves us with the observation that the mentioned change in binutils broke the package build. Further inspection of the patch made my find the following 'workaround': When I pass this to configure: --extra-cflags='-Wa,-Av8' then this flag is added to the compiler flags. And indeed, this unbreaks the compilation, now even with -mcpu=v8. I wonder why gcc doesn't pass it on his own behalf? So, how do we proceed from here? I think I'll upload this change, but to me it seems that this is only a workaround and not a real fix. Moreover, Jurij suggests that mplayer2 should be compiled with -mcpu=ultrasparc anyway. The upstream configure script will do that when running under a 64bit kernel. However, this piece of information is 'hidden' on the buildds by the use of linux32. I personally don't have a sparc machine, nor the time or enough knowledge to drive this further. My main concern is to have mplayer2 in testing, which my change fulfills. Dear sparc porters, please advise, ideally in form of patches, how to improve the mplayer2 package. I'm pretty sure the patches would also apply to the mplayer package. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: mplayer2 FTBFS on sparc
On Sun, Oct 09, 2011 at 10:03:47AM +0200, Reinhard Tartler wrote: > On Sa, Okt 08, 2011 at 19:34:47 (CEST), Jurij Smakov wrote: > > > On Sat, Oct 08, 2011 at 06:51:49PM +0200, Kurt Roeckx wrote: > >> On Sat, Oct 08, 2011 at 03:21:50PM +0200, Reinhard Tartler wrote: > >> > Hi, > >> > > >> > I've noticed that mplayer2 2.0-134-g84d8671-7 failed to build on sparc, > >> > and I'm quite puzzled why. There are no code changes compared to > >> > 2.0-134-g84d8671-6, which did build on the very same buildd 'lebrun': > >> > > >> > https://buildd.debian.org/status/logs.php?pkg=mplayer2&arch=sparc > >> > > >> > Could anyone please have a look and explain me what's going on? Is there > >> > anything to fix in the package? (porters CC'ed with this mail). > >> > >> -7 was build with binutils_2.21.53.20110922-1, gcc-4.6_4.6.1-13, > >> dpkg-dev_1.16.1 > >> -6 was build with binutils_2.21.53.20110805-1, gcc-4.6_4.6.1-7, > >> dpkg-dev_1.16.0.3 > >> > >> I suspect that one of those changes broke it for you. > > > > As I mentioned to Reinhard on irc (not sure whether he noticed), this > > commit looks suspicious, as it introduces the "hardware compatibility" > > error message, seen during failed build: > > > > http://repo.or.cz/w/binutils.git/commitdiff/24f272de258d79c9d959143a8fd626b9961a8ac0 > > I did but had to leave from irc. > > Funny thing, a manual build in sperger's sid chroot did succeed. I used: > > binutils (2.21.90.20111004-1) > gcc-4.6 (4.6.1-13) > dpkg (1.16.1) Do you have the logs from the sperger build? I think the problem is that mplayer2 build system does CPU type autodetection. The failed build used -mcpu=v8, however if I run it on my machine (SunBlade 1000), I see that it compiles with -mcpu=ultrasparc. If compilation on sperger used -mcpu=ultrasparc as well, then it does not tell us anything, and it will fail again on buildds. It looks like -mcpu=ultrasparc should always be used, because we do not support earlier machines anymore. For example, our system binaries report: jurij@debian:~/mplayer/mplayer2-2.0-134-g84d8671$ file /bin/ls /bin/ls: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xdef701c1cd7c87aa36fb4955a5cd430e9f2bd1d1, stripped which is what is produced when -mcpu=ultrasparc is used. With -mcpu=v8 one gets: jurij@debian:~/mplayer/mplayer2-2.0-134-g84d8671$ file mixer.o mixer.o: ELF 32-bit MSB relocatable, SPARC, version 1 (SYSV), not stripped I think the right way to fix it is to turn off (possibly broken) CPU type autodetection and always use -mcpu=ultrasparc. Best regards, -- Jurij Smakov ju...@wooyd.org Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
?????@????????
L?nzP^P^P^@L??n??P^@K@???La??nLa?n %L?nL@?~?`?`@?~`???z@???^@z@@?k@`?^@`?z@^@?z@???M??k??k??]^@`??z@???^@?`?z@??^@??`???z@??^@??`?z@???M???k???k???]^@???z@?^@??z@?^@??``???`??`??z@^@??```??z@^@??``??`?z@???nL@?~???n??LanL@?~?`?`?nP^LanL@?~???nT@??@LanL@?~?`?`?nP^LanL@?~???n??@???LanL@?~nKLanL@?~?`?`?nP^LanL@?~???n@?KLanL@?~?`?`?nP^LanL@?~???n??@LanL@?~nk@LanL@?~nKLanL@?~?`?`?nP^LanL@?~???n???LanL@?~?`?`?nP^LanL@?~???nKKKLanL??nL??nL@?~???n?LanL@?~?`?`?nP^LanL@?~???n??@@??@??LanL@?~?`?`?nP^LanL@?~???n??LanL@?~?`?`?nP^LanL@?~???n}???DLanL@?~?`?`?nP^LanL@?~???n??@???KLanL@?~?`?`?nP^LanL@?~???n??@@??@?LanL@?~?`?`?nP^LanL@?~???n???LanL@?~?`?`?nP^LanL@?~???n??@??lLanL@?~?`?`?nP^LanL@?~???n??@??LanL@?~?`?`?nP^LanL@?~???n???@???KLanL??nL??nL@?~???n??@???LanL@?~?`?`?nP^LanL@?~???n???kLanL@?~?`?`?nP^LanL@?~???n???@???@?@???LanLanLa?n %L?nL@?~?`?`@?~`???z@???^@z@@?k@`?^@`?z@^@?z@???M??k??k??]^@`??z@???^@?`?z@??^@??`???z@??^@??`?z@???M???k???k???]^@???z@?^@??z@?^@??``???`??`??z@^@??```??z@^@??``??`?z@???nL@?~???nL@?~?`?`@?~`???z@???^@z@@?k@`?^@`?z@^@?z@???M??k??k??]^@`??z@???^@?`?z@??^@??`???z@??^@??`?z@???M???k???k???]^@???z@?^@??z@?^@??``???`??`??z@^@??```??z@^@??``??`?z@???nL@?~?nL@?~???n??LanL@?~?`?`?nP^LanL@?~???n?LanL@?~?`?`?nP^LanL@?~???n??@??@??LanL@?~?`?`?nP^LanL@?~???n???@??@@?LanL@?~?`?`?nP^LanL@?~???n???@?LanLanLanLanLanLa?n %L?nL@?~?`?`@?~`???z@???^@z@@?k@`?^@`?z@^@?z@???M??k??k??]^@`??z@???^@?`?z@??^@??`???z@??^@??`?z@???M???k???k???]^@???z@?^@??z@?^@??``???`??`??z@^@??```??z@^@??``??`?z@???nL@?~???n`??`?@??z??z??LanLanLa?n %L?nL@?~?`?`@?~`???z@???^@z@@?k@`?^@`?z@^@?z@???M??k??k??]^@`??z@???^@?`?z@??^@??`???z@??^@??`?z@???M???k???k???]^@???z@?^@??z@?^@??``???`??`??z@^@??```??z@^@??``??`?z@???nL@?~nLanLanP^La?n ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: pd-hid caught in unstable, but why?
On 09/10/11 07:58, Hans-Christoph Steiner wrote: On Oct 8, 2011, at 1:15 AM, Simon Wise wrote: On 08/10/11 12:54, Hans-Christoph Steiner wrote: On Oct 7, 2011, at 11:48 PM, Simon Wise wrote: On 07/10/11 23:00, Hans-Christoph Steiner wrote: I was just checking in on my packages, it seems that pd-hid is caught in unstable for 75 days, but I can't figure out what the issue is. The error message is "Adding pd-hid makes 1 non-depending packages uninstallable on kfreebsd-amd64: pd-hid " http://release.debian.org/migration/testing.pl?package=pd-hid;expand=1 But what is that 1 non-depending package? Is it 'puredata (<<0.43)'? Other packages with that same Build-Depends are already in testing. The package is listed as pd-hid itself ... apparently it is not installable on kfreebsd-amd64, that is what is keeping it out of testing That's odd, because buildd seems to show it as installed on kFreeBSD: https://buildd.debian.org/status/package.php?p=pd-hid It says that moving pd-hid to testing prevents pd-hid from installing on testing in kfreebsd-amd64 [and maybe more architectures, only the first found is listed]. Since it IS installed on sid, is there something missing from testing, but present in sid, that pd-hid needs before it can be installed? something that is not listed as a dependency, but should be? Simon pd-hid was written in 2004-2005 and uses the Linux input.h. It's had bug fixes since then, but no major changes. I can't imagine what pd-hid would need that wouldn't be in oldstable, or sarge even. Any ideas on how I can find details on what the issue is? I don't think testing has everything that is in stable - a combination of sid and testing together probably would have all that pd-hid needs, but maybe something hasn't migrated from sid yet --- maybe something to do with serial, or usb or something. Since it builds in sid, whatever is the missing dependency will presumably get migrated eventually. Could you try building on a pure, minimal 'testing' system that has as little as possible already installed and see what pd-hid is missing there? Simon ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: mplayer2 FTBFS on sparc
On Sa, Okt 08, 2011 at 19:34:47 (CEST), Jurij Smakov wrote: > On Sat, Oct 08, 2011 at 06:51:49PM +0200, Kurt Roeckx wrote: >> On Sat, Oct 08, 2011 at 03:21:50PM +0200, Reinhard Tartler wrote: >> > Hi, >> > >> > I've noticed that mplayer2 2.0-134-g84d8671-7 failed to build on sparc, >> > and I'm quite puzzled why. There are no code changes compared to >> > 2.0-134-g84d8671-6, which did build on the very same buildd 'lebrun': >> > >> > https://buildd.debian.org/status/logs.php?pkg=mplayer2&arch=sparc >> > >> > Could anyone please have a look and explain me what's going on? Is there >> > anything to fix in the package? (porters CC'ed with this mail). >> >> -7 was build with binutils_2.21.53.20110922-1, gcc-4.6_4.6.1-13, >> dpkg-dev_1.16.1 >> -6 was build with binutils_2.21.53.20110805-1, gcc-4.6_4.6.1-7, >> dpkg-dev_1.16.0.3 >> >> I suspect that one of those changes broke it for you. > > As I mentioned to Reinhard on irc (not sure whether he noticed), this > commit looks suspicious, as it introduces the "hardware compatibility" > error message, seen during failed build: > > http://repo.or.cz/w/binutils.git/commitdiff/24f272de258d79c9d959143a8fd626b9961a8ac0 I did but had to leave from irc. Funny thing, a manual build in sperger's sid chroot did succeed. I used: binutils (2.21.90.20111004-1) gcc-4.6 (4.6.1-13) dpkg (1.16.1) Shall we retry the package on the buildd network, then? Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
