Copyright status and US-govt-created works (was: debian/copyright file)
Robin Cornelius <[EMAIL PROTECTED]> writes: > There are a couple of files that do NOT have copyright, these were > created by a US government contractor and therefor :- > > Copyright: It is the policy of NLM (U.S. National Library of Medicine) >(and U.S. government) to not assert copyright. For the question of copyright status, it is (currently) irrelevant under copyright legislation what the *policy* of the (potential) copyright holder might be. Copyright accrues to works, or not, regardless of what their policy is. So, this statement doesn't explain what the copyright status is. It's more accurate to say something like: Copyright: The NLM (U.S. National Library of Medicine), as a U.S. government organisation, by U.S. law does not hold copyright in works it creates. The wording likely needs to be scrutinised by someone more knowledgeable about the relevant legislation (or, preferably, copied from an existing statement that has held up under such scrutiny). Russ Allbery <[EMAIL PROTECTED]> writes: > Robin Cornelius <[EMAIL PROTECTED]> writes: > > Copyright: It is the policy of NLM (U.S. National Library of Medicine) > >(and U.S. government) to not assert copyright. > > License: other > [...] > > License here is actually public domain, although I see the wiki page > doesn't yet allow this, probably because people misuse it who don't > understand what public domain means. Agreed on both points. With the copyright status explained more clearly, this might be more understandable. -- \ "The WWW is exciting because Microsoft doesn't own it, and | `\ therefore, there's a tremendous amount of innovation | _o__) happening." -- Steve Jobs | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Thousand Parsec packages.
Barry deFreese <[EMAIL PROTECTED]> writes: > On of the big things I need to know about are the copyright files. > Upstream doesn't specify any years for Copyright that I can find. Copyright notices are only valid if they contain all three of: * The word "Copyright" and/or the copyright symbol "©" * The year(s) the copyright began in the work * The name of the legal entity that holds the copyright It's also highly preferable for the legal entity's contact information (these days, a valid email address specifically for that entity) to also be in the copyright notice. An example of a valid copyright notice: Copyright © 2008 Ben Finney <[EMAIL PROTECTED]> You'll need to contact the upstream copyright holder to get the information necessary. Ideally, they'll update the copyright notices in the source to make them all valid and correct, and release those changes to you; that way, you just copy the notices verbatim into the 'debian/copyright' file. -- \ "If the desire to kill and the opportunity to kill came always | `\ together, who would escape hanging?" -- Mark Twain, _Following | _o__) the Equator_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Missing descriptions on mentors.debian.net
Christoph Haas <[EMAIL PROTECTED]> writes: > Expect a shiny new mentors.debian.net during the summer based on > "debexpo". :) *The* summer? You mean I'll be getting it before the end of February 2008, while those in the northern hemisphere will have to wait longer? (Debian is international and worldwide. If any community should avoid the mistake of assuming a given season is experienced by the entire planet at the same time, it's us.) Also, and regardless of the above nitpick: thanks for the good news, can't wait to see the new site :-) -- \ "I like to fill my bathtub up with water, then turn the shower | `\on and pretend I'm in a submarine that's been hit." -- Steven | _o__) Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: Thousand Parsec packages.
Tristan Seligmann <[EMAIL PROTECTED]> writes: > * Ben Finney <[EMAIL PROTECTED]>: > > > Copyright notices are only valid if they contain all three of: > > > > * The word "Copyright" and/or the copyright symbol "©" > > * The year(s) the copyright began in the work > > * The name of the legal entity that holds the copyright > > Valid in what sense? Recognised legally. > Since copyright is automatic under the Berne Convention (so far as I > understand), the copyright holder would still retain their rights > even if no copyright notice existed This is true as far as it goes, but: > so is a strict formal copyright notice still required by anything? My understanding is that a copyright declaration on the work makes it easier to prove to a court that the recipient knows that the work *is* copyrighted to the specified entity, and that the copyright is current. In that sense, while the copyright holder retains that copyright irrespective of notices, the notices make life legally simpler for both the copyright holder *and* recipient, provided such notices are in a standard legally-recognised form. -- \ "Pinky, are you pondering what I'm pondering?" "I think so, | `\ Brain, but I find scratching just makes it worse." -- _Pinky | _o__) and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Copyright question (BSD with advertisement clause)
Russ Allbery <[EMAIL PROTECTED]> writes: > I don't think it's horribly credible that including software covered > by the 4-clause BSD license in Debian violates the principle of > least surprise when we specifically list it as one of our acceptable > licenses in the DFSG. The 4-clause BSD license is not one that we list as an acceptable license. DFSG http://www.debian.org/social_contract> §10: 10. Example Licenses The GPL, BSD, and Artistic licenses are examples of licenses that we consider free. That text isn't specific about *which* "BSD license" is an example of a free license. However, in that text, the term 'BSD' is an anchor to http://www.debian.org/misc/bsd.license>, which is a copy of the 3-clause BSD license, without advertising clause. That seems explicit that it's the version given as an example of a free license. It would perhaps be better for the DFSG to disambiguate "BSD license" in the text of the DFSG, but the hyperlink to the 3-clause BSD license without advertising clause serves the purpose in this instance. -- \ “It ain't so much the things we don't know that get us in | `\ trouble. It's the things we know that ain't so.” —Artemus | _o__) Ward (1834-67), U.S. journalist | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Long descriptions in RFS emails.
Neil Williams <[EMAIL PROTECTED]> writes: > Just a note for everyone - I will now ignore any RFS that does not > include the long description for the package. > > It doesn't matter how many times you "ping", without a long > description posted to *this* list, I will no longer waste time > either asking for one or reviewing your package and your RFS is > likely to be deleted without any further action. A good policy except that I'd recommend you respond to at least some of them to say *why* you think they're worth ignoring. Many people posting to this list cannot be expected to know your policy since they're here for the first time. I agree in the main with the majority of your sponsoring considerations, and I'd love for prospective maintainers to be educated on them as good practice. -- \ “Sittin’ on the fence, that’s a dangerous course / You | `\ can even catch a bullet from the peace-keeping force” —Dire | _o__) Straits, _Once Upon A Time In The West_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Long descriptions in RFS emails.
Neil Williams <[EMAIL PROTECTED]> writes: > On Mon, 2008-02-11 at 08:37 +1100, Ben Finney wrote: > > A good policy except that I'd recommend you respond to at least > > some of them to say *why* you think they're worth ignoring. > > Those who take some time over the preparation of packages and show > some level of effort in at least applying the principles of the FAQ > deserve my support and as I have limited time, I therefore choose to > prioritise my support to those who take the time to do the work. A reasonable position. Well, thanks for making your policies available for reference by others, and for keeping them up to date. -- \“We have to go forth and crush every world view that doesn't | `\believe in tolerance and free speech.” —David Brin | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Default admin password for a webapp
Xavier Luthi <[EMAIL PROTECTED]> writes: > I'm currently packaging pixelpost (ITP #470214) which is a photoblog > application written in php and using mysql. The installation process > requires to create an 'admin' account in the database with, of > course, a password. Apparently based on the assumption that the installation will in all cases be monitored by a person babysitting the installation process. > My question is: what do you think is the best solution to set this > password? Since the above assumption is not necessarily true on a Debian system, and (as you point out) a debconf query for the password might not be answered at install time, you should have the package installed such that it allows *no* access until the password is chosen by the administrator. > One solution, the easiest on the package development point of view, > is to set a default password documented in the README.Debian. Of > course, this is not beautiful and can be a security issue, > especially if the user doesn't change it immediately... I would modify "can be" to "is definitely" a security issue. Don't do that. Installing applications with default passwords is not a valid approach for a 21st century package. Instead, in the absence of explicitly choosing a password, the application should be installed such that it will deny authentication until such a password is explicitly chosen. -- \ "I got a postcard from my best friend, it was a satellite | `\ picture of the entire Earth. On the back he wrote, 'Wish you | _o__) were here'." -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Default admin password for a webapp
Xavier Luthi <[EMAIL PROTECTED]> writes: > The webapp won't allow any authentication becasue the password is > not set. How to ask for a password? Some way that the administrator can do so separately from installing the package. Ideally, the installation would use the same API to set the administrative password if available during the install. > With a warning message on the administrative page of the webapp > saying something like: 'Please run (as root) "dpkg-reconfigure > pixeplpost" to set the password of the administrative user.' > (priority is always 'low' for dpkg-reconfigure). That would do the job at hand, but is unfortunately Debian-specific. Better would be to work with the upstream to address this at the source, such that the solution becomes part of the upstream distribution. That's up to you to determine whether you have the resources to do so. -- \ “It is difficult to get a man to understand something when his | `\ salary depends upon his not understanding it.“ —Upton | _o__) Sinclair, 1935 | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Default admin password for a webapp
Please follow http://www.debian.org/MailingLists/#codeofconduct>; specifically, please don't send individual copies of messages you also send to the mailing list, since I haven't asked for them. Xavier Luthi <[EMAIL PROTECTED]> writes: > On Thu, Apr 10, 2008 at 08:58:51AM +1000, Ben Finney wrote: > > Xavier Luthi <[EMAIL PROTECTED]> writes: > > > > > The webapp won't allow any authentication becasue the password is > > > not set. How to ask for a password? > > > > Some way that the administrator can do so separately from > > installing the package. Ideally, the installation would use the > > same API to set the administrative password if available during > > the install. > > The installation procedure from the upstream source ask for the > administrative password the very first time anyone access the > application (this the "classical" way for a webapp). It may be the "classical" way, but nevertheless it's making an unwarranted assumption. > The assumption is the installation time is the same as the > configuration time, thus reducing to a minimum the time when the > application is "left open". The installation of a network-accessible application (or even one that *could* be made network-accessible) should never have the application "left open" for any period of time. In the absence of proper administrative credentials, the application should refuse all access until such credentials are set. > In the case of the webapp packaged for Debian, the installation time > is not always the same as the configuration time, so it is not an > option to use the upstream method to set the password: this would be > a big security hole. That's why the Debian package of a webapp often > needs to diverge from the upstream source in the way the application > is configured. Such divergence is to be avoided where possible. I suggest, if you're willing, you (as the Debian packager for this package) could work with the upstream developers to close this security hole consistently in the upstream *and* Debian packages. -- \ "...one of the main causes of the fall of the Roman Empire was | `\that, lacking zero, they had no way to indicate successful | _o__) termination of their C programs." -- Robert Firth | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Default admin password for a webapp
Ben Finney <[EMAIL PROTECTED]> writes: > Xavier Luthi <[EMAIL PROTECTED]> writes: > > > In the case of the webapp packaged for Debian, the installation > > time is not always the same as the configuration time, so it is > > not an option to use the upstream method to set the password: this > > would be a big security hole. That's why the Debian package of a > > webapp often needs to diverge from the upstream source in the way > > the application is configured. > > Such divergence is to be avoided where possible. [...] This (and the rest of the paragraph) is phrased poorly, with a corollary left unimplied. Better is: Such divergence, though sometimes necessary, should be resolved as soon as possible by working with the upstream developers to merge Debian's improvements into a future upstream release. -- \“Simplicity is prerequisite for reliability.” —Edsger W. | `\ Dijkstra | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposed new package, bugs-everywhere_0.0.193-1.1
Howdy all, I'm putting together a new Debian package, 'bugs-everywhere', in anticipation of having someone sponsor it into Debian. I'd like to get feedback on my packaging efforts before seeking a sponsor, as I'm still rather green at packaging Python applications. (I'm also seeking Alioth hosting for the project, but encountering technical difficulties unrelated to the package.) The source package can be had here: http://www.cyber.com.au/~benf/bzr/bugs-everywhere/build-area/bugs-everywhere_0.0.193-1.1.dsc> http://www.cyber.com.au/~benf/bzr/bugs-everywhere/build-area/bugs-everywhere_0.0.193.orig.tar.gz> http://www.cyber.com.au/~benf/bzr/bugs-everywhere/build-area/bugs-everywhere_0.0.193-1.1.diff.gz> Possibly also of interest: http://www.cyber.com.au/~benf/bzr/bugs-everywhere/build-area/bugs-everywhere_0.0.193-1.1_i386.changes> The package currently passes Lintian v1.23.46 with no errors, and only a warning about the package version number. I'd appreciate any feedback from those more experienced with Debian packaging in general and Python packaging in particular. -- \"When you go in for a job interview, I think a good thing to | `\ ask is if they ever press charges." -- Jack Handey | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Alioth complains about new project registration
Howdy all, I can't easily find administrative contact email address at the Alioth website http://alioth.debian.org/>, so I'm asking here in the hope of some overlap. When I try to register a new project using the "Project Information" form at https://alioth.debian.org/register/projectinfo.php>, the form returns with: ERROR: Could not create group: ERROR: value too long for type character varying(255) There's no indication of *which* value is "too long". But the "group", as far as I can tell, is the "Unix name" on the form. I've specified "bugs-everywhere", which is only 15 characters, certainly not "too long for type character varying(255)". How can I register this project at Alioth successfully with its correct name, "bugs-everywhere"? -- \ "Anger makes dull men witty, but it keeps them poor." -- | `\ Elizabeth Tudor | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new package, bugs-everywhere_0.0.193-1.1
Cyril Brulebois <[EMAIL PROTECTED]> writes: > - debhelper version mismatch: 5 is debian/compat, >= 6 in >debian/control. Fixed. > - strange to see there's only a © 2005 copyright line, IIRC the project >has been quite active lately. But still IIRC you're more versed into >legalese than I am, so you probably told them to update their >copyright notices. Hmm, and a quick grep shows that you're missing at >least: ./libbe/hg.py:# Copyright (C) 2007 Steve Borho <[EMAIL PROTECTED]> Good catch. I'll have to gather the copyright notices properly from the whole tree. > - debian/README.Debian looks like superfluous (and contains a different >address, for the sake of the argument). Removed. Thanks very much for the feedback! -- \ "I cannot conceive that anybody will require multiplications at | `\ the rate of 40,000 or even 4,000 per hour ..." -- F. H. Wales, | _o__) 1936 | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
VCS repository on Alioth projects with unrelated packages (was: Proposed new package, bugs-everywhere_0.0.193-1.1)
"Sandro Tosi" <[EMAIL PROTECTED]> writes: > If this is as python app (and you'd like to follow this path) It is implemented in Python, and I'm interested in the PAPT; thanks for the invite. > the repository it's already on Alioth, and it's called PAPT[1] ;) Unfortunately (as made clear in a conversation earlier this evening), the PAPT won't allow packages to use any VCS but their chosen repository, which is currently a Subversion back-end. Since my VCS preference, and that of my upstream, is Bazaar, this makes PAPT more of a burden than I was looking for. Alioth was attractive for this package largely *because* it provides hosted Bazaar repositories. Thanks again! -- \ "I have an answering machine in my car. It says, 'I'm home now. | `\ But leave a message and I'll call when I'm out.'" -- Steven | _o__) Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tkgate & povray
Ahmed El-Mahmoudy <[EMAIL PROTECTED]> writes: > Now povray is neither in Depends nor Build-Depends. The images in > povray/ directory are provided by the upstream orig tarball (ie. not > created by the building process). The reason to remove them from the tarball is that the work then doesn't include the corresponding source code (required by DFSG §2) under the same license terms (required by DFSG §3). Once the images can be re-built with software in 'main', the images can be re-included; but until then, they need to be removed if the work is to satisfy the DFSG. > Also there's another issue, the previous maintainer of tkgate > package did not put any copyrights for the packaging itself (please > look at debian/copyright). So I do not know what to do regarding > this matter. Is the previous maintainer responding to your attempts at contacting them? The simplest resolution is to get explicit written copyright notice and license from them, preferably under the same terms of the packaged work (i.e. GPL v2 or later). -- \ "For man, as for flower and beast and bird, the supreme triumph | `\is to be most vividly, most perfectly alive" -- D.H. Lawrence | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Check license and copyright of files in entire tree (was: Proposed new package, bugs-everywhere_0.0.193-1.1)
Emilio, and everyone: a reminder to please continue following http://www.debian.org/MailingLists#codeofconduct>. In particular, please don't send individual copies of messages also sent to the list, since I haven't asked for that. Emilio Pozuelo Monfort <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > > Good catch. I'll have to gather the copyright notices properly > > from the whole tree. > > Have a look at `licensecheck -R *` (in case you haven't yet), very > useful script for these purposes. Indeed, I wasn't aware of that. In this case, it's even more useful for me to run: $ licensecheck --recursive --copyright . Thanks for informing me about that tool. -- \ “The most common way people give up their power is by | `\ thinking they don’t have any.” —Alice Walker | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tkgate & povray
Ben Finney <[EMAIL PROTECTED]> writes: > Ahmed El-Mahmoudy <[EMAIL PROTECTED]> writes: > > > Now povray is neither in Depends nor Build-Depends. The images in > > povray/ directory are provided by the upstream orig tarball (ie. not > > created by the building process). > > The reason to remove them from the tarball is that the work then > doesn't include the corresponding source code (required by DFSG §2) > under the same license terms (required by DFSG §3). Unclearly phrased. Try this: The reason to remove the images from the 'povray/' directory is that you can't provide the corresponding source (because then the package isn't buildable with only software from 'main'), and DFSG §2 requires corresponding source for the package. So, the only way to satisfy these requirements simultaneously is to not include those images in the package (source or binary) at all, until the situation improves. -- \"Good judgement comes from experience. Experience comes from | `\ bad judgement." -- Frederick P. Brooks | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Test suites
Neil Williams <[EMAIL PROTECTED]> writes: > On Mon, 2008-04-21 at 10:14 -0700, Kevin B. McCarty wrote: > > Neil Williams wrote: > > >> 1) Always run the test suite (for example to catch bugs that may not > > >> occur on the developper's architecture) > > > > > > Yes. (That is the main point of having a test suite.) > > > > I agree with this (of course with the caveat that > > DEB_BUILD_OPTIONS=nocheck should disable the test suite). But I'll add > > a minor and maybe obvious exception -- one should disable or rework any > > parts of the test suite that would need any of the following: > > > > * An X server (e.g. for GUI tests) > > * A working network connection > > * Write access to the file system outside the build directory (with > > obvious exceptions like /tmp) > > * Interactivity > > IMHO test suites that require any of these external requirements are > simply not sane. Agreed, if we're talking specifically about a *unit test* suite, as opposed to the other kinds of tests that should also be in a test suite: functional tests, stress tests, etc. Unit tests should go to whatever lengths are necessary to test *only* the tiny portion of the code that is the subject of the specific test case, and use test doubles for any external dependencies as listed above. With that description of unit tests, it then makes sense to say that the build daemon should always run the unit test suite. Therefore it should also be easy to *only* run the unit tests, without any other tests. -- \ "Instead of a trap door, what about a trap window? The guy | `\ looks out it, and if he leans too far, he falls out. Wait. I | _o__) guess that's like a regular window." -- Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Check license and copyright of files in entire tree
Mike Hommey <[EMAIL PROTECTED]> writes: > On Mon, Apr 21, 2008 at 11:27:18PM +1000, Ben Finney wrote: > > $ licensecheck --recursive --copyright . > > Just don't forget that it will skip a lot of file types by default. Thanks. From the program source, the default regex for files to check is: my $default_check_regex = '\.(c(c|pp)?|h(h|pp)?|p(l|m)|sh|php|py|rb|java|el)$'; The '--check=foobarbazregex' option overrides this. -- \“Holy knit one purl two, Batman!” —Robin | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: bugs-everywhere
Howdy mentors, I have a package that is seeking a sponsor. Package name: bugs-everywhere Version:0.0.193-2~rc1 Upstream Author:Aaron Bentley <[EMAIL PROTECTED]> Chris Ball <[EMAIL PROTECTED]> URL:http://bugseverywhere.org/ License:GPL-2+ Section:devel It builds the binary package 'bugs-everywhere', which has the following description: Description: distributed bug tracker Bugs Everywhere is a “distributed bug tracker”, designed to complement distributed version control systems. By using a distributed VCS as a back-end for bug state, it gains several convenient features: . * Bugs and code that live on branches are tracked together. * Users can fully modify bug state while offline. * When a user checks out a project’s source code, she gets the current bug state for free. * A web interface to the bug database becomes just another client that merges with the main repository. The package passes 'lintian' with no warnings or errors. It is on mentors.debian.net: URL: http://mentors.debian.net/debian/pool/main/b/bugs-everywhere/ Repository: http://mentors.debian.net/debian/ unstable main Command: dget http://mentors.debian.net/debian/pool/main/b/bugs-everywhere/bugs-everywhere_0.0.193-2~rc1.dsc Looking forward to someone who can sponsor this package for me. -- \ Contentsofsignaturemaysettleduringshipping. | `\ | _o__) | Ben Finney <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Packaging without Makefile
"Dominik George" <[EMAIL PROTECTED]> writes: >- Ran dpkg -b in order to get a .deb package out of that Yes, that's all 'dpkg -b' does: it builds the *binary* package (the foo.deb). > But all I am left with is a .deb file - so nothing I could upload to > mentors.debian.net or such. You want 'dpkg-buildpackage'. Read its man page to see that you can use it to build either binary or source packages, and much more flexible besides. > All guides I could find explain how to either build a source package That's exactly what you should be uploading to mentors.debian.net. > or how to use dh_make - which needs a Makefile that compiles the > sources. Er? The upstream package doesn't need to have a Makefile at all, I don't know what gave you the impression that's a requirement. You merely need to construct the 'debian/rules' file (which is, itself, a makefile) with rules to do the right thing for the expected targets. If that's running "make build" for the upstream package, then do that; but if it's something else entirely, do that instead. -- \ “Leave nothing to chance. Overlook nothing. Combine | `\ contradictory observations. Allow yourself enough time.” | _o__) —Hippocrates | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: bugs-everywhere
Vincent Bernat <[EMAIL PROTECTED]> writes: > On Wed, 23 Apr 2008 23:41:30 +1000, Ben Finney <[EMAIL PROTECTED]> wrote: > > Howdy mentors, > > > > I have a package that is seeking a sponsor. > > > > Package name: bugs-everywhere > > Version:0.0.193-2~rc1 > > Upstream Author:Aaron Bentley <[EMAIL PROTECTED]> > > Chris Ball <[EMAIL PROTECTED]> > > URL:http://bugseverywhere.org/ > > License:GPL-2+ > > Section:devel > > Hi Ben! > > Did you get the mail from Alexander? Alexander who? When was it sent? > I agree with him: the diff.gz is difficult to read. Don't patch > headers for FSF address, That's a patch which has been sent upstream, and the upstream devel agrees it will be applied. I'm patching it in the Debian package as a direct result of other feedback that said it *should* be corrected in the Debian package. > don't ship this .be directory (I suppose you should adapt clean > target of your debian/rules). Oops, yes, you're right, that directory shouldn't be part of the package. Thanks for the feedback! -- \ “There is no reason anyone would want a computer in their | `\ home.” —Ken Olson, president, chairman and founder of | _o__)Digital Equipment Corp., 1977 | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
foo.diff.gz "difficult to read" (was: RFS: bugs-everywhere)
Vincent Bernat <[EMAIL PROTECTED]> writes: > Did you get the mail from Alexander? [from Alexander Schmehl, on a > different thread. > http://lists.debian.org/debian-mentors/2008/04/msg00330.html>] > I agree with him: the diff.gz is difficult to read. How is it difficult to read? I've opened it in Emacs and 'zless' and in either of them it reads like any other diff. Like any other unified diff, the changes are clearly marked by file, hunk location, and context lines. What readability problems are you seeing? What improvements would you want to see in the diff? As for a "patch management system", I find packages that use them *more* difficult to understand as an outsider than those that use the standard foo.diff.gz. I've read much discussion for and against, and I'm currently convinced that such systems are detrimental, on balance, for those wanting to work with the package. So, no thanks, I'll decline on that suggestion and continue to ship a standard foo.diff.gz. Feedback still appreciated, and I'll be incorporating other suggestions soon. -- \“There are only two ways to live your life. One is as though | `\ nothing is a miracle. The other is as if everything is.” | _o__) —Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A question about adopting a package
Amaya <[EMAIL PROTECTED]> writes: > Luis Rodrigo Gallardo Cruz wrote: > > You don't actually need the 'quit', but it hurts noone. > > There actuatually seems to be a trend to use 'kthxbye' nowadays, which > is not documented, but seems to work, and a lot cooler and lolcatter I find these last two to be mutually exclusive. -- \"Laurie got offended that I used the word 'puke.' But to me, | `\ that's what her dinner tasted like." -- Jack Handey | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Keep directory in working tree, but exclude from foo.diff.gz
Howdy mentors, I have a working tree for a package that's under version control; the working tree is specific to the Debian packaging for the software. That working tree contains a (version-controlled) directory that must remain in the working tree, and remain under version control, but should *not* become part of the Debian foo.diff.gz against the upstream source. The directory contains developer-only data that is not part of the Debian package, but *is* part of the data that should be under VCS in that working tree. So, in this case, it's not appropriate to have the directory removed by the 'debian/rules clean' action; the files need to remain in the working tree. What would be the best way to keep such a directory in place, but exclude the directory from the Debian source and binary packages? -- \ "If you can do no good, at least do no harm." -- _Slapstick_, | `\ Kurt Vonnegut | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Felipe Sateler <[EMAIL PROTECTED]> writes:
> Ben Finney wrote:
>
> > What would be the best way to keep such a directory in place, but
> > exclude the directory from the Debian source and binary packages?
>
> dpkg-source -i"regexp"?
Thanks. That looks like the right functionality, indeed.
However:
=
$ man dpkg-source
[...]
-i[regexp]
You may specify a perl regular expression to match files
you want filtered out of the list of files for the diff.
[...] There can only be one active regexp, of multiple
-i options only the last one will take effect.
[...]
$ dpkg-source --help
[...]
-i[] filter out files to ignore diffs of
(defaults to:
'(?:^|/).*~$|(?:^|/)\.#.*$|(?:^|/)\..*\.swp$|(?:^|/),,.*(?:$|/.*$)|(?:^|/)(?:DEADJOE|\.cvsignore|\.arch-inventory|\.bzrignore|\.gitignore)$|(?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn|\.hg|_darcs|\.git|\.shelf|_MTN|\.bzr(?:\.backup|tags)?)(?:$|/.*$)').
[...]
=
Yikes. So, in order to filter out an additional pattern, I can't just
say "ignore this pattern as well as the defaults". I have to construct
a *single* regexp that contains the default pattern *plus* mine, and
forever diverge from any future changes to the default regexp.
Am I reading it wrong, or is this dpkg-source option really that
awful?
--
\ "First they came for the verbs, and I said nothing, for verbing |
`\weirds language. Then, they arrival for the nouns and I speech |
_o__) nothing, for I no verbs." -- Peter Ellis |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: foo.diff.gz "difficult to read"
Vincent Bernat <[EMAIL PROTECTED]> writes: > Ben Finney <[EMAIL PROTECTED]> disait: > > > How is [the Debian source diff] difficult to read? I've opened it > > in Emacs and 'zless' and in either of them it reads like any other > > diff. > > When I look at a diff.gz, I use "zgrep '^+++ ' foo.diff.gz". If the > files listed here are only concerning debian/ directory, that's > fine, I just have to look at files in debian/directory. Otherwise, I > have to look at the diff more closely: Okay. From what I can tell, your issues apply to *any* diff that modifies the upstream source, and this one is not particularly difficult to read. Thanks for the clarification. -- \"Somebody told me how frightening it was how much topsoil we | `\ are losing each year, but I told that story around the campfire | _o__) and nobody got scared." -- Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Hubert Chathi <[EMAIL PROTECTED]> writes: > Ben Finney <[EMAIL PROTECTED]> said: > > > Yikes. So, in order to filter out an additional pattern, I can't > > just say "ignore this pattern as well as the defaults". I have to > > construct a *single* regexp that contains the default pattern > > *plus* mine, and forever diverge from any future changes to the > > default regexp. > > Yes. However, the "defaults to:" only applies to if you add the "-i" > option with no regexp given. i.e. if you weren't using "-i" already, > then dpkg-source wasn't ignoring anything in the first place. Okay, thanks. That does help, even if I'm still amazed at the poor design of that option. -- \ "If you're a young Mafia gangster out on your first date, I bet | `\it's real embarrassing if someone tries to kill you." -- Jack | _o__) Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Felipe Sateler <[EMAIL PROTECTED]> writes:
> BTW, why are there files useful to you but not other developers?
They're useful to someone who will be using the VCS to track changes,
because they contain bug information that is useful only in the
context of that VCS data.
They aren't useful to someone trying to re-build the Debian source of
the package, and they aren't used at all in the package building
process. For the purpose of a Debian source package, they're cruft
that needs to be omitted.
--
\ "It was half way to Rivendell when the drugs began to take |
`\ hold" -- Hunter S. Tolkien, _Fear and Loathing in Barad-Dûr |�_o__)
|
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Russ Allbery <[EMAIL PROTECTED]> writes: > Ben Finney <[EMAIL PROTECTED]> writes: > > They're useful to someone who will be using the VCS to track > > changes, because they contain bug information that is useful only > > in the context of that VCS data. > > Is this some additional VCS that the default dpkg-source regex > should be changed to also handle? Excluding any VCS files seems to > be the goal of the regex and I expect the maintainers would not be > adverse to adding another one. It's close. Bugs Everywhere is (like 'ditrack') designed to have the bug database for a project in a DVCS keep its bug database in the version-controlled files. It does this by maintaining a bug database in a hidden directory of the project's working tree. The directory defaults to '.be' in the working tree's top level. That directory and anything under it should be omitted from source packages. -- \ "Today, I was -- no, that wasn't me." -- Steven Wright | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Osamu Aoki <[EMAIL PROTECTED]> writes: > On Thu, Apr 24, 2008 at 10:31:21PM -0400, Felipe Sateler wrote: > > Ben Finney wrote: > > > > > What would be the best way to keep such a directory in place, > > > but exclude the directory from the Debian source and binary > > > packages? > > > > dpkg-source -i"regexp"? > > I am too lazy to type extra regexp > > I have ~/.devscripts with: > DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -ICVS -I.svn -I.git" > > I also have ~/.pbuilderrc with: > DEBBUILDOPTS="-i -ICVS -I.svn -I.git" Handy. Thank you for these tips. -- \ "I hope if dogs ever take over the world, and they chose a | `\king, they don't just go by size, because I bet there are some | _o__)Chihuahuas with some good ideas." -- Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Osamu Aoki <[EMAIL PROTECTED]> writes: > On Thu, Apr 24, 2008 at 10:31:21PM -0400, Felipe Sateler wrote: > > Ben Finney wrote: > > > > > What would be the best way to keep such a directory in place, but > > > exclude the directory from the Debian source and binary packages? > > > > dpkg-source -i"regexp"? > > I am too lazy to type extra regexp > > I have ~/.devscripts with: > DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -ICVS -I.svn -I.git" This doesn't have the same effect. The '-iEXCLUDE_REGEXP' option omits files matching the Perl regexp 'EXCLUDE_REGEXP' from the 'foo.diff.gz' Debian diff file. The '-IEXCLUDE_GLOB' option will omit files matching the shell glob 'EXCLUDE_GLOB' from the 'foo.orig.tar.gz' tarball. -- \ "I bought a self learning record to learn Spanish. I turned it | `\on and went to sleep; the record got stuck. The next day I | _o__)could only stutter in Spanish." -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Osamu Aoki <[EMAIL PROTECTED]> writes: > Now that I checked latest command, -i and -I without argument seems > to be good enough since current default regexp is very exhaustive. Okay. In this case, though, I have a directory in the working tree that *isn't* covered by the defaults for those options. > PS: These exclusion lists are impressive. Yet sometimes they are insufficient. I wish there was a way to *add* to the '-i' option, instead of wiping it completely. Apparently, there isn't such a way. -- \ "Anyone can do any amount of work provided it isn't the work he | `\ is supposed to be doing at the moment." -- Robert Benchley | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
"Joe Smith" <[EMAIL PROTECTED]> writes: > "Ben Finney" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > It's close. Bugs Everywhere is (like 'ditrack') designed to have > > the bug database for a project in a DVCS keep its bug database in > > the version-controlled files. It does this by maintaining a bug > > database in a hidden directory of the project's working tree. > > In other words, adding adding a .be folder to the default regex is a > sane idea, as including a bug database in the .diff.gz would be > absurd in any case. Yes. -- \"Most people don't realize that large pieces of coral, which | `\ have been painted brown and attached to the skull by common | _o__) wood screws, can make a child look like a deer." -- Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Developer names within debian/changelog
Howdy all, Policy §4.4, "Debian changelog", details the expected changelog format http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog>. It defines entries in the following form: = package (version) distribution(s); urgency=urgency [optional blank line(s), stripped] * change details more change details [blank line(s), included in output of dpkg-parsechangelog] * even more change details [optional blank line(s), stripped] -- maintainer name [two spaces] date = In recent years I've seen entries in 'debian/changelog' that are broken up into "sections" by developer name. I'm referring to entries like this: = package (version) distribution(s); urgency=urgency [ name of one developer ] * change details more change details [blank line(s), included in output of dpkg-parsechangelog] * even more change details [optional blank line(s), stripped] [ name of another developer ] * change details more change details [blank line(s), included in output of dpkg-parsechangelog] * even more change details [optional blank line(s), stripped] -- maintainer name [two spaces] date = The Policy section above is silent on this extension to the format, though I've seen Joey Hess discussing it in the past. I also know that 'debchange' can produce it, and 'dpkg' can consume it. Is it defined anywhere, such that I can produce it myself, or tell by visual inspection whether entries conform to it or not? -- \ “[T]he question of whether machines can think [...] is about | `\as relevant as the question of whether submarines can swim.” | _o__) —Edsger W. Dijkstra | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developer names within debian/changelog
Thijs Kinkhorst <[EMAIL PROTECTED]> writes: > On Monday 12 May 2008 06:17, Ben Finney wrote: > > The Policy section above is silent on this extension to the > > format, though I've seen Joey Hess discussing it in the past. I > > also know that 'debchange' can produce it, and 'dpkg' can consume > > it. > > Indeed debchange generates the format. I'm not sure what you mean > that dpkg can consume it. Sorry, I was unclear; I meant the 'dpkg-source' program (from the 'dpkg' package). > I know of no special meaning that dpkg assigns to those names, as > far as I know it just treats them like any other changelog line. Yet they don't conform to the policy specification, so I'm wondering what specification was followed when implementing consumers of the format. > If there's any specification to it, I think it's best found in > debchange's source code. That tells me *one* possible valid format, but doesn't tell me whether something different generated otherwise is also valid or not. A better way might be to look at the 'dpkg-source' source code. I did that, though, and my eyes started to cross from all the regexes :-( -- \ “It's dangerous to be right when the government is wrong.” | `\ —Francois Marie Arouet Voltaire | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developer names within debian/changelog
Russ Allbery <[EMAIL PROTECTED]> writes: > I don't know if it's worth being more formal here in Policy or not. > It might be more of a devref thing. I'm less interested in strictness in Policy than I am in finding out how this is *specified* for all consumers, rather than merely *implemented* in specific programs. Life is too short to go chasing down the difference between "that's the way it's specified so all consumers of the format can expect it", versus "that's the way it's implemented and who knows whether other implementations might be just as acceptable". If the answer is "there is no specification", than what on earth should a programmer looking to consume this format actually expect to consume? -- \ "Remember men, we're fighting for this woman's honour; which is | `\probably more than she ever did." -- Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developer names within debian/changelog
Thijs Kinkhorst <[EMAIL PROTECTED]> writes: > Maybe you can specify what problem you are trying to solve. That's a fair question. Thibaut Paumard <[EMAIL PROTECTED]> writes: > Le 13 mai 08 à 13:24, Ben Finney a écrit : > > I'm less interested in strictness in Policy than I am in finding > > out how this is *specified* for all consumers, rather than merely > > *implemented* in specific programs. > > It's merely allowed by the specification as Russ mentioned it. > There's no reason to specify it further, unless you're trying to > parse the changelog entries and want to detect these names. There's a disconnect there: I want to generate this data in such a way that someone *else* can parse the changelog entries for these names. Yes, there are existing tools to do it; but how can someone making a *new* tool know that they're always generating the output correctly? How can someone trying to parse output from various sources know whether a parsing error is due to bad input or bad parsing? It's probably a simple thing to specify. All the more reason for it to be specified in one place, by the people who designed it, rather than leave the question open of how to implement generators or parsers for it. -- \ “When cryptography is outlawed, bayl bhgynjf jvyy unir | `\ cevinpl.” —Anonymous | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developer names within debian/changelog
Ben Finney <[EMAIL PROTECTED]> writes: > Thijs Kinkhorst <[EMAIL PROTECTED]> writes: > > > Maybe you can specify what problem you are trying to solve. > > That's a fair question. And I didn't really answer it directly. Here's another try: I'm trying to know that what I put into the changelog is going to be machine-parseable for all the structural information that can reasonably be parsed from it. Sure, the conventional way is to use 'debchange' with appropriate options. What if I'm using a different tool? What if I'm editing the changelog by hand? Then I have the options of either "generate it however I think best, regardless of what parsers may expect", or "don't ever use any tool but debchange". The latter is (for me) unacceptable, and the former is irresponsible. All the answers I've had so far indicate that there *is* no specification for developer names within a changelog entry, and that any format at all is allowed so long as the loose definition in Policy is followed. My issue with that is that it leads to this information being recorded in many, mutually-incompatible ways (which was, I believe, the existing state when the format was proposed), with no simple guide of how one *should* put the information in to be a good Debian citizen. -- \"If you continue running Windows, your system may become | `\unstable." —Microsoft, Windows 95 BSOD message | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developer names within debian/changelog
Thijs, Goswin: Please follow the Debian mailing list code of conduct http://www.debian.org/MailingLists#codeofconduct>, in particular please don't send me copies of messages also sent to the list. Thijs Kinkhorst <[EMAIL PROTECTED]> writes: > Nearly all of the changelog is currently not machine-parsable, with > notable exclusion of the first and last line (-- author), and the > closes: statements. Everything else, like descriptions of files > changed, bugs fixed, translations updated, release codenames and > indeed maintainer names are there only for humans to read. Okay, thanks for this answer. AFAICT, this leads to "put whatever you want within a changelog entry, so long as it doesn't cause significant annoyance, because no program can expect to read it". Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Any consumer must accept anything with two leading spaces. Expecting > anything beyond that is not garantied to work. But a pretty good bet > is that it will follow the single or multi maintainer format > prodused by e.g. dch. The problem is that I need to reverse-engineer what debchange is doing if I want to reproduce it myself. > If you want to write your own tool to interpret a changelog entry I don't. I want to be considerate to people who *do* write such tools. Thanks again for everyone's answers, I have what I need now. -- \ "Pinky, are you pondering what I'm pondering?" "I think so, | `\ Brain, but three round meals a day wouldn't be as hard to | _o__) swallow." -- _Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developer names within debian/changelog
James Westby <[EMAIL PROTECTED]> writes: > As the ability to provide non-standard changelog parsers doesn't > seem to be used much, would it be a good idea to make it mandatory > to use the standard format, and at the same time retire any > pre-standard entries to debian/changelog.old or similar? So long as "the standard format" is specified such that it can be reliably produced and parsed (so that we're all talking about the same "standard format"), and there's a consensus that it *is* "the standard format", I'm in support of this. -- \ "I put contact lenses in my dog's eyes. They had little | `\ pictures of cats on them. Then I took one out and he ran around | _o__) in circles." -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dh_clean and explicit package clean lists
Howdy all, I recall recently seeing mention that 'dh_clean' could obey a 'debian/.clean' file as a list of patterns or files to clean. However, I can't find it with search engines; "package.clean" returns hits for "package clean", and "dh" returns hits for all the "dh_foo" commands. Can someone point me to a description or specification of this feature? -- \ "I bought some batteries, but they weren't included; so I had | `\ to buy them again." -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_clean and explicit package clean lists
Joey Hess <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > > I recall recently seeing mention that 'dh_clean' could obey a > > 'debian/.clean' file as a list of patterns or files to > > clean. > > I recently added support for dh_clean reading debian/clean (see its > man page) That's exactly it, I just misremembered the details. Thanks. > but didn't see any reason to support per-package > debian/package.clean, so didn't add that. Fair enough. I don't have a use case for that at the moment, so won't ask for it. -- \ "That's all very good in practice, but how does it work in | `\ *theory*?" -- Anonymous | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_clean and explicit package clean lists
Joey Hess <[EMAIL PROTECTED]> writes: > I recently added support for dh_clean reading debian/clean (see its man > page) I'm trying to remove the entire top-level '.be/' directory from the source package, using this feature of 'dh_clean'. However, in the 'debian/clean' file, neither of '.be' nor '.be/*' result in removing that directory from the source package. Am I wrong to expect 'dh_clean' to be run when building the Debian source package? What tool should I be using for this purpose? -- \ "True greatness is measured by how much freedom you give to | `\ others, not by how much you can coerce others to do what you | _o__) want." --Larry Wall | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_clean and explicit package clean lists
"Paul Wise" <[EMAIL PROTECTED]> writes: > On Sun, May 18, 2008 at 11:34 AM, Ben Finney > <[EMAIL PROTECTED]> wrote: > > > I'm trying to remove the entire top-level '.be/' directory from > > the source package, using this feature of 'dh_clean'. However, in > > the 'debian/clean' file, neither of '.be' nor '.be/*' result in > > removing that directory from the source package. > > Sounds like you are removing it from the diff.gz but want it removed > from the orig.tar.gz? If so, best ask upstream to not distribute it > there in the first place. No, I want it removed from the Debian '*.diff.gz'. It's part of the upstream source but is akin to VCS data: it should not be present in the Debian '*.diff.gz'. -- \ "I spilled spot remover on my dog. Now he's gone." -- Steven | `\Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_clean and explicit package clean lists
"Paul Wise" <[EMAIL PROTECTED]> writes: > On Sun, May 18, 2008 at 12:00 PM, Ben Finney wrote: > > No, I want it removed from the Debian '*.diff.gz'. It's part of > > the upstream source but is akin to VCS data: it should not be > > present in the Debian '*.diff.gz'. I misspoke here. '.be/' a directory that's part of both upstream *and* the Debian working tree, and belongs in version control; but should not be part of the Debian source package, because it's on the order of a VCS data directory. In other words (and thank you for asking questions until I know how to ask this): I want an additional directory to be removed from the Debian source package, the same way '.bzr/' and '.hg/' and 'CVS/' et al are removed when building the Debian source package. How can I achieve this? What should I use? -- \ "No wonder I'm all confused; one of my parents was a woman, the | `\ other was a man." -- Ashleigh Brilliant | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz (was: dh_clean and explicit package clean lists)
Ben Finney <[EMAIL PROTECTED]> writes: > In other words (and thank you for asking questions until I know how > to ask this): I want an additional directory to be removed from the > Debian source package, the same way '.bzr/' and '.hg/' and 'CVS/' et > al are removed when building the Debian source package. > > How can I achieve this? What should I use? Hmm. It seems I have cunningly tricked myself into continuing the discussion opened in Message-Id: <[EMAIL PROTECTED]> http://lists.debian.org/msgid-search/[EMAIL PROTECTED]>. Message header fields updated accordingly, to re-join the thread. The discussion was never resolved beyond "re-specify the entire cumbersome regex of dpkg-source, modified slightly for this directory". I will have a look at a patch to dpkg-source to allow for this particular directory. That solves the problem only on my system, unless and until all others building the package get an updated 'dpkg' incorporating the patch. So "patch dpkg-source" is similarly sub-optimal. In the meantime, I'd still appreciate alternative answers. -- \ "I went camping and borrowed a circus tent by mistake. I didn't | `\ notice until I got it set up. People complained because they | _o__)couldn't see the lake." -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz (was: dh_clean and explicit package clean lists)
"Paul Wise" <[EMAIL PROTECTED]> writes:
> You probably want a custom regex in the -i option to dpkg-source.
The biggest problem here is I don't want to lose the effect of the
*existing* buildpackage ignore list that 'dpkg-source' uses. I just
want to ignore an *additional* directory.
So it seems the only option being presented so far is to repeat the
entire, unwieldy thing, insert a pattern into it, and hope that I
haven't messed up the regex.
> Using debuild and DEBUILD_DPKG_BUILDPACKAGE_OPTS in ~/.devscripts is
> a good way to prevent the need to add it to the dpkg-buildpackage
> command-line every time you run it.
This '$HOME/.devscripts' file is not having the desired effect:
=
# $HOME/.devscripts
# Configuration for Debian developer scripts
# Options to pass to dpkg-buildpackage
tar_ignore_opts="-I.svn -I.git -I.bzr -I.shelf -I.be"
diff_ignore_opts="-i '# Ignore general backup files
(?:^|/).*~$|
# Ignore emacs recovery files
(?:^|/)\.#.*$|
# Ignore vi swap files
(?:^|/)\..*\.swp$|
# Ignore baz-style junk files or directories
(?:^|/),,.*(?:$|/.*$)|
# File-names that should be ignored (never directories)
(?:^|/)(?:DEADJOE|\.cvsignore|\.arch-inventory|\.bzrignore|\.gitignore)$|
# File or directory names that should be ignored
(?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn|\.hg|_darcs|\.git|
\.shelf|_MTN|\.be|\.bzr(?:\.backup|tags)?)(?:$|/.*$)
'"
DEBUILD_DPKG_BUILDPACKAGE_OPTS="${diff_ignore_opts} ${tar_ignore_opts}"
=
The package, when built, still has the '.be/' directory in the
'foo.diff.gz'. Setting 'export DH_VERBOSE=1' in the 'debian/rules'
file doesn't show the commandline options given to 'dpkg-source', so I
don't know if it's even using the '$HOME/.devscripts' settings.
How can I achieve the above correctly?
--
\ "Just because nobody complains doesn't mean all parachutes are |
`\ perfect." -- Benny Hill |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_clean and explicit package clean lists
Bas Wijnen <[EMAIL PROTECTED]> writes: > All the VCS stuff should definitely not be ignored; packages are > built from released tarballs, not from vcs checkouts (well, most of > the time anyway). But leaving them in will make lintian complain, > which is good. :-) Good point. I'll also file a bug with a patch to add a check to lintian for DBTS directories in the package. -- \ "We must respect the other fellow's religion, but only in the | `\ sense and to the extent that we respect his theory that his | _o__) wife is beautiful and his children smart." -- Henry L. Mencken | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Submit a bug report known to be blocked by another bug
Howdy all, When submitting a bug to <[EMAIL PROTECTED]>, the instructions at http://www.debian.org/Bugs/Reporting> show some of the control that can be operated by fields in the pseudo-header of the bug report message. One aspect of the bug I can't see represented there is the 'blocked by' property. I would like to be able to submit a bug with the information that it is blocked by another; often I know this at the time I'm submitting the bug report, so it would be good to put that in the pseudo-header at submit time. As it stands, all it seems I can do is to wait for the BTS to report my bug number, and only then can I hunt down the information on what bugs this new bug is blocked by, and 'bts block $NEWBUG by $OLDBUG_A $OLDBUG_B'. Is there a way to do this when submitting the bug report? -- \ "My house is on the median strip of a highway. You don't really | `\notice, except I have to leave the driveway doing 60 MPH." -- | _o__) Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Submit a bug report known to be blocked by another bug
Don Armstrong <[EMAIL PROTECTED]> writes: > Block by (and a few other control mechanisms) aren't support at > submit@ time; it's a valid wishlist bug, and one that I'm going to > be resolving soon. Thanks. Would you like me to submit a bug report for this wishlist bug? -- \ "Jealousy: The theory that some other fellow has just as little | `\ taste." -- Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Submit a bug report known to be blocked by another bug
Don Armstrong <[EMAIL PROTECTED]> writes: > On Mon, 19 May 2008, Ben Finney wrote: > > Don Armstrong <[EMAIL PROTECTED]> writes: > > > > > Block by (and a few other control mechanisms) aren't support at > > > submit@ time; it's a valid wishlist bug, and one that I'm going > > > to be resolving soon. > > > > Thanks. Would you like me to submit a bug report for this wishlist > > bug? > > If there's not currently one against debbugs At least six, if http://bugs.debian.org/378108> is to be believed. I'll refrain from adding yet another :-) -- \ "No matter how far down the wrong road you've gone, turn back." | `\ —Turkish proverb | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mutt-meta
Vern Sun <[EMAIL PROTECTED]> writes: > mutt-meta - Meta-package for the Mutt Email Client Environment. In addition to not giving any real information about what this package does, this fails the packaging guidelines by starting "Meta" with a capital letter. It would also be good if you gave the full long description here too. -- \"Courteous and efficient self-service." —Café sign, southern | `\France | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Packager question again: can you point me to a not flawed package?
George Danchev <[EMAIL PROTECTED]> writes: > Using a modern SCM is wonderful, but please, get back to the ground, > and think of the possible use cases with what Debian has officially > released, and if that is what warns a certain level of unification. > There are users (let's say within restricted areas) who can't access > random DD repos at will, but rely solely on diff.gz supplied by > released source CD/DVD media. It sounds like you are strongly motivated to contribute to a tool that will allow developers that track changes in their VCS to automatically generate the 'debian/patches/' directory that you are so interested in seeing. Stronger motivated than, say, the motivation felt by the VCS-using developer themselves, who already has a workflow that functions fine. -- \“The restriction of knowledge to an elite group destroys the | `\ spirit of society and leads to its intellectual | _o__) impoverishment.” —Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: python-minimock
Howdy mentors, I have a package that is seeking a sponsor. Package name: python-minimock Version:0.8-1 Upstream Author:Ian Bicking <[EMAIL PROTECTED]> URL:http://pypi.python.org/pypi/MiniMock License:Expat Section:python It builds the binary package 'python-minimock', which has the following description: Description: simple library for Python mock objects minimock is a simple Python library for using mock objects. . Its mock objects will report any access made to the mock object's interfaces. By using the standard-library 'doctest' module, the programmer can easily make assertions about how mock objects are used by matching the reported access against expected behaviour. . Mock objects can return specified values, raise exceptions, etc. to simulate the mocked behaviour. Existing objects can optionally be replaced in-place in their namespace by a mock object, and restored safely after testing. The package passes 'lintian' with no warnings or errors. It is on mentors.debian.net: URL: http://mentors.debian.net/debian/pool/main/p/python-minimock/ Repository: http://mentors.debian.net/debian/ unstable main Command: dget http://mentors.debian.net/debian/pool/main/p/python-minimock/python-minimock_0.8-1.dsc I'll appreciate it if someone can sponsor this package into Debian for me. -- \ "In the long run, the utility of all non-Free software | `\ approaches zero. All non-Free software is a dead end." —Mark | _o__) Pilgrim, 2006 | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-minimock
Michal Čihař <[EMAIL PROTECTED]> writes:
> Maybe you should try to maintain this package within Python Modules
> team...
Unfortunately they require using a Subversion repository. One of the
big advantages of Alioth is that I don't have to use Subversion
repositories for my packages :-)
If I could use the Bazaar repository on Alioth, I'd be happy to join.
> Why do you set all these variables in debian/rules which you don't
> use?
Legacy of previous packages. Fixed.
> Why you can not use simply 'dh install'?
Because 'python-central' didn't support debhelper v7...
> You can use 'dh --with python_central binary-indep' in binary-indep
> (and build-dep on python-central (>= 0.6.7).
... and thank you for pointing out that 'python-central' 0.6.7 *does*
support debhelper v7, which I hadn't noticed. Fixed.
> Please upgrade to standards 3.8.0.
The 'lintian' I have on my 'testing' workstation complains if I do
that ("newer-standards-version 3.8.0 (current is 3.7.3)"), but
alright, done.
Thanks very much for the feedback.
--
\ "If you go flying back through time and you see somebody else |
`\ flying forward into the future, it's probably best to avoid eye |
_o__)contact." -- Jack Handey |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: python-minimock 0.8-2
Howdy mentors, I have a package that is seeking a sponsor. Package name: python-minimock Version:0.8-2 Upstream Author:Ian Bicking <[EMAIL PROTECTED]> URL:http://pypi.python.org/pypi/MiniMock License:Expat Section:python It builds the binary package 'python-minimock', which has the following description: Description: simple library for Python mock objects minimock is a simple Python library for using mock objects. . Its mock objects will report any access made to the mock object's interfaces. By using the standard-library 'doctest' module, the programmer can easily make assertions about how mock objects are used by matching the reported access against expected behaviour. . Mock objects can return specified values, raise exceptions, etc. to simulate the mocked behaviour. Existing objects can optionally be replaced in-place in their namespace by a mock object, and restored safely after testing. The package passes 'lintian' with no warnings or errors. It is on mentors.debian.net: URL: http://mentors.debian.net/debian/pool/main/p/python-minimock/ Repository: http://mentors.debian.net/debian/ unstable main Command: dget http://mentors.debian.net/debian/pool/main/p/python-minimock/python-minimock_0.8-2.dsc I'll appreciate it if someone can sponsor this package into Debian for me. -- \ "Philosophy is questions that may never be answered. Religion | `\ is answers that may never be questioned." —anonymous | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-minimock 0.8-2
Michal Čihař <[EMAIL PROTECTED]> writes:
> Why did you add DM-Upload-Allowed?
Because I'm applying for Debian Maintainer status, and I'd like to be
able to make use of that with this package in future releases.
Should I not do this?
> Please fix debian/copyright, minimock.py is not under Expat license,
> but:
>
> Licensed under the MIT license:
> http://www.opensource.org/licenses/mit-license.php
The terms currently available at that URL, and those directly included
with the package ('docs/license.txt' in the source) are identical to
the terms of the Expat license.
See the explanation at
http://wiki.debian.org/Proposals/CopyrightFormat#head-efd90160bd80efbe27609100a3e0b055774cf0e9>
for the explanation of why the name "Expat" is simpler and less
ambiguous than "MIT" when referring to those license terms.
This might be an issue worth taking up with the upstream developer (a
request to simply change the name used to refer to the exact same
license terms), but regardless should not IMO impact being able to
release the package.
Thanks again for examining this package.
--
\ "My girlfriend has a queen sized bed; I have a court jester |
`\ sized bed. It's red and green and has bells on it, and the ends |
_o__) curl up." -- Steven Wright |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-minimock 0.8-2
Michal Čihař <[EMAIL PROTECTED]> writes: > On Sat, 14 Jun 2008 00:46:58 +1000 > Ben Finney <[EMAIL PROTECTED]> wrote: > > > Should I not [set the DM-Upload-Allowed field]? > > I won't upload package with DM-Upload-Allowed unless I'm confident > that the maintainer will not break something in next uploads. And I > can not say this when uploading package for first time. That's fine, it's a reasonable and cautious policy. I approve :-) > I uploaded the package without DM-Upload-Allowed, if you need it to > upload new version, just drop me an email with [sponsoring] > somewhere in subject. Thank you very much! -- \“Compulsory unification of opinion achieves only the | `\ unanimity of the graveyard.” —Justice Roberts in 319 U.S. | _o__) 624 (1943) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: python-minimock
Vincent Bernat <[EMAIL PROTECTED]> writes: > Wow, that's really close-minded. People are trying to work more > together (important packages are now encouraged to have a > co-maintainer, there is more and more teams) and you just refuse to > work with any other VCS than Bazaar? Quite a leap from what I actually said. Thanks for the offer of guilt, but I'll decline. -- \ "I just got out of the hospital; I was in a speed-reading | `\ accident. I hit a bookmark and flew across the room." -- | _o__) Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Latest upstream versions of files
Ben Finney <[EMAIL PROTECTED]> writes: > I'm the current maintainer for 'lojban-common', a very simple > package of some data files for the Lojban language. > > The latest version of the files hasn't changed in many years. It > would be easy for me to simply assume that they'll never change > during my maintainership of the package. However, I don't consider > that attitude good enough; I'd want a good package maintainer to > stay on top of even slow-moving packages, and use automation as much > as feasible. Since this original message, I've had 'lojban-common' sponsored into Debian. (Thanks, Anibal!) However, I'm still looking for a good approach to this situation. The files in this package are located at individual URLs, with no attempt made by upstream at putting them together into an archive. The packaging currently http://ftp.debian.org/debian/pool/main/l/lojban-common/lojban-common_1.4-1.dsc> has a 'get-orig-source' target, but that results in fetching the original source files every time the package is built, ignoring any existing tarball. The Best Practices chapter of the Developer's Reference suggests http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-repackagedorigtargz>: 6.7.8.2 Repackaged upstream source You should upload packages with a pristine source tarball if possible, but there are various reasons why it might not be possible. This is the case if upstream does not distribute the source as gzipped tar at all […] In these cases the developer must construct a suitable .orig.tar.gz file himself. There is no suggestion for the best way to make this happen, though. Ideally I'd like it to be a simple process for someone else to generate the upstream-source tarball automatically from the online files, and get the same result as when I do it. What can I do to meet this aim? -- \ "If you do not trust the source do not use this program." | `\ —Microsoft Vista security dialogue | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Latest upstream versions of files
Charles Plessy <[EMAIL PROTECTED]> writes:
> the Policy gives more hints:
>
> get-orig-source (optional)
>
> This target fetches the most recent version of the original source
> package from a canonical archive site (via FTP or WWW, for example),
> does any necessary rearrangement to turn it into the original source tar
> file format described below, and leaves it in the current directory.
>
> This target may be invoked in any directory, and should take care to
> clean up any temporary files it may have left.
>
> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules
Okay, that's pretty good, thank you.
I have the following rule:
.PHONY: get-orig-source
get-orig-source: ${SOURCE_FILES}
dpkg-source -b $(CURDIR)
This isn't having the desired effect; 'dpkg-source' attempts to write
to temporary files in the current directory, and then complains that
the directory content changes while it was reading it.
dpkg-source: info: building lojban-common in lojban-common_1.4-2.tar.gz
tar: lojban-common.debian/lojban-common_1.4-2.tar.gz.new.ohh0aH: file
changed as we read it
Do I need to make a temp directory, replicate the files from the
current directory into that temporary directory, invoke 'dpkg-source',
and clean up? Or is there a more straightforward way?
It also isn't making the expected 'lojban-common_1.4.orig.tar.gz', but
instead seems to just be making a tarball based on the full Debian
version. The 'dpkg-source' manpage doesn't indicate how I should
change this behaviour. How do I build *only* the upstream-source
tarball?
--
\ "The way to build large Python applications is to componentize |
`\ and loosely-couple the hell out of everything." -- Aahz |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Updating a package; ediquette and procedure questions
"Paul Johnson" <[EMAIL PROTECTED]> writes: > The Debian packaging process still seems awkward to me, but I think > I'm starting to make it work. Congratulations on your persistence, and thank you for your efforts to understand the needs of those who package your software. > I had not realized the package builder was detecting the version of > the deb package from the changelog. Surprise! A pleasant surprise, I hope. (I see it as an excellent application of the Don't Repeat Yourself principle.) > 1. Is this roughly how you would go about building a package for a > new source tarball? I'd usually maintain an ongoing "upstream source" branch in the VCS, and merge the changes from a new version into that. Not try to build directly from the upstream source. Then, use the appropriate 'foovcs-buildpackage' tool (where 'foovcs' is the VCS in question) to automatically export and copy files to the appropraite places to generate Debian source and binary packages. > 2. In Ubuntu, or Debian more generally, what happens when package > maintainers don't stay up to date? Someone files a bug report against the package. Setting the bug report severity to "wishlist" and summary of "New upstream version available" are customary, but not immutable. That bug report is then the contact point for any discussion about packaging that new upstream version, regardless of whether the official package maintainer is responsive. > It is a little tough to figure out who is responsible for a package > sometimes, there is an OriginalMaintainer and other names in the > changelog. The Debian source package format includes a mandatory control file with fields describing the package; look for "foo_1.2-3.dsc". One of the mandatory fields in that file is 'Maintainer', giving the contact details for the maintainer of the Debian package. > If you email the person you think is in charge, and don't get an > answer, what do you do? Be patient, if possible. File the "New upstream version available" bug report yourself, definitely. If it's more urgent that a new version should be packaged (e.g. a security vulnerability), you could agitate for some other Debian developer to address the bug report, with a Non-Maintainer Upload of a new revision of the package. > 3. What do you do with code distributed in bz2 files? Complain about the fact that the currently-supported Debian source package format doesn't allow them. Then, repackage them as gzip tarballs. There is a new source package format specification in the pipeline that does allow (among many new features) upstream source tarballs in bzip2 format, but cannot be recommended until the entire toolchain and infrastructure supports that specification. -- \ “Holy astringent plum-like fruit, Batman!” —Robin | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dh_install not finding files from orig source (was: Latest upstream versions of files)
Ben Finney <[EMAIL PROTECTED]> writes:
> There is no suggestion for the best way to make this happen, though.
> Ideally I'd like it to be a simple process for someone else to
> generate the upstream-source tarball automatically from the online
> files, and get the same result as when I do it.
My current progress on this is now online at
http://mentors.debian.net/debian/pool/main/l/lojban-common>.
The 'debian/get-orig-source' program is working fine, creating an
archive tarball of the original upstream files, named correctly as
'lojban-common_1.5.orig.tar.gz'. This is now the command run by the
'get-orig-source' target in 'debian/rules'.
However, I'm not having any luck building the binary package. I'm
constructing, via the 'install' target in 'debian/rules', a
'debian/lojban-common.install' file:
=
.PHONY: install
install: build
cut -d ' ' -f 3 ${SHA1SUMS_FILE} \
| sed -e 's_$$_\tusr/share/lojban_' \
> debian/${PACKAGE_NAME}.install
dh install
=
This does indeed create the 'debian/lojban-common.install' file
correctly. But 'dh_install' doesn't seem to use it properly; it's
complaining about a file path that I don't understand.
=
$ bzr-buildpackage --build-dir ../build-area/
Building using working tree
Preparing the build area: ../build-area/
Looking for ../tarballs/lojban-common_1.5.orig.tar.gz to use as upstream source
Exporting to ../build-area/lojban-common-1.5
Building the package in ../build-area/lojban-common-1.5, using
dpkg-buildpackage -rfakeroot -D -si
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value:
dpkg-buildpackage: set LDFLAGS to default value:
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package lojban-common
dpkg-buildpackage: source version 1.5-1
dpkg-buildpackage: source changed by Ben Finney <[EMAIL PROTECTED]>
dpkg-buildpackage: host architecture powerpc
fakeroot debian/rules clean
dh clean
dh_testdir
dh_auto_clean
dh_clean
dpkg-source -b lojban-common-1.5
dpkg-source: info: using source format `1.0'
dpkg-source: info: building lojban-common using existing
lojban-common_1.5.orig.tar.gz
dpkg-source: info: building lojban-common in lojban-common_1.5-1.diff.gz
dpkg-source: warning: ignoring deletion of file NORALUJV.txt
dpkg-source: warning: ignoring deletion of file cmavo.txt
dpkg-source: warning: ignoring deletion of file lujvo.txt
dpkg-source: warning: ignoring deletion of file rafsi.txt
dpkg-source: warning: ignoring deletion of file gismu.txt
dpkg-source: info: building lojban-common in lojban-common_1.5-1.dsc
debian/rules build
make: Nothing to be done for `build'.
fakeroot debian/rules binary
cut -d ' ' -f 3 debian/upstream.sha1sums \
| sed -e 's_$_\tusr/share/lojban_' \
> debian/lojban-common.install
dh install
dh_testdir
dh_auto_configure
dh_auto_build
dh_auto_test
dh_testroot
dh_prep
dh_installdirs
dh_auto_install
dh_install
cp: cannot stat `debian/tmp/cmavo.txt': No such file or directory
dh_install: command returned error code 256
make: *** [install] Error 1
dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit status
2
bzr: ERROR: The build failed.
=
Why is 'dh_install' looking for the file 'debian/tmp/cmavo.txt', when
that's not mentioned in the 'lojban-common.install' file?
I'd appreciate feedback from people downloading my source package and
finding where I've gone wrong.
--
\ "For my birthday I got a humidifier and a de-humidifier. I put |
`\ them in the same room and let them fight it out." -- Steven |
_o__) Wright |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_install not finding files from orig source
Joey Hess <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > >dh_install > > cp: cannot stat `debian/tmp/cmavo.txt': No such file or directory > > dh_install: command returned error code 256 > > make: *** [install] Error 1 > > dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit > > status 2 > > bzr: ERROR: The build failed. > > = > > > > Why is 'dh_install' looking for the file 'debian/tmp/cmavo.txt', when > > that's not mentioned in the 'lojban-common.install' file? > >From debhelper compatibility level 7 on, if --sourcedir is not >specified, dh_install will install files from debian/tmp if the >directory contains the files. Otherwise, it will install files from the >current directory. Thanks, I wasn't aware of that change. However, that doesn't solve the mystery. If the above is an accurate description of behaviour, 'dh_install' shouldn't be exiting with an error if the file doesn't exist in 'debian/tmp'; it should only attempt to install from there "if the directory contains the files". Why, then, is it exiting with a "No such file or directory" error trying to read the file from 'debian/tmp'? Feel free (anyone!) to use the online source package http://mentors.debian.net/debian/pool/main/l/lojban-common/> to try it for yourself and see if you can explain what's going wrong better than I. -- \"My doctor told me to stop having intimate dinners for four. | `\Unless there are three other people." -- Orson Welles | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SOLVED: dh_install not finding files from orig source
Ben Finney <[EMAIL PROTECTED]> writes: > The 'debian/get-orig-source' program is working fine, creating an > archive tarball of the original upstream files, named correctly as > 'lojban-common_1.5.orig.tar.gz'. This is now the command run by the > 'get-orig-source' target in 'debian/rules'. > > > However, I'm not having any luck building the binary package. This turned out to be a mix-up with a previously-created 'lojban-common_1.5.orig.tar.gz' existing, not being overwritten, and not containing the files at the expected locations. After 'rm ../build-area/*', the build process worked again (by creating the upstream source tarball from scratch). -- \ “People demand freedom of speech to make up for the freedom of | `\ thought which they avoid.” —Soren Aabye Kierkegaard (1813-1855) | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: lojban-common 1.5-1
Howdy mentors, I have a package that is seeking a sponsor. Package name: lojban-common Version:1.5-1 Upstream Author:Logical Language Group, Inc. URL:http://www.lojban.org/ License:Public Domain Section:misc It builds the binary package 'lojban-common', which has the following description: Description: commonly-used wordlists for the Lojban language Lojban is a constructed human language, designed to have a logical foundation, a regular, logical, and unambigious structure, phonetic spelling, and to be culturally neutral. . This package contains the current versions of the gismu, cmavo, rafsi, and lujvo wordlists for the Lojban language, as published by the Logical Language Group. This revision of the package updates it for a number of outstanding packaging deficiencies. The package now passes 'lintian' with no warnings or errors. It is on mentors.debian.net: URL: http://mentors.debian.net/debian/pool/main/l/lojban-common/ Repository: http://mentors.debian.net/debian/ unstable main Command: dget http://mentors.debian.net/debian/pool/main/l/lojban-common/lojban-common_1.5-1.dsc I'll appreciate it if someone can sponsor this package into Debian for me. -- \“When in doubt tell the truth. It will confound your enemies | `\ and astound your friends.” —Mark Twain, _Following the Equator_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: lojban-common 1.5-2
Howdy mentors, (Thanks to Mike Connor for pointing out issues with revision 1.5-1 of this package.) I have a package that is seeking a sponsor. Package name: lojban-common Version:1.5-2 Upstream Author:Logical Language Group, Inc. URL:http://www.lojban.org/ License:Public Domain Section:misc It builds the binary package 'lojban-common', which has the following description: Description: commonly-used wordlists for the Lojban language Lojban is a constructed human language, designed to have a logical foundation, a regular, logical, and unambigious structure, phonetic spelling, and to be culturally neutral. . This package contains the current versions of the gismu, cmavo, rafsi, and lujvo wordlists for the Lojban language, as published by the Logical Language Group. The package passes 'lintian' with no warnings or errors. It is on mentors.debian.net: URL: http://mentors.debian.net/debian/pool/main/l/lojban-common/ Repository: http://mentors.debian.net/debian/ unstable main Command: dget http://mentors.debian.net/debian/pool/main/l/lojban-common/lojban-common_1.5-2.dsc I'll appreciate it if someone can sponsor this package into Debian for me. -- \ “Anyone who believes exponential growth can go on forever in a | `\finite world is either a madman or an economist.” —Kenneth | _o__) Boulding | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lojban-common 1.5-2
Mike O'Connor <[EMAIL PROTECTED]> writes: > On Wed, Jul 02, 2008 at 12:24:00AM +1000, Ben Finney wrote: > > Package name: lojban-common > > Version:1.5-2 > > Do you have a good reason to make a new -2 instead of just making > the changes in -1 since -1 hasn't yet been uploaded? Yes: 1.5-1 *was* uploaded, to the mentors repository. That means an unknown number have already got 1.5-1 (I even explicitly asked them to do so), and releasing a changed package without also changing the release number would be needlessly confusing. In a real sense, once I upload a revision of a package to mentors.d.n it *is* released, even if it doesn't make it into Debian. So any further changes made should be to a subsequent release number. There have been complaints from DDs in the past on this very forum about re-uploading to mentors.d.n a different package with the same release number. So I don't do that. -- \ “Yesterday I parked my car in a tow-away zone. When I came back | `\ the entire area was missing.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: php-clamavlib
"Adam Sommer" <[EMAIL PROTECTED]> writes: > I am looking for a sponsor for the new version 0.13-1.2 of my > package "php-clamavlib". Are you actually the maintainer? The current package version (0.13-1.1) lists Jonas Gennart <[EMAIL PROTECTED]> as the package maintainer. There is no RFH, RFA, or O bug reported against this package by the maintainer. > It builds these binary packages: > php5-clamavlib - PHP ClamAV Lib - ClamAV Interface for PHP5 Scripts The synopsis of the package should not be capitalised (Developer's Reference §6.2.2, "The package synopsis, or short description" http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-pkg-synopsis>). Nor should the synopsis repeat itself, saying the same thing twice. A better synopsis for the package would be: interface to ClamAV for PHP5 -- \ “Those who write software only for pay should go hurt some | `\ other field.” —Erik Naggum, in _gnu.misc.discuss_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: php-clamavlib
"Sandro Tosi" <[EMAIL PROTECTED]> writes: > On Wed, Jul 2, 2008 at 06:34, Ben Finney > <[EMAIL PROTECTED]> wrote: > > "Adam Sommer" <[EMAIL PROTECTED]> writes: > > > >> I am looking for a sponsor for the new version 0.13-1.2 of my > >> package "php-clamavlib". > > > > Are you actually the maintainer? The current package version > > (0.13-1.1) lists Jonas Gennart <[EMAIL PROTECTED]> as the > > package maintainer. > > it's a NMU (*Non* Maintainer Upload), as the version clearly states. This is at odds with Adam referring to "my package". Hence my question. If this was merely the result of not checking the text of a RFS template to see if it makes sense, all the more reason to do that in future. -- \ “I bought some batteries, but they weren't included; so I had | `\ to buy them again.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: P4A - PHP For Applications
"Andrea Giardina" <[EMAIL PROTECTED]> writes: > Hi Raphael, > >> This program is free software: you can redistribute it and/or modify > >> it under the terms of the GNU General Public License as published by > >> the Free Software Foundation, either version 2.1 of the License. > > > > looks like some part of it is missing > uhm, sorry, I don't understand.. which part is missing? First, there is no "version 2.1" of the GNU General Public License. Either the version is wrong, or the name is wrong, or both. Second, the copyright statement says "either version 2.1 of the License" and then stops. This makes no sense: "either" implies alternative options, but only one option is presented. -- \ “Probably the earliest flyswatters were nothing more than some | `\sort of striking surface attached to the end of a long stick.” | _o__) —Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: P4A - PHP For Applications
"Andrea Giardina" <[EMAIL PROTECTED]> writes: > > Second, the copyright statement says "either version 2.1 of the > > License" and then stops. This makes no sense: "either" implies > > alternative options, but only one option is presented. > ops.. bad copy and paste... thank you It would be best to copy and paste the recommended text from the "How to Apply These Terms" section of the license text. -- \ “Smoking cures weight problems. Eventually.” —Steven Wright | `\ | _o__) | Ben Finney -- 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]
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: atmailopen (2nd attempt)
Giuseppe Iuculano <[EMAIL PROTECTED]> writes: > Dear mentors, > > I am looking for a sponsor for my package "atmailopen". > > * Package name: atmailopen > Version : 1.01-1 > Upstream Author : @Mail <[EMAIL PROTECTED]> > * URL : http://www.atmail.org/ > * License : Apache License Version 2.0 > Section : web > > > > Description: An Open Source Webmail Client The synopsis (short one-line package description) should not be capitalised like the start of a sentence. Nor should it begin with an article like "a" or "an". Please refer to http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-pkg-synopsis>. All of Debian is "open source", because it is all free software. This is not a useful thing to put in the package description. What makes this package different or useful compared to other similar software in Debian? Try summarising that in the synopsis. -- \“Nothing so needs reforming as other people's habits.” —Mark | `\ Twain, _Pudd'n'head Wilson_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: atmailopen (2nd attempt)
Giuseppe Iuculano <[EMAIL PROTECTED]> writes: > I think now it should be fixed, reuploaded. Since many prospective sponsors will want to see the description as it stands now, you should probably send another RFS message with the updated description. > (I'm sorry for duplicate email, I forgot to change 'to' field.) Thanks for being aware of mailing list policy, and fixing that. -- \ “The WWW is exciting because Microsoft doesn't own it, and | `\ therefore, there's a tremendous amount of innovation | _o__) happening.” —Steve Jobs | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: atmailopen (2nd attempt - updated description)
Giuseppe Iuculano <[EMAIL PROTECTED]> writes: > Description: elegant and intuitive ajax webmail client written in php > AtMail is a webmail client written in PHP. It aim to provide > an elegant Ajax webmail client for existing IMAP mailservers, with less bloat > and a focus on an intuitive, simple user interface. Seems fine, except for all the references to PHP; you should remove all of them. Once the package is in Debian, you can use debtags to classify things like implementation language. > AtMail provides users with a lightweight, yet powerful webmail client and > it is poised to deliver the next generation webmail. This sentence seems like useless marketing drivel. It can safely be deleted. > Features of AtMail Open include: >* Lightweight Ajax Webmail Interface >* Video Mail >* PHP source code >* IMAP support >* Live Spell Check >* Address Book Good. Giuseppe Iuculano <[EMAIL PROTECTED]> writes: > Description: elegant and intuitive ajax webmail client Much improved. -- \ “In any great organization it is far, far safer to be wrong | `\ with the majority than to be right alone.” —John Kenneth | _o__) Galbraith, 1989-07-28 | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: atmailopen (2nd attempt - updated description)
Eduardo M KALINOWSKI <[EMAIL PROTECTED]> writes: > Eugene V. Lyubimkin wrote: > > Debian developers reference suggest not no put "written in > > " into one-line descriptions - it is useless for users > > to know what language the program written in. > > In this particular case, it actually can be useful, since it's a web > application to be run in a web browser, which will need support for the > particular language. I've never needed PHP support in my web browser to use web applications written in PHP. Perhaps you mean the web *server* needs PHP support? > Naturally, the same can be guessed from the package dependencies, This information is better done with debtags, using the organised tag hierarchy, rather than cluttering the description. Packaging tools can easily show the debtags for a package along with its description. -- \ "The opposite of a correct statement is a false statement. But | `\ the opposite of a profound truth may well be another profound | _o__) truth." —Niels Bohr | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: atmailopen (2nd attempt - updated description)
Eduardo M KALINOWSKI <[EMAIL PROTECTED]> writes: > I meant that from the server admin's point of view, it he who will > be installing the package, not the users. Right. So, that admin, when she's ready to install packages, can choose to use a package tool like aptitude that will display all the debtags for a package. -- \ “I have an answering machine in my car. It says, ‘I'm home now. | `\ But leave a message and I'll call when I'm out.’” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libzendframework-php
"Andrea Giardina" <[EMAIL PROTECTED]> writes:
> It builds these package:
> libzendframework-php - High quality framework for Web Development
Please note the "best packaging practice" for the package synopsis
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-pkg-synopsis>.
The synopsis should *not* be capitalised like a full sentence.
> Description:
> Zend Framework is a high quality framework for developing Web Applications
> and Web Services with PHP.
> It provides solutions for building modern, robust, and secure websites
Please separate paragraphs with a "blank line", which is achieved with
a full stop (".") on a line by itself. Also, terminate full sentences
with a full stop.
The terms "web applications" and "web services" are not proper nouns
(i.e. they're not names of specific entities), so should not be
capitalised.
Hence:
Description: high quality framework for Web Development
Zend Framework is a high quality framework for developing web
applications and web services with PHP.
.
It provides solutions for building modern, robust, and secure
websites.
--
\ “I have no race prejudices nor caste prejudices nor creed |
`\prejudices. All I care to know is that a man is a human being, |
_o__) and that is enough for me; he can't be any worse.” —Mark Twain |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libzendframework-php
Ben Finney <[EMAIL PROTECTED]> writes: > The terms "web applications" and "web services" are not proper nouns > (i.e. they're not names of specific entities), so should not be > capitalised. > > Hence: > > Description: high quality framework for Web Development Following my own advice, that should be: Description: high quality framework for web development -- \ “It's a good thing we have gravity or else when birds died | `\ they'd just stay right up there. Hunters would be all | _o__) confused.” —Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about watch-file
Mauro Lizaur <[EMAIL PROTECTED]> writes: > The thing is that the format of the url [1] is something similar to > http://host/release.zip where you can't see if it has a new release > or anything. It can't hurt to ask upstream to make release archives with the version string in the filename. That would be the ideal situation, and you could then encode that in the 'debian/watch' file. > And i don't know if i should add a lintian-override, Rather than an override, you can simply add a 'debian/watch' file that has (only) comments explaining the current situation. > add a watch file with the url [1] anyway That wouldn't be any use. An empty watch file (with comments) is better than this. > or to contact the upstream author and ask him if he could change the > URL to something where the watch file can tell if there's a new > version. Best of luck with this. -- \ “The trouble with eating Italian food is that five or six days | `\later you're hungry again.” —George Miller | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about watch-file
Patrick Schoenfeld <[EMAIL PROTECTED]> writes: > On Tue, Jul 08, 2008 at 12:30:57AM +1000, Ben Finney wrote: > > An empty watch file (with comments) is better than [a watch file > > with a URL to an unversioned file]. > > Whats your rationale for proposing to include useless empty files > within of a package? They're not useless if they document the situation in comments. > Given that > a) a watch file is still optional > b) the lintian message is only of type 'info' Right. And the lintian message suggests exactly what I'm suggesting: a watch file that documents exactly why 'uscan' can't yet do its work for this particular package. > c) We don't hide problems according to our social contract Indeed. Documenting them explicitly is what I'm suggesting, instead of an override to silence a message. > I'd say the best thing is to not include a watch file, to not add a > lintian override (its useless anyway) and fix the problem with > upstream first and _then_ fix it in the package. Creating the watch file with comments on the *current* situation is no barrier to also working with upstream to fix that situation. In addition, it documents the current situation exactly where people can be expected to look, for as long as that situation persists. -- \ “No wonder I'm all confused; one of my parents was a woman, the | `\ other was a man.” —Ashleigh Brilliant | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about watch-file
Patrick Schoenfeld <[EMAIL PROTECTED]> writes: > On Tue, Jul 08, 2008 at 11:23:24PM +1000, Ben Finney wrote: > > Right. And the lintian message suggests exactly what I'm > > suggesting: a watch file that documents exactly why 'uscan' can't > > yet do its work for this particular package. > > Seems wrong to me. The lintian text states that a package which is > "(...) not maintained upstream (...)" may add a commented watch file > "(...) containing only comments to document this." In my opinion the > wording is very clear and aims at packages who are not maintained > upstream. Your reading is correct; thank you for drawing my attention to this. I come to a different conclusion, though, which I'll explain below. > Meaning that a watch file is useless, because it will never report > new upstream versions. But a comment is useful, because everyone who > wants to do something with the package can read from it that > upstream is dead. You're correct that the 'debian-watch-file-is-missing' description suggests that a comments-only watch file is appropriate when upstream is inactive. I think this is only one possible case where it's reasonable to do so, though. My suggestion is that comments in the watch file are appropriate to document *any* reason why the package maintainer is currently unable to provide suitable information for 'uscan'. > Despite that I'm not sure if the watch file is the proper place for > such a note this has sureley an entitlement, and the watch file > can't be fixed anyway, so a warning is inappropriate. I don't understand what you're saying in this sentence. > > Indeed. Documenting them explicitly is what I'm suggesting, > > instead of an override to silence a message. > > Well, the problem with your solution is that you silence an > indicator for a problem anyway. Someone who looks at the lintian > status of the package can do this from the outside and can decide to > act upon. I don't think lintian should be providing such an indication "from the outside"; that's more appropriate for the DEHS checker. I think the description of 'debian-watch-file-is-missing' should be changed to ask the package maintainer to add a watch file regardless: either with functional settings for 'uscan', or with comments explaining why this can't currently be done. > If you add a comment in a watch file then you have a comment in a > hidden place for a lot of people who could potential fix the > problem. They would need to look *into* that specific package, which > is unlikely. DEHS already clearly shows packages for which the upstream version can't be checked; e.g. see http://dehs.alioth.debian.org/maintainer.php?name=lojban-common>. > No, not for the current maintainer, thats true. But it *is* a > barrier for everybody who wants to track specific problems from the > outside, e.g. by looking at lintian.d.o. My argument is that lintian, which is a tool suitable for running frequently by the package maintainer, should not nag the developer for such a common situation. Adding a lintian override is inappropriate if the situation is not exceptional, and especially not if the problem can be documented in a better way. Those who want to find problems like "is the package healthy?" should be looking at the DEHS reports, which show this status clearly without involvement by lintian. They will then know that 'uscan' had some problem, and can examine the watch file, where they'll see whatever the package maintainer has written about the situation. No need to get lintian involved. -- \ “Life does not cease to be funny when people die any more than | `\ it ceases to be serious when people laugh.” —George Bernard Shaw | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about watch-file
Russ Allbery <[EMAIL PROTECTED]> writes: > If the package is not maintained upstream or if upstream uses a > distribution mechanism that cannot be meaningfully monitored by > uscan and the Debian External Health Status project, please > consider adding a debian/watch file containing only comments > documenting the situation. Looks good to me, thanks for this change. > This is not a problem *with the Debian package*, which is what > lintian.d.o is trying to track. It's a problem with upstream. A more compelling and simple argument than mine, thank you :-) -- \ “I went to a museum where all the artwork was done by children. | `\ They had all the paintings up on refrigerators.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about watch-file
Raphael Geissert <[EMAIL PROTECTED]> writes: > Russ Allbery wrote: > > > having the Debian External Health Status system extract watch > > files containing only comments and put the text of the comments up > > on the DEHS web site. > > Is that a feature request? it sounds like one :) > > Implemented: > http://dehs.alioth.debian.org/report.php?package=lojban-common Fast work, thanks. Bug report: The file contents should be interpreted as UTF-8 encoding. Apparently it's not: the output I see at that URL today is (in part): = Fetching these files for inclusion in a Debian source package is automated in the Debian package with 'debian/rules get-orig-source', as per Policy 3.8.0 Ã�§4.9 = whereas the actual contents of the file should be parsed as: = Fetching these files for inclusion in a Debian source package is automated in the Debian package with 'debian/rules get-orig-source', as per Policy 3.8.0 §4.9. = -- \ “A cynic is a man who knows the price of everything and the | `\ value of nothing.” —Oscar Wilde | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about watch-file
Ben Finney <[EMAIL PROTECTED]> writes: > Bug report: The file contents should be interpreted as UTF-8 encoding. > Apparently it's not: the output I see at that URL today is (in part): > > = > Fetching these files for inclusion in a Debian source package is > automated in the Debian package with 'debian/rules get-orig-source', > as per Policy 3.8.0 Ã�§4.9 > = Possibly related: The link provided to view the watch file http://dehs.alioth.debian.org/wwiz_detail.php?id=11448238&type=watch> leads to content served as UTF-8 but apparently not interpreting its source correctly: = # # Fetching these files for inclusion in a Debian source package is # automated in the Debian package with 'debian/rules get-orig-source', # as per Policy 3.8.0 §4.9. = The package's watch file is encoded as UTF-8, so apparently something is getting the encoding wrong somewhere along the line to producing the codument at that URL. -- \ “I went to a restaurant that serves ‘breakfast at any time’. So | `\I ordered French Toast during the Renaissance.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about watch-file
Raphael Geissert <[EMAIL PROTECTED]> writes: > Ben Finney wrote: > > > > Bug report: The file contents should be interpreted as UTF-8 > > encoding. > > Fixed. htmlentities() was messing the special characters instead of > making them display properly. An improvement, but now it shows the same (wrong) output as described here: Ben Finney <[EMAIL PROTECTED]> writes: > Possibly related: The link provided to view the watch file > http://dehs.alioth.debian.org/wwiz_detail.php?id=11448238&type=watch> > leads to content served as UTF-8 but apparently not interpreting its > source correctly: > > = > # > # Fetching these files for inclusion in a Debian source package is > # automated in the Debian package with 'debian/rules get-orig-source', > # as per Policy 3.8.0 §4.9. > = > > The package's watch file is encoded as UTF-8, so apparently something > is getting the encoding wrong somewhere along the line to producing > the [document] at that URL. -- \“Consider the daffodil. And while you're doing that, I'll be | `\ over here, looking through your stuff.” —Jack Handey | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about watch-file
Raphael Geissert <[EMAIL PROTECTED]> writes: > Yeah, that's another known issue. DEHS currently treats all its > input data as ISO-8859-1 and converts it into UTF-8 without first > checking if the input is already UTF-8. Since there's no way to deduce the encoding of a byte stream for certain, and the heuristics are both complicated and prone to false positives, it would be better not to "check" the encoding of a text file in the absence of an explicit declaration of its encoding. Better would be to assume the input is UTF-8, and encourage all authors of such files to encode them using Debian's de facto (and, in increasingly many areas, de jure) standard of UTF-8. > Will try to fix it next time I dig on DEHS' code. Appreciated. -- \“Some people, when confronted with a problem, think 'I know, | `\ I'll use regular expressions'. Now they have two problems.” | _o__) —Jamie Zawinski, in alt.religion.emacs | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I adopted a package but nobody seems to want to upload it
Serafeim Zanikolas <[EMAIL PROTECTED]> writes: > - the short description should start with a lower-case letter For more guidance on writing the package synopsis, see http://www.debian.org/doc/developers-reference/ch-best-pkging-practices#s-bpp-pkg-synopsis>. > - in debian/copyright after "this package was debianized by > [...]", add "and is currently maintained by " Even better, write the 'debian/copyright' file in accordance with http://wiki.debian.org/Proposals/CopyrightFormat> to make it machine-parseable. It's not official but it's still a good idea. > ps. these are pretty basic mistakes; consider at least skimming > through the cited docs Seconded. -- \ “Compulsory unification of opinion achieves only the unanimity | `\of the graveyard.” —Justice Roberts in 319 U.S. 624 (1943) | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A few Questions: Creating an arch indep pkg.
Brian <[EMAIL PROTECTED]> writes: […] Brian, the questions you asked are best asked on [EMAIL PROTECTED] I'll follow up with some answers there. -- \ “People's Front To Reunite Gondwanaland: Stop the Laurasian | `\ Separatist Movement!” —wiredog, http://kuro5hin.org/ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A few Questions: Creating an arch indep pkg.
Brian <[EMAIL PROTECTED]> writes: > Q1) > What's the difference between Build-Depends-Indep and Build-Depends? Please read the Debian Policy. These fields are described there, especially in §7.7, "Relationships between source and binary packages - `Build-Depends', `Build-Depends-Indep', `Build-Conflicts', `Build-Conflicts-Indep'". > Q2) > What should my debian/rules .PHONY line look like? > > I guess it to be?? > .PHONY: build clean binary-indep binary install I don't try maintaining the .PHONY rule on a separate line. I append to the .PHONY rule immediately before each phony target, so that it's clear at each target whether it's part of the .PHONY rule or not. = .PHONY: install install: # foo .PHONY: build build: # bar = This way, the .PHONY rule is built up to contain all the right targets, and it's easier to maintain as the targets themselves change (I'm much less likely to miss the requirement to change .PHONY when a target changes). Every target which is not intended to result in a file of the same name should be appended this way to the .PHONY rule. > Q3) > Are there any well built packages that are similar? So I can copy > their templates? The 'dh-make' package installs a tool intended to give you a good starting point for making a Debian package of an existing source tree. Install that, and refer to its documentation. You should become thoroughly familiar with the Developer's Reference. It's available in the 'developers-reference' package, and is one of many good documents available from http://www.debian.org/doc/>. -- \ “Marriage is a wonderful institution, but who would want to | `\ live in an institution.” —Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dict-foldoc (adopted package)
Iustin Pop <[EMAIL PROTECTED]> writes: > dict-foldoc - FOLDOC Dictionary Database No need to Capitalise Ordinary Words in the Package Synopsis. A better synopsis would be: FOLDOC dictionary database -- \ “‘Did you sleep well?’ ‘No, I made a couple of mistakes.’” | `\—Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I adopted a package but nobody seems to want to upload it
Holger Levsen <[EMAIL PROTECTED]> writes: > I'm not impressed: I checked the version in etch. Impressive. -- \ “Pinky, are you pondering what I'm pondering?” “Well, I think | `\ so, Brain, but it's a miracle that this one grew back.” —_Pinky | _o__) and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: quick-lounge-applet (updated package)
Diego Fernández Durán <[EMAIL PROTECTED]> writes: > quick-lounge-applet - GNOME 2 Panel Applet to organize your preferred > applications GNOME 1 will not be in lenny, and GNOME 3 doesn't exist. No need to specify version 2. No need to Capitalise Normal Words in Package Synopsis. Is "panel applet" a proper noun? No need to speak about "you" to the user. A better synopsis would be: GNOME panel applet to organise preferred applications -- \ “Patience, n. A minor form of despair, disguised as a virtue.” | `\ —Ambrose Bierce, _The Devil's Dictionary_, 1906 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package extraction process (dpkg-source, format 1.0 and 3.0 (quilt))
George Danchev <[EMAIL PROTECTED]> writes: > Now, you have two kinds of diff.gz - hooligan ones which directly > modify upstream files when applied as one fat, monolitic and > illogical changeset, and such that create logically separated diffs > in debian/patches/ which are then applied build time. I'd like to point out that George is making a severe value judgement here. The "fat, monolithic, and illogical changeset" is what I would describe more neutrally as "plain monolithic diff directly against the source tree". No need to use emotive words like "hooligan" or "illogical", since those imply an unwarranted value judgement and have no necessary connection to the plain direct-diff style. -- \ “I wish I had a dollar for every time I spent a dollar, because | `\ then, yahoo!, I'd have all my money back.” —Jack Handey | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dgtdrv
"W. van den Akker" <[EMAIL PROTECTED]> writes: > dgtdrv - Posix driver for the DGT chess board POSIX is usually treated as an initialism, so should be spelled in all-capitals. A better synopsis would be: POSIX driver for the DGT chess board Could you please send another RFS with the full package description included? The synopsis doesn't make it clear to me what the package is or does. -- \ “I bought some powdered water, but I don't know what to add.” | `\—Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libdgtnix
"W. van den Akker" <[EMAIL PROTECTED]> writes:
> libdgtnix-1-9 - Libraries for using DGT chess board
> libdgtnix-dev - Development libraries dgtnix POSIX driver DGT chess board
The package synopsis should be treated as a clause within a sentence,
and should not be capitalised like the beginning of a sentence. It
should make sense when inserted into this template:
is {a,an,the}
The second doesn't seem to make grammatical sense.
Suggested improvements:
libraries for using DGT chess board
development libraries for using DGT chess board
--
\“Madness is rare in individuals, but in groups, parties, |
`\nations and ages it is the rule.” —Friedrich Nietzsche |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
