Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Le Sat, Jul 05, 2008 at 11:04:31AM +0800, Paul Wise a écrit : > wwwconfig-common may provide what you need. Le Fri, Jul 04, 2008 at 11:34:43PM -0400, Richard Hurt a écrit : > You could also check out webapps-common > (http://webapps-common.alioth.debian.org/draft-wac/html/index.html ) > although I don't know which one is more current/appropriate. Thanks for your answers! Unfortunately webapps-common is dead upstream, and wwwconfig-common does not provide debconf templates. I think that I will just drop a symlink in /etc/apache2/conf.d and hope that some magic will be done some day with DPKG triggers. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
You could also check out webapps-common (http://webapps-common.alioth.debian.org/draft-wac/html/index.html ) although I don't know which one is more current/appropriate. Later... Richard On Jul 4, 2008, at 11:04 PM| Jul 4, 2008, Paul Wise wrote: wwwconfig-common may provide what you need. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
wwwconfig-common may provide what you need. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Factorised code for adding a file in /etc/apache2/conf.d/ and restarting apache ?
Dear Mentors and Apache maintainers, In the course of making a package (emboss-explorer) FHS-compliant, I moved its files from /var/www to /usr/share. I would like http://localhost/mypackage to work after package installation just as before when the package was installing its files in the default document root of apache2 (and maybe other webservers). For the moment I will only support apache2 because of my lack of knowledge of other systems, but of course suggestions on how to achieve this with other httpd-cgi servers are appreciated. After insallation, the package must: - Check if apache2 is there, - if yes add a link to a configuration file in /etc/apache2/conf.d - restart apache. Of course, I can cut-and-paste from the postinst script of other packages already implementing this, but before doing so I was wondering if there were some factorised code somewhere that I could call instead. (I am also wondering if I have to ask the user wether he agrees to restart apache...) In the worst case, I can just document in README.Debian that the link has to be created and apache restarted, but as the package I am working on is a www interface to a command-line program, I would prefer that it does not require command-line intervention, since its public is partly composed of persons who are not comfortable with command-line. PS: would the DPKG triggers be a good mechanism to deal with this apache restarting tasks? Have a nice day, -- Charles Plessy Debian-Med packaging team, Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: genwebgallery
Just to put another 2 cents on this topic... I think I got Patrick's point as well as Asheesh's one. My personal opinion is that I just don't like those packages filled with lots of stuff I don't need but I need to install when I want a small part of it (like a 200 lines script), but IANADD. On Fri, Jul 04, 2008 at 08:41:02PM +0200, Patrick Schoenfeld wrote: > I ask to *just think* a moment weither a single package is adequate for a > single 200 line script, or not. And I really appreciate that always some of us are looking on things from another point of view. Since I like this package (and I looked at it; it seems to be in a good shape) I'd really like if a DD would spend some time on it. So, volunteers? :) Cheers, Hauke signature.asc Description: Digital signature
Re: RFS: mozvoikko - Finnish spell-checker extension for Iceweasel and Icedove
On Thu, Jul 03, 2008 at 07:06:21PM +0300, Heikki Mäntysaari wrote:
> 2008/7/1 Mike Hommey <[EMAIL PROTECTED]>:
> >
> > Just generate one package, with symlinks in the proper directories. Take
> > a look at packages such as livehttpheaders or venkman.
> >
> > Note that in the future, there will be a canonical place for extensions:
> > /usr/share/mozilla/extensions.
> >
> > Mike
>
> Do you mean /usr/share/mozilla-extensions dir? At least venkman is
> installed in that directory.
I do mean /usr/share/mozilla/extensions. /usr/share/mozilla-extensions
is where I did put these shared files in my mozilla extensions packages,
and where symlinks in /usr/lib/$app/extensions point to.
/usr/share/mozilla/extensions is a new location that new upstream looks at.
That means iceweasel 3.0 does look into /usr/share/mozilla/extensions
too, and doesn't need a link in /usr/lib/iceweasel/extensions if the
shared files are in /usr/share/mozilla/extensions. It also means iceape
2 and icedove 3, when they will be available, will also look there.
Note that directory names in /usr/share/mozilla/extensions must contain
a '@' character (usually, that would be [EMAIL PROTECTED]) or be a
uuid between curly braces ("{}").
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: clamfs (updated package)
OoO En cette soirée bien amorcée du mercredi 25 juin 2008, vers 22:46, "Krzysztof Burghardt" <[EMAIL PROTECTED]> disait : > I am looking for a sponsor for the new version 0.9.1-3 > of my package "clamfs". Hi Krzysztof! I have uploaded your package. Thanks for your contribution. -- if (user_specified) /* Didn't work, but the user is convinced this is the * place. */ 2.4.0-test2 /usr/src/linux/drivers/parport/parport_pc.c pgpIq4zsE0DrZ.pgp Description: PGP signature
Re: RFS: witty (updated package)
OoO Pendant le repas du lundi 23 juin 2008, vers 19:11, Pau Garcia i
Quiles <[EMAIL PROTECTED]> disait :
> I am looking for a sponsor for the new version 2.1.3-1
> of my package "witty".
Hi!
Sorry for the late answer. I did not spot your new upload. You can ping
me if I fail to answer in less than a week next time.
Instead of patching LICENSE file, you should just state the OpenSSL
exception in debian/copyright (with the fact that it is not present in
the LICENSE yet, but this has been fixed in CVS). A link to the CVS
commit that adds it will be appreciated by ftp-masters.
Please, don't keep commented commands in debian/rules.
About the extra licenses, you should just remove them of the
installation (with rm in debian/rules). You can keep them in
orig.tar.gz. They are just considered superflous since they are copied
verbatim in debian/copyright.
Regards.
--
panic("bad_user_access_length executed (not cool, dude)");
2.0.38 /usr/src/linux/kernel/panic.c
pgpCG9xTEoeOl.pgp
Description: PGP signature
Re: RFS: genwebgallery
Hi, On Fri, Jul 04, 2008 at 10:57:34AM -0700, Asheesh Laroia wrote: > Honestly, disks are cheap, and buildds don't spend a lot of time on shell > script packages since they don't need to be built. 5 kilobytes for a > .deb file and its source packaging is not a great burden to ask of the > mirror operators. (And five kilobytes is a generous estimate.) I wouldn't really mind if I would buy the diskspace, but given that mirror operators do it on a volunteer base, do it free and do not only mirror our archives I think we should have some sanity. Its not that I ask to exclude the script from Debian. I ask to not *waste* space at the wrong places. Disk space is cheap, you say. Thats true, if people have a chance to decide weither they want to waste that particular byte or not. Mirror operators don't have the choice (or better said they give space to the project and ask it to use it sane), so we do have to be sane. Users have the choice, they can decide weither they install a great package including thousands of little scripts and binaries, or not. I ask to *just think* a moment weither a single package is adequate for a single 200 line script, or not. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Natural Language Toolkit (NLTK)
OoO La nuit ayant déjà recouvert d'encre ce jour du samedi 21 juin 2008, vers 23:21, "Steven Bird" <[EMAIL PROTECTED]> disait : > Hi -- I'm looking for a sponsor to help with packaging NLTK please. > Package: Natural Language Toolkit (NLTK) Hi Steven! Did you get some help? The start point to package something for Debian is here: http://www.debian.org/doc/maint-guide/ -- Each module should do one thing well. - The Elements of Programming Style (Kernighan & Plauger) pgpxCZo7H765a.pgp Description: PGP signature
Re: RFS: genwebgallery
On Fri, 4 Jul 2008, Patrick Schoenfeld wrote: Hi, On Wed, Jun 18, 2008 at 07:29:49PM +0200, markus schnalke wrote: But back to `genwebgallery': I think packages should be like programs according to the Unix philosophy: - small and simple - do one thing well I would usually agree with you, but only to some extent. After all each package has a given overhead, needs mirror space and bandwith. If you package is only a 200 lines shell script its just questionable if the ratio program ./ additional needed space for the packaging is okay. Also consider that my argumentation is not that your utility isn't worth to be included into Debian. My argumentation is, that it would be good to add it to another package, which includes similar tools. This way the general overhead is reduced, mirror space isn't excessive used and the user who would otherwise install both tools (which is very likeley if tools are similar) would save some wasted space, too. Honestly, disks are cheap, and buildds don't spend a lot of time on shell script packages since they don't need to be built. 5 kilobytes for a .deb file and its source packaging is not a great burden to ask of the mirror operators. (And five kilobytes is a generous estimate.) Is this a real issue? I don't mean to flame, but to understand and create a coherent perspective. (-: -- Asheesh. -- I am having FUN... I wonder if it's NET FUN or GROSS FUN? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lockrun
On Thu, Jul 03, 2008 at 12:52:46PM -0500, Raphael Geissert wrote: > What has upstream's response? If you really want the package in Debian but > upstream doesn't want to integrate your patches without a good reason you > could anyway package it, drop a few lines in debian/README.Debian and look > for a sponsor. The upstream told me that my patch was too much hassle and as he didn't understand the implications for other distributions or users he would not accept it and was unwilling to work on an edited version. An uncooperative upstream and my lack of C skills are not a good combination. You are welcome to take over, it's packaging is largely a fait accompli. Thanks, -- Noah Slater, http://bytesexual.org/nslater -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice on project name change request
IANADD
From: Matteo Vescovi <[EMAIL PROTECTED]>
Subject: Advice on project name change request
Date: Fri, 4 Jul 2008 09:52:16 + (GMT)
> Hallo mentors,
>
> I come to you to ask for advice on how to best handle the situation I'm about
> to describe, hoping you can provide some insights.
>
> I am the developer and maintainer of soothsayer [1], a GPL-licensed
> intelligent predictive text-entry system, which I am also packaging for
> Debian [2].
>
> Recently, I received an email from a software company called Applied Human
> Factors [3], who have been selling an application called "Soothsayer Word
> Prediction" for the past 12 years.
>
> They kindly and respectfully requested that I change the name of my
> soothsayer project, so that it is not confused with their "Soothsayer Word
> Prediction" product.
>
> I understand their concern and I find their request very reasonable.
> I intend to comply with their request and change my project's name, despite
> the fact that the soothsayer name had begun to receive some attention [4].
>
> I would like some advice on the following items:
> - how different should the new name be? I considered using names such as
> "predict" or "guess", but they are already taken, so I thought about using
> "soothie" (short for soothsayer, sort of :-) ), but would this name be
> different enough? I'm currently leaning towards using "presage" as the new
> name.
[EMAIL PROTECTED]:/var/lib/myfrdcsa/codebases/internal/perllib/scripts$ bard -c
soothsayer
$VAR1 = {
'Rhyme' => undef,
'Regex' => '.',
'MaxSize' => undef,
'SeedWords' => [
'soothsayer'
],
'Relation' => '==',
'Syllables' => '0',
'Subtone' => undef
};
forecaster, illusionist, predictor, prognosticator, seer, soothsayer,
visionary, conjurer, conjuror, intellect, intellectual, magician,
performer, performing artist, prestidigitator, computer, computing
device, computing machine, data processor, electronic computer,
information, information processing system, beholder, diviner,
observer, oracle, perceiver, percipient, prophesier, prophet,
vaticinator, Laputan, airy, impractical, individual, mortal, person,
somebody, someone, soul, utopian (vs. dystopian), windy, conjure man,
witch doctor, faculty, intelligence, mental faculty, mind, module,
reason, understanding, highbrow, highbrowed, intellectual
(vs. nonintellectual), mental (vs. physical), noetic, rational,
necromancer, occultist, sorcerer, thaumaturge, thaumaturgist, wizard,
entertainer, calculator, estimator, expert, figurer, machine,
reckoner, accumulation, accusal, accusation, aggregation, assemblage,
cognition, collection, content, data, entropy, info, information
measure, knowledge, message, noesis, selective information, subject
matter, substance, divine, elysian, glorious (vs. inglorious),
godlike, godly, heavenly (vs. earthly), inspired, providential, sacred
(vs. profane), superhuman (vs. subhuman), commentator, divination,
prophecy, shrine, clear, discerning (vs. undiscerning), religious
person, aerial, aeriform, aery, aired, ethereal, insubstantial
(vs. substantial), light (vs. heavy), unreal, unsubstantial,
ventilated (vs. unventilated), crazy, half-baked, impractical
(vs. practical), screwball, softheaded, being, case-by-case,
idiosyncratic, independent (vs. dependent), individual (vs. common),
individual(prenominal), item-by-item, organism, personal
(vs. impersonal), private, single, single(prenominal), unshared
(vs. shared), deadly, deathly, earthborn, fatal (vs. nonfatal),
merciless (vs. merciful), mortal (vs. immortal), mortal(prenominal),
unmerciful, unpardonable (vs. pardonable), anatomy, bod, build,
chassis, figure, flesh, form, frame, grammatical category, human body,
material body, physical body, physique, shape, soma, syntactic
category, embodiment, feeling, gospel, gospel singing, psyche,
soulfulness, spirit, Utopian, crusader, meliorist, reformer,
reformist, social reformer, utopian, blowy, breezy, fast (vs. slow),
long-winded, prolix (vs. concise), stormy (vs. calm), tedious,
verbose, wordy, ability, body, power, staff, administrative body,
administrative unit, information gathering, intelligence activity,
intelligence agency, intelligence information, intelligence operation,
intelligence service, news, tidings, word
> - what is the best way to ensure that users looking for soothsayer project
> will easily find the new project name and that the publicity (such as the
> review on Linux.com [4]) that soothsayer received will not be wasted?
You can always mention on your site something to the effect of "presage used to
be called soothsayer".
> - how should this name change be handled in the BTS? Should I retitle the
> ITP? Or close it and open a new one?
>
> Finally, how strong a case do Applied Human Factors have here? This is just
> out of curiosity, I fully appreciate that their request is justi
Re: Advice on project name change request
Patrick Schoenfeld <[EMAIL PROTECTED]> writes: > that is probably a question that a lawyer can answer only. Otherwise > ask the company who asked for the rename if they are okay with your > favorite. If one is to rely on such an informal response from the company, ask for it in writing of some form, and get them to be clear that they represent the company's position on this. It makes absolutely no difference to some putative later iteration of management if some predecessor informally okayed the name. Without a firm statement of the position of the company at the time, you have little to no defense. Case in point: The Firefox trademark handball [0] that occurred to Debian, with MozillaCorp deciding out of the blue that some predecessor was not actually representing the company's position, represented a total waste of negotiation effort up to that point. With that in mind, you should try to get either expert legal advice or, failing that, firm written commitment from someone who says (and you believe) to be representing the company's official position. [0]: bug#354622, http://bugs.debian.org/354622> -- \ “If you were going to shoot a mime, would you use a silencer?” | `\—Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nemesis (updated package)
Now here is the package (at last) lintian clean http://mentors.debian.net/debian/pool/main/n/nemesis/nemesis_1.4-1.dsc I deserve an upload! :) Regards! 2008/7/4 William Vera <[EMAIL PROTECTED]>: > Thanks Paul :) > Now the package is lintian clean > at last! > > Cheers > > 2008/7/4 Paul Wise <[EMAIL PROTECTED]>: >> On Fri, Jul 4, 2008 at 6:14 PM, William Vera <[EMAIL PROTECTED]> wrote: >> >>> But these file are in build, if I delete them, the package don't build >>> Sorry maybe I'm a little lose, can you give more details? >> >> If you run autotools during the build, something like this: >> >> build: >>autoreconf --force --install >>./configure >>... >> >> clean: >>rm -f aclocal.m4 config.h.in configure >> >> Those particular files should not be changed unless autoconf/automake >> are being run during the build. >> >> -- >> bye, >> pabs >> >> http://wiki.debian.org/PaulWise >> >> >> -- >> To UNSUBSCRIBE, email to [EMAIL PROTECTED] >> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >> >> > > > > -- > William Vera <[EMAIL PROTECTED]> > PGP Key: 1024D/F5CC22A4 > Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 > -- William Vera <[EMAIL PROTECTED]> PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nemesis (updated package)
Thanks Paul :) Now the package is lintian clean at last! Cheers 2008/7/4 Paul Wise <[EMAIL PROTECTED]>: > On Fri, Jul 4, 2008 at 6:14 PM, William Vera <[EMAIL PROTECTED]> wrote: > >> But these file are in build, if I delete them, the package don't build >> Sorry maybe I'm a little lose, can you give more details? > > If you run autotools during the build, something like this: > > build: >autoreconf --force --install >./configure >... > > clean: >rm -f aclocal.m4 config.h.in configure > > Those particular files should not be changed unless autoconf/automake > are being run during the build. > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- William Vera <[EMAIL PROTECTED]> PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nemesis (updated package)
On Fri, Jul 4, 2008 at 6:14 PM, William Vera <[EMAIL PROTECTED]> wrote: > But these file are in build, if I delete them, the package don't build > Sorry maybe I'm a little lose, can you give more details? If you run autotools during the build, something like this: build: autoreconf --force --install ./configure ... clean: rm -f aclocal.m4 config.h.in configure Those particular files should not be changed unless autoconf/automake are being run during the build. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: nemesis (updated package)
2008/7/3 Paul Wise <[EMAIL PROTECTED]>: > On Fri, Jul 4, 2008 at 10:55 AM, William Vera <[EMAIL PROTECTED]> wrote: > >> No, that warnings are patched, I talk about this warnings: >> >> W: nemesis source: patch-system-but-direct-changes-in-diff aclocal.m4 >> N: >> N: The package uses a patch-system, but the Debian diff.gz contains >> N: changes made on files without being separated out in a patch. >> N: >> W: nemesis source: patch-system-but-direct-changes-in-diff config.h.in >> W: nemesis source: patch-system-but-direct-changes-in-diff configure >> >> I can't delete them because are by upstream. > > Delete them in the clean rule of debian/rules and their changes will > not be added to the diff.gz. But these file are in build, if I delete them, the package don't build Sorry maybe I'm a little lose, can you give more details? thanks > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- William Vera <[EMAIL PROTECTED]> PGP Key: 1024D/F5CC22A4 Fingerprint: 3E73 FA1F 5C57 6005 0439 4D75 1FD2 BF96 F5CC 22A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice on project name change request
Hi Matteo, On Fri, Jul 04, 2008 at 09:52:16AM +, Matteo Vescovi wrote: > - how different should the new name be? I considered using names such as > "predict" or "guess", but they are already taken, so I thought about using > "soothie" (short for soothsayer, sort of :-) ), but would this name be > different enough? I'm currently leaning towards using "presage" as the new > name. that is probably a question that a lawyer can answer only. Otherwise ask the company who asked for the rename if they are okay with your favorite. > - what is the best way to ensure that users looking for soothsayer project > will easily find the new project name and that the publicity (such as the > review on Linux.com [4]) that soothsayer received will not be wasted? Probably keep the soothsayer.sf.net site for a while, make a hint on the page that this is not related to the product of the company you've stated, that the project has been renamed to avoid confusions and then redirect after some seconds. Talk to the company that this is the way you want to go, because you also have an interest in protect. Consider some grace period after which this project will be deleted. Probably you also need to let the sf team acknowledge this, but I don't know. > - how should this name change be handled in the BTS? Should I retitle the > ITP? Or close it and open a new one? No need to open a new one. Just retitle it. > Finally, how strong a case do Applied Human Factors have here? What does that mean? Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice on project name change request
Matteo Vescovi <[EMAIL PROTECTED]> writes: > Recently, I received an email from a software company called Applied > Human Factors [3], who have been selling an application called > "Soothsayer Word Prediction" for the past 12 years. > > They kindly and respectfully requested that I change the name of my > soothsayer project, so that it is not confused with their > "Soothsayer Word Prediction" product. > > I understand their concern and I find their request very reasonable. Agreed. This is exactly the sort of same-field name confusion that trademark law is intended to prevent. It's good that you're being approached amicably. > I intend to comply with their request and change my project's name, > despite the fact that the soothsayer name had begun to receive some > attention [4]. > > I would like some advice on the following items: > - how different should the new name be? Different enough that a reasonable person won't be misled into confusing the two products by their names. Hard definitions of where the line falls on "reasonable" and "confuse" can only be had by expert legal advice, which I strongly encourage you to seek. > - what is the best way to ensure that users looking for soothsayer > project will easily find the new project name and that the publicity > (such as the review on Linux.com [4]) that soothsayer received will > not be wasted? I would advise: Keep the web domain you have (if any), and change all material to make it clear that there are two products, and provide clear links to both of them. > - how should this name change be handled in the BTS? Should I > retitle the ITP? Or close it and open a new one? I don't have an answer on this one. > Finally, how strong a case do Applied Human Factors have here? (Presumably you're asking whether, if they were to sue for trademark infringement, they would have a strong case.) I would find it confusing, and I consider myself a reasonable person :-) -- \“I was in the grocery store. I saw a sign that said ‘pet | `\ supplies’. So I did. Then I went outside and saw a sign that | _o__) said ‘compact cars’.” —Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Advice on project name change request
Hallo mentors, I come to you to ask for advice on how to best handle the situation I'm about to describe, hoping you can provide some insights. I am the developer and maintainer of soothsayer [1], a GPL-licensed intelligent predictive text-entry system, which I am also packaging for Debian [2]. Recently, I received an email from a software company called Applied Human Factors [3], who have been selling an application called "Soothsayer Word Prediction" for the past 12 years. They kindly and respectfully requested that I change the name of my soothsayer project, so that it is not confused with their "Soothsayer Word Prediction" product. I understand their concern and I find their request very reasonable. I intend to comply with their request and change my project's name, despite the fact that the soothsayer name had begun to receive some attention [4]. I would like some advice on the following items: - how different should the new name be? I considered using names such as "predict" or "guess", but they are already taken, so I thought about using "soothie" (short for soothsayer, sort of :-) ), but would this name be different enough? I'm currently leaning towards using "presage" as the new name. - what is the best way to ensure that users looking for soothsayer project will easily find the new project name and that the publicity (such as the review on Linux.com [4]) that soothsayer received will not be wasted? - how should this name change be handled in the BTS? Should I retitle the ITP? Or close it and open a new one? Finally, how strong a case do Applied Human Factors have here? This is just out of curiosity, I fully appreciate that their request is justified and I intend to honour it. Cheers, - Matteo [1] http://soothsayer.sourceforge.net/ [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468820 [3] http://www.ahf-net.com/ [4] http://www.linux.com/feature/135093 __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: genwebgallery
Hi, On Wed, Jun 18, 2008 at 07:29:49PM +0200, markus schnalke wrote: > But back to `genwebgallery': > > I think packages should be like programs according to the Unix > philosophy: > - small and simple > - do one thing well I would usually agree with you, but only to some extent. After all each package has a given overhead, needs mirror space and bandwith. If you package is only a 200 lines shell script its just questionable if the ratio program ./ additional needed space for the packaging is okay. Also consider that my argumentation is not that your utility isn't worth to be included into Debian. My argumentation is, that it would be good to add it to another package, which includes similar tools. This way the general overhead is reduced, mirror space isn't excessive used and the user who would otherwise install both tools (which is very likeley if tools are similar) would save some wasted space, too. Just my 2 cents. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: RFS: bluemindo
Hi, On Thu, Jul 03, 2008 at 11:25:18AM +0200, Thibaut GIRKA wrote: > > Due to the fact that its a GPL license you have the possibility to > > create a symlink to the file in /u/s/common-licenes. > > Or patch bluemindo. First choice probably preferrable. > > Done, but not sure this is the cleanest way. well, you've done it in an overcomplicated way. You call dh_link manually, but thats not neccessary as CDBS already calls it. You just have to add a file debian/links containing all the links that you need to create. This also saves some build-time (not that many, but consider 1000 packages calling a perl script like dh_link twice for no reason), what I consider quiet important, as some architectures are already overloaded. BTW. this is one of the biggest disadvantages I see with CDBS. It seems to call almost every dh_* script for no good reason, without having a clue if it needs to call it or not. This way a CDBS run takes almost always a bit longer, as if you had done it yourself. > Bluemindo does not provide a setup.py file, so I've done what the New > Policy says [2]. Okay. Good. > > So to make your copyright perfect: > > - Remove license excerpts for well known licenses > > - Include complete license information for the PSF, because it is not in > > /u/s/common-licenses > > - Make the human readable part complete (e.g. re-add a Copyright part). > > Hm... The resulting file will be pretty large if I do so. Only because of the PSF, but that is obligatory, because copyright is the single-place to find copyright and licensing information. You have no chance to link somewhere (like /u/s/common-licenses) so you need to include the license. Its as simple as that. > The human readable part... Hm... I switched to the machine-parseable one > because there weren't any 'official' way to do when there are multiple > copyrights/licenses... Well, its okay if you want to keep the machine-parseable part only. I just recommend you to keep a human-readable variant as well, because I think that people who are not technical experienced will have trouble to understand the format and a human-readable version would therefore be an advantage. But obvious you can decide that you don't want that. You can decide to only keep a machine-parseable version. But then do it consistent. Don't include human readable information (like the License block) if you don't intend to keep a human readable version of the copyright file. > I however made some modifications to debian/copyright. Hm. IMHO It looks a bit weird, now, but except the not needed empty lines between the machine parseable part and the human readable part it seems okay. However I have a suggestion for you how the human-readable part could look like. See [1] for it. > > Well, the most window managers probably don't understand the PNG format, > > so yes this is required. However you can do this automatically by > > converting the file with convert and build-depending on imagemagick. > > Done, but like the COPYING symlink, I don't know if I have done it in a > clean way. Given that it isn't a 'install' step you should move it to another target. The CDBS documentation has 'build/foo' for it. > Should be enough, now, provided that cdbs-edit-patch is available. Nearly. I still don't know how I could disable certain patches from beeing applied on build. For example: quilt has a file series which stores the list of patches that will be applied. Its possible to remove entries from there and the patches won't be applied. CDBS does not seem to have such a file, so I wonder how to do it there. You need to document that. Otherwise the fine is simple, but okay. > > Yeah right, but you missed the depend in debian/control. > > It should be ok now. Yeah, alright. > The first patch is now splitted into two patches: one for $DESTDIR and > one for permissions. Great. > However, I'm working with the upstream developer, and we'll apply the > patches as soon we are sure all is fine with the package. Perfect. > I've moved one of them to Suggests. Okay, good. > > - The enumeration in the description is confusing. I still think that this is true and I would also prefer a more terse description. Bluemindo is a really simple but powerful audio player in Python/PyGTK, using GStreamer. . Features include: * Download pictures for artists and album or lyrics of the current playing song * Different view modes (lightweight, basic, normal or full) * Plugin support * Desktop notifications * Change the status message of the Gajim Instant Messenger * Send music to your last.fm profile or your Jabber account I think its not adequate to over-detailled describe the feature (like the details of the view modes). Thats what documentation is for. The user just needs a chance to decide weither this player is worth beeing tried out. I'm open for discussion if the 3 items that are featured via plugins should be handled seperately, but I'm arguing that they are part
Re: RFS: yabause - Yet Another Buggy And Uncomplete Saturn Emulator
On Wed, 2 Jul 2008 00:45:33 +0200 Evgeni Golov wrote: > I am looking for a sponsor for my package "yabause". > > * Package name: yabause > Version : 0.9.6-1 > Upstream Author : Theo Berkau, Guillaume Duhamel, Fabien Coulon > * URL : http://yabause.org > * License : GPL-2+ > Section : utils > > It builds these binary packages: > yabause- Yet Another Buggy And Uncomplete Saturn Emulator > yabause-gtk - Yet Another Buggy And Uncomplete Saturn Emulator - Gtk port > yabause-qt - Yet Another Buggy And Uncomplete Saturn Emulator - Qt port > > Yabause is a Sega Saturn emulator under GNU GPL. > . > Yabause support booting games using Saturn cds or iso files. > > The package appears to be lintian, pbuilder and gcc4.3 clean. > > The upload would fix these bugs: 483124 > > The package can be found on mentors.debian.net: > - URL: http://mentors.debian.net/debian/pool/main/y/yabause > - Source repository: deb-src http://mentors.debian.net/debian unstable > main contrib non-free > - dget > http://mentors.debian.net/debian/pool/main/y/yabause/yabause_0.9.6-1.dsc Just a small note. If you want to test Yabause, and dont have any Sega Saturn games (which might or might not work with yabause), you could try it with some homebrew: http://rockin-b.de/c4-2005-cd.html Regards Evgeni -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
