Re: [SCM] mma packaging annotated tag, upstream/1.7, created. upstream/1.7
Hello: Assuming you did a gbp-pull and git-buildpackage is configured correctly it should work. Also when I created the missing tag a while ago I confirmed that upstream/1.7 contain the correct source when compared to a tarball I downloaded from upstream and I also merged upstream/1.7 to master and verified that everything was peachy. So the git in alioth should be fine. Try doing a gbp-pull or cloning it again. You will get build errors during dh_install since files got renamed. I could fix them but not sure if you already fixed it all. Cheers, Miguel On Wed, Feb 2, 2011 at 7:53 AM, Joel Roth jo...@pobox.com wrote: Michael and others, I wonder if I made a mistake in merging the upstream version. When I try building this package, I get a huge raft of errors. Could someone see if these are common or readily solved? thanks, Joel -- Joel Roth ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] mma packaging annotated tag, upstream/1.7, created. upstream/1.7
On Wed, Feb 02, 2011 at 08:09:44AM +, Miguel Colon wrote: Hello: Assuming you did a gbp-pull and git-buildpackage is configured correctly it should work. Also when I created the missing tag a while ago I confirmed that upstream/1.7 contain the correct source when compared to a tarball I downloaded from upstream and I also merged upstream/1.7 to master and verified that everything was peachy. So the git in alioth should be fine. Try doing a gbp-pull or cloning it again. You will get build errors during dh_install since files got renamed. I could fix them but not sure if you already fixed it all. Thanks Miguel, Looks better. With git-buildpackage, I now get as far as dh_install: dh_installdirs dh_install cp: cannot stat `./mma': No such file or directory The following line in mma.install appears to be at fault. mma usr/bin The executable is actally called mma.py. I'd like to do this: mma.py usr/bin/mma But according to 'man dh_install' the destination must be a directory. Any suggestions? thanks again, Joel -- Joel Roth ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#611791: libmms0: libmms alignment problems on ARM
Package: libmms0 Version: 0.6-1 Severity: important Tags: upstream libmms 0.6 has some alignment issues on ARM. This causes any mms_connect() to fail on those platforms due to GUID compare mismatches. See http://sourceforge.net/tracker/?func=detailaid=3137994group_id=101989atid=630607 for the upstream bug report. As this is fixed in later upstream releases, please update the libmms package to version 0.6.1 or 0.6.2. Thanks, Danny -- System Information: Debian Release: 6.0 APT prefers testing APT policy: (990, 'testing') Architecture: armel (armv5tel) Kernel: Linux 2.6.37 (PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libmms0 depends on: ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libglib2.0-0 2.24.2-1 The GLib library of C routines libmms0 recommends no packages. libmms0 suggests no packages. -- no debconf information ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] mma packaging annotated tag, upstream/1.7, created. upstream/1.7
Hello: That should work. Try to pull the commit I just made to make sure. It should complain at dh_installchangelogs now. Cheers, Miguel On Wed, Feb 2, 2011 at 9:16 AM, Joel Roth jo...@pobox.com wrote: On Wed, Feb 02, 2011 at 08:09:44AM +, Miguel Colon wrote: Hello: Assuming you did a gbp-pull and git-buildpackage is configured correctly it should work. Also when I created the missing tag a while ago I confirmed that upstream/1.7 contain the correct source when compared to a tarball I downloaded from upstream and I also merged upstream/1.7 to master and verified that everything was peachy. So the git in alioth should be fine. Try doing a gbp-pull or cloning it again. You will get build errors during dh_install since files got renamed. I could fix them but not sure if you already fixed it all. Thanks Miguel, Looks better. With git-buildpackage, I now get as far as dh_install: dh_installdirs dh_install cp: cannot stat `./mma': No such file or directory The following line in mma.install appears to be at fault. mma usr/bin The executable is actally called mma.py. I'd like to do this: mma.py usr/bin/mma But according to 'man dh_install' the destination must be a directory. Any suggestions? thanks again, Joel -- Joel Roth ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#611791: libmms0: libmms alignment problems on ARM
Am 02.02.2011 10:14, schrieb Danny Baumann: libmms 0.6 has some alignment issues on ARM. This causes any mms_connect() to fail on those platforms due to GUID compare mismatches. See http://sourceforge.net/tracker/?func=detailaid=3137994group_id=101989atid=630607 for the upstream bug report. As this is fixed in later upstream releases, please update the libmms package to version 0.6.1 or 0.6.2. libmms 0.6.2 is already prepared in our git repository, but is scheduled for post-squeeze. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#611791: libmms0: libmms alignment problems on ARM
Am 02.02.2011 10:14, schrieb Danny Baumann: libmms 0.6 has some alignment issues on ARM. This causes any mms_connect() to fail on those platforms due to GUID compare mismatches. See http://sourceforge.net/tracker/?func=detailaid=3137994group_id=101989atid=630607 for the upstream bug report. As this is fixed in later upstream releases, please update the libmms package to version 0.6.1 or 0.6.2. PS: I suspect the following commit fixes this issue. If you can confirm this, I think this fix would be a candidate for a 0.6-1squeeze1 package in squeeze+r1. http://libmms.git.sourceforge.net/git/gitweb.cgi?p=libmms/libmms;a=commitdiff;h=160a0c1c29b2be301a409856c4393dc9c1b88dd0 - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#611791: libmms0: libmms alignment problems on ARM
Am 02.02.2011 10:58, schrieb Danny Baumann: Please excuse my lack of understanding, but given that only maintenance and bugfixing work seems to be done in upstream libmms, and given that the alignment bug makes it impossible to properly use libmms on ARM, why are the newer releases not considered for squeeze? Because they were released too late (i.e. squeeze was already in freeze) and bugs that were fixed in the new versions were reported too late (i.e. today). ;) If updating libmms is not an option, could you consider backporting the alignment fix? (http://libmms.git.sourceforge.net/git/gitweb.cgi?p=libmms/libmms;a=commit;h=160a0c1c29b2be301a409856c4393dc9c1b88dd0) As stated in my previous mail, this will be considered for the next point release. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#611791: libmms0: libmms alignment problems on ARM
Hi, libmms 0.6 has some alignment issues on ARM. This causes any mms_connect() to fail on those platforms due to GUID compare mismatches. See http://sourceforge.net/tracker/?func=detailaid=3137994group_id=101989atid=630607 for the upstream bug report. As this is fixed in later upstream releases, please update the libmms package to version 0.6.1 or 0.6.2. libmms 0.6.2 is already prepared in our git repository, but is scheduled for post-squeeze. Please excuse my lack of understanding, but given that only maintenance and bugfixing work seems to be done in upstream libmms, and given that the alignment bug makes it impossible to properly use libmms on ARM, why are the newer releases not considered for squeeze? If updating libmms is not an option, could you consider backporting the alignment fix? (http://libmms.git.sourceforge.net/git/gitweb.cgi?p=libmms/libmms;a=commit;h=160a0c1c29b2be301a409856c4393dc9c1b88dd0) Thanks, Danny ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Libsoundtouch{0,1}-dev?
Ardour (perhaps among others) build-depends on libsoundtouch1-dev, but this is not built by the archive as soundtouch provides libsoundtouch-dev but not libsoundtouch1-dev. Is this just a typo in soundtouch packaging, or do we have a more serious problem? -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Libsoundtouch{0,1}-dev?
On Wed, Feb 02, 2011 at 02:54:37PM +0100, David Henningsson wrote: Ardour (perhaps among others) build-depends on libsoundtouch1-dev, but this is not built by the archive as soundtouch provides libsoundtouch-dev but not libsoundtouch1-dev. Is this just a typo in soundtouch packaging, or do we have a more serious problem? The changelog in http://packages.qa.debian.org/s/soundtouch/news/20110116T154758Z.html says: * Rename libsoundtouch1c2 to libsoundtouch0 and libsoundtouch1-dev to libsoundtouch0-dev so we comply with policy. - Obsolete c2 naming due to CXX transition is not needed anymore. - ardour used to provide libsoundtouch0 and libsoundtouch0-dev as mentioned in #271108. These packages were removed in 2004. So looks like a transition to me, and we probably need to readjust ardour's build dependency (to libsoundtouch-dev). I can take care of this if agreed upon. Perhaps Alessio wants to provide further clarification. Cheers -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Libsoundtouch{0,1}-dev?
Am Mittwoch, den 02.02.2011, 15:23 +0100 schrieb Adrian Knoth: On Wed, Feb 02, 2011 at 02:54:37PM +0100, David Henningsson wrote: Ardour (perhaps among others) build-depends on libsoundtouch1-dev, but this is not built by the archive as soundtouch provides libsoundtouch-dev but not libsoundtouch1-dev. Is this just a typo in soundtouch packaging, or do we have a more serious problem? The changelog in http://packages.qa.debian.org/s/soundtouch/news/20110116T154758Z.html says: * Rename libsoundtouch1c2 to libsoundtouch0 and libsoundtouch1-dev to libsoundtouch0-dev so we comply with policy. - Obsolete c2 naming due to CXX transition is not needed anymore. - ardour used to provide libsoundtouch0 and libsoundtouch0-dev as mentioned in #271108. These packages were removed in 2004. So looks like a transition to me, and we probably need to readjust ardour's build dependency (to libsoundtouch-dev). I can take care of this if agreed upon. It's libsoundtouch0-dev. The question is: Why doesn't libsoundtouch-dev exist? -- Benjamin Drung Debian Ubuntu Developer signature.asc Description: This is a digitally signed message part ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Libsoundtouch{0,1}-dev?
On Wed, Feb 02, 2011 at 04:10:51PM +0100, Benjamin Drung wrote: http://packages.qa.debian.org/s/soundtouch/news/20110116T154758Z.html says: * Rename libsoundtouch1c2 to libsoundtouch0 and libsoundtouch1-dev to libsoundtouch0-dev so we comply with policy. - Obsolete c2 naming due to CXX transition is not needed anymore. - ardour used to provide libsoundtouch0 and libsoundtouch0-dev as mentioned in #271108. These packages were removed in 2004. So looks like a transition to me, and we probably need to readjust ardour's build dependency (to libsoundtouch-dev). I can take care of this if agreed upon. It's libsoundtouch0-dev. The question is: Why doesn't libsoundtouch-dev exist? It's just a Provides: http://git.debian.org/?p=pkg-multimedia/soundtouch.git;a=blob;f=debian/control;h=64e2d9f736500c6eef76d1572d6ca9fe1d569b7f;hb=HEAD -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Libsoundtouch{0,1}-dev?
On Wed, Feb 02, 2011 at 04:10:51PM +0100, Benjamin Drung wrote: Am Mittwoch, den 02.02.2011, 15:23 +0100 schrieb Adrian Knoth: On Wed, Feb 02, 2011 at 02:54:37PM +0100, David Henningsson wrote: Ardour (perhaps among others) build-depends on libsoundtouch1-dev, but this is not built by the archive as soundtouch provides libsoundtouch-dev but not libsoundtouch1-dev. Is this just a typo in soundtouch packaging, or do we have a more serious problem? The changelog in http://packages.qa.debian.org/s/soundtouch/news/20110116T154758Z.html says: * Rename libsoundtouch1c2 to libsoundtouch0 and libsoundtouch1-dev to libsoundtouch0-dev so we comply with policy. - Obsolete c2 naming due to CXX transition is not needed anymore. - ardour used to provide libsoundtouch0 and libsoundtouch0-dev as mentioned in #271108. These packages were removed in 2004. So looks like a transition to me, and we probably need to readjust ardour's build dependency (to libsoundtouch-dev). I can take care of this if agreed upon. It's libsoundtouch0-dev. The question is: Why doesn't libsoundtouch-dev exist? Virtual unversioned -dev package names providing a corresponding versioned package is an optional convenience feature, not mandated. Also, it makes sense to use directly only if a single real package satisfies that virtual dependency at each distro suite. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] mma packaging annotated tag, upstream/1.7, created. upstream/1.7
On Wed, Feb 02, 2011 at 09:45:50AM +, Miguel Colon wrote: Hello: That should work. Try to pull the commit I just made to make sure. It should complain at dh_installchangelogs now. Great. It goes much further. A few lintian warnings remain. W: mma source: changelog-should-mention-nmu W: mma source: source-nmu-has-incorrect-version-number 1.7-1 W: mma source: no-human-maintainers W: mma source: ancient-standards-version 3.7.3 (current is 3.9.1) W: mma: binary-without-manpage usr/bin/mma-gb Will study the patches you made. Regards, Joel Cheers, Miguel -- Joel Roth ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Adopting Ecasound
On Wed, Feb 02, 2011 at 04:45:19PM +0100, Alessandro Ghedini wrote: Hello, sorry for the late reply, I'm currently on vacation and Internet connectivity is quite unreliable (I also don't have my PC). Thanks for dropping by! :-) On Sun, Jan 30, 2011 at 03:24, Joel Roth jo...@pobox.com wrote: TODO says: * Fix Python module Builds without errors. That wasn't the problem. I have no exprience in Python modules packaging, so I'm not sure it is the right way to do it (even if it builds). * Maybe build shared libecasound, libecasoundc, libkvutils they all appear to build They are built statically. Since this is not a good thing we should make them build dynamically and add some new packages (e.g. libecasound2 libecasoundc2 and libkvutils2). I'll have a look at this when I'll be back home. * ... What about large file support? Does anyone know what the dependencies are? This seems a good idea to me. I asked on the ecasound list. Apparently we don't need to do anything special to support large files. On amd64 systems (which I tested on) there is no problem, although the ./configure output is misleading. Someone should still probabaly test under a 32-bit system. Meanwhile, enjoy :-) :-) Best, Joel Cheers ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers -- Joel Roth ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] mma packaging annotated tag, upstream/1.7, created. upstream/1.7
Hello: Sure, I fixed a few things since I only planned to make 1 commit but made a mistake since I forgot about the dh_install limitations. Anyway since you seem to be doing well on your own now I was gonna leave it at this but I noticed that you added a new manpage on the source. When using quilt (3.0) all the changes should be done inside the debian folder and the source left untouched. You should revert the commit that adds docs/man/mma-gb.1 and add it as a patch in debian/patches that creates this file and (if applicable) report it upstream (this link should give you some info: http://dep.debian.net/deps/dep3/) . At this point you will probably also want to add a .gitignore file to ignore the .pc folder. Cheers, Miguel On Wed, Feb 2, 2011 at 5:44 PM, Joel Roth jo...@pobox.com wrote: On Wed, Feb 02, 2011 at 09:45:50AM +, Miguel Colon wrote: Hello: That should work. Try to pull the commit I just made to make sure. It should complain at dh_installchangelogs now. Great. It goes much further. A few lintian warnings remain. W: mma source: changelog-should-mention-nmu W: mma source: source-nmu-has-incorrect-version-number 1.7-1 W: mma source: no-human-maintainers W: mma source: ancient-standards-version 3.7.3 (current is 3.9.1) W: mma: binary-without-manpage usr/bin/mma-gb Will study the patches you made. Regards, Joel Cheers, Miguel -- Joel Roth ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#599329: vainfo segfaults
On Wed, Oct 06, 2010 at 11:05:33PM +0600, Andrey Rahmatullin wrote: $ vainfo libva: libva version 0.31.1 Xlib: extension XFree86-DRI missing on display :0.0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/dri/nvidia_drv_video.so zsh: segmentation fault vainfo If I downgrade only libva11, vainfo still segfaults. If I downgrade only libva-x11-1, vainfo can't load nvidia_drv_video.so. If I downgrade both libva1 and libva-x11-1, vainfo works. I have an nVidia card with nvidia-glx, nvidia- vdpau-driver etc. from experimental. I've upgraded from 1.0.7 to 1.0.8 and the situation appeared again. vainfo and vlc with VAAPI enabled segfault with libva-x11-1 1.0.8 and work with 1.0.7. -- WBR, wRAR signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: Libsoundtouch{0,1}-dev?
So looks like a transition to me, and we probably need to readjust ardour's build dependency (to libsoundtouch-dev). I can take care of this if agreed upon. Hello, yes it's a transition I was the one that made renamed it. Perhaps Alessio wants to provide further clarification. Last time I spoke with Alessio about it from what I understood and remember he was waiting for post-squeeze. But better to wait for an official response since I might have misunderstood. Ardour (perhaps among others) build-depends on libsoundtouch1-dev, but this is not built by the archive as soundtouch provides libsoundtouch-dev but not libsoundtouch1-dev. Is this just a typo in soundtouch packaging, or do we have a more serious problem? The source packages affected are: Package: ardour Package: audacity Package: djplay Package: freecycle Package: gst-plugins-bad0.10 Package: ihu Package: ocaml-soundtouch Package: rezound Package: yatm In addition: - liquidsoap just needs to be rebuilt whenever ocaml-soundtouch get updated since it depends on libsoundtouch-ocaml-dev and not libsoundtouch directly. - mixx just needs to be rebuilt since it depends on libsoundtouch-dev so it should be fine after a binary upload or something. I basically got this information by adding sid/experimental source repos to the source.list and doing: grep-dctrl -FBuild-Depends libsoundtouch -sPackage /var/lib/apt/lists/*Sources | sort | uniq and confirming with apt-cache rdepends (not sure if there was a better way or if doing it with these 2 commands is not exhaustive enough) I locally recompiled all the packages in a clean chroot when I made the initial rename and what I just posted are my notes from that time. Also, from what I wrote down, all packages except ocaml-soundtouch and liquidsoap worked with just renaming the build dependency but as luck would have it ardour is the only package that I forgot to document the changes I made to it so it would build. Finally I remember Alessio uploading a new version of audacity and freecycle to experimental using the renamed library so the transition on those 2 I assume is done or started. Hope I made some sense. Cheers, Miguel ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
NICE TO MEET YOU
Nice to meet you, My name is Miss Rejoice,i saw your profile today and became interested in you,i will also like to know you more,and i want you to send an email to my email address so i can give you my picture for you to know whom i am.Here is my email address believe we can move from here.I am waiting for your mail to my email address above.Miss Rejoice(Remember the distance or color does not matter but love matters a lot in life. My regards Miss Rejoice. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#599329: vainfo segfaults
On Wed, Feb 02, 2011 at 22:02:19 (CET), Andrey Rahmatullin wrote: On Wed, Oct 06, 2010 at 11:05:33PM +0600, Andrey Rahmatullin wrote: $ vainfo libva: libva version 0.31.1 Xlib: extension XFree86-DRI missing on display :0.0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/dri/nvidia_drv_video.so zsh: segmentation fault vainfo If I downgrade only libva11, vainfo still segfaults. If I downgrade only libva-x11-1, vainfo can't load nvidia_drv_video.so. If I downgrade both libva1 and libva-x11-1, vainfo works. I have an nVidia card with nvidia-glx, nvidia- vdpau-driver etc. from experimental. I've upgraded from 1.0.7 to 1.0.8 and the situation appeared again. vainfo and vlc with VAAPI enabled segfault with libva-x11-1 1.0.8 and work with 1.0.7. Can you please provide an (updated) backtrace, please? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#599329: vainfo segfaults
On Thu, Feb 03, 2011 at 06:43:20AM +0100, Reinhard Tartler wrote: $ vainfo libva: libva version 0.31.1 Xlib: extension XFree86-DRI missing on display :0.0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/dri/nvidia_drv_video.so zsh: segmentation fault vainfo If I downgrade only libva11, vainfo still segfaults. If I downgrade only libva-x11-1, vainfo can't load nvidia_drv_video.so. If I downgrade both libva1 and libva-x11-1, vainfo works. I have an nVidia card with nvidia-glx, nvidia- vdpau-driver etc. from experimental. I've upgraded from 1.0.7 to 1.0.8 and the situation appeared again. vainfo and vlc with VAAPI enabled segfault with libva-x11-1 1.0.8 and work with 1.0.7. Can you please provide an (updated) backtrace, please? #0 0x773440e0 in XDisplayString () from /usr/lib/libX11.so.6 #1 0x764b3e62 in ?? () from /usr/lib/dri/nvidia_drv_video.so #2 0x764b47c3 in __vaDriverInit_0_31 () from /usr/lib/dri/nvidia_drv_video.so #3 0x77bba242 in vaInitialize () from /usr/lib/libva.so.1 #4 0x00400a92 in ?? () #5 0x7766bc4d in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x7fffe6a8) at libc-start.c:228 #6 0x00400959 in ?? () #7 0x7fffe6a8 in ?? () #8 0x001c in ?? () #9 0x0001 in ?? () #10 0x7fffe9bf in ?? () #11 0x in ?? () -- WBR, wRAR signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#599329: vainfo segfaults
On Thu, Feb 03, 2011 at 07:51:14 (CET), Andrey Rahmatullin wrote: On Thu, Feb 03, 2011 at 06:43:20AM +0100, Reinhard Tartler wrote: $ vainfo libva: libva version 0.31.1 Xlib: extension XFree86-DRI missing on display :0.0. libva: va_getDriverName() returns 0 libva: Trying to open /usr/lib/dri/nvidia_drv_video.so zsh: segmentation fault vainfo If I downgrade only libva11, vainfo still segfaults. If I downgrade only libva-x11-1, vainfo can't load nvidia_drv_video.so. If I downgrade both libva1 and libva-x11-1, vainfo works. I have an nVidia card with nvidia-glx, nvidia- vdpau-driver etc. from experimental. I've upgraded from 1.0.7 to 1.0.8 and the situation appeared again. vainfo and vlc with VAAPI enabled segfault with libva-x11-1 1.0.8 and work with 1.0.7. Can you please provide an (updated) backtrace, please? #0 0x773440e0 in XDisplayString () from /usr/lib/libX11.so.6 #1 0x764b3e62 in ?? () from /usr/lib/dri/nvidia_drv_video.so #2 0x764b47c3 in __vaDriverInit_0_31 () from /usr/lib/dri/nvidia_drv_video.so #3 0x77bba242 in vaInitialize () from /usr/lib/libva.so.1 #4 0x00400a92 in ?? () #5 0x7766bc4d in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x7fffe6a8) at libc-start.c:228 #6 0x00400959 in ?? () #7 0x7fffe6a8 in ?? () #8 0x001c in ?? () #9 0x0001 in ?? () #10 0x7fffe9bf in ?? () #11 0x in ?? () Unfortunaltly, this backtrace is not helpful. Could you please retry with debug symbol so that we can see what's actually going wrong? The only thing that I can see is that nvidia_drv_video.so is involved. Doesn't VDPAU work for you? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
