News about the Package Tracking System
Hi folks, I just made an important change to PTS. Since the PTS email adresses have been available on the web, they start collecting a significant quantity of spam. As a first measure to avoid them I decided that any email sent directly to the PTS should be auto-approved. Auto-approval is easy, you just have to add an X-PTS-Approved header with a non-empty value. If you don't do that, you get a bounce (and the bounce explains you how to auto-approve your message). This change shouldn't affect too many people since the PTS is mostly used to receive information and not to send it. However if you were used to use the PTS for discussing with co-maintainers, you'll have to get used to add this header. Otherwise, the PTS continues its (slow) growth. Latest figures are : - 1274 source packages - monitored by 981 unique email adresses - totalizing 2044 subscriptions Currently I'm alone to manage the PTS and its evolution. I'd like this to change ... so I'm looking for people who are willing to help manage it. As a proof of interest, you only have to implement one (or more) of the items that still are on my TODO list ;-) Otherwise, applicants or future maintainers can also pick something to do and I may sponsor them or advocate them in return. So, what is there to do ? - Integrate the information from WNPP in the web interface (so that people can notice that the package is orphaned or looking for a new maintainer (O or RFA)) - Use a more elaborate anti-spam measure (whitelist with one-time confirmation for the first time, or something similar to that) - Check for the validity of the sender adress before sending a bounce (this is to reduce the volume of bounces that I receive because of the refused spams) That's what is the most important to me but you may of course have your own ideas about what needs to be added/done and I'll consider any patch. I can find many other things that would help (script to remove/disable/reenable a particular email address for example) but that's not priority one right now. So, you want to start hacking ? The sources are in the QA CVS : http://cvs.debian.org/pts/?cvsroot=qa (anonymous cvs access at :pserver:[EMAIL PROTECTED]:/cvs/qa, module pts) The working setup is installed in /org/packages.qa.debian.org/ on master.debian.org. Of course, I'll respond to questions concerning the code of the PTS. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com pgpJJzV1pW7V6.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
Trimmed CC: little; I can't imagine why this should go to -testing ... On Sun, Apr 20, 2003 at 02:49:36AM +0200, Marcel Weber wrote: All I can say to this is: use what you like, resp. if you don't like bloated software or spamware do not use it. My point is, that it should be a right of the original authors of the software to include credits. If someone else does a complete rewrite of the software, okay than we can discuss it, but if the rewrite means only the removal of the credits it is questionable. This is irrelevant. We're not questioning whether Hans Reiser has the right to license his own software to prohibit the removal of large messages. The questions being asked are: 1. Is software licensed in the manner Hans intends DFSG-free? That is, is it DFSG-free to require that interactive programs output a full page of sponsorship information? (That's a question for debian-legal.) If not, it can not be distributed in Debian and will be relegated to non-free. 2. Is the software licensed consistently? If not, it's probably not legally safe to distribute at all, and will be removed entirely unless Hans clarifies the licensing. Another question that comes to mind: has ReiserFS used code from projects licensed under the GPL? If so, he can not, in fact, place this extra restriction, as it would be in violation of GPL clause 6. This isn't a special issue for programs under completely different licenses; they know they're not GPL-compatible and don't use GPL code. However, when people use modified GPL licenses, they often don't realise that they can no longer use code from other GPL projects. But first of all, before we continue this discussion: What exactly has been removed? A readme file, the outputs during boot time, the outputs of mkfs.reiserfs? Has this output any impact on the usability of the software, so that there were good reasons the remove it? Has the license been violated by removing the credits? It's been suggested that the removed message is the one referenced in this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=152547 Impact and good reasons don't matter. Debian requires that users be granted the right to do certain things regardless of whether they have good reasons. If Hans doesn't want to grant those rights to users, that's may be his choice, but Debian won't distribute his software. -- Glenn Maynard
Re: old lib still needed
I am curious, how are we (err, Debian) supposed to deal with old libraries? I have been using uvscan by NAI, and aside from its being non-free it unfortunately depends on libstdc++ 2.8, which was previously available through the package libstdc++2.8_2.90.29-2.deb. This doesn't seem to be available anywhere now, for which reason I am hanging on to my local copy. It should be possible to obtain copies from previous releases, like Debian 2.2, or 2.1. As far as I know, Debian 2.2 is available through normal mirrors still, and Debian 2.1 is available at archive.debian.org. It is difficult to maintain old copies since tools evolve, and most old libraries now don't build from source on current Debian systems, depending on some special behavior of old compilers, etc. regards, junichi
Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng
On Sun, 20 Apr 2003, Brian May wrote: On Fri, Apr 18, 2003 at 08:51:51PM -0400, David B Harris wrote: Share an initscript between them, if that's possible? No, that would cause more problems trying to rename the existing amavisd-new conffile. Agreed. This is not something we should be doing at all. This is actually a big, ugly mess, for which the only sane alternative is to have a package-specific binary for amavisd-new or amavis-ng (actually, if we're going to do it the proper and fix-the-damn-thing-once-and-for-all way, ALL amavis packages). It is also a damn hole in Debian policy. That one I will propose a fix to: scripts that are conffiles MUST test if the package is in the installed state, and that test MUST either be done by checking for the presence of a *file* (and no other filesystem object!) that is specific for that package only in the entire distribution, or by querying the packaging system. We really should have a very fast script to query if a package is installed. lrwxrwxrwx root/root 0 2003-04-06 05:15:36 ./usr/sbin/amavisd - ../bin/amavis Why is this symlink required? Why does amavis-ng need to have two names? Looks like amavis-ng has both the amavis client and server functionalities built-in the same executable. If it decides what it should be doing based on its calling name... Anyway, yuck. I am glad I am using and co-maintaining amavisd-new now :) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng
On Sat, 19 Apr 2003, Ernst Kloppenburg wrote: yes. So maybe one of the packages should have its amavisd renamed. I have no problem with that (heck, it is a daemon). But this does not solve the entire Debian-wide problem that the amavis-* packages hit. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: plagiarism of reiserfs by Debian
On Sat, 19 Apr 2003, Travis Crump wrote: all that was removed was *code* that gets compiled. If the maintainer cannot arbitrarily change any code he wants, then it is not clear that the program is DFSG-free. THEN it is not DFSG-free, and needs to be dropped from Debian, or upstream needs to change the copyright. Note that I am NOT talking about reiser* here, I didn't check it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Do we need policy changes?
On Sun, 20 Apr 2003, Nikolai Prokoschenko wrote: The point is actually that deb??an (and others) doesn't care much about internationalization, no matter what they say. I'm just trying to be Go away. I hate trolls that make little of the work of others... If you think something is actively being i18n/l10n unfriendly, file a bug against that. The correct severity is either grave (if it is a required dependency of anything that is i18n/l10n-friendly, and thus it is breaking that thing's l10n/i18n support), or normal otherwise. And the fix for that bug might not be what you expect, AND still be a proper fix. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Bug#189347: stop the manage with debconf madness
Emile van Bergen [EMAIL PROTECTED] writes:
In most cases, the only feature that's used (and needed) of XML that it
stores a tree of attribute/value pairs.
Given limited effort, I am absolutely convinced that it should be
possible to come up with a more robust, well defined, simple(!), user
and implementor-friendly(!), do-one-thing-and-do-it-well way of doing
that.
Not by starting from we've got HTML which is being (ab)used for ad-hoc
RPC purposes, let's make a more general SGML application to do that
which became XML, but starting from the simple requirement stated above:
storing and transmitting nested trees of attribute/value pairs with a
*limited* number of possible data types.
I personally must say that I find the format of apt.conf satisfies
this goal admirably. It also easily allows one to easily override
some specific settings while leaving the rest in place.
For example, here's an apt.conf that I used when I was preparing an
upgrade CD for a machine that sat in a benighted place without network
access:
Dir /
{
// Location of the state dir
State var/lib/apt/
{
status /home/martind/lazarus/status;
};
Cache /home/martind/lazarus/aptchive;
};
Debug::NoLocking true;
Perhaps it has a few too many quoted strings, semicolons, and braces
for some people's taste, but it has the very distinct advantage that
it's already implemented in a program that's already on every Debian
machine.
Then there's always the format Sun came up with for java's .properties
files, which definitely wins the simplicity award, evne if trailing
spaces can sometimes bite the unwary.
Re: libc6 (security) update does not restart system-services?
On Sun, 20 Apr 2003 00:05:49 +0900 GOTO Masanori [EMAIL PROTECTED] wrote: Woody comes with libc6 2.2.5-11.5, so the section about restarting services is never reached. This leaves the machine vulnerable as all services use the old library until restarted. Shouldn't the services be restarted when installing a new libc-version? What reasons would there be not to restart services? But my concern is that running programs such as system services use the old libraries instead of the new one as long as they continue running, don't they? If they do the security bug is still exploitable though the new libraries are already installed on the system. Yes, right, good point. This is not only glibc issue; this problem affects all library packages. Yupp... I have to warn all users who believe that we needs only apt-get upgrade, yeah, that's all folks! concept. It's not true for this library upgrade issue. From our glibc upgrade experience, it's difficult to restart packages which have specific problem automatically... The simple method to detect old libraries are to use lsof, so debian package system can warn for users there are old libraries which has security problem, so you should restart these binaries. I don't know there is good way to fix this problem. As Bob pointed out in his message, searching for running programs using the old libraries using lsof and restarting the corresponding services _automatically_ is currently hardly possible. IMHO the best practice would be to check if a any version of glibc (or more generally the library-package just being installed) is installed already and is to be replaced by the new one. If any running programs are found, prompt the user an info-message to make sure to restart programs/services in order to benefit from the changes. This would actually only be necessary with either a security update or with major version changes (such as libc 2.1 - 2.2). While the latter is already dealt with by the postinst script, it would be necessary to know if the update is a simple new version's here-update or if it's a security-related one... That's probabely hard to decide for Testing and Unstable, I assume, but it is not for the Stable-tree where generally no updated versions (other than security-related) are to be installed. So at least for Woody, the warning message would be appropriate, I think. If everything _is_ designed not to restart the services, I suppose telling the users to take care of that theirselves would be a good idea for example using a simple echo in the post-install script(or similar). The restarting message is not sufficient for you? Of course, but the message is only shown if the services _are_ to be restarted (which is only when doing a major version update). Services are not restarted by the security update though I think they should be (as stated above). I think you confuse two issue. One is generic problem as I write above (memory resident libraries issue). Another is glibc NSS start problem as I write below. Or did you point the messages which are not appeared in libc6.postinst when you upgraded from 2.2 to 2.3 ? I was writing 'bout the echo-messages in Woody's glibc-version which inform the user about restarting services in case of upgrading from 2.1 to 2.2, so I suppose this is a similar case as 2.2 - 2.3. Anyway, I did not think of glibc NSS start problems ... As I've already mentioned, I actually don't know enough about the inside-workings of glibc and the corresponding techniques. I actually just thought about the memory resident libraries issue, yes. OK, now start to say about glibc NSS start problem. The reason why glibc needs to restart all NSS authentication services was written in my (a bit long) mail: http://lists.debian.org/debian-glibc/2003/debian-glibc-200303/msg00276.html The problem is dlopen(). Thanks for your explanation and the link. I'll check it out as soon as some spare time drops by... but this might take a while. :) Thanks too for clearing things up for me (still) definitely being more of a user than a developer. Cheers, Max -- The first time any man's freedom is trodden on, we're all damaged. Cpt. Picard, The Drumhead, StarTrek TNG http://homex.subnet.at/~max/
Re: stop abusing debconf already
On Sat, 19 Apr 2003 16:47:26 -0500, Steve Langasek [EMAIL PROTECTED] wrote: Um, no. *Policy* says that it may not be used as a registry. This has always prompted me to ask myself _why_ debconf entries are persistent then. If I _really_ have to parse config files in my config script to properly seed debconf to ask the right questions, then why does debconf have a database in the first place? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: libc6 (security) update does not restart system-services?
On Sat, 19 Apr 2003 18:04:01 +0200 Bernd Eckenfels [EMAIL PROTECTED] wrote: On Sun, Apr 20, 2003 at 12:05:49AM +0900, GOTO Masanori wrote: So everytime we have to restart all binaries which use a library involving security-problem. In additionm this problem affects not only debian packages, but user-built binaries. Well, this is why it is most often described in the security advisory. To be shure one can eighter use init 1 and get back to multi user mode, or use tools like lsof or my package of memstat to find loaded and deleeted libraries. I couldn't find any information about restarting programs and services (no matter what way) in DSA-282 (the corresponding DSA for the libc-update). Though I think it's a good idea to place such information in the DSA, I'd suppose an small notice this message in the postinst script (as described in my other mail) would be good as this information will reach those not reading the DSAs too. Cheers Max -- The first time any man's freedom is trodden on, we're all damaged. Cpt. Picard, The Drumhead, StarTrek TNG http://homex.subnet.at/~max/
Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng
On Sun, 20 Apr 2003 01:13:50 -0300, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: It is also a damn hole in Debian policy. That one I will propose a fix to: scripts that are conffiles MUST test if the package is in the installed state, and that test MUST either be done by checking for the presence of a *file* (and no other filesystem object!) that is specific for that package only in the entire distribution, or by querying the packaging system. In the last case, there should be a way to do this _easily_. Currently the only way to do this is parsing dpkg --list output, which is mucho ugly. To address the original problem: I think that amavis-ng needs to have its amavisd renamed, and I am working with the amavis-ng maintainer to do this. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Proposed handling of generated configuration files
On Sat, 19 Apr 2003 15:14:34 -0400, Matt Zimmerman [EMAIL PROTECTED] wrote: - Notice that a non-conffile, autogenerated configuration file has been modified by the user, and don't lose their changes - Use debconf for prompting That combination prompts a question: Why does dpkg not use debconf for the the conffile foo has changed locally, install package maintainer's version? script, and why are these questions not asked on pre-configuration time? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: stop abusing debconf already
On Sun, 20 Apr 2003 08:58:14 +0200, Marc Haber [EMAIL PROTECTED] said: On Sat, 19 Apr 2003 16:47:26 -0500, Steve Langasek [EMAIL PROTECTED] wrote: Um, no. *Policy* says that it may not be used as a registry. This has always prompted me to ask myself _why_ debconf entries are persistent then. So one does not have to answer the same question over and over on each install. If I _really_ have to parse config files in my config script to properly seed debconf to ask the right questions, then why does debconf have a database in the first place? Because not all debconf responses are stored in configuration files? Some debconf answers influence installation scripts behaviour, and never impact the installed program behaviour. manoj -- No problem is so formidable that you can't just walk away from it. Schulz Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sat, 19 Apr 2003 19:33:21 -0400, Matt Zimmerman [EMAIL PROTECTED] said: As was explained in detail, in order to do anything useful with that information, it is necessary to be able to show the user the proposed changes to the configuration file. It is completely unhelpful to say: You have modified this configuration file, and it has also been updated by the package maintainer. Do you want to replace it with the version provided by the package maintainer? Without showing the user the new version. Hmm. ucf does show the user the changes, and even offers to merge maintainer changes into the current configuration file. What functionality do you think ucf is missing? manoj -- quit When the quit statement is read, the bc processor is terminated, regardless of where the quit state- ment is found. For example, if (0 == 1) quit will cause bc to terminate. (Seen in the manpage for bc. Note the if statement's logic) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop abusing debconf already
On Sun, Apr 20, 2003 at 08:58:14AM +0200, Marc Haber wrote: | | This has always prompted me to ask myself _why_ debconf entries are | persistent then. If I _really_ have to parse config files in my config | script to properly seed debconf to ask the right questions, then why | does debconf have a database in the first place? | So that most of the time, you don't have to hit enter mindlessly to confirm the answers to questions that you've already answered when upgrading? Cameron.
Re: stop abusing debconf already
On Sat, 19 Apr 2003 20:17:16 +0100, Matt Ryan [EMAIL PROTECTED] said: Policy is what matters not the opinion of some jumped up developers! Conside rthis: when considering input from a ``jumped up developer'' who has demonstrated competence and has put in the effort like Joey Hess, and has intituted a couple of major changes in how Debian works, and an unknown twit, guess who am I going to listen to? manoj -- My dear People. My dear Bagginses and Boffins, and my dear Tooks and Brandybucks, and Grubbs, and Chubbs, and Burrowses, and Hornblowers, and Bolgers, Bracegirdles, Goodbodies, Brockhouses and Proudfoots. Also my good Sackville Bagginses that I welcome back at last to Bag End. Today is my one hundred and eleventh birthday: I am eleventy-one today! Tolkien Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop the manage with debconf madness
On Sat, 19 Apr 2003 20:21:14 +0100, Matt Ryan [EMAIL PROTECTED] said: Secondly, this isnot a witch hunt. What is being done is that a policy violation in older practice is being pointed out. Alternatives are being discussed; a witch hunt would have involved mass RC bug filings. The TEX discussion is definitely in witchunt territory. Maintainers Really? We are discussion a policy violation that causes loss of user changes, and you think this is a witch hunt? And You happen to be a developer. Seems like a flaw in the NM process (on the whole) try to make the best job they can of the packaging of their programs. Anyone can make mistakes. What is not helpful is when a developer gets a bad case of NOMUS (Not On My UNIX System) and goes off on one about how perfectly the world would be if everyone agreed with their narrow definition of the 'correct' way to do things. The recent /run debate was another example of this virulent disease taking hold amongst the vocal developer cabal. Really a flaw in the NM process. Don't we require peopel to acknowledge the importance of policy nowadays? Diversity is what keeps the human race going... Right. The hell with policy, since following policy is mind less conformance. Jesus. manoj -- There appears to be irrefutable evidence that the mere fact of overcrowding induces violence. Harvey Wheeler Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: New project proposal: debian-lex
On Sat, Apr 19, 2003 at 09:33:05PM +0200, Ralf Hildebrandt wrote: * Sami Haahtinen [EMAIL PROTECTED]: lex is the better word, as it is not only known in English, but also in most other (roman) Languages for law. Oh right, in finland there is a site finlex.fi, which is ofcouse obviously a site that contains the finnish law. This is the first time i've even heard the definition for 'lex', i support naming it debian-law, so that it's clear for the non-lawyers too. You forget that lex, legis (f.) is well known with lawyers. They'll immedialtely recognize it, since so many laws are of roman origin and many latin terms occur. Are you trying to tell me, that if the list is named debian-lex, more people will know what it means, than by naming it debian-law? I think i can claim that pretty much all the lawyers that attend the list, know english. Atleast enough to know what 'law' means. Regards, Sami -- - Sami Haahtinen - -[ Notify immediately if you do not receive this message ]- - 2209 3C53 D0FB 041C F7B1 F908 A9B6 F730 B83D 761C -
Re: Do we need policy changes?
On Sun, 20 Apr 2003 00:26:04 +0200, Nikolai Prokoschenko [EMAIL PROTECTED] said: What I think about is some regulated way to care about the needs of international debian users. Let's take an example: some programmplays badly along with UTF-8 and therefore can't be properly used by me, as I need e.g. both German and Russian. I can as well file a bug against it, but it wouldn't matter much, as the maintainer would just say 'it's not supported upstream' and nothing would happen. And what exactly have *YOU* done about it, apart from whinging? manoj -- Your mother was a hamster, and your father smelt of elderberrys! Monty Python and the Holy Grail Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Do we need policy changes?
On Sun, 20 Apr 2003 02:05:33 +0200, Eduard Bloch [EMAIL PROTECTED] said: A point. What *is* yours? Read. Just read and try with imagination. = Better, flexible and _smooth_ i18n in debian-desktop. Something userfriendly but not easy to achieve without conditional dependencies, debconf config with controllable queue order and some other things I have already told about in the past :( Apart from telling various and sundry people about it, have you done anything? This is free software. If it scratches youtr itch, fix it. And send patches. manoj -- Windows NT Beer: Comes in 32-oz. cans, but you can only buy it by the truckload. This causes most people to have to go out and buy bigger refrigerators. The can looks just like Windows 3.1 Beer's, but the company promises to change the can to look just like Windows 95 Beer's -- after Windows 95 beer starts shipping. Touted as an industrial strength beer, and suggested only for use in bars. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: plagiarism of reiserfs by Debian
On Sat, 19 Apr 2003 20:24:21 +0100, Matt Ryan [EMAIL PROTECTED] said: You really need to calm down. Twice now recently you have opened your mouth and stuck your foot in when there really wasn't any need to. Take a Valium and do something less stressful. Heh. First you bad mouth Joey Hess. And now you go up against Ben Collins. And both times you take what I consider impolitic stances that show poor judgment (even ignoring the fact that you are, with nothing whatsoever to back it up) some of the most respected developers in Debian. I applaud this masterly demonstration of a nadir of cluelessness. I suppose this is accomplishment of a sort. manoj -- This fortune would be seven words long if it were six words shorter. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
debian-devel@lists.debian.org
E-mail , E-mail Forrester Research2001 E-mail200052.3%611 20032400E-maileMarketer61% 70% http://emving.126.com [EMAIL PROTECTED]
Re: Do we need policy changes?
Moin Henrique! Henrique de Moraes Holschuh schrieb am Sunday, den 20. April 2003: On Sun, 20 Apr 2003, Nikolai Prokoschenko wrote: The point is actually that deb??an (and others) doesn't care much about internationalization, no matter what they say. I'm just trying to be Go away. Come on, is fscking wish reports a good way to communicate with users? If you think something is actively being i18n/l10n unfriendly, file a bug against that. The correct severity is either grave (if it is a required Against what? Who is to blame? Who cares? For example, as user, I would like mlterm to work with UTF8 out of the box when I install (bogus) utf8-environment package plus language-ru? See #186983 and tell us how you, as maintainer, could _ensure_ that the damn thing works (with the best font for this charset environment) _and_ works like the user expects it. Yes, you may say that this is something debian-desktop should work with, but a) who is debian-desktop and b) how should debian-desktop (whoever it is, most likely the each maintianer) deal with it without having a sane structure to make things flexible? And before you do not have the answer or if you did never work in a complelete UTF-8 environment at all (or permanently charset-switching environment), please think twice befre you raise your voice. dependency of anything that is i18n/l10n-friendly, and thus it is breaking that thing's l10n/i18n support), or normal otherwise. And the fix for that bug might not be what you expect, AND still be a proper fix. Oh please, he is a pure USER. It is nasty to deal with charset switching in every program, you have to find out how to do it, you have to find out what maintainers forgot, you have to do some research with apt-cache to locate and replace some packages with the UTF-8 versions. I do not say that UTF-8 support on Debian is generaly bad (or worse than with other distributions), but the last (user-relevant) step of the setup is not user-friendly at all. MfG, Eduard. -- Wir wissen nicht was wir tun, das aber mit System!
Re: New project proposal: debian-lex
On Sat, 2003-04-19 at 15:33, Ralf Hildebrandt wrote: * Sami Haahtinen [EMAIL PROTECTED]: lex is the better word, as it is not only known in English, but also in most other (roman) Languages for law. Oh right, in finland there is a site finlex.fi, which is ofcouse obviously a site that contains the finnish law. This is the first time i've even heard the definition for 'lex', i support naming it debian-law, so that it's clear for the non-lawyers too. You forget that lex, legis (f.) is well known with lawyers. They'll immedialtely recognize it, since so many laws are of roman origin and many latin terms occur. I would have to vote for debian-law, because while lex might be recognizable by lawyers, everyone who sees it is not going to be a lawyer. A good sized portion of them, in fact, will be software developers. The first impression such a person would encounter would be to associate it with something like flex, as mentioned before. I think debian-law would create a lot less confusion than debian-lex, but IANADD so just my two cents. Mike
Re: Do we need policy changes?
Nikolai Prokoschenko [EMAIL PROTECTED] writes: My problem was: everybody was acting like mad, screaming at last, some good fonts for linux!, whereas, as far as I remember, these fonts lacks many many scripts, starting with the simpliest ones like Cyrillic. I don't even want to mention double-width characters. The What do you suggest? Shouldn't we package these fonts before they are of use to everybody? used by me, as I need e.g. both German and Russian. I can as well file a bug against it, but it wouldn't matter much, as the maintainer would just say 'it's not supported upstream' and nothing would happen. Other What do you suggest? Well at least the maintainer should probally forward the bug upstream and mark it forwarded. Not that this alone would help very much. The only way to really improve the general situation is if someone who cares does the work. For exampel the IPv6-developers has done a lot of work this way. Finding packages with disabled IPv6-support finding patches and pushing them upward a that kind of stuff. You as utf8-interrested have to do the same to improve the situation. language environments had been (I'm just speculating) a part of Debian Policy. In that case, package at least could have been marked as 'non-functioning under non-latin circumstances' and this could We have the BTS for this kind of information. And why should we pull packages that works 95% of the time? That would be damaging. Please find some way to improve the situation without doing great harm to those statisfied with status quo. If you force people to put a lot of work in something they don't want they are going to be even more resisting changes. Thank you for your time, and you want to tell me I'm paranoid, don't bother, it is not worth your time :) Better tell me what I might have missed in the observing the subject. I doesn't think any of the above counts as paranoia which obvious doesn't mean that you aren't paranoid. What you have missed? Probally some basic facts of how stuff is done with the least damage. -- Peter Makholm | I have no caps-lock but I must scream... [EMAIL PROTECTED] | -- Greg http://hacking.dk |
Re: foo has reached testing, removing versioned build-depends?
On Sat, Apr 19, 2003 at 03:50:23PM +0100, Colin Watson wrote: I've read the changelog and the bug report closed by that earlier change, and removing the version still makes no sense. If earlier versions of debiandoc-sgml produce incorrect output, as reported, then the versioned build-dep should be left there, as it will help people trying to build with older versions to know what the problem is. There is no problem with older versions, only with buggy versions. Some debiandoc-sgml version (not the one in woody e.g) produced incorrect output with a lot of package, not just menu, but fortunately this caused only a minor problem. I do not know the exact versions where this problem occured, and probably some others versions had worse problems as well. I was nder the impression that builddeps were not to be used to avoid using buggy packages. Sometime packages with bugs are uploaded, eventually fixed packages are uploaded, but the detail about that belong to the package changelog, not to other packages control files. The only reason I have used versionned builddeps in the first place was to ensure the buildd pick up a fixed version, now the risk is gone, so I have removed it. In the same vein, should I write the complete list of g++ version that are known to misbuild menu on at least one arch ? Cheers, -- Bill. [EMAIL PROTECTED]
Re: Accepted openldap2 2.1.17-1 (i386 source)
Quoting Torsten Landschoff [EMAIL PROTECTED]: Source: openldap2 Binary: slapd libldap2 ldap-utils libldap2-dev Version: 2.1.17-1 Changes: openldap2 (2.1.17-1) unstable; urgency=low [...] openldap2.1 (2.1.16-1) unstable; urgency=low Was this such a clever idea? Shouldn't the new upload ALSO be named 'openldap2.1'? -- Ft. Meade smuggle kibo BATF assassination explosion Honduras pits president tritium PLO colonel FSF Marxist $400 million in gold bullion [See http://www.aclu.org/echelonwatch/index.html for more about this]
Re: debconf review of cvsd (was Re: stop abusing debconf already)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arthur de Jong wrote: Ok, could you review my cvsd package for me for correct debconf usage and tell me what you do and don't like? Thanks for taking advantage of that offer. (So far you're the only one.) I am ccing this to -devel just because. All of the debconf questions are pretty well worded and clear, but there's always room for improvement: Thanks for the review. I've changed most of the wording according to your suggestions (English isn't my native language). s/zero (0)/0/ # Apparently writing it out has the possibility to make # someone enter the number the wrong way so why not just # not write it out? I spelled out zero because some (most) fonts don't represent 0 differently from O. Same goes for 1 and l. - It's sort of odd that you use spaces to separate multiple items in one question, and then colons to separate them in the next. It would be nice if debconf would have some unified way of entering lists. I'm also not very happy with the way it is currently done, but I've modeled it after the cvs questions and a colon is the standard seporator for directories, while using : in addresses may provide problems with IPv6 addresses (improving this is on my TODO list). - I was fairly confused by cvsd/limit_memorylocked, because I thought that only programs run as root could lock memory, and why would cvs want to? Was this just added for (over)completeness? Probably. I provided questions for all the limits I could find. The code also covers limits for things that are not settable on linux (there is even a debconf question about it that is never asked). - You have no translations for the debconf templates in the package. The DDTP project has a complete German translation at http://ddtp.debian.org/debconf/source/cvsd. Of course you may want to make the above changes first, and wait for an updated translation.. I have received a Brazillian translation of the debconf questions that I'm merging into cvsd (bug #187795). I saw the German translation at http://ddtp.debian.org/cgi-bin/ddtp.cgi?part=debconfpackage=cvsd before but I never saw the page you linked (very useful page but I can't find it linked from the site). And since the site says (Now) we don't need any action from the debian package maintainer. I didn't take any action regarding the translation. If I reconfigure cvsd, pick all the limits, and take the default value for everything else, it exits with code 20: debconf (developer): -- GET cvsd/limits debconf (developer): -- 0 coredumpsize, cputime, datasize, filesize, memorylocked, openfiles, maxproc, memoryuse, stacksize, virtmem debconf (developer): -- GET cvsd/limit_coredumpsize cputime datasize filesize memorylocked openfiles maxproc memoryuse stacksize virtmem debconf (developer): -- 20 Incorrect number of arguments zsh: exit 20DEBCONF_DEBUG=. dpkg-reconfigure cvsd Looks like a bug.. After doing this I also did not see all the limits stuff in cvsd.conf, it had only these config items: Uid cvsd Gid cvsd PidFile /var/run/cvsd.pid RootJail /var/lib/cvsd MaxConnections 10 Nice 1 Listen * 2401 This looks like it may be due to a bug (or incompatibility) in zsh. Do you have /bin/sh set to zsh? I have some strange results if I use zsh to process the postinst. I'll do some more testing. Somehow the result of the 'GET cvsd/limits' is passed to the next command. Looking at your priorities, I'm not sure why the maximum connection limit is at priority medium. I already changed it to low for the next release (couldn't remember either why it was set to medium). I've set it up to ask first whether to use debconf to manage configuration of /etc/cvsd/cvsd.conf (not a conffile). If the user chooses to not use debconf, he's on his own (an example cvsd.conf is provided). Of course this is where in my opinion you lose. First of all, as Colin pointed out recently, any question that asks use debconf and defaults to true results in the package violating debian policy on any system where the debconf priority is higher than the question, or noninteractive mode is used. If the question is not shown to the user at all, and a default config is put into place, and the user edits that config and loses changes on upgrade, then you've violated policy. Secondly of course, I hate all use debconf questions. It's the wrong way to use debconf; you should be intelligently parsing answers out of the file on reconfigure and upgrade, and intelligently editing them back into the file, so you do not lose an admin's modifications or comments. No config file in debian should have warnings at the top about not editing it. I wince every time I see another do not edit this file; I consider every one at least one user lost to gentoo or some other distribution. I also don't like the question and would rather see it removed. I was working
Re: New project proposal: debian-lex
On Sat, 2003-04-19 at 23:57, Andreas Tille wrote: On 19 Apr 2003, Jeremy Malcolm wrote: I am interested in coordinating a new sub-project called Debian-Lex, Could you please explain the naming lex for non English speakers? In general I really like your idea because I think those internal projects are an important way to fit the needs of our users. I would recommend to read the slides of my talk about internal projects and also follow rhe link to the Subproject HOWTO. OK, thanks. Here (http://people.debian.org/~terminus/debian-lex/) is a rough Web page which I have shamelessly plagiarised from your Debian-Med project. I will contact the appropriate people in the mailing list and Web page groups to see if we can get this formalised. I have a preliminary list of packages (or proposed packages) that I would want to see as part of Debian-Lex, and I will contact those developers also. -- JEREMY MALCOLM [EMAIL PROTECTED] Personal: http://www.malcolm.id.au Providing online networks of Australian lawyers (http://www.ilaw.com.au) and Linux experts (http://www.linuxconsultants.com.au) for instant help! Disclaimer: http://www.terminus.net.au/disclaimer.html. GPG key: finger. signature.asc Description: This is a digitally signed message part
Re: plagiarism of reiserfs by Debian
Andreas Dilger [EMAIL PROTECTED] writes: [...] I'm sure all the FSF/Debian folks would be thrilled if someone changed the code in [x]emacs to not output anything about the GPL at startup, or if vim didn't include any info about helping Ugandan orphans. XEmacs and Emacs follow sensible guidelines: if you start them without any arguments, then they display useful information, including information about the GNU GPL. If you start them such that they can usefully display something else (like a filename that you want to edit), then they don't display the other information, and you don't get reminded about the GNU GPL. So the information isn't thrust in anybody's face: if you don't give it any arguments, Emacs doesn't have anything else it might display, so it may as well display information about itself (how to get help, conditions of copying, etc.). To remove this code would be a bad technical decision---there's no reason to. I presume (if any code has been changed) that some of the reiserfs code is doing something that's less technically justifiable. (I don't know about vim.) [...]
Re: plagiarism of reiserfs by Debian
[ I wrote this yesterday when I first saw Hans' message on -devel, but
postponed it to let the people who have actually had something to do
with this to speak up. But it seems that I was right when I assumed
people wouldn't really know what this is about. So, stamp a big FYI
on this post. Don't Cc me, I'll follow the discussion on -devel.
Thanks. ]
On Sat, Apr 19, 2003 at 08:07:03PM +0400, Hans Reiser wrote:
Please explain your reasons for removing the credits and attributions
from the reiserfs utilities in violation of our copyright.
Just for the benefit of people who don't have any idea what Hans is
talking about, the following text is printed by (upstream's but not
Debian's) mkreiserfs before exiting:
The Defense Advanced Research Projects Agency (DARPA) is the
primary sponsor of Reiser4. DARPA does not endorse this project;
it merely sponsors it.
Continuing core development of version 3 is mostly paid for by
Hans Reiser from money made selling licenses in addition to the
GPL to companies who don't want it known that they use ReiserFS
as a foundation for their proprietary product. And my lawyer
asked 'People pay you money for this?'. Yup. Hee Hee. Life is
good. If you buy ReiserFS, you can focus on your value add
rather than reinventing an entire FS. You should buy some free
software too
SuSE pays for continuing work on journaling for version 3, and
paid for much of the previous version 3 work. Reiserfs
integration in their distro is consistently solid.
MP3.com paid for initial journaling development.
Bigstorage.com contributes to our general fund every month, and
has done so for quite a long time.
Thanks to all of those sponsors, including the secret ones.
Without you, Hans would still have that day job, and the merry
band of hackers would be missing quite a few
Have fun.
In the academic world, this is called plagiarism. In the academic
world, knowledge is shared but fairly credited. The GPL is born of
the academic tradition.
JFTR:
plagiarism
n 1: a piece of writing that has been copied from someone else
and is presented as being your own work
2: the act of plagiarizing; taking someone's words or ideas as
if they were your own [syn: {plagiarization}, {plagiarisation},
{piracy}]
Marcelo
Re: ITO: searching new maintainer for gworkspace package
* Paul Seelig [EMAIL PROTECTED] [2003-04-10 15:28]: here's your Debian package maintainer (still) for the gworkspace package writing. I want to get rid of the gworkspace package and wanted to first ask here before i move on to simply orphan the package via bug report. Has anyone volunteered? If not, I think it's time to file a WNPP bug. -- Martin Michlmayr [EMAIL PROTECTED]
Re: Do we need policy changes?
On Sun, 20 Apr 2003, Eduard Bloch wrote: On Sun, 20 Apr 2003, Nikolai Prokoschenko wrote: The point is actually that deb??an (and others) doesn't care much about internationalization, no matter what they say. I'm just trying to be Go away. Come on, is fscking wish reports a good way to communicate with users? Of course it is not. But you get the treatment you ask for... and being insulting IS asking to be ignored or insulted back. Since it is an user report, I was quite civilized... If you think something is actively being i18n/l10n unfriendly, file a bug against that. The correct severity is either grave (if it is a required Against what? Who is to blame? Who cares? For example, as user, I would like Well, you don't have to care much about it. Any Debian maintainer worth the name knows how to reassign bug reports. mlterm to work with UTF8 out of the box when I install (bogus) utf8-environment package plus language-ru? See #186983 and tell us how you, as maintainer, could _ensure_ that the damn thing works (with the best font for this charset environment) _and_ works like the user expects it. Ensure? I would create a sub-project Debian-desktop-RU that had all defaults tweaked so that it would work. I don't think there is anything else you can do that will *ensure* it will always be at best .ru condition. There is also the often-forgotten X resources. Configure everything correctly through it... It is not impossible to get all packages to cooperate enough that you can do so. And a X term that can't handle resources is so broken, it deserves a grave bug to keep it out of Debin stable until it learns to do so [I am speaking this with my Debian QA hat on]. Then package the resources and call it debian-desktop-ru or something. but a) who is debian-desktop and b) how should debian-desktop (whoever it is, most likely the each maintianer) deal with it without having a sane structure to make things flexible? Well, what is missing to have this sane structure? Propose it well enough, and if someone that can implement it starts, it will be done. THAT IS HOW DEBIAN WORKS. And the fix for that bug might not be what you expect, AND still be a proper fix. Oh please, he is a pure USER. It is nasty to deal with charset switching I don't know if you noticed yet, but being a pure user in Debian does not mean we will assume you are a braindead moron that cannot think or learn for yourself. That is exactly what set us appart from other distros. And yes, this DOES have its drawbacks sometimes. other distributions), but the last (user-relevant) step of the setup is not user-friendly at all. Then work at improving it. UTF8 in Debian is _very_ imature still, and even a how to make your package UTF-8 friendly document that you could write (and posted to d-devel and d-desktop if you don't know better places to put it in, since someone will read it and update the other stuff with it if it is good enough) would help things immensely. But don't be insulting at the people who DO spend a lot of effort with l18n while you're at it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng
On Sun, Apr 20, 2003 at 09:00:51AM +0200, Marc Haber wrote: In the last case, there should be a way to do this _easily_. Currently the only way to do this is parsing dpkg --list output, which is mucho ugly. I'd actually prefer the file check, and not involve the packaging system in the day-to-day running of the system. (Example: if I'm installing and configuring a firewall, I'd like to be able to delete the dpkg files from the final image before flashing it.) Richard Braakman
Re: Do we need policy changes?
On Sun, Apr 20, 2003 at 10:34:10AM +0200, Eduard Bloch wrote: Henrique de Moraes Holschuh schrieb am Sunday, den 20. April 2003: Go away. Come on, is fscking wish reports a good way to communicate with users? Yes. If they say things like deb??an (and others) doesn't care much about internationalization, no matter what they say, then they should be told to go away. That kind of shit just demoralizes the people who are doing the work. Richard Braakman
dpkg conffiles merging - request for status summary
Just to bring the uninitiated like me up to date about ways to upgrade changed dpkg conffiles, I would greatly appreciate if someone with insight could summarize the current status: + How emotional has the discussion on this topic been in the past? Scale: 0 (mostly technical) ... 5 (flamewars) ... 9 (new religion) + Are there some specific reasons why dpkg doesn't offer merge interactively in addition to keep old, install new, show diff and shell when upgrading a package with changed conffiles or is it just a feature that nobody has tried to implement yet? + Does dpkg currently save the original conffiles somewhere to make 3-way merging possible? + If I understand correctly, ucf has some merging features. Can it be used as an alternative for dpkg's conffile upgrade interface or is it meant solely for postinst scripts? + I recently proposed using generic configuration file parser program(s) for editing and upgrading simple config files directly without saving the same options in many places at the same time. Have such tools been discussed and/or tried before in the Debian project? + I can program and find this problem interesting. Would some of you authors/maintainers of related tools appreciate help in developing configuration management features? - Jarno
Re: Do we need policy changes?
On Sun, Apr 20, 2003 at 02:28:13AM +0200, Nikolai Prokoschenko wrote: Andrew Suffield [EMAIL PROTECTED] wrote: Thank you for your time, and you want to tell me I'm paranoid, don't bother, it is not worth your time :) Better tell me what I might have missed in the observing the subject. AS A point. What *is* yours? The point is actually that deb??an (and others) doesn't care much about internationalization, no matter what they say. I'm just trying to be diplomatic,???not to risk a 'Do It Yourself' Answer. I'd like to have solutions. There's no magic wand for i18n/l10n. Every application has to be handled individually, and every language needs some global tuning before stuff will work right. We can't do anything about general stuff like this, because it's open-ended. Pick specific stuff that you care about and see what can be done with it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpyPMAKBX9mK.pgp Description: PGP signature
Re: Do we need policy changes?
On Sun, Apr 20, 2003 at 02:05:33AM +0200, Eduard Bloch wrote: #include hallo.h * Andrew Suffield [Sun, Apr 20 2003, 12:29:49AM]: On Sun, Apr 20, 2003 at 12:26:04AM +0200, Nikolai Prokoschenko wrote: Thank you for your time, and you want to tell me I'm paranoid, don't bother, it is not worth your time :) Better tell me what I might have missed in the observing the subject. A point. What *is* yours? Read. Just read and try with imagination. Lengthly and vague and it's easier for me to ask him to get to the point than to read through it all. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpy8JcXYh58A.pgp Description: PGP signature
Re: Do we need policy changes?
And why should we pull packages that works 95% of the time? One of the release goals for Woody (I believe) was that everything is 8-bit clean. The same could have been said for that; why should we pull packages that work 95% of the time? (And if 8-bit cleanness is not 95% of the time, then neither is not handling UTF-8, considering that's requirement for India, home of over a sixth of the world's population.) -- David Starner - [EMAIL PROTECTED] Ic sæt me on anum leahtrice, ða com heo and bát me!
Re: debconf review of cvsd (was Re: stop abusing debconf already)
Arthur de Jong wrote: I have received a Brazillian translation of the debconf questions that I'm merging into cvsd (bug #187795). I saw the German translation at http://ddtp.debian.org/cgi-bin/ddtp.cgi?part=debconfpackage=cvsd before but I never saw the page you linked (very useful page but I can't find it linked from the site). And since the site says (Now) we don't need any action from the debian package maintainer. I didn't take any action regarding the translation. I think they want thier translations to be used, but I don't really know. Don't expect the DDTP to make things very useful or organized though. :-/ I have a script that can automatically download translations from the DDTP, it's only a prototype however. If I reconfigure cvsd, pick all the limits, and take the default value for everything else, it exits with code 20: debconf (developer): -- GET cvsd/limits debconf (developer): -- 0 coredumpsize, cputime, datasize, filesize, memorylocked, openfiles, maxproc, memoryuse, stacksize, virtmem debconf (developer): -- GET cvsd/limit_coredumpsize cputime datasize filesize memorylocked openfiles maxproc memoryuse stacksize virtmem debconf (developer): -- 20 Incorrect number of arguments zsh: exit 20DEBCONF_DEBUG=. dpkg-reconfigure cvsd Looks like a bug.. After doing this I also did not see all the limits stuff in cvsd.conf, it had only these config items: Uid cvsd Gid cvsd PidFile /var/run/cvsd.pid RootJail /var/lib/cvsd MaxConnections 10 Nice 1 Listen * 2401 This looks like it may be due to a bug (or incompatibility) in zsh. Do you have /bin/sh set to zsh? I have some strange results if I use zsh to process the postinst. I'll do some more testing. Somehow the result of the 'GET cvsd/limits' is passed to the next command. My /bin/sh is dash. Looks like there must be some problem in the for loop that is not splitting the RET on words. Reading the current configuration is almost finished and will go into the next release. I'll look into editing the existing configuration file rather than overwriting it. I ran into some problems earlier though (especially things like where do you put new configuration options that were not there before). Also Limit, Repos and Listen may be specified multiple times so that may be tricky. Remember you can use perl for either the config or the postinst script. Might make the more complicated stuff more maneagable. I'm glad you're making progress on this. -- see shy jo pgpojKvSKBZdx.pgp Description: PGP signature
Re: Bug#189566: amavisd-new: bad interaction with package amavis-ng
On Sun, 20 Apr 2003 15:54:23 +0300, Richard Braakman [EMAIL PROTECTED] wrote: On Sun, Apr 20, 2003 at 09:00:51AM +0200, Marc Haber wrote: In the last case, there should be a way to do this _easily_. Currently the only way to do this is parsing dpkg --list output, which is mucho ugly. I'd actually prefer the file check, and not involve the packaging system in the day-to-day running of the system. That way, one would need to have a special tag file in the package, since every file in real use of the package can potentially be present in a conflicting package as well. Maybe the init scripts should check an md5sum of the file they intend to invoke before doing so? But that wouldn't solve the problem for inetd configuration left around for example. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Common Policy Proposal
Dear Debian and Chad: Is it possible for you to assist me by sharing with me a framework for a common defence and security policy proposal. I would be most grateful if you can share with me this information at your earliest possible convenience. Happy Easter, Wafula -- __ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup
Re: Do we need policy changes?
On Sunday 20 April 2003 10:09, Manoj Srivastava wrote: Apart from telling various and sundry people about it, have you done anything? This is free software. If it scratches youtr itch, fix it. And send patches. The original author stated that it occurs that upstream rejects UTF-8 fixes and the like. So, here's my proposal, Nikolai: Make a public webpage with a list of all projects which reject such fixes, and/or maintainers who claim that their upstream rejects such fixes. Add a column to this list with applications and libraries which lack proper support, so people can see where it's worth working on improvements and where it's worth checking out alternative projects if nothing happens after some time. Further improvements can be accellerated by adding support on development tools (for instance automake still cannot handle i18n'd manpages), even though this is not always easy to do. Another example: The German translation of passwd(1) is from 1993, and is plain wrong. The way to handle such issues is not to complain, but to run: apt-cache show `dpkg -S /usr/share/man/de/man1/passwd.1.gz | cut -d : -f 1` | grep Maintainer ...and to send the guy in question a mail with an updated manpage (or use the BTS in more complicated cases, or send it to upstream directly where it makes sense). Sarge will have an updated version, because I cared about it :) Josef -- Play for fun, win for freedom.
Re: New project proposal: debian-lex
On Sat, Apr 19, 2003 at 01:41:51PM -0400, Daniel Burrows wrote: I am interested in coordinating a new sub-project called Debian-Lex, Could you please explain the naming lex for non English speakers? It's latin, not english. :-) It means law. I strongly urge you to change it to something like Debian-Law, or everyone will think you're creating a subproject for regexp-based tokenizers :-) (or maybe libraries, which was my second guess from your subject line) I should point out that there are probably more lawyers than software developers in the world, so your point can be reversed. rant If english people don't even know what lex means, they should make a damn effort and and learn it, or at least try to see if they can. The rest of people on Earth using computers have been having headaches learning stupid english slang words like widgets, gadgets or applets for years: show at least some respect, damnit. /rant With love, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED] pgpsyRcaUpuo0.pgp Description: PGP signature
ITA: mpich: Parallel computing system
Package: wnpp Severity: wishlist Greetings, I'm in the process of adopting mpich from Junichi Uekawa. This is at Junichi's request, as described on the debian-beowulf list a few days ago. Zeen, -- -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg
Re: why do we care about configuration files?
I demand that Anthony DeRobertis may or may not have written... Is it just me, or would this fix the problem simply: 1) If a postinst generates a configuration file with debconf, it must place the md5sum of the generated configuration file in /var 2) A package should try and parse the current configuration file back into debconf before prompting. 3) After prompting, the package must confirm that the current md5sum matches the one stored in /var. If it does and the package succeeded at (2) it may replace the configuration file. Otherwise, use ucf. 4) The user edits the configuration file (I'd changed that to do foo), then notices that his extra configuration text has gone missing, along with his comments as to why the change was made. And it's all been restored to the original layout, and he finds it harder to follow when it's formatted like that... 5) Said user happens finds your message and some followups, and agrees that you were probably too tired to think straight... ;-) -- | Darren Salt | nr. Ashington, | linux (or ds) at | woody, sarge, | Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk | Oh, sarge too... Avoid run-on sentences they are hard to read.
Re: New project proposal: debian-lex
rant If english people don't even know what lex means, they should make a damn effort and and learn it, or at least try to see if they can. The rest of people on Earth using computers have been having headaches learning stupid english slang words like widgets, gadgets or applets for years: show at least some respect, damnit. /rant Ouch, punch taken.. There's a difference here, however. 'Lex' is an academin slang word for which a common language alternative exists, 'law', while 'widget' is the only name for the thing it represents. Debian-law is not an optimal name either, though. It feels like the package contains The Debian Law that every user must follow. (And makes Debian-policy sound like it's a project for making Debian suitable for the police.. :]) Don't mind us detailists, the project is an ambitious and admirable one. You have the right to name it however you like - and if it sounds good to a member of its intended audience, it's probably good. =) - Jarno
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, Apr 20, 2003 at 02:45:32AM -0500, Manoj Srivastava wrote: Hmm. ucf does show the user the changes, and even offers to merge maintainer changes into the current configuration file. What functionality do you think ucf is missing? In my first message, I listed bullet points for goals, most of which ucf meets, and then outlined the problems with this model, and linked to previous threads discussing them in detail. http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01320.html -- - mdz
Re: debconf review of cvsd (was Re: stop abusing debconf already)
On Sun, Apr 20, 2003 at 12:03:40PM +0200, Arthur de Jong wrote: s/zero (0)/0/ # Apparently writing it out has the possibility to make # someone enter the number the wrong way so why not just # not write it out? I spelled out zero because some (most) fonts don't represent 0 differently from O. Same goes for 1 and l. In this case, I would suggest putting the word, not the number, in parentheses: 0 (zero). Regards, -- Steve Langasek postmodern programmer pgpQhQ4mvmpq0.pgp Description: PGP signature
Re: md5 checksums
On Thu, Apr 17, 2003 at 02:11:49PM +0200, Josip Rodin wrote: On Thu, Apr 17, 2003 at 01:14:04PM +0200, Stephane Jourdois wrote: I just noticed that not all packages in sid do provide md5 checksums for the files they contains. What should be done against this ? Shall we file bugreports against all packages that we can found, or perhaps lintian should check this ? No. md5sums control file is an optional feature. Which, IMHO should be required by now. IMHO it's bad enough that dpkg does not handle this itself (#155799 and, better, #187019). Regards Javi pgpobGGio0SGE.pgp Description: PGP signature
Re: New project proposal: debian-lex
On Sun, Apr 20, 2003 at 06:56:14PM +0300, Jarno Elonen wrote: rant If english people don't even know what lex means, they should make a damn effort and and learn it, or at least try to see if they can. The rest of people on Earth using computers have been having headaches learning stupid english slang words like widgets, gadgets or applets for years: show at least some respect, damnit. /rant Ouch, punch taken.. There's a difference here, however. 'Lex' is an academin slang word for which a common language alternative exists, 'law', English is not the common language for lawyers. Nor is lex a slang word. -- Steve Langasek postmodern programmer pgpOoD0pFAh32.pgp Description: PGP signature
anti-spam trick for debian ml (was Re: News about the Package Tracking System)
On Sun, Apr 20, 2003 at 02:49:26PM +0200, Raphael Hertzog wrote: Hi folks, hi Raphael, I just made an important change to PTS. Since the PTS email adresses have been available on the web, they start collecting a significant quantity of spam. As a first measure to avoid them I decided that any email sent directly to the PTS should be auto-approved. Auto-approval is easy, you just have to add an X-PTS-Approved header with a non-empty value. If you don't do that, you get a bounce (and the bounce explains you how to auto-approve your message). why not use this trick also for posts to debian mailing lists? -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: New project proposal: debian-lex
* Jarno Elonen ([EMAIL PROTECTED]) [030420 18:20]: Ouch, punch taken.. There's a difference here, however. 'Lex' is an academin slang word for which a common language alternative exists, 'law', while But: lex is also used in many different languages than English. I don't see the strong need for an english word when there is a much better international alternative that is understand by jurisprudent people all over the world - the potential users. Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C Fachbegriffe des Schienenverkehrs #1 von Marc Haber in dasr Alles wird billiger: 50 % Preiserhöhung für Stammkunden.
Re: New project proposal: debian-lex
On Sun, Apr 20, 2003 at 06:56:14PM +0300, Jarno Elonen wrote: Ouch, punch taken.. There's a difference here, however. 'Lex' is an academin slang word for which a common language alternative exists, 'law', while 'widget' is the only name for the thing it represents. Debian-law is not an optimal name either, though. It feels like the package contains The Debian Law that every user must follow. (And makes Debian-policy sound like it's a project for making Debian suitable for the police.. :]) And after that we should create Debian-dogma! g -- Christian Surchi, [EMAIL PROTECTED], [EMAIL PROTECTED] | ICQ www.debian.org - www.softwarelibero.it - www.firenze.linux.it| 38374818 He who laughs has not yet heard the bad news. -- Bertolt Brecht
Re: anti-spam trick for debian ml (was Re: News about the Package Tracking System)
I just made an important change to PTS. Since the PTS email adresses have been available on the web, they start collecting a significant quantity of spam. As a first measure to avoid them I decided that any email sent directly to the PTS should be auto-approved. Auto-approval is easy, you just have to add an X-PTS-Approved header with a non-empty value. If you don't do that, you get a bounce (and the bounce explains you how to auto-approve your message). why not use this trick also for posts to debian mailing lists? Is there some reason why TMDA isn't being used? We've used this at Xiph.org for the mailing lists for quite some time now, and I don't think a single spam has gotten through yet. It's somewhat similar what what you discuss above, but a lot more user friendly. jack.
Re: New project proposal: debian-lex
On Sun, Apr 20, 2003 at 11:19:23AM -0500, Steve Langasek wrote: Ouch, punch taken.. There's a difference here, however. 'Lex' is an academin slang word for which a common language alternative exists, 'law', English is not the common language for lawyers. Nor is lex a slang word. Probably they missed lessons about ancient Rome... :) -- Christian Surchi, [EMAIL PROTECTED], [EMAIL PROTECTED] | ICQ www.debian.org - www.softwarelibero.it - www.firenze.linux.it| 38374818 Grazie dei fiori, anch'io ti farò un mazzo così. -- Freak Antoni
Re: Do we need policy changes?
other distributions), but the last (user-relevant) step of the setup is not user-friendly at all. Then work at improving it. UTF8 in Debian is _very_ imature still, and even a how to make your package UTF-8 friendly document that you could write (and posted to d-devel and d-desktop if you don't know better places to put it in, since someone will read it and update the other stuff with it if it is good enough) would help things immensely. That document would certainly be a good idea, and I would take it to heart. I would certainly love to make my prospective packages as UTF-8 (and i18n in gerenal) friendly as possible. -- Morgon Kanter GPG key ID: 297CEA5B If everyone demanded peace instead of another television set, there'd be peace. -- John Lennon
Re: md5 checksums
On Sun, 2003-04-20 at 12:16, Javier Fernndez-Sanguino Pea wrote: Which, IMHO should be required by now. IMHO it's bad enough that dpkg does not handle this itself (#155799 and, better, #187019). And even better than both of those, #155676.
Re: foo has reached testing, removing versioned build-depends?
On Sun, Apr 20, 2003 at 11:20:54AM +0200, Bill Allombert wrote: On Sat, Apr 19, 2003 at 03:50:23PM +0100, Colin Watson wrote: I've read the changelog and the bug report closed by that earlier change, and removing the version still makes no sense. If earlier versions of debiandoc-sgml produce incorrect output, as reported, then the versioned build-dep should be left there, as it will help people trying to build with older versions to know what the problem is. There is no problem with older versions, only with buggy versions. Some debiandoc-sgml version (not the one in woody e.g) Aha, I see. Thanks. I was nder the impression that builddeps were not to be used to avoid using buggy packages. I tend to agree. -- Colin Watson [EMAIL PROTECTED]
Re: plagiarism of reiserfs by Debian
Of course as you already know emacs includes so many thing unrelated to editing that anyone using it has already decided they don't mind the bloat. *OT* Really is there any argument that a psychoanalysis program in an editor is not bloat? By the way emacs21 takes 50MB to install (vim takes 15MB), and yes a full KDE install takes more at around 254MB to install but it could be argued it provides more functionality. ;) Of course KDE can also be seen as bloat to people enjoying using command line tools or flipping the switches on their altair. ;) *OT* The point I was trying to make was that adding bloat for no good reason at all, in this case over a screenfull of advertising to a console util harms its usability. Chris
Re: New project proposal: debian-lex
* Sami Haahtinen [EMAIL PROTECTED]: You forget that lex, legis (f.) is well known with lawyers. They'll immedialtely recognize it, since so many laws are of roman origin and many latin terms occur. Are you trying to tell me, that if the list is named debian-lex, more people will know what it means, than by naming it debian-law? I think i can claim that pretty much all the lawyers that attend the list, know english. Atleast enough to know what 'law' means. Well, med isn't a word at all. At least lex is a word. -- Ralf Hildebrandt (Im Auftrag des Referat V a) [EMAIL PROTECTED] Charite Campus MitteTel. +49 (0)30-450 570-155 Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916 AIM: ralfpostfix
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, 20 Apr 2003 12:22:31 -0400, Matt Zimmerman [EMAIL PROTECTED] said: On Sun, Apr 20, 2003 at 02:45:32AM -0500, Manoj Srivastava wrote: Hmm. ucf does show the user the changes, and even offers to merge maintainer changes into the current configuration file. What functionality do you think ucf is missing? In my first message, I listed bullet points for goals, most of which ucf meets, and then outlined the problems with this model, and linked to previous threads discussing them in detail. http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01320.html From my reading of that message, about the only thing that is missing is using debconf to ask the questions. Have I missed anything? (I must confess I only skimmed the first few layers of the message tree you pointed to as references; from my memory of those discussions, there was little new, and the consensus seemed to have been reached for post-inst prompting). Using debconf is on the TODO list for ucf, and perhaps a rewrite of the current prototype in C for speed later down the line. manoj -- Smear the road with a runner!! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: anti-spam trick for debian ml (was Re: News about the Package Tracking System)
Le Sun, Apr 20, 2003 at 06:19:07PM +0200, Domenico Andreoli écrivait: quantity of spam. As a first measure to avoid them I decided that any email sent directly to the PTS should be auto-approved. Auto-approval is easy, you just have to add an X-PTS-Approved header with a non-empty value. If you don't do that, you get a bounce (and the bounce explains you how to auto-approve your message). why not use this trick also for posts to debian mailing lists? For the PTS it's ok as it's not something used regularly to send mails. But for mailing lists it would be annoying to have to add an extra-header each time you want to write to the list. And there are people who don't use mutt or gnus and can't easily add arbitrary headers. I really think that this auto-approval thingie is just a temporary measure until we do something better. Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com
Re: plagiarism of reiserfs by Debian
On Sun, Apr 20, 2003 at 01:02:15PM -0500, Chris Cheney wrote: in an editor is not bloat? By the way emacs21 takes 50MB to install (vim takes 15MB), and yes a full KDE install takes more at around 254MB to install but it could be argued it provides more functionality. ;) Are you sure ? Emacs provides a _lot_ of functionality ;) Frank Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: imlib-linked-with-libpng3
On Fri, Apr 18, 2003 at 07:53:50PM -0500, Steve Langasek wrote: On Fri, Apr 18, 2003 at 08:43:45PM -0400, Steve M. Robbins wrote: What would be the best way to accomodate such a request? I can imagine introducing a new package of imlib linked with libpng3. But since it has to use the same SOVERSION as the current imlib1, it would have to conflict with imlib1. Each individual admin could then choose to use imlib+png2 or to use imlib+png3. However, each choice would have its own set of incompatible programs so this option doesn't appeal to me. If upstream is dormant (and I know that's an understatement), you could also try to coordinate with other vendors who might still ship imlib and agree to pick a new soname anyway. That seems a better choice than creating a new package that conflicts with imlib1, IMHO. I was in fact having email discussions with both upstream and with a Red Hat maintainer last August September. We had mutually agreed to pick a new soname. As Chris pointed out, Red Hat has gone ahead and released imlib1 with the new soname. I was waiting for the new upstream release for fear of violating a rule about changing the soname from upstream. You're suggesting we just go ahead. I'm fine with that. I expect that any new upstream release would have to take into account the soname of the currently-shipping Red Hat package anyway. If changing the soname for imlib1 bothers anyone, do let me know now. I want to emphasize that this is only for imlib1: I have no plan to change anything with gdk-imlib. Thanks, -Steve
Re: anti-spam trick for debian ml (was Re: News about the Package Tracking System)
Le Sun, Apr 20, 2003 at 10:47:55AM -0600, Jack Moffitt écrivait: Is there some reason why TMDA isn't being used? We've used this at Xiph.org for the mailing lists for quite some time now, and I don't think a single spam has gotten through yet. I don't know exactly. It's because most of the Debian lists have always been 100% open... and requiring a confirmation would close the list for complete newbies who can't understand the principle. I for one would be ok to test TMDA at the PTS level if someone shows me how to integrate it nicely in the current setup. But you know master.debian.org is running potato and I don't know if the TMDA in potato is well suited ... Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, Apr 20, 2003 at 12:59:27PM -0500, Manoj Srivastava wrote: On Sun, 20 Apr 2003 12:22:31 -0400, Matt Zimmerman [EMAIL PROTECTED] said: In my first message, I listed bullet points for goals, most of which ucf meets, and then outlined the problems with this model, and linked to previous threads discussing them in detail. http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01320.html From my reading of that message, about the only thing that is missing is using debconf to ask the questions. Have I missed anything? (I must confess I only skimmed the first few layers of the message tree you pointed to as references; from my memory of those discussions, there was little new, and the consensus seemed to have been reached for post-inst prompting). Yes, debconf would seem to be the only item in that list that ucf does not implement, now that the three-way option is documented in 0.12 (18 Apr). Using debconf is on the TODO list for ucf, and perhaps a rewrite of the current prototype in C for speed later down the line. ucf still has the same fundamental problem with regard to preconfiguration, which was the primary issue that I raised in my original message. The consensus, as I recall, was that preconfiguration is important, and that prompting in postinst should be minimized. If such a system is to be used for a large number of packaging, this would mean moving a large number of prompts into postinst, which I think is undesirable. -- - mdz
Re: plagiarism of reiserfs by Debian
On Sun, Apr 20, 2003 at 01:02:15PM -0500, Chris Cheney wrote:
Of course as you already know emacs includes so many thing unrelated to
editing that anyone using it has already decided they don't mind the
bloat. *OT* Really is there any argument that a psychoanalysis program
in an editor is not bloat?
Yes. It's the same as the argument that a psychoanalysis program in
an editor is not a gerbil, nameably that there's no apparent
connection.
From The Free On-line Dictionary of Computing (09 FEB 02) [foldoc]:
software bloat
jargon, abuse The result of adding new features to a program
or system to the point where the benefit of the new features
is outweighed by the extra resources consumed ({RAM}, disk
space or performance) and complexity of use. Software bloat
is an instance of Parkinson's Law: resource requirements
expand to consume the resources available. Causes of software
bloat include {second-system effect} and {creeping
featuritis}. Commonly cited examples include Unix's {ls}(1)
command, the {X Window System}, {BSD}, {Missed'em-five},
{OS/2} and any {Microsoft} product.
[{Jargon File}]
(1995-10-16)
In order to demonstrate that something is bloat, you have to
demonstrate that including it causes a problem which outweighs the
advantage.
Note that you have to do this in an environment where .5Gb of memory,
120Gb hard drives, and 1GHz processors are relatively common, and so
losing a few hundred kb of storage is not likely to bother you
much. Certainly doesn't bother me.
[As a side note, this implies that bloat is a context-sensitive
term, and not an absolute - much like fast.]
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ | Dept. of Computing,
`. `' | Imperial College,
`- -- | London, UK
pgpybwy176XTC.pgp
Description: PGP signature
Re: anti-spam trick for debian ml (was Re: News about the Package Tracking System)
But for mailing lists it would be annoying to have to add an extra-header each time you want to write to the list. And there are people who don't use mutt or gnus and can't easily add arbitrary headers. I really think that this auto-approval thingie is just a temporary measure until we do something better. How about keeping a whitelist database in which the users can add themselves by sending a mail in certain format to something like [EMAIL PROTECTED]? Only after that would mail from that address be accepted without bouncing. That should filter out most of the spam. - Jarno
Re: anti-spam trick for debian ml (was Re: News about the Package Tracking System)
Is there some reason why TMDA isn't being used? We've used this at Xiph.org for the mailing lists for quite some time now, and I don't think a single spam has gotten through yet. I don't know exactly. It's because most of the Debian lists have always been 100% open... and requiring a confirmation would close the list for complete newbies who can't understand the principle. We haven't seen this problem on the vorbis lists. We do occasionally get people who quote the entire reply from TMDA when authorizing themselves, but even so, it's better than a lot of spam and certainly better than closing the lists. jack.
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
ucf still has the same fundamental problem with regard to preconfiguration, which was the primary issue that I raised in my original message. The consensus, as I recall, was that preconfiguration is important, and that prompting in postinst should be minimized. I may have missed something but why can't the changed/merged configuration files be saved somewhere in preinstall phase and the current live configs be overwritten only in the postinstall phase by dpkg or postinst scripts if the rest of the installation went well? - Jarno
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, Apr 20, 2003 at 09:48:48PM +0300, Jarno Elonen wrote: ucf still has the same fundamental problem with regard to preconfiguration, which was the primary issue that I raised in my original message. The consensus, as I recall, was that preconfiguration is important, and that prompting in postinst should be minimized. I may have missed something but why can't the changed/merged configuration files be saved somewhere in preinstall phase and the current live configs be overwritten only in the postinstall phase by dpkg or postinst scripts if the rest of the installation went well? Again: see my first message and followups for a specific, concrete example of why this won't work. -- - mdz
Re: plagiarism of reiserfs by Debian
Dude, You really need to calm down. Twice now recently you have opened your mouth and stuck your foot in when there really wasn't any need to. Take a Valium and do something less stressful. Are you talking to me? You are the one with the foot hanging out of your mouth so by a process of elimination it has to be you. Really we don't need to alienate upstream software authors with flame responses. Point out that he can file a bug and leave it at that. Matt.
Re: stop abusing debconf already
Conside rthis: when considering input from a ``jumped up developer'' who has demonstrated competence and has put in the effort like Joey Hess, and has intituted a couple of major changes in how Debian works, and an unknown twit, guess who am I going to listen to? Yawn. I don't know and I doubt you would listen if I did. It doesn't really matter. Everyone has an opinion and I have voiced mine. Perhaps I should be censored to avoid my rambling encroaching into your computer? Just because they have put some effort into the project does *not* make them infallible - all it makes them is a good coder, nothing more. Emboldening them with further super-powers is ridiculous. Matt.
Re: plagiarism of reiserfs by Debian
Heh. First you bad mouth Joey Hess. And now you go up against Ben Collins. And both times you take what I consider impolitic stances that show poor judgment (even ignoring the fact that you are, with nothing whatsoever to back it up) some of the most respected developers in Debian. I applaud this masterly demonstration of a nadir of cluelessness. I suppose this is accomplishment of a sort. Ignore me then if I don't rate in your view. On the other hand you could try to educate me, but I guess I'm too dumb for that. Perhaps if you removed the Debian prune from your ass I may take some notice. A Linux distribution is not worth getting so excited over in the grand scheme of things! Matt.
Re: stop abusing debconf already
No offense, but I think you joined the wrong project, then. No offence taken. I joined when Debian wasn't run by anal retentives. Sure there was the whole free software part - but not the SS Nazi version of free software that is being prompted recently. I have to say that I'm beginning to think that your assessment is right and I should find a more liberal bunch of Linux fanatics to join with. Matt. BTW: Remember at the end of the day it is only a Linux distribution, nothing more, nothing less.
Re: stop abusing debconf already
Um, no. *Policy* says that it may not be used as a registry. [SNIPPED LONG DIATRIBE THAT DOES NOT PROVE THE ABOVE STATEMENT] Sure, you delete the registry things should still work. Did I say anything different? You are making a long tenuous link to prove your point which I don't subscribe to. Unless we have a formal definition of 'registry' in policy as well we can argue this forever as to what is the right way to view it. Perhaps not taking a Windows centric view would help? I'm not sure why you think Joey's expertise doesn't qualify him to make pronouncements about the use of debconf. Unlike you, he at least gets the answer right. Well I don't agree on the right answer bit and I never said he wasn't right (in some people views). All I said was he answer was not the gospel on this issue. Matt.
Re: plagiarism of reiserfs by Debian
Chris Cheney [EMAIL PROTECTED] writes: Of course as you already know emacs includes so many thing unrelated to editing that anyone using it has already decided they don't mind the bloat. *OT* Really is there any argument that a psychoanalysis program in an editor is not bloat? By the way emacs21 takes 50MB to install (vim takes 15MB), and yes a full KDE install takes more at around 254MB to install but it could be argued it provides more functionality. ;) Of course KDE can also be seen as bloat to people enjoying using command line tools or flipping the switches on their altair. ;) *OT* The point I was trying to make was that adding bloat for no good reason at all, in this case over a screenfull of advertising to a console util harms its usability. Yeah, yeah, we've heard it all before. Why don't you take it to slashdot instead. Don't you have anything better to do than to make these pointless, off-topic rants? You haven't fucked up libvorbis in a couple weeks. Why don't you go randomly break that again instead? -- I don't know half of you half as well as I should like; and I like less than half of you half as well as you deserve. pgpwwUSh9Qxq6.pgp Description: PGP signature
Re: stop abusing debconf already
BTW the opinion of this jumped-up developer is please don't send me private copies of posts to mailing lists. Thanks. Apologies, 'reply-all' is not clever enough in Outlook Express to evaluate the sender preference on being copied on list emails. Any suggestions for a MUA that can perform this feat are appreciated. Altering top posts based on preference would be an advantage as well. Matt.
Re: stop the manage with debconf madness
What is not helpful is when a developer gets a bad case of NOMUS (Not On My UNIX System) and goes off on one about how perfectly the world would be if everyone agreed with their narrow definition of the 'correct' way to do things. The recent /run debate was another example of this virulent disease taking hold amongst the vocal developer cabal. Really a flaw in the NM process. Don't we require peopel to acknowledge the importance of policy nowadays? Please. I assume we are both adults (I am at least). Therefore we should be able to have a sensible debate without getting too heated about it. Right. The hell with policy, since following policy is mind less conformance. I never suggested to throw out policy (perhaps you should revisit my email). All I said was that this was prior best practice and now we might make a change. Do not burn everyone for trying their best to make things easy for users just because someone has a bee in their bonnet over this issue. Eventually someone (MDZ seems to be starting this again) will come up with a sensible solution (that doesn't predepend on some configuration program bloat) that will deal with this. Then we can all move over to using that and everyone will the happy again. Matt. Note: That's happy until the next time someone gets all fussed up over the wrong location for a configuration file.
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, 20 Apr 2003 21:48:48 +0300, Jarno Elonen [EMAIL PROTECTED] said: ucf still has the same fundamental problem with regard to preconfiguration, which was the primary issue that I raised in my original message. The consensus, as I recall, was that preconfiguration is important, and that prompting in postinst should be minimized. I may have missed something but why can't the changed/merged configuration files be saved somewhere in preinstall phase and the current live configs be overwritten only in the postinstall phase by dpkg or postinst scripts if the rest of the installation went well? Well, for configuration files that require the unpacked package to generate, you can't ask during preconfiguration. For files created using non essential packages, you need to wait until postinst, or else those utilities may not be available. Thus, in a number of cases, the ``new'' configuration file is not determinable in the preinst phase. Even for files in the package there is no way for ucf to get at them -- especially given that the files handled by ucf are not conffiles, and thus mingled in the package data. manoj -- Virtue is a relative term. Spock, Friday's Child, stardate 3499.1 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
RE: NOTICE: libcupsys2 splitting
Jeff Licquia wrote: -SNIP- If, however, your package deals with the CUPS raster image format somehow, your package will fail to work with 1.1.18-3 or later until it is rebuilt with the new libs. I have identified three packages as possibly meeting that test: gs-esp, cupsys-driver-gimpprint, and foomatic-bin. I maintain gs-esp, and will be dealing with that package shortly. The other two maintainers are CCed on this message. FYI: I can confirm that it does break cupsys-driver-gimpprint and foomatic-bin because I missed this message, and my CUPS printing system quit working on about 16 Apr. These remain broken as of 20 Apr 2003. I have managed to get printing working under CUPS with a combination of your new gs-esp package from unstable + hpijs + a printer specific PPD generated from linuxprinting.org for my HP 960C printer. This offers a temporary fix for owners of HP inkjet printers until cupsys-driver-gimpprint and foomatic-bin are re-built. Cheers, -Don Spoon-
Re: stop the manage with debconf madness
On Sun, Apr 20, 2003 at 09:06:38PM +0100, Matt Ryan wrote: Eventually someone (MDZ seems to be starting this again) will come up with Please avoid using my name in support of your arguments. I rather not be associated with your recent publicity. -- - mdz
Re: plagiarism of reiserfs by Debian
On Sat, 19 Apr 2003 19:46:41 -0700, Craig Dickson [EMAIL PROTECTED] said: Chris Cheney [EMAIL PROTECTED] wrote: First of all emacs is pure bloat so who cares what it does... Ah, a troll. Don't be an ass. There are a lot of people who would say the same of KDE, so it's silly for one of the main Debian KDE maintainers to be saying such a thing. Please don't feed the troll. We already have a problem with the miasma of the bones beneath the bridge. manoj -- If God had not given us sticky tape, it would have been necessary to invent it. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: stop abusing debconf already
On Sun, Apr 20, 2003 at 08:57:38PM +0100, Matt Ryan wrote: No offense, but I think you joined the wrong project, then. No offence taken. I joined when Debian wasn't run by anal retentives. Sure there was the whole free software part - but not the SS Nazi version of free software that is being prompted recently. I have to say that I'm beginning to think that your assessment is right and I should find a more liberal bunch of Linux fanatics to join with. Please do. BTW: Remember at the end of the day it is only a Linux distribution, nothing more, nothing less. Bullshit. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpKB0ytYttoK.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
On Sun, 20 Apr 2003 20:39:09 +0100, Matt Ryan [EMAIL PROTECTED] said: You are the one with the foot hanging out of your mouth so by a process of elimination it has to be you. Really we don't need to alienate upstream software authors with flame responses. Point out that he can file a bug and leave it at that. If the upstream author is rude to me, he does not deserve any consideration from myself. If he chooses to alienate his clientele, he should expect to reap what he sowed. manoj -- In order to live free and happily, you must sacrifice boredom. It is not always an easy sacrifice. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: plagiarism of reiserfs by Debian
On Sun, 20 Apr 2003 20:53:11 +0100, Matt Ryan [EMAIL PROTECTED] said: A Linux distribution is not worth getting so excited over in the grand scheme of things! Then you are in the wrong project. If you do not think Debian is important in the grand scheme of things, and if you think fawning obsequiousness is an appropriate stance for Debian developers to take, you really need to think about your commitment to this project. manoj -- On the subject of C program indentation: In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. Blair P. Houghton Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: plagiarism of reiserfs by Debian
On Sun, Apr 20, 2003 at 08:39:09PM +0100, Matt Ryan wrote: Dude, You really need to calm down. Twice now recently you have opened your mouth and stuck your foot in when there really wasn't any need to. Take a Valium and do something less stressful. Are you talking to me? You are the one with the foot hanging out of your mouth so by a process of elimination it has to be you. Really we don't need to alienate upstream software authors with flame responses. Point out that he can file a bug and leave it at that. I'm with Ben. Hans was trolling and you're being a dick. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -- | London, UK pgpQfP38nhmy0.pgp Description: PGP signature
Re: Common Policy Proposal
Wafula Okumu [EMAIL PROTECTED] wrote: Dear Debian and Chad: Is it possible for you to assist me by sharing with me a framework for a comm on defence and security policy proposal. HUH? OK. Let's give this a try. I'm thinking that a couple Patriot Missle batteries would be essential in any common defense and security policy proposal. I mean, if you're really going to deter your foes, why not do it the right way. They're a rightous weapon, and they attract the babes like a basket full of Cadbury Chocolate Easter Eggs. Now, you're going to have to hire at least enough mercenaries for a 5:1 ratio of your upper division staff, the people you most want to protect. You could drop down to 1:20 for the rest of your company staff, maybe even 1:50. If you're trying to protect a country, well, I can't give you exact numbers, but you're going to want tens of thousands of troops. That might be a bit expensive to pay mercenaries, so try instilling a draft. In any case, make sure you keep them busy on the off time by helping hide those Easter Eggs in the mine-field. It's a diversion tactic. Your foes won't be able to resist the temptation of a good egg hunt. Before you ask, chemical weapons are right out. It's just too messy and way to problematic. You'll likely kill half of your own troops trying to pull off any sort of attack. Train them in how to defend against such warfare, but don't give them the means to participate in any other way. You do want some sort of credibility, don't you? If you really must, send your foes truckloads of Peeps, you know, the marshmello sugar bombs. If that doesn't devestate your foe completely, they'll at least be busy shoveling out the latrine for weeks. Weapons of mass distruction? Again out. Don't even bother. Just be smart on how you deploy your forces and you'll do fine. If you can, however, try to get your hands on a Holy Hand Grenade of Antioch. They're quite effective, especially against vorpal bunnies, but rare indeed. I suggest that you train your special forces in using this awesome weapon by screening Monty Python's, The Search for the Holy Grail. It is the defacto standard training material for Holy weaponry. Remember, you must pull the pin and toss the Grenade on three. I would be most grateful if you can share with me this information at your ea rliest possible convenience. My pleasure. I hope my information has helped you out... OK, not really. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
I may have missed something but why can't the changed/merged configuration files be saved somewhere in preinstall phase [...] Again: see my first message and followups for a specific, concrete example of why this won't work. Thanks, I read the thread. So the reason was that configuration file generation is mostly done in postinst scripts? I didn't quite get why it couldn't in practically all cases be done in preinst (or even a completely new installation if required), though. Could you provide some counter-example(s)? I doubt the (pre-)dependencies on tools used for generation would really be a problem - the generation scripts are usually quite simple and can usually use pretty standard tools that don't change much. - Jarno
Re: plagiarism of reiserfs by Debian
If the upstream author is rude to me, he does not deserve any consideration from myself. If he chooses to alienate his clientele, he should expect to reap what he sowed. The difficulty of their character unfortunately often seems to correlate with the important of their software. ;) So even if the upstreams sometimes heats up easily, please spend extra patience on them for the sake of the users. Pretty please.. I'd really hate to lose something like Reiserfs from Debian just because of a few unpolite mails back and forth. - Jarno
Re: stop abusing debconf already
On Sun, 2003-04-20 at 15:57, Matt Ryan wrote: No offense, but I think you joined the wrong project, then. No offence taken. I joined when Debian wasn't run by anal retentives. Sure there was the whole free software part - but not the SS Nazi [...] Congratulations, you just proved (yet again) Godwin's Law.
Re: stop the manage with debconf madness
On Sun, 20 Apr 2003 21:06:38 +0100, Matt Ryan [EMAIL PROTECTED] said: I never suggested to throw out policy (perhaps you should revisit my email). All I said was that this was prior best practice and now we might make a change. Any prior practice that promotes not preserving user changes ad comments (despite all that policy says on that subject) can't possibly be deemed best. Do not burn everyone for trying their best to make things easy for users just because someone has a bee in their bonnet over this issue. Throwing away user changes is doing ones best for them? Since when? And when is doing something suboptimally been excusable by whining but I was doing my best? Making mistakes is not an issue. Everyone makes them. Mindlessly defending practices that go against what we promise our users, despite being told by several other developers, is a level of intransigence that is unacceptable. Eventually someone (MDZ seems to be starting this again) MDZ seems to be (sinsibly) distancing himself from your stance. will come up with a sensible solution (that doesn't predepend on some configuration program bloat) that will deal with this. Then we can all move over to using that and everyone will the happy again. Heh. The solution, when presented to you that does keep the admin in the loop whenever their changes would be blown away, while allowing generation of new configuration files via debconf or other programmatic means, it is bloat, even when under 20KB of code. So, while you are wringing your hands over the hurt sensibilities of practitioners of a practice that discards user changes, do _you_ have any constructive suggestions that can be rapidly prototyped, and put into use soon, and are not, in your considered opinion, bloat? manoj -- You! What PLANET is this! McCoy, The City on the Edge of Forever, stardate 3134.0 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
I may have missed something but why can't the changed/merged configuration files be saved somewhere in preinstall phase and the [...] Well, for configuration files that require the unpacked package to generate, you can't ask during preconfiguration. For files created using non essential packages, you need to wait until postinst, or else those utilities may not be available. I have a feeling that these cases are actually quite rare. At least with a little help, the developers currently facing those few cases would most likely be able to split their packages so that proper pre-depends could be applied. Or am I provably being too optimistic? - Jarno
Re: stop abusing debconf already
On Sun, Apr 20, 2003 at 08:57:38PM +0100, Matt Ryan wrote: No offense, but I think you joined the wrong project, then. No offence taken. I joined when Debian wasn't run by anal retentives. Sure there was the whole free software part - but not the SS Nazi version of free software that is being prompted recently. A great, so we can end this thread now. BTW: Remember at the end of the day it is only a Linux distribution, nothing more, nothing less. Ever had a look at http://www.debian.org/ports/#nonlinux? cheers, Michael
Re: Proposed handling of generated configuration files (Re: stop the manage with debconf madness)
On Sun, 20 Apr 2003 23:49:50 +0300, Jarno Elonen [EMAIL PROTECTED] said: Thanks, I read the thread. So the reason was that configuration file generation is mostly done in postinst scripts? I didn't quite get why it couldn't in practically all cases be done in preinst (or even a completely new installation if required), though. Could you provide some counter-example(s)? my package contains /usr/bin/floobargle that I use to analize the system to create a configuration file. /usr/bin/floobargle is not available until unpacked. Or, I have a file I can generate, which is in /usr/lib/foo/bar.conf; and this file is large, and changes often, I do not want to embed it inline in my packages preinst file. I doubt the (pre-)dependencies on tools used for generation would really be a problem - the generation scripts are usually quite simple and can usually use pretty standard tools that don't change much. It depends on what I use to generate the file. A few xml files, a little bit of xsl transofrms, and you have a ton of prepends. manoj -- I was recently on a tour of Latin America, and the only regret I have was that I didn't study Latin harder in school so I could converse with those people. Danforth Quayle Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: plagiarism of reiserfs by Debian
Jarno == Jarno Elonen [EMAIL PROTECTED] writes: Jarno I'd really hate to lose something like Reiserfs from Debian Jarno just because of a few unpolite mails back and forth. Well, if we do lose something because of a few unpolite emails alone I don't think it qualifies as being free enough to be in Debian to start with, right? Not that I'm suggesting being rude to upstream, but if it was about opinions there's a few people who'd like to see my OS masquerading as an editor go away too ;-) Cheers! Shyamal
Re: stop abusing debconf already
On Sun, Apr 20, 2003 at 08:57:38PM +0100, Matt Ryan wrote: No offense, but I think you joined the wrong project, then. No offence taken. I joined when Debian wasn't run by anal retentives. Sure there was the whole free software part - but not the SS Nazi version of free software that is being prompted recently. I have to say that I'm beginning to think that your assessment is right and I should find a more liberal bunch of Linux fanatics to join with. Oooh, is that a promise? Anything we can do to facilitate that? manoj -- A man who turns green has eschewed protein. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: plagiarism of reiserfs by Debian
I followed Release Managers request on how to deal with the libvorbis mess, if you have a problem with how it was dealt with bring it up on irc. You should know this already but a message was sent out a week in advance to the libvorbis breakage occuring so that maintainers would about it. And no the general consensus is not for a library to conflict with every package that built against an older version (I don't recall if you suggested that or if it was someone else). Thanks, Chris
