Re: Debian conference in the US?
On Sat, 24 May 2003 09:51, Alan Shutko wrote: The citizens of the US have a little more power than the rest of the world, in that you have a *vote* as to who gets to fuck the rest of the world. Well, didn't work that way last time... They got their second choice. -- 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
Bug#194515: ITP: debdivert -- Debian packaging aid to create patch packages
Package: wnpp Version: unavailable; reported 2003-05-24 Severity: wishlist * Package name: debdivert * URL : http://www.some.org/ License : GPL Description : Debian packaging aid to create patch packages This package aims to create packages which replace files of another package. If you want to create some tuned packages based on another debian package and if chagnes of your tuned packages are only few files of the package, then your tuned packages would consist of only these few files and share other files with its original packages. This package is considered as patch package to these original packages. . You can create packages which simply overwrite files of another package easily, and also create diversion-enabled packages, that is, these original files which are changed by your tuned packages will be diverted before installing yours and will be recovered after removing yours automatically. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux vass.taru.net 2.4.20-686 #1 Mon Jan 13 22:22:30 EST 2003 i686 Locale: LANG=ja_JP.eucJP, LC_CTYPE=ja_JP.eucJP
Re: Bug#194515: ITP: debdivert -- Debian packaging aid to create patch packages
On Sat, 24 May 2003, Masato Taruishi wrote: Package: wnpp Version: unavailable; reported 2003-05-24 Severity: wishlist * Package name: debdivert * URL : http://www.some.org/ License : GPL Description : Debian packaging aid to create patch packages [snip] Er, what's the point? This seems like a waste of package space, mirror space, ftpmaster time.
Re: What makes a debconf?
On Fri, May 23, 2003 at 05:25:29PM -0400, Joe Drew wrote: Do we need some method of deciding what constitutes 'the' Debconf? No, as everyone knows that the only true Debconf are the ones in Australia, with LCA. ;-). -- Brian May [EMAIL PROTECTED]
Re: Debian conference in the US?
On Fri, May 23, 2003 at 03:14:48PM -0400, Jaldhar H. Vyas wrote: My only objection to a conference in the US is the weather is miserable. I want to go somewhere warm! Debian MiniConf @ Linux.conf.au, January 2004. http://conf.linux.org.au/. Speakers lined up for the main conference (which tends to draw around 300-400 people) apparently include Tridge, Rusty, Bdale, Keith Packard, Maddog, Rasmus and Havoc Pennington; the call for papers will probably come out in a month or two. The Debian miniconf drew ~50 people in 2002 and ~100 this year. Please direct criticism of Australian foreign policy to /dev/null or your local MP. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpVE5yPh7rup.pgp Description: PGP signature
Menu's 24 color policy (was: apt-listchanges output for beterraba.horta)
Hello! Does this mean that the, IMHO brain-dead, 24-color limit has been droped? From menu's changelog: * No more require icons to use the colors from cmap.xpm. Closes:#193231, #175430, #192218, #97080 * No more install cmap.xpm. Closes:#172092 []s! -- [EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov Debian: http://www.debian.org * http://www.debian-br.org Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br
Re: Debian conference in the US?
On Thu, May 22, 2003 at 06:15:48PM +0900, Miles Bader wrote: Hi Greg, Now that you've got this release out, have you given any thought to the message I sent earlier about merging gdb server versions? Kindly get this on-topic shit out of this off-topic thread. ;-) -- G. Branden Robinson| If God had intended for man to go Debian GNU/Linux | about naked, we would have been [EMAIL PROTECTED] | born that way. http://people.debian.org/~branden/ | pgpLrtb7Jybqw.pgp Description: PGP signature
Re: Bug#194515: ITP: debdivert -- Debian packaging aid to create patch packages
2003$BG/(B05$B7n(B24$BF|(B(?)$B$N(B14$B;~(B32$BJ,$K(B Adam Heath $B[)$/(B: (B (B Package: wnpp (B Version: unavailable; reported 2003-05-24 (B Severity: wishlist (B (B * Package name: debdivert (BLicense : GPL (BDescription : Debian packaging aid to create patch packages (B (B [snip] (B (B Er, what's the point? This seems like a waste of package space, mirror space, (B ftpmaster time. (B (BAh, the main point of this package is to create a local ad-hoc package (Bwhich can coexist with its official package. Escpecially, I can manage (Bmy temporary on-going improvement to some debian package as a debian (Bpackage. I didn't think to waste official debian packages because we (Bshouldn't upload this kind of patch packages to the official but merge (Bthe patch to the official packages if we want to share them on public. (B (B-- (BMasato Taruishi [EMAIL PROTECTED]
Re: What makes a debconf?
On Fri, May 23, 2003 at 10:02:42PM -0400, David B Harris wrote: The problem is that people who can get expenses reimbursed need to have a focus. Sponsors need to have a focus. There needs to be a major conference for these kinds of things; in other words, it has to be billed as something more than just a bunch of people getting together, even if that's what *all* conferences are at heart. If a Debian Developer's employer is willing to let them go to one trade conference a year, expenses paid or partially paid, and the options are one of a dozen Debian conferences or LinuxWorld, their employers will say LinuxWorld. If, on the other hand, the options are one of a dozen Debian conferences, Debconf, and LinuxWorld, their employers will likely allow either of the last two. True enough, but since USENIX took over Atlanta Linux Showcase, ran it for one year, and then shot it in the back of a head like a drug kingpin assassinating an unwanted lieutenant, Debian developers in the U.S., particularly the southeast, have been missing a bit of an opportunity for a gathering. I really miss ALS. -- G. Branden Robinson|The first thing the communists do Debian GNU/Linux |when they take over a country is to [EMAIL PROTECTED] |outlaw cockfighting. http://people.debian.org/~branden/ |-- Oklahoma State Senator John Monks pgpFRE1cdW2o1.pgp Description: PGP signature
ITP: pyblosxom -- simple weblog (blog) written in Python
Package: wnpp Version: unavailable; reported 2003-05-24 Severity: wishlist * Package name: pyblosxom Version : 0.7beta1-1 Upstream Author : Wari Wahab [EMAIL PROTECTED] * URL : http://roughingit.subtlehints.net/pyblosxom/ * License : Python Description : simple weblog (blog) written in Python Pyblosxom is a blog, which allows you to keep an online journal. It acts as an extension for a web server such as Apache. Pyblosxom is very easy to set up and use; entries are stored in simple text files, and allows you to categorize them using directories. . Pyblosxom is so-named because it was inspired by the blosxom package. If you're interested, prerelease packages are in my staging repository (see URL:http://people.debian.org/~walters). -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux columbia 2.4.20+xfs #1 Fri May 2 22:54:36 EDT 2003 i686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Re: Debian MIA check
[James Troup] Tor Slettnes [EMAIL PROTECTED] I forwarded this email to his other address, which I came across in a mail from a common friend of our.
Re: Bug#194515: ITP: debdivert -- Debian packaging aid to create patch packages
On 24 May 2003 15:40:08 +0900 Masato Taruishi [EMAIL PROTECTED] wrote: Ah, the main point of this package is to create a local ad-hoc package which can coexist with its official package. Escpecially, I can manage my temporary on-going improvement to some debian package as a debian package. I didn't think to waste official debian packages because we shouldn't upload this kind of patch packages to the official but merge the patch to the official packages if we want to share them on public. The main question is what on god's green earth does this do that dpkg-divert doesn't do? Looking at the package description, it implies that it will in fact do a lot less than dpkg-divert unless you tell it otherwise. pgpaRVCmGccgC.pgp Description: PGP signature
Re: Unofficial projects related with Debian.
Le Fri, May 23, 2003 at 02:22:08PM -0300, Gustavo Franco écrivait: You didn't understand my affirmation.Debian Desktop is on www.debian.org and many others aren't there, for example: Mono for Debian and ipv6. What are the rules to be there? AFAIK, there are no documented rules. The rules are quite simple: is there someone willing to write those pages ? I have this very same problem for DebianEdu, if I want a page on www.debian.org I have to prepare it but I have no time for that. I also don't have any contributor willing to do that so we have to leave with the initial Wiki... Cheers, -- Raphaël Hertzog -+- http://www.ouaza.com Formation Linux et logiciel libre : http://www.logidee.com Earn money with free software: http://www.geniustrader.org
Re: Unofficial projects related with Debian.
On Fri, May 23, 2003 at 09:55:33PM -0400, David B Harris wrote: http://www.debian.org/devel/, Projects section: * Debian Web Pages [...] * Alioth: Debian GForge Certainly seems that they're listed. The Debian Usability Research seems to be missing: http://deb-usability.alioth.debian.org Ciao, Enrico
Re: Bug#194515: ITP: debdivert -- Debian packaging aid to create patch packages
Masato Taruishi [EMAIL PROTECTED] wrote: Ah, the main point of this package is to create a local ad-hoc package which can coexist with its official package. Escpecially, I can manage my temporary on-going improvement to some debian package as a debian package. I didn't think to waste official debian packages because we shouldn't upload this kind of patch packages to the official but merge the patch to the official packages if we want to share them on public. The main question is what on god's green earth does this do that dpkg-divert doesn't do? Looking at the package description, it implies that it will in fact do a lot less than dpkg-divert unless you tell it otherwise. This creates a fragment to use dpkg-divert. It checks all md5sums of each package and lists files which we need to invoke 'dpkg-divert'. -- Masato Taruishi [EMAIL PROTECTED]
Re: Bug#194515: ITP: debdivert -- Debian packaging aid to create patch packages
David B Harris [EMAIL PROTECTED] wrote: On 24 May 2003 15:40:08 +0900 Masato Taruishi [EMAIL PROTECTED] wrote: Ah, the main point of this package is to create a local ad-hoc package which can coexist with its official package. Escpecially, I can manage my temporary on-going improvement to some debian package as a debian package. I didn't think to waste official debian packages because we shouldn't upload this kind of patch packages to the official but merge the patch to the official packages if we want to share them on public. The main question is what on god's green earth does this do that dpkg-divert doesn't do? Looking at the package description, it implies that it will in fact do a lot less than dpkg-divert unless you tell it otherwise. Reread it, please. | create diversion-enabled packages, that is, these original files | which are changed by your tuned packages will be diverted before | installing yours and will be recovered after removing yours | automatically. Afaict, this should enable you to * apt-get source foo * apply debdivert * build package * dpkg -i foo_1.0-debdivert_i386.deb with a foo_debdivert that can coexist with foo and has all the necessary calls to dpkg-divert needed for co-existence in its maintainterscripts. I still don't get why you wouldn't simply generate a modified version and install it _instead_ of the original package, unless foo also include a switch-debdivert-foo package that enables to choose to switch to officila package faster than 'dpkg -i official.deb' cu andreas
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 08:44:48AM +1000, Herbert Xu wrote: Guido Guenther [EMAIL PROTECTED] wrote: This only works if we have a _clean_ kernel-source-2.X.Y package. One of the reasons why maintaining kernel-patch-2.X.Y-arch packages is such a pain is the asymmetry between i386 and other arches - almost every time a new kernel-source package is uploaded the kernel-patch-2.X.Y-mips package has to be rediffed. So the first and maybe most important step I can understand your pain. However, most of the changes made to the kernel-source are not i386-specific. In fact, if they were, they would not be causing these patch conflicts that you're seeing. So essentially throwing them out means that your architecture will miss out on all bug fixes. If this turns out to be what most of you want, then that's fine and I will do just that. It's very hard to get these bug fixes anyway since when I do a _complete_ diff between kernel-source-2.X.Y in the archive and the kernel source for architecture foo I'll _always_ (accidentally) pull out all the bug fixes you made. Only diffing specific parts of the tree is unfortunately out of question (at least for mips(el)) since the diff is just too big to make this feasible. So having a separate i386 kernel-patch package would make things even easier since I can then first diff against a clean Linus tree (giving a minimal diff) and then look into your kernel-patch-*-i386 and apply all the fixes. What worries me a bit is that the majority of our users would have to pull an additional kernel-patch-*-i386 to build custom kernels but I'm not sure how many of the folks who build custom i386 kernels get the source packages from our archives, many of them get the source from kernel.org directly anyway, I'd guess. Regards, -- Guido
Re: What makes a debconf?
* Joe Drew ([EMAIL PROTECTED]) [030524 01:11]: It's not entirely clear to me what makes Debconf into 'the' Debian conference. For example, if this conference in the US ends up happening, what's to say it isn't Debconf 3? The defining characteristics, so far as I can define them, are that it is annual, and Debian developers go to it. that it is international, and is focused on debian regarding the topics of talks, surrounding events and such? Do we need some method of deciding what constitutes 'the' Debconf? and we do need THE Debconf. I am all for having as many debian meetings, install parties, debian beer hikes and Debian user group meetings as possible, preferable on a regualar basis. Everyting to let debian become a real-live (vs online/virtual) community, too! the intention of the debconf is to be the regular/annual meetingpoint for the debian developer/user community, where people can get in touch, enjoy the huge bandwidth of face-to-face communication, build relations to people otherwise on the other end of the earth and only met on irc/mailinglist, eat and talk,... in my opinion this servs to inspire and to enthuse people to spend insane amounts of their time on making debian the best operatingsystem. people should realise again that they are part of a greater cause, some kind of crusade, if you will. (c: it does that only if it is significant. it is less significant if it is less focused (as david pointed out in this thread) and less international. It needs to be unique for that. the significant amount of work and time (and money) the preparation of a debconf consumes will by itself ensure that there are not too many in one year. And those wishing and able to invest this time hopefully are enlightend enough to not destroy the debconf experience by creating the debconf3.2.5. it might be possible to have a debconf at several locations (even the US?) at the same time, with high-powered communication links (satellite links for video-tansmission of talks?). This sounds rather advanced and i know nothing about the economic and technical implications.
Re: Debian conference in the US?
On Thu, May 22, 2003 at 08:55:31PM -0700, Marc Singer wrote: This doesn't mean that we should not have a Debian conference in North America. I'm sure there are many North American DDs who'd like to meet more DDs in person. Having a conference in the US or Canada is not an endorsement of US foreign policy. You all probably know that there are some serious privacy issues involved in traveling to the US. Carriers are forced to pass all their information about the passengeres on to the US authorities, including: previous connecting flight, place of orginal departure, requests for special food (read: non pork), credit card information and other personal information. -- René Seindal ([EMAIL PROTECTED]) http://sights.seindal.dk/
Re: Unofficial projects related with Debian.
On Sat, 24 May 2003 10:19:38 +0200 Enrico Zini [EMAIL PROTECTED] wrote: http://www.debian.org/devel/, Projects section: * Debian Web Pages [...] * Alioth: Debian GForge Certainly seems that they're listed. The Debian Usability Research seems to be missing: http://deb-usability.alioth.debian.org I think that's fairly new, eh? Might be a while before it shows up. (I don't know how anal the webmaster for that page is, but I know I'd give it a while to make sure it was a viable, active effort.) pgp6TA44JuDfw.pgp Description: PGP signature
Re: Unofficial projects related with Debian.
On Sat, May 24, 2003 at 10:28:19AM +0200, Raphael Hertzog wrote: The rules are quite simple: is there someone willing to write those pages ? I have this very same problem for DebianEdu, if I want a page on www.debian.org I have to prepare it but I have no time for that. I also don't have any contributor willing to do that so we have to leave with the initial Wiki... Which is exactly my problem: I'm quite busy already designing and writing debtags and related tools, and I can't dedicate much time and resources in promoting debtags and the other usability stuff I care to bring on. Which is especially bad because: 1) If I don't produce useful software, I miss my goal of increasing the quality of Debian 2) If I fail to promote my software (in the free software sense: create interest around it and his code), I risk being the only one in charge of caring for it 3) The more things I am the only one in charge of caring for, the less new things I can do. Which is a pity, because I have a lot of ideas for new things, and because doing new things from time to time definitely contributes to the fun. Free software in a way introduces the problem of creating sustainable software projects, which is in part obtained with the quality and usefulness of the sotware itself, and in part with the charisma and the ability of the maintainers to attract interest. Which means that a good project can fail not because the software is bad, but because the maintainer has no time, capacitiy or resources to promote it. It's been some time I'm having these thoughts, I'm happy I've finally found an occasion to share them. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini [EMAIL PROTECTED]
Re: Bug#194155: ITP: ehnt -- Extreme Happy Netflow Tool - Obtains useful information out of netflow data
On Wed, 21 May 2003 21:40:04 +1000, Craig small [EMAIL PROTECTED] wrote: The flow reports come out in text and show flow summaries (such as top n ASes, protocols, etc per m minutes). NetFlow is a packet protocol that is used by routers such as Cisco and Juniper. Is there any tool that enables a Linux router to generate netflow data, coexisting with Cisco and Juniper generated data? 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: Debian MIA check
* Petter Reinholdtsen | [James Troup] | Tor Slettnes [EMAIL PROTECTED] | | I forwarded this email to his other address, which I came across in a | mail from a common friend of our. I've recently mailed with him, and for the time being, he is out of time for doing Debian work. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Maintaining kernel source in sarge
Guido Guenther [EMAIL PROTECTED] wrote:
It's very hard to get these bug fixes anyway since when I do a
_complete_ diff between kernel-source-2.X.Y in the archive and the
kernel source for architecture foo I'll _always_ (accidentally)
pull out all the bug fixes you made. Only diffing specific parts of the
OK, barring any major objections, that's how it will be for 2.4.21.
I will make kernel-source-2.4.21 be identical to the upstream tar ball
except for the non-free bits. A kernel-patch-i386 package will be
introduced.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Very uneven distribution of packages per maintainer
[Tollef Fog Heen] So, why do you think having a more even distribution is a good thing? Because in Debian there is a few people with high load in debian, and many with less load. People with high load are more likely to burn out and disappear. It is thus better to have more people with less load. Of course, the packages per developer is not a perfect indicator of load, but it is an indicator.
Re: Very uneven distribution of packages per maintainer
On Fri, May 23, 2003 at 09:48:02PM -0500, Adam Heath wrote: On Sat, 24 May 2003, Wouter Verhelst wrote: The script can't even get everything a Debian Developer does for Debian. While most, if not all, active Debian Developers do packaging work, there's other stuff to be done -- such as taking care of autobuilders, being a sysadmin, ftp-master, listadmin, or release manager, doing porters' work. So doing bts work is worthless? :) Mind the 'such as'. These are examples; I'm sure I forgot hundreds of other people doing valuable non-packaging work. Should've been more explicit, perhaps. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts. -- National Geographic Channel, in a documentary about large African beasts. pgpRT7sgYPuQb.pgp Description: PGP signature
Re: Very uneven distribution of packages per maintainer
On Sat, 24 May 2003 22:15, Petter Reinholdtsen wrote: Because in Debian there is a few people with high load in debian, and many with less load. People with high load are more likely to burn out and disappear. It is thus better to have more people with less load. Of course, the packages per developer is not a perfect indicator of load, but it is an indicator. Sometimes you can have an easy source package that produces several other packages. Sometimes you can have a difficult source package that only produces one package. Then there's the issue of upstream maintainers who are also Debian developers, being the active upstream developer can be enough work that developing any other Debian packages would take too much time. Even if you had a metric for measuring the amount of work a developer was doing, that wouldn't gain you anything. We can't force people who have a small number of packages to take on more work, and we don't want to discourage them from contributing altogether. -- 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: Very uneven distribution of packages per maintainer
On Sat, May 24, 2003 at 11:25:03PM +1000, Russell Coker wrote: On Sat, 24 May 2003 22:15, Petter Reinholdtsen wrote: Because in Debian there is a few people with high load in debian, and many with less load. People with high load are more likely to burn out and disappear. It is thus better to have more people with less load. Of course, the packages per developer is not a perfect indicator of load, but it is an indicator. Sometimes you can have an easy source package that produces several other packages. Sometimes you can have a difficult source package that only produces one package. Then there's the issue of upstream maintainers who are also Debian developers, being the active upstream developer can be enough work that developing any other Debian packages would take too much time. Even if you had a metric for measuring the amount of work a developer was doing, that wouldn't gain you anything. We can't force people who have a small number of packages to take on more work, and we don't want to discourage them from contributing altogether. Not to mention those that are paid to work on Debian (Hello HP :) and those who have full time jobs that are irrelevant to anything they do for Debian. Then we could get into single/married, kids, hobbies, etc. Even that is little indicator. I know folks who's job has nothing to do with Debian, but they do more work than people who are paid to work on Debian. It's all about motivation, and no person is doing anything wrong. It's a personal choice how much time and energy you devote to Debian. As long as that number isn't zero, then you are welcome to stay. -- Debian - http://www.debian.org/ Linux 1394 - http://www.linux1394.org/ Subversion - http://subversion.tigris.org/ Deqo - http://www.deqo.com/
Re: Very uneven distribution of packages per maintainer
Petter Reinholdtsen wrote: Because in Debian there is a few people with high load in debian, and many with less load. People with high load are more likely to burn out and disappear. Do you have statistics to support that statement? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Debian conference in the US?
Please take all of these political screeds off -devel!! Regards. Bob -- _ |_) _ |_Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) 1294 S.W. Seagull Way [EMAIL PROTECTED] Palm City, FL 34990 USA GPG Key ID: 390D6559
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 09:24:16PM +1000, Herbert Xu wrote: OK, barring any major objections, that's how it will be for 2.4.21. I will make kernel-source-2.4.21 be identical to the upstream tar ball except for the non-free bits. A kernel-patch-i386 package will be introduced. You won't here me objecting ;) Thanks a lot, -- Guido
Re: Accepted directory-administrator 1.3.5-1 (i386 source)
On Wed, May 21, 2003 at 11:47:52PM +0200, Bernd Eckenfels wrote: On Wed, May 21, 2003 at 12:31:14PM -0700, Brian Nelson wrote: * New Upstream Version (closes: #176227, #188308, #90276) Changelog abuse. This is only a valid entry if all 3 of these bugs were requests for a new version, which they were not. to me it reads: fixed by the new version. which is perfectly valid. To me it does not. I close bugs with New Upstream Version when the bugs were requesting a new version because upstream released a new one. They should read, at least: * The new version closes: ... to make the difference. mooch -- Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 -- Registered Linux user #66350 proudly using Debian Sid Linux 2.4.20 If a man cannot choose, he ceases to be a man. --Minister (A clockwork orange)
Re: Unofficial projects related with Debian.
On Fri, May 23, 2003 at 01:58:31PM -0300, Ben Armstrong wrote: Why Debian Desktop subproject is on official website and many others[1] aren't? You're on crack. http://www.debian.org/devel/debian-desktop/ It's hard to discern useful information when you start out by showing you haven't done the slightest hint of pre-investigation... Reread that. He said Debian Desktop *is* on the official website but others aren't. Ow, the word order completely threw off my vgrep. Apologies -- the crack pipe here is mine. ;( -- 2. That which causes joy or happiness.
Re: Accepted directory-administrator 1.3.5-1 (i386 source)
Hi, Jesus Climent wrote: On Wed, May 21, 2003 at 11:47:52PM +0200, Bernd Eckenfels wrote: On Wed, May 21, 2003 at 12:31:14PM -0700, Brian Nelson wrote: * New Upstream Version (closes: #176227, #188308, #90276) Changelog abuse. This is only a valid entry if all 3 of these bugs were requests for a new version, which they were not. to me it reads: fixed by the new version. which is perfectly valid. To me it does not. I close bugs with New Upstream Version when the bugs were requesting a new version because upstream released a new one. They should read, at least: * The new version closes: ... That's shit too. * New Upstream version - explanation of the bug or fix (closes: #nr) ... ... would be the best solution. Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 pgplV2Uu2H7nx.pgp Description: PGP signature
Bug#194546: ITP: libemail-simple-perl -- Email handling. Simply.
Package: wnpp Version: N/A; reported 2003-05-24 Severity: wishlist * Package name: libemail-simple-perl Version : 1.4 Upstream Author : Simon Cozens [EMAIL PROTECTED] * URL : http://search.cpan.org/CPAN/authors/id/R/RC/RCLAMP/Email-Simple-1.4.tar.gz * License : Same as Perl. Description : Email handling. Simply. -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux khms.westfalen.de 2.4.19+kai.58 #1 Sam Sep 7 14:16:44 CEST 2002 i686 Locale: LANG=de_DE, LC_CTYPE=de_DE
Bug#194547: ITP: libemail-filter-perl -- Library for creating easy email filters
Package: wnpp Version: N/A; reported 2003-05-24 Severity: wishlist * Package name: libemail-filter-perl Version : 1.0 Upstream Author : [EMAIL PROTECTED] * URL : http://search.cpan.org/CPAN/authors/id/S/SI/SIMON/Email-Filter-1.0.tar.gz * License : Same as Perl. Description : Library for creating easy email filters -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux khms.westfalen.de 2.4.19+kai.58 #1 Sam Sep 7 14:16:44 CEST 2002 i686 Locale: LANG=de_DE, LC_CTYPE=de_DE
Bug#194548: ITP: libemail-localdelivery-perl -- Deliver a piece of email - simply
Package: wnpp Version: N/A; reported 2003-05-24 Severity: wishlist * Package name: libemail-localdelivery-perl Version : 0.04 Upstream Author : [EMAIL PROTECTED] * URL : http://search.cpan.org/CPAN/authors/id/S/SI/SIMON/Email-LocalDelivery-0.04.tar.gz * License : Same as Perl. Description : Deliver a piece of email - simply -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux khms.westfalen.de 2.4.19+kai.58 #1 Sam Sep 7 14:16:44 CEST 2002 i686 Locale: LANG=de_DE, LC_CTYPE=de_DE
Bug#194550: ITP: libemail-mime-encodings-perl -- A unified interface to MIME encoding and decoding
Package: wnpp Version: N/A; reported 2003-05-24 Severity: wishlist * Package name: libemail-mime-encodings-perl Version : 1.0 Upstream Author : [EMAIL PROTECTED] * URL : http://search.cpan.org/CPAN/authors/id/S/SI/SIMON/Email-MIME-Encodings-1.0.tar.gz * License : Same as Perl. Description : A unified interface to MIME encoding and decoding -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux khms.westfalen.de 2.4.19+kai.58 #1 Sam Sep 7 14:16:44 CEST 2002 i686 Locale: LANG=de_DE, LC_CTYPE=de_DE
Re: Very uneven distribution of packages per maintainer
[EMAIL PROTECTED] (Petter Reinholdtsen) writes: [Tollef Fog Heen] So, why do you think having a more even distribution is a good thing? Because in Debian there is a few people with high load in debian, and many with less load. I think this is the wrong way to see it. Since work for Debian is based on a voluntary basis developers who have mor packages to process can allow themselves to invest more time and effort into such an undertaking than others. I'd rather propose to think the other way round: People with a higher load are more likely to work on less packages and people with a lesser load have more time/energy/money left to work on more packages. Of course, the packages per developer is not a perfect indicator of load, but it is an indicator. Indicating that their maintainers can afford investing more of his/her time, effort, money, etc. than other people? Yes, definitely!
Re: Bug#194515: ITP: debdivert -- Debian packaging aid to create patch packages
Andreas Metzler [EMAIL PROTECTED] writes: I still don't get why you wouldn't simply generate a modified version and install it _instead_ of the original package, unless foo also include a switch-debdivert-foo package that enables to choose to switch to officila package faster than 'dpkg -i official.deb' I can kind of see this. If your modified version has the same name as the original, you might end up accidentally upgrading to a version without the desired changes. On the other hand, if it has a different name, it cannot be a full substitute because dpkg still doesn't support versioned provides. -- 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: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 04:06:30PM +0200, Guido Guenther wrote: On Sat, May 24, 2003 at 09:24:16PM +1000, Herbert Xu wrote: OK, barring any major objections, that's how it will be for 2.4.21. I will make kernel-source-2.4.21 be identical to the upstream tar ball except for the non-free bits. A kernel-patch-i386 package will be introduced. You won't here me objecting ;) Thanks a lot, I'll object! Guido, you're not going about it the right way. It's a three-way merge. You take a kernel.org tree, diff it against the architecture tree that you're interested in, and then wiggle it into applying to the kernel source package that comes with Debian. It's not all that hard, and there's a number of tools to help you (dirdiff, for instance; but all I ever use is diff, patch, a text editor, and CVS/BK). For the PowerPC kernels this is how I've been doing it (sporadically) for years. It's never been hard; nowadays the diffs are only on the order of 70K, but they used to be multi-megabyte and I still rarely had conflicts with Herbert's patches. If you do have problems, do the merge the other way: kernel.org tarball diffed against Herbert's packages, wiggle those diffs on top of your architecture tree, diff the result against the kernel-source package, and call that your archictecture patch. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: ITP: pyblosxom -- simple weblog (blog) written in Python
On Saturday, May 24, 2003, at 03:28 AM, Colin Walters wrote: Pyblosxom is so-named because it was inspired by the blosxom package. Does pyblosxom offer any features which blosxom proper doesn't?
Re: Bug#189825: roxen: depend on newer pike 7.4 ?
Quoting Laurent Bonnaud [EMAIL PROTECTED]: Either upgrade to Roxen 2.1 OK. I upgraded to the latest roxen2 package in sid. Now I have another question: would it be possible to update roxen to depend on pike7.4 instead of pike7 ? Same answer. Roxen 2.1 won't work with pike 7.4... I'm working on packaging Roxen 3.3, but I don't know when I can upload it... -- Panama Mossad plutonium colonel FSF munitions Cocaine fissionable ammunition pits Marxist quiche Cuba KGB jihad [See http://www.aclu.org/echelonwatch/index.html for more about this]
Re: Debian conference in the US?
Russell Coker wrote: On Sat, 24 May 2003 09:51, Alan Shutko wrote: The citizens of the US have a little more power than the rest of the world, in that you have a *vote* as to who gets to fuck the rest of the world. Well, didn't work that way last time... They got their second choice. I never chose Little Napolean and he wasn't on my alternate list either. Please stop assuming everyone in a given country actually agrees with what their government has done or is doing. This is the most distressing aspect of this thread: Debian is (supposed to be) a group of intelligent, like-minded individuals whose individual nationality or origin is largely irrelevent. There should be only 2 requirements for a conference: someone is willing to sponsor it, and enough people are willing to come to make it worthwhile. This idea that conference locations need to be vetted based on the politics of the host country is dangerous and stupid. What Debian is about has nothing to do with individual nations or their politics. We should be better than this.
debconfig: package description
Hello, from time to time, especially while upgrading a lot of packages I notice debconfig questions for packages I do not know. This is of course quite likely given the size of debian archive and the fact, that task packages introduce a lot of packages one has not selected explecitely. Some of those packages ask questions, which are hard to understand, if you do not know what the package is all about. Of course, one can argue, that this is a problem with the phrasing of the question an should be fixed by a bug report, but I truely think that for example explaining, what the package is all about should not be repeated in every debconfig question. Therefore I wonder if the various debconfig frontends cant support something like displaying the package description. For the slang frontend for example I would think that a footer with foo: dealing with bar f3 for more would do the trick. Where f3 opens a pop-up with the package description and dependencies. What do you think? Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote: Guido, you're not going about it the right way. It's a three-way merge. You take a kernel.org tree, diff it against the architecture tree that you're interested in, and then wiggle it into applying to the kernel source package that comes with Debian. It's not all that hard, and there's a number of tools to help you (dirdiff, for instance; but all I ever use is diff, patch, a text editor, and CVS/BK). Why can't Debian have just one tree for multiple architectures like SuSE and RedHat (sometimes) do. Okay suse supports 'only' i386, x86_64,ppc,ppc64,s390,s390x,ia64 but their kernel also has patches for sparc,sparc64,mips and m68k although I can't guarantee that these really work in the relased tree (but last time I visted their office people were playing with those ports in their spare time). Sure, it's more work but I think it's worth it. And imagine how many people would scream if debian had $BIGNUM XFree86 or glibc packages..
Re: Very uneven distribution of packages per maintainer
On Sat, 24 May 2003, Wouter Verhelst wrote: On Fri, May 23, 2003 at 09:48:02PM -0500, Adam Heath wrote: On Sat, 24 May 2003, Wouter Verhelst wrote: The script can't even get everything a Debian Developer does for Debian. While most, if not all, active Debian Developers do packaging work, there's other stuff to be done -- such as taking care of autobuilders, being a sysadmin, ftp-master, listadmin, or release manager, doing porters' work. So doing bts work is worthless? :) Mind the 'such as'. These are examples; I'm sure I forgot hundreds of other people doing valuable non-packaging work. Should've been more explicit, perhaps. That was as joke.
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 09:24:16PM +1000, Herbert Xu wrote: Guido Guenther [EMAIL PROTECTED] wrote: It's very hard to get these bug fixes anyway since when I do a _complete_ diff between kernel-source-2.X.Y in the archive and the kernel source for architecture foo I'll _always_ (accidentally) pull out all the bug fixes you made. Only diffing specific parts of the OK, barring any major objections, that's how it will be for 2.4.21. I will make kernel-source-2.4.21 be identical to the upstream tar ball except for the non-free bits. A kernel-patch-i386 package will be introduced. So this means that maintainers of the architecture patches must be sure to merge in these fixes, otherwise they may inherit security vulnerabilities (for example)? How can we track when this has happened when there are so many different patches? -- - mdz
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 07:03:22PM +0200, Christoph Hellwig wrote: On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote: Guido, you're not going about it the right way. It's a three-way merge. You take a kernel.org tree, diff it against the architecture tree that you're interested in, and then wiggle it into applying to the kernel source package that comes with Debian. It's not all that hard, and there's a number of tools to help you (dirdiff, for instance; but all I ever use is diff, patch, a text editor, and CVS/BK). Why can't Debian have just one tree for multiple architectures like SuSE and RedHat (sometimes) do. Okay suse supports 'only' i386, x86_64,ppc,ppc64,s390,s390x,ia64 but their kernel also has patches for sparc,sparc64,mips and m68k although I can't guarantee that these really work in the relased tree (but last time I visted their office people were playing with those ports in their spare time). Sure, it's more work but I think it's worth it. Because no one's done it? We can't count on it because the architecture ports become available at different times; m68k still hasn't caught up IIRC. It would be nice, though. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote: Guido, you're not going about it the right way. It's a three-way merge. You take a kernel.org tree, diff it against the architecture tree that you're interested in, and then wiggle it into applying to the kernel source package that comes with Debian. It's not all that hard, and there's a number of tools to help you (dirdiff, for instance; but all I ever use is diff, patch, a text editor, and CVS/BK). This is how I thought it worked already, but I don't have the experience in maintaining the various arch-specific patches to speak first-hand about it. The only thing that would seem to complicate this is that the Debian patches to kernel source are implicit (kernel-source .diff.gz) rather than explicit (kernel-patch-debian). Given an explicit kernel-patch-debian, containing architecture-agnostic differences between kernel.org source and Debian's kernel source, arch-specific merges could be mostly automated, and security fixes could be made in one place. -- - mdz
Re: Bug#194515: ITP: debdivert -- Debian packaging aid to create patch packages
On Sat, May 24, 2003 at 05:37:31PM +0900, Masato Taruishi wrote: Masato Taruishi [EMAIL PROTECTED] wrote: Ah, the main point of this package is to create a local ad-hoc package which can coexist with its official package. Escpecially, I can manage my temporary on-going improvement to some debian package as a debian package. I didn't think to waste official debian packages because we shouldn't upload this kind of patch packages to the official but merge the patch to the official packages if we want to share them on public. The main question is what on god's green earth does this do that dpkg-divert doesn't do? Looking at the package description, it implies that it will in fact do a lot less than dpkg-divert unless you tell it otherwise. This creates a fragment to use dpkg-divert. It checks all md5sums of each package and lists files which we need to invoke 'dpkg-divert'. This seems like it would make more sense as a debhelper component than as an independent program. -- - mdz
Re: Debian conference in the US?
On Sun, 25 May 2003 02:24, Ed Cogburn wrote: Well, didn't work that way last time... They got their second choice. I never chose Little Napolean and he wasn't on my alternate list either. Something between 49% and 50% of US voters wanted the Shrub as president. Please stop assuming everyone in a given country actually agrees with what their government has done or is doing. This is the most I don't assume that everyone agrees, just the 49.X% that voted for him. distressing aspect of this thread: Debian is (supposed to be) a group of intelligent, like-minded individuals whose individual nationality or origin is largely irrelevent. There should be only 2 requirements for a conference: someone is willing to sponsor it, and enough people are willing to come to make it worthwhile. Which is what I have said, repeatedly. This idea that conference locations need to be vetted based on the politics of the host country is dangerous and stupid. What Debian is about has nothing to do with individual nations or their politics. We should be better than this. Be glad that I never suggested that the conference be held outside the US for this reason. Someone asked why people would want to decline an opportunity to visit the US. I answered the question. A bunch of USians started jumping up and down and the thread has continued ever since. The most amusing thing was that no USian even bothered to ask me whether I am implementing such a boycot myself, they just made their assumptions and jumped into the flame-war. My purchases of US products have not changed of recent times, they only things from the US that I want are made by Intel, AMD, IBM, and Ford. Three of those companies have no viable non-US competition. For avoiding entering the US there are better reasons such as the following: http://www.informationclearinghouse.info/article1689.htm -- 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: Unofficial projects related with Debian.
Em Sat, 24 May 2003 06:11:18 -0400, David B Harris [EMAIL PROTECTED] escreveu: On Sat, 24 May 2003 10:19:38 +0200 Enrico Zini [EMAIL PROTECTED] wrote: http://www.debian.org/devel/, Projects section: * Debian Web Pages [...] * Alioth: Debian GForge Certainly seems that they're listed. The Debian Usability Research seems to be missing: http://deb-usability.alioth.debian.org I think that's fairly new, eh? Might be a while before it shows up. (I don't know how anal the webmaster for that page is, but I know I'd give it a while to make sure it was a viable, active effort.) I'd instead show it around to help it being a viable, active effort =) []s! -- [EMAIL PROTECTED]: Gustavo Noronha http://people.debian.org/~kov Debian: http://www.debian.org * http://www.debian-br.org Dúvidas sobre o Debian? Visite o Rau-Tu: http://rautu.cipsga.org.br
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 01:25:38PM -0400, Daniel Jacobowitz wrote: Sure, it's more work but I think it's worth it. Because no one's done it? Hey, if that was an argument. The question is whether people want it.. We can't count on it because the architecture ports become available at different times; m68k still hasn't caught up IIRC. It would be nice, though. Some m68k architectures might be a hard, I agree. But having a package that works on as many machines as possible would be very cool. Note that although I'm not a DD (and don't have plans to become one), I'd be happy to invest time to help out wherever needed for such a kernel-unified package.
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 07:55:08PM +0200, Christoph Hellwig wrote: Some m68k architectures might be a hard, I agree. But having a package that works on as many machines as possible would be very cool. well, I there is a shared debian-kernel cvs then all architecture maintainers can commit, and the package can be build for those who are ready. This might generate a autobuilder and testing-transition problem :( Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: ITP: pyblosxom -- simple weblog (blog) written in Python
On Sat, 2003-05-24 at 11:52, Joe Drew wrote: On Saturday, May 24, 2003, at 03:28 AM, Colin Walters wrote: Pyblosxom is so-named because it was inspired by the blosxom package. Does pyblosxom offer any features which blosxom proper doesn't? Plugins, sane code, xmlrpc support, different rendering systems, etc. See: http://roughingit.subtlehints.net/pyblosxom/
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 07:51:17PM +0200, Karsten Merker wrote: Because it simply did not work out - not all architectures are in sync with Linus' tree Oh, I know that well enough. and if I understood our port maintainer correctly, there are some architecture-specific things Linus does not accept for his tree some architectures have code that can't go into a stable branch anymore, yes. ia64 is the only major example I know. or that are incompatible between other architectures. Umm, no. Sometimes you get conflicts when applying the plain architecture patches, bat that's not due to incompatible requirements but because they touch the same area. I doubt that a standard Suse kernel tree produces a working kernel on mips, mipsel or m68k; can't say for the other architectures, though. Even Marcelo's tree seems to get a working m68k kernel nowdays - although just the less stranger m68k variants. Well, the mips tree is total mess, you'd have to ask the guys playing with it at suse (Andreas Jaeger IIRC). OTOH to the diff to a 2.4.20 XFS tree (i.e. almost like Marcelo's tree) to get it working on my indy was rather small.
Re: Maintaining kernel source in sarge
On Fri, May 23, 2003 at 09:20:28PM +1000, Herbert Xu wrote: So unless someone can come up with a solution to this problem, we will have to live with multiple Debian source packages for now. This does make security fixes more difficult than it would be otherwise, however, I do not think it is unsurmountable given enough cooperation from the people involved. I think that we can live with multiple source packages given a little bit of infrastructure which more closely follows the way that kernel development happens. We need to be able to introduce specific patches to all of our kernels while minimizing the possibility of errors. Errors include breaking kernel builds, breaking module packages, missing some kernel packages and patches, etc. We also need to consider users who need to build their own kernels. Here is my rough idea as to how it can work: 1. The architectures should be treated as independent packages. By 'independent packages', do you mean that we should have separate kernel-source source packages for each architecture? This would seem to be a step backward. We should not be shy of releasing DSAs for some architectures before others. Since we cannot assume that all architectures are at the same version, some will inevitably take longer to fix due to the back-porting involved. This is already the case. However, look at the mess which results: s390 and mips have integrated one of the ptrace patches into their respective kernel-patch packages (DSA-276 and DSA-270). Now, how are we going to fix i386? If we integrate the patch into kernel-source-2.4.17 or kernel-source-2.4.19, then s390 and mips are now broken because they will conflict. 2. We should be more liberal about adding new kernels to the stable archive and getting rid of old ones. The main advantage to this is in fact security. It is routine for small security fixes to enter a stable kernel unannounced. For instance, between 2.4.18 and 2.4.19, dozens of unannounced small security which only affect specific drivers were fixed. It also minimises any back-porting that has to be done when a security alert is raised. I believe that we should not do anything to encourage this kind of irresponsible behaviour. If an upstream is not willing to share information about security fixes with us, we should not reward them by doing extra integration work to try to push a new upstream release into stable. What benefit is there in not announcing these problems? Security through obscurity? How can we inform our users of their exposure when we are not informed ourselves about security problems? The disadvantage is of course the potential to break existing systems. However, I believe this can be minimised through careful management and thorough testing. It is also mitigated by the fact that we allow multiple kernels to be installed simultaneously so it is easy to roll back. In fact, due to the use of modules, it is often impossible to make security fixes which are module ABI compatible with previous kernels. For example, the last two security holes (ptrace and net hash) both changed the modules ABI. It is infortunate if this must sometimes happen, but hopefully it is an exception, and in those cases we will need to rebuild modules and provide for both kernel images to be installed at once. I don't see why the ptrace fix necessitated a change in the module ABI however, only that it was implemented that way upstream. Let me make it a bit more concrete as to what we can do about woody right now. Yes, on that note: could you send any separate patches that you have for these issues to [EMAIL PROTECTED] - CAN-2003-0001: etherleak - CAN-2003-0127: ptrace - CAN-2003-0244: ip route cache hash - CAN-2003-0246: ioperm issue - CAN-2002-1380: mmap() on /proc/pid/mem - CVE-2002-0429: lcall7 DoS Problem: Too many kernel-source packages. This is caused in part by gratuitous kernel-patch dependencies. Kernel-patch packages should *never* depend on a kernel-source package since the user can always use a kernel tar ball. Here is a quick list for unstable: mizar:[...deb/notmine/security/kernel] apt-cache dumpavail | grep-dctrl -nsPackage -FDepends kernel-source- kernel-patch-2.2.20-powerpc kernel-patch-2.4.19-powerpc kernel-patch-2.4.20-hppa kernel-patch-2.4.20-ia64 kernel-patch-2.4.20-powerpc Shall I file bugs for these so that they can be fixed for sarge? Solution: Remove offending kernel-patch packages and kernel-source packages. Users of those kernel-source packages should be encouraged to upgrade to a later version. I'd recommend that we keep 2.4.18 and inject 2.4.19/2.4.20 as soon as possible. All architectures have kernel images in either stable or proposed-updates that is at least 2.4.18 or higher. Removing kernel-patch package from stable does not help users who are running kernels built from them, and this is not the least of the problems, either. Linux 2.4 does not exactly have a
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote: Guido, you're not going about it the right way. It's a three-way merge. You take a kernel.org tree, diff it against the architecture tree that you're interested in, and then wiggle it into applying to the kernel source package that comes with Debian. It's not all that hard, and there's a number of tools to help you (dirdiff, for instance; but all I ever use is diff, patch, a text editor, and CVS/BK). That helps with the merges but doesn't give me a source tree that is as close to the linux-mips.org tree as possible. If we have a vanilla upstream source I can still add Herbert's patches on top of that later if I desire. -- Guido
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 08:18:40PM +0200, Bernd Eckenfels wrote: On Sat, May 24, 2003 at 07:55:08PM +0200, Christoph Hellwig wrote: Some m68k architectures might be a hard, I agree. But having a package that works on as many machines as possible would be very cool. well, I there is a shared debian-kernel cvs then all architecture maintainers can commit, and the package can be build for those who are ready. This might generate a autobuilder and testing-transition problem :( Yes, same as for gcc,glibc,xfree86. The real question is 'should the kernel be different' and if yes why?
Re: Maintaining kernel source in sarge
On Sun, 25 May 2003 04:18, Bernd Eckenfels wrote: On Sat, May 24, 2003 at 07:55:08PM +0200, Christoph Hellwig wrote: Some m68k architectures might be a hard, I agree. But having a package that works on as many machines as possible would be very cool. well, I there is a shared debian-kernel cvs then all architecture maintainers can commit, and the package can be build for those who are ready. This might generate a autobuilder and testing-transition problem :( The problem here is when architecture specific patches require patches to core code. If we have a single kernel source tree that everyone commits to then it will be changing daily, it will be difficult to determine what source was used to compile a particular kernel (and getting two kernels compiled from the same source will be a neat trick). I think that the thing to do is to have a base kernel source package that is the standard Linus tree plus fixes that are really important. That means security fixes, fixes to file systems to fix data-loss issues, etc. The VM fix for 2.4.20 which stops machines with 4G of RAM from choking under load would be a border-line case. Then patches that strictly affect one architecture will be separate, patches that are only really needed for one architecture (EG JFFS2 patches may be required for embedded devices but for most machines - including all Alpha's there would be no need for it) would be kept separate. Also for the architecture-specific patches we should avoid the temptation to merge in other patches. When people merge in patches for things such as XFS into more generic kernel patches (as SuSe appears to do) it makes things very painful for anyone who wants to extract things and use a sub-set of the patches. -- 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: Debian conference in the US?
Russell Coker [EMAIL PROTECTED] writes: I don't assume that everyone agrees, just the 49.X% that voted for him. This figure is not as meaningful as it might seem; we still use a non-preferential voting system, in which votes for non-mainstream candidates are effectively wasted. :-/ The most amusing thing was that no USian even bothered to ask me whether I am implementing such a boycot myself, they just made their assumptions and jumped into the flame-war. Toward the beginning of the thread, I specifically asked who would actually be unwilling to show up, as opposed to merely knowing other developers with that stance. -- 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: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 02:34:17PM -0400, Matt Zimmerman wrote: What benefit is there in not announcing these problems? Security through obscurity? How can we inform our users of their exposure when we are not informed ourselves about security problems? Noise. You can's accnounce every possibly security-related fix found by an audit - note that it's not clear whether it actually _is_ security-relevant at this point and certainly no one wrote an exploit for it. It is infortunate if this must sometimes happen, but hopefully it is an exception, and in those cases we will need to rebuild modules and provide for both kernel images to be installed at once. It's not an exception. Fixes can and will change the ABI all the time. You should not expect to be able to load a binary kernel module into _any_ other one than the one it was compiled against. Sometimes security fixes may even break the source API. (remember the dcache issues in 2.2.early?).
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 01:42:22PM -0400, Matt Zimmerman wrote: So this means that maintainers of the architecture patches must be sure to merge in these fixes, otherwise they may inherit security vulnerabilities (for example)? How can we track when this has happened when there are so many different patches? The situation won't change much over the current one. You currently can't be sure that an arch doesn't back out security fixes in our kernel-source with it's kernel-patch diff (intentionally or not). Herbert did a great job of keeping the kernel-patch maintainers up to date about pending security issues. I certainly hope that splitting out i386 will not change that. Having a separate kernel-patch-i386 will make it even easier to pull these changes into the different architectures. -- Guido
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 11:37:09AM -0400, Daniel Jacobowitz wrote: Guido, you're not going about it the right way. It's a three-way merge. You take a kernel.org tree, diff it against the architecture tree that you're interested in, and then wiggle it into applying to the kernel source package that comes with Debian. It's not all that hard, and there's a number of tools to help you (dirdiff, for instance; but all I ever use is diff, patch, a text editor, and CVS/BK). These diff some random CVS tree vs kernel-source approach also has other problems. At least kernel-patch-2.4.20-m68k reintroduces the oh so unfree firmware the kernel-source package removes..
Re: Maintaining kernel source in sarge
On Sun, May 25, 2003 at 04:29:13AM +1000, Russell Coker wrote: On Sun, 25 May 2003 04:18, Bernd Eckenfels wrote: On Sat, May 24, 2003 at 07:55:08PM +0200, Christoph Hellwig wrote: Some m68k architectures might be a hard, I agree. But having a package that works on as many machines as possible would be very cool. well, I there is a shared debian-kernel cvs then all architecture maintainers can commit, and the package can be build for those who are ready. This might generate a autobuilder and testing-transition problem :( The problem here is when architecture specific patches require patches to core code. If we have a single kernel source tree that everyone commits to then it will be changing daily, it will be difficult to determine what source was used to compile a particular kernel (and getting two kernels compiled from the same source will be a neat trick). I think that the thing to do is to have a base kernel source package that is the standard Linus tree plus fixes that are really important. That means security fixes, fixes to file systems to fix data-loss issues, etc. The VM fix for 2.4.20 which stops machines with 4G of RAM from choking under load would be a border-line case. Why not have a standard linus tree + a set of security fix patches + a per arch arch specific patch. This would have the advantage of easily isolating the security patches from the other stuff, and make work easier for people of the different arches to check if they would cause problems or not on their arch. Ideally, the security patches could even be isolated for each problem they solve, a bit like the patches to the xfree86 package Branden has been using all this time. Friendly, Sven Luther
Re: Constitutional amendment: Condorcet/Clone Proof SSD votetallying
Manoj said: Oh, as a sponsor of the GR, I suppose I should clarify that I am not going to accept this amendment; I consider it a bad one. This makes our vote method fail the monoticity criteria (http://www.electionmethods.org/evaluation.htm). See Scenario 2 below. I'll present two (perhaps contrived, but failing to make quorum is not a very usual scenario in any case). Scenario A: Suppose the tech ctte has 10 members, and is trying to vote on the rainbow vote. The quorum is 4. (If you recall, the rainbow vote had 10 options). All 10 members vote -- and they all like like different colors, except that two people like red. Most are indifferent about the colors they did not chose, but they do not feel they should win -- and express their preferences by either only voting for the color of their choice. In my version, since no option got the needed 4 votes, there is no winner. In this amendment, red wins -- even though only 2 of the 10 people voted for it (less than the quorum of 4). Red won, even though 8 out of 10 people did not want to see it as winner. This is inaccurate. With this amendment, no options are excluded by quorum. However, the default option actually *beats* red here. (2 people prefer red to the default, while 8 people prefer to the default to red.) The default option in fact is the Condorcet winner and will win. --Nathanael
Re: Maintaining kernel source in sarge
Matt Zimmerman [EMAIL PROTECTED] wrote:
Given an explicit kernel-patch-debian, containing architecture-agnostic
differences between kernel.org source and Debian's kernel source,
arch-specific merges could be mostly automated, and security fixes could be
made in one place.
How does this automate the arch-specific merges where conflicts arise?
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: stunnel
Hello, I created a new package for stunnel 4, it is available at : http://people.debian.org/~speedblue/stunnel/ I will wait a little before take over the package. Best Regards. -- Julien LEMOINE / SpeedBlue pgpNIXSuf9fJZ.pgp Description: PGP signature
Re: Maintaining kernel source in sarge
Matt Zimmerman [EMAIL PROTECTED] wrote: I think that we can live with multiple source packages given a little bit of infrastructure which more closely follows the way that kernel development happens. We need to be able to introduce specific patches to all of our kernels while minimizing the possibility of errors. Errors include breaking kernel builds, breaking module packages, missing some kernel packages and patches, etc. We also need to consider users who need to build their own kernels. Agreed. Here is my rough idea as to how it can work: 1. The architectures should be treated as independent packages. By 'independent packages', do you mean that we should have separate kernel-source source packages for each architecture? This would seem to be a step backward. No, they are independent packages already in that each architecture is built from a different Debian source package. I'm just saying that the Security Team should treat it as different packages for the purposes of release DSAs. This is already the case. However, look at the mess which results: s390 and mips have integrated one of the ptrace patches into their respective kernel-patch packages (DSA-276 and DSA-270). Now, how are we going to fix i386? If we integrate the patch into kernel-source-2.4.17 or kernel-source-2.4.19, then s390 and mips are now broken because they will conflict. This is a mistake that we can avoid in future. The release of a kernel-source or a general kernel-patch package with the security fix should precede all architecture uploads. The main advantage to this is in fact security. It is routine for small security fixes to enter a stable kernel unannounced. For instance, between 2.4.18 and 2.4.19, dozens of unannounced small security which only affect specific drivers were fixed. It also minimises any back-porting that has to be done when a security alert is raised. I believe that we should not do anything to encourage this kind of irresponsible behaviour. If an upstream is not willing to share information about security fixes with us, we should not reward them by doing extra integration work to try to push a new upstream release into stable. Well it's not a question of irresponsibility. It's simply impossible to for either the upstream or us to vet every single patch that passes through the system and decide whether it has security implications and raise an alert as a result. In fact, due to the use of modules, it is often impossible to make security fixes which are module ABI compatible with previous kernels. For example, the last two security holes (ptrace and net hash) both changed the modules ABI. It is infortunate if this must sometimes happen, but hopefully it is an exception, and in those cases we will need to rebuild modules and provide for both kernel images to be installed at once. It's going to be more common than you think due to the way the Linux module ABI works. A small change in any structure that is either directly or indirectly referred to by a commonly used one will result in a change. I don't see why the ptrace fix necessitated a change in the module ABI however, only that it was implemented that way upstream. If you mean that it could have been fixed without changing the bitfields in task_struct then perhaps so assuming that we care about it enough to do it in such a way. Otherwise I don't see your point. Let me make it a bit more concrete as to what we can do about woody right now. Yes, on that note: could you send any separate patches that you have for these issues to [EMAIL PROTECTED] - CAN-2003-0001: etherleak - CAN-2003-0127: ptrace - CAN-2003-0244: ip route cache hash - CAN-2003-0246: ioperm issue - CAN-2002-1380: mmap() on /proc/pid/mem - CVE-2002-0429: lcall7 DoS Will do. However I can't guarantee that the patches will apply to older versions of 2.4. Here is a quick list for unstable: mizar:[...deb/notmine/security/kernel] apt-cache dumpavail | grep-dctrl -nsPackage -FDepends kernel-source- kernel-patch-2.2.20-powerpc kernel-patch-2.4.19-powerpc kernel-patch-2.4.20-hppa kernel-patch-2.4.20-ia64 kernel-patch-2.4.20-powerpc Shall I file bugs for these so that they can be fixed for sarge? I don't really mind the arch-specific kernel-patch packages depending on them since they are and should always built against the Debian source. I was mostly referring to the other kernel-patch packages. In fact, I don't see a single generic kernel-patch package in unstable that depends on kernel-source. That's a great thing. Solution: Remove offending kernel-patch packages and kernel-source packages. Users of those kernel-source packages should be encouraged to upgrade to a later version. I'd recommend that we keep 2.4.18 and inject 2.4.19/2.4.20 as soon as possible. All architectures have kernel images in either stable or proposed-updates that is at least 2.4.18 or higher. Removing kernel-patch
Re: Maintaining kernel source in sarge
Christoph Hellwig [EMAIL PROTECTED] wrote:
Why can't Debian have just one tree for multiple architectures like
SuSE and RedHat (sometimes) do. Okay suse supports 'only' i386,
x86_64,ppc,ppc64,s390,s390x,ia64 but their kernel also has patches
for sparc,sparc64,mips and m68k although I can't guarantee that these
really work in the relased tree (but last time I visted their office
people were playing with those ports in their spare time).
I don't think we can go all the way yet, but let's make a start. If
the architecture maintainers send me patches which clearly don't affect
other archs or otherwise cause build problems, I will merge them.
I don't think we can guarantee a tree that builds on all or most
architectures, but we should be able to keep the difference to a
minimum.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 08:42:39PM +0200, Christoph Hellwig wrote: On Sat, May 24, 2003 at 02:34:17PM -0400, Matt Zimmerman wrote: What benefit is there in not announcing these problems? Security through obscurity? How can we inform our users of their exposure when we are not informed ourselves about security problems? Noise. You can's accnounce every possibly security-related fix found by an audit - note that it's not clear whether it actually _is_ security-relevant at this point and certainly no one wrote an exploit for it. You certainly can; other projects do. The presence of an exploit is irrelevant; we fix vulnerabilities all the time for which no exploit necessarily exists. It's not noise at all when it's something that we and others (desperately!) want to know about. It is infortunate if this must sometimes happen, but hopefully it is an exception, and in those cases we will need to rebuild modules and provide for both kernel images to be installed at once. It's not an exception. Fixes can and will change the ABI all the time. You should not expect to be able to load a binary kernel module into _any_ other one than the one it was compiled against. Sometimes security fixes may even break the source API. (remember the dcache issues in 2.2.early?). Compatibility is often broken for many other reasons as well; this does not mean that it is necessary for our purposes. -- - mdz
Re: Maintaining kernel source in sarge
On Sat, May 24, 2003 at 08:44:26PM +0200, Guido Guenther wrote: On Sat, May 24, 2003 at 01:42:22PM -0400, Matt Zimmerman wrote: So this means that maintainers of the architecture patches must be sure to merge in these fixes, otherwise they may inherit security vulnerabilities (for example)? How can we track when this has happened when there are so many different patches? The situation won't change much over the current one. You currently can't be sure that an arch doesn't back out security fixes in our kernel-source with it's kernel-patch diff (intentionally or not). In most cases, it's much easier for a maintainer to unintentionally leave something out (especially if they are unaware of it) than to revert it (unintentionally or not). -- - mdz
Re: Maintaining kernel source in sarge
On Sun, May 25, 2003 at 07:37:10AM +1000, Herbert Xu wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: Given an explicit kernel-patch-debian, containing architecture-agnostic differences between kernel.org source and Debian's kernel source, arch-specific merges could be mostly automated, and security fixes could be made in one place. How does this automate the arch-specific merges where conflicts arise? 1. unpack pristine kernel source 2. apply Debian patch 3. dry-run arch-specific patch 4. if no conflicts, test and release, otherwise: 5. apply arch-specific patch to pristine kernel source 6. 3-way merge between pristine kernel source, Debian tree, and arch-specific tree 7. resolve marked conflicts by hand Obviously conflicts must be resolved manually, hence the mostly above. This is relatively straightforward to do within a source package, given direct access to the (separate) pristine kernel source and Debian patch. -- - mdz
Re: Debian conference in the US?
* Aaron M. Ucko ([EMAIL PROTECTED]) [030519 04:26]: What are other developers' feelings on the matter these days? I would rather not come.
Re: Debian conference in the US?
On Sun, May 25, 2003, Andreas Schuldei wrote: What are other developers' feelings on the matter these days? I would rather not come. Neither would I. Given what happened to Sklyarov, I don't fancy going to the USA at all. And like many others, I won't object, I merely won't attend. Sam. -- Sam Hocevar [EMAIL PROTECTED] http://sam.zoy.org/
Re: Debian conference in the US?
On Sun, May 25, 2003 at 03:32:57AM +1000, Russell Coker wrote: For avoiding entering the US there are better reasons such as the following: http://www.informationclearinghouse.info/article1689.htm May 20, 2003. French reporters covering Electronic Entertainment Expo (E3) arrested, forcibly repatriated: http://www.theinquirer.net/?article=9609 http://www.rsf.org/article.php3?id_article=6909
Re: Maintaining kernel source in sarge
On Sun, May 25, 2003 at 07:58:09AM +1000, Herbert Xu wrote: Matt Zimmerman [EMAIL PROTECTED] wrote: By 'independent packages', do you mean that we should have separate kernel-source source packages for each architecture? This would seem to be a step backward. No, they are independent packages already in that each architecture is built from a different Debian source package. I'm just saying that the Security Team should treat it as different packages for the purposes of release DSAs. In general, this is not a problem. The exception is coordinated disclosure, where it is important that fixes be available for all architectures in order to minimize exposure. In those cases, it would be helpful to coordinate with all of the kernel package maintainers ahead of time. I believe that we should not do anything to encourage this kind of irresponsible behaviour. If an upstream is not willing to share information about security fixes with us, we should not reward them by doing extra integration work to try to push a new upstream release into stable. Well it's not a question of irresponsibility. It's simply impossible to for either the upstream or us to vet every single patch that passes through the system and decide whether it has security implications and raise an alert as a result. Of course, we cannot expect anyone to tell us things that they do not realize themselves. I thought you were referring to changes with known security impact. We cannot justifiably be too liberal with new releases in the hope of getting unknown bugfixes, as we are as likely to receive unknown bugs. It is infortunate if this must sometimes happen, but hopefully it is an exception, and in those cases we will need to rebuild modules and provide for both kernel images to be installed at once. It's going to be more common than you think due to the way the Linux module ABI works. A small change in any structure that is either directly or indirectly referred to by a commonly used one will result in a change. If so, then we must be prepared to rebuild kernel module packages, and this is a fact of life. Fortunately, we don't provide many of these. I don't see why the ptrace fix necessitated a change in the module ABI however, only that it was implemented that way upstream. If you mean that it could have been fixed without changing the bitfields in task_struct then perhaps so assuming that we care about it enough to do it in such a way. Otherwise I don't see your point. Are task_struct and mm_struct exposed to modules? It does not seem like they should need to be, but I am no expert in the kernel. If this is meant to be this way, then shouldn't the struct have some amount of padding to allow for changes like this without breaking compatibility? Yes, on that note: could you send any separate patches that you have for these issues to [EMAIL PROTECTED] - CAN-2003-0001: etherleak - CAN-2003-0127: ptrace - CAN-2003-0244: ip route cache hash - CAN-2003-0246: ioperm issue - CAN-2002-1380: mmap() on /proc/pid/mem - CVE-2002-0429: lcall7 DoS Will do. However I can't guarantee that the patches will apply to older versions of 2.4. That is no problem; at this point we need all of the information that we can get. It helps greatly to see how the fix was made. [arch-specific patch packages] Shall I file bugs for these so that they can be fixed for sarge? I don't really mind the arch-specific kernel-patch packages depending on them since they are and should always built against the Debian source. I was mostly referring to the other kernel-patch packages. Ah, I did not realize you did not mean to include these. Never mind, then. Pushing a new kernel release is essentially punting to the user, forcing them to decide between old bugs and new bugs. Firstly I'm not suggesting the uploading new versions in direct response to a security alert. I'm saying that we should be keeping up with new versions so that we can be better prepared for subsequent security alerts. That is, you are saying that we should try to run the most recent kernels so that we can patch them more easily? I'm wary of introducing churn in stable for problems which we don't yet know about. And please don't exaggerate about the possibility of breaking systems. New versions are only uploaded to proposed-updates after extensive testing by the maintainers, the users in unstable as well as the general Linux user base. If you have a particular breakage in the 2.4 line in mind, please bring it up so we can see how it could've be dealt with better. I did not mean to disregard the testing that you do, but kernel upgrades are problematic enough as it is, considering that the entire system must be brought down. One example which comes to mind immediately is the grossly incompatible TUN/TAP changes around kernel 2.4.5. The UML skas breakage from the ptrace fix is another, but I
Re: Maintaining kernel source in sarge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christoph Hellwig [EMAIL PROTECTED] wrote: Why can't Debian have just one tree for multiple architectures like SuSE and RedHat (sometimes) do. Okay suse supports 'only' i386, x86_64,ppc,ppc64,s390,s390x,ia64 but their kernel also has patches for sparc,sparc64,mips and m68k although I can't guarantee that these really work in the relased tree (but last time I visted their office people were playing with those ports in their spare time). SuSE don't have a single kernel source either. They have a set of a few hundred common patches plus some more patches (e.g. 200 for s390) that are used only for one architecture, usually both 32 and 64 bit. Single patches can be enabled or excluded per architecture there. On Sunday 25 May 2003 00:12, Herbert Xu wrote: I don't think we can go all the way yet, but let's make a start. If the architecture maintainers send me patches which clearly don't affect other archs or otherwise cause build problems, I will merge them. I don't think we can guarantee a tree that builds on all or most architectures, but we should be able to keep the difference to a minimum. IMHO the ability to easily override base patches is important, which would require not a patched kernel-source package but a kernel-patch-debian package containing all changes as single diffs. AFAICS, dh-kpatches allows creating versioned patches. As a real-world example, kernel-patch-s390 can provide the ptrace bug fix from Martin Schwidefsky, while kernel-patch-debian contains the generic solution from Alan Cox. When building kernel-image-s390, make-kpkg would first apply the arch specific patches and the the arch independent ones that have not been superceded by an arch specific one. The same scheme allows creating a kernel-patch-2.4.21-rc3 package for kernel-source-2.4.20 that simply overrides all fixes that have been backported from Marcellos tree to kernel-patch-debian. This is very helpful for architectures like amd64, where the official kernel tree only contains changes against the latest prepatch. Arnd -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+0AVt5t5GS2LDRf4RAhRjAJ9mzGRGp4uA5P4xBI7CBNFW/wb/kwCff6z8 uNPf7MfMLgNoXq8PQRG0IkI= =a4wk -END PGP SIGNATURE-
Re: ITP: firehol -- a powerful and easy to use firewall configuration system
Florian Thiel [EMAIL PROTECTED] wrote:
Package: wnpp
Version: N/A; reported 2003-01-13
Severity: wishlist
* Package name: firehol
There was no further activity on this ITP.
I've packaged FireHOL myself, found a sponsor and mailed Florian 3 weeks
ago [1]. If there is no answer in a week, i'll ask my sponsor to upload
the package [2] to the Debian archive.
Marc
Footnotes:
[1] The mail was sent at Sunday, 04 May 2003.
[2] http://marcbrockschmidt.de/debian/
--
$_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3*
)e$(htgnel+23(rhc,u(kcapnu ,nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y
V2ajFGabus} yV2ajFGa{gwmclBHIbus}gwmclBHI{yVGa09mbbus}yVGa09mb{hBCdzVnSbus';
s/\n//g;s/bus/\nbus/g;eval scalar reverse # mailto:[EMAIL PROTECTED]
Re: Maintaining kernel source in sarge
Matt Zimmerman [EMAIL PROTECTED] wrote:
On Sun, May 25, 2003 at 07:37:10AM +1000, Herbert Xu wrote:
How does this automate the arch-specific merges where conflicts arise?
1. unpack pristine kernel source
2. apply Debian patch
3. dry-run arch-specific patch
4. if no conflicts, test and release, otherwise:
5. apply arch-specific patch to pristine kernel source
6. 3-way merge between pristine kernel source, Debian tree, and
arch-specific tree
7. resolve marked conflicts by hand
Obviously conflicts must be resolved manually, hence the mostly above.
This is relatively straightforward to do within a source package, given
direct access to the (separate) pristine kernel source and Debian patch.
But the pristine kernel source and the Debian patch are already available
to the architecture maintainers:
apt-get --tar-only source kernel-source-2.4.xx
apt-get --diff-only source kernel-source-2.4.xx
So I don't think having a kernel-patch-debian by itself is of any value
to the merging process. It also doesn't solve the problem that a new
kernel-patch-debian may break the building of old kernel-image packages.
There is also the suggestion of a complete break down of all Debian
changes should be made available. Unfortunately that is simply
unmaintainable and unusable as the number of changes grows as the
dependencies between the patches are complex.
I think perhaps we could find a middle ground. We can keep kernel-source
as it is with all the patches applied. In addition to that, we can have a
kernel-patch-debian package which depends on the kernel-source of the same
upstream version containing patches that will take the kernel-source to
the following source trees:
1. The pristine upstream except for non-free removals.
2. All previous kernel-source revisions of that release. For example,
kernel-patch-debian-2.4.20 will contain patches that will give you the
kernel-source-2.4.20-[1-7] packages respectively. These patches will
be presented in incremental form with wrapper scripts around them that
will preserve compatibility with previous kernel-patch-debian packages
of the same version.
The per-architecture kernel images can then depend on kernel-patch-debian
and use the wrapper script that is most appropriate at that particular
time. If a new kernel-source/kernel-patch-debian pair of the same version
is released then nothing will be broken as there will be a patch with the
same name in kernel-patch-debian that takes you to exactly the same source
tree used to build previous kernel-image packages.
This approach has the following benefits:
* The kernel-source binary contains all bug fixes as is. Guido raised
a good point that if we separated the patches from the kernel-source, then
users may miss out on the bug fixes. This is especially important in light
of the current speed of upstream releases.
* The pristine kernel-source is available in the binary archive. Many people
have asked for this in the past and this makes it available in the form of
a source tar ball plus a patch.
* Per-arch kernel-image will no longer be made unbuildable by new
kernel-source updates. This has always been a problem for those
architectures using the main kernel-source archive.
* The incremental patches should ease the merging process of those
architectures that wish to incoporate Debian changes.
* The incremental patches should also allow people to get only the updated
kernel-patch packages if they wish.
I'd like to hear from the architecture maintainers if this proposal
poses any problems to them.
Cheers,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Maintaining kernel source in sarge
Matt Zimmerman [EMAIL PROTECTED] wrote:
In general, this is not a problem. The exception is coordinated disclosure,
where it is important that fixes be available for all architectures in order
to minimize exposure. In those cases, it would be helpful to coordinate
with all of the kernel package maintainers ahead of time.
Agreed.
Of course, we cannot expect anyone to tell us things that they do not
realize themselves. I thought you were referring to changes with known
security impact.
Well I do know at least some of those problems. But it'll require someone
with a fulltime job to sit down and list them all. Since IMHO it doesn't
make sense to just provide a partial fix to what is a wide-spread problem,
especially when you're just taking fixes from a new version which has
been available for a long time, I must say that it is not worth it.
We cannot justifiably be too liberal with new releases in the hope of
getting unknown bugfixes, as we are as likely to receive unknown bugs.
It's not just bug fixes. There are also new drivers or updates to
existing drivers that are required to make the system work on new systems.
Of course this also brings the possibility of breaking existing systems
when old drivers are updated. But that is hopefully what testing will
eliminiate or at least minimise.
We must remember that most of our concerns in this area is shared by
the upstream.
Are task_struct and mm_struct exposed to modules? It does not seem like
Yes.
Firstly I'm not suggesting the uploading new versions in direct response
to a security alert. I'm saying that we should be keeping up with new
versions so that we can be better prepared for subsequent security alerts.
That is, you are saying that we should try to run the most recent kernels so
that we can patch them more easily? I'm wary of introducing churn in stable
for problems which we don't yet know about.
Unfortunately it is my opinion that we have no choice given our current
release schedules.
One example which comes to mind immediately is the grossly incompatible
TUN/TAP changes around kernel 2.4.5. The UML skas breakage from the ptrace
fix is another, but I don't know if that was possible to avoid.
Well first 2.4.5 is fair game since any stable Linux release in single
digits should be treated as fluid.
The ptrace breakage is not the fault of the upstream since they did not
actually release a new version. In fact, the next release will contain
the fixed patch.
We also have to deal with the fact that miscellaneous changes between kernel
releases can and do break third-party patches (EVMS 1.2.x, device-mapper,
freeswan, etc.) that we ship and our users depend on to run their systes.
If the only fix we provide is an updated kernel, then users can no longer
use the patches that we supply.
I agree that we should try to maintain compatibility. But it should not
override the need to include new stable kernel releases from upstream.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#194515: ITP: debdivert -- Debian packaging aid to create patch packages
On Sat, May 24, 2003 at 05:37:31PM +0900, Masato Taruishi wrote: Masato Taruishi [EMAIL PROTECTED] wrote: Ah, the main point of this package is to create a local ad-hoc package which can coexist with its official package. Escpecially, I can manage my temporary on-going improvement to some debian package as a debian package. I didn't think to waste official debian packages because we shouldn't upload this kind of patch packages to the official but merge the patch to the official packages if we want to share them on public. The main question is what on god's green earth does this do that dpkg-divert doesn't do? Looking at the package description, it implies that it will in fact do a lot less than dpkg-divert unless you tell it otherwise. This creates a fragment to use dpkg-divert. It checks all md5sums of each package and lists files which we need to invoke 'dpkg-divert'. This seems like it would make more sense as a debhelper component than as an independent program. Yes, this package includes dh_gendebdivert to make the fragment. * debdivert program to make a diff build-tree * debhelper interface to use debidvert as a backend * cdbs inteface to use the debhelper interface as the backend I don't know well whether this package name is appropriate.
Re: Debian conference in the US?
On Sat, May 24, 2003 at 07:46:53PM -0400, Geordie Birch wrote: On Sun, May 25, 2003 at 03:32:57AM +1000, Russell Coker wrote: For avoiding entering the US there are better reasons such as the following: http://www.informationclearinghouse.info/article1689.htm May 20, 2003. French reporters covering Electronic Entertainment Expo (E3) arrested, forcibly repatriated: http://www.theinquirer.net/?article=9609 http://www.rsf.org/article.php3?id_article=6909 Oh my god. The last time I heard this was the shocking news from Baghdad when CNN got thrown out by Saddam for not having the new press visas. There are even reports that Canadian citizens that have darker skins are discriminated against. There was one _Canadian_ citizen that got arrested in the US because he didn't have a visa [NOTE: Canadians do not need visas to enter US and vice versa] He was then deported to Sudan because apparently he immigrated from there to Canada a two or three decades ago. My parents got searched _twice_ (yes, including shoes!!) in the states. They were going back home from Europe and they had to catch a connecting flight in Miniapolis, Minnesota. Maybe it's just me, but it appears that people have less freedom now if they travel to US, then when you travelled to 1970s Soviet Union. Land of the free, lol. - Adam PS. Personally, I would prefer to travel for a DebConf in Cuba than in US. Really.
Re: Debian no FISL2003 - cade?????
Eu tambem estou em SP - Capital e gostaria de ir ... mas por enquanto estou sozinho Infelizmente peguei o thread pela metade, entao nao tenho nenhum email/endereco de alguem que esteja organizando um onibus p/ la. []'s On Fri, 2003-05-23 at 17:15, Gustavo Polillo wrote: Ola lista, muitas falam de ir a FISL2003, e alguns estao juntado a galera para ir de onibus... mandei emails alertando sobre meu interesse e ninguem respondeu... sera que e papo furado??? somos em 3 pessoas e caso alguem esteja interessado em ir conosco.. estamos em sp capital... ate.. Gustavo.
