Bug#706866: transition: libarchive

[Andres Mejia]

On Tue, May 21, 2013 at 11:13 AM, Julien Cristau  wrote:
> Control: tags -1 confirmed
>
> On Sun, May  5, 2013 at 11:49:54 -0400, Andres Mejia wrote:
>
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> I am requesting a transition from libarchive12 to libarchive13. libarchive13
>> is from the latest release of libarchive (3.1.2). A soname bump was done
>> upstream due to some ABI changes, specifically with HFS support.
>>
> Go ahead.  Please let us know once it's installed on all archs.
>
> Cheers,
> Julien

I see the packages were built on the last two archs after retrying.
The packages have been built on all archs now.

--
~ Andres


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#706866: Fwd: Bug#706866: transition: libarchive

[Andres Mejia]

Hi,
I see there's a tracker setup
http://release.debian.org/transitions/html/libarchive13.html

Now am I suppose to upload now, or is someone going to tell me when to upload?


-- Forwarded message --
From: Andres Mejia 
Date: Sun, May 5, 2013 at 11:49 AM
Subject: Bug#706866: transition: libarchive
To: Debian Bug Tracking System 


Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I am requesting a transition from libarchive12 to libarchive13. libarchive13
is from the latest release of libarchive (3.1.2). A soname bump was done
upstream due to some ABI changes, specifically with HFS support.

Packages that need to be updated are
  tuxcmd-modules
  libtotem-plparser17
  reprepro
  rdup
  libpackagekit-glib2-14
  listaller-devtools
  listaller
  liblistaller-glib0
  libgxps2
  libgxps-utils
  libapache2-mod-musicindex
  hydrogen
  gvfs-backends
  libevdocument3-4
  deb-gview
  cmake-qt-gui
  cmake-curses-gui
  cmake
  claws-mail-archiver-plugin
  ark
  archivemount
  libtotem-plparser-dev
  libgxps-dev


Ben file:

title = "libarchive";
is_affected = .depends ~ "libarchive12" | .depends ~ "libarchive13";
is_good = .depends ~ "libarchive13";
is_bad = .depends ~ "libarchive12";


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


--
~ Andres


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#706866: transition: libarchive

[Andres Mejia]

Oops, meant to reply all.
On May 6, 2013 8:17 PM, "Andres Mejia"  wrote:

> Yes, I plan on disabling lrzip support for now.
> On May 6, 2013 7:55 PM, "peter green"  wrote:
>
>>
>>> I am requesting a transition from libarchive12 to libarchive13.
>>> libarchive13
>>> is from the latest release of libarchive (3.1.2). A soname bump was done
>>> upstream due to some ABI changes, specifically with HFS support.
>>>
>>>
>> I notice the most recent experimental upload FTBFS on many architectures
>> with testsuite failures. Have you investigated how serious those failures
>> are? Do you have plans for fixing them before uploading to sid?
>>
>

Bug#706866: transition: libarchive

[Andres Mejia]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I am requesting a transition from libarchive12 to libarchive13. libarchive13
is from the latest release of libarchive (3.1.2). A soname bump was done
upstream due to some ABI changes, specifically with HFS support.

Packages that need to be updated are
  tuxcmd-modules
  libtotem-plparser17
  reprepro
  rdup
  libpackagekit-glib2-14
  listaller-devtools
  listaller
  liblistaller-glib0
  libgxps2
  libgxps-utils
  libapache2-mod-musicindex
  hydrogen
  gvfs-backends
  libevdocument3-4
  deb-gview
  cmake-qt-gui
  cmake-curses-gui
  cmake
  claws-mail-archiver-plugin
  ark
  archivemount
  libtotem-plparser-dev
  libgxps-dev


Ben file:

title = "libarchive";
is_affected = .depends ~ "libarchive12" | .depends ~ "libarchive13";
is_good = .depends ~ "libarchive13";
is_bad = .depends ~ "libarchive12";


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#703814: libsbuild-perl: Add Suggests of libwww-perl

[Andres Mejia]

Package: libsbuild-perl
Version: 0.63.2-1.1
Severity: minor

The Sbuild::Utility module can optionally make use of LWP::UserAgent to
download source packages remotely. This is used for packages which are not
yet in the archive, such as those found in mentors.debian.net. Please add a
Suggests for libwww-perl so that users know what package to install so that
they may use this feature.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libsbuild-perl depends on:
ii  adduser3.113+nmu3
ii  apt0.9.7.8
ii  apt-utils  0.9.7.8
ii  dctrl-tools2.22.2
ii  devscripts 2.12.6
ii  dpkg-dev   1.16.9
ii  exim4  4.80-7
ii  exim4-daemon-light [mail-transport-agent]  4.80-7
ii  libdpkg-perl   1.16.9
ii  libexception-class-perl1.32-1
ii  libfilesys-df-perl 0.92-4+b1
ii  libmime-lite-perl  3.028-1
ii  perl   5.14.2-20
ii  perl-modules [libio-zlib-perl] 5.14.2-20
ii  schroot1.6.4-4

libsbuild-perl recommends no packages.

libsbuild-perl suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#702372: Please build against gstreamer 1.0

[Andres Mejia]

You should send the patch to the mailing list instead.

On Sun, Mar 10, 2013 at 9:31 AM, Guido Günther  wrote:
> Hi Andres,
> On Sun, Mar 10, 2013 at 01:59:16AM -0500, Andres Mejia wrote:
>> On Wed, Mar 6, 2013 at 2:49 PM, Guido Günther  wrote:
>> > tag 702372 +patch
>> > thanks
>> >
>> > On Tue, Mar 05, 2013 at 08:38:22PM +0100, Guido Günther wrote:
>> >> Package: gstreamer0.10-crystalhd
>> >> Version: 1:0.0~git20110715.fdd2f19-9
>> >> Severity: wishlist
>> >> Tags: patch
>> >>
>> >> Hi,
>> >> I'd be great to have a version built against gstreamer 1.0 in
>> >> experimental since GNOME/totem uses gstreamer 1.0 there already. I've
>> >> added patches here:
>> >>
>> >>   https://github.com/agx/crystalhd
>> >>
>> >> Tested with totem and gst-launch it reduces CPU usage from 60% to <25%
>> >> when playing h264 video. It's a straight forward port of the gst0.10
>> >> version you were previously tracking.
>> > Attached patch updates the package.
>> >  -- Guido
>>
>> Hi, great work here. Have you tried submitting a patch to linuxtv.org
>> as well? I would like changes done to the upstream source be committed
>> upstream first.
> I mailed Jarod Wilson  but got no reply so far. What
> would be the right place, the linux-media list?
> Cheers,
>  -- Guido



--
~ Andres


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#702372: Please build against gstreamer 1.0

[Andres Mejia]

On Wed, Mar 6, 2013 at 2:49 PM, Guido Günther  wrote:
> tag 702372 +patch
> thanks
>
> On Tue, Mar 05, 2013 at 08:38:22PM +0100, Guido Günther wrote:
>> Package: gstreamer0.10-crystalhd
>> Version: 1:0.0~git20110715.fdd2f19-9
>> Severity: wishlist
>> Tags: patch
>>
>> Hi,
>> I'd be great to have a version built against gstreamer 1.0 in
>> experimental since GNOME/totem uses gstreamer 1.0 there already. I've
>> added patches here:
>>
>>   https://github.com/agx/crystalhd
>>
>> Tested with totem and gst-launch it reduces CPU usage from 60% to <25%
>> when playing h264 video. It's a straight forward port of the gst0.10
>> version you were previously tracking.
> Attached patch updates the package.
>  -- Guido

Hi, great work here. Have you tried submitting a patch to linuxtv.org
as well? I would like changes done to the upstream source be committed
upstream first.

--
~ Andres


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#690152: bsaf: FTBFS: Test org.jdesktop.application.TaskMonitorTest failed

[Andres Mejia]

On Sun, Mar 3, 2013 at 8:42 AM, gregor herrmann  wrote:
> On Sat, 02 Mar 2013 19:12:32 -0500, Andres Mejia wrote:
>
>> I just rebuilt bsaf on my machine that has the DISPLAY environment variable
>> set and
>
> In a chroot or in the "normal" environment?

The "normal" environment.

>> on a sid and wheezy chroot via sbuild-shell (which in turn uses
>> schroot) that does not have DISPLAY set. All builds succeeded and passed
>> the test suite.
>
> That's not surprising, since without DISPLAY the otherwise failing
> tests are skipped :)
>
> FWIW: The tests still fail for me in wheezy and sid cowbuilder amd64
> chroots, with DISPLAY set, with or without my earlier patch (to use
> xvfb).
>
> As mentioned earlier in this bug log by Matteo, building with
> openjdk-7-jdk works in the same setup.
>
> Cheers,
> gregor
>
> --
>  .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
>  : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
>  `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
>`-   NP: David Bowie: Suffragette City

At this time, being this late into the release cycle, I would like to
support only the default-jdk. I am building with sbuild using a chroot
created by sbuild-createchroot as I believe this closely matches what
the buildd machines are running. The bsaf package builds and passes
the test suite for me fine on my machine running Debian wheezy, inside
a wheezy chroot using sbuild, and inside a sid chroot using sbuild. My
machine has a display, the chroot environments do not have a display.

I will be downgrading this bug to important as I don't believe
supporting cowbuilder, xvfb, or openjdk-7-jdk to be release critical.
If someone else can reproduce the test case failure with the version
of bsaf in the archives as is, then feel free to raise it back,
otherwise fixing these other issues of supporting cowbuilder, xvfb,
and openjdk-7-jdk can wait.

-- 
~ Andres


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#702109: unblock: crystalhd/1:0.0~git20110715.fdd2f19-8

[Andres Mejia]

retitle 702109 unblock: crystalhd/1:0.0~git20110715.fdd2f19-9
stop

On Saturday, March 02, 2013 2:43:26 PM Adam D. Barratt wrote:
> As per our last d-d-a mail in January[1], release goal changes no longer
> qualify for unblocks.
> 
> Regards,
> 
> Adam
> 
> [1] http://lists.debian.org/debian-devel-announce/2013/01/msg5.html

Ok, please unblock crystalhd/1:0.0~git20110715.fdd2f19-9.

This will only have the removal of the dkms package to
address bugs 682252 and 699470. Note the bug 682252
was marked a normal bug, but both were actually the
same bug and both were release critical.

Here is the debdiff from the current package in testing
to the new package in unstable.

diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/changelog 
crystalhd-0.0~git20110715.fdd2f19/debian/changelog
--- crystalhd-0.0~git20110715.fdd2f19/debian/changelog  2013-03-02 
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/changelog  2013-03-02 
17:45:53.0 -0500
@@ -1,3 +1,23 @@
+crystalhd (1:0.0~git20110715.fdd2f19-9) unstable; urgency=high
+
+  * New package upload with just fixes to remove dkms package.
+  * Revert bump to Standards-Version 3.9.4.
+  * Revert build with hardening options to satisfy Wheezy release goal.
+
+ -- Andres Mejia   Sat, 02 Mar 2013 17:43:59 -0500
+
+crystalhd (1:0.0~git20110715.fdd2f19-8) unstable; urgency=high
+
+  * Remove dkms package which contained buggy driver.
+Driver already existed in mainline kernel. Any issues with the driver
+should be directed to the kernel package.
+(Closes: #682252)
+(Closes: #699470)
+  * Bump to Standards-Version 3.9.4.
+  * Build with hardening options to satisfy Wheezy release goal.
+
+ -- Andres Mejia   Sat, 02 Mar 2013 13:34:36 -0500
+
 crystalhd (1:0.0~git20110715.fdd2f19-7) unstable; urgency=low
 
   * Include udev rules for crystalhd-dkms.
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/control 
crystalhd-0.0~git20110715.fdd2f19/debian/control
--- crystalhd-0.0~git20110715.fdd2f19/debian/control2013-03-02 
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/control2013-03-02 
17:43:19.0 -0500
@@ -3,8 +3,7 @@
 Maintainer: Andres Mejia 
 Build-Depends: debhelper (>= 8.1.3~),
libgstreamer0.10-dev,
-   libgstreamer-plugins-base0.10-dev,
-   dkms
+   libgstreamer-plugins-base0.10-dev
 Standards-Version: 3.9.3
 Section: libs
 Homepage: http://www.broadcom.com/support/crystal_hd/
@@ -37,18 +36,6 @@
  .
  This package contains the shared library.
 
-Package: crystalhd-dkms
-Section: kernel
-Architecture: amd64 i386
-Depends: ${shlibs:Depends}, ${misc:Depends}, dkms
-Suggests: linux-headers
-Description: Crystal HD Video Decoder (Linux kernel driver)
- Crystal HD Solution is a product offered by Broadcom. It is used to enable
- flawless playback of 1080p high definition video across a wide range of
- systems.
- .
- This package contains the crystalhd Linux kernel driver.
-
 Package: gstreamer0.10-crystalhd
 Section: video
 Architecture: amd64 i386
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms 
crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-
dkms.dkms
--- crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms
2013-03-02 14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms
1969-12-31 19:00:00.0 -0500
@@ -1,11 +0,0 @@
-# DKMS configuration for crystalhd
-
-PACKAGE_NAME="crystalhd"
-PACKAGE_VERSION="#MODULE_VERSION#"
-BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
-BUILT_MODULE_LOCATION[0]=driver/linux
-DEST_MODULE_LOCATION[0]="/updates/dkms/"
-AUTOINSTALL=yes
-
-MAKE[0]="cd driver/linux && ./configure && make"
-CLEAN="make -C driver/linux clean distclean"
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install 
crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-
dkms.install
--- crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install 
2013-03-02 14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install 
1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-usr/src
-lib/udev/rules.d
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/rules 
crystalhd-0.0~git20110715.fdd2f19/debian/rules
--- crystalhd-0.0~git20110715.fdd2f19/debian/rules  2013-03-02 
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/rules  2013-03-02 
17:43:52.0 -0500
@@ -1,8 +1,5 @@
 #!/usr/bin/make -f
 
-UPSTREAM_VERSION = $(shell dpkg-parsechangelog | grep -G '^Version' | \
- cut -d ' ' -f 2 | sed 's/^[^:]:*//' | sed 's/-.*$$//')
-
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 EXTRA_INCLUDES = -I$(CURDIR)/include \
@@ -11,7 +8,7 @@
 EXTRA_LD_PATH = -L$(CURDIR)/linux_lib/libcrystalhd
 
 %:
-

Bug#570611: ITP: mythtv -- A personal video recorder application

[Andres Mejia]

On Friday, July 20, 2012, Wookey wrote:

> Hi, I've been using the deb-mulitmedia mythtv packages for many years
> (thanx for that work), and having just had to re-install stuff and
> noting the long existence of mythbuntu was wondering why there were
> still no packages in Debian. So I came to this bug.
>
> I'm happy to help out, and would also like to have it working on ARM
> hardware too - not sure what the status of that is upstream, but I see
> there are packgaes at deb-multimedia already for armel and armhf. I'd
> better get testing...
>
> So where are we at? Still waiting to sort out the internal library
> thing properly, even though the 1st message from two years ago claims
> a patch for that? Looks like the deb-m package uses the internal av* libs.
>
> Josh have you started the 'long conversation' with upstream yet?
>
> Is your packaging online somewhere? The verison at
> http://anonscm.debian.org/gitweb/?p=collab-maint/mythtv.git stops in
> March 2010
>
> Wookey
> --
> Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
> http://wookware.org/


Hi Wookey,
If you want to help with mythtv packaging, please start from the packaging
work done for Ubuntu at https://github.com/MythTV/packaging. The main
maintainer for the mythtv packages in Ubuntu is superm1.

Note that for Debian, the issue with using a fork of ffmpeg/libav will need
to be addressed. Last I checked, mythtv was still making changes to their
version of ffmpeg that were different from upstream ffmpeg/libav. There's
also the licensing issues from using openssl. With this, I believe you can
simply use the openssl wrapper provided by gnutls.

--
Andres


-- 
~ Andres

Bug#690152: bsaf: FTBFS: Test org.jdesktop.application.TaskMonitorTest failed

[Andres Mejia]

On Monday, January 7, 2013, Joost Yervante Damad wrote:

> On 01/07/2013 07:48 PM, gregor herrmann wrote:
>
>> On Sat, 15 Dec 2012 16:13:35 +0100, Joost Yervante Damad wrote:
>>
>>  I tried rebuilding the bsaf software in wheezy with default-jdk,
>>> which uses the openjdk from openjdk-6-jre-headless_6b24.
>>> It builds just fine.
>>> Is this really still an issue?
>>>
>>
>> It still fails to build for me in wheezy and sid chroots
>> - without my earlier patch because of
>>"Can't connect to X11 window server using ':0' as the value of the
>> DISPLAY variable."
>> - with the patch with the long java.beans stack trace
>>
>> I guess you had DISPLAY unset during the build and the problematic
>> tests were skipped?
>>
>
> Indeed, I did not have DISPLAY set. Unfortunately I forgot to keep a log
> of the build around.
>
> Joost
>
> __
> This is the maintainer address of Debian's Java team
>  pkg-java-maintainers>.
> Please use
> debian-j...@lists.debian.org for discussions and questions.
>

I just rebuilt bsaf on my machine that has the DISPLAY environment variable
set and on a sid and wheezy chroot via sbuild-shell (which in turn uses
schroot) that does not have DISPLAY set. All builds succeeded and passed
the test suite.

The chroot environment will not have DISPLAY set of course. In fact, there
should be a small number of environment variables set in an chroot
environment using schroot. My chroot environment has the following
variables set.

USER
HOME
XDG_SESSION_COOKIE
SCHROOT_CHROOT_NAME
SCHROOT_UID
LOGNAME
TERM
USERNAME
PATH
SCHROOT_COMMAND
SCHROOT_SESSION_ID
SCHROOT_ALIAS_NAME
SCHROOT_GROUP
SCHROOT_USER
SHELL
PWD
SCHROOT_GID

--
Andres


-- 
~ Andres

Bug#658335: [firmware-crystalhd] Firmware image signature failure

[Andres Mejia]

tags 658335 moreinfo
stop

Tim,
Are you still having an issue with the firmware for crystalhd? If so,
are you using the crystalhd-dkms package? Note that the crystalhd-dkms
package is being dropped at this time. It is recommended you use the
crystalhd driver found in the mainline Linux kernel.

On Sun, Mar 4, 2012 at 2:43 PM, Andres Mejia  wrote:
> Hi,
> I'm the maintainer of the crystalhd packages in Debian. There's a user
> that reported the below issue. Do you have any suggestions on what he
> may try?
>
> I'm not sure about any mismatch. The crystalhd library and firmware
> packages were built from the same git snapshot (repo:
> http://git.linuxtv.org/jarod/crystalhd.git, commit:
> fdd2f19ac739a3db1fd7469ea19ceaefe0822e5a).
>
> When you reply, please preserve the CC field.
>
>
> -- Forwarded message --
> From: Tim Sattarov 
> Date: Wed, Feb 1, 2012 at 10:22 PM
> Subject: Bug#658335: [firmware-crystalhd] Firmware image signature failure
> To: sub...@bugs.debian.org
>
>
> Package: firmware-crystalhd
> Version: 0.0~git20120110.fdd2f19-1
> Severity: grave
>
> --- Please enter the report below this line. ---
> Hello,
>
> I'm trying to use my Broadcom HW decoder bcm70015
>
> here is lspci output
> 04:00.0 Multimedia controller: Broadcom Corporation BCM70015 Video
> Decoder [Crystal HD]
>
> driver compiles but every time I start video application (xbmc or
> totem) I'm getting these messages in dmesg
>
> [ 5503.584187] Loading crystalhd v3.10.0
> [ 5503.584345] crystalhd :04:00.0: Starting Device:0x1615
> [ 5503.584430] crystalhd :04:00.0: PCI INT A -> GSI 19 (level,
> low) -> IRQ 19
> [ 5503.595602] crystalhd :04:00.0: irq 47 for MSI/MSI-X
> [ 5503.668241] crystalhd :04:00.0: setting latency timer to 64
> [ 5527.782089] crystalhd :04:00.0: Opening new user[0] handle
> [ 5527.852226] crystalhd :04:00.0: Closing user[0] handle with mode 
> 
> [ 5734.101508] crystalhd :04:00.0: Opening new user[0] handle
> [ 5734.172146] crystalhd :04:00.0: Closing user[0] handle with mode 
> 
> [ 5734.210614] crystalhd :04:00.0: Opening new user[0] handle
> [ 5734.280237] crystalhd :04:00.0: Closing user[0] handle with mode 
> 
> [ 5734.317633] crystalhd :04:00.0: Opening new user[0] handle
> [ 5734.668199] crystalhd :04:00.0: [crystalhd_flea_download_fw]:
> step 7. Error bit occured. RetVal:c00018
> [ 5734.668226] crystalhd :04:00.0: [crystalhd_flea_download_fw]:
> step 7. Firmware image signature failure.
> [ 5734.668242] crystalhd :04:00.0: Firmware Download Failure!! - -1
> [ 5734.784736] crystalhd :04:00.0: Closing user[0] handle via
> ioctl with mode 1c200
>
> and crystalhd is not used at all.
> Google says - firmware version does not match driver version.
> Any ideas how to make it work ?
>
> Thanks
> Tim
>
> --- System information. ---
> Architecture: i386
> Kernel: Linux 3.2.0-1-686-pae
>
> Debian Release: wheezy/sid
> 500 unstable www.debian-multimedia.org
> 500 unstable http.us.debian.org
> 1 experimental http.us.debian.org
>
> --- Package information. ---
> Package's Depends field is empty.
>
> Package's Recommends field is empty.
>
> Suggests (Version) | Installed
> ==-+-===
> initramfs-tools | 0.99
> linux-image |
>
>
>
>
> --
> ~ Andres



--
~ Andres


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#702109: unblock: crystalhd/1:0.0~git20110715.fdd2f19-8

[Andres Mejia]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package crystalhd

This new package release fixes two release critical bugs related to the
buggy driver that was distributed through a dkms package. Users of the driver
should instead use the crystalhd driver already provided in the mainline
kernel. This package also enables the hardening options which is a release
goal. This was missed in the last upload.

Finally, I did end up bumping the Standards-Version from 3.9.3 to 3.9.4.
I can place it back to 3.9.3, though there was no changes needed when
bumping the Standards-Version to 3.9.4.

Below is the debdiff.

diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/changelog 
crystalhd-0.0~git20110715.fdd2f19/debian/changelog
--- crystalhd-0.0~git20110715.fdd2f19/debian/changelog  2013-03-02 
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/changelog  2013-03-02 
13:34:42.0 -0500
@@ -1,3 +1,15 @@
+crystalhd (1:0.0~git20110715.fdd2f19-8) unstable; urgency=high
+
+  * Remove dkms package which contained buggy driver.
+Driver already existed in mainline kernel. Any issues with the driver
+should be directed to the kernel package.
+(Closes: #682252)
+(Closes: #699470)
+  * Bump to Standards-Version 3.9.4.
+  * Build with hardening options to satisfy Wheezy release goal.
+
+ -- Andres Mejia   Sat, 02 Mar 2013 13:34:36 -0500
+
 crystalhd (1:0.0~git20110715.fdd2f19-7) unstable; urgency=low

   * Include udev rules for crystalhd-dkms.
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/control 
crystalhd-0.0~git20110715.fdd2f19/debian/control
--- crystalhd-0.0~git20110715.fdd2f19/debian/control  2013-03-02 
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/control  2013-03-02 
13:01:17.0 -0500
@@ -3,9 +3,8 @@
 Maintainer: Andres Mejia 
 Build-Depends: debhelper (>= 8.1.3~),
libgstreamer0.10-dev,
-   libgstreamer-plugins-base0.10-dev,
-   dkms
-Standards-Version: 3.9.3
+   libgstreamer-plugins-base0.10-dev
+Standards-Version: 3.9.4
 Section: libs
 Homepage: http://www.broadcom.com/support/crystal_hd/
 Vcs-Git: git://git.debian.org/git/collab-maint/crystalhd.git
@@ -37,18 +36,6 @@
  .
  This package contains the shared library.

-Package: crystalhd-dkms
-Section: kernel
-Architecture: amd64 i386
-Depends: ${shlibs:Depends}, ${misc:Depends}, dkms
-Suggests: linux-headers
-Description: Crystal HD Video Decoder (Linux kernel driver)
- Crystal HD Solution is a product offered by Broadcom. It is used to enable
- flawless playback of 1080p high definition video across a wide range of
- systems.
- .
- This package contains the crystalhd Linux kernel driver.
-
 Package: gstreamer0.10-crystalhd
 Section: video
 Architecture: amd64 i386
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms 
crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms
--- crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms  2013-03-02 
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.dkms  1969-12-31 
19:00:00.0 -0500
@@ -1,11 +0,0 @@
-# DKMS configuration for crystalhd
-
-PACKAGE_NAME="crystalhd"
-PACKAGE_VERSION="#MODULE_VERSION#"
-BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
-BUILT_MODULE_LOCATION[0]=driver/linux
-DEST_MODULE_LOCATION[0]="/updates/dkms/"
-AUTOINSTALL=yes
-
-MAKE[0]="cd driver/linux && ./configure && make"
-CLEAN="make -C driver/linux clean distclean"
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install 
crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install
--- crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install 2013-03-02 
14:23:07.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/crystalhd-dkms.install 1969-12-31 
19:00:00.0 -0500
@@ -1,2 +0,0 @@
-usr/src
-lib/udev/rules.d
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/patches/hardening-opts.patch 
crystalhd-0.0~git20110715.fdd2f19/debian/patches/hardening-opts.patch
--- crystalhd-0.0~git20110715.fdd2f19/debian/patches/hardening-opts.patch 
1969-12-31 19:00:00.0 -0500
+++ crystalhd-0.0~git20110715.fdd2f19/debian/patches/hardening-opts.patch 
2013-03-02 13:21:28.0 -0500
@@ -0,0 +1,16 @@
+Description: Allow extra compiler and linker flags to be passed into build
+ system.
+Author: Andres Mejia 
+
+--- a/linux_lib/libcrystalhd/Makefile
 b/linux_lib/libcrystalhd/Makefile
+@@ -30,6 +30,9 @@
+ CPPFLAGS += $(MACHINE_OPTS)
+ LDFLAGS = -Wl,-soname,${BCLIB_SL} -pthread
+
++CPPFLAGS += $(EXTRA_CPPFLAGS) $(EXTRA_CXXFLAGS)
++LDFLAGS += $(EXTRA_LDFLAGS)
++
+ SRCFILES =  libcrystalhd_if.cpp \
+ libcrystalhd_int_if.cpp \
+ libcrystalhd_fwcmds.cpp \
diff -Nru crystalhd-0.0~git20110715.fdd2f19/debian/patches/series 
crystalhd-0.0~git20110715.fdd2f19/debian/patches/serie

Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()

[Andres Mejia]

On Fri, Mar 1, 2013 at 3:55 PM, Julien Cristau  wrote:
> On Fri, Mar  1, 2013 at 21:38:54 +0100, thomas schorpp wrote:
>
>> So no technical reasons to drop the package?
>>
> Until and unless the driver is in mainline, there's every reason to drop
> it.
>
> Cheers,
> Julien

I just checked the crystalhd driver in the mainline kernel. The driver
seems to be much better maintained over there than at linuxtv.org. See
[1].

I'm going to drop the driver from linuxtv.org. If after I drop the
package someone has some compelling reason to use the driver from
linuxtv.org, they can submit another bug to the crystalhd package and
explain why the linuxtv.org driver should be used.

1. 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/staging/crystalhd

--
~ Andres


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#699470: crystalhd-dkms: Kernel null pointer BUG in crystalhd_dioq_fetch_wait()

[Andres Mejia]

It looks like the crystalhd drivers are buggy with newer kernel
releases. I opt for removing the dkms package. I will do this over the
weekend.

On Thu, Feb 28, 2013 at 4:52 PM, thomas schorpp
 wrote:
> On 28.02.2013 20:41, Julien Cristau wrote:
>>
>> On Thu, Jan 31, 2013 at 19:25:50 +0100, tom schorpp wrote:
>>
>>> Package: crystalhd-dkms
>>> Version: 1:0.0~git20110715.fdd2f19-7
>>> Severity: critical
>>> Tags: patch
>>> Justification: breaks the whole system
>>>
>>> Reproducible NULL pointer BUG at
>>> crystalhd-0.0~git20110715.fdd2f19/driver/linux/crystalhd_misc.c:515,
>>> triggered by adobe flash plugin from dmo repo, ffmpeg, mplayer, bino or
>>> other, mostly on heavy ioq usage
>>> or after FETCH_TIMEOUT and/or unclosed driver HANDLEs.
>>>
>> Does the maintainer or somebody on pkg-multimedia plan on fixing this RC
>> bug?  If not I'll consider a NMU removing the dkms package from
>> crystalhd source.
>>
>> Cheers,
>> Julien
>>
>
> Known linux-media Maintainers
>
> STAGING - CRYSTAL HD VIDEO DECODER
> M:Naren Sankar 
> M:Jarod Wilson 
> M:Scott Davilla 
> M:Manu Abraham 
>
> seem to have left the Broadcom's legacy driver code, focusing on the new
> linux-media staging driver, but limited time,
> one stated lately on the linux-media/LKML, nothing read from the others.
> I could adapt it to new kernel releases the next 2-3 years, but nothing
> more, not a experienced kernel driver coder,
> no debian package/policy maintaining motivation because I do not use dkms or
> debian kernels packages.
>
> If my last patch applies to Your codebase in the debian git repository (mine
> is from git.linuxtv.org, according to the
> git changelog more advanced in the gstreamer plugin, merge?) You may
> consider it
>
> "hotfixed"
>
> and release with known multithreading (gstreamer based transcoders/matroska
> demuxers) and PM ACPI S3 issues?
> Has not crashed here any more, nor notable side effects with usual playback
> use cases, including Totem (gstreamer).
>
> y
> tom
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers



--
~ Andres


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#681840: liblzo2-dev: multirch dev package

[Andres Mejia]

Hi,
You asked over the summer if this was necessary for wheezy. The answer
is yes, this is one of Debian wheezy's release goals. [1].

1. http://release.debian.org/wheezy/goals.txt

--
~ Andres


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#701782: java-package: Add java-6-sun -> j2sdk1.6-oracle symlink for Java 1.6 packages

[Andres Mejia]

Package: java-package
Version: 0.50+nmu2
Severity: normal

Building Android requires either JDK 6 for Gingerbread or newer, and JDK 5
for Froyo or older. For JDK 6, the java package is expected to be found under
/usr/lib/jvm/java-6-sun. Adding a symlink from
/usr/lib/jvm/java-6-sun -> /usr/lib/jvm/j2sdk1.6-oracle will allow Android
to be built for Gingerbread and newer. Please provide this symlink.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages java-package depends on:
ii  debhelper   9.20120909
ii  fakeroot1.18.4-2
ii  libasound2  1.0.25-4
ii  libx11-62:1.5.0-1
ii  unzip   6.0-8

Versions of packages java-package recommends:
ii  dpkg-dev  1.16.9
ii  gcc   4:4.7.2-1

Versions of packages java-package suggests:
ii  openjdk-6-jre  6b24-1.11.5-1
pn  openjdk-7-jre  

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#700679: ITP: maven-native -- Maven plugin to compile C/C++ source code

[Andres Mejia]

Nothing. It's part of the build dependencies for BridJ which I would
like to get compiling on the buildd network because of the C code it
uses.

On Fri, Feb 15, 2013 at 10:38 PM, Istimsak Abdulbasir
 wrote:
>
> What is the problem with the Maven plugin?
>
>
> On Fri, Feb 15, 2013 at 8:54 PM, Andres Mejia  wrote:
>>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Andres Mejia 
>>
>> * Package name: maven-native
>>   Version : 1.0~alpha-7
>>   Upstream Author : Dan T. Tran 
>> * URL :
>> http://mojo.codehaus.org/maven-native/native-maven-plugin/
>> * License : MIT
>>   Programming Lang: Java
>>   Description : Maven plugin to compile C/C++ source code
>>
>> The Native Maven Plugin is a plugin to compile C and C++ source code under
>> Maven using native compilers such as gcc, msvc, gcj, etc.
>>
>>
>> --
>> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
>> with a subject of "unsubscribe". Trouble? Contact
>> listmas...@lists.debian.org
>> Archive:
>> http://lists.debian.org/20130216015459.5.16678.report...@andres-laptop.home
>>
>



--
~ Andres


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#700679: ITP: maven-native -- Maven plugin to compile C/C++ source code

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: Andres Mejia 

* Package name: maven-native
  Version : 1.0~alpha-7
  Upstream Author : Dan T. Tran 
* URL : http://mojo.codehaus.org/maven-native/native-maven-plugin/
* License : MIT
  Programming Lang: Java
  Description : Maven plugin to compile C/C++ source code

The Native Maven Plugin is a plugin to compile C and C++ source code under
Maven using native compilers such as gcc, msvc, gcj, etc.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#663020: Intend to Package BridJ and friends

[Andres Mejia]

retitle 663020 ITP: jnaerator -- parses C/C++/Obj-C headers and
generates BridJ/JNA/Rococoa Java interfaces
owner 663020 !
retitle 663021 ITP: bridj -- Java / native interoperability library
owner 663021 !
thanks

I have a need for this now. Since it looks like no one will take up
packaging this, I'll look into packaging this myself.

--
~ Andres


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#697157: cryptsetup: Install script to prompt for passphrases in ssh sessions

[Andres Mejia]

Package: cryptsetup
Version: 2:1.4.3-4
Severity: wishlist
Tags: patch

It would be better if instead of saving passphrases in scripts or passing them
on the command line, use /lib/cryptsetup/askpass instead to prompt for the
passphrases. I'm attaching a custom hook to install a script at
/root/enter-passphrase that will run /scripts/local-top/cryptroot, which I've
modified to pass the passphrases into /lib/cryptsetup/passfifo. The custom
hook should probably be included in README-remote or somewhere in the docs for
cryptsetup.

-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/andres--desktop-root ro quiet

-- /etc/crypttab
sda2_crypt UUID=522e25f9-7e66-49fd-83c9-3bf168b5ddfd none luks
sdb1_crypt UUID=2e1f3d5f-fcc7-4ed9-9b02-f1672cb6206b /var/local/luks/random_key 
luks
sdc1_crypt UUID=8657c2e9-1d7b-4229-86db-408874c7c944 /var/local/luks/random_key 
luks

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/andres--desktop-root /   ext4errors=remount-ro 0
   1
# /boot was on /dev/sda1 during installation
UUID=f4472afd-877c-47a9-979f-13ad302042bc /boot   ext4defaults  
  0   2
/dev/mapper/andres--desktop--2-drive2 /media/drive2   ext4defaults0 
  2
/dev/mapper/andres--desktop--3-drive3 /media/drive3   ext4defaults0 
  2
/dev/mapper/andres--desktop-swap noneswapsw  0  
 0
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0

-- lsmod
Module  Size  Used by
parport_pc 22364  0 
ppdev  12763  0 
lp 17149  0 
parport31858  3 lp,ppdev,parport_pc
pci_stub   12429  1 
vboxpci19103  0 
vboxnetadp 25443  0 
vboxnetflt 23608  0 
vboxdrv   190105  3 vboxnetflt,vboxnetadp,vboxpci
binfmt_misc12957  1 
nfsd  216029  2 
nfs   312283  0 
nfs_acl12511  2 nfs,nfsd
auth_rpcgss37143  2 nfs,nfsd
fscache36739  1 nfs
lockd  67306  2 nfs,nfsd
sunrpc173774  6 lockd,auth_rpcgss,nfs_acl,nfs,nfsd
loop   22641  0 
snd_usb_audio  84836  0 
snd_usbmidi_lib23420  1 snd_usb_audio
snd_seq_midi   12848  0 
snd_seq_midi_event 13316  1 snd_seq_midi
snd_rawmidi23060  2 snd_seq_midi,snd_usbmidi_lib
uvcvideo   57744  0 
cx18_alsa  13045  0 
mxl5005s   37647  1 
snd_hda_codec_realtek   188858  1 
s5h140913142  1 
tuner_simple   17175  1 
tuner_types16409  1 tuner_simple
snd_hda_intel  26345  0 
cs5345 12628  1 
nvidia  11214135  30 
tda988712645  1 
tda829017278  0 
snd_hda_codec  78031  2 snd_hda_intel,snd_hda_codec_realtek
tuner  17497  2 
snd_hwdep  13186  2 snd_hda_codec,snd_usb_audio
snd_pcm68083  4 
snd_hda_codec,snd_hda_intel,cx18_alsa,snd_usb_audio
snd_page_alloc 13003  2 snd_pcm,snd_hda_intel
cx18  103254  1 cx18_alsa
videobuf_vmalloc   12715  1 cx18
cx2341x21461  1 cx18
dvb_core   77683  1 cx18
tveeprom   20593  1 cx18
snd_seq45126  2 snd_seq_midi_event,snd_seq_midi
snd_seq_device 13176  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer  22917  2 snd_seq,snd_pcm
snd52889  12 
snd_timer,snd_seq_device,snd_seq,snd_pcm,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_realtek,cx18_alsa,snd_rawmidi,snd_usbmidi_lib,snd_usb_audio
coretemp   12898  0 
acpi_cpufreq   12935  0 
mperf  12453  1 acpi_cpufreq
soundcore  13065  1 snd
mxm_wmi12515  0 
iTCO_wdt   17081  0 
wmi13243  1 mxm_wmi
videobuf_core  17825  2 videobuf_vmalloc,cx18
v4l2_common13222  4 cx2341x,cx18,tuner,cs5345
videodev   70889  6 v4l2_common,cx2341x,cx18,tuner,cs5345,uvcvideo
i2c_i801   16870  0 
v4l2_compat_ioctl3216655  1 videodev
iTCO_vendor_support12704  1 iTCO_wdt
media  18148  2 videodev,uvcvideo
i2c_algo_bit   12841  1 cx18
i7core_edac22454  0 
psmouse64497  0 
edac_core  35258  3 i7core_edac
i2c_core   23876  14 
i2c_algo_bit,i2c_i801,videodev,v4l2_common,tveeprom,cx18,tuner,tda8290,tda9887,nvidia,cs5345,tuner_simple,s5h1409,mxl5005s
button 12937  0 
processor  28157  1 acpi_cpufreq
evdev 

Bug#697156: /usr/share/initramfs-tools/scripts/local-top/cryptroot: Pass $cryptkey to /lib/cryptsetup/passfifo in ssh session

[Andres Mejia]

Package: cryptsetup
Version: 2:1.4.3-4
Severity: wishlist
File: /usr/share/initramfs-tools/scripts/local-top/cryptroot
Tags: patch

It would be great if the cryptroot script can also pass the $cryptkey into
/lib/cryptsetup/passfifo when running in an ssh session via dropbear. I've
attached a patch which will enable this.

-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/andres--desktop-root ro quiet

-- /etc/crypttab
sda2_crypt UUID=522e25f9-7e66-49fd-83c9-3bf168b5ddfd none luks
sdb1_crypt UUID=2e1f3d5f-fcc7-4ed9-9b02-f1672cb6206b /var/local/luks/random_key 
luks
sdc1_crypt UUID=8657c2e9-1d7b-4229-86db-408874c7c944 /var/local/luks/random_key 
luks

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/andres--desktop-root /   ext4errors=remount-ro 0
   1
# /boot was on /dev/sda1 during installation
UUID=f4472afd-877c-47a9-979f-13ad302042bc /boot   ext4defaults  
  0   2
/dev/mapper/andres--desktop--2-drive2 /media/drive2   ext4defaults0 
  2
/dev/mapper/andres--desktop--3-drive3 /media/drive3   ext4defaults0 
  2
/dev/mapper/andres--desktop-swap noneswapsw  0  
 0
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0

-- lsmod
Module  Size  Used by
parport_pc 22364  0 
ppdev  12763  0 
lp 17149  0 
parport31858  3 lp,ppdev,parport_pc
pci_stub   12429  1 
vboxpci19103  0 
vboxnetadp 25443  0 
vboxnetflt 23608  0 
vboxdrv   190105  3 vboxnetflt,vboxnetadp,vboxpci
binfmt_misc12957  1 
nfsd  216029  2 
nfs   312283  0 
nfs_acl12511  2 nfs,nfsd
auth_rpcgss37143  2 nfs,nfsd
fscache36739  1 nfs
lockd  67306  2 nfs,nfsd
sunrpc173774  6 lockd,auth_rpcgss,nfs_acl,nfs,nfsd
loop   22641  0 
snd_usb_audio  84836  0 
snd_usbmidi_lib23420  1 snd_usb_audio
snd_seq_midi   12848  0 
snd_seq_midi_event 13316  1 snd_seq_midi
snd_rawmidi23060  2 snd_seq_midi,snd_usbmidi_lib
uvcvideo   57744  0 
cx18_alsa  13045  0 
mxl5005s   37647  1 
snd_hda_codec_realtek   188858  1 
s5h140913142  1 
tuner_simple   17175  1 
tuner_types16409  1 tuner_simple
snd_hda_intel  26345  0 
cs5345 12628  1 
nvidia  11214135  30 
tda988712645  1 
tda829017278  0 
snd_hda_codec  78031  2 snd_hda_intel,snd_hda_codec_realtek
tuner  17497  2 
snd_hwdep  13186  2 snd_hda_codec,snd_usb_audio
snd_pcm68083  4 
snd_hda_codec,snd_hda_intel,cx18_alsa,snd_usb_audio
snd_page_alloc 13003  2 snd_pcm,snd_hda_intel
cx18  103254  1 cx18_alsa
videobuf_vmalloc   12715  1 cx18
cx2341x21461  1 cx18
dvb_core   77683  1 cx18
tveeprom   20593  1 cx18
snd_seq45126  2 snd_seq_midi_event,snd_seq_midi
snd_seq_device 13176  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer  22917  2 snd_seq,snd_pcm
snd52889  12 
snd_timer,snd_seq_device,snd_seq,snd_pcm,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_realtek,cx18_alsa,snd_rawmidi,snd_usbmidi_lib,snd_usb_audio
coretemp   12898  0 
acpi_cpufreq   12935  0 
mperf  12453  1 acpi_cpufreq
soundcore  13065  1 snd
mxm_wmi12515  0 
iTCO_wdt   17081  0 
wmi13243  1 mxm_wmi
videobuf_core  17825  2 videobuf_vmalloc,cx18
v4l2_common13222  4 cx2341x,cx18,tuner,cs5345
videodev   70889  6 v4l2_common,cx2341x,cx18,tuner,cs5345,uvcvideo
i2c_i801   16870  0 
v4l2_compat_ioctl3216655  1 videodev
iTCO_vendor_support12704  1 iTCO_wdt
media  18148  2 videodev,uvcvideo
i2c_algo_bit   12841  1 cx18
i7core_edac22454  0 
psmouse64497  0 
edac_core  35258  3 i7core_edac
i2c_core   23876  14 
i2c_algo_bit,i2c_i801,videodev,v4l2_common,tveeprom,cx18,tuner,tda8290,tda9887,nvidia,cs5345,tuner_simple,s5h1409,mxl5005s
button 12937  0 
processor  28157  1 acpi_cpufreq
evdev  17562  10 
pcspkr 12579  0 
thermal_sys18040  1 processor
serio_raw  12931  0 
ext4  350601  4 
crc16  12343  1 ext4
jbd2

Bug#697155: /usr/share/initramfs-tools/scripts/local-top/cryptroot: Can't find blkid via ssh session

[Andres Mejia]

Package: cryptsetup
Version: 2:1.4.3-4
Severity: normal
File: /usr/share/initramfs-tools/scripts/local-top/cryptroot
Tags: patch

If using the cryptroot script to unlock the encrypted drives, the script will
fail at line 296 with the message that it cannot find blkid. The simple fix here
is to change the line to run /sbin/blkid instead.

-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/andres--desktop-root ro quiet

-- /etc/crypttab
sda2_crypt UUID=522e25f9-7e66-49fd-83c9-3bf168b5ddfd none luks
sdb1_crypt UUID=2e1f3d5f-fcc7-4ed9-9b02-f1672cb6206b /var/local/luks/random_key 
luks
sdc1_crypt UUID=8657c2e9-1d7b-4229-86db-408874c7c944 /var/local/luks/random_key 
luks

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/andres--desktop-root /   ext4errors=remount-ro 0
   1
# /boot was on /dev/sda1 during installation
UUID=f4472afd-877c-47a9-979f-13ad302042bc /boot   ext4defaults  
  0   2
/dev/mapper/andres--desktop--2-drive2 /media/drive2   ext4defaults0 
  2
/dev/mapper/andres--desktop--3-drive3 /media/drive3   ext4defaults0 
  2
/dev/mapper/andres--desktop-swap noneswapsw  0  
 0
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0

-- lsmod
Module  Size  Used by
parport_pc 22364  0 
ppdev  12763  0 
lp 17149  0 
parport31858  3 lp,ppdev,parport_pc
pci_stub   12429  1 
vboxpci19103  0 
vboxnetadp 25443  0 
vboxnetflt 23608  0 
vboxdrv   190105  3 vboxnetflt,vboxnetadp,vboxpci
binfmt_misc12957  1 
nfsd  216029  2 
nfs   312283  0 
nfs_acl12511  2 nfs,nfsd
auth_rpcgss37143  2 nfs,nfsd
fscache36739  1 nfs
lockd  67306  2 nfs,nfsd
sunrpc173774  6 lockd,auth_rpcgss,nfs_acl,nfs,nfsd
loop   22641  0 
snd_usb_audio  84836  0 
snd_usbmidi_lib23420  1 snd_usb_audio
snd_seq_midi   12848  0 
snd_seq_midi_event 13316  1 snd_seq_midi
snd_rawmidi23060  2 snd_seq_midi,snd_usbmidi_lib
uvcvideo   57744  0 
cx18_alsa  13045  0 
mxl5005s   37647  1 
snd_hda_codec_realtek   188858  1 
s5h140913142  1 
tuner_simple   17175  1 
tuner_types16409  1 tuner_simple
snd_hda_intel  26345  0 
cs5345 12628  1 
nvidia  11214135  30 
tda988712645  1 
tda829017278  0 
snd_hda_codec  78031  2 snd_hda_intel,snd_hda_codec_realtek
tuner  17497  2 
snd_hwdep  13186  2 snd_hda_codec,snd_usb_audio
snd_pcm68083  4 
snd_hda_codec,snd_hda_intel,cx18_alsa,snd_usb_audio
snd_page_alloc 13003  2 snd_pcm,snd_hda_intel
cx18  103254  1 cx18_alsa
videobuf_vmalloc   12715  1 cx18
cx2341x21461  1 cx18
dvb_core   77683  1 cx18
tveeprom   20593  1 cx18
snd_seq45126  2 snd_seq_midi_event,snd_seq_midi
snd_seq_device 13176  3 snd_seq,snd_rawmidi,snd_seq_midi
snd_timer  22917  2 snd_seq,snd_pcm
snd52889  12 
snd_timer,snd_seq_device,snd_seq,snd_pcm,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_realtek,cx18_alsa,snd_rawmidi,snd_usbmidi_lib,snd_usb_audio
coretemp   12898  0 
acpi_cpufreq   12935  0 
mperf  12453  1 acpi_cpufreq
soundcore  13065  1 snd
mxm_wmi12515  0 
iTCO_wdt   17081  0 
wmi13243  1 mxm_wmi
videobuf_core  17825  2 videobuf_vmalloc,cx18
v4l2_common13222  4 cx2341x,cx18,tuner,cs5345
videodev   70889  6 v4l2_common,cx2341x,cx18,tuner,cs5345,uvcvideo
i2c_i801   16870  0 
v4l2_compat_ioctl3216655  1 videodev
iTCO_vendor_support12704  1 iTCO_wdt
media  18148  2 videodev,uvcvideo
i2c_algo_bit   12841  1 cx18
i7core_edac22454  0 
psmouse64497  0 
edac_core  35258  3 i7core_edac
i2c_core   23876  14 
i2c_algo_bit,i2c_i801,videodev,v4l2_common,tveeprom,cx18,tuner,tda8290,tda9887,nvidia,cs5345,tuner_simple,s5h1409,mxl5005s
button 12937  0 
processor  28157  1 acpi_cpufreq
evdev  17562  10 
pcspkr 12579  0 
thermal_sys18040  1 processor
serio_raw  12931  0 
ext4  350601  4 
crc16  12343  1 ext4
jbd2

Bug#697008: firmware-ivtv: Please include Conexant cx18 firmware

[Andres Mejia]

Package: firmware-ivtv
Version: 0.36
Severity: wishlist

The firmware-ivtv package contains firmware for some Conexant devices, but not
for the cx18 devices which are needed for using the Hauppauge HVR-1600 tuner.
The firmware needed are 'v4l-cx23418-apu.fw', 'v4l-cx23418-cpu.fw', and
'v4l-cx23418-dig.fw'. These firmware are available at
http://linuxtv.org/downloads/firmware/.

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages firmware-ivtv depends on:
ii  debconf [debconf-2.0]  1.5.48

firmware-ivtv recommends no packages.

Versions of packages firmware-ivtv suggests:
ii  initramfs-tools  0.109
ii  linux-image-3.2.0-4-amd64 [linux-image]  3.2.35-2

-- debconf information:
* firmware-ivtv/license/accepted: true
  firmware-ivtv/license/error:


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#687374: Please update to 1.8.0

[Andres Mejia]

Hi,
Here's a diff of changes I did to get the plain taglib library
packages to build for 1.8. I dropped the rusxmms changes entirely. I
think the rusxmms changes should be properly integrated upstream first
and then backported to the Debian packages.

-- 
~ Andres


taglib-1.8_packaging.diff
Description: Binary data

Bug#668901: please drop transitional packages

[Andres Mejia]

tags 668901 upstream
stop

The transitional packages will be dropped after the release of wheezy.

-- 
~ Andres


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#676688: /usr/bin/krunner: krunner crashes, unable to lock screen

[Andres Mejia]

Package: kde-workspace-bin
Version: 4:4.7.4-2+b1
Severity: important
File: /usr/bin/krunner

After a recent update of my machines, I have been unable to lock my screen.
While doing some investigation, I've seen mention that the screensaver
functionality in KDE is tied to krunner. krunner crashes every time an attempt
to run it is made, whether it's during an initial login, or simply through
the command line. The following output is displayed when krunner crashes.

$ krunner
QDBusConnection: session D-Bus connection created before QCoreApplication. 
Application may misbehave.
QDBusConnection: session D-Bus connection created before QCoreApplication. 
Application may misbehave.
X Error: BadValue (integer parameter out of range for operation) 2
  Major opcode: 53 (X_CreatePixmap)
  Resource id:  0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 14 (X_GetGeometry)
  Resource id:  0x5200142
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 3 (X_GetWindowAttributes)
  Resource id:  0x5
QPainter::begin: Cannot paint on a null pixmap
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Extension:152 (RENDER)
  Minor opcode: 4 (RenderCreatePicture)
  Resource id:  0x5200142
X Error: BadValue (integer parameter out of range for operation) 2
  Major opcode: 53 (X_CreatePixmap)
  Resource id:  0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 14 (X_GetGeometry)
  Resource id:  0x5200144
X Error: BadWindow (invalid Window parameter) 3
  Major opcode: 3 (X_GetWindowAttributes)
  Resource id:  0x5
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Extension:152 (RENDER)
  Minor opcode: 4 (RenderCreatePicture)
  Resource id:  0x5200144
X Error: RenderBadPicture (invalid Picture parameter) 174
  Extension:152 (RENDER)
  Minor opcode: 8 (RenderComposite)
  Resource id:  0x5200144
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 55 (X_CreateGC)
  Resource id:  0x5200144
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 55 (X_CreateGC)
  Resource id:  0x5200144
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 73 (X_GetImage)
  Resource id:  0x5200144
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
KCrash: Attempting to start /usr/bin/krunner from kdeinit
sock_file=/home/andres/.kde/socket-debian/kdeinit4__0
unnamed app(12646): Communication problem with  "krunner" , it probably crashed.
Error message was:  "org.freedesktop.DBus.Error.NoReply" : " "Message did not 
receive a reply (timeout by message bus)" "

$ KCrash: Application 'krunner' crashing...
KCrash: Attempting to start /usr/lib/kde4/libexec/drkonqi from kdeinit
sock_file=/home/andres/.kde/socket-debian/kdeinit4__0
QSocketNotifier: Invalid socket 10 and type 'Read', disabling...

This is the report that would be genereted with KDE's crash report utility.

Application: krunner (0.1)
KDE Platform Version: 4.7.4 (4.7.4)
Qt Version: 4.8.1
Operating System: Linux 3.2.0-2-amd64 x86_64
Distribution: Debian GNU/Linux unstable (sid)

-- Information about the crash:


The crash can be reproduced every time.

-- Backtrace:
Application: Run Command Interface (krunner), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f5ec0bd27a0 (LWP 4684))]

Thread 2 (Thread 0x7f5ea3b20700 (LWP 4692)):
#0  0x7f5ec04fc70d in read () at ../sysdeps/unix/syscall-template.S:82
#1  0x7f5eb165a0bc in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
#2  0x7f5eaeec1b27 in ?? () from 
/usr/lib/x86_64-linux-gnu/tls/libnvidia-tls.so.295.53
#3  0x7f5eb59b650f in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f5eb597b059 in g_main_context_check () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f5eb597b472 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x7f5eb597b5f4 in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x7f5ebceed7c6 in QEventDispatcherGlib::processEvents (this=0x1dc2920, 
flags=...) at kernel/qeventdispatcher_glib.cpp:426
#8  0x7f5ebcebe14f in QEventLoop::processEvents 
(this=this@entry=0x7f5ea3b1fd10, flags=...) at kernel/qeventloop.cpp:149
#9  0x7f5ebcebe3d8 in QEventLoop::exec (this=0x7f5ea3b1fd10, flags=...) at 
kernel/qeventloop.cpp:204
#10 0x7f5ebcdc1c50 in QThread::exec (this=) at 
thread/qthread.cpp:501
#11 0x7f5ebce9eaaf in QInotifyFileSystemWatcherEngine::run (this=0x1dc2480) 
at io/qfilesystemwatcher_inotify.cpp:248
#12 0x7f5ebcdc4beb in QThreadPrivate::start (arg=0x1dc2480) at 
thread/qthread_unix.cpp:298
#13 0x7f5eb165bb74 in ?? () from /usr/lib/x86_64-linux-gnu/libGL.so.1
#14 0x7f5eb5e48b50 in start_thread (arg=) at 
pthread_create.c:304
#15 0x7f5ec05086dd in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#16 0x in ?? ()

Thread 1 (Thread 0x

Bug#675354: sbuild fails to run without xapt installed

[Andres Mejia]

Package: sbuild
Version: 0.63.0-1
Severity: important

Currently, running any of the sbuild commands requires xapt to be installed.
It looks as though using xapt is supposed to be optional. Under the
Sbuild/Conf.pm file around line 262, the 'XAPT' hash entry contains two
CHECK child hash entries. Remove the second CHECK entry (the line which simply
has 'CHECK => $validate_program') and sbuild resumes to work as it should.

I could add an appropriate patch later.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages sbuild depends on:
ii  adduser 3.113+nmu3
ii  apt-utils   0.9.5.1
ii  libsbuild-perl  0.63.0-1
ii  perl5.14.2-11
ii  perl-modules5.14.2-11

Versions of packages sbuild recommends:
ii  debootstrap  1.0.40
ii  fakeroot 1.18.3-1

Versions of packages sbuild suggests:
ii  deborphan  
ii  wget   1.13.4-3

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#456165: Decent DVD rippers?

[Andres Mejia]

On Sun, May 13, 2012 at 5:19 PM, Fabian Greffrath  wrote:
> Am Freitag, den 11.05.2012, 16:10 -0400 schrieb Andres Mejia:
>> Could it use vo-aacenc as an alternate?
>
> I've never considered. It's not like vo-aacenc is a drop-in replacement
> for faac, their APIs appear quite dissimilar (IIRC vo-aacenc is C++
> while libfaac is C).

Yes it's not a drop-in replacement and I believe faac has some
features not available in vo-aacenc. I could be mistaken about the
features however.

>> It probably makes more sense to replace use of libmp4v2 with libav
>> instead anyway. mp4v2 upstream doesn't look very active IMO and it may
>> serve the handbrake project better to switch to something else.
>
> There is still atomicparsley as an alternative. The gtkpod mainatiners
> have just turned it into a GPL'ed library, cf.
> <http://old.nabble.com/Finally-pushed-alternative-to-libmp4v2-td33723081.html>
>
>  - Fabian
>
>

Ok, saving this little information about atomicparsley in the ITP bug
for handbrake.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#672791: Strict internal dependencies make libavcodec53 uninstallable when updating to libav 0.9

[Andres Mejia]

On Sun, May 13, 2012 at 3:10 PM, Reinhard Tartler  wrote:
> On So, Mai 13, 2012 at 20:43:08 (CEST), Andres Mejia wrote:
>
>> On Sun, May 13, 2012 at 1:48 PM, Reinhard Tartler  
>> wrote:
>>> Package: libavcodec53
>>> Severity: important
>>>
>>> I have now prepared a new upstream snapshot of libav at
>>> http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=shortlog;h=refs/heads/experimental.
>>> In this new version, the SONAME of libavcodec and libavformat was bumped
>>> from 53 to 54. This is not a problem by itself and necessary as a number
>>> of deprecated APIs have been dropped. However, libavutil51 has not been
>>> bumped, but is simply newer. This fact now causes the problem that the
>>> 'old' libavcodec53, which a lot of applications link against, becomes
>>> uninstallable because of the strict internal dependencies:
>>>
>>> Depends: libavutil51 (>= 4:0.8.1-0ubuntu1) | libavutil-extra-51 (>= 
>>> 4:0.8.1), libavutil51 (<< 4:0.8.1-99) | libavutil-extra-51 (<< 4:0.8.1.99)
>>>
>>> What can we do now about this:
>>>
>>> a) We could simply drop the strict internal dependencies.
>>>
>>> They were mostly a safety guard to ensure that on upstream version
>>> upgrades, all shipped libraries stay in sync. This is exactly what
>>> breaks now. Technically, removing this safety net is easy to do by
>>> dropping a few lines in debian/rules.
>>>
>>> b) somehow ship a 'new' libavcodec53 that links against the new
>>> libavutil.
>>>
>>> Yay, code duplication. We would also need to duplicate libavformat53. I
>>> think this is a no-go.
>>>
>>> c) bump SONAME of libavutil
>>>
>>> This would work, but I'd rather not diverge from upstream's SONAMES. And
>>> convincing upstream to do this to accommodate Debian's rather strange
>>> decisions with strict internal dependencies is rather not going to happen.
>>>
>>> d) something else I didn't think of.
>>>
>>>
>>> TBH, I'd tend for option a), but before going that way, I'd also like to
>>> hear your input on that.
>>>
>
> [...]
>
>>
>> I'm more inclined to go with option a) for those libraries/programs
>> that do not need the strict internal dependencies (i.e. libraries and
>> programs that are not using non-public headers and symbols). I think
>> libavutil should drop the strict dependencies if this is the case.
>
> Ah, so you suggest do have the strict internal dependencies excluded for
> libavcodec? For the sake of simplicity, I'd just drop them for all
> packages.  I've introduced the strict internal dependencies in the days
> where there weren't proper releases, and the internal APIs were much
> more in flux.  I think this has vastly improved in the mean time.
>
> Cheers,
> Reinhard
>
> --
> Gruesse/greetings,
> Reinhard Tartler, KeyID 945348A4

