Bug#659442: [blender] OceanSim not compiled in

Package: blender Version: 2.61-2 Severity: wishlist --- Please enter the report below this line. --- When applying the OceanSim modifier it reports that it hasn't been compiled in. Could you please enable this feature? Thanks, vitaminx --- System information. --- Architecture: i386 Kernel: L

Processed: Re: Bug#658791: gnome-mplayer doesn't support gvfs

Processing commands for cont...@bugs.debian.org: > tags 658791 + fixed-upstream Bug #658791 [gnome-mplayer] gnome-mplayer doesn't support gvfs Added tag(s) fixed-upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 658791: http://bugs.debian.org/cgi-bin/bugre

Bug#658791: gnome-mplayer doesn't support gvfs

tags 658791 + fixed-upstream thanks Fixed in upstream's svn repository as of revision 2212 [1]. Kind regards [1] https://code.google.com/p/gnome-mplayer/source/detail?r=2212 -- Sebastian Ramacher signature.asc Description: OpenPGP digital signature ___

zita-lrx_0.1.0-1_amd64.changes ACCEPTED into unstable

Accepted: zita-lrx_0.1.0-1.debian.tar.gz to main/z/zita-lrx/zita-lrx_0.1.0-1.debian.tar.gz zita-lrx_0.1.0-1.dsc to main/z/zita-lrx/zita-lrx_0.1.0-1.dsc zita-lrx_0.1.0-1_amd64.deb to main/z/zita-lrx/zita-lrx_0.1.0-1_amd64.deb zita-lrx_0.1.0.orig.tar.bz2 to main/z/zita-lrx/zita-lrx_0.1.0.o

Re: gpac_0.4.5+svn3450~dfsg3-1_amd64.changes ACCEPTED into unstable

On Fri, Feb 10, 2012 at 6:17 PM, Debian FTP Masters wrote: > Accepted: > gpac_0.4.5+svn3450~dfsg3-1.debian.tar.gz >  to main/g/gpac/gpac_0.4.5+svn3450~dfsg3-1.debian.tar.gz > gpac_0.4.5+svn3450~dfsg3-1.dsc >  to main/g/gpac/gpac_0.4.5+svn3450~dfsg3-1.dsc > gpac_0.4.5+svn3450~dfsg3-1_amd64.deb >  t

qmidiarp 0.4.5-1 MIGRATED to testing

FYI: The status of the qmidiarp source package in Debian's testing distribution has changed. Previous version: 0.4.2-1 Current version: 0.4.5-1 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receiv

Bug#636350: marked as done (ITP: gpac -- multimedia framework for research and academic purposes)

Your message dated Fri, 10 Feb 2012 17:17:21 + with message-id and subject line Bug#636350: fixed in gpac 0.4.5+svn3450~dfsg3-1 has caused the Debian Bug report #636350, regarding ITP: gpac -- multimedia framework for research and academic purposes to be marked as done. This means that you cl

gpac_0.4.5+svn3450~dfsg3-1_amd64.changes ACCEPTED into unstable

Accepted: gpac_0.4.5+svn3450~dfsg3-1.debian.tar.gz to main/g/gpac/gpac_0.4.5+svn3450~dfsg3-1.debian.tar.gz gpac_0.4.5+svn3450~dfsg3-1.dsc to main/g/gpac/gpac_0.4.5+svn3450~dfsg3-1.dsc gpac_0.4.5+svn3450~dfsg3-1_amd64.deb to main/g/gpac/gpac_0.4.5+svn3450~dfsg3-1_amd64.deb gpac_0.4.5+svn345

Bug#654648: marked as done (ITA: libavc1394 -- control IEEE 1394 audio/video devices)

Your message dated Fri, 10 Feb 2012 17:05:14 + with message-id and subject line Bug#654648: fixed in libavc1394 0.5.4-1 has caused the Debian Bug report #654648, regarding ITA: libavc1394 -- control IEEE 1394 audio/video devices to be marked as done. This means that you claim that the problem

libavc1394 override disparity

There are disparities between your recently accepted upload and the override file for the following file(s): libavc1394-0_0.5.4-1_amd64.deb: package says priority is optional, override says extra. libavc1394-dev_0.5.4-1_amd64.deb: package says priority is optional, override says extra. Please

libavc1394_0.5.4-1_amd64.changes ACCEPTED into unstable

Accepted: libavc1394-0_0.5.4-1_amd64.deb to main/liba/libavc1394/libavc1394-0_0.5.4-1_amd64.deb libavc1394-dev_0.5.4-1_amd64.deb to main/liba/libavc1394/libavc1394-dev_0.5.4-1_amd64.deb libavc1394-tools_0.5.4-1_amd64.deb to main/liba/libavc1394/libavc1394-tools_0.5.4-1_amd64.deb libavc1394

gmerlin override disparity

There are disparities between your recently accepted upload and the override file for the following file(s): gmerlin-data_1.0.0~dfsg-12_all.deb: package says priority is optional, override says extra. gmerlin-doc_1.0.0~dfsg-12_all.deb: package says priority is optional, override says extra. gmer

gmerlin_1.0.0~dfsg-12_amd64.changes ACCEPTED into unstable

Accepted: gmerlin-data_1.0.0~dfsg-12_all.deb to main/g/gmerlin/gmerlin-data_1.0.0~dfsg-12_all.deb gmerlin-dbg_1.0.0~dfsg-12_amd64.deb to main/g/gmerlin/gmerlin-dbg_1.0.0~dfsg-12_amd64.deb gmerlin-doc_1.0.0~dfsg-12_all.deb to main/g/gmerlin/gmerlin-doc_1.0.0~dfsg-12_all.deb gmerlin-plugins-

gmerlin_1.0.0~dfsg-12_amd64.changes is NEW

gmerlin-data_1.0.0~dfsg-12_all.deb to main/g/gmerlin/gmerlin-data_1.0.0~dfsg-12_all.deb gmerlin-dbg_1.0.0~dfsg-12_amd64.deb to main/g/gmerlin/gmerlin-dbg_1.0.0~dfsg-12_amd64.deb gmerlin-doc_1.0.0~dfsg-12_all.deb to main/g/gmerlin/gmerlin-doc_1.0.0~dfsg-12_all.deb (new) gmerlin-plugins-base_1.

Processing of gmerlin_1.0.0~dfsg-12_amd64.changes

gmerlin_1.0.0~dfsg-12_amd64.changes uploaded successfully to localhost along with the files: gmerlin_1.0.0~dfsg-12.dsc gmerlin_1.0.0~dfsg-12.debian.tar.gz gmerlin-doc_1.0.0~dfsg-12_all.deb gmerlin-data_1.0.0~dfsg-12_all.deb libgmerlin-doc_1.0.0~dfsg-12_all.deb gmerlin_1.0.0~dfsg-12_amd6

Bug#659336: ecasound dpkg-buildpackage fails due to some python-ecasound things

Le 10/02/2012 12:48, Alessandro Ghedini a écrit : On Fri, Feb 10, 2012 at 11:58:58AM +0100, Aurélien - Chargé de Porn AMMD wrote: Le 10/02/2012 11:39, Alessandro Ghedini a écrit : On Fri, Feb 10, 2012 at 11:00:21AM +0100, Aurélien - Chargé de Porn AMMD wrote: Hi guys, Hi, please do not emai

Re: d-m.o dependency tree

Am 09.02.2012 16:49, schrieb Sebastian Dröge: Not obsoleted (yet). faac supports 1-6 channels and the main, lc, ssr and ltp profiles. vo-aacenc only supports 1-2 channels and the lc profile. OK, so it's good enough for the usual CD ripping. The current gnome-media-profiles still uses the faac

Processed: tagging 659336

Processing commands for cont...@bugs.debian.org: > tags 659336 + moreinfo unreproducible Bug #659336 [ecasound] ecasound: build fails due to some missing files in debian/python-ecasound/ Added tag(s) unreproducible and moreinfo. > thanks Stopping processing here. Please contact me if you need as

Bug#659336: ecasound dpkg-buildpackage fails due to some python-ecasound things

On Fri, Feb 10, 2012 at 11:58:58AM +0100, Aurélien - Chargé de Porn AMMD wrote: > Le 10/02/2012 11:39, Alessandro Ghedini a écrit : > >On Fri, Feb 10, 2012 at 11:00:21AM +0100, Aurélien - Chargé de Porn AMMD > >wrote: > >>Hi guys, > > > >Hi, > > > >please do not email us directly. If you have any

Processed: Re: Bug#658791: gnome-mplayer doesn't support gvfs

