Re: What to do about the situation with id3v2
Hi On Wed, Sep 28, 2011 at 18:07, Tobias Hansen tobias.han...@physik.uni-hamburg.de wrote: Any feedback would be highly welcome. Hi, I just had to change the album names of 200 files from different sources. If you edit tags of so many mp3s, there are always some files with problems. I used your newest version of id3v2 and it worked very well. Even where the tag could not be read or changed by the tool (maybe it was ape tags or something) and other tools didn't succeed, using id3v2 to remove the tag and then write a new one worked. I'll let you know if I encounter a problem with the tool in the future. Great, thank you very much for testing it! Since it seems to work for you (and me), I'll try to put together an updated package to be uploaded to experimental in order to get more feedback from a wider audience. cheers -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOk=tpqwug4ojbzzy0u9+hm8yxr8x0ejjseiyqct81-jdws...@mail.gmail.com
Re: What to do about the situation with id3v2
Am 25.09.2011 18:12, schrieb Stefan Ott: I'm asking because I think it's going to be non-trivial to find people who are willing to test a new tool that solves a problem which, for many people, doesn't seem to be extremely urgent. Anyway, if somebody on this list is interested in trying it out, you can get the current source code at http://src.ott.net/id3v2/ - most things (the build system, the included debian/ directory etc.) are still identical to upstream id3v2 but would of course be cleaned up if I were to actually try and do this right. Any feedback would be highly welcome. Hi, I just had to change the album names of 200 files from different sources. If you edit tags of so many mp3s, there are always some files with problems. I used your newest version of id3v2 and it worked very well. Even where the tag could not be read or changed by the tool (maybe it was ape tags or something) and other tools didn't succeed, using id3v2 to remove the tag and then write a new one worked. I'll let you know if I encounter a problem with the tool in the future. Best regards, Tobias -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e83464d.1080...@physik.uni-hamburg.de
Re: What to do about the situation with id3v2
On Fri, Sep 23, 2011 at 01:54, Paul Wise p...@debian.org wrote: Draining the audio file tag reading swamp can only be a good idea. Please get some more testing done (by debian-user or where-ever) before you embark on this project. Do you think it would be a reasonable approach to put together a working version of this and upload it to experimental? Or should I try to focus in finding testers outside of Debian? I'm asking because I think it's going to be non-trivial to find people who are willing to test a new tool that solves a problem which, for many people, doesn't seem to be extremely urgent. Anyway, if somebody on this list is interested in trying it out, you can get the current source code at http://src.ott.net/id3v2/ - most things (the build system, the included debian/ directory etc.) are still identical to upstream id3v2 but would of course be cleaned up if I were to actually try and do this right. Any feedback would be highly welcome. cheers -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOk=tpsnxsdynhtx0-btbmofyxn3m0y0y388gcronyu_+e1...@mail.gmail.com
Re: What to do about the situation with id3v2
On Sun, Sep 25, 2011 at 12:12 PM, Stefan Ott ste...@ott.net wrote: On Fri, Sep 23, 2011 at 01:54, Paul Wise p...@debian.org wrote: Draining the audio file tag reading swamp can only be a good idea. Please get some more testing done (by debian-user or where-ever) before you embark on this project. Do you think it would be a reasonable approach to put together a working version of this and upload it to experimental? Or should I try to focus in finding testers outside of Debian? I'm asking because I think it's going to be non-trivial to find people who are willing to test a new tool that solves a problem which, for many people, doesn't seem to be extremely urgent. Anyway, if somebody on this list is interested in trying it out, you can get the current source code at http://src.ott.net/id3v2/ - most things (the build system, the included debian/ directory etc.) are still identical to upstream id3v2 but would of course be cleaned up if I were to actually try and do this right. Any feedback would be highly welcome. cheers -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOk=tpsnxsdynhtx0-btbmofyxn3m0y0y388gcronyu_+e1...@mail.gmail.com It seems more likely the maintainers of the original id3 project are no longer active, instead of outright ignoring you. If you check their VCS repository, they haven't been active for at least 2 years. If as you say they haven't respond to you after several months, then I would assume they won't be responding at all. In this case, I don't see the harm in taking over the project, especially if you are making improvements to it. An upload to experimental is fine. If you think you have a release that is production ready, an upload to unstable should be done instead. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALgfg4iUwzq-v=p6+Q5GL4v1i7dttn=eu03qu5ewk-v3f5p...@mail.gmail.com
Re: What to do about the situation with id3v2
Hello everyone On Wed, May 25, 2011 at 22:56, Andrew O. Shadoura bugzi...@tut.by wrote: You can also drop libid3 as it is now and write a wrapper around some better ID3 tagging library that has the same (or compatible) interface as libid3. Also, I'd merge id3 and id3v2 into one package, or even one binary, which would behave differently depending on its argv[0]. Well, here we are, several months later. I have since rewritten id3v2 to use taglib instead of libid3 and it seems to work reasonably well [1]. I have informed upstream about my work but haven't received any feedback so far. I thus assume that they are not particularly interested in maintaining a thing that now consists of mostly my code - I can't really blame them for that. I also contacted several debian package maintainers whose packages use libid3 and sent some patches along but so far without a whole lot of success either. I guess they have more pressing things to worry about. What this leaves me with, however, is an AFAICT working version of id3v2 with support for id3v2.4 tags and nobody using it. After re-reading this thread (and the last message in particular) I have now come up with a cunning plan (which would probably have been obvious from the very beginning to a greater mind): as I took over upstream development of id3 [2] when I adopted the package, I'm thinking of (ab)using that project for my id3v2 fork and replacing the debian id3 and id3v2 packages with this great new hopefully-working thing, probably calling the new package id3 again. Once that is done, I intend to orphan libid3 to make it obvious to everyone who still uses it that they should seriously consider switching to something else instead. I realize that replacing a perfectly working little tool like id3 with my mostly untested id3v2 fork might not be the nicest thing to do, but at the moment it's the best solution I can come up with. Thus I was wondering if any of you have any comments on this. Reasonble idea? The most stupid thing you've heard in a while? Something in between? Any feedback would be welcome. [1] http://src.ott.net/cgi-bin/gitweb.cgi?p=id3v2;a=summary [2] http://id3.googlecode.com/ cheers -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOk=tptpouvpekfvdwe67ygw8r0-l3mgmu5pzw_pq0mrvqk...@mail.gmail.com
Re: What to do about the situation with id3v2
On Fri, Sep 23, 2011 at 12:48 AM, Stefan Ott wrote: I realize that replacing a perfectly working little tool like id3 with my mostly untested id3v2 fork might not be the nicest thing to do, but at the moment it's the best solution I can come up with. Thus I was wondering if any of you have any comments on this. Reasonble idea? The most stupid thing you've heard in a while? Something in between? Any feedback would be welcome. Draining the audio file tag reading swamp can only be a good idea. Please get some more testing done (by debian-user or where-ever) before you embark on this project. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6hxz10wjljsk8ms2fvkx0txfb1uz_o9pqnr8a9wb5z...@mail.gmail.com
Re: What to do about the situation with id3v2
Hello, On Wed, 27 Apr 2011 18:10:35 +0200 Stefan Ott ste...@ott.net wrote: - Port id3v2 to libid3tag [5]. This is a different id3 tagging library which supports v2.4 tags. I did some work in this direction but I realized that this would require major modifications to id3v2 since it's closely modeled around libid3. Also, some modifications to libid3tag would be required to support all the current features of the id3v2 program. My current estimate is that the work required for a complete port of id3v2 would be close to rewriting it from scratch and would result in a program that hardly shares any code with the current id3v2 tool. You can also drop libid3 as it is now and write a wrapper around some better ID3 tagging library that has the same (or compatible) interface as libid3. Also, I'd merge id3 and id3v2 into one package, or even one binary, which would behave differently depending on its argv[0]. -- WBR, Andrew signature.asc Description: PGP signature
Re: What to do about the situation with id3v2
Hi On Sat, Apr 30, 2011 at 00:44, Craig Small csm...@debian.org wrote: Hello Stefan, As someone who has been in your situation many times (I look after more orphans than an animal shelter) you do need to think about the longer term. I took over psmisc in 2000, for example. I saw some suggested you make the library a basic shim to the currently developed one and that's probably a good compromise if it doesn't look like too much work. The ideal would be for programs to use a supported library. I would say that the library change would be about the same effort as the command-line one but there's more ongoing support. It's the ongoing work that you need to consider. Also I wonder how many of the other programs know the id3 library state. I was actually looking for an id3 tagger for a program of mine and wasn't aware. Thanks, good point. I guess I should contact and inform the maintainers of other packages that use libid3 and see what they think, i.e. ask whether they think switching to another library would be possible without too much work. cheers -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTik-joCvH-xane3Wjcuv=mhuc6v...@mail.gmail.com
Re: What to do about the situation with id3v2
Hello Stefan, As someone who has been in your situation many times (I look after more orphans than an animal shelter) you do need to think about the longer term. I took over psmisc in 2000, for example. I saw some suggested you make the library a basic shim to the currently developed one and that's probably a good compromise if it doesn't look like too much work. The ideal would be for programs to use a supported library. I would say that the library change would be about the same effort as the command-line one but there's more ongoing support. It's the ongoing work that you need to consider. Also I wonder how many of the other programs know the id3 library state. I was actually looking for an id3 tagger for a program of mine and wasn't aware. - Craig -- Craig Small VK2XLZhttp://www.enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110429224409.gb10...@enc.com.au
Re: What to do about the situation with id3v2
On Thu, Apr 28, 2011 at 09:08:42AM +0800, Paul Wise wrote: I also that there are quite a few id3 related command-line tools and libraries in Debian, it would be nice to unify all of those into one library This makes the command line tool redundant, which is an argument for removal. Not a strong one, though -- to migrate to the competition, I'd have to change several lines in one of my private mp3 management scripts which is unnecessary work for me :p In case you are thinking of dropping libid3, the following are the reverse deps and reverse build-deps that would need to be ported or dropped. You might want to talk to their maintainers and upstreams: [15 packages] But this is an argument to keep it. Porting 15 packages to something else would be quite a bit of work. However, what if you made not the command line tool but the library a thin wrapper over a competing one? That would require porting just once. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Re: What to do about the situation with id3v2
On Wed, Apr 27, 2011 at 9:08 PM, Paul Wise p...@debian.org wrote: Since upstream is effectively dead, for Debian's purposes, you have the same responsibilities as upstream. Given the above, why not take over the upstream project. The mailing list still seems active so theoretically upstream could give you admin access to the sourceforge project and you could work on the code there and produce new releases. At the same time you could invite the maintainers of id3v2/libid3 in other distros (run whohas to find them) to join upstream and merge their patches so that you won't be alone. I can't really see a right answer here, everything requires a lot of work or is a suboptimal solution. I also that there are quite a few id3 related command-line tools and libraries in Debian, it would be nice to unify all of those into one library: http://packages.debian.org/search?keywords=id3 You might want to mail the maintainers and upstreams of all the relevant ones, some might be willing to join libid3 upstream. In case you are thinking of dropping libid3, the following are the reverse deps and reverse build-deps that would need to be ported or dropped. You might want to talk to their maintainers and upstreams: # Broken Depends: clam: libclam1.4 [alpha amd64 armel i386 ia64 mips mipsel powerpc s390] djplay: djplay [alpha amd64 armel hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc] easytag: easytag gmediaserver: gmediaserver id3v2: id3v2 intone: intone [alpha amd64 armel hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc] kid3: kid3 kid3-qt liblicense: liblicense3 ripperx: ripperx splay: splay [alpha armel hurd-i386 i386 powerpc] tagtool: tagtool # Broken Build-Depends: clam: libid3-3.8.3-dev djplay: libid3-3.8.3-dev easytag: libid3-3.8.3-dev flac: libid3-3.8.3-dev gmediaserver: libid3-3.8.3-dev id3v2: libid3-3.8.3-dev intone: libid3-3.8.3-dev iripdb: libid3-3.8.3-dev (= 3.8.3-5) kid3: libid3-3.8.3-dev (= 3.8.3-4.2) kwave: libid3-3.8.3-dev (= 3.8.3-4.2) liblicense: libid3-3.8.3-dev ripperx: libid3-dev splay: libid3-3.8.3-dev tagtool: libid3-3.8.3-dev -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=_4fts-bmac_uw075yjgp7irm...@mail.gmail.com I believe taglib is worth a mention here too. See [1]. Aside from id3 tags, taglib supports many other tag formats. Also, taglib upstream seems much more active. 1. http://packages.qa.debian.org/t/taglib.html -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktim1p+t_uqfaynv3fh241h7cu9r...@mail.gmail.com
Re: What to do about the situation with id3v2
On Thu, Apr 28, 2011 at 11:29, Adam Borowski kilob...@angband.pl wrote: In case you are thinking of dropping libid3, the following are the reverse deps and reverse build-deps that would need to be ported or dropped. You might want to talk to their maintainers and upstreams: [15 packages] But this is an argument to keep it. Porting 15 packages to something else would be quite a bit of work. True However, what if you made not the command line tool but the library a thin wrapper over a competing one? That would require porting just once. Someone also suggested this on IRC last night and I actually like the idea, thanks! cheers -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktim6bvknk-nzz7gpvnjfv_nicmj...@mail.gmail.com
Re: What to do about the situation with id3v2
On Thu, Apr 28, 2011 at 12:23, Andres Mejia mcita...@gmail.com wrote: On Wed, Apr 27, 2011 at 9:08 PM, Paul Wise p...@debian.org wrote: Since upstream is effectively dead, for Debian's purposes, you have the same responsibilities as upstream. Given the above, why not take over the upstream project. The mailing list still seems active so theoretically upstream could give you admin access to the sourceforge project and you could work on the code there and produce new releases. At the same time you could invite the maintainers of id3v2/libid3 in other distros (run whohas to find them) to join upstream and merge their patches so that you won't be alone. I can't really see a right answer here, everything requires a lot of work or is a suboptimal solution. I also that there are quite a few id3 related command-line tools and libraries in Debian, it would be nice to unify all of those into one library: http://packages.debian.org/search?keywords=id3 You might want to mail the maintainers and upstreams of all the relevant ones, some might be willing to join libid3 upstream. In case you are thinking of dropping libid3, the following are the reverse deps and reverse build-deps that would need to be ported or dropped. You might want to talk to their maintainers and upstreams: # Broken Depends: clam: libclam1.4 [alpha amd64 armel i386 ia64 mips mipsel powerpc s390] djplay: djplay [alpha amd64 armel hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc] easytag: easytag gmediaserver: gmediaserver id3v2: id3v2 intone: intone [alpha amd64 armel hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc] kid3: kid3 kid3-qt liblicense: liblicense3 ripperx: ripperx splay: splay [alpha armel hurd-i386 i386 powerpc] tagtool: tagtool # Broken Build-Depends: clam: libid3-3.8.3-dev djplay: libid3-3.8.3-dev easytag: libid3-3.8.3-dev flac: libid3-3.8.3-dev gmediaserver: libid3-3.8.3-dev id3v2: libid3-3.8.3-dev intone: libid3-3.8.3-dev iripdb: libid3-3.8.3-dev (= 3.8.3-5) kid3: libid3-3.8.3-dev (= 3.8.3-4.2) kwave: libid3-3.8.3-dev (= 3.8.3-4.2) liblicense: libid3-3.8.3-dev ripperx: libid3-dev splay: libid3-3.8.3-dev tagtool: libid3-3.8.3-dev -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=_4fts-bmac_uw075yjgp7irm...@mail.gmail.com I believe taglib is worth a mention here too. See [1]. Aside from id3 tags, taglib supports many other tag formats. Also, taglib upstream seems much more active. 1. http://packages.qa.debian.org/t/taglib.html Very nice, thanks, I'll have a closer look at taglib. I like the idea of having active upstream development! :) cheers -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktimnbbubcokbvsu_rcpehamjz2z...@mail.gmail.com
Re: What to do about the situation with id3v2
On Thu, Apr 28, 2011 at 5:53 AM, Andres Mejia mcita...@gmail.com wrote: I believe taglib is worth a mention here too. See [1]. Aside from id3 tags, taglib supports many other tag formats. Also, taglib upstream seems much more active. 1. http://packages.qa.debian.org/t/taglib.html It also worth to mention python-mutagen. http://packages.qa.debian.org/m/mutagen.html -- Miguel Landaeta, miguel at miguel.cc secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/ Faith means not wanting to know what is true. -- Nietzsche -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktimpopm6zg7b1wnp8j3opehhjp2...@mail.gmail.com
What to do about the situation with id3v2
Hello my fellow maintainers and DDs I have a question concerning two of my packages: I am maintaining id3v2 [1] and libid3 [2]. For those unfamiliar with them, id3v2 is a simple command-line tool to manage ID3 tags and libid3 is the library behind it. Now, those packages suffer from some major issues: - The library (and thus the tool) cannot handle version 2.4 ID3 tags (they only support version 2.3 of the standard - a rather outdated version). - Partly as a consequence of the lack of v2.4 support, Unicode tags are broken. Most of the remaining bug reports are related to this [3] [4]. - Upstream development for both packages is pretty much dead. When I originally adapted the packages, my intention was to fix this - so far I failed miserably, partly because I'm not sure how to approach the problem. My current ideas are: - Port id3v2 to libid3tag [5]. This is a different id3 tagging library which supports v2.4 tags. I did some work in this direction but I realized that this would require major modifications to id3v2 since it's closely modeled around libid3. Also, some modifications to libid3tag would be required to support all the current features of the id3v2 program. My current estimate is that the work required for a complete port of id3v2 would be close to rewriting it from scratch and would result in a program that hardly shares any code with the current id3v2 tool. - Fix libid3 to support v2.4 tags and Unicode. This would probably only require minor changes to id3v2, but it would introduce a significant delta between the Debian version of libid3 and upstream, making me the de-facto upstream for the library. Also, this would mean a lot of work to basically duplicate the other id3 tag library (libid3tag). - Drop id3v2 and replace it with a wrapper around one of the other command-line id3 taggers. This would however leave the broken library in the repository since other packages also use it. Also, I haven't actually investigated the alternatives. One possibly interesting candidate is eyed3 [6] but since this is a python application, that would introduce a whole lot of new dependencies for the users of id3v2. My personal goal for wheezy is to fix this mess, but since none of the solutions I can currently think of convince me, I'd like to get some input from other package maintainers. What would you do in a similar situation? Do you have other ideas than the ones mentioned above? Any input would be highly appreciated. [1] http://packages.debian.org/sid/id3v2 [2] http://packages.debian.org/sid/libid3-3.8.3-dev [3] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=id3v2;dist=unstable [4] http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;src=id3lib3.8.3;dist=unstable;repeatmerged=0 [5] http://packages.debian.org/sid/libid3tag0 [6] http://packages.debian.org/sid/eyed3 cheers -- Stefan Ott http://www.ott.net/ You are not Grey Squirrel? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=Unda9mJV4+CO9LdmchEjU66pK=a...@mail.gmail.com
Re: What to do about the situation with id3v2
Since upstream is effectively dead, for Debian's purposes, you have the same responsibilities as upstream. Given the above, why not take over the upstream project. The mailing list still seems active so theoretically upstream could give you admin access to the sourceforge project and you could work on the code there and produce new releases. At the same time you could invite the maintainers of id3v2/libid3 in other distros (run whohas to find them) to join upstream and merge their patches so that you won't be alone. I can't really see a right answer here, everything requires a lot of work or is a suboptimal solution. I also that there are quite a few id3 related command-line tools and libraries in Debian, it would be nice to unify all of those into one library: http://packages.debian.org/search?keywords=id3 You might want to mail the maintainers and upstreams of all the relevant ones, some might be willing to join libid3 upstream. In case you are thinking of dropping libid3, the following are the reverse deps and reverse build-deps that would need to be ported or dropped. You might want to talk to their maintainers and upstreams: # Broken Depends: clam: libclam1.4 [alpha amd64 armel i386 ia64 mips mipsel powerpc s390] djplay: djplay [alpha amd64 armel hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc] easytag: easytag gmediaserver: gmediaserver id3v2: id3v2 intone: intone [alpha amd64 armel hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc] kid3: kid3 kid3-qt liblicense: liblicense3 ripperx: ripperx splay: splay [alpha armel hurd-i386 i386 powerpc] tagtool: tagtool # Broken Build-Depends: clam: libid3-3.8.3-dev djplay: libid3-3.8.3-dev easytag: libid3-3.8.3-dev flac: libid3-3.8.3-dev gmediaserver: libid3-3.8.3-dev id3v2: libid3-3.8.3-dev intone: libid3-3.8.3-dev iripdb: libid3-3.8.3-dev (= 3.8.3-5) kid3: libid3-3.8.3-dev (= 3.8.3-4.2) kwave: libid3-3.8.3-dev (= 3.8.3-4.2) liblicense: libid3-3.8.3-dev ripperx: libid3-dev splay: libid3-3.8.3-dev tagtool: libid3-3.8.3-dev -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=_4fts-bmac_uw075yjgp7irm...@mail.gmail.com