If libavcodec is not using any private headers or symbols from any of
the other libraries, then yes, the strict internal dependencies should
be excluded.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#672791: Strict internal dependencies make libavcodec53 uninstallable when updating to libav 0.9

[Andres Mejia]

On Sun, May 13, 2012 at 1:48 PM, Reinhard Tartler  wrote:
> Package: libavcodec53
> Severity: important
>
> I have now prepared a new upstream snapshot of libav at
> http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=shortlog;h=refs/heads/experimental.
> In this new version, the SONAME of libavcodec and libavformat was bumped
> from 53 to 54. This is not a problem by itself and necessary as a number
> of deprecated APIs have been dropped. However, libavutil51 has not been
> bumped, but is simply newer. This fact now causes the problem that the
> 'old' libavcodec53, which a lot of applications link against, becomes
> uninstallable because of the strict internal dependencies:
>
> Depends: libavutil51 (>= 4:0.8.1-0ubuntu1) | libavutil-extra-51 (>= 4:0.8.1), 
> libavutil51 (<< 4:0.8.1-99) | libavutil-extra-51 (<< 4:0.8.1.99)
>
> What can we do now about this:
>
> a) We could simply drop the strict internal dependencies.
>
> They were mostly a safety guard to ensure that on upstream version
> upgrades, all shipped libraries stay in sync. This is exactly what
> breaks now. Technically, removing this safety net is easy to do by
> dropping a few lines in debian/rules.
>
> b) somehow ship a 'new' libavcodec53 that links against the new
> libavutil.
>
> Yay, code duplication. We would also need to duplicate libavformat53. I
> think this is a no-go.
>
> c) bump SONAME of libavutil
>
> This would work, but I'd rather not diverge from upstream's SONAMES. And
> convincing upstream to do this to accommodate Debian's rather strange
> decisions with strict internal dependencies is rather not going to happen.
>
> d) something else I didn't think of.
>
>
> TBH, I'd tend for option a), but before going that way, I'd also like to
> hear your input on that.
>
> Cheers,
> Reinhard
>
>
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