Processing commands for cont...@bugs.debian.org: > tags 658791 - moreinfo + confirmed Bug #658791 [gnome-mplayer] gnome-mplayer doesn't support gvfs Removed tag(s) moreinfo. Bug #658791 [gnome-mplayer] gnome-mplayer doesn't support gvfs Added tag(s) confirmed. > thanks Stopping processing here. P

Bug#658791: gnome-mplayer doesn't support gvfs

tags 658791 - moreinfo + confirmed thanks On 02/08/2012 01:38 PM, Patrik Dufresne wrote: > I have the same problem after upgrading gnome-mplayer to 1.0.5-1 by using > the package available in sid unstable. Thanks for checking. I am also able to reproduce it now. Kind regards _

Bug#659336: ecasound: build fails due to some missing files in debian/python-ecasound/

Package: ecasound Version: 2.8.1-5+b1 Severity: normal Dear Maintainer, When trying to build an ecasound debian package from source, it fails due to some missing files in debian/python-ecasound, which is actually empty. When looking at the dependencies, in SID, it seems like python-ecasound depe

Bug#659165: marked as done (libbluray-dev: please review need for -dev package to depend on libbluray-bdj)

Your message dated Fri, 10 Feb 2012 09:17:25 + with message-id and subject line Bug#659165: fixed in libbluray 1:0.2.1+git20111208.63e308d-2 has caused the Debian Bug report #659165, regarding libbluray-dev: please review need for -dev package to depend on libbluray-bdj to be marked as done.

libbluray_0.2.1+git20111208.63e308d-2_amd64.changes ACCEPTED into unstable

Accepted: libbluray-bdj_0.2.1+git20111208.63e308d-2_all.deb to main/libb/libbluray/libbluray-bdj_0.2.1+git20111208.63e308d-2_all.deb libbluray-dev_0.2.1+git20111208.63e308d-2_amd64.deb to main/libb/libbluray/libbluray-dev_0.2.1+git20111208.63e308d-2_amd64.deb libbluray-doc_0.2.1+git20111208.

Re: d-m.o dependency tree

On 12-02-10 at 09:59am, Fabian Greffrath wrote: > Am 10.02.2012 09:49, schrieb Alessio Treglia: > >And regarding MPL-1.1, it says [2]: "This is a free software license > >which is not a strong copyleft; unlike the X11 license, it has some > >complex restrictions that make it incompatible with the G

Processing of libbluray_0.2.1+git20111208.63e308d-2_amd64.changes

libbluray_0.2.1+git20111208.63e308d-2_amd64.changes uploaded successfully to localhost along with the files: libbluray_0.2.1+git20111208.63e308d-2.dsc libbluray_0.2.1+git20111208.63e308d-2.debian.tar.gz libbluray-dev_0.2.1+git20111208.63e308d-2_amd64.deb libbluray1_0.2.1+git20111208.63e308

Re: d-m.o dependency tree

Am 10.02.2012 09:49, schrieb Alessio Treglia: And regarding MPL-1.1, it says [2]: "This is a free software license which is not a strong copyleft; unlike the X11 license, it has some complex restrictions that make it incompatible with the GNU GPL. That is, a module covered by the GPL and a module

Re: d-m.o dependency tree

On Fri, Feb 10, 2012 at 9:19 AM, Fabian Greffrath wrote: > For the initial upload to Debian we could simply configure --without-mp4v2. > BTW, the library is not affected, only the CLI frontend. I assume it will be > OK to ship both sources in the same tarball as long as they are not linked > toget

Re: d-m.o dependency tree

On 12-02-10 at 09:19am, Fabian Greffrath wrote: > Am 09.02.2012 17:34, schrieb Alessio Treglia: > >Do you mean FAAC links against libmp4v2? If so, we could try to make > >it rely on a dlopen() based mechanism. > > For the initial upload to Debian we could simply configure > --without-mp4v2. BTW, t

Re: d-m.o dependency tree

Am 09.02.2012 17:34, schrieb Alessio Treglia: Do you mean FAAC links against libmp4v2? If so, we could try to make it rely on a dlopen() based mechanism. For the initial upload to Debian we could simply configure --without-mp4v2. BTW, the library is not affected, only the CLI frontend. I assu

Re: d-m.o dependency tree

Am 09.02.2012 18:37, schrieb Reinhard Tartler: Aah, I didn't get this point yesterday on the phone. Right, so porting the faac frontend to libavformat would allow us to drop the internal libmp4v2 copy. Good idea. Yes, but it would still remain non-free because of the reference implementation u