Processed: severity of 578622 is serious

2010-04-21 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> # Regression on a release arch, adjusting severity.
> severity 578622 serious
Bug #578622 [mplayer] mplayer: FTBFS on kfreebsd-amd64 (vidix disable needed)
Severity set to 'serious' from 'important'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#578443: marked as done (bristol: FTBFS on kfreebsd-*: error: token ""i386|amd64"" is not valid in preprocessor expressions)

2010-04-21 Thread Debian Bug Tracking System 
Your message dated Wed, 21 Apr 2010 23:32:34 +
with message-id 
and subject line Bug#578443: fixed in bristol 0.60.0-2
has caused the Debian Bug report #578443,
regarding bristol: FTBFS on kfreebsd-*: error: token ""i386|amd64"" is not 
valid in preprocessor expressions
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
578443: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578443
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: bristol
Version: 0.40.8-3
Severity: serious
Justification: FTBFS
User: debian-...@lists.debian.org
Usertags: kfreebsd

Hi,

your package no longer builds on kfreebsd-*. On kfreebsd-amd64:
| libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include 
-Wall -g -I./../include/slab -I./../include/bristol -DBRISTOL_HAS_OSS=1 
-DBRISTOL_HAS_ALSA=0 -D_BRISTOL_JACK -g -O2 -I/usr/X11R6/include -c 
audioEngineOSS.c  -fPIC -DPIC -o .libs/audioEngineOSS.o
| In file included from ./../include/slab/slabaudiodev.h:30,
|  from audioEngineOSS.c:43:
| ./../include/slab/slabmixer.h:28:6: error: token ""amd64"" is not valid in 
preprocessor expressions
| audioEngineOSS.c: In function 'ossAudioInit':
| audioEngineOSS.c:165: warning: suggest explicit braces to avoid ambiguous 
'else'
| make[3]: *** [audioEngineOSS.lo] Error 1

And s/amd64/i386/ for the other architecture in the error message.

Full build logs:
  https://buildd.debian.org/status/package.php?p=bristol

You can ask -bsd@ for assistance if needed. (Sorry for the lag, I didn't
realize it was a regression on GNU/kFreeBSD until now.)

Mraw,
KiBi.


--- End Message ---
--- Begin Message ---
Source: bristol
Source-Version: 0.60.0-2

We believe that the bug you reported is fixed in the latest version of
bristol, which is due to be installed in the Debian FTP archive:

bristol-data_0.60.0-2_all.deb
  to main/b/bristol/bristol-data_0.60.0-2_all.deb
bristol_0.60.0-2.debian.tar.gz
  to main/b/bristol/bristol_0.60.0-2.debian.tar.gz
bristol_0.60.0-2.dsc
  to main/b/bristol/bristol_0.60.0-2.dsc
bristol_0.60.0-2_kfreebsd-i386.deb
  to main/b/bristol/bristol_0.60.0-2_kfreebsd-i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 578...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Alessio Treglia  (supplier of updated bristol package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 22 Apr 2010 00:52:06 +0200
Source: bristol
Binary: bristol bristol-data
Architecture: source kfreebsd-i386 all
Version: 0.60.0-2
Distribution: unstable
Urgency: low
Maintainer: Debian Multimedia Maintainers 

Changed-By: Alessio Treglia 
Description: 
 bristol- vintage synthesizer emulator
 bristol-data - vintage synthesizer emulator (data files)
Closes: 578443
Changes: 
 bristol (0.60.0-2) unstable; urgency=low
 .
   * Add patch to fix FTBFS on kfreebsd architectures (Closes: #578443).
   * Temporary switch to debian 3.0 (quilt) format to workaround bug#578693.
Checksums-Sha1: 
 446a3e560e9238d31fd27ddf6b32a8bd3a53dc98 1407 bristol_0.60.0-2.dsc
 6aefb32e010e9428b2f53c56eb19326dde6d850b 10082 bristol_0.60.0-2.debian.tar.gz
 40332dfbb08566d318d0752f235375c3f2d6a0ac 785006 
bristol_0.60.0-2_kfreebsd-i386.deb
 465df2f4e91d57ca34dfa367b004055636b9bb16 2834734 bristol-data_0.60.0-2_all.deb
Checksums-Sha256: 
 193c5b18b532689b9d28fdb1e46a142ce7c5bb29de775ce0b22539dcf870ab78 1407 
bristol_0.60.0-2.dsc
 6803f64789cf56fbeff73e9dff06db6b32434e645f09bf29f01b0e4e4755ead5 10082 
bristol_0.60.0-2.debian.tar.gz
 f54f3f0549e3afdadf82575abb002436b11393219196a33576d35ac986f42311 785006 
bristol_0.60.0-2_kfreebsd-i386.deb
 e3d6162cb9309974393246dce7c14bcd5589532c55027040d16d8a7cab3eb6ec 2834734 
bristol-data_0.60.0-2_all.deb
Files: 
 c7b7bc41a5a0bb892e3c9cc4badf80e3 1407 sound optional bristol_0.60.0-2.dsc
 31cae064b4dc13ecf691c9f733672605 10082 sound optional 
bristol_0.60.0-2.debian.tar.gz
 3be9c24effea668688990aabead2db84 785006 sound optional 
bristol_0.60.0-2_kfreebsd-i386.deb
 b381f702cda1f01bd1eef349194c6170 2834734 sound optional 
bristol-data_0.60.0-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkvPh6EACgkQRdSMfNz8P9BX6gCfdcdKqZCHwEcWBMvD2Ok7j135
FUUAnj1

bristol_0.60.0-2_kfreebsd-i386.changes ACCEPTED

2010-04-21 Thread Archive Administrator 



Accepted:
bristol-data_0.60.0-2_all.deb
  to main/b/bristol/bristol-data_0.60.0-2_all.deb
bristol_0.60.0-2.debian.tar.gz
  to main/b/bristol/bristol_0.60.0-2.debian.tar.gz
bristol_0.60.0-2.dsc
  to main/b/bristol/bristol_0.60.0-2.dsc
bristol_0.60.0-2_kfreebsd-i386.deb
  to main/b/bristol/bristol_0.60.0-2_kfreebsd-i386.deb


Override entries for your package:
bristol-data_0.60.0-2_all.deb - optional sound
bristol_0.60.0-2.dsc - source sound
bristol_0.60.0-2_kfreebsd-i386.deb - optional sound

Announcing to debian-devel-chan...@lists.debian.org
Closing bugs: 578443 


Thank you for your contribution to Debian.

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Processing of bristol_0.60.0-2_kfreebsd-i386.changes

2010-04-21 Thread Archive Administrator 
bristol_0.60.0-2_kfreebsd-i386.changes uploaded successfully to localhost
along with the files:
  bristol_0.60.0-2.dsc
  bristol_0.60.0-2.debian.tar.gz
  bristol_0.60.0-2_kfreebsd-i386.deb
  bristol-data_0.60.0-2_all.deb

Greetings,

Your Debian queue daemon (running on host ries.debian.org)

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Processed: Re: Bug#573257: mplayer: font path error

2010-04-21 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> retitle 573257 please enable fontconfig by default
Bug #573257 [mplayer] mplayer: font path error
Changed Bug title to 'please enable fontconfig by default' from 'mplayer: font 
path error'
> stop
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#573257: mplayer: font path error

2010-04-21 Thread Reinhard Tartler 
retitle 573257 please enable fontconfig by default
stop

AFAIUI, enabling fontconfig with the -fontconfig option should be a
better "fix" for this.

can you confirm this?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#578615: marked as done (audacity: segfault in libasound.so.2.0.0)

2010-04-21 Thread Debian Bug Tracking System 
Your message dated Wed, 21 Apr 2010 21:18:47 +0200
with message-id <1271877527.31899.2.ca...@deep-thought>
and subject line audacity: segfault in libasound.so.2.0.0
has caused the Debian Bug report #578615,
regarding audacity: segfault in libasound.so.2.0.0
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
578615: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578615
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: audacity
Version: 1.3.12-2
Severity: normal


Audacity does not start:
kernel: [583559.281926] audacity[11674]: segfault at 0 ip 0033f1c567e3 sp 
7fff2e62a0c0 error 4 in libasound.so.2.0.0[33f1c0+de000]

(Severity normal because it's testing)

hth.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'testing'), (500, 
'testing-proposed-updates'), (500, 'proposed-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32.2 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages audacity depends on:
ii  audacity-data  1.3.12-2  A fast, cross-platform audio edito
ii  libasound2 1.0.22-2  shared library for ALSA applicatio
ii  libc6  2.10.2-6  Embedded GNU C Library: Shared lib
ii  libexpat1  2.0.1-4+lenny3XML parsing C library - runtime li
ii  libflac++6 1.2.1-1.2 Free Lossless Audio Codec - C++ ru
ii  libflac8   1.2.1-1.2 Free Lossless Audio Codec - runtim
ii  libgcc11:4.4.2-9 GCC support library
ii  libglib2.0-0   2.24.0-1  The GLib library of C routines
ii  libgtk2.0-02.18.6-1~bpo50+1  The GTK+ graphical user interface 
ii  libid3tag0 0.15.1b-10ID3 tag reading library from the M
ii  libjack0   0.118+svn3796-2   JACK Audio Connection Kit (librari
ii  libmad00.15.1b-4 MPEG audio decoder library
ii  libogg01.1.3-4   Ogg Bitstream Library
ii  libsamplerate0 0.1.7-3   Audio sample rate conversion libra
ii  libsndfile11.0.21-2  Library for reading/writing audio 
ii  libsoundtouch1c2   1.3.1-2   sound stretching library
ii  libstdc++6 4.4.2-9   The GNU Standard C++ Library v3
ii  libtwolame00.3.12-1  MPEG Audio Layer 2 encoding librar
ii  libvamp-hostsdk3   2.1-1 helper library for Vamp hosts writ
ii  libvorbis0a1.2.0.dfsg-3.1+lenny1 The Vorbis General Audio Compressi
ii  libvorbisenc2  1.2.0.dfsg-3.1+lenny1 The Vorbis General Audio Compressi
ii  libvorbisfile3 1.2.0.dfsg-3.1+lenny1 The Vorbis General Audio Compressi
ii  libwxbase2.8-0 2.8.10.1-3wxBase library (runtime) - non-GUI
ii  libwxgtk2.8-0  2.8.10.1-3wxWidgets Cross-platform C++ GUI t

Versions of packages audacity recommends:
ii  libavcodec52   5:0.5+svn20100208-0.1 library to encode decode multimedi
ii  libavformat52  5:0.5+svn20100208-0.1 ffmpeg file format library

Versions of packages audacity suggests:
ii  libmp3lame0   3.98.2-0.5 LAME Ain't an MP3 Encoder
ii  swh-plugins [ladspa-plugin]   0.4.15-0.2 Steve Harris's LADSPA plugins
ii  vcf [ladspa-plugin]   0.0.5-5audio EQ biquad filters for LADSPA

-- no debconf information


--- End Message ---
--- Begin Message ---
Closing this bug.

BTW, ich konnte das Problem nicht in einer KVM Instanz nachvollziehen.

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
--- End Message ---
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#573257: mplayer: font path error

2010-04-21 Thread Timo Juhani Lindfors 
Hi,

I can reproduce the problem. If I hit "o" I only see "|>" sign but no
numbers. If I do 

ln -s /usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf .mplayer/subfont.ttf

I can see the position of the video properly again in OSD.




___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

bristol_0.60.0-2_kfreebsd-i386.changes REJECTED

2010-04-21 Thread Archive Administrator 



Reject Reasons:
bristol_0.60.0-2.dsc: debian/changelog not found in extracted source.



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Processing of bristol_0.60.0-2_kfreebsd-i386.changes

2010-04-21 Thread Archive Administrator 
bristol_0.60.0-2_kfreebsd-i386.changes uploaded successfully to localhost
along with the files:
  bristol_0.60.0-2.dsc
  bristol_0.60.0-2.diff.gz
  bristol_0.60.0-2_kfreebsd-i386.deb
  bristol-data_0.60.0-2_all.deb

Greetings,

Your Debian queue daemon (running on host ries.debian.org)

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#578615: audacity: Already done!

2010-04-21 Thread Alex Wilk 
Package: audacity
Severity: normal

Hi,

es hat sich herausgestellt, dass die oben stehende Fehlermeldung auf einen 
Eintrag in der ~/.asoundrc herrührt. Bitte betrachtet den Report als 
gegenstandslos.

Google translation:
It turns out that the above error on an entry in the ~/.asoundrc arises. Please 
view the report as insubstantial.

Grüße.


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (700, 'stable'), (500, 
'testing-proposed-updates'), (500, 'proposed-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32.2 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages audacity depends on:
ii  audacity-data1.3.12-2A fast, cross-platform audio edito
ii  libasound2   1.0.22-2shared library for ALSA applicatio
ii  libc62.10.2-6Embedded GNU C Library: Shared lib
ii  libexpat12.0.1-7 XML parsing C library - runtime li
ii  libflac++6   1.2.1-2+b1  Free Lossless Audio Codec - C++ ru
ii  libflac8 1.2.1-2+b1  Free Lossless Audio Codec - runtim
ii  libgcc1  1:4.4.2-9   GCC support library
ii  libglib2.0-0 2.24.0-1The GLib library of C routines
ii  libgtk2.0-0  2.20.0-2The GTK+ graphical user interface 
ii  libid3tag0   0.15.1b-10  ID3 tag reading library from the M
ii  libjack0 0.118+svn3796-2 JACK Audio Connection Kit (librari
ii  libmad0  0.15.1b-5   MPEG audio decoder library
ii  libogg0  1.2.0~dfsg-1Ogg bitstream library
ii  libsamplerate0   0.1.7-3 Audio sample rate conversion libra
ii  libsndfile1  1.0.21-2Library for reading/writing audio 
ii  libsoundtouch1c2 1.3.1-2 sound stretching library
ii  libstdc++6   4.4.2-9 The GNU Standard C++ Library v3
ii  libtwolame0  0.3.12-1MPEG Audio Layer 2 encoding librar
ii  libvamp-hostsdk3 2.1-1   helper library for Vamp hosts writ
ii  libvorbis0a  1.3.1-1 The Vorbis General Audio Compressi
ii  libvorbisenc21.3.1-1 The Vorbis General Audio Compressi
ii  libvorbisfile3   1.3.1-1 The Vorbis General Audio Compressi
ii  libwxbase2.8-0   2.8.10.1-3  wxBase library (runtime) - non-GUI
ii  libwxgtk2.8-02.8.10.1-3  wxWidgets Cross-platform C++ GUI t

Versions of packages audacity recommends:
ii  libavcodec52   5:0.5+svn20100208-0.1 library to encode decode multimedi
ii  libavformat52  5:0.5+svn20100208-0.1 ffmpeg file format library

Versions of packages audacity suggests:
ii  libmp3lame0   3.98.2-0.5 LAME Ain't an MP3 Encoder
ii  swh-plugins [ladspa-plugin]   0.4.15+1-4 Steve Harris's LADSPA plugins
ii  vcf [ladspa-plugin]   0.0.5-5audio EQ biquad filters for LADSPA

-- no debconf information



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#578622: mplayer: FTBFS on kfreebsd-amd64

2010-04-21 Thread Diego Biurrun 
On Wed, Apr 21, 2010 at 04:22:16PM +0200, Petr Salinger wrote:
>
> please also change configure as shown bellow.
> Otherwise the memalign() is without prototype,
> which on 64 bit platform leads to segfaults
> for some videos.

Fixed upstream.

Why don't you submit your patches directly to MPlayer instead of
hiding them in some distro package?

Diego



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#578622: mplayer: FTBFS on kfreebsd-amd64 (vidix disable needed)

2010-04-21 Thread Petr Salinger 

the current version fails to build on kfreebsd-amd64.
it suffices to disable vidix support in debian/rules



Bad solution, this will only work for Debian.  You should fix configure
instead of adding workarounds to the local packaging infrastructure.

What are the error messages?


The full build log is linked from usual place
https://buildd.debian.org/status/package.php?p=mplayer

https://buildd.debian.org/fetch.cgi?&pkg=mplayer&ver=1.0%7Erc3%2Bsvn20090405-1&arch=kfreebsd-amd64&stamp=1271726776&file=log

vidix/pci.o: In function `pci_config_read':
/build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:719: 
undefined reference to `pci_config_read_long'

vidix/pci.o: In function `pci_scan':
/build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:536: 
undefined reference to `pci_config_type'
/build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:556: 
undefined reference to `pci_get_vendor'
/build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:568: 
undefined reference to `pci_config_read_long'
/build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:570: 
undefined reference to `pci_config_read_long'
/build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:572: 
undefined reference to `pci_config_read_long'
/build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:574: 
undefined reference to `pci_config_read_long'
/build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:576: 
undefined reference to `pci_config_read_long'
vidix/pci.o:/build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405/vidix/pci.c:578: 
more undefined references to `pci_config_read_long' follow

collect2: ld returned 1 exit status
make[1]: *** [mplayer] Error 1
make[1]: Leaving directory 
`/build/buildd-mplayer_1.0~rc3+svn20090405-1-kfreebsd-amd64-tJVuOE/mplayer-1.0~rc3+svn20090405'

make: *** [build-arch-stamp] Error 2




___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#578622: mplayer: FTBFS on kfreebsd-amd64 (vidix disable needed)

2010-04-21 Thread Diego Biurrun 
On Wed, Apr 21, 2010 at 02:10:31PM +0200, Petr Salinger wrote:
>
> the current version fails to build on kfreebsd-amd64.
> it suffices to disable vidix support in debian/rules
> to get working mplayer.
>
> ifeq ($(DEB_HOST_ARCH),kfreebsd-amd64)
>   with_real_and_xanim = true
>   DEB_BUILD_CONFIGURE += --enable-runtime-cpudetection --disable-vidix
> endif

Bad solution, this will only work for Debian.  You should fix configure
instead of adding workarounds to the local packaging infrastructure.

What are the error messages?

Diego



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

[...@drcomp.erfurt.thur.de: RFP: tschack -- Another implementation for the JACK api written in C. Supports SMP]

2010-04-21 Thread Adrian Knoth 
Hi!

As requested by Jonas, here's the RFP.

- Forwarded message from Adrian Knoth  -

From: Adrian Knoth 
To: Debian Bug Tracking System 
Subject: RFP: tschack -- Another implementation for the JACK api written in C.
Supports SMP
Date: Wed, 21 Apr 2010 14:22:02 +0200

Package: wnpp
Severity: wishlist

* Package name: tschack
  Version : 0.118.2 (or git)
  Upstream Author : Torben Hohn 
* URL : http://hochstrom.endofinternet.org/trac/tschack
* License : GPL, LGPL
  Programming Lang: C
  Description : Another implementation for the JACK api written in C.
Supports SMP

- End forwarded message -

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver

Der merkt halt, dass das seine muttermilch ist, die gerade übertragen wird.
(user während des dd's der root-partition auf den fileserver)

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#578622: mplayer: FTBFS on kfreebsd-amd64

2010-04-21 Thread Petr Salinger 

Hi,

please also change configure as shown bellow.
Otherwise the memalign() is without prototype,
which on 64 bit platform leads to segfaults
for some videos.

Petr


--- configure
+++ configure
@@ -3166,7 +3166,7 @@
   def_malloc_h='#define HAVE_MALLOC_H 0'
 fi
 # malloc.h emits a warning in FreeBSD and OpenBSD
-freebsd || openbsd || dragonfly && def_malloc_h='#define HAVE_MALLOC_H 0'
+openbsd || dragonfly && def_malloc_h='#define HAVE_MALLOC_H 0'
 echores "$_malloc"






___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: packaging jack - details on "plan B"

2010-04-21 Thread Jonas Smedegaard 

On Wed, Apr 21, 2010 at 12:26:41PM +0200, Reinhard Tartler wrote:

On Tue, Apr 20, 2010 at 10:17:42 (CEST), Jonas Smedegaard wrote:


On Sat, Apr 17, 2010 at 09:32:47PM +0200, torbenh wrote:

On Sat, Apr 17, 2010 at 09:13:34PM +0200, Jonas Smedegaard wrote:


I propose to stick to jackd1 as the default/only library for other 
packages to rely on until the rerlease of Squeeze, and only offer 
alternative daemons (and eventually - most likely post-Squeeze - 
alternative libraries too) if they do not interfere with that.


stop right here.
the library and the daemon are tied together.
the protocol between jackd and libjack is NOT fixed.


Ok, my mistake.

Let me then adjust and refine my proposal (main point is the same):

 1. Release src:jack-audio-connection-kit to unstable:
* revert to track only jackd1


As said in my other mail, I don't think we have this option anymore.
Doing so would be like stabbing in adi's wrt. his cross-distro
coordination on jackd2.


"Switch to jackd2, no matter the costs" is silly.  I propose to "do our 
best to ship next distro release with jackd2 support", and do not feel 
like stabbing anyone by juggling that wording - now that the world of 
(j|ch)ack(d[12])? turned out to be more complex, post the cross-distro 
agreements.


But let us discuss strategy and implementation separately: Please do 
*not* reply to this email regarding cross-distro coordination strategy, 
but comment on my other recent email in another forked subthread. :-)




 2. Initially release src:jackd2:
* jackd2 conflicts/replaces/provides jackd
* libjack0-jackd2 conflicts/replaces libjack0
* libjack0-jackd2 provides libjack-0.116.0
* libjack-jackd2-dev conflicts libjack-dev
* Big fat warning to use -dev package only privately


So you propose to introduce 2 virtual packages: jackd and
libjack-0.116.0? What problem does introducing the virtual package jackd
solve?


 3. Initially release src:tchack, like jackd2
 4. Update jack-depending packages after testing that it works:
* Add libjack-0.116.0 as fallback-dependency for libjack0


Ah, so at this point you propose to introduce a shlibs file like:

,[proposed shlibs file]
| libjack0 0 libjack0 (>= 0.116) | libjack-0.116.0
`

is that correct?


Yes, correct.

But an important detail is that I do *not* introduce that virtual 
package to the currently stable jackd1 packaging, only to newly 
introuced jackd2 and tchack packagings!


Only when proven reliable do I want to "infect" the stable package or 
other jack-dependent packages!


The reason for this is the logic of molding a new Debian releaase: It is 
much easier to rip out newly introduced oddities with not depended on by 
other already-accepted packages, than it is to fix problems involving 
chains of package rebuilds.


This also means we do not need to set it all in stone: we do not need to 
discuss *now* what exact wording of each shlib file or naming of virtual 
packages - only if suspected to not work at all is it relevant to 
discuss *now*, else we move faster if discussing and implementing in 
parallel.


(I do feel that you suspect the grand plan to not work at all, so do not 
want to stop the current discussion, just want to warn about it 
exploding into all sorts of details not needed to discuss ahead)




How is the libjack0 package from other implementations supposed to look
like? Something like this?

Package:   libjack-jackd2-0
Provides:  libjack-0.116.0
Conflicts: libjack0


Yes, something like that.



 4. Release jackd1 to experimental, with libjack0 providing   virtual
package libjack-0.116.0
 5. Repackage jackd1 to experimental, with libjack0 providing   virtual
package libjack0-0.116.0


what actual changes are involved in this repackaging?


This step is not needed for technical reasons but was included for 
potential political reason: not in the long term emphasize jackd1 as 
being better than the other implementations.  

If it truly is irrelevant if a jack-dependent package build against 
jackd1, jackd2 or tchack, then it might (or might not!) make sense to 
stop promoting jackd1 as the most rightous of the implementations. We 
could either just abandon the libjack0 and libjack-dev as real packages 
and only rely on virtual package names for build-dependencies of 
common-ABI-conforming projects. Or we can create a set of empty 
meta-packages e.g. libjack-abi-0.116.0 and libjack-abi-0.116.0-dev, 
depending on the implementations truly obeying the declared ABI - making 
it possible to ease transition to newer ABI if API does not change, even 
if not all implementations do not switch to that newer API at the exact 
same time (or maybe some of them not at all).


Most likely this step is long after Squeeze.  And quite probably we 
won't do this step at all. Even if completely broken, I do not see 
failure of this step to affect any of the other steps. Is it relevant to 
discuss it in detail now?




 4. Release jackd1 to experimental, with libjack

Re: packaging jack - cross-distro coordination

2010-04-21 Thread Jonas Smedegaard 

On Wed, Apr 21, 2010 at 12:09:50PM +0200, Reinhard Tartler wrote:

On Wed, Apr 21, 2010 at 09:45:22 (CEST), Jonas Smedegaard wrote:


On Tue, Apr 20, 2010 at 07:48:26PM -0500, Gabriel M. Beddingfield wrote:


On Tue, 20 Apr 2010, Jonas Smedegaard wrote:


Let me then adjust and refine my proposal (main point is the same):

[snip]


It was suggested to discuss the introduction of the virtual 
libjack-0.116.0 on d-devel.  I consider that unnecessary as it is 
coordinated only amongst 3 packages that are all maintained by us. 
But if someone finds it relevant and


I don't understand the libjack-0.116.0 thing.  Is that going to be 
the package name?  If so, that sounds like we would be repeating the 
libjack0.100.0 mistake.


It is more like an add-on tag, indicating the library ABI.


I deduce from this that you don't want to adjust the shlibs file of 
libjack package to make application package generate dependencies on 
libjack-0.116.0 then?


No, I want to adjust shlibs file later on, but not required for step 1.

But let us keep subdiscussions apart: Please do *not* respond to this 
email regarding to technical details of my proposed plan, but wait for a 
separate email (a response to your other recent email).



[enlightening details on upstream coding style snipped]


Right now going from jack1->jack2 is a clean upgrade because of the 
version numbers... so (for me) that would be fine. This all hit the 
fan because it's hard for users to go from jack2->jack1 because they 
have to force a downgrade and the LAD list was told that squeeze 
would ship with Jack 2.


Indeed.  My proposal puts first priority on keeping what we know is 
stable (and what turns out to not be abandoned upstream after all), 
and it puts second a way to try switch not only from one 
implementation to one other (that's easy) but from a single 
implementation to a choice of multiple ones.  Not multiple ones 
installed concurrently, but multiple mutually conflicting ones 
available for installation concurrently.


So to put straight: you propose to not switch to jackd2 at all but 
stick with jackd1? I guess you are aware that adi has negotiated with 
opensuse to do a coordinated switch to jackd2, and is currently trying 
to agree on something similar with fedora? I think that stepping back 
from this plan would makes us look, well, strange.


I want to switch, but a) without lock-in on jackd2 (since that has 
turned out to not be the only potential future) and b) without 
geopardizing the release process.


Generally speaking (please let us discuss technical details in a 
separate subthread - I will fork one when done writing this), I see 3 
possible ways forward:


 * conservative: Stay with jackd1, ignoring jackd2 and tchack.
 * stubborn: Switch to jackd2, abandoning jackd1 and ignoring tchack.
 * bold: switch to supporting multiple implementations.

You seem to want the stubborn path, because a cross-distro wave have set 
off.


I wanted to push jackd2 back when it was seen as the only future, only a 
question on when to make the switch.  But when it turns out jackd1 is 
intended to be kept alive or and tchack exist as a third possible 
future, I find it wrong to pick a single future immaturely.


So I want to keep jackd1 alive and _then_ include jackd2, not include 
jackd2 as replacement for jackd1.  Which means there is a _risk_ that 
jackd2 will not reach inclusion into Squeeze.



In other words, I propose a 4th path:

 * cautious: first conservative, then gradually bolder.


Others looking strangely at Debian is nothing new: When I started using 
Debian in the last millenium, Redhat and SuSE users emphasized the 
weirdness of Debian not using upstream library naming but renaming to 
make it possible to handle multiple ABIs (or whatever it is called, not 
important here) in the distribution - either concurrently installable or 
conflicting but at least available in same release of the distro.



 - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: packaging jack...

2010-04-21 Thread Reinhard Tartler 
On Tue, Apr 20, 2010 at 10:17:42 (CEST), Jonas Smedegaard wrote:

> On Sat, Apr 17, 2010 at 09:32:47PM +0200, torbenh wrote:
>>On Sat, Apr 17, 2010 at 09:13:34PM +0200, Jonas Smedegaard wrote:
>
>>> I propose to stick to jackd1 as the default/only library for other
>>> packages to rely on until the rerlease of Squeeze, and only offer
>>> alternative daemons (and eventually - most likely post-Squeeze - 
>>> alternative libraries too) if they do not interfere with that.
>>
>>stop right here.
>>the library and the daemon are tied together.
>>the protocol between jackd and libjack is NOT fixed.
>
> Ok, my mistake.
>
> Let me then adjust and refine my proposal (main point is the same):
>
>  1. Release src:jack-audio-connection-kit to unstable:
> * revert to track only jackd1

As said in my other mail, I don't think we have this option anymore.
Doing so would be like stabbing in adi's wrt. his cross-distro
coordination on jackd2.

>  2. Initially release src:jackd2:
> * jackd2 conflicts/replaces/provides jackd
> * libjack0-jackd2 conflicts/replaces libjack0
> * libjack0-jackd2 provides libjack-0.116.0
> * libjack-jackd2-dev conflicts libjack-dev
> * Big fat warning to use -dev package only privately

So you propose to introduce 2 virtual packages: jackd and
libjack-0.116.0? What problem does introducing the virtual package jackd
solve?

>  3. Initially release src:tchack, like jackd2
>  4. Update jack-depending packages after testing that it works:
> * Add libjack-0.116.0 as fallback-dependency for libjack0

Ah, so at this point you propose to introduce a shlibs file like:

,[proposed shlibs file]
| libjack0 0 libjack0 (>= 0.116) | libjack-0.116.0
`

is that correct?

How is the libjack0 package from other implementations supposed to look
like? Something like this?

Package:   libjack-jackd2-0
Provides:  libjack-0.116.0
Conflicts: libjack0

>  4. Release jackd1 to experimental, with libjack0 providing   virtual
> package libjack-0.116.0
>  5. Repackage jackd1 to experimental, with libjack0 providing   virtual
> package libjack0-0.116.0

what actual changes are involved in this repackaging?

>  4. Release jackd1 to experimental, with libjack0 providing   virtual
> package libjack0-0.116.0

Repeated step 4? Or copy & paste mistake?


With you're proposal, I think switching from one alternative
implementation to another one won't work. For example switching from
tschack to jackd3 would break with undeclared file conflicts AFAIUI. And
my understanding of this whole hickhack was to allow users to switch
jack implementations without having to recompile packages.


(If it works) my idea would allow this; and without having each and
every implementation to declare conflicts against every existing other
implementation.


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: packaging jack...

2010-04-21 Thread Reinhard Tartler 
On Wed, Apr 21, 2010 at 09:45:22 (CEST), Jonas Smedegaard wrote:

> On Tue, Apr 20, 2010 at 07:48:26PM -0500, Gabriel M. Beddingfield wrote:
>
>>On Tue, 20 Apr 2010, Jonas Smedegaard wrote:
>>
>>>Let me then adjust and refine my proposal (main point is the same):
>>[snip]
>>>
>>> It was suggested to discuss the introduction of the virtual
>>> libjack-0.116.0 on d-devel.  I consider that unnecessary as it is
>>> coordinated only amongst 3 packages that are all maintained by us.
>>> But if someone finds it relevant and
>>
>> I don't understand the libjack-0.116.0 thing.  Is that going to be the
>> package name?  If so, that sounds like we would be repeating the
>> libjack0.100.0 mistake.
>
> It is more like an add-on tag, indicating the library ABI.

I deduce from this that you don't want to adjust the shlibs file of
libjack package to make application package generate dependencies on
libjack-0.116.0 then?

If that's correct, then I didn't understand the purpose of the virtual
package name at all. My (and torben's idea AFAIU him) was to make
application packages generate dependencies on the virtual package that
indicates the promised 'stable ABI' by default, unless the package has
specific requirements on some (extended) libjack implementation. The
most prominent example of this are of course the respective jackd
implementations. In those cases, a shlibs.local overrides the default
shlibs.

> Each implementation will have their own package names, and then in
> addition they will all claim to provide a _virtual_ package name called
> "libjack0.100.0".  So not like earlier (which was before I got involved
> in the team, so I only know of the result, not the considerations behind
> it).

I wasn't involved at that time either, but I guess this was done because
at that time both the ABI and API was not stable (enough or at all).

> If upstream had a more strict coding style (and if I understand it
> correctly, I am a scripter myself, not a coder, so looking at it from
> aside), then they would probably instead have bumped the SONAME and we
> would not use an odd version like this but just use "libjack1" as the
> tag name.

No they wouldn't. They already track ABI very strictly which is the best
that could happen to a packager. AFAIUI, upstream is handling binary
compatibility in the best way given the circumstances.

The issue that makes the matter complicated are the different
implementations that are required (or at least supposed) to implement an
binary interface. This is packaging wise pretty unusual; versioned
provides would make things here much easier.

> We could also use "libjack-2010" or "jack-lib-new-generation" if those
> better indicate what is common across the implementations.  Do upstream
> perhaps have an internal codename for the unification/freeze that we
> could reuse?

They refer to the "binary interface as expressed by libjack version
0.116". For this reason, we invent the virtual package libjack-0.116 to
express "we promise that each and every package that provides this
package name is actually binary compatible to the libjack library
version 0.116". (that's BTW the main reason why I think we need to
adjust the shlibs file and mass rebuild each and every package that
build-depends on libjack-dev).

>>> Later it might make sense to try support officially linking against
>>> alternate implementations. If that works out, it might make sense to
>>> repackage jackd1 similar to the others, so as to treat all
>>> implementations as equal competitors.  But that is post Squeeze IMO.
>>
>> An alternative to keep from holding up squeeze could be: keep things
>> as they are currently... with Jack 1.  Keep Jack 2 in sid (or
>> something) so users can upgrade to it if they want.  Meanwhile, the
>> proposal sounds odd because of the way that the package names relate
>> and the 0.116.0 thing.
>
> This is contained in my proposal: Just tag the newly added
> implementations with a dummy release-critical bugreport to keep them
> from trickling into testing and from there to stable, and you have
> "things as they are currently".
>
> What I propose goes _beyond_ that, though.  It is a no-brainer to revert
> our git to status quo, but what then?  I did not put timestamps on each
> step but it _is_ an ordered list, and if some step fail or gets stalled,
> then the affected packages will not reach Squeeze in time for the
> release.  In other words, if something (or someone - e.g. ftpmaster)
> turns out to not work right, then what will for sure stay in the archive
> and get shipped with Squeeze be jackd1.

TBH, I don't understand how your approach is addressing the challenge:
"Enable users to choose their jack implementation" in a way that works.

I guess I need to find a counter example to show how things break.

>> Right now going from jack1->jack2 is a clean upgrade because of the
>> version numbers... so (for me) that would be fine. This all hit the
>> fan because it's hard for users to go from jack2->jack1 be

Bug#578622: mplayer: FTBFS on kfreebsd-amd64 (vidix disable needed)

2010-04-21 Thread Petr Salinger 

Package: mplayer
Version: 1.0~rc3+svn20090405-1
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd


Hi,

the current version fails to build on kfreebsd-amd64.
it suffices to disable vidix support in debian/rules
to get working mplayer.

Petr


ifeq ($(DEB_HOST_ARCH),kfreebsd-amd64)
  with_real_and_xanim = true
  DEB_BUILD_CONFIGURE += --enable-runtime-cpudetection --disable-vidix
endif




___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#578615: audacity: segfault in libasound.so.2.0.0

2010-04-21 Thread Adrian Knoth 
On Wed, Apr 21, 2010 at 11:01:00AM +0200, Alex Wilk wrote:

> Version: 1.3.12-2
> Severity: normal
> 
> Audacity does not start:
> kernel: [583559.281926] audacity[11674]: segfault at 0 ip
> 0033f1c567e3 sp 7fff2e62a0c0 error 4 in
> libasound.so.2.0.0[33f1c0+de000]

Just a little comment: the very same version works fine (read: starts)
for me, but I'm testing on i686 (instead of amd64) with pure Debian
unstable.

Any chance you could provide a backtrace? (see
, especially section 3)


Cheerio

-- 
mail: a...@thur.de  http://adi.thur.de  PGP/GPG: key via keyserver



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#578615: audacity: segfault in libasound.so.2.0.0

2010-04-21 Thread Jonas Smedegaard 

Hi Alex,

Thanks for the bugreport,

On Wed, Apr 21, 2010 at 11:01:00AM +0200, Alex Wilk wrote:

Package: audacity
Version: 1.3.12-2
Severity: normal


Audacity does not start:
kernel: [583559.281926] audacity[11674]: segfault at 0 ip 0033f1c567e3 sp 
7fff2e62a0c0 error 4 in libasound.so.2.0.0[33f1c0+de000]

(Severity normal because it's testing)


If you mean to say that grave bugs are not grave when occuring as part 
of a non-stable environment, then I believe you are wrong: severity 
should be tagged independent from suite.


Please elaborate.


Kind regards,

 - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Bug#578615: audacity: segfault in libasound.so.2.0.0

2010-04-21 Thread Alex Wilk 
Package: audacity
Version: 1.3.12-2
Severity: normal


Audacity does not start:
kernel: [583559.281926] audacity[11674]: segfault at 0 ip 0033f1c567e3 sp 
7fff2e62a0c0 error 4 in libasound.so.2.0.0[33f1c0+de000]

(Severity normal because it's testing)

hth.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'testing'), (500, 
'testing-proposed-updates'), (500, 'proposed-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32.2 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages audacity depends on:
ii  audacity-data  1.3.12-2  A fast, cross-platform audio edito
ii  libasound2 1.0.22-2  shared library for ALSA applicatio
ii  libc6  2.10.2-6  Embedded GNU C Library: Shared lib
ii  libexpat1  2.0.1-4+lenny3XML parsing C library - runtime li
ii  libflac++6 1.2.1-1.2 Free Lossless Audio Codec - C++ ru
ii  libflac8   1.2.1-1.2 Free Lossless Audio Codec - runtim
ii  libgcc11:4.4.2-9 GCC support library
ii  libglib2.0-0   2.24.0-1  The GLib library of C routines
ii  libgtk2.0-02.18.6-1~bpo50+1  The GTK+ graphical user interface 
ii  libid3tag0 0.15.1b-10ID3 tag reading library from the M
ii  libjack0   0.118+svn3796-2   JACK Audio Connection Kit (librari
ii  libmad00.15.1b-4 MPEG audio decoder library
ii  libogg01.1.3-4   Ogg Bitstream Library
ii  libsamplerate0 0.1.7-3   Audio sample rate conversion libra
ii  libsndfile11.0.21-2  Library for reading/writing audio 
ii  libsoundtouch1c2   1.3.1-2   sound stretching library
ii  libstdc++6 4.4.2-9   The GNU Standard C++ Library v3
ii  libtwolame00.3.12-1  MPEG Audio Layer 2 encoding librar
ii  libvamp-hostsdk3   2.1-1 helper library for Vamp hosts writ
ii  libvorbis0a1.2.0.dfsg-3.1+lenny1 The Vorbis General Audio Compressi
ii  libvorbisenc2  1.2.0.dfsg-3.1+lenny1 The Vorbis General Audio Compressi
ii  libvorbisfile3 1.2.0.dfsg-3.1+lenny1 The Vorbis General Audio Compressi
ii  libwxbase2.8-0 2.8.10.1-3wxBase library (runtime) - non-GUI
ii  libwxgtk2.8-0  2.8.10.1-3wxWidgets Cross-platform C++ GUI t

Versions of packages audacity recommends:
ii  libavcodec52   5:0.5+svn20100208-0.1 library to encode decode multimedi
ii  libavformat52  5:0.5+svn20100208-0.1 ffmpeg file format library

Versions of packages audacity suggests:
ii  libmp3lame0   3.98.2-0.5 LAME Ain't an MP3 Encoder
ii  swh-plugins [ladspa-plugin]   0.4.15-0.2 Steve Harris's LADSPA plugins
ii  vcf [ladspa-plugin]   0.0.5-5audio EQ biquad filters for LADSPA

-- no debconf information



___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Re: packaging jack...

2010-04-21 Thread Jonas Smedegaard 

On Tue, Apr 20, 2010 at 07:48:26PM -0500, Gabriel M. Beddingfield wrote:


On Tue, 20 Apr 2010, Jonas Smedegaard wrote:


Let me then adjust and refine my proposal (main point is the same):

[snip]


It was suggested to discuss the introduction of the virtual 
libjack-0.116.0 on d-devel.  I consider that unnecessary as it is 
coordinated only amongst 3 packages that are all maintained by us.  
But if someone finds it relevant and


I don't understand the libjack-0.116.0 thing.  Is that going to be 
the package name?  If so, that sounds like we would be repeating the 
libjack0.100.0 mistake.


It is more like an add-on tag, indicating the library ABI.

Each implementation will have their own package names, and then in 
addition they will all claim to provide a _virtual_ package name called 
"libjack0.100.0".  So not like earlier (which was before I got involved 
in the team, so I only know of the result, not the considerations behind 
it).


If upstream had a more strict coding style (and if I understand it 
correctly, I am a scripter myself, not a coder, so looking at it from 
aside), then they would probably instead have bumped the SONAME and we 
would not use an odd version like this but just use "libjack1" as the 
tag name.


We could also use "libjack-2010" or "jack-lib-new-generation" if those 
better indicate what is common across the implementations.  Do upstream 
perhaps have an internal codename for the unification/freeze that we 
could reuse?



Later it might make sense to try support officially linking against 
alternate implementations. If that works out, it might make sense to 
repackage jackd1 similar to the others, so as to treat all 
implementations as equal competitors.  But that is post Squeeze IMO.


An alternative to keep from holding up squeeze could be: keep things as 
they are currently... with Jack 1.  Keep Jack 2 in sid (or something) 
so users can upgrade to it if they want.  Meanwhile, the proposal 
sounds odd because of the way that the package names relate and the 
0.116.0 thing.


This is contained in my proposal: Just tag the newly added 
implementations with a dummy release-critical bugreport to keep them 
from trickling into testing and from there to stable, and you have 
"things as they are currently".


What I propose goes _beyond_ that, though.  It is a no-brainer to revert 
our git to status quo, but what then?  I did not put timestamps on each 
step but it _is_ an ordered list, and if some step fail or gets stalled, 
then the affected packages will not reach Squeeze in time for the 
release.  In other words, if something (or someone - e.g. ftpmaster) 
turns out to not work right, then what will for sure stay in the archive 
and get shipped with Squeeze be jackd1.



Right now going from jack1->jack2 is a clean upgrade because of the 
version numbers... so (for me) that would be fine. This all hit the 
fan because it's hard for users to go from jack2->jack1 because they 
have to force a downgrade and the LAD list was told that squeeze 
would ship with Jack 2.


Indeed.  My proposal puts first priority on keeping what we know is 
stable (and what turns out to not be abandoned upstream after all), and 
it puts second a way to try switch not only from one implementation to 
one other (that's easy) but from a single implementation to a choice of 
multiple ones.  Not multiple ones installed concurrently, but multiple 
mutually conflicting ones available for installation concurrently.



Regards,

 - Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers