Bug#604872: unblock: faad2/2.7-6

[Andres Mejia]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception

Please unblock package faad2.

This upload fixes a segfault found in 2.7-4 [1]. Here is the entire changelog.

faad2 (2.7-6) unstable; urgency=high

  [ Alessio Treglia ]
  * Fix segmentation fault in faad due to an incorrect pointer size
(Closes: #603807, LP: #665802).
  * Add gbp config file.

  [ Andres Mejia ]
  * Revert changes in 2.7-5. Upload of 2.7-5 was unintentionally done.
  * Refresh patches.

 -- Andres Mejia   Mon, 22 Nov 2010 19:17:36 -0500

Changes done in 2.7-5 were all reverted, since it was uploaded unintentionally.
Here is a diff for the changes from 2.7-4 to 2.7-6 [2].

1. http://bugs.debian.org/603807
2. 
http://git.debian.org/?p=pkg-multimedia/faad2.git;a=commitdiff;h=005521ed80bd75e2c88319373b6a885db721a903;hp=ae1c31447582637aed1f23087240c567d34ef2ac


unblock faad2/2.7-6

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

Kernel: Linux 2.6.32-5-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#469397: ITP: xbmc -- XBMC Media Center (status update)

[Andres Mejia]

Just a small update on what's going on.

I have given updates to any possible licensing issues at [1]. In short, I fixed 
numerous possible licensing issues myself upstream. The libraries libXBMS and 
UnrarXLib are the only issues that currently exist which are still an issue 
with licensing. At least for Debian, XBMC won't include those two libraries.

Also, I'm not going to worry about including the entire source tree of XBMC 
for Debian packages. I'll just be including the minimum to build the Debian 
packages.

There is the issue of needing to use system libraries instead of internal 
libraries whenever possible. This is especially true for XBMC's use of Python 
and FFMpeg libraries. Because XBMC depends on functionality where libc 
function calls are overridden (functions like fopen(), fdopen(), etc.), XBMC 
now needs to override libc function calls inside a system library as well. 
This is especially true for the two mentioned libraries above. See [2] for 
more info.

Aside from that, I don't see any other issue with XBMC being suitable for 
Debian.

1. http://trac.xbmc.org/ticket/7983
2. http://trac.xbmc.org/ticket/8658

-- 
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#570611: ITP: mythtv -- A personal video recorder application (status update)

[Andres Mejia]

Just a small update.

I'm mainly waiting to see if lame will enter Debian or not to see if I should 
worry about modifying mythtv to dlopen lame.

Also, mythtv would have to use system ffmpeg to be suitable for Debian.

That's it for now.

1. http://ftp-master.debian.org/new/lame_3.98.4-1.html

-- 
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#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#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#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#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#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#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]

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#469397: ITP: xbmc -- XBMC Media Center

[Andres Mejia]

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

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#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#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#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: 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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#403246: [PATCH] sbuild dependancy resolution fails when b-dep on A | B ; A uninstallable

[Andres Mejia]

Here's a patch that would partially fix this bug. I say partially because this 
only works if $apt_policy is left with it's default value of 1.

I've run into an issue in trying to work out something that could work without 
apt-get.

-- 
Regards,
Andres
From fc4d77506c4f7003712d89eda9bb599a2809aad7 Mon Sep 17 00:00:00 2001
From: Andres Mejia 
Date: Sat, 27 Feb 2010 17:28:39 -0500
Subject: [PATCH] Fix internal build-dep satisfier for A | B build-dep and A uninstallable when APT_POLICY is used.

---
 lib/Sbuild/InternalBuildDepSatisfier.pm |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/lib/Sbuild/InternalBuildDepSatisfier.pm b/lib/Sbuild/InternalBuildDepSatisfier.pm
index 335a03c..2a845ba 100644
--- a/lib/Sbuild/InternalBuildDepSatisfier.pm
+++ b/lib/Sbuild/InternalBuildDepSatisfier.pm
@@ -244,6 +244,9 @@ sub filter_dependencies {
 		} else {
 			$builder->log("Using default version " . $policy->{$name}->{defversion} . "\n");
 		}
+		} elsif ($self->get_conf('APT_POLICY') && !defined($policy->{$name})) {
+			$builder->log("Package $name not found. Skipping for now, maybe there are alternatives.\n");
+			next if ($self->get_conf('CHECK_DEPENDS_ALGORITHM') eq "alternatives");
 		}
 		$installable = $name if !$installable;
 		next;
-- 
1.7.0

Bug#571806: sbuild: STDERR not being piped in Sbuild::Build::run_apt

[Andres Mejia]

Package: sbuild
Version: 0.60.0-1
Severity: normal

It looks as though STDERR is not being properly piped in the run_apt()
subroutine. This problem may be in Sbuild::Chroot, but I haven't thouroughly
checked. This is from sbuild version 0.60.0-1 with the patch in bug #403246.

Here's a debug output. Note the 'E: Couldn't find package' message and how
it's missing in $msgs at the end.

Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1138):
1138:   my $pipe =
1139:   $self->get('Session')->pipe_apt_command(
1140:   { COMMAND => [$self->get_conf('APT_GET'), '--purge',
1141: '-o', 'DPkg::Options::=--force-confold',
1142: '-q', "$mode", 'install', @to_install],
1143: ENV => {'DEBIAN_FRONTEND' => 'noninteractive'},
1144: USER => 'root',
1145: PRIORITY => 0,
1146: DIR => '/' });
  DB<4> n
Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1147):
1147:   if (!$pipe) {
  DB<4> E: Couldn't find package does-not-exist
l
1147==> if (!$pipe) {
1148:   $self->log("Can't open pipe to apt-get: $!\n");
1149:   return 0;
1150}
1151
1152:   while(<$pipe>) {
1153:   $msgs .= $_;
1154:   $self->log($_) if $mode ne "-s" || debug($_);
1155}
1156:   close($pipe);
  DB<4> n
Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1152):
1152:   while(<$pipe>) {
  DB<4> n
Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1153):
1153:   $msgs .= $_;
  DB<4> n
Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1154):
1154:   $self->log($_) if $mode ne "-s" || debug($_);
  DB<4> n
Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1153):
1153:   $msgs .= $_;
  DB<4> n
Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1154):
1154:   $self->log($_) if $mode ne "-s" || debug($_);
  DB<4> n
Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1153):
1153:   $msgs .= $_;
  DB<4> n
Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1154):
1154:   $self->log($_) if $mode ne "-s" || debug($_);
  DB<4> n
Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1156):
1156:   close($pipe);
  DB<4> n
Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1157):
1157:   $status = $?;
  DB<4> n
