Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Emile van Bergen wrote: So what do you propose then, to drop everything just because you cynically point out that a lot of rules are being violated today? What I'm saying is that (a lot of) these rules are archaic and irrelevant in today's Internet world. Firstly I doubt any of the people who violate the rules are even aware what an RFC is or what it's for - and if they did they probably wouldn't care. Does it matter to the sender that they put a couple of extra lines in their signature and this *may* cause a few extra seconds download time for the recipient? Is forwarding a chain letter going to get them cut off by their ISP? Will their computer explode if they type their message in CAPITALS? The answer to these is no, and I hazard a guess that 'abuse' of any of these rules would end up at the same conclusion - it's not relevant to me therefore I'll dismiss it. Society evolves and with it rules change, we need to accept this and see what evolves - if it turns out to be bad then limits will have to be applied, but I'm not seeing a complete state of anarchy break out yet... Matt.
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Matt Ryan [EMAIL PROTECTED] wrote: Emile van Bergen wrote: So what do you propose then, to drop everything just because you cynically point out that a lot of rules are being violated today? What I'm saying is that (a lot of) these rules are archaic and irrelevant in today's Internet world. Firstly I doubt any of the people who violate the rules are even aware what an RFC is or what it's for - and if they did they probably wouldn't care. Hello, Which does not matter at all. This memo does not specify an Internet standard of any kind. having it distributed as RFC is just a convenience, because searching for rcf1855 on google will find perfect hits en masse. Does it matter to the sender that they put a couple of extra lines in their signature and this *may* cause a few extra seconds download time for the recipient? Yes it does, he'll get some more or less polite complaints, but that is not the point, the netiquette is about miminumal standards of politeness. Is it still impolite to have a 10 line signature for every two line article causing 100's of recipients a few extra seconds download time? Yes, it is. Is forwarding a chain letter going to get them cut off by their ISP? Probably not today. Will their computer explode if they type their message in CAPITALS? [...] No and the netiquette does not say so, instead it says Use mixed case. UPPER CASE LOOKS AS IF YOU'RE SHOUTING. which is still correct. I'd suggest reading the netiquette from top to bottom again. cu andreas
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, May 18, 2003 at 10:26:38AM +0100, Matt Ryan wrote: Emile van Bergen wrote: So what do you propose then, to drop everything just because you cynically point out that a lot of rules are being violated today? Society evolves and with it rules change, we need to accept this and see what evolves - if it turns out to be bad then limits will have to be applied, but I'm not seeing a complete state of anarchy break out yet... These are all valid points, however, I still don't want to read HTML e-mail in mutt. Asking people to blindly follow a set of rules, doesn't as you say work. However, if someonbe does send me an e-mail, I send one back explaining why HTML e-mail is bad and wrong due to a) compatability and b) bandwidth issues. It then doesn't happen again, as people realise why the 'rules' were set up in the first place. Neil -- 16 Channels in mode 4 I disclaim everything I can under English law. gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li 8DEC67C5
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, May 18, 2003 at 10:26:38AM +0100, Matt Ryan wrote: Society evolves and with it rules change, we need to accept this and see what evolves - if it turns out to be bad then limits will have to be applied, but I'm not seeing a complete state of anarchy break out yet... Right now we're getting really damn close to anarchy, when everyone and their dog has the means to entirely obliterate everyone else's mailbox with unwanted whatever-they-have-to-say, and sometimes even obliterate their computer (with viruses). The only way the rules need to evolve is to make things that annoy all decent users punished properly, rather than effectively ignored. (As for the particular rule in question, the McQuary limit is perhaps one of the more utopian ones, but I still don't see many people on Debian mailing lists that I track breaking it.) -- 2. That which causes joy or happiness.
debian-devel@lists.debian.org
debian-devel -- 120 www.xhfsb.com: --http://www.xhfsb.com/bbs/; --http://www.xhfsb.com/chat/; http://www.xhfsb.com :[EMAIL PROTECTED] 0373-3717120
Re: Some important orphaned packages
On Sat, May 17, 2003 at 11:39:00PM +0200, Marc Haber wrote: On Mon, 12 May 2003 13:30:00 -0500, Donald J Bindner [EMAIL PROTECTED] wrote: Maybe I should roll my sleeves up and send them some patches. apg's upstream is pretty responsive. I checked out the source, and I don't think it is a good candidate for for entropy calculation. The pronounceable generation algorithm uses an elaborate kind of backtracking method to guarantee that words are English-like. To know how much information a password contains, you effectively need to know what the probability is of each random choice you make. [Each choice adds -log_2(p) bits of information.] It is pretty hard to calculate these values when the algorithm is constantly making and unmaking choices. On the other hand, I have some more (intuitive) respect for how it works now that I have looked through the algorithm some. I have also checked the pwgen program. It uses a more direct algorithm, and I already have something of a patch worked together for it. Don -- Don Bindner [EMAIL PROTECTED]
Re: security in testing
* Steve Kemp | On Fri, May 16, 2003 at 01:39:20PM -0400, Matt Zimmerman wrote: | | If a member of the sec-team says Yes, we are actively trying to | find | new members, but finding competent and responsive people who have | the | time and will to help is very difficult, then I'm happy and shut | up. | | Well, then. :-) | | Every time I get a few spare hours I glance over list of packages | needing work, and tagged security: | | http://qa.debian.org/bts-security.html | | Of the packages listed there 23 out of the 147 entries contain | patches, (some of these patches may well be bogus). | | So it seems like a simple matter to apply and rebuild them, short | of performing an NMU it seems that there's little a random developer | could do. _And test them_. If you have done that and a bug hasn't been tended to, an NMU is just fine. A mail to the maintainer is also a good idea. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: DebConf 3 for New Maintainers
* Josselin Mouette | Le jeu 15/05/2003 à 14:49, Tollef Fog Heen a écrit : | The area is covered with WLANs already, but we'll have a few switches | for people who don't have wireless. | | Side question: will there be a few machines for people who can't bring a | laptop ? Hopefully, yes, but if you can bring a laptop: do it. :) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Josip Rodin wrote: Right now we're getting really damn close to anarchy, when everyone and their dog has the means to entirely obliterate everyone else's mailbox with unwanted whatever-they-have-to-say, and sometimes even obliterate their computer (with viruses). We have the ability to annialte each other on the highways (and to a certain degree we do), but its a rick of being involved for the benefits it brings you. It would be nice to make everyone drive well, but they don't and they won't play nice with your email either. The only way the rules need to evolve is to make things that annoy all decent users punished properly, rather than effectively ignored. At present there is no one who is going to step in and do that. You can on a limited basis (rules for mailing lists etc) but as a general point you are going to be hard pressed to limit crap in your inbox and still participate fully with others on the Internet. Matt.
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Neil McGovern wrote: These are all valid points, however, I still don't want to read HTML e-mail in mutt. You are figting a losing battle. If the MUA that someone uses is set-up to send HTML (rich test, whatever) email then you are highly unlikely to get them to change it. Some devices (cable TV email?) may not even be able to turn it off. Whatever the arguements are for running a lean mean email client its probably going to have to cope with HTML email or you are going to have to limit who you interact with! Asking people to blindly follow a set of rules, doesn't as you say work. However, if someonbe does send me an e-mail, I send one back explaining why HTML e-mail is bad and wrong due to a) compatability and b) bandwidth issues. Yes, but then if the majority of clients can send/recive HTML email, who has the compatibility problem? It then doesn't happen again, as people realise why the 'rules' were set up in the first place. Maybe, I suspect not though. Matt.
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Andreas Metzler wrote: Hello, Which does not matter at all. This memo does not specify an Internet standard of any kind. having it distributed as RFC is just a convenience, because searching for rcf1855 on google will find perfect hits en masse. Hello, Finding it is not the problem. As I stated and if they did they probably wouldn't care means that its one thing to read it, but what if they don't act on it? Matt.
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, May 18, 2003 at 11:38:14AM +0100, Neil McGovern wrote: | These are all valid points, however, I still don't want to read HTML | e-mail in mutt. Why not? Mutt deals perfectly well with HTML e-mail if you have lynx or w3m installed on your system and have auto_view text/html in your .muttrc. Cameron.
Maintaining kernel source in sarge
Only a few people will probably have noticed the mess resulting from tons of different kernel packages in the stable (and unstable) distribution. Not only there are several versions of kernel source in each architecture, they are also different for most architectures. Only mips and mipsel share the same kernel source. To make it worse, there are also third party kernel modules that depend on a particular version of the kernel source (they don't depend on the particular Debian revision, though, I hope). As a result of this, it is almost impossible to update the kernel in a released Debian distribution. Removing one kernel version and including another without rebuilding all modules packages will break several installations. Not removing the old packages will make the archive grow through time which will cause problems with CD build scripts. Hence, it is important that when a new kernel is added (e.g. for security reasons) an older package is removed *and* all relevant modules packages are rebuilt and included as well. I wonder if there are ways and efforts to improve the situation for sarge. I would be glad if somebody could investigate the modules situation and describe which modules packages require which kernel versions (and/or depend on which other packages). I also wonder if there are efforts in progress to unify the kernel source through more than two architectures? This would require a group or architecture maintainers (current kernel package mantainers) to work collaboratively towards this goal. Regards, Joey -- Ten years and still binary compatible. -- XFree86 Please always Cc to me when replying to me on the lists.
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Mon, 19 May 2003 00:25, Matt Ryan wrote: Neil McGovern wrote: These are all valid points, however, I still don't want to read HTML e-mail in mutt. You are figting a losing battle. If the MUA that someone uses is set-up to send HTML (rich test, whatever) email then you are highly unlikely to get them to change it. Some devices (cable TV email?) may not even be able to turn it off. Whatever the arguements are for running a lean mean email client its probably going to have to cope with HTML email or you are going to have to limit who you interact with! I don't think that avoiding communication with webtv users is any great loss. It's very rare for me to have a HTML email that I actually want to read, I probably should configure my mail server to reject them all. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Do not touch l10n files
On Sat, May 17, 2003 at 11:39:02PM +0200, Marc Haber wrote: On Wed, 14 May 2003 01:54:34 +0200, Nicolas Boullis [EMAIL PROTECTED] wrote: You're probably right, those useless l10n teams are annoying. (..) Unfortunately, there does not seem to be any possibility to prevent translation work from being done on my packages. Unfortunately, there is a large population of the world that does not understand english at all, but only their native language. I would understand that preserving your wish would violate DFSG #5 (since you _are_ discriminating non-english speakers). Friendly Javi pgpVEWe3l1tK1.pgp Description: PGP signature
Bug#193751: ITP: kwiki -- A Quickie Wiki that's not too Tricky
Package: wnpp Version: unavailable; reported 2003-05-18 Severity: wishlist * Package name: kwiki Version : 0.13 Upstream Author : Brian Ingerson [EMAIL PROTECTED] * URL : http://search.cpan.org/author/INGY/CGI-Kwiki/ * License : Perl/Artistic Description : A Quickie Wiki that's not too Tricky There are dozens of wiki implementations in the world, and many of those are written in Perl. As is common with many Perl hacks, they are rarely modular, and almost never released on CPAN. One major exception is CGI::Wiki. This is a wiki framework that is extensible and is actively maintained. Another exception is this module, CGI::Kwiki. CGI::Kwiki focuses on simplicity and extensibility. You can create a new kwiki website with a single command. The module has no prerequisite modules, except the ones that ship with Perl. It doesn't require a database backend, although it could be made to use one. The default kwiki behaviour is fairly full featured, and includes support for html tables. Any behaviour of the kwiki can be customized, without much trouble.
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, May 18, 2003 at 03:25:42PM +0100, Matt Ryan wrote: Yes, but then if the majority of clients can send/recive HTML email, who has the compatibility problem? It doesn't matter what the clients are able to do. The majority of readers on this list don't want HTML-postings. Just like they don't want to jump through hoops to reach somebody or read half a screenful of signatures. Michael -- The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism. -- Paul Tomblin
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, May 18, 2003 at 10:54:08PM +0800, Cameron Patrick wrote: On Sun, May 18, 2003 at 11:38:14AM +0100, Neil McGovern wrote: | These are all valid points, however, I still don't want to read HTML | e-mail in mutt. Why not? Mutt deals perfectly well with HTML e-mail if you have lynx or w3m installed on your system and have auto_view text/html As Spamassassin already deals perfectly well with HTML e-mail (after tweaking some scores here and there), I have no need to configure my muttrc accordingly :P Michael -- Debian. Give us the child until the age of six, and we'll give you the man. -- Branden Robinson
Re: Do not touch l10n files (was Re: DDTP issue)
* Henrique de Moraes Holschuh | On Sat, 17 May 2003, Martin Schulze wrote: | | should always try to stay as close to the original as you can. | Changing the text layout is a NO-GO in my opinion - and in the | opinion of our Apache people apparently. | | Apparently. We are trying to bring to light that proper l10n | requires more than that. We asked why the removal of the number «3» from the word «PHP3» caused the format of the whole description to the changed. We asked _why_, we did not say «do not do this». First, we wanted to know why. Then, we might want to ask it to be changed back. Somehow, this whole discussion has been blown completely out of propositions. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Matt Ryan [EMAIL PROTECTED] wrote: Andreas Metzler wrote: Hello, Which does not matter at all. This memo does not specify an Internet standard of any kind. having it distributed as RFC is just a convenience, because searching for rcf1855 on google will find perfect hits en masse. Hello, Finding it is not the problem. As I stated and if they did they probably wouldn't care means that its one thing to read it, but what if they don't act on it? Act accordingly. If people send me mail that ignores the netiquette, there are three possibilities: * they don't know about it - tell them. * they do not care whether they are impolite to me - ignore them. * they do not have to care whether... (e.g. your boss.) - read it. cu andreas
Re: Do not touch l10n files
On Sun, May 18, 2003 at 05:10:29PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: On Sat, May 17, 2003 at 11:39:02PM +0200, Marc Haber wrote: Unfortunately, there does not seem to be any possibility to prevent translation work from being done on my packages. Unfortunately, there is a large population of the world that does not understand english at all, but only their native language. I would understand that preserving your wish would violate DFSG #5 (since you _are_ discriminating non-english speakers). Please don't drag the DFSG into this. The DFSG talks about licences on packages, not about what maintainers do. -- Colin Watson [EMAIL PROTECTED]
Bug#193758: ITP: xsupplicant -- Implementation of the IEEE 802.1x authentication protocol.
Package: wnpp Version: unavailable; reported 2003-05-18 Severity: wishlist * Package name: xsupplicant * URL : http://www.open1x.org/ * License : GPL, BSD Description : Implementation of the IEEE 802.1x authentication protocol. This software allows a GNU/Linux or BSD workstation to authenticate with a RADIUS server using 802.1x and the EAP/TLS and MD5 protocols. The intended use is for computers with wireless LAN connections to complete a strong authentication before joining the network. However, support for dynamic WEP keys has not yet been implemented.
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Matt Ryan [EMAIL PROTECTED] writes: What I'm saying is that (a lot of) these rules are archaic and irrelevant in today's Internet world. Firstly I doubt any of the people who violate the rules are even aware what an RFC is or what it's for - and if they did they probably wouldn't care. Go read Lessig's Code, it might prove enlightening to you. The point is extremely simple: there's a set of established rules (or etiquette, if you will) and newcomers might as well stick to them. If newcomers decide they don't like the rules, they are free to go away and form they own forum or do whatever pleases them: they seem to end up forming things like discussion boards where smilies come in the form of animated images, there's no easy way to keep track of who has replied to whom and where it is not only accepted but even expected that you edit your own messages after posting them. Fine. If that's what they want, live and let die. But that's hardly a reason to bring their rules to the established fora. These daft stuff had a reason: efficiency. It's not only economic efficiency (fully quoting the original message and adding a single line at the top is a waste of bandwidth, which used to be, and still is in many places, expensive), but of time management and time sharing. If I have to spend 10 extra seconds decyphering your messages because you don't know how to quote, your messages are a waste of my time, and that, last time I checked, hasn't got any cheaper than it was before. In short: noneone is going to stop you from wasting your time, but don't waste others'. -- Marcelo | Item 23: Don't try to return a reference when you must [EMAIL PROTECTED] | return an object | -- Scott Meyers, Effective C++
Re: Do not touch l10n files
On Sun, 18 May 2003 17:10:29 +0200, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: Unfortunately, there does not seem to be any possibility to prevent translation work from being done on my packages. Unfortunately, there is a large population of the world that does not understand english at all, but only their native language. Highly technical packages like zebra, netfilter-related stuff and linux-atm are most likely to be used by people who know English. Not speaking English will make running routers and/or internet security systems almost impossible anyway. I do not have any objection against end-user packages like KDE, Office Suites and Word Processors to be internationalized, but it seems pointless do try that effort for technical, geek-only packages. 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: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, 18 May 2003 15:30:52 +0100, Matt Ryan [EMAIL PROTECTED] said: Andreas Metzler wrote: Hello, Which does not matter at all. This memo does not specify an Internet standard of any kind. having it distributed as RFC is just a convenience, because searching for rcf1855 on google will find perfect hits en masse. Hello, Finding it is not the problem. As I stated and if they did they probably wouldn't care means that its one thing to read it, but what if they don't act on it? Then they shall be ignored. manoj -- Commenting on the advantages of bisexuality, Woody Allen once remarked It doubles your chances of getting a date on Saturday night. 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: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, 18 May 2003 15:25:42 +0100, Matt Ryan [EMAIL PROTECTED] said: Neil McGovern wrote: These are all valid points, however, I still don't want to read HTML e-mail in mutt. You are figting a losing battle. If the MUA that someone uses is set-up to send HTML (rich test, whatever) email then you are highly unlikely to get them to change it. Some devices (cable TV email?) may not even be able to turn it off. Whatever the arguements are for running a lean mean email client its probably going to have to cope with HTML email or you are going to have to limit who you interact with! I have no issue withg not interacting with such people -- if they can't change the default format of their mail messages; it is unlikely that they say anything of interest to me. As I said, I like to warn people of this. Then their email goes to the bitbucket. manoj -- A countryman between two lawyers is like a fish between two cats. Ben Franklin 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: Maintaining kernel source in sarge
On Sun, 18 May 2003 16:52:54 +0200, Martin Schulze [EMAIL PROTECTED] said: I also wonder if there are efforts in progress to unify the kernel source through more than two architectures? This would require a group or architecture maintainers (current kernel package mantainers) to work collaboratively towards this goal. When I first envisaged the kernel source and kernel-patch system, I always figured there should be a single source package per version -- the one you get from kernel.org. *EVERY* arch, including i386, should provided a kernel-patch package with all the changes for their arch based on the pristine kernel source. There is also a mechanism to order the order in which kernel-patches are applied -- so if, say, a m68k kernel image maintainer wanted to create a patch relative to the i386 patches, they could depend on that patch, and order the m68k kernel-pacth to be applied later in the chain than the i386 patch. This dependency-and-ordering mechanism could be extended to third party modules. People interested in hammering out details of this mechanism, and kernel image maintainers, please contact me; perhaps it is time to create policy for kernel patches. manoj -- Chip Salzenberg sent me a complete patch to add System V IPC (msg, sem and shm calls), so I added them. If that bothers you, you can always undefine them in config.sh. :-) --Larry Wall in [EMAIL PROTECTED] 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: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, 18 May 2003 10:26:38 +0100, Matt Ryan [EMAIL PROTECTED] said: Emile van Bergen wrote: So what do you propose then, to drop everything just because you cynically point out that a lot of rules are being violated today? What I'm saying is that (a lot of) these rules are archaic and irrelevant in today's Internet world. Firstly I doubt any of the people who violate the rules are even aware what an RFC is or what it's for - and if they did they probably wouldn't care. Does it matter to the sender that they put a couple of extra lines in their signature and this *may* cause a few extra seconds download time for the recipient? Will their computer explode if they type their message in CAPITALS? Only indirectly. People doing so shall end up in the kill files of people like me -- and if they ever need responses to questions (anyone who does not know what an RFC is is likely to have questions that people like me can answer), well, they shall be out of luck. Rather than this happening silently, we inform the user in no uncertain terms that a breach of nettiquette occurred. It is up to them to heed the warning or not -- and figure if the consequences matter to them. manoj -- I love mankind ... It's people I hate. 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: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, 18 May 2003 22:54:08 +0800, Cameron Patrick [EMAIL PROTECTED] said: On Sun, May 18, 2003 at 11:38:14AM +0100, Neil McGovern wrote: These are all valid points, however, I still don't want to read HTML e-mail in mutt. Why not? Mutt deals perfectly well with HTML e-mail It is not merely a matter of being able to deal with HTML email. It is a matter of wanting to do so. So far, the correlation between HTML and things I want to read has been entirely negative. manoj -- Swipple's Rule of Order: He who shouts the loudest has the floor. 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: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, May 18, 2003 at 03:25:42PM +0100, Matt Ryan wrote: Neil McGovern wrote: These are all valid points, however, I still don't want to read HTML e-mail in mutt. You are figting a losing battle. Unfortunatly, this may be so, but the latest trend I personally have seen is away from HTML e-mail. then you are highly unlikely to get them to change it. I disagree. Once I've explained why I don't like HTML e-mail, people normally see 'my side' and switch. Some devices (cable TV email?) may not even be able to turn it off. Whatever the arguements are for running a lean mean email client its probably going to have to cope with HTML email or you are going to have to limit who you interact with! I don't have a problem with those who CAN'T send in plain-text. I just prefer not to receive HTML e-mail. Yes, but then if the majority of clients can send/recive HTML email, who has the compatibility problem? The same train of thought will bring down W3C and HTML guidelines, and in fact, the principal that gcc/debian/java/... works on all platforms. The majority of people use MS Windows. Thus, why should linux be supported? On the whole bandwidth issue, I know it's been flogged to death but here's a prime example: An ex-lecturer (one which was, ironically, meant to be teaching good programming techniques) sent us a Microsoft Word HTML formatted *one-line* e-mail that totaled over 100k. Following that trend, and using a 56k dial-up, do you really want to spend your time downloading a message that says Thanks for your message for 3 minutes? Neil -- 16 Channels in mode 4 I disclaim everything I can under English law. gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li 8DEC67C5
Bug#193772: ITP: guidedog -- NAT/masquerading/port-forwarding configuration tool for KDE
Package: wnpp Version: unavailable; reported 2003-05-18 Severity: wishlist * Package name: guidedog Version : 0.9.1 Upstream Author : Simon Edwards [EMAIL PROTECTED] * URL : http://www.simonzone.com/software/guidedog * License : GPL Description : NAT/masquerading/port-forwarding configuration tool for KDE Guidedog is a KDE utility which allows to use easily activate and configure your machine for packet routing, Network Address Translation/IP Masquerading (NAT) and port-forwarding.
Re: Do not touch l10n files (was Re: DDTP issue)
[All Cc's removed] On Sat, May 17, 2003 at 07:54:55AM +0200, Fabio Massimo Di Nitto wrote: [...] I don't believe that there is not an estestic layout that can satisfy all the languages we have in Debian. What is the rationale for having a single layout for all languages? How do developers check how translations are rendered? Don't forget that most of the text we use in descriptions (or templates, or whatever) are based on technical language and terms, imho most of them farly new i would say and only recently adopted by common languages. Could you please be more explicit? I do not understand how this sentence is related to the issue discussed here. Denis
debian-devel@lists.debian.org
15000 YESKY 2 100 (Pageview)15000 (IP)1800 8 3 4 5 20-45 [EMAIL PROTECTED] Q Q332481 http://www.winzheng.com/
Re: Maintaining kernel source in sarge
On Mon, 19 May 2003 03:06, Manoj Srivastava wrote: When I first envisaged the kernel source and kernel-patch system, I always figured there should be a single source package per version -- the one you get from kernel.org. *EVERY* arch, including i386, should provided a kernel-patch package with all the changes for their arch based on the pristine kernel source. Definately. This should be done if only to avoid multiple copies of a 27M bzip2 archive wasting everyone's disk space and network bandwidth. Also regarding the i386 arch, multiple patches would be good. Something in the i386 patch gives me lots of 'D' state processes, if the patch was separated into a few smaller patches then it would be easier to track down the cause. There is also a mechanism to order the order in which kernel-patches are applied -- so if, say, a m68k kernel image maintainer wanted to create a patch relative to the i386 patches, they could depend on that patch, and order the m68k kernel-pacth to be applied later in the chain than the i386 patch. Or if there's a patch that everyone needs such as the ptrace patch then only one package needs to provide it and everything else can depend on it. Why not have a security kernel patch package which starts out as a zero byte file and gets bigger as the need dictates. Next we need a mechanism for tracking which version of each patch was used in the compilation. Was your kernel compiled with version 0 of the security patch or version 1 which has the ptrace fix? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Do not touch l10n files
On Sat, May 17, 2003 at 11:39:02PM +0200, Marc Haber wrote: On Wed, 14 May 2003 01:54:34 +0200, Nicolas Boullis [EMAIL PROTECTED] wrote: You're probably right, those useless l10n teams are annoying. No offense intended, but actually I would prefer my packages to stay untranslated. I am not an English native speaker, and by no way fluent in English, but I feel that the documentation for most of the packages I maintain (which are mostly technical packages) should be read in English to avoid misunderstandings. If it would be possible to translate technical documents without causing misunderstanding, I would be doing my German translation myself. Unfortunately, there does not seem to be any possibility to prevent translation work from being done on my packages. We are mostly talking about debconf templates and package descriptions; after looking at your packages I do not see how these texts can be considered as being technical documents. Denis
debian-devel@lists.debian.org
15000 YESKY 2 100 (Pageview)15000 (IP)1800 8 3 4 5 20-45 [EMAIL PROTECTED] Q Q332481 http://www.winzheng.com/
debian-devel@lists.debian.org
15000 YESKY 2 100 (Pageview)15000 (IP)1800 8 3 4 5 20-45 [EMAIL PROTECTED] Q Q332481 http://www.winzheng.com/
Re: Do not touch l10n files
On Sun, May 18, 2003 at 06:55:37PM +0200, Marc Haber wrote: On Sun, 18 May 2003 17:10:29 +0200, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: Unfortunately, there does not seem to be any possibility to prevent translation work from being done on my packages. Unfortunately, there is a large population of the world that does not understand english at all, but only their native language. Highly technical packages like zebra, netfilter-related stuff and linux-atm are most likely to be used by people who know English. Not speaking English will make running routers and/or internet security systems almost impossible anyway. (...) You would be surprised in any case, if speaking English would be a prerequisite for running routers then the Internet would not be as it is today. Regards Javi pgppeHZeTxvFa.pgp Description: PGP signature
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: It's very rare for me to have a HTML email that I actually want to read, I probably should configure my mail server to reject them all. I have sendmail rules to do that. I may go back to rejecting multipart/alternative mail as well. (sendmail.mc changes available on request.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html Text is a way we cheat time. -- Patrick Nielsen Hayden
Re: Do not touch l10n files
Hi, On Sun, May 18, 2003 at 10:39:21PM +0200, Javier Fernández-Sanguino Peña wrote: On Sun, May 18, 2003 at 06:55:37PM +0200, Marc Haber wrote: On Sun, 18 May 2003 17:10:29 +0200, Javier Fernández-Sanguino Peña [EMAIL PROTECTED] wrote: Unfortunately, there does not seem to be any possibility to prevent translation work from being done on my packages. Unfortunately, there is a large population of the world that does not understand english at all, but only their native language. Highly technical packages like zebra, netfilter-related stuff and linux-atm are most likely to be used by people who know English. Not speaking English will make running routers and/or internet security systems almost impossible anyway. (...) You would be surprised in any case, if speaking English would be a prerequisite for running routers then the Internet would not be as it is today. Yes, most notably the spam levels would be much more bearable. Sorry, couldn't resist. Of course, that's also an argument /for/ translating mail server documentation. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, May 18, 2003 at 07:26:34PM +0100, Neil McGovern wrote: I disagree. Once I've explained why I don't like HTML e-mail, people normally see 'my side' and switch. And if they still don't see it, the following 'html' might convince them, at least if they use outlook (be careful. It is not harmless) htmlforminput type crash/form/html Another way is to encourage them, and support MIME multipart/alternative mails, just not text/plain and text/html, but application/x-troff and application/postscript. Frank
Packages with i18n support disabled
Hi, below is a list of source packages containing gettext .po files, for which binary packages do not ship any file under a LC_MESSAGES directory. There might be several reasons: a. Programs use gettext PO files to store translations but manage them with other tools at run time (eg. abiword, Zope or Qt applications) b. PO files are not used, e.g. they are test files (po-debconf) c. I18n support is not enabled at build time d. Errors in PO files prevent l10n I am going to file bugs about (c) and (d), but it needs manual checking. If you know that your packages are correctly l10ned, or if you want to help me checking these packages, please let me know. Of course, maintainer names are only given to ease searching, there is no personal attack against those mentioned here (otherwise I would at least have removed my name from this list). Thanks. Aaron Lehmann (aaronl at vitelus.com) skipstone akira yamada (akira at debian.org) libintl-gettext-ruby (b) Alastair McKinstry (mckinstry at computer.org) console-common gtk+2.0-directfb Alberto Gonzalez Iniesta (agi at agi.as) fwlogwatch Aurelien Jarno (aurel32 at debian.org) hddtemp Bastian Blank (waldi at debian.org) zope-zwiki Ben Burton (bab at debian.org) kile Bradley Bell (btb at debian.org) bakery-gnomeui1.3 Camm Maguire (camm at enhanced.com) gcl Carlos Laviola (claviola at debian.org) fpc (b) mp3kult Chip Salzenberg (chip at debian.org) libcpanplus-perl Christian Marillat (marillat at debian.org) gnome-panel gnome-themes Christian Perrier (bubulle at debian.org) geneweb (b) Craig Small (csmall at debian.org) lprng Daniel Bungert (drb at debian.org) zssh Daniel Gubser (daniel.gubser at gutreu.ch) psad Daniel Jacobowitz (dan at debian.org) gdb David Coe (davidc at debian.org) zope-cmfphoto zope-cmfphotoalbum zope-cmfplone zope-localizer David Schleef (ds at schleef.org) comedilib Debian Install System Team (debian-boot at lists.debian.org) boot-floppies (a) Denis Barbier (barbier at debian.org) po-debconf(b) Ed Boraas (ed at debian.org) aime Enrique Robledo Arnuncio (era at debian.org) mctools-lite Enrique Zanardi (ezanard at debian.org) pointerize(b) Eray Ozkural (erayo at cs.bilkent.edu.tr) sourcenav Federico Di Gregorio (fog at debian.org) grass Fernando Sanchez (fer at debian.org) qcad Filip Van Raemdonck (mechanix at debian.org) gxset Francois Gurin (matrix at debian.org) fsviewer Frederic Peters (fpeters at debian.org) pronto Greg Norris (adric at debian.org) rio500 Hidetaka Iwai (tyuyu at debian.or.jp) widestudio Ivan E. Moore II (rkrusty at debian.org) qt-embedded (b) qt-embedded-free(b) qt-x11 (b) James LewisMoss (dres at debian.org) xemacs21-packages (b) Jan-Hendrik Palic (jan.palic at linux-debian.de) gtkpbbuttons pbbuttonsd powerprefs Javier Fernandez-Sanguino Pen~a (jfs at computer.org) bastille Jereme Corrado (jereme at zoion.net) faqomatic Jordi Mallach (jordi at debian.org) freeciv Joshua Kwan (joshk at triplehelix.org) ircd-hybrid Josselin Mouette (joss at debian.org) gnome-themes-extras Kyle McMartin (kyle at debian.org) mad Lenart Janos (ocsi at debian.org) dfm #193484 Luca - De Whiskey's - De Vitis (luca at debian.org) phpgroupware Luca Filipozzi (lfilipoz at debian.org) ifhp Mario Lang (mlang at debian.org) oleo Mark Brown (broonie at debian.org) tua Martin Loschwitz (madkiss at debian.org) qt-x11-free (b) Martin Mitchell (martin at debian.org) apcupsd eject #192829 Masayuki Hatta (mhatta at debian.org) abiword (a) Matt Zimmerman (mdz at debian.org) gpe-todo Matthew Garrett (mjg59 at srcf.ucam.org) dasher Mike Markley (mike at markley.org) aide Noah Meyerhans (noahm at debian.org) wdm Peter Karlsson (peterk at debian.org) turqstat Phil Blundell (pb at debian.org) libgpewidget Robert Woodcock (rcw at debian.org) id3lib Robin Verduijn (robin at debian.org) kvirc Samuele Giovanni Tonon (samu at debian.org) apcupsd-devel Sebastian Rittau (srittau at debian.org) orbit Sergio Talens-Oliag (sto at debian.org) python-htmltmpl (b) Siggi Langauf (siggi at debian.org) gnome-xine Stefan Schwandter (swan at debian.org) snd Steve Kostecke (steve at debian.org) linuxlogo Steve Langasek (vorlon at debian.org) unixodbc Susumu OSAWA (susumuo at debian.org) bookview Søren Boll Overgaard (boll at debian.org) gkrellweather Takuo KITAME (kitame at
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Sun, May 18, 2003 at 03:28:27PM +0100, Matt Ryan wrote: Right now we're getting really damn close to anarchy, when everyone and their dog has the means to entirely obliterate everyone else's mailbox with unwanted whatever-they-have-to-say, and sometimes even obliterate their computer (with viruses). We have the ability to annialte each other on the highways (and to a certain degree we do), but its a rick of being involved for the benefits it brings you. It would be nice to make everyone drive well, but they don't and they won't play nice with your email either. Well, yeah, sure, but the highway analogy doesn't apply. There isn't a single technical reason why I as a random person need to ever be in any sort of contact with a spammer to keep the system running. -- 2. That which causes joy or happiness.
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Hi, On Sun, May 18, 2003 at 10:26:38AM +0100, Matt Ryan wrote: Emile van Bergen wrote: So what do you propose then, to drop everything just because you cynically point out that a lot of rules are being violated today? What I'm saying is that (a lot of) these rules are archaic and irrelevant in today's Internet world. Firstly I doubt any of the people who violate the rules are even aware what an RFC is or what it's for - and if they did they probably wouldn't care. So? I may as well ask the question again. I also don't understand the phrase today's Internet world. You mean with the hordes running Outlook and shopping on the clickable amazing discoveries / quantum shopping / tell sell channel that's the WWW? How does that make sane email communication standards less relevant? Does it matter to the sender that they put a couple of extra lines in their signature and this *may* cause a few extra seconds download time for the recipient? Is forwarding a chain letter going to get them cut off by their ISP? Will their computer explode if they type their message in CAPITALS? The answer to these is no, and I hazard a guess that 'abuse' of any of these rules would end up at the same conclusion - it's not relevant to me therefore I'll dismiss it. So if your ISP doesn't cut you off, or your computer doesn't explode, you'll dismiss the friendly requests and advice given by the people you're communicating with. That doesn't sound very social, does it? Society evolves and with it rules change, we need to accept this and see what evolves - if it turns out to be bad then limits will have to be applied, but I'm not seeing a complete state of anarchy break out yet... Again, I ask: what's the alternative you are proposing? What do you want? It seems you just want to send HTML mail, and not feel sorry for it. Be my guest. Just don't send it my way. Or to a mailing list, or to anybody you don't know, or to somebody of who you don't know whether he or she accepts HTML mail, for that matter. Thanks, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl pgpoK2iqfKpoU.pgp Description: PGP signature
Re: Maintaining kernel source in sarge
On Sun, May 18, 2003 at 04:52:54PM +0200, Martin Schulze wrote: I also wonder if there are efforts in progress to unify the kernel source through more than two architectures? This would require a group or architecture maintainers (current kernel package mantainers) to work collaboratively towards this goal. I thought this was already the case? Looking at woody in fact, it appears to only exceptions appear to be HPPA and IA64: kernel-source-2.2.22 - Linux kernel source for version 2.2.22 kernel-source-2.4.10 - Linux kernel source for version 2.4.10 kernel-source-2.4.14 - Linux kernel source for version 2.4.14 kernel-source-2.4.16 - Linux kernel source for version 2.4.16 kernel-source-2.4.17 - Linux kernel source for version 2.4.17 kernel-source-2.4.17-hppa - Linux kernel source for version 2.4.17 on HPPA kernel-source-2.4.17-ia64 - Linux kernel source for version 2.4.17 on IA-64 kernel-source-2.4.18 - Linux kernel source for version 2.4.18 kernel-source-2.4.18-hppa - Linux kernel source for version 2.4.18 on HPPA kernel-source-2.4.19 - Linux kernel source for version 2.4.19 kernel-source-2.4.20 - Linux kernel source for version 2.4.20 with Debian patches user-mode-linux builds by depending on kernel-source-2.4.20 and automatically applying the UML patch, I wonder if the same thing could also be doine for -hppa and/or -ia64? -- Brian May [EMAIL PROTECTED]
Re: Packages with i18n support disabled
Hello. On Sun, 18 May, 2003 at 23:39:09 +0200, Denis Barbier wrote: There might be several reasons: b. PO files are not used, e.g. they are test files (po-debconf) ... zssh Upstream original source contains the full lrzsz source tree. zssh isn't gettextized, but lrzsz is (that is where the po file is from), so zssh fits into category b. -- Daniel Bungert
Re: Maintaining kernel source in sarge
On Mon, May 19, 2003 at 09:33:48AM +1000, Brian May wrote:
Looking at woody in fact, it appears to only exceptions appear to be
HPPA and IA64:
kernel-source-2.2.22 - Linux kernel source for version 2.2.22
kernel-source-2.4.10 - Linux kernel source for version 2.4.10
kernel-source-2.4.14 - Linux kernel source for version 2.4.14
kernel-source-2.4.16 - Linux kernel source for version 2.4.16
kernel-source-2.4.17 - Linux kernel source for version 2.4.17
kernel-source-2.4.17-hppa - Linux kernel source for version 2.4.17 on HPPA
kernel-source-2.4.17-ia64 - Linux kernel source for version 2.4.17 on IA-64
kernel-source-2.4.18 - Linux kernel source for version 2.4.18
kernel-source-2.4.18-hppa - Linux kernel source for version 2.4.18 on HPPA
kernel-source-2.4.19 - Linux kernel source for version 2.4.19
kernel-source-2.4.20 - Linux kernel source for version 2.4.20 with Debian
patches
2.2.22 has i386-{compact,idepci} and some alpha kernel images
2.4.10 has no reason to even be in the archive as far as I can tell
2.4.14 has an associated m68k patch, but no kernel images
2.4.16 has i386 and ARM kernel images
2.4.17 has powerpc, hppa, ia64, mips and mipsel kernel images
2.4.18 has i386, alpha, hppa, powerpc, and sparc kernel images
2.4.19 has mips and sun4u kernel images
2.4.20 did not ship with woody
We could practically shrink woody by one CD if we could consolidate some of
these.
In addition, we have:
kernel-image-2.2.10-apus | 2.2.10-13 |stable | powerpc
kernel-image-2.2.10-powerpc-apus | 2.2.10-13 |stable | source
kernel-image-2.2.19-netwinder | 20011109.1 |stable | source, arm
kernel-image-2.2.19-riscpc | 20011109 |stable | source, arm
kernel-image-2.2.20 | 2.2.20-5 |stable | i386
kernel-image-2.2.20-amiga | 2.2.20-2 |stable | source, m68k
kernel-image-2.2.20-atari | 2.2.20-1 |stable | source, m68k
kernel-image-2.2.20-bvme6000 | 2.2.20-1 |stable | source, m68k
kernel-image-2.2.20-chrp | 2.2.20-3 |stable | powerpc
kernel-image-2.2.20-compact | 2.2.20-5 |stable | i386
kernel-image-2.2.20-i386 | 2.2.20-5 |stable | source
kernel-image-2.2.20-idepci | 2.2.20-5 |stable | i386
kernel-image-2.2.20-mac | 2.2.20-1 |stable | source, m68k
kernel-image-2.2.20-mvme147 | 2.2.20-1 |stable | source, m68k
kernel-image-2.2.20-mvme16x | 2.2.20-1 |stable | source, m68k
kernel-image-2.2.20-pmac | 2.2.20-3 |stable | powerpc
kernel-image-2.2.20-prep | 2.2.20-3 |stable | powerpc
kernel-image-2.2.20-reiserfs | 2.2.20-4 |stable | i386
kernel-image-2.2.20-reiserfs-i386 | 2.2.20-4 |stable | source
kernel-image-2.2.20-sun4cdm | 9 |stable | sparc
kernel-image-2.2.20-sun4dm-smp | 9 |stable | sparc
kernel-image-2.2.20-sun4u | 9 |stable | sparc
kernel-image-2.2.20-sun4u-smp | 9 |stable | sparc
for which there is no corresponding kernel-source in woody. This means that
these kernels cannot be built on woody, and this is very problematic for
support (specifically security fixes). There seem to be about 85
kernel-image packages in woody, and I have no idea how many of them can
actually be built, much less patched and supported in any sane way.
To fix the ptrace bug, the s390 and mips architectures rolled the ptrace
security fix into kernel-patch-2.4.17-s390 and
kernel-patch-2.4.{17,19}-mips. This makes things even worse, because if
kernel-source-2.4.{17,19} are patched to contain the fix, it will almost
certainly make these architectures' kernel images fail to build because of
patch conflicts, and require that the -patch packages be updated _again_ to
undo this.
user-mode-linux builds by depending on kernel-source-2.4.20 and
automatically applying the UML patch, I wonder if the same thing could
also be doine for -hppa and/or -ia64?
UML doesn't build a kernel-source package at all; it works essentially like
kernel-image-x.y.z-i386. That is, it build-depends on kernel-source-x.y.z
and kernel-patch-uml, and builds with those.
This approach has its share of problems, of course. In fact, to use UML as
an example again, I believe user-mode-linux will not build in woody because
it build-depends on the exact version of kernel-patch-uml that it expects,
and 'testing' apparently does not care about build-dependencies.
The ideal solution would be to be able to share tarballs between source
packages. Then, all of the kernel-image packages could be built as if they
had a complete kernel source tree as their source package (which simplifies
things a lot), and yet we would only need one such tarball in the archive.
Of course, I have little idea how much work this would be to implement,
except that it would touch a lot of different tools. I don't have the time
anyway.
Making 'testing' aware of build-dependencies seems like it should be
significantly more straightforward, and if
Re: DebConf 3 for New Maintainers
Tollef Fog Heen dijo [Sun, May 18, 2003 at 04:21:15PM +0200]: | Side question: will there be a few machines for people who can't bring a | laptop ? Hopefully, yes, but if you can bring a laptop: do it. :) Tollef, I might be able to bring an extra laptop with me, as I am sure someone will find use for it. But, is there a need for it? (specially because I understand most international customs departments allow you to travel with one computer for personal use, and I would be playing with my luck here ;-) ) Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Packages with i18n support disabled
[EMAIL PROTECTED] (Denis Barbier) writes: Hi, Hi, below is a list of source packages containing gettext .po files, for which binary packages do not ship any file under a LC_MESSAGES directory. There might be several reasons: a. Programs use gettext PO files to store translations but manage them with other tools at run time (eg. abiword, Zope or Qt applications) b. PO files are not used, e.g. they are test files (po-debconf) c. I18n support is not enabled at build time d. Errors in PO files prevent l10n I am going to file bugs about (c) and (d), but it needs manual checking. [...] Christian Marillat (marillat at debian.org) gnome-panel gnome-themes You can remove these two packages. Christian
Re: Maintaining kernel source in sarge
On Sun, May 18, 2003 at 12:06:21PM -0500, Manoj Srivastava wrote: There is also a mechanism to order the order in which kernel-patches are applied -- so if, say, a m68k kernel image maintainer wanted to create a patch relative to the i386 patches, they could depend on that patch, and order the m68k kernel-pacth to be applied later in the chain than the i386 patch. This dependency-and-ordering mechanism could be extended to third party modules. People interested in hammering out details of this mechanism, and kernel image maintainers, please contact me; perhaps it is time to create policy for kernel patches. dh-kpatches provides a dependency/ordering facility which has worked well for me in my packages. It also provides /usr/share/doc/kernel-image-foo/applied-patches documenting the package and version for each patch that is applied. I think this would be a good starting point for such a policy, since it is already being applied in Debian. -- - mdz
Re: Maintaining kernel source in sarge
On Mon, May 19, 2003 at 05:13:54AM +1000, Russell Coker wrote: Definately. This should be done if only to avoid multiple copies of a 27M bzip2 archive wasting everyone's disk space and network bandwidth. Also regarding the i386 arch, multiple patches would be good. Something in the i386 patch gives me lots of 'D' state processes, if the patch was separated into a few smaller patches then it would be easier to track down the cause. The kernel-source diff used to be quite manageable; this iteration seems to be much heavier than in the past (compare README.Debian). IMO, our base kernel-source diff should contain only things that absolutely everyone wants, like security and critical fixes, and things necessary for our boot process and kernel-image packages to work. Fixing typos and compiler warnings seems like it causes more problems than it solves, especially with regard to patch conflicts. Value added modifications would be more manageable in a separate kernel-patch package. Next we need a mechanism for tracking which version of each patch was used in the compilation. Was your kernel compiled with version 0 of the security patch or version 1 which has the ptrace fix? See my notes about dh-kpatches elsewhere in this thread. -- - mdz
unsubscribe
Guy Izsolt Systems Administrator BEELINE Technologies Unit 6 - 7, West End Corporate Park 305 Montague Road West End QLD 4101 AUSTRALIA Tel: +61-7-3004 6700 Fax: +61-7-3004 6799 Note: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error,please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. BEELINE Technologies and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Thank You. This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal - For more information please visit www.marshalsoftware.com
Debian conference in the US?
[I've already asked a few relevant individuals about this, but am opening it up to the list at their suggestion.] I've recently been in touch with somebody (a lawyer and professor concerned with government open source policy) who is interested in sponsoring a Debian conference here in Washington, DC, next spring, in conjunction with an international conference on open source in government. I understand that there has been historical opposition to holding events in this country, due in large part to our lovely political climate. While I can certainly sympathize -- I'm no fan of the DMCA and its ilk either -- I would like to offer some counterarguments: * Although I am unfortunately in no position to guarantee anyone's safety, I would estimate the risk of being arrested for DMCA violations or the like as extremely low unless you've managed to offend somebody important; the government really has better things to do, especially given the potential bad PR. * Quite a few of us already live in the US, and find the lack of local conferences rather inconvenient. * As mentioned, we have an enthusiastic sponsor lined up, which is a definite plus. What are other developers' feelings on the matter these days? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Debian conference in the US?
What are other developers' feelings on the matter these days? If we're doing let's have a conf where we normally don't how about we have it on the US's east coast aswell. I'd personally argue for the nothern Virginia are myself. Too many conferences are held on the US's West coast, and if conferences do get to the East coast, they are always in New York. That leaves the south eastern US folks out in the cold. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: Debian conference in the US?
Ben Collins [EMAIL PROTECTED] writes: If we're doing let's have a conf where we normally don't how about we have it on the US's east coast aswell. I'd personally argue for the nothern Virginia are myself. This would probably be in DC proper (specifically, at GWU) -- so a bit further north/east, but still well south of NY and thus hitting a previously neglected region. Too many conferences are held on the US's West coast, and if conferences do get to the East coast, they are always in New York. That leaves the south eastern US folks out in the cold. Indeed. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Warning: python-apt in testing broken, aptitude users DO NOT UPGRADE
Looks like the python2.2 stuff migrated into testing without noticing that it breaks python-apt. Anyone using python-apt (e.g. aptitude users) are advised not to upgrade. Anyone know how exactly the testing scripts managed to miss this breakage? -- Taral [EMAIL PROTECTED] This message is digitally signed. Please PGP encrypt mail to me. Most parents have better things to do with their time than take care of their children. -- Me pgpvqGX9Jli7Y.pgp Description: PGP signature
Re: Do not touch l10n files (was Re: DDTP issue)
On Sun, 18 May 2003, Tollef Fog Heen wrote: * Henrique de Moraes Holschuh | On Sat, 17 May 2003, Martin Schulze wrote: | should always try to stay as close to the original as you can. | Changing the text layout is a NO-GO in my opinion - and in the | opinion of our Apache people apparently. | | Apparently. We are trying to bring to light that proper l10n | requires more than that. We asked why the removal of the number «3» from the word «PHP3» caused the format of the whole description to the changed. We asked _why_, we did not say «do not do this». First, we wanted to know why. Then, we might want to ask it to be changed back. Somehow, this whole discussion has been blown completely out of propositions. Maybe. But as you see, Tollef, the fact that l10n includes far more than simple translations ISN'T common knowlege... :) -- 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
[fwd] Debian.cl (from: ek3k0@vtr.net)
A ver... Prefiero traer esto acá, entre cuates, antes de pasarlo al foro grandote. ¿Se lo enviamos a debian-legal? ¿Hay algo que se pueda hacer al respecto? ¿Algún chileno a la mano, ocnocen la política de resolución de disputas en .cl? Saludos, - Forwarded message from Ekeko [EMAIL PROTECTED] - From: Ekeko [EMAIL PROTECTED] To: Usuarios Debian debian-user-spanish@lists.debian.org Date: 18 May 2003 20:05:07 -0400 Subject: Debian.cl X-Mailing-List: debian-user-spanish@lists.debian.org archive/latest/64546 Veo que debian.cl apunta a una empresa chilena que, por lo que veo, no se relaciona con Debian. ¿Qué podemos hacer? -- Ekeko [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
