___ ! GLÜCKWÜNSCHE GEWINN NR.:GOOGLE-1029375-2011! ___
VOM SCHREIBTISCH
DIE LEITUNG INTERNATIONALEN BEFOERDERUNGEN
GOOGLE INTERNATIONAL INC.
ENGLAND AUSSENSTELLE
Belgrave House
76 Buckingham Palace Road
London SW1W 9TQ
United Kingdom
===
REF NR.: GOOGLE-0293856-2011
***
GEWINN NR.:GOOGLE-1029375-2011
***
DATUM: 03.10.2011
***
BETRAG:EUR 1.000.000,00
***
GEBIET: EUROPA
***
PROGRAMM: GOOGLE WOHLTÄTIGKEITSFONDS 2011.
===
___ ! GLÜCKWÜNSCHE GEWINN NR.:GOOGLE-1029375-2011! ___
Google International Inc. hiermit verkündet die Ergebnisse von
Google Wohltätigkeitsfonds fuer 2011 E-Mail-Adresse Gewinn [fuer
Europaeische Einwohner] Programm mit.Die endgueltige Programme wurden
auf dem 02. Oktober 2011 in Aachen,Deutschland gehalten.Ihre
E-Mailadress ist als ein Gewinner fuer den Geldpreis vom EUR
1.000.000,00 (EINE MILLION EUROS) gewaehlt worden.Dies Ergebnis ist
jetzt zu Ihnen heute 03. Oktober 2011 freigegeben und Ihre
E-Mail-Adresse, die in der Einer Kategorie befestigt wird,hat EUR
1.000.000,00 (EINE MILLION EUROS)gewonnen.
Diese Programme wurde von den Google International Inc. und die unten
genannten Firmen fundiert:
1. Microsoft Incoporation
2. Aol
3. Calsberg
4. Becks
5. Coca-Cola
6. Mercedez Benz
7. Suisse Credit
8. Raiffeisen Bankgruppe
9. Allianz
10.Volkswagen
11.Nokia
12.Siemens
Alle E-Mail-Adressen wurden automatisch durch ein
Computerstimmzettelsystem ausgewaehlt, in den Ihre Email-Adresse als
einer der ZEHN {10} gluecklichen Gewinner ausgewaehlt wurde.
Andere Gewinner aus Europa in Ihrer Kategorie lautet:
1. Dr. Joerg Schuster - Aus Basel, Schweiz
2. Frau Linda Reichert- Aus Linz, Oesterreich
3. Herr Ivan Boranov- Aus Moscow, Russland
4. Herr Jacques Van Belweek- Aus Antwerp, Belgien
5. Frau Inge Schneider- Aus Stuttgart, Deutschland
6. Pfarrer Luis Mendez-Aus Mallorca, Spanien
7. Frau Lisa Collini-Aus Milan, Italien
8. Ing. Johannsen Bergkramp-Aus Copenhagen, Denmark
9. Herr Gary Morgan- Aus Liverpool, England.
Alle E-mail Adressen wurde von den Europaeischen Union{EU}
Einwohnerverzeichnis und Internet Benutzer Databanken aus dem ganzen
Europa Gebiet ausgewaehlt.
Ihre Ticket Nummer lautet:-846594 .und Glueckszahl 5 Sie werden
geraten, Ihre siegreichen Informationen vertraulich {SEHR GEHEIM} zu
behalten, bis Ihre Ansprueche und Ihr Geld bearbeitet worden sind, das
zu Ihnen ueberwiesen werden wird.Dies ist ein Teil von unserem
Sicherheitsprotokoll,um Doppelbeanspruchen und ungerechtfertigten
Missbrauch von diesem Programm durch Schwindel zu vermeiden.
Sie muessen Ihr Gewinn nicht spaeter als am 20th. Oktober 2011
beansprucht werden.Nach diesem Datum, wird alle unbeanspruchten Fonds
zu unserem Zentralebuero (alsnicht beansprucht) zurueckgekehrt werden
.Bitte merken Sie, um unnoetige Verspaetungen und Komplikationen zu
vermeiden,erinnern Sie sich immer an Ihre REF NR.: Google-0293856-2011
in allen von Ihren Korrespondenz mit uns zu zitieren. Wir bitten Sie,
sich an der Google Wohltätigkeitsfonds 2011 Verarbeitung /Auszahlung
von der Offiziellen Bezahlende Bank {Barclays Bank Plc} zu wenden
{fuer Auszahlung und alle andere wichtige Erklaerungen}:
==
BARCLAYS BANK PLC.
BUERO VON VERARBEITUNG UND AUSZAHLUNG,
GOOGLE WOHLTÄTIGKEITSFONDS 2011
ANSPRECHPERSON: Frau Rose Trevor
E-mail: trevor.ros...@googlemail.com
LONDON, ENGLAND
==
Fuer die Verarbeitung und Auszahlung von Ihrem Gewinn ,fuellen Sie
sofort die unten Form und reichen Sie es zu Google E-mail
Wohltätigkeitsfonds 2011 Verarbeitung / Auszahlung von der
Offiziellen Bezahlende Bank {Barclays Bank Plc} Frau Rose Trevor Durch
E-mail ein: trevor.ros...@googlemail.com
***
GOOGLE WOHLTÄTIGKEITSFONDS 2011 GEWINNER ANMELDEFORMULAR FUER
ZAHLUNG .
***
VORNAME:...
GEBURTSDATUM:..
NACHNAME:..
GESCHLECHT:
ADRESSE:...
NATIONALITAET:.
Re: request sponsor/upload for pd-pdstring
On Sun, 2011-10-02 at 12:16 -0400, Hans-Christoph Steiner wrote: I find that Launchpad is a good place to test new packages. Can you also use it to test against Debian releases? If yes, how? I think you have a launchpad account already, so it should be easy. I always upload my packages to my launchpad before submitting them for upload to Debian. So far, I haven't remembered how to use cowbuilder or pbuilder... an uploading to launchpad has stuck. (Am I right in thinking that launchpad.net also uses pbuilder?) Thanks for the tip. I'm actually using pbuilder-dist from the ubuntu-dev-tools packages which is also available in Debian. It's a wrapper around pbuilder that allows for easy deployments of different Ubuntu and Debian distros. Roman ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: request sponsor/upload for pd-pdstring
On Sat, 2011-10-01 at 14:11 +0200, Roman Haefeli wrote: On Fri, 2011-09-30 at 17:02 +0200, IOhannes m zmölnig wrote: i'm not entirely sure though (given the nastiness of [declare]) if you think that it is a bug in puredata-core, please file a bugreport. Yeah, that is indeed the case. Before filing a bug report, I'd like to clear up the meanings of the different paths. /usr/lib/pd/extra Am I right in assuming that this path is supposed to be searched by all flavors of Pd (all packages that provide the virtual package pd)? This also the path where usually external libraries are installed to because from there they can be loaded from any flavor of pd? /usr/lib/puredata/extra is only searched by puredata / pd from the puredata package? This is where libraries are installed that only are suitable for the pd provided by the puredata package? /usr/lib/pd-extended/extra is only searched by pdextended / pd from the pd-extended package? Libs that are only useful with pdextended go there? If that is the case, then there is definitely a bug in the puredata-core package as it is ignoring /usr/lib/pd/extra. This also means, that currently all Pd libraries in unstable that install to /usr/lib/pd/extra (most of them do) are currently broken, as there is no proper way to actually load them in pd (you still can specify the absolute path to the library, which renders your patch unportable to other OS'). Let me refine this: Since Pd-vanilla in Debian was moved to from /usr/lib/pd to /usr/lib/puredata, some Debian-specific patches were necessary to correct paths. There is also a patch that adds /usr/lib/pd to puredata's search paths. This means that single-object libraries such as pd-wiimote and pd-readanysf still work flawlessly, since if you instantiate [wiimote] puredata will find /usr/lib/pd/extra/wiimote/wiimote.pd_linux. The problem here is that [declare]'s '-stdpath' and '-stdlib' flags show no effect for /usr/lib/pd/extra. Probably it got forgotten to make [declare] not only expand the (new) native /usr/lib/puredata/extra path, but also /usr/lib/pd/extra. This sound to me like a bug in the Debian packaging. On a sidenote: The fact that [declare -lib pdstring] loads the library is contradictory to the [declare]'s documentation. The '-lib' flag should only load libraries relative to the patch's path. But this is an issue that is apparent also in upstream (probably since 0.41). This is probably not the right place to ask, but why is puredata packaged in a different team than all the pd-libraries? This is a bit of an unlucky situation. Roman ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: request sponsor/upload for pd-pdstring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-03 09:19, Roman Haefeli wrote: This is probably not the right place to ask, but why is puredata packaged in a different team than all the pd-libraries? mainly because of legacy reasons. the current maintainer (paul), has not shown any inclination on moving the puredata package to pkg-multimedia. i think this should be respected. This is a bit of an unlucky situation. why? if the only reason is to not have to include paul's address in such discussions, then i think it is a rather lame excuse. (apart from that, it is mainly me who is responsible for the changes in question, and you do reach me via this group.) fmgasdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6JY74ACgkQkX2Xpv6ydvRPmgCdFIGsmRC8nepWrtj5nmxxUsbx bEMAnRuKVC42fKxaI1kKOGMkF64nqWFL =3U/R -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic 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
Re: request sponsor/upload for pd-pdstring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-01 14:11, Roman Haefeli wrote: On Fri, 2011-09-30 at 17:02 +0200, IOhannes m zmölnig wrote: extra/pdstring/pdstring.pd_linux, so it should probably read -stdlib extra/pdstring/pdstring. '-stdlib extra/pdstring/pdstring' is supposed to work as well but should not be necessary at all. Pd normally checks also folders with the lib name for libs. When specifying mylib, both extra/mylib.pd_linux and extra/mylib/mylib.pd_linux are searched. indeed, this is true (Pd's loader being more clever than i thought); sorry for the noise masdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6JZFQACgkQkX2Xpv6ydvRSLwCgyz0jzhxl0G6eBCg79anhOvX5 7OQAnjPTF7OAvCpNfSdG1uu9eaj6PFj8 =SAtJ -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic 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
launchpad builders, was: request sponsor/upload for pd-pdstring
On Mo, Okt 03, 2011 at 08:56:00 (CEST), Roman Haefeli wrote: On Sun, 2011-10-02 at 12:16 -0400, Hans-Christoph Steiner wrote: I find that Launchpad is a good place to test new packages. Can you also use it to test against Debian releases? If yes, how? No, launchpad builds in ubuntu chroots only. I think you have a launchpad account already, so it should be easy. I always upload my packages to my launchpad before submitting them for upload to Debian. So far, I haven't remembered how to use cowbuilder or pbuilder... an uploading to launchpad has stuck. (Am I right in thinking that launchpad.net also uses pbuilder?) No, launchpad uses the same software as used on the debian buildds: sbuild (although it may be patched a bit differently) Thanks for the tip. I'm actually using pbuilder-dist from the ubuntu-dev-tools packages which is also available in Debian. It's a wrapper around pbuilder that allows for easy deployments of different Ubuntu and Debian distros. TBH, I've found that sbuild/schroot (with aufs overlays) are a bit easier to setup than pbuilder-dist, but of course YMMV. Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
where is Pd's -stdlib? (was Re: request sponsor/upload for pd-pdstring)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 @pd-dev: in the course of making packages for debian, we discovered another slight problem with the -stdpath and -stdlib flags for declare (and probably this also expands to the -nostdpath startup flag). following is an excerpt of the discussion in the debian packaging team: On 2011-10-01 14:11, Roman Haefeli wrote: On Fri, 2011-09-30 at 17:02 +0200, IOhannes m zmölnig wrote: i'm not entirely sure though (given the nastiness of [declare]) if you think that it is a bug in puredata-core, please file a bugreport. Yeah, that is indeed the case. Before filing a bug report, I'd like to clear up the meanings of the different paths. /usr/lib/pd/extra Am I right in assuming that this path is supposed to be searched by all flavors of Pd (all packages that provide the virtual package pd)? This also the path where usually external libraries are installed to because from there they can be loaded from any flavor of pd? /usr/lib/puredata/extra is only searched by puredata / pd from the puredata package? This is where libraries are installed that only are suitable for the pd provided by the puredata package? /usr/lib/pd-extended/extra is only searched by pdextended / pd from the pd-extended package? Libs that are only useful with pdextended go there? If that is the case, then there is definitely a bug in the puredata-core package as it is ignoring /usr/lib/pd/extra. it might as well be a bug in puredata upstream (that's why i want to discuss it; probably a more appropriate place for discussion is the pd-dev mailinglist which i include in the recipients) imho, the issue boils down to the question what are stdpaths? (and i assume that stdlibs are std because they live in stdpaths). for the sake of simplicity, i will only talk about the linux version of Pd (and with Pd i mean Pd-vanilla) before Pd-0.43 (vanilla!), there was only a single stdpath, which was the path were the Pd binaries lived in. this usually was /usr/local/lib/pd/ or /usr/lib/pd/ since 0.43, a few more paths have been added, namely: /usr/local/lib/pd-externals and ~/pd-externals on Debian and derivatives, yet another path is added: since Pd is installed into /usr/lib/puredata/ (in order to allow pd-extended live side by side with puredata), the path /usr/lib/pd is also added as a common system-managed search path. now all these paths are handled separately from the user defined search-paths; e.g. they do not show up in the path dialog, and they can be disabled with the -nostdpaths flag. otoh, [declare] has not adapted to these changes. if you add -stdpath extra/foo, it will only search in /usr/local/lib/pd/extra/foo (given that pd is installed in /usr/local/lib/pd), but it will not search in /usr/local/lib/pd-externals/extra/foo nor in ~/pd-externals/extra/foo. (the same applies for the additional Debian-specific search path /usr/lib/pd/extra/foo). hence i do think that the problem is general problem with Pd-vanilla (and not specific to Debian; it only shows here) This also means, that currently all Pd libraries in unstable that install to /usr/lib/pd/extra (most of them do) are currently broken, as there is no proper way to actually load them in pd (you still can specify the absolute path to the library, which renders your patch unportable to other OS'). you could also simply start Pd with -lib foo and it will just work. so i wouldn't consider all broken. obviously, we lack the possibility to express a library dependency within the patch, which is a shame (but which is also due to the current broken implementation of [declare] in general). anyhow, what i'm mainly asking is, whether std prefixed declare options and the std prefixed cmdline flags are supposed to work on the same standard. if so, does this mean to be exclusive (e.g. only have the Pd install path) or inclusive (additionally have /usr/local/lib/pd-externals/ and ~/pd-externals/ (and on debian the additional /usr/lib/pd/extra/) i generally tend towards an inclusive solution, though i'm not 100% sure whether this is the user expectancy with regards to ~/pd-externals/ fgm,asdr IOhannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6JajEACgkQkX2Xpv6ydvSVzgCgh78s7H3JNu5Ev/dhl3i2CxWj lPAAn2o/jopO8jnzi+Z6rRkUXxkCkO08 =rmN+ -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic 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
Re: [SCM] crtmpserver/master: Split package to 4 parts
I noticed crtmpserver on PET hanging around, waiting for a reviewer and I took a look at it. On Fr, Jul 29, 2011 at 15:04:17 (CEST), Andriy Beregovenko wrote: Hi, On Thursday 28 July 2011 14:04:39 Alessio Treglia you wrote: On Thu, Jul 28, 2011 at 8:25 AM, jet-gu...@users.alioth.debian.org wrote: The following commit has been merged in the master branch: commit 589879437b6083106bb2ffa4a09ec6fff7cd5b0c Author: Andriy Beregovenko j...@jet.kiev.ua Date: Thu Jul 28 01:31:05 2011 +0300 Split package to 4 parts libs will install only basic libs (common and thelib) apps will install only applications main will install main binary, doc, examples, init script and basic configuration file \o/ What's the rationale? In fact, this software is the platform that consists of several components: - the main component library; - applications that use these libraries; - actually the main executable file / daemon and supported files like docs, configs etc... We can install only crtmpserver-libs and crtmpserver-dev and makes own software. Do you do this? Do you have any indication that there are users doing this? I'm asking because I notice the libs are installed in a private path, so this isn't directly accessible. Of course you can override this with proper linker paths, but there is neither documentation nor helper scripts/pkg-config files that would assist with that. Moreover, the package descriptions don't really explain what's going on, so I have doubts that the split in the current form is helpful for the users. I also note that the .orig.tar gz is an svn checkout. Please use 'svn export' instead. For the next upload (the package is RC buggy atm, after all), what shall we do? Shall we revert the fix, or do we want to keep it? Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] crtmpserver/master: Split package to 4 parts
Hi Reinhard, Yeah, I see. Thanks alot. So there are question: Right not script get-orig-source is not actual, and do not make effective result. To import my version of script(which I actually use for import sources) I need to know next: what must be result of script execution ? Fresh source tree? Fresh source repacked tree ? With debian directory ? As tar(.gz) archive ? If this is described in some place, please point me the there. Also package not complete yet so there was no need to remove the binary package crtmpserver(from control) :) I'll finish this package for a few days. Also there is old question: in which way I can release old version with incremented minor version, if my master git-branch goes forward from old version? Make git brach and point tag to it ? On Mon, Oct 03, 2011 at 10:21:22AM +0200, Reinhard Tartler wrote: I noticed crtmpserver on PET hanging around, waiting for a reviewer and I took a look at it. On Fr, Jul 29, 2011 at 15:04:17 (CEST), Andriy Beregovenko wrote: Hi, On Thursday 28 July 2011 14:04:39 Alessio Treglia you wrote: On Thu, Jul 28, 2011 at 8:25 AM, jet-gu...@users.alioth.debian.org wrote: The following commit has been merged in the master branch: commit 589879437b6083106bb2ffa4a09ec6fff7cd5b0c Author: Andriy Beregovenko j...@jet.kiev.ua Date: Thu Jul 28 01:31:05 2011 +0300 Split package to 4 parts libs will install only basic libs (common and thelib) apps will install only applications main will install main binary, doc, examples, init script and basic configuration file \o/ What's the rationale? In fact, this software is the platform that consists of several components: - the main component library; - applications that use these libraries; - actually the main executable file / daemon and supported files like docs, configs etc... We can install only crtmpserver-libs and crtmpserver-dev and makes own software. Do you do this? Do you have any indication that there are users doing this? I'm asking because I notice the libs are installed in a private path, so this isn't directly accessible. Of course you can override this with proper linker paths, but there is neither documentation nor helper scripts/pkg-config files that would assist with that. Moreover, the package descriptions don't really explain what's going on, so I have doubts that the split in the current form is helpful for the users. I also note that the .orig.tar gz is an svn checkout. Please use 'svn export' instead. For the next upload (the package is RC buggy atm, after all), what shall we do? Shall we revert the fix, or do we want to keep it? Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: request sponsor/upload for pd-pdstring
On Fri, 2011-09-30 at 13:24 +0200, IOhannes m zmölnig wrote: debian/control: Depends on pd,but there pd is only a virtual package, and you should provide a real one first. this is also caught by lintian: W: pd-pdstring: virtual-package-depends-without-real-package-depends depends: pd something like this should fix the problem: Depends: puredata-core | pd I followed the suggestion and lintian did not complain anymore. I removed all the puredata/pd related packages from my unstable test system and tried to install the resulting pd-pdstring package with gdebi and got this: $ sudo gdebi pbuilder/sid_result/pd-pdstring_0.10.2-1_amd64.deb Reading package lists... Done Building dependency tree Reading state information... Done Building data structures... Done Building data structures... Done This package is uninstallable Dependency is not satisfiable: pd When I change the dependency for pd-pdstring to 'puredata | pd', it installs fine by installing puredata. I noticed that only the package 'puredata' provides the virtual package 'pd', but 'puredata-core' does not. So, what is the correct setup meant to be? Assuming that pd-libs are running fine with only the core of Pd, shouldn't 'puredata-core' provide 'pd'? Or is intended behavior that installing any pd-lib installs the full 'puredata' suite? Or asked more generally: What is the common practice: depending on the least necessary or depending on then most common setup (whatever that is)? Roman ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
openoctave 2011.1 is out
Hi, It would be good to have this in Debian, it looks really nice. http://www.openoctave.org/ Thanks in advance, \r ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: request sponsor/upload for pd-pdstring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2011-10-03 11:50, Roman Haefeli wrote: system and tried to install the resulting pd-pdstring package with gdebi and got this: $ sudo gdebi pbuilder/sid_result/pd-pdstring_0.10.2-1_amd64.deb Reading package lists... Done Building dependency tree Reading state information... Done Building data structures... Done Building data structures... Done This package is uninstallable Dependency is not satisfiable: pd When I change the dependency for pd-pdstring to 'puredata | pd', it installs fine by installing puredata. I noticed that only the package 'puredata' provides the virtual package 'pd', but 'puredata-core' does not. this is unreproducible for me: $ LANG=C aptitude show puredata | egrep '(Provides|Version)' Version: 0.43.0-4 Provides: pd $ LANG=C aptitude show puredata-core | egrep '(Provides|Version)' Version: 0.43.0-4 Provides: pd So, what is the correct setup meant to be? Assuming that pd-libs are running fine with only the core of Pd, shouldn't 'puredata-core' provide 'pd'? yes, that is why it does provide pd. Or is intended behavior that installing any pd-lib installs the full 'puredata' suite? definitely not. if so, the entire split of puredata into subpackages would have made no sense at all. Or asked more generally: What is the common practice: depending on the least necessary or depending on then most common setup (whatever that is)? personally i have a quite strict opinion on this: Depend on the bare minimum Recommend the most common setup Suggest other possible use-cases i think this is in accordance with the policy [1]. other people might have different opinions. fgmasdr IOhannes [1] http://www.debian.org/doc/debian-policy/ch-relationships.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6JiXMACgkQkX2Xpv6ydvSzxACg83+TKTtpFd8q8kLMfj8vdhAH u+gAoOiLIncv6cOnrSoXP3BKi/9Tz8U/ =enYo -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic 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#644146: Double free in C++ destructor
Package: libffado2
Version: 2.0.99+svn1995-1
A program that is linked with libffado aborts on exit. This command
reproduces the problem:
echo 'int main() {}' |gcc -x c -lffado - ./a.out
Command output follows (amd64):
Cannot create thread 1 Operation not permitted
Cleaning up leftover debug module: DeviceManager
*** glibc detected *** ./a.out: free(): invalid pointer: 0x7fc333e1f9c0 ***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x72606)[0x7fc333924606]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7fc33392933c]
/usr/lib/libffado.so.2(_ZN18DebugModuleManagerD2Ev+0x81)[0x7fc333cf33e1]
/usr/lib/libffado.so.2(+0xbb236)[0x7fc333cf1236]
/lib64/ld-linux-x86-64.so.2(+0xe21c)[0x7fc333e2f21c]
/lib/x86_64-linux-gnu/libc.so.6(+0x36d82)[0x7fc3338e8d82]
/lib/x86_64-linux-gnu/libc.so.6(+0x36dd5)[0x7fc3338e8dd5]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x104)[0x7fc3338d0eb4]
./a.out[0x4004f9]
=== Memory map:
0040-00401000 r-xp 00:13 34146
/tmp/a.out
00401000-00402000 rw-p 00:13 34146
/tmp/a.out
01364000-01385000 rw-p 00:00 0 [heap]
7fc32c00-7fc32c021000 rw-p 00:00 0
7fc32c021000-7fc33000 ---p 00:00 0
7fc330335000-7fc330336000 ---p 00:00 0
7fc330336000-7fc330d37000 rw-p 00:00 0
7fc330d37000-7fc330d73000 r-xp 08:02 4849738
/lib/x86_64-linux-gnu/libpcre.so.3.12.1
7fc330d73000-7fc330f72000 ---p 0003c000 08:02 4849738
/lib/x86_64-linux-gnu/libpcre.so.3.12.1
7fc330f72000-7fc330f73000 rw-p 0003b000 08:02 4849738
/lib/x86_64-linux-gnu/libpcre.so.3.12.1
7fc330f73000-7fc330f76000 r-xp 08:02 797451
/usr/lib/libgmodule-2.0.so.0.2800.6
7fc330f76000-7fc331175000 ---p 3000 08:02 797451
/usr/lib/libgmodule-2.0.so.0.2800.6
7fc331175000-7fc331176000 rw-p 2000 08:02 797451
/usr/lib/libgmodule-2.0.so.0.2800.6
7fc331176000-7fc33118d000 r-xp 08:02 799367
/usr/lib/libz.so.1.2.3.4
7fc33118d000-7fc33138c000 ---p 00017000 08:02 799367
/usr/lib/libz.so.1.2.3.4
7fc33138c000-7fc33138d000 rw-p 00016000 08:02 799367
/usr/lib/libz.so.1.2.3.4
7fc33138d000-7fc33138f000 r-xp 08:02 4850295
/lib/x86_64-linux-gnu/libdl-2.13.so
7fc33138f000-7fc33158f000 ---p 2000 08:02 4850295
/lib/x86_64-linux-gnu/libdl-2.13.so
7fc33158f000-7fc33159 r--p 2000 08:02 4850295
/lib/x86_64-linux-gnu/libdl-2.13.so
7fc33159-7fc331591000 rw-p 3000 08:02 4850295
/lib/x86_64-linux-gnu/libdl-2.13.so
7fc331591000-7fc3315a6000 r-xp 08:02 4849679
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fc3315a6000-7fc3317a6000 ---p 00015000 08:02 4849679
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fc3317a6000-7fc3317a7000 rw-p 00015000 08:02 4849679
/lib/x86_64-linux-gnu/libgcc_s.so.1
7fc3317a7000-7fc331828000 r-xp 08:02 4850218
/lib/x86_64-linux-gnu/libm-2.13.so
7fc331828000-7fc331a27000 ---p 00081000 08:02 4850218
/lib/x86_64-linux-gnu/libm-2.13.so
7fc331a27000-7fc331a28000 r--p 0008 08:02 4850218
/lib/x86_64-linux-gnu/libm-2.13.so
7fc331a28000-7fc331a29000 rw-p 00081000 08:02 4850218
/lib/x86_64-linux-gnu/libm-2.13.so
7fc331a29000-7fc331b15000 r-xp 08:02 1189696
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7fc331b15000-7fc331d14000 ---p 000ec000 08:02 1189696
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7fc331d14000-7fc331d1c000 r--p 000eb000 08:02 1189696
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7fc331d1c000-7fc331d1e000 rw-p 000f3000 08:02 1189696
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16
7fc331d1e000-7fc331d33000 rw-p 00:00 0
7fc331d33000-7fc331e23000 r-xp 08:02 4849897
/lib/libglib-2.0.so.0.2800.6
7fc331e23000-7fc332022000 ---p 000f 08:02 4849897
/lib/libglib-2.0.so.0.2800.6
7fc332022000-7fc332023000 rw-p 000ef000 08:02 4849897
/lib/libglib-2.0.so.0.2800.6
7fc332023000-7fc332024000 rw-p 00:00 0
7fc332024000-7fc33202b000 r-xp 08:02 4850305
/lib/x86_64-linux-gnu/librt-2.13.so
7fc33202b000-7fc33222a000 ---p 7000 08:02 4850305
/lib/x86_64-linux-gnu/librt-2.13.so
7fc33222a000-7fc33222b000 r--p 6000 08:02 4850305
/lib/x86_64-linux-gnu/librt-2.13.so
7fc33222b000-7fc33222c000 rw-p 7000 08:02 4850305
/lib/x86_64-linux-gnu/librt-2.13.so
7fc33222c000-7fc33223 r-xp 08:02 795214
Processing of sord_0.5.0-1_amd64.changes
sord_0.5.0-1_amd64.changes uploaded successfully to localhost along with the files: sord_0.5.0-1.dsc sord_0.5.0.orig.tar.bz2 sord_0.5.0-1.debian.tar.gz libsord-0-0_0.5.0-1_amd64.deb libsord-dev_0.5.0-1_all.deb sordi_0.5.0-1_amd64.deb libsord-doc_0.5.0-1_all.deb sord-dbg_0.5.0-1_amd64.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: [SCM] crtmpserver/master: Split package to 4 parts
On Mo, Okt 03, 2011 at 11:29:40 (CEST), Andriy Beregovenko wrote: Hi Reinhard, Yeah, I see. Thanks alot. So there are question: Right not script get-orig-source is not actual, and do not make effective result. Oh, I wasn't aware of that. Comments explaining this situation would have helped me a lot, please make sure to add such comments in future. To import my version of script(which I actually use for import sources) I need to know next: what must be result of script execution ? Fresh source tree? Fresh source repacked tree ? With debian directory ? As tar(.gz) archive ? That's indeed an interesting question and AFAIUI not entierly agreed on among Maintainers. Debian Policy §4.9 says this: ,[ get-orig-source (optional) | This target fetches the most recent version of the original source | package from a canonical archive site (via FTP or WWW, for example), | does any necessary rearrangement to turn it into the original source tar | file format described below, and leaves it in the current directory. | | This target may be invoked in any directory, and should take care to | clean up any temporary files it may have left. | | This target is optional, but providing it if possible is a good idea. ` I think this has been discussed on debian-devel to death, but here are my personal opinions on this (YMMV, on each point): * the target should fetch the version of the orig.tar.gz that most recent for the current packaging. This may or may not be the latest upstream version * the target should apply any necessary modifications that are necessary to make the tarball suitable for upload. This includes removing files that are not redistributable. Many refer to this as the 'repacked tarball'. * the resulting tarball should not contain any debian/ subdirectory * the result should be placed in ../$packagename_$version.orig.tar.gz (or bz2, if you prefer) * for fetching the *most recent* upstream tarball, uscan seems a better means to me. If this is described in some place, please point me the there. Also package not complete yet so there was no need to remove the binary package crtmpserver(from control) :) I'll finish this package for a few days. Okay, can you in this case please use as upload target 'UNRELEASED' instead of 'unstable' in debian/changelog? This will make the package disappear from http://pet.debian.net/pkg-multimedia/pet.cgi, where crtmpserver is currently in the 'ready to upload' section. Also there is old question: in which way I can release old version with incremented minor version, if my master git-branch goes forward from old version? Make git brach and point tag to it ? Yes, create a new branch in the repository. I've just done so to fix the RC bug and will upload it RSN to unstable. Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: openoctave 2011.1 is out
On Mo, Okt 03, 2011 at 11:51:10 (CEST), rosea grammostola wrote: Hi, It would be good to have this in Debian, it looks really nice. http://www.openoctave.org/ this is known as: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578787 Cheers -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ 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#551935: mplayer: Inconsistency detected by ld.so
submitter 551935 ! thanks * Jakub Wilk uba...@users.sf.net, 2009-10-22, 00:10: $ mplayer /dev/null 21 | tail -n1 Inconsistency detected by ld.so: dl-close.c: 731: _dl_close: Assertion `map-l_init_called' failed! I have not seen this bug triggering for a very long time. Should it be closed? -- Jakub Wilk ___ 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: Re: Bug#551935: mplayer: Inconsistency detected by ld.so
Processing commands for cont...@bugs.debian.org: submitter 551935 ! Bug #551935 [mplayer] mplayer: Inconsistency detected by ld.so Changed Bug submitter to 'Jakub Wilk jw...@debian.org' from 'Jakub Wilk uba...@users.sf.net' thanks Stopping processing here. Please contact me if you need assistance. -- 551935: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551935 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
sord_0.5.0-1_amd64.changes ACCEPTED into unstable
Accepted: libsord-0-0_0.5.0-1_amd64.deb to main/s/sord/libsord-0-0_0.5.0-1_amd64.deb libsord-dev_0.5.0-1_all.deb to main/s/sord/libsord-dev_0.5.0-1_all.deb libsord-doc_0.5.0-1_all.deb to main/s/sord/libsord-doc_0.5.0-1_all.deb sord-dbg_0.5.0-1_amd64.deb to main/s/sord/sord-dbg_0.5.0-1_amd64.deb sord_0.5.0-1.debian.tar.gz to main/s/sord/sord_0.5.0-1.debian.tar.gz sord_0.5.0-1.dsc to main/s/sord/sord_0.5.0-1.dsc sord_0.5.0.orig.tar.bz2 to main/s/sord/sord_0.5.0.orig.tar.bz2 sordi_0.5.0-1_amd64.deb to main/s/sord/sordi_0.5.0-1_amd64.deb Override entries for your package: libsord-0-0_0.5.0-1_amd64.deb - optional utils libsord-dev_0.5.0-1_all.deb - optional libdevel libsord-doc_0.5.0-1_all.deb - optional doc sord-dbg_0.5.0-1_amd64.deb - extra debug sord_0.5.0-1.dsc - source libs sordi_0.5.0-1_amd64.deb - optional text Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Processing of crtmpserver_0.0~dfsg+svn474-2_i386.changes
crtmpserver_0.0~dfsg+svn474-2_i386.changes uploaded successfully to localhost along with the files: crtmpserver_0.0~dfsg+svn474-2.dsc crtmpserver_0.0~dfsg+svn474-2.debian.tar.gz crtmpserver_0.0~dfsg+svn474-2_i386.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: request sponsor/upload for pd-pdstring
On Mon, 2011-10-03 at 12:07 +0200, IOhannes m zmoelnig wrote On 2011-10-03 11:50, Roman Haefeli wrote: I noticed that only the package 'puredata' provides the virtual package 'pd', but 'puredata-core' does not. this is unreproducible for me: Sorry for the noise. It is now for me as well :-/ Or asked more generally: What is the common practice: depending on the least necessary or depending on then most common setup (whatever that is)? personally i have a quite strict opinion on this: Depend on the bare minimum Recommend the most common setup Suggest other possible use-cases Totally makes sense to me. [1] http://www.debian.org/doc/debian-policy/ch-relationships.html Thanks for the link. And sorry again for the noise. Can't even reproduce what I've done (wrong) before. Roman ___ 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: Re: Bug#551935: mplayer inconsistency output goes away when libopenal1 is at version 1:1.10.622-1
Processing commands for cont...@bugs.debian.org: reassign 551935 libopenal1 Bug #551935 [mplayer] mplayer: Inconsistency detected by ld.so Bug reassigned from package 'mplayer' to 'libopenal1'. Bug No longer marked as found in versions mplayer/1.0~rc3+svn20090405-1. fixed 551935 1:1.10.622-1 Bug #551935 [libopenal1] mplayer: Inconsistency detected by ld.so There is no source info for the package 'libopenal1' at version '1:1.10.622-1' with architecture '' Unable to make a source version for version '1:1.10.622-1' Bug Marked as fixed in versions 1:1.10.622-1. stop Stopping processing here. Please contact me if you need assistance. -- 551935: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551935 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
crtmpserver_0.0~dfsg+svn474-2_i386.changes ACCEPTED into unstable
Accepted: crtmpserver_0.0~dfsg+svn474-2.debian.tar.gz to main/c/crtmpserver/crtmpserver_0.0~dfsg+svn474-2.debian.tar.gz crtmpserver_0.0~dfsg+svn474-2.dsc to main/c/crtmpserver/crtmpserver_0.0~dfsg+svn474-2.dsc crtmpserver_0.0~dfsg+svn474-2_i386.deb to main/c/crtmpserver/crtmpserver_0.0~dfsg+svn474-2_i386.deb Override entries for your package: crtmpserver_0.0~dfsg+svn474-2.dsc - source video crtmpserver_0.0~dfsg+svn474-2_i386.deb - optional video Announcing to debian-devel-chan...@lists.debian.org Closing bugs: 642707 Thank you for your contribution to Debian. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: request sponsor/upload for pd-pdstring
All the issue below have been fixed or do not belong to the package in question. I'd be grateful if someone could have a look again and eventually upload it. Cheers Roman On Fri, 2011-09-30 at 16:19 +0200, Roman Haefeli wrote: Hi IOhannes First of all, thanks a lot for having such a thorough look. On Fri, 2011-09-30 at 13:24 +0200, IOhannes m zmölnig wrote: [...] debian/control: current standards-version is 3.9.2 fixed debian/control: Uploaders field has a stray trailing comma oops... fixed. debian/control: any reason why you are so picky about the debhelper version? as jonas has pointed out before (e.g in the recent pd-zexy thread), debhelper-7 is even in oldstable, so you might happily use debhelper. I'm using short-form dh with dh overrides. Lintian tells me that those features are only available since 7.0.50. I read the thread about pd-zexy, but I _think_ the situation might be different there, because it is using cdbs (and thus probably not using dh overrides). http://lintian.debian.org/tags/debhelper-overrides-need-versioned-build-depends.html (i know you care about ubuntu a lot, and i don't know the exact situation there) I'm currently packaging on Debian/unstable and testing on both. I got the exact same lintian warnings/errors on both. debian/control: Depends on pd,but there pd is only a virtual package, and you should provide a real one first. this is also caught by lintian: W: pd-pdstring: virtual-package-depends-without-real-package-depends depends: pd something like this should fix the problem: Depends: puredata-core | pd fixed. debian/copyright: is it really true that moocow holds the copyright for files in debian/? no file in debian/ has an explicit copyright notice (why), but i still doubt that moocow did the debian packaging. fixed also config.* and some other files seem to have different copyright holders Hopefully fixed. If someone could have look, that be nice, as this is the most tedious (I find) and probably rather error-prone part. I was told on #debian-devel, that auto-generated files such as Makefile.in (generated by autotools) are not required to be listed in debian/copyright. So I left them out. Is that compliant with the practice of pkg-multimedia? debian/patches/add-meta-file.patch: this patch is actually unneeded. you could simply put the pdstring-meta.pd into debian/ and install it directly from there btw, you could also use debian/install to install the file, rather than adding a dh_override Converted from patch to a simple debian/install command. debian/README.Debian quite a long line :-) more important, i cannot load pdstring following your advice in README.Debian: [declare -stdlib extra/pdstring] will do nothing (on reload), only [declare -lib pdstring] helps How did you test? The '-lib' flag searches relative to your patch, whereas '-stdlib' searches relative to pd. You only can correctly test it by effectively installing the package and run pd (/usr/bin/pd). However, it turned out, that the advice was not complete, since the library also contains abstractions, which are not found with only '-stdlib extra/pdstring'. The full and correct declaration is: [declare -stdlib extra/pdstring -stdpath extra/pdstring] Yeah, that's a lot for loading only a library, but unfortunately that is how it currently works in Pd. debian/watch it seems that the name is not mangled correctly, i get snip Newest version on remote site is 0.10-2, local version is 0.10.2 pd-pdstring: remote site does not even have current version /snip try something like: opts=uversionmangle=s/-/./ Thanks for the hint. With this I get: uscan warning: malformed opts=... in watchfile, skipping line: I'll look later into that. Roman ___ 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 bugs that does not affect stable
Processing commands for cont...@bugs.debian.org:
# Hi everybody
#
# So I ought to have used found where possible, but I am
# a bit lazy... With this many bugs, I hope you can forgive
# me. :-)
# libav/0.7 transition - does not affect packages in stable
tags 628197 + sid wheezy
Bug #628197 {Done: Aurelien Jarno aure...@debian.org} [xine-lib] xine-lib:
FTBFS with libav 0.7
Added tag(s) sid and wheezy.
tags 638559 + sid wheezy
Bug #638559 {Done: Alastair McKinstry mckins...@debian.org} [vtk] Needs to be
adapted for libav/0.7.1
Added tag(s) sid and wheezy.
tags 638251 + sid wheezy
Bug #638251 {Done: Mathieu Malaterre mathieu.malate...@gmail.com} [vxl] Needs
to be adapted for libav/0.7.1
Added tag(s) sid and wheezy.
tags 638535 + sid wheezy
Bug #638535 {Done: Yavor Doganov ya...@gnu.org} [lynkeos.app] Needs to be
adapted for libav/0.7.1
Added tag(s) sid and wheezy.
tags 638550 + sid wheezy
Bug #638550 {Done: Uwe Hermann u...@debian.org} [miro] Needs to be adapted
for libav/0.7.1
Added tag(s) sid and wheezy.
tags 640562 + sid wheezy
Bug #640562 [motion] FTBFS against libav/0.7.1
Added tag(s) sid and wheezy.
tags 638246 + sid wheezy
Bug #638246 {Done: Anton Gladky gladky.an...@gmail.com} [paraview] Needs to
be adapted for libav/0.7.1
Added tag(s) sid and wheezy.
tags 638244 + sid wheezy
Bug #638244 [picard] Needs to be adapted for libav/0.7.1
Added tag(s) sid and wheezy.
tags 640224 + sid wheezy
Bug #640224 {Done: Iain Lane la...@debian.org} [taoframework] Needs to be
rebuild against libav / 0.7
Added tag(s) sid and wheezy.
tags 638560 + sid wheezy
Bug #638560 [electricsheep] Needs to be adapted for libav/0.7.1
Added tag(s) sid and wheezy.
tags 638245 + sid wheezy
Bug #638245 {Done: Tiago Bortoletto Vaz ti...@debian.org} [ffmpeg2theora]
Needs to be adapted for libav/0.7.1
Added tag(s) sid and wheezy.
tags 640697 + sid wheezy
Bug #640697 [freej] Needs to be adapted for libav 0.7
Added tag(s) sid and wheezy.
tags 638569 + sid wheezy
Bug #638569 {Done: Alessio Treglia ales...@debian.org} [idjc] libav7 patch
needs to be activated
Added tag(s) sid and wheezy.
tags 638546 + sid wheezy
Bug #638546 {Done: Fathi Boudra f...@debian.org} [k3b] Needs to be adapted
for libav/0.7.1
Added tag(s) sid and wheezy.
# dpkg-buildflags did not change in stable :)
tags 644048 + sid wheezy
Bug #644048 [xdvik-ja] xdvik-ja: FTBFS: dpkg-buildflags
Added tag(s) sid and wheezy.
# Dependency appears to be satisfied in stable
tags 623445 + sid wheezy
Bug #623445 {Done: Yves-Alexis Perez cor...@debian.org} [xfce4-wmdock-plugin]
xfce4-wmdock-plugin: cannot be installed due to dependency issue
Added tag(s) sid and wheezy.
# Iceweasel 5.0 was not in stable
tags 635008 + sid wheezy
Bug #635008 {Done: Fabrizio Regalli fab...@fabreg.it}
[xul-ext-all-in-one-sidebar] xul-ext-add-in-one-sidebar: not compatible with
iceweasel 5.0
Added tag(s) sid and wheezy.
# Openjdk-6 did not change its path in stable
tags 641380 + sid wheezy
Bug #641380 {Done: Miguel Landaeta mig...@miguel.cc} [surefire] surefire:
FTBFS: You must specify a valid JAVA_HOME or JAVACMD!
Added tag(s) sid and wheezy.
tags 642036 + sid wheezy
Bug #642036 [umlet] FTBFS: /usr/lib/jvm/java-6-openjdk/bin/javac: not found
Added tag(s) sid and wheezy.
End of message, stopping processing here.
Please contact me if you need assistance.
--
642036: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642036
628197: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628197
638546: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638546
638559: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638559
638244: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638244
638245: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638245
635008: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635008
638569: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638569
623445: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623445
640697: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640697
638550: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638550
640562: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640562
641380: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641380
640224: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640224
638246: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638246
644048: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644048
638535: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638535
638251: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638251
638560: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638560
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
