Re: [SCM] ardour3/master: New upstream revision
On 03/13/2013 02:19 AM, edwardw-gu...@users.alioth.debian.org wrote: > Author: Edward Wang > Date: Tue Mar 12 18:47:57 2013 -0400 > > New upstream revision > > diff --git a/debian/changelog b/debian/changelog > index 2e3b6ac..3e5da3e 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -1,6 +1,11 @@ > -ardour3 (3.0.0~svn10909-1) UNRELEASED; urgency=low > +ardour3 (3.0-1) unstable; urgency=low Nice to see some work on the new A3. I guess we're deep into new territory with packaging A3, since A3 is usually built by building all the dependency libraries when building A3 itself. We certainly don't want embedded copies but rely on the already packaged versions in Debian. Here's a list of build dependencies: http://subversion.ardour.org/svn/ardour2/branches/2.0-ongoing/tools/build-ardour-stack See the defmod section in the middle. We may also need to file a bug report against libgnomecanvas to update the .pc file (see link above, right at the bottom). According to the website, the distro approach hasn't been thoroughly tested, so expect all kinds of problems. And when we fuck it up, upstream will rightfully yell at us, so let's get this right. ;) That said, let me know whenever you need help or somebody to talk to upstream. Cheers ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Atenciosamente;
Atenciosamente;Meu nome é o Sr. Victor Mensah.I sou um gerente de uma instituição financeira. Eu tenho o seu contato do Ministério das Relações Exteriores e do Ministério da Indústria e Comércio Internacional. Preciso de sua ajuda para transferir EUA $ 3,5 milhões.Este dinheiro é parte dos lucros do nosso banco no ano passado (2012). Eu já enviou relatório anual para o ano passado minha sede do banco, em Acra-Gana e eles não perceberam lucros excessivos. Eu depositei a 3,5 EUA $ milhões em uma conta vinculada, sem um beneficiário (Anônimo) para evitar qualquer vestígio.Eu não pode ser diretamente ligado a esse dinheiro, porque eu ainda trabalho com o banco. Então, eu preciso de sua ajuda para transferir esse dinheiro para o seu país para mim e para você compartilhar. Eu ofereço-lhe 45% deste dinheiro como meu parceiro estrangeiro e 55% seria para mim. Não há risco envolvido, porque vai ser uma transferência de banco para banco.Tudo que você precisa é a sua cooperação honesta para nos permitir ver esta operação através de. Se você está interessado e disposto a ajudar (victormensah2...@gmail.com) responda com você detalhesUm. Seu nome completo:2. Sua ocupação / posição no escritório:3. Sua data de nascimento:4. Estado civil:5. nacionalidade:6. O seu endereço de contato total (casa / escritório):7. Seu passaporte internacional:Oito. O seu telefone privado / fax:Eu vou estar ansioso para receber os detalhes acima. Toda a correspondência será via e-mail ou telefone.Atenciosamente,Sr. Victor Mensah. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processed: tagging as pending bugs that are closed by packages in NEW
Processing commands for cont...@bugs.debian.org:
> # Sunday 17 March 19:03:16 UTC 2013
> # Tagging as pending bugs that are closed by packages in NEW
> # http://ftp-master.debian.org/new.html
> #
> # Source package in NEW: href="http://packages.qa.debian.org/handbrake";>handbrake
> tags 691067 + pending
Bug #691067 [handbrake-gtk] handbrake-gtk: Handbrake SIGABRTs while scanning
DVD titles
Added tag(s) pending.
> # Source package in NEW: href="http://packages.qa.debian.org/handbrake";>handbrake
> tags 696471 + pending
Bug #696471 {Done: Fabian Greffrath } [handbrake-cli]
handbrake-cli: Info page for handbrake not present
Added tag(s) pending.
> # Source package in NEW: href="http://packages.qa.debian.org/handbrake";>handbrake
> tags 701039 + pending
Bug #701039 [handbrake] handbrake: libhb/decavcodec.c and
libhb/encavcodecaudio.c in handbrake are missing prototypes
Added tag(s) pending.
> # Source package in NEW: python-stem
> tags 697880 + pending
Bug #697880 [wnpp] ITP: python-stem -- Tor control library for Python
Added tag(s) pending.
>
End of message, stopping processing here.
Please contact me if you need assistance.
--
691067: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691067
696471: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696471
697880: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697880
701039: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701039
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#697144: dir2ogg: Broken sound speed of converted files
TLDR: Please check with current mpg123 snapshot and think about either prescribing format and letting mpg123 write really raw data or make proper use of the improper WAV header. Hello, mpg123 upstream here. I really did not intend to break dir2ogg in various ways. I totally regret touching WAV writing code at all. While I think that it is a bit bold to pipe something like WAV to stdout and expect it to work (many programs really are not happy with the inconsistent headers that this produces, take audacity or even just libsndfile), there are some that could make use of this. Among those are oggenc and lame, for that matter. I do wonder why you have opts=['-r', '-R', str(mutagen.File(self.song).info.sample_rate)] for mpg123 output in dir2ogg. Is this already an attempt to fix broken WAV output by mpg123? If not, I really have to wonder why you do not just use mpg123 -s input.mp3 | ogggenc -r -R $rate -C $channels -B 16 -o output.ogg or rather mpg123 -e s24 -s input.mp3 | ogggenc -r -R $rate -C $channels -B 24 -o output.ogg for avoiding extra quality impact from rounding to 16 bit in between (sadly, oggenc does not seem to support float, which would avoid integer intermediate altogether). Note $channels ... current dir2ogg will screw up if the input is a mono file. It assumes stereo. Thing is, you tell mpg123 to write WAV headers and then tell oggenc to ignore them via -r. That confuses me. If you want raw data, tell mpg123 to deliver raw data to stdout via the -s switch. But, once we got through this mess with the repeatedly messed up WAV-to-stdout (which I always recommend to use with caution only ...), for example using current http://mpg123.org/snapshot, which shall become mpg123 1.16.0, you can just do that: src/mpg123 -w - -e s24 input.mp3 | oggenc -o output.ogg - and have it magically work. Note that the '-e s24' might not be available on certain builds of mpg123. If it is supported, it appears in mpg123 --longhelp in this line: -e --encoding force a specific encoding (s16 u16 u8 s8 ulaw alaw f32 s32 u32 s24 u24) I might add a specific switch to ask about that (mpg123 --list-encodings or such) to 1.16.0, if it's desired. To support all versions of mpg123, you can extend your hack that inserts the sample rate via mutagen and have it provide the full format (including channel count) and just pipe the raw data from mpg123 via -s. The option for s24 format would just reduce the quality loss a bit ... if you care about that when converting between lossy formats;-) Using the WAV output of a minimally required mpg123 >= 1.16.0 would avoid the question of checking which output format is available. People can make different builds of mpg123 that have different (default) sample format (floating point, for example). It's interesting that oggenc and lame are the only tools I found with some quick tests that are happy with the kind of broken WAV you get via pipes. But then, if you intend to store such files, you'd better write them properly. Alrighty then, Thomas signature.asc Description: PGP signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#703200: libav: CVE-2013-0894 CVE-2013-2277 CVE-2013-2495 CVE-2013-2496
On Sat, Mar 16, 2013 at 9:09 PM, Michael Gilbert wrote: > package: src:libav > severity: grave > version: 6:0.8.5-1 > > Hi, the following vulnerabilities were published for libav. These are > currently unfixed in 0.8.5-1. > > CVE-2013-0894[0]: > | Buffer overflow in the vorbis_parse_setup_hdr_floors function in the > | Vorbis decoder in vorbisdec.c in libavcodec in FFmpeg through 1.1.3, > | as used in Google Chrome before 25.0.1364.97 on Windows and Linux and > | before 25.0.1364.99 on Mac OS X and other products, allows remote > | attackers to cause a denial of service (divide-by-zero error or > | out-of-bounds array access) or possibly have unspecified other impact > | via vectors involving a zero value for a bark map size. scheduled for 0.8.6, commit v0.8.5-12-ge050af9 > CVE-2013-2277[1]: > | The ff_h264_decode_seq_parameter_set function in h264_ps.c in > | libavcodec in FFmpeg before 1.1.3 does not validate the relationship > | between luma depth and chroma depth, which allows remote attackers to > | cause a denial of service (out-of-bounds array access and application > | crash) or possibly have unspecified other impact via crafted H.264 > | data. > Scheduled for 0.8.6, commit v0.8.5-19-g9e48d77 > CVE-2013-2495[2]: > | The iff_read_header function in iff.c in libavformat in FFmpeg through > | 1.1.3 does not properly handle data sizes for Interchange File Format > | (IFF) data during operations involving a CMAP chunk or a video codec, > | which allows remote attackers to cause a denial of service (integer > | overflow, out-of-bounds array access, and application crash) or > | possibly have unspecified other impact via a crafted header. Patch proposed: http://patches.libav.org/patch/36075/ We are currently discussing this issue; we are unsure if the fix from FFmpeg is correct. > CVE-2013-2496[3]: > | The msrle_decode_8_16_24_32 function in msrledec.c in libavcodec in > | FFmpeg through 1.1.3 does not properly determine certain end pointers, > | which allows remote attackers to cause a denial of service > | (out-of-bounds array access and application crash) or possibly have > | unspecified other impact via crafted Microsoft RLE data. scheduled for 0.8.6, commit v0.8.5-38-g4160398 > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. Will do. As for the timeline, I actually intended to release 0.8.6 this weekend, but since you have raised these four issues, I'm considering to delay the release for another week to allow further testing, espc. given that one of the issues did not even land in master yet. Thanks for raising these security issues. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