I'm more inclined to go with option a) for those libraries/programs
that do not need the strict internal dependencies (i.e. libraries and
programs that are not using non-public headers and symbols). I think
libavutil should drop the strict dependencies if this is the case.

~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#456165: ITP: handbrake -- Rips and encodes DVDs (was Bug#672561: libavcodec-dev: Missing /usr/include/libavcodec/audioconvert.h)

[Andres Mejia]

On Sat, May 12, 2012 at 1:36 PM, Reinhard Tartler  wrote:
> On Sat, May 12, 2012 at 5:40 PM, Andres Mejia  wrote:
>
>>
>> I just noticed that libmkv was written specifically for handbrake. In
>> this case, I wouldn't even bother uploading libmkv separately and just
>> use whatever libmkv ships with handbrake.
>
> TBH, I agree.
>
> Fabian, this does not mean that your work on
> git+ssh://git.debian.org/git/pkg-multimedia/libmkv was in vain. As
> soon as some other package uses it, we can use your packaging and
> upload to debian. But until then, we gain little to nothing by
> shipping it outside of handbrake
>
> --
> regards,
>     Reinhard

I was going off by the assumption that handbrake ships with libmkv,
but I found it doesn't. It simply downloads libmkv. I think it will be
easier to upload libmkv instead.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#672659: ITP: libmkv -- Alternative to the official libmatroska/libebml libraries

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: Debian Multimedia Maintainers 


* Package name: libmkv
  Version : 0.6.5.1
  Upstream Author : saint...@gmail.com
* URL : https://github.com/saintdev/libmkv
* License : GPLv2+
  Programming Lang: C
  Description : Alternative to the official libmatroska/libebml libraries

This library is meant to be an alternative to the official libmatroska
library.  It is writen (Thanks Haali) in plain C, and intended to be very
portable.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#456165: ITP: handbrake -- Rips and encodes DVDs (was Bug#672561: libavcodec-dev: Missing /usr/include/libavcodec/audioconvert.h)

[Andres Mejia]

On Sat, May 12, 2012 at 5:07 AM, Rogério Brito  wrote:
> Hi, all.
>
> On Sat, May 12, 2012 at 3:46 AM, Reinhard Tartler  wrote:
>> The problem with that is that audioconvert.h is not part of the public
>> API. Moreover, most of the APIs have already been removed in current
>> libav/master in favor of the newly introduced libavresample library.
>> Therefore, I do not think it would be a good idea to start shipping
>> this header.
>
> OK.
>
>> The proper long-term solution is to port handbrake to 'libavresample'
>> (not yet uploaded to experimental, the packaging needs review, and is
>> not going to be included in wheezy). As short-term workaround, I'd
>> suggest to copy the parts of audioconvert.h and audioconvert.c to the
>> handbrake packaging.
>
> For the quick and dirty solution, I did just that, but the packaging
> is crufty. As I need to get some sleep right now, it will be great to
> see the package gain some love from others, even if we can't upload
> handbrake due to licensing and dependencies in time for wheezy.
>
> OTOH, it never hurts to be able to have the package in source form
> ready for a compilation to be used as we see fit, while the package
> has not hit the main archive.
>
>> That's excellent news! Thanks for working on it and count me in as
>> supporter (i.e., put me to Uploaders).
>
> Just did that and pushed my current changes to the repo:
>
>    http://anonscm.debian.org/gitweb/?p=pkg-multimedia/handbrake.git
>
> I hope that others will join me in getting it slowly in shape.
>
>
> Regards,
>
> --
> Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
> http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
> DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

I just noticed that libmkv was written specifically for handbrake. In
this case, I wouldn't even bother uploading libmkv separately and just
use whatever libmkv ships with handbrake.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#456165: ITP: handbrake -- Rips and encodes DVDs

[Andres Mejia]

owner 456165 pkg-multimedia-maintain...@lists.alioth.debian.org
retitle 456165 ITP: handbrake -- Rips and encodes DVDs
stop

The package is now being worked on. See [1].

1. http://anonscm.debian.org/gitweb/?p=pkg-multimedia/handbrake.git



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#672561: libavcodec-dev: Missing /usr/include/libavcodec/audioconvert.h

[Andres Mejia]

On May 12, 2012 2:22 AM, "Rogério Brito"  wrote:
>
> Hi there.
>
> On Sat, May 12, 2012 at 3:07 AM, Andres Mejia  wrote:
> > On Sat, May 12, 2012 at 1:39 AM, Rogério Brito 
wrote:
> >> Package: libavcodec-dev
> >> Severity: important
> >>
> >> Hi.
> >>
> >> The libavcodec-dev package is missing
.
> >
> > Audioconvert is not a public header in either libav or ffmpeg. What is
> > suppose to be used for this functionality is libavresample or
> > libswresample.
>
> I'm just getting it to compile, at first, and they use that. They
> probably need a cluebat, then, if that is not a public interface. The
> problem here is that they use AVAudioConvert, which is present only in
> that header.
>
> I'm not exactly sure if I want to patch this so heavily as to fix the
> use of that interface.
>
> >> This file is needed by handbrake. If I clone the libav git tree,
> >> checkout the v0.8.2 tag and copy that file to /usr/include/avcodec,
> >> then I am able to successfully compile handbrake with Debian's libav,
> >> without needing to download things from outside.
> >>
> >> BTW, regarding handbrake, I am down to few packages now that need to
> >> be taken from outside debian for it to compile, namely:
> >>
> >> * MODULES += contrib/libdvdread
> >> * MODULES += contrib/libdvdnav
> >> * MODULES += contrib/mpeg2dec
> >
> > Does handbrake used patched versions of these libs or can it use these
> > libs as released upstream?
>
> I have yet to see which patches can be dropped and which don't. OTOH,
> the basics compile and a brief test here works. :)
>
> >> Everything else works with packages in Debian *or* with packages in
> >> the pkg-multimedia git repositories (e.g., libmkv, faac, libmp4v2).
> >
> > Ping Fabian. Was libmkv ready for upload?
>
> I think it is fine as is. Not sure if the legal stuff
> (debian/copyright etc.) is all in place for an upload to unstable.
>
> > Could vo-aacenc be used instead of faac?
>
> I still have to study that to see what can be done and how similar the
> interfaces are.
>
> > Also, as I mentioned in another email, libmp4v2 should be replaced with
libav. mp4v2 is seeing
> > less and less development and it's probably better to look into
> > replacing use of mp4v2 anyway.
>
> That's the same story as with vo-aacenc/faac.
>
> > Also next time, please leave out things unrelated to a bug in it's bug
report.
>
> OK, but the excitement is really huge and I couldn't help sending some
> side comments. :) Feel free to reply to the bug only the parts
> pertaining to the bug and to the mailing list the other parts (please,
> keep me CCed).
>
>
>
> Thanks.
>
> P.S.: Now, it compiles with Debian's mpeg2, which is one fewer embedded
library.
> --
> Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
> http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
> DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Keep up the great work. You may also want to create an ITP bug for
handbrake now.

~ Andres

Bug#672561: libavcodec-dev: Missing /usr/include/libavcodec/audioconvert.h

[Andres Mejia]

On Sat, May 12, 2012 at 1:39 AM, Rogério Brito  wrote:
> Package: libavcodec-dev
> Severity: important
>
> Hi.
>
> The libavcodec-dev package is missing 
> .

Audioconvert is not a public header in either libav or ffmpeg. What is
suppose to be used for this functionality is libavresample or
libswresample.

> This file is needed by handbrake. If I clone the libav git tree,
> checkout the v0.8.2 tag and copy that file to /usr/include/avcodec,
> then I am able to successfully compile handbrake with Debian's libav,
> without needing to download things from outside.
>
> BTW, regarding handbrake, I am down to few packages now that need to
> be taken from outside debian for it to compile, namely:
>
> * MODULES += contrib/libdvdread
> * MODULES += contrib/libdvdnav
> * MODULES += contrib/mpeg2dec

Does handbrake used patched versions of these libs or can it use these
libs as released upstream?

> Everything else works with packages in Debian *or* with packages in
> the pkg-multimedia git repositories (e.g., libmkv, faac, libmp4v2).

Ping Fabian. Was libmkv ready for upload?

Could vo-aacenc be used instead of faac? Also, as I mentioned in
another email, libmp4v2 should be replaced with libav. mp4v2 is seeing
less and less development and it's probably better to look into
replacing use of mp4v2 anyway.

>
> Regards,
>
> --
> Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
> http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
> DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
>
>
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Also next time, please leave out things unrelated to a bug in it's bug report.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#671302: Circular Build Dependencies (was Bug#671302: libav: circular dependency between libav and opencv)

[Andres Mejia]

On May 4, 2012 4:43 PM, "Fabian Greffrath"  wrote:
>
> > libav -> x264 -> libav
>
> AFAICT the x264 frontend uses libav whereas libav uses the libx264 shared
> library. So theortically (!) this issue could be solved by two separate
> source packages for the x264 frontend and the library.
>
>  - Fabian
>
>

This doesn't resolve the issue with opencv though.

~ Andres

Bug#671302: libav: circular dependency between libav and opencv

[Andres Mejia]

On May 3, 2012 5:36 PM, "Julien Cristau"  wrote:
>
> On Thu, May  3, 2012 at 10:20:57 -0400, Andres Mejia wrote:
>
> > I'm not entirely certain how build circular dependency issues like this
are
> > resolved. Perhaps we should ask for help from the toolchain package
> > maintainers or debian-devel.
>
> What's wrong with just disabling opencv?
>
> Cheers,
> Julien

There's a circular build dependency with x264 and gpac. I rather find
anothet way to resolve this issue now then resorting to doing a full
rebuild of libav on the buildd network twice.

It may just be faster to do what I suggested earlier.

~ Andres

Bug#671302: Circular Build Dependencies (was Bug#671302: libav: circular dependency between libav and opencv)

[Andres Mejia]

On May 3, 2012 10:20 AM, "Andres Mejia"  wrote:
>
> On May 3, 2012 9:30 AM, "Pino Toscano"  wrote:
> >
> > Alle giovedì 3 maggio 2012, Andres Mejia ha scritto:
> > > On Thu, May 3, 2012 at 3:44 AM, Pino Toscano  wrote:
> > > > Package: libav
> > > > Version: 6:0.8.1-7
> > > > Severity: important
> > > >
> > > > Hi,
> > > >
> > > > libav 6:0.8.1-7 reenables the use of opencv... which itself uses
> > > > libav libraries. This currently makes libav unbuildable on mipsel
> > > > and hurd-i386, and generically makes libav no more bootstrap'able
> > > > without having itself compiled already.
> > > > Could you please drop the opencv usage again, please?
> > > >
> > > What could be done instead is a binary only upload with opencv
> > > support disabled (i.e. use dpkg-buildpackage -B). Doing it on our
> > > end will not require changing the version. Once this package is
> > > uploaded, the release team can then be asked to do a binNMU for
> > > these archs, which will bring back opencv support since the archive
> > > will contain the regular *.debian.tar.gz changes that included
> > > opencv.
> > >
> > > I believe this is better than doing a full build on all archs without
> > > opencv, then doing another build with opencv.
> >
> > This mess (which is only a mess, not a clean solution) does not solve at
> > all the fact that you cannot do a clean build of libav without having
> > libav compiled already (for opencv).
> > I don't see this as a viable solution, especially if in the future the
> > epoch is raised bringing again conflicts between the old libav libraries
> > and the new one.
> >
> > --
> > Pino Toscano
>
> I'm not entirely certain how build circular dependency issues like this
are resolved. Perhaps we should ask for help from the toolchain package
maintainers or debian-devel.
>
> ~ Andres

Hello all,
I would like to know if there is a good (perhaps best) approach in
resolving issues with packages with circular build dependencies.

Libav has various circular build dependencies including.

libav -> opencv -> libav
libav -> x264 -> libav
libav -> x264 -> gpac -> libav

I found some mention of this issue at [1]. This however doesn't offer any
clear solution.

1. http://wiki.debian.org/DebianBootstrap

~ Andres

Bug#671302: libav: circular dependency between libav and opencv

[Andres Mejia]

On May 3, 2012 9:30 AM, "Pino Toscano"  wrote:
>
> Alle giovedì 3 maggio 2012, Andres Mejia ha scritto:
> > On Thu, May 3, 2012 at 3:44 AM, Pino Toscano  wrote:
> > > Package: libav
> > > Version: 6:0.8.1-7
> > > Severity: important
> > >
> > > Hi,
> > >
> > > libav 6:0.8.1-7 reenables the use of opencv... which itself uses
> > > libav libraries. This currently makes libav unbuildable on mipsel
> > > and hurd-i386, and generically makes libav no more bootstrap'able
> > > without having itself compiled already.
> > > Could you please drop the opencv usage again, please?
> > >
> > What could be done instead is a binary only upload with opencv
> > support disabled (i.e. use dpkg-buildpackage -B). Doing it on our
> > end will not require changing the version. Once this package is
> > uploaded, the release team can then be asked to do a binNMU for
> > these archs, which will bring back opencv support since the archive
> > will contain the regular *.debian.tar.gz changes that included
> > opencv.
> >
> > I believe this is better than doing a full build on all archs without
> > opencv, then doing another build with opencv.
>
> This mess (which is only a mess, not a clean solution) does not solve at
> all the fact that you cannot do a clean build of libav without having
> libav compiled already (for opencv).
> I don't see this as a viable solution, especially if in the future the
> epoch is raised bringing again conflicts between the old libav libraries
> and the new one.
>
> --
> Pino Toscano

I'm not entirely certain how build circular dependency issues like this are
resolved. Perhaps we should ask for help from the toolchain package
maintainers or debian-devel.

~ Andres

Bug#671302: libav: circular dependency between libav and opencv

[Andres Mejia]

On Thu, May 3, 2012 at 3:44 AM, Pino Toscano  wrote:
> Package: libav
> Version: 6:0.8.1-7
> Severity: important
>
> Hi,
>
> libav 6:0.8.1-7 reenables the use of opencv... which itself uses libav
> libraries. This currently makes libav unbuildable on mipsel and
> hurd-i386, and generically makes libav no more bootstrap'able without
> having itself compiled already.
> Could you please drop the opencv usage again, please?
>
> Thanks,
> --
> Pino
>
>
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

What could be done instead is a binary only upload with opencv support
disabled (i.e. use dpkg-buildpackage -B). Doing it on our end will not
require changing the version. Once this package is uploaded, the
release team can then be asked to do a binNMU for these archs, which
will bring back opencv support since the archive will contain the
regular *.debian.tar.gz changes that included opencv.

