Re: Bug#219293: ITP: songwrite -- a tablatures editor and player
On Sat, 2003-11-08 at 15:18, Joe Drew wrote: > On Sat, 2003-11-08 at 07:41, Duck wrote: > > Songwrite is a guitar tablature (fingering notation) editor and player, > > quite similar to TablEdit. > > In addition to tablatures, it also supports staff, lyrics and drums. > > Printing and playing support are available through external programs. > > Songwrite was formely know as GTablature. > > Good description. > Here's how I'd format it into paragraphs: > > Songwrite is a guitar tablature (fingering notation) editor and player, Perhaps "string and fret notation" instead of "fingering notation"? > quite similar to TablEdit. In addition to tablatures, it also supports > staff, lyrics and drums. > . > Printing and playing support are available through external programs. I'd say, "Printing support and playback are available via external programs." > Songwrite was formely know as GTablature. "Songwrite was formerly known as GTablature," is better. signature.asc Description: This is a digitally signed message part
Re: Yelp HTML generation (#177167)
On Fri, 2003-10-03 at 19:35, Aaron Isotton wrote: > Hi, > > [This was CC'd to Christian Marillat <[EMAIL PROTECTED]> but I typed > 'debain' instead of 'debian' into the to field.] > > As far as I understand the Gnome help system is supposed to work like > this: > > - packages ship the documentation only in XML format > - as conversion to HTML/whatever is slow, the XML gets converted to the > appropriate formats on package installation. > - yelp displays the pregenerated HTML, and only generates it 'on the > fly' when it is not available/outdated. > > The problem is that yelp stores the generated HTML in the same directory > as the XML data is, i.e. in /usr/doc. This is of course the wrong place > for generated data, which should go into /var/cache. > > Because of that the HTML pregeneration is disabled in Debian, and this > causes yelp to be close to unusable (I experienced waiting times of up > to 1 minute), since the HTML needs to be generated *every time*. > > Christian Marillat (the Debian yelp maintainer) has tagged the bug > #177167 as 'wontfix' and forwarded it to [0]; as far as I can see, > neither him nor the Gnome developers seem to be very keen to fix the > bug. > > [0] http://bugzilla.gnome.org/show_bug.cgi?id=103777 > > As I am very annoyed by the bug, I am looking into fixing it. But I > need some information about the whole gnome help generation process. > > - what kind of documents are currenty generated from the XML sources? > HTML? PDF? PS? Others? Are they/should they all be cached? > > - what kind of structure should /var/cache/yelp have? > > - how should the cache be updated? by root running yelp-pregenerate, or > by yelp 'on first request'? If yelp must be able to write to the cache, > how should it do so? Via setuid or via group permissions (like the man > cache). > > - has any of this already been done? Is somebody working on it? The upcoming release of Yelp features a brand-new collection of XSLT style sheets that are much faster than Norm's. Because of this, the yelp-pregenerate program will be taken out of the build (unless someone is willing to work more on it, that is), and the caching you mentioned is probably unnecessary. signature.asc Description: This is a digitally signed message part
Re: Bug#220888: ITP: python-eyed3 -- Python module for id3-tags manipulation
On Sat, 2003-11-15 at 07:20, Alexander Wirt wrote: > Package: wnpp > Severity: wishlist > > * Package name: python-eyed3 > Version : 0.5.1 > Upstream Author : Travis Shirk <[EMAIL PROTECTED]> > * URL : http://www.travisshirk.net/eyeD3/ > * License : GPL > Description : Python module for id3-tags manipulation > > python-eyed3 is a python module for id3-tags manipulation. > It supports Version 1.0,1.1,2.3 and 2.4 id3-tags. It also > allows to retrieve informations like length, bitrate from > the mp3 file. Once again, I would change the long description to the following: A Python module for the manipulation of ID3 tags. It supports versions 1.0, 1.1, 2.3, and 2.4 of the ID3 standard. It can also retrieve information such as length and bit rate from an MP3 file. signature.asc Description: This is a digitally signed message part
Re: Bug#220888: ITP: python-eyed3 -- Python module for id3-tags manipulation
On Sat, 2003-11-15 at 22:01, Alexander Winston wrote: > On Sat, 2003-11-15 at 07:20, Alexander Wirt wrote: > > Package: wnpp > > Severity: wishlist > > > > * Package name: python-eyed3 > > Version : 0.5.1 > > Upstream Author : Travis Shirk <[EMAIL PROTECTED]> > > * URL : http://www.travisshirk.net/eyeD3/ > > * License : GPL > > Description : Python module for id3-tags manipulation > > > > python-eyed3 is a python module for id3-tags manipulation. > > It supports Version 1.0,1.1,2.3 and 2.4 id3-tags. It also > > allows to retrieve informations like length, bitrate from > > the mp3 file. > > Once again, I would change the long description to the following: > > A Python module for the manipulation of ID3 tags. It supports versions > 1.0, 1.1, 2.3, and 2.4 of the ID3 standard. It can also retrieve > information such as length and bit rate from an MP3 file. My apologies. The previous message was intended to go to the entry in the BTS. signature.asc Description: This is a digitally signed message part
Re: Some observations regardig the progress towards Debian 3.1
On Sat, 2003-11-15 at 23:17, David Starner wrote: > > Debian 3.0 contains 7 CDs with binaries and Debian 3.1 might contain 10 > > or more CDs. How do you explain to a user why there are 10 CDs, but this > > popular package is not included, and that package he needs is not > > included? > > > > Saying "The maintainer didn't care enough about the package you need." > > only sounds like a good reason to switch to RedHat... :-( > > There are going to be packages that users want that aren't included. > That's life. We are never going to support every program that anyone > might think they need. > > If you were a Debian developer, you could fix this by adopting or at least > NMUing important programs that were unmaintained. Is it easier to stand > on the outside and complain then actually work to making it better? But it may take many months or even years before he reaches official Debian developer status... Could anything be done about that, perhaps? signature.asc Description: This is a digitally signed message part
