Re: packages newer in Ubuntu than in Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bart Martens a écrit : Hi Package Maintainers (DD's and non-DD's), Now that Etch is released to stable, many package maintainers have already updated their packages to the newest upstream releases. That is of course very good. However, some packages have no working debian/watch file, and then it is not always easily seen whether there are newer upstream releases available for these packages. I suggest to add/update debian/watch with your next updates of your packages. Non-DD's are welcome to ask help for that on [EMAIL PROTECTED] . Hint: test the debian/watch file with uscan --report-status. Hi, I would be happy to update filezilla package, however it require wxwidgets 2.8 which is available in ubuntu but not in debian. I have no time and not enough knowledge to maintain such a package so I'm just waiting on someone to care about wx2.8. I think we'll have many problems when upstreams will start using wx2.8 new features... Regards, Adam -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGN5TRHNb/igTI5bsRAnvkAJ0aKbMYRfOiYGvCc4f3heLdy2TZBACeOdpn tRuPGJJzAJH3umRdjoLbg7M= =xLyy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: packages newer in Ubuntu than in Debian (reduced false positives)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bart Martens a écrit : On Fri, 2007-05-04 at 08:14 +0200, Bart Martens wrote: On Thu, 2007-05-03 at 23:16 -0500, Peter Samuelson wrote: [Bart Martens] I've thought about adding an column for the versions in experimental, but that is not a high priority to me because this does not change that Debian Unstable is outdated for the listed packages. Uh ... I thought the point of your project was to help package maintainers. Obviously if the maintainer has put something in experimental, he has already done the work to package it! Wouldn't putting the experimental version in your table be _more_ useful than the sid version, if it's newer? It is of course very good that during Etch freeze some packagers have already packaged newer versions in Experimental. I intend to add a column for the versions available in Experimental, to express appropriate appreciation for those packagers. OK for you? Should be better now. http://people.debian.org/~bartm/borg/outdated.html It is true that additionally comparing with Experimental makes the report more useful, as this makes the updated packages in Experimental more visible. It also reveals some packages that outdated in both Unstable and Experimental. Regards, Bart Martens Hi, There's at least one false positive left. See picard package. Regards, Adam. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGQs8DHNb/igTI5bsRAqJTAJ9i9J97ZvcRqUjK3iG7lDdiyjXpQgCeI8bo 1P4Q0DK6xQLqhTYZCk6gIko= =GZze -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Uploading wxWidgets 2.8 to experimental ?
Hi, I already built wx2.8 from ubuntu on my debian lenny for testing purpose. It build and works fine, I have been able to get latest filezilla running without any issues. I would be really happy if you could upload it to unstable, then I'll help fixing bugs if I can and can help you to keep it synced with the ubuntu package. Charles Plessy a écrit : Le Sat, May 26, 2007 at 03:44:56AM +0930, Ron a écrit : offer any proof that we can transition to this release without major breakage in an important application. Dear Ron, I am member of a team which is Maintainer: of a package using wxWidgets. I would be happy to test it against an experimental version of wx2.8, in order to report problems to Upstream. But I am not comfortable enough with library packaging to produce private packages. If the people who depend on wxWidgets would agree to use 2.8 packages just for tests and to not upload uncoordinated upgrades to unstable, would you agree to publish 2.8 packages? Alternatively, would it be OK if a DD would upload Ubuntu's packages to experimental? Have a nice day, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
I (audacious maintainer) have some stuff to add about xmms plugins. Most of them have been merged into audacious and I worked with xmms-crossfade maintainer to build an audacious flavour of this plugins. We should have a look at all xmms-plugins but I'm pretty sure more then 90% are already part of audacious distribution. Regards, Adam. José Miguel Parrella Romero a écrit : The maintainers of the xmms package in Debian are proposing the removal of the aforementioned package. Please read on. 1. Rationale * Upstream has deprecated development and support for the current version of XMMS. * Several parts of the application are broken and no longer of Debian quality. 2. Current status * The BTS reports 231 bugs, most tagged 'important' or 'normal', and a couple of debugging was attempted with little success. * XMMS is broken in several aspects, one of the most important being it's dependence on GTK+ 1.2 and no UTF-8 support, which is standard in Debian Etch. * Other distributions have already discussed XMMS removal. Gentoo hardmasked the package based on the same rationale [1] * 'bmpx' and 'audacious' are in Debian, ranks 8048 and 3649 in popcon. Both are very good and development-active substitutes to xmms. * There's also in Debian the upstream-supported xmms2 package, 2598 in popcon rank. 2.1 Reverse depends The following packages depend on XMMS: xmms-liveice xmms-festalon xmp-xmms xmmsctrl xmms-xf86audio xmms-wmdiscotux xmms-wma xmms-volnorm xmms-synaesthesia xmms-stats xmms-speex xmms-skins xmms-singit xmms-sid xmms-shell xmms-scrobbler xmms-rplay xmms-qbble xmms-osd-plugin xmms-openspc xmms-oggre xmms-musepack xmms-msa xmms-mpg123-ja xmms-mp4 xmms-modplug xmms-mad xmms-lirc xmms-ladspa xmms-kjofol xmms-kde xmms-jess xmms-jackasyn xmms-iris xmms-infopipe xmms-infinity xmms-goom xmms-goodnight xmms-gbs xmms-fmradio xmms-flac xmms-finespectrum xmms-find xmms-dev xmms-dbmix xmms-crossfade xmms-coverviewer xmms-cdread xmms-bumpscope xmms-blursk xmms-arts xmms-alarm xmms-adplug |xfce4-xmms-plugin wmusic superkaramba smpeg-xmms shermans-aquarium rep-xmms python-xmms playground-plugin-xmms |peercast-handlers madman logjam-xmms libxmms-ruby libxmms-perl kvirc2 karamba kadu-external-modules junior-sound imms hotkeys gnump3d gnomp3 gkrellmms gjay gdesklets-data gdancer gaim-xmms-remote |fvwm-crystal extace education-standalone education-music education-desktop-other Most of this packages are xmms plugins. Maintainers will need to port them to xmms2 or bmpx, or they should be removed. Other packages just depend on xmms as a mere multimedia player, and therefore we recommend the maintainers to adjust their dependencies to bmpx, xmms2 or audacious. 2.2 Popcon xmms is now 1069 in the overall popcon rank, with 11029 installations, not counting the plugin users. Yours, the XMMS maintainers [1] http://www.gentoo.org/proj/en/desktop/sound/xmms.xml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#431482: Considerations for 'xmms' removal from Debian
Hi Steve, I really hate circular depency and I'm not sure it's the better way. In fact, audacious is broken in testing for ages and forcing a build of mcs on mipsel would fix all that crap... Adeodato Simó a écrit : * Russ Allbery [Mon, 02 Jul 2007 14:39:20 -0700]: Steve Langasek [EMAIL PROTECTED] writes: Um. Which version of audacious was this? libaudacious5 isn't in testing at all, and the stable (=testing) version of audacious works fine for me with libaudacious4 which it depends on. (Also filing this as a bug report.) windlord:~ audacious Failed to load plugin (/usr/lib/audacious/Input/libaac.so): /usr/lib/audacious/Input/libaac.so: undefined symbol: vfs_buffered_file_new_from_uri Files in audacious-plugins are dlopened by audacious, so they don't depend on any libaudaciousX package. What has happened here is that there are no package relationships in place to prevent upstream version skew from happening between the application and the plugins. And audacious-plugins 1.3.X made it into testing while audacious 1.3.X did not. Adam, to fix this, the probably saniest way is to make the plugin packages depend on audacious with a relationship like this: Package: audacious-plugins-whatever Version: 1.X.Y Depends: audacious ( 1.X), audacious ( 1.(X+1)~) This introduces a circular dependency between audacious and audacious-plugins, but I think that's okay and preferable to making the plugins Conflict: audacious ( 1.X), audacious ( 1.(X+1)~). I'm sure others in -devel will agree. NB: this can't be fixed by just updating the audacious-plugins dependency in the audacious package, because there are several plugin packages and audacious does not depend on them all. HTH, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Joseph Neal a écrit : Most of this packages are xmms plugins. Maintainers will need to port them to xmms2 or bmpx, or they should be removed. Other packages just depend on xmms as a mere multimedia player, and therefore we recommend the maintainers to adjust their dependencies to bmpx, xmms2 or audacious. 2.2 Popcon xmms is now 1069 in the overall popcon rank, with 11029 installations, not counting the plugin users. There are a number of plugins available from the rarewares repository[1] and perhaps other third party repositories which provide the only convient way I'm aware of to access a number of media formats (bonk, wavepack, lossless audio, shorten, various DVD audio formats). While I do not expect debian to support these packages, I do ask that the wider ecosystem be taken into consideration. Thanks [1] http://www.rarewares.org/index.php Hi Could you get audacious + audacious-plugins-extra from unstable and tell us which formats are supported by xmms but not by audacious ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#431482: Considerations for 'xmms' removal from Debian
Adeodato Simó a écrit : * Adam Cécile (Le_Vert) [Tue, 03 Jul 2007 08:46:45 +0200]: Hi Steve, (My name is not Steve.) Wasn't talking to new or mistake. I really hate circular depency and I'm not sure it's the better way. Well, do as Joss said and tighten the audacious-plugins dependency in audacious, *and* introduce tight dependencies against audacious in all the rest of plugin packages. No circular dependencies. In fact, audacious is broken in testing for ages and forcing a build of mcs on mipsel would fix all that crap... Well, sorry but no. It is not broken in testing because of mcs not being built, it is broken in testing because it's not packaged correctly. Maybe, I didn't know how to deal with this circular dependency. Here is what I understand, let me know if there's something wrong: audacious 1.3.X should depends on audacious-plugins (= 1.3) and audacious-plugins ( 1.4). That make senses now upstream and me are sure X.Y ABI will always be incompatible with X.Z ABI. If it's fine I'll prepare a new upload for it, however I still can't do anything until mcs is built on mipsel ;) Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#431482: Considerations for 'xmms' removal from Debian
Do you mean having the right audacious-plugins dependency on audacious wouldn't be enough ? Adeodato Simó a écrit : * Steve Langasek [Tue, 03 Jul 2007 12:25:11 -0700]: But at a minimum, yes, the audacious-plugins package should be depending on libaudacious by way of shlibdeps. There is no NEEDED entry in the plugins against libaudaciousX. Do you mean hardcoding the dependency instead? (Which, true, solves the situation.) Cheers, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Joseph Neal a écrit : Well, my reasoning was, that we just try to wild guess about user capabilities. I have just learned that user behave very unexpected and exactly these users happen to be quite vocal how broken Debian is. I just would like to give them lesser chances to be correct when they claim this. Anyone who claims Debian is broken for not shipping 6-year-old abandonware in stable is an idiot who should be refuted, not pandered to. Responding from the web because I'm lazy. Xmms-shn was last updated March 28th 2007. I personally have about 40 hours of zappa boots in shn format that would only be playable from mplayer and perhaps vlc if xmms were removed. This is a common media format. http://en.wikipedia.org/wiki/Shorten This has been proposed to Google SoC by Audacious. xmms-shn can't be ported because their some licensing issues. Moreover audacious provies a mplayer backend in audacious-plugins-ugly package. Looking at Freshmeat, 16 plugins or otherwise xmms based projects have been updated in the past year including two new ones that were introduced. It may be dead, but development on top of it is definitely ongoing. Bmpx is not really a substitute for the simple fact that it's gstreamer based. A substitute needs to be a simple library based player that is scriptable and provides maximum exposure to the features of the underlying libraries. It needs to be suitable for use in car computers, portable media devices, pro-audio applications, etc. It's my impression that audicious is not scriptable so it can't be as easily integrated into existing applications or controlled from emacs or irssi. man audtool My money is on Xmms2, but it's got a ways to go before it's usable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
Joseph Neal a écrit : On Mon, 09 Jul 2007 10:09:35 +0200 Adam Cécile (Le_Vert) [EMAIL PROTECTED] wrote: Xmms-shn was last updated March 28th 2007. I personally have about 40 hours of zappa boots in shn format that would only be playable from mplayer and perhaps vlc if xmms were removed. This is a common media format. http://en.wikipedia.org/wiki/Shorten This has been proposed to Google SoC by Audacious. xmms-shn can't be ported because their some licensing issues. Moreover audacious provies a mplayer backend in audacious-plugins-ugly package. Mplayer support in shorten is lacking. Specifically you can't seek within a file. You have to start playback and wait for it to get to the part you want. If you miss it you have to start back over at the beginning. Since it's commonly used for live audio recordings that sometimes are not always broken up into tracks. I assume you mean that it can be ported but it can't be included in debian, the same as is the case with Monkey's Audio, OptimFROG and the like? I've not tried it yet, but it looks like porting the plugins is going to be easier than actually making a deb. (I've still not got that down right). Yes, I mean you can port it, but it won't ever be available through debian (at least until we use the crap non-free bits, some people are working on a free implemenation) I'm slightly concerned that packaging all the plugins in large bundles with many dependencies makes audacious more cumbersome to use on handhelds and car computers. What about packaging the plugins individually and using metapackages to pull them in? I would do this first, but many devs told me I should't do that, because it'll lead ton much load for britney (sid-etch transition script). If it's one condition for xmms replacement, just ask it and I'll do. It's my impression that audicious is not scriptable so it can't be as easily integrated into existing applications or controlled from emacs or irssi. man audtool Kick ass, thanks. Np, Adam. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for 'xmms' removal from Debian
William Pitcock a écrit : Julien BLACHE jblache at debian.org writes: I think you need at least an Intel HDA card to reproduce that problem, as it's probably the driver that presents something weird to the lib. Might even need a MacBook with the same setup :| I'll see on another machine if the ALSA plugin behaves better. Yes, we have received reports about problems with the intel HDA driver in ALSA and audacious. I think it's because per Takashi Iwai, we removed the mmap mode from our plugin, but as I do not use ALSA anymore I can't honestly say what the problem is, as I do not know for certain. Not reproductible on my recent Apple iMac : │ Card: HDA Intel │ Chip: SigmaTel STAC9221 A1 Still using OSS ? :) If by OSS you mean that crappy OSS/Free, then no. I use the recently open sourced OSS4, created by the guys who ironically sponsored XMMS development. The reason being is that ALSA has never really worked well for my hardware (in any application, including XMMS), and OSS4 supports my current hardware while ALSA's support is still unimplemented (Soundblaster XFi). If you're having issues with ALSA, I strongly recommend giving OSS4 a go, it works very well (although some people with political interests over technical ones are probably likely to disagree). You can find out more information at http://developer.opensound.com if you're interested in it. I'll try to take a closer look at the problem if I can find some time to do so. Ok, I'm sure they would indeed be happy to look into your problem. Reviewing IRC logs it looks like at least Chainsaw is interested in it. Can't be worse than -devel ;) If you say so. Well, actually, it's very similar. Probably because everyone feels that they are doing what is best for Audacious, even if it's perhaps not. William
To the aqualung NMUer....
Hello, I just received a DAK acknowledgement for aqualung 0.9~beta9.1-1.1 but it's not me who prepared this package. I guess it's a NMU fixing the ffmpeg/libavcodec issue but I can't found any related message neither on the BTS nor on debian mailing lists (-devel and -release). I would have been great if this people told me he were preparing a NMU because I was working on new upstream release package that ALSO fix the ffmpeg issue. Anyway... If someone is responsible of this upload, please overwrite it by the new packages I just uploaded to debian-mentors: http://mentors.debian.net/debian/pool/main/a/aqualung/aqualung_0.9~beta10-1.dsc Thanks in advance, Adam. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
To the aqualung NMUer....
Hello, I just received a DAK acknowledgement for aqualung 0.9~beta9.1-1.1 but it's not me who prepared this package. I guess it's a NMU fixing the ffmpeg/libavcodec issue but I can't found any related message neither on the BTS nor on debian mailing lists (-devel and -release). I would have been great if this people told me he were preparing a NMU because I was working on new upstream release package that ALSO fix the ffmpeg issue. Anyway... If someone is responsible of this upload, please overwrite it by the new packages I just uploaded to debian-mentors: http://mentors.debian.net/debian/pool/main/a/aqualung/aqualung_0.9~beta10-1.dsc Thanks in advance, Adam. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: To the aqualung NMUer....
Barry deFreese a écrit : Adam Cécile (Le_Vert) wrote: Hello, I just received a DAK acknowledgement for aqualung 0.9~beta9.1-1.1 but it's not me who prepared this package. I guess it's a NMU fixing the ffmpeg/libavcodec issue but I can't found any related message neither on the BTS nor on debian mailing lists (-devel and -release). I would have been great if this people told me he were preparing a NMU because I was working on new upstream release package that ALSO fix the ffmpeg issue. Anyway... If someone is responsible of this upload, please overwrite it by the new packages I just uploaded to debian-mentors: http://mentors.debian.net/debian/pool/main/a/aqualung/aqualung_0.9~beta10-1.dsc Thanks in advance, Adam. That was me. I haven't posted the diff for the NMU yet. I'll take a look at the new upstream on mentors. Of course tagging the existing bug as pending or some other form of notification that you were working on it would have helped. Sorry, Barry deFreese Hello, Thanks for having a look to the new upstream release and sorry for not having updated the bug status ! Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: To the aqualung NMUer....
Don Armstrong a écrit : On Mon, 09 Mar 2009, Barry deFreese wrote: That was me. I haven't posted the diff for the NMU yet. Just to underline here, you need to send the diff for the NMU to the bug(s) that you are fixing in the NMU *before* uploading the NMU. In the case where a 0-day NMU is valid, you can upload immediately following this, but there should never be a period of time where the NMU has gone through and the patch has not landed in the BTS. Don Armstrong We were both wrong and I guess we're aware of it ;) Anyway, the issue is fixed; I just received a dak email for latest upstream package. Thanks and sorry for bothering -devel ! Adam. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: To the aqualung NMUer....
Simon Huggins a écrit : On Mon, Mar 09, 2009 at 10:10:13PM +0100, Adeodato Simó wrote: 1. Don't spam devel to contact just one person. For reference, who-uploads from devscripts is useful for working out who NMU'd something. Simon I bet it won't work for a package in dak ;) Adam. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: To the aqualung NMUer....
Adeodato Simó a écrit : * Adam Cécile (Le_Vert) [Tue, 10 Mar 2009 15:42:43 +0100]: I bet it won't work for a package in dak ;) http://incoming.debian.org http://packages.qa.debian.org/aqualung It didn't appear neither on incoming nor on pts. And, FFS, the ACCEPTED mail you get has you *and* the uploader in the To: line. Well... I still can't explain why I missed that, but that's definitely the right information. Beware of small resolution of netbooks' screens that may hide some parts of the mails you get... Imho, it's better to submit a quick reply to the bug saying you intend to prepare a NMU. Maintainer may start working on a package without replying to the bug first, advicing him about an incoming NMU may avoid having the work done twice. That's my opinion, but I agree, it's always better to ack the bug first. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
wxwidgets 2.8 needs help !
Hello developers, I'm writing you this mail to be sure everybody is aware of this issue and with the hope that someone will be interrested in fixing it ;) wxWidgets has been released a long time ago and we're still missing it. wx2.8 has been packaged for Ubuntu [1] so most of the initial packaging effort could be stolen there. Moreover, I already successfully rebuild wx2.8 from Ubuntu on Lenny without any change. Currently, I don't have time (and skill) to maintain wx2.8, that's why I'm asking for your help. Current FileZilla package in debian is quite broken (beta version) but it's too much work for me to backport patches from upstream, as they have now switched to wx2.8. aMule suffers of the same problem and there's is probably tones of others package's upstreams that switched to wx2.8 or plan to do. Despite many open bugs reports [2], current wx2.6 maintainer doesn't really seem to be interrested in packaging wx2.8. Anyone else ? Best regards, Adam. [1] http://packages.ubuntu.com/gutsy/source/wxwidgets2.8 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403237 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=415677 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425647 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440330 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447410: ITP: libmowgli -- Development framework for C
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: libmowgli Version: 0.5.0 Upstream Author: Atheme Project URL: http://www.atheme-project.org/projects/mowgli.shtml License: ISC Description: Mowgli is a development framework for C (like GLib), which provides high performance and highly flexible algorithms. . It can be used as a suppliment to GLib (to add additional functions (dictionaries, hashes), or replace some of the slow GLib list manipulation functions), or stand alone. . It also provides a powerful hook system and convenient logging for your code, as well as a high performance block allocator. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Orphaned packages with quite some users
Cyril Brulebois a écrit : Luk Claes [EMAIL PROTECTED] (31/10/2007): Bernd Zeimetz wrote: http://packages.qa.debian.org/x/xmms-crossfade.html If I remember right gtk-1 is supposed to be removed from lenny, so xmms will be gone, too. Yes, but this source package also builds audacious-crossfade which probably should stay? Putting the audacious maintainer in the loop (unsure whether he reads d-d) so that he eventually picks up this package and maintains it along with audacious. Cheers, Hi, I'm subscribed to d-d but now always reading it, so it's a good thing to CC me. I don't have much time for audacious-crossfade right now, and already maintaining a large bunch of packages. Anyone else interrested in? If nobody cares, please contact me again, I'll do. Best regards, Adam.
Bug#473235: ITP: divfix++ -- repair broken AVI file streams by rebuilding index part of file
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: divfix++ Version: 0.29 Upstream Author: Erdem U. Altinyurt death_knight at gamebox.net URL: http://divfixpp.sourceforge.net/ License: GPL v2 or later Description: This program designed to repair broken AVI file streams by rebuilding index part of file. This is very useful when trying to preview movies which has no index part, like some files are currently downloading from ed2k or bittorent networks. DivFix++ has supports CLI tools, this means you can fix a file to temporary location, preview with a player, than delete temporary movie file after preview automatically via script by using argument parameters... DivFix++ is complete rewrite of DivFix program due it's bugs and low performance. It has been written using C++/wxWidgets and thus, ported on various Operating Systems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
