doc-base: documentation in different languages
Dear mentors, I'm packaging a Java library that contains its usage documentation in both an English version (Documentation.html) and a French version (Documentation_fr.html). I've created a .doc-base file to register the documentation for Debian help viewers. Is there a way to let doc-base know that there are two versions of the documentation available, and that it should display, e.g., Documentation_fr.html if LC_LANG=fr, and Documentation.html otherwise? Thanks for any help, Jan-Pascal signature.asc Description: OpenPGP digital signature
Re: daemon stop and start during upgrade
Felipe Sateler wrote: - Behave sensibly when invoked with 'start' and already running - Behave sensibly when invoked with 'stop' and not running Ah.. yeah, that would be a possible interpretation of the policy. But formalizing something as to behave sensibly is not really exact, cause it is up to the reader how he interprets it. I do interpret it like this: - Don't do nasty things with 'start' when already running (like killing the firsts pidfiles, launching a seconds instance, etc.) - Don't do nasty things with 'stop' when not running (like killing other processes or changing something in the environment so it won't start the next time). I understand it so, that the third one is just there to describe it more exactly. Because exiting with zero or non-zero has absolutely nothing to do with behaving sensibly. Actually returning a non-zero exit code is the right thing to do, cause the action to stop a process _did_ fail, because the process has not been running. Then again it would be sensible not to let the upgrade process fail just because of this, but i think thats far from the scope. So in the end I agree that would be sensible to exit with 0, if the process is not running, cause their might be different errors to occur when stopping (even though I never met one), but that it would make sense to describe this more clear in the policy. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: doc-base: documentation in different languages
On Thu, 13 Sep 2007 08:10:32 +0200 Jan-Pascal van Best [EMAIL PROTECTED] wrote: Dear mentors, I'm packaging a Java library that contains its usage documentation in both an English version (Documentation.html) and a French version (Documentation_fr.html). I've created a .doc-base file to register the documentation for Debian help viewers. Is there a way to let doc-base know that there are two versions of the documentation available, and that it should display, e.g., Documentation_fr.html if LC_LANG=fr, and Documentation.html otherwise? You could just use two files: debian/foo.doc-base.fr debian/foo.doc-base That gets you two entries in the doc base list. I use this to create a doc-base entry for general info and another for the detailed API docs. debian/libqof-doc.doc-base.website debian/libqof-doc.doc-base.doxy (doxy = doxygen, tool to create API docs from the source code.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpowGCu31l0o.pgp Description: PGP signature
Re: busybox
On Wed, 12 Sep 2007 18:22:25 -0700 K. Richard Pixley [EMAIL PROTECTED] wrote: I'm confused about the busybox package. I mean, I'm familiar with busybox and it's applications. However, I'm wondering... If there a reason why busybox should not be packaged in such a way as to provide a mutually exclusive alternative with the packages that it supplants such as coreutils? One reason is that busybox doesn't come with an 'uninstall' option, just an install. I've been bitten by that many times. It's a bit of a fiddle finding the busybox versions and removing them. It is probably safer to not activate busybox by default than to risk an imperfect uninstall script in postrm that leaves the system with a damaged coreutils setup. Reinstalling coreutils won't always fix the issue either. (For the uninitiated, you install the busybox package then run an install command on the system and it is this that puts the busybox executable in place so that it replaces the functionality of 'ls' etc. the difficulty is that precisely which commands get replaced is entirely down to the configuration chosen by the user *prior* to running the install command.) I guess the second reason is that configuration step - it allows busybox to be customised prior to activation but I may be wrong on that. Have you asked the busybox maintainer? It seems to me that intuitively, the busybox package should do exactly that, yet the package we have now does not. Emdebian certainly needs busybox to work that way - I'm guessing that the busybox maintainer expects that kind of functionality from a busybox-udeb. (Which, IIRC, busybox can build.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgplnDFuNXgUJ.pgp Description: PGP signature
Re: doc-base: documentation in different languages
On Thu, 13 Sep 2007 13:18:00 +0200 (CEST) Jan-Pascal van Best [EMAIL PROTECTED] wrote: Please keep this on the mentors mailing list. Is there a way to let doc-base know that there are two versions of the documentation available, and that it should display, e.g., Documentation_fr.html if LC_LANG=fr, and Documentation.html otherwise? You could just use two files: That gets you two entries in the doc base list. Sure. But what I was trying to ask, can I tell doc-base that these are really the same information but in different languages, so that when a French user browses the doc base, he or she sees the French version, while all others see only the English version? 1. If this is gnome-related, use gnome-doc-tools and scrollkeeper. That involves rewriting the docs in docbook / XML. 2. If your .doc package can depend on dwww, then you could use some form of scripting. PHP can do it, perl can do it, even Javascript can have a go at it. Using PHP etc. could get tricky as you are relying on the user having not just http://localhost but a working PHP install too. AFAICT doc-base is not i18n-aware. IMHO it does not need to be aware either. doc-base simply registers documentation for use by other tools. It is up to those other tools whether and how to support i18n and l10n. If you want automation, use i18n-aware tools as in Gnome (and I suspect in KDE too). Using gnome-help, yelp, scrollkeeper or something similar is the standard method but it requires upstream cooperation. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpWn3aBVFBIy.pgp Description: PGP signature
Re: daemon stop and start during upgrade
On Thu, Sep 13, 2007 at 08:33:16AM +0200, Patrick Schoenfeld wrote: Felipe Sateler wrote: - Behave sensibly when invoked with 'start' and already running - Behave sensibly when invoked with 'stop' and not running So in the end I agree that would be sensible to exit with 0, if the process is not running, cause their might be different errors to occur when stopping (even though I never met one), but that it would make sense to describe this more clear in the policy. IIRC, lsb requires exiting with 0 in this case. signature.asc Description: Digital signature
Re: RFS: ario
Hi, As mentioned by other reply, simple rm in clean target should do it. Ok that's what I had done for ario_0.2-2. I just noticed one more thing - as we now have Homepage field support in dpkg, please use it instead of URL pseudo tag (some tools will complain about Homepage for now, but you can ignore it). done. I have uploaded ario_0.2-3 whith this modification. Marc
Re: busybox
Neil Williams wrote: One reason is that busybox doesn't come with an 'uninstall' option, just an install. I've been bitten by that many times. It's a bit of a fiddle finding the busybox versions and removing them. It is probably safer to not activate busybox by default than to risk an imperfect uninstall script in postrm that leaves the system with a damaged coreutils setup. Reinstalling coreutils won't always fix the issue either. This seems like a specious argument to me. If reinstalling coreutils, (and all of the other packages supplanted including util-linux, grep, gzip, hostname, procps, login, mktemp, etc), doesn't restore your system, then there's a bug in the packaging. This same argument could be applied to coreutils by saying that IF it didn't uninstall correctly then it should never be installed in the first place and therefor we should never install coreutils. I think the logical fallacy here is a little more obvious than with busybox, but I think the same fallacy applies to both. (For the uninitiated, you install the busybox package then run an install command on the system and it is this that puts the busybox executable in place so that it replaces the functionality of 'ls' etc. the difficulty is that precisely which commands get replaced is entirely down to the configuration chosen by the user *prior* to running the install command.) I guess the second reason is that configuration step - it allows busybox to be customised prior to activation but I may be wrong on that. Have you asked the busybox maintainer? This also seems like a specious argument. Most of the FSF packages also behave differently depending on how they are configured. Eg, emacs with X11 support vs emacs without X11 support. Part of the value added by debian is that debian makes these sorts of choices for most end users such that end users don't have to do so. There aren't really any user choices when building a source debian package into binary debian packages. There's no configuration step for the debian package. (Yes, there's configuration for the upstream distribution, but this is intended to be hidden by the package maintainer - at least, as far as I understand it which could be flawed.) No, I haven't asked the busybox maintainer. I figured that a step as big as fixing this, which would necessarily involve changes to 10's of packages including many which were already deemed essential would require a much larger blessing. It seems to me that intuitively, the busybox package should do exactly that, yet the package we have now does not. Emdebian certainly needs busybox to work that way - I'm guessing that the busybox maintainer expects that kind of functionality from a busybox-udeb. (Which, IIRC, busybox can build.) That would be an overloaded application of the udeb format and one which, as far as I can understand, is specifically disfavored by the debian developer community. --rich
Re: doc-base: documentation in different languages
Neil Williams wrote: On Thu, 13 Sep 2007 13:18:00 +0200 (CEST) Jan-Pascal van Best [EMAIL PROTECTED] wrote: Sure. But what I was trying to ask, can I tell doc-base that these are really the same information but in different languages, so that when a French user browses the doc base, he or she sees the French version, while all others see only the English version? 1. If this is gnome-related, use gnome-doc-tools and scrollkeeper. That involves rewriting the docs in docbook / XML. It's a Java library, so it's definitely not gnome-related. 2. If your .doc package can depend on dwww, then you could use some form of scripting. PHP can do it, perl can do it, even Javascript can have a go at it. Using PHP etc. could get tricky as you are relying on the user having not just http://localhost but a working PHP install too. For a Java library this would be going way too far. AFAICT doc-base is not i18n-aware. IMHO it does not need to be aware either. doc-base simply registers documentation for use by other tools. It is up to those other tools whether and how to support i18n and l10n. Well, yes, but how can those other tools know that two documents are really the same in another language if that information is not stored in doc-base somehow? If you want automation, use i18n-aware tools as in Gnome (and I suspect in KDE too). Using gnome-help, yelp, scrollkeeper or something similar is the standard method but it requires upstream cooperation. I'm not installing a help viewing system, I'm just registering documentation with the Debian documentation repository. Currently, doc-base supports multiple versions of the same document in other formats (such as HTML, PDF) and I guess the front-ends would decide which version to show. I would like the same kind of behaviour for multiple translations of the same document, but it seems doc-base does not support that. I could register all translations as separate documents. With only English and French, that would not be too bad, but if a document would be available in 50 languages, the documentation index would be polluted severely. Cheers Jan-Pascal signature.asc Description: OpenPGP digital signature
Re: busybox
K. Richard Pixley wrote: Ok, sure. But that seems like a hack to me so that busybox can be installed on regular desktop systems which presumably want coreutils, (and friends), to be installed as the primary ls command. In this context, busybox is more of a toy, or an evaluation install than a useful tool. Most systems that have busybox installed use it to boot, since initramfs-tools puts it on the initramfs by default. That's not very toy-like. For busybox to be a useful tool, it would need to supplant coreutils, (and friends). And my question is to why this hasn't been done. Several reasons, including that it would break large quantities of software that expects to be able to use various command line options that are not present in the busybox utilities. http://kitenet.net/~joey/blog/entry/replacing_stuff_with_busybox.html -- see shy jo signature.asc Description: Digital signature
Re: daemon stop and start during upgrade
Patrick Schoenfeld wrote: Because exiting with zero or non-zero has absolutely nothing to do with behaving sensibly. Actually returning a non-zero exit code is the right thing to do, cause the action to stop a process _did_ fail, because the process has not been running. Not really. It also depends on how you see it: if I ask some process to stop, I don't care if it was running or not. All I care is that it does end up stopped. I see it like this: stop: pre-requisites: none post-conditions: the service is stopped, or an error is reported -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: daemonlogger
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package daemonlogger. * Package name: daemonlogger Version : 0.91-1 Upstream Author : Martin Roesch [EMAIL PROTECTED] * URL : http://www.snort.org/users/roesch/Site/Daemonlogger.html * License : GPL Section : net It builds these binary packages: daemonlogger - simple network packet logger and soft tap daemon Daemonlogger is a tool that is very useful to network security administrators and analysts. It is capable of mirroring traffic between interfaces, and also logging network traffic to file. It can chroot itself, and has numerous other useful features. The package appears to be lintian clean. The upload would fix these bugs: 439008 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/d/daemonlogger - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/d/daemonlogger/daemonlogger_0.91-1.dsc I would be glad if someone uploaded this package for me. Kind regards Chris Taylor -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG6YWQLpNUoan9SCERAm7pAJ9nnXpAxN7hbKRZ3hkmUBANhYOScgCfY9dn LdzimsDYNuSYbWo9CZTm2FQ= =pCKc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
Felipe Sateler schrieb: Not really. It also depends on how you see it: if I ask some process to Sure. Thats exactly what I'm saying. stop, I don't care if it was running or not. All I care is that it does end up stopped. I see it like this: Really? So maybe *you* don't care about the services state when you stop it. But *I* could expect it to be running, if I ask it to stop. Because something could be wrong, if the service is not running, I want to know if it isn't. OTOH its not me requesting the service to stop, but a process that can't know that I eventually stopped the service, because I wanted to do. Well doesn't matter, really. I agree to what you are saying. But the point is, that others could see that different. Thats were rules and policies come in handy. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Nevermind (Re: RFS: drscheme (updated package))
Seems the packages are totally broken. Don't even look at them. Will repost later. Francois-Denis Gonthier wrote: Dear mentors, This is an update to DrScheme which is already in Debian. It is basically the upstream update plus some rather conservative changes, especially around the web server. I would be happy if someone could check this package. There are a few lintian errors but none of them seemed really problematic to me. Feel free to prove me wrong. As I upload it, I notice there are some things I thought I fixed which I somehow creeped back into the package, so this is more like a RFC than a RFS --- The obligatory template It builds these binary packages: drscheme - PLT Scheme Programming Environment mzscheme - PLT Scheme Interpreter The upload would fix these bugs: 402589, 425539 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/drscheme - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/drscheme/drscheme_370-1.dsc I would be glad if someone uploaded this package for me. Kind regards François-Denis Gonthier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Opencity policy: violates 9.1 10.7 MUSTs
scripsit Cyril Brulebois: Cyril Brulebois [EMAIL PROTECTED] (12/09/2007): My questions about the exact content of the bug remains, because “FHS violations” isn't self-explanatory. For the sake of completeness, posting the following here, so as to demonstrate how many points of the Policy the opencity package violates. There are explanations actually. Let's see: | AUTHORS -- doesn't ship, must be in $(DOCDIR) Must? What about the copyright file? (1) sorry, that wasn't as clear as it should have been. It doesn't ship, and it's not clear why -- that's a minor bug, yes -- but if it _does_ ship it _must_ be in $(DOCDIR): # 9.1.1 File system Structure # # The location of all installed files and directories must comply with the # File system Hierarchy Standard (FHS), version 2.3, with the exceptions # noted below, and except where doing so would violate other terms of # Debian Policy. There are no relevant exceptions regarding the location of documentation files. [omitting OK stuff] | OpenCity.desktop -- double-installed in /usr/share/applications | (correct) and $(DATADIR) (redundant) Bug, OK. What violation is that? | OpenCity.png -- double-installed in /usr/share/pixmaps (correct) and | $(DATADIR) (redundant) Maybe a bug, OK. What violation is that? (2) Not a policy violation, a minor bug. | README, TODO -- don't ship, must be in $(DOCDIR) See Policy 12.3 again. What violation is that? (3) The README file is the primary documentation for the package. Not shipping it is at least Important `a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone' -- the package is not unusable to anyone who reads Italian (a small minority of users) or who goes and downloads the upstream package to get this file (not a reasonable expectation for an end user) if not Grave `makes the package unusable or mostly so'). If installed (see [1] above) it _must_ be in $(DOCDIR). | autopackage/ -- ships in $(DATADIR), no reason to ship at all Maybe a bug, OK. What violation is that? See (2). | config/* -- ship in $(DATADIR)/config; must be in $(CONFDIR) Not if it is not meant to be modified by the local admin. That configuration files, although in a directory called “config” can be static data. What violation is that, then? These files _are_ meant to be modified by the local admin; they are the program's configuration files. Putting them under /usr violates 9.1 (not following FHS, a `must') and 10.7 (not putting config files under /etc, also a `must'). A Serious bug means violating a `must' policy. | docs/* -- ship in $(DATADIR)/docs; must be in $(DOCDIR) Policy 12.3 againt, must != should. No, Policy 9.1, a `must'. FHS is very clear about where documentation files go. It is _also_ a violation of 12.3 `should', but the `must' obligation to follow FHS would make that largely irrelevant. How many policy violations remain? 9.1, 10.7, 12.3 To sum this up, ignoring the minor things that I mentioned only as a `by the way, this can be fixed too': A) The English-language documentation is not shipped. This is not a policy violation per se, as 12.3 says additional documentation MAY be installed. It is, however, an (at least) Important bug as it renders the program more-or-less unusable without going upstream to get the documentation. M. Brulebois's comment that if I can read FHS I should be able to go look upstream for docs is just insulting; while I'm (obviously) quite capable of fixing the bugs myself, that is irrelevant to whether the bugs exist. B) The Italian-language documentation and the (English) FAQ are shipped, but in an incorrect location. This violates 9.1 (MUST follow FHS, which says that documentation, if installed, MUST go at /usr/share/doc) and 12.3 (SHOULD put docs at /usr/share/doc). C) The configuration files are not installed under /etc. This violates 9.1 (MUST follow FHS, which says config in /etc) and 10.7 (MUST put configuration files in /etc). -- Thanasis Kinias Doctoral Candidate, Department of History, and Instructor, Professional Enhancement Programs Arizona State University, Tempe, Arizona, U.S.A. . Je ne viens d'aucun pays, d'aucune cité, d'aucune tribu. Je suis fils de la route, ma patrie est caravane, et ma vie la plus inattendue des traversées. -- Amin Maalouf, _Léon l'Africain_ signature.asc Description: Digital signature
Re: opencity NMU to mentors
scripsit Neil Williams: [...] No URL, no bug reports, no detail - how do you propose that it gets sponsored? There is no duplication involved in an NMU - but you must engage with the maintainer, explain your proposals, detail your patches and allow time for the maintainer to either do the upload themselves. From your request, I have no way to tell if you have done any of those essential things. (1) I was not addressing you, Neil. (2) I was not requesting sponsorship. I CC'd the mentors list because I was using the mentors server to make a package available to the Games Team, whose work I thought it might help. That's twice now, Neil, that you have replied in a very rude and aggressive to my posts to this list. I don't know if you are confusing me with someone else or if you just have very poor social skills in general, but since you seem to have an inability to respond politely and constructively I guess I'd just prefer you ignored my posts. Killfile me if I offend you so. I'm just trying to contribute to this project and I don't need to deal with your attitude problems. Regards, -- Thanasis Kinias Doctoral Candidate, Department of History, and Instructor, Professional Enhancement Programs Arizona State University, Tempe, Arizona, U.S.A. . Je ne viens d'aucun pays, d'aucune cité, d'aucune tribu. Je suis fils de la route, ma patrie est caravane, et ma vie la plus inattendue des traversées. -- Amin Maalouf, _Léon l'Africain_ signature.asc Description: Digital signature
Re: opencity NMU to mentors
scripsit Cyril Brulebois: [...] The Right Thing to do is to contact the maintainers first. And it is not like the Games Team were totally unresponsive, especially when it comes to handling copyright-related problems (see Miriam's — in particular but not only — incredible work bugging upstreams to clarify their license / consider relicensing). is to do a non-DD NMU and let the Games Team sponsor it if they want... it seemed silly to duplicate the work. What about letting the team some time to react and fix its package? [...] Hey Games Team, I'm sorry about the confusion here. Neil's perplexing hostility toward me seems unfortunately to have set the tone for discussion. Let me clarify a few things: 1) I'm not a DD so I can't _really_ do an NMU. I made an NMU package for my own personal use, fixing the problems I identified. I filed bugs, assigning severity as I understood was appropriate (and I stand by assigning Serious severity to violating policy MUSTs). The I uploaded my package to mentors.debian.net and sent e-mails mentioning that it was there, and that if they wanted to the Games Team could simply sponsor the upload -- or do whatever they wanted to with it. I specifically did _not_ request to have anyone else sponsor the upload; that would have been grossly inappropriate and I am displeased to think that anyone should have thought that was my objective. 2) I could have posted three separate patches to the three bugs I'd filed -- or I could just upload a package from which the maintainer could do a quick diff and see what's there. I thought making a ready-to-upload package available might ease the workload on the Games Team -- but only, of course, if the Team accepted it. Again, I'm sorry about the confusion. I'm just trying to be helpful :) -- Thanasis Kinias Doctoral Candidate, Department of History, and Instructor, Professional Enhancement Programs Arizona State University, Tempe, Arizona, U.S.A. . Je ne viens d'aucun pays, d'aucune cité, d'aucune tribu. Je suis fils de la route, ma patrie est caravane, et ma vie la plus inattendue des traversées. -- Amin Maalouf, _Léon l'Africain_ signature.asc Description: Digital signature
Re: opencity NMU to mentors
On Thu, 13 Sep 2007 13:19:09 -0700 Thanasis Kinias [EMAIL PROTECTED] wrote: is to do a non-DD NMU and let the Games Team sponsor it if they want... it seemed silly to duplicate the work. No URL, no bug reports, no detail - how do you propose that it gets sponsored? Sounds like a request for sponsorship to me - and one that was lacking the most basic information. There is no duplication involved in an NMU - but you must engage with the maintainer, explain your proposals, detail your patches and allow time for the maintainer to either do the upload themselves. From your request, I have no way to tell if you have done any of those essential things. (1) I was not addressing you, Neil. You were addressing this list and I am part of the list, so I replied. Seems straightforward enough. If your mail was for a subset of this list, maybe that should have been clearer in the original mail or sent direct? (2) I was not requesting sponsorship. See above. It looked like it to me. YMMV. I CC'd the mentors list because I was using the mentors server to make a package available to the Games Team, whose work I thought it might help. I was just pointing out that important information was missing. That's twice now, Neil, that you have replied in a very rude and aggressive to my posts to this list. ? Huh ? You misinterpret. I don't know if you are confusing me with someone else or if you just have very poor social skills in general, but since you seem to have an inability to respond politely and constructively I guess I'd just prefer you ignored my posts. Killfile me if I offend you so. I'm just trying to contribute to this project and I don't need to deal with your attitude problems. You appear confused. I have not done anything of the sort and if you have misread my requests due to who knows what reason, it is nothing to do with me. I don't killfile anyone. I'm not impolite although sometimes direct. If you see attitude problems where none exist, I can't do much about that except continue to contribute in a constructive and efficient manner as I have done for some time. Nothing I have said on this list or any other public list should be contorted into the meaning you appear to ascribe. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpstj53ae3yg.pgp Description: PGP signature
Re: opencity NMU to mentors
On Thu, 13 Sep 2007 13:43:35 -0700 Thanasis Kinias [EMAIL PROTECTED] wrote: scripsit Cyril Brulebois: [...] The Right Thing to do is to contact the maintainers first. And it is not like the Games Team were totally unresponsive, especially when it comes to handling copyright-related problems (see Miriam's — in particular but not only — incredible work bugging upstreams to clarify their license / consider relicensing). is to do a non-DD NMU and let the Games Team sponsor it if they want... it seemed silly to duplicate the work. What about letting the team some time to react and fix its package? [...] Hey Games Team, I'm sorry about the confusion here. Neil's perplexing hostility toward me seems unfortunately to have set the tone for discussion. Not at all. I have no hostility to you or anyone else on this list or any other public list to which I post. I can't help it if you see something that does not exist, except to put the record straight that you must be mistook. No wonder you are perplexed. 1) I'm not a DD so I can't _really_ do an NMU. (I guessed that much.) I made an NMU package for my own personal use, fixing the problems I identified. (Something I do myself - rough and ready packages that are nowhere near release, but the patches always go to the BTS.) The only reason to upload packages to mentors.debian.net is to request sponsoring - if your changes are just patches and not a request to take over or start maintenance of the package yourself then all I can say is that you made the wrong choice. I see no need to upload the package anywhere, the BTS is quite sufficient for patches, NMU's or any other change to a package where the maintainer of the package is not going to change. I filed bugs, assigning severity as I understood was appropriate (and I stand by assigning Serious severity to violating policy MUSTs). The I uploaded my package to mentors.debian.net and sent e-mails mentioning that it was there, and that if they wanted to the Games Team could simply sponsor the upload -- or do whatever they wanted to with it. Doesn't the Games Team have a team packaging mailing list? I specifically did _not_ request to have anyone else sponsor the upload; that would have been grossly inappropriate and I am displeased to think that anyone should have thought that was my objective. Now that's clearer - a lot clearer than the original request which was, IMHO, overly casual and omitted lots of relevant data. 2) I could have posted three separate patches to the three bugs I'd filed -- or I could just upload a package from which the maintainer could do a quick diff and see what's there. I thought making a ready-to-upload package available might ease the workload on the Games Team -- but only, of course, if the Team accepted it. Generally, patches to the BTS are the established way and for good reason. Getting patches back out of a .diff.gz is not nice, it isn't regarded as being helpful; it is regarded as being obtuse, awkward or just plain mistaken. Just think that not everyone prepares or handles patches as you do in the package so prising each patch out of the whole .diff.gz is usually a complete waste of time. There is a reason why Policy specifies that patches are uploaded to the BTS and that they reside there for some time period before an upload. Again, I'm sorry about the confusion. I'm just trying to be helpful :) I'd suggest sticking to multiple patches to multiple bugs next time. Saves a lot of hassle. Honest. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpYu78CKCakl.pgp Description: PGP signature
RFS: php-text-password
Dear mentors, I am looking for a sponsor for my package php-text-password. * Package name: php-text-password Version : 1.1.0-1 Upstream Author : [Martin Jansen, Olivier Vanhoucke] * URL : [http://pear.php.net/package/Text_Password] * License : [PHP License] Section : web It builds these binary packages: php-text-password - Creating passwords with PHP The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/php-text-password - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/php-text-password/php-text-password_1.1.0-1.dsc I would be glad if someone uploaded this package for me. -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 The most beautiful experience we can have is the mysterious. -- Albert Einstein, The World As I See it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: php-i18nv2
Dear mentors, I am looking for a sponsor for my package php-i18nv2. * Package name: php-i18nv2 Version : 0.11.4-1 Upstream Author : [Michael Wallner, Helgo Thormar, Lorenzo Alberton] * URL : [http://pear.php.net/package/I18Nv2] * License : [PHP License] Section : web It builds these binary packages: php-i18nv2 - Internationalization for PHP The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/php-i18nv2 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/php-i18nv2/php-i18nv2_0.11.4-1.dsc I would be glad if someone uploaded this package for me. -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 The most beautiful experience we can have is the mysterious. -- Albert Einstein, The World As I See it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: php-mdb3
Dear mentors, I am looking for a sponsor for my package php-mdb2. * Package name: php-mdb2 Version : 2.4.1-1 Upstream Author : [Lukas Kahwe Smith, Lorenzo Alberton] * URL : [http://pear.php.net/package/MDB2] * License : [BSD] Section : web It builds these binary packages: php-mdb2 - database abstraction layer The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/php-mdb2 - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/p/php-mdb2/php-mdb2_2.4.1-1.dsc I would be glad if someone uploaded this package for me. -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 The most beautiful experience we can have is the mysterious. -- Albert Einstein, The World As I See it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: opencity NMU to mentors
scripsit Neil Williams: On Thu, 13 Sep 2007 13:19:09 -0700 Thanasis Kinias [EMAIL PROTECTED] wrote: is to do a non-DD NMU and let the Games Team sponsor it if they want... it seemed silly to duplicate the work. No URL, no bug reports, no detail - how do you propose that it gets sponsored? Sounds like a request for sponsorship to me - and one that was lacking the most basic information. Well, I expect if I were requesting sponsorship I would have entitled the e-mail `RFS: ...' and set the seeking-sponsors flag on the mentors upload to `yes'. And I would not have specified that it was the package maintainer I was addressing. (1) I was not addressing you, Neil. You were addressing this list and I am part of the list, so I replied. Seems straightforward enough. If your mail was for a subset of this list, maybe that should have been clearer in the original mail or sent direct? I see now I transposed the `To:' and the `CC:' headers in my original post: I was e-mailing the maintainer and CCing this list out of courtesy since I was using the mentors server to hold the files. I can see how it might have been confusing since I in fact did set `To:' to this list and `CC:' to the maintainer. (2) I was not requesting sponsorship. See above. It looked like it to me. YMMV. Indeed, YMMV. That's twice now, Neil, that you have replied in a very rude and aggressive to my posts to this list. ? Huh ? You misinterpret. I don't know if you are confusing me with someone else or if you just have very poor social skills in general, but since you seem to have an inability to respond politely and constructively I guess I'd just prefer you ignored my posts. Killfile me if I offend you so. I'm just trying to contribute to this project and I don't need to deal with your attitude problems. You appear confused. I have not done anything of the sort and if you have misread my requests due to who knows what reason, it is nothing to do with me. I don't killfile anyone. I'm not impolite although sometimes direct. If you see attitude problems where none exist, I can't do much about that except continue to contribute in a constructive and efficient manner as I have done for some time. Nothing I have said on this list or any other public list should be contorted into the meaning you appear to ascribe. Directness is a popular excuse for rudeness. You go beyond that, however. I direct you to reread your response to my RFS for cinepaint, where you not only were hostile, accused me of lying by omission, and abused me for using a template on the mentors Web site. You wrote: ] This just isn't good enough - not by a long way. Packages are not ] removed from unstable without due cause so be OPEN about the cause - ] this is open source, this is Debian - we don't hide problems. You could, of course, simply have looked at the bug the upload closed, which would have explained in detail what was going on. But you didn't do that; you made a very clear implication that I was hiding the reason the package was removed and trying to sneak something (harmful?) back into Debian. You could have very tersely said something like `You need to give us a full report of bugs and reason for the package's removal' in your response, which would have been direct and not unnecessarily padded with _politesse_. Instead you chose to characterize my request as `woeful', accusing me of treating mentors as `a dumping ground for bad packages', and informed me that I was `going to have to do a LOT more to make up for such a bad start', since I was `starting from a deeply negative position', and that my `responses had better be very good'. Finally, you were kind enough to sign off by saying you were `not going to do [my] work for [me] on this one'. I suppose that might not strike you as hostile or abusive. As you said, YMMV. But I don't think it takes much for this to be `contorted into the meaning [I] appear to ascribe' (your words), i.e. a `rude and aggressive' reply (my words). Incidentally, when I pointed out where you were mistaken about the presence of RC bugs in the package, you simply failed to respond. That's fine; I prefer that to further abuse. -- Thanasis Kinias Doctoral Candidate, Department of History, and Instructor, Professional Enhancement Programs Arizona State University, Tempe, Arizona, U.S.A. . Je ne viens d'aucun pays, d'aucune cité, d'aucune tribu. Je suis fils de la route, ma patrie est caravane, et ma vie la plus inattendue des traversées. -- Amin Maalouf, _Léon l'Africain_ signature.asc Description: Digital signature
RFS: php-mdb2-driver-mysql
Dear mentors, I am looking for a sponsor for my package php-mdb2-driver-mysql. * Package name: php-mdb2-driver-mysql Version : 1.4.1-1 Upstream Author : [Lukas Kahwe Smith, Lorenzo Alberton] * URL : [http://pear.php.net/package/Text_Password] * License : [PHP License] Section : web It builds these binary packages: php-mdb2-driver-mysql - mysql MDB2 driver The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/php-mdb2-driver-mysql - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/p/php-mdb2-driver-mysql/php-mdb2-driver-mysql_1.4.1-1.dsc I would be glad if someone uploaded this package for me. -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 The most beautiful experience we can have is the mysterious. -- Albert Einstein, The World As I See it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: php-mdb3
On Thu, 13 Sep 2007 17:52:12 -0400 [EMAIL PROTECTED] (Mark A. Hershberger) wrote: Dear mentors, I am looking for a sponsor for my package php-mdb2. Subject says php-mdb3 ? * Package name: php-mdb2 ? It builds these binary packages: php-mdb2 - database abstraction layer Please add the long description - PHP does have database abstraction layers already - what does this one offer? Which databases? (probably need to add ... for foo database to the short description too.) The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/php-mdb2 - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/p/php-mdb2/php-mdb2_2.4.1-1.dsc Back to php-mdb2 - which is it? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp9H6nXxyui1.pgp Description: PGP signature
Re: opencity NMU to mentors
scripsit Neil Williams: (Something I do myself - rough and ready packages that are nowhere near release, but the patches always go to the BTS.) The only reason to upload packages to mentors.debian.net is to request sponsoring - if your changes are just patches and not a request to take over or start maintenance of the package yourself then all I can say is that you made the wrong choice. I see no need to upload the package anywhere, the BTS is quite sufficient for patches, NMU's or any other change to a package where the maintainer of the package is not going to change. I stand corrected. I will avoid such use in future. Doesn't the Games Team have a team packaging mailing list? Yes. I mailed their devel list as well as mentors in the post to which you just replied, but you cut them out of your response for some reason. [snip] Generally, patches to the BTS are the established way and for good reason. Getting patches back out of a .diff.gz is not nice, it isn't regarded as being helpful; it is regarded as being obtuse, awkward or just plain mistaken. Just think that not everyone prepares or handles patches as you do in the package so prising each patch out of the whole .diff.gz is usually a complete waste of time. There is a reason why Policy specifies that patches are uploaded to the BTS and that they reside there for some time period before an upload. Again, I'm sorry about the confusion. I'm just trying to be helpful :) I'd suggest sticking to multiple patches to multiple bugs next time. Saves a lot of hassle. Honest. Understood. Thanks for the constructive response; this is very helpful. -- Thanasis Kinias Doctoral Candidate, Department of History, and Instructor, Professional Enhancement Programs Arizona State University, Tempe, Arizona, U.S.A. . Je ne viens d'aucun pays, d'aucune cité, d'aucune tribu. Je suis fils de la route, ma patrie est caravane, et ma vie la plus inattendue des traversées. -- Amin Maalouf, _Léon l'Africain_ signature.asc Description: Digital signature
Re: RFS: php-mdb3
On Thu, 13 Sep 2007 17:52:12 -0400 [EMAIL PROTECTED] (Mark A. Hershberger) wrote: * Package name: php-mdb2 Version : 2.4.1-1 Upstream Author : [Lukas Kahwe Smith, Lorenzo Alberton] * URL : [http://pear.php.net/package/MDB2] * License : [BSD] Section : web Nearly forgot too: Is this an existing package? If it is not, where is the ITP ? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp03T5lP3ixD.pgp Description: PGP signature
Re: RFS: php-text-password
On Thu, 13 Sep 2007 17:43:15 -0400 [EMAIL PROTECTED] (Mark A. Hershberger) wrote: Dear mentors, I am looking for a sponsor for my package php-text-password. Appears to be a new package, no ITP number - have you filed one? (Hint: you *must* have an ITP bug number for a new package. No ifs, no buts, *no* exceptions. Make sure you have ITP's for any of the other requests you made tonight that need them whilst you are filing this one.) PHP packages can be very trivial and yet very troublesome for security. Please provide evidence of what has been done to make password handling secure in this package. (I'm not offering to sponsor, I'm just highlighting the omissions in your request.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpE4VQIk8l0a.pgp Description: PGP signature
Re: RFS: php-mdb2-driver-mysql
On Thu, 13 Sep 2007 17:55:30 -0400 [EMAIL PROTECTED] (Mark A. Hershberger) wrote: Dear mentors, I am looking for a sponsor for my package php-mdb2-driver-mysql. * Package name: php-mdb2-driver-mysql Version : 1.4.1-1 Upstream Author : [Lukas Kahwe Smith, Lorenzo Alberton] * URL : [http://pear.php.net/package/Text_Password] Wrong URL. No ITP. Are you planning on submitting one driver for every supported database? File the ITP bugs and fix the submissions you have made so far before you do any more. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpkqaKTyxoY2.pgp Description: PGP signature
Re: opencity NMU to mentors
On Thu, 13 Sep 2007 15:09:55 -0700 Thanasis Kinias [EMAIL PROTECTED] wrote: Sounds like a request for sponsorship to me - and one that was lacking the most basic information. Well, I expect if I were requesting sponsorship I would have entitled the e-mail `RFS: ...' Not always. and set the seeking-sponsors flag on the mentors upload to `yes'. That setting doesn't get as far as the mailing list. I don't go hunting around on mentors.debian.net until *after* the package has peaked my interest and I have sufficient information in the RFS to make a sensible decision about sponsoring the package. I see now I transposed the `To:' and the `CC:' headers in my original post: I was e-mailing the maintainer and CCing this list out of courtesy since I was using the mentors server to hold the files. I can see how it might have been confusing since I in fact did set `To:' to this list and `CC:' to the maintainer. OK. Directness is a popular excuse for rudeness. You go beyond that, however. Me thinks a 'IMHO' is missing in that sentence. You wrote: ] This just isn't good enough - not by a long way. Packages are not ] removed from unstable without due cause so be OPEN about the cause - ] this is open source, this is Debian - we don't hide problems. It wasn't good enough. The onus is on the person requesting sponsorship to provide the information for the sponsor. The sponsor is not there to be a gopher. The bare RFS template is inadequate 95% of the time - it is not a fault of the template, it is a problem with the maintainer not filling in the gaps with sufficient detail. This applies to most RFS emails, it's not specific to any one maintainer. Incidentally, when I pointed out where you were mistaken about the presence of RC bugs in the package, you simply failed to respond. Would that just possibly be because I tend to be very busy with things elsewhere in Debian? A request for sponsorship needs to invite the sponsor to engage with the maintainer, to be appealing and provide all the information necessary - it is an advertisement, a request, an invitation - not a command, instruction, direction or stipulation. Please take on board that there are other things sponsors are doing and that your requests need to HELP the sponsor, not burden them. You are the one making the requests - you do the work and you must put the information in the RFS email that the sponsor will need. The template is just a guide, it is meant to be embellished. Be verbose, explain things, remember that there are 19,000 packages in Debian and the sponsor has probably never heard of your pet project so explain what it does and what you have done, clearly and fully. No template can cover all the data required for an RFS so *think* and make any request enticing and attractive - not burdensome, tedious or incomplete. I offer sponsorship during what little of my free time is still available to Debian *after* I have done all my priority tasks relating to my own packages. It would be good to hear that such efforts are appreciated and that those requesting sponsorship accept that getting a package sponsored is a partnership, not a right. Those that I have sponsored know me and I know that they appreciate my help. I am not against you, I am not out to persecute you - I would like to be able to help but I need the information and a decent explanation of what you have done with a particular package. Don't perpetuate this sub-thread. Whatever you think I meant is not what I intended but I did consider your cinepaint request to be inadequate and your reactions since then have done nothing to change that. Accept the criticism for what it was and move on. Then apply what you have learnt and what I have proposed, in your next RFS. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpGJcSJJ976r.pgp Description: PGP signature
Re: opencity NMU to mentors
I would beg everyone in the thread to keep calm. There seems to have been a miscomunication among all of us, so lets let it that way and forget about it, please. It won't do any good for anyone to keep discissing this. To be honest, when I read the first mail I thought How can this be? They're doing us an NMU for some bugs that are not extremelly urgent, they haven't even notified us about it, and they haven't sent eny patches to the BTS?. I guess that's why everyone in the mailing list was so shocked, because we (me, at least) didn't understand what was happening. In fact the letters NMU have a very clear and concise meaning, that's an upload to Debian's repositories, from a person that's not the maintainer, to solve a problem in the minimal disruptive form. The usage of the word NMU for a different thing, as in this case, seems to have confused us all. For the future, I'd prefer that whoever wants to help the Games Team send patches to the BTS. It's much easier for everyone. We're handling all the packages in a subversion server, and it's not as simple as to get the package and upload it as it is, we have to commit the changes there too. Furthermore, there might be changes already there that might not be uploaded yet, so those should also be added to the package to be uploaded. To sum up, it's quite a big amount of work for us to extract the patches from the already made packege. Now that all the situation has been clarified, lets all continue with our work :) Greetings, Miry 2007/9/13, Thanasis Kinias [EMAIL PROTECTED]: scripsit Cyril Brulebois: [...] The Right Thing to do is to contact the maintainers first. And it is not like the Games Team were totally unresponsive, especially when it comes to handling copyright-related problems (see Miriam's — in particular but not only — incredible work bugging upstreams to clarify their license / consider relicensing). is to do a non-DD NMU and let the Games Team sponsor it if they want... it seemed silly to duplicate the work. What about letting the team some time to react and fix its package? [...] Hey Games Team, I'm sorry about the confusion here. Neil's perplexing hostility toward me seems unfortunately to have set the tone for discussion. Let me clarify a few things: 1) I'm not a DD so I can't _really_ do an NMU. I made an NMU package for my own personal use, fixing the problems I identified. I filed bugs, assigning severity as I understood was appropriate (and I stand by assigning Serious severity to violating policy MUSTs). The I uploaded my package to mentors.debian.net and sent e-mails mentioning that it was there, and that if they wanted to the Games Team could simply sponsor the upload -- or do whatever they wanted to with it. I specifically did _not_ request to have anyone else sponsor the upload; that would have been grossly inappropriate and I am displeased to think that anyone should have thought that was my objective. 2) I could have posted three separate patches to the three bugs I'd filed -- or I could just upload a package from which the maintainer could do a quick diff and see what's there. I thought making a ready-to-upload package available might ease the workload on the Games Team -- but only, of course, if the Team accepted it. Again, I'm sorry about the confusion. I'm just trying to be helpful :) -- Thanasis Kinias Doctoral Candidate, Department of History, and Instructor, Professional Enhancement Programs Arizona State University, Tempe, Arizona, U.S.A. . Je ne viens d'aucun pays, d'aucune cité, d'aucune tribu. Je suis fils de la route, ma patrie est caravane, et ma vie la plus inattendue des traversées. -- Amin Maalouf, _Léon l'Africain_ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG6aD3Pw5095PItGURAtq5AKCHyfqfTLppKzUkGQw8YttM+a+/AwCg3F3m 38UFLcDiXM0h+cFoAHcA7ak= =2Bid -END PGP SIGNATURE-
RFS: php-gettext (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.0.7-3 of my package php-gettext. It builds these binary packages: php-gettext - read gettext MO files directly, without requiring anything other The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/php-gettext - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/php-gettext/php-gettext_1.0.7-3.dsc I would be glad if someone uploaded this package for me. Kind regards Marcelo Jorge Vieira -- Marcelo Jorge Vieira (metal) poesias/rascunhos - http://metal.alucinados.com fotos - http://flickr.com/photos/marcelometal/ blog tecnico - http://metaldot.alucinados.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How can we get people to write better RFSes?
scripsit Neil Williams: The bare RFS template is inadequate 95% of the time - it is not a fault of the template, it is a problem with the maintainer not filling in the gaps with sufficient detail. This applies to most RFS emails, it's not specific to any one maintainer. _This_ is a subject worth discussing. How can we, perhaps, improve the template or the documentation on mentors.d.n so that we can improve the `hit rate', as it were. I would suggest (and the number of RFSes which you find inadequate seems to support this idea) that the instructions on the Web site do not go far enough in explaining what is needed. A first-time user could very well assume, I believe, that what is expected is to fill the blanks in the RFS template and the rest is self-explanatory. For example, _I_ assumed that since the page on the upload clearly showed `Closes: #xx', I didn't need to mention that in the RFS. If convention is that one _should_ do so, we would save everyone a lot of time if the template included that. If packages formerly but not currently in unstable are a special case (and I think they are), then having some guidelines on how to handle them would be very helpful. Rather than getting frustrated about expectations not being met, why don't we talk about how we can communicate those expectations more clearly so nobody gets to be disappointed, aggravated, irritated, or generally misanthropic. I did not see your personal guidelines for sponsorship until well after our initial encounter, as it is not very prominent on the site. Since you read so many RFSes, Neil, could you give us a list of, say, your top-ten pet peeves about things would-be sponsees screw up? (Without naming names, in the interest of keeping temperatures under flashpoint *grin*). Then we could talk about what we can do to encourage future RFS submitters _not_ to make the same mistakes. -- Thanasis Kinias Doctoral Candidate, Department of History, and Instructor, Professional Enhancement Programs Arizona State University, Tempe, Arizona, U.S.A. . Je ne viens d'aucun pays, d'aucune cité, d'aucune tribu. Je suis fils de la route, ma patrie est caravane, et ma vie la plus inattendue des traversées. -- Amin Maalouf, _Léon l'Africain_ signature.asc Description: Digital signature
RFS: libphp-jabber (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.4.3-2 of my package libphp-jabber. It builds these binary packages: libphp-jabber - Object-oriented PHP interface for the Jabber/XMPP protocol The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libphp-jabber - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libphp-jabber/libphp-jabber_0.4.3-2.dsc I would be glad if someone uploaded this package for me. Kind regards Marcelo Jorge Vieira -- Marcelo Jorge Vieira (metal) poesias/rascunhos - http://metal.alucinados.com fotos - http://flickr.com/photos/marcelometal/ blog técnico - http://metaldot.alucinados.com
Re: opencity NMU to mentors
scripsit Miriam Ruiz: I would beg everyone in the thread to keep calm. There seems to have been a miscomunication among all of us, so lets let it that way and forget about it, please. I like that idea very much. We have better things to do. [snip] To be honest, when I read the first mail I thought How can this be? They're doing us an NMU for some bugs that are not extremelly urgent, they haven't even notified us about it, and they haven't sent eny patches to the BTS?. I guess that's why everyone in the mailing list was so shocked, because we (me, at least) didn't understand what was happening. In fact the letters NMU have a very clear and concise meaning, that's an upload to Debian's repositories, from a person that's not the maintainer, to solve a problem in the minimal disruptive form. The usage of the word NMU for a different thing, as in this case, seems to have confused us all. I understand that. I should not have used NMU in the title; I honestly really wasn't thinking about the emotional impact of the term. (Funny how three little letters, completely meaningless to all but a few thousand human beings, can inspire such a strong emotional reaction! There's got to be a paper in there somewhere...) I need to avoid using 'x.y' debian version numbers when I make my own builds, because things like dch and debuild then throw `NMU' around a lot... For the future, I'd prefer that whoever wants to help the Games Team send patches to the BTS. [snip] Understood. Now that all the situation has been clarified, lets all continue with our work :) Having continued with my work, I've submitted a patch to bug #442029 containing all the changes between my quasi-pseudo-misnamed `NMU' and the current -2 version, except for those related to #442034 and #442056 (which bugs Cyril tagged as fixed in SVN). I hope that is more useful than my previous effort :) -- Thanasis Kinias Doctoral Candidate, Department of History, and Instructor, Professional Enhancement Programs Arizona State University, Tempe, Arizona, U.S.A. . Je ne viens d'aucun pays, d'aucune cité, d'aucune tribu. Je suis fils de la route, ma patrie est caravane, et ma vie la plus inattendue des traversées. -- Amin Maalouf, _Léon l'Africain_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
On 13/09/2007, Patrick Schoenfeld [EMAIL PROTECTED] wrote: Felipe Sateler schrieb: Not really. It also depends on how you see it: if I ask some process to Sure. Thats exactly what I'm saying. stop, I don't care if it was running or not. All I care is that it does end up stopped. I see it like this: Really? So maybe *you* don't care about the services state when you stop it. But *I* could expect it to be running, if I ask it to stop. Because something could be wrong, if the service is not running, I want to know if it isn't. OTOH its not me requesting the service to stop, but a process that can't know that I eventually stopped the service, because I wanted to do. What about adding a 'status' target to the init.d script? I think that's the way to make sure the exit status is zero nomatter the daemon is running or not (it should only return a non-zero status if it failed to check whether the daemon is running or not). And about how to tell the postinst script whether the daemon was stopped by the prerm script I think the easiest and safest way to do it is by storing the information with debconf. Well doesn't matter, really. I agree to what you are saying. But the point is, that others could see that different. Thats were rules and policies come in handy. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Just my two cents, hope it helps. Sincerely, -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: php-i18nv2
On 13/09/2007, Mark A. Hershberger [EMAIL PROTECTED] wrote: Dear mentors, I am looking for a sponsor for my package php-i18nv2. * Package name: php-i18nv2 Version : 0.11.4-1 Upstream Author : [Michael Wallner, Helgo Thormar, Lorenzo Alberton] * URL : [http://pear.php.net/package/I18Nv2] * License : [PHP License] I think you should talk to upstream and get them to use some other license like LGPL or BSD. The ftp-master's take a particularly hard line on this license and it may require justifying later on if they decide to get picky. I've already got one package rejected because of that license. Section : web It builds these binary packages: php-i18nv2 - Internationalization for PHP The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/php-i18nv2 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/php-i18nv2/php-i18nv2_0.11.4-1.dsc I would be glad if someone uploaded this package for me. -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 The most beautiful experience we can have is the mysterious. -- Albert Einstein, The World As I See it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: php-text-password
On 13/09/2007, Mark A. Hershberger [EMAIL PROTECTED] wrote: Dear mentors, I am looking for a sponsor for my package php-text-password. * Package name: php-text-password Version : 1.1.0-1 Upstream Author : [Martin Jansen, Olivier Vanhoucke] * URL : [http://pear.php.net/package/Text_Password] * License : [PHP License] Quoting what I said on my other email: I think you should talk to upstream and get them to use some other license like LGPL or BSD. The ftp-master's take a particularly hard line on this license and it may require justifying later on if they decide to get picky. I've already got one package rejected because of that license. This also applies for the RFS for the php-mdb2-driver-mysql package. Section : web It builds these binary packages: php-text-password - Creating passwords with PHP The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/php-text-password - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/php-text-password/php-text-password_1.1.0-1.dsc I would be glad if someone uploaded this package for me. -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 The most beautiful experience we can have is the mysterious. -- Albert Einstein, The World As I See it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Atomo64 - Raphael Please avoid sending me Word, PowerPoint or Excel attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Say NO to Microsoft Office broken standard. See http://www.noooxml.org/petition -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: php-text-password
Neil Williams [EMAIL PROTECTED] writes: Appears to be a new package, no ITP number - have you filed one? (Hint: you *must* have an ITP bug number for a new package. No ifs, no buts, *no* exceptions. Make sure you have ITP's for any of the other requests you made tonight that need them whilst you are filing this one.) I'm not sure why you are missing the ITPs. The changelog entry for every one of these packages includes them and I posted the ITPs within the past three days. The ITP is also listed on the mentors.debian.net page for each of these packages as well as the Packages being worked on page. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441644 If you can tell me what would make it easier for you to find the ITPs, I'll be sure to do that for any future RFSs. Mark. -- http://hexmode.com/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 The most beautiful experience we can have is the mysterious. -- Albert Einstein, The World As I See it -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: php-text-password
scripsit Mark A. Hershberger: Neil Williams [EMAIL PROTECTED] writes: Appears to be a new package, no ITP number - have you filed one? (Hint: you *must* have an ITP bug number for a new package. No ifs, no buts, *no* exceptions. Make sure you have ITP's for any of the other requests you made tonight that need them whilst you are filing this one.) I'm not sure why you are missing the ITPs. The changelog entry for every one of these packages includes them and I posted the ITPs within the past three days. The ITP is also listed on the mentors.debian.net page for each of these packages as well as the Packages being worked on page. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441644 If you can tell me what would make it easier for you to find the ITPs, I'll be sure to do that for any future RFSs. Hola Mark, I made a post earlier this evening encouraging Neil to let us know what he views as the major `this pisses me off' errors people make in putting together RFSes, and it appears that this is one of them. Neil's belief AFAICT is that a would-be sponsor should not have to look at the package page on mentors.d.n -- which means that bugs you close must be specified explicitly in the RFS e-mail (including, then, obviously, the ITP). Neil, is that accurate statement, that your perspective is that a would-be sponsor should not be expected to look at the package page on mentors.d.n, and so any relevant information there should be repeated in the RFS? Would it be helpful if we recommended that for package updates the latest changelog entry be included as well? Mark, I'm hoping we can put together a list of things like this to put on the Web site so that we can have clearer guidelines for prospective sponsees to know what's expected... -- Thanasis Kinias Doctoral Candidate, Department of History, and Instructor, Professional Enhancement Programs Arizona State University, Tempe, Arizona, U.S.A. . Je ne viens d'aucun pays, d'aucune cité, d'aucune tribu. Je suis fils de la route, ma patrie est caravane, et ma vie la plus inattendue des traversées. -- Amin Maalouf, _Léon l'Africain_ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
