Re: Unofficial projects related with Debian.
On Fri, 23 May 2003 11:58:45 -0300 Gustavo Franco <[EMAIL PROTECTED]> wrote: > Hi, > > Why Debian Desktop subproject is on official website > and many others[1] aren't? The Debian Desktop is a good > initiative, but there are many others that are being > excluded from the website.I've some ideas: > > - Guidelines to Debian subprojects (Do you known >what are the official and unofficial subprojects now?); > > - List the subprojects in two areas of the website: >* Developers' corner, to subprojects in initial state; >* A new area called: Subprojects, containing full >information about the subprojects considered mature. > > [1] = "Mono for Debian", ipv6 (is it official or unofficial?), > "ddtp", ... http://www.debian.org/devel/, "Projects" section: * Debian Web Pages * Debian archive * Debian Documentation Project (DDP) * The X Strike Force * The Quality Assurance group * Debian GNU/Linux CD images * The sponsorship program * The key signing coordination page * Debian IPv6 Project * Debian Jr. Project * Debian-Med Project * Debian-Edu Project * Debian-Lex Project * The Debian Desktop Project * Automatic package building system * Technical Committee * Debian Description Translation Project (DDTP) * Alioth: Debian GForge Certainly seems that they're listed. pgps6ZrYkKk9O.pgp Description: PGP signature
Re: What makes a debconf?
On Fri, 23 May 2003 17:33:58 -0700 Sean 'Shaleh' Perry <[EMAIL PROTECTED]> wrote: > "Debconf" is about Debian developers trying to meet other devels and users. > Its about trying to make us a stronger organization. Its about hacking and > all of the other reasons we love Debian. > > Treating it like a Comdex, a Linux World or anything else just seems wrong. The problem is that people who can get expenses reimbursed need to have a focus. Sponsors need to have a focus. There needs to be a "major" conference for these kinds of things; in other words, it has to be billed as something more than just a bunch of people getting together, even if that's what *all* conferences are at heart. If a Debian Developer's employer is willing to let them go to one trade conference a year, expenses paid or partially paid, and the options are "one of a dozen Debian conferences or LinuxWorld", their employers will say "LinuxWorld". If, on the other hand, the options are "one of a dozen Debian conferences, Debconf, and LinuxWorld", their employers will likely allow either of the last two. > Developers should feel encouraged to declare a conference whenever and > whereever they can make one. If one of us can organize a meet and people > will show up that makes a conference. Of course, but "Debconf" is a specific term. If you're arguing that it isn't, then we need to come up with another one, that denotes an annual Debian conference that's official in nature :) See above. I'm really not trying to say that people can't get together when they want to. Just saying that having something people can *focus* on is a benefit to the community. So an annual or semi-annual Debconf is good, even if all that _really_ distinguishes it from the rest is that we don't call two conferences "Debconf" within the same six/tweleve-month time frame :) pgpldMJDrEpvJ.pgp Description: PGP signature
Re: Bug#194515: ITP: debdivert -- Debian packaging aid to create patch packages
On 24 May 2003 15:40:08 +0900 Masato Taruishi <[EMAIL PROTECTED]> wrote: > Ah, the main point of this package is to create a local ad-hoc package > which can coexist with its official package. Escpecially, I can manage > my temporary on-going improvement to some debian package as a debian > package. I didn't think to waste official debian packages because we > shouldn't upload this kind of patch packages to the official but merge > the patch to the official packages if we want to share them on public. The main question is "what on god's green earth does this do that dpkg-divert doesn't do?" Looking at the package description, it implies that it will in fact do a lot less than dpkg-divert unless you tell it otherwise. pgpaRVCmGccgC.pgp Description: PGP signature
Re: Unofficial projects related with Debian.
On Sat, 24 May 2003 10:19:38 +0200 Enrico Zini <[EMAIL PROTECTED]> wrote: > > http://www.debian.org/devel/, "Projects" section: > > > > * Debian Web Pages > [...] > > * Alioth: Debian GForge > > Certainly seems that they're listed. > > The Debian Usability Research seems to be missing: > http://deb-usability.alioth.debian.org I think that's fairly new, eh? Might be a while before it shows up. (I don't know how anal the webmaster for that page is, but I know I'd give it a while to make sure it was a viable, active effort.) pgp6TA44JuDfw.pgp Description: PGP signature
Re: new bug tags
On Sun, 01 Jun 2003 15:33:29 +0100 James Troup <[EMAIL PROTECTED]> wrote: > >> Since we're using bug tags for such specific things now wouldn't it make > >> sense to add per architecture tags so one can search via > >> http://bugs.debian.org/tag:hppa > >> for hppa related issues (not that there are any of course!). It would > >> help porters to identify arch related issues much more easily. > > > > I strongly second this. > > I don't; it's silly. At best you'll get an architecture tag for the > arch that the buildd maintainer reported the bug on, but that's it. > An inaccurate architecture tag is worse than useless, it's misleading. > Just parse wanna-build's failed logs; it's trivial. I don't think he's specifically referring to buildd things as much as just general arch issues (ie: one might file a bug with respect to an endianness issue and tag it "hppa"). pgpkvbWqYwIAk.pgp Description: PGP signature
Re: CGI:IRC on Debian
On Mon, 23 Jun 2003 16:02:39 +0200 Vincent Zweije <[EMAIL PROTECTED]> wrote: > Dodging with symlinks is not really a solution, as all the files will > actually still be in the wrong places. I believe he meant installing them to the proper locations, and then making symlinks from there to the "big directory" which is probably in /var/www. Thus, the files wouldn't actually be in the wrong places. I agree however, in that it's an unpleasant workaround. As for my own suggestion, I would say - fix the package. The diff.gz exists for a reason. If you're incapable of fixing it, find somebody who can (and hopefully get them to show you how they did it). pgppuQijpkXCx.pgp Description: PGP signature
Re: maildirmake
On Tue, 24 Jun 2003 11:46:48 +1000 (EST) Matthew Palmer <[EMAIL PROTECTED]> wrote: > On Tue, 24 Jun 2003 [EMAIL PROTECTED] wrote: > > > Now I'm wondering about it even more. IMHO `maildirmake' is _very_ > > necessary for any mail and as it seems to be only a 2-line-shell-script > > why it isn't included anywhere and anyway in the base-system? > > As I recall, maildirmake is only needed if you are running Maildir-based > MDAs, which Debian does not by default[1]. That is enough of a reason not > to ship it in the base system, regardless of whether it's a two line shell > script or not. > > [1] Arguments as to whether Debian should do this or not should be directed > to /dev/null. Exim is capable of handling Maildir mailboxes. It's Priority: important. I don't know if that counts as "shipping it by default" or not, but I would certainly say that it's the closest thing around. pgp8nmZT4A4RL.pgp Description: PGP signature
Re: CGI:IRC on Debian
On Mon, 23 Jun 2003 23:27:48 -0300 Gustavo Noronha Silva <[EMAIL PROTECTED]> wrote: > > As for my own suggestion, I would say - fix the package. The diff.gz > > exists for a reason. If you're incapable of fixing it, find somebody who > > can (and hopefully get them to show you how they did it). > > Additionally, try to make those modifications as compatible with > the upstream's policies and code style as possible, as this > is going to increase the possibility of he taking the patch. Excellent and important point, thanks. I'll try not to forget in the future. pgpUQCtjX1PCM.pgp Description: PGP signature
Re: maildirmake
On Tue, 24 Jun 2003 13:12:04 +1000 (EST) Matthew Palmer <[EMAIL PROTECTED]> wrote: > Capable of handling, yes, but then, so is cat.Once delivered, though, > there's no way of getting it back out again unless you're running something > like courier or similar. Or Mutt, or a halfdozen other MUAs. :) > My logic was that, from the basic system, Maildir mailboxes are no use. > Things like courier make Maildir useful, so that's where the maildirmake > script should live. It *might* make sense to put it in exim where people > can run it to make their mailboxes, but since the delivery is useless > without other programs to post-process, I'm still not won over on the > idea... Well, it's a standard format, and it's a trivial shell script. The options are either including maildirmake(1) in each and every MUA that understands Maildir formats (understanding here that imapds perform many/most functions traditionally assigned to an MUA), and having them all either Conflicts: with one another or using alternatives. Given how simple it is, makes more sense to have it in one place. I don't know where it should be (in all the MTAs?), but there you go :) pgpmJKfebDkaV.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
On Wed, 25 Jun 2003 14:04:54 -0500 Gunnar Wolf <[EMAIL PROTECTED]> wrote: > And not only 80386 needs this - There is the Sparc64 port which would > also benefit from this (http://www.debian.org/ports/sparc/#64bit). If we > had support for subarchtectures, not only would the ix86 mess be able to > be split in many flavors (i.e. strict 386, 486 and up, 686, or whatever > you fancy). And I am sure this can somehow help maintain the non-Linux > ports - NetBSD gives us the potential to bring Debian to _many_ new > platforms. No it doesn't. I've yet to even hear of an architecture that NetBSD runs on but which Linux doesn't. They just have a different definition of "architecture" than us. (ie: our "hppa" may be three or four arches to the NetBSD kernel folk.) pgpecAblVDzu4.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
On Sat, 28 Jun 2003 15:53:56 -0600 Joel Baker <[EMAIL PROTECTED]> wrote: > > No it doesn't. I've yet to even hear of an architecture that NetBSD runs > > on but which Linux doesn't. They just have a different definition of > > "architecture" than us. (ie: our "hppa" may be three or four arches to > > the NetBSD kernel folk.) > > There are a couple. I don't think most people care about any of them, > right now (and quite possibly never will, in the case of old VAXen, > for example). There's a working VAX port including a relatively complete driver set, at least, so that's not one. :) But, regardless; > In discussing it the other day, I actually found a concise way to > express one of the major reasons I choose to work on the port and find > it worthwhile: I think ports to other kernels are generally worthwhile in and of themselves, simply for cleaning up the codebase and getting rid of unportable stuff. It's just plain old healthy is all. The previous comment about it was just meant in an informative manner is all. (I've never heard of a "Turbochannel" machine either, so I won't bother looking into it.) pgp0LjEdvp7zM.pgp Description: PGP signature
Re: but I want the GNU versions of packages
On Sat, 28 Jun 2003 07:57:55 +0800 Dan Jacobson <[EMAIL PROTECTED]> wrote: > Gentlemen, after I installed "Debian GNU/Linux", I found I had to take > extra steps to get the GNU version of a program installed, as some > other leading brand alternative was in its stead. > > So what is the single command to apt-get install all the GNU versions > of everything? > > Last year I discovered mawk sitting there until I banished it away with > apt-get install gawk. > > Yesterday I realized I had been using mailx all this time while GNU's > mailutils were sitting unused. > > Do I look in Packages.gz for Conflicts:, and then look in Description: > for "this is the GNU version of..."? > > What other other leading brands programs are sitting on my computer > when I could have been using a genuine GNU program? > > What genuine GNU programs should I defer, lest e.g. messages get trunc A fair numbe rof those apps you probably want were implemented in Debian before GNU made their own versions - install-info(8) is one of the ones most often griped about. I believe which(1) is another case. Regardless, having a "gnu" task is perfectly reasonable as far as I'm concerned - just wanted to point out that it isn't necessarily maliciousness or even a judgement call so much as things just *weren't there* :) pgpLEMheDgw4I.pgp Description: PGP signature
Re: Bug#198158: architecture i386 isn't i386 anymore
On Mon, 30 Jun 2003 18:17:57 +0200 Karsten Merker <[EMAIL PROTECTED]> wrote: > > I think ports to other kernels are generally worthwhile in and of > > themselves, simply for cleaning up the codebase and getting rid of > > unportable stuff. > > > > It's just plain old healthy is all. The previous comment about it was > > just meant in an informative manner is all. (I've never heard of a > > "Turbochannel" machine either, so I won't bother looking into it.) > > TurboChannel is a 32bit bus system used in Digital Equipment systems like > the MIPS-based DECstation series and the Alpha-based DEC 3000 series. The > former (at least some models) is supported by Linux/MIPS (and Debian/MIPS) > as well as by NetBSD/OpenBSD, the latter is only supported by *BSD. Thanks :) pgpS2MBhvRyC8.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On 03 Jul 2003 13:00:47 +0200 Petter Reinholdtsen <[EMAIL PROTECTED]> wrote: > > [Javier Fernández-Sanguino Peña] > > (For those who are not aware of this issue, please read #92810) > > There seem to be someone believing that standard documents should be > treated as software. Standards are not software. Standards do not > improve if everyone is allowed to modify them and publish the modified > version as an updated version of the standard. Standards get their > value from having a rigid procedure for updates and modifications. > Software do not. > > I believe this whole case of RFC standards are not confirming to The > Debian Free Software Guidelines display a complete lack of > understanding of the value of standards, and should be rejected. > Standards are not software, nor software manuals, and should not be > treated as such. > > I haven't been following this case, and understand it might be late to > speak up against it, but believe it is about time the whole case is > stopped. #92810 specifically deals with whether the RFCs should be in main or non-free. They are not freely modifiable, so they should not be in main - end of story, regardless of whether it's a good thing or a bad thing. I happen to agree with your thoughts (if not the phrasing and tone), and agree that standards by their nature can't be both Free and effective. But they're no less effective in non-free, so just relax :) pgp0WiB4muIiQ.pgp Description: PGP signature
Re: Please remove RFCs from the documentation in Debian packages
On 03 Jul 2003 23:45:56 -0500 Joe Wreschnig <[EMAIL PROTECTED]> wrote: > On Thu, 2003-07-03 at 15:19, Thomas Viehmann wrote: > > Cameron Patrick wrote: > > > On Thu, Jul 03, 2003 at 02:36:48PM -0500, Branden Robinson wrote: > > > | Well, once you folks have come up with a definition of "software", you > > > | be sure and let us know. > > > How about "anything included in Debian"? That way we won't be in danger > > > of violating the Social Contract #1. > > > > Oh, cool. How about changing in DFSG to "Anything that can go in main or > > contrib." > > Because that's a circular definition. Saying everything in Debian is > software, is not. > > It's also the only reasonable way to define software. Or at least, the > only reasonable way I (or anyone else who has voiced their opinion on > this issue here) have come up with in 3 years, and it's not for a lack > of trying. The assumption in his suggestion was that it would no longer be the "Debian Free Software Guidelines", but the "Debian Free main/contrib Guidelines". ie: if it's going to go into main or contrib, it needs to meet the guidelines. Except for the title, the DFSG is very content-agnostic. It can be applied equally well to software, fiction, nonfiction, images, what have you. pgpsRUM6OreNP.pgp Description: PGP signature
Re: NEWS.Debian support is here
On Sun Jul 06, 04:58pm -0400, Matt Zimmerman wrote: > On Sun, Jul 06, 2003 at 04:31:22PM -0400, Matt Zimmerman wrote: > > > On Sun, Jul 06, 2003 at 07:13:23PM +0100, Scott James Remnant wrote: > > > Would this work just as well? > > > [example without distribution and urgency] > > > > It would work just as well. The changelog format was used unmodified for > > purposes of simplicity. Tools already know how to parse it, and its format > > is already reasonably specified in the documentation. > > To clarify, I meant that such a format would meet the need of NEWS.Debian. > However, the existing tools would not understand it. > > I do not see the extra unused information as a problem, and it lets us use > existing tools for creating and editing NEWS.Debian (debchange, dpkg-dev-el, > etc.) If you can make apt-listchanges understand the pared-down format, perhaps the others will support it eventually too. I don't care a whole lot about it myself, but it *does* look a lot nicer :)
Re: Debian 10th birthday gear
On Tue, 8 Jul 2003 11:11:13 +0200 Sebastian Rittau <[EMAIL PROTECTED]> wrote: > On Tue, Jul 08, 2003 at 05:36:22PM +1000, Anand Kumria wrote: > > > General > > Debian > > 1 project > >10 architectures > > 100 countries > > 1000 maintainers > > 1 packages > >10 bug fixed > > 100 million users > > 1000 installations > > I would recommend to exchange these last two lines. More installations > than users? I'm a single Debian "user", and I maintain about a dozen Debian boxen. (And when I say "maintain", I mean they do various things for me, the sysadmin, and I'm the closest thing to a user for them that exists.) So the 10:1 ratio is approximately accurate, at least here. It's a common demographic for Debian I believe. pgpcr0nofWLXi.pgp Description: PGP signature
Re: NEWS.Debian support is here
On Tue, 8 Jul 2003 22:48:48 +1200 Nick Phillips <[EMAIL PROTECTED]> wrote: > On Tue, Jul 08, 2003 at 10:46:47AM +0200, Josselin Mouette wrote: > > Le mar 08/07/2003 ? 01:15, Matt Zimmerman a ?crit : > > > > All that's missing is an automatic debconf notice entry for each NEWS > > > > item. > > > > > > > > That wud be well c00l. > > > > > > As I recall, part of the idea of NEWS.Debian was to prevent having this > > > kind > > > of information end up as debconf notes. > > > > But some people like to have this information in debconf notes. Having > > the choice between displaying them and reading them in NEWS.Debian would > > be neat. > > He was JOKING... wasn't he? I doubt it. Some people have few enough packages installed that a nice pretty interface like that is reasonable. Keep in mind that debconf notes weren't implemented to piss people off - they were implemented because they can be used well. They're overused and overabused, but they're a valid presentation mechanism ... under the right circumstances :) pgpKKZh9syZb2.pgp Description: PGP signature
Re: default MTA for sarge
On Sun, 13 Jul 2003 10:31:51 +0200 Joey Hess <[EMAIL PROTECTED]> wrote: > For sarge we have two options for the default MTA in base: > > a. replace exim with exim4 > b. no MTA installed by default, add a MTA task > > So do we want there to be a MTA by default? I would opt for a) personally. Exim has done me well for years, and exim-config (or its debconf-based replacement) is great. However, if b) is chosen ... doesn't this cry for a category, not a task? Or perhaps even a one-off frontend that lets one select from the list of 'grep-available -FProvides -sPackage mail-transport-agent'? pgplbFa6n1iM4.pgp Description: PGP signature
Re: new credit printing mechanism now present in reiserfsprogs
(That's a really long recipient list - does this need only go to reiserfs-list@namesys.com and [EMAIL PROTECTED]) On Wed, 23 Jul 2003 11:45:09 +0400 Hans Reiser <[EMAIL PROTECTED]> wrote: > it now prints two random credits rather than all of them, and credits > for the developers are in place. suggestions about how to improve this > while preserving the credits (e.g. printing them at a different stage of > mkreiserfs, etc.) are welcome. If mkreiserfs was slower, I would suggest printing them at the start of the program. It gives people something to read while they're waiting for it to finish. (They would probably be more likely to read it, too.) It takes less than 4 seconds on a regular file of 410M here, though, so that's not a whole lot of time. Does it take longer on bigger filesystems? Lots of people are making many-gigabyte filesystems these days, so perhaps that really is a good idea. pgpSmUZz0vdA1.pgp Description: PGP signature
Re: Bug#203046: RFA: doc-linux -- Linux HOWTOs and FAQs
On Sun, 27 Jul 2003 11:47:06 +0100 Colin Watson <[EMAIL PROTECTED]> wrote: > David Harris has expressed an interest in this job, and I've talked to > him about it on IRC, so if he still wants it he's welcome. If anyone > else is interested, then contact me: a small team would be a good idea > anyway. I'll wait and see if anybody else, perhaps more suitable, will volounteer to be the "primary" maintainer before considering taking on a package this large. I'd have to think about it at any rate. I'd also be more comfortable in a team environment, I find that more work gets done that way. P.S.: The packages look to be in great shape now, so either way, thanks for the work :) pgpVhwgnaWuis.pgp Description: PGP signature
Re: LWN subscription for Debian developers
On Sun, 31 Aug 2003 05:42:06 +0800 Dan Jacobson <[EMAIL PROTECTED]> wrote: > Bdale> ... I announced a group subscription to lwn.net for Debian > Bdale> developers, sponsored by HP... > > Debian may be seen as supporting non-disclosure conditions / > protected proprietary information / trade secrets / etc. whatever. > > Bdale> If you are a Debian developer and want full LWN access, go to > Bdale> lwn.net and create an account for yourself (no money is > Bdale> required... > > But the Debian developer cannot disclose the information seen with non > Debian developers. Jealous? :) pgpKuaboT6Ya9.pgp Description: PGP signature
Re: A possible GFDL compromise
On Thu, 04 Sep 2003 21:55:07 -0400 Richard Stallman <[EMAIL PROTECTED]> wrote: > This clause has a direct effect on all users, > restricting the use of e.g. encrypted filesystems. > > That's a new one on me. I don't think the GFDL restricts > the use of encrypted filesystems. I have mentioned it at least a half-dozen times myself, and at least once to you explicitly. (I believe you also responded to that mail, though not addressing the point in question.) As Jamin mentions, in section 2: "You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute." I'll also mention the first half of the sentence of section 4: "You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above ..." Please don't think that I'm quoting that out-of-context. I assume that anybody who will respond to this message has read the GFDL as fully as I have, and will instead point out other sections or clauses which render the above sentence irrelevant (I wasn't able to find any myself, and I looked quite hard). Taken literally (ie: should a copyright holder take a distributor to court over this point), the clause forbids _anything_ which might obstruct the reading or futher copying of the copies you make or distribute. Thus, we may not host the GFDL document on a password-protected portion of a web site. Nor may we use SSL to transmit any of the text. Nor may we store any text on an encrypted filesystem. An anonymous FTP server that requires USER and PASS would also fall into this category (regardless of whether the USER is "anonymous" or not). I've asked a couple of lawyers, and they strongly feel that a case could be made (though not so clear-cut as the above examples) for copying the document to a place that's already protected in some form (a $HOME that's not world-readable for instance, or on a machine that has a firewall), or distributing the document in a format that may be extraordinarily well-documented and not patent-encumbered, but for which the only reader implementation is non-Free. To RMS specifically: I have always assumed that this was simply a bug in the license, but it _has_ been brought up a lot, by myself as well as others, sometimes in messages you replied to. Now that you've noticed the point in question, I'm trying to present the rationale for the conclusion. It's not meant in a combatitive manner, nor is it meant as a personal attack against yourself. If for whatever reason somebody interprets as either of the above, I apologise and will correct that person if they're pointed out to me. pgpMyhXCdSliG.pgp Description: PGP signature
Re: A possible GFDL compromise
Sorry folks, I CC'd: -devel instead of -legal. God I hate Reply-To:s :) On Fri, 5 Sep 2003 12:03:59 -0400 David B Harris <[EMAIL PROTECTED]> wrote: > On Thu, 04 Sep 2003 21:55:07 -0400 > Richard Stallman <[EMAIL PROTECTED]> wrote: > > This clause has a direct effect on all users, > > restricting the use of e.g. encrypted filesystems. > > > > That's a new one on me. I don't think the GFDL restricts > > the use of encrypted filesystems. > > I have mentioned it at least a half-dozen times myself, and at least > once to you explicitly. (I believe you also responded to that mail, > though not addressing the point in question.) > > As Jamin mentions, in section 2: > > "You may not use technical measures to obstruct or control the reading > or further copying of the copies you make or distribute." > > I'll also mention the first half of the sentence of section 4: > > "You may copy and distribute a Modified Version of the Document under > the conditions of sections 2 and 3 above ..." > > Please don't think that I'm quoting that out-of-context. I assume that > anybody who will respond to this message has read the GFDL as fully as I > have, and will instead point out other sections or clauses which render > the above sentence irrelevant (I wasn't able to find any myself, and I > looked quite hard). > > Taken literally (ie: should a copyright holder take a distributor to > court over this point), the clause forbids _anything_ which might > obstruct the reading or futher copying of the copies you make or > distribute. Thus, we may not host the GFDL document on a > password-protected portion of a web site. Nor may we use SSL to transmit > any of the text. Nor may we store any text on an encrypted filesystem. > An anonymous FTP server that requires USER and PASS would also fall into > this category (regardless of whether the USER is "anonymous" or not). > > I've asked a couple of lawyers, and they strongly feel that a case could > be made (though not so clear-cut as the above examples) for copying the > document to a place that's already protected in some form (a $HOME > that's not world-readable for instance, or on a machine that has a > firewall), or distributing the document in a format that may be > extraordinarily well-documented and not patent-encumbered, but for which > the only reader implementation is non-Free. > > To RMS specifically: I have always assumed that this was simply a bug in > the license, but it _has_ been brought up a lot, by myself as well as > others, sometimes in messages you replied to. Now that you've noticed > the point in question, I'm trying to present the rationale for the > conclusion. It's not meant in a combatitive manner, nor is it meant as a > personal attack against yourself. If for whatever reason somebody > interprets as either of the above, I apologise and will correct that > person if they're pointed out to me. > pgpzM26Bf4Cwx.pgp Description: PGP signature
Re: apt-proxy/wget/squid caches file indefinitely
On Sun, 21 Sep 2003 11:11:37 +1000 Brian May <[EMAIL PROTECTED]> wrote: > Ok, this is driving me bananas. I go to download the latest > unstable packages, only to find that apt-get update > has just retrieved a cached copy of the Packages file that > (in some cases) can be a month old. I've seen similar a while ago, but I didn't bother tracking it down. I'll try to reproduce it again, an d I'll let you know if I'm able to fix it. pgp4N0rG5I9iB.pgp Description: PGP signature
Re: Ideas about allowing Co-maintainer
On 05 Oct 2003 13:13:55 +0200 Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > There is no point for me working on those bugs if the patches will > just rod in the bts or be thrown out so as not to differ from > upstream. As I said before I won't work on the debian package again > without an assurance by the maintainer that he will look at it. I've occasionally helped out with util-linux, and I must say that Debian's util-linux is already markedly different from upstream's, and this isn't a good thing. It's already bitten people once; for instance, it's unlikely that cryptoloop volumes created with Debian's util-linux will work on other machines (the passphrase is hashed before use in Debian's util-linux, and I don't believe it's done elsewhere.) As others have suggested, if you have fixes to upstream bugs, the best place to send them is to upstream. Failing that, you can always file them in the BTS and forward them upstream yourself. pgp9jP1FF6mg3.pgp Description: PGP signature
Re: Bug#215103: ITP: gmasqdialer -- gtk/gnome client for masqdialer server
On Fri, 10 Oct 2003 21:04:23 -0400 Joe Drew <[EMAIL PROTECTED]> wrote: > > Description : gtk/gnome client for masqdialer server > > How about "client for masqdialer"? > > > > > From the freshmeat description: > > GMasqdialer provides a GNOME/GTK client for the Masqdialer system. The > > Which is it, GTK only or GNOME? As much as you may dislike it, people care about toolkit. I don't understand the witch-hunt to remove references to such things. (Though I do agree that "GNOME/GTK" could easily be shortened to "GNOME".) pgpbwd0428jOf.pgp Description: PGP signature
Re: Bug#215103: ITP: gmasqdialer -- gtk/gnome client for masqdialer server
On Mon, 13 Oct 2003 00:02:47 -0400
Joe Drew <[EMAIL PROTECTED]> wrote:
> David B Harris wrote:
>
> > As much as you may dislike it, people care about toolkit. I don't
> > understand the witch-hunt to remove references to such things.
>
> Short description is a limited resource. By all means, put GTK or GNOME
> in the long description if it is deemed necessary; apt searches will
> still find what you're looking for.
Obviously if the short description is too long, something needs to go -
and in that case, certainly not mentioning the toolkit is reasonable.
However, in this particular case ("gtk/gnome client for masqdialer
server", but really "gnome client for masqdialer" since the "gtk" is
assumed when talking about GNOME) is 35 characters long.
If you think 35 characters is too long, feel free to start filing
thousands and thousands of bugs on all the other packages, suggesting
that they remove little bits and pieces.
pgpJg5QyDch8o.pgp
Description: PGP signature
Re: Bug#215103: ITP: gmasqdialer -- gtk/gnome client for masqdialer server
On Mon, 13 Oct 2003 01:44:57 -0400
David B Harris <[EMAIL PROTECTED]> wrote:
> Obviously if the short description is too long, something needs to go -
> and in that case, certainly not mentioning the toolkit is reasonable.
> However, in this particular case ("gtk/gnome client for masqdialer
> server", but really "gnome client for masqdialer" since the "gtk" is
> assumed when talking about GNOME) is 35 characters long.
>
> If you think 35 characters is too long, feel free to start filing
> thousands and thousands of bugs on all the other packages, suggesting
> that they remove little bits and pieces.
(And if you don't, please don't bother people about it - instead file a
bug on Policy asking for the short description guidelines to
specifically say "do not mention the application's toolkit".)
pgpbH15Uf0TrV.pgp
Description: PGP signature
Re: Pre-Depends for postgresql
On Fri, 17 Oct 2003 02:18:00 +0100 Colin Watson <[EMAIL PROTECTED]> wrote: > Uid 31 is reserved forever (speaking as the base-passwd maintainer), but > new installations of postgresql should have a uid in the system range, > namely 100-999, as created by 'adduser --system'. See the changelog for > base-passwd 3.5.0. What for, out of curiosity? Just part of the "standard" range of 0-99? pgpZoZaNdEesN.pgp Description: PGP signature
Re: [debian enterprise] sub-project planning
On Mon, 01 Dec 2003 13:12:52 -0500 Andres Salomon <[EMAIL PROTECTED]> wrote: > I have discussed this sub-project extensively at Voxel, and we are > willing to commit to seeing this idea through - in a manner that allows > the Debian community to benefit from resources that we put into it. We > are willing to provide developmental resources (Voxel is more than > willing to pay me to head up this sub-project), hardware, legal > resources, bandwidth, and hosting, with development happening under the > Debian moniker. We are also researching the possibility of 24/7 > commercial support for enterprise clients, as that is a large part of > what companies want (both for technical support, as well as someone to > blame when something goes wrong). Up until this portion of the email, I was thinking, "oh yeah, this sounds good, and get a big company involved too - like HP or IBM." Any thoughts on that? Anybody from HP or IBM here want to weigh in? P.S.: I'm willing to put work into the debix/FAI-type stuff.
Re: Debian Enterprise - a Custom Debian Distribution
On Mon, 01 Dec 2003 11:45:35 -0800 Bruce Perens <[EMAIL PROTECTED]> wrote: > I am still negotiating with the large industry group that approached me > about this project. When the price tag is north of $1M, it takes time. > If that works out, they would fund 3-5 engineers full-time, plus myself > and an admin to work on the aspects of this project that are important > to their industry group. And only their industry group. Thus, there is > room for participation of a number of vendors and/or industry groups, as > well as direct participation by all of the various entities that would > participate in Debian. Are you still on good terms with some people at HP? I don't even think we need funding, per se. I wouldn't mind getting paid well for the work I do, but that's a rarity. (Why does money always need to get involved?) What I'd really like to see is a company providing input, serving as a central point for customer contact, and above all, actually *supporting* the use of the end-product. ie: not being hostile to users who run it, as is so often the case these days. I can't count the number of times I've heard horror stories from HP customers (and other vendors as well) about people being unable to RMA hardware because they're using a decent software bundle that they're familiar with and can maintain, as opposed to whatever outdated and bastardised crap was included with the hardware. Okay, that sort of turned into a rant :) I do apologise, but I'd desperately like to help dispell the stigma that's associated with anything non-Red Hat.
Re: [debian enterprise] sub-project planning
On Tue, 02 Dec 2003 06:27:12 +1100 Zenaan Harkness <[EMAIL PROTECTED]> wrote: > > Any thoughts on that? Anybody from HP or IBM here want to weigh in? > > My primary thought wrt making money from Free Software - make as much as > we possibly can - at least that's my goal, so that I can provide for > myself and my family, and (in the future) work on more Free Software > projects. My goals are only to provide something that and end-user can use without having their vendor tell them they're on their own, no RMAs, no hardware support, nothing.
Re: Debian Enterprise - a Custom Debian Distribution
On Mon, 01 Dec 2003 13:53:02 -0800 Bruce Perens <[EMAIL PROTECTED]> wrote: > >Are you still on good terms with some people at HP? > > > Yes. Has anyone discussed this with Bdale? He hasn't participated in the thread yet. > >I wouldn't mind getting paid well for the work > >I do, but that's a rarity. (Why does money always need to get involved?) > > > I admire those who don't have to consider money while fulfilling all > three of the above goals. I meant more specifically, when corporate involvement is discussed :) There's lots of other things companies can do without writing cheques. > >What I'd really like to see is a company providing input, serving as a > >central point for customer contact, and above all, actually > >*supporting* the use of the end-product. ie: not being hostile to users > >who run it, as is so often the case these days. > > > Yes, but let me add something. I think we will have failed if there is > only one company doing this. No lock-ins, no lack of choices, please. > That's one of the things wrong with RH/Fedora. > > And I think I have the structure to make this work. I'm writing now, > should have something for you later today. Sorry, yeah. I should instead have said "*their* company", not any one company. The company they buy their hardware and support from. In my mind, HP and IBM are paramount, since they also happen to be the only two major suppliers for the shop I work in :)
Re: [custom] Debian Enterprise - packages
On Tue, 2 Dec 2003 22:49:20 -0600 John Goerzen <[EMAIL PROTECTED]> wrote: > First of all. This is obviously not a Debian project (since it is not > operating within the Debian framework.) I don't see why this then > necessitates over a dozen threads on debian-devel -- AND why it gets to > call itself "Debian." Amen, brother.
Re: Accounts on debian.org machines
On Mon, 08 Dec 2003 03:18:53 + Matthew Garrett <[EMAIL PROTECTED]> wrote: > Steve Langasek wrote: > >But an ssh key on removable media is not vulnerable to keysniffing > >alone, where a password is. > > If such behaviour becomes common, the keysniffers will simply copy > anything that looks like an SSH key that exists on an item of removable > media. There's no inherent increase in security from using a key on a > USB device other than the fact that attackers aren't thinking about that > yet. The old "security through obscurity" idea, eh? Well, if you *rely* on obscurity for your security (ie: if an attacker has free reign if they know the secret you're trying to keep [in this case, that the SSH key is on USB media]), then sure, there's a problem. It's not a problem, however, if it's only *part* of a security regimen. For instance, I'll ask a simple question: does the hacker who installed the hardware keylogger on my machine know that my SSH key is somewhere unusual? Do they even know about SSH keys? If either of those answers is "no", I have effectively averted a compromise, whereas even if they *didn't* know, but I didn't use an SSH key, they'd have effective control of my machine. Some food for thought. Obscurity != security, but I've yet to see any effective security regimen which did *not* include some obscurity factors. I've also yet to see anybody post their IP address, userid, and password for their publicly-accessible servers to a public mailing list :)
Re: Accounts on debian.org machines
On Mon, 08 Dec 2003 18:38:25 -0500 Joe Drew <[EMAIL PROTECTED]> wrote: > On Mon, 2003-12-08 at 15:37, David B Harris wrote: > > I've also yet to see anybody post their IP address, userid, and > > password for their publicly-accessible servers to a public mailing list > > :) > > I have. root, even. > > http://lists.debian.org/debian-devel/2002/debian-devel-200206/msg01187.html *THEIR* IP address, userid, and password. As opposed to a carefully sandboxed userid and environment. Or are you saying that you used [EMAIL PROTECTED] for your computing needs, including storing your unencrypted GPG, unencrypted SSH key (or encrypted, in which case both of which use the passwords you've posted), your email client, your web browsing, your programming, your work, and what have you? :)
Re: Bug#144046: general: Sections are not finely grained
On Mon, 22 Apr 2002 16:15:45 +0200 Javier Fern <[EMAIL PROTECTED]> wrote: > Users need a hierachical layout in order to find software. > Keyword by themselves are not that much useful since they would be > only appropiate to the language used. Several disadvantages: > > 1.- more difficult to translate than sections > 2.- are not organised hierarchicaly (sp?) > 3.- difficult to represent graphically in a package-administration gui > (sections are easily represented as trees). Agreed. However, there's no reason why one can't conceivably have more than on tree. The tasks system is kind of like that. In fact, it's arguable that if all packages belonged to at least one task, we would actually have a hybird keyword/category system. A package, gnome-calculator, could belong to the desktop task, the gnome task, and the desktop-calculators task. /me ponders... What's it take to get a new task? Just a matter of adding a Task: field? No other hoops? If that's the case, then maybe the original poster would like to come up with a relatively long list of "keywords" (really, just tasks). The aforementioned gnome-calculator task could appear as the following leaves in the tree: desktop-calculators/gnome gnome/desktop-calculators desktop/desktop-calculators Easy to present in a UI, and since a) the list of keywords (tasks) needn't be a very small number, and b) a package can belong to more than one task (have more than one keyword), it meets the original poster's request. -- ________ \ David B. Harris, Systems administrator | http://www.terrabox.com / / [EMAIL PROTECTED], [EMAIL PROTECTED] | http://eelf.ddts.net \ \==/ / Clan Barclay motto: Aut agere, aut mori. (Either action, or death.) \ pgpyUB2lfVyFl.pgp Description: PGP signature
Re: Improper NMU (Re: NMU for libquota-perl)
On Sun, 1 Sep 2002 12:42:20 -0400 Elie Rosenblum <[EMAIL PROTECTED]> wrote: > I also don't see a bug submitted with this. If you're submitting > NMU's, you sure as hell better be submitting bugs with patches (or > the fact that no patch is required other than rebuilding with an > updated system). > > Please delete your uploads. You are violating policy. > > For debian-devel: The NMU here was made to rebuild for perl 5.8; > no other changes would have been necessary. > > What is the concensus on this? I'm not talking out of my ass here, > am I? Typically, when somebody rebuilds on of my packages for a library change and then NMUs it, I say "thank you". :) pgpom9cIl2Wft.pgp Description: PGP signature
New thread about people switching to other distributions
Hey there :) I'm starting a new thread about people switching to other distributions. Why? Because I'd rather we start first with an information-gathering thread. I'm shortly going to relate my first-hand knowledge of why people have switched from Debian, to Gentoo. Everybody else who has any first-hand knowledge about it, please relate your experiences too. Also, if you know of somebody who was thinking "Hmmm, Debian or Gentoo?", and they chose Gentoo, do tell why. (I don't know anybody who's been in that situation, unfortunately. I think they've probably got great insights. Joey's comments on the web site would probably also come from somebody in this group of Gentoo users.) If you don't have any first-hand knowledge, please don't respond to this thread. We'll start a "what do we do with this knowledge now?" thread later. Okay, so, my experiences. I've watched about three dozen people from #debian "switch" to Gentoo. About two dozen of them switched simply because it was cool. I mean, these people showed up in #debian because they had tried Slackware and failed miserably (yes. This happens like every other day). Now they were trying Debian, because it was the next step up in the coolness meter. No, I'm not just assuming these people are idiots :) I actually talk to them privately, help them out, and whatnot. The other third of people I've watched switched just wanted something new to play with. Would have been FreeBSD, probably, if Gentoo hadn't been around. Most of them have already tried SuSE, Mandrake, Red Hat, and their ilk. One person had a very good reason - they had a client whose company policy was to use specific gcc flags (can't remember which, but IIRC they had something to do with hardware stability and debugging) - Gentoo let them do that more easily. Anybody else? pgpuDqpwBovp8.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Fri, 29 Nov 2002 15:58:51 -0500 Joey Hess <[EMAIL PROTECTED]> wrote: > The comparison is only fair with organizations that *want* you do do > so(so not redhat, probably not openbsd, or mandrake, or others whose > principal developers try to sell cds). Strictly speaking, given the ISO mirroring situation, we've never wanted people to use full 640M ISOs when we knew that 99% of people downloading would use a couple hundreds megs, at most. pgpYSbDdC8lGr.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Sat, 30 Nov 2002 23:27:33 +1300 Nick Phillips <[EMAIL PROTECTED]> wrote: > "Given the ISO mirroring situation"? Care to elucidate? There being an order of magnitude more package mirrors than ISO mirrors. Completely ignoring the web site organisation, mind you, it's been common for a long time for people to encourage network-based installs, or anything other than downloading full 640M ISOs. Part of it, of course, is to enhance the "user experience" - users will rightfully go with full 640M ISOs because it's been their experience in the past that a) it was required, and b) shit broke often enough that they needed to reinstall. Almost everybody I got to do a 'net install never had any problems whatsoever, and they were EXTREMELY delighted. Had they gone wish the full 640M ISO, they'd have been happy, but they wouldn't have had as good an idea as to how things *can* work, when it's done right :) pgpZo7vImmMrN.pgp Description: PGP signature
Re: Are we losing users to Gentoo?
On Sat, 30 Nov 2002 16:06:40 -0500 Joey Hess <[EMAIL PROTECTED]> wrote: > The problem with the net installs isos is mainly that they are > unofficial and there are several varying cd's produced by different > folks, and of varying quality (though quality is overall good; I've > used them happily in the past). If we really want to promote them more > it would be good to set things up so they can be generated from the > debian-cd package, and make them official debian isos. > > Of course debian-installer should support 1.4 mb net install floppies > too. > > But still if someone wants a whole debian CD, for whatever reasons, > I'd rather they could easily find it, especially if they are a > newcomer to debian. Agreed, on all counts :) pgpLK5R1aKajL.pgp Description: PGP signature
Re: Mozilla Calendar?
On Wed, 4 Dec 2002 12:55:35 +0200 [EMAIL PROTECTED] (Sami Haahtinen) wrote: > In the past the only thing that stopped me from doing a build of my > own from the sources was that debian missed libical.. and now that > there appears to be libical-dev, i can't see any reason why not > package it.. Yes, looks like it was uploaded somewhere near the end of September. Regardless, newer versions of Mozilla Calendar don't need it. :) pgp9rG0oGCoS7.pgp Description: PGP signature
Re: description writing guide
On 04 Dec 2002 12:55:50 -0500 Colin Walters <[EMAIL PROTECTED]> wrote: > http://people.debian.org/~walters/descriptions.html Thanks. pgpfyKOIrBIap.pgp Description: PGP signature
Re: description writing guide
On 04 Dec 2002 12:55:50 -0500
Colin Walters <[EMAIL PROTECTED]> wrote:
> http://people.debian.org/~walters/descriptions.html
I do have some differences of opinion, though. It's sad, but there are a
getting to be a fairly large number of DDs who are "attention grabbers".
Just a few days ago, I saw a package description that said something
along the lines of "this is the best package for this purpose" ... and
it certainly wasn't. Even if it was, I think everybody would agree that
that kind of language doesn't belong in a Debian package description.
So, the opening section that talks about advertising and whatnot will
probably give these sorts of people the wrong idea; I'd ammend it to:
Debian package descriptions are the first avenue for you to give your
audience relevant, useful information about your package. When you
attempt to give somebody new knowledge, the key idea is to know your
audience.
Also, I'm not sure I agree with the third paragraph; everything in it is
factual and well-said, but it'd be nice if somebody who *didn't* know
what GTK+ and RAD are could know conclusively, "this is not what I
want". When you're looking for something specific, but don't know the
exact package name, the process of elimination is the best start. I know
I, *personally*, have installed packages which I couldn't immediately
rule out from the package description because I didn't *quite*
understand the jargon.
glade is a bad example for my point, though, because it has a great
description :)
In paragraph five ("So how can we better target these users?"), I'd
s/minimum/appropriate amount/. I've seen bloody jihads in very
well-known projects to give only the "minimum of technical jargon", and
people invariably take it to far. Had they just stressed appropriateness
of the text to the audience, things would have been much more
reasonable.
In paragraph six, ("So far we've mainly discussed the synopsis line"),
I'd s/competition/alternatives/; s/advertisement/good documentation/.
(BTW, if you totally disagree with me about this "advertisement" stuff,
do replace all references to "advertisements" with "good advertisements"
and whatnot :)
Also, in the description template, two spaces are used after a period -
is that standard nowadays? (My understanding was that they were
primarily used for variable-width fonts, where a single space would take
up very little page space. Since the descriptions should be presented in
a fixed-width font (for many reasons, this also includes GUI package
browsers), they're a bit redundant.)
Thanks again :)
pgpvz7X4QJZE4.pgp
Description: PGP signature
Re: description writing guide
On 04 Dec 2002 19:19:38 +
Scott James Remnant <[EMAIL PROTECTED]> wrote:
> In correct English grammar and typography the space after a full stop
> ("period" in Merkin) is supposed to be a wider space then that between
> words and after commas and suchlike.
Ahh, allright, so there's still reason to be using them, at least in
fixed-width fonts.
I personally, though, suggest we just do away with it :)
pgpzq11f5gZjV.pgp
Description: PGP signature
Re: description writing guide
On Wed, 4 Dec 2002 11:33:35 -0800 Craig Dickson <[EMAIL PROTECTED]> wrote: > I don't see any reason why package descriptions shouldn't be presented > in variable-width fonts. The right margin might look a bit ragged > (assuming the program preserves line breaks, which is probably a good > idea to avoid messing up bulletted lists in the description), but so > what? Package descriptions don't usually include tabular data that > would be seriously messed up by variable-width fonts. Just for looks, and to allow some flexibility on the part of the description writer. If variable-width fonts are used, then line breaks shouldn't be preserved. If they're not going to be preserved, there needs to be a very specific set of rules as to how lines are joined. These already exist in code, actually; I believe packages.debian.org joins lines. pgpgVk65NIWMv.pgp Description: PGP signature
Re: description writing guide
On Thu, 5 Dec 2002 12:13:57 +0100 Michael Piefel <[EMAIL PROTECTED]> wrote: > Line breaks already aren't preserved, and there already exist a very > specific set of rules for that. Look into your documentation, and have > a look at dselect. I already have example applications which don't preserve them :) packages.d.o was just one such example. Could you point me at the documentation in question? pgpZ1ILPPpLkT.pgp Description: PGP signature
Re: description writing guide
On Thu, 5 Dec 2002 20:59:09 +0100 Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote: > a good search interface in our package interface UIs (good search != > search by words). ... as opposed to searching based on the contents of people's minds? :) pgphxF5io44ke.pgp Description: PGP signature
Re: description writing guide
On Sat, 7 Dec 2002 11:51:03 +0100 Martin Schulze <[EMAIL PROTECTED]> wrote: > It is a bad practice to repeat the package name as the first word in > the long description. Why is that again? > Also the URL does not belong into the description but should be > placed in the debian/copyright file instead. Joey might have said that, but I believe the consensus was "it's a nice feature". The description is not a random dumping-ground for information, but what information we include is entirely arbitrary. If people like having the URL in the description (and they do), there's no reason why it shouldn't be included unless you want to make a case for "Packages.gz bloat". pgp8Qr6wqeOwI.pgp Description: PGP signature
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
On Fri Apr 11, 11:47am +0200, Philipp Kern wrote: > * Package name: exim-mysql > Version : 3.36 > > I already packaged with one (exim compiled with mysql and tls support). > I needed it personally, with the provided debian exim package a > recompile is necessary to use a mysql backend. > debian package mirror: http://draenor.its-toasted.org/~phil/deb-pkgs > distribution: unstable > component: unofficial For what it's worth, exim4-daemon-heavy includes MySQL support; this package isn't in the archive yet, I grabbed it from q.bofh.de at some point, and that's stopped working. The package was from a team working on exim 4.x packaging, presumably it'll be uploaded to the archive eventually (though "eventually" may be far enough into the future to warrant this package, given how slow they're going at it). pgpydj4zb7MyI.pgp Description: PGP signature
Re: Bug#188564: ITP: exim-mysql -- An MTA (Mail Transport Agent) with mysql backend support.
On Fri Apr 11, 02:25pm +0200, Andreas Metzler wrote: > http://pkg-exim4.alioth.debian.org/ Ack, sorry, I didn't realise you guys were uploading to experimental now :) pgp5PKNAFgS4V.pgp Description: PGP signature
[david@eelf.ddts.net: Re: why do we care about configuration files?]
On Fri Apr 18, 11:15am -0400, Colin Walters wrote:
> Perhaps I've been overly strong with the rhetoric. Let me give two
> realistic scenarios where this "manage foo with debconf?" fails.
I like your two real-world examples, and I'd like to present a third.
3) Impatient but advanced user
Somebody who dislikes being asked repeatedly whether or not a
conffile can be overwritten. This user has tested xserver-xfree86's
debconf interface, and has taken the time to understand how
xserver-xfree86's postinst generates the configuration file based on
the debconf information. He is very confident in it doing the right
thing, and doesn't want to be bothered on each upgrade about whether
or not it can overwrite it. More importantly, this user knows full
well that, in the very rare circumstance where it *does* break, he
can easily fix it within minutes.
This user will likely feel the same way about almost all
debconf/postinst-managed configuration files, excepting the few which he
knows will break repeatedly. He doesn't want to get asked 50 "may I
overwrite your file?" questions each upgrade. He knows that in the time
spent reading and answering all those questions, he could just has
easily fixed the two cases of breakage. Which he would have to do in
addition to answering the questions, were they forced upon him.
I liked the concept behind your suggestion of "managed" and "unmanaged"
configuration files. I would, however, suggest a slightly different
interface:
1) Package has a configuration file which can (optionally) be managed
debconf/postinst
2) Package's .config asks, *once* (respecting debconf "seen" flag), the
following question:
"File /etc/foo/bar can optionally be managed by this package's
maintenance scripts in an automated manner. How would you like
changes to /etc/foo/bar to be handled?
ask-no: If /etc/foo/bar will be changed, ask first. Default to
`no'
ask-yes: If /etc/foo/bar will be changed, ask first. Default to
`yes'
always-no: Never automatically overwrite /etc/foo/bar, don't even
ask.
always-yes: Always automatically overwrite /etc/foo/bar, don't even
ask (warning: dangerous).
ask-no
ask-yes
always-no
always-yes"
3) That question should be standard amongst all packages, identical. It
should always be of priority "medium".
4) A standard interface for ask-yes and ask-no would also be required,
similar to dpkg's conffile handling.
For ask-* interfaces, debconf's "seen" flag should (obviously) be
ignored, since it's *meant* to be asked repeatedly.
After some feedback, I will implement said standard interfaces as
example. I kind of like the idea of
/etc/conffiles/{managed,unmanaged,default}. That could easily be used as
the backend storage for the standard {ask,always}-{no,yes} question.
pgpddpFF01dCy.pgp
Description: PGP signature
Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]
Apologies for starting a new thread, I accidentally replied to Colin privately, and instead of re-writing the email, I simply forwarded it. Bad clal :) pgpLvG6UUTUOa.pgp Description: PGP signature
Re: stop the "manage with debconf" madness
On Fri Apr 18, 12:54pm -0500, Manoj Srivastava wrote: > >> On 18 Apr 2003 11:55:09 -0400, > >> Colin Walters <[EMAIL PROTECTED]> said: > > > So, opinions? Yeah, it's kind of gross. But the way things are > > now is far worse. > > As long as /etc/conffiles/managed, /etc/conffiles/unmanaged, > and /etc/conffiles/default are never themselves unmanaged, this would > work. And the factory default for /etc/conffiles/default should be > managed; and the other two files should be empty. > > If we standardize on a easy to interpret format for these > files, I'll add the logic to ucf to handle these directives. (how > about a configuration file path per line for /etc/conffiles/managed > and /etc/conffiles/unmanaged, and /etc/conffiles/default contain a > single word, which is "managed" by default; anything other than > "unmanaged" is interpreted as "managed?). Something else worth thinking about, which I was gonna throw in my example package for all this stuff, is config-file-change priority. ie: It would be nice to differentiate between "the entire config format has changed, I will break completely if the old one is used", "some parameter options have changed; the old ones will still work - for now", "I just changed some defaults, keep what they have now", and "I fixed a typo in one of the documentation comments." We could then respect things like DEBCONF_PRIORITY, and not bother the user if all we've changed is the spelling of a descriptive (ie: not example) word in a comment. Pet peeve of mine in dpkg conffile handling :) pgp9z3wRbXkEU.pgp Description: PGP signature
Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]
On Fri Apr 18, 05:28pm -0400, Colin Walters wrote:
> > 1) Package has a configuration file which can (optionally) be
> > managed
> >debconf/postinst
>
> This is already the way things are now; a package doesn't have to do
> anything special to create configuration files in its postinst.
Yeah, I was just setting out the scenario.
> > 2) Package's .config asks, *once* (respecting debconf "seen" flag), the
> >following question:
>
> Uggg. We should be extremely hesitant about changing
> /etc/conffiles/{managed,unmanaged,default} in maintainer scripts. I
> mean they exist solely *because* of the problems of changing
> configuration files in maintainer scripts :)
I think this is the *perfect* place for maintainer scripts. We can make
the format extraordinarily simple, such that anybody who is capable of
writing a maintainer script can take 60 seconds to parse it and write it
out. It could be as simple as:
if [[ "$always_yes" = "true" ]]; then
grep -v '^/etc/foo/bar$' /etc/conffiles/managed > "$tempfile" && cp
"$tempfile" /etc/conffiles/managed
if ! grep '^/etc/foo/bar$' /etc/conffiles/unmanaged; then
echo /etc/foo/bar >> /etc/conffiles/unmanaged
fi
fi
I may have the meanings of unmanaged and managed backwards :)
The root of this problem isn't that maintainers are changing config
files in postinst scripts; the root is that those scripts aren't smart
enough to parse those config files and preserve user changes.
> I don't think we should use Debconf to prompt on each package
> installation like this. Your proposal would make the "medium" debconf
> priority far more painful than it is even now. Just think about how
> many prompts you'd have to go through on an initial installation. It
> would be at least a hundred.
I dunno. I agree that it's unpleasant, but at least it'd only have to be
done once. (And that's a common strength in Debian; you usually only
need to do things once, as unpleasant as it might be. I think the
tradeoff has worked really well thus far.)
If /etc/conffiles/* *only* lists files that could possible be managed by
postinsts, then I could live with the question never being asked,
instead being maintained manually through editing /etc/conffiles.
> Basically, it seems to me that in your use case, the user could just:
> echo managed > /etc/conffiles/default
Yeah, I'm starting to think this.
> And then explicitly list those files they want to keep unmanaged in
> /etc/conffiles/unmanaged.
>
> Now, it would be nice if at the end of a package installation run, dpkg
> said something like:
>
> The following new configuration files have been installed:
> Managed:
> /etc/foo/foo.conf
> /etc/blah.config
> Unmanaged;
> /etc/whee/moo.conf
>
> That way if you see something you want to maintain yourself, you drop it
> into /etc/conffiles/unmaanaged.
Aaah. That's good, I like that.
But I dunno, the scenario I brought up would still remain. Even if a
file is in /etc/conffiles/managed, the user still needs to be asked if
it's okay to overwrite it, unless they tell the system otherwise.
How will we let them tell it otherwise?
I'm thinking in the "may I upgrade your configuration file?" question,
have the options I mentioned before ("no", "yes", "always-no").
With "no" and "yes" being one-time-only things, "always-no" removing the
line from /etc/conffiles/managed and adding it to
/etc/conffiles/unmanaged.
How's that sound? It's unobtrusive, only adding a third option. We
ensure that /etc/conffiles/* is *extroardinarily* easy to deal with (we
can have a tool to do this for us, akin to
update-rc.d/update-inetd/etc), they'll only get changed when the user
tells us to change them, they're perfectly capable of changing it
themselves manually, and we end up with no more questions than we have
now.
pgp0J7QWh2iZv.pgp
Description: PGP signature
Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]
On Fri Apr 18, 07:06pm -0400, David B Harris wrote:
> I'm thinking in the "may I upgrade your configuration file?" question,
> have the options I mentioned before ("no", "yes", "always-no").
>
> How's that sound? It's unobtrusive, only adding a third option. We
> ensure that /etc/conffiles/* is *extroardinarily* easy to deal with (we
> can have a tool to do this for us, akin to
> update-rc.d/update-inetd/etc), they'll only get changed when the user
> tells us to change them, they're perfectly capable of changing it
> themselves manually, and we end up with no more questions than we have
> now.
>
Gar. We'd still need always-yes to deal with the case I raised. Don't
like it, but ...
pgpwpHDeAJjRA.pgp
Description: PGP signature
Re: [david@eelf.ddts.net: Re: why do we care about configuration files?]
On Fri Apr 18, 06:37pm -0500, Manoj Srivastava wrote: > If you use ucf like mechanisms, and you acpet the first > debconf generated file, then you will never be asked to over write > your file -- since the md5sum of the installed file shall match the > previous maintainer version. Bingo, we cater to all these use cases > at once. Wouldn't that only be accurate if the postinst generated an identical config file every time? pgp88NKTvdObo.pgp Description: PGP signature
Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng
On Sat Apr 19, 10:22am +1000, Brian May wrote: > Any ideas? Share an initscript between them, if that's possible? pgp2vmAEIdmO0.pgp Description: PGP signature
Re: stop abusing debconf already
On Sat Apr 19, 11:18am -0500, Steve Greenland wrote: > On 19-Apr-03, 06:47 (CDT), Steve Kowalik <[EMAIL PROTECTED]> wrote: > > At 7:22 pm, Saturday, April 19 2003, Denis Barbier mumbled: > > > I do not understand exactly what is good and bad use of debconf. > > > For instance all questions asked by the debconf package have good default > > > values, so there is no reason to prompt user, a configuration file is > > > enough. So what am I missing? > > > > > Well, not all use of debconf is bad. For example, libnet-perl is a terrible > > misuse of debconf, *but* it can be remedied by dropping the priority of the > > questions from medium to low. > > Huh? If all the questions it asks can be converted to priority low, then > that means there are reasonable defaults, and therefore IT SHOULDN'T BE > USING DEBCONF AT ALL. > > How hard is this? What is so unclear about Policy on this topic? From debconf-devel(8): "low: Very trivial items that have defaults that will work in the vast majority of cases; oinly control freaks see these." pgpWKYL2Wz8BY.pgp Description: PGP signature
Re: stop abusing debconf already
On Mon Apr 21, 10:05am -0500, Steve Greenland wrote: > On 19-Apr-03, 11:44 (CDT), David B Harris <[EMAIL PROTECTED]> wrote: > > > > From debconf-devel(8): "low: Very trivial items that have defaults that > > will work in the vast majority of cases; oinly control freaks see > > these." > > If you have a package that is asking only medium and lower priority > debconf questions, then debconf should not be used at all. Those > priorities *exist* because there are packages that have a high-priority, > non-defaultable question, and once you've broken the conffile system, > you might as well include those questions. Perhaps it was a bad > idea. Another use for those lower priorities is for notes to the > admin. I contend that this second use *is* a bad idea, because the > common implementation is to NOT include the same information under > /usr/share/doc/, and thus those of us who have low and medium > priority turned off lose that info. I never said otherwise, and in fact I have followed that practice myself. pgpK4f2EaPA2M.pgp Description: PGP signature
Re: irssi-text - Not quite a release-critical bug
On Wed Apr 23, 09:35pm +0200, Wilmer van der Gaast wrote: > Bug 183186 seems to be stopping irss-text 0.8.6 from entering Sarge, but > IMHO the bug is not quite release critical. Botti is just a small part > of irssi, not used by 90% of the package users (at least, I think so). > (Maybe it should be split into a separate package anyway?) > > Can this bug be put back to normal priority? I can't even reproduce it in Sid's Irssi. pgpj8bLD1Ecma.pgp Description: PGP signature
Re: Time to package simpleinit?
On Sat Apr 26, 07:36pm +0200, Joachim Breitner wrote: > * The /etc/init.d/ scripts would need to add "need otherscript" (and > sometimes "provide something"). As I think it is a very bad idea to edit > these scripts in our post-install (and try to reedit them in > pre-remove)) one would have to file bugs agains packages with > /etc/init.d scripts. Will that be sucessfull? How cooperative will the > maintainers of these script be? I second Matthew Palmer and Henrique's sentiments. Matthew's in that if you do all the work for me, I'll merge it (likely quickly :). And Henrique's in that it needs to be fairly generic. pgp0FlsmzWqA1.pgp Description: PGP signature
Re: Lightweight Web browsers
To quote Aaron Lehmann <[EMAIL PROTECTED]>, > I think in principle glib may be a good idea, but it is overdone. I think I disagree. Look down the road five or ten years. Maybe at that point, there will be a good reason for gint to be different from the standard C int, but yet backwards-compatible with older gints. So you're right - there's no reason for it now. But as it stands, glib has a lot less inertia than glibc; there's a lot less pressure to keep things the same for long periods of time. So I think they were right to go for completeness, and leave it open-ended. Better to build one ten-lane highway than build five two-lane highways(for lots of reasons, and the analogy holds). David Barclay Harris, Clan Barclay Aut agere, aut mori. (Either action, or death.) pgpW77l7kLroh.pgp Description: PGP signature
Local Sid/unstable repository.
Hello there :) I'm looking to set up a local Debian mirror(for private LAN only, until we get more bandwidth), but only of the Sid/i386 distribution. Now, anonftpsync seems pretty good, but I can't get it to work properly. I've gotten it to --exclude the proper things, but, unfortunatly, dists/sid/main/binary-all points to woody. Okay, no biggie. So, I fiddle around more. The best I could get was Sid/i386, and all of Woody. Not very good. :) I have also tried absurd_debmirror. Unfortunatly, it doesn't seem to deal with package pools. So, am I missing something? :) I hope so. David Barclay Harris, Clan Barclay Aut agere, aut mori. (Either action, or death.) pgpyAYzGRErVa.pgp Description: PGP signature
Re: discrepancy in ISO 3166-1 country codes
On Thu, 20 Sep 2001 18:40:32 -0500,?f( Colin Watson <[EMAIL PROTECTED]> wrote:) q> On Thu, Sep 20, 2001 at 08:51:26PM +0200, Eric Van Buggenhaut wrote: > > Since your organization is the official authority for maitaining and > > ISO country codes, I extensively used your page > > http://www.din.de/gremien/nas/nabd/iso3166ma/ for the last, in need of > > a list of ISO 3166 country codes. > > > > The page web claims to list the ISO country codes as used in the > > Internet. > > > > I note that you list United Kingdom as GB although the TLD for United > > Kingdom, as everyone knows is UK. > > The TLD for the United Kingdom does not follow the corresponding ISO > country code, mainly for historical reasons. > > -- > Colin Watson [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] Hiii olkjsadflkja laskfakssfksj lkjasdlkj asdlf kj sdlfkj asdglkj sldkfj -- .--=-=-=-=--=---=-=-=. /David Barclay HarrisAut agere, aut mori. \ \Clan Barclay Either action, or death./ `---==-=-=-=-===-=---=--='
Re: Quake 2 sources GPL'd
On 21 Dec 2001 19:57:43 -0800, [EMAIL PROTECTED] (Thomas Bushnell, BSG) wrote: > Does this include any game levels? > > If it doesn't include any levels that a person can play, then it only > belongs in contrib. Only the engine has been GPL'd; all the artwork is still copyright Id Software. The only way you're legally allowed to use it is from purchasing the game itself. There's no reason why the engine itself can't be included in Debian, as far as I'm concerned. It doesn't absolutely *have* to have game data, to begin with(if you also care to look at the package as an educational one, anyways). Not only that, but in time there will be fully Free artwork available which people can then download and use with the engine. Come on ... this is a cool-factor thing, at least partially :) Having Quake II source in Debian would be pretty spiffy, if you ask me. And like I said, it'd be nice to be able to 'apt-get source quake2' and read what they've written. -- .--=-=-=-=--=---=-=-=. /David Barclay HarrisAut agere, aut mori. \ \Clan Barclay Either action, or death./ `---==-=-=-=-===-=---=--=' pgpc7bFId0sLy.pgp Description: PGP signature
Re: Quake 2 sources GPL'd
On Sat, 22 Dec 2001 14:37:48 +0100, Peter Makholm <[EMAIL PROTECTED]> wrote: > > There's no reason why the engine itself can't be included in Debian, > > as far as I'm concerned. It doesn't absolutely *have* to have game > > data, to > > But thats is an argument for putting all the stuff in contrib into > Debian main. Like I said, if you look at it from an educational percpective ... :) But yeah, I see your point. I think in my mind the big difference is in probability. Look at Lyx. It's in contrib because it requires libforms. Upstream isn't interesting in rewriting it to not use libforms, and I don't see any volounteers to come up with something a la lesstif. But with Quake2, you can be pretty damned sure that there will be at least dozens of people coming up with fully Free stuff that can be used as quake2-data. Maybe I'm splitting hairs, but I think that, at least morally, it's allright to put Quake2 in main. -- .--=-=-=-=--=---=-=-=. /David Barclay HarrisAut agere, aut mori. \ \Clan Barclay Either action, or death./ `---==-=-=-=-===-=---=--=' pgpA3vQt2kxt4.pgp Description: PGP signature
Re: Quake 2 sources GPL'd
On Sun, 23 Dec 2001 00:44:39 +1100, Hamish Moffatt <[EMAIL PROTECTED]> wrote: > On Sat, Dec 22, 2001 at 08:35:34AM -0500, David B Harris wrote: > > Come on ... this is a cool-factor thing, at least partially :) > > Having Quake II source in Debian would be pretty spiffy, if you ask > > me. And like I said, it'd be nice to be able to 'apt-get source > > quake2' and read what they've written. > > If it's just source (with no useful binary package), why should > it be packaged? Why can't you download it directly from the > web if it interests you? One word; 'debuild' :) See my response to <[EMAIL PROTECTED]> (Peter Makholm <[EMAIL PROTECTED]>: Re: Quake 2 sources GPL'd) for the rest of my feelings on the matter :) -- .--=-=-=-=--=---=-=-=. /David Barclay HarrisAut agere, aut mori. \ \Clan Barclay Either action, or death./ `---==-=-=-=-===-=---=--=' pgp5jgNiN2xQb.pgp Description: PGP signature
dbarclay10@yahoo.ca
pgpHhthiP6Qsp.pgp Description: PGP signature
Re: from potato to woody without a free internet connection
On Fri, 28 Dec 2001 21:58:34 +0100 "Tom Jongsma" <[EMAIL PROTECTED]> wrote: > I'm running debian potato right now. I want to upgrade it to Debian > Woody, but I don't have a free internet connection. Can I update my > potato by burning a cd on school. And Install it on my machine at > home? I can't find cd-images (iso's) of debian woody. > Aren't there cd-images of debian woody? This is a question for debian-user, not debian-devel. In case you just didn't notice that there *was* a debian-user, the answer to your question is "Woody isn't released yet. When Woody is a released Debian, ISO images will be available." Oh, and yeah, you should be able to upgrade via CD. :) Dave pgpkrqXt7S3Dh.pgp Description: PGP signature
Re: Debian.rpm
On Fri, 4 Jan 2002 17:56:58 +0100 martin f krafft <[EMAIL PROTECTED]> wrote: > it would be possible, you know. an RPM that basically substitutes > every installed RPM by the corresponding DEB. that would rock ;) Well, what you're suggesting isn't really feasible ;) But it would be feasible to package up a Debian chroot in an RPM. Too bad it would have to be huge to have a reasonable subset of useful Debian packages :) Dave pgprwdNgCi6O2.pgp Description: PGP signature
Re: Debian.rpm
On Fri, 4 Jan 2002 18:18:41 +0100 martin f krafft <[EMAIL PROTECTED]> wrote: > ps: please don't cc me on list responses. Yeah, my apologies. Hit the wrong keybinding :) pgpuw3oHQFncR.pgp Description: PGP signature
Re: Debian.rpm
On Sat, 5 Jan 2002 01:03:37 +0100 Wichert Akkerman <[EMAIL PROTECTED]> wrote: > > Well, what you're suggesting isn't really feasible ;) > > Someone actually did this a couple of years ago so it is feasible. Well, I'm kind of thinking he meant an automated procedure. To do a "real" upgrade, lots of things need to be done, like figuring out what's installed, figuring out what *to* install, so on and so forth. Considering we have no way to be relatively sure what a package on a Red Hat system really *is*(since .rpms are downloaded from everywhere, and rarely have a coherent naming scheme[though luckily our namespace isn't too crowded yet, so most things are allright])... Anyways, I'm just being anal :) I have actually "upgraded" a RH box to a Debian box, while it was running, but I'd still call it nontrivial, and rather extraordinarily difficult to automate. -- .--=-=-=-=--=---=-=-=. /David Barclay HarrisAut agere, aut mori. \ \Clan Barclay Either action, or death./ `---==-=-=-=-===-=---=--=' pgpPTsGtFjnbL.pgp Description: PGP signature
Bug#143548: ITP: ipm -- PHP-based tasklist/project management
Package: wnpp Version: N/A; reported 2002-04-19 Severity: wishlist * Package name: ipm Version : 0.9 Upstream Author : phlux <[EMAIL PROTECTED]> * URL : http://udpviper.com/project.php?project=ipm * License : GPL Description : PHP-based tasklist/project management IPM is short for the Incyte Project Manager. It is a featureful PHP-based project/task management system. While it doesn't integrate with any "groupware", it does its job simply and well - it manages tasks and projects made up of tasks :) -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux willow 2.4.18-xfs-a0 #1 Tue Apr 16 15:57:44 CDT 2002 i686 Locale: LANG=en_CA, LC_CTYPE=en_CA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
