Re: Debian Games Team
On 13-Jan-2006, Miriam Ruiz wrote: > --- Eddy Petriºor <[EMAIL PROTECTED]> escribió: > > Can ome packaging can be done for non-free games? > > To be honest, I'm not particulary interested in non-free software at > all, including games, but I have nothing against it if we decide as > a group to do so. In my oppinion there's so much work to do about > free games that I don't think it's a good idea giving away our time > to non-free projects. Seconded. This Debian user would be much better pleased by Debian's efforts going to improving the packaging and coordination of free software games. -- \"I took it easy today. I just pretty much layed around in my | `\ underwear all day. ... Got kicked out of quite a few places, | _o__) though." -- Bug-Eyed Earl, _Red Meat_ | Ben Finney <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: cogito_0.10-1 available
On 09-May-2005, Sebastian Kuzminsky wrote: > Peter Samuelson <[EMAIL PROTECTED]> wrote: > ] [Sebastian Kuzminsky] > ] > the shell libraries are moved to /usr/lib/cogito. > ] Correct, except that it should be /usr/share/cogito/. > > The FHS describes /usr/share as "architecture-independent data", and > gives examples like sound files and icons; this conflicts with > executable code in my mind. It could be better described, yes. My understanding of /usr/share as "architecture-independent" (and read-only, as the description continues) is that /usr/share/can potentially be mounted read-only for multiple machines of different architectures. -- \ "The basic fact about human existence is not that it is a | `\ tragedy, but that it is a bore." -- Henry L. Mencken | _o__) | Ben Finney <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: namespace conflict != package Conflict?
On 09-Jun-2005, Sebastian Kuzminsky wrote: > The cogito /usr/bin/git is a tiny little helper script hardly worth > its inode, but it's in the upstream package and I dont want to > remove it or rename it. Care to expand on why you don't wish to rename or remove the conflicting Cogito file? It may help those trying to form a solution. -- \ "I busted a mirror and got seven years bad luck, but my lawyer | `\ thinks he can get me five." -- Steven Wright | _o__) | Ben Finney <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Code of Conduct on the Debian mailinglists
Wouter Verhelst <[EMAIL PROTECTED]> writes: > You know, I use a mail program. Replying to people is in my fingers > as "hitting a button". A very specific button, especially for that > purpose. I expect my MUA to Do The Right Thing (TM). Most MUAs will do the right thing when you reply; they'll send a message to the single person who wrote the message. The person who wrote the message can indicate where this single-person reply should go, by specifying header fields such as 'From' and 'Reply-To'. Many MUAs also have a separate specific facility, for replying to *every* address related to the discussion. This is fine for a group of individuals, but problematic for a mailing list, since one of those addresses will be the mailing list address itself, and then some people get two copies -- one individually (which usually arrives first, since it has less processing time) and one from the mailing list. With mailing lists, there's a third kind of reply needed, a "followup" to continue the discussion. This usually should be sent to the mailing list address, and to people not on the mailing list but who want to receive followup responses. We can't use the mailing list address for this: that misses anyone who's not subscribed but wants followup messages. We can't use the Reply-To field in an existing message: that is specifically for *individual* responses to the person posting the message. This is completely wrong for followup messages intended for all interested parties. There *is* no header field recommended by the IETF that meets this need. We use Mail-Followup-To because it actually meets the need described above. -- \ "My interest is in the future, as I am going to spend the rest | `\ of my life there." -- Charles F. Kettering | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg doing wrong math (0.09 = 0.9) ?-
Michael Biebl <[EMAIL PROTECTED]> writes: > I have to admit that when choosing 0.09+0.1 as version number I > didn't check with dpkg --compare-versions because then I would have > discovered that "dpkg --compare-versions '0.09' '=' '0.9'" yields > true, which I think is rather odd, because it means that now all > version numbers up to 0.9 will be considered < 0.09+0.1. Which is correct. Version strings can consist of (among other things) any number of '.'-separated integers in sequence. Leading zeros on the individual integers are not significant. The full description of how values of the Version field are compared is in Policy: 5.6.12 Version [...] The strings are compared from left to right. First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters. Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero. These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a difference is found or both strings are exhausted. http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version> -- \ "I love to go down to the schoolyard and watch all the little | `\ children jump up and down and run around yelling and screaming. | _o__) They don't know I'm only using blanks." -- Emo Philips | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg doing wrong math (0.09 = 0.9) ?-
"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes: > On Fri, Aug 11, 2006 at 02:21:04AM +0200, Adeodato Simó wrote: > > * Roberto C. Sanchez [Thu, 10 Aug 2006 19:47:36 -0400]: > > > > > Except that the final comparison ignores that the number was to > > > the right of the decimal, making the zero significant. > > > > Er, read Policy 5.6.12. > > > I have read it. I was simply speaking from a mathematical perspective. It's still right from a mathematical perspective. The integers within two version numbers are compared in sequence. Leading zeros are insignificant for integers. A '.' character doesn't mean "decimal point" in a version number; Policy 5.6.12 explains what it does mean. -- \"If it ain't bust don't fix it is a very sound principle and | `\ remains so despite the fact that I have slavishly ignored it | _o__) all my life." -- Douglas Adams | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg doing wrong math (0.09 = 0.9) ?-
Florian Weimer <[EMAIL PROTECTED]> writes: > "." is not special as far as version numbers are concerned. It's not > a separator, for instance, and "1." is a valid version number (which > is equal to "1.0"). That doesn't match my reading of Policy 5.6.12: The strings are compared from left to right. First the initial part of each string consisting entirely of non-digit characters is determined. These two parts (one of which may be empty) are compared lexically. If a difference is found it is returned. The lexical comparison is a comparison of ASCII values modified so that all the letters sort earlier than all the non-letters. Then the initial part of the remainder of each string which consists entirely of digit characters is determined. The numerical values of these two parts are compared, and any difference found is returned as the result of the comparison. For these purposes an empty string (which can only occur at the end of one or both version strings being compared) counts as zero. These two steps (comparing and removing initial non-digit strings and initial digit strings) are repeated until a difference is found or both strings are exhausted. So any '.' between digits would be a "part of [the] string consisting entirely of non-digit characters", and is compared lexically by ASCII values; following which is a "part of the remainder of [the] string which consists entirely of digit characters", and is compared numerically; and we repeat these steps until the string is exhausted. That sure sounds like a lone '.' between digit-sequences would be a separator for those digit-sequences. -- \ "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: dpkg doing wrong math (0.09 = 0.9) ?-
"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes: > Except that the final comparison ignores that the number was to the > right of the decimal, making the zero significant. A '.' character in a version string isn't a decimal point. The prevalence of versions strings containing more than one '.' character should make this abundantly clear. -- \"The right to search for truth implies also a duty; one must | `\ not conceal any part of what one has recognized to be true." | _o__) -- Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thanks for the work
David Barker <[EMAIL PROTECTED]> writes: > I'm writing this mail to you the developers to say thanks for the work > you put into Debian. I am really impressed at how polished etch as a > desktop OS is. Thanks for taking the time to write and post this. It's refreshing to know that problems are not the only thing that can motivate a message to the developers :-) -- \ "God forbid that any book should be banned. The practice is as | `\ indefensible as infanticide." -- Dame Rebecca West | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.1 [gfdl] documentation packages for non-free
"Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes: > I'm one of those people beaten by recent removal of gcc > documentation. Both myself and people to whom I recommend Debian, > *need* gcc documentation to be available in the system. The FSF agree with your position. http://www.fsf.org/licensing/essays/free-doc.html> > So I had four options: > - start a new flamewar on the issue, > - stop to use Debian (and to recomment it), > - install documentation in non-package form, > - create appropriate documentation debs (for non-free). Your situation is the same as any DD who finds the software they want to package is licensed incompatibly with the DFSG. You can ask politely but firmly for the software to be licensed so that Debian can include it. > Since I'm a DD, the only real option for me was the last one. Fortunately, packaging the documentation for non-free isn't incompatible with continuing to ask the copyright holder for a free license. > I've created gcc-4.1-doc-non-dfsg package, intended for non-free. Thank you for your work! -- \"Computers are useless. They can only give you answers." -- | `\ Pablo Picasso | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Media players in Debian
"César Martínez Izquierdo" <[EMAIL PROTECTED]> writes: > First of all, I don't have time to send bug reports for all the bugs I > find (although I send most of them, when I have to choose I send to > packages which I usually use). > Specially, when I want to see a film, I really want to see the film at > that moment, not after sending some bug reports. That's entirely your choice of course. No-one here can tell you what to do with your time. However, if you experience the bug, and don't ensure that the bug tracker has a record of that bug, then you can't expect anyone to fix it. -- \ "Time's fun when you're having flies." -- Kermit the Frog | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XS-X-Vcs-XXX field not (yet) announced
Joey Hess <[EMAIL PROTECTED]> writes: > Stefano Zacchiroli wrote: > > Thanks, my preference is now for XS-Vcs-* > > While the name is still in flux, could I suggest XS-Repo-*? > > I tend to get VCS and RCS confused :-) On the other hand, "repo" is ambiguous and doesn't necessarily suggest "repository of a version control system"; it could be a repository of *anything* related to the project. I'm -1 on "repo", +1 on "vcs". (And those are worth dog biscuits because IANADD :-) -- \ "People demand freedom of speech to make up for the freedom of | `\thought which they avoid." -- Soren Aabye Kierkegaard | _o__) (1813-1855) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free artwork in main
Josselin Mouette <[EMAIL PROTECTED]> writes: > Beware not to be confused between licensing issues and trademark > ones. I think perhaps you mean "confused between copyright licensing issues and trademark licensing ones". Both copyright and trademarks reserve rights to the holder, who can then grant license to those rights. -- \"I have one rule to live by: Don't make it worse." -- Hazel | `\ Woodcock | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Free flash player for your browser
Jonas Meurer <[EMAIL PROTECTED]> writes: > On 26/09/2006 Petter Reinholdtsen wrote: > > That would be a bug in your X server. X servers should not crash > > no matter the client. :) > > ... my X server crashed a second time, this time at an artist at > myspace.com, which automaticly starts a flash music player. Excellent. You're getting more of an understanding of how to reproduce this bug in your X server. I hope that soon you can submit a bug report against the X server with a test case. -- \ "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: Entering parameters at the boot prompt
Mike Hommey <[EMAIL PROTECTED]> writes: > Well, users seeing q when typing a wouldn't continue typing anyway... Unless they're one of the great many users who look at the keyboard, rather than the monitor, while they type. -- \ "I am an optimist. It does not seem too much use being anything | `\ else." -- Winston Churchill | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Free flash player for your browser
Jonas Meurer <[EMAIL PROTECTED]> writes: > On 28/09/2006 Ben Finney wrote: > > Excellent. You're getting more of an understanding of how to > > reproduce this bug in your X server. I hope that soon you can > > submit a bug report against the X server with a test case. > > i'm not able to reproduce the bug at the moment. When you do, the 'reportbug' tool (which you can install via aptitude if you don't already have it) will make it easy to report a bug to the Debian bug tracking system. -- \ "Any sufficiently advanced bug is indistinguishable from a | `\ feature." -- Rich Kulawiec | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-findremovable v0.1 (initial release)
Michelle Konzack <[EMAIL PROTECTED]> writes: > Am 2006-10-04 18:08:50, schrieb Alexey Feldgendler: > > > Why not just stop using apt-get? aptitude can do everything the > > same as apt-get and even supports the same command line > > parameters. > > And HOW do you install/remove packages if the TUI from aptitude > crashs? I do not know how aptitude is working and whether it use > ncurses or slang but it segfaults all the time on two of my servers > and kill the ssh session. I'm guessing from what you say here that you are unaware that aptitude will not present a full-screen interface (neither ncurses nor slang) if you give it any explicit command: $ aptitude update $ aptitude search bubble $ aptitude show morse $ aptitude install cowsay $ aptitude --help In this, it is a replacement for apt-get. -- \"The number of UNIX installations has grown to 10, with more | `\ expected." -- Unix Programmer's Manual, 2nd Ed., 12-Jun-1972 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for "GR: : Handling source-less firmware in the Linux kernel"
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Sven Luther <[EMAIL PROTECTED]> writes: > > > So, given this poorly worded ballot, i suppose the vote will be > > void anyway, and i strongly call for everyone to vote further > > discussion over the other solutions. > > If people do not READ THE RESOLUTION, then they get what they > deserve. In a vote, those who do not read the resolution affect others who do. This is one of the benefits of a discussion period -- the opportunity to ensure people understand the resolution before voting. -- \ "Saying that Java is nice because it works on all OSes is like | `\saying that anal sex is nice because it works on all genders" | _o__) -- http://bash.org/ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for "GR: : Handling source-less firmware in the Linux kernel"
Ben Finney <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > If people do not READ THE RESOLUTION, then they get what they > > deserve. > > In a vote, those who do not read the resolution affect others who > do. This is one of the benefits of a discussion period -- the > opportunity to ensure people understand the resolution before voting. s/people/more people/ -- \ "Democracy is the art of running the circus from the monkey | `\ cage." -- Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Will IceWeasel be based on a fork or on vanilla FireFox?
"Sam Morris" <[EMAIL PROTECTED]> writes: > It is unfortunate because of the user confusion that it will > cause. IMO, the firefox package should not be renamed to iceweasel. If it's not renamed, we can't legally ship it. What, IYO, should be done to ship the existing program currently known as Firefox? > The package 'iceweasel' should be a package of the Gnuzilla project > of the same name. I think there will be a serious attempt at collaborating with the Gnuzilla folks to try to resolve this confusion. Meanwhile, we're trying to get the existing Firefox into Debian as free software. -- \ "What you have become is the price you paid to get what you | `\ used to want." -- Mignon McLaughlin | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Will IceWeasel be based on a fork or on vanilla FireFox?
Ben Finney <[EMAIL PROTECTED]> writes: > "Sam Morris" <[EMAIL PROTECTED]> writes: > > > It is unfortunate because of the user confusion that it will > > cause. IMO, the firefox package should not be renamed to > > iceweasel. > > If it's not renamed, we can't legally ship it. ... "we can't ship it as free software", I should have said. -- \"Imagine a world without hypothetical situations." -- Anonymous | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding maintainer email
Bill Allombert <[EMAIL PROTECTED]> writes: > Something I have yet to understand is what purposes the bounce [from > a moderated list] serve in the first place. Moderating is OK, but > bouncing ? I read many mailing lists (this one, for example) without being subscribed as a member. An automated message saying "Your post to the list, unlike many others, will be delayed until a human acts" tells me that I shouldn't get anxious at the non-appearance of my message on the list. Without such a message, many people would believe their message was eaten somewhere, and post it again and again. -- \ "Money is always to be found when men are to be sent to the | `\ frontiers to be destroyed: when the object is to preserve them, | _o__) it is no longer so." -- Voltaire, _Dictionnaire Philosophique_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thanks!
Eike Nicklas <[EMAIL PROTECTED]> writes: > I'm not sure where to post this email, so I am sending it to this > list. It is totally unproductive, but still I'd like to send it :-) Some businesses have a little sign that says: "If you don't like our service, please tell us; if you do like our service, please tell others!" It's great to give positive feedback, and even better that you've done so in public. I'd call it morale-boosting, certainly not unproductive. -- \ "Sunday School: A prison in which children do penance for the | `\ evil conscience of their parents." -- Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Etch
Thomas Fischer <[EMAIL PROTECTED]> writes: > this mail should only be something to encourage you to develop etch > in the beginner-friendly way as it is today. thank you therefore! Thanks for giving comments on your experience with Debian. > I don't like: - no easy overview in the console for example: if > there are many files in apt there should be something like a "list" > in alphabetical order You may not be aware of the 'aptitude' console-mode tool, installed by default on Debian etch. As well as providing complete operation from the command line, it also features an interactive full-terminal interface with a browser for packages, one per line. http://aptitude.sourceforge.net/> http://packages.debian.org/aptitude> -- \ "Our products just aren't engineered for security." -- Brian | `\ Valentine, senior vice-president of Microsoft Windows | _o__) development | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BTS: Why no "invalid" or "notabug" tag?
Russ Allbery <[EMAIL PROTECTED]> writes: > Manoj Srivastava <[EMAIL PROTECTED]> writes: > > > Out of curiousity, what _did_ you expect the blocking tag to do? > > If there is an obvious answer to that, I can see why not having > > that behaviour would be a surprise. > > The one thing that I really wanted to have happen and was surprised > didn't happen was that I wanted a blocking annotation be > automatically removed when the blocking bug was closed. (Or even > better, made dormant so that if the other bug would reopen, the > annotation would reappear.) I would find this more sensible: - Ben Finney asks BTS to mark bug 123 as blocking bug 789. - BTS updates bug 123 and bug 789 correspondingly - Russ Allberry asks the BTS to mark bug 789 as resolved. - BTS rejects the change, saying that bug 789 can't be resolved until bug 123 is resolved - Russ Allberry sees in the bug list that bug 789 is blocked. - Russ Allberry asks Ben Finney what to do about the block. - Ben Finney gives a patch to Manoj Srivastava to fix bug 123. - Manoj Srivastava asks BTS to close bug 123. - BTS updates bug 123 and 789 correspondingly - Russ Allberry sees in the bug list that bug 789 is not blocked. - Russ Allberry asks the BTS to mark bug 789 as resolved. - BTS updates bug 789 In other words, the block affects the possible work flows for the bugs involved -- if bug 789 is blocked by 123, that's an indicator that bug 789 can't be resolved until the block is cleared, so the BTS should enforce that. The data about the block reflects something the real-world developers should know about the bug, and when that real-world information changes, the bug record need to be updated to reflect that. -- \ "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: Bug is very vague, should I close it?
Jose Luis Rivas Contreras <[EMAIL PROTECTED]> writes: > >Package: rtorrent > >Version: 0.4.1-1a0.mrvn.1 > >Severity: wishlist > > > >Hi, > > > >I would like to see some features like DHT in rtorrent to make it > >more competitive with other clients. For an overview see > >[...] > > This bug probably will never be solved until rtorrent get all > features of all torrent clients... > > So, should I close this bug? There's a lot of bugs requesting > specific features[1] so I don't think this bug it's necessary. You could enlist the bug submitter's help. Ask them to retitle the bug and be more specific about a particular feature, or to close it and submit separate wishlist bugs for each feature they want. -- \ "If we don't believe in freedom of expression for people we | `\ despise, we don't believe in it at all." -- Noam Chomsky | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug is very vague, should I close it?
Jose Luis Rivas Contreras <[EMAIL PROTECTED]> writes: > Ben Finney escribió: > > Jose Luis Rivas Contreras <[EMAIL PROTECTED]> writes: > [...] > >> > >> So, should I close this bug? There's a lot of bugs requesting > >> specific features[1] so I don't think this bug it's necessary. > > > > You could enlist the bug submitter's help. Ask them to retitle the > > bug and be more specific about a particular feature, or to close > > it and submit separate wishlist bugs for each feature they want. > > > So I will close the bug since all the features are already requested > in another wishlist bugs. That's the opposite of what I was suggesting. It's your privilege (as the package maintainer) to do so if you wish, of course. -- \"There was a point to this story, but it has temporarily | `\ escaped the chronicler's mind." -- Douglas Adams | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] list of valid documents for KSPs
Wouter Verhelst <[EMAIL PROTECTED]> writes: > Yes, you should bring a government-issued ID, and no, having an ID > card that is not trustable should not be considered acceptable. This thread has already established that many governments have untrustable ID issuing procedures. If the definition of acceptable ID is "must be government-issued AND be trustable", that leaves citizens of many countries unable to meet those criteria. -- \ "It is well to remember that the entire universe, with one | `\ trifling exception, is composed of others." -- John Andrew | _o__) Holmes | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Andreas Tille <[EMAIL PROTECTED]> writes: > IMHO there is a need for putting patches against upstream source > into a defeult place. Agreed. This place is provided by a VCS, especially one with good merging algorithms. We are blessed with an ever-improving wealth of such VCS software, with superlative merging support. in recent times. That way, the "patches against upstream source" are revisions in your debian packaging branch for the source. > The rationale behind this is that if you are using VCS for your > packaging to enable effective group maintainance it makes no sense > to store a complete tarball but just the patches. I see no rationale for this assertion. Why does it "make no sense" to keep the source tree in VCS to track changes to it? > For instance in the Debian-Med project > >http://svn.debian.org/wsvn/debian-med/trunk/packages/ > > we agreed to store only the debian directory into SVN and have a > get-orig-source target in the debian/rules file. Subversion is not a VCS with good merging support. That should be fixed first before declaring it to "make no sense" to track source changes in a VCS. NB: IANADD. -- \ "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]
Re: How to cope with patches sanely
Andreas Tille <[EMAIL PROTECTED]> writes: > Call me old fashioned but I want to see a set of files if I do > > apt-get source XY > > and want to see the patches to the original tarball. That's not "old-fashioned", because that's never been what 'apt-get source foo' is meant to do. "old-fashioned" (and, IMAO, "sensible") is for the above command to get the complete already-patched source, ready to build and/or examine as a Debian package. > I could browse the diff but haveing all patches collected (and > commented THERE) is in my eyes the easiest way to see what the > maintainer has done. "easiest" only if everyone uses exactly the patch-management scheme you're accustomed to. Currently, as JoeyH points out, the only one that's currently expected for Debian is a single diff against the orig.tar.gz. -- \ "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: How to cope with patches sanely
Andreas Tille <[EMAIL PROTECTED]> writes: > On Fri, 25 Jan 2008, Joey Hess wrote: > > > The competing vcs situation has its problems, but no matter what > > vcs is used for a package, you can check out the source to the > > package using apt-get source. This allows examination and > > modification of the source to any package, without needing to know > > the vcs. > > I agree here, but if I understood Ben Finney in > >http://lists.debian.org/debian-devel/2008/01/msg00912.html > > right, others do not. I also agree with JoeyH's point above (again, as I understand it). It seems to me that you can only agree with the position that "you can check out the source to the package using 'apt-get source'. This allows examination and midification of the source to any package" if "the source to the package" is agreed upon. I believe JoeyH defines "the source to the package" as being the exact source that is then built to become the binary package; *not* an intermediate form that must be patched again before it is ready to build. It is that former position that I agree with, and that 'dpatch' et al are obstacles to. > So your main issue is that patches belong into the code not into a > separate directory (in whatever form). Rather (again, my understanding of JoeyH's position) that the source package (i.e. that which is unpacked and presented by 'apt-get source foo') can be examined in the knowledge that it is exactly the source form that will be built, with no further patching operations required. > I for myself would refuse to learn different vcs but if there is a > chance for a common wrapper - I might consider changing my working > preferences. Sure. This is analogous to "I don't care what tool the package maintainer uses to manipulate their patches, so long as I can be completely ignorant of that tool and just 'apt-get source foo' to see the already-patched source". -- \ "I object to doing things that computers can do." —Olin | `\ Shivers | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Russ Allbery <[EMAIL PROTECTED]> writes: > Lars Wirzenius <[EMAIL PROTECTED]> writes: > > > In other words: dpkg-source must unpack sources that can be > > directly edited and then dpkg-buildpackage will build a new, > > modified package that can be uploaded. > > [...] > > This work flow simply doesn't work with our current source package > format and a patch management system. Requiring this to work *with > the current source package format* essentially means outlawing using > patch management systems to manage Debian packages. That's why this > proposal is controversial. Yes. However, I entirely agree with Lars's proposed requirement that the described workflow should work on every Debian source package. So, either an improved source package format is contrived (and implemented, and tested, and adopted, and becomes reliable) to allow the above workflow with (some subset of) patch management schemes, or people should use VCSen instead of patch management schemes. IANADD. -- \"Pinky, are you pondering what I'm pondering?" "Wuh, I think | `\ so, Brain, but will they let the Cranberry Dutchess stay in the | _o__) Lincoln Bedroom?" -- _Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The 30 most popular packages missing in Debian
Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > [Sebastian Pipping] > > * Would non-free be an option to all or some of them? > > Do we have binary only packages in Debian? > > Yes. The issue is more that very few package maintainers in Debian > want to maintain non-free packages. And that's as it should be. Non-free software is a dead end, and few developers want to put in ongoing effort for something that is a dead end. If the software vendor doesn't care to maintain the software in the community of its users, and that community can't care enough to put in the ongoing effort to make and maintain a Debian package, I don't see why one would say it's a bad thing for that software to lack a Debian package. -- \ "Pinky, are you pondering what I'm pondering?" "I think so, but | `\ where will we find an open tattoo parlor at this time of | _o__) night?" -- _Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Specifying where to follow-up (was: List of packages shipping shell scripts with bashisms + MBF proposal)
Steffen Grunewald <[EMAIL PROTECTED]> writes:
> On Tue, Jan 29, 2008 at 07:58:05PM -0600, Raphael Geissert wrote:
> >
> > [Please only reply to -devel]
>
> Reply-To?
That's a field defined (in RFC 2822) as specifying where posts
intended individually to the author ("replies") should be sent. It
would not be good to have such replies sent instead to a public
mailing list.
I suspect Raphael instead wants to specify that public follow-up posts
(not individual replies) should go to debian-devel. The
Mail-Followup-To field is often used for this, but is not a standard
nor widely implemented.
--
\ "Sunday School: A prison in which children do penance for the |
`\ evil conscience of their parents." -- Henry L. Mencken |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changing the default syslog daemon for lenny?
Michael Biebl <[EMAIL PROTECTED]> writes: > Ok, here we go... > > [investigation and analysis of dependencies on 'sysklogd'] Good work, thankyou. > Should, I file a lenny release goal first and wait for it's > approval, or can I take this thread as consensus that I can pursue > changing the default system-log-daemon to rsyslog? It doesn't need to be a release goal to proceed with the work. File the release goal if you like, but I'd say go ahead with the change whether the release goal is accepted or not. -- \ "bash awk grep perl sed, df du, du-du du-du, vi troff su fsck | `\ rm * halt LART LART LART!" —The Swedish BOFH, | _o__) alt.sysadmin.recovery | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The 30 most popular packages missing in Debian
Franklin PIAT <[EMAIL PROTECTED]> writes: > Also It's important that we can tell our users "Debian 4.0, as of > 2008-01-31 has flashplugin-nonfree version X.Y, skype version Z.Y" That will never be true as long as those works are non-free. Debian has no non-free software (and if it does, that's a bug to be corrected). Some non-free works are distributed via Debian's infrastructure, but it's very important to *not* have "Debian includes non-free work $FOO" be true, because that's against the entire point of Debian. > and provide all the QA associated (BTS, security tracking...). For most non-free software, we *can't* provide all the QA associated with Debian. For most of them we are prohibited from redistribution of modified versions, so security updates cannot be provided the same way as software that is part of Debian; we have to wait for updates from the original vendor. -- \ "For fast acting relief, try slowing down." —Jane Wagner, | `\ via Lily Tomlin | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
sean finney <[EMAIL PROTECTED]> writes: > is there any reason why this issue couldn't be solved by amending > policy (or just simply patching dpkg-source) to require that > "debian/rules patch" (or some less commonly used name if we're > worried about existing implementations of this rule) is called as > part of the unpacking process or a source package? just a thought... One good reason I can think of is that you're then running unknown code as part of unpacking the source. It's no security risk to unpack a tarball, apply a patch to it via GNU 'patch', and examine the result. (I don't even have to trust debhelper for that, since it's not part of unpacking the source.) I'm *not* happy to need to run some target with arbitrary commands in the 'debian/rules' file, just to allow me to examine the source. A big part of the reason for unpacking the source could be to find out what's in there *before* executing any part of it. -- \ "[T]he speed of response of the internet will re-introduce us | `\to that from which our political systems have separated us for | _o__)so long, the consequences of our own actions." —Douglas Adams | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Charles Plessy <[EMAIL PROTECTED]> writes: > But I am still missing something: how can we get the benefits of > using a patching strategy, that is to break up changes into logical > components, with the VCS strategy? Make commits to the VCS branch for the package, at the same level of granularity (or finer) as you would write individual patches. Be sure to describe the commit with a good message, just as you would comment a patch file. With any decent modern VCS, each individual commit can be inspected at any later date, including generating a patch against another arbitrary revision. Indeed, this is how I generate most patches for submitting via email: make the change to a working tree in a VCS branch, then invoke the VCS to generate a diff against the upstream revision (even if I was the one who committed that upstream revision myself). Thus, you get a record of every granular change from a given state, automatically sequenced in the right order. You also get to roll up the entire set into a .diff.gz against the original upstream source, for creating the Debian source package. There are in fact tools in Debian that know how to do this automatically for most popular DVCSen; look for packages called '$VCSNAME-buildpackage'. -- \"To me, boxing is like a ballet, except there's no music, no | `\ choreography, and the dancers hit each other." —Jack Handey | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Charles Plessy <[EMAIL PROTECTED]> writes: > - In the fist I propose that the 'patch' rule could only be provided > by snippets such as those of dpatch, quilt, and CDBS, so that there > is no security risk running this command. This doesn't do anything to prevent a non-policy-compliant source package providing arbitrary hostile commands (whether by accident or malice) in the 'patch' target. The correct way to avoid that is not to run anything from inside the source package until the user specifies to do that. Unpacking the source should *not* require (nor even default to) executing something from inside that source. -- \"I saw a sign: 'Rest Area 25 Miles'. That's pretty big. Some | `\ people must be really tired." —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Daniel Leidert <[EMAIL PROTECTED]> writes: > And people should check the VCS history just to get the current > "patch"? What is "the current patch"? If you mean the entire set of differences against the upstream source, I already addressed that: simply generate a diff between the branches containing upstream source versus debian-packaged source. As I pointed out, there are already tools that generate an entire Debian source package, including 'foo.orig.tar.gz' and 'foo.diff.gz', in a single step from a given VCS. Evidently what you ask for is possible, and already indeed implemented such that it is easy. If you mean something else by "the current patch", please explain further. -- \ "Experience is that marvelous thing that enables you to | `\ recognize a mistake when you make it again." —Franklin P. | _o__) Jones | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Raphael, please follow the Debian Mailing List code of conduct http://www.debian.org/MailingLists#codeofconduct>; in particular, don't send individual copies of list messages unless specifically requested. Raphael Hertzog <[EMAIL PROTECTED]> writes: > Imagine an history like this: > > - Change behaviour1 > - Change behaviour2 > - Bugfix in patch to change behaviour1 > - Bugfix in patch to change behaviour2 > > You have two logical patches and a dumb export from the VCS into > debian/patches/ would give 4 patches when you really want only two. In a VCS with good merging support (most DVCSes fit this description, Subversion does not), those "logical patches" can be maintained as "feature branches". Essentially, any set of changes that is more than "add this change and let it be absorbed into the stream of changes" merits branching the development tree to maintain that feature. Into that feature branch go any commits that are related logically to the feature; anything else goes into other branches. Any time you want to find how feature-branch-A differs from the development branch, that's a simple diff operation between the two branches (optionally specifying which revision of each you're interested in comparing). Merges between the two will show up as single revisions in each branch, so the changes in feature-branch-A will show exactly the history of feature A. Any time the changes in feature-branch-A are at a point where they need to be included in the main development branch, simply merge them in. The important thing that enables this workflow is *easy merging* between arbitrary branches that share a common ancestor. Again, this rules CVS and Subversion out. (Some, like git, allow merging *anywhere*, but that's not necessary for this to work well.) -- \ "I have had a perfectly wonderful evening, but this wasn't it." | `\ -- Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Raphael Hertzog <[EMAIL PROTECTED]> writes: > On Fri, 01 Feb 2008, Ben Finney wrote: > > Raphael, please follow the Debian Mailing List code of conduct > > http://www.debian.org/MailingLists#codeofconduct>; in > > particular, don't send individual copies of list messages unless > > specifically requested. > > If you were using mutt [...] I'm not. Please follow the code of conduct regardless. -- \ "For of those to whom much is given, much is required." -- | `\ John F. Kennedy | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package synopsis: appositive clause, not full sentence (was: Bug#463666: ITP: tomoe -- Tomoe - A handwriting recognition engine)
Christian Perrier <[EMAIL PROTECTED]> writes:
> Quoting NIIBE Yutaka ([EMAIL PROTECTED]):
> > Description :
>
> Apparently your proposed synopsis for the package is "-- Tomoe - A
> handwriting recognition engine". May I suggest a simpler and more
> "standard" one:
>
> handwriting recognition engine
Yes.
In general, all Debian packages should follow the Debian Developer's
Reference guide on package descriptions:
It's a good idea to think of the synopsis as an appositive clause,
not a full sentence. An appositive clause is defined in WordNet as
a grammatical relation between a word and a noun phrase that
follows, e.g., "Rudolph the red-nosed reindeer". The appositive
clause here is "red-nosed reindeer". Since the synopsis is a
clause, rather than a full sentence, we recommend that it neither
start with a capital nor end with a full stop (period). It should
also not begin with an article, either definite ("the") or
indefinite ("a" or "an").
http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-pkg-synopsis>
--
\ "For fast acting relief, try slowing down." —Jane Wagner, |
`\ via Lily Tomlin |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Daniel Leidert <[EMAIL PROTECTED]> writes: > What I mean is: Say you have addressed 5 different issues in the > code. I still think it is easier to understand, if 5 separate > patches are provided instead of one. And tracking each of them be > checking commits for the initial fix and changes done later to > update the fix is IMHO not as easy as simply providing a separate > patch. As long as you maintain the package alone, you probably do > not have advantages of using separate patches. But say e.g. a > co-maintainer offers help or you do collaborative maintenance in > general. Then I think, it is much easier to separate fixes into > logical patches. And IMHO this cannot be done by just using "good" > commit messages. All of these are likely reasons for a developer to choose a patch management system. My argument is that they are unconvincing to a developer who is *not* a primary developer of that package, who does not have familiarity with the specific patch management system you've chosen, yet who will need to understand it before making changes to the source code (e.g. in the case of an NMU). > > As I pointed out, there are already tools that generate an entire > > Debian source package, including 'foo.orig.tar.gz' and > > 'foo.diff.gz', in a single step from a given VCS. Evidently what > > you ask for is possible, and already indeed implemented such that > > it is easy. > > What I ask for is already possible and implemented: quilt and dpatch > exist. You were asking specifically to be educated on how this would be done with a VCS. > I read your answer to Raphael, where you point to so called "feature > branches". This leads to the question, if people should be forced to > use a special VCS (which is already discussed somewhere else in the > thread), whereas creating Debian packages never relayed on the usage > of a VCS. No, the only thing that a potential developer needs to know is the method for getting source from the VCS; from that point, they have exactly what I've been describing: the complete source, ready to edit and/or build. Even the need for executing a specific VCS command goes away with the 'Vcs-*' fields and 'debcheckout' becomes available. > To be honest, your workflow is different to mine. I would need to > examine your way and compare it to mine. All I can say is, that I'm > pretty satisfied with my workflow and I'm sure, you claim the same > for your solution. Yes, this was never about demanding that people's *workflow* change. You asked how a VCS-based approach allows change management, I was explaining based on my understanding of your requirements. The original discussion remains: about ameliorating the effect *on other developers* of the internal practices of developers on a given package. With a VCS-based change management approach, the impact is minimal to none: The prospective newcomer or one-time developer does not need to know anything about the tool, because the source package is already usable without it. With the patch management schemes you describe, that developer must learn an arbitrary patch management scheme before even beginning to look at the source. -- \ "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: How to cope with patches sanely
Matthew Johnson <[EMAIL PROTECTED]> writes: > I am against patch system users being forced to changed to a DVCS > system, however, which _has_ been suggested. I've not seen that suggested in this thread. Can you give a reference, please? What I've seen, that might be confused with the above, is: * arguments against patch systems on the basis of forcing others to use those specific tools; followed by requests; * arguments for DVCS workflows on the basis that they provide the advantages of tracking changes without forcing others to know the specific tool used; * requests from, and responses to, people wanting to know how a DVCS workflow can do this. -- \ "Everything you read in newspapers is absolutely true, except | `\for that rare story of which you happen to have first-hand | _o__) knowledge." —Erwin Knoll | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Matthew Johnson <[EMAIL PROTECTED]> writes: > Also: * The package format should be standardised such that the same > workflow works for everyone. Not necessarily the pacakge *format*. The request you seem to be referring to was that of Lars, when he requested that a specific sequence of operations should work for every source package. That's an issue of the *interface*, much more than the format. Currently, that request is fullfillable with either of "don't track changes, mix everything into foo.diff.gz" or "track changes in a VCS, use automated tools to build foo.diff.gz when building the source package". It is not met by patch bundle systems. > This implies to me that those who dislike patch systems and like > DVCS workflows wish to standardise on the latter. Not that I've seen, no. What I have seen is the argument that a VCS-based workflow doesn't impose the internal workings on the one-time source modification contributor the way that patch bundle workflows do. This has accordingly been held up as an advantage of VCS-based workflow, with which I agree. I've not seen it held up as an argument to force anyone to use a specific tool or workflow, and with that I would disagree. -- \ "Whatever you do will be insignificant, but it is very | `\important that you do it." —Mahatma Gandhi | _o__) | 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: How to cope with patches sanely
Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Thu, Feb 07, 2008 at 05:12:00AM +, Manoj Srivastava wrote: > > Why should I bring my feature branches into a patch system, when > > there is no need to? As far as the end user or NMUer is ocnerned, they > > do apt-get source foo, and they get the sources they may hack > > on. Adding to the chaos by converting my nice, clean source format to > > the blecherousness of a patch system does seem like regression to me. > > That's not really about "bring your feature branches" into a patch > system, but rather export them into something that looks like one so > that the security team or the NMUer can have a good outlook of the > modifications you apply to upstream. In the scenario Manoj presents above, the modifications applied to upstream are easily available all in one place: the foo.diff.gz. > It sounds like a fair thing to me. You can't decently ask the > security team to know every single $SCM out ther, and guess how > $random_developer use it (especially, sorry but it's true, when it's > a SCM as complicated as tla is). In the scenario Manoj presents above, no-one in the security team needs to know how to do anything but get the source package, since that gets the complete original source and a foo.diff.gz showing exactly what changes are applied. With 'debcheckout' even knowing what VCS is used will be unnecessary. Whereas with a patch bundle system, the security team needs to know *every* patch bundle system in use and how to use it, just to have a chance of operating on arbitrary Debian source packages. -- \ “It is far better to grasp the universe as it really is than to | `\ persist in delusion, however satisfying and reassuring.” | _o__) —Carl Sagan | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Binaries with the same name
Russ Allbery <[EMAIL PROTECTED]> writes: > David Paleino <[EMAIL PROTECTED]> writes: > > Frank Küster <[EMAIL PROTECTED]> wrote: > > >> /--- Policy 10.1 > >> | Two different packages must not install programs with different > >> | functionality but with the same filenames. (The case of two > >> | programs having the same functionality but different > >> | implementations is handled via "alternatives" or the > >> | "Conflicts" mechanism. > >> \--- > > > Both programs provide the same basic functionality indeed (i.e. > > translations), and the implementation is different. Why not using > > alternatives|Conflicts then? (read as: I can't understand your > > Policy citation, since it seems you're contradicting yourself). > > I've always read functionality in this context as meaning the API, > not the general task the program does. Agreed, but I can certainly see how that confusion arises from the policy text as it is. Perhaps a bug report against policy to specify "API" instead of "implementations"? -- \ “Know what I hate most? Rhetorical questions.” —Henry N. Camp | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
Mike Bird <[EMAIL PROTECTED]> writes: > Debian has a policy which allows it to inflict this change on DD's, > but it is perfectly reasonable for Debian users to have determined > that /bin/sh was linked to bash Yes. > and for Debian users to assume that /bin/sh will not be changed No. Why is this assumption reasonable? > for no good reason. This thread has listed many good reasons. -- \"All persons, living and dead, are purely coincidental." -- | `\_Timequake_, Kurt Vonnegut | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian over sensitivity?
Bas Wijnen <[EMAIL PROTECTED]> writes: > Also, lintian wants a statement of the form "Copyright ". > While saying "it is copyrighted " seems to have the same > meaning to me, I'm not sure how lawyers think about this. Again, better > be safe and use the standard format. Despite common misunderstandings about copyright law, "to copyright" is not a verb. Copyright is a *noun*, so to say that a work "is copyrighted" is, at best, poor grammar. Worse, the statement "author foo copyrights work bar" is legal nonsense. Copyright is not enacted by the author, it's enacted by their government — specifically, the government's copyright laws. The form "Copyright © " is stating who holds the copyright, with "hold" being the verb. The holder of the copyright is *granted* the copyright by the government of their jurisdiction. -- \ “We demand rigidly defined areas of doubt and uncertainty!” | `\—Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, | _o__)Douglas Adams | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the new style "mass tirage" of bugs
[EMAIL PROTECTED] writes:
> With the new style of "mass tirage" of bugs,
The word is "triage"; it's a term from hospital work.
> The user submits a bug;
> while (sleep 1 year) {
> He gets a message asking him to verify if the bug still exists;
> He perhaps especially reinstalls the package that he long ago stopped using
> &&
> He verifies it || the bug is closed
> }
Who other than the bug reporter would you suggest should try
reproducing the bug?
Suggesting "put that effort into fixing the bugs" is presuming that
the prospective bug fixer knows *which* bugs are worth the effort. If
the bug reporter is unresponsive, the bug is unlikely to be resolved
anyway because it can't be confirmed fixed.
What would you put in place of triage?
Suggesting that the bug simply remain rotting in the BTS seems worse
than subjecting it to triage to determine if it can be discarded.
--
\ "[...] a Microsoft Certified System Engineer is to information |
`\ technology as a McDonalds Certified Food Specialist is to the |
_o__) culinary arts." —Michael Bacarella |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the new style "mass tirage" of bugs
Please don't send me copies of messages that are also sent to the list, as I didn't ask for them. John Goerzen <[EMAIL PROTECTED]> writes: > On Wed February 20 2008 3:43:18 pm Ben Finney wrote: > > What would you put in place of triage? > > I think that the point is that triage should happen at *submission* > time, not so long later. > [...] > There appears to be no place for Debian users to submit OpenOffice > bugs where a human will investigate. All good points. Those are problems that need to be addressed. Orthogonal to that, there are currently packages that (like openoffice.org) have a lot of bugs of various ages. Triage seems to be a good approach to deal with those bugs, and fixes to the problems you point out will not address those existing old bugs. So complaints about triage of old bugs seems petulant. -- \ “The cost of education is trivial compared to the cost of | `\ ignorance.” —Thomas Jefferson | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the new style "mass tirage" of bugs
"Paul Wise" <[EMAIL PROTECTED]> writes: > I'm very bad at doing this myself, but it is equally important for bug > submitters to triage their own bugs, especially if they have lots or > many old ones. It's important for bug submitters to *confirm* their own bugs, especially if newer versions of the package have been released. That's not the same as *triage*, which is the process of making a first-run estimate of the priority of each in a set of bugs. I'd say that is *not* for the bug submitter to do, because bug submitter will not be able to be sufficiently objective about the bugs they've submitted. -- \ "Cross country skiing is great if you live in a small country." | `\ -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely
Manoj Srivastava <[EMAIL PROTECTED]> writes: > David Nusinow <[EMAIL PROTECTED]> said: > > > No matter what you want to say about your feature branches, you > > *must* apply them in a linear fashion to your final source tree > > that you ship in the package. This is no way around it. > > But there is no such linearization, not in the way that > quilt et al do it. The state of such integration is not maintained > in the feature branches; it is in the history of the integration > branch. Is this (the integration branch and its history of changes) not the linear sequence of changes that David Nusinow is asking for? > And the integration branch does not keep track of what changes come > from which branch -- that is not its job. Doesn't each commit message in the integration branch's history state what merge you were performing at each revision? You've previously described your workflow as one where you carefully integrate each feature branch separately into the integration branch. Do your commit messages in the integration branch not state what individual feature branch you're merging in? It seems to me that the analogue to a linear sequence of patches is the revision history of your integration branch. Granted, this doesn't give patches against a pristine upstream except from some initial state. -- \ "Some mornings, it's just not worth chewing through the leather | `\ straps." -- Emo Philips | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: FTP assistants, marketing team, init scripts, elections
gregor herrmann <[EMAIL PROTECTED]> writes: > What I'd actually like to see, own and use is a sweat-shirt; wearing > it in everday life would be a nice and easy way of promoting Debian. http://clusty.com/search?query=host%3Acafepress.com+debian+sweatshirt> -- \ "Dyslexia means never having to say that you're ysror." -- | `\ Anonymous | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary vs "real debian" packages
"Shaun Jackman" <[EMAIL PROTECTED]> writes: > The orig file would contain all the files not in the debian/ > directory, and the diff file would contain all the files in the > debian/ directory. More accurately, the 'foo-1.2.3.orig.tar.gz' file would contain the "upstream from the perspective of Debian" source; that is, the working tree of all files that someone would want if they were taking the software and uninterested in making a Debian package. The 'foo_1.2.3-1.diff.gz' would contain whatever changes are necessary to turn that working tree into something buildable to a Debian binary package. The 'foo_1.2.3-1.dsc' would contain necessary metadata about the combination of 'foo-1.2.3.tar.gz' and 'foo_1.2.3-1.diff.gz'. To answer the OP's "for some reason" implied question: the combination of these three files is a "Debian source package". -- \“To punish me for my contempt of authority, Fate has made me | `\an authority myself.” —Albert Einstein, 1930-09-18 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposing a new field in the source control data (was: Proposing a new source control header to link to upstream BTSs)
"Martín Ferrari" <[EMAIL PROTECTED]> writes: > Following the trend to add metadata to the debian/control file that > allows for the creation of new and powerful tools, I thought about the > usefulness of a header that'd allow to automatically relate to > upstream bug trackers. Those pieces of data are called "fields". Just like in RFC2822 messages or HTTP responses. In the case of a 'debian/control' file, it makes even *less* sense to call each field a "header". -- \ "A poet more than thirty years old is simply an overgrown | `\ child." -- Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new field in the source control data
"Martín Ferrari" <[EMAIL PROTECTED]> writes: > On Mon, Mar 17, 2008 at 4:37 AM, Ben Finney > <[EMAIL PROTECTED]> wrote: > > > Those pieces of data are called "fields". Just like in RFC2822 > > messages or HTTP responses. > > Thanks for the correction. I always think of headers, because one > usually refers to rfc2822 "fields" as "headers", I didn't know it was > incorrect. It's also incorrect in the context of RFC2822 messages and HTTP requests and responses. Each of those messages has exactly one header, comsisting of multiple fields. To refer to "the headers of a message" is confusing the issue, because it contradicts what the specification says. For a 'debian/control' file, which doesn't even have the "header and body" distinction, it's plain silly to talk about "headers". They're fields, just like in the header of an RFC2822 message. -- \ "When I was born I was so surprised I couldn't talk for a year | `\ and a half." -- Gracie Allen | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
BitTorrent and ISP interference (was: What CDs and DVDs should we produce for lenny?)
Gunnar Wolf <[EMAIL PROTECTED]> writes: > cobaco (aka Bart Cornelis) dijo [Wed, Mar 19, 2008 at 09:28:03AM +0100]: > > er, you do realise torrent is used for way more then that right? > > I do know, and I do think the idea is a darn good one. Several ISPs, > however, only see you are sharing via P2P - and might charge you > extra or disconnect you. That is a problem that won't be solved by avoiding use of BitTorrent; on the contrary, reducing legitimate use of BitTorrent can only result in supporting those who would paint BitTorrent as a tool without significant legitimate use. Rather, we should put pressure on those ISPs that would discriminate againt BitTorrent traffic. This pressure will be aided by an *increase* in legitimate use of BitTorrent. Actual, ongoing legitimate use will have far more weight as a demonstration of the value of BitTorrent than theoretical discussion in the absence of significant legitimate use. -- \ "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: BitTorrent and ISP interference
William, please follow the Debian mailing list code of conduct http://www.debian.org/MailingLists/#codeofconduct>; specifically, don't send me individual messages that are also sent to the list, since I didn't ask for them. William Pitcock <[EMAIL PROTECTED]> writes: > On Thu, 2008-03-20 at 07:51 +1100, Ben Finney wrote: > > That is a problem that won't be solved by avoiding use of > > BitTorrent; on the contrary, reducing legitimate use of BitTorrent > > can only result in supporting those who would paint BitTorrent as > > a tool without significant legitimate use. > > This has nothing to do with "legitimate" or not "legitmate" use; > this has to do with the fact that BitTorrent and swarm-based P2P > networks in general overload many ISPs infrastructure since ISPs > like to highly oversell their networks. I don't see why you present that as a counterpoint. Such actions by ISPs are by definition relegating BitTorrent traffic to "non-legitimate" status, by saying it shouldn't be supported equally. That problem which can only be solved by proving through actual use that BitTorrent is a service that users require their ISPs to support equally along with all other legitimate traffic. Refraining from using BitTorrent can only bolster the argument that it's not significantly used enough to support. > Putting pressure on them will not do any good, and infact, someone > who claims that it has to do with piracy will look like an idiot in > 90% of cases where BitTorrent is blocked. Fortunately, no-one has raised the topic of piracy, and I don't see the need to do so now. -- \ "Truth would quickly cease to become stranger than fiction, | `\ once we got as used to it." -- Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libcwd in Debian unstable
"Paul Wise" <[EMAIL PROTECTED]> writes: > On Mon, Apr 14, 2008 at 4:11 AM, Carlo Wood <[EMAIL PROTECTED]> wrote: > > > Author, copyright holder, maintainer, tired of this, and all what not, > > Do you mind if I ask why you chose the QPL instead of a DFSG-free licence? According to the FSF, the Q Public License version 1.0 is a free software license: Q Public License (QPL), Version 1.0 This is a non-copyleft free software license which is incompatible with the GNU GPL. It also causes major practical inconvenience, because modified sources can only be distributed as patches. http://www.fsf.org/licensing/licenses/> Debian's wiki, on the DFSGLicense page, categorises QPLv1 in the "unsettled" section: The QPL is not GPL-compatible, which, regardless of one's opinion about the license's DFSG-freeness, poses a major practical problem for any code licensed under the QPL that is reused elsewhere in conjunction with code under the GNU GPL. This makes the QPL alone a particularly poor choice of license for a library. http://wiki.debian.org/DFSGLicenses#head-32008704067079028804a5dc10bb340d4086> All that aside, though, if Carlo Wood is "tired of all this", he would be best advised to choose to license his work under terms whose freedom status *is* settled. -- \ "I filled my humidifier with wax. Now my room is all shiny." | `\ -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package maintenance in $HOME os an NFS share? (best practices survey)
Christoph Haas <[EMAIL PROTECTED]> writes: > So I'm wondering what other developers do. Are you using NFS at all? > Are you putting all your work under repository control and check the > files out to a local disk and back in to the server? I choose Bazaar http://bazaar-vcs.org/> where possible for version control of my software projects. It has many features, one of which is apropos here: "checkout" allows the best of both centralised-style VCS workflow when available and distributed repository workflow when offline. http://bazaar-vcs.org/Tutorials/CentralizedWorkflow> This allows me to work in checkouts on local hard drives whichever machine I happen to be working on, yet Bazaar keeps the central branch in sync (at each commit to the branch) with the local branch across the network, whenever it's available. When it's not, I commit locally, knowing that I can sync with the central branch later. So, it's almost what you say above, except that Bazaar takes care of the "out to a local disk and back in to the server" automatically, without losing the full benefits of distributed VCS. -- \ "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]
Bug#477125: ITP: bugs-everywhere -- distributed bug tracker
Package: wnpp Severity: wishlist Owner: Ben Finney <[EMAIL PROTECTED]> * Package name: bugs-everywhere Version : 0.0.193 Upstream Author : Chris Ball <[EMAIL PROTECTED]> * URL : http://bugseverywhere.org/ * License : GPL 2+ Programming Lang: Python 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.
Re: Package maintenance in $HOME os an NFS share? (best practices survey)
Marc Haber <[EMAIL PROTECTED]> writes: > On Sun, 20 Apr 2008 23:58:26 +1000, Ben Finney > <[EMAIL PROTECTED]> wrote: > >I choose Bazaar http://bazaar-vcs.org/> where possible for > >version control of my software projects. > > Am I the only one who finds answering a question a la "tool A is my > tool of choice, but it doesn't do a tiny little detail just as I > want it to do, can it be tweaked" with "use tool B, it's superior > anyway" totally unconstructive and also a little offensive? Nope, that sure does sound offensive. I'm glad nobody has done that in this thread. Or are you saying you find "I choose foo because of reason bar and baz" indistinguishable from "Use foo, it's superior anyway"? -- \ "I got food poisoning today. I don't know when I'll use it." | `\ -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please think and test before setting a mailing list as "Maintainer:"
Tino Keitel <[EMAIL PROTECTED]> writes: > What about ordinary users who report bugs for packages with > members-only Alioth lists as the Maintainer: address? Those lists are configured inappropriately. The Maintainer email address should accept email messages from anyonei, to avoid exactly that problem. If that's a mailing list, the same applies. http://wiki.debian.org/Alioth/PackagingProject#head-81024e1029fe37a8a12a7940ca799050f97bb275> -- \ "Pinky, are you pondering what I'm pondering?" "I think so, | `\ Brain, but if they called them 'Sad Meals', kids wouldn't buy | _o__) them!" -- _Pinky and The Brain_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Package maintenance in $HOME os an NFS share? (best practices survey)
Marc Haber <[EMAIL PROTECTED]> writes: > On Wed, 23 Apr 2008 23:48:26 +1000, Ben Finney > <[EMAIL PROTECTED]> wrote: > >Or are you saying you find "I choose foo because of reason bar and > >baz" indistinguishable from "Use foo, it's superior anyway"? > > At least if it's an answer to "How can I make bar do baz", yes. The OP asked specifically about "putting files under repository control". That's exactly what I was describing in my response. If you read something else in what I said, I'm unable to help you with that. -- \ "Ours is a world where people don't know what they want and are | `\willing to go through hell to get it." -- Donald Robert Perry | _o__) Marquis | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#478689: ITP: getopt -- Command-line parsing for GNU R
Guus Sliepen <[EMAIL PROTECTED]> writes: > On Wed, Apr 30, 2008 at 06:51:08AM -0500, Dirk Eddelbuettel wrote: > > > * Package name: getopt > > Please name the source package r-cran-getopt as well, just getopt is a > bit too generic. And competes for mindspace with an existing command 'getopt(1)' that is provided by a "Priority: required" package (and thus is on just about every Debian system out 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: Bug#479238: ITP: res -- OCaml library for automatically resizing contiguous data structure
Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > Package: wnpp > Severity: wishlist > Owner: Stefano Zacchiroli <[EMAIL PROTECTED]> > > * Package name: res Please change this to a package name that is less generic, and conforms with other OCaml library packages. 'libres-ocaml' would be better. -- \ “The cost of education is trivial compared to the cost of | `\ ignorance.” —Thomas Jefferson | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479238: ITP: res -- OCaml library for automatically resizing contiguous data structure
Please follow http://www.debian.org/MailingLists#codeofconduct> and avoid sending individual copies of messages also sent to the lists, since I haven't asked for that. Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > On Sun, May 04, 2008 at 12:27:29PM +1000, Ben Finney wrote: > > Please change this to a package name that is less generic, and > > conforms with other OCaml library packages. 'libres-ocaml' would > > be better. > > This is the source package name, as in all ITPs, not the binary > package name. No OCaml package has a source name like libFOO-ocaml, > they all have *binaries* called libFOO-ocaml-dev. Regardless, 'res' is an overly general name. The package should be more specific to the fact that it's an OCaml library. The time to choose an appropriate name is now rather than later. -- \ “If sharing a thing in no way diminishes it, it is not | `\ rightly owned if it is not shared.” —Saint Augustine | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#479238: ITP: res -- OCaml library for automatically resizing contiguous data structure
Stefano Zacchiroli <[EMAIL PROTECTED]> writes: > On Sun, May 04, 2008 at 05:08:57PM +1000, Ben Finney wrote: > > Regardless, 'res' is an overly general name. The package should be > > more specific to the fact that it's an OCaml library. The time to > > choose an appropriate name is now rather than later. > > Ack, I'll rename it to "ocaml-res" (source name). Fine by me. Thanks. -- \ "From the moment I picked your book up until I laid it down I | `\was convulsed with laughter. Someday I intend reading it." -- | _o__) Groucho Marx | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Specification for the 'Bugs' field in 'debian/control'
Howdy all, I'm trying to find the specification for the 'Bugs' field found in some packages (usually non-Debian ones). The field is not mentioned in the Policy §5 on control files http://www.debian.org/doc/debian-policy/ch-controlfields.html>. The combination "debian", "control", and "bugs" isn't helping me find it via search engines. I don't want to just guess based on existing packages and hope I get it right. Where can I find the specification for this 'Bugs' field? -- \ Eccles: "I just saw the Earth through the clouds!" Lew: "Did | `\ it look round?" Eccles: "Yes, but I don't think it saw me." | _o__) -- The Goon Show, _Wings Over Dagenham_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Specification for the 'Bugs' field in 'debian/control'
[EMAIL PROTECTED] (Aaron M. Ucko) writes: > Ben Finney <[EMAIL PROTECTED]> writes: > > > I don't want to just guess based on existing packages and hope I > > get it right. Where can I find the specification for this 'Bugs' > > field? > > deb-control(5): Thanks, I wasn't aware of that manpage. -- \ "My roommate got a pet elephant. Then it got lost. It's in the | `\ apartment somewhere." -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Regenerated SSL certificates for debian.org (was: debian infrastructure ssh key logins disabled, passwords reset)
Peter Palfrader <[EMAIL PROTECTED]> writes: > We also had to replace the SSL certificate on db.debian.org because > its CA which is operated by Software in the Public Interest (SPI) is > known to have been created with a SSL with the bug. The new SPI > CA can be found at the SPI's secretary page[8], its fingerprints > signed by Joerg Jaspert's GPG key. They are: > SHA1: AF:70:88:43:83:82:02:15:CD:61:C6:BC:EC:FD:37:24:A9:90:43:1C > MD5: 2A:47:9F:60:BB:83:74:6F:01:03:D7:0B:0D:F6:0D:78 > [A copy of the cert is available at http://ca.debian.org/spi-cacert.crt>] Is it normal that I should see "Could not verify this certificate for unknown reasons" when loading the certificate in Iceweasel? -- \ “The man who is denied the opportunity of taking decisions of | `\ importance begins to regard as important the decisions he is | _o__) allowed to take.” —C. Northcote Parkinson | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SSH keys: DSA vs RSA (was: Alioth and SSH: restored)
Roland Mas <[EMAIL PROTECTED]> writes: > - Keys submitted through the web interface are now filtered, and only > RSA keys end up in your authorized_keys file. Don't even try > putting DSA keys in your authorized_keys2 file, the use of that file > has been disabled (and it'll be deleted anyway). Could you explain the rationale for this? My impression was that DSA was recommended over RSA. -- \ "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: Sorting out mail-transport-agent mess
Mike Bird <[EMAIL PROTECTED]> writes: > All of the MTA's provide mail-transport-agent. I had assumed that apt > would choose between them on the basis that exim4-daemon-light is the > only provider with priority standard, the others being optional or extra. > > If apt does not consider package priorities in resolving disjunctions, > a possible solution would be for apt to do so. +1 This solution seems superior to my next choice, the introduction of a 'sensible-mta' package (to be used much as the OP's suggestion of 'default-mta'). -- \ "Ice Water? Get some onions - that'll make your eyes water!" | `\ -- Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
Steve Langasek <[EMAIL PROTECTED]> writes: > On Thu, May 15, 2008 at 11:33:04PM +0200, Sune Vuorela wrote: > > > 2) Introduce a default-mta package (currently) depending on exim4. > > All packages requiring a MTA should depend on default-mta | > > mail-transport-agent. This will have the extra advantage that we > > (and others like CDDs and derived distros) easily could swap > > default MTA. > > I believe that 2) is the correct option, and can see no reason that it > shouldn't be implemented straight away. If 'default-mta' is renamed to 'sensible-mta' to follow the existing convention (evidenced by 'sensible-editor', etc.), I agree. -- \ "For every complex problem, there is a solution that is simple, | `\neat, and wrong." -- Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
Steve Langasek <[EMAIL PROTECTED]> writes: > sensible-editor and sensible-browser are /commands/ Provided by the 'debianutils' package. > default-mta is not at all like this. You're right, I'm wrong. Thanks for clearing my confusion. -- \ "Hey Homer! You're late for English!" "Pff! English, who needs | `\ that? I'm never going to England!" -- Barney & Homer, _The | _o__) Simpsons_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Alioth and SSH: restored
Roland Mas <[EMAIL PROTECTED]> writes: > - Keys submitted through the web interface are now filtered, and only > RSA keys end up in your authorized_keys file. Don't even try > putting DSA keys in your authorized_keys2 file, the use of that file > has been disabled (and it'll be deleted anyway). The text of https://alioth.debian.org/account/editsshkeys.php> still reads: To generate a public key, run the program 'ssh-keygen' (you can use both protocol 1 or 2). The public key will be placed at '~/.ssh/identity.pub' (protocole 1) and '~/.ssh/id_dsa.pub' or '~/.ssh/id_rsa.pub' (protocole 2). Read the ssh documentation for further information on sharing keys. Please update this page to match the set of acceptable key types as per the announcement. -- \ "My interest is in the future, as I am going to spend the rest | `\ of my life there." -- Charles F. Kettering | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to handle Debian patches
Mike Hommey <[EMAIL PROTECTED]> writes: > If we're to say that we need a format such that external entities can > easily parse it, that will need to be a standardized format, and an > unique one. And despite what you'd like, I don't think this is git. +1. Saying that the plural 3.0 source formats allow Debian tools to consume multiple package source formats is equivalent to saying that upstream developers have no standard source format to rely on from Debian. It might allow interesting competition between the different source formats, but it doesn't improve the upstream's patch interface, because they still have to deal with a plural set of patch management styles. -- \"As soon as I get through with you, you'll have a clear case | `\for divorce and so will my wife." -- Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packages using VCS but with no 'Vcs-*' control field (was: How to handle Debian patches)
Joey Hess <[EMAIL PROTECTED]> writes: > I think it's about time to file mass bugs on whatever packages are > left that use version control and lack the fields. How would the putative filer of these bugs determine which packages are in this set? -- \ "...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]
Tracking divergence from upstream as a bug (was: divergence from upstream as a bug)
Joey Hess <[EMAIL PROTECTED]> writes: > Pierre Habouzit wrote: > > The 3 first. I assumed that everyone knows it's best to present > > a summary of your idea in the first paragraph. > > You seem to have actually missed the second sentence, "A change > might be a bug in upstream, or in the debianisation, or in Debian > for requiring the change.". > > nyway, I assume that people read the entirety of what I write before > blindly reacting to it. People who show they're not tend to get > ignored or have their reactions discounted after a while. Perhaps the tone would have been better set by describing this idea as "Tracking divergence from upstream as a bug" in the Subject field. -- \"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]
Tracking divergence from upstream as a bug (was: divergence from upstream as a bug)
Joey Hess <[EMAIL PROTECTED]> writes: > Hmm, another thought is, I sometimes have a changelog like this: > > * New upstream release. > - Including my fix for foo. > - And a better approach than my old hack to fix bar. > > It would be nice to be able to add bug numbers to close the > divergences when I'm writing that. Surely there are already bugs in the BTS, and corresponding changelog entries closing them, that match this description. Can you give examples so we can see what this might look like? > (And then an automatic system closing any I forget to mention would > be nice.) What information would trigger such automation, in the absence of you noting it as such in the changelog entry? -- \ “Holy bouncing boiler-plated fits, Batman!” —Robin | `\ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Tracking divergence from upstream as a bug (was: divergence from upstream as a bug)
Joey Hess <[EMAIL PROTECTED]> writes: > I think that going back and collecting all the patches I've sent to > upstreams over the years, and any I've dropped on the floor, and > keeping it up-to-date going forward will help me maintain my > packages better anyway, so I plan to do that this week. Though > usertags will be a bit suboptimal. Care to discuss what tags you plan to use, so an attempt at consensus can be made on naming the tags for this purpose? -- \ "If you don't know what your program is supposed to do, you'd | `\ better not start writing it." -- Edsger W. Dijkstra | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
George Danchev <[EMAIL PROTECTED]> writes: > I strongly believe that [...] there is no any urgent need for more > infrastrucre enhancements and yet another places to look at (like > teaching BTS/PTS of doing additional DD-upstream communication > processing which brings even more complexity to the scene). How is the Debian BTS "another place to look at"? It's already an essential place to look for information about what changes are made in a Debian package. > In the world of diversion, there should be a single point of > unification one can safely return to. The Debian BTS is already on the list of places to go for information about Debian package changes. The proposal in this thread doesn't increase that. -- \ "We tend to scoff at the beliefs of the ancients. But we can't | `\scoff at them personally, to their faces, and this is what | _o__) annoys me." -- Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages using VCS but with no 'Vcs-*' control field
Lars Wirzenius <[EMAIL PROTECTED]> writes: > su, 2008-05-18 kello 11:42 +1000, Ben Finney kirjoitti: > > Joey Hess <[EMAIL PROTECTED]> writes: > > > > > I think it's about time to file mass bugs on whatever packages are > > > left that use version control and lack the fields. > > > > How would the putative filer of these bugs determine which packages > > are in this set? > > We could add a requirement to add Vcs- field to specify that the package > has none. This would still not meet the stated requirement for the proposed mass bug filing, of finding packages that *do* use a VCS but don't declare it. -- \"I have one rule to live by: Don't make it worse." -- Hazel | `\ Woodcock | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tracking divergence from upstream as a bug
Neil Williams <[EMAIL PROTECTED]> writes: > However, from a bug submitter point of view, I don't think I want to > see the bug report kept open (tagged divergence) after it has > actually been closed by a Debian-specific patch. As upstream it > might make a fair bit of sense but as a user / bug submitter, it > will just look odd. Would your opinion be different if the bug was "fixed" but not closed nor archived, until the "divergence" tag is gone? > A user reporting a bug in foo should not still be wondering why the > bug is open after the fix has been applied. Isn't that a matter easily resolved by presenting the bug information appropriately in the interface? -- \“Always code as if the guy who ends up maintaining your code | `\ will be a violent psychopath who knows where you live.” —John | _o__) F. Woods | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packages using VCS but with no 'Vcs-*' control field
Lars Wirzenius <[EMAIL PROTECTED]> writes: > su, 2008-05-18 kello 18:40 +1000, Ben Finney kirjoitti: > > This would still not meet the stated requirement for the proposed > > mass bug filing, of finding packages that *do* use a VCS but don't > > declare it. > > That is true, but it would get all package maintainers to add the > headers, and the package maintainers would then know what to add. > > So the mass bug filing would be to add Vcs- headers according to > need. When such bugs are filed, I would ask that they not refer to "headers" which is a term that doesn't apply to 'debian/control'. The contents of 'debian/control' is a set of *fields*, not headers, just like the fields in the header of an email message. > Of course, I wouldn't do a mass bug filing yet. I'd add a lintian > check first, and do a d-d-a mail, and wait a couple of months. That sounds a reasonable approach, *if* there is consensus that the 'Vcs-*' fields should be mandatory in 'debian/control' files. The mass bug filing would then have nothing to do with whether the 'Vcs-*' fields were *correct* or not, just whether they were *present*. This is different from the original "file bugs against packages that do use a VCS but don't declare it" proposal, up-thread. -- \ "I was stopped by the police for speeding; they said 'Don't you | `\ know the speed limit is 55 miles an hour?' I said 'Yeah I know, | _o__) but I wasn't going to be out that long.'" -- Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
Please follow http://www.debian.org/MailingLists#codeofconduct> and avoid sending messages individually to someone when the message is also sent to the list, unless they ask for it. Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Sun, May 18, 2008 at 06:01:19AM +, Ben Finney wrote: > > The Debian BTS is already on the list of places to go for > > information about Debian package changes. The proposal in this > > thread doesn't increase that. > > For _debian_ packagers yes. But such a tool would be useful for > upstreams, and form them it *is* one another place to look at. And > most wont, because for large upstreams, there's this huge userbase > you see, and the huge number of downstreams, and huge number of > downstreams issue trackers. They can't look at them all. So it's already the case that they have a certain number of places to look, *including* the Debian BTS if the work is packaged for Debian. I don't see that this proposal changes that. -- \"Program testing can be a very effective way to show the | `\presence of bugs, but is hopelessly inadequate for showing | _o__) their absence." —Edsger W. Dijkstra | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Sun, May 18, 2008 at 09:26:12AM +0000, Ben Finney wrote: > > So it's already the case that they have a certain number of places > > to look, *including* the Debian BTS if the work is packaged for > > Debian. I don't see that this proposal changes that. > > That's why the proposal is bad. It doesn't improve that, and it > requires more work from the maintainer. Lose/lose situation. As I understand it, the proposal is to put *new* information (that Debian source diverges, and exactly why) into an existing location that is already a place we expect upstream to know about (the Debian BTS) and that all Debian package maintainers are already expected to know how to use. That seems like an improvement on putting that information in a *new* place, that historically is not a place where all Debian package maintainers can be expected to use, and expecting that upstream will look there. The former builds on the existing conventions (use of the Debian BTS is mandatory for Debian package maintainers, upstreams already at least know the BTS contains useful information), the latter attempts to set up a separate system that hasn't historically been mandatory at all. -- \"There was a point to this story, but it has temporarily | `\ escaped the chronicler's mind." -- Douglas Adams | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
Pierre, please fix your MUA to honour the request I made earlier: stop
sending individual copies of messages that you also send to the Debian
lists. It's a request in the mailing list guidelines, and I've
explicitly pointed it out earlier.
Pierre Habouzit <[EMAIL PROTECTED]> writes:
> On Sun, May 18, 2008 at 09:57:02AM +, Ben Finney wrote:
> > Pierre Habouzit <[EMAIL PROTECTED]> writes:
> >
> > > That's why the proposal is bad. It doesn't improve that, and
> > > it requires more work from the maintainer. Lose/lose situation.
> >
> > As I understand it, the proposal is to put *new* information (that
> > Debian source diverges, and exactly why) into an existing location
> > that is already a place we expect upstream to know about (the
> > Debian BTS) and that all Debian package maintainers are already
> > expected to know how to use.
>
> But it's NOT ABOUT Debian package maintainers.
You seem to contradict yourself; in the earlier message I quoted
above, *you* raised the issue of "requires more work from the
maintainer". I was responding directly to that point. If you don't
think the effect on maintainers is relevant, I don't see why you
raised it in the first place.
> More administrivia is never an improvement. See (yeah I know it's
> always about the glibc, but well … that's a very good example for the
> discussion) in the glibc we have
> debian/patches/$arch/$state-$subject.patches. For $state in
> {submitted,local,cvs}. submitted means its sent upstream, local means
> that it's not, cvs that it's a cherry-pick from upstream. Why on earth
> would we need to write that in _yet another place_ ?
Again, the BTS is not "yet another place"; it's already a place where
Debian-specific information needs to be about other changes to the
package. It's a proposal to *consolidate* information into a place
that already has much similar information for similar purposes,
instead of having that information scattered in many places.
> What Joey's proposal is:
> * put more burden on the maintainers that already report patch
> upstream ;
Are these maintainers not recording the fact of a bug in the BTS?
> * has very few advantages for people that already did that work in
> their source package in a decent enough way (like the glibc does):
> the sole advantage I see is that it's predictable where to find the
> information. But when you want to check a package you have to
> `apt-get source` it anyways, and if debian/patches is sorted
> properly, then you'll see that in an obvious way before even
> launching your browser to look at the BTS.
This assumes that 'debian/patches' is a known standard interface for
all Debian packages, which I would think it clearly isn't in light of
previous threads here. The Debian BTS, on the other hand, *is* a known
standard interface for all Debian packages.
--
\ "I busted a mirror and got seven years bad luck, but my lawyer |
`\ thinks he can get me five." -- Steven Wright |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
Lucas Nussbaum <[EMAIL PROTECTED]> writes: > On 18/05/08 at 19:57 +1000, Ben Finney wrote: > > As I understand it, the proposal is to put *new* information (that > > Debian source diverges, and exactly why) into an existing location > > that is already a place we expect upstream to know about (the > > Debian BTS) > > Huh? Upstreams knowing about the Debian BTS? Sure, in an ideal > world, that's the case. But most upstreams don't follow the > BTS/don't use it, simply because they don't have time to do that. That's not what I said, though. I posited only that they know it exists as a place to look for Debian-specific information, in the context that it's not a *new* place for them to look for such information. Whether or not they actually look there isn't something we can have much hope of enforcing, regardless of where it is. -- \ "Prediction is very difficult, especially of the future." -- | `\ Niels Bohr | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
George Danchev <[EMAIL PROTECTED]> writes: > You seem to forgot that people will actually work with the source > code and actual patches applied to it, not with a bunch of patches > floating in Debian BTS with not so clear/predictable state > (applied/unapplied/blamed/whatever). Such a service to can only be a > companion one, but not a reliable source of what has actually > changed, so consider it 'yet another place to DIG at'. Whether the patch is in the bug report or not, I don't see how that affects the proposal. > You wil have hard time teaching every upstream in Debian BTS (new) > tags and features, but they all already know how to deal well > prepared diffs from debian ftp mirrors. I've gone back to re-read the original proposal that starts this thread, and I can't see where everyone is reading "bureaucracy" and "extra workload" and "patches floating in the BTS" and "forcing upstream to read new BTS tags and features". The proposal, at its core, is merely about how to *classify* divergence from upstream source in a Debian package. There's nothing in the original message that requires patches to be duplicated, or upstream to get patches in a different way, or any of the other spectres people are raising here. It *suggests* that, with such a classification, certain workflows would be enabled naturally; but it doesn't *insist* on any of them. There's merely the proposal that we start *tracking* the divergence as a bug that needs resolution, like any other bug report in the BTS. Am I wrong? -- \"I hate it when my foot falls asleep during the day, because | `\ that means it's gonna be up all night." -- Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
Pierre Habouzit <[EMAIL PROTECTED]> writes: > FFS let's do not a mua and m-f-t wars. Set your MFT and my MUA will > honour that. What I've requested is laid out in the Debian mailing list code of conduct as behaviour to be expected in the absence of explicit requests. A Mail-Followup-To field setting may or may not count as an explicit request; in the absence of that, the code of conduct should apply. > debian/patches is the proper place to put your changes. Is it? Where is that stated to be required for all packages throughout Debian? -- \ "Truth: Something somehow discreditable to someone." -- Henry | `\L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > The proposal is about tracking the required patches in the BTS. No, the bug is about classifying "divergence from upstream" as a bug to be tracked in the Debian BTS. The location of patches isn't a necessary part of the proposal. Patches in the BTS are listed in the proposal as a "can", not a "should" -- i.e. something that would be a natural part of the workflow, but not a necessary part of the proposal. -- \"Don't worry about people stealing your ideas. If your ideas | `\are any good, you'll have to ram them down people's throats." | _o__) -- Howard Aiken | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: divergence from upstream as a bug
Pierre Habouzit <[EMAIL PROTECTED]> writes: > [tracking divergence from upstream as a bug in the Debian BTS is] > additional work. That's creepy and uninteresting work to begin with, > its useless with proper upstreams, and is needed only for bad > upstreams, that won't eve take a glance at all that work ever. Yay. > That's kind of what I call bureaucracy indeed. This, at least, is addressing the point of the proposal. Thanks. I don't have enough experience using the BTS to interact with upstream to comment on this, but I'll watch the responses of others (who do have such experience) with interest. -- \ “Any intelligent fool can make things bigger and more | `\complex... It takes a touch of genius – and a lot of courage | _o__) – to move in the opposite direction.” —Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Mailing lsit code of conduct, again (was: divergence from upstream as a bug)
Pierre Habouzit <[EMAIL PROTECTED]> writes: > On Sun, May 18, 2008 at 01:26:20PM +0000, Ben Finney wrote: > > What I've requested is laid out in the Debian mailing list code of > > conduct as behaviour to be expected in the absence of explicit > > requests. A Mail-Followup-To field setting may or may not count as > > an explicit request; in the absence of that, the code of conduct > > should apply. > > oh boy, are we really "fighting" over a dupe of a mail ? Your mail message individually to me is not wanted, and I have a reasonable expectation through the mailing list code of conduct *and* through my explicit request that you not send it. Yet you continue to do so, violating both. > wasting 4k of data and two keystrokes ? You make unfounded assumptions about how I receive and handle messages in this forum. > CoC is meant to reduce rudeness Then please have it reduce your rudeness, and comply with explicit requests both from me and the ML CoC: stop sending unwanted mail messages when the messages are already sent to the list. -- \ "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: Packages using VCS but with no 'Vcs-*' control field
Bernd Eckenfels <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]> you wrote: > > When such bugs are filed, I would ask that they not refer to > > "headers" which is a term that doesn't apply to 'debian/control'. > > The contents of 'debian/control' is a set of *fields*, not > > headers, just like the fields in the header of an email message. > > Are we making new packaging policy here? No. It's a request for correct terminology. Hopefully it doesn't need policy rules to enforce. -- \ "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: Mailing lsit code of conduct, again
Russ Allbery <[EMAIL PROTECTED]> writes: > Ben Finney <[EMAIL PROTECTED]> writes: > > > Your mail message individually to me is not wanted, and I have a > > reasonable expectation through the mailing list code of conduct > > *and* through my explicit request that you not send it. > > The solution to this problem is to fix the mailing list code of > conduct to stop creating this expectation. Presumably the code of conduct requests it because it was deemed desirable. > We don't enforce it anyway, and all this provision seems to do in > practice is create these annoying arguments periodically. No, that's not all it does. It also has the significant effect that discussions in these forums do not, in the main, generate needless individual copies of messages in the participants's mailboxes. I, and presumably the people who drafted the code of conduct, continue to find that a very favourable outcome of this provision. -- \ "A fine is a tax for doing wrong. A tax is a fine for doing | `\ well." -- Anonymous | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mailing lsit code of conduct, again
Vincent Bernat <[EMAIL PROTECTED]> writes: > Another solution on your side is to use Mail-Followup-To. > [...] > Most mailers comply with this header. That field is non-standard, and there are many MUAs that don't obey it. It's not much of a solution if I can't expect it to be applied consistently. Whereas with the ML CoC, I do have a reasonable expectation that most people should follow it as a recommended best practice on the mailing lists. > With gnus, this is really easy: just set message-subscribed-regexps > to a list of regexps of the list you are subscribed to. That set is empty. I don't (nor do I wish to) receive messages in Debian list discussions via email. -- \ Q: "I've heard that Linux causes cancer..." Torvalds: "That's | `\ a filthy lie. Besides, it was only in rats and has not been | _o__) reproduced in humans." -- Linus Torvalds | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