I believe this is better than doing a full build on all archs without
opencv, then doing another build with opencv.

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#671275: xbmc-live package modifications

[Andres Mejia]

Hi all,
I just reported a bug with some of my concerns about xbmc-live. See [1].

I think xbmc-live needs to use less of the maintainer script to do
what it needs to do. I'll just repeat what I wrote in the bug report.

  * The script reads /etc/default/xbmc-live but no such file is installed.
Whatever resides in /etc/default/ is meant for the sysv init scripts
anyway so the line reading /etc/default/xbmc-live should be dropped.
  * Line changing allowed_users in Xwrapper.config. Is this line really
necessary? I don't believe it's a good idea to allow all users to
start X. Besides, it's poor practice for a package to override
local administrator settings such as any settings in /etc.
  * Choosing an account to use with xbmc-live. I believe it would be
better to simply choose an account to be used with xbmc-live
(i.e. just choose 'xbmc'). This would help in installation of
configuration files as then we could ship any needed config files
in the xbmc-live package and not have to generate them with the
maintainer scripts. Shipping the config files this way also ensures
that any modifications done by the local administrator are not
overridden after each update of xbmc-live. Choosing a dedicated
account for xbmc will also remove the need to override the group
settings for any preexisting user account.
  * Allow users to override password for dedicated xbmc-live account.
It would be a good idea if users can override the default password
used for the dedicated account. debconf can be used in this case.
  * sudoers config file.
Maybe something else can be done that allows the xbmc-live account
to shutdown, reboot, mount, and unmount drives in the system. Also,
/etc/sudoers.d should be utilized for the xbmc specific sudo
configuration.
  * grub modifications
Modifications to grub need to be supplied in /etc/grub.d. It's generally
not a good idea to override settings set by the local administrator.
  * Seperate xbmc-live package for different init systems.
The xbmc-live package supplies scripts for both sysv init and upstart.
The sysv and upstart packages are not coinstallable so the xbmc-live
package should be split up.

Also, something else was mentioned about the creation of an xbmc-live
account. It's mentioned at [2] and I will repeated below.
"...Oh, and while we are it, please create a system user with its home
in /var/lib."

Here's a note about system users from the 'adduser' manpage.
   Add a system user
   If  called with one non-option argument and the --system
option, adduser will add a
   system user. If a user with the same name already exists in the
 system  uid  range
   (or, if the uid is specified, if a user with that uid already
exists), adduser will
   exit with a warning. This warning can be suppressed by adding "--quiet".

   adduser will choose the first available UID from the  range
specified  for  system
   users in the configuration file (FIRST_SYSTEM_UID and
LAST_SYSTEM_UID). If you want
   to have a specific UID, you can specify it using the --uid option.

   By default, system users are placed in the nogroup group.  To
place the new  system
   user  in  an  already existing group, use the --gid or
--ingroup options.  To place
   the new system user in a new group with the same ID, use the
--group option.

   A home directory is created by the same rules as for normal
users.  The new  system
   user  will  have  the shell /bin/false (unless overridden with
the --shell option),
   and have logins disabled.  Skeletal configuration files are not copied.

So basically, if we add a system user for xbmc-live, the --group
option will be needed, and the new user will have no shell and logins
disabled. Is this something we want?

1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671275
2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669727

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#671275: xbmc-live package modifications

[Andres Mejia]

Source: xbmc-live
Version: 2:11.0~git20120423.cd20772-2
Severity: important

The xbmc-live package needs to be reworked (IMO). Here are some things about
this package that stand out to me.

postinst maintainer script.
  * The script reads /etc/default/xbmc-live but no such file is installed.
Whatever resides in /etc/default/ is meant for the sysv init scripts
anyway so the line reading /etc/default/xbmc-live should be dropped.
  * Line changing allowed_users in Xwrapper.config. Is this line really
necessary? I don't believe it's a good idea to allow all users to
start X. Besides, it's poor practice for a package to override
local administrator settings such as any settings in /etc.
  * Choosing an account to use with xbmc-live. I believe it would be
better to simply choose an account to be used with xbmc-live
(i.e. just choose 'xbmc'). This would help in installation of
configuration files as then we could ship any needed config files
in the xbmc-live package and not have to generate them with the
maintainer scripts. Shipping the config files this way also ensures
that any modifications done by the local administrator are not
overridden after each update of xbmc-live. Choosing a dedicated
account for xbmc will also remove the need to override the group
settings for any preexisting user account.
  * Allow users to override password for dedicated xbmc-live account.
It would be a good idea if users can override the default password
used for the dedicated account. debconf can be used in this case.
  * sudoers config file.
Maybe something else can be done that allows the xbmc-live account
to shutdown, reboot, mount, and unmount drives in the system. Also,
/etc/sudoers.d should be utilized for the xbmc specific sudo
configuration.
  * grub modifications
Modifications to grub need to be supplied in /etc/grub.d. It's generally
not a good idea to override settings set by the local administrator.
  * Seperate xbmc-live package for different init systems.
The xbmc-live package supplies scripts for both sysv init and upstart.
The sysv and upstart packages are not coinstallable so the xbmc-live
package should be split up.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#660786: closed by Andres Mejia (Re: Bug#660786: ffmpeg: please migrate /etc/ffserver.conf to /etc/avserver.conf)

[Andres Mejia]

reopen 660786
severity 660786 minor
thanks

On Apr 23, 2012 4:42 AM, "Luca Capello"  wrote:
>
> notfixed 660786 4:0.8.1-1
> thanks
>
> Hi there!
>
> On Sun, 22 Apr 2012 17:39:13 +0200, Debian Bug Tracking System wrote:
> > This is an automatic notification regarding your Bug report
> > which was filed against the ffmpeg package:
> >
> > #660786: ffmpeg: please migrate /etc/ffserver.conf to /etc/avserver.conf
> >
> > It has been closed by Andres Mejia .
> [...]
> > From: Andres Mejia 
> > Subject: Re: Bug#660786: ffmpeg: please migrate /etc/ffserver.conf to
/etc/avserver.conf
> > To: 660786-d...@bugs.debian.org, cont...@bugs.debian.org
> > Date: Sun, 22 Apr 2012 11:36:29 -0400
> >
> > fixed 660786 4:0.8.1-1
> > stop
> [...]
> > This has since been fixed in version 4:0.8.1-1.
>
> No, it is not:
> =
> root@gismo:/etc# ls -l /etc/ffserver.conf /etc/avserver.conf
> -rw-r--r-- 1 root root 9085 Feb  5 23:43 /etc/avserver.conf
> -rw-r--r-- 1 root root 9085 Sep  1  2011 /etc/ffserver.conf
> root@gismo:/etc# dpkg-query -W ffmpeg
> ffmpeg  5:0.8.1-4
> root@gismo:/etc# dpkg-query -W libav\*
> libav-tools 5:0.8.1-4
> libavahi-client3:amd64  0.6.31-1
> libavahi-common-data:amd64  0.6.31-1
> libavahi-common3:amd64  0.6.31-1
> libavahi-core7:amd640.6.31-1
> libavahi-glib1:amd640.6.31-1
> libavcodec-extra-53
> libavcodec53:amd64  5:0.8.1-4
> libavdevice-extra-53
> libavdevice53:amd64 5:0.8.1-4
> libavfilter-extra-2
> libavfilter2:amd64  5:0.8.1-4
> libavformat-extra-53
> libavformat53:amd64 5:0.8.1-4
> libavutil-extra-51
> libavutil51:amd64   5:0.8.1-4
> root@gismo:/etc#
> =
>
> And 4:0.8.1-1 debian/changelog does not contain any hint about this issue.
>
> Thx, bye,
> Gismo / Luca
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
>
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

I suppose what you want is a proper migration for the renamed config file.
This would only affect users who have modified /etc/ffserver.conf before.
I'll look into this.

~ Andres

Bug#570611: Bug#669920: Please provide a backport for squeeze

[Andres Mejia]

On Sat, Apr 21, 2012 at 8:46 PM, Josh Triplett  wrote:
> On Sat, Apr 21, 2012 at 06:53:57PM -0400, Andres Mejia wrote:
>> On Sat, Apr 21, 2012 at 6:10 PM, Josh Triplett  wrote:
>> > Package: libcrystalhd-dev
>> > Severity: wishlist
>> >
>> > Please consider providing a backport of libcrystalhd-dev for squeeze.
>> > Such a backport would make it easier to prepare MythTV packages for
>> > squeeze.
>> >
>> > Thanks,
>> > Josh Triplett
>> >
>> > -- System Information:
>> > Debian Release: wheezy/sid
>> >  APT prefers unstable
>> >  APT policy: (500, 'unstable'), (1, 'experimental')
>> > Architecture: amd64 (x86_64)
>> >
>> > Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
>> > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
>> > Shell: /bin/sh linked to /bin/dash
>> >
>> >
>>
>> Hi Josh,
>> Were you trying to package MythTV to unstable at all? IMO that should
>> be done first before attempting to upload for squeeze (i.e. actually
>> get accepted, get tested in unstable, migrate to testing, then
>> backport to stable).
>
> At the moment I'm just building some local packages, not official
> backports.  I'd love to see official MythTV packages, and I'd be happy
> to help work on them, but that wasn't my goal at the moment.
>
> - Josh Triplett

I recommend starting off by porting the Ubuntu packaging of MythTV to
Debian. I presume if these are local packages, you're using reprepro
or something similar to host a local archive. In such a case, you may
as well build packages of libcrystalhd and upload them to your local
archive. Then you can build mythtv.

Note that mythtv is using it's own copy of ffmpeg. It needs to be
modified so it can build/run with system libav before it can be
uploaded to Debian. If that's something you're interested in doing, by
all means, feel free to modify mythtv source tree, and preferably work
with mythtv upstream to pass along patches.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#570611: Bug#669920: Please provide a backport for squeeze

[Andres Mejia]

On Sat, Apr 21, 2012 at 6:10 PM, Josh Triplett  wrote:
> Package: libcrystalhd-dev
> Severity: wishlist
>
> Please consider providing a backport of libcrystalhd-dev for squeeze.
> Such a backport would make it easier to prepare MythTV packages for
> squeeze.
>
> Thanks,
> Josh Triplett
>
> -- System Information:
> Debian Release: wheezy/sid
>  APT prefers unstable
>  APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
>

Hi Josh,
Were you trying to package MythTV to unstable at all? IMO that should
be done first before attempting to upload for squeeze (i.e. actually
get accepted, get tested in unstable, migrate to testing, then
backport to stable).

How was the packaging going to be done? Were you using the Ubuntu
packaging of MythTV as a baseline?

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#669390: O: ppmd -- fast archiver program with good compression ratio

[Andres Mejia]

On Apr 19, 2012 10:09 AM, "Guillem Jover"  wrote:
>
> Package: wnpp
> Severity: normal
>
> Continuing with my intention to try to match my current dissatisfaction
> with the project with my dedication to it, I've just orphaned the ppmd
> package.
>
> The package just got ported recently to 64-bit systems so builds for
> those systems need to be hand-held for now as that's not reflected
> on P-a-s yet.
>
> The package description is:
>  ppmd predicts the probability of a given character based on the
>  characters that immediately precede it (as all PPM compressors,
>  see also Markov Chains and Context Modeling). This archiver
>  should be better than zip, gzip, bzip2, zzip, szip and ppmz(2)
>  at compressing files.
>
> regards,
> guillem

FYI, ppmd (at least variants H and I) is used in 7zip. Similar code to
read/write 7zip is found in libarchive (and thus bsdtar). Libarchive has
been ported to a wide range of systems. I think the same is true for 7zip.

So there are alternatives.

~ Andres

Bug#668308: [Team-xbmc] Bug#668308: [xbmc] Re: xbmc: VDPAU with NVidia card stopped working

[Andres Mejia]

tags 668308 moreinfo
thanks

On Fri, Apr 13, 2012 at 3:59 AM, strawks  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Package: xbmc
> Version: 2:11.0~git20120403.ec33f1f+repack1-5
>
> - --- Please enter the report below this line. ---
>
>
> Acccording to packages.debian.org, version
> 2:11.0~git20120403.ec33f1f+repack1-5 is the official version, which
> suffers from this bug.

I'm not having any issues with VDPAU on my machines. Could you provide
a copy of your log file? See
http://wiki.xbmc.org/index.php?title=Log_file on where to find your
log file.

Also, please provide the output from the command 'reportbug --template
xbmc-bin'.

> Only 3:11.0-0.1 is from dmo and vdpau works fine.
>
> Regards,
> strawks
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk+H3PgACgkQ+2TXLlA5m7/CKgCeKh2QTSYz0j8Guz/WMb/i2uNy
> 0xEAmwURXIip8S9bweeeAsp0InF2sy/n
> =bDvT
> -END PGP SIGNATURE-
>
>
>
> ___
> Mailing list: https://launchpad.net/~team-xbmc
> Post to     : team-x...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~team-xbmc
> More help   : https://help.launchpad.net/ListHelp



-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#668316: [Team-xbmc] Bug#668316: xbmc: Please enable builds for arches other than amd64 and i386

[Andres Mejia]

tags 668316 upstream pending
stop

2012/4/10 Rogério Brito :
> Package: xbmc
> Severity: wishlist
> Version: 2:11.0~git20120403.ec33f1f+repack1-5
>
> Hi.
>
> I saw that the latest revision of xbmc (BTW, thanks for uploading it to
> Debian---one fewer package from dmo) disabled builds for architectures other
> than amd64 and i386. Would it be possible to have it enabled for other
> architectures? The changelog didn't mention the reason for the restriction.
>
> At least for PowerPC there are people that may (and are willing to) test the
> packages.
>
>
> Regards,
>
> --
> Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
> http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
> DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
>
>
>
>
> ___
> Mailing list: https://launchpad.net/~team-xbmc
> Post to     : team-x...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~team-xbmc
> More help   : https://help.launchpad.net/ListHelp

Yes, builds for the other archs will be reactivated soon. We're
currently working on getting the ARM builds working. For now, I at
least want the amd64 and i386 packages to enter testing.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#668404: xbmc-live: dependency on upstart prevents using xbmc with sysvinit

[Andres Mejia]

severity 668404 important
stop

Thanks for your report. xbmc-live requires upstart to be installed.
Note that xbmc-live is not necessary to install and use the xbmc
package.

I did not find anything in policy that says packages cannot require
the use of another init system. The only language I found pertaining
to this is Debian policy 9.3, which pertains to how maintainer scripts
should be provided for the init system, and has language like "should"
or "may" and not "must" or "require." I'm downgrading this bug to
important.

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#667583: override: libav binary packages

[Andres Mejia]

Package: ftp.debian.org
Severity: normal

The override needs to be updated for all these packages.

libavdevice-extra-53_0.8.1-4_all.deb: package says section is oldlibs, override 
says libs.
libavdevice-extra-53_0.8.1-4_all.deb: package says priority is extra, override 
says optional.
libavfilter-extra-2_0.8.1-4_all.deb: package says section is oldlibs, override 
says libs.
libavfilter-extra-2_0.8.1-4_all.deb: package says priority is extra, override 
says optional.
libavformat-extra-53_0.8.1-4_all.deb: package says section is oldlibs, override 
says libs.
libavformat-extra-53_0.8.1-4_all.deb: package says priority is extra, override 
says optional.
libavutil-extra-51_0.8.1-4_all.deb: package says section is oldlibs, override 
says libs.
libavutil-extra-51_0.8.1-4_all.deb: package says priority is extra, override 
says optional.
libpostproc-extra-52_0.8.1-4_all.deb: package says section is oldlibs, override 
says libs.
libpostproc-extra-52_0.8.1-4_all.deb: package says priority is extra, override 
says optional.
libswscale-extra-2_0.8.1-4_all.deb: package says section is oldlibs, override 
says libs.
libswscale-extra-2_0.8.1-4_all.deb: package says priority is extra, override 
says optional.

These are all transitional packages now and thus should have priority extra in
section oldlibs.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#667573: x264: 10 bit builds

[Andres Mejia]

Package: x264
Version: 2:0.120.2171+git01f7a33-3
Severity: wishlist

Reporting this to open discussion on this. It looks like 10 bit h264 encoding
is becoming the norm. We should allow some way to support both 10 bit and 8 bit
builds of x264, possibly making use of the alternatives system.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages x264 depends on:
ii  libavcodec-extra-53   5:0.8.1-4
ii  libavformat-extra-53  4:0.8~beta2.2
ii  libavformat53 [libavformat-extra-53]  5:0.8.1-4
ii  libavutil-extra-514:0.8.0.1+b1
ii  libavutil51 [libavutil-extra-51]  5:0.8.1-4
ii  libc6 2.13-27
ii  libffms2-22.17-1
ii  libpostproc-extra-52  4:0.8~beta2.2
ii  libpostproc52 [libpostproc-extra-52]  5:0.8.1-4
ii  libswscale-extra-24:0.8~beta2.2
ii  libswscale2 [libswscale-extra-2]  5:0.8.1-4
ii  libx264-120   2:0.120.2171+git01f7a33-3
ii  zlib1g1:1.2.6.dfsg-2

x264 recommends no packages.

x264 suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#666963: openal-soft: Build failure on many architectures

[Andres Mejia]

Package: openal-soft
Version: 1:1.14-1
Severity: serious

The new upload of openal-soft currently fails to build. Reporting this issue
now to remind myself to look into this issue.

Any help is welcome however.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#666765: lintian: Add libav libraries to embedded-library check

[Andres Mejia]

Package: lintian
Version: 2.5.6
Severity: wishlist
Tags: patch

Embedded libav libraries should be checked for in the 'embedded-library' check.
Reasons for this are as follow.

 * libav is a heavily used multimedia library. Many multimedia related packages
   (apps, frameworks, etc.) use libav in one form or another.
 * libav sees at least 10 security related fixes each point release.
 * In Debian, it was already expected that no package should use an embedded
   copy of any of the libav libraries.

Attached is a patch that will add the libav libraries into the
'embedded-libraries' lintian check.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages lintian depends on:
ii  binutils   2.22-6
ii  bzip2  1.0.6-1
ii  diffstat   1.55-2
ii  file   5.11-1
ii  gettext0.18.1.1-5
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.26
ii  libc-bin   2.13-27
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.31-1+b2
ii  libdpkg-perl   1.16.2
ii  libemail-valid-perl0.187-2
ii  libipc-run-perl0.91-1
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  locales2.13-27
ii  locales-all [locales]  2.13-27
ii  man-db 2.6.1-2
ii  patchutils 0.3.2-1.1
ii  perl [libdigest-sha-perl]  5.14.2-9
ii  unzip  6.0-6

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 
ii  dpkg-dev   1.16.2
ii  libhtml-parser-perl3.69-1+b1
ii  libtext-template-perl  1.45-2
ii  man-db 2.6.1-2
ii  xz-utils   5.1.1alpha+20110809-3

-- no debconf information
>From 9d3349195b9618aab5f7e1c67e4094400edc5392 Mon Sep 17 00:00:00 2001
From: Andres Mejia 
Date: Sat, 31 Mar 2012 16:19:50 -0400
Subject: [PATCH] Add check for embedded libav/ffmpeg libraries. It seems that
 libav/ffmpeg gets at least 10 security fixes every point
 release. A point release seems to be made once every 2
 months. Given this, embedding the libav/ffmpeg libs in an
 app should now be an error.

---
 checks/binaries |7 +++
 1 file changed, 7 insertions(+)

diff --git a/checks/binaries b/checks/binaries
index 2117659..57f103d 100644
--- a/checks/binaries
+++ b/checks/binaries
@@ -119,6 +119,13 @@ our %EMBEDDED_LIBRARIES = (
 'glee'  => qr'Extension name exceeds 1023 characters.',
 'glew'  => qr'Missing GL version',
 'libtheora' => qr'Xiph.Org libtheora ',
+'libavcodec'=> qr'insufficient thread locking around avcodec_open/close\(\)\n',
+'libavdevice'   => qr'Soundcard does not support 16 bit sample format\n',
+'libavfilter'   => qr'Buffer video frames, and make them accessible to the filterchain.',
+'libavformat'   => qr'Format detected only with low score of %d, misdetection possible!\n',
+'libavutil' => qr'AVOption type %d of option %s not implemented yet\n',
+'libpostproc'   => qr'using npp filters 0x%X/0x%X\n',
+'libswscale'=> qr'Exactly one scaler algorithm must be chosen\n',
 );
 
 our $MULTIARCH_DIRS = Lintian::Data->new('binaries/multiarch-dirs', '\s+');
-- 
1.7.9.5

Bug#664700: libva1: please search dri module in /usr/lib/{/, }dri

[Andres Mejia]

On Tue, Mar 27, 2012 at 4:53 PM, Andreas Beckmann  wrote:
> Hi Andres,
>
> you need to Cc: the bug submitter if you expect answers.
>
> For libvdpau please see
> debian/patches/vdpau-module-searchpath.patch
> where I sanitized the searching to look in \${ORIGIN}/vdpau/,
> $libdir/vdpau/, /usr/lib/vdpau/.
>
> dlopen() does the right thing, i.e. won't load a mismatching
> library (e.g. 32bit into a 64bit programm).
>
> Andreas

I would feel more comfortable if this were forwarded upstream. You may
want to forward a patch to them yourself. Right now, this isn't in my
list of priorities.

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#665318: ITP: faac -- AAC audio encoder

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: Debian Multimedia Maintainers 


* Package name: faac
  Version : 1.28
  Upstream Author : Menno Bakker 
* URL : http://www.audiocoding.com/
* License : GPL, LGPL, BSD, other
  Programming Lang: C, C++
  Description : AAC audio encoder

The FAAC project includes the AAC encoder FAAC and decoder FAAD2. It supports
several MPEG-4 object types (LC, Main, LTP, HE AAC, PS) and file formats
(ADTS AAC, raw AAC, MP4), multichannel and gapless en/decoding as well as MP4
metadata tags. The codecs are compatible with standard-compliant audio
applications using one or more of these profiles.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658084: libav-extra: Really necessary?

[Andres Mejia]

On Wed, Mar 21, 2012 at 6:58 PM, Reinhard Tartler  wrote:
> On Wed, Mar 21, 2012 at 9:55 PM, Andres Mejia  wrote:
>> On Mar 21, 2012 4:40 PM, "Micah Gersten"  wrote:
>>>
>>> On 03/21/2012 06:40 AM, Andres Mejia wrote:
>>> > On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler 
>>> > wrote:
>>> >>
>>> >> Do you volunteer to do at least the first uploads for libav and
>>> >> libav-extra for ubuntu as well?
>>> > Yes, I'll volunteer, but the first thing I would do for ubuntu is a)
>>> > request libav to be demoted back to universe or b) request all of
>>> > libav's build dependencies to be promoted to main.
>>> >
>>> > You think any of these requests would succeed?
>>> libav can be demoted next cycle when KDE gets demoted to universe.
>>>
>>> Micah
>>
>> Great thanks.
>>
>> Reinhard, did you wanted 0.8.1 in precise? Betafreeze is tomorrow.
>
> Thanks for the notice, yes I did, and unfortunately, I'm travelling
> and won't be at home before friday. Could anyone from the team please
> upload 0.8.1 to precise for me before the freeze? Thanks in advance!
>
> --
> regards,
>     Reinhard

I'm not an Ubuntu developer I'm afraid. At best I could have something
ready for someone to review and sponsor for an upload to Ubuntu.

We could always ask for a freeze exception. After all, this new
release brings a lot of security fixes.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658084: libav-extra: Really necessary?

[Andres Mejia]

On Mar 21, 2012 4:40 PM, "Micah Gersten"  wrote:
>
> On 03/21/2012 06:40 AM, Andres Mejia wrote:
> > On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler 
wrote:
> >>
> >> Do you volunteer to do at least the first uploads for libav and
> >> libav-extra for ubuntu as well?
> > Yes, I'll volunteer, but the first thing I would do for ubuntu is a)
> > request libav to be demoted back to universe or b) request all of
> > libav's build dependencies to be promoted to main.
> >
> > You think any of these requests would succeed?
> libav can be demoted next cycle when KDE gets demoted to universe.
>
> Micah

Great thanks.

Reinhard, did you wanted 0.8.1 in precise? Betafreeze is tomorrow.

~ Andres

Bug#658084: libav-extra: Really necessary?

[Andres Mejia]

Alright, going to upload to experimental now.

Bug#658084: libav-extra: Really necessary?

[Andres Mejia]

On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler  wrote:
> On Wed, Mar 21, 2012 at 1:40 AM, Andres Mejia  wrote:
>> Here are some of the comments Reinhard said on IRC. Placing them here
>> for recording purposes.
>>
>> [02:47]  amejia: in the merged case, I think the -dev
>> packages can have tight dependencies on the library packages
>> [02:48]  amejia: also, I think only libavcodec changes, so
>> in that case we'd no longer need to provide e.g. libavutil-extra-51
>> [03:00]  amejia: ultimatively, I think this change goes into
>> the right direction. unfortunately, it wont save a lot of effort,
>> because for ubuntu we'll still need libav-extra and this change needs
>> to be reverted there. at least for now :-(
>>
>> With only libavcodec having an extra package, the other extra packages
>> would need transitional packages. Also, I'm afraid the epoch would
>> need to be bumped again.
>>
>> $ dpkg --compare-versions 4:0.8.1-1 le 4:0.8.1.1 && echo true
>> true
>>
>> I would like to upload a package to experimental soon. Anyone have any
>> other suggestions at this time?
>
> Do you volunteer to do at least the first uploads for libav and
> libav-extra for ubuntu as well?
>
> --
> regards,
>     Reinhard

Yes, I'll volunteer, but the first thing I would do for ubuntu is a)
request libav to be demoted back to universe or b) request all of
libav's build dependencies to be promoted to main.

You think any of these requests would succeed?

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658084: libav-extra: Really necessary?

[Andres Mejia]

Ok, here are the changes to libav to include libav-extra so far. Just
tested these and they provide a smooth upgrade with libav/libav-extra
packages currently in unstable. avconv can use either libavcodec or
libavcodec-extra package and it works like it should. None of the
other packages were necessary as far as I can tell. Also, libav-source
will be dropped.

If nobody has any other suggestions, I would like to upload this to
experimental for further testing.

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#664819: libav source build needs to link with -lgcrypt

[Andres Mejia]

On Tue, Mar 20, 2012 at 9:24 PM, Dave Anglin  wrote:
> Source: libav
> Version: 4:0.8.1-1
> Severity: normal
>
> gcc -Llibavcodec -Llibavdevice -Llibavfilter -Llibavformat -Llibavutil 
> -Llibpostproc -Llibswscale -Wl,--as-needed -Wl,--warn-common 
> -Wl,-rpath-link=libpostproc:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil
>  -o ffmpeg ff
> mpeg.o cmdutils.o -lavdevice -lavfilter -lavformat -lavcodec -lpostproc 
> -lswscale -lavutil -ldl -lX11 -lXext -lXfixes -lcdio_paranoia -lcdio_cdda 
> -lcdio -ljack
> -lasound -ldc1394 -lraw1394 -lxvidcore -lx264 -lvpx -lvpx -lvorbisenc 
> -lvorbis -logg -ltheoraenc -ltheoradec -logg -lspeex -lschroedinger-1.0 
> -lrtmp -lz -lgnutl
> s -lpulse-simple -lpulse -lopenjpeg -lopencv_core -lopencv_imgproc 
> -lopencv_high
> gui -lopencv_ml -lopencv_video -lopencv_features2d -lopencv_calib3d 
> -lopencv_obj
> detect -lopencv_contrib -lopencv_legacy -lopencv_flann -lmp3lame -lgsm 
> -lfreetyp
> e -ldirac_encoder -ldirac_decoder -lstdc++ -lgnutls -lva -lm -pthread -lbz2 
> -lz
> /usr/bin/ld.bfd.real: libavformat/libavformat.a(network.o): undefined 
> reference
> to symbol 'gcry_control@@GCRYPT_1.2'
> /usr/bin/ld.bfd.real: note: 'gcry_control@@GCRYPT_1.2' is defined in DSO 
> /lib/li
> bgcrypt.so.11 so try adding it to the linker command line
> /lib/libgcrypt.so.11: could not read symbols: Invalid operation
> collect2: ld returned 1 exit status
> make[1]: *** [ffmpeg] Error 1
> make[1]: Leaving directory `/home/dave/debian/libav/libav-0.8.1/debian-static'
> make: *** [build-stamp-static] Error 2
>
> The following allows a successful build:
>
> --- rules.save  2012-03-18 14:40:11.0 -0400
> +++ rules       2012-03-20 19:08:22.0 -0400
> @@ -46,6 +46,7 @@
>        dh_testdir
>        mkdir -p debian-$*
>        cd debian-$* && CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" 
> LDFLAGS="$(LDFLAGS)" $(CURDIR)/configure \
> +               --extra-libs=-lgcrypt \
>                $($*_build_confflags) $(extra_$*_build_confflags)
>        touch $@
>
>
>
> -- System Information:
> Debian Release: wheezy/sid
>  APT prefers unreleased
>  APT policy: (500, 'unreleased'), (500, 'unstable')
> Architecture: hppa (parisc64)
>
> Kernel: Linux 3.2.11+ (SMP w/4 CPU cores)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
>
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

libav builds fine. See [1].

This issue is common if you're using the libav-extra libraries. It's
likely a broken symlink from your *.so files.

1. https://buildd.debian.org/status/package.php?p=libav

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658084: libav-extra: Really necessary?

[Andres Mejia]

Here are some of the comments Reinhard said on IRC. Placing them here
for recording purposes.

[02:47]  amejia: in the merged case, I think the -dev
packages can have tight dependencies on the library packages
[02:48]  amejia: also, I think only libavcodec changes, so
in that case we'd no longer need to provide e.g. libavutil-extra-51
[03:00]  amejia: ultimatively, I think this change goes into
the right direction. unfortunately, it wont save a lot of effort,
because for ubuntu we'll still need libav-extra and this change needs
to be reverted there. at least for now :-(

With only libavcodec having an extra package, the other extra packages
would need transitional packages. Also, I'm afraid the epoch would
need to be bumped again.

$ dpkg --compare-versions 4:0.8.1-1 le 4:0.8.1.1 && echo true
true

I would like to upload a package to experimental soon. Anyone have any
other suggestions at this time?

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#664700: libva1: please search dri module in /usr/lib/{/, }dri

[Andres Mejia]

On Mon, Mar 19, 2012 at 9:55 PM, Andres Mejia  wrote:
> On Mon, Mar 19, 2012 at 8:38 PM, Andreas Beckmann  wrote:
>> Package: libva1
>> Version: 1.0.15-4
>> Severity: normal
>>
>> Hi,
>>
>> please use a search path for the DRI modules that contains both
>>  /usr/lib//dri
>>  /usr/lib/dri
>> While we can (hopefully) fix the Debian packages to ship the files in
>> the multiarch locations, the multiarch move "breaks" any third-party
>> (probably proprietary) software/installer/... that is not multiarch
>> aware. Therefore "plugins" should be searched in both locations.
>>
>> So far the following problems have been reported:
>>
>> xvba-va:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664487
>>
>> fglrx + vainfo:
>>
>> $ vainfo
>> libva: VA-API version 0.32.0
>> Xlib:  extension "XFree86-DRI" missing on display ":0".
>> libva: va_getDriverName() returns 0
>> libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so
>> libva: va_openDriver() returns -1
>> vaInitialize failed with error code -1 (unknown libva error),exit
>>
>> I'm not sure if I can move dri/fglrx_drv_video.so around - it is loaded
>> from the fglrx driver (a non-free blob) using the hardcoded path
>> /usr/lib/dri ... (and the last time I tried to use symlinks (although in
>> a different context) the fglrx blob used lstat() and complained about
>> world writable files ...)
>>
>>
>> Andreas
>>
>>
>>
>> ___
>> pkg-multimedia-maintainers mailing list
>> pkg-multimedia-maintain...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
>
> I don't believe modules should be allowed to load from /usr/lib/dri in
> a multiarch library. Suppose the amd64 library package is loaded into
> an i386 machine, and the module is i386 and installed in /usr/lib/dri.
> This configuration may cause breakage. I'm afraid the module has to be
> fixed, even if it's a proprietary module.
>
> --
> ~ Andres

I looked into this some more. NVIDIA's vdpau driver doesn't show a
problem with the modules being installed in
/usr/lib/x86_64-linux-gnu/vdpau. vainfo is working fine for me (after
fixing some issues with the vdpau-va-driver which I just uploaded).

$ vainfo
libva: VA-API version 0.32.0
Xlib:  extension "XFree86-DRI" missing on display ":0".
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
libva: va_openDriver() returns 0
vainfo: VA-API version: 0.32 (libva 1.0.15)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for
VA-API - 0.7.3
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointVLD
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD

Also, I checked the code that sets the module directory for both
libvdpau and libva. Only one path is set for both libraries and it is
based off of $libdir variable from their build systems. With
multiarch, each library sets the module path to /usr/lib//*.

With this information, I believe the fglrx driver should be fixed.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#664700: libva1: please search dri module in /usr/lib/{/, }dri

[Andres Mejia]

On Mon, Mar 19, 2012 at 8:38 PM, Andreas Beckmann  wrote:
> Package: libva1
> Version: 1.0.15-4
> Severity: normal
>
> Hi,
>
> please use a search path for the DRI modules that contains both
>  /usr/lib//dri
>  /usr/lib/dri
> While we can (hopefully) fix the Debian packages to ship the files in
> the multiarch locations, the multiarch move "breaks" any third-party
> (probably proprietary) software/installer/... that is not multiarch
> aware. Therefore "plugins" should be searched in both locations.
>
> So far the following problems have been reported:
>
> xvba-va:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664487
>
> fglrx + vainfo:
>
> $ vainfo
> libva: VA-API version 0.32.0
> Xlib:  extension "XFree86-DRI" missing on display ":0".
> libva: va_getDriverName() returns 0
> libva: Trying to open /usr/lib/x86_64-linux-gnu/dri/fglrx_drv_video.so
> libva: va_openDriver() returns -1
> vaInitialize failed with error code -1 (unknown libva error),exit
>
> I'm not sure if I can move dri/fglrx_drv_video.so around - it is loaded
> from the fglrx driver (a non-free blob) using the hardcoded path
> /usr/lib/dri ... (and the last time I tried to use symlinks (although in
> a different context) the fglrx blob used lstat() and complained about
> world writable files ...)
>
>
> Andreas
>
>
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

I don't believe modules should be allowed to load from /usr/lib/dri in
a multiarch library. Suppose the amd64 library package is loaded into
an i386 machine, and the module is i386 and installed in /usr/lib/dri.
This configuration may cause breakage. I'm afraid the module has to be
fixed, even if it's a proprietary module.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658084: libav-extra: Really necessary?

[Andres Mejia]

On Mon, Mar 19, 2012 at 9:52 AM, Fabian Greffrath  wrote:
> Am 19.03.2012 14:38, schrieb Andres Mejia:
>
>> I made the changes to filter out building of static libs for extra
>> packages. See [1]. Note that I rebased the changes from current
>> master, so if you checked out this branch, you'll have to merge the
>> changes back in.
>
>
> Alright. In this context, has someone lately tried out if the static libs
> that we provide in the -dev packages work at all?

Yes, and they do.

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658084: libav-extra: Really necessary?

[Andres Mejia]

On Mon, Mar 19, 2012 at 7:25 AM, Fabian Greffrath  wrote:
> Am 19.03.2012 10:25, schrieb Fabian Greffrath:
>
>> I generally agree with your proposal, although "easier and less
>> error-prone" is in the eye of the beholder, of course. At least I am
>> currently a bit lost in your proposed diff against debian/rules. ;)
>
>
> Furthermore, I think the additional debian/lib*-extra.copyright files, since
> they are all identical, should get created per package from a
> debian/copyright-extra.in template file and removed in the clean rule.
>
>  - Fabian

I made the changes to filter out building of static libs for extra
packages. See [1]. Note that I rebased the changes from current
master, so if you checked out this branch, you'll have to merge the
changes back in.

About the copyright files, I'm not sure, but it seems debhelper is
ignoring the installation of the per package *.copyright files unless
they are in the debian directory at the start of a build. I'll look
into this later.

1. 
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=shortlog;h=refs/heads/libav-extra

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658084: libav-extra: Really necessary?

[Andres Mejia]

On Mon, Mar 19, 2012 at 9:14 AM, Jonas Smedegaard  wrote:
> On 12-03-19 at 08:59am, Andres Mejia wrote:
>> On Mon, Mar 19, 2012 at 5:25 AM, Fabian Greffrath
>>  wrote:
>> > Am 19.03.2012 03:59, schrieb Andres Mejia:
>> >
>> >> Though the build time is increased for libav, ultimately, this
>> >> change would be better as the buildd network would not have to cope
>> >> with building from two source packages (i.e. setting up and tearing
>> >> down for libav and libav-extra for each architecture). Also, in my
>> >> opinion, it is easier and less error prone to maintain a single
>> >> libav package rather than two of them.
>> >
>> >
>> > I generally agree with your proposal, although "easier and less
>> > error-prone" is in the eye of the beholder, of course. At least I am
>> > currently a bit lost in your proposed diff against debian/rules. ;)
>> >
>> > In this context, please remove the libav-source binary package as
>> > well. It is of no further use (that I know of) if the libav-extra
>> > source package is removed. Also, please make sure that only the
>> > dynamic libraries are rebuilt for the extra packages, not the static
>> > one (don't know if it is already like this; as I said, the diff is a
>> > bit too much for me on a Monday morning ;) ).
>
>> I think the libav-source package will still be useful. There are
>> people who like to activate/deactivate certain features of libav. They
>> can use the libav-source package and ensure they have a build with all
>> the patches applied for the Debian builds of libav.
>
> I disagree: That argument would apply for *any* package in Debian.
>
> Binary packages containing sources is a special construct specifically
> for our build system, not needed for direct exposure to our users: Users
> who want to recompile packages can much easier do so by forking the
> source package.
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

Yes, after thinking about it, I was going to draw the same conclusion.
Since the libav-extra package would no longer be needed, the
libav-source package should go away. Users needing a different
installation of libav libs can simply download the source package and
recompile with whatever options they needed.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658084: libav-extra: Really necessary?

[Andres Mejia]

On Mon, Mar 19, 2012 at 5:25 AM, Fabian Greffrath  wrote:
> Am 19.03.2012 03:59, schrieb Andres Mejia:
>
>> Though the build time is increased for libav, ultimately, this change
>> would be better as the buildd network would not have to cope with
>> building from two source packages (i.e. setting up and tearing down
>> for libav and libav-extra for each architecture). Also, in my opinion,
>> it is easier and less error prone to maintain a single libav package
>> rather than two of them.
>
>
> I generally agree with your proposal, although "easier and less error-prone"
> is in the eye of the beholder, of course. At least I am currently a bit lost
> in your proposed diff against debian/rules. ;)
>
> In this context, please remove the libav-source binary package as well. It
> is of no further use (that I know of) if the libav-extra source package is
> removed. Also, please make sure that only the dynamic libraries are rebuilt
> for the extra packages, not the static one (don't know if it is already like
> this; as I said, the diff is a bit too much for me on a Monday morning ;) ).
>
>  - Fabian

I think the libav-source package will still be useful. There are
people who like to activate/deactivate certain features of libav. They
can use the libav-source package and ensure they have a build with all
the patches applied for the Debian builds of libav.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658084: libav-extra: Really necessary?

[Andres Mejia]

Here is what I propose in order to provide the lib*extra* packages
from the libav source package. [1] It essentially has libav building
the extra packages, thus no longer having to rely on a seperate source
package. This change ensures the regular and the extra packages are
built for all 'flavors' to be built depending on the architecture.

As I said before, as far as building the GPLv3 enabled libraries,
there is no reason to do that with a seperate source package. Building
them separately would not change the fact that the packages are
ultimately distributed through Debian main. The source package will
remain LGPLv2.1+. The binaries will be GPLv2+ for the regular
packages, and GPLv3+ for the extra packages.

Though the build time is increased for libav, ultimately, this change
would be better as the buildd network would not have to cope with
building from two source packages (i.e. setting up and tearing down
for libav and libav-extra for each architecture). Also, in my opinion,
it is easier and less error prone to maintain a single libav package
rather than two of them.

1. 
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=commitdiff;h=3037cab27717de75a73c77a553ab6dfad04a57da;hp=d78d2e6d0d0f43a6203ee6b78a8c0fefcab7838a

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#664541: override: vainfo:utils/optional

[Andres Mejia]

Package: ftp.debian.org
Severity: normal

The override file needs to be updated for vainfo.

vainfo_1.0.15-4_amd64.deb: package says section is utils, override says libs.

vainfo is a utility program, not a library.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#664537: override: vo-amrwbenc binary packages

[Andres Mejia]

Package: ftp.debian.org
Severity: normal

The override file needs to be updated for the following packages.

libvo-amrwbenc-dev_0.1.2-1_amd64.deb: package says priority is optional, 
override says extra.
libvo-amrwbenc0_0.1.2-1_amd64.deb: package says priority is optional, override 
says extra.

These packages should be Priority:optional. There is nothing particularly
special about them. They don't require a specific system setup or special
knowledge in order to use them or develop with them.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#664536: override: vo-aacenc0 binary packages

[Andres Mejia]

Package: ftp.debian.org
Severity: normal

The override file needs to be updated for the following packages.

libvo-aacenc-dev_0.1.2-1_amd64.deb: package says priority is optional, override 
says extra.
libvo-aacenc0_0.1.2-1_amd64.deb: package says priority is optional, override 
says extra.

These packages should be Priority:optional. These packages can reasonably be
used by anyone and don't require any specific setup or knowledge to use them
or develop with them.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#664535: override: intel-vaapi-driver binary packages

[Andres Mejia]

Package: ftp.debian.org
Severity: normal

The override file needs to be updated for the following packages.

i965-va-driver_1.0.16-1_all.deb: package says section is oldlibs, override says 
libs.
i965-va-driver_1.0.16-1_all.deb: package says priority is extra, override says 
optional.
This is now a transitional package. It should be oldlibs/extra.

libva-intel-vaapi-driver_1.0.16-1_amd64.deb: package says priority is optional, 
override says extra.
This is the new name for the libva VAAPI Intel driver package. It should be
priority optional.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#662716: reveal log files

[Andres Mejia]

On Fri, Mar 9, 2012 at 12:34 PM, Savvas Radevic  wrote:
>> I rather have a patch to libarchive's build system that sets '-v'
>> option for all test programs.
>
>
> I'll read the code and see if I can come up with something.
>
>>
>> Also, next time, please don't include unrelated changes in your
>> patches (I'm referring to the use of '-').
>
>
> '-' ignores the exit status, that was deliberately put there - I thought
> that the dh_auto_test returns an exit code 2, e.g. the mipsel build:
> https://buildd.debian.org/status/fetch.php?pkg=libarchive&arch=mipsel&ver=3.0.3-6&stamp=1330969393
>
> =
> make[4]: *** [check-TESTS] Error 1
> 1 of 3 tests failed
> Please report to kient...@freebsd.org
> =
> make[4]: Leaving directory
> `/build/buildd-libarchive_3.0.3-6-mipsel-znTD6e/libarchive-3.0.3'
> make[3]: *** [check-am] Error 2
> make[3]: Leaving directory
> `/build/buildd-libarchive_3.0.3-6-mipsel-znTD6e/libarchive-3.0.3'
> make[2]: *** [check] Error 2
> make[2]: Leaving directory
> `/build/buildd-libarchive_3.0.3-6-mipsel-znTD6e/libarchive-3.0.3'
> dh_auto_test: make -j2 check returned exit code 2
> make[1]: *** [override_dh_auto_test] Error 29
> make[1]: Leaving directory
> `/build/buildd-libarchive_3.0.3-6-mipsel-znTD6e/libarchive-3.0.3'
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
> If the tests fail, it won't execute the commands that follow after
> dh_auto_test.
> Another example:
>
> $ cat Makefile
> test:
>     exit 2
>     echo "hello world"
>
> $ make -f Makefile test
> exit 2
> make: *** [test] Error 2

The exit status should not be ignored. In the above case, I would have preferred
$ test dh_auto_test --parallel || ...do something here...

In any case, I prefer something to the build system that optionally
passes '-v' to the test programs. If you are going to come up with
something, note that libarchive can use two build systems, autotools
and cmake.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#659650: [libarchive-dev] please include examples

[Andres Mejia]

tags 659650 wontfix
stop

On Sun, Feb 12, 2012 at 3:34 PM, Filipus Klutiero  wrote:
> Package: libarchive-dev
> Version: 3.0.3-3
> Severity: wishlist
>
> There are some libarchive examples in examples/ and on
> https://github.com/libarchive/libarchive/wiki/Examples
> Please include some

I believe the wiki page you mentioned and the test cases in the source
tarball provide enough examples. I would rather not bloat any of the
existing packages with examples, nor create another package solely for
installation of examples.

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#662716: reveal log files

[Andres Mejia]

On Mon, Mar 5, 2012 at 6:09 PM, Savvas Radevic  wrote:
> Package: libarchive
> Severity: wishlist
>
> This patch should reveal log files if any tests fail.
> Bad side is that it doesn't fail the build if tests fail.
> I tried to use $$? to check the exit status of dh_auto_test
> and fail after showing the log files, but couldn't make it
> work. Looks like gnu make doesn't support $$?
>
> If you have a better idea to make it fail *after* showing the
> log files, please apply it. It would be much better to see why
> the errors fail directly in the buildd logs. :)
>
> -- System Information:
> Debian Release: wheezy/sid
>  APT prefers oneiric-updates
>  APT policy: (500, 'oneiric-updates'), (500, 'oneiric-security'), (500, 
> 'oneiric'), (100, 'oneiric-backports')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.0.0-16-generic (SMP w/2 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash

I rather have a patch to libarchive's build system that sets '-v'
option for all test programs.

Also, next time, please don't include unrelated changes in your
patches (I'm referring to the use of '-').

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#663021: RFP: BridJ -- Java / native interoperability library

[Andres Mejia]

Package: wnpp
Severity: wishlist

* Package name: bridj
  Version : 0.6
  Upstream Author : Olivier Chafik
* URL : http://code.google.com/p/bridj/
* License : BSD
  Programming Lang: C, C++, Objective C, C#, Java
  Description : Java / native interoperability library

BridJ is an interoperability library used in making native calls to C, C++, and
COM libraries. BridJ was written from scratch to replace JNA, with performance
and usability as golden objectives.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#663020: RFP: JNAerator -- parses C/C++/Obj-C headers and generates BridJ/JNA/Rococoa Java interfaces

[Andres Mejia]

Package: wnpp
Severity: wishlist

* Package name: jnaerator
  Version : 0.9.10-SNAPSHOT 20120306
  Upstream Author : Olivier Chafik
* URL : http://code.google.com/p/jnaerator/
* License : LGPL
  Programming Lang: C, C++, Objective C, Java
  Description : parses C/C++/Obj-C headers and generates BridJ/JNA/Rococoa 
Java interfaces

JNAerator is a utility that can parse C, C++, and Objective C headers and
generate a corresponding BridJ, JNA, and Rococoa Java interace for use in making
native calls to shared libraries from Java.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#662725: cgal: CGAL 4.0 Beta 1 Released

[Andres Mejia]

Package: cgal
Severity: wishlist

A beta for the upcoming release of CGAL has been released. Though it's a beta,
the new release will be released under the terms of the LGPLv3+ and GPLv3+. It
would be worthwhile to prepare for the upcoming release by uploading to
experimental to let others start testing with the new release.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#658335: Fwd: Bug#658335: [firmware-crystalhd] Firmware image signature failure

[Andres Mejia]

Hi,
I'm the maintainer of the crystalhd packages in Debian. There's a user
that reported the below issue. Do you have any suggestions on what he
may try?

I'm not sure about any mismatch. The crystalhd library and firmware
packages were built from the same git snapshot (repo:
http://git.linuxtv.org/jarod/crystalhd.git, commit:
fdd2f19ac739a3db1fd7469ea19ceaefe0822e5a).

When you reply, please preserve the CC field.


-- Forwarded message --
From: Tim Sattarov 
Date: Wed, Feb 1, 2012 at 10:22 PM
Subject: Bug#658335: [firmware-crystalhd] Firmware image signature failure
To: sub...@bugs.debian.org


Package: firmware-crystalhd
Version: 0.0~git20120110.fdd2f19-1
Severity: grave

--- Please enter the report below this line. ---
Hello,

I'm trying to use my Broadcom HW decoder bcm70015

here is lspci output
04:00.0 Multimedia controller: Broadcom Corporation BCM70015 Video
Decoder [Crystal HD]

driver compiles but every time I start video application (xbmc or
totem) I'm getting these messages in dmesg

[ 5503.584187] Loading crystalhd v3.10.0
[ 5503.584345] crystalhd :04:00.0: Starting Device:0x1615
[ 5503.584430] crystalhd :04:00.0: PCI INT A -> GSI 19 (level,
low) -> IRQ 19
[ 5503.595602] crystalhd :04:00.0: irq 47 for MSI/MSI-X
[ 5503.668241] crystalhd :04:00.0: setting latency timer to 64
[ 5527.782089] crystalhd :04:00.0: Opening new user[0] handle
[ 5527.852226] crystalhd :04:00.0: Closing user[0] handle with mode 
[ 5734.101508] crystalhd :04:00.0: Opening new user[0] handle
[ 5734.172146] crystalhd :04:00.0: Closing user[0] handle with mode 
[ 5734.210614] crystalhd :04:00.0: Opening new user[0] handle
[ 5734.280237] crystalhd :04:00.0: Closing user[0] handle with mode 
[ 5734.317633] crystalhd :04:00.0: Opening new user[0] handle
[ 5734.668199] crystalhd :04:00.0: [crystalhd_flea_download_fw]:
step 7. Error bit occured. RetVal:c00018
[ 5734.668226] crystalhd :04:00.0: [crystalhd_flea_download_fw]:
step 7. Firmware image signature failure.
[ 5734.668242] crystalhd :04:00.0: Firmware Download Failure!! - -1
[ 5734.784736] crystalhd :04:00.0: Closing user[0] handle via
ioctl with mode 1c200

and crystalhd is not used at all.
Google says - firmware version does not match driver version.
Any ideas how to make it work ?

Thanks
Tim

--- System information. ---
Architecture: i386
Kernel: Linux 3.2.0-1-686-pae

Debian Release: wheezy/sid
500 unstable www.debian-multimedia.org
500 unstable http.us.debian.org
1 experimental http.us.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Suggests (Version) | Installed
==-+-===
initramfs-tools | 0.99
linux-image |




-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#659294: Fwd: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)

[Andres Mejia]

On Feb 23, 2012 2:12 AM, "Philipp Kern"  wrote:
>
> On Wed, Feb 22, 2012 at 08:37:38PM -0500, Andres Mejia wrote:
> > The issue is resolved for s390 but not for s390x. I see there's no
> > porterbox available for s390x so I won't be able to help out much with
> > the test suite failure in s390x.
>
> Chroot sid_s390x on zelenka.
>
> Kind regards
> Philipp Kern

The locales package wasn't installed. Otherwise, libarchive passes the test
suite on s390x as well.

~ Andres

Bug#659294: libarchive: FTBFS on various architectures (mipsel, s390x)

[Andres Mejia]

severity 659294 important
stop

Downgrading the severity to important since libarchive builds and
passes the test suite on the eder porterbox used for mipsel and since
there's no porterbox available for s390x.

~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#659294: Fwd: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)

[Andres Mejia]

Ok. I see the eder.debian.org porterbox had libarchive's build
dependencies installed. I built and ran the test suite several times
for mipsel and it passes every time. I even ran the
test_read_disk_directory_traversals test about 300 times in a row
using a while loop trying to reproduce the build failure. It builds
just fine on eder.

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#659294: Fwd: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)

[Andres Mejia]

On Sat, Feb 11, 2012 at 6:00 AM, Philipp Kern  wrote:
> On Fri, Feb 10, 2012 at 04:34:40PM -0500, Andres Mejia wrote:
>> Hi. The new version of libarchive uploaded to unstable is failing the
>> test suite (and thus failing to build the deb packages). We're going
>> to need copies of the test directories from the test suites, e.g.,
>> >>  Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000
>> Please provide these test directories to libarchive-disc...@googlegroups.com.
>
> For s390(x) you can just use the porter box zelenka.  The build-deps are
> installed.  For the other porterboxes you might need to mail the admin list to
> get them installed.
>
> Kind regards,
> Philipp Kern
> --
>  .''`.  Philipp Kern                        Debian Developer
> : :' :  http://philkern.de                         Stable Release Manager
> `. `'   xmpp:p...@0x539.de                         Wanna-Build Admin
>  `-    finger pkern/k...@db.debian.org
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEAREIAAYFAk82SjsACgkQ7Ro5M7LPzdgQmwCgmaFOa/zkrHa7KEeeG0eLWo7k
> zKoAn0UzCeZ5fGbfphgtZdHFARD7/aVC
> =mORi
> -END PGP SIGNATURE-
>

The issue is resolved for s390 but not for s390x. I see there's no
porterbox available for s390x so I won't be able to help out much with
the test suite failure in s390x.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#659294: Help resolving libarchive test suite failure for mipsel

[Andres Mejia]

Hi. I need a little help in resolving the test suite failure of
libarchive for mipsel (see bug #659294). Could someone please install
libarchive's build dependencies on one of the mipsel porter boxes so I
can attempt to resolve the issue.

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)

[Andres Mejia]

On Feb 22, 2012 12:45 AM, "Tim Kientzle"  wrote:
>
>
> On Feb 21, 2012, at 3:40 AM, Pino Toscano wrote:
>
> > Hi,
> >
> > (greetings from your favourite Hurd porter)
> >
> > Alle lunedì 13 febbraio 2012, Tim Kientzle ha scritto:
> >> So on hurd, I see a couple of interesting failures for bsdtar:
> >> [...]
> >
> > Actually, libarchive is pretty fine on Hurd, as it was after I fixed
> > libarchove 3.0.2 (and in 3.0.3 there are no changes leading to issues).
> >
> > The problem is that the test suite run (just like the whole package
> > build) is done within fakeroot (which means fakeroot-tcp), triggering
> > Debian's #534879.
>
> Thanks, Pino.
>
> Libarchive's test suite does a lot of file operations, including
> a lot of cross-checks of file modes, ownership, and other
> properties.
>
> The races described in #534789 would likely manifest
> as essentially random failures in libarchive's test suite.
>
> Tim
>

Ok, resolved the issue on hurd. Now that leaves the issues on mipsel and
s390x which don't seem random.

~ Andres

Bug#659294: Fwd: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)

[Andres Mejia]

Hi. The new version of libarchive uploaded to unstable is failing the
test suite (and thus failing to build the deb packages). We're going
to need copies of the test directories from the test suites, e.g.,

>>  Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000

Please provide these test directories to libarchive-disc...@googlegroups.com.

-- Forwarded message --
From: Tim Kientzle 
Date: Thu, Feb 9, 2012 at 11:15 PM
Subject: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive:
FTBFS on various architectures (hurd, mipsel, s390, s390x)
To: libarchive-disc...@googlegroups.com
Cc: 659294-forwar...@bugs.debian.org, 659...@bugs.debian.org, Julien
Cristau 


Each of these reports includes the name of the test directory, e.g.,

>>  Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000

Can we get the contents of those directories (which include detailed
logs for each failure, the files involved, and other details)?

Tim


On Feb 9, 2012, at 4:20 PM, Andres Mejia wrote:

> There are some build failures on various architectures in Debian. Note
> that they're failures in the test suite.
>
>
> -- Forwarded message --
> From: Julien Cristau 
> Date: Thu, Feb 9, 2012 at 5:52 PM
> Subject: Bug#659294: libarchive: FTBFS on various architectures (hurd,
> mipsel, s390, s390x)
> To: Debian Bug Tracking System 
>
>
> Source: libarchive
> Version: 3.0.3-3
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> libarchive FTBFS on various buildds, with test failures:
> https://buildd.debian.org/status/package.php?p=libarchive
>
> mipsel:
>>  Totals:
>>    Tests run:              172
>>    Tests failed:             1
>>    Assertions checked:12407225
>>    Assertions failed:        3
>>    Skips reported:          73
>>
>>  Failing tests:
>>    60: test_read_disk_directory_traversals (3 failures)
>>
>>  Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000
>>
>>  FAIL: libarchive_test
>
> s390:
>>  Totals:
>>    Tests run:              172
>>    Tests failed:             1
>>    Assertions checked:12407234
>>    Assertions failed:        3
>>    Skips reported:          73
>>
>>  Failing tests:
>>    60: test_read_disk_directory_traversals (3 failures)
>>
>>  Details for failing tests: /tmp/libarchive_test.2012-02-06T22.43.00-000
>>
>>  FAIL: libarchive_test
>
> s390x:
>>  Totals:
>>    Tests run:               31
>>    Tests failed:             1
>>    Assertions checked:    7460
>>    Assertions failed:        2
>>    Skips reported:           1
>>
>>  Failing tests:
>>    13: test_option_b (2 failures)
>>
>>  Details for failing tests: /tmp/bsdtar_test.2012-02-06T22.40.24-000
>>
>>  FAIL: bsdtar_test
>
> hurd-i386:
>>  Totals:
>>    Tests run:               31
>>    Tests failed:             2
>>    Assertions checked:    7459
>>    Assertions failed:        3
>>    Skips reported:           1
>>
>>  Failing tests:
>>    7: test_option_H_upper (1 failures)
>>    8: test_option_L_upper (2 failures)
>>
>>  Details for failing tests: /tmp/bsdtar_test.2012-02-07T00.14.52-000
>>
>>  FAIL: bsdtar_test
>>
>>  [...]
>>
>>  Totals:
>>    Tests run:               28
>>    Tests failed:             2
>>    Assertions checked:     923
>>    Assertions failed:       14
>>    Skips reported:           1
>>
>>  Failing tests:
>>    1: test_basic (13 failures)
>>    26: test_passthrough_reverse (1 failures)
>>
>>  Details for failing tests: /tmp/bsdcpio_test.2012-02-07T00.22.32-000
>>
>>  FAIL: bsdcpio_test
>
> Cheers,
> Julien
>
>
> --
> ~ Andres
>
> --
> You received this message because you are subscribed to the Google Groups 
> "libarchive-discuss" group.
> To post to this group, send email to libarchive-disc...@googlegroups.com.
> To unsubscribe from this group, send email to 
> libarchive-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/libarchive-discuss?hl=en.
>
>
>





-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#659294: Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)

[Andres Mejia]

There are some build failures on various architectures in Debian. Note
that they're failures in the test suite.


-- Forwarded message --
From: Julien Cristau 
Date: Thu, Feb 9, 2012 at 5:52 PM
Subject: Bug#659294: libarchive: FTBFS on various architectures (hurd,
mipsel, s390, s390x)
To: Debian Bug Tracking System 


Source: libarchive
Version: 3.0.3-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

libarchive FTBFS on various buildds, with test failures:
https://buildd.debian.org/status/package.php?p=libarchive

mipsel:
>  Totals:
>    Tests run:              172
>    Tests failed:             1
>    Assertions checked:12407225
>    Assertions failed:        3
>    Skips reported:          73
>
>  Failing tests:
>    60: test_read_disk_directory_traversals (3 failures)
>
>  Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000
>
>  FAIL: libarchive_test

s390:
>  Totals:
>    Tests run:              172
>    Tests failed:             1
>    Assertions checked:12407234
>    Assertions failed:        3
>    Skips reported:          73
>
>  Failing tests:
>    60: test_read_disk_directory_traversals (3 failures)
>
>  Details for failing tests: /tmp/libarchive_test.2012-02-06T22.43.00-000
>
>  FAIL: libarchive_test

s390x:
>  Totals:
>    Tests run:               31
>    Tests failed:             1
>    Assertions checked:    7460
>    Assertions failed:        2
>    Skips reported:           1
>
>  Failing tests:
>    13: test_option_b (2 failures)
>
>  Details for failing tests: /tmp/bsdtar_test.2012-02-06T22.40.24-000
>
>  FAIL: bsdtar_test

hurd-i386:
>  Totals:
>    Tests run:               31
>    Tests failed:             2
>    Assertions checked:    7459
>    Assertions failed:        3
>    Skips reported:           1
>
>  Failing tests:
>    7: test_option_H_upper (1 failures)
>    8: test_option_L_upper (2 failures)
>
>  Details for failing tests: /tmp/bsdtar_test.2012-02-07T00.14.52-000
>
>  FAIL: bsdtar_test
>
>  [...]
>
>  Totals:
>    Tests run:               28
>    Tests failed:             2
>    Assertions checked:     923
>    Assertions failed:       14
>    Skips reported:           1
>
>  Failing tests:
>    1: test_basic (13 failures)
>    26: test_passthrough_reverse (1 failures)
>
>  Details for failing tests: /tmp/bsdcpio_test.2012-02-07T00.22.32-000
>
>  FAIL: bsdcpio_test

Cheers,
Julien


-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)

[Andres Mejia]

tags 659294 help
stop

On Thu, Feb 9, 2012 at 5:52 PM, Julien Cristau  wrote:
> Source: libarchive
> Version: 3.0.3-3
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> libarchive FTBFS on various buildds, with test failures:
> https://buildd.debian.org/status/package.php?p=libarchive
>
> mipsel:
>>  Totals:
>>    Tests run:              172
>>    Tests failed:             1
>>    Assertions checked:12407225
>>    Assertions failed:        3
>>    Skips reported:          73
>>
>>  Failing tests:
>>    60: test_read_disk_directory_traversals (3 failures)
>>
>>  Details for failing tests: /tmp/libarchive_test.2012-02-06T23.02.12-000
>>
>>  FAIL: libarchive_test
>
> s390:
>>  Totals:
>>    Tests run:              172
>>    Tests failed:             1
>>    Assertions checked:12407234
>>    Assertions failed:        3
>>    Skips reported:          73
>>
>>  Failing tests:
>>    60: test_read_disk_directory_traversals (3 failures)
>>
>>  Details for failing tests: /tmp/libarchive_test.2012-02-06T22.43.00-000
>>
>>  FAIL: libarchive_test
>
> s390x:
>>  Totals:
>>    Tests run:               31
>>    Tests failed:             1
>>    Assertions checked:    7460
>>    Assertions failed:        2
>>    Skips reported:           1
>>
>>  Failing tests:
>>    13: test_option_b (2 failures)
>>
>>  Details for failing tests: /tmp/bsdtar_test.2012-02-06T22.40.24-000
>>
>>  FAIL: bsdtar_test
>
> hurd-i386:
>>  Totals:
>>    Tests run:               31
>>    Tests failed:             2
>>    Assertions checked:    7459
>>    Assertions failed:        3
>>    Skips reported:           1
>>
>>  Failing tests:
>>    7: test_option_H_upper (1 failures)
>>    8: test_option_L_upper (2 failures)
>>
>>  Details for failing tests: /tmp/bsdtar_test.2012-02-07T00.14.52-000
>>
>>  FAIL: bsdtar_test
>>
>>  [...]
>>
>>  Totals:
>>    Tests run:               28
>>    Tests failed:             2
>>    Assertions checked:     923
>>    Assertions failed:       14
>>    Skips reported:           1
>>
>>  Failing tests:
>>    1: test_basic (13 failures)
>>    26: test_passthrough_reverse (1 failures)
>>
>>  Details for failing tests: /tmp/bsdcpio_test.2012-02-07T00.22.32-000
>>
>>  FAIL: bsdcpio_test
>
> Cheers,
> Julien

Note that this time, I'm expecting the test suite to pass for all
architectures. It has failed the test suite in the previous version,
though test suite failures had been ignored.

I'm going to need some help resolving this issue on these
architectures. Patches welcome, even if they're against the test
suite.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#659165: libbluray-dev: please review need for -dev package to depend on libbluray-bdj

[Andres Mejia]

On Wed, Feb 8, 2012 at 4:16 PM, Alessio Treglia  wrote:
> tags 659165 patch
> thanks
>
> Hi all!
>
> On Wed, Feb 8, 2012 at 9:59 PM, Neil Williams  wrote:
>> Trying to build xine-lib-1.2 in a clean chroot wiht Recommends turned off 
>> results
>> in a lot of java packages being included as build-dependencies. This doesn't 
>> make
>> a lot of sense.
>>
>> The problem comes down to libbluray-dev which depends on libbluray-bdj.
>
> That's my proposal:
>
> diff --git a/debian/control b/debian/control
> index 87acaf6..e57ffdd 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -23,11 +23,26 @@ Homepage: 
> http://www.videolan.org/developers/libbluray.html
>  Vcs-Git: git://git.debian.org/git/pkg-multimedia/libbluray.git
>  Vcs-Browser: http://git.debian.org/?p=pkg-multimedia/libbluray.git;a=summary
>
> +Package: bluray-dev
> +Architecture: all
> +Section: libdevel
> +Depends: libbluray-dev (>= ${source:Version}),
> +         libbluray-dev (<< ${source:Version}+1~),
> +         libbluray-bdj (>= ${source:Version}),
> +         libbluray-bdj (<< ${source:Version}+1~),
> +Description: Blu-ray disc playback support (development files)
> + libbluray is an open-source library designed for Blu-Ray Discs playback for
> + media players, like VLC or MPlayer. This research project is developed by an
> + international team of developers from Doom9. libbluray integrates 
> navigation,
> + playlist parsing, menus, and BD-J.
> + .
> + This package provides all the necessary files needed for development,
> + also including the BD-J library.
> +
>  Package: libbluray-dev
>  Architecture: any
>  Section: libdevel
>  Depends: libbluray1 (= ${binary:Version}),
> -         libbluray-bdj (= ${source:Version}),
>          ${misc:Depends}
>  Description: Blu-ray disc playback support library (development files)
>  libbluray is an open-source library designed for Blu-Ray Discs playback for
> @@ -38,7 +53,8 @@ Description: Blu-ray disc playback support library 
> (development files)
>  NB: Most commercial Blu-Ray are restricted by AACS or BD+ technologies and 
> this
>  library is not enough to playback those discs.
>  .
> - This package provides the necessary files needed for development.
> + This package provides the necessary files needed for compiling program 
> against
> + libbluray.
>
>  Package: libbluray1
>  Architecture: any
>
> -
>
> Any feedback is welcome!
>
> --
> Alessio Treglia          | www.alessiotreglia.com
> Debian Developer         | ales...@debian.org
> Ubuntu Core Developer    | quadris...@ubuntu.com
> 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A
>
>
>
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

There's no need for the extra 'bluray-dev' package. Users needing
libbluray-bdj can just build-depend on the package.

-- 
~ Andres



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#653195: transition: libarchive

[Andres Mejia]

I haven't seen any activity with evolution 3.2 / libgdata 0.10
transition. Should the transition of libarchive still wait?

-- 
~ Andres



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#656173: piuparts: Add --dpkg-force-yes option to allow upstart to uninstall sysvinit

[Andres Mejia]

Package: piuparts
Version: 0.42
Severity: normal

There should be an option to allow --force-yes to be used to allow upstart to
remove sysvinit. This is needed since sysvinit is an essential package.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages piuparts depends on:
ii  apt   0.8.15.9
ii  debootstrap   1.0.38
ii  lsb-release   3.2-28
ii  lsof  4.81.dfsg.1-1
ii  python2.7.2-9
ii  python-apt0.8.3
ii  python-debian 0.1.21
ii  python-debianbts  1.10
ii  python2.6 2.6.7-4
ii  python2.7 2.7.2-12

piuparts recommends no packages.

Versions of packages piuparts suggests:
pn  ghostscript  9.04~dfsg-3
pn  python-rpy   

-- no debconf information
0m0.0s INFO: 
--
0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of 
this logfile.
0m0.0s INFO: FAQ available at http://wiki.debian.org/piuparts/FAQ
0m0.0s INFO: 
--
0m0.0s INFO: piuparts version 0.42 starting up.
0m0.0s INFO: Command line arguments: /usr/sbin/piuparts -b 
/var/lib/sbuild/sid-amd64.tar.gz -l xbmc-piuparts.log 
xbmc_11.0~git20120116.0cae44d-1_all.deb 
xbmc-bin_11.0~git20120116.0cae44d-1_amd64.deb 
xbmc-live_11.0~git20120116.0cae44d-1_all.deb
0m0.0s INFO: Running on: Linux debian 3.1.0-1-amd64 #1 SMP Tue Jan 10 05:01:58 
UTC 2012 x86_64
0m0.0s DEBUG: Starting command: ['dpkg', '--info', 
'xbmc_11.0~git20120116.0cae44d-1_all.deb']
0m0.0s DUMP: 
   new debian package, version 2.0.
   size 22240588 bytes: control archive= 28173 bytes.
  1909 bytes,34 lines  control  
 95756 bytes,   969 lines  md5sums  
   350 bytes,12 lines   *  postinst #!/bin/sh
   160 bytes, 5 lines   *  postrm   #!/bin/sh
   185 bytes, 7 lines   *  prerm#!/bin/sh
   Package: xbmc
   Version: 2:11.0~git20120116.0cae44d-1
   Architecture: all
   Maintainer: Team XBMC 
   Installed-Size: 33004
   Depends: xbmc-bin (>= 2:11.0~git20120116.0cae44d-1), xbmc-bin (<< 
2:11.0~git20120116.0cae44d-1.1~), mesa-utils, x11-utils, ttf-liberation, 
ttf-dejavu-core, python-bluez | python-lightblue, python-imaging, python, 
python-support (>= 0.90.0)
   Recommends: python-qt3
   Suggests: xbmc-test-helper
   Conflicts: xbmc-data, xbmc-skin-confluence, xbmc-standalone
   Replaces: xbmc-data, xbmc-skin-confluence, xbmc-standalone
   Provides: xbmc-data, xbmc-skin-confluence, xbmc-standalone
   Section: video
   Priority: optional
   Homepage: http://xbmc.org/
   Description: XBMC Media Center (arch-independent data package)
XBMC, recursive acronym for "XBMC Media Center", is an award winning free 
and
open source software media-player and entertainment hub for all your digital
media. XBMC is available for Linux, Mac OS X (Leopard, Tiger and Apple TV)
and Microsoft Windows, as well as the original Xbox game console. Created in
2003 by a group of like minded programmers, XBMC is a non-profit project run
and developed by volunteers located around the world. More than 50 software
developers have contributed to XBMC, and 100-plus translators have worked to
expand its reach, making it available in more than 30 languages.
.
While XBMC functions very well as a standard media player application for
your computer, it has been designed to be the perfect companion for your
HTPC. Supporting an almost endless range of remote controls, and combined
with its beautiful interface and powerful skinning engine, XBMC feels very
natural to use from the couch and is the ideal solution for your home
theater. Once installed, your computer will become a fully functional
multimedia jukebox.
.
This package contains all the archiecture independent data needed to have a
working XBMC.
0m0.0s DEBUG: Command ok: ['dpkg', '--info', 
'xbmc_11.0~git20120116.0cae44d-1_all.deb']
0m0.0s DEBUG: Starting command: ['dpkg', '--info', 
'xbmc-bin_11.0~git20120116.0cae44d-1_amd64.deb']
0m0.0s DUMP: 
   new debian package, version 2.0.
   size 7451470 bytes: control archive= 2541 bytes.
  3154 bytes,33 lines  control  
  2047 bytes,24 lines  md5sums  
   Package: xbmc-bin
   Source: xbmc
   Version: 2:11.0~git20120116.0cae44d-1
   Architecture: amd64
   Maintainer: Team XBMC 
   Installed-Size: 17373
   Depends: libasound2 (>> 1.0.24.1), libavahi-client3 (>= 0.6.16), 
libavahi-common3 (>= 0.6.16), libavcodec53 (>= 4:0.8~beta2-2) | 
libavcodec-extra-53 (>= 4:0.8~beta2-2), libavfilter2 (>= 4:0.8~beta2-2) | 
libavf

Bug#570611: ITP: mythtv -- A personal video recorder application

[Andres Mejia]

One other thing was mythtv's use of an internal ffmpeg. It needs to be able
to use system ffmpeg/libav libraries before it can be uploaded to Debian.

At least with Debian/Ubuntu, it needs to run with system libav.

Bug#469397: ITP: xbmc -- XBMC Media Center

[Andres Mejia]

All packaging is done at https://github.com/xbmc/xbmc-packaging

Bug#655427: ITP: firmware-crystalhd -- Crystal HD Video Decoder (firmware)

[Andres Mejia]

On Jan 11, 2012 2:56 AM, "Daniel Baumann" <
daniel.baum...@progress-technologies.net> wrote:
>
> On 01/11/2012 01:30 AM, Andres Mejia wrote:
> > I'm not sure if this is something I ask the kernel team, or maintain
myself, so
> > I'm reporting this as an ITP for now.
>
> why not just fill a bug against firmware-nonfree for inclusion of it (or
> reassign and retitle this one)?
>
> --
> Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
> Email:  daniel.baum...@progress-technologies.net
> Internet:   http://people.progress-technologies.net/~daniel.baumann/

I found this firmware is not loaded by a kernel driver anyway. See the last
message I sent to the bug report.

Bug#655427: Fwd: Fwd: Bug#655427: ITP: firmware-crystalhd -- Crystal HD Video Decoder (firmware)

[Andres Mejia]

Ok, this isn't loaded by a kernel driver.


-- Forwarded message --
From: Scott D. Davilla 
Date: Tue, Jan 10, 2012 at 8:24 PM
Subject: Re: Fwd: Bug#655427: ITP: firmware-crystalhd -- Crystal HD
Video Decoder (firmware)
To: Andres Mejia 


> davilla, I'm trying to upload the crystalhd firmware to Debian. Is
> this a firmware loaded by a Linux kernel driver?


no, crystalhd firmware is loaded by it's library, libcrystalhd so the
firmware is located in userland.


-- 
Regards,
Andres Mejia



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#655427: ITP: firmware-crystalhd -- Crystal HD Video Decoder (firmware)

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: Andres Mejia 

* Package name: firmware-crystalhd
  Version : 0.0~git20120110.fdd2f19
  Upstream Author : Broadcom Corporation
* URL : http://git.linuxtv.org/jarod/crystalhd.git
* License : other
  Description : Crystal HD Video Decoder (firmware)

I'm not sure if this is something I ask the kernel team, or maintain myself, so
I'm reporting this as an ITP for now. This is an ITP for the firmware needed by
the crystalhd library which has already been uploaded to Debian.

Crystal HD Solution is a product offered by Broadcom. It is used to enable
flawless playback of 1080p high definition video across a wide range of
systems.

The firmware has this disclaimer.

FIRMWARE BINARIES ARE DISTRIBUTED UNDER THE FOLLOWING LICENSE -

BINARIES COVERED WITH THIS LICENSE ARE bcm70015fw.bin and bcm70012fw.bin

Copyright 2007-2010 Broadcom Corporation

Redistribution and use in binary forms of this software, without modification,
are permitted provided that the following conditions are met:

Redistributions must reproduce the above copyright notice, this list of
conditions and the following disclaimer in the documentation and/or other
materials provided with the distribution.

Neither the name of Broadcom nor the names of its contributors may be used to
endorse or promote products derived from this software without specific prior
written permission.

THIS SOFTWARE IS PROVIDED “AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL BROADCOM BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES;LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The above notice is found in a source file for the crystalhd package. It can be
read from
http://git.linuxtv.org/jarod/crystalhd.git/blob/HEAD:/linux_lib/libcrystalhd/libcrystalhd_fwcmds.cpp



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#655270: ITP: libshairport -- emulates an AirPort Express

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: Andres Mejia 

* Package name: libshairport
  Version : 1.2.0
  Upstream Author : Team XBMC
* URL : http://xbmc.org/
* License : MIT/X
  Programming Lang: C
  Description : emulates an AirPort Express

This program emulates an AirPort Express for the purpose of
streaming music from iTunes and compatible iPods. It implements
a server for the Apple RAOP protocol. ShairPort does not support
AirPlay v2 (video and photo streaming). It supports multiple
simultaneous streams, if your audio output chain
(as detected by libao) does so.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org