Bug#821328: ITP: debian-paketmanagement-buch -- German-written book about package management with Debian
Holger Levsen wrote: > On Sun, Apr 17, 2016 at 08:04:40PM +0200, Axel Beckert wrote: >> * Package name: debian-paketmanagement-buch > > it feels a bit weird to see a package name mostly made up out of German > words… not sure what would be better though. maybe > debian-paketmanagement-book ? It feels weird to see it all lowercase like that. >> Description : German-written book about package management with Debian "German-written" would mean "written by Germans" - a more efficient alternative to "ghost-written". > maybe better "Book about package management with Debian in German"? Or > "German book about…" or "German language book"? DevRef recommends no extra capitalisation in a synopsis - that would be "book about...". And I wouldn't use "with" quite like that. How about: Description:book in German about Debian package management >> This package contains the book "Debian Paketmanagement" by Axel Beckert >> and Frank Hofmann as single HTML page, as PDF document and as e-book in >> the epub format. > > The long description should probably also mention the language the book > is written in. I don't know; as long as it mentions the German book title I'd think that would be enough. In fact you might argue that a long description like this should be *entirely* in German, so that people who can't read it immediately recognise this package as useless to them. But that's not what policy currently says, and if it's going to be in English it needs a couple of tweaks to the articles: # This package contains the book "Debian Paketmanagement" by Axel Beckert # and Frank Hofmann as a single HTML page, as a # PDF document and as an e-book in the epub format. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#768936: ITP: nufft -- Library implementing the Non-Uniform Fast Fourier Transform
Chris Bannister wrote: > Ghislain Antony Vaillant wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Ghislain Antony Vaillant >> >> * Package name: nufft >> Version : 1.3.3 >> Upstream Author : Leslie Greengard >> * URL : http://www.cims.nyu.edu/cmcl/nufft/nufft.html >> * License : BSD >> Programming Lang: FORTRAN >> Description : Library implementing the Non-Uniform Fast Fourier >> Transform >> >> Implementation of the Non-Uniform Fast Fourier Transform (NUFFT) coded in >> FORTRAN using a fast, procedural, algorithm. ^ ^ >> Compared to existingly packaged solutions, like the NFFT library, the NUFFT >> provides Octave (and MATLAB) compatible bindings. Because of the procedural >> implementation, usage of the NUFFT is more straightforward. However, it >> lacks >> support for high dimensionality than 3 and support for precomputation in case > ^^ > I think that would be better worded as "dimensions greater than three" > or similar. Agreed. Also, surplus commas in the first paragraph; and I'd recommend rearranging it to avoid the misreading that it was coded using this algorithm. This is a FORTRAN implementation of the Non-Uniform Fast Fourier Transform (NUFFT) using a fast procedural algorithm. Then in the second paragraph, "existingly packaged" has got to go; and that first sentence never does explicitly compare anything - it's only implied that NFFT doesn't provide these bindings. Say: Unlike solutions such as the NFFT library, the NUFFT provides Octave (and MATLAB) compatible bindings. [...] Then at the end: >> support for high dimensionality than 3 and support for precomputation in case >> a transform needs to be repeated. As a result both the NFFT and NUFFT package >> may coexist as they fit different needs. Nitpicking, "it lacks support for A and support for B" is needless repetition, the "in case" should be "in the case that" or simply "if", and "both [...] may coexist" is redundant and sounds as if you don't know whether in fact they do exist. So: This is a FORTRAN implementation of the Non-Uniform Fast Fourier Transform (NUFFT) using a fast procedural algorithm. . Unlike solutions such as the NFFT library, the NUFFT provides Octave (and MATLAB) compatible bindings. Because of the procedural implementation, usage of the NUFFT is more straightforward. However, it lacks support for dimensions greater than three or for precomputation if a transform needs to be repeated. As a result the NFFT and NUFFT packages fit different needs and can coexist. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014104043.gb4...@xibalba.demon.co.uk
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
Thomas Goirand wrote:
>> If I can work out the final wrinkle ("why would you Debianise it?")
>> then I might add a couple of words, but that would be more or less it.
>
> # cat debian/patches/debianize.patch
> Description: Debianize the package
> Using files from libjs-jquery.quicksearch instead of embedded files.
Actually the word "embedded" might be worth putting somewhere in the
description for python-xstatic.
>> Let's see: the Debian package can't be pulled in by pip, but it can
>> satisfy pip dependencies, which improves portability in aspects of the
>> workflow I probably don't need to know about.
>
> Correct.
>
>> If it also provides
>> hooks to make virtualenv setups work more smoothly
>
> Not correct.
Oh, well, then probably there's no need to add anything more to the
python-xstatic-foo descriptions; leave them as
This package integrates jQuery.quicksearch (see libjs-quicksearch)
into the XStatic system (see python-xstatic).
or
$XSTATIC_BOILERPLATE_PARA
.
This package integrates jQuery.quicksearch (see libjs-quicksearch)
into the XStatic system.
Going back to the longer version for python-xstatic itself: I had
XStatic (see python-xstatic) is a Python web development tool for
bundling sets of required data files from external non-Python
projects into Python packages that your app can depend on portably.
but lets see if there's anything extra that needs to be kept from the
long version...
> XStatic is a packaging standard to package external (often 3rd party) static
> files as a Python package, so they are easily usable on all operating
> systems,
> with any package management system or even without one.
Well, I have to keep the word "static" somewhere.
> .
> Many Python projects need to use some specific data files, like javascript,
> css, java applets, images, etc.
Mention a couple of these examples.
Sometimes these files belong to YOUR project
> (then you may want to package them separately, but you could also just put
> them into your main package). But in many other cases, those files are
> maintained by someone else (like jQuery javascript library or even much
> bigger
> js libraries or applications) and you definitely do not really want to merge
> them into your project.
Mention avoiding embedded copies.
> So, you want to have static file packages, but you
> don’t want to get lots of stuff you do not want. Thus, stuff required by
> XStatic file packages (especially the main, toplevel XStatic package) tries
> to
> obey to be a MINIMAL, no-fat thing. XStatic doesn't "sell" any web framework
> or other stuff you don't want. Maybe there will be optional XStatic
> extensions
> for all sorts of stuff, but they won't be required if you just want the
> files.
Probably boils down to the word "simple" or "lightweight".
> .
> By having static files in packages, it is also easier to build virtual envs,
> support linux/bsd/... distribution package maintainers and even windows
> installs using the same mechanism.
The word "virtualenv" should probably still be there.
Are XStatic packages enough like Debian dependency packages that we
should use that term, or would that just confuse people? I'll avoid
it for now.
XStatic is a Python web development tool for handling required static
data files from external projects, such as CSS, images, and JavaScript.
It provides a lightweight infrastructure to manage them via Python
modules that your app can depend on in a portable, virtualenv-friendly
way instead of using embedded copies.
Meanwhile in another e-mail Thomas Goirand wrote:
> Justin B Rye wrote:
>>> As opposed to dynamic content. For example:
>>>> - javascript
>>>> - .css
>>>> - .png
>>>>
>>>> are all static files, and not scripts. This is what XStatic provides.
>>
>> When you say "not scripts" you mean "not the Python code of your
>> actual webapp", right? Oh well, I get it now. My confusion was
>> because when a package description says it contains "static files",
>> that essentially boils down to "any actual files at all", since
>> obviously it can't provide content for $DOCROOT/dynamic/!
>
> You should view a javascript file just as if it was a PNG image... This
> is still static content, which will *not* be modified grammatically in
> the Python application.
Being literally static as opposed to dynamic has little to do with it.
The Python code is just as static as the JavaScript, but you call the
JavaScript "static" bec
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
Thomas Goirand wrote: > On 08/17/2014 10:29 PM, Justin B Rye wrote: >> Thomas Goirand wrote: >>> Thanks for this message. I would welcome indeed any change to this long >>> description, reviewed by the d-l-english team! >> >> Well, I'd like to, but so far I don't really understand it. I don't >> even know what it means by "static files". As opposed to what? > > As opposed to dynamic content. For example: > - javascript > - .css > - .png > > are all static files, and not scripts. This is what XStatic provides. When you say "not scripts" you mean "not the Python code of your actual webapp", right? Oh well, I get it now. My confusion was because when a package description says it contains "static files", that essentially boils down to "any actual files at all", since obviously it can't provide content for $DOCROOT/dynamic/! >>> I do believe this is relevant. The point of the XStatic packages is that >>> they are available using "pip install", which make them universal. This >>> is a very good "selling point" for Python developers, and will push them >>> to use XStatic rather than embedding static files directly in their >>> python module/app. >> >> I'm sure it's an interesting fact about XStatic, and therefore may >> belong in the package description for python-xstatic. But how is it >> useful information for people trying to decide whether to install >> python-xstatic-jquery.quicksearch? It seems to amount to "this >> software is also available as something that isn't a Debian package", >> and that's true of pretty much anything in the archives. > > The point is that they will have an API to find out what is the location > of the jquery.quicksearch in the system. And this API will work on every > operating system using packages (if they are available), or by > downloading the XStatic package using "pip install > xstatic-jquery.quicksearch" within the Python virtualenv. Yes, this explains why my imaginary developer on BeOS would want it - or even developers on Debian who want to work entirely in Python eggs and bypass APT. But it doesn't quite explain why there's a Debian package. >> Meanwhile there's literally no description whatsoever of the >> functionality of jQuery.quicksearch! > > The package depends on libjs-quicksearch. This is where you have the > correct description, and that's where I expect users will read. Do you > think the description of jquery.quicksearch should be copied there too? Seeing it as a sort of dependency shim package, maybe you could cut the entire thing right down to: This package integrates jQuery.quicksearch (see libjs-quicksearch) into the XStatic system (see python-xstatic). > By the way, python-xstatic-* packages aren't directly useful for the > final users, they will only be dependencies of Python applications, and > in my case, the OpenStack dashboard (eg: the Horizon web GUI). Well, the final users of webapps might not even own a computer! But for the sake of Debian users scanning the list of newly available devel packages, the ideal description would let them see at a glance whether this is useful to them. [...] >> But I definitely don't yet understand how XStatic renders a collection >> of files "easily usable on all operating systems with any package >> management system". Sure, bundling files into a Python egg might make >> them accessible via a Python egg installer, but that's not the same >> thing as making it possible to install them with APT. > > The point of XStatic is to avoid developers to embed static files of > libraries (often: javascript libraries) directly in their Python > application, which is a security disaster from a distribution stand > point. A Python developer will simply make his application "require" > (which is the Python language to say "depends") the XStatic python > module. If the developer works with pip, then it will automatically "pip > install xstatic-jquery.quicksearch" for example, which will go in the > virtualenv (which is a kind of chroot-like stuff specific to Python, if > you like). Yes, so developers using pip get to pull in Python xstatic-foo modules as dependencies. I see that. But requiring xstatic-foo can't pull in a Debian package; and if on the other hand I'm using Debian package dependencies, what's the benefit of depending on python-xstatic-foo instead of libjs-foo direct? Does python-xstatic-foo maybe set up the libjs-foo libraries so that they're pulled into a virtualenv (for some reason) instead of being
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
I think I'm getting closer to understanding, but not close enough. David Prévot wrote: >> * Package name: python-xstatic-jquery.quicksearch [...] >> Description : jQuery.quicksearch XStatic support >> >> XStatic is a packaging standard to package external (often 3rd party) static >> files as a Python package, so they are easily usable on all operating >> systems, >> with any package management system or even without one. Okay, a bit of research tells me there's a chunk of context missing here: it's taking it for granted that I already know it's talking specifically about web development where the part you're coding is in Python but it depends on other people's JavaScript (or similar). I would probably have understood that quicker if I was a developer, but still, it's friendlier to the people reading this if the information that tells them "this isn't for you" is at the start. Some further googling reveals that by "static files", Python web developers mean the kind of data files you might expect to find under $DOCROOT/resources/ or somewhere. "Static" files as opposed to... I'm not sure what. Dynamically generated pages? User-provided content? Oh well; maybe we can get away with using the word "static" and hoping that readers somehow already know what it means. That seems to be what everyone else is doing. And the point of XStatic is that you want to incorporate some particular "static files" into your $DOCROOT/resources directory, but... well, maybe the nature of the problem will become clear later. But I definitely don't yet understand how XStatic renders a collection of files "easily usable on all operating systems with any package management system". Sure, bundling files into a Python egg might make them accessible via a Python egg installer, but that's not the same thing as making it possible to install them with APT. >> . >> Many Python projects need to use some specific data files, like javascript, >> css, java applets, images, etc. Sometimes these files belong to YOUR project >> (then you may want to package them separately, but you could also just put >> them into your main package). But in many other cases, those files are >> maintained by someone else (like jQuery javascript library or even much >> bigger >> js libraries or applications) and you definitely do not really want to merge >> them into your project. I can't believe it needs to spend so much effort explaining the case where there isn't a problem for this software to solve. Should "jQuery javascript library" have an article? So the thing to do is arrange for the package that contains your Python software to depend on the package that contains that JavaScript library. Right? Oh, no, of course, you can't do that because you're not on Debian, so your packaged Python doesn't have any way of depending on JavaScript - other than directly including the files, which is nasty. Or... putting them in a *fake* Python package? Aaah! Maybe this is beginning to make sense now... >> So, you want to have static file packages, but you >> don’t want to get lots of stuff you do not want. The stuff I don't want to get is the stuff I do not want? What a coincidence! Or perhaps a really turgid explanation. >> Thus, stuff required by >> XStatic file packages (especially the main, toplevel XStatic package) tries >> to >> obey to be a MINIMAL, no-fat thing. "To obey to be" is the only part of this that's out-and-out ungrammatical. "Stuff tries to be a thing." This paragraph is overstuffed. >> XStatic doesn't "sell" any web framework >> or other stuff you don't want. Maybe there will be optional XStatic >> extensions >> for all sorts of stuff, but they won't be required if you just want the >> files. I like the air of mystery - maybe there will be optional extensions for stuff, or maybe there won't! But not only will they be optional, they won't be required. >> . >> By having static files in packages, it is also easier to build virtual envs, Borderline ungrammatical. And isn't it "virtualenvs"? (Or "virtual environments", but that's bad because it sounds as if it means what it says.) >> support linux/bsd/... distribution package maintainers and even windows >> installs using the same mechanism. All the above is the blurb for the XStatic framework, and doesn't belong in the python-xstatic-jquery.quicksearch package description unless that Debian package really does make it easier to support Windows installs. A deverbosified version could go in the package description for python-xstatic, but I'd prefer to start from somewhere else. The python-xstatic-* packages should have a much, much shorter section saying something like XStatic (see python-xstatic) is a Python web development tool for bundling sets of required data files from external non-Python projects into Python p
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
Thomas Goirand wrote: > Thanks for this message. I would welcome indeed any change to this long > description, reviewed by the d-l-english team! Well, I'd like to, but so far I don't really understand it. I don't even know what it means by "static files". As opposed to what? > These are copy/past from the upstream stuff, but as it is often the > case, it shall be improved. > >> Some parts may be of little relevance for a Debian package too: >>> By having static files in packages, it is also easier to build virtual >>> envs, >>> support linux/bsd/... distribution package maintainers and even windows >>> installs using the same mechanism. > > I do believe this is relevant. The point of the XStatic packages is that > they are available using "pip install", which make them universal. This > is a very good "selling point" for Python developers, and will push them > to use XStatic rather than embedding static files directly in their > python module/app. I'm sure it's an interesting fact about XStatic, and therefore may belong in the package description for python-xstatic. But how is it useful information for people trying to decide whether to install python-xstatic-jquery.quicksearch? It seems to amount to "this software is also available as something that isn't a Debian package", and that's true of pretty much anything in the archives. Meanwhile there's literally no description whatsoever of the functionality of jQuery.quicksearch! -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140817142921.ga6...@xibalba.demon.co.uk
Bug#743669: ITP - gedraa-dsh - Data mine Internet catalogs to find double starts candidates double starts candidates
Victor Di Rienzo wrote: > hi guys, how do i update the information in my ITP to make it valid. sorry for > all the errors but im working very late, and im making tons of errors. Me too, so I waited until the next day. But beware of the Gmail user interface and its default of blind top-posting: if you had clicked on "show trimmed content" and interleaved your reply you'd probably have noticed some of the answers I gave last time. > updated information: The way to get a template for an ITP is to say "reportbug wnpp" (then reply "1: ITP" and "gedraa-dsh"). This sends it to the right "section" of the BTS, and CCs the debian-devel mailinglist so that people have a chance to see that you're "claiming" this package (or in some cases, to jump in and say things like "don't package that, it's not legally distributable"). > Package: gedraa-dsh (That is, the "Grupo de Estrellas Dobles de la Red de Aficionados a la Astronomía" Double Star Hunter... you don't need to explain all of that, I'm just making a note in case I ever want to add it to "https://wiki.debian.org/WhyTheName";!) > Status: install ok installed You don't need to say this in an ITP. > Priority: optional > Section: science You don't need to announce these in an ITP, either, but at least they're accurate now. > Maintainer: Victor Di Rienzo This would be implied by the fact that you're the one posting the ITP, unless you mean it to indicate that you're also the Upstream Author. > Version: 1.0 (Yes, this is included in ITPs - which always vaguely surprises me, since after all how would it matter if the version that reached the archive turned out to be numbered as 1.99.domingo or something?) > Depends: default-jre This is not needed in an ITP. On the other hand it's recommended to include the upstream homepage, the license, and the programming language (though I'm fairly sure I can guess the language). > Description: Data mine Internet catalogs to find double starts candidates Improving... but: * most importantly, you mean "stars", not "starts"; (Then the rest of these are nitpicks) * the first word doesn't need to be capitalised; * "data mining" usually has a space, but if I was using "data-mine" as a verb (which is rarer) I would probably hyphenate it; * "candidates" isn't quite the right word (unless perhaps you mean "candidates for some authoritative source to check"?); * the form DevRef recommends for package short descriptions is "noun-based" rather than "verb-based" - a summary of what the software _is_ rather than of what it _does_. In this case I would suggest just saying "double star hunter" - it's a noun phrase, it's a (partial) expansion of the package name, and it also happens to make an adequate description of the software. (Except... doesn't "double stars" include ones that are merely optical doubles? Surely the kind of stars you're interested in finding are the ones that are genuine gravitationally-associated _binary_ stars?) Then you're supposed to follow this with a few lines of "long description", saying what functionality gedraa-dsh offers and perhaps how it relates to other gedraa-* packages. It might begin with something like: Description: double star hunter This package provides a tool for data-mining observatory catalogs on the Internet to find pairs of stars that are possible binaries. Or perhaps, if these details happen to be correct: This package provides an easy-to-use graphical front-end for finding binary stars. It downloads observatory catalogs from the Internet to data-mine for candidate stars, and can submit discoveries to a central database. Just remember that I'm not even an amateur astronomer, so it's only guesswork! -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140408141155.ga1...@xibalba.demon.co.uk
Bug#737563: ITP: telegram-cli -- Command-line interface for Telegram
I don't know if this ITP is still alive, but if so I think we should be Cc-ing the bug rather than posting on debian-devel. > Cleto Martín wrote: >> Package: wnpp >> * Package name: telegram-cli [...] >> Description : Command-line interface for Telegram messenger That's more or less just an expansion of the package name, and doesn't give me much of a clue what this software is for. Is this a single binary package? If it's one package for a library and one for the executable, they should probably have short descriptions along the lines of Description: phone instant messenger - shared library Description: phone instant messenger - command-line interface >> Telegram messenger is a cloud-based instant messaging platform >> designed for smart phones and similar to Whatsapp but more flexible, These days it's usually s/smart phones/smartphones/ Isn't it "WhatsApp", with capital A? No need for a comma after "flexible". >> and powerful. You can send messages, photos, videos and documents to >> people who are in your phone contacts (and have Telegram). Telegram >> also supports secret chats whose provide a private (encrypted) way of > ^ Chris Bannister wrote: > That should be "which provides"? Chats are plural, so they "provide" (no -s). Or say "providing". Also, "a [...] way of communication" seems unidiomatic - s/way/means/ >> communication. >> . >> This package contains a command-line based client for Telegram with What's the difference between a command-line based client and an actual command-line client? >> the following features: >> * Colored terminal messages. >> * Message management: history, stats, etc. >> * Group chat: create and manage groups. >> * Secret chat: secured and encrypted conversations. >> * Contact management: add/edit/remove contacts. >> * Multimedia support: send/load photos and videos. This isn't quite in "d-l-e house style", but it's okay. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140204204755.ga30...@xibalba.demon.co.uk
Bug#727078: ITP: libobject-container-perl -- simple object container
I'd love to be able to provide a version that's in grammatical English, but I don't understand what it's trying to say well enough to make it say it. Chris Bannister wrote: > Marius Gavrilescu wrote: >> Description : simple object container >> >> This module is a object container interface which supports Wrong article (s/a/an/). >> both OO interface and Singleton interface. Missing article(s) and a confusing profusion of interfaces. Aren't Singleton classes themselves necessarily OO? (When should "singleton" get a capital S?) >> If you want to use one module from several places, you might use "Places" in what sense? I don't understand the problem - what's stopping me saying "use Foo" wherever necessary? >> Class::Singleton to access the module from any places. "Any places" should be... something different. And this sentence seems repetitive. But I'm not sure what it's trying to say. Why would I want to use Class::Singleton to access a module? >> But you should subclass each modules to singletonize. "Each" should probably be followed by singular "module", but I can't follow this. Does it mean "in order to singletonize (something) you should subclass each module"? Or maybe "Each module which is to be singletonized should be subclassed"? Or "You should subclass each and every module, so that singletonization occurs"? Or... what? >> This module provide singleton container instead of module itself, Wrong agreement (provides), missing article(s). But what is it trying to say? "This X provides a Y instead of X itself"? My brain hurts. >> so it is easy to singleton multiple classes. > > Is it easier to use a noun as a verb than explain it in plain English? It could at least have re-used "singletonize" instead of invoking it as a one-off. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131022172930.ga20...@xibalba.demon.co.uk
Bug#721267: ITP: iwsy -- Analyze #includes in C and C++ source files
Sylvestre Ledru wrote: > * Package name: iwsy [...] > "Include what you use" means this: for every symbol (type, function variable, [...] Shouldn't that be "iwyu"? -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130829231302.ga25...@xibalba.demon.co.uk
Bug#718791: ITP: mikutter -- Simple, powerful and moeful twitter client
Jonathan Nieder wrote: > Chris Bannister wrote: >> HIGUCHI Daisuke (VDR dai) wrote: >>> Mikutter is a simple, powerful and moeful twitter client. >> >> I can't find any definition of "moeful" > > Maybe it means "cute". It's not immediately obvious how a Twitter client could be "cute", and translating it would lose the fact that (judging by the upstream website) it's "cute" in a specifically Japanese sense - it's not talking about photos of puppies, it means cartoons of young girls... Maybe the safest translation would be "anime-themed"? >>>* Followee, Follower list >> >> No such word. It does seem as if it should be an unnecessary coinage - aren't the things being listed here "subscriptions"? But what is this line trying to say? Does mikutter present a single list that includes both the accounts you're following and the accounts that are following you, or does it have two separate lists? If it's the latter, why not give them a bulletpoint each? And then what is the "List view" three bullets later? It's really unclear what some of these "views" are talking about. Some of them must be different ways of viewing tweets, but then there are the ones like "Profile view". And while it's on debian-l10n-english, here are some extra stylistic nitpicks: the synopsis shouldn't be capitalised, Twitter on the other hand should be capitalised, there should be a comma before the "and" (according to our usual d-l-e house style), the long description shouldn't repeat the synopsis, and the bulletpoints don't need to be indented that far. I would suggest a package description like this: Description: simple, powerful anime-themed Twitter client Mikutter is a multi-pane Twitter client with several advanced features: * different tweet views (flat list, threaded list, searches); * user profile and activity views; * lists of followers and subscriptions. WARNING: some of that is guesswork, and needs to be replaced by an accurate description. ObWhyTheName: the logo and icon are pictures of Hatsune Miku®, so I hope Crypton Future Media, Inc don't mind. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130806113818.ga23...@xibalba.demon.co.uk
Bug#605001: Request for package: Ubuntu's usb image creator software
Dmitrijs Ledkovs wrote: > Please note this RFP has already previously been filed as > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=576359 > > Please consider merging these two together. Good advice. > And usb-creator is a better name for a package. Bad advice - it would prevent it getting through NEW. See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582884#77 If it created bootable LiveCDs and installer-CDs, "cd-creator" would be a poor but tolerable name and "bootcd-creator" would be fine. But even "bootusb-creator" would still be a terrible name for this package, because there's no such thing as a bootable USB (or "a USB" in general), and because the software also works on non-USB media. -- JBR already reserving a space at http://wiki.debian.org/WhyTheName -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120409215357.ga30...@xibalba.demon.co.uk
Bug#641899: description for new package ebook-speaker
Paul Gevers wrote: > This package is a simple command-line program that reads the content of > an EPUB e-book out with espeak. The issue that I have is with the > English expression "to read out". I believe that most non-native speaker > might not recognize that this package is not meant for the user to read > the e-book (only the chapters are displayed), but that this program > mostly gives audio output. I have the current description (inspired by > my daisy-player description), but improvements are very welcome. It works in context (in the long description), but for the synopsis I'd suggest "reads aloud". > Description : eBook reader that reads out via synthetic voice > ebook-speaker is a command-line electronic book reader that reads out > eBooks using speech synthesis. (Currently only the EPUB format is > supported). It has a simple user interface appropriate for Braille > terminals. It took me a moment to parse "command-line electronic book reader"; eBook does need to be expanded somewhere, but if you shift it you could fit in the word "e-reader", in case anybody's searching for that. (Or should it be "eReader"?) And I suppose I would suggest splitting out the bit you're hoping will need to be revised: Description: eBook reader that reads aloud in a synthetic voice This package provides a command-line e-reader that reads out electronic books using speech synthesis. It has a simple user interface appropriate for Braille terminals. . Currently only the EPUB format is supported. -- JBR Ankh kak! (Ancient Egyptian blessing) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110918125925.ga28...@xibalba.demon.co.uk
Bug#626159: ITP: scilab-jims -- Binding the worlds of Scilab and Java
Christian PERRIER wrote: > Quoting Sylvestre Ledru (sylves...@debian.org): >> Description: Binds Java from the Scilab engine > > That's still a verb sentence and still has a leading capital..:) > > How about "Scilab Java bindings" > > (here, the leading capital is OK as this is the official spelling of Scilab Or (mostly just to keep it from looking too much like a repeat of the package name): Description: Java bindings for the Scilab engine >> JIMS is an effort to allow Scilab programs full access to Java class >> libraries. This is achieved by interfacing at the native level in both >> Virtual Machines. "Effort to" and "achieved" don't really go together - if its aims are really achieved, it's more than just an effort. I don't know what interfacing at the native level is exactly, but having looked up what JIMS stands for it sounds as if you could say something like: The Java Interaction Mechanism in Scilab (JIMS) provides a native-level interface between the two Virtual Machines, giving Scilab programs full access to Java class libraries. >> . >> From Scilab, JIMS allows the capability to load and manage Java objects >> from the Scilab interpreter. > > "allows the capibility" is too french for being honest..:-). See > http://wiki.debian.org/I18n/SmithDebconfReviewGuidelines for what is > allowed after "allow" And now that I've expanded JIMS the repeats of "Java" and "Scilab" are getting a bit excessive (especially here where it seems to repeat the "from Scilab" part). [...], giving Scilab programs full access to Java class libraries and allowing them to load and manage Java objects. >> . >> Thanks to this module, Scilab can access to complex and advanced Java >> objects >> with Scilab classical data types. > > I suspect that "thanks to this module" can be improved. "Access" doesn't need "to". But is this "can access objects with (=that have) Scilab classical data types" or "can access objects with (=by using) Scilab classical data types"? I'd guess the latter, but that means it looks like just another item to merge into that list of things it allows Scilab to do. Something like: Description: Java bindings for the Scilab engine The Java Interaction Mechanism in Scilab (JIMS) provides a native-level interface between the two Virtual Machines. It gives Scilab programs full access to Java class libraries, allowing them to load and manage complex and advanced Java objects using Scilab's classical data types. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110509145906.ga29...@xibalba.demon.co.uk
Bug#595292: Request for review of daisy-player package description
Paul Gevers wrote: > Description: player for Daisy talking books (DTB) If you need to give the expansion, there's not much point including the abbreviation in the synopsis; but anyway, surely it's: Description: player for DAISY Digital Talking Books (Plain "talking books" usually means tape or audio-CD, whereas I gather that DTB is some sort of file-archive using XML.) > Daisy-player is a command line player for talking books based on the > DAISY protocol (currently only version 2 is supported). It is > comparable in functionality, features and ease of use with commercial > players. The interface of this program is simple and appropriate for > braille terminals. Is it the player or the books that are based on the DAISY protocol? Probably both, I suppose. Expanding DAISY would help clarify that this isn't just a random ebook format, it's particularly intended for a11y purposes: Daisy-player is a command-line player for talking books based on the Digital Accessible Information System protocol (currently only version 2 is supported). It is comparable in functionality, features, and ease of use with commercial players, and has a simple user interface appropriate for Braille terminals. While I'm rewriting it I've thrown in an extra comma, rephrased a line, and capitalised Braille. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101128184254.ga1...@xibalba.demon.co.uk
Bug#582884: ITP: usb-creator -- Live USB creator
Dmitrijs Ledkovs wrote: > Mehdi Dogguy wrote: > * Package name : usb-creator "usb-creator" is a bit misleading (or at least… not clear). Could you rename it into something like "live-usb-creator"? >>> >>> This package has been shipped in Ubuntu for a few releases now. >> >> Honestly, I don't know how you (as a team) ended up with such a name. > > it was before me. But there is liveusb-creator package already > developed and packaged in Fedora [1] > > [1] https://fedorahosted.org/liveusb-creator/ Speaking as a random bystander who just happened to notice this Debian ITP and went "WTF?", I would like to point out that "usb-creator" and "liveusb-creator" are two different strings, and that even "liveusb-creator" may be less than self-explanatory for people who don't happen to have been reading the boot-CD development mailinglists for the past few years. For us outsiders, "LiveUSB" is an unfamiliar piece of jargon. I gather it's formed by analogy with "liveCD", but the difference is that "live CDs" are literally a kind of CD (like "music CDs" and "data CDs"), while "live USBs" aren't any kind of USB - they're a kind of flash drive. Taking that already confusing term and leaving off the "live" eliminates the only clue that it has something to do with booting an operating system, and leaves us wondering how you've managed to package a Creator that can be plugged into a USB port. So if you're going to insist on giving these packages newbie-hostile names, please at least say you'll give them intelligible short descriptions, not just ones that expand the name slightly. I would suggest instead of having synopses like this: Package: usb-creator-common ... Description: Live USB creator (common files) they should be more along the lines of: Package: usb-creator-common ... Description: tool for putting OS images on flash drives - common files -- JBR Ankh kak! (Ancient Egyptian blessing) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100524161923.ga6...@xibalba.demon.co.uk
Bug#561307: RFP: dos2unix -- convert text file line endings between CRLF and LF
Jari Aalto wrote: > Subject: RFP: dos2unix -- convert text file line endings between CRLF and LF See: http://packages.debian.org/tofrodos -- JBR Ankh kak! (Ancient Egyptian blessing) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#462606: ITP: dejima-mincho -- antiquated Japanese TrueType Mincho font, Dejima Mincho
Ron Johnson wrote: > On 02/06/08 04:54, Hideki Yamane wrote: >> "Antique-looking Japanese TrueType Mincho, based on Meiji-era font" >> >> Is it OK? > > IMO, both this and Justin's suggestions are good. I thought this one didn't work - is it saying it's a Mincho, which is based on a font? Make it simpler... either: Japanese TrueType Mincho font based on Meiji-era designs or move the historical details to the long description and say: antique-looking Japanese TrueType Mincho font (there's no need for initial capitalisation in short descriptions). Alternatively you could say: Meiji-era Japanese TrueType Mincho font Meiji-style Japanese TrueType Mincho font (The first implies that it really is from the 19th century - that it's the original font, converted into .ttf format. The second implies it's a modern font based on the look of 19th-century ones.) -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462606: ITP: dejima-mincho -- antiquated Japanese TrueType Mincho font, Dejima Mincho
Ron Johnson wrote:
>> So can you give me any suggestion for suitable word?
>> You can see it at http://www.sodan.org/~penny/blosxom.cgi/fonts
>>
>> and CC'ing the -english mailing list for advices.
>
> Historical calligraphy?
>
> Meiji-era calligraphy?
"Antique-looking" wan't bad ("Antiquated" is old and useless,
"antique" is old and valuable). I was thinking "classical", but
in Japan that means pre-1185, so yes, "Meiji-era" (or "Edo-era",
depending on the exact date, or "historical" if we don't know).
But no need to call it calligraphy - that style's roughly what
"Minchō" means (see "http://www.sljfaq.org/w/Minch%C5%8D";).
So would that make it:
Meiji-era Japanese TrueType Minchō font
Or does it have to be ASCII?
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462792: ITP: failmalloc -- demonstrate what really happens if memory allocation fails
Christian Perrier wrote: > Quoting Hideki Yamane ([EMAIL PROTECTED]): >> Description: tool to address problems when memory allocation fails >> >> Is it okay? That's a valid short description now. > I think that moving the most important part at the beginning would be > better: > > "memory allocation failure analysis tool" Looks good to me. But these descriptions all sound like things you execute to debug a past malloc error; instead as far as I can see from http://www.nongnu.org/failmalloc it's an LD_PRELOAD library for *inducing* them. Would that be a... memory allocation failure crash-test tool memory allocation robustness testing preload library memory allocation failure simulator Or something like that? -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#456597: Please review package description of dctrl2xml
Frank S. Thomas wrote: > Could someone please review the package description of my recently ITP'ed > dctrl2xml tool: Looks pretty good. >> Description: convert Debian control data to XML No, short descriptions should say what it is, not what it does. Something like: Description: Debian control data to XML converter (If it would also be useful in Ubuntu, maybe we need a more generic word for the Debian-standard control file format. Or maybe Ubuntu users just need to learn where their OS's package-management system comes from.) Otherwise, I can only see stylistic nitpicks: >> This package contains the dctrl2xml tool that converts Debian control >> data into an XML representation. It can be used to convert data which >> is normally found in debian/control, .changes, .dsc, Packages, >> Sources, and similar files to XML. >> . >> For most fields dctrl2xml just uses the field name as element name >> and the field data as element content. For other fields like package >> interrelationship fields (Depends, Build-Depends, etc.) or the Files >> field in .changes or Sources files dctrl2xml additionally parses their >> field data to represent it in a more fine structured form. I'd prefer s/like/such as/ and some stronger punctuation: and the field data as element content. For other fields, such as package interrelationship fields (Depends, Build-Depends, etc.) or the Files field in .changes or Sources files, dctrl2xml additionally parses their field data to represent it in a more fine-structured form. ^ Also an extra hyphen: ---' -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428256: ITP: ffrenzy -- Multiplayer platform with dwarfs fighting with/for food
Christian Perrier wrote: > multiplayer game featuring dwarves fighting with/for food "Dwarfs" and "dwarves" are both used, but "dwarfs" is more traditional (Disney's Snow White had dwarfs). JRR Tolkien used "dwarves" as a sort of philological in-joke, and fantasy writers have tended to copy him ever since. ... > The game features dwarves who need to collect food as fast as > possible to bring it back to their mushrooms to live. When a dwarf > leaves home without providing it with food for too long, (s)he dies Do we know whether any of them are represented as female? In a lot of fantasy settings it's assumed that females are never seen, or that they're all treated as male... -- JBR Ankh kak! (Ancient Egyptian blessing) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
