Re: packaging jack - cross-distro coordination
On Fri, Apr 23, 2010 at 01:48:01PM +0200, Reinhard Tartler wrote: > > * 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 think adi should decide on this. And AFAIUI, adi has already decided > to go with jackd2. Sorry for kicking in late, I'm horribly busy at the moment. Will hopefully change after 2010-04-28 (project deadline). > His arguments were pretty convincing that jackd2 was the best > implementation for squeeze. Ok guys, after an endless thread of major and minor technical issues, I "suggest" the following. If you want, consider this "suggestion" a "rule", though I would personally never ever insist on deciding here. Anyway, I've been the most active jackd maintainer recently, so somebody needs to step forward. ;) We instantly switch to jackd2. End of the story. Ok, it's not actually the end of the story, but we first make progress and upload jackd2 to unstable. This way, our worst case scenario is jackd2-only in squeeze. And that's better than jackd1-only. Why? Because torbenh said so. ;) We know that jackd2 is working, and it currently provides the one important feature required for desktop users: pulseaudio integration, so PA and jackd can coexists without major tweaks like ripping off PA, shutting down applications blocking the audio device and the lot. Torben said: "If you can only have one implementation, then jackd2 is probably the best." Ok, so somebody will upload jackd2 within one week. This is where the story continues... We *then* try to support multiple jackd packages. I'm pretty sure this will work, we've already outlined all the details, Garbiel and Torben even hacked a prototype within 15 minutes. If we'll be fast enough to get this into squeeze... well, I think it's mainly copy and paste, the actual work is probably no more than one hour for somebody who knows what he's doing (Reinhard, Jonas). > - decide on a default implementation jackd2. > - allow users to switch and use a non-default implementation Absolutely. 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
Re: packaging jack - details on "plan B"
On Fri, Apr 23, 2010 at 05:52:35PM -0500, Gabriel M. Beddingfield wrote: >> On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote: >>> [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach >> >> Note that this is a wiki and the suggestions come from only one person. > > True, but Nedko (the author of the article) shouldn't be ignored. He is > very knowledgeable and respected in the LAD/Jack communities. > > Furthermore, he is saying the exact same thing that Torben and I have > been saying. I mostly agree with the suggested packaging except "jackd", "jackdbus" and "jack server library" being separate packages. Not that it'd be wrong, but the amount of packages seems unnecessarily high. There are even people who suggest to put everything in a single jackd1/jackd2 package, but we probably don't want to go this far. -- 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
GREETINGS
Hello, Do you need a loan to enhance your business? Loan to consolidate your debt,Loan for personal use, Loan for credit Card, Medical Care loan, Car Loan,Mortgage Loan, Student Loan, loan for any purposes? e.t.c.Here comes the Good news,MR.MARK WILFORT, The loan giant is out with the Yearly loan offer, Get loan at 3% interest rate annually, Hurry up now and fill out this below application details if interested,Contact Via: markwilfortloanvent...@rediffmail.com APPLICATION DETAILS Full Names--- Gender:___ Age Contact Address: Country:__ State:__ Amount Needed as Loan:___ Loan Duration: Occupation:___ _ Purpose for Loan: Have you apply for loan before?--- Phone: ___ WAY TO FINANCIAL FREEDOM!!! Regard, MR.MARK WILFORT ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: [...@drcomp.erfurt.thur.de: RFP: tschack -- Another implementation for the JACK api written in C. Supports SMP]
On Wed, Apr 21, 2010 at 02:23:10PM +0200, Adrian Knoth wrote: > Hi! > > As requested by Jonas, here's the RFP. Is there any reason not to begin trying out approaches to supporting switching jack implementations with packages in experimental? I could probably be of more use with something to test than I am by trying to participate in the discussion of what to do when. -edrz ___ 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"
On Fri, 23 Apr 2010, Eric Dantan Rzewnicki wrote: On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote: [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach Note that this is a wiki and the suggestions come from only one person. True, but Nedko (the author of the article) shouldn't be ignored. He is very knowledgeable and respected in the LAD/Jack communities. Furthermore, he is saying the exact same thing that Torben and I have been saying. Thanks, Gabriel ___ 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"
On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote: > Hi guys, > I'm new to the details of deb packaging... so I may be replying to the > wrong snippets... but: > [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach Note that this is a wiki and the suggestions come from only one person. -edrz ___ 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"
On Fri, Apr 23, 2010 at 02:29:00PM +0200, Reinhard Tartler wrote: On Wed, Apr 21, 2010 at 14:16:36 (CEST), Jonas Smedegaard wrote: 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? ping? Sorry, not sure I understand the question. Without virtually providing jackd, the jackd2 package does not, well, provide jackd. It will work for packages just wanting _any_ jackd. Packages like Ardour that are picky about the version of jackd will need to explicitly state which version of the alternative implementation (if at all) is acceptable. Did that answer your question? As indicated in the other mail, we have two objectives: a) switch the default implementation b) rearrange packaging to support switching the used implementation [...] You seem to insist on deciding a) before b), while I'd rather see b) implemented before a), No, I explicitly as step 1 *postpone* switching. Long term I want jackd2 as default. I just do not want to switch before supportive mechanisms for multiple concurrent implementations are properly in place. Seems we actually agree, just talk past each other here :-) (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) You're right, I fear step b) will be technically challenging and I offer my experience from a similar trick in the FFmpeg packages to review its implementation. It seems you miss my point (contained in the paragraph above which you snipped, if I recall correctly): If you feel that the plan is utterly broken, cannot work, will meet a dead end mid way, is impossible(!) to implement, then let us discuss fully and in detail untill either agreeing to drop the plan or agreeing that it seems doable. If, on the other hand, you feel that the plan will be "technically challenging" but otherwise is sane, then I strongly suggest to not discuss in details all steps of it, but instead discuss when (or if) problems are spotted while implementing. 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. Which is more or less what I propose. So my proposal does not conflict with yours, but optionally includes it. Great. :-) 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? Yes, because I think we really can and should implement this for squeeze! You believe we can work fast, and therefore you want us to discuss more before we start working? Even if we do not disagree on the steps, only on details within some of the (later) steps? Do you only fear that I forgot some details, or do you fear that it is impossible to implement at all like I drafted, even with carefully composed package relations? I fear that your proposal would require all jack implementation packages to be aware of all other "competing" implementation packages. I fail to imagine how my *plan* could cause such situation. It very much sounds like ugly _implementaiont_ of that plan. And something that can easily be fixed by adjusting minor packaging hints - not something broken in the overall plan, and thus not something relevant to stall the work for discussing ahead IMHO. So yes, I'm more and more convinced that this should work. "this" being your proposal or mine? Or did I (again) misunderstand? 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
Re: packaging jack - details on "plan B"
Hi Jonas, On Fri, 23 Apr 2010, Jonas Smedegaard wrote: [3] Going backwards has never been promised, though. A program compiled against 0.118.0 will work with 0.34.0. However, the use of weak symbols for new features may make this available. Isn't it exactly "going backwards" if jackd2 becomes the default and jackd1 only an optional alternative? Then applications are compiled against jackd2 and potentially using jackd1 at runtime. Is that assured to work too, or only hopefully working if weak symbols work out as planned? Jack2/Jack1 are API-synchronized. Here are the sync points that have been published: JACK1JACK2 REF --- - 0.118.0 1.9.4 [1] 0.116.2 1.9.1 [2], [3] It is reasonable to expect that a program compiled against Jack2 1.9.1 will work fine with 0.116.2. Note also that the API changes since 0.109.0 (the first stable JACK MIDI release) have been minor. (Adding weak symbols, internal changes, documentations, internal header reorg.) HTH, Gabriel [1] http://jackaudio.org/node/28 [2] http://jackaudio.org/node/23 [3] http://jackaudio.org/node/22 ___ 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"
On Fri, Apr 23, 2010 at 02:32:45PM -0500, Gabriel M. Beddingfield wrote: Therefore, any old program will work without recompile on a new libjack0. Jack 2 (formerly jackdmp) has also rigorously maintained binary compatability with Jack 1.[3] [...] [3] Going backwards has never been promised, though. A program compiled against 0.118.0 will work with 0.34.0. However, the use of weak symbols for new features may make this available. Isn't it exactly "going backwards" if jackd2 becomes the default and jackd1 only an optional alternative? Then applications are compiled against jackd2 and potentially using jackd1 at runtime. Is that assured to work too, or only hopefully working if weak symbols work out as planned? 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
Re: packaging jack - cross-distro coordination
On Fri, Apr 23, 2010 at 01:48:01PM +0200, Reinhard Tartler wrote: On Wed, Apr 21, 2010 at 13:30:55 (CEST), Jonas Smedegaard wrote: 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. I don't see a reason to delay this. Details follow. Understood (although I do not agree). Sorry for too simplified summary of options - that was not intentional. Generally speaking [...], 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 think adi should decide on this. And AFAIUI, adi has already decided to go with jackd2. He visited me a few weeks ago at my workplace here (he happened to be around for a workshop at my university) and we discussed the pro and cons for the various jack implementations. His arguments were pretty convincing that jackd2 was the best implementation for squeeze. NB: I don't use jack myself, so I don't consider myself qualified to actually backup such a decision. I just point out the results of the previous discussions on this topic. Regarding earlier decision: I believe previous discussions could be summarized as this list of choices: a) Release Squeeze only with jackd1 b) Release Squeeze only with jackd2, replacing jackd1 I got the impression that even if an option of shipping with both was discussed briefly, it died due to a general assumption that jackd2 was the natural successor of jackd1 and thus keeping both around would only be for the sake of slower transistion (i.e. irrelevant if a faster switch was deemed realistic). Regarding options: Let me try summarize anew, given my new understanding (dropping potentially provocative names): a) Stay with jackd1, ignoring jackd2 and tchack. b) Switch to jackd2, abandoning jackd1 and ignoring tchack. c) switch to supporting multiple implementations. Let me try summarize anew, given my new understanding (dropping potentially provocative names): a) Release Squeeze only with jackd1 b) Release Squeeze only with jackd2, replacing jackd1 c) Release Squeeze with jackd1 as default, and optionally jackd2 d) Release Squeeze with jackd2 as default, and optionally jackd1 I agree that adi already decided on b). But at a time when jackd1 seemed dying and jackd2 its natural replacement - just a question of when to switch. Options like c) and d) was only considered as a more gentle transition method, which was later deemed unnecessary. In other words, it is not my impression that adi already decided on d). I do not want jackd1 as default due to being best, but due to being most tested. We are close to release, so any radical is risky. Switching from jackd1 to jackd2 as default (or only) library and daemon is a radical change, which we agreed to do anyway. Implementing support for multiple implementations of the JACK interfaces is yet another radical change. Two radical changes is one too many IMHO. Replacing jackd1 because we consider it obsolete seemed a valid argument for me to take the risk. But doing it not because we consider it obsolete but because we consider it still valid just less interesting is too weak argument for a too big risk this late in the game IMO. I sincerely want jackd2 as default in a multi-implementation scenario. I just feel that we are too close to release to make multiple risky steps. You (or adi?) want this: 1) replace jackd1 with jackd2 2) readd jackd1 differently named as optional alternative Both of those are risky: The first might reveal problems when recompiling against claimed compatible but potentially not in reality compatible library API and daemon runtime ABI. The second might cause problems in designing package interrelations correctly, and (depending on degree of offered replacements) linking and compiling issues as well. I want this instead: 1) keep jackd1 as is at first 2) add jackd2 as optional alternative 3) switch around to have jackd2 as default At each step we may run out of time and ship that with Squeeze. It makes better sense for me to risk shipping only something too boring for professionals to use but not broken, rather than something maybe broken and not discovered as such in time because we were busy complicating things even furthere. I wanted to push jackd2 back when it was seen as the only future, only a question on when to make the
Re: packaging jack - details on "plan B"
Hi guys, I'm new to the details of deb packaging... so I may be replying to the wrong snippets... but: 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. Then let's make all applications to depend on 'libjack0-0.116.0', which refers to the ABI, and provide a package 'jack-defaults', which builds a meta-package 'jackd' which depends on the distribution chosen 'default' jack implementation. I don't understand why we're emphasizing the ABI of `libjack0-0.116.0'. According to the Jack devs, a program compiled against Jack 0.34.0 (released ca. 2001) is still binary-compatible with /any/ Jack implementation (whether Jack1, Jack2, tschack, etc.) They have rigorously been maintaining this. Therefore, any old program will work without recompile on a new libjack0. Jack 2 (formerly jackdmp) has also rigorously maintained binary compatability with Jack 1.[3] Therefore, the virtual package should be `libjack0', not `libjack0-0.116.0'. See also [1] and [2]. Also, I'm sure you're on top of it, but it's important that this: $ gcc -o foo `pkg-config --cflags --libs jack` foo.cpp ...does the right thing with: $ dpkg-shlibdeps foo Thanks, Gabriel [1] http://trac.jackaudio.org/wiki/SuggestedPackagingApproach [2] http://subversion.jackaudio.org/jack/tags/RELEASE_0_118_0/README.developers [3] Going backwards has never been promised, though. A program compiled against 0.118.0 will work with 0.34.0. However, the use of weak symbols for new features may make this available. ___ 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"
On Fri, Apr 23, 2010 at 07:35:28AM -0400, Eric Dantan Rzewnicki wrote: On Fri, Apr 23, 2010 at 10:55:20AM +0200, Jonas Smedegaard wrote: If I get no response on this by sunday, and noone else objects, I will go ahead with my proposed plan. I've tried to follow this as closely as I can, but I am new to packaging so not qualified to discuss the specifics. However, from what I do understand I do not see a consensus, yet. Also, I would ask that we restate and clarify the proposed scheme and give upstream a chance to comment. NB: though torben is truly awesome, he is not the only upstream developer. Thanks for the response. I shall not touch the libjack packaging (even step one that I find glaring and obvious) until others have explicitly requested so and not been disputed by others on this list. - 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: tremor (libivorbis) on mips
On Fri, Apr 23, 2010 at 14:32, Reinhard Tartler wrote:
> On Thu, Apr 22, 2010 at 21:47:05 (CEST), Thorsten Hirsch wrote:
>> decoding ogg on my mips based nas device is slower than real-time, so
>> it's not really usable here.
>> I've already done some research on this and I think the reason is that
>> the mips cpu has no fpu, so floating point calculations are really
>> slow. Unfortunately libogg is based on floating point calculations.
>> But there's also an integer based version of libogg: tremor (or is it
>> called libivorbis?). It's also available in ffmpeg (there's a
>> configure parameter "--enable-tremor" or something like that)
>>
>> And here's my question to you: is it possible to use tremor-enabled
>> packages on mips instead of the normal ones? Can you provide something
>> like a ffmpeg (libavcodec) package on mips that depends on libivorbis
>> instead of libvorbis?
>
> If the debian-mips porters confirm that there are FPU enabled mips
> machines, or they are at least pretty uncommon, then I think we should
> add this switch for mips only. CC'ing debian-mips for their feedback on
> this.
>
>> I know I can compile everything myself, but I'd like to see a
>> beautiful solution with debian packages. :-)
>
> indeed. Would you mind filing a bug against ffmpeg so that we don't look
> track of this discussion? Please also X-Debbugs-CC: debian-mips.
FWIW, on the RBTX4927, which has a 200 MHz TX4927 (with FPU), mpd
uses ca 25% of the CPU while playing ogg files, in a Debian userland.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: tremor (libivorbis) on mips
--- On Fri, 4/23/10, Reinhard Tartler wrote: > From: Reinhard Tartler > (CEST), Thorsten Hirsch wrote: > > > decoding ogg on my mips based nas device is slower > than real-time, so > > it's not really usable here. > > I've already done some research on this and I think > the reason is that > > the mips cpu has no fpu, so floating point > calculations are really > > slow. Unfortunately libogg is based on floating point > calculations. > > But there's also an integer based version of libogg: > tremor (or is it > > called libivorbis?). It's also available in ffmpeg > (there's a > > configure parameter "--enable-tremor" or something > like that) > > > > And here's my question to you: is it possible to use > tremor-enabled > > packages on mips instead of the normal ones? Can you > provide something > > like a ffmpeg (libavcodec) package on mips that > depends on libivorbis > > instead of libvorbis? > > If the debian-mips porters confirm that there are FPU > enabled mips > machines, or they are at least pretty uncommon, then I > think we should > add this switch for mips only. CC'ing debian-mips for their > feedback on > this. Here's the deal. The mips port covers desktop mips systems such as SGI's and embedded mips devices such as PDA's. Desktop mips chips have decent floating point units, while embedded mips chips traditionally have not. Traditionally, the desktop mips have usually run big endian, and the embedded have usually been little endian. (I did say "usually".) The mips port has been divided into separate mips and mipsel builds. Thus you may be able to accomplish such a change without offending too many people by targeting mipsel for either the fast integer library, or possibly using -msoft-float as a general build-option for the media libaries. (The -msoft-float flag causes gcc to emit emulation code in the binary itself, thus avoiding the costly overhead of the kernel emulation for the missing FPU.) The newer embedded mips chips sometimes do have traditional FPU, or more likely some flavor of SIMD. I'm not aware for general, widespread support for the mips SIMD that is out there yet, but it may happen thanks to the wide spread demand for embedded multi-media devices. Cheers, -S- ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#578918: libdvbpsi5: new upstream 0.1.7
Package: libdvbpsi5 Version: 0.1.6 Severity: wishlist hi, a new upstream just appeared in http://download.videolan.org/pub/libdvbpsi/0.1.7/ a. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (450, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-4-686 (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libdvbpsi5 depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib libdvbpsi5 recommends no packages. libdvbpsi5 suggests no packages. -- Andrea Mennucc "E' un mondo difficile. Che vita intensa!" (Tonino Carotone) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#578917: Please include Catalan translation for the VLC desktop file
Package: vlc Version: 1.0.5-2 Tags: l10n, patch The VLC .desktop file is missing a Catalan translation. I've included it in the attached patch against the current git tree. It would be great if it could be included in the source package. Thanks! From 5ff62f01a2ead5458b33f7fd215fd4594f384218 Mon Sep 17 00:00:00 2001 From: David Planella Date: Fri, 23 Apr 2010 15:47:53 +0200 Subject: [PATCH] Added Catalan translation to the desktop menu entry --- share/applications/vlc.desktop |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/share/applications/vlc.desktop b/share/applications/vlc.desktop index a8f5f5b..28a3fd1 100644 --- a/share/applications/vlc.desktop +++ b/share/applications/vlc.desktop @@ -2,6 +2,8 @@ Version=1.0 Name=VLC media player Comment=Read, capture, broadcast your multimedia streams +Name[ca]=Reproductor multimèdia VLC +Comment[ca]=Reproduïu, captureu i difoneu fluxos multimèdia Name[es]=Reproductor multimedia VLC Comment[es]=Lea, capture y emita sus contenidos multimedia Name[fr]=Lecteur multimédia VLC -- 1.7.0.4 signature.asc Description: Això és una part d'un missatge signada digitalment ___ 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)
Modified: trunk/libvo/vo_directfb2.c == --- trunk/libvo/vo_directfb2.c Thu Apr 22 16:02:20 2010(r31057) +++ trunk/libvo/vo_directfb2.c Fri Apr 23 12:04:56 2010(r31058) @@ -35,9 +35,9 @@ #include #ifdef __linux__ -#include -#else #include +#else +#include #endif #include "config.h" You could really use everywhere: http://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/sys/kd.h;hb=HEAD I should probably note that GNU/kFreeBSD uses same kernel as FreeBSD, but libc/gcc/binutils same as Linux. is there a directfb port available on FreeBSD? I suspect not. I do not understand meaning of this question. There are no gfxdrivers, but the library exists: http://packages.debian.org/sid/kfreebsd-amd64/libdirectfb-1.2-9/filelist http://packages.debian.org/sid/kfreebsd-amd64/libdirectfb-extra/filelist Cheers Petr ___ 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)
I can understand your position if you are only a porter and not a direct maintainer of a package. However, I have seen package maintainers in different distros duplicate each other's work and add hacks to their packages that I could have fixed quicker and cleaner if somebody had shared their problems with me. I'm just letting you know the upstream position. We want to hear about issues and we want the patches. Everybody's life gets easier if work gets upstreamed. Just look how quick we managed to get GNU/kfreebsd building, it was a matter of hours after we received the reports. And now that it's upstream nobody will have extra work maintaining patches again... Unfortunately, I have to repeat again that not every upstream is responsive as you, see i.e. [2] From my POV, ideal cooperation is as in [3], I as a porter really don't know enough details of a package. Or even when the porting problem comes from package maintainer [4]. And this case, of course ;-) Thanks Petr [2] http://sourceforge.net/tracker/index.php?func=detail&aid=2179778&group_id=36127&atid=416300 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578023 [4] http://lists.debian.org/debian-bsd/2010/02/msg00022.html ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Re: tremor (libivorbis) on mips
On Thu, Apr 22, 2010 at 21:47:05 (CEST), Thorsten Hirsch wrote: > Hi, > > decoding ogg on my mips based nas device is slower than real-time, so > it's not really usable here. > I've already done some research on this and I think the reason is that > the mips cpu has no fpu, so floating point calculations are really > slow. Unfortunately libogg is based on floating point calculations. > But there's also an integer based version of libogg: tremor (or is it > called libivorbis?). It's also available in ffmpeg (there's a > configure parameter "--enable-tremor" or something like that) > > And here's my question to you: is it possible to use tremor-enabled > packages on mips instead of the normal ones? Can you provide something > like a ffmpeg (libavcodec) package on mips that depends on libivorbis > instead of libvorbis? If the debian-mips porters confirm that there are FPU enabled mips machines, or they are at least pretty uncommon, then I think we should add this switch for mips only. CC'ing debian-mips for their feedback on this. > I know I can compile everything myself, but I'd like to see a > beautiful solution with debian packages. :-) indeed. Would you mind filing a bug against ffmpeg so that we don't look track of this discussion? Please also X-Debbugs-CC: debian-mips. -- 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 - details on "plan B"
On Wed, Apr 21, 2010 at 14:16:36 (CEST), Jonas Smedegaard wrote: > >>> 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? ping? >>> 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! As indicated in the other mail, we have two objectives: a) switch the default implementation b) rearrange packaging to support switching the used implementation I think b) can and should be done independently on the choice of a), which means any change to packaging needs to work even if stick with jack1. Therefore, there is no reason to loose time with planning and starting the upcoming jackd transition. > 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. You seem to insist on deciding a) before b), while I'd rather see b) implemented before a), because a) [switching the default implementation] is technically much easier to implement than b) [packaging changes], which requires rebuilds of existing packages and therefore takes potentially a lot of time (build time, coordination with the release team, etc). > 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 think this is essential for implementing and reviewing the implementation of step b). > (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) You're right, I fear step b) will be technically challenging and I offer my experience from a similar trick in the FFmpeg packages to review its implementation. >>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. Then let's make all applications to depend on 'libjack0-0.116.0', which refers to the ABI, and provide a package 'jack-defaults', which builds a meta-package 'jackd' which depends on the distribution chosen 'default' jack implementation. This is similar to the 'gcc-defaults' and 'python-defaults' packages. > 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. It depends on the package. Of course there are packages that only work with a specific libjack implementation. The most prominent example for this are the respective jack daemon packages. These packages do need a shlibs.local to override our default libjack shlibs file. This can and probably will also affect some other jack application packages. > 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. Which is more or less what I propose. > 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 c
Bug#578622: mplayer: FTBFS on kfreebsd-amd64 (vidix disable needed)
On Fri, Apr 23, 2010 at 12:57:33PM +0200, Petr Salinger wrote: > >> That was helpful, fixed upstream. >> >> I once again reiterate my suggestion to pass problems to upstream first >> before attempting to work around them locally in the packaging >> infrastructure of a single distribution. > > The expected workflow is a different one. Let the package does not build > on a particular architecture. Iff it is detected by porter (me), porter > tries to find the cause or provide workaround/fix/hints. They go to > Debian BTS, package maintainer evaluates them and integrates into package > and forward upstream. In some cases the package maintainer is upstream > author or have commit rights into upstream repository, some upstream > authors look after bug entries in some distribution. > > Please take a look at [1], click on bottom on "Toggle all extra > information". There is at about 16000 source packages in Debian. It > cannot be managed to comunicate with every of thousands upstreams > directly. Moreover the entry in BTS signals for other porters, that the > problem is known and its state. I can understand your position if you are only a porter and not a direct maintainer of a package. However, I have seen package maintainers in different distros duplicate each other's work and add hacks to their packages that I could have fixed quicker and cleaner if somebody had shared their problems with me. I'm just letting you know the upstream position. We want to hear about issues and we want the patches. Everybody's life gets easier if work gets upstreamed. Just look how quick we managed to get GNU/kfreebsd building, it was a matter of hours after we received the reports. And now that it's upstream nobody will have extra work maintaining patches again... Diego ___ 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 - cross-distro coordination
On Wed, Apr 21, 2010 at 13:30:55 (CEST), Jonas Smedegaard wrote: 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. I don't see a reason to delay this. Details follow. >> 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 think adi should decide on this. And AFAIUI, adi has already decided to go with jackd2. He visited me a few weeks ago at my workplace here (he happened to be around for a workshop at my university) and we discussed the pro and cons for the various jack implementations. His arguments were pretty convincing that jackd2 was the best implementation for squeeze. NB: I don't use jack myself, so I don't consider myself qualified to actually backup such a decision. I just point out the results of the previous discussions on this topic. > 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. The future in the short term seems to including competing yet binary compatible implementations of jack. We as a distribution can (and I think also should) fulfill the following goals: - decide on a default implementation - allow users to switch and use a non-default implementation When torben mailed our mailing list, I didn't have the impression that he advocated jack1 to be the default; au contraire, I think he even supported the decision to go with jackd2 (but I may be wrong here). He merrily asked to consider the 2nd point, so that he is in a position to provide drop-in 3rd party packages on the jack1 website that don't require to have all applications rebuilt. > 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. I think we have to face two different changes: a) switch the default implementation b) restructure the packaging so that users can switch from one implementation to another one. I don't see the reason to wait with a) (adi discussed this months! ago on this mailing list), and for b), I have technical concerns. But let's discuss them in the other thread. > 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. Which is a good example why we should continue to make technical sound decisions, but has nothing to do with the fact that adi is now in a very difficult position with his correspondence with other distros. -- 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#578622: mplayer: FTBFS on kfreebsd-amd64 (vidix disable needed)
On Fri, Apr 23, 2010 at 12:57:33 (CEST), Petr Salinger wrote: > The build for mplayer from current SVN snapshot, without any flags > passed to configure on kfreebsd-amd64: > > cc .. -c -o libvo/vo_dfbmga.o libvo/vo_dfbmga.c > libvo/vo_dfbmga.c: In function 'get_image': > libvo/vo_dfbmga.c:1352: warning: cast to pointer from integer of > different size > libvo/vo_dfbmga.c: In function 'draw_image': > libvo/vo_dfbmga.c:1369: warning: cast from pointer to integer of > different size > cc -MD -MP -Wstrict-prototypes -Wmissing-prototypes -Wundef > -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement > -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 > -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE > -Ilibdvdread4 -I. -I/usr/local/include -D_THREAD_SAFE > -I/usr/include/directfb -I/usr/include/kde/artsc -pthread > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -I/usr/include/freetype2-c -o libvo/vo_directfb2.o > libvo/vo_directfb2.c > Glibvo/vo_directfb2.c:40:22: error: linux/kd.h: No such file or directory > make: *** [libvo/vo_directfb2.o] Error 1 I've committed a fix in trunk a few hours ago. > > It is needed to pass "--disable-directfb" to finish build. > > When I do this: > > --- libvo/vo_directfb2.c~ 2010-04-23 06:15:06.0 +0200 > +++ libvo/vo_directfb2.c2010-04-23 10:24:06.0 +0200 > @@ -34,11 +34,7 @@ > #include > #include > > -#ifdef __linux__ > #include > -#else > -#include > -#endif > > #include "config.h" > #include "video_out.h" > > > The build ends with: > > cc -MD -MP -Wstrict-prototypes -Wmissing-prototypes -Wundef > -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement > -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 > -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE > -Ilibdvdread4 -I. -I/usr/local/include -D_THREAD_SAFE > -I/usr/include/directfb -I/usr/include/kde/artsc -pthread > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT > -I/usr/include/freetype2-c -o libvo/vo_directfb2.o > libvo/vo_directfb2.c > In file included from libvo/vo_directfb2.c:40: > libvo/video_out.h:272: error: redefinition of 'struct keymap' > make: *** [libvo/vo_directfb2.o] Error 1 > > > There is already "struct keymap" defined in system header > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/kbio.h > > Would be possible to use a different name in > , i.e. "struct vo_keymap" ? fixed in trunk as well by renaming to struct mp_keymap. > I should probably note that GNU/kFreeBSD uses same kernel as FreeBSD, > but libc/gcc/binutils same as Linux. is there a directfb port available on FreeBSD? I suspect not. -- 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 - details on "plan B"
On Fri, Apr 23, 2010 at 10:55:20AM +0200, Jonas Smedegaard wrote: > Hi Reinhard and others, > On Wed, Apr 21, 2010 at 02:16:36PM +0200, Jonas Smedegaard wrote: >> On Wed, Apr 21, 2010 at 12:26:41PM +0200, Reinhard Tartler wrote: >>> 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 I understand your concern correctly, it is easily handled using >> "Replaces:". >> I deliberately did not go into such details, as I can easily imagine >> lots of details being forgotten, but cannot imagine it eventually done >> right. >> >> In other words: Do you only fear that I forgot some details, or do you >> fear that it is impossible to implement at all like I drafted, even >> with carefully composed package relations? > Ping! >>> (If it works) my idea would allow this; and without having each and >>> every implementation to declare conflicts against every existing >>> other implementation. >> Sorry, I lost track: Could you please, in a differently named >> subthread, repeat your proposal? > Ping! > > If I get no response on this by sunday, and noone else objects, I will > go ahead with my proposed plan. > > Please do respond - I realy do want input on this, and may very well > have missed something obvious to oters that make the plan not work out > at all. > > Also, please do speak up if anyone feels they made earlier proposals > still valid to compare against. I sincerely apologize if missing out on > them - I lost track of it in these discussions, and did not find/take > the time to go through the whole thread to isolate them. I've tried to follow this as closely as I can, but I am new to packaging so not qualified to discuss the specifics. However, from what I do understand I do not see a consensus, yet. Also, I would ask that we restate and clarify the proposed scheme and give upstream a chance to comment. NB: though torben is truly awesome, he is not the only upstream developer. -edrz ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
Bug#571549: marked as done (Opening filename without any extension crashes lives)
Your message dated Fri, 23 Apr 2010 12:27:21 +0200 with message-id <4bd17609.3020...@phys.ethz.ch> and subject line Opening filename without any extension crashes lives has caused the Debian Bug report #571549, regarding Opening filename without any extension crashes lives 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.) -- 571549: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571549 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: lives Version: 1.1.8-2 Severity: normal Open any filename without an extension (I tried and was able to crash with text file "README", empty file "foo", and avi file "video") --- lives crashes. I simply open the file using "Open File" menu item. $ touch foo $ lives -debug LiVES 1.1.8 Copyright 2002-2009 Gabriel Finch (salsa...@xs4all.nl) and others. LiVES comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details. Unfortunately LiVES crashed. Please report this bug at http://sourceforge.net/tracker/?group_id=64341&atid=507139 Thanks. Recovery should be possible if you restart LiVES. When reporting crashes, please include details of your operating system, distribution, and the LiVES version (1.1.8) and any information shown below: #0 0xb7efc424 in __kernel_vsyscall () #1 0xb744af0b in waitpid () from /lib/i686/cmov/libpthread.so.0 #2 0xb7746a6a in g_on_error_stack_trace () from /lib/libglib-2.0.so.0 #3 0x08058c4b in ?? () #4 #5 0xb69f4cd0 in ?? () from /tmp/livestmp//520151788/dv_decoder.so #6 0xb69f5013 in get_clip_data () from /tmp/livestmp//520151788/dv_decoder.so #7 0x0806b062 in ?? () #8 0x080f5df5 in ?? () #9 0x080f681f in ?? () #10 0x0813018f in ?? () #11 0xb7806544 in g_cclosure_marshal_VOID__VOID () #12 0xb77f8de3 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #13 0xb780cf0f in ?? () from /usr/lib/libgobject-2.0.so.0 #14 0xb780e359 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #15 0xb780e7b6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #16 0xb7b99b7a in gtk_button_clicked () from /usr/lib/libgtk-x11-2.0.so.0 #17 0xb7dca729 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #18 0xb7c58293 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #19 0xb77f8de3 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #20 0xb780cf0f in ?? () from /usr/lib/libgobject-2.0.so.0 #21 0xb780e359 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #22 0xb780e7b6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #23 0xb7d52d98 in gtk_tree_view_row_activated () #24 0xb7d650ab in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #25 0xb7c59f66 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #26 0xb77f7569 in ?? () from /usr/lib/libgobject-2.0.so.0 #27 0xb77f8de3 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #28 0xb780cbb7 in ?? () from /usr/lib/libgobject-2.0.so.0 #29 0xb780e1ef in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #30 0xb780e7b6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #31 0xb7d761b6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #32 0xb7c526fc in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 #33 0xb7c53b77 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 #34 0xb7adc57a in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #35 0xb776cf28 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #36 0xb77706b3 in ?? () from /lib/libglib-2.0.so.0 #37 0xb7770b7a in g_main_loop_run () from /lib/libglib-2.0.so.0 #38 0xb7c53f09 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #39 0x0805dde9 in ?? () #40 0xb72ecb55 in __libc_start_main (main=0x805d880, argc=2, #41 0x08054dd1 in ?? () -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lives depends on: ii frei0r-plugins 1.1.22git20090409-2 minimalistic plugin API for video ii imagemagick 7:6.5.8.3-1 image manipulation programs ii libasound2 1.0.21a-1shared library for ALSA applicatio ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit ii libavc1394-00.5.3-1+b2 control IEEE 1394 audio/video devi ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libdv4 1.0.0-2
bristol_0.60.0-4_i386.changes ACCEPTED
Accepted: bristol-data_0.60.0-4_all.deb to main/b/bristol/bristol-data_0.60.0-4_all.deb bristol_0.60.0-4.diff.gz to main/b/bristol/bristol_0.60.0-4.diff.gz bristol_0.60.0-4.dsc to main/b/bristol/bristol_0.60.0-4.dsc bristol_0.60.0-4_i386.deb to main/b/bristol/bristol_0.60.0-4_i386.deb Override entries for your package: bristol-data_0.60.0-4_all.deb - optional sound bristol_0.60.0-4.dsc - source sound bristol_0.60.0-4_i386.deb - optional sound 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/mailman/listinfo/pkg-multimedia-maintainers
Re: packaging jack - details on "plan B"
Hi Reinhard and others, On Wed, Apr 21, 2010 at 02:16:36PM +0200, Jonas Smedegaard wrote: On Wed, Apr 21, 2010 at 12:26:41PM +0200, Reinhard Tartler wrote: 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 I understand your concern correctly, it is easily handled using "Replaces:". I deliberately did not go into such details, as I can easily imagine lots of details being forgotten, but cannot imagine it eventually done right. In other words: Do you only fear that I forgot some details, or do you fear that it is impossible to implement at all like I drafted, even with carefully composed package relations? Ping! (If it works) my idea would allow this; and without having each and every implementation to declare conflicts against every existing other implementation. Sorry, I lost track: Could you please, in a differently named subthread, repeat your proposal? Ping! If I get no response on this by sunday, and noone else objects, I will go ahead with my proposed plan. Please do respond - I realy do want input on this, and may very well have missed something obvious to oters that make the plan not work out at all. Also, please do speak up if anyone feels they made earlier proposals still valid to compare against. I sincerely apologize if missing out on them - I lost track of it in these discussions, and did not find/take the time to go through the whole thread to isolate them. 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#578622: mplayer: FTBFS on kfreebsd-amd64 (vidix disable needed)
Hi. That was helpful, fixed upstream. I once again reiterate my suggestion to pass problems to upstream first before attempting to work around them locally in the packaging infrastructure of a single distribution. The expected workflow is a different one. Let the package does not build on a particular architecture. Iff it is detected by porter (me), porter tries to find the cause or provide workaround/fix/hints. They go to Debian BTS, package maintainer evaluates them and integrates into package and forward upstream. In some cases the package maintainer is upstream author or have commit rights into upstream repository, some upstream authors look after bug entries in some distribution. Please take a look at [1], click on bottom on "Toggle all extra information". There is at about 16000 source packages in Debian. It cannot be managed to comunicate with every of thousands upstreams directly. Moreover the entry in BTS signals for other porters, that the problem is known and its state. [1] http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=kfreebsd;users=debian-...@lists.debian.org The build for mplayer from current SVN snapshot, without any flags passed to configure on kfreebsd-amd64: cc .. -c -o libvo/vo_dfbmga.o libvo/vo_dfbmga.c libvo/vo_dfbmga.c: In function 'get_image': libvo/vo_dfbmga.c:1352: warning: cast to pointer from integer of different size libvo/vo_dfbmga.c: In function 'draw_image': libvo/vo_dfbmga.c:1369: warning: cast from pointer to integer of different size cc -MD -MP -Wstrict-prototypes -Wmissing-prototypes -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4 -I. -I/usr/local/include -D_THREAD_SAFE -I/usr/include/directfb -I/usr/include/kde/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT -I/usr/include/freetype2-c -o libvo/vo_directfb2.o libvo/vo_directfb2.c Glibvo/vo_directfb2.c:40:22: error: linux/kd.h: No such file or directory make: *** [libvo/vo_directfb2.o] Error 1 It is needed to pass "--disable-directfb" to finish build. When I do this: --- libvo/vo_directfb2.c~ 2010-04-23 06:15:06.0 +0200 +++ libvo/vo_directfb2.c2010-04-23 10:24:06.0 +0200 @@ -34,11 +34,7 @@ #include #include -#ifdef __linux__ #include -#else -#include -#endif #include "config.h" #include "video_out.h" The build ends with: cc -MD -MP -Wstrict-prototypes -Wmissing-prototypes -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -Ilibdvdread4 -I. -I/usr/local/include -D_THREAD_SAFE -I/usr/include/directfb -I/usr/include/kde/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT -I/usr/include/freetype2-c -o libvo/vo_directfb2.o libvo/vo_directfb2.c In file included from libvo/vo_directfb2.c:40: libvo/video_out.h:272: error: redefinition of 'struct keymap' make: *** [libvo/vo_directfb2.o] Error 1 There is already "struct keymap" defined in system header http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/kbio.h Would be possible to use a different name in , i.e. "struct vo_keymap" ? I should probably note that GNU/kFreeBSD uses same kernel as FreeBSD, but libc/gcc/binutils same as Linux. Petr ___ 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-4_i386.changes
bristol_0.60.0-4_i386.changes uploaded successfully to localhost along with the files: bristol_0.60.0-4.dsc bristol_0.60.0-4.diff.gz bristol_0.60.0-4_i386.deb bristol-data_0.60.0-4_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
kmidimon_0.7.3-1_amd64.changes ACCEPTED
Accepted: kmidimon_0.7.3-1.diff.gz to main/k/kmidimon/kmidimon_0.7.3-1.diff.gz kmidimon_0.7.3-1.dsc to main/k/kmidimon/kmidimon_0.7.3-1.dsc kmidimon_0.7.3-1_amd64.deb to main/k/kmidimon/kmidimon_0.7.3-1_amd64.deb kmidimon_0.7.3.orig.tar.gz to main/k/kmidimon/kmidimon_0.7.3.orig.tar.gz Override entries for your package: kmidimon_0.7.3-1.dsc - source sound kmidimon_0.7.3-1_amd64.deb - optional sound 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/mailman/listinfo/pkg-multimedia-maintainers
Processing of kmidimon_0.7.3-1_amd64.changes
kmidimon_0.7.3-1_amd64.changes uploaded successfully to localhost along with the files: kmidimon_0.7.3-1.dsc kmidimon_0.7.3.orig.tar.gz kmidimon_0.7.3-1.diff.gz kmidimon_0.7.3-1_amd64.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
Re: Possible problems in your Debian packages
On Mon, Apr 19, 2010 at 12:25:30 (CEST), Adrian Knoth wrote: > On Mon, Apr 19, 2010 at 07:40:30AM +0200, Reinhard Tartler wrote: > >> > === Packages with a new upstream version according to DEHS: >> > kmidimon 0.7.2 (Debian: 0.7.1-1) > > We have version 0.7.3 ready to be uploaded since 2010-03-10 in our git > repository: > >http://git.debian.org/?p=pkg-multimedia/kmidimon.git;a=summary > > Since the last upload was lacking DM-Upload-Allowed, may I kindly ask > for an upload? uploaded -- 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