Sbuild::Build::run_apt(sbuild/lib/Sbuild/Build.pm:1159):
1159:   if ($status != 0 && $msgs =~ /^E: Packages file \S+ (has changed|is 
out of sync)/mi) {
  DB<4> x $pipe
0  GLOB(0x29cb778)
   -> *Sbuild::Chroot::$pipe
  DB<5> x $msgs
0  'Reading package lists...
Building dependency tree...
Reading state information...
'


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

Kernel: Linux 2.6.32-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.112   add and remove users and groups
ii  libsbuild-perl   0.60.0-1Tool for building Debian binary pa
ii  perl 5.10.1-11   Larry Wall's Practical Extraction 
ii  perl-modules 5.10.1-11   Core Perl modules

Versions of packages sbuild recommends:
ii  debootstrap   1.0.22 Bootstrap a basic Debian system
ii  fakeroot  1.14.4-1   Gives a fake root environment

Versions of packages sbuild suggests:
pn  deborphan  (no description available)
ii  wget  1.12-1.1   retrieves files from the web

-- 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#534504: [patch] ifupdown integration of mediatomb

[Andres Mejia]

On Sunday 24 January 2010 12:48:51 Reinhard Tartler wrote:
> On So, Jan 24, 2010 at 13:55:41 (CET), Eric Lavarde wrote:
> > Package: mediatomb
> > Followup-For: Bug #534504
> >
> > Hello,
> >
> > to solve the problem described by other persons, I've created two small
> > scripts that start and stop mediatomb when the interfaces are being
> > brought up and down.
> 
> I understand from the context of the bug that the issue seems to be that
> mediatomb must not be started before the network interface is up and
> running. Why can't this be fixed be changing the initscript ordering?
> 
> > There is also a diff file for /etc/default/mediatomb that adds a
> > variable DELAYED (yes/no) to disable/enable those small scripts.
> 
> The race condition is present on *all* systems, so no need to make this
> fix configurable.
> 
> > Few remarks:
> >
> > 1. the current default is DELAYED=yes, which enables the script. It
> > doesn't really hurt as mediatomb is restarted, and should work in all
> > situations (with and withou NetworkManager).
> 
> What about the case that a system has 2 interfaces and mediatomb is
> serving to both interfaces at the same time: Restarting one interface is
> likely to disconnect users connected via that interface, but would this
> affect users via the second interface as well?
> 
> > 2. I'm not sure I correctly understood the meaning of the "INTERFACE"
> > variable (mine is empty), so my check might be incorrect as I only
> > restart/stop if the interface given by INTERFACE is being
> > stopped/started ($IFACE = $INTERFACE). Someone with more knowledge of
> > mediatomb's internas might want to check if this is the right
> > decision.
> 
> I guess this is a saftey guard to avoid unnecessary restarts if
> mediatomb is configured to serve only on one specific interface and
> other interfaces are restarted. Which seems to suggest an answer to my
> previous question.
> 
> > 3. if INTERFACE=lo, then the scripts do something if and only if the 'lo'
> > interface is brought up or down, again, it might not be the right logic.
> 
> what do they do exactly?
> 
> > 4. the attached tar file contains the files and diff with correct
> > relative position (don't unpack in root direcotry unless it's what you
> > want to do!).
> 
> I see that your if-updown scripts call the init script. That means that
> depending on the context the init script is called, it behaves
> differently. I find this a bit odd.
> 
> How about dumping the init script altogether and implement starting and
> stopping mediatomb solely from if-updown scripts? This way there was no
> need for the DELAYED=yes flag and the race condition would be avoided as
> well.
> 

Simplest thing to do I think would be to have the if-updown scripts just run 
the mediatomb init script. 

-- 
Regards,
Andres



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

Bug#637758: Distributing static libraries

[Andres Mejia]

On Thu, Aug 11, 2011 at 11:40 PM, Felipe Sateler  wrote:
> On Thu, Aug 11, 2011 at 22:29, Andres Mejia  wrote:
>> On Thu, Aug 11, 2011 at 3:46 AM, Fabian Greffrath  
>> wrote:
>>> Am 11.08.2011 05:22, schrieb Andres Mejia:
>>>>
>>>> I have seen a commit with mp4v2 that disables building of the static
>>>> library. Though I know binaries in Debian are normally linked with
>>>> shared libraries, distributing the static library is beneficial to
>>>> users with different requirements for software they distribute.
>>>>
>>>> I have heard of various use cases involving distribution of stand
>>>> alone binaries (no dependent shared libraries).
>>>
>>> The problem with this specific library is its license, which prohibits
>>> linking against about 99% of packages that come into consideration to make
>>> use of it. So most probably any application that statically links against it
>>> commits a license violation. :/
>>>
>>> Therefore, many applications fall back to dlopen() the library, in which
>>> case only the header files (if at all) are required.
>>>
>>> A similar case is libdvdcss. All applications that I know to make use of it
>>> try to dlopen() it instead of explicit linking, because they know that this
>>> library is widely considered undistributable - though for other reasons.
>>>
>>>  - Fabian
>>>
>>> ___
>>> pkg-multimedia-maintainers mailing list
>>> pkg-multimedia-maintain...@lists.alioth.debian.org
>>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
>>>
>>
>> Ok, I see you're considering to licensing issues with mp4v2. I was
>> referring to the issue of simply providing static libraries in general
>> (not just with mp4v2).
>>
>> To state what I've mentioned another way, we shouldn't disable
>> distribution of static libraries simply because packages in Debian
>> won't link to them.
>
> Actually, I think static libraries should be disabled by default and
> enabled when needed. They provide zero value for most. Those who need
> it can build the static libraries themselves. And they probably
> will/should anyways, since static libs will probably be used in some
> rare context.

Going back to the issue of distributing static libs, I suppose it's
true that static libs will not be needed by most. However, the users
that would need them would expect them to be in the development
package of their distro (in Debian's case, the -dev package).

We could make these users build the libraries themselves, but then
they would also need to build all the build dependencies as well for
the library they need. This can be quite a burden on various
architectures, such as arm or mips. I'm sure everyone here is aware
that for most libraries, it's not just a matter of running
'./configure && make'.

It's likely these various users would be under limited time and
resources to provide their deliverable, thus I suspect they would
simply look elsewhere for precompiled static libraries.

> --
>
> Saludos,
> Felipe Sateler
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers

-- 
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#634294: nettle-dev: please support pkg-config

[Andres Mejia]

Upstream provides a pkg-config file now, since version 2.3.

-- 
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#640243: nettle: Nettle 2.4 released

[Andres Mejia]

Package: nettle
Severity: wishlist

Nettle 2.4 was released shortly after the released of Nettle 2.3. This includes
a fix for the test failures of ripemd160 implementation on big-endian machines.

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

Kernel: Linux 3.0.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



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

Bug#640524: libarchive 2.8.5 Released

[Andres Mejia]

Package: libarchive
Severity: wishlist

>From the announcement...

Libarchive 2.8.5 is the latest release in the libarchive 2.8 branch.

This includes a number of bug fixes since the previous release and is
the best version of libarchive, bsdtar, and bsdcpio for general
production use.  All users of previous versions are encouraged to
upgrade.

Specific fixes since libarchive 2.8.4:
   * Now reads ISO images created by NetBSD makefs and other tools.
   * Relax an lzma compression test to remove false negatives.
   * Better handling of open failures and interrupted writes.
   * Corrected compile warnings on various platforms.

Any problems with libarchive should be reported to the bug tracker at
http://libarchive.googlecode.com/

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

Kernel: Linux 3.0.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



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

Bug#636350: ITP: gpac -- multimedia framework for research and academic purposes

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: Debian Multimedia Maintainers 


* Package name: gpac
  Version : 0.4.5+svn3450
  Upstream Author : Jean Le Feuvre 
* URL : http://gpac.sourceforge.net
* License : LGPL
  Programming Lang: C
  Description : multimedia framework for research and academic purposes

GPAC stands for GPAC Project on Advanced Content (a recursive acronym).
It is an Open Source multimedia framework for research and academic purposes.
The project covers different aspects of multimedia, with a focus on presentation
technologies (graphics, animation and interactivity).



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

Bug#636670: libvpx: New upstream release 0.9.7 available

[Andres Mejia]

Package: libvpx
Severity: wishlist

A new release (0.9.7) has been made available.

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

Kernel: Linux 3.0.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



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

Bug#641265: libarchive: FTBFS : 25: test_read_compress_program FAIL: libarchive_test

[Andres Mejia]

I see this failed again with the new upload of libarchive. Could you
attach the contents of the test directory everything is tested in?
Even having the archive that caused this failure might help us out a
bit.

-- 
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#642798: libav-extra: Libraries uninstallable because of libav-dbg

[Andres Mejia]

Package: libav-extra
Version: 4:0.7.1.3
Severity: important

If libav-dbg is installed in the system, any of the libav-extra libraries are
uninstallable.

I think a libav-extra-dbg package should be built from libav-extra. This would
mean that ffmpeg-dbg would need to have 'Depends: libav-dbg | libav-extra-dbg'
as well. Also, libav-dbg Depends on ffmpeg should be moved to ffmpeg-dbg.

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

Kernel: Linux 3.0.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



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

Bug#641265: libarchive: FTBFS : 25: test_read_compress_program FAIL: libarchive_test

[Andres Mejia]

On Tue, Sep 27, 2011 at 8:54 PM, Nobuhiro Iwamatsu  wrote:
> Hi,
>
>> I see this failed again with the new upload of libarchive. Could you
>> attach the contents of the test directory everything is tested in?
>> Even having the archive that caused this failure might help us out a
>> bit.
>
> /tmp/libarchive_test*/test_read_compress_program.log of new packge is empty.
> I uploaded binary of libarchive-2.8.5 to
>  http://people.debian.org/~iwamatsu/libarchive/libarchive-2.8.5.tar.gz
>
> Could you check this?
>
> Best regards,
>  Nobuhiro
>
> --
> Nobuhiro Iwamatsu
>    iwamatsu at {nigauri.org / debian.org}
>    GPG ID: 40AD1FA6
>
>
>
>

The only hope in debugging this (for me at least) would be for someone
to install libarchive's build dependencies on the alpha or sh4
porterboxes (preferrably on alpha since alpha seems faster). I could
then debug the library on these machines.

-- 
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#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#635269: nmu: sdl-image1.2_1.2.10-2.1

[Andres Mejia]

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

nmu sdl-image1.2_1.2.10-2.1 . ALL . -m "Migrate to libjpeg8"

I'm requesting a binNMU of sdl-image1.2 to build against libjpeg8. No changes
are needed for sdl-image1.2.

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

Kernel: Linux 2.6.39-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#625178: directfb: FTBFS: configure: error: C compiler cannot create executables

[Andres Mejia]

Hi,

Any status on fixing these bugs (#625178, #624875)?

I suppose since there hasn't been any response from the maintainers in over 2 
months, I could upload an NMU with the fix for these bugs.

-- 
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#635286: nmu: tiff_3.9.5-1

[Andres Mejia]

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

nmu tiff_3.9.5-1 . ALL . -m "Migrate to libjpeg8"

I'm requesting a binnmu of tiff to build against libjpeg8. No changes were
needed for tiff to build against libjpeg8.

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

Kernel: Linux 2.6.39-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#624807: libav 0.7 transition

[Andres Mejia]

Has there been any work on transitioning to libav-0.7?

-- 
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#635941: www.debian.org: "Software that can't be packaged" page should be updated

[Andres Mejia]

Package: www.debian.org
Severity: normal

The page at 'http://www.debian.org/devel/wnpp/unable-to-package' should be
updated. LAME has been accepted into Debian, thus the bullet point mentioning
LAME and other packages similar to LAME is no longer true.

See also http://packages.qa.debian.org/l/lame/news/20110729T093211Z.html

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

Kernel: Linux 3.0.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



-- 
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: 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: 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: 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: 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]

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#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#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#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#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#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#655143: ITP: libcec -- USB CEC Adaptor communication Library

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: Andres Mejia 

* Package name: libcec
  Version : 1.3.2
  Upstream Author : Lars Op den Kamp 
* URL : https://github.com/Pulse-Eight/libcec
* License : GPL
  Programming Lang: C++
  Description : USB CEC Adaptor communication Library 

This library provides support for the Pulse-Eight USB-CEC adapter.



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

Bug#655180: ITP: afpfs-ng -- Client for the Apple Filing Protocol (AFP)

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: Andres Mejia 

* Package name: afpfs-ng
  Version : 0.8.1
  Upstream Author : Alex deVries 
* URL : http://sites.google.com/site/alexthepuffin/home
* License : GPL
  Programming Lang: C
  Description : Client for the Apple Filing Protocol (AFP)

This is a client for the Apple Filing Protocol (AFP) which will let you mount
and access shared volumes from Mac OS X (or netatalk) to Linux, BSD and
Mac OS X systems.



-- 
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

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 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#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#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#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#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#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#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]

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 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: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#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#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#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#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]

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#653195: transition: libarchive

[Andres Mejia]

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

I am requesting a transition from libarchive1 to the latest libarchive shared
library package (which will be libarchive12). The latest libarchive version to
transition to will be libarchive-3.0.2 (soon to be uploaded to experimental).
This transition will require source changes to packages that used the following
functions from libarchive.

archive_read_data_block
archive_read_data_into_buffer
archive_read_set_format_options
archive_read_set_filter_options
archive_read_extract_set_skip_file
archive_write_set_skip_file
archive_write_data_block
archive_write_set_format_options
archive_write_set_compressor_options
archive_write_disk_set_skip_file
archive_write_disk_set_group_lookup
archive_write_disk_set_user_lookup
archive_read_disk_gname
archive_read_disk_uname
archive_read_disk_set_gname_lookup
archive_read_disk_set_uname_lookup
archive_entry_gid
archive_entry_ino
archive_entry_uid
archive_entry_set_gid
archive_entry_set_ino
archive_entry_set_uid
archive_entry_acl_add_entry
archive_entry_acl_add_entry_w
__archive_entry_acl_parse_w

All other packages can simply be binNMUed. The following packages are reverse
dependencies of libarchive1 (as found using apt-cache).

  ark
  gmameui
  tuxcmd-modules
  libtotem-plparser17
  reprepro
  rdup
  packagekit-bash-completion
  packagekit
  libpackagekit-glib2-14
  gstreamer0.10-packagekit
  browser-plugin-packagekit
  libapache2-mod-musicindex
  hydrogen
  gvfs-backends
  deb-gview
  cpio
  cmake-qt-gui
  cmake-curses-gui
  cmake
  claws-mail-archiver-plugin
  archivemount

Also, libtotem-plparser-dev is a reverse dependency on libarchive-dev.

-- 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



-- 
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]

On Sat, Dec 24, 2011 at 7:43 PM, Andres Mejia  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> I am requesting a transition from libarchive1 to the latest libarchive shared
> library package (which will be libarchive12). The latest libarchive version to
> transition to will be libarchive-3.0.2 (soon to be uploaded to experimental).
> This transition will require source changes to packages that used the 
> following
> functions from libarchive.
>
> archive_read_data_block
> archive_read_data_into_buffer
> archive_read_set_format_options
> archive_read_set_filter_options
> archive_read_extract_set_skip_file
> archive_write_set_skip_file
> archive_write_data_block
> archive_write_set_format_options
> archive_write_set_compressor_options
> archive_write_disk_set_skip_file
> archive_write_disk_set_group_lookup
> archive_write_disk_set_user_lookup
> archive_read_disk_gname
> archive_read_disk_uname
> archive_read_disk_set_gname_lookup
> archive_read_disk_set_uname_lookup
> archive_entry_gid
> archive_entry_ino
> archive_entry_uid
> archive_entry_set_gid
> archive_entry_set_ino
> archive_entry_set_uid
> archive_entry_acl_add_entry
> archive_entry_acl_add_entry_w
> __archive_entry_acl_parse_w
>
> All other packages can simply be binNMUed. The following packages are reverse
> dependencies of libarchive1 (as found using apt-cache).
>
>  ark
>  gmameui
>  tuxcmd-modules
>  libtotem-plparser17
>  reprepro
>  rdup
>  packagekit-bash-completion
>  packagekit
>  libpackagekit-glib2-14
>  gstreamer0.10-packagekit
>  browser-plugin-packagekit
>  libapache2-mod-musicindex
>  hydrogen
>  gvfs-backends
>  deb-gview
>  cpio
>  cmake-qt-gui
>  cmake-curses-gui
>  cmake
>  claws-mail-archiver-plugin
>  archivemount
>
> Also, libtotem-plparser-dev is a reverse dependency on libarchive-dev.
>
> -- 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
>
>

I attempt to rebuild all packages in this list in a clean chroot. Out
of all the packages, only gmameui, tuxcmd-modules, and deb-gview
appear to require changes to their sources in order to build with the
latest libarchive. All other packages can simply be binNMUed.

One other note, hydrogen currently fails to build, although that stems
from a different issue which has already been addressed and pending a
new upload. The pending version of hydrogen builds with the latest
version of libarchive.

-- 
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#653231: gmameui: Fix build failure using new libarchive 3.0.2.

[Andres Mejia]

Package: gmameui
Version: 0.2.12-1
Severity: normal
Tags: patch

I am getting ready for an upload of the latest stable release of libarchive
version 3.0.2 to unstable. Because of a SONAME bump, this requires packages
using libarchive to be rebuilt. I found that gmameui fails to build using
libarchive 3.0.2. Attached is a patch that will allow gmameui to be built with
either the current version of libarchive in unstable (2.8.5) or the latest
version of libarchive (3.0.2).

-- 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
Description: Fix build failure because of removal of
 archive_read_data_into_buffer. Use archive_read_data instead.
Author: Andres Mejia 

--- a/src/gmameui-zip-utils.c
+++ b/src/gmameui-zip-utils.c
@@ -91,7 +91,7 @@
 			buffer_data = (gchar *) g_malloc0 (filesize);
 			
 			/* Read the zipped pixbuf into memory */
-			archive_read_data_into_buffer (zipfile, buffer_data, filesize);
+			archive_read_data(zipfile, buffer_data, filesize);
 			
 			pixbuf = load_pixbuf_data (buffer_data, filesize);
 	 

Bug#653233: tuxcmd-modules: Fix build failure using libarchive 3.0.2

[Andres Mejia]

Package: tuxcmd-modules
Version: 0.6.70+ds-1
Severity: normal
Tags: patch

I am getting ready for an upload of the latest stable release of libarchive
version 3.0.2 to unstable. Because of a SONAME bump, this requires packages
using libarchive to be rebuilt. I found that tuxcmd-modules fails to build using
libarchive 3.0.2. Attached is a patch that will allow tuxcmd-modules to be built
with either the current version of libarchive in unstable (2.8.5) or the latest
version of libarchive (3.0.2).

-- 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
Description: Fix build failure because of removal of ARCHIVE_LIBRARY_VERSION.
 Use ARCHIVE_VERSION_STRING instead.
Author: Andres Mejia 

--- a/libarchive/libarchive.c
+++ b/libarchive/libarchive.c
@@ -141,7 +141,7 @@
 
   module_info->ID = g_strdup ("libarchive_plugin");
   module_info->Name = g_strdup ("libarchive plugin");
-  module_info->About = g_strdup_printf ("version %s, build date: %s\nusing %s\n", VERSION, BUILD_DATE, ARCHIVE_LIBRARY_VERSION);
+  module_info->About = g_strdup_printf ("version %s, build date: %s\nusing %s\n", VERSION, BUILD_DATE, ARCHIVE_VERSION_STRING);
   module_info->Copyright = g_strdup ("Plugin Copyright (C) 2008-2009 Tomáš Bžatek\nlibarchive sources Copyright (c) 2003-2007 Tim Kientzle");
 
   return module_info;

Bug#653237: deb-gview: Fix build failure when using libarchive 3.0.2

[Andres Mejia]

Package: deb-gview
Version: 0.2.7
Severity: normal
Tags: patch

I am getting ready for an upload of the latest stable release of libarchive
version 3.0.2 to unstable. Because of a SONAME bump and because deb-gview uses a
symbol which has been dropped in the latest libarchive release (namely
archive_version_number), this requires deb-gview to be rebuilt. Attached is a
patch that will allow deb-gview to be built with either the current version of
libarchive in unstable (2.8.5) or the latest version of libarchive (3.0.2). This
patch will provide the same functionality as what it currently has.

-- 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
Description: Fix build failure when building with libarchive 3.0.2.
Author: Andres Mejia 

--- a/src/main.c	2011-12-25 12:59:50.356201098 -0500
+++ b/src/main.c	2011-12-25 13:03:18.896199110 -0500
@@ -142,7 +142,8 @@
 	bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8");
 	textdomain (GETTEXT_PACKAGE);
 #endif
-	g_assert (archive_api_version () == ARCHIVE_API_VERSION);
+	g_assert ((archive_version_number() / 100) ==
+	  (ARCHIVE_VERSION_NUMBER   / 100));
 	remaining_args = NULL;
 	window1 = NULL;
 	option_context = g_option_context_new ("");

Bug#653195: transition: libarchive

[Andres Mejia]

I have finished checking what changes were required for gmameui,
tuxcmd-modules, and deb-gview in order to build with both the current
version of libarchive (2.8.5) and the latest version (3.0.2).
Fortunately, all changes required are trivial. I filed bug reports and
patches in the following locations.

gmameui: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653231
tuxcmd-modules: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653233
deb-gview: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653237

As said before, all other packages simply need to be binNMUed. The
package 'hydrogen' requires a sourceful upload for a seperate issue.

With all this said, I am requesting a transition slot for the
transition from libarchive 2.8.5 to libarchive 3.0.2.

-- 
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#653195: transition: libarchive

[Andres Mejia]

On Sun, Dec 25, 2011 at 5:09 PM, Niels Thykier  wrote:
> On Dec 25, 2011 19:42 "Andres Mejia"  wrote:
>
>> I have finished checking what changes were required for gmameui,
>> tuxcmd-modules, and deb-gview in order to build with both the current
>> version of libarchive (2.8.5) and the latest version (3.0.2).
>> Fortunately, all changes required are trivial. I filed bug reports and
>> patches in the following locations.
>>
>> gmameui: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653231>
>> tuxcmd-modules:
>> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653233>
>> deb-gview: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653237>
>>
>> As said before, all other packages simply need to be binNMUed. The
>> package 'hydrogen' requires a sourceful upload for a seperate issue.
>>
>> With all this said, I am requesting a transition slot for the
>> transition from libarchive 2.8.5 to libarchive 3.0.2.
>>
>>
>>
>
>
> Hi,
>
> Thanks for rebuild testing the packages.
>
> I have setup a tracker for the libarchive transition at [1], please confirm 
> it matches your expectations.

Yes, this is what I expect.

> In regards to timing, we will have to wait until the evolution3.2 transition 
> is over[2].  We will get back to you when it is done.

Very well.

> ~Niels
>
> [1] http://release.debian.org/transitions/html/libarchive.html
>
> [2] http://release.debian.org/transitions/html/evolution3.2.html
>



-- 
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#653844: RFP: python-libarchive -- Python wrapper for libarchive

[Andres Mejia]

Package: wnpp
Severity: wishlist

* Package name: python-libarchive
  Version : 3.0.1
  Upstream Author : SmartFile 
* URL : http://code.google.com/p/python-libarchive/
* License : BSD
  Programming Lang: C, Python
  Description : Python wrapper for libarchive

Fully functional Python wrapper for libarchive. Created using SWIG. The
low-level API provides access to all of the functionality of libarchive.



-- 
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 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]

Alright, going to upload to experimental now.

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]

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#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