From notting at redhat.com Mon Jul 21 14:03:38 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 21 Jul 2003 10:03:38 -0400 Subject: Announcing a beta release of Red Hat Linux: Severn Message-ID: <20030721100338.A701@devserv.devel.redhat.com> Thank you gentlemen. This is rumor control. Here are the facts. As some of you know, new Red Hat Linux Beta bits crash landed here at 1000 on the morning watch. There was one survivor. Two dead processes, and a daemon that was hopelessly smashed beyond repair. The survivor is called SEVERN. It's that time again. (Time to floss?) (Time to make a gooky?) No, it's time for a Red Hat Linux Beta, named SEVERN. "I just want to say that I took a vow of stability. That also includes betas. We all took the vow. Now let me say, that I for one, do not appreciate Company policy allowing beta bits to freely intermingle..." "Cheeky bastard, right sir?" "What brother means to say is ... We view the presence of any outside OS, beta, as a violation of the stability, a potential break in the spiritual unity." We are well aware of your feelings in this matter. You will be pleased to know that I have requested a testing team - Hopefully, they will be here inside of a few hours and evaluate it A.S.A.P. As always, betas such as SEVERN are not intended for use on production environments. Use as such could lead to your machines being slaughtered like pigs by the dragon. Or just public laughter. Problems with SEVERN should be reported via bugzilla, at: http://bugzilla.redhat.com/bugzilla/ What's its development status? "It doesn't seem too horrendously in flux. Difficult at this moment to make a specific diagnosis." Among other things, SEVERN has: - a new graphical boot - GCC 3.3 - an updated 2.4.21 kernel - updated Evolution and Mozilla - and more! Will it live? "Yes, I should think so." Look, none of us here is naive. It's in everybody's best interests if this beta doesn't come out into production until the testing team is through with it. And certainly not without the proper qualification and bug reports. Right? So we should all stick to our set routines and not get unduly agitated. Correct? All right. Thank you gentlemen. Speaking of unduly agitated... there's lots of rumors going on about Red Hat Linux. We've been doing it for nearly ten years now, and in that time, there's been various changes. From rpp to RPM, from Red Hat Commercial Linux to Official Red Hat Linux, from 'install' to anaconda. And now, we're making another change. We changed the rules. We said our Linux should be your Linux. Just as most of the software in Red Hat Linux is developed in an open fashion, so should Red Hat Linux itself; driven by those who develop, test, document, and translate. To accomplish this, we're opening up our process. Now this is an evolution, not a revolution. The first steps will be moving much of our development discussions and schedules external, via mailing lists and other means, and including external developers in the process of making technical decisions. More will be done from there. Red Hat Linux will remain as it has been; a freely available general purpose operating system, released on the average every six months. For more information, see: http://rhl.redhat.com/ For discussion of SEVERN, send mail to: rhl-beta-list-request at redhat.com with subscribe in the subject line. You can leave the body empty. Or see: https://listman.redhat.com/mailman/listinfo/rhl-beta-list/ As always, you can get SEVERN at redhat.com, specifically: ftp://ftp.redhat.com/pub/redhat/beta/severn/ Or the following mirrors: North America: United States: ftp://moni.msci.memphis.edu/pub/redhat/linux/beta/severn/ http://moni.msci.memphis.edu/pub/redhat/linux/beta/severn/ ftp://linux.stanford.edu/pub/mirrors/redhat/linux/beta/severn/ ftp://ftp.cse.buffalo.edu/pub/RedHat/redhat/linux/beta/severn/ ftp://mirror.eas.muohio.edu/mirrors/redhat/linux/beta/severn/ ftp://mirrors.secsup.org/pub/linux/redhat/beta/severn/ ftp://redhat.dulug.duke.edu/pub/redhat/linux/beta/severn/ ftp://mirror.hiwaay.net/redhat/redhat/linux/beta/severn/ http://mirror.hiwaay.net/redhat/redhat/linux/beta/severn/ http://www.gtlib.cc.gatech.edu/pub/redhat/linux/beta/severn/ ftp://ftp.gtlib.cc.gatech.edu/pub/redhat/linux/beta/severn/ rsync://rsync.gtlib.cc.gatech.edu/redhat/linux/beta/severn/ Canada: ftp://less.cogeco.net/pub/redhat/linux/beta/severn/ ftp://ftp.nrc.ca/pub/systems/linux/redhat/ftp.redhat.com/linux/beta/severn/ South America: Brazil: http://bastion.las.ic.unicamp.br/pub/redhat/linux/beta/severn ftp://bastion.las.ic.unicamp.br/pub/redhat/linux/beta/severn Chile: ftp://ftp.tecnoera.com/Linux/redhat-beta/severn/ Europe: Austria: ftp://gd.tuwien.ac.at/opsys/linux/redhat.com/dist/linux/beta/severn/ http://gd.tuwien.ac.at/opsys/linux/redhat.com/dist/linux/beta/severn/ rsync://gd.tuwien.ac.at/opsys/linux/redhat.com/dist/linux/beta/severn/ Czech Republic: ftp://sunsite.mff.cuni.cz/MIRRORS/ftp.redhat.com/redhat/linux/beta/severn/ ftp://ultra.linux.cz/MIRRORS/ftp.redhat.com/redhat/linux/beta/severn/ ftp://sunsite.cnlab-switch.ch/mirror/redhat/linux/beta/severn/ ftp://ftp.linux.cz/pub/linux/redhat/linux/beta/severn/ ftp://ftp6.linux.cz/pub/linux/redhat/linux/beta/severn/ Denmark: ftp://klid.dk/pub/redhat/linux/beta/severn/ Germany: ftp://ftp.tu-chemnitz.de/pub/linux/redhat-ftp/redhat/linux/beta/severn/ http://wftp.tu-chemnitz.de/pub/linux/redhat-ftp/redhat/linux/beta/severn/ ftp://ftp.informatik.uni-frankfurt.de/pub/linux/Mirror/ftp.redhat.com/linux/beta/severn/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/redhat/linux/beta/severn/ Ireland: ftp://ftp.esat.net/mirrors/ftp.redhat.com/redhat/linux/beta/severn/ http://ftp.esat.net/mirrors/ftp.redhat.com/redhat/linux/beta/severn/ rsync://ftp.esat.net/mirrors/ftp.redhat.com/redhat/linux/beta/severn/ Netherlands: ftp://ftp.nluug.nl/pub/os/Linux/distr/RedHat/ftp/redhat/linux/beta/severn/ ftp://ftp.surfnet.nl/pub/os/Linux/distr/RedHat/ftp/redhat/linux/beta/severn/ ftp://alviss.et.tudelft.nl/pub/redhat/beta/severn/ Poland: ftp://sunsite.icm.edu.pl/pub/Linux/redhat/linux/beta/severn/ rsync://sunsite.icm.edu.pl/ftp/pub/Linux/redhat/linux/beta/severn/ http://sunsite.icm.edu.pl/pub/Linux/redhat/linux/beta/severn/ Romania: ftp://ftp.iasi.roedu.net/pub/mirrors/ftp.redhat.com/pub/redhat/linux/beta/severn/ http://ftp.iasi.roedu.net/mirrors/ftp.redhat.com/pub/redhat/linux/beta/severn/ rsync://ftp.iasi.roedu.net/ftp.redhat.com/pub/redhat/linux/beta/severn/ Turkey: ftp://ftp.linux.org.tr/pub/redhat/beta/severn/ United Kingdom: http://zeniiia.linux.org.uk/pub/distributions/redhat/beta/severn/ ftp://zeniiia.linux.org.uk/pub/distributions/redhat/beta/severn/ rsync://zeniiia.linux.org.uk/ftp/pub/distributions/redhat/beta/severn/ Asia/Pacific: Australia: http://planetmirror.com/pub/redhat/linux/beta/severn/ ftp://ftp.planetmirror.com/pub/redhat/linux/beta/severn/ http://mirror.aarnet.edu.au/pub/redhat/linux/severn/ ftp://mirror.aarnet.edu.au/pub/redhat/linux/severn/ Japan: ftp://ftp.sfc.wide.ad.jp/pub/Linux/RedHat/linux/beta/severn/ Singapore: ftp://ftp.oss.eznetsols.org/linux/redhat/linux/beta/severn/ rsync://rsync.oss.eznetsols.org/linux/redhat/linux/beta/severn/ One additional feature provided by the Linux community is the availability of SEVERN via BitTorrent. http://torrent.dulug.duke.edu/severn-binary-iso.torrent http://torrent.dulug.duke.edu/severn-source-iso.torrent RPMS for Red Hat Linux 7.3 through 9 of BitTorrent are available from: http://torrent.dulug.duke.edu/btrpms/ Usage is simple: btdownloadcurses.py --url http://URL.torrent Allow incoming TCP 6881 - 6889 to join the torrent swarm. http://torrent.dulug.duke.edu/ From kaboom at gatech.edu Mon Jul 21 14:24:52 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Mon, 21 Jul 2003 08:24:52 -0600 (MDT) Subject: docs in downloadable format? Message-ID: I'm browsing through http://rhl.redhat.com/ -- looks good. Under the Participate section, there's a "Developer's Guide" and a "Documentation Guide". Any chance of those being posted in a format that's easy to download / print (pdf, single inline html, or similar)? later, chris From ed at redhat.com Mon Jul 21 14:31:24 2003 From: ed at redhat.com (Edward C. Bailey) Date: 21 Jul 2003 10:31:24 -0400 Subject: docs in downloadable format? In-Reply-To: References: Message-ID: >>>>> "Chris" == Chris Ricker writes: Chris> I'm browsing through http://rhl.redhat.com/ -- looks good. Under Chris> the Participate section, there's a "Developer's Guide" and a Chris> "Documentation Guide". Any chance of those being posted in a format Chris> that's easy to download / print (pdf, single inline html, or Chris> similar)? I'm not the person responsible for that, but I don't see any reason why not. Let me check... Ed -- Ed Bailey Red Hat, Inc. http://www.redhat.com/ From tfox at redhat.com Mon Jul 21 14:48:07 2003 From: tfox at redhat.com (Tammy Fox) Date: Mon, 21 Jul 2003 10:48:07 -0400 Subject: docs in downloadable format? In-Reply-To: References: Message-ID: <20030721144807.GG24468@redhat.com> I'm working on it. The tools to produce PDFs from DocBook XML aren't very robust. Tam On Mon, Jul 21, 2003 at 08:24:52AM -0600, Chris Ricker wrote: > I'm browsing through http://rhl.redhat.com/ -- looks good. > > Under the Participate section, there's a "Developer's Guide" and a > "Documentation Guide". Any chance of those being posted in a format that's > easy to download / print (pdf, single inline html, or similar)? > > later, > chris > > From twaugh at redhat.com Mon Jul 21 16:03:45 2003 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 21 Jul 2003 17:03:45 +0100 Subject: docs in downloadable format? In-Reply-To: <20030721144807.GG24468@redhat.com> References: <20030721144807.GG24468@redhat.com> Message-ID: <20030721160345.GA16222@redhat.com> On Mon, Jul 21, 2003 at 10:48:07AM -0400, Tammy Fox wrote: > I'm working on it. The tools to produce PDFs from DocBook XML aren't > very robust. Hopefully xmlroff will mature quickly, and then we can switch to that. xmlroff.sourceforge.net Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jorton at redhat.com Mon Jul 21 18:38:38 2003 From: jorton at redhat.com (Joe Orton) Date: Mon, 21 Jul 2003 19:38:38 +0100 Subject: docs in downloadable format? In-Reply-To: <20030721160345.GA16222@redhat.com> References: <20030721144807.GG24468@redhat.com> <20030721160345.GA16222@redhat.com> Message-ID: <20030721183838.GA10901@redhat.com> On Mon, Jul 21, 2003 at 05:03:45PM +0100, Tim Waugh wrote: > On Mon, Jul 21, 2003 at 10:48:07AM -0400, Tammy Fox wrote: > > > I'm working on it. The tools to produce PDFs from DocBook XML aren't > > very robust. > > Hopefully xmlroff will mature quickly, and then we can switch to that. Neat, hadn't seen this. Have you tried any of the Apache FOP tools (Java stuff)? They supposedly produce decent PDF output. http://xml.apache.org/fop/ From feliciano.matias at free.fr Mon Jul 21 23:01:06 2003 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: 22 Jul 2003 01:01:06 +0200 Subject: docs in downloadable format? In-Reply-To: <20030721144807.GG24468@redhat.com> References: <20030721144807.GG24468@redhat.com> Message-ID: <1058828465.1606.28.camel@one.myworld> Le lun 21/07/2003 ? 16:48, Tammy Fox a ?crit : > I'm working on it. The tools to produce PDFs from DocBook XML aren't > very robust. > Can you please put the translation online. RedHat have a really beautiful documentation ! Check this : http://www.redhat.com/docs/manuals/linux/ Only in English. Check this : http://ftp.rhnet.is/pub/redhat/linux/9/en/doc/RH-DOCS/index-en.html No links to the French, Spanish, ... translations. > Tam > > On Mon, Jul 21, 2003 at 08:24:52AM -0600, Chris Ricker wrote: > > I'm browsing through http://rhl.redhat.com/ -- looks good. > > > > Under the Participate section, there's a "Developer's Guide" and a > > "Documentation Guide". Any chance of those being posted in a format that's > > easy to download / print (pdf, single inline html, or similar)? > > > > later, > > chris > > > > http://rhl.redhat.com/ is great. A french man with a poor english. -- F?liciano Matias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tfox at redhat.com Tue Jul 22 00:35:11 2003 From: tfox at redhat.com (Tammy Fox) Date: Mon, 21 Jul 2003 20:35:11 -0400 Subject: docs in downloadable format? In-Reply-To: <1058828465.1606.28.camel@one.myworld> References: <20030721144807.GG24468@redhat.com> <1058828465.1606.28.camel@one.myworld> Message-ID: <20030722003511.GB29611@redhat.com> On Tue, Jul 22, 2003 at 01:01:06AM +0200, F?liciano Matias wrote: > Le lun 21/07/2003 ? 16:48, Tammy Fox a ?crit : > > I'm working on it. The tools to produce PDFs from DocBook XML aren't > > very robust. > > > > Can you please put the translation online. > RedHat have a really beautiful documentation ! > Check this : > http://www.redhat.com/docs/manuals/linux/ > > Only in English. > > Check this : > http://ftp.rhnet.is/pub/redhat/linux/9/en/doc/RH-DOCS/index-en.html > > No links to the French, Spanish, ... translations. > The plan is to put the translated versions of the docs up on http://www.redhat.com/docs/. I just haven't gotten to it yet because of other priorities (like the project). There used to be some available on the non-US sites such as www.europe.redhat.com, but I'm not sure if they are still there. Tam > > Tam > > > > On Mon, Jul 21, 2003 at 08:24:52AM -0600, Chris Ricker wrote: > > > I'm browsing through http://rhl.redhat.com/ -- looks good. > > > > > > Under the Participate section, there's a "Developer's Guide" and a > > > "Documentation Guide". Any chance of those being posted in a format that's > > > easy to download / print (pdf, single inline html, or similar)? > > > > > > later, > > > chris > > > > > > > > http://rhl.redhat.com/ is great. > > > > A french man with a poor english. > > -- > F?liciano Matias -- From feliciano.matias at free.fr Tue Jul 22 00:56:29 2003 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: 22 Jul 2003 02:56:29 +0200 Subject: docs in downloadable format? In-Reply-To: <20030722003511.GB29611@redhat.com> References: <20030721144807.GG24468@redhat.com> <1058828465.1606.28.camel@one.myworld> <20030722003511.GB29611@redhat.com> Message-ID: <1058835388.3330.8.camel@one.myworld> Le mar 22/07/2003 ? 02:35, Tammy Fox a ?crit : > On Tue, Jul 22, 2003 at 01:01:06AM +0200, F?liciano Matias wrote: > > Le lun 21/07/2003 ? 16:48, Tammy Fox a ?crit : > > > I'm working on it. The tools to produce PDFs from DocBook XML aren't > > > very robust. > > > > > > > Can you please put the translation online. > > RedHat have a really beautiful documentation ! > > Check this : > > http://www.redhat.com/docs/manuals/linux/ > > > > Only in English. > > > > Check this : > > http://ftp.rhnet.is/pub/redhat/linux/9/en/doc/RH-DOCS/index-en.html > > > > No links to the French, Spanish, ... translations. > > > > The plan is to put the translated versions of the docs up on > http://www.redhat.com/docs/. I just haven't gotten to it yet because > of other priorities (like the project). Take the time you need to make it clean like the current http://rhl.redhat.com/. There is not urgency. > There used to be some > available on the non-US sites such as www.europe.redhat.com, but I'm > not sure if they are still there. Thanks. There is a problem for http://www.fr.redhat.com/documentation/ ... > Tam > > > > Tam > > > > > > On Mon, Jul 21, 2003 at 08:24:52AM -0600, Chris Ricker wrote: > > > > I'm browsing through http://rhl.redhat.com/ -- looks good. > > > > > > > > Under the Participate section, there's a "Developer's Guide" and a > > > > "Documentation Guide". Any chance of those being posted in a format that's > > > > easy to download / print (pdf, single inline html, or similar)? > > > > > > > > later, > > > > chris > > > > > > > > > > > > http://rhl.redhat.com/ is great. > > > > > > > > A french man with a poor english. > > > > -- > > F?liciano Matias -- F?liciano Matias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From EULERKHC1976 at kmfms.com Tue Jul 22 08:51:53 2003 From: EULERKHC1976 at kmfms.com (euler euler) Date: Tue, 22 Jul 2003 01:51:53 -0700 (PDT) Subject: AN IDEA FOR A BIG PROJECT! Message-ID: <20030722085153.E86A1CF45@sitemail.everyone.net> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From mark at mark.mielke.cc Tue Jul 22 09:41:21 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Tue, 22 Jul 2003 05:41:21 -0400 Subject: AN IDEA FOR A BIG PROJECT! In-Reply-To: <20030722085153.E86A1CF45@sitemail.everyone.net> References: <20030722085153.E86A1CF45@sitemail.everyone.net> Message-ID: <20030722094121.GA2887@mark.mielke.cc> So, euler, you want everybody to install uml, and make their uml installation available to the public. It's a neat idea, but it wouldn't work for a few reasons: 1) It is almost impossible to ensure that the protected area has no influence on the main machine. Performance will suffer, available memory will be reduced, or disk space will be used up. 2) If packets can get in to this 'special area', and they can get back out, then they must be getting past the firewall configurations that people have erected to keep the bad people out. How do you tell good testers from malicious or disrespectful testers? 3) The product isn't being tested on a real kernel. It is being tested in a protected area that does not match real world conditions, and does not talk to real hardware. (If it talked to real hardware, point (1) would become more significant) The approach that has impressed me, is companies such as IBM offering time share on test machines to reknowned open source developers, and in some cases, even to merely curious open source developers. mark On Tue, Jul 22, 2003 at 01:51:53AM -0700, euler euler wrote: > Hello everyone, > I have a good idea for a big project, > any developer care to listen? > The development of Linux is always > depend on chance, not certainity. > It maybe the biggest hinderance for > Linux to become a real competitive > OS. > For Linux to run well, either kernel > and softwares has to be tested on > many different hardwares platform > (combination of CPU and other > components). Currently, if some developer > has developed a program, s/he > will post it in E-mail/mailing list, > then wait for someone of unknown > hardware platform to test it. S/he: > 1.) Can NOT TARGET a certain > hardware platform for beta-test, > it all depend on his/her luck; > 2.) Can NOT expect a response within certain time limit; > 3.) May NOT able to test the program on ALL hardware platform > for a long time. > To overcome this, how do we TURN every > Linux user automatically a beta-tester without > ANY technical background? > The answer lie in a specially made kernel: > It will allocated a protected area of CPU which > is open for ALL developer in the world for > beta-testing his/her program. For instance, if > a developer is writing a program called K which > he want to test on hardware platform A,B and C, he > will just have to activate a searcher in his Linux, > then the searcher will look at the hardware profile > of all Linux in the world to find a match; if a match > is made, then the program is travel through www to > these specific computer; the program is executed in > the special area of CPU which will NOT affect what > the owner is doing, then the result is sent back > to the original developer for comparison. Now the > developer can get results for ANY specified hardware > platform in an expect time, it does NOT depend on > luck or chance! S/he could get MANY MANY MANY > results from MANY MANY MANY different hardware > platform within a short time, and s/he should > NEVER worry about un-tested platforms since the > whole Linux community's CPU is open for him/her. > Moreover, instead of waiting for some human to > pick it up from a list then test it then post the > result, everything is now done AUTOMATICALLY > without the help of owner, the developer can > COUNT on getting the result within hours or even > minutes, how much it will SPEED UP the Linux > development? Any taker of this idea? Anyone want > to write a new chapter of Linux development? > I believe developmental process is key aspect > to improve and refine if Linux want to stay ahead. > > > Thanks in advance! > Best Regards, > Euler Cheung > Project Manager > LinuxLiveCD.com > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From matthias at rpmforge.net Tue Jul 22 10:26:04 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Tue, 22 Jul 2003 12:26:04 +0200 Subject: RPM building section of RHL's developer guide Message-ID: <20030722122604.624f3b23.matthias@rpmforge.net> Hi, I've got a few minor remarks regarding the example spec file given here: http://rhl.redhat.com/participate/developers-guide/ch-rpm-building.html - Summary: "The foo package does foo": Having redundancy ("the package foo") in the summary is useless IMHO, and shouldn't be encouraged. - Summary: I'd like to see an official suggestion as to whether a trailing dot should be added or omitted. If would be prettier when all go by at install time :-) - Requires vs. PreReq: AFAIK, both are now handled identically and using PreReq shouldn't be needed anymore. Jeff can correct me if I'm wrong. For explicit requirements of the %pre/%post scriplets, should the "Requires(pre):" way be suggested from now on or not? - BuildPreReq vs. BuildRequires: Same thing, and it seems even more useless to have any kind of distinction for source packages. - %description and %prep shouldn't be stuck together for readability and section separation. - %makeinstall should probably not be separated from the rest of the %install section as it's just a macro, not a separate section. - The $1, 0 and 1 from the scriplets should either be all or none quoted to keep consistent. AFAIK, $1 is always present and is an integer, so quoting is not required. - The %defattr could show the default directory mode too, by using %defattr(-, root, root, 0755) instead (or replace 0755 with - maybe) as directories might get mode 775 depending on the user's umask. - The n-e-v-r should maybe be added at the end of the first line of each %changelog entry. I don't do it myself (email address too long ;-)), but I've noticed it has become common practise inside Red Hat. It's a nice introduction page to what a spec file is, the descriptions below are short and clear. Good work! Now about the guidelines... ;-) 5) "The package may obsolete itself"... I really don't get that one! 6) "If a file from the package conflicts with a file from another package in the Red Hat Linux project, the package must use Conflicts: to specify it in the spec file." Should this be "Conflicts:" with the file or the package name? 12) s/specified/specify/ typo. 13) "If a newer RPM does not have a binary package that the older SRPMS produced, the binary package not produced anymore must be specified with the Obsoletes: option in the new spec file." I would also add something about encouraging to always use versions with "Obsoletes:" in order to avoid many kind of future issues when re-introducing packages for example. Also, there is no mention of "Epoch:" usage, not even a quick note to suggest not introducing any apart from when it's really the last resort. I guess people may want to stay out of the endless discussion for as long as possible ;-) IIRC, I think I read someone mentioning somewhere that a list of current packages with full "n-e-v-r" would be maintained. With the current implementation of epoch handling in rpm >= 4.2.1, this will become a necessity when depending on specific versions of certain packages. Long mail, hopefully not just useless talk, or else, well... "sorry" ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Raw Hide 20030718 running Linux kernel 2.4.20-20.1.2013.nptl Load : 0.24 0.27 0.26 From pauln at truemesh.com Tue Jul 22 11:24:40 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 22 Jul 2003 12:24:40 +0100 Subject: External CVS access Message-ID: <20030722112439.GD18698@raq465.uk2net.com> As documented: http://rhl.redhat.com/projects/additional-projects/kudzu/ [paul at uruk src]$ export CVSROOT=:pserver:anonymous at rhlinux.redhat.com:/usr/local/CVS [paul at uruk src]$ cvs -z3 login Logging in to :pserver:anonymous at rhlinux.redhat.com:2401/usr/local/CVS CVS password: cvs [login aborted]: connect to rhlinux.redhat.com(66.187.233.241):2401 failed: Connection timed out I assume this just isn't setup yet. Paul From jos at xos.nl Tue Jul 22 11:39:54 2003 From: jos at xos.nl (Jos Vos) Date: Tue, 22 Jul 2003 13:39:54 +0200 Subject: RPM building section of RHL's developer guide In-Reply-To: Your message of "Tue, 22 Jul 2003 12:26:04 +0200." <20030722122604.624f3b23.matthias@rpmforge.net> Message-ID: <200307221139.h6MBdsH22176@xos037.xos.nl> Hi, > - Summary: I'd like to see an official suggestion as to whether a trailing > dot should be added or omitted. If would be prettier when all go by at > install time :-) Agreed. I propose: summary without a trailing dot, description contains one or more complete sentences (or even paragraphs), thus with dots. > - Requires vs. PreReq: AFAIK, both are now handled identically and using > PreReq shouldn't be needed anymore. Jeff can correct me if I'm wrong. > For explicit requirements of the %pre/%post scriplets, should the > "Requires(pre):" way be suggested from now on or not? I didn't know it was handled the same, as the semantics are different. But I can't find the Ultimate Reference Guide for RPM right now ;-) ;-), so I don't know yet. > - The $1, 0 and 1 from the scriplets should either be all or none quoted > to keep consistent. AFAIK, $1 is always present and is an integer, so > quoting is not required. True, and there is more: "=" *and* "-ge" are used, the first is an operator for string comparison, the second is an operator for number comparison. I assume it's always a number, you should use "-eq" i.s.o. "=". > - The %defattr could show the default directory mode too, by using > %defattr(-, root, root, 0755) instead (or replace 0755 with - maybe) > as directories might get mode 775 depending on the user's umask. Umask is set by rpm, but I might be wrong. > 5) "The package may obsolete itself"... I really don't get that one! Older version, maybe? > 6) "If a file from the package conflicts with a file from another package > in the Red Hat Linux project, the package must use Conflicts: to > specify it in the spec file." > Should this be "Conflicts:" with the file or the package name? Package name, I guess, as it would otherwise conflict with itself. For the rest I agree with most comments. It's nice to see that others also think in so much detail about spec files, including a discussion about a dot at the end of the summary line ;-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From pmatilai at welho.com Tue Jul 22 11:51:09 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 22 Jul 2003 14:51:09 +0300 Subject: RPM building section of RHL's developer guide In-Reply-To: <20030722122604.624f3b23.matthias@rpmforge.net> References: <20030722122604.624f3b23.matthias@rpmforge.net> Message-ID: <1058874669.3f1d252da3f3f@webmail.welho.com> Quoting Matthias Saou : > Hi, > > I've got a few minor remarks regarding the example spec file given here: > http://rhl.redhat.com/participate/developers-guide/ch-rpm-building.html > > - Summary: "The foo package does foo": Having redundancy ("the package > foo") in the summary is useless IMHO, and shouldn't be encouraged. Seconded. > - Requires vs. PreReq: AFAIK, both are now handled identically and using > PreReq shouldn't be needed anymore. Jeff can correct me if I'm wrong. IIRC PreReq vs Requires handling only differs in presence of dependency loops. Speaking of which... would be good to point out in the docs never to create them. > For explicit requirements of the %pre/%post scriplets, should the > "Requires(pre):" way be suggested from now on or not? See http://www.fedora.us/pipermail/fedora-devel/2003-June/001457.html - how you interprete that is another deal :) > - BuildPreReq vs. BuildRequires: Same thing, and it seems even more > useless to have any kind of distinction for source packages. Yup, these are just aliases for each other. > - The n-e-v-r should maybe be added at the end of the first line of each > %changelog entry. I don't do it myself (email address too long ;-)), > but I've noticed it has become common practise inside Red Hat. Some additional stuff: - "make" in %build section should probably be "make %{?_smp_mflags}" to enable paraller compiling where applicable, or at least mention that in the hints section. > > It's a nice introduction page to what a spec file is, the descriptions > below are short and clear. Good work! Indeed! > > > Now about the guidelines... ;-) > > 5) "The package may obsolete itself"... I really don't get that one! Me neither, unless it means packages which have "Obsoletes: foo" and "Provides: foo" but even in that case it could be worded more clearly. > Also, there is no mention of "Epoch:" usage, not even a quick note to > suggest not introducing any apart from when it's really the last resort. I > guess people may want to stay out of the endless discussion for as long as > possible ;-) > IIRC, I think I read someone mentioning somewhere that a list of current > packages with full "n-e-v-r" would be maintained. With the current > implementation of epoch handling in rpm >= 4.2.1, this will become a > necessity when depending on specific versions of certain packages. Also I didn't notice any version handling guidelines. The Fedora project spent like 6 months creating a specification how to handle odd package versioning so that rpm can deal with them cleanly and there are *still* some unresolved bits. Much of the document is Fedora-specific but similar document about handling alphabets in version numbers etc would be good addition to the docs: http://www.fedora.us/wiki/PackageNamingGuidelines -- - Panu - From matthias at rpmforge.net Tue Jul 22 11:56:19 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Tue, 22 Jul 2003 13:56:19 +0200 Subject: RPM building section of RHL's developer guide In-Reply-To: <200307221139.h6MBdsH22176@xos037.xos.nl> References: <20030722122604.624f3b23.matthias@rpmforge.net> <200307221139.h6MBdsH22176@xos037.xos.nl> Message-ID: <20030722135619.2728f94f.matthias@rpmforge.net> Jos Vos wrote : > For the rest I agree with most comments. It's nice to see that > others also think in so much detail about spec files, including a > discussion about a dot at the end of the summary line ;-). But I can imagine from here poor Jeff ripping his hair off because of people discussing futile spec file aspects when there isn't even a spec file grammar :-) I'm personally glad too to see that some initial recommendations have been written, instead of some strict guidelines that could have been tossed at everyone. Now what I'd love to see is a publicly accessible CVS repository of all current Red Hat Linux spec files (and associated files like initscripts, patches, menu entries...). It would become much easier to track ongoing changes and submit patches. And after, even easier for Red Hat to get external contributions in one place. I guess the CVS instructions in the Developer Guide aren't there by pure luck ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Raw Hide 20030718 running Linux kernel 2.4.20-20.1.2013.nptl Load : 0.17 0.20 0.22 From matthias at rpmforge.net Tue Jul 22 12:10:40 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Tue, 22 Jul 2003 14:10:40 +0200 Subject: RPM building section of RHL's developer guide In-Reply-To: <1058874669.3f1d252da3f3f@webmail.welho.com> References: <20030722122604.624f3b23.matthias@rpmforge.net> <1058874669.3f1d252da3f3f@webmail.welho.com> Message-ID: <20030722141040.6b28b64e.matthias@rpmforge.net> Panu Matilainen wrote : > Also I didn't notice any version handling guidelines. The Fedora project > spent like 6 months creating a specification how to handle odd package > versioning so that rpm can deal with them cleanly and there are *still* > some unresolved bits. Much of the document is Fedora-specific but similar > document about handling alphabets in version numbers etc would be good > addition to the docs: http://www.fedora.us/wiki/PackageNamingGuidelines The lack of "odd package versioning" is probably because that's yet another topic many people don't want to touch even with a 20m pole, just like introducing and handling epoch ;-) >From what I can tell, RH doesn't seem so reluctant(?) to add epochs when needed, unlike Fedora or me, as indeed they are the authoritative primary source for packages, and breaking 3rd party compatibility isn't the same as a 3rd party breaking compatibility with the main distro. I personally wouldn't mind being headed in a direction where all included packages have versions that match the upstream ones, even if this means a possible epoch introduction later on, as long as there is an exhaustive list of all RHL packages with their complete current n-e-v-r. Maybe there are drawbacks that I'm missing though, in which case I'd really like to know. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Raw Hide 20030718 running Linux kernel 2.4.20-20.1.2013.nptl Load : 0.13 0.15 0.14 From matthias at rpmforge.net Tue Jul 22 12:14:18 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Tue, 22 Jul 2003 14:14:18 +0200 Subject: External CVS access In-Reply-To: <20030722112439.GD18698@raq465.uk2net.com> References: <20030722112439.GD18698@raq465.uk2net.com> Message-ID: <20030722141418.7effec97.matthias@rpmforge.net> Paul Nasrat wrote : > As documented: > > http://rhl.redhat.com/projects/additional-projects/kudzu/ > > [paul at uruk src]$ export > CVSROOT=:pserver:anonymous at rhlinux.redhat.com:/usr/local/CVS > [paul at uruk src]$ cvs -z3 login > Logging in to :pserver:anonymous at rhlinux.redhat.com:2401/usr/local/CVS > CVS password: > cvs [login aborted]: connect to rhlinux.redhat.com(66.187.233.241):2401 > failed: > Connection timed out > > I assume this just isn't setup yet. As documented here : http://rhl.redhat.com/participate/developers-guide/s1-cvs-configure.html You need to access through ssh, not pserver, so "export CVS_RSH=ssh" is required. Haven't tried it yet, though :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Raw Hide 20030718 running Linux kernel 2.4.20-20.1.2013.nptl Load : 0.39 0.27 0.18 From jos at xos.nl Tue Jul 22 12:16:15 2003 From: jos at xos.nl (Jos Vos) Date: Tue, 22 Jul 2003 14:16:15 +0200 Subject: RPM building section of RHL's developer guide In-Reply-To: Your message of "Tue, 22 Jul 2003 13:56:19 +0200." <20030722135619.2728f94f.matthias@rpmforge.net> Message-ID: <200307221216.h6MCGFe22292@xos037.xos.nl> > Now what I'd love to see is a publicly accessible CVS repository of all > current Red Hat Linux spec files (and associated files like initscripts, I always start with for f in somepath/*.src.rpm; do rpm2cpio $f | cpio -iuvdm '*.spec'; done to look for all the new features in rpm ;-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From pauln at truemesh.com Tue Jul 22 12:58:13 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 22 Jul 2003 13:58:13 +0100 Subject: External CVS access In-Reply-To: <20030722141418.7effec97.matthias@rpmforge.net> References: <20030722112439.GD18698@raq465.uk2net.com> <20030722141418.7effec97.matthias@rpmforge.net> Message-ID: <20030722125813.GE18698@raq465.uk2net.com> On Tue, Jul 22, 2003 at 02:14:18PM +0200, Matthias Saou wrote: > Paul Nasrat wrote : > As documented here : > http://rhl.redhat.com/participate/developers-guide/s1-cvs-configure.html > > You need to access through ssh, not pserver, so "export CVS_RSH=ssh" is > required. Haven't tried it yet, though :-) I also tried this and it doesn't time out it looks as if ssh doesn't allow password auth. [paul at uruk src]$ export CVSROOT=:ext:anonymous at rhlinux.redhat.com:/usr/local/CVS [paul at uruk src]$ cvs co kudzu Permission denied (publickey,keyboard-interactive). cvs [checkout aborted]: end of file from server (consult above messages if any) [paul at uruk src]$ echo $? 1 Obviously I don't have pub key in anonymous' authorized_keys, so I thought anonymous access would be pserver as described for the kudzu page. Either way doesn't work for me. Paul From anvil at livna.org Tue Jul 22 13:54:14 2003 From: anvil at livna.org (Dams) Date: 22 Jul 2003 15:54:14 +0200 Subject: RPM building section of RHL's developer guide In-Reply-To: <20030722122604.624f3b23.matthias@rpmforge.net> References: <20030722122604.624f3b23.matthias@rpmforge.net> Message-ID: <1058882054.2223.26.camel@gruyere.lan.livna.org> I see in the template there is %{buildroot}. I thought JBJ told once $RPM_BUILD_ROOT was the 'official way' and %{buildroot} might be changed/removed one day.. According to this, fedora, who firstly used %{buildroot}, modified [almost] all spec files to use $RPM_BUILD_ROOT instead... So ? Who is 'wrong' ? What to do ? D Le mar 22/07/2003 ? 12:26, Matthias Saou a ?crit : > Hi, > > I've got a few minor remarks regarding the example spec file given here: > http://rhl.redhat.com/participate/developers-guide/ch-rpm-building.html > > - Summary: "The foo package does foo": Having redundancy ("the package > foo") in the summary is useless IMHO, and shouldn't be encouraged. > - Summary: I'd like to see an official suggestion as to whether a trailing > dot should be added or omitted. If would be prettier when all go by at > install time :-) > - Requires vs. PreReq: AFAIK, both are now handled identically and using > PreReq shouldn't be needed anymore. Jeff can correct me if I'm wrong. > For explicit requirements of the %pre/%post scriplets, should the > "Requires(pre):" way be suggested from now on or not? > - BuildPreReq vs. BuildRequires: Same thing, and it seems even more > useless to have any kind of distinction for source packages. > - %description and %prep shouldn't be stuck together for readability and > section separation. > - %makeinstall should probably not be separated from the rest of the > %install section as it's just a macro, not a separate section. > - The $1, 0 and 1 from the scriplets should either be all or none quoted > to keep consistent. AFAIK, $1 is always present and is an integer, so > quoting is not required. > - The %defattr could show the default directory mode too, by using > %defattr(-, root, root, 0755) instead (or replace 0755 with - maybe) > as directories might get mode 775 depending on the user's umask. > - The n-e-v-r should maybe be added at the end of the first line of each > %changelog entry. I don't do it myself (email address too long ;-)), > but I've noticed it has become common practise inside Red Hat. > > It's a nice introduction page to what a spec file is, the descriptions > below are short and clear. Good work! > > > Now about the guidelines... ;-) > > 5) "The package may obsolete itself"... I really don't get that one! > 6) "If a file from the package conflicts with a file from another package > in the Red Hat Linux project, the package must use Conflicts: to > specify it in the spec file." > Should this be "Conflicts:" with the file or the package name? > 12) s/specified/specify/ typo. > 13) "If a newer RPM does not have a binary package that the older SRPMS > produced, the binary package not produced anymore must be specified > with the Obsoletes: option in the new spec file." > I would also add something about encouraging to always use versions > with "Obsoletes:" in order to avoid many kind of future issues when > re-introducing packages for example. > > Also, there is no mention of "Epoch:" usage, not even a quick note to > suggest not introducing any apart from when it's really the last resort. I > guess people may want to stay out of the endless discussion for as long as > possible ;-) > IIRC, I think I read someone mentioning somewhere that a list of current > packages with full "n-e-v-r" would be maintained. With the current > implementation of epoch handling in rpm >= 4.2.1, this will become a > necessity when depending on specific versions of certain packages. > > Long mail, hopefully not just useless talk, or else, well... "sorry" ;-) > Matthias -- Dams Nad? Anvil/Anvilou on irc.freenode.net : #Linux-Fr, #Fedora I am looking for a job : http://livna.org/~anvil/cv.php "Dona Nobis Pacem E Dona Eis Requiem". Noir. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ms-nospam-0306 at arcor.de Tue Jul 22 14:09:02 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 22 Jul 2003 16:09:02 +0200 Subject: docs in downloadable format? In-Reply-To: <20030722003511.GB29611@redhat.com> References: <20030721144807.GG24468@redhat.com> <1058828465.1606.28.camel@one.myworld> <20030722003511.GB29611@redhat.com> Message-ID: <20030722160902.3759e841.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 21 Jul 2003 20:35:11 -0400, Tammy Fox wrote: > There used to be some > available on the non-US sites such as www.europe.redhat.com, but I'm > not sure if they are still there. Of course. It just has taken some time for the Shrike docs to show up there: http://europe.redhat.com/documentation/ - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/HUV+0iMVcrivHFQRAvxCAJ9sjRy1nYZ11HUkIt5phnVr772qeACbBO5d rsd3qW6un6LKtRiaXvJwGB0= =lW4o -----END PGP SIGNATURE----- From Michael.Redinger at uibk.ac.at Tue Jul 22 15:59:38 2003 From: Michael.Redinger at uibk.ac.at (Michael Redinger) Date: Tue, 22 Jul 2003 17:59:38 +0200 (CEST) Subject: External CVS access In-Reply-To: <20030722125813.GE18698@raq465.uk2net.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Same here. Tried bot "normal" and with CVS_RSH=ssh . Also posted this on the rhl-docs list, but the problem still exists. Michael On Tue, 22 Jul 2003, Paul Nasrat wrote: > On Tue, Jul 22, 2003 at 02:14:18PM +0200, Matthias Saou wrote: > > Paul Nasrat wrote : > > > As documented here : > > http://rhl.redhat.com/participate/developers-guide/s1-cvs-configure.html > > > > You need to access through ssh, not pserver, so "export CVS_RSH=ssh" is > > required. Haven't tried it yet, though :-) > > I also tried this and it doesn't time out it looks as if ssh doesn't > allow password auth. > > [paul at uruk src]$ export > CVSROOT=:ext:anonymous at rhlinux.redhat.com:/usr/local/CVS > [paul at uruk src]$ cvs co kudzu > Permission denied (publickey,keyboard-interactive). > cvs [checkout aborted]: end of file from server (consult above messages > if any) > [paul at uruk src]$ echo $? > 1 > > Obviously I don't have pub key in anonymous' authorized_keys, so I > thought anonymous access would be pserver as described for the kudzu > page. Either way doesn't work for me. - -- Michael Redinger Zentraler Informatikdienst (Computer Centre) Universitaet Innsbruck Technikerstrasse 13 Tel.: ++43 512 507 2335 6020 Innsbruck Fax.: ++43 512 507 2944 Austria Mail: Michael.Redinger at uibk.ac.at BB98 D2FE 0F2C 2658 3780 3CB1 0FD7 A9D9 65C2 C11D http://www.uibk.ac.at/~c102mr/mred-pubkey.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/HV9xD9ep2WXCwR0RAt0HAJ9ExZhjZgjY3w4MnOkPk9i8zW2yIgCg+pDF 6DPk61uXpgPL5JHgk4FfCsc= =bjoB -----END PGP SIGNATURE----- From notting at redhat.com Tue Jul 22 16:30:36 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 Jul 2003 12:30:36 -0400 Subject: External CVS access In-Reply-To: <20030722141418.7effec97.matthias@rpmforge.net>; from matthias@rpmforge.net on Tue, Jul 22, 2003 at 02:14:18PM +0200 References: <20030722112439.GD18698@raq465.uk2net.com> <20030722141418.7effec97.matthias@rpmforge.net> Message-ID: <20030722123036.E26155@devserv.devel.redhat.com> Matthias Saou (matthias at rpmforge.net) said: > As documented here : > http://rhl.redhat.com/participate/developers-guide/s1-cvs-configure.html > > You need to access through ssh, not pserver, so "export CVS_RSH=ssh" is > required. Haven't tried it yet, though :-) Woops, I believe that's wrong; it does need to be pserver. And yes, the pserver isn't working right now. Bill From pros-n-cons at bak.rr.com Tue Jul 22 20:13:27 2003 From: pros-n-cons at bak.rr.com (vincent) Date: Tue, 22 Jul 2003 13:13:27 -0700 Subject: xdirectfb In-Reply-To: <20030722193614.25881.96307.Mailman@listman.back-rdu.redhat.com> References: <20030722193614.25881.96307.Mailman@listman.back-rdu.redhat.com> Message-ID: <20030722131327.4bb1fbe4.pros-n-cons@bak.rr.com> Is xdirectfb installed in X by default? if not it should be, It's a tiny patch but alot of work to recompile all of X every time there is a RH update for those of us on low-end machines, or just not tech savy enough to install it. http://www.directfb.org/xdirectfb.xml From kaboom at gatech.edu Tue Jul 22 21:02:23 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Tue, 22 Jul 2003 15:02:23 -0600 (MDT) Subject: other window managers In-Reply-To: <20030722153100.J17627@devserv.devel.redhat.com> References: <20030722174021.11812.qmail@web40902.mail.yahoo.com> <20030722153100.J17627@devserv.devel.redhat.com> Message-ID: On Tue, 22 Jul 2003, Havoc Pennington wrote: > On Tue, Jul 22, 2003 at 10:40:21AM -0700, Lawrence Mao wrote: > > Just wondering whether RedHat or somebody else is > > thinking about adding other lightweights window > > managers besides that BlueCurve like Xfce, Fluxbox, or > > Fvwm! BlueCurve is nice but I don't need all those > > bells and whistles. I want something (window manager) > > that is fast and doesn't take up a lot of system > > resources... > > > > We aren't thinking of doing this ourselves at Red Hat, but alternative > WMs are a prime example of the kind of package we'd like to see added > to Red Hat Linux by others. Okay. I've got a fairly complete package of Openbox -- IMHO probably the best of the Blackbox family (blackbox, fluxbox, etc.) -- that I put together for fedora. How do I go about submitting this package? I'll bugzilla it against the distro for now, but what happens then? later, chris From michael at koziarski.com Tue Jul 22 22:14:18 2003 From: michael at koziarski.com (michael at koziarski.com) Date: Wed, 23 Jul 2003 10:14:18 +1200 Subject: Adding new packages to RedHat Linux Message-ID: <1058912058.3f1db73a5aace@202-0-52-37.cable.paradise.net.nz> Hi, I'm a user of gtkmm for my internal development work, redhat releases currently do not include a version of gtkmm-2 and this causes me a lot of problems. Judging by the following bugzilla entry, I'm not alone. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82473 With the announcement of the redhat linux project I was wondering what would be required to get gtkmm (and the gnomemm packages) added to the redhat linux project's releases. Some of us on the mailing list have already indicated that we'll be able to help with testing the spec files, builds, dependencies etc. http://mail.gnome.org/archives/gtkmm-list/2003-July/msg00185.html There's still some work to be done with the spec files, but the newly published guidelines make this much easier to do. Once we have the spec files updated and tested by a few of us with the new beta, what is the process we should follow to get the package officially included? Cheers Koz ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ From feliciano.matias at free.fr Wed Jul 23 02:20:22 2003 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: 23 Jul 2003 04:20:22 +0200 Subject: How to Propose Packages? In-Reply-To: <20030722155814.M17627@devserv.devel.redhat.com> References: <20030722174021.11812.qmail@web40902.mail.yahoo.com> <20030722153100.J17627@devserv.devel.redhat.com> <1058903265.1280.16.camel@owen.egbok.com> <20030722155814.M17627@devserv.devel.redhat.com> Message-ID: <1058926820.1232.55.camel@one.myworld> Le mar 22/07/2003 ? 21:58, Havoc Pennington a ?crit : > On Tue, Jul 22, 2003 at 12:47:47PM -0700, Howard Owen wrote: > > How do you propose a package for inclusion under the new regime? > > I have an auditing package called sudoscript that's been in contrib > > since 1.0.something. It's now at version 2.2.1 with 3.0 in testing. > > I'd like to maintain in RHL. What's the process? > > Well, that's the catch. We don't have the infrastructure in place yet. > > We've started by putting up a lot of our internal devel docs on > rhl.redhat.com, and moving our devel discussion from internal forums > to rhl-devel-list and #rhl-devel. So joining those is probably a good > step. > > The problem is that our infrastructure for all the aspects of > maintaining a package is still partially internal. So over the next > months, we will be trying to break down the barriers to external > contribution. > > Right now, to accept an external package we'd basically need someone > internal to act as a proxy for you to build your SRPMs, we may do this > for two or three packages, but it isn't going to scale at all. > Can we expect that this infrastructure will be an "open projet" in the RedHat Linux Projet ? > Havoc > > > -- > Rhl-list mailing list > Rhl-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-list -- F?liciano Matias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From hp at redhat.com Wed Jul 23 02:33:57 2003 From: hp at redhat.com (Havoc Pennington) Date: Tue, 22 Jul 2003 22:33:57 -0400 Subject: How to Propose Packages? In-Reply-To: <1058926820.1232.55.camel@one.myworld> References: <20030722174021.11812.qmail@web40902.mail.yahoo.com> <20030722153100.J17627@devserv.devel.redhat.com> <1058903265.1280.16.camel@owen.egbok.com> <20030722155814.M17627@devserv.devel.redhat.com> <1058926820.1232.55.camel@one.myworld> Message-ID: <20030722223357.D785@devserv.devel.redhat.com> On Wed, Jul 23, 2003 at 04:20:22AM +0200, F?liciano Matias wrote: > > Can we expect that this infrastructure will be an "open projet" in the > RedHat Linux Projet ? > I would think so, yes. Havoc From notting at redhat.com Wed Jul 23 03:34:40 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 22 Jul 2003 23:34:40 -0400 Subject: anonymous pserver access to rhlinux.redhat.com Message-ID: <20030722233440.A10002@devserv.devel.redhat.com> Anonymous pserver access to rhlinux.redhat.com should be restored now. We apologize for the inconvenience. Bill From nphilipp at redhat.com Wed Jul 23 05:46:45 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: 23 Jul 2003 07:46:45 +0200 Subject: [Patch] Start rhgb after mounting partitions (if not done yet), was: Graphical boot isn't so graphical In-Reply-To: References: <200307211503.57071.hosting@j2solutions.net> <20030721183741.F18319@devserv.devel.redhat.com> <200307211527.03478.hosting@j2solutions.net> <20030721184350.A31471@devserv.devel.redhat.com> <1058872851.20414.12.camel@gibraltar.stuttgart.redhat.com> Message-ID: <1058939205.3327.1.camel@wombat.dialup.fht-esslingen.de> On Tue, 2003-07-22 at 15:28, Jonathan Blandford wrote: > Nils Philippsen writes: > > > On Tue, 2003-07-22 at 00:43, Bill Nottingham wrote: > > > Jesse Keating (hosting at j2solutions.net) said: > > > > On Monday 21 July 2003 15:37, Bill Nottingham wrote: > > > > > You have a separate /usr? > > > > > > > > Yes, could that be it? > > > > > > That is exactly it, actaully. rhgb tries to start before /usr > > > is mounted, so it's very hard to run /usr/X11R6/bin/X in this > > > case. > > > > Hmm. How about retrying after mounts are in place? This is a similar > > situation as with swap files IMO. Will you accept a patch? > > Sure. Patch is attached to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100525 Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david.paeme at belbone.net Wed Jul 23 07:24:16 2003 From: david.paeme at belbone.net (david paeme) Date: 23 Jul 2003 09:24:16 +0200 Subject: my thoughts on package management Message-ID: <1058945056.3457.58.camel@owsdavid> Hello, this is my first post on the redhat-dev mailing list, but I'd like to share some ideas with you people, that might increase the ease of use for redhat. please be aware that this is my opinion, and I'm sure that your opinion or comments will be appreciated! (and don't shoot me for some stuff, because I haven't read the complete docs on the site yet ;-) here we go: RedHat has made an excellent decision when using the RedHat-network stuff... the update checker, so no comments there. But on the other side, people that aren't used to Linux (in general) will have problems installing/adding software. The rpm system is nice, but If you can't find an rpm that's compiled for your exact system, you're in trouble. And let's not forget the infamous dependancy hell! So why not use apt-like system (I'll call it apt from now on)? I know that there are probably a lot of arguments as why not to use it, but consider the advantages: It might be possible to have an installation version that is only 1 cd. This can then only contain the basic system, window manager, and some basic applications (if a system like knoppix can do this...). It is then possible to use apt to get people to install applications, without having to download 3 cd's in a row. (even with a graphical frontend like Synaptic) Also good about this, is that it can reduce debate about which packages need to be included with the distribution itself, and which not. And people will have 'official' redhat packages, for those that don't trust third-party stuff. What do you guys think? bye, David. From fs111 at web.de Wed Jul 23 07:52:01 2003 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: 23 Jul 2003 09:52:01 +0200 Subject: my thoughts on package management In-Reply-To: <1058945056.3457.58.camel@owsdavid> References: <1058945056.3457.58.camel@owsdavid> Message-ID: <1058946721.1460.13.camel@localhost> Am Mit, 2003-07-23 um 09.24 schrieb david paeme: > So why not use apt-like system (I'll call it apt from now on)? > I know that there are probably a lot of arguments as why not to use it, > but consider the advantages: or yum, which looks more stable to me. > It might be possible to have an installation version that is only 1 cd. > This can then only contain the basic system, window manager, and some > basic applications (if a system like knoppix can do this...). It is then > possible to use apt to get people to install applications, without > having to download 3 cd's in a row. (even with a graphical frontend like > Synaptic) Nice idea, it is like Debian, Gentoo or *BSD but i see a problem: There are still a lot of modem and ISDN (in Germany) users out on the net. For those people it is impossible to use apt/yum etc. to install big things like KDE or GNOME. They still need CDs/DVDs to simple install packages without waiting for weeks until all packages are downloaded. I think there must be a distro which has more than one CD. regards Andr? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From rjl at renaissoft.com Wed Jul 23 09:00:45 2003 From: rjl at renaissoft.com (Robert LeBlanc) Date: Wed, 23 Jul 2003 02:00:45 -0700 Subject: my thoughts on package management In-Reply-To: <1058945056.3457.58.camel@owsdavid> Message-ID: <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> At 00:24 2003/07/23, david paeme wrote: >RedHat has made an excellent decision when using the RedHat-network >stuff... the update checker, so no comments there. > >But on the other side, people that aren't used to Linux (in general) >will have problems installing/adding software. The rpm system is nice, >but If you can't find an rpm that's compiled for your exact system, >you're in trouble. And let's not forget the infamous dependancy hell! > > >So why not use apt-like system (I'll call it apt from now on)? This is an improvement that I'd like to see, yes, essentially a "smarter" package manager with an awareness of prerequisites, where to find them, and how to install them. A next-generation RPM, effectively :) On the other hand, I have a long-standing problem with RPMs and the updating system. While it's quite useful for workstation installations (where almost all packages are pre-compiled with suitable default options), it's all but useless on server installations, where custom configurations are common. As a case in point, if I happen to use IBM DB2 as my database of choice (or necessity) on a given server, I'll end up having to (re)build packages like PHP from sources in order to configure --with-ibm-db2 or somesuch. The RPM-based PHP distributions won't have been compiled with that option (though they may have MySQL support compiled in), so there's no way around building from sources in most cases. This not only defeats the purpose of RPMs for these applications, it also makes it impossible to use the automated updating features of the RH network, since that system relies on a registry of installed binary RPMs. If I built PHP 4.3.2 from sources and the up2date system saw that I had a previously-installed PHP 4.3.2 binary RPM installation, it might well upgrade me to the PHP 4.3.3 binary RPM, overwriting my custom build. What I'd like to see in RPMs for server packages is something like dynamic compilation based on some checkboxes or command-line flags that describe the options to autoconf. Essentially a higher-level interface to ./configure, which could be used to build a custom installation of the package, and store those settings (e.g. from config.status) so that later the up2date process could use those to properly build future versions without breaking the existing installation. If the configuration options are not backward-compatible, have up2date simply download the updated package and flag it for the administrator to deal with manually. If none of this is feasible, then at least consider compiling as many available options as possible into the binary distributions you package into RPMs, so that custom recompilations (which break up2date) won't be necessary in as many cases. Sure, this will result in larger, more bloated binaries, but at least they'll have all the optional support features built-in, so that there should be no need to rebuild the packages from sources later, even if you switch from MySQL to DB2, or something similar. Think of the way the installation kernel contains driver support for almost everything, to ensure that almost all hardware will be able to run the installation. If you're going to package binary distributions of applications in an RPM, and you want that to be automatically update-able, you'll have the most success when people are able to use that package "as-is", without having to make custom builds for themselves. Robert LeBlanc From ali at packetknife.com Wed Jul 23 09:14:58 2003 From: ali at packetknife.com (Ali-Reza Anghaie) Date: Wed, 23 Jul 2003 05:14:58 -0400 Subject: my thoughts on package management In-Reply-To: <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> References: <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> Message-ID: <200307230515.13765.ali@packetknife.com> On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote: > At 00:24 2003/07/23, david paeme wrote: > >So why not use apt-like system (I'll call it apt from now on)? Well, it looks like 'yum' is in Rawhide now so RH is considering/working such a thing. And the project page seems to indicate some hope on some form of integration w/ r-c-p. > This is an improvement that I'd like to see, yes, essentially a "smarter" > package manager with an awareness of prerequisites, where to find them, > and how to install them. A next-generation RPM, effectively :) Seperate APT from DEB in your head and realize the same must be done w/ RPM... > As a case in point, if I happen to use IBM DB2 as my database of choice > (or necessity) on a given server, I'll end up having to (re)build > packages like PHP from sources in order to configure --with-ibm-db2 or > somesuch. The RPM-based PHP distributions won't have been compiled with And your vendor doesn't provide such packages? I'd think for something as 'enterprise' as DB2 is there are base changes like this that IBM would provide the new based-on-RH RPMs. > What I'd like to see in RPMs for server packages is something like > dynamic compilation based on some checkboxes or command-line flags that > describe the options to autoconf. Essentially a higher-level interface > to ./configure, which could be used to build a custom installation of the Ick. Ouch. *spit* You don't mean at install time, do you? I mean, what's so bad about taking your SRPM and futzing your changes there? And you could always help out Fedora.us or Freshrpms.net to post updated RPMs as such (if you're not using RHEL).. For your case above I quite literally recommend taking it up w/ your vendor and asking them what they certify on. I'm sure there are other cases though.. Cheers, -Ali -- OpenPGP Key: 030E44E6 -- Was I helpful?: http://svcs.affero.net/rm.php?r=packetknife -- Ignorance must certainly be bliss or there wouldn't be so many people so resolutely pursuing it. -- Unknown -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: signature URL: From david.paeme at belbone.net Wed Jul 23 11:45:41 2003 From: david.paeme at belbone.net (david paeme) Date: 23 Jul 2003 13:45:41 +0200 Subject: my thoughts on package management In-Reply-To: <1058946721.1460.13.camel@localhost> References: <1058945056.3457.58.camel@owsdavid> <1058946721.1460.13.camel@localhost> Message-ID: <1058960741.3457.77.camel@owsdavid> On Wed, 2003-07-23 at 09:52, Andr?? Kelpe wrote: > Am Mit, 2003-07-23 um 09.24 schrieb david paeme: > > > > So why not use apt-like system (I'll call it apt from now on)? > > I know that there are probably a lot of arguments as why not to use it, > > but consider the advantages: > > or yum, which looks more stable to me. > well, I was just using apt because everybody knows that one ;-) (i presume) > > It might be possible to have an installation version that is only 1 cd. > > This can then only contain the basic system, window manager, and some > > basic applications (if a system like knoppix can do this...). It is then > > possible to use apt to get people to install applications, without > > having to download 3 cd's in a row. (even with a graphical frontend like > > Synaptic) > > Nice idea, it is like Debian, Gentoo or *BSD but i see a problem: There > are still a lot of modem and ISDN (in Germany) users out on the net. For > those people it is impossible to use apt/yum etc. to install big things > like KDE or GNOME. They still need CDs/DVDs to simple install packages > without waiting for weeks until all packages are downloaded. I think > there must be a distro which has more than one CD. > > regards Andr?? > > you're right about that, but why not go for a stable/testing/addon system, a bit like debian uses? I mean, you can take general packages, and create a distribution out of it (RedHat 10?), which contains everything that a working system needs, but still quite restricted: instead of a few different mail clients, let's just put evolution on the cd. if someone wants another one, let them install sylpheed without a hassle (apt or yum or ripm -- redhat internet package manager?? -- just kidding). or xmms as standard (with mp3, please...), and alsaplayer and stuff as extra's via apt? maybe even the basic system on one cd, with the repository snapshot on the other cd's? and let a utility like synaptic the take care of installing software from cd or some ftp? who knows... maybe the idea needs some more discussion, but I really think that an apt-like system is what redhat needs. it's the only thing that's really missing from the distro... From pekkas at netcore.fi Wed Jul 23 12:42:24 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 23 Jul 2003 15:42:24 +0300 (EEST) Subject: strange bug in ipv6 initscripts, ideas? Message-ID: Hi, When looking at a bug report in IPv6 initscripts: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86210 I came across a very strange bug. When a command is run from interactively, it works fine. When it's run via hotplug, it bugs under a very specific scenario: sometimes when we're redirecting stderr to stdin. The chain of commands is: /sbin/ifup eth1 /etc/sysconfig/network-scripts/ifup-ipv6 eth1 ipv6_add_addr_on_device eth1 fec0::2/64 [in /etc/sysconfig/network-scripts/network-functions-ipv6] ipv6_exec_ifconfig eth1 inet6 add fec0::2/64 LC_ALL=C /sbin/ifconfig eth1 inet6 add fec0::2/64 2>&1 The last fails, for some unknown reason with error code 1 and no output when run non-interactively; the code fragment in full is: ---8<--- ##### Wrapper for used binaries ## ifconfig # $*: # return code: result of execution ipv6_exec_ifconfig() { local options=$* LC_ALL=C /sbin/ifconfig $options 2>&1 return $? } ---8<--- One can work around the issue by removing "2>&1" (again, for whatever reason?!?). However, we really shouldn't change that code in the source, because some functions depend on that to eliminate error messages. I did a prototype change, and modified the relevant ipv6_add_addr_on_device:ipv6_exec_ifconfig function to use ipv6_exec_ip; a similar problem appeared (so, it doesn't seem to be specific to the application executed). Any ideas/thoughts? This seems so weird I'd like some pointers what could be wrong here.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From notting at redhat.com Wed Jul 23 15:44:18 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Jul 2003 11:44:18 -0400 Subject: strange bug in ipv6 initscripts, ideas? In-Reply-To: ; from pekkas@netcore.fi on Wed, Jul 23, 2003 at 03:42:24PM +0300 References: Message-ID: <20030723114418.F18078@devserv.devel.redhat.com> Pekka Savola (pekkas at netcore.fi) said: > Hi, > > When looking at a bug report in IPv6 initscripts: > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86210 > > I came across a very strange bug. When a command is run from > interactively, it works fine. When it's run via hotplug, it bugs under a > very specific scenario: sometimes when we're redirecting stderr to stdin. Hotplug runs with stdin/stdout/stderr to /dev/null, FWIW. Bill From notting at redhat.com Wed Jul 23 15:45:45 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Jul 2003 11:45:45 -0400 Subject: anonymous pserver access to rhlinux.redhat.com In-Reply-To: <20030723104657.GB7718@rap.rap.dk>; from keld@dkuug.dk on Wed, Jul 23, 2003 at 12:46:58PM +0200 References: <20030722233440.A10002@devserv.devel.redhat.com> <20030723104657.GB7718@rap.rap.dk> Message-ID: <20030723114545.G18078@devserv.devel.redhat.com> Keld J?rn Simonsen (keld at dkuug.dk) said: > On Tue, Jul 22, 2003 at 11:34:40PM -0400, Bill Nottingham wrote: > > Anonymous pserver access to rhlinux.redhat.com should be restored > > now. We apologize for the inconvenience. > > would you know about login pserver access to i18n.redhat.com ? pserver is anonymous only. Other accounts go through ssh. Bill From smoogen at lanl.gov Wed Jul 23 16:38:23 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 23 Jul 2003 10:38:23 -0600 Subject: Inclusion of cyrus-imapd and mimedefang Message-ID: <1058978302.10599.21.camel@smoogen1.lanl.gov> We are in the process of moving our IMAP servers from the redhat default to the cyrus-imapd as we have found them to be a bit more robust than WU. Currently we are using a set based off of Ivoca Linux but would like a 'blessed' version included into RHL at some point. Other than an RFE is there anything we can do to push this through? -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From hbo at egbok.com Wed Jul 23 17:09:29 2003 From: hbo at egbok.com (Howard Owen) Date: 23 Jul 2003 10:09:29 -0700 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <1058978302.10599.21.camel@smoogen1.lanl.gov> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> Message-ID: <1058980163.1280.207.camel@owen.egbok.com> I too missed Cyrus imap when I recently moved my home mail setup from Cyrus/Postfix/FreeBSD to Cyrus/Postfix/RH 7.3. However, you might consider that under the new regime, Red Hat will not be supporting the commodity OS in the same way as before. Therefore a Red Hat "blessing" on Cyrus imapd might mean they get someone at CMU to do the packaging. (I'm quite willing to be slapped down by someone at Red Hat on this. But that's the way I read the new direction.) You would essentially be no better off in that event than if you built from source and stayed current with CMU updates. I don't know if Cyrus imapd is in RHEL, but if it is, you might consider that option, particularly if support is an issue. The cost on a server isn't unreasonable for a critical infrastructure app like imap, IMHO. On Wed, 2003-07-23 at 09:38, Stephen Smoogen wrote: > We are in the process of moving our IMAP servers from the redhat default > to the cyrus-imapd as we have found them to be a bit more robust than > WU. Currently we are using a set based off of Ivoca Linux but would like > a 'blessed' version included into RHL at some point. > > Other than an RFE is there anything we can do to push this through? -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From matthias at rpmforge.net Wed Jul 23 17:13:06 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Wed, 23 Jul 2003 19:13:06 +0200 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <1058978302.10599.21.camel@smoogen1.lanl.gov> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> Message-ID: <20030723191306.11f8c493.matthias@rpmforge.net> Stephen Smoogen wrote : > We are in the process of moving our IMAP servers from the redhat default > to the cyrus-imapd as we have found them to be a bit more robust than > WU. Currently we are using a set based off of Ivoca Linux but would like > a 'blessed' version included into RHL at some point. > > Other than an RFE is there anything we can do to push this through? Do you know dovecot? It's to imap servers what vsftpd is to ftp servers ;-) I've put it into production not long ago with postfix, amavisd-new and clamav, all architectured around LDAP and Maildir boxes, it rocks! http://dovecot.procontrol.fi/ I'd prefer seeing this one go into RHL rather than Cyrus or Courier. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Raw Hide 20030722 running Linux kernel 2.4.20-20.1.2013.nptl Load : 0.48 0.56 0.55 From sopwith at redhat.com Wed Jul 23 17:16:10 2003 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 23 Jul 2003 13:16:10 -0400 (EDT) Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030723191306.11f8c493.matthias@rpmforge.net> Message-ID: On Wed, 23 Jul 2003, Matthias Saou wrote: > I'd prefer seeing this one go into RHL rather than Cyrus or Courier. It's already in. :) -- Elliot Humpty Dumpty was pushed. From kaboom at gatech.edu Wed Jul 23 17:18:28 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 23 Jul 2003 11:18:28 -0600 (MDT) Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: References: Message-ID: On Wed, 23 Jul 2003, Elliot Lee wrote: > On Wed, 23 Jul 2003, Matthias Saou wrote: > > > I'd prefer seeing this one go into RHL rather than Cyrus or Courier. > > It's already in. :) though there are, err, issues that need resolving on upgrades b/c of it later, chris From smoogen at lanl.gov Wed Jul 23 17:27:19 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 23 Jul 2003 11:27:19 -0600 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030723191306.11f8c493.matthias@rpmforge.net> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723191306.11f8c493.matthias@rpmforge.net> Message-ID: <1058981239.11609.0.camel@smoogen1.lanl.gov> I wasnt aware of it.. the lack of shared mailboxes is a bad point for it for us.. but I will see what it brings. On Wed, 2003-07-23 at 11:13, Matthias Saou wrote: > Stephen Smoogen wrote : > > > We are in the process of moving our IMAP servers from the redhat default > > to the cyrus-imapd as we have found them to be a bit more robust than > > WU. Currently we are using a set based off of Ivoca Linux but would like > > a 'blessed' version included into RHL at some point. > > > > Other than an RFE is there anything we can do to push this through? > > Do you know dovecot? It's to imap servers what vsftpd is to ftp servers ;-) > I've put it into production not long ago with postfix, amavisd-new and > clamav, all architectured around LDAP and Maildir boxes, it rocks! > > http://dovecot.procontrol.fi/ > > I'd prefer seeing this one go into RHL rather than Cyrus or Courier. > > Matthias -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From dax at gurulabs.com Wed Jul 23 17:34:32 2003 From: dax at gurulabs.com (Dax Kelson) Date: 23 Jul 2003 11:34:32 -0600 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: References: Message-ID: <1058981672.2678.42.camel@mentor.gurulabs.com> On Wed, 2003-07-23 at 11:18, Chris Ricker wrote: > On Wed, 23 Jul 2003, Elliot Lee wrote: > > > On Wed, 23 Jul 2003, Matthias Saou wrote: > > > > > I'd prefer seeing this one go into RHL rather than Cyrus or Courier. > > > > It's already in. :) > > though there are, err, issues that need resolving on upgrades b/c of it I've seen this claim twice now. What are the "issues"? BTW, if it supports Maildir++ sub-folders, I/we might start using it instead of courier-imap. How does dovecot compare to courier-imap in: * memory/cpu consumption * performance * featureset Dax Kelson Guru Labs From wcooley at nakedape.cc Wed Jul 23 17:35:18 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: 23 Jul 2003 10:35:18 -0700 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <1058978302.10599.21.camel@smoogen1.lanl.gov> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> Message-ID: <1058981717.6603.49.camel@localhost.localdomain> On Wed, 2003-07-23 at 09:38, Stephen Smoogen wrote: > We are in the process of moving our IMAP servers from the redhat default > to the cyrus-imapd as we have found them to be a bit more robust than > WU. Currently we are using a set based off of Ivoca Linux but would like > a 'blessed' version included into RHL at some point. > > Other than an RFE is there anything we can do to push this through? No one yet knows what the process will be, althrough there are no doubt plenty of us interested in seeing Cyrus supported in a more central way. I myself am using RPMs from Simon Matter, which are at http://home.teleport.ch/simix/ I've got binaries built on 7.3 which set some of the non-default options at http://ftp.nakedape.cc/nakedape/rh73/rpm/. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * Linux Services for Small Businesses * * * * * * * Easy, reliable solutions for small businesses * * Naked Ape Business Server http://nakedape.cc/r/sms * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From elanthis at awesomeplay.com Wed Jul 23 17:38:43 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: 23 Jul 2003 13:38:43 -0400 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030723191306.11f8c493.matthias@rpmforge.net> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723191306.11f8c493.matthias@rpmforge.net> Message-ID: <1058981923.25239.4.camel@smiddle.civic.twp.ypsilanti.mi.us> On Wed, 2003-07-23 at 13:13, Matthias Saou wrote: > Stephen Smoogen wrote : > > > We are in the process of moving our IMAP servers from the redhat default > > to the cyrus-imapd as we have found them to be a bit more robust than > > WU. Currently we are using a set based off of Ivoca Linux but would like > > a 'blessed' version included into RHL at some point. > > > > Other than an RFE is there anything we can do to push this through? > > Do you know dovecot? It's to imap servers what vsftpd is to ftp servers ;-) > I've put it into production not long ago with postfix, amavisd-new and > clamav, all architectured around LDAP and Maildir boxes, it rocks! > > http://dovecot.procontrol.fi/ > > I'd prefer seeing this one go into RHL rather than Cyrus or Courier. Aye, dovecot is a joy to work with. It's missing a few essential features, but if they are covered up, I can't imagine much reason to use another IMAP server for most uses. (Not sure how well dovecot scales to the hundred-thousand user limit.) Going with whichever IMAP server, tho, it might be nice to include a config tool for the mail server. Just the basic stuff, like local domains, standard unqualified domain, etc. Covering outgoing SMTP, and POP3/IMAP. Might help bump Debian offer my servers. ;-) > > Matthias -- Sean Middleditch AwesomePlay Productions, Inc. From wcooley at nakedape.cc Wed Jul 23 17:51:04 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: 23 Jul 2003 10:51:04 -0700 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030723191306.11f8c493.matthias@rpmforge.net> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723191306.11f8c493.matthias@rpmforge.net> Message-ID: <1058982663.6603.66.camel@localhost.localdomain> On Wed, 2003-07-23 at 10:13, Matthias Saou wrote: > Do you know dovecot? It's to imap servers what vsftpd is to ftp servers ;-) > I've put it into production not long ago with postfix, amavisd-new and > clamav, all architectured around LDAP and Maildir boxes, it rocks! > > http://dovecot.procontrol.fi/ > > I'd prefer seeing this one go into RHL rather than Cyrus or Courier. I'd prefer to see both. Many of us already have substantial investments in Cyrus installations ("investments" being expertise using it and having installations where migration would be non-trivial). However, Dovecot is very appealing and would fit a different problem domain than Cyrus. Dovecot, from what I can tell, should be mailbox compatible with UW-IMAP, which Cyrus definitely isn't, so upgrading a small site to Dovecot should be easy. On other hand, Cyrus has a number of advantages, especially for large sites: o Multiple partitions to accomodate growth and performance tuning. o Clustering with Murder. o Squatter back-end indexes, which make mailbox searches very fast. o Skiplist databases, which are fast. o LMTP delivery (don't need to run an MTA on the IMAP server). o Single-instance store. o Virtual domains. o Sieve filtering (less flexible but considerably faster than procmail). And finally: o Fairly long term commitment by a stable organization. o Mature, widely-used and tested codebase. The last two aren't meant to be slams on Dovecot; it's development structure is unknown to me, but these I do know about Cyrus. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * Linux Services for Small Businesses * * * * * * * Easy, reliable solutions for small businesses * * Naked Ape Business Server http://nakedape.cc/r/sms * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kaboom at gatech.edu Wed Jul 23 17:58:55 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 23 Jul 2003 11:58:55 -0600 (MDT) Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <1058981672.2678.42.camel@mentor.gurulabs.com> References: <1058981672.2678.42.camel@mentor.gurulabs.com> Message-ID: On Wed, 23 Jul 2003, Dax Kelson wrote: > > though there are, err, issues that need resolving on upgrades b/c of it > > I've seen this claim twice now. > > What are the "issues"? Prior to this point, RHL has only shipped uw-imap. If you upgrade a server using uw-imap, last I looked: * both dovecot (Sys V init) and uw-imap (xinetd) were enabled, so you get converted to dovecot whether you wanted or not * clients have to be configured differently for uw and for dovecot, so after the upgrade, you have to reconfigure all the clients (and then again if you downgrade) I've not bugzilla'd it yet b/c I've not had time to do a systematic look, but at some point I will > How does dovecot compare to courier-imap in: > > * memory/cpu consumption > * performance > * featureset It's much better than courier in featureset, since it actually supports mbox. Performance / memory / cpu it's better than uw (but what isn't? ;-). I can't say about courier b/c it's maildirs and, for lots of reasons, I'm not. later, chris From hbo at egbok.com Wed Jul 23 18:01:02 2003 From: hbo at egbok.com (Howard Owen) Date: 23 Jul 2003 11:01:02 -0700 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <1058981717.6603.49.camel@localhost.localdomain> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <1058981717.6603.49.camel@localhost.localdomain> Message-ID: <1058983261.1280.234.camel@owen.egbok.com> Building cyrus imapd from source isn't all that bad. But you also need sasl2. For my RH 7.3 setup I installed cyrus-sasl-2.1.13 with a simple ./configure;make;make install. For cyrus-imapd-2.1.12, it was ./configure --with-krb=no --with-auth=unix;make;make install You then have to create /etc/sasldb2 and add at least one user/password with saslpasswd2. Finally, chown cyrus /etc/sasldb2. Set your saslauth scheme in /etc/imapd.conf and your authentication is set. On Wed, 2003-07-23 at 10:35, Wil Cooley wrote: > On Wed, 2003-07-23 at 09:38, Stephen Smoogen wrote: > > We are in the process of moving our IMAP servers from the redhat default > > to the cyrus-imapd as we have found them to be a bit more robust than > > WU. Currently we are using a set based off of Ivoca Linux but would like > > a 'blessed' version included into RHL at some point. > > > > Other than an RFE is there anything we can do to push this through? > > No one yet knows what the process will be, althrough there are no doubt > plenty of us interested in seeing Cyrus supported in a more central way. > > I myself am using RPMs from Simon Matter, which are at > http://home.teleport.ch/simix/ > > I've got binaries built on 7.3 which set some of the non-default options > at http://ftp.nakedape.cc/nakedape/rh73/rpm/. > > Wil -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From wcooley at nakedape.cc Wed Jul 23 18:20:05 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: 23 Jul 2003 11:20:05 -0700 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <1058983261.1280.234.camel@owen.egbok.com> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <1058981717.6603.49.camel@localhost.localdomain> <1058983261.1280.234.camel@owen.egbok.com> Message-ID: <1058984404.6603.76.camel@localhost.localdomain> On Wed, 2003-07-23 at 11:01, Howard Owen wrote: > Building cyrus imapd from source isn't all that bad. But > you also need sasl2. For my RH 7.3 setup I installed cyrus-sasl-2.1.13 > with a simple ./configure;make;make install. For cyrus-imapd-2.1.12, it > was ./configure --with-krb=no --with-auth=unix;make;make install No, it's not, but I have several installations, so I prefer that they be reproducible. I also just used the back-ported cyrus-sasl2 packages. > You then have to create /etc/sasldb2 and add at least one user/password > with saslpasswd2. Finally, chown cyrus /etc/sasldb2. Set your saslauth > scheme in /etc/imapd.conf and your authentication is set. You don't need sasldb2 if you're not actually using it. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * Linux Services for Small Businesses * * * * * * * Easy, reliable solutions for small businesses * * Naked Ape Business Server http://nakedape.cc/r/sms * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bullleo2003 at yahoo.com Wed Jul 23 18:25:46 2003 From: bullleo2003 at yahoo.com (De Yu Liu) Date: Wed, 23 Jul 2003 11:25:46 -0700 (PDT) Subject: A question about /linux/driver/net/e100 Message-ID: <20030723182546.95828.qmail@web14707.mail.yahoo.com> Greeting all: In /linux/driver/net/e100 directory of RH 9, there are several files like e100_config.c, e100_eeprom.c, e100_main.c, e100_phy.c, e100_proc.c, e100_test.c and etc. What's is the relationship between them? Please draw me a picture like flow chart? Thanks in advance. Deyu --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzj at redhat.com Wed Jul 23 18:32:25 2003 From: katzj at redhat.com (Jeremy Katz) Date: 23 Jul 2003 14:32:25 -0400 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: References: <1058981672.2678.42.camel@mentor.gurulabs.com> Message-ID: <1058985144.28014.3.camel@mirkwood.devel.redhat.com> On Wed, 2003-07-23 at 13:58, Chris Ricker wrote: > On Wed, 23 Jul 2003, Dax Kelson wrote: > * both dovecot (Sys V init) and uw-imap (xinetd) were enabled, so you get > converted to dovecot whether you wanted or not dovecot doesn't start by default any more (that was a bug :) > * clients have to be configured differently for uw and for dovecot, so after > the upgrade, you have to reconfigure all the clients (and then again if you > downgrade) If you've overriden client defaults, yes. The subscription file is annoying -- there's a simple way to have dovecot do that migration the first time, though and it's easy enough to throw in. I'm still hoping Timo will make it a zero work thing soon, though ;-) > > How does dovecot compare to courier-imap in: > > > > * memory/cpu consumption > > * performance > > * featureset > > It's much better than courier in featureset, since it actually supports > mbox. Performance / memory / cpu it's better than uw (but what isn't? ;-). > I can't say about courier b/c it's maildirs and, for lots of reasons, I'm > not. Seems better in performance/memory than Courier for me with my lots of mail. And oodles better than uw imap. Jeremy From matthias at rpmforge.net Wed Jul 23 18:45:37 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Wed, 23 Jul 2003 20:45:37 +0200 Subject: Installing a mail server, including dovecot (was: Re: Inclusion of cyrus-imapd...) In-Reply-To: <20030723191306.11f8c493.matthias@rpmforge.net> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723191306.11f8c493.matthias@rpmforge.net> Message-ID: <20030723204537.3ab7c735.matthias@rpmforge.net> BTW, Worth mentioning maybe. I've just finished the very first version of a document which explains all the configuring I had to go through to get a working assembly of : - Postfix 2 - Dovecot - Spamassassin - AMaViSd-new - Clamav - OpenLDAP It is for RHL 7.3 and links only to 7.3 packages, but installing on 9 or Severn shouldn't be very hard, and the same config changes will apply. http://freshrpms.net/docs/mail-server/ And as a goody, there's even a screenshot ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Raw Hide 20030722 running Linux kernel 2.4.20-20.1.2013.nptl Load : 0.01 0.12 0.28 From scottb at bxwa.com Wed Jul 23 18:47:40 2003 From: scottb at bxwa.com (Scott Becker) Date: Wed, 23 Jul 2003 11:47:40 -0700 Subject: Is linux a plug and play OS? Message-ID: <3F1ED84C.5010207@bxwa.com> Several times I've had difficultys bringing up eth0 after an OS install and found that setting "Plug and play OS" to "no" in the bios setup would cause Kudzu to find the nic and everything worked. This helped with 3 diffenent nics, including a 3c905c with rh9 and a sound card. Is far as I can tell the bios was assigning an IRQ and/or IO address after I made the change so that the device was ready for linux (kudzu) to use. Does linux normally handle this or does the bios need to set this way normally? Scott Becker From elanthis at awesomeplay.com Wed Jul 23 18:58:30 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: 23 Jul 2003 14:58:30 -0400 Subject: Is linux a plug and play OS? In-Reply-To: <3F1ED84C.5010207@bxwa.com> References: <3F1ED84C.5010207@bxwa.com> Message-ID: <1058986710.25573.21.camel@smiddle.civic.twp.ypsilanti.mi.us> On Wed, 2003-07-23 at 14:47, Scott Becker wrote: > Several times I've had difficultys bringing up eth0 after an OS install > and found that setting "Plug and play OS" to "no" in the bios setup > would cause Kudzu to find the nic and everything worked. This helped > with 3 diffenent nics, including a 3c905c with rh9 and a sound card. > > Is far as I can tell the bios was assigning an IRQ and/or IO address > after I made the change so that the device was ready for linux (kudzu) > to use. Does linux normally handle this or does the bios need to set > this way normally? This is normal behaviour; currently, Linux is not Plug-n-Play compatible in a couple ways. I'm not sure on the technical details. Iirc, Linux kernel 2.6 should be fully Plug-n-Play compatible, and can have the PnP BIOS option set. Note this doesn't mean Linux can't be "plug and play" now, only that the specific Plug-n-Play BIOS features don't work quite right. > Scott Becker > > > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From rjl at renaissoft.com Wed Jul 23 19:20:38 2003 From: rjl at renaissoft.com (Robert LeBlanc) Date: Wed, 23 Jul 2003 12:20:38 -0700 Subject: my thoughts on package management In-Reply-To: <200307230515.13765.ali@packetknife.com> References: <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> Message-ID: <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> At 02:14 2003/07/23, Ali-Reza Anghaie wrote: >On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote: > > > As a case in point, if I happen to use IBM DB2 as my database of choice > > (or necessity) on a given server, I'll end up having to (re)build > > packages like PHP from sources in order to configure --with-ibm-db2 or > > somesuch. The RPM-based PHP distributions won't have been compiled with > >And your vendor doesn't provide such packages? I'd think for something as >'enterprise' as DB2 is there are base changes like this that IBM would >provide the new based-on-RH RPMs. It's not entirely fair (or effective) to try to pin this issue on the vendors, expecting them to solve every conceivable incompatibility issue. In this example I singled out IBM DB2, but the same problem applies to many other packages, whether they're closed-source or not. If I download a MySQL (or PHP, or Apache, or...) binary distribution, I have no guarantee that it has all the necessary options compiled into it for my specific needs. The problem at the root of all this is that if I ever need to rebuild anything from sources, I break the auto-update chain for that package. The fact that I've applied a (developer-defined) customization effectively means I can no longer have security updates and bug-fixes applied without doing them by hand. What I'd rather see is a system flexible enough to detect (e.g. by reading the equivalent of a config.status file) the configuration options that were used to build a package in the first place, and then applying these to updated sources--*or*--have it search for a binary distribution that was compiled with those specific options enabled. The latter may in the end be the more feasible option for RH. Essentially have the RPM information itself keep track of what options were used to compile the package, so that people who need a set of binaries compiled with options X, Y, and J can search on this basis, and make this a requirement for any auto-updates. Robert LeBlanc From pauln at truemesh.com Wed Jul 23 19:21:21 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 23 Jul 2003 20:21:21 +0100 Subject: people.redhat.com index Message-ID: <20030723192120.GC28315@raq465.uk2net.com> Seeing as we're being wonderfully open, any chance the wonderfull index page at people.redhat.com could be removed so there is the directory index instead. Not to worry if not. Cheers Paul From notting at redhat.com Wed Jul 23 19:35:41 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Jul 2003 15:35:41 -0400 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <1058978302.10599.21.camel@smoogen1.lanl.gov>; from smoogen@lanl.gov on Wed, Jul 23, 2003 at 10:38:23AM -0600 References: <1058978302.10599.21.camel@smoogen1.lanl.gov> Message-ID: <20030723153541.G19044@devserv.devel.redhat.com> Stephen Smoogen (smoogen at lanl.gov) said: > We are in the process of moving our IMAP servers from the redhat default > to the cyrus-imapd as we have found them to be a bit more robust than > WU. Currently we are using a set based off of Ivoca Linux but would like > a 'blessed' version included into RHL at some point. > > Other than an RFE is there anything we can do to push this through? We're actually considering for this upcoming release: - adding in cyrus-imap - taking out uw-imap Opinions? Bill From notting at redhat.com Wed Jul 23 19:37:32 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 23 Jul 2003 15:37:32 -0400 Subject: Is linux a plug and play OS? In-Reply-To: <3F1ED84C.5010207@bxwa.com>; from scottb@bxwa.com on Wed, Jul 23, 2003 at 11:47:40AM -0700 References: <3F1ED84C.5010207@bxwa.com> Message-ID: <20030723153732.H19044@devserv.devel.redhat.com> Scott Becker (scottb at bxwa.com) said: > Several times I've had difficultys bringing up eth0 after an OS install > and found that setting "Plug and play OS" to "no" in the bios setup > would cause Kudzu to find the nic and everything worked. This helped > with 3 diffenent nics, including a 3c905c with rh9 and a sound card. Is this with Severn or 9? There was some unneeded code removed after 9 shipped that would cause this. > Is far as I can tell the bios was assigning an IRQ and/or IO address > after I made the change so that the device was ready for linux (kudzu) > to use. Does linux normally handle this or does the bios need to set > this way normally? Resources are assigned when pci_enable_device() (or whatever the kernel function is, I forget) is called, if they aren't set before. Bill From tcallawa at redhat.com Wed Jul 23 19:39:37 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: 23 Jul 2003 14:39:37 -0500 Subject: cipe In-Reply-To: References: <20030722014002.GD22711@redhat.com> Message-ID: <1058989176.3288.60.camel@zorak> Moving this to the appropriate list: On Mon, 2003-07-21 at 23:27, Chris Ricker wrote: > With cipe-1.5.4, if you do > > ./configure --enable-protocol=3 (or just ./configure) > > you get the exact same protocol in 1.5 that you get in 1.4. That > interoperates with the cipe-1.4.x stuff RH ships currently > > If you do > > ./configure --enable-protocol=4 > > you get the new protocol with all the new features. That doesn't > interoperate. Its a little more complicated than that in implementation. Specifically, the following is true: Cipe 1.5.4 has two different crypto algorithms (Blowfish and IDEA). They are mutually exclusive in the code. In addition, the two protocol types (3 and 4) are mutually exclusive in the code. This means, to add it to the Red Hat Linux kernel as is, there would need to be 4 directories with virtually identical code, simply to account for all 4 possible modules. Headers cannot be shared in current state. In order to clean this up (one source tree generates 4 modules in full build mode), the code would need a fairly massive rewrite (IMHO). I came across all of this while dealing with Aurora. The big question is: how does the RH kernel team feel about adding four new directories to drivers/addon: cipe3-bf/ cipe3-idea/ cipe4-bf/ cipe4-idea/ If they don't have a problem with doing that (I was planning on encapsulating them within a single "cipe" directory), the patches I'm doing for Aurora should work with RHL. ~spot --- Tom "spot" Callaway SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260 The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me. "Immature poets borrow, mature poets steal." --- T. S. Eliot From matthias at rpmforge.net Wed Jul 23 19:46:58 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Wed, 23 Jul 2003 21:46:58 +0200 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030723153541.G19044@devserv.devel.redhat.com> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723153541.G19044@devserv.devel.redhat.com> Message-ID: <20030723214658.07d466b0.matthias@rpmforge.net> Bill Nottingham wrote : > We're actually considering for this upcoming release: > > - adding in cyrus-imap > - taking out uw-imap Well, I'll miss wu-imap just about as much as I miss wu-ftpd :-) So as long as dovecot, which is now my fav', stays... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Raw Hide 20030722 running Linux kernel 2.4.20-20.1.2013.nptl Load : 0.31 0.19 0.25 From wcooley at nakedape.cc Wed Jul 23 19:49:21 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: 23 Jul 2003 12:49:21 -0700 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030723153541.G19044@devserv.devel.redhat.com> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723153541.G19044@devserv.devel.redhat.com> Message-ID: <1058989761.6603.96.camel@localhost.localdomain> On Wed, 2003-07-23 at 12:35, Bill Nottingham wrote: > We're actually considering for this upcoming release: > > - adding in cyrus-imap > - taking out uw-imap > > Opinions? +1 Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Tired of spam and viruses in your e-mail? Get the * * Naked Ape Mail Defender! http://nakedape.cc/r/maildefender * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jbj at redhat.com Wed Jul 23 19:58:35 2003 From: jbj at redhat.com (Jeff Johnson) Date: Wed, 23 Jul 2003 15:58:35 -0400 Subject: my thoughts on package management In-Reply-To: <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1>; from rjl@renaissoft.com on Wed, Jul 23, 2003 at 12:20:38PM -0700 References: <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <200307230515.13765.ali@packetknife.com> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> Message-ID: <20030723155835.N18401@devserv.devel.redhat.com> On Wed, Jul 23, 2003 at 12:20:38PM -0700, Robert LeBlanc wrote: > At 02:14 2003/07/23, Ali-Reza Anghaie wrote: > >On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote: > > > > > As a case in point, if I happen to use IBM DB2 as my database of choice > > > (or necessity) on a given server, I'll end up having to (re)build > > > packages like PHP from sources in order to configure --with-ibm-db2 or > > > somesuch. The RPM-based PHP distributions won't have been compiled with > > > >And your vendor doesn't provide such packages? I'd think for something as > >'enterprise' as DB2 is there are base changes like this that IBM would > >provide the new based-on-RH RPMs. > > It's not entirely fair (or effective) to try to pin this issue on the > vendors, expecting them to solve every conceivable incompatibility > issue. In this example I singled out IBM DB2, but the same problem applies > to many other packages, whether they're closed-source or not. If I > download a MySQL (or PHP, or Apache, or...) binary distribution, I have no > guarantee that it has all the necessary options compiled into it for my > specific needs. > > The problem at the root of all this is that if I ever need to rebuild > anything from sources, I break the auto-update chain for that package. The > fact that I've applied a (developer-defined) customization effectively > means I can no longer have security updates and bug-fixes applied without > doing them by hand. What I'd rather see is a system flexible enough to > detect (e.g. by reading the equivalent of a config.status file) the > configuration options that were used to build a package in the first place, > and then applying these to updated sources--*or*--have it search for a > binary distribution that was compiled with those specific options enabled. > > The latter may in the end be the more feasible option for RH. Essentially > have the RPM information itself keep track of what options were used to > compile the package, so that people who need a set of binaries compiled > with options X, Y, and J can search on this basis, and make this a > requirement for any auto-updates. There are two problems here: 1) how the build system is set up. 2) how the package was built. The build system for RHL is setup by using build dependencies for all but a handful of packages like gcc and make. How the package was built is encoded in the spec file, and rpm by design guarantees that each and every rpm started from a spec file, virgin sources, etc and ran to completion in some build system. Yes there is no explicit config.status, basically because there is no need if you are using RHL packages, or custom modifications of RHL packages, or simple additions to RHL distros. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From tcallawa at redhat.com Wed Jul 23 20:21:31 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: 23 Jul 2003 15:21:31 -0500 Subject: cipe In-Reply-To: <1058989176.3288.60.camel@zorak> References: <20030722014002.GD22711@redhat.com> <1058989176.3288.60.camel@zorak> Message-ID: <1058991690.3288.72.camel@zorak> On Wed, 2003-07-23 at 14:39, Tom 'spot' Callaway wrote: > Cipe 1.5.4 has two different crypto algorithms (Blowfish and IDEA). They > are mutually exclusive in the code. In addition, the two protocol types > (3 and 4) are mutually exclusive in the code. > > This means, to add it to the Red Hat Linux kernel as is, there would > need to be 4 directories with virtually identical code, simply to > account for all 4 possible modules. Headers cannot be shared in current > state. Addendum: The cipe code also assumes that the userspace tools/daemon are built at the same time as the kernel modules. As such, it generates a "VERSION" string, which the userspace compares against the kernel module. If they don't match, it bails out. ~spot --- Tom "spot" Callaway SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260 The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me. "Immature poets borrow, mature poets steal." --- T. S. Eliot From smoogen at lanl.gov Wed Jul 23 20:30:45 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 23 Jul 2003 14:30:45 -0600 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030723153541.G19044@devserv.devel.redhat.com> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723153541.G19044@devserv.devel.redhat.com> Message-ID: <1058992245.11609.5.camel@smoogen1.lanl.gov> My opinion is clearly.. add cyrus-imap and remove uw-imap. On Wed, 2003-07-23 at 13:35, Bill Nottingham wrote: > Stephen Smoogen (smoogen at lanl.gov) said: > > We are in the process of moving our IMAP servers from the redhat default > > to the cyrus-imapd as we have found them to be a bit more robust than > > WU. Currently we are using a set based off of Ivoca Linux but would like > > a 'blessed' version included into RHL at some point. > > > > Other than an RFE is there anything we can do to push this through? > > We're actually considering for this upcoming release: > > - adding in cyrus-imap > - taking out uw-imap > > Opinions? > > Bill > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From smoogen at lanl.gov Wed Jul 23 20:31:46 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 23 Jul 2003 14:31:46 -0600 Subject: people.redhat.com index In-Reply-To: <20030723192120.GC28315@raq465.uk2net.com> References: <20030723192120.GC28315@raq465.uk2net.com> Message-ID: <1058992306.11609.7.camel@smoogen1.lanl.gov> Well there might be pages on there are engineers who might have a fix for a particular customer only. On Wed, 2003-07-23 at 13:21, Paul Nasrat wrote: > Seeing as we're being wonderfully open, any chance the wonderfull index > page at people.redhat.com could be removed so there is the directory > index instead. Not to worry if not. > > Cheers > > Paul > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From skvidal at phy.duke.edu Wed Jul 23 20:33:35 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 23 Jul 2003 16:33:35 -0400 Subject: people.redhat.com index In-Reply-To: <1058992306.11609.7.camel@smoogen1.lanl.gov> References: <20030723192120.GC28315@raq465.uk2net.com> <1058992306.11609.7.camel@smoogen1.lanl.gov> Message-ID: <1058992415.4157.223.camel@binkley> On Wed, 2003-07-23 at 16:31, Stephen Smoogen wrote: > Well there might be pages on there are engineers who might have a fix > for a particular customer only. > Shouldn't that be htauth protected then? -sv From pauln at truemesh.com Wed Jul 23 20:32:47 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 23 Jul 2003 21:32:47 +0100 Subject: people.redhat.com index In-Reply-To: <1058992306.11609.7.camel@smoogen1.lanl.gov> References: <20030723192120.GC28315@raq465.uk2net.com> <1058992306.11609.7.camel@smoogen1.lanl.gov> Message-ID: <20030723203247.GD28315@raq465.uk2net.com> On Wed, Jul 23, 2003 at 02:31:46PM -0600, Stephen Smoogen wrote: > Well there might be pages on there are engineers who might have a fix > for a particular customer only. True, there is nothing stopping (as many people did have) a index.html in a person's dir to stop casual browsing. Paul From smoogen at lanl.gov Wed Jul 23 20:43:17 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 23 Jul 2003 14:43:17 -0600 Subject: people.redhat.com index In-Reply-To: <1058992306.11609.7.camel@smoogen1.lanl.gov> References: <20030723192120.GC28315@raq465.uk2net.com> <1058992306.11609.7.camel@smoogen1.lanl.gov> Message-ID: <1058992997.11609.10.camel@smoogen1.lanl.gov> I should also put it that this was in the past sort of a benefit for employees where they could put up family albums and such. It is also a place where many non-engineers have accounts etc. On Wed, 2003-07-23 at 14:31, Stephen Smoogen wrote: > Well there might be pages on there are engineers who might have a fix > for a particular customer only. > > On Wed, 2003-07-23 at 13:21, Paul Nasrat wrote: > > Seeing as we're being wonderfully open, any chance the wonderfull index > > page at people.redhat.com could be removed so there is the directory > > index instead. Not to worry if not. > > > > Cheers > > > > Paul > > > > > > -- > > Rhl-devel-list mailing list > > Rhl-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From hbo at egbok.com Wed Jul 23 20:43:40 2003 From: hbo at egbok.com (Howard Owen) Date: 23 Jul 2003 13:43:40 -0700 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <1058992245.11609.5.camel@smoogen1.lanl.gov> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723153541.G19044@devserv.devel.redhat.com> <1058992245.11609.5.camel@smoogen1.lanl.gov> Message-ID: <1058993018.1280.266.camel@owen.egbok.com> hbo shoots up his hand. "Me too," he says. On Wed, 2003-07-23 at 13:30, Stephen Smoogen wrote: > My opinion is clearly.. add cyrus-imap and remove uw-imap. > > On Wed, 2003-07-23 at 13:35, Bill Nottingham wrote: > > Stephen Smoogen (smoogen at lanl.gov) said: > > > We are in the process of moving our IMAP servers from the redhat default > > > to the cyrus-imapd as we have found them to be a bit more robust than > > > WU. Currently we are using a set based off of Ivoca Linux but would like > > > a 'blessed' version included into RHL at some point. > > > > > > Other than an RFE is there anything we can do to push this through? > > > > We're actually considering for this upcoming release: > > > > - adding in cyrus-imap > > - taking out uw-imap > > > > Opinions? > > > > Bill > > > > > > -- > > Rhl-devel-list mailing list > > Rhl-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From hbo at egbok.com Wed Jul 23 20:46:52 2003 From: hbo at egbok.com (Howard Owen) Date: 23 Jul 2003 13:46:52 -0700 Subject: people.redhat.com index In-Reply-To: <20030723203247.GD28315@raq465.uk2net.com> References: <20030723192120.GC28315@raq465.uk2net.com> <1058992306.11609.7.camel@smoogen1.lanl.gov> <20030723203247.GD28315@raq465.uk2net.com> Message-ID: <1058993212.1280.270.camel@owen.egbok.com> You have to rely on everyone there Doing the Right Thing. I know they have lots of smart folks working at Red Hat, but in my experience as a sysadmin, even brilliant folks make mistakes on occasion. Still, having wider access to internal Red Hat resources has my vote. On Wed, 2003-07-23 at 13:32, Paul Nasrat wrote: > On Wed, Jul 23, 2003 at 02:31:46PM -0600, Stephen Smoogen wrote: > > Well there might be pages on there are engineers who might have a fix > > for a particular customer only. > > True, there is nothing stopping (as many people did have) a index.html > in a person's dir to stop casual browsing. > > Paul > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From scottb at bxwa.com Wed Jul 23 20:59:27 2003 From: scottb at bxwa.com (Scott Becker) Date: Wed, 23 Jul 2003 13:59:27 -0700 Subject: Is linux a plug and play OS? In-Reply-To: <20030723153732.H19044@devserv.devel.redhat.com> References: <3F1ED84C.5010207@bxwa.com> <20030723153732.H19044@devserv.devel.redhat.com> Message-ID: <3F1EF72F.8050304@bxwa.com> This was with 8 and 9, I just joined this list (After finding out about RHL Project). I think I'll download Severn and test it out. I had an issue with 9 with the dvorak keyboard layout, I'll see if it still appears and track it down. Scott Becker Bill Nottingham wrote: >Scott Becker (scottb at bxwa.com) said: > > >>Several times I've had difficultys bringing up eth0 after an OS install >>and found that setting "Plug and play OS" to "no" in the bios setup >>would cause Kudzu to find the nic and everything worked. This helped >>with 3 diffenent nics, including a 3c905c with rh9 and a sound card. >> >> > >Is this with Severn or 9? There was some unneeded code removed after >9 shipped that would cause this. > > > >>Is far as I can tell the bios was assigning an IRQ and/or IO address >>after I made the change so that the device was ready for linux (kudzu) >>to use. Does linux normally handle this or does the bios need to set >>this way normally? >> >> > >Resources are assigned when pci_enable_device() (or whatever the kernel >function is, I forget) is called, if they aren't set before. > >Bill > > >-- >Rhl-devel-list mailing list >Rhl-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/rhl-devel-list > > From scottb at bxwa.com Wed Jul 23 21:02:20 2003 From: scottb at bxwa.com (Scott Becker) Date: Wed, 23 Jul 2003 14:02:20 -0700 Subject: Is linux a plug and play OS? In-Reply-To: <20030723153732.H19044@devserv.devel.redhat.com> References: <3F1ED84C.5010207@bxwa.com> <20030723153732.H19044@devserv.devel.redhat.com> Message-ID: <3F1EF7DC.3080003@bxwa.com> So it is abnormal to have to tell the bios the OS is stupid. That's good to know. I'll try to reproduce it if it can with Severn and test it. scottb Bill Nottingham wrote: >Scott Becker (scottb at bxwa.com) said: > > >>Several times I've had difficultys bringing up eth0 after an OS install >>and found that setting "Plug and play OS" to "no" in the bios setup >>would cause Kudzu to find the nic and everything worked. This helped >>with 3 diffenent nics, including a 3c905c with rh9 and a sound card. >> >> > >Is this with Severn or 9? There was some unneeded code removed after >9 shipped that would cause this. > > > >>Is far as I can tell the bios was assigning an IRQ and/or IO address >>after I made the change so that the device was ready for linux (kudzu) >>to use. Does linux normally handle this or does the bios need to set >>this way normally? >> >> > >Resources are assigned when pci_enable_device() (or whatever the kernel >function is, I forget) is called, if they aren't set before. > >Bill > > >-- >Rhl-devel-list mailing list >Rhl-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/rhl-devel-list > > From hbo at egbok.com Wed Jul 23 21:38:46 2003 From: hbo at egbok.com (Howard Owen) Date: 23 Jul 2003 14:38:46 -0700 Subject: people.redhat.com index In-Reply-To: <1058993212.1280.270.camel@owen.egbok.com> References: <20030723192120.GC28315@raq465.uk2net.com> <1058992306.11609.7.camel@smoogen1.lanl.gov> <20030723203247.GD28315@raq465.uk2net.com> <1058993212.1280.270.camel@owen.egbok.com> Message-ID: <1058996325.1280.276.camel@owen.egbok.com> So, perhaps only selected directories on people.redhat.com could be opened up and/or linked from the main index. Those individuals could get a check up by IT to make sure they had the tools and knowledge to run an exposed website at a high-profile company reasonably securely. Yeah, I know, it's not as if IT doesn't have enough to do already. 8) On Wed, 2003-07-23 at 13:46, Howard Owen wrote: > You have to rely on everyone there Doing the Right Thing. I know > they have lots of smart folks working at Red Hat, but in my experience > as a sysadmin, even brilliant folks make mistakes on occasion. > > Still, having wider access to internal Red Hat resources has my vote. > > On Wed, 2003-07-23 at 13:32, Paul Nasrat wrote: > > On Wed, Jul 23, 2003 at 02:31:46PM -0600, Stephen Smoogen wrote: > > > Well there might be pages on there are engineers who might have a fix > > > for a particular customer only. > > > > True, there is nothing stopping (as many people did have) a index.html > > in a person's dir to stop casual browsing. > > > > Paul > > > > > > -- > > Rhl-devel-list mailing list > > Rhl-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From smoogen at lanl.gov Wed Jul 23 21:40:40 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 23 Jul 2003 15:40:40 -0600 Subject: Diskless workstations Message-ID: <1058996440.11609.24.camel@smoogen1.lanl.gov> Hi one thing that has come up over and over again (here) is that Debian is easier to install into a diskless workstation environment than Red Hat. I being the RH bigot that I am have not tried this yet, but I get the feeling that it is. I would really like to see some work on making a Heavy Diskless Workstation install possible in the future. [Heavy Diskless means boxes that have say 1-2 gigs of Ram, big CPUs, and 100 mbps network at least.] THere are many environments that use this heavy duty, and right now I am having to admin 4 different ways of killing the problem with no one absolutely correct. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From lance at uklinux.net Wed Jul 23 21:44:08 2003 From: lance at uklinux.net (Lance Davis) Date: Wed, 23 Jul 2003 22:44:08 +0100 (BST) Subject: people.redhat.com index In-Reply-To: <1058996325.1280.276.camel@owen.egbok.com> Message-ID: On 23 Jul 2003, Howard Owen wrote: > So, perhaps only selected directories on people.redhat.com could be > opened up and/or linked from the main index. Those individuals could > get a check up by IT to make sure they had the tools and knowledge to > run an exposed website at a high-profile company reasonably securely. > > Yeah, I know, it's not as if IT doesn't have enough to do already. 8) Why not set up a simple database that the people with stuff behind people.redhat.com can add their link to if they want (or get told to ... ), that then gets displayed on the front page as a link to their index page ?? Lance -- uklinux.net - The ISP of choice for the discerning Linux user. From smoogen at lanl.gov Wed Jul 23 21:44:16 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 23 Jul 2003 15:44:16 -0600 Subject: people.redhat.com index In-Reply-To: <1058996325.1280.276.camel@owen.egbok.com> References: <20030723192120.GC28315@raq465.uk2net.com> <1058992306.11609.7.camel@smoogen1.lanl.gov> <20030723203247.GD28315@raq465.uk2net.com> <1058993212.1280.270.camel@owen.egbok.com> <1058996325.1280.276.camel@owen.egbok.com> Message-ID: <1058996655.11609.28.camel@smoogen1.lanl.gov> Red Hat's IT has always been lean and tight (ie no f*ing way). I would say it would be better for the developers to just put it in their .sigs and if you see something interesting go from there. On Wed, 2003-07-23 at 15:38, Howard Owen wrote: > So, perhaps only selected directories on people.redhat.com could be > opened up and/or linked from the main index. Those individuals could > get a check up by IT to make sure they had the tools and knowledge to > run an exposed website at a high-profile company reasonably securely. > > Yeah, I know, it's not as if IT doesn't have enough to do already. 8) > > On Wed, 2003-07-23 at 13:46, Howard Owen wrote: > > You have to rely on everyone there Doing the Right Thing. I know > > they have lots of smart folks working at Red Hat, but in my experience > > as a sysadmin, even brilliant folks make mistakes on occasion. > > > > Still, having wider access to internal Red Hat resources has my vote. > > > > On Wed, 2003-07-23 at 13:32, Paul Nasrat wrote: > > > On Wed, Jul 23, 2003 at 02:31:46PM -0600, Stephen Smoogen wrote: > > > > Well there might be pages on there are engineers who might have a fix > > > > for a particular customer only. > > > > > > True, there is nothing stopping (as many people did have) a index.html > > > in a person's dir to stop casual browsing. > > > > > > Paul > > > > > > > > > -- > > > Rhl-devel-list mailing list > > > Rhl-devel-list at redhat.com > > > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From kaboom at gatech.edu Wed Jul 23 21:48:52 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 23 Jul 2003 15:48:52 -0600 (MDT) Subject: cipe In-Reply-To: <1058989176.3288.60.camel@zorak> References: <20030722014002.GD22711@redhat.com> <1058989176.3288.60.camel@zorak> Message-ID: On Wed, 23 Jul 2003, Tom 'spot' Callaway wrote: > Cipe 1.5.4 has two different crypto algorithms (Blowfish and IDEA). They > are mutually exclusive in the code. In addition, the two protocol types > (3 and 4) are mutually exclusive in the code. > > This means, to add it to the Red Hat Linux kernel as is, there would > need to be 4 directories with virtually identical code, simply to > account for all 4 possible modules. Headers cannot be shared in current > state. That's not new. Cipe 1.4.x also has both Blowfish and IDEA. Unless compiled with ./configure --enable-idea it only includes Blowfish, just like with Cipe 1.5.x. RH has, AFAIK, only shipped Cipe with Blowfish only, and I don't know of any reason why it would be necessary or even desirable to include IDEA support suddenly just because of moving to 1.5.x. later, chris From pri.rhl1 at iadonisi.to Wed Jul 23 22:33:43 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 23 Jul 2003 18:33:43 -0400 Subject: Diskless workstations In-Reply-To: <1058996440.11609.24.camel@smoogen1.lanl.gov> References: <1058996440.11609.24.camel@smoogen1.lanl.gov> Message-ID: <1058999623.24452.37.camel@va.local.linuxlobbyist.org> On Wed, 2003-07-23 at 17:40, Stephen Smoogen wrote: > Hi one thing that has come up over and over again (here) is that Debian > is easier to install into a diskless workstation environment than Red > Hat. I being the RH bigot that I am have not tried this yet, but I get > the feeling that it is. > > I would really like to see some work on making a Heavy Diskless > Workstation install possible in the future. [Heavy Diskless means boxes > that have say 1-2 gigs of Ram, big CPUs, and 100 mbps network at least.] > THere are many environments that use this heavy duty, and right now I am > having to admin 4 different ways of killing the problem with no one > absolutely correct. Well, if I understand what you are asking for, the K12LTSP project (at http://www.k12ltsp.org/) serves this purpose quite well. Version 3.1.1 is Red Hat 9 with updates (through around June 24), ltsp packages from http://www.ltsp.org/ and a few additional packages suitable for an educational environment. So a *lot* of this (excellent) work has already been done by Eric Harrison and Paul Nelson who head up the project. I've been able to do an install of a server and *even before ever logging into the server* to tweak even a single setting, I'm able to boot a thin client with a PXE enabled network card and have a working desktop. Fabulous work on Eric and Paul's part. What does require some work is the ltsp packages themselves. They most certainly won't meet any Red Hat criteria. The K12LTSP project takes them directly from the LTSP project and makes some minor tweaks but they suffer from what I consider a nasty problem: they are built from binary tarballs created by lifting binaries directly from an existing distribution (in this case, Red Hat 7.1, I believe). The ltsp packages included in K12LTSP 3.1.1 are based on ltsp version 3.x. The new ltsp version 4.x (I think still currently in alpha stage) takes an entirely different approach. What they do now is build an entire cross-compiling, chrooted environment to build all packages (tarballs, really) for the thin clients. This allows the LTSP project to be more distribution agnostic, but it isn't much better from a perspective of fitting into Red Hat neatly. I've been working on (and am willing to take on the task of doing so for the Red Hat Linux project) coming up with better ltsp packages that will fit nicely into Red Hat. No binary tarballs in the src rpms, no special build environments, but very specific to Red Hat. There are some issues to be worked out, however: 1) It seems the LTSP project has been concerned about disk space for the thin client tree (defaults to /opt/ltsp/i386), as is evidenced in their use of busybox instead of the real tools. I ask, what's the point? It's all stored on the server and it takes no additional RAM on the clients. Heck, the commands are barely (if at all) even used outside the boot process. So why not just install second copies of the rpms that are needed by the thin clients into an alternate root (like /opt/ltsp/i386)? There's other stuff that needs to be added (config files an the like), but those can be in additional packages. 2) Is it reasonable to ask for a change to anaconda to allow for these rpms to be installed in this alternate root? It would probably be an invasive change, as it's not currently done anywhere in anaconda, to the best of my knowledge, except that the actually installer *does* in fact install the entire distribution into an alternate root (after, how else would you do it?). What's different is that now I'm asking for anaconda to switch gears in the middle of the installation and install a specific list of packages in a different alternate root. 3) If the above isn't considered the best approach, another possibility is to rebuild the required rpms (and probably rename them with an 'ltsp-' prefix or some such distinction), with a different prefix directory. That seems like potentially a lot of extra build time and complexity, however, especially since both the (mknbi enabled) kernel and XFree86 are needed. Thoughts? 4) The last approach that I can think of is having a single ltsp-config package (or equivalent, name it whatever) that has includes all the additional ltsp stuff (config files, etherboot images, etc.) and a single script that checks to make sure all the rpms required for the thin client tree are actually installed in the normal root directory. and just copies all the required binaries into place in the /opt/ltsp/i386 tree. Alternatively, the script might not require that the rpms be installed on the server, but instead take a directory with the required rpms so that the appropriate rpms can be extracted. Of course, this approach has the problem of issuing errata: the script would have to be run whenever any relevant errata was issued. So I'd like some input into how to approach this and I'd also like to hear if there is sufficient interest in having this included in the Red Hat Linux project. If so, looks like I found my niche! (Unless of course Eric Harrison is on this list and would like to do it himself -- I tend to doubt it, though, given how busy he already is. ;-)) From smoogen at lanl.gov Wed Jul 23 22:41:57 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 23 Jul 2003 16:41:57 -0600 Subject: Diskless workstations In-Reply-To: <1058999623.24452.37.camel@va.local.linuxlobbyist.org> References: <1058996440.11609.24.camel@smoogen1.lanl.gov> <1058999623.24452.37.camel@va.local.linuxlobbyist.org> Message-ID: <1059000117.13133.7.camel@smoogen1.lanl.gov> On Wed, 2003-07-23 at 16:33, Paul Iadonisi wrote: > On Wed, 2003-07-23 at 17:40, Stephen Smoogen wrote: > > Hi one thing that has come up over and over again (here) is that Debian > > is easier to install into a diskless workstation environment than Red > > Hat. I being the RH bigot that I am have not tried this yet, but I get > > the feeling that it is. > > > > I would really like to see some work on making a Heavy Diskless > > Workstation install possible in the future. [Heavy Diskless means boxes > > that have say 1-2 gigs of Ram, big CPUs, and 100 mbps network at least.] > > THere are many environments that use this heavy duty, and right now I am > > having to admin 4 different ways of killing the problem with no one > > absolutely correct. > > Well, if I understand what you are asking for, the K12LTSP project (at > http://www.k12ltsp.org/) serves this purpose quite well. Version 3.1.1 > is Red Hat 9 with updates (through around June 24), ltsp packages from > http://www.ltsp.org/ and a few additional packages suitable for an > educational environment. Actually it is the opposite of want I need. The clients are usually multi cpu/ large ram machines/ etc with the server being not much at all. I think that LTSP servers 90% of most diskless environment needs.. I just end up in the 10% where the machines are diskless for programatic needs but the work must be done on the workstation (Lets just say a lot of the work maxes out a 2-4 CPU workstation.) -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From kaboom at gatech.edu Wed Jul 23 23:32:34 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 23 Jul 2003 17:32:34 -0600 (MDT) Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030723153541.G19044@devserv.devel.redhat.com> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723153541.G19044@devserv.devel.redhat.com> Message-ID: On Wed, 23 Jul 2003, Bill Nottingham wrote: > We're actually considering for this upcoming release: > > - adding in cyrus-imap > - taking out uw-imap > > Opinions? I think it's a good long-term idea, but I think uw-imap should ship and be marked in RELEASE-NOTES as slated for future removal (some of us actually do read the RELEASE-NOTES and plan accordingly ;-) later, chris From pri.rhl1 at iadonisi.to Wed Jul 23 23:40:29 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 23 Jul 2003 19:40:29 -0400 Subject: Diskless workstations In-Reply-To: <1059000117.13133.7.camel@smoogen1.lanl.gov> References: <1058996440.11609.24.camel@smoogen1.lanl.gov> <1058999623.24452.37.camel@va.local.linuxlobbyist.org> <1059000117.13133.7.camel@smoogen1.lanl.gov> Message-ID: <1059003628.24452.45.camel@va.local.linuxlobbyist.org> On Wed, 2003-07-23 at 18:41, Stephen Smoogen wrote: [snip] > > Actually it is the opposite of want I need. The clients are usually > multi cpu/ large ram machines/ etc with the server being not much at > all. > > I think that LTSP servers 90% of most diskless environment needs.. I > just end up in the 10% where the machines are diskless for programatic > needs but the work must be done on the workstation (Lets just say a lot > of the work maxes out a 2-4 CPU workstation.) Ah, I see. So it sounds like a job for openMosix (with node/cpu affinity), Compaq/HP's SSI, or maybe a customized LTSP config that creates a really big ramdisk to hold a full OS instead using NFS mounts. Hmm, if you use the big ramdisk approach, then it seems like not so big a change from the usually LTSP config, though I wouldn't call it LTSP at that point, but instead 'diskless-client' or something similar. I think most of what wrote might still apply. It could be made as some config option. Or even if it's separate, they are related enough that I might be able work on both. From smoogen at lanl.gov Thu Jul 24 00:28:22 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 23 Jul 2003 18:28:22 -0600 Subject: Diskless workstations In-Reply-To: <1059003628.24452.45.camel@va.local.linuxlobbyist.org> References: <1058996440.11609.24.camel@smoogen1.lanl.gov> <1058999623.24452.37.camel@va.local.linuxlobbyist.org> <1059000117.13133.7.camel@smoogen1.lanl.gov> <1059003628.24452.45.camel@va.local.linuxlobbyist.org> Message-ID: <1059006502.13133.19.camel@smoogen1.lanl.gov> No we do everything via NFS at the moment. Using a big ramdisk would cut into why all the machines have so much memory and CPU's. Basically the idea is that all CPU cycles are local and all data is foreign. The approach to this seems to follow either SGI or Sun ways of doing diskless clients. I like the Sun way of doing it (with each client getting its own tree) versus the SGI where most is common with the server and clients need a rebuild if server code changes. On Wed, 2003-07-23 at 17:40, Paul Iadonisi wrote: > On Wed, 2003-07-23 at 18:41, Stephen Smoogen wrote: > > [snip] > > > > > Actually it is the opposite of want I need. The clients are usually > > multi cpu/ large ram machines/ etc with the server being not much at > > all. > > > > I think that LTSP servers 90% of most diskless environment needs.. I > > just end up in the 10% where the machines are diskless for programatic > > needs but the work must be done on the workstation (Lets just say a lot > > of the work maxes out a 2-4 CPU workstation.) > > Ah, I see. So it sounds like a job for openMosix (with node/cpu > affinity), Compaq/HP's SSI, or maybe a customized LTSP config that > creates a really big ramdisk to hold a full OS instead using NFS > mounts. Hmm, if you use the big ramdisk approach, then it seems like > not so big a change from the usually LTSP config, though I wouldn't call > it LTSP at that point, but instead 'diskless-client' or something > similar. > I think most of what wrote might still apply. It could be made as > some config option. Or even if it's separate, they are related enough > that I might be able work on both. > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From warren at togami.com Thu Jul 24 04:35:00 2003 From: warren at togami.com (Warren Togami) Date: 23 Jul 2003 18:35:00 -1000 Subject: RPM building section of RHL's developer guide In-Reply-To: <20030722122604.624f3b23.matthias@rpmforge.net> References: <20030722122604.624f3b23.matthias@rpmforge.net> Message-ID: <1059021299.1858.64.camel@laptop> On Tue, 2003-07-22 at 00:26, Matthias Saou wrote: > - Summary: I'd like to see an official suggestion as to whether a > trailing > dot should be added or omitted. If would be prettier when all go by > at > install time :-) What do you mean? > - %description and %prep shouldn't be stuck together for readability > and > section separation. +1 http://cvs.fedora.us/cgi-bin/cvsweb.cgi/packages/fedora-rpmdevtools/spectemplate.spec Consider something like the layout near the top of Fedora's spec template. > Now about the guidelines... ;-) > > 5) "The package may obsolete itself"... I really don't get that one! When we hear the answer to this, can we have links from the RHLP page to more detailed information describing "why" and examples where it is used? Can we Wiki this? =) > 13) "If a newer RPM does not have a binary package that the older > SRPMS > produced, the binary package not produced anymore must be > specified > with the Obsoletes: option in the new spec file." > I would also add something about encouraging to always use > versions > with "Obsoletes:" in order to avoid many kind of future issues > when > re-introducing packages for example. > > Also, there is no mention of "Epoch:" usage, not even a quick note to > suggest not introducing any apart from when it's really the last > resort. I > guess people may want to stay out of the endless discussion for as > long as > possible ;-) > IIRC, I think I read someone mentioning somewhere that a list of > current > packages with full "n-e-v-r" would be maintained. With the current > implementation of epoch handling in rpm >= 4.2.1, this will become a > necessity when depending on specific versions of certain packages. Responding to this in a new thread. Preparing flame retardant suit. Warren Togami warren at togami.com From pri.rhl1 at iadonisi.to Thu Jul 24 04:39:52 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 24 Jul 2003 00:39:52 -0400 Subject: Diskless workstations In-Reply-To: <1059006502.13133.19.camel@smoogen1.lanl.gov> References: <1058996440.11609.24.camel@smoogen1.lanl.gov> <1058999623.24452.37.camel@va.local.linuxlobbyist.org> <1059000117.13133.7.camel@smoogen1.lanl.gov> <1059003628.24452.45.camel@va.local.linuxlobbyist.org> <1059006502.13133.19.camel@smoogen1.lanl.gov> Message-ID: <1059021592.24452.51.camel@va.local.linuxlobbyist.org> On Wed, 2003-07-23 at 20:28, Stephen Smoogen wrote: > No we do everything via NFS at the moment. Using a big ramdisk would cut > into why all the machines have so much memory and CPU's. Basically the > idea is that all CPU cycles are local and all data is foreign. The > approach to this seems to follow either SGI or Sun ways of doing > diskless clients. I like the Sun way of doing it (with each client > getting its own tree) versus the SGI where most is common with the > server and clients need a rebuild if server code changes. Okay, I give. ;-) Looks like it's a lot lest complicated than I was thinking, but I get your point about it being a bit of pain to set up. It would be nice to be able to do this OOB. Anyhow, all I wrote is still something I might do if there is enough interest. Maybe I'll look at what you need, too, and since they are somewhat related. (sorta, kinda, maybe...) -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From chuckw at quantumlinux.com Thu Jul 24 04:59:25 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 23 Jul 2003 21:59:25 -0700 (PDT) Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030723153541.G19044@devserv.devel.redhat.com> Message-ID: > We're actually considering for this upcoming release: > > - adding in cyrus-imap > - taking out uw-imap > > Opinions? We've got significant investment in uw-imap. I don't mind change as long as it's seamless. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From chuckw at quantumlinux.com Thu Jul 24 05:25:48 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Wed, 23 Jul 2003 22:25:48 -0700 (PDT) Subject: Diskless workstations In-Reply-To: <1059006502.13133.19.camel@smoogen1.lanl.gov> Message-ID: > No we do everything via NFS at the moment. Using a big ramdisk would cut > into why all the machines have so much memory and CPU's. Basically the > idea is that all CPU cycles are local and all data is foreign. The > approach to this seems to follow either SGI or Sun ways of doing > diskless clients. I like the Sun way of doing it (with each client > getting its own tree) versus the SGI where most is common with the > server and clients need a rebuild if server code changes. Can a user move to another workstation and resume their session? I've seen this done with RFID tags that automatically detach your session if you move away from the terminal and re-attach you when you move closer. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From warren at togami.com Thu Jul 24 05:43:05 2003 From: warren at togami.com (Warren Togami) Date: 23 Jul 2003 19:43:05 -1000 Subject: More Packaging Guidelines... Message-ID: <1059025301.1858.137.camel@laptop> http://www.fedora.us/wiki/QAChecklist Some highlights from Fedora's packaging guidelines... for now the easier points. I'm avoiding the Epoch discussion for now since I am short on time. 1. Are the pre- and post(un)install scripts correct? ================================================= If it installs files named **.so.* into %{_libdir}, is there a %post -p /sbin/ldconfig and %postun -p /sbin/ldconfig? If it has info files, is there a %post script that installs them, and a %postun one which removes them (and only on erase, not upgrade)? 2. Finding Missing BuildRequires ================================ http://www.fedora.us/wiki/HOWTOFindMissingBuildRequires Here is a brute force method of finding missing package BuildRequires. This works a lot better if you have a local apt/yum repository, or cache everything. Any suggestions for a cleaner way of testing for missing BuildRequires? Any suggestions for the "list of packages that should not be in BuildRequires" because they occur too frequently and should be in a standard build environment? We should define a standard minimal build environment for RHLP. Fedora currently does so implicitly with the dependencies of fedora-rpmdevtools. 3. Finding Redundant BuildRequires ================================== http://www.fedora.us/wiki/HOWTOUseRequires How not to be overzealous in adding BuildRequires, and including versioned dependencies when not needed. This document needs to be clarified a bit but otherwise good. 4. RPM Macros ============= http://www.fedora.us/wiki/RPMMacros Whenever possible use directory macros rather than hard coded directories. RHLP's docs should probably state the "why" too. 5. Strict Directory Ownership ============================= Any directory created by the package should be owned with a %dir entry within %files. rpm -vv shows unowned directories during installation, and I believe Enrico wrote a tool to test many RPMS and look for unowned directories. Attacking Epoch when I have more time later this week... Warren Togami warren at togami.com From pekkas at netcore.fi Thu Jul 24 06:16:33 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 24 Jul 2003 09:16:33 +0300 (EEST) Subject: strange bug in ipv6 initscripts, ideas? In-Reply-To: <20030723114418.F18078@devserv.devel.redhat.com> Message-ID: On Wed, 23 Jul 2003, Bill Nottingham wrote: > Pekka Savola (pekkas at netcore.fi) said: > > Hi, > > > > When looking at a bug report in IPv6 initscripts: > > > > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=86210 > > > > I came across a very strange bug. When a command is run from > > interactively, it works fine. When it's run via hotplug, it bugs under a > > very specific scenario: sometimes when we're redirecting stderr to stdin. > > Hotplug runs with stdin/stdout/stderr to /dev/null, FWIW. Ok. Now I see that: --8<-- ipv6_exec_ifconfig() { local options=$* LC_ALL=C /sbin/ifconfig $options 2>&1 return $? } ipv6_exec_ifconfig $device inet6 add $address || return 3 --8<-- 1) works if you remove "2>&1", or 2) works if you change the command to like: "ipv6_exec_ifconfig $device inet6 add $address > /dev/null || return 3" I.e. it seems as if "2>&1" does not work with hotplug's "unspecified" stdout/stderr fd's. So.. - Is there a bug in hotplug's handling of stdout/stderr ? - Is there a bug in sh's handling of "2>&1" when 1 is implicitly /dev/null? - Is there something I'm missing? :-) (Note: I've done all my tests on RHL73, so if something has changed in the meantime...) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mark at mark.mielke.cc Thu Jul 24 06:26:26 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Thu, 24 Jul 2003 02:26:26 -0400 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723153541.G19044@devserv.devel.redhat.com> Message-ID: <20030724062626.GA11256@mark.mielke.cc> On Wed, Jul 23, 2003 at 05:32:34PM -0600, Chris Ricker wrote: > On Wed, 23 Jul 2003, Bill Nottingham wrote: > > We're actually considering for this upcoming release: > > - adding in cyrus-imap > > - taking out uw-imap > > Opinions? > I think it's a good long-term idea, but I think uw-imap should ship and be > marked in RELEASE-NOTES as slated for future removal (some of us actually do > read the RELEASE-NOTES and plan accordingly ;-) I agree with Chris. Although, I don't like the default install configurations installing multiple tools that all do the same thing. Perhaps the default should be to only provide either cyrus-imap or dovecot? mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From rjl at renaissoft.com Thu Jul 24 07:07:39 2003 From: rjl at renaissoft.com (Robert LeBlanc) Date: Thu, 24 Jul 2003 00:07:39 -0700 Subject: my thoughts on package management In-Reply-To: <20030723155835.N18401@devserv.devel.redhat.com> References: <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <200307230515.13765.ali@packetknife.com> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> Message-ID: <5.1.1.6.2.20030723233050.00aec490@127.0.0.1> At 12:58 2003/07/23, Jeff Johnson wrote: >On Wed, Jul 23, 2003 at 12:20:38PM -0700, Robert LeBlanc wrote: > > > The problem at the root of all this is that if I ever need to rebuild > > anything from sources, I break the auto-update chain for that > package. The > > fact that I've applied a (developer-defined) customization effectively > > means I can no longer have security updates and bug-fixes applied without > > doing them by hand. What I'd rather see is a system flexible enough to > > detect (e.g. by reading the equivalent of a config.status file) the > > configuration options that were used to build a package in the first > place, > > and then applying these to updated sources--*or*--have it search for a > > binary distribution that was compiled with those specific options enabled. > > > > The latter may in the end be the more feasible option for RH. Essentially > > have the RPM information itself keep track of what options were used to > > compile the package, so that people who need a set of binaries compiled > > with options X, Y, and J can search on this basis, and make this a > > requirement for any auto-updates. > >There are two problems here: > 1) how the build system is set up. > 2) how the package was built. > >The build system for RHL is setup by using build dependencies for all but >a handful of packages like gcc and make. > >How the package was built is encoded in the spec file, and rpm by design >guarantees that each and every rpm started from a spec file, virgin sources, >etc and ran to completion in some build system. > >Yes there is no explicit config.status, basically because there is no need >if you are using RHL packages, or custom modifications of RHL packages, >or simple additions to RHL distros. Sorry, but I feel a bit like I've been "talked in circles", here :) I've been describing the problems inherent in "custom modifications of RHL packages", namely that any need to rebuild anything from sources (e.g. to recompile a package with a different set of configuration options) breaks the auto-updating capability for that package. I'm confused by the last sentence of your response, though, which seems to imply that there's no problem here at all. Could you clarify that a bit more? I confess to being an old-timer, having used Linux since kernel 0.99.12 when *everything* had to be assembled by hand. I'm well used to the process of downloading a source tarball, configuring and building the sources, and installing packages that way. When RPM came along I was initially impressed--package installation was about to become a whole lot easier and more streamlined, I thought. This is certainly true for "out of the box" installations, like for mass-deployment on workstations, but for servers I've simply determined that RPM and its auto-updating facilities are just false hopes--I can't (and therefore don't) use them, as too much customization tends to be required for server apps. The downside of doing everything manually, of course, is that I now have to keep abreast of bug and security fixes myself, and apply them all by hand to my sources, rebuild them, and reinstall them. I'd really like the convenience of the auto-updating facility--and would find it worth paying for--if it could actually work for me. The fact that it can't unless I straightjacket myself with "standard" binary installations is frustrating. I'd like to see a more flexible, versatile approach in any "next-generation" RPM/up2date system, and that's what I'm trying to petition for here. Either a Gentoo-like system that can build applications at install time with user-specified options selected, or at least a means of making the option set visible somewhere within the RPM package, so that when updates are downloaded for those packages the up2date process can search for RPMs built with those particular options. I'm sure there are other solutions that would work as well, given a little time and thought, and a willingness to make changes on this level. If, on the other hand, you really feel this is a problem that doesn't exist, or one that would require more work to fix than you're willing to invest, just say so and I'll shut up. I'm only trying to help make the RPM/up2date system live up to its initial promise, and if indeed you believe it's as good as it can get I'll drop the matter and go back to my tarballs, or to Gentoo. Robert LeBlanc From jorton at redhat.com Thu Jul 24 08:52:50 2003 From: jorton at redhat.com (Joe Orton) Date: Thu, 24 Jul 2003 09:52:50 +0100 Subject: cipe In-Reply-To: References: <20030722014002.GD22711@redhat.com> <1058989176.3288.60.camel@zorak> Message-ID: <20030724085250.GA17871@redhat.com> On Wed, Jul 23, 2003 at 03:48:52PM -0600, Chris Ricker wrote: > On Wed, 23 Jul 2003, Tom 'spot' Callaway wrote: > > > Cipe 1.5.4 has two different crypto algorithms (Blowfish and IDEA). They > > are mutually exclusive in the code. In addition, the two protocol types > > (3 and 4) are mutually exclusive in the code. > > > > This means, to add it to the Red Hat Linux kernel as is, there would > > need to be 4 directories with virtually identical code, simply to > > account for all 4 possible modules. Headers cannot be shared in current > > state. > > That's not new. Cipe 1.4.x also has both Blowfish and IDEA. Unless compiled > with > > ./configure --enable-idea > > it only includes Blowfish, just like with Cipe 1.5.x. > > RH has, AFAIK, only shipped Cipe with Blowfish only, and I don't know of any > reason why it would be necessary or even desirable to include IDEA support > suddenly just because of moving to 1.5.x. Indeed, IDEA is patent encumbered, we couldn't ship this at all. joe From fs111 at web.de Thu Jul 24 10:39:31 2003 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: 24 Jul 2003 12:39:31 +0200 Subject: people.redhat.com index In-Reply-To: <20030723192120.GC28315@raq465.uk2net.com> References: <20030723192120.GC28315@raq465.uk2net.com> Message-ID: <1059043171.2975.6.camel@localhost> Am Mit, 2003-07-23 um 21.21 schrieb Paul Nasrat: > Seeing as we're being wonderfully open, any chance the wonderfull index > page at people.redhat.com could be removed so there is the directory > index instead. Not to worry if not. > > Cheers > > Paul I wrote a small workaround in perl to get an working index.html. Don't laugh I'm a beginner, but it works. It uses the fact that the ftp access to people.redhat.com is still wide open and a simple ls on it gives me all the directory names: #!/usr/bin/perl use Net::FTP; $ftp = Net::FTP->new("people.redhat.com", Debug => 0); $ftp->login("anonymous",'me at test.net'); $ftp->cwd("/"); @data=$ftp->ls("/"); $ftp->quit; print("\n\r\n\r"); print(""); foreach $a(@data) { chomp($a); print("$a
\r\n"); } print(""); Save this to getIndex.pl, them make it runnable an redirect the output to a html-file, like ./getIndex.pl > index.html HTH regards Andr? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From david.paeme at belbone.net Thu Jul 24 10:47:16 2003 From: david.paeme at belbone.net (david paeme) Date: 24 Jul 2003 12:47:16 +0200 Subject: people.redhat.com index In-Reply-To: <1059043171.2975.6.camel@localhost> References: <20030723192120.GC28315@raq465.uk2net.com> <1059043171.2975.6.camel@localhost> Message-ID: <1059043635.3457.80.camel@owsdavid> an equally grand scheme: just slamming ftp://people.redhat.com in mozilla gives you the same result ;-) bye, d. On Thu, 2003-07-24 at 12:39, Andr?? Kelpe wrote: > Am Mit, 2003-07-23 um 21.21 schrieb Paul Nasrat: > > Seeing as we're being wonderfully open, any chance the wonderfull index > > page at people.redhat.com could be removed so there is the directory > > index instead. Not to worry if not. > > > > Cheers > > > > Paul > > > I wrote a small workaround in perl to get an working index.html. Don't > laugh I'm a beginner, but it works. It uses the fact that the ftp access > to people.redhat.com is still wide open and a simple ls on it gives me > all the directory names: > > #!/usr/bin/perl > use Net::FTP; > > > $ftp = Net::FTP->new("people.redhat.com", Debug => 0); > $ftp->login("anonymous",'me at test.net'); > $ftp->cwd("/"); > @data=$ftp->ls("/"); > $ftp->quit; > > > print("\n\r\n\r"); > print(""); > > foreach $a(@data) > { > chomp($a); > print("$a
\r\n"); > } > > print(""); > > Save this to getIndex.pl, them make it runnable an redirect the output > to a html-file, like ./getIndex.pl > index.html > > HTH > > regards Andr?? From fs111 at web.de Thu Jul 24 11:04:51 2003 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: 24 Jul 2003 13:04:51 +0200 Subject: people.redhat.com index In-Reply-To: <1059043635.3457.80.camel@owsdavid> References: <20030723192120.GC28315@raq465.uk2net.com> <1059043171.2975.6.camel@localhost> <1059043635.3457.80.camel@owsdavid> Message-ID: <1059044691.2975.11.camel@localhost> Am Don, 2003-07-24 um 12.47 schrieb david paeme: > an equally grand scheme: > > just slamming ftp://people.redhat.com in mozilla gives you the same > result ;-) That's true but than mozilla speaks ftp not http which slower on my connection, and using mozilla isn't the UNIX way to do things. We want scripts for everything ;-) Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From david.paeme at belbone.net Thu Jul 24 11:15:18 2003 From: david.paeme at belbone.net (david paeme) Date: 24 Jul 2003 13:15:18 +0200 Subject: people.redhat.com index In-Reply-To: <1059044691.2975.11.camel@localhost> References: <20030723192120.GC28315@raq465.uk2net.com> <1059043171.2975.6.camel@localhost> <1059043635.3457.80.camel@owsdavid> <1059044691.2975.11.camel@localhost> Message-ID: <1059045317.3457.88.camel@owsdavid> that's true. my fault. mea culpa. i forgot that: no cli == no good ;-) but this is even better than perl: a shellscript! it speaks http, and is "wick'id" fast! it outputs to a file called 'index.html', which can then be instpected with your favourite cli text-file tool! here it is: |---------------script starts here------------------| #!/bin/sh wget ftp://people.redhat.com |---------------script ends here--------------------| On Thu, 2003-07-24 at 13:04, Andr?? Kelpe wrote: > Am Don, 2003-07-24 um 12.47 schrieb david paeme: > > an equally grand scheme: > > > > just slamming ftp://people.redhat.com in mozilla gives you the same > > result ;-) > > That's true but than mozilla speaks ftp not http which slower on my > connection, and using mozilla isn't the UNIX way to do things. We want > scripts for everything ;-) > > Andre From fs111 at web.de Thu Jul 24 11:32:48 2003 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: 24 Jul 2003 13:32:48 +0200 Subject: people.redhat.com index In-Reply-To: <1059045317.3457.88.camel@owsdavid> References: <20030723192120.GC28315@raq465.uk2net.com> <1059043171.2975.6.camel@localhost> <1059043635.3457.80.camel@owsdavid> <1059044691.2975.11.camel@localhost> <1059045317.3457.88.camel@owsdavid> Message-ID: <1059046368.2975.17.camel@localhost> Am Don, 2003-07-24 um 13.15 schrieb david paeme: > that's true. my fault. mea culpa. > > i forgot that: no cli == no good ;-) [...] > |---------------script starts here------------------| > > #!/bin/sh > wget ftp://people.redhat.com > > |---------------script ends here--------------------| This does not work on my machine. I don't know why, but I get just some error messages from wget. If it will work on my machine, you are the winner of "the-shortest-script-to-get-the-index-of-peple.redhat.com-contest" ;-) Andre -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From skvidal at phy.duke.edu Thu Jul 24 12:08:45 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 24 Jul 2003 08:08:45 -0400 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030724062626.GA11256@mark.mielke.cc> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723153541.G19044@devserv.devel.redhat.com> <20030724062626.GA11256@mark.mielke.cc> Message-ID: <1059048525.4157.270.camel@binkley> > I agree with Chris. Although, I don't like the default install configurations > installing multiple tools that all do the same thing. Perhaps the default > should be to only provide either cyrus-imap or dovecot? I disagree in this case. Cyrus and dovecot handle imap for two different scales of systems right now. Cyrus being a larger more complex system and dovecot being much more straightforward. -sv From kaboom at gatech.edu Thu Jul 24 12:16:14 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 24 Jul 2003 06:16:14 -0600 (MDT) Subject: plaintext imap authentication Message-ID: Prior to this first beta, uw-imap was configured in alphas / rawhide with plaintext authentication disabled when connecting over unsecured connections (ie, pop / imap, but not pops / imaps). In beta1, uw-imap and dovecot both accept plaintext auth via at least imap (didn't try pop). Was it decided that the world's not ready to give up plaintext yet after all? Or just an accidental reversion? later, chris From laroche at redhat.com Thu Jul 24 12:46:09 2003 From: laroche at redhat.com (Florian La Roche) Date: Thu, 24 Jul 2003 14:46:09 +0200 Subject: yum initscript changes Message-ID: <20030724124609.GA2780@dudweiler.stuttgart.redhat.com> Change the initscript for current RHL defaults (whereever they are specified ;-) ;-): - It is bash-only. - Translations are possible. - Do not use subshells if not needed. - Add reload as dummy function. - Use touch instead of /bin/touch. (That is personal feeling.) greetings, Florian La Roche --- yum-2.0/etc/yum.init.lr 2003-07-24 14:28:50.000000000 +0200 +++ yum-2.0/etc/yum.init 2003-07-24 14:41:48.000000000 +0200 @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash # # yum This shell script enables the automatic use of YUM # @@ -13,14 +13,14 @@ . /etc/rc.d/init.d/functions start() { - echo -n "Enabling yum: " - (/bin/touch /var/lock/subsys/yum && success) || failure + echo -n $"Starting yum service: " + touch /var/lock/subsys/yum && success || failure echo } stop() { - echo -n "Disabling yum: " - (/bin/rm -f /var/lock/subsys/yum && success) || failure + echo -n $"Stopping yum service: " + rm -f /var/lock/subsys/yum && success || failure echo } @@ -35,6 +35,8 @@ stop start ;; + reload) + ;; condrestart) if [ -f /var/lock/subsys/yum ]; then stop @@ -43,13 +45,13 @@ ;; status) if [ -f /var/lock/subsys/yum ]; then - echo "nightly yum update is enabled" + echo $"Nightly yum update is enabled." else - echo "nightly yum update is disabled" + echo $"Nightly yum update is disabled." fi ;; *) - echo "*** Usage: yum {start|stop|restart|condrestart|status}" + echo $"Usage: $0 {start|stop|status|restart|reload|condrestart}" exit 1 esac From dwalsh at redhat.com Thu Jul 24 13:23:26 2003 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 24 Jul 2003 09:23:26 -0400 Subject: Diskless workstations References: Message-ID: <3F1FDDCE.4080702@redhat.com> I have been working on a package called redhat-config-netboot that allows you to setup diskless environments using NFS, as well as network installations. It is based somewhat off of LTSB. It is basically a series of scripts and python code that sets up a PXE boot environment and an diskless NFS partition. ftp://people.redhat.com/dwalsh/netboot Comments welcome. Dan Chuck Wolber wrote: > > >>No we do everything via NFS at the moment. Using a big ramdisk would cut >>into why all the machines have so much memory and CPU's. Basically the >>idea is that all CPU cycles are local and all data is foreign. The >>approach to this seems to follow either SGI or Sun ways of doing >>diskless clients. I like the Sun way of doing it (with each client >>getting its own tree) versus the SGI where most is common with the >>server and clients need a rebuild if server code changes. >> >> > >Can a user move to another workstation and resume their session? I've seen >this done with RFID tags that automatically detach your session if you >move away from the terminal and re-attach you when you move closer. > >-Chuck > > > From nphilipp at redhat.com Thu Jul 24 13:21:33 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: 24 Jul 2003 15:21:33 +0200 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: References: Message-ID: <1059052893.4599.3.camel@gibraltar.stuttgart.redhat.com> On Thu, 2003-07-24 at 06:59, Chuck Wolber wrote: > > We're actually considering for this upcoming release: > > > > - adding in cyrus-imap > > - taking out uw-imap > > > > Opinions? > > We've got significant investment in uw-imap. I don't mind change as long > as it's seamless. Pretty seemless. It was a one-liner config change in /etc/dovecot.conf so that it doesn't look in ~/Mail for additional mbox files, but in ~ (as UW-IMAP does). I'll probably change to Cyrus (and would even volunteer to help with the package) in the future, though. Shared mailboxes are yummy, even with only two users ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Ole.Aamot at nr.no Thu Jul 24 13:27:52 2003 From: Ole.Aamot at nr.no (Ole Aamot) Date: 24 Jul 2003 15:27:52 +0200 Subject: PDA/Mobile Phone connectivity with MultiSync Message-ID: <1059053271.30161.4.camel@perceptron.nr.no> Could you add PDA/Mobile Phone connectivity in the next release? I deeply recommend the MultiSync GNOME2 application for the job, as it is easy-to-use, integrates with Evolution, supports SyncML and IrMC, etc. It is advertised to work with the following PDAs * Compaq iPAQ 31XX * Compaq iPAQ 36XX * Compaq iPAQ 37XX * Compaq iPAQ 38XX * Compaq iPAQ 39XX * Sharp Zaurus SL-5500 * Sharp Zaurus SL-5000D * Sharp Zaurus SL-5600 * Windows CE / Pocket PC and these mobile phones: * Sony Ericsson R320 (IrMC) * Sony Ericsson T39 (IrMC) * Sony Ericsson T68i (IrMC) * Siemens S45i (IrMC) * Siemens S55 (IrMC) http://multisync.sourceforge.net/ MultiSync is a free modular program to synchronize calendars, addressbooks and other PIM data between programs on your computer and other computers, mobile devices, PDAs or cell phones. Currently MultiSync has plugins for * Ximian Evolution synchronization, supporting calendar, ToDos and contacts. * IrMC Mobile Client synchronization (supported by e.g. SonyEricsson T39/T68i, Siemens S45i/S55 phones etc.) via Bluetooth or IR on Linux, or cable connection. * Windows CE / Pocket PC synchronization. This plugin is part of the SynCE project, and can be downloaded there. * Remote connection of two MultiSync programs via an encrypted connection over the net. Perfect to synchronize your laptop and stationary computer, or why not your home and work calendars? * Backup of your PIM data. -- Ole Aamot, Oslo, Norway From jbj at redhat.com Thu Jul 24 14:00:09 2003 From: jbj at redhat.com (Jeff Johnson) Date: Thu, 24 Jul 2003 10:00:09 -0400 Subject: RPM building section of RHL's developer guide In-Reply-To: <1059021299.1858.64.camel@laptop>; from warren@togami.com on Wed, Jul 23, 2003 at 06:35:00PM -1000 References: <20030722122604.624f3b23.matthias@rpmforge.net> <1059021299.1858.64.camel@laptop> Message-ID: <20030724100009.O18401@devserv.devel.redhat.com> On Wed, Jul 23, 2003 at 06:35:00PM -1000, Warren Togami wrote: > > > > 5) "The package may obsolete itself"... I really don't get that one! > > When we hear the answer to this, can we have links from the RHLP page to > more detailed information describing "why" and examples where it is > used? > > Can we Wiki this? =) > Every package obsoletes (i.e. erases) itself when using --upgrade. Obsoletes: is commonly used to get rid of a differently named but otherwise nearly identical package. In order to resolve dependencies, the new package often carries a Provides:. So what a packager sees is Name: newfoo ... Obsoletes: oldfoo Provides: oldfoo leading to a confusion based on (from user POV) newfoo == oldfoo interpretation. The only other case I can think of where a packager might consider adding Name: foo ... Obsoletes: foo is to attempt to get rid of other copies of packages if rpm is invoked with --install. Not gonna work, doesn't afaik, as the promise of --install is No information will ever be erased if invoked with --install. There's enough conflicting features and policies in rpm that it wouldn't surprise me to hear about some exotic corner case, but that's a bug imho. > > 13) "If a newer RPM does not have a binary package that the older > > SRPMS > > produced, the binary package not produced anymore must be > > specified > > with the Obsoletes: option in the new spec file." > > I would also add something about encouraging to always use > > versions > > with "Obsoletes:" in order to avoid many kind of future issues > > when > > re-introducing packages for example. > > > > Also, there is no mention of "Epoch:" usage, not even a quick note to > > suggest not introducing any apart from when it's really the last > > resort. I > > guess people may want to stay out of the endless discussion for as > > long as > > possible ;-) > > IIRC, I think I read someone mentioning somewhere that a list of > > current > > packages with full "n-e-v-r" would be maintained. With the current > > implementation of epoch handling in rpm >= 4.2.1, this will become a > > necessity when depending on specific versions of certain packages. > > Responding to this in a new thread. Preparing flame retardant suit. > Current behavior in rpm-4.2.1 (and all future versions of rpm) is A missing (i.e. unsepcified) Epoch: is exactly equivalent to Epoch: 0. Whether you choose to make the Epoch: explicit is a matter of style, the version comparison in rpm is now deterministic, the same answer is returned every time. I'd suggest that broken packages (i.e. missing Epoch: is needed) are more easily handled with rpm -Va --nofiles --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ i.e. verify that the dependencies of each package are satisfied within the universe of packages contained in, say, the rpmdb-redhat package for the distro, becuase a) missing Epoch: is just a special case of a more general problem, dependency closure for a collection of packages called a distro. a) closure on dependencies cannot be easily detected by a packager, but is trivial (and necessary) to check by a distro release manager. (aside) I'd like to add the closure check to rpmbuild, what stops me is that noone is willing to figger means to maintain the equivalent of a rpmdb-redhat package incrementally. Without that, it's premature to check for dependency closure in rpmbuild. So the immediate problem is to establish the need of creating a rpmdb-redhat database so that the tools necessary to do the job can start being written. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From enrico.scholz at informatik.tu-chemnitz.de Thu Jul 24 14:52:54 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 24 Jul 2003 16:52:54 +0200 Subject: RFC: i18n proposal In-Reply-To: <20030723213756.B9605@devserv.devel.redhat.com> (Havoc Pennington's message of "Wed, 23 Jul 2003 21:37:56 -0400") References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> Message-ID: <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> [ f'up2 to rhl-devel; the starting point of this thread is available at http://www.fedora.us/pipermail/fedora-devel/2003-July/001756.html ] hp at redhat.com (Havoc Pennington) writes: > On Thu, Jul 24, 2003 at 01:19:11AM +0200, Enrico Scholz wrote: >> >> Other thoughts or comments? >> > > Probably works for now (we've been doing it forever), but in the end > the only right thing has to be that translations are part of the > package being translated. I see a problem in the maintenance of these translations. With the specspo approach, there is one big .po-file which is updated by the translators. When making the translations a part of the package, there will be either thousands of small .po-files on the distribution side (Fedora, Red Hat) or the package author has to maintain his .po files himself. IMHO, the latter option will not work because this will result in a maintainance nightmare: since there are not enough translators, every translator has to look after several packages, has to communicate with the author and the author has to release packages with updated translations very often. And this for every language... So, there stays only the thousands of small .po-files case where the translator has to choose one of them. Clicking hundreds of time in the browser to download the files sounds very annoying and error-prone to me. Sure, you can hide this complexity with tools but such tools must be written first and it will need a lot of work to make them as powerful like the current solutions (e.g. the Emacs po-mode). Another advantage of the big .po file is, that common strings (e.g. group-names) need do be translated once. > Say you are using redhat-config-packages or another package tool. You > see a list of packages. You should see nice user friendly names of > those packages in your own language Ok; but I do not think that this is a matter of translations. To make this possible, a new rpm-tag (e.g. 'LongName:' or 'ShortSummary:') which defaults to the value of 'Name:' must be created. This new tag can be added to the fields going to be translated. But I think, only a few packages will profit from this; e.g. consider the 'docbook-style-*' packages. What will you use for 'LongName:'? When using e.g. _("docbook tools") the package-tool will present dozens of _("docbook tools") and user is forced to enable either the raw-view or to look at 'Summary:' to see which package it is. > Also you want translated descriptions of course. > > I see no way to reliably do this using specspo. You have to somehow > bundle the translations into the RPM package, and also install them > when the RPM is installed. You are right; specpo has disadvantages. E.g. you will have to download the several mebibytes sized package for every small change in the translation. There is a time-gap between package- and specspo-release also. > Otherwise mixing packages from different sources (including different > OS versions) *will* break. IMHO, this is not a big problem. The average user (who wants/needs translations), will use the big repositories (the upcoming Red Hat Linux Project, Fedora, Freshrpms, ...) which can provide their specspo-packages. There is an issue with rpm that is not easy to "register" such packages; but for now, this can be solved with some %triggers and Jeff is open for ideas how it can be improved in "better" ways. > One approach would add a "PoFilesDir: foo" field to spec files, ... Very interesting idea. Because I do not like decentralized maintainance of po-files, I would apply it in the following way: * The build-hosts of the repositories which are maintaining the translations are "authoritative" regarding translations. "authoritative" means that there are global macros like | %_i18n_update_pofiles 1 | %_i18n_translation_domain fedora-i18n This i18n domain is maintained in the current way: there is a big .po file for every language, translators update it through cvs and release manager compiles it to a .mo-file. * while doing 'rpmbuild -bs ...' on these hosts, the resulting srpm-package gets - a tarball with *.po-files containing the trasnlated strings of the package - a tag like 'PoSources: ' non-authoritative hosts will not touch this tarball or tag. * when doing 'rpmbuild --rebuild ...' for such a prepared srpm, the operations mentioned by you already (make update-po) will be executed and rpm creates translated headers by executing | gettext(header[RPMTAG_SUMMARY/DESCRIPTION/...]) for every supported language. 'rpmbuild --rebuild' will not differ on authoritative and non-authoritative hosts. Problems: * it is not implemented yet > It might be nice if there were some way to add translation resource > bundles to an RPM *after* building the RPM, Yes; you will need to modify the headers (change localized language tags and increase release) and you will have to update the po-tarball. On the first glance, this does not look very complicated. Enrico From notting at redhat.com Thu Jul 24 15:05:42 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Jul 2003 11:05:42 -0400 Subject: people.redhat.com index In-Reply-To: <1059043635.3457.80.camel@owsdavid>; from david.paeme@belbone.net on Thu, Jul 24, 2003 at 12:47:16PM +0200 References: <20030723192120.GC28315@raq465.uk2net.com> <1059043171.2975.6.camel@localhost> <1059043635.3457.80.camel@owsdavid> Message-ID: <20030724110541.A17865@devserv.devel.redhat.com> david paeme (david.paeme at belbone.net) said: > just slamming ftp://people.redhat.com in mozilla gives you the same > result ;-) FTP and HTTP content are different on that box. Bill From notting at redhat.com Thu Jul 24 15:14:57 2003 From: notting at redhat.com (Bill Nottingham) Date: Thu, 24 Jul 2003 11:14:57 -0400 Subject: plaintext imap authentication In-Reply-To: ; from kaboom@gatech.edu on Thu, Jul 24, 2003 at 06:16:14AM -0600 References: Message-ID: <20030724111457.D17865@devserv.devel.redhat.com> Chris Ricker (kaboom at gatech.edu) said: > Prior to this first beta, uw-imap was configured in alphas / rawhide with > plaintext authentication disabled when connecting over unsecured connections > (ie, pop / imap, but not pops / imaps). > > In beta1, uw-imap and dovecot both accept plaintext auth via at least imap > (didn't try pop). Was it decided that the world's not ready to give up > plaintext yet after all? Or just an accidental reversion? * Fri Jul 11 2003 John Dennis 1:2002d-1 - bring upto new upstream release 2002d, change SSLTYPE to allow for plain text login again Bill From herrold at owlriver.com Thu Jul 24 15:17:59 2003 From: herrold at owlriver.com (R P Herrold) Date: Thu, 24 Jul 2003 11:17:59 -0400 (EDT) Subject: yum initscript changes In-Reply-To: <20030724124609.GA2780@dudweiler.stuttgart.redhat.com> Message-ID: On Thu, 24 Jul 2003, Florian La Roche wrote: > Change the initscript for current RHL defaults (whereever they are > specified ;-) ;-): filed upstream to yum bugzilla https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=81 -- Russ Herrold From jbj at redhat.com Thu Jul 24 15:42:26 2003 From: jbj at redhat.com (Jeff Johnson) Date: Thu, 24 Jul 2003 11:42:26 -0400 Subject: RFC: i18n proposal In-Reply-To: <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de>; from enrico.scholz@informatik.tu-chemnitz.de on Thu, Jul 24, 2003 at 04:52:54PM +0200 References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20030724114226.Q18401@devserv.devel.redhat.com> On Thu, Jul 24, 2003 at 04:52:54PM +0200, Enrico Scholz wrote: > [ f'up2 to rhl-devel; the starting point of this thread is available at > http://www.fedora.us/pipermail/fedora-devel/2003-July/001756.html ] > > hp at redhat.com (Havoc Pennington) writes: > > > On Thu, Jul 24, 2003 at 01:19:11AM +0200, Enrico Scholz wrote: > >> > >> Other thoughts or comments? > >> > > > > Probably works for now (we've been doing it forever), but in the end > > the only right thing has to be that translations are part of the > > package being translated. > > I see a problem in the maintenance of these translations. With the > specspo approach, there is one big .po-file which is updated by the > translators. When making the translations a part of the package, there > will be either thousands of small .po-files on the distribution side > (Fedora, Red Hat) or the package author has to maintain his .po files > himself. > Yup, one big file is much easier to hand to a per-locale translator. And, even though I don't do i18n myself becuase I'm deprived of other languages, I suspect that one big file is easier on everyone involved than hundreds of 20 line files. Is hundreds of teensy .po files doable? Sure, but there are many technical reasons not to do so. The really important issue is that i18n is lots and lots of work from a team of people. IMHO, the work is best left to for-pay translators (and editors, hackers are not necessarily the best redactors) by commercial entities like Red Hat. > IMHO, the latter option will not work because this will result in a > maintainance nightmare: since there are not enough translators, every > translator has to look after several packages, has to communicate > with the author and the author has to release packages with updated > translations very often. And this for every language... > > > So, there stays only the thousands of small .po-files case where the > translator has to choose one of them. Clicking hundreds of time in the > browser to download the files sounds very annoying and error-prone to > me. > > Sure, you can hide this complexity with tools but such tools must be > written first and it will need a lot of work to make them as powerful > like the current solutions (e.g. the Emacs po-mode). > > Another advantage of the big .po file is, that common strings > (e.g. group-names) need do be translated once. > Thousands of teensy *.po files doesn't work? If so, we agree completely. Otherwise I'm confused by your words, as I see thousands of *.po files as a logistical nightmare that will just impede the process of l10n. I'd suggest that someone who actually does (or has done) i18n translations for package Summary/Description/Group design the process, because the goal is to make it as easy as possible to complete and maintain the corpus. Yes, no process design means that only ad hoc tools can be built. > > > > Say you are using redhat-config-packages or another package tool. You > > see a list of packages. You should see nice user friendly names of > > those packages in your own language > > Ok; but I do not think that this is a matter of translations. To make > this possible, a new rpm-tag (e.g. 'LongName:' or 'ShortSummary:') which > defaults to the value of 'Name:' must be created. This new tag can be > added to the fields going to be translated. > > But I think, only a few packages will profit from this; e.g. consider > the 'docbook-style-*' packages. What will you use for 'LongName:'? When > using e.g. _("docbook tools") the package-tool will present dozens of > _("docbook tools") and user is forced to enable either the raw-view or > to look at 'Summary:' to see which package it is. > This is a much nastier problem because: a) there's a change of data type (i.e. RPM_STRING_TYPE -> RPM_I18NSTRING_TYPE involved, it's not just adding new text for RPMTAG_NAME or adding new LongName:/ShortName: tag. In fact, the creation of the data type was exactly the reason for a major incompatibility. Having personally survived (but barely) v2 -> v3 -> v4 -> v3 changes in rpm packaging, I wish not to go there ever again. I wasted 1 year of my life already discussing the ramifications of the value contained in byte 5 of an rpm package. Have at it, enjoy, I have no desire to go there again. b) LongName: appears to have exactly the properties currently in %description; ditto ShortSummary: wrto Summary:; otherwise see c) c) There are significant issues involved in attempting to do i18n on a database key like Name:. Yes, the value of Name: is displayed as output, and as output, is a candidate for translation. Writing a database layer that properly handles i18n'ified tags is way outside the scope of what I wish to attempt with rpmdb. d) There's also the peripheral issue of the i18n name of the Name: tag, see "rpm -qi rpm" output. Should "Name:" or "Nom:" be displayed in LANG=fr_FR? My own opinion -- after having a long discussion with a member of the i18n team -- is that RPMTAG_NAME should be identified as a string in the C locale bacuase the value is havily used in, say, python constructs like N = h['name'], OTOH, the mechanism to do otherwise already exists if you disagree, see popt(3) aliases which are mostly gettext'ified and ready for translation. Note: only a single person has even attempted to look at the i18n problem wrto /usr/lib/rpm/rpmpopt-x.y.z afaik.) e) rpm was written (and still uses) a ctype(3) parser because i18n was not even a consideration when rpm was written. The parser has broken several times becuase of i18n deployment, can/will break further if the tokens parsed (e.g. "Name:" used in error messages) are localized. f) rpm is totally clueless about encodings, although reasonable deployments (because rpm is 8bit clean) might be attempted. > > > Also you want translated descriptions of course. > > > > I see no way to reliably do this using specspo. You have to somehow > > bundle the translations into the RPM package, and also install them > > when the RPM is installed. > > You are right; specpo has disadvantages. E.g. you will have to download > the several mebibytes sized package for every small change in the > translation. There is a time-gap between package- and specspo-release > also. > My (and Red Hat's at the time) is specspo is great for distributions but bad for packages. The major advantages for distros are a) single file encapsulation of large and changing set of text. b) uncoupling build from doc processes, they happen on different time scales, for different reasons, and mashing the two processes into one is a formidable task indeed. c) the potential for updating package translations after release. The major disadvantage for 3rd party packages is that specspo has not been generalized into thousands of teensy *.po files. Certainly doable, will even attempt in rpm if/when I see a significant number of packagers, not distros, even attempting to translate package Summary/Description/Group. > > > Otherwise mixing packages from different sources (including different > > OS versions) *will* break. > > IMHO, this is not a big problem. The average user (who wants/needs > translations), will use the big repositories (the upcoming Red Hat > Linux Project, Fedora, Freshrpms, ...) which can provide their > specspo-packages. > > There is an issue with rpm that is not easy to "register" such packages; > but for now, this can be solved with some %triggers and Jeff is open for > ideas how it can be improved in "better" ways. > Hmmm, hopefilly can be solved without %triggers, but yes I'm willing to try to accomodate. > > > One approach would add a "PoFilesDir: foo" field to spec files, ... > > Very interesting idea. Because I do not like decentralized maintainance > of po-files, I would apply it in the following way: > > * The build-hosts of the repositories which are maintaining the translations > are "authoritative" regarding translations. "authoritative" means that > there are global macros like > > | %_i18n_update_pofiles 1 > | %_i18n_translation_domain fedora-i18n > > This i18n domain is maintained in the current way: there is a big .po > file for every language, translators update it through cvs and release > manager compiles it to a .mo-file. > > * while doing 'rpmbuild -bs ...' on these hosts, the resulting srpm-package > gets > > - a tarball with *.po-files containing the trasnlated strings of the > package > - a tag like 'PoSources: ' > > non-authoritative hosts will not touch this tarball or tag. > > * when doing 'rpmbuild --rebuild ...' for such a prepared srpm, the > operations mentioned by you already (make update-po) will be executed > and rpm creates translated headers by executing > > | gettext(header[RPMTAG_SUMMARY/DESCRIPTION/...]) > > for every supported language. > > 'rpmbuild --rebuild' will not differ on authoritative and non-authoritative > hosts. > > > Problems: > > * it is not implemented yet > I can certainly see ways to simplify and automate building distros that have packages with po sub-directories. However, automation does not start with Let's add "PoFilesDir: foo" tag because ... there's far more to automation than parsing syntax (XML != automation). Yeah there's tha "not implemented yet" problem isn't there ;-) > > > > It might be nice if there were some way to add translation resource > > bundles to an RPM *after* building the RPM, > > Yes; you will need to modify the headers (change localized language tags > and increase release) and you will have to update the po-tarball. On the > first glance, this does not look very complicated. > Been there, done that -- twice -- the process was called "drilling" and was nearly as painful as a root canal. IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in tar/cpio headers. Keep i18n out of packages, please. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From pmmm at rnl.ist.utl.pt Thu Jul 24 15:57:32 2003 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Thu, 24 Jul 2003 16:57:32 +0100 Subject: RFC: i18n proposal In-Reply-To: <20030724114226.Q18401@devserv.devel.redhat.com> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> Message-ID: <200307241657.32739.pmmm@rnl.ist.utl.pt> Em Quinta, 24 de Julho de 2003 16:42, Jeff Johnson escreveu: > The really important issue is that i18n is lots and lots of work from > a team of people. IMHO, the work is best left to for-pay translators > (and editors, hackers are not necessarily the best redactors) by commercial > entities like Red Hat. My 2 person team has sucessfully translated all KDE releases since the 1.x days and Red Hat Linux from about 7 to European Portuguese. For some "smaller" countries like Portugal (10 million persons) you just can't wait that some day Red Hat will want to support a localized version. The only problem we've faced so far with the specspo approach is that it's not regenerated enough times during a beta cicle; just look at the logs and see how many times it has been regenerated during the 8.0.x days. Volunteers work on their own free time so the earlier the specspo pot file is regenerated the bigger the change we'll find some time to update it. For example, it could use an update right now. Pedro Morais KDE and Red Hat pt_PT i18n From smoogen at lanl.gov Thu Jul 24 16:03:17 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 24 Jul 2003 10:03:17 -0600 Subject: Diskless workstations In-Reply-To: <3F1FDDCE.4080702@redhat.com> References: <3F1FDDCE.4080702@redhat.com> Message-ID: <1059062597.3380.6.camel@smoogen1.lanl.gov> Thanks I will try to look at this next week. What I am trying to figure out is the best/fastest way to set up new diskless clients that have 'full' installs. Currently we have two systems here. The first is where /usr and some other directories are stored on the master tree and then the few remaining (/lib /var /etc /initrd etc) are seperate per machine. This is very fast to bring up a new machine because the date to be copied is small (20-40 megs on average). However it is a pain in the ass to update as all the clients have to be rebuilt after errata that change /etc, /lib etc occur. The second is much more disk intensive but easier to maintain. In this version each client gets a complete install in an NFS tree. This allows for a lot of customization per client (some can run 7.1 while others run 9.0). Maintenance is much easier because RPM can be run on each of the trees seperately. However installs are SLOW because they are either server side using a chroot anaconda (which I havent gotten working seamlessly) or the client is doing all the writes via NFS. On Thu, 2003-07-24 at 07:23, Daniel J Walsh wrote: > I have been working on a package called redhat-config-netboot that > allows you to setup diskless environments > using NFS, as well as network installations. It is based somewhat off > of LTSB. It is basically a series of scripts and python code that sets > up a PXE boot environment and an diskless NFS partition. > > ftp://people.redhat.com/dwalsh/netboot > > Comments welcome. > > Dan > > Chuck Wolber wrote: > > > > > > >>No we do everything via NFS at the moment. Using a big ramdisk would cut > >>into why all the machines have so much memory and CPU's. Basically the > >>idea is that all CPU cycles are local and all data is foreign. The > >>approach to this seems to follow either SGI or Sun ways of doing > >>diskless clients. I like the Sun way of doing it (with each client > >>getting its own tree) versus the SGI where most is common with the > >>server and clients need a rebuild if server code changes. > >> > >> > > > >Can a user move to another workstation and resume their session? I've seen > >this done with RFID tags that automatically detach your session if you > >move away from the terminal and re-attach you when you move closer. > > > >-Chuck > > > > > > > > > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From jbj at redhat.com Thu Jul 24 16:07:52 2003 From: jbj at redhat.com (Jeff Johnson) Date: Thu, 24 Jul 2003 12:07:52 -0400 Subject: RFC: i18n proposal In-Reply-To: <200307241657.32739.pmmm@rnl.ist.utl.pt>; from pmmm@rnl.ist.utl.pt on Thu, Jul 24, 2003 at 04:57:32PM +0100 References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <200307241657.32739.pmmm@rnl.ist.utl.pt> Message-ID: <20030724120752.R18401@devserv.devel.redhat.com> On Thu, Jul 24, 2003 at 04:57:32PM +0100, Pedro Morais wrote: > Em Quinta, 24 de Julho de 2003 16:42, Jeff Johnson escreveu: > > The really important issue is that i18n is lots and lots of work from > > a team of people. IMHO, the work is best left to for-pay translators > > (and editors, hackers are not necessarily the best redactors) by commercial > > entities like Red Hat. > > My 2 person team has sucessfully translated all KDE releases since the 1.x > days and Red Hat Linux from about 7 to European Portuguese. > For some "smaller" countries like Portugal (10 million persons) you just can't > wait that some day Red Hat will want to support a localized version. > > The only problem we've faced so far with the specspo approach is that it's > not regenerated enough times during a beta cicle; just look at the logs and > see how many times it has been regenerated during the 8.0.x days. > Volunteers work on their own free time so the earlier the specspo pot file > is regenerated the bigger the change we'll find some time to update it. > For example, it could use an update right now. What needs "update"? New package additions not extracted into C.po all ready to go for you? Or do you mean that the just translated msgid's have changed in "fuzzy" ways. Yes, package additions *require* addition to C.po in order for the translation process to work. "Fuzzy" is even more complicated, ultimately depends on which of the following entities should "own" the text that appears in msgid's: a) upstream maintainers b) distro packagers/developers c) editors d) translators Any of a) through d) is a possible/reasonable candidate for "ownership". Choose one, and a reasonable process flow that efficiently gets the translations performed and distributed is quite easy. OTOH, choose none or all of the above, and you will have a very complicated, difficult to administer, process, much like Red Hat's current process. Lest there be any mistake: Red Hat has managed to do a quite reasonable job of getting translations for packages. Sure, not every locale is there, sure there's lots of glitches, but overall, I believe the process is pretty sound. Disclaimer: I used to, but not for years, be responsible for Red Hat package i18n. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From wcooley at nakedape.cc Thu Jul 24 16:06:53 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: 24 Jul 2003 09:06:53 -0700 Subject: plaintext imap authentication In-Reply-To: <20030724111457.D17865@devserv.devel.redhat.com> References: <20030724111457.D17865@devserv.devel.redhat.com> Message-ID: <1059062812.10064.162.camel@localhost.localdomain> On Thu, 2003-07-24 at 08:14, Bill Nottingham wrote: > Chris Ricker (kaboom at gatech.edu) said: > > Prior to this first beta, uw-imap was configured in alphas / rawhide with > > plaintext authentication disabled when connecting over unsecured connections > > (ie, pop / imap, but not pops / imaps). > > > > In beta1, uw-imap and dovecot both accept plaintext auth via at least imap > > (didn't try pop). Was it decided that the world's not ready to give up > > plaintext yet after all? Or just an accidental reversion? > > * Fri Jul 11 2003 John Dennis 1:2002d-1 > - bring upto new upstream release 2002d, change SSLTYPE to allow for plain text login again I think it's a sensible move. Disabling plain-text over non-SSL connections would cause no end of support trouble and cost to existing installations. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Tired of spam and viruses in your e-mail? Get the * * Naked Ape Mail Defender! http://nakedape.cc/r/maildefender * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwalsh at redhat.com Thu Jul 24 16:11:30 2003 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 24 Jul 2003 12:11:30 -0400 Subject: Diskless workstations References: <3F1FDDCE.4080702@redhat.com> <1059062597.3380.6.camel@smoogen1.lanl.gov> Message-ID: <3F200532.6070501@redhat.com> This diskless is a single /root directory containing all files and a /.snapshot directory containing files that are specific to the client. (A very small subset). It then uses mount -o bind to mount the snapshot files over the /root files on the client. You need to do a chroot on the server to up2date it or rpm install it. It will not support older versions of RH. It should work on RH9 or greater and it might work on RH8. Dan Stephen Smoogen wrote: >Thanks I will try to look at this next week. What I am trying to figure >out is the best/fastest way to set up new diskless clients that have >'full' installs. > >Currently we have two systems here. > >The first is where /usr and some other directories are stored on the >master tree and then the few remaining (/lib /var /etc /initrd etc) are >seperate per machine. This is very fast to bring up a new machine >because the date to be copied is small (20-40 megs on average). However >it is a pain in the ass to update as all the clients have to be rebuilt >after errata that change /etc, /lib etc occur. > >The second is much more disk intensive but easier to maintain. In this >version each client gets a complete install in an NFS tree. This allows >for a lot of customization per client (some can run 7.1 while others run >9.0). Maintenance is much easier because RPM can be run on each of the >trees seperately. However installs are SLOW because they are either >server side using a chroot anaconda (which I havent gotten working >seamlessly) or the client is doing all the writes via NFS. > > >On Thu, 2003-07-24 at 07:23, Daniel J Walsh wrote: > > >>I have been working on a package called redhat-config-netboot that >>allows you to setup diskless environments >>using NFS, as well as network installations. It is based somewhat off >>of LTSB. It is basically a series of scripts and python code that sets >>up a PXE boot environment and an diskless NFS partition. >> >>ftp://people.redhat.com/dwalsh/netboot >> >>Comments welcome. >> >>Dan >> >>Chuck Wolber wrote: >> >> >> >>> >>> >>> >>> >>>>No we do everything via NFS at the moment. Using a big ramdisk would cut >>>>into why all the machines have so much memory and CPU's. Basically the >>>>idea is that all CPU cycles are local and all data is foreign. The >>>>approach to this seems to follow either SGI or Sun ways of doing >>>>diskless clients. I like the Sun way of doing it (with each client >>>>getting its own tree) versus the SGI where most is common with the >>>>server and clients need a rebuild if server code changes. >>>> >>>> >>>> >>>> >>>Can a user move to another workstation and resume their session? I've seen >>>this done with RFID tags that automatically detach your session if you >>>move away from the terminal and re-attach you when you move closer. >>> >>>-Chuck >>> >>> >>> >>> >>> >> >> >>-- >>Rhl-devel-list mailing list >>Rhl-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/rhl-devel-list >> >> From hp at redhat.com Thu Jul 24 16:11:43 2003 From: hp at redhat.com (Havoc Pennington) Date: Thu, 24 Jul 2003 12:11:43 -0400 Subject: RFC: i18n proposal In-Reply-To: <20030724114226.Q18401@devserv.devel.redhat.com> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> Message-ID: <20030724121143.D32225@devserv.devel.redhat.com> On Thu, Jul 24, 2003 at 11:42:26AM -0400, Jeff Johnson wrote: > Yup, one big file is much easier to hand to a per-locale translator. This is trivial, it shouldn't dictate the overall approach. Ever heard of "cat" ? ;-) > a) there's a change of data type (i.e. > RPM_STRING_TYPE -> RPM_I18NSTRING_TYPE > involved, it's not just adding new text for RPMTAG_NAME or adding > new LongName:/ShortName: tag. In fact, the creation of the data > type was exactly the reason for a major incompatibility. Having > personally survived (but barely) v2 -> v3 -> v4 -> v3 changes > in rpm packaging, I wish not to go there ever again. I wasted > 1 year of my life already discussing the ramifications of the > value contained in byte 5 of an rpm package. Have at it, enjoy, > I have no desire to go there again. I wouldn't do it this way. Another suggestion is to have the gettext hash tables in the package file list (/usr/share/locale/LANG/translation-domain.mo) The translation domain might be in the RPM header. Then a tool such as redhat-config-packages, if the package is installed simply calls bindtextdomain (/usr/share/locale) and uses the gettext hash in-place; if the package is not installed it sucks the gettext hash out of the package and puts it somewhere temporary to use. > My (and Red Hat's at the time) is > specspo is great for distributions but bad for packages. specspo isn't much good for us either, really. It's always out of date and otherwise busted. > IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in > tar/cpio headers. Keep i18n out of packages, please. i18n is already in the packages; if I install Gnumeric, then my Gnumeric has the translations with it. It's just the RPM info itself that isn't translated. An alternate solution is to copy the RPM header information (name, etc.) into a .desktop file that's included in the package, /usr/share/package-descriptions/gnumeric.desktop This could be autogenerated in the spec file from %name etc. There's no genuine difference between this and the above-mentioned approach with /usr/share/locale/LANG/translation-domain.mo, just a different flavor of the same. You can't say translation just breaks if someone has packages from 3 versions of Red Hat, plus some 3rd party packages. Handling that case is a basic requirement we need to address at some point. Havoc From pmmm at rnl.ist.utl.pt Thu Jul 24 16:28:40 2003 From: pmmm at rnl.ist.utl.pt (Pedro Morais) Date: Thu, 24 Jul 2003 17:28:40 +0100 Subject: RFC: i18n proposal In-Reply-To: <20030724120752.R18401@devserv.devel.redhat.com> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <200307241657.32739.pmmm@rnl.ist.utl.pt> <20030724120752.R18401@devserv.devel.redhat.com> Message-ID: <200307241728.40355.pmmm@rnl.ist.utl.pt> > What needs "update"? New package additions not extracted into C.po all > ready to go for you? Or do you mean that the just translated msgid's > have changed in "fuzzy" ways. > > Yes, package additions *require* addition to C.po in order for the > translation process to work. New package additions. Just take a look at the CVS log for (for example) specspo/pt.po. Somehow I can't believe that since 2003/02/24 the only thing that changed in the distro was the spamassassin summary. (2003/07/03). Was happens is that before the release there's a huge specspo update with lots and lots of packages. It'd be better if the file was updated more often. > "Fuzzy" is even more complicated, ultimately depends on which of the > following entities should "own" the text that appears in msgid's: > a) upstream maintainers > b) distro packagers/developers > c) editors > d) translators Uhm... Not the translators, I think. We own the text in the msgstr in our .po file. > Any of a) through d) is a possible/reasonable candidate for "ownership". > > Choose one, and a reasonable process flow that efficiently gets the > translations performed and distributed is quite easy. I would choose b) or c), depending on who wrote the original spec file description. I guess that in rhl-project a) can now be equal to b). > Lest there be any mistake: Red Hat has managed to do a quite reasonable > job of getting translations for packages. Sure, not every locale is there, > sure there's lots of glitches, but overall, I believe the process is > pretty sound. Yes it is. It's just that if the specspo file got some attention earlier it would be much easier for the (voluntary) translators. Pedro Morais From jbj at redhat.com Thu Jul 24 16:30:38 2003 From: jbj at redhat.com (Jeff Johnson) Date: Thu, 24 Jul 2003 12:30:38 -0400 Subject: RFC: i18n proposal In-Reply-To: <20030724121143.D32225@devserv.devel.redhat.com>; from hp@redhat.com on Thu, Jul 24, 2003 at 12:11:43PM -0400 References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> Message-ID: <20030724123038.S18401@devserv.devel.redhat.com> On Thu, Jul 24, 2003 at 12:11:43PM -0400, Havoc Pennington wrote: > On Thu, Jul 24, 2003 at 11:42:26AM -0400, Jeff Johnson wrote: > > Yup, one big file is much easier to hand to a per-locale translator. > > This is trivial, it shouldn't dictate the overall approach. Ever heard > of "cat" ? ;-) > Sure, but I've never heard of uncat. There are other technical issues, such as reducing the size of the corpus (and the translation work involved) by consolidating common strings into single msgid's. Or maybe there's some option to cat that I've missed? > > a) there's a change of data type (i.e. > > RPM_STRING_TYPE -> RPM_I18NSTRING_TYPE > > involved, it's not just adding new text for RPMTAG_NAME or adding > > new LongName:/ShortName: tag. In fact, the creation of the data > > type was exactly the reason for a major incompatibility. Having > > personally survived (but barely) v2 -> v3 -> v4 -> v3 changes > > in rpm packaging, I wish not to go there ever again. I wasted > > 1 year of my life already discussing the ramifications of the > > value contained in byte 5 of an rpm package. Have at it, enjoy, > > I have no desire to go there again. > > I wouldn't do it this way. Another suggestion is to have the gettext > hash tables in the package file list > (/usr/share/locale/LANG/translation-domain.mo) > > The translation domain might be in the RPM header. > > Then a tool such as redhat-config-packages, if the package is > installed simply calls bindtextdomain (/usr/share/locale) and uses the > gettext hash in-place; if the package is not installed it sucks the > gettext hash out of the package and puts it somewhere temporary to > use. > I can/will discuss this process ad nauseum, but I am adamant (particularly if I have to do the work) in keeping i18n out of package headers. I18n does not belong in package headers is my only non-negotiable stand. I'm quite willing to listen to any other approach. > > My (and Red Hat's at the time) is > > specspo is great for distributions but bad for packages. > > specspo isn't much good for us either, really. It's always out of date > and otherwise busted. > You are confusing specspo and the process that creates it. And you have never attempted "drilling". > > IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in > > tar/cpio headers. Keep i18n out of packages, please. > > i18n is already in the packages; if I install Gnumeric, then > my Gnumeric has the translations with it. > > It's just the RPM info itself that isn't translated. > Don't confuse summary/description/group with analogies for how other i18n text is handled. The problem space is very very different wrto rpm summary/description/group. > An alternate solution is to copy the RPM header information > (name, etc.) into a .desktop file that's included in the package, > /usr/share/package-descriptions/gnumeric.desktop > > This could be autogenerated in the spec file from %name etc. > > There's no genuine difference between this and the above-mentioned > approach with /usr/share/locale/LANG/translation-domain.mo, just a > different flavor of the same. > > > You can't say translation just breaks if someone has packages from 3 > versions of Red Hat, plus some 3rd party packages. Handling that case > is a basic requirement we need to address at some point. > That sketchy process is fine by me, as the i18n is not in package metadata, nor does it need to be imho. I can say similar things about Name:, Packager:, Distribution: tags, I don't believe that any of that information belongs in, (note I didn't say "with") rpm metadata either. But let's not get our panties too twisted yet, the (or at least my) goal is to get the maximum amount of software in from of the maximum number of users in as useful a fashion as possible, and I'm quite sure we agree on that goal even if we differ on implementation details. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From smoogen at lanl.gov Thu Jul 24 16:47:00 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 24 Jul 2003 10:47:00 -0600 Subject: Diskless workstations In-Reply-To: <3F200532.6070501@redhat.com> References: <3F1FDDCE.4080702@redhat.com> <1059062597.3380.6.camel@smoogen1.lanl.gov> <3F200532.6070501@redhat.com> Message-ID: <1059065220.3380.17.camel@smoogen1.lanl.gov> Is it is simple to rename .snapshot to soemthing else. The NFS server is a netapp :) On Thu, 2003-07-24 at 10:11, Daniel J Walsh wrote: > This diskless is a single /root directory containing all files and a > /.snapshot directory containing > files that are specific to the client. (A very small subset). It then > uses mount -o bind to mount the > snapshot files over the /root files on the client. You need to do a > chroot on the server to up2date it > or rpm install it. It will not support older versions of RH. It > should work on RH9 or greater and > it might work on RH8. > > Dan > > > Stephen Smoogen wrote: > > >Thanks I will try to look at this next week. What I am trying to figure > >out is the best/fastest way to set up new diskless clients that have > >'full' installs. > > > >Currently we have two systems here. > > > >The first is where /usr and some other directories are stored on the > >master tree and then the few remaining (/lib /var /etc /initrd etc) are > >seperate per machine. This is very fast to bring up a new machine > >because the date to be copied is small (20-40 megs on average). However > >it is a pain in the ass to update as all the clients have to be rebuilt > >after errata that change /etc, /lib etc occur. > > > >The second is much more disk intensive but easier to maintain. In this > >version each client gets a complete install in an NFS tree. This allows > >for a lot of customization per client (some can run 7.1 while others run > >9.0). Maintenance is much easier because RPM can be run on each of the > >trees seperately. However installs are SLOW because they are either > >server side using a chroot anaconda (which I havent gotten working > >seamlessly) or the client is doing all the writes via NFS. > > > > > >On Thu, 2003-07-24 at 07:23, Daniel J Walsh wrote: > > > > > >>I have been working on a package called redhat-config-netboot that > >>allows you to setup diskless environments > >>using NFS, as well as network installations. It is based somewhat off > >>of LTSB. It is basically a series of scripts and python code that sets > >>up a PXE boot environment and an diskless NFS partition. > >> > >>ftp://people.redhat.com/dwalsh/netboot > >> > >>Comments welcome. > >> > >>Dan > >> > >>Chuck Wolber wrote: > >> > >> > >> > >>> > >>> > >>> > >>> > >>>>No we do everything via NFS at the moment. Using a big ramdisk would cut > >>>>into why all the machines have so much memory and CPU's. Basically the > >>>>idea is that all CPU cycles are local and all data is foreign. The > >>>>approach to this seems to follow either SGI or Sun ways of doing > >>>>diskless clients. I like the Sun way of doing it (with each client > >>>>getting its own tree) versus the SGI where most is common with the > >>>>server and clients need a rebuild if server code changes. > >>>> > >>>> > >>>> > >>>> > >>>Can a user move to another workstation and resume their session? I've seen > >>>this done with RFID tags that automatically detach your session if you > >>>move away from the terminal and re-attach you when you move closer. > >>> > >>>-Chuck > >>> > >>> > >>> > >>> > >>> > >> > >> > >>-- > >>Rhl-devel-list mailing list > >>Rhl-devel-list at redhat.com > >>http://www.redhat.com/mailman/listinfo/rhl-devel-list > >> > >> > > > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From wcooley at nakedape.cc Thu Jul 24 16:51:13 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: 24 Jul 2003 09:51:13 -0700 Subject: Diskless workstations In-Reply-To: <1058999623.24452.37.camel@va.local.linuxlobbyist.org> References: <1058996440.11609.24.camel@smoogen1.lanl.gov> <1058999623.24452.37.camel@va.local.linuxlobbyist.org> Message-ID: <1059065472.10064.179.camel@localhost.localdomain> On Wed, 2003-07-23 at 15:33, Paul Iadonisi wrote: > 2) Is it reasonable to ask for a change to anaconda to allow for these > rpms to be installed in this alternate root? It would probably be an > invasive change, as it's not currently done anywhere in anaconda, to the > best of my knowledge, except that the actually installer *does* in fact > install the entire distribution into an alternate root (after, how else > would you do it?). What's different is that now I'm asking for anaconda > to switch gears in the middle of the installation and install a specific > list of packages in a different alternate root. I don't know if it can be done with Anaconda, but you should be able to build the tree by relocating packages, if the packages are built properly and permit relocation. If memory serves, most don't however, which makes relocation mostly useless in these cases. I wonder if it would be horribly broken to change that, perhaps by giving a default Prefix of '/'. This would let you more easily built a tree not intended to be used localy. I can see another benefit of being able to more easily relocate packages: It makes building chroot jails much easier, esp for things that depend on a number of libraries, such as ucd-snmpd. I wonder if it would be possible to specify that a package depends not only on a package name and version, but also that package being installed in a relocated place? I'm thinking of something like: Requires: foo >= x.y; prefix=/var/chroot/bar, baz (This is this inverse of the way we'd use commas and semi-colons in English, but the comma is already in use and I can't think of a better separator.) Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * * * * Good, fast and cheap: Pick all 3! * * * * * * * * Naked Ape Consulting http://nakedape.cc * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwalsh at redhat.com Thu Jul 24 17:12:10 2003 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 24 Jul 2003 13:12:10 -0400 Subject: Diskless workstations References: <3F1FDDCE.4080702@redhat.com> <1059062597.3380.6.camel@smoogen1.lanl.gov> <3F200532.6070501@redhat.com> <1059065220.3380.17.camel@smoogen1.lanl.gov> Message-ID: <3F20136A.6070406@redhat.com> Stephen Smoogen wrote: >Is it is simple to rename .snapshot to soemthing else. The NFS server is >a netapp :) > Not really sure what you are asking. /.snapshot is a directory on the client that mounts a client specific directory on the server. The server directories could be on a netapp server, but you would then have the problem of upgrading over NFS. One other solution would be to have a Diskfull machine that you could upgrade and the rsync to the netapp server. > >On Thu, 2003-07-24 at 10:11, Daniel J Walsh wrote: > > >>This diskless is a single /root directory containing all files and a >>/.snapshot directory containing >>files that are specific to the client. (A very small subset). It then >>uses mount -o bind to mount the >>snapshot files over the /root files on the client. You need to do a >>chroot on the server to up2date it >>or rpm install it. It will not support older versions of RH. It >>should work on RH9 or greater and >>it might work on RH8. >> >>Dan >> >> >>Stephen Smoogen wrote: >> >> >> >>>Thanks I will try to look at this next week. What I am trying to figure >>>out is the best/fastest way to set up new diskless clients that have >>>'full' installs. >>> >>>Currently we have two systems here. >>> >>>The first is where /usr and some other directories are stored on the >>>master tree and then the few remaining (/lib /var /etc /initrd etc) are >>>seperate per machine. This is very fast to bring up a new machine >>>because the date to be copied is small (20-40 megs on average). However >>>it is a pain in the ass to update as all the clients have to be rebuilt >>>after errata that change /etc, /lib etc occur. >>> >>>The second is much more disk intensive but easier to maintain. In this >>>version each client gets a complete install in an NFS tree. This allows >>>for a lot of customization per client (some can run 7.1 while others run >>>9.0). Maintenance is much easier because RPM can be run on each of the >>>trees seperately. However installs are SLOW because they are either >>>server side using a chroot anaconda (which I havent gotten working >>>seamlessly) or the client is doing all the writes via NFS. >>> >>> >>>On Thu, 2003-07-24 at 07:23, Daniel J Walsh wrote: >>> >>> >>> >>> >>>>I have been working on a package called redhat-config-netboot that >>>>allows you to setup diskless environments >>>>using NFS, as well as network installations. It is based somewhat off >>>>of LTSB. It is basically a series of scripts and python code that sets >>>>up a PXE boot environment and an diskless NFS partition. >>>> >>>>ftp://people.redhat.com/dwalsh/netboot >>>> >>>>Comments welcome. >>>> >>>>Dan >>>> >>>>Chuck Wolber wrote: >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>>>No we do everything via NFS at the moment. Using a big ramdisk would cut >>>>>>into why all the machines have so much memory and CPU's. Basically the >>>>>>idea is that all CPU cycles are local and all data is foreign. The >>>>>>approach to this seems to follow either SGI or Sun ways of doing >>>>>>diskless clients. I like the Sun way of doing it (with each client >>>>>>getting its own tree) versus the SGI where most is common with the >>>>>>server and clients need a rebuild if server code changes. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Can a user move to another workstation and resume their session? I've seen >>>>>this done with RFID tags that automatically detach your session if you >>>>>move away from the terminal and re-attach you when you move closer. >>>>> >>>>>-Chuck >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>-- >>>>Rhl-devel-list mailing list >>>>Rhl-devel-list at redhat.com >>>>http://www.redhat.com/mailman/listinfo/rhl-devel-list >>>> >>>> >>>> >>>> >> >> >>-- >>Rhl-devel-list mailing list >>Rhl-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/rhl-devel-list >> >> From m.a.young at durham.ac.uk Thu Jul 24 17:41:41 2003 From: m.a.young at durham.ac.uk (M A Young) Date: Thu, 24 Jul 2003 18:41:41 +0100 (BST) Subject: RPM building section of RHL's developer guide In-Reply-To: <20030724100009.O18401@devserv.devel.redhat.com> Message-ID: On Thu, 24 Jul 2003, Jeff Johnson wrote: > > (aside) I'd like to add the closure check to rpmbuild, what stops me is > that noone is willing to figger means to maintain the equivalent of a > rpmdb-redhat package incrementally. Without that, it's premature to > check for dependency closure in rpmbuild. So the immediate problem is > to establish the need of creating a rpmdb-redhat database so that the > tools necessary to do the job can start being written. What are the problems with doing this with the justdb flag? It seems to me that you could do this automatically, based on the packages in rawhide say, though presumably it can't be that simple or it would already have been done. Michael Young From smoogen at lanl.gov Thu Jul 24 18:09:30 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 24 Jul 2003 12:09:30 -0600 Subject: Diskless workstations In-Reply-To: <3F20136A.6070406@redhat.com> References: <3F1FDDCE.4080702@redhat.com> <1059062597.3380.6.camel@smoogen1.lanl.gov> <3F200532.6070501@redhat.com> <1059065220.3380.17.camel@smoogen1.lanl.gov> <3F20136A.6070406@redhat.com> Message-ID: <1059070170.3380.23.camel@smoogen1.lanl.gov> On Thu, 2003-07-24 at 11:12, Daniel J Walsh wrote: > Stephen Smoogen wrote: > > >Is it is simple to rename .snapshot to soemthing else. The NFS server is > >a netapp :) > > > Not really sure what you are asking. /.snapshot is a directory on the > client that mounts a client specific directory on the server. The > server directories could be on a netapp server, but you would then have > the problem of upgrading over NFS. One other solution would be to have > a Diskfull machine that you could upgrade and the rsync to the netapp > server. > The main reasons were to try and do as much over NFSv3 with TCP as possible. We have found that the clients (400+ workstations) perform much better when we put as much on a netapp as possible and mount things as v3-tcp when possible. Sorry for not saying that earlier. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From mark at mark.mielke.cc Thu Jul 24 18:10:26 2003 From: mark at mark.mielke.cc (Mark Mielke) Date: Thu, 24 Jul 2003 14:10:26 -0400 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <1059048525.4157.270.camel@binkley> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723153541.G19044@devserv.devel.redhat.com> <20030724062626.GA11256@mark.mielke.cc> <1059048525.4157.270.camel@binkley> Message-ID: <20030724181026.GA2112@mark.mielke.cc> On Thu, Jul 24, 2003 at 08:08:45AM -0400, seth vidal wrote: > > I agree with Chris. Although, I don't like the default install configurations > > installing multiple tools that all do the same thing. Perhaps the default > > should be to only provide either cyrus-imap or dovecot? > I disagree in this case. > Cyrus and dovecot handle imap for two different scales of systems right > now. Cyrus being a larger more complex system and dovecot being much > more straightforward. I suspect that a lot more people, in terms of actual desktop installations, would choose dovecot or not dovecot over cyrus-imap. My main peave is with distribution bloat. I hate having 3 or 4 implementations of the same thing, especially when I don't use any of them. Having the RPM's on the CD is good enough for me. I can install it if I really want it. I assume that a system that required capacity and scalability, that wanted to use cyrus-imap, would have a competent enough system administrator to execute 'rpm -Uvh cyrus-imap...' after installation. :-) mark -- mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ From hp at redhat.com Thu Jul 24 18:22:41 2003 From: hp at redhat.com (Havoc Pennington) Date: Thu, 24 Jul 2003 14:22:41 -0400 Subject: RFC: i18n proposal In-Reply-To: <20030724123038.S18401@devserv.devel.redhat.com> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <20030724123038.S18401@devserv.devel.redhat.com> Message-ID: <20030724142240.F32225@devserv.devel.redhat.com> On Thu, Jul 24, 2003 at 12:30:38PM -0400, Jeff Johnson wrote: > Sure, but I've never heard of uncat. There are other technical issues, > such as reducing the size of the corpus (and the translation work involved) > by consolidating common strings into single msgid's. > > Or maybe there's some option to cat that I've missed? I'm pretty sure the utilities that come with gettext can do this kind of thing. (merge po files) Unmerging is just a matter of scanning for msgid's found in a given package, it should be trivial. > I can/will discuss this process ad nauseum, but I am adamant (particularly > if I have to do the work) in keeping i18n out of package headers. > > I18n does not belong in package headers is my only non-negotiable stand. > I'm quite willing to listen to any other approach. Oh I could care less if it's in the headers or not ;-) I just want it in the package somewhere, rather than having a "central registry" package with all the translations. Packages should be self-contained (well, other than dependencies, but I don't think "Requires: specspo = X.Y" would go over well). Havoc From jbj at redhat.com Thu Jul 24 18:26:49 2003 From: jbj at redhat.com (Jeff Johnson) Date: Thu, 24 Jul 2003 14:26:49 -0400 Subject: RFC: i18n proposal In-Reply-To: <20030724142240.F32225@devserv.devel.redhat.com>; from hp@redhat.com on Thu, Jul 24, 2003 at 02:22:41PM -0400 References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <20030724123038.S18401@devserv.devel.redhat.com> <20030724142240.F32225@devserv.devel.redhat.com> Message-ID: <20030724142649.U18401@devserv.devel.redhat.com> On Thu, Jul 24, 2003 at 02:22:41PM -0400, Havoc Pennington wrote: > Oh I could care less if it's in the headers or not ;-) > > I just want it in the package somewhere, rather than having a "central > registry" package with all the translations. Packages should be > self-contained (well, other than dependencies, but I don't think > "Requires: specspo = X.Y" would go over well). > s/it in/it with/ and we're on the same page. Otherwise, it's time to get the snake oil out and wrestle. Wheee! 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From skvidal at phy.duke.edu Thu Jul 24 18:32:43 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 24 Jul 2003 14:32:43 -0400 Subject: RFC: i18n proposal In-Reply-To: <20030724142649.U18401@devserv.devel.redhat.com> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <20030724123038.S18401@devserv.devel.redhat.com> <20030724142240.F32225@devserv.devel.redhat.com> <20030724142649.U18401@devserv.devel.redhat.com> Message-ID: <1059071563.9358.92.camel@opus.phy.duke.edu> On Thu, 2003-07-24 at 14:26, Jeff Johnson wrote: > On Thu, Jul 24, 2003 at 02:22:41PM -0400, Havoc Pennington wrote: > > Oh I could care less if it's in the headers or not ;-) > > > > I just want it in the package somewhere, rather than having a "central > > registry" package with all the translations. Packages should be > > self-contained (well, other than dependencies, but I don't think > > "Requires: specspo = X.Y" would go over well). > > > > s/it in/it with/ and we're on the same page. Otherwise, it's time to get > the snake oil out and wrestle. Wheee! > MUST.... STOP.... MENTAL... IMAGE... arggggggggggggggggggggh -sv From smoogen at lanl.gov Thu Jul 24 18:51:28 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: 24 Jul 2003 12:51:28 -0600 Subject: RFC: i18n proposal In-Reply-To: <1059071563.9358.92.camel@opus.phy.duke.edu> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <20030724123038.S18401@devserv.devel.redhat.com> <20030724142240.F32225@devserv.devel.redhat.com> <20030724142649.U18401@devserv.devel.redhat.com> <1059071563.9358.92.camel@opus.phy.duke.edu> Message-ID: <1059072687.3380.33.camel@smoogen1.lanl.gov> On Thu, 2003-07-24 at 12:32, seth vidal wrote: > On Thu, 2003-07-24 at 14:26, Jeff Johnson wrote: > > On Thu, Jul 24, 2003 at 02:22:41PM -0400, Havoc Pennington wrote: > > > Oh I could care less if it's in the headers or not ;-) > > > > > > I just want it in the package somewhere, rather than having a "central > > > > s/it in/it with/ and we're on the same page. Otherwise, it's time to get > > the snake oil out and wrestle. Wheee! > > > > MUST.... > STOP.... > MENTAL... > IMAGE... > arggggggggggggggggggggh > Tickets for the snake oil match will be sold at ticketmaster. The event will be held at the collesium right before the SCO vs Lions match. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From jbj at redhat.com Thu Jul 24 19:04:22 2003 From: jbj at redhat.com (Jeff Johnson) Date: Thu, 24 Jul 2003 15:04:22 -0400 Subject: RPM building section of RHL's developer guide In-Reply-To: ; from m.a.young@durham.ac.uk on Thu, Jul 24, 2003 at 06:41:41PM +0100 References: <20030724100009.O18401@devserv.devel.redhat.com> Message-ID: <20030724150422.V18401@devserv.devel.redhat.com> On Thu, Jul 24, 2003 at 06:41:41PM +0100, M A Young wrote: > On Thu, 24 Jul 2003, Jeff Johnson wrote: > > > > > (aside) I'd like to add the closure check to rpmbuild, what stops me is > > that noone is willing to figger means to maintain the equivalent of a > > rpmdb-redhat package incrementally. Without that, it's premature to > > check for dependency closure in rpmbuild. So the immediate problem is > > to establish the need of creating a rpmdb-redhat database so that the > > tools necessary to do the job can start being written. > > What are the problems with doing this with the justdb flag? It seems to me > that you could do this automatically, based on the packages in rawhide > say, though presumably it can't be that simple or it would already have > been done. > Yup, --justdb works quite well. The issue is who is willing to maintain, not whether rpm supports. Different problems, one process, the other mechanism. Further refinements on mechanism are quite possible, it's not like adding the line of code rc = rpmdbAdd(rpmdb_redhatdb, buildtime, h, NULL, NULL); is hard for me to implement in rpm or anything. But that is only mechanism, what's needed is thought on the policy on when to do that, and which database to choose. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From angles at aminvestments.com Thu Jul 24 20:09:39 2003 From: angles at aminvestments.com ( Angles Puglisi) Date: Thu, 24 Jul 2003 20:09:39 +0000 Subject: Inclusion of cyrus-imapd and mimedefang (plus webmail) Message-ID: <20030724.gGl.88076300@www.dudex.net> If you'll give it consideration I could rip AngleMail out of phpGroupWare into a standalone webmail. (I'd do it for the fame of the few people who know me ...) www.anglemail.org there is a demo of an older version at: https://demo.axisgroupware.org:4430/login.php check out the email part of the demo. Paul Iadonisi (pri.rhl1 at iadonisi.to) wrote: > >On Wed, Jul 23, 2003 at 03:35:41PM -0400, Bill Nottingham wrote: > >[snip] > >> We're actually considering for this upcoming release: >> >> - adding in cyrus-imap >> - taking out uw-imap >> >> Opinions? > > My vote is definite thumbs up for cyrus-imap. Simon Matter's rpms have >also been well put together (and have only been getting better) and would >probably only require minor tweaks to fit into Red Hat Linux nicely. > On a sort of related note, I'd like to see something better than >squirrelmail (or an additional choice) for webmail. I know that comment >might generate some flames, but my problem with it is that it claims to be >modular, but I have a hard time calling something modular when most of >the additional modules I've seen require modification of some other source >files. Maybe it's bad module design, but I suspect that's not the case. >I'd rather see something that treats modules the way, for example, drupal >does (http://www.drupal.org/). Drop the right .module file in modules >directory and add whatever other files you need to, and the function is >added. No mucking around with core source files. > I tried out squirrelmail mostly because I didn't want to learn sieve >(I can be lazy at times :-)) and saw that it had a sieve module. But then >I got frustrated because I could just apply the errata for squirrelmail and >expect everything to work. Sieve is but *one* of the reasons I like >cyrus-imapd. It would be nice to have a webmail program (that handled >sieve or had extensions for it) that was a little easier to deal with >from admin point of view. > Alternatives? Not sure. Horde's IMP, possibly, but I don't know how >well it meets my above criteria, and I know it's a whole suite of web apps, >so it would have to be looked a more closely. Don't want TOO much cruft. > >-- >-Paul Iadonisi > Senior System Administrator > Red Hat Certified Engineer / Local Linux Lobbyist > Ever see a penguin fly? -- Try Linux. > GPL all the way: Sell services, don't lease secrets > > >http://www.redhat.com/mailman/listinfo/rhl-devel-list -- That's "angle" as in geometry. From jeremyp at pobox.com Thu Jul 24 20:20:37 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: 24 Jul 2003 16:20:37 -0400 Subject: my thoughts on package management In-Reply-To: <20030724201247.GF32340@iadonisi.to> References: <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <200307230515.13765.ali@packetknife.com> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723233050.00aec490@127.0.0.1> <20030724201247.GF32340@iadonisi.to> Message-ID: <1059078036.5247.56.camel@jeremy.dtcc.cc.nc.us> On Thu, 2003-07-24 at 16:12, Paul Iadonisi wrote: > Although I don't think anyone at Red Hat is going to tell you 'shut up,' > I don't think that rpm/up2date has ever included the promise of being able > to account for custom changes users have made. Read the section in the release > notes of the past several releases on the Ximian desktop for evidence of this. > Take a look at other vendors, for instance. Ever decide that Solaris 'ls' > command was too braindead for your taste and replace it with the GNU coreutils > (yes, I know, an unlikely scenario, but bear with me)? Then try to apply a > patch from Sun that happens to include the ls binary. Your stuck there, too. Actually, I used to do that regularly when I was responisble for some Solaris boxes. I just installed the GNU tools in another location -- say /usr/gnu/bin -- and modified my $PATH to look for them before the native OS versions. Very simple, and doesn't conflick with the Sun patches at all. However, that's not as easy with something as complex as Ximian Desktop, and obviously you have to be responsible for keep your versions up to date. (sunfreeware.com makes that easier) > My examples aren't exactly perfect, but my point is that given that the > resources that Red Hat has, (even with the new future addition of outside > package maintainers), it's very like not going to be enough to meet the needs > you describe. Some packages have an inordinate number of ways they can be > built and Red Hat taking on the responsibility of providing upgrade > paths for all possibly contingencies is probably corporate suicide. > A source based distribution is, in some cases, exactly what some people need. Agreed. I find these conversations on mailing lists a bit frustrating, because some people will join in and be very vocal about their specific needs, which may or may not match what 99% of people use. [not focusing this at Rober specifically, but in general]. How can we, as possible contributors to the new Red Hat Linux Project, really get a feel for what the majority of people want? If only the most vocal come to the mailing lists, or bugzilla, and make their specific needs know, won't the silent majority be ignored? --Jeremy -- /---------------------------------------------------------------------\ | Jeremy Portzer jeremyp at pobox.com trilug.org/~jeremy | | GPG Fingerprint: 712D 77C7 AB2D 2130 989F E135 6F9F F7BC CC1A 7B92 | \---------------------------------------------------------------------/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dax at gurulabs.com Thu Jul 24 20:22:09 2003 From: dax at gurulabs.com (Dax Kelson) Date: 24 Jul 2003 14:22:09 -0600 Subject: RFE: Other "Everything" installs Message-ID: <1059078129.2622.67.camel@mentor.gurulabs.com> I typically do Everything installs on my personal workstations. Simplifies life greatly. However, it would be nice if there were: "Everything ONLY English" (ie, no foreign language support) "Everything NO Development" Comments? From elanthis at awesomeplay.com Thu Jul 24 20:29:35 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: 24 Jul 2003 16:29:35 -0400 Subject: RFE: Other "Everything" installs In-Reply-To: <1059078129.2622.67.camel@mentor.gurulabs.com> References: <1059078129.2622.67.camel@mentor.gurulabs.com> Message-ID: <1059078575.4326.19.camel@smiddle.civic.twp.ypsilanti.mi.us> On Thu, 2003-07-24 at 16:22, Dax Kelson wrote: > I typically do Everything installs on my personal workstations. > Simplifies life greatly. > > However, it would be nice if there were: > > "Everything ONLY English" (ie, no foreign language support) > > "Everything NO Development" > > Comments? Definitely dont' think that's a good idea. It solves perhaps your problem, but I'm there are many users who have other specific package sets they'd love install options for too. What we'd end up with is an Everything menu with tons of semi-Everythings, covering everything imaginable, even tho they aren't Everything. ~,^ Seriously, it's not that much work to just select the package groups. If you do find yourself spending too much time on it, quit reinstalling your machines so often. ;-) Or just use Kickstart. > > > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From jbj at redhat.com Thu Jul 24 20:29:13 2003 From: jbj at redhat.com (Jeff Johnson) Date: Thu, 24 Jul 2003 16:29:13 -0400 Subject: my thoughts on package management In-Reply-To: <20030724201247.GF32340@iadonisi.to>; from pri.rhl1@iadonisi.to on Thu, Jul 24, 2003 at 04:12:47PM -0400 References: <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <200307230515.13765.ali@packetknife.com> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723233050.00aec490@127.0.0.1> <20030724201247.GF32340@iadonisi.to> Message-ID: <20030724162913.Z18401@devserv.devel.redhat.com> On Thu, Jul 24, 2003 at 04:12:47PM -0400, Paul Iadonisi wrote: > On Thu, Jul 24, 2003 at 12:07:39AM -0700, Robert LeBlanc wrote: > > [snip] > > > I'd like to see a more flexible, versatile approach in any > > "next-generation" RPM/up2date system, and that's what I'm trying to > > petition for here. Either a Gentoo-like system that can build applications > > at install time with user-specified options selected, or at least a means > > of making the option set visible somewhere within the RPM package, so that > > when updates are downloaded for those packages the up2date process can > > search for RPMs built with those particular options. I'm sure there are > > other solutions that would work as well, given a little time and thought, > > and a willingness to make changes on this level. > > To be frank, I think you really are looking for something more like Gentoo. > Red Hat is doing its best to handle the 95% - 99% use cases. In my own, > somewhat biased opinion, I think they do a pretty good job of it. But I > have run into similar things that you have (applying a mysql patch to > sendmail and building the cyrus-sasl-mysql module as two examples). > There's room for moving closer to a Gentoo approach, but typically the problem revolves around a) how to set up a build system b) how to use rpmbuild to package Both a) and b) are simple with a rpm package management domain, but entirely outside of the scope of rpm if/when you want to do your own thing differently. > > If, on the other hand, you really feel this is a problem that doesn't > > exist, or one that would require more work to fix than you're willing to > > invest, just say so and I'll shut up. I'm only trying to help make the > > RPM/up2date system live up to its initial promise, and if indeed you > > believe it's as good as it can get I'll drop the matter and go back to my > > tarballs, or to Gentoo. > > Although I don't think anyone at Red Hat is going to tell you 'shut up,' > I don't think that rpm/up2date has ever included the promise of being able > to account for custom changes users have made. Read the section in the release > notes of the past several releases on the Ximian desktop for evidence of this. Up2date (and rpm underneath it) depends solely on the concepts (N == name, E == epoch, V== version, etc) a) package N to choose what to compare with. b) "newer" as in EVR version comparison. c) whether to use rpm for software mgmt at all. Both a) and b) are quite mangeable for customization. b) in particular pretty much means that you have to choose a release that is newer than the RHL starting point, but "older" than any release number that rpm is likely to choose. This preserves the ability to upgrade, see "vepoch" in the package building guidelines at http://fedora.us for a perfectly reasonable rule based release naming scheme that has the right properties. The other piece that might be needed is to configure up2date to Never remove or upgrade this package. (i.e. because it's customised). Already there, breaks on paradigm shifts, but Red Hat does it's best to avoid aurprises. Sure there's surprises, NPTL comes instantly to mind, but there are as few as is humanly possible. c) is insoluble in general, way outside the scope of rpm package management as currently implemented. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From m.a.young at durham.ac.uk Thu Jul 24 20:36:07 2003 From: m.a.young at durham.ac.uk (M A Young) Date: Thu, 24 Jul 2003 21:36:07 +0100 (BST) Subject: RPM building section of RHL's developer guide In-Reply-To: <20030724150422.V18401@devserv.devel.redhat.com> Message-ID: On Thu, 24 Jul 2003, Jeff Johnson wrote: > Yup, --justdb works quite well. The issue is who is willing to maintain, > not whether rpm supports. Different problems, one process, the other mechanism. I think we were thinking along different lines. I was thinking of a process which runs maybe daily on the central rpm repository, generates an rpmdb-redhat type database, and uses this to report back dependency errors to the package maintainer, which should be relatively easy to do with the existing rpm, and probably very little additional programming. It also means it would be a QA problem setting it up, rather than yours! To achieve the same thing at build time is more difficult, because anyone building an rpm would probably need an up to date copy of the master rpmdb so they know the latest situation on any package they have dependencies, and there would probably have to be some central checking anyway, so that you can spot inconsistencies based on simultaneous updates or if package is withdrawn. Moreover if you require such a check, there might be problems if someone has to update 2 interdependent packages at the same time. Other central checking that would be useful would be whether there are any dependency difficulties with regard to the last release, eg. are the package versions strictly increasing, and are all non-superceded packages deliberate or should they be obsoleted by another package. Michael Young From dax at gurulabs.com Thu Jul 24 20:39:52 2003 From: dax at gurulabs.com (Dax Kelson) Date: 24 Jul 2003 14:39:52 -0600 Subject: RFE: Other "Everything" installs In-Reply-To: <1059078575.4326.19.camel@smiddle.civic.twp.ypsilanti.mi.us> References: <1059078129.2622.67.camel@mentor.gurulabs.com> <1059078575.4326.19.camel@smiddle.civic.twp.ypsilanti.mi.us> Message-ID: <1059079191.2622.72.camel@mentor.gurulabs.com> On Thu, 2003-07-24 at 14:29, Sean Middleditch wrote: > On Thu, 2003-07-24 at 16:22, Dax Kelson wrote: > > I typically do Everything installs on my personal workstations. > > Simplifies life greatly. > > > > However, it would be nice if there were: > > > > "Everything ONLY English" (ie, no foreign language support) > > > > "Everything NO Development" > > > > Comments? > > Seriously, it's not that much work to just select the package groups. If you go through and click every checkbox available to you in the package groups, what you end up with is vastly different then an Everything install. At the same time, Everything install can be too much. There is no middle ground. Personally, I would install my machines with "Everything ONLY English". From elanthis at awesomeplay.com Thu Jul 24 20:45:55 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: 24 Jul 2003 16:45:55 -0400 Subject: RFE: Other "Everything" installs In-Reply-To: <1059079191.2622.72.camel@mentor.gurulabs.com> References: <1059078129.2622.67.camel@mentor.gurulabs.com> <1059078575.4326.19.camel@smiddle.civic.twp.ypsilanti.mi.us> <1059079191.2622.72.camel@mentor.gurulabs.com> Message-ID: <1059079555.4343.21.camel@smiddle.civic.twp.ypsilanti.mi.us> On Thu, 2003-07-24 at 16:39, Dax Kelson wrote: > Personally, I would install my machines with "Everything ONLY English". Again, then, just use Kickstart. No sense in adding 10 billion install options for each and every unique Redhat user when a good solution exists for users to make their own install sets. ;-) > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From scottb at bxwa.com Thu Jul 24 20:50:53 2003 From: scottb at bxwa.com (Scott Becker) Date: Thu, 24 Jul 2003 13:50:53 -0700 Subject: RFE: Other "Everything" installs In-Reply-To: <1059079191.2622.72.camel@mentor.gurulabs.com> References: <1059078129.2622.67.camel@mentor.gurulabs.com> <1059078575.4326.19.camel@smiddle.civic.twp.ypsilanti.mi.us> <1059079191.2622.72.camel@mentor.gurulabs.com> Message-ID: <3F2046AD.3070805@bxwa.com> How about: a "Everything" b "Everything in the selected language" or making Everything do just packages for the selected language and then to get **everything** you just select all languages >Personally, I would install my machines with "Everything ONLY English". > > > > From katzj at redhat.com Thu Jul 24 20:54:15 2003 From: katzj at redhat.com (Jeremy Katz) Date: 24 Jul 2003 16:54:15 -0400 Subject: RFE: Other "Everything" installs In-Reply-To: <1059078129.2622.67.camel@mentor.gurulabs.com> References: <1059078129.2622.67.camel@mentor.gurulabs.com> Message-ID: <1059080055.31800.74.camel@mirkwood.devel.redhat.com> On Thu, 2003-07-24 at 16:22, Dax Kelson wrote: > "Everything ONLY English" (ie, no foreign language support) This really sucks from a user point of view. I'd be really curious to see what you define as foreign language support. Where do you draw the line? Translations, fonts, input methods, programs that are useful mainly because they support specific locales better? Everything except some stuff has always seemed like a silly thing to me because everybody is going to have a different idea of what "some stuff" is for them. Jeremy From hp at redhat.com Thu Jul 24 21:19:38 2003 From: hp at redhat.com (Havoc Pennington) Date: Thu, 24 Jul 2003 17:19:38 -0400 Subject: my thoughts on package management In-Reply-To: <20030724203139.GG32340@iadonisi.to> References: <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <200307230515.13765.ali@packetknife.com> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723233050.00aec490@127.0.0.1> <20030724201247.GF32340@iadonisi.to> <1059078036.5247.56.camel@jeremy.dtcc.cc.nc.us> <20030724203139.GG32340@iadonisi.to> Message-ID: <20030724171938.T32225@devserv.devel.redhat.com> On Thu, Jul 24, 2003 at 04:31:39PM -0400, Paul Iadonisi wrote: > Havoc Pennington has made exactly this point at least a few times in > various forums when people argue about user interfaces. What many > people on these mailing lists forget is that the user base of a distribution > is typically two or three orders of magnitude larger than the mailing > list participation. The kind of people participating in the mailing lists > are typically not representative of the entire user base (rhl-list may be an > exception, I don't know). Another kind of bias is that people only complain about what they don't like, very few people ever praise what they do like. That is if you have 100 people who like it how it is and 10 people who don't, you'll get 10 complaints and 1 praise, which looks like a 10-1 vote for changing it. You find out the reality when you change it and suddenly get 100 complaints and 0 praise. ;-) Anyway, this is why you really have to understand the goals and rationale for why the software is how it is, otherwise you sort of just keep changing it back and forth in response to complaints. > I like choice too, which is why I typically replace metacity with sawfish > on my systems (sorry, Havoc, I know I keep jabbing you with that. hehe ;-)), I don't mind one bit, though. ;-) I understand there are tradeoffs and everyone will use what they like, and that's all good. Havoc From rjl at renaissoft.com Thu Jul 24 21:10:02 2003 From: rjl at renaissoft.com (Robert LeBlanc) Date: Thu, 24 Jul 2003 14:10:02 -0700 Subject: my thoughts on package management In-Reply-To: <1059078036.5247.56.camel@jeremy.dtcc.cc.nc.us> References: <20030724201247.GF32340@iadonisi.to> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <200307230515.13765.ali@packetknife.com> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723233050.00aec490@127.0.0.1> <20030724201247.GF32340@iadonisi.to> Message-ID: <5.1.1.6.2.20030724140500.05c47250@127.0.0.1> At 13:20 2003/07/24, Jeremy Portzer wrote: >On Thu, 2003-07-24 at 16:12, Paul Iadonisi wrote: > >I find these conversations on mailing lists a bit frustrating, because >some people will join in and be very vocal about their specific needs, >which may or may not match what 99% of people use. [not focusing this >at Rober specifically, but in general]. How can we, as possible >contributors to the new Red Hat Linux Project, really get a feel for >what the majority of people want? If only the most vocal come to the >mailing lists, or bugzilla, and make their specific needs know, won't >the silent majority be ignored? The trouble, I suppose, is that unless you take a stab at defining what the silent majority likes/wants, people posting to mailing lists like this one won't know ahead of time whether their wishlists are "already spoken for" or "clearly in the minority". Trying to do that would just ensure that you get no useful feedback from anyone, since the ones who see their views already represented in your list won't feel the need to say anything, and the ones who *don't* see their views represented will get the impression that their views aren't welcome. From my perspective as an old-time sysadmin, I find it hard to imagine that I'm truly in the From newren at math.utah.edu Thu Jul 24 21:53:30 2003 From: newren at math.utah.edu (Elijah P Newren) Date: 24 Jul 2003 15:53:30 -0600 Subject: BitTorrent enabled downloads & updates Message-ID: <1059083610.23202.68.camel@amr.math.utah.edu> Sorry for the cross-posting. I originally posted this idea on #fedora at irc.freenode.net and Anvil suggested I email these two lists with this idea. My idea was the following: Have apt-get/yum/up2date/ use BitTorrent for file downloads. This would have the following benefits: Users would get a much faster download rate (at least, that's been my experience for the downloads I've done with BitTorrent). It would alleviate the 'which mirror should I use' problem. Anyone could easily become a mirror. It should keep any specific mirror from getting overloaded. I figured this made so much sense that someone else has already thought of it and perhaps already implemented it. Anyone know if that's the case? If not, does that idea sound interesting to others? Elijah From rjl at renaissoft.com Thu Jul 24 22:07:20 2003 From: rjl at renaissoft.com (Robert LeBlanc) Date: Thu, 24 Jul 2003 15:07:20 -0700 Subject: my thoughts on package management In-Reply-To: <5.1.1.6.2.20030724140500.05c47250@127.0.0.1> References: <1059078036.5247.56.camel@jeremy.dtcc.cc.nc.us> <20030724201247.GF32340@iadonisi.to> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <200307230515.13765.ali@packetknife.com> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723233050.00aec490@127.0.0.1> <20030724201247.GF32340@iadonisi.to> Message-ID: <5.1.1.6.2.20030724144706.01a83c60@127.0.0.1> (Apologies for the previous partial post :) >At 13:20 2003/07/24, Jeremy Portzer wrote: >>On Thu, 2003-07-24 at 16:12, Paul Iadonisi wrote: >> >>I find these conversations on mailing lists a bit frustrating, because >>some people will join in and be very vocal about their specific needs, >>which may or may not match what 99% of people use. [not focusing this >>at Rober specifically, but in general]. How can we, as possible >>contributors to the new Red Hat Linux Project, really get a feel for >>what the majority of people want? If only the most vocal come to the >>mailing lists, or bugzilla, and make their specific needs know, won't >>the silent majority be ignored? The trouble, I suppose, is that unless you take a stab at defining what the silent majority likes/wants, people posting to mailing lists like this one won't know ahead of time whether their wishlists are "already spoken for" or "clearly in the minority". Trying to do that would just ensure that you get no useful feedback from anyone, since the ones who see their views already represented in your list won't feel the need to say anything, and the ones who *don't* see their views represented will get the impression that their views aren't welcome. It's also typically the case that for any group of people sharing an opinion or view, there'll be someone from that group who speaks up to represent them. When one person posts to a mailing list like this, there's no easy way to tell how many people she's representing. That one poster could be (unconsciously) representing a concern that hundreds or thousands of other people share, in the proverbial "tip of the iceberg" scenario. Just because the more vocal people on the list don't share that poster's concerns doesn't mean those concerns aren't represented in that "silent majority" out there. From my perspective as an old-time sysadmin, I find it hard to imagine that I'm truly the only one with this particular view, or that this view is shared by only a negligibly small portion of the Linux-using market. Rather, I suspect that most of those who share my concerns have simply written off Red Hat entirely already, on the theory that they'll "look at it again if/when Red Hat fixes ". They remain pessimistic about their ability to effect changes, and are quite used to having to do things on their own (i.e. "the old way"), so coming to lists like this to speak up with feature requests is not first- or second-nature to them, and thus they fulfill their own prophecies. They (like myself) will likely continue to deploy RHL on workstations, but will continue to avoid it in the server room. This might not be a problem to Red Hat, if indeed the company's focus remains on the desktop market, but from what I've seen of their marketing materials they also seem eager to compete at the enterprise level as well, so this *should* be a concern to them in that case. Have they polled enterprise sysadmins lately? Unfortunately comments like the one quoted above are virtually guaranteed to stifle input from anyone who fears their concerns might be too divergent from what they perceive the "silent majority" to want. Such comments create an atmosphere that suggests that the spectrum of acceptable opinion is rather narrow, and that outside views are undesirable and unwelcome. Robert LeBlanc From kaboom at gatech.edu Thu Jul 24 23:09:20 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Thu, 24 Jul 2003 17:09:20 -0600 (MDT) Subject: my thoughts on package management In-Reply-To: <20030724171938.T32225@devserv.devel.redhat.com> References: <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <200307230515.13765.ali@packetknife.com> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723233050.00aec490@127.0.0.1> <20030724201247.GF32340@iadonisi.to> <1059078036.5247.56.camel@jeremy.dtcc.cc.nc.us> <20030724203139.GG32340@iadonisi.to> <20030724171938.T32225@devserv.devel.redhat.com> Message-ID: On Thu, 24 Jul 2003, Havoc Pennington wrote: > Another kind of bias is that people only complain about what they > don't like, very few people ever praise what they do like. > > That is if you have 100 people who like it how it is and 10 people who > don't, you'll get 10 complaints and 1 praise, which looks like a 10-1 > vote for changing it. > > You find out the reality when you change it and suddenly get 100 > complaints and 0 praise. ;-) > > Anyway, this is why you really have to understand the goals and > rationale for why the software is how it is, otherwise you sort of > just keep changing it back and forth in response to complaints. I was actually thinking about this last night when I ran across a "praise bug" in bugzilla. The problem is that there's no real place for praise ;-). There's bugzilla for logging all the "this sucks" stuff, but there's no similar constant surveying / tracking of what people like.... Maybe it would be a good idea to catalog periodically? later, chris From goeran at uddeborg.se Thu Jul 24 23:12:24 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran?= Uddeborg) Date: Fri, 25 Jul 2003 01:12:24 +0200 Subject: RFC: i18n proposal In-Reply-To: <20030724142240.F32225@devserv.devel.redhat.com> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <20030724123038.S18401@devserv.devel.redhat.com> <20030724142240.F32225@devserv.devel.redhat.com> Message-ID: <16160.26584.750948.633307@uebn.uddeborg.se> Havoc Pennington writes: > On Thu, Jul 24, 2003 at 12:30:38PM -0400, Jeff Johnson wrote: > > Sure, but I've never heard of uncat. There are other technical issues, > > such as reducing the size of the corpus (and the translation work involved) > > by consolidating common strings into single msgid's. > > > > Or maybe there's some option to cat that I've missed? > > I'm pretty sure the utilities that come with gettext can do this kind > of thing. (merge po files) Exactly, "msgmerge " would do that for you. Repeat for each "". From goeran at uddeborg.se Thu Jul 24 23:18:15 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran?= Uddeborg) Date: Fri, 25 Jul 2003 01:18:15 +0200 Subject: RFC: i18n proposal In-Reply-To: <20030724114226.Q18401@devserv.devel.redhat.com> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> Message-ID: <16160.26935.272814.779571@uebn.uddeborg.se> Jeff Johnson writes: > IMHO, the work is best left to for-pay translators I wouldn't mind that! > (and editors, hackers are not necessarily the best redactors) Oh! Thought there would be a catch! :-) From pri.rhl1 at iadonisi.to Thu Jul 24 23:32:49 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 24 Jul 2003 19:32:49 -0400 Subject: my thoughts on package management In-Reply-To: <5.1.1.6.2.20030724144706.01a83c60@127.0.0.1> References: <1059078036.5247.56.camel@jeremy.dtcc.cc.nc.us> <20030724201247.GF32340@iadonisi.to> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <200307230515.13765.ali@packetknife.com> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723233050.00aec490@127.0.0.1> <20030724201247.GF32340@iadonisi.to> <5.1.1.6.2.20030724144706.01a83c60@127.0.0.1> Message-ID: <1059089569.488.18.camel@va.local.linuxlobbyist.org> On Thu, 2003-07-24 at 18:07, Robert LeBlanc wrote: [snip] > Unfortunately comments like the one quoted above are virtually guaranteed > to stifle input from anyone who fears their concerns might be too divergent > from what they perceive the "silent majority" to want. Such comments > create an atmosphere that suggests that the spectrum of acceptable opinion > is rather narrow, and that outside views are undesirable and unwelcome. Careful with your quoting, there! Your 'snipping' made it look like I posted what you are responding to, but it was actually Jeremy Portzer. Just so it's clear, I tend to agree that these conversations are fine on these lists. They don't annoy me (though, I do understand Jeremy's annoyance -- just a different perspective), as long as they don't drag on too long with no apparent progress. But that goes for any topic. I don't know for certain, but I think it's Sun that has contributed a bunch of resources to do some usability studies for GNOME, so it's not like the "silent majority" is completely silent. You just have to actively go other there and get some feedback from them, which might have already been done by Sun and others. And for all I dislike about Microsoft, I think it's fair to say that the company has done quite extensive research in this area, too. As much as geeks like me dislike the limited choice in the Windows world, we don't need to throw out the good with the bad and can extract some good ideas about the user interface design for our own use. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From goeran at uddeborg.se Thu Jul 24 23:33:40 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran?= Uddeborg) Date: Fri, 25 Jul 2003 01:33:40 +0200 Subject: RFC: i18n proposal In-Reply-To: <20030724121143.D32225@devserv.devel.redhat.com> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> Message-ID: <16160.27860.553257.398777@uebn.uddeborg.se> Havoc Pennington writes: > I wouldn't do it this way. Another suggestion is to have the gettext > hash tables in the package file list > (/usr/share/locale/LANG/translation-domain.mo) > > The translation domain might be in the RPM header. > > Then a tool such as redhat-config-packages, if the package is > installed simply calls bindtextdomain (/usr/share/locale) and uses the > gettext hash in-place; if the package is not installed it sucks the > gettext hash out of the package and puts it somewhere temporary to > use. I'm trying to follow this discussion, but I don't quite understand what you suggest here. Partly I'm confused about what is variables, and what is literal. If we take an example: Swedish translations and coreutils. The translations of coreutils' own messages resides in /usr/share/locale/sv/LC_MESSAGES/coreutils.mo. What would be the file name of the file containing the Swedish translation of the %description of the RPM package coreutils? And what other translations would that file contain? From hp at redhat.com Thu Jul 24 23:37:45 2003 From: hp at redhat.com (Havoc Pennington) Date: Thu, 24 Jul 2003 19:37:45 -0400 Subject: RFC: i18n proposal In-Reply-To: <16160.27860.553257.398777@uebn.uddeborg.se> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> Message-ID: <20030724193745.D29567@devserv.devel.redhat.com> On Fri, Jul 25, 2003 at 01:33:40AM +0200, G?ran Uddeborg wrote: > If we take an example: Swedish translations and coreutils. The > translations of coreutils' own messages resides in > /usr/share/locale/sv/LC_MESSAGES/coreutils.mo. What would be the file > name of the file containing the Swedish translation of the > %description of the RPM package coreutils? And what other > translations would that file contain? I didn't mean to try to address that in detail. You could do it several ways. Maybe rpm-coreutils-X.Y-Z.mo ? Havoc From aoliva at redhat.com Fri Jul 25 01:37:46 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Jul 2003 22:37:46 -0300 Subject: RFE: Other "Everything" installs In-Reply-To: <1059080055.31800.74.camel@mirkwood.devel.redhat.com> References: <1059078129.2622.67.camel@mentor.gurulabs.com> <1059080055.31800.74.camel@mirkwood.devel.redhat.com> Message-ID: On Jul 24, 2003, Jeremy Katz wrote: > Everything except some stuff has always seemed like a silly thing to me > because everybody is going to have a different idea of what "some stuff" > is for them. How about the following new categories (we can always work out what to place on each of them later): - Nearly everything - Pretty much everything - Everything I might want to use - Everything - Everything, really (currently known as everything) :-D /me runs -- Alexandre Oliva, GCC Team, Red Hat From wcooley at nakedape.cc Fri Jul 25 03:09:37 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: 24 Jul 2003 20:09:37 -0700 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030723153541.G19044@devserv.devel.redhat.com> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723153541.G19044@devserv.devel.redhat.com> Message-ID: <1059102573.10064.193.camel@localhost.localdomain> On Wed, 2003-07-23 at 12:35, Bill Nottingham wrote: > We're actually considering for this upcoming release: > > - adding in cyrus-imap > - taking out uw-imap > > Opinions? I wrote to Simon Matter who has maintained Cyrus IMAP RPMs for 2.1 and whose RPMs are indubitably the most widely used for 2.1. He expressed interest in continuing development of his packages but wasn't aware of the new development model. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Naked Ape Consulting http://nakedape.cc * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jeremyp at pobox.com Fri Jul 25 03:39:34 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: 24 Jul 2003 23:39:34 -0400 Subject: my thoughts on package management In-Reply-To: <1059089569.488.18.camel@va.local.linuxlobbyist.org> References: <1059078036.5247.56.camel@jeremy.dtcc.cc.nc.us> <20030724201247.GF32340@iadonisi.to> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <200307230515.13765.ali@packetknife.com> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723233050.00aec490@127.0.0.1> <20030724201247.GF32340@iadonisi.to> <5.1.1.6.2.20030724144706.01a83c60@127.0.0.1> <1059089569.488.18.camel@va.local.linuxlobbyist.org> Message-ID: <1059104373.1205.18.camel@localhost.localdomain> On Thu, 2003-07-24 at 19:32, Paul Iadonisi wrote: > On Thu, 2003-07-24 at 18:07, Robert LeBlanc wrote: > > [snip] > > > Unfortunately comments like the one quoted above are virtually guaranteed > > to stifle input from anyone who fears their concerns might be too divergent > > from what they perceive the "silent majority" to want. Such comments > > create an atmosphere that suggests that the spectrum of acceptable opinion > > is rather narrow, and that outside views are undesirable and unwelcome. > > Careful with your quoting, there! Your 'snipping' made it look like I > posted what you are responding to, but it was actually Jeremy Portzer. > Just so it's clear, I tend to agree that these conversations are fine > on these lists. They don't annoy me (though, I do understand Jeremy's > annoyance -- just a different perspective), as long as they don't drag > on too long with no apparent progress. But that goes for any topic. Right, and I should clarify that I am NOT trying to stifle any kind of conversation, just trying to determine what types of conversation are most useful. It's just that I'm wondering what processes exist, or should exist, to make a more objective test of what users really do want. Similarly, How does and should Red Hat communicate its goals effectively? Sure, we have the top-level goals listed on http://rhl.redhat.com/ -- but how do those drill-down to things like what kinds of packages will be included, and what things Red Hat is interested in getting outside developer help with? An example of this is the inclusion of tools like apt and yum in Red Hat Linux. Prior to the creation of the Red Hat Linux Project, many assumed it would be a cold day in hell before these would be included, as they threatened RHN, a revenue source for Red Hat. Several folks vocally asked for the inclusion of these tools, and there wasn't much response from Red Hat, seeming to support the cold-day-in-hell view. These requests thus became tiresome and seemed like a waste of time on the mailing lists. But with the RHLP, the viewpoint has changed: yum is in rawhide and Jeff J. has said that apt may be coming if some issues can be worked out. So how can Red Hat communicate their viewpoint on things like this, so we can sort out what is just a vocal minority complaining for no use, and things that will be considered and are worth spending time discussing? --Jeremy -- /---------------------------------------------------------------------\ | Jeremy Portzer jeremyp at pobox.com trilug.org/~jeremy | | GPG Fingerprint: 712D 77C7 AB2D 2130 989F E135 6F9F F7BC CC1A 7B92 | \---------------------------------------------------------------------/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dax at gurulabs.com Fri Jul 25 03:51:05 2003 From: dax at gurulabs.com (Dax Kelson) Date: 24 Jul 2003 21:51:05 -0600 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030723153541.G19044@devserv.devel.redhat.com> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723153541.G19044@devserv.devel.redhat.com> Message-ID: <1059105064.2636.18.camel@mentor.gurulabs.com> On Wed, 2003-07-23 at 13:35, Bill Nottingham wrote: > We're actually considering for this upcoming release: > > - adding in cyrus-imap > - taking out uw-imap > > Opinions? Uh, yeah. :) The mbox sucks, Maildir rules and uw-imap is a dog. Anything that supports Maildir is plus in my book. I've always been a fan of courier-imap. Dax From pekkas at netcore.fi Fri Jul 25 03:57:12 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 25 Jul 2003 06:57:12 +0300 (EEST) Subject: RFE: Other "Everything" installs In-Reply-To: <3F2046AD.3070805@bxwa.com> Message-ID: On Thu, 24 Jul 2003, Scott Becker wrote: > How about: > > a "Everything" > b "Everything in the selected language" > > or making Everything do just packages for the selected language and then > to get **everything** you just select all languages packages don't provide any indication of "language". -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From angles at aminvestments.com Fri Jul 25 05:23:14 2003 From: angles at aminvestments.com ( Angles Puglisi) Date: Fri, 25 Jul 2003 05:23:14 +0000 Subject: Inclusion of cyrus-imapd and mimedefang Message-ID: <20030725.bUA.53499300@www.dudex.net> *sometimes* courier-imap sticks to the RFC (which is their right) so much that known broken mailers like some mail from AOL, which do not end with the correct trailing CRLF, return NO message. Usually the text version in MIME Part 1 is fine but if the HTML in MIME part 2 does not end correctly, you get nothing. There are other broken mailers. Maybe a 5% thing. Dax Kelson (dax at gurulabs.com) wrote: > >On Wed, 2003-07-23 at 13:35, Bill Nottingham wrote: > >> We're actually considering for this upcoming release: >> >> - adding in cyrus-imap >> - taking out uw-imap >> >> Opinions? > >Uh, yeah. :) > >The mbox sucks, Maildir rules and uw-imap is a dog. > >Anything that supports Maildir is plus in my book. I've always been a >fan of courier-imap. > >Dax > > > > >http://www.redhat.com/mailman/listinfo/rhl-devel-list -- That's "angle" as in geometry. From julo at altern.org Fri Jul 25 07:01:21 2003 From: julo at altern.org (Julien Olivier) Date: 25 Jul 2003 08:01:21 +0100 Subject: my thoughts on package management In-Reply-To: References: <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <200307230515.13765.ali@packetknife.com> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <5.1.1.6.2.20030723233050.00aec490@127.0.0.1> <20030724201247.GF32340@iadonisi.to> <1059078036.5247.56.camel@jeremy.dtcc.cc.nc.us> <20030724203139.GG32340@iadonisi.to> <20030724171938.T32225@devserv.devel.redhat.com> Message-ID: <1059116481.4631.5.camel@localhost.localdomain> On Fri, 2003-07-25 at 00:09, Chris Ricker wrote: > On Thu, 24 Jul 2003, Havoc Pennington wrote: > > > Another kind of bias is that people only complain about what they > > don't like, very few people ever praise what they do like. > > > > That is if you have 100 people who like it how it is and 10 people who > > don't, you'll get 10 complaints and 1 praise, which looks like a 10-1 > > vote for changing it. > > > > You find out the reality when you change it and suddenly get 100 > > complaints and 0 praise. ;-) > > > > Anyway, this is why you really have to understand the goals and > > rationale for why the software is how it is, otherwise you sort of > > just keep changing it back and forth in response to complaints. > > I was actually thinking about this last night when I ran across a "praise > bug" in bugzilla. The problem is that there's no real place for praise ;-). > There's bugzilla for logging all the "this sucks" stuff, but there's no > similar constant surveying / tracking of what people like.... Maybe it would > be a good idea to catalog periodically? > Well, I guess the problem is that users don't _know_ what they like until they lose it, mostly because lots of features are just hidden (for good reasons). > later, > chris > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list From chuckw at quantumlinux.com Fri Jul 25 07:02:37 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Fri, 25 Jul 2003 00:02:37 -0700 (PDT) Subject: RFE: Other "Everything" installs In-Reply-To: Message-ID: > > a "Everything" > > b "Everything in the selected language" > > > > or making Everything do just packages for the selected language and > > then to get **everything** you just select all languages > > packages don't provide any indication of "language". Apparently you aren't familiar with the %lang macro? -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From david.paeme at belbone.net Fri Jul 25 07:11:40 2003 From: david.paeme at belbone.net (david paeme) Date: 25 Jul 2003 09:11:40 +0200 Subject: the installer... Message-ID: <1059117099.3457.103.camel@owsdavid> Hi again, I have a little question about the standard rh installer, regarding a little problem I had. In RH9, the installer kernel is compiled for i686 (RH8 was i386). Since this is not a bad thing, It kinda gives some problems sometimes when installing on certain systems. For example: The installer-kernel kept on crashing when trying to do an install on my little home server, which has a Via C3 processor (you know, soldered on one of those sweet mini-itx boards), which does not support the i686 instruction set (almost, but it doesn't support the 'cmov' instruction). I was wondering if it would be possible to keep the option open to install future redhats on older systems? I think this would be a "good thing"(tm), since not everyone uses high-end machines. (also: think of people in developing countries, who can use the latest and greatest os features, without having to spend a fortune on the latest/greatest machines.) From pmatilai at welho.com Fri Jul 25 07:44:04 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 25 Jul 2003 10:44:04 +0300 Subject: BitTorrent enabled downloads & updates In-Reply-To: <1059083352.23202.65.camel@amr.math.utah.edu> References: <1059083352.23202.65.camel@amr.math.utah.edu> Message-ID: <1059119044.3f20dfc4711ff@webmail.welho.com> Quoting Elijah P Newren : > Sorry for the cross-posting. I originally posted this idea on #fedora > at irc.freenode.net and Anvil suggested I email these two lists with > this idea. My idea was the following: > > Have apt-get/yum/up2date/ > use BitTorrent for file downloads. > > This would have the following benefits: > Users would get a much faster download rate (at least, that's > been my experience for the downloads I've done with > BitTorrent). > It would alleviate the 'which mirror should I use' problem. > Anyone could easily become a mirror. > It should keep any specific mirror from getting overloaded. > > I figured this made so much sense that someone else has already thought > of it and perhaps already implemented it. Anyone know if that's the > case? If not, does that idea sound interesting to others? See http://distro2.conectiva.com.br/pipermail/apt-rpm/2003-June/001808.html. Haven't tried "circle" though. > > > Elijah > _______________________________________________ > Fedora-devel mailing list > Fedora-devel at fedora.us > http://www.fedora.us/mailman/listinfo/fedora-devel > -- - Panu - From pmatilai at welho.com Fri Jul 25 07:45:01 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 25 Jul 2003 10:45:01 +0300 Subject: BitTorrent enabled downloads & updates In-Reply-To: <1059083352.23202.65.camel@amr.math.utah.edu> References: <1059083352.23202.65.camel@amr.math.utah.edu> Message-ID: <1059119101.3f20dffdc46a1@webmail.welho.com> Quoting Elijah P Newren : > Sorry for the cross-posting. I originally posted this idea on #fedora > at irc.freenode.net and Anvil suggested I email these two lists with > this idea. My idea was the following: > > Have apt-get/yum/up2date/ > use BitTorrent for file downloads. > > This would have the following benefits: > Users would get a much faster download rate (at least, that's > been my experience for the downloads I've done with > BitTorrent). > It would alleviate the 'which mirror should I use' problem. > Anyone could easily become a mirror. > It should keep any specific mirror from getting overloaded. > > I figured this made so much sense that someone else has already thought > of it and perhaps already implemented it. Anyone know if that's the > case? If not, does that idea sound interesting to others? See http://distro2.conectiva.com.br/pipermail/apt-rpm/2003-June/001808.html. Haven't tried it though... > > > Elijah > _______________________________________________ > Fedora-devel mailing list > Fedora-devel at fedora.us > http://www.fedora.us/mailman/listinfo/fedora-devel > -- - Panu - From pmatilai at welho.com Fri Jul 25 07:45:37 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 25 Jul 2003 10:45:37 +0300 Subject: BitTorrent enabled downloads & updates In-Reply-To: <1059083352.23202.65.camel@amr.math.utah.edu> References: <1059083352.23202.65.camel@amr.math.utah.edu> Message-ID: <1059119137.3f20e0213edef@webmail.welho.com> Quoting Elijah P Newren : > Sorry for the cross-posting. I originally posted this idea on #fedora > at irc.freenode.net and Anvil suggested I email these two lists with > this idea. My idea was the following: > > Have apt-get/yum/up2date/ > use BitTorrent for file downloads. > > This would have the following benefits: > Users would get a much faster download rate (at least, that's > been my experience for the downloads I've done with > BitTorrent). > It would alleviate the 'which mirror should I use' problem. > Anyone could easily become a mirror. > It should keep any specific mirror from getting overloaded. > > I figured this made so much sense that someone else has already thought > of it and perhaps already implemented it. Anyone know if that's the > case? If not, does that idea sound interesting to others? See http://distro2.conectiva.com.br/pipermail/apt-rpm/2003-June/001808.html. Haven't tried it though.. -- - Panu - From chuckw at quantumlinux.com Fri Jul 25 07:56:13 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Fri, 25 Jul 2003 00:56:13 -0700 (PDT) Subject: Diskless workstations In-Reply-To: <3F1FDDCE.4080702@redhat.com> Message-ID: > I have been working on a package called redhat-config-netboot that > allows you to setup diskless environments using NFS, as well as network > installations. It is based somewhat off of LTSB. It is basically a > series of scripts and python code that sets up a PXE boot environment > and an diskless NFS partition. > > ftp://people.redhat.com/dwalsh/netboot > > Comments welcome. Pretty intuitive and straightforward approach. If I read your README correctly, it looks as if you install an OS on a machine that will be a similar configuration to the diskless machines and then upload that image at boot time to the diskless clients. My only comment so far is, why are you locking things down by MAC address? Wouldn't end user authentication be a more appropriate method (RFID is what comes to mind, but PAM is a good abstraction model)? It seems like you're really marrying the hardware to the software in several ways. Why can't I boot from a floppy and load my workstation image onto my laptop (which happens to have 1GB of RAM) if I'm in a meeting "down the hall" without having to update a dhcpd.conf file. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From dwalsh at redhat.com Fri Jul 25 10:17:25 2003 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 25 Jul 2003 06:17:25 -0400 Subject: Diskless workstations References: Message-ID: <3F2103B5.7030206@redhat.com> Chuck Wolber wrote: > > >>I have been working on a package called redhat-config-netboot that >>allows you to setup diskless environments using NFS, as well as network >>installations. It is based somewhat off of LTSB. It is basically a >>series of scripts and python code that sets up a PXE boot environment >>and an diskless NFS partition. >> >>ftp://people.redhat.com/dwalsh/netboot >> >>Comments welcome. >> >> > >Pretty intuitive and straightforward approach. If I read your README >correctly, it looks as if you install an OS on a machine that will be a >similar configuration to the diskless machines and then upload that image >at boot time to the diskless clients. > >My only comment so far is, why are you locking things down by MAC address? >Wouldn't end user authentication be a more appropriate method (RFID is >what comes to mind, but PAM is a good abstraction model)? It seems like >you're really marrying the hardware to the software in several ways. Why >can't I boot from a floppy and load my workstation image onto my laptop >(which happens to have 1GB of RAM) if I'm in a meeting "down the hall" >without having to update a dhcpd.conf file. > >-Chuck > > > > I am locking the system to an IP Address, nothing more. The reason for this is so that the machine boots the same every time, unless the sysadmin changes the boot configuration file (PXE File). This way there is consistancy between boots, like there would be in a diskfull system. The client uses the IP Address to find the system specific data on the server. I can't use the authentication because there is no gaurantee that anyone is even going to be logging into the machine (think blade servers). Also a lot of the system specific information is required long before the login prompt happens. One interesting point that people keep bringing up is the idea of having the entire operating system in RAM instead of using NFS. In this situation you would get a completely fresh machine on every reboot, ie there would be nothing retained between boots. Might be an interesting experiment to try. From jbj at redhat.com Fri Jul 25 13:17:48 2003 From: jbj at redhat.com (Jeff Johnson) Date: Fri, 25 Jul 2003 09:17:48 -0400 Subject: RFC: i18n proposal In-Reply-To: <16160.26935.272814.779571@uebn.uddeborg.se>; from goeran@uddeborg.se on Fri, Jul 25, 2003 at 01:18:15AM +0200 References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <16160.26935.272814.779571@uebn.uddeborg.se> Message-ID: <20030725091748.A18401@devserv.devel.redhat.com> On Fri, Jul 25, 2003 at 01:18:15AM +0200, G?ran Uddeborg wrote: > Jeff Johnson writes: > > IMHO, the work is best left to for-pay translators > > I wouldn't mind that! > Beind paid? Put Arabic on a resume and send it in. Don't worry about the laguage skill set, all your other skills are perfect. ;-) > > (and editors, hackers are not necessarily the best redactors) > > Oh! Thought there would be a catch! Seriously, there are often corrections to the msgid's found by translator's that need to be pushed uphill. Some of these changes are best handled by a C locale translator aka editor. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From katzj at redhat.com Fri Jul 25 14:38:46 2003 From: katzj at redhat.com (Jeremy Katz) Date: 25 Jul 2003 10:38:46 -0400 Subject: the installer... In-Reply-To: <1059117099.3457.103.camel@owsdavid> References: <1059117099.3457.103.camel@owsdavid> Message-ID: <1059143926.16814.59.camel@isengard> On Fri, 2003-07-25 at 03:11, david paeme wrote: > In RH9, the installer kernel is compiled for i686 (RH8 was i386). Since > this is not a bad thing, It kinda gives some problems sometimes when > installing on certain systems. > For example: The installer-kernel kept on crashing when trying to do an > install on my little home server, which has a Via C3 processor (you > know, soldered on one of those sweet mini-itx boards), which does not > support the i686 instruction set (almost, but it doesn't support the > 'cmov' instruction). The kernel on the CD is the i586 kernel with ACPI turned on. Not the i686. The kernel on bootdisk.img is the i386 BOOT kernel without ACPI. If you boot from CD with 'acpi=off', does it work better? Jeremy From scottb at bxwa.com Fri Jul 25 17:20:24 2003 From: scottb at bxwa.com (Scott Becker) Date: Fri, 25 Jul 2003 10:20:24 -0700 Subject: my thoughts on package management In-Reply-To: <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> References: <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> Message-ID: <3F2166D8.7080606@bxwa.com> On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote: > As a case in point, if I happen to use IBM DB2 as my database of choice > (or necessity) on a given server, I'll end up having to (re)build > packages like PHP from sources in order to configure --with-ibm-db2 or > somesuch. > The problem at the root of all this is that if I ever need to rebuild > anything from sources, I break the auto-update chain for that package. What's the Big Picture/Goal? RHL Project users get no "Support" from RH. Apparently this does not preclude RH from collecting money for RHN subscriptions to distribute and apply updates. Obviously for the example above, RH is going to provide support for DB2 in RHEL. RH's goal isn't to supply the serious do it yourselfer like Robert with everything he needs in RHL Project but instead in RHEL. Robert however, like myself, doesn't want to pay big bucks for support that we will almost never use (maybe his is willing but RH didn't speakup and say, "that's in RHEL"). We need to find a balance in all this. I see RH is being very careful but maybe too careful. If RH actually "is" willing support an array of PHP rpms, etc, for various configurations to cover the needs of people like Robert but "only" in RHEL and Robert is willing to pay for the convienence then that dialog needs to happen. Obviously RH is a large company which needs to make money so this is understandable but RH is being a little tight lipped about what they have going in RHEL and probably haven't decided it all yet. On the other hand for people like Robert and myself who "aren't" willing to pay big bucks when we can do it ourselves but are willing to contribute to RHL Project, RH needs to work with us or lose us. I personally am considering moving to RHEL when 3.0 is released but I need to check it out first. They have said to me, "Talk to us, we give volume discounts. At low volumes." Not formalizing and publishing the volume discounts is very short sighted because more than half of the prospective RHEL customers my size never talk to them after seeing the price and multiplying it times the number of servers (7 in my case). We just say to our selves, "forget it, it cost too much". If RHL Project is supported only by the community, then the community will move to one of the free update distribution systems if RH does not work with us. For example RHL Project is GPL. I can install it on 10 computers or 50 computers. RHEL has a satellite RHN server. Because it's technically easy for the community to write a light version of this, we will (and have) if RH does not. We are do it yourselfers. Include in RHL Project a light RHN satellite that only the do it yourselfer can use: rpm -i rhn-sat.... dhcp.conf: update_server=192.168.0.1 Done! Simple but not automatic. The masses will have one computer and pay for update the way they are now. With this RH collects $100 / year / channel (or whatever) for a subscription which feeds the rhn-satellite all the updates only once. Then "Do it Yourself IT" can have an infinate number of installs in their company and RH never has to answer a single support call but is making just a little money from *many* small businesses. IMHO RH can not reserve convienient security updates for RHEL. But if they approach it from the right angle they can succeed big time. The other companies which are willing to spend $500K to save $2M will use RHEL for all the other advantages it has. As for updating custom installs here is what is needed for both RHL Project and RHEL. Someone sugguested something close to this: All updates are released as not only bin and src rpms but also a src-diff rpm which installs patches for the update in an "unapplied patches" dir in the src tree for that package. This rpm is dependent on prior patches and the original src rpm. The only thing the do it yourselfer needs to do to take advantage of this when he needs to modify a package is to force the uninstall of the binary rpm first and then compile and install from the src rpm. Up2date will then do the right thing without mods. If we don't get carried away with diffs from every point to every point then this won't be very much extra work to support, just one patch rpm in addition to the src rpm (correct me if making a dif rpm is labor intensive). If the diff rpm cats an entry in a "src-update" log file then after running up2date -u the do-it-yourselfer only needs to check it for new entries to know which packages need recompiled. He then applies, compiles and then moves the patches to the "applied patches" folder and he's all set. Perhaps rpm can be taught to update a src rpm, simulating the diff rpm above, to accomplish all this without any other changes! A single update to rpm and a howto and it's all done! I honestly believe RH can be a raving success if they strike a good balance between the do-it-yourselfer and the enterprise. Sorry for being so wordy but I hope it helps. Scott Becker From wcooley at nakedape.cc Fri Jul 25 17:21:51 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: 25 Jul 2003 10:21:51 -0700 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <20030725.bUA.53499300@www.dudex.net> References: <20030725.bUA.53499300@www.dudex.net> Message-ID: <1059153710.10064.206.camel@localhost.localdomain> On Thu, 2003-07-24 at 22:23, Angles Puglisi wrote: > *sometimes* courier-imap sticks to the RFC (which is their > right) so much that known broken mailers like > some mail from AOL, which do not end with the correct > trailing CRLF, return NO message. Usually the text > version in MIME Part 1 is fine but if the HTML > in MIME part 2 does not end correctly, you get nothing. > There are other broken mailers. Maybe a 5% thing. > And sometimes refuses to follow it or even participate in the standards proccess: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=Pine.LNX.4.50.0206050910320.6814-100000%40shiva0.cac.washington.edu Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Naked Ape Consulting http://nakedape.cc * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Fri Jul 25 18:06:15 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: 25 Jul 2003 13:06:15 -0500 Subject: my thoughts on package management In-Reply-To: <3F2166D8.7080606@bxwa.com> References: <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <3F2166D8.7080606@bxwa.com> Message-ID: <1059156374.3253.161.camel@zorak> On Fri, 2003-07-25 at 12:20, Scott Becker wrote: > If RH actually "is" willing support an array of PHP rpms, etc, > for various configurations to cover the needs of people like Robert but > "only" in RHEL and Robert is willing to pay for the convienence then > that dialog needs to happen. Obviously RH is a large company which needs > to make money so this is understandable but RH is being a little tight > lipped about what they have going in RHEL and probably haven't decided > it all yet. If you need the ability to call Red Hat and get support for anything Linux related, you will need to be using RHEL. Do we support the PHP rpms we ship in RHEL? Of course. Yes, we are being tight-lipped on what we have going in RHEL, and part of this is due to the fact that the next release of RHEL is just barely in Beta. Features may be added/dropped while we're in this stage. If anyone would like to talk about RHEL, either contact your sales representative (if you have one) or email me directly, and I will be happy to discuss it with you as far as I can. Recognize that an NDA may be necessary to get into the fine details, such is the nature of the game, pre-release. > Not formalizing and publishing the volume > discounts is very short sighted because more than half of the > prospective RHEL customers my size never talk to them after seeing the > price and multiplying it times the number of servers (7 in my case). We > just say to our selves, "forget it, it cost too much". Do you pay list price for your hardware? Do you pay list price for ANY software application? I suspect the answer is no on both counts, but you HAVE to engage the Sales machine in order to get that volume discount. Almost no computer business entities publish their volume sales discounts (outside of the channel). Red Hat is not unique in this regard. Striking a middle ground between the needs of the "do-it-yourselfer" and the "enterprise" is far trickier than you've detailed. Any approach taken has to be sure not to weaken the position on either side. If you find yourself needing telephone support or Red Hat guaranteed updates, you're sliding onto the enterprise side. Give Red Hat a call, let us try to work with you to see if RHEL is an option. ~spot --- Tom "spot" Callaway SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260 The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me. "Immature poets borrow, mature poets steal." --- T. S. Eliot From scottb at bxwa.com Fri Jul 25 18:39:31 2003 From: scottb at bxwa.com (Scott Becker) Date: Fri, 25 Jul 2003 11:39:31 -0700 Subject: my thoughts on package management In-Reply-To: <1059156374.3253.161.camel@zorak> References: <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <3F2166D8.7080606@bxwa.com> <1059156374.3253.161.camel@zorak> Message-ID: <3F217963.4030405@bxwa.com> Tom 'spot' Callaway wrote: >On Fri, 2003-07-25 at 12:20, Scott Becker wrote: > > >>Not formalizing and publishing the volume >>discounts is very short sighted because more than half of the >>prospective RHEL customers my size never talk to them after seeing the >>price and multiplying it times the number of servers (7 in my case). We >>just say to our selves, "forget it, it cost too much". >> >> > >Do you pay list price for your hardware? Do you pay list price for ANY >software application? I suspect the answer is no on both counts, but you >HAVE to engage the Sales machine in order to get that volume discount. >Almost no computer business entities publish their volume sales >discounts (outside of the channel). Red Hat is not unique in this >regard. > > We have seven servers accumulated/updated over 5 years. We paid list for all of it. I understand you have to work through your system but I recommend at least mentioning a volume discounts exists. We have 20 windows workstations bought one or two at a time over five years with no discount except that the OS was less by being bundled with the hardware. There is no yearly fee to keep windows updated. Windows sucks of course and updates will end soon for the version I'm using. I've bought a few servers with no OS and I think it was only $30 less. I work for the kind of small business where we don't have any volume in our IT (me). The RH seminar in Seattle which I attended (first ever) is where I found out about about volume discounts. I just carefully read the page on "Enterprise Linux ES" and found "For Volume Sales: Contact Sales" which implies volume discount but I still, after all this, don't know if 7 servers would give me a discount. I know, "Call Sales and talk to them." but a little more info on the site may intice an average Joe like me to actually call. >Striking a middle ground between the needs of the "do-it-yourselfer" and >the "enterprise" is far trickier than you've detailed. Any approach >taken has to be sure not to weaken the position on either side. > > > Understood. Scott Becker From florin at sgi.com Fri Jul 25 20:19:53 2003 From: florin at sgi.com (Florin Andrei) Date: 25 Jul 2003 13:19:53 -0700 Subject: Inclusion of cyrus-imapd and mimedefang In-Reply-To: <1059102573.10064.193.camel@localhost.localdomain> References: <1058978302.10599.21.camel@smoogen1.lanl.gov> <20030723153541.G19044@devserv.devel.redhat.com> <1059102573.10064.193.camel@localhost.localdomain> Message-ID: <1059164392.16828.36.camel@stantz.corp.sgi.com> On Thu, 2003-07-24 at 20:09, Wil Cooley wrote: > > I wrote to Simon Matter who has maintained Cyrus IMAP RPMs for 2.1 and > whose RPMs are indubitably the most widely used for 2.1. Indeed. > He expressed > interest in continuing development of his packages but wasn't aware of > the new development model. Apart from the clever authentication scheme, from shared folders and the very scalable architecture, IMO one of the best features of Cyrus is Sieve, the mail filtering language. To be able to filter messages server-side _without_ scripting hacks bolted onto the daemon Home Depot-style (not to mention procmail and stuff like that) - that's amazing. The whole point about IMAP is mobility - the users are able to go places, change their workstations and yet access their mail folders in an uniform fashion. Hence, the server-side filtering is such a natural development, i'm amazed there aren't more IMAP daemons with native filtering schemes. Well, probably everyone thought classic scripting is enough, which is not, at least not when you want to scale things up. On my personal mail server, i need to access mail from at least two different workstations (both running Evolution at this moment) and one Webmail gateway. Not having a proper server-side filtering scheme makes it very difficult for me to maintain a consistent structure and content of my e-mail. That's why i'm planning to move my personal server on to Cyrus, even though it's a really small system, with very few users (and Cyrus might seem to be overkill for it). I think the inclusion of an "official" Cyrus package in Red Hat is a _very_ good thing. Make it the higher-end IMAP server, and use something else for simple and straightforward installations (i forgot what's the name of the other imapd proposal for Severn). Of course, UW must stay around for a while, but having three different IMAP daemons is kinda too much. Or not. :-) -- Florin Andrei "Never send a human to do a machine's job." - Agent Smith From goeran at uddeborg.se Fri Jul 25 21:26:42 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran?= Uddeborg) Date: Fri, 25 Jul 2003 23:26:42 +0200 Subject: RFC: i18n proposal In-Reply-To: <20030724193745.D29567@devserv.devel.redhat.com> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> Message-ID: <16161.41106.591644.103709@uebn.uddeborg.se> Havoc Pennington writes: > I didn't mean to try to address that in detail. You could do it > several ways. Maybe rpm-coreutils-X.Y-Z.mo ? Ok, so you mean a separate message catalog per package, containing the translations related to the package. That makes sense to me. Now, let's see if I can imagine how this would be done. Preparation for translation: 1. Descriptions, summaries, and group information are extracted from all SPEC files. Putting descriptions and summaries in the same po file probably makes sense, the group names could be collected in a separate po file if convenient. 2. This/these po files are made available for translation. (Talking of which, when will specspo appear in this cycle? :-) 3. As translations arrive, they are put in some dedicated hierarchy. Call this H. (/var/lib/rpm/locale/... maybe, I'm sure a nice macro could be used to define this. :-) During package build: 1. Rpmbuild creates a pot file containing description, summary, and group for the package being built. 2. For each language defined in H, look for translations of the messages in the pot file made. This would be something like msgmerge -C -C ... /dev/null Where are all translations found in H for this language. If the resulting file contains any translations, it is included in the package as the translations for that language. When running things like "rpm -qi" or redhat-config-packages 1. When a description, summary, or group is to be displayed, a translation is sought by a call to dgettext() whith a domain name derived from the package being inspected. Would this make sense? Is it approximately along the lines you meant? (To the extent you had them thought out.) Would it be appropriate to put these package po files in some specific hierarchy, separate from /usr/share/locale? (And do a corresponding call to bindtextdomain() before calling dgettext().) Is the needed information always available? Like, does rpm know enough in time to find the po files when quering a package file, for example? How would one handle building single packages, not being part of a distribution? Maybe by having an RPM directive specifying a directory in the build tree to search for further message catalogs? Then the translations for this package would be part of the source of the package, which I guess would make sense. Or am I missing too much here? From felipe_alfaro at linuxmail.org Fri Jul 25 22:34:30 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 26 Jul 2003 00:34:30 +0200 Subject: further development of libuser's LDAP module Message-ID: <1059172469.705.8.camel@teapot.felipe-alfaro.com> Hi! While using libuser's LDAP module, I think I've found that it's not complete. The fact is that several operations, like adding users and groups try to invoke "lu_ldap_set" libuser's function, which in turn, uses ldap_modify_s(). The problem here is that can't expect ldap_modify_s() to succeed in creating a user or group account when the underlying LDAP entry does not exist. The real fact is that I've been unable to use "luseradd" and "lgroupadd" to add users and groups to my LDAP backend. Thus, I've modified and redeveloped the LDAP module of libuser a little bit and I think I've got a 100%, fully functional LDAP backend module which can be used to add, delete and modify user and group accounts. Are you interested in me posting a unified diff/patch (or the whole sources)? Please, say yes ;-) This is a very interesting piece of software I'm using in a real proyect to migrate a stinking farm of NT4 boxes to Linux + Samba 3.0 and LDAP. Thanks! From florin at sgi.com Fri Jul 25 23:43:00 2003 From: florin at sgi.com (Florin Andrei) Date: 25 Jul 2003 16:43:00 -0700 Subject: split rc.sysinit Message-ID: <1059176579.16828.46.camel@stantz.corp.sgi.com> How about splitting rc.sysinit into multiple commands in a directory, init.d style? I've seen several cases when various applications (usually stuff that wants to do low-level things) needed to somehow insert themselves in the rc.sysinit sequence. With a monolithic rc.sysinit that's impossible unless you hack the script using sed, perl, etc., which is ugly to say the least. One issue with splitting it (among many other that i'm not going to mention) might be that the boot up time might get a bit bigger. If i'm not mistaken, this could be avoided by creating one single actual executable, and let it source things up from a directory, instead of launching multiple executable scripts sequentially. Splitting this executable might also allow for things like optionally turning on (or NOT turning on) IEEE1394 or USB in userspace (as opposed to using kernel parameters in the bootloader), etc. Keyword: flexibility Downside: complexity -- Florin Andrei "Never send a human to do a machine's job." - Agent Smith From notting at redhat.com Sat Jul 26 00:17:10 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 25 Jul 2003 20:17:10 -0400 Subject: split rc.sysinit In-Reply-To: <1059176579.16828.46.camel@stantz.corp.sgi.com>; from florin@sgi.com on Fri, Jul 25, 2003 at 04:43:00PM -0700 References: <1059176579.16828.46.camel@stantz.corp.sgi.com> Message-ID: <20030725201710.A17885@devserv.devel.redhat.com> Florin Andrei (florin at sgi.com) said: > How about splitting rc.sysinit into multiple commands in a directory, > init.d style? It's been seriously considered, just not enough round tuits yet. Bill From pri.rhl1 at iadonisi.to Sat Jul 26 05:05:01 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 26 Jul 2003 01:05:01 -0400 Subject: On the inclusion of cyrus-imapd Message-ID: <1059195900.9525.10.camel@va.local.linuxlobbyist.org> After the recent discussion of possibly including cyrus-imapd in this upcoming release, I figured I'd check to see how things work on severn. I've been running 2.1.12 on Red Hat 9 since Red Hat Linux 9's release and figured I'd check for updates. I had the 2.1.13 src rpm from Simon Matter, but hadn't upgraded and found that 2.1.14 has since been released. Also, I had experimented with the 2.2.0 alpha a while ago because I'm interested in the new virtual hosting feature. I found that this has been updated, too, and Simon Matter has and rpm for it (2.2.1-2). So I gave an 'rpmbuild --rebuild' on severn and it failed. It builds fine on Red Hat 9. Upon initial investigation, it appears that a /var/tmp/cyrus-imapd-2.2.1-root/var/tmp/cyrus-imapd-2.2.1-root/ directory is getting created and much of the install is putting files in there instead of just /var/tmp/cyrus-imapd-2.2.1-root. I'm about to dig into the rpm spec file and possibly the default rpm config differences between RHL 9 and servern, but wanted to ask here if anyone else has run into this or knew of any changes in the default rpm config that would cause this. It could be a simple fix to the spec file, but I'm just wondering what changed, given that it works on RHL 9. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From pri.rhl1 at iadonisi.to Sat Jul 26 06:27:44 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 26 Jul 2003 02:27:44 -0400 Subject: On the inclusion of cyrus-imapd In-Reply-To: <1059195900.9525.10.camel@va.local.linuxlobbyist.org> References: <1059195900.9525.10.camel@va.local.linuxlobbyist.org> Message-ID: <1059200863.9525.23.camel@va.local.linuxlobbyist.org> On Sat, 2003-07-26 at 01:05, Paul Iadonisi wrote: [snip] > So I gave an 'rpmbuild --rebuild' on severn and it failed. It builds Got it. It's the perlhack stuff which appears to not be necessary anymore. The workarounds Simon has in the spec file would have worked except that the %{buildroot} portion is no longer necessary in the PREFIX value of the make install command, either. The 2.1.14-4 package failed with the same problem. If anyone else is interested, attached are two patches, one for the beta (2.2.1-2) and one for the stable (2.1.14-4) spec files. And for reference, Simon's rpms are available at http://home.teleport.ch/simix/ -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets -------------- next part -------------- --- cyrus-imapd.spec 2003-07-08 18:22:06.000000000 -0400 +++ cyrus-imapd.spec.fixed 2003-07-26 02:22:00.000000000 -0400 @@ -58,6 +58,8 @@ %define _dbver %(eval "rpm -q --quiet db4 && echo db4 || echo db3") # Do we need the perl install hack for RedHat > 7.3 ? %define _perlhack %(eval [ %{_rhver} = "6.2" -o %{_rhver} = "7.0" -o %{_rhver} = "7.1" -o %{_rhver} = "7.2" -o %{_rhver} = "7.3" -o %{_rhver} = "2.1AS" -o %{_rhver} = "2.1ES" ] && echo 0 || echo 1) +# Do we need the perl make install hack for RedHat 9.0.93 (severn) +%define _perlmakehack %(eval [ %{_rhver} = "9.0.93" ] && echo 0 || echo 1) # Do we need the snmpargs patch (needed on RedHat 6.2) %define _snmpargs_patch %(eval [ %{_rhver} = "6.2" ] && echo 1 || echo 0) %define _perl_man3dir %(eval "$(perl -V:man3dir)"; echo $man3dir) @@ -367,9 +369,15 @@ popd %endif +%if %{_perlmakehack} # Do what the regular make install does %{__make} install DESTDIR=%{buildroot} PREFIX=%{buildroot}%{_prefix} mandir=%{_mandir} %{__make} -C man install DESTDIR=%{buildroot} PREFIX=%{buildroot}%{_prefix} mandir=%{_mandir} +%else +# Do what the regular make install does +%{__make} install DESTDIR=%{buildroot} PREFIX=%{_prefix} mandir=%{_mandir} +%{__make} -C man install DESTDIR=%{buildroot} PREFIX=%{_prefix} mandir=%{_mandir} +%endif %if %{DEL_WRAP} %{__install} -s -m 2755 deliver-wrapper %{buildroot}%{_cyrexecdir}/ -------------- next part -------------- --- cyrus-imapd-BETA.spec 2003-07-25 20:07:18.000000000 -0400 +++ cyrus-imapd-BETA.spec.fixed 2003-07-26 02:09:57.000000000 -0400 @@ -55,6 +55,8 @@ %define _dbver %(eval "rpm -q --quiet db4 && echo db4 || echo db3") # Do we need the perl install hack for RedHat > 7.3 ? %define _perlhack %(eval [ %{_rhver} = "6.2" -o %{_rhver} = "7.0" -o %{_rhver} = "7.1" -o %{_rhver} = "7.2" -o %{_rhver} = "7.3" -o %{_rhver} = "2.1AS" -o %{_rhver} = "2.1ES" ] && echo 0 || echo 1) +# Do we need the perl make install hack for RedHat = 9.0.93 (severn) +%define _perlmakehack %(eval [ %{_rhver} = "9.0.93" ] && echo 0 || echo 1) # Do we need the snmpargs patch (needed on RedHat 6.2) %define _snmpargs_patch %(eval [ %{_rhver} = "6.2" ] && echo 1 || echo 0) %define _perl_man3dir %(eval "$(perl -V:man3dir)"; echo $man3dir) @@ -351,6 +353,7 @@ %install [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot} +echo %{_rhver} %{_perlhack} > /tmp/rhver.perlhack # This hack is needed on RedHat > 7.3 to install the perl files correctly %if %{_perlhack} pushd perl/imap @@ -361,9 +364,15 @@ popd %endif +%if %{_perlmakehack} # Do what the regular make install does %{__make} install DESTDIR=%{buildroot} PREFIX=%{buildroot}%{_prefix} mandir=%{_mandir} %{__make} -C man install DESTDIR=%{buildroot} PREFIX=%{buildroot}%{_prefix} mandir=%{_mandir} +%else +# Do what the regular make install does +%{__make} install DESTDIR=%{buildroot} PREFIX=%{_prefix} mandir=%{_mandir} +%{__make} -C man install DESTDIR=%{buildroot} PREFIX=%{_prefix} mandir=%{_mandir} +%endif %if %{DEL_WRAP} %{__install} -s -m 2755 deliver-wrapper %{buildroot}%{_cyrexecdir}/ From warren at togami.com Sat Jul 26 08:55:53 2003 From: warren at togami.com (Warren Togami) Date: 25 Jul 2003 22:55:53 -1000 Subject: gtkspell problem in Severn Message-ID: <1059209752.1859.2.camel@laptop> When I attempt to run gaim-0.66 from Fedora on Severn using gtkspell-2.0.4-1 (included in Severn), it fails with this message. gaim: error while loading shared libraries: libgtkspell.so.0: cannot open shared object file: No such file or directory After I ran "ldconfig" manually as root, gaim works. Upon inspection of RH's .spec file of gtkspell it has ldconfig within %post, so I am confused. Any idea what happened here? Warren From nphilipp at redhat.com Sat Jul 26 12:18:36 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: 26 Jul 2003 14:18:36 +0200 Subject: On the inclusion of cyrus-imapd In-Reply-To: <1059200863.9525.23.camel@va.local.linuxlobbyist.org> References: <1059195900.9525.10.camel@va.local.linuxlobbyist.org> <1059200863.9525.23.camel@va.local.linuxlobbyist.org> Message-ID: <1059221915.8726.30.camel@wombat.dialup.fht-esslingen.de> On Sat, 2003-07-26 at 08:27, Paul Iadonisi wrote: > On Sat, 2003-07-26 at 01:05, Paul Iadonisi wrote: > > [snip] > > > So I gave an 'rpmbuild --rebuild' on severn and it failed. It builds > > Got it. It's the perlhack stuff which appears to not be necessary > anymore. The workarounds Simon has in the spec file would have worked > except that the %{buildroot} portion is no longer necessary in the > PREFIX value of the make install command, either. The 2.1.14-4 package > failed with the same problem. If anyone else is interested, attached > are two patches, one for the beta (2.2.1-2) and one for the stable > (2.1.14-4) spec files. > And for reference, Simon's rpms are available at > http://home.teleport.ch/simix/ One thing I'm not so fond of with Simon's RPMs is that the 2.2.1-BETA package doesn't have any indication that it's the beta (even when the original tarball does: "cyrus-imapd-2.2.1-BETA.tar.gz"). The package name-version-release should IMO rather be something like "cyrus-imapd-2.2.1BETA-2" or "cyrus-imapd-2.2.1-0.BETA.2". Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pri.rhl1 at iadonisi.to Sat Jul 26 13:52:38 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 26 Jul 2003 09:52:38 -0400 Subject: On the inclusion of cyrus-imapd In-Reply-To: <1059221915.8726.30.camel@wombat.dialup.fht-esslingen.de> References: <1059195900.9525.10.camel@va.local.linuxlobbyist.org> <1059200863.9525.23.camel@va.local.linuxlobbyist.org> <1059221915.8726.30.camel@wombat.dialup.fht-esslingen.de> Message-ID: <1059227557.9525.74.camel@va.local.linuxlobbyist.org> [oops. sorry if this shows up twice. I sent it from the wrong account the first time] On Sat, 2003-07-26 at 08:18, Nils Philippsen wrote: [snip] > > One thing I'm not so fond of with Simon's RPMs is that the 2.2.1-BETA > package doesn't have any indication that it's the beta (even when the > original tarball does: "cyrus-imapd-2.2.1-BETA.tar.gz"). The package > name-version-release should IMO rather be something like > "cyrus-imapd-2.2.1BETA-2" or "cyrus-imapd-2.2.1-0.BETA.2". Agreed. However, it *is* a beta and it's not too hard to fix that. Without looking at the spec file, the resultant binary rpms at least appear to put all the files in the right places (no mixing of /etc and /usr/local crap for one example -- A real annoyance from many packagers I've seen). The spec file is actually pretty good, too. He uses macros everywhere possible (almost to a fault), good formating, good division of sub packages, good portability (Red Hat 6.2 - 9, at least). His %post script is a bit long for my tastes, though. Anyhow, it's a good starting point and maybe he'd be willing to accept patches to bring it in line with Red Hat's guidelines, if it's necessary. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From mike at netlyncs.com Sat Jul 26 15:01:02 2003 From: mike at netlyncs.com (Mike Chambers) Date: 26 Jul 2003 10:01:02 -0500 Subject: my thoughts on package management In-Reply-To: <3F217963.4030405@bxwa.com> References: <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723012957.05c64b30@127.0.0.1> <5.1.1.6.2.20030723120010.05bf1d60@127.0.0.1> <3F2166D8.7080606@bxwa.com> <1059156374.3253.161.camel@zorak> <3F217963.4030405@bxwa.com> Message-ID: <1059231661.4781.5.camel@bart.netlyncs.com> On Fri, 2003-07-25 at 13:39, Scott Becker wrote: > I just carefully read the page on "Enterprise Linux ES" and found "For > Volume Sales: Contact Sales" which implies volume discount but I still, > after all this, don't know if 7 servers would give me a discount. I > know, "Call Sales and talk to them." but a little more info on the site > may intice an average Joe like me to actually call. Not me. If I need to find out something and can't find it immediately, I call ASAP and find out what I need to know, least business wise. -- Mike Chambers Madisonville, KY "Everyone is entitled to be stupid, but some abuse the privilege." From rhl-devel-list at cygnusx-1.org Sat Jul 26 15:25:22 2003 From: rhl-devel-list at cygnusx-1.org (Nathan G. Grennan) Date: 26 Jul 2003 08:25:22 -0700 Subject: gtkspell problem in Severn In-Reply-To: <1059209752.1859.2.camel@laptop> References: <1059209752.1859.2.camel@laptop> Message-ID: <1059233122.7016.41.camel@proton.cygnusx-1.org> On Sat, 2003-07-26 at 01:55, Warren Togami wrote: > When I attempt to run gaim-0.66 from Fedora on Severn using > gtkspell-2.0.4-1 (included in Severn), it fails with this message. > > gaim: error while loading shared libraries: libgtkspell.so.0: cannot > open shared object file: No such file or directory > > After I ran "ldconfig" manually as root, gaim works. Upon inspection of > RH's .spec file of gtkspell it has ldconfig within %post, so I am > confused. Any idea what happened here? > I am using gtkspell-2.0.4-1 and gaim-0.66-0.fdr.2.rh90.93. I haven't had this problem. I did a fresh install, and I think gaim-0.66 was installed by throwing it in one of my repositories and running yum. From chuckw at quantumlinux.com Sat Jul 26 17:07:32 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Sat, 26 Jul 2003 10:07:32 -0700 (PDT) Subject: split rc.sysinit In-Reply-To: <20030725201710.A17885@devserv.devel.redhat.com> Message-ID: > > How about splitting rc.sysinit into multiple commands in a directory, > > init.d style? > > It's been seriously considered, just not enough round tuits yet. What's the policy on someone from the "civilian" world coming up with a solution? Will RedHat accept stuff like that? -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From ckloiber at redhat.com Sat Jul 26 19:09:32 2003 From: ckloiber at redhat.com (Chris Kloiber) Date: 26 Jul 2003 15:09:32 -0400 Subject: RFE: Other "Everything" installs In-Reply-To: <1059078575.4326.19.camel@smiddle.civic.twp.ypsilanti.mi.us> References: <1059078129.2622.67.camel@mentor.gurulabs.com> <1059078575.4326.19.camel@smiddle.civic.twp.ypsilanti.mi.us> Message-ID: <1059246572.10375.39.camel@(null)> On Thu, 2003-07-24 at 16:29, Sean Middleditch wrote: > On Thu, 2003-07-24 at 16:22, Dax Kelson wrote: > > I typically do Everything installs on my personal workstations. > > Simplifies life greatly. > > > > However, it would be nice if there were: > > > > "Everything ONLY English" (ie, no foreign language support) > > > > "Everything NO Development" > > > > Comments? > > Definitely dont' think that's a good idea. It solves perhaps your > problem, but I'm there are many users who have other specific package > sets they'd love install options for too. What we'd end up with is an > Everything menu with tons of semi-Everythings, covering everything > imaginable, even tho they aren't Everything. ~,^ > > Seriously, it's not that much work to just select the package groups. > If you do find yourself spending too much time on it, quit reinstalling > your machines so often. ;-) Or just use Kickstart. I think more people speak other languages than do speak American English, but I understand where you are going with the original suggestion. I sort of expanded on that idea as I personally think it's a good one, and filed this bugzilla report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100888 You can read my suggestion there, but I can't say how much traction it will get for this release. It's more than likely too late for now. -- Chris Kloiber From ckloiber at redhat.com Sat Jul 26 19:19:55 2003 From: ckloiber at redhat.com (Chris Kloiber) Date: 26 Jul 2003 15:19:55 -0400 Subject: RFE: Other "Everything" installs In-Reply-To: References: Message-ID: <1059247195.10375.42.camel@luser.ckloiber.com> On Thu, 2003-07-24 at 23:57, Pekka Savola wrote: > On Thu, 24 Jul 2003, Scott Becker wrote: > > How about: > > > > a "Everything" > > b "Everything in the selected language" > > > > or making Everything do just packages for the selected language and then > > to get **everything** you just select all languages > > packages don't provide any indication of "language". I thought that was handled in the 'comps' file of the installer, otherwise what would the "Language Selection" page be for? -- Chris Kloiber From tcallawa at redhat.com Sat Jul 26 22:38:48 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: 26 Jul 2003 17:38:48 -0500 Subject: split rc.sysinit In-Reply-To: References: Message-ID: <1059259128.3175.32.camel@localhost.localdomain> On Sat, 2003-07-26 at 12:07, Chuck Wolber wrote: > > > How about splitting rc.sysinit into multiple commands in a directory, > > > init.d style? > > > > It's been seriously considered, just not enough round tuits yet. > > What's the policy on someone from the "civilian" world coming up with a > solution? Will RedHat accept stuff like that? I think this is the key reason that the RHLP exists. We're opening the playing field here. We want everyone to be involved. If you can code, hack. If you can write, document. If you can't, bend, break, and file bugs. You don't have to end in @redhat.com to play. If your code is good, it will be considered. Thats not to say that we'll be including everything, it has to be maintainable. But if you can speed up rc.sysinit in a clean way by splitting it up, by all means, do it. ~spot --- Tom "spot" Callaway SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260 The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me. "Immature poets borrow, mature poets steal." --- T. S. Eliot From jos at xos.nl Sat Jul 26 22:48:17 2003 From: jos at xos.nl (Jos Vos) Date: Sun, 27 Jul 2003 00:48:17 +0200 Subject: split rc.sysinit In-Reply-To: <1059259128.3175.32.camel@localhost.localdomain>; from tcallawa@redhat.com on Sat, Jul 26, 2003 at 05:38:48PM -0500 References: <1059259128.3175.32.camel@localhost.localdomain> Message-ID: <20030727004817.A9858@xos037.xos.nl> On Sat, Jul 26, 2003 at 05:38:48PM -0500, Tom 'spot' Callaway wrote: > But if you can speed up rc.sysinit in a clean way by splitting it up, by > all means, do it. Personally, I think the actions in rc.sysinit fit pretty tight together and it will be pretty difficult to split up in a decent way. I could imagine that it hands off some tasks that *might* people want to customize to separate scripts, though. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From pros-n-cons at bak.rr.com Sun Jul 27 00:41:37 2003 From: pros-n-cons at bak.rr.com (vincent) Date: Sat, 26 Jul 2003 17:41:37 -0700 Subject: gtkspell problem in Severn In-Reply-To: <1059209752.1859.2.camel@laptop> References: <1059209752.1859.2.camel@laptop> Message-ID: <20030726174137.0ee52e6e.pros-n-cons@bak.rr.com> On Fri, 25 Jul 2003 22:55:53 -1000 Warren Togami said: > When I attempt to run gaim-0.66 from Fedora on Severn using > gtkspell-2.0.4-1 (included in Severn), it fails with this message. > > gaim: error while loading shared libraries: libgtkspell.so.0: cannot > open shared object file: No such file or directory > Did you update from AYO rawhide? I did that and it broke a few things. what I did to get gaim back was to delete aspell aspell-en pspell and gtkspell. then installed the old one and it worked. Another problem that I cant fix is SSL is messed, I can't install devel package for some source that needs it. I'd have to delete some 150 apps that need ssl. Things like 'passwd' which are critical. last time I do something stupid like update everything to rawhide. From elanthis at awesomeplay.com Sun Jul 27 00:53:23 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: 26 Jul 2003 20:53:23 -0400 Subject: gtkspell problem in Severn In-Reply-To: <20030726174137.0ee52e6e.pros-n-cons@bak.rr.com> References: <1059209752.1859.2.camel@laptop> <20030726174137.0ee52e6e.pros-n-cons@bak.rr.com> Message-ID: <1059267203.4783.26.camel@stargrazer.home.awesomeplay.com> On Sat, 2003-07-26 at 20:41, vincent wrote: > On Fri, 25 Jul 2003 22:55:53 -1000 > Warren Togami said: > > > When I attempt to run gaim-0.66 from Fedora on Severn using > > gtkspell-2.0.4-1 (included in Severn), it fails with this message. > > > > gaim: error while loading shared libraries: libgtkspell.so.0: cannot > > open shared object file: No such file or directory > > > > Did you update from AYO rawhide? I did that and it broke a few things. > what I did to get gaim back was to delete aspell aspell-en pspell and gtkspell. > then installed the old one and it worked. > > Another problem that I cant fix is SSL is messed, I can't install devel package > for some source that needs it. I'd have to delete some 150 apps that need ssl. > Things like 'passwd' which are critical. last time I do something stupid like > update everything to rawhide. This was easy to fix actually... just don't your ssl libs. :P I also had to downgrade cvs. Something with the new krb5 libs I think; I can't install them (dependency errors), but some apps apparntly are compiled for them, their depends aren't set to only be usable with the new version, and the ABI changed. Yet another wonderful example why Windows' DLL Hell is a poor reason to move to Linux. :P All the old packages you've installed are in /var/cache/apt/archives if you're using apt-rpm, can be a life-saver. ^,^ > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From pros-n-cons at bak.rr.com Sun Jul 27 01:47:37 2003 From: pros-n-cons at bak.rr.com (vincent) Date: Sat, 26 Jul 2003 18:47:37 -0700 Subject: gtkspell problem in Severn In-Reply-To: <1059267203.4783.26.camel@stargrazer.home.awesomeplay.com> References: <1059209752.1859.2.camel@laptop> <20030726174137.0ee52e6e.pros-n-cons@bak.rr.com> <1059267203.4783.26.camel@stargrazer.home.awesomeplay.com> Message-ID: <20030726184737.427210ff.pros-n-cons@bak.rr.com> On Sat, 26 Jul 2003 20:53:23 -0400 Sean Middleditch said: > On Sat, 2003-07-26 at 20:41, vincent wrote: > > On Fri, 25 Jul 2003 22:55:53 -1000 > > Warren Togami said: > > > > > When I attempt to run gaim-0.66 from Fedora on Severn using > > > gtkspell-2.0.4-1 (included in Severn), it fails with this message. > > > > > > gaim: error while loading shared libraries: libgtkspell.so.0: cannot > > > open shared object file: No such file or directory > > > > > > > Did you update from AYO rawhide? I did that and it broke a few things. > > what I did to get gaim back was to delete aspell aspell-en pspell and gtkspell. > > then installed the old one and it worked. > > > > Another problem that I cant fix is SSL is messed, I can't install devel package > > for some source that needs it. I'd have to delete some 150 apps that need ssl. > > Things like 'passwd' which are critical. last time I do something stupid like > > update everything to rawhide. > > This was easy to fix actually... just don't your ssl libs. :P I also > had to downgrade cvs. Something with the new krb5 libs I think; I can't > install them (dependency errors), but some apps apparntly are compiled > for them, their depends aren't set to only be usable with the new > version, and the ABI changed. Yet another wonderful example why > Windows' DLL Hell is a poor reason to move to Linux. :P > > All the old packages you've installed are in /var/cache/apt/archives if > you're using apt-rpm, can be a life-saver. ^,^ Yep its that krb5 file that was stubborn. you said: "This was easy to fix actually... just don't your ssl libs." did you mean "just don't delete them"? Cause when i tried to update krb5 by force though apt-get it wanted to drop tons of packages. what packages did you rpm -e to get ssl back in shape? thanks. From tdiehl at rogueind.com Sun Jul 27 04:07:44 2003 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 27 Jul 2003 00:07:44 -0400 (EDT) Subject: RFE: Other "Everything" installs In-Reply-To: <1059246572.10375.39.camel@(null Message-ID: On 26 Jul 2003, Chris Kloiber wrote: > On Thu, 2003-07-24 at 16:29, Sean Middleditch wrote: > > On Thu, 2003-07-24 at 16:22, Dax Kelson wrote: > > > I typically do Everything installs on my personal workstations. > > > Simplifies life greatly. > > > > > > However, it would be nice if there were: > > > > > > "Everything ONLY English" (ie, no foreign language support) > > > > > > "Everything NO Development" > > > > > > Comments? > > > > Definitely dont' think that's a good idea. It solves perhaps your > > problem, but I'm there are many users who have other specific package > > sets they'd love install options for too. What we'd end up with is an > > Everything menu with tons of semi-Everythings, covering everything > > imaginable, even tho they aren't Everything. ~,^ > > > > Seriously, it's not that much work to just select the package groups. > > If you do find yourself spending too much time on it, quit reinstalling > > your machines so often. ;-) Or just use Kickstart. > > I think more people speak other languages than do speak American > English, but I understand where you are going with the original > suggestion. I sort of expanded on that idea as I personally think it's a > good one, and filed this bugzilla report: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=100888 > > You can read my suggestion there, but I can't say how much traction it > will get for this release. It's more than likely too late for now. FWIW, It is already closed as WONTFIX. -- ......Tom Registered Linux User #14522 http://counter.li.org tdiehl at rogueind.com My current SpamTrap -------> mtd123 at rogueind.com From ckloiber at redhat.com Sun Jul 27 05:17:57 2003 From: ckloiber at redhat.com (Chris Kloiber) Date: 27 Jul 2003 01:17:57 -0400 Subject: RFE: Other "Everything" installs In-Reply-To: References: Message-ID: <1059283077.22928.2.camel@(null)> On Sun, 2003-07-27 at 00:07, Tom Diehl wrote: > FWIW, It is already closed as WONTFIX. Guess it wasn't as good as idea as I thought. Win some, lose some. -- Chris Kloiber From ville.skytta at iki.fi Sun Jul 27 16:43:54 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: 27 Jul 2003 19:43:54 +0300 Subject: RPM building section of RHL's developer guide In-Reply-To: <20030724100009.O18401@devserv.devel.redhat.com> References: <20030722122604.624f3b23.matthias@rpmforge.net> <1059021299.1858.64.camel@laptop> <20030724100009.O18401@devserv.devel.redhat.com> Message-ID: <1059324234.15610.233.camel@bobcat.mine.nu> On Thu, 2003-07-24 at 17:00, Jeff Johnson wrote: > Current behavior in rpm-4.2.1 (and all future versions of rpm) is > A missing (i.e. unsepcified) Epoch: is exactly equivalent to Epoch: 0. > > Whether you choose to make the Epoch: explicit is a matter of style, the > version comparison in rpm is now deterministic, the same answer is returned > every time. Let's consider a specfile without an explicit Epoch that produces packages foo and foo-devel. Does this work in foo-devel with rpm-4.2.1? Requires: foo = %{epoch}:%{version} IIRC it doesn't work in rpm-4.2 and earlier. It'd be nice if it worked, in the case of an Epoch bump later the inter-subpackage dependencies would automagically follow if one doesn't fancy putting the explicit "Epoch: 0"'s in specfiles. Also, outputting the 0 in cases of a missing Epoch would be nice too, I remember trying out rpm-4.2.1 on RHL 9, and trying to install glib and glib-devel (Epoch: 1, but a buggy requires in -devel; fixed in Severn). The error message IIRC was: glib = x.x.x is required by glib-devel ...whereas a less confusing one IMHO would have been: glib = 0:x.x.x is required by glib-devel Ditto for "rpm -q --qf '%{epoch}:%{version}-%{release}' foo", does/could 4.2.1 print out "0:x.y-z" instead of "(none):x.y-z" if foo doesn't have an explicit Epoch? -- \/ From ville.skytta at iki.fi Sun Jul 27 17:03:40 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: 27 Jul 2003 20:03:40 +0300 Subject: yum initscript changes In-Reply-To: References: Message-ID: <1059325419.15610.235.camel@bobcat.mine.nu> On Thu, 2003-07-24 at 18:17, R P Herrold wrote: > On Thu, 24 Jul 2003, Florian La Roche wrote: > > > Change the initscript for current RHL defaults (whereever they are > > specified ;-) ;-): > > filed upstream to yum bugzilla > https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=81 Fedora QA gave some spanking to the yum init script too: https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=56 -- \/ From notting at redhat.com Mon Jul 28 01:23:02 2003 From: notting at redhat.com (Bill Nottingham) Date: Sun, 27 Jul 2003 21:23:02 -0400 Subject: split rc.sysinit In-Reply-To: ; from chuckw@quantumlinux.com on Sat, Jul 26, 2003 at 10:07:32AM -0700 References: <20030725201710.A17885@devserv.devel.redhat.com> Message-ID: <20030727212302.B12258@devserv.devel.redhat.com> Chuck Wolber (chuckw at quantumlinux.com) said: > > It's been seriously considered, just not enough round tuits yet. > > What's the policy on someone from the "civilian" world coming up with a > solution? Will RedHat accept stuff like that? Basic requirements: - have an rcS.d for sysinit stuff - get all the ordering and requirements right - fix chkconfig, ntsysv, redhat-config-services, etc. to DTRT and present a sane UI to it. Bill From david.paeme at belbone.net Mon Jul 28 06:40:36 2003 From: david.paeme at belbone.net (david paeme) Date: 28 Jul 2003 08:40:36 +0200 Subject: the installer... In-Reply-To: <1059143926.16814.59.camel@isengard> References: <1059117099.3457.103.camel@owsdavid> <1059143926.16814.59.camel@isengard> Message-ID: <1059374436.21687.4.camel@owsdavid> that's strange... I'm not getting any error directly related to power management... the system kinda hangs on hd errors... (hard to recall which exactly) but to be honest, I really didn't investigate matters deeply, I went back to running rh8, because I wanted the system up fast... On Fri, 2003-07-25 at 16:38, Jeremy Katz wrote: > On Fri, 2003-07-25 at 03:11, david paeme wrote: > > In RH9, the installer kernel is compiled for i686 (RH8 was i386). Since > > this is not a bad thing, It kinda gives some problems sometimes when > > installing on certain systems. > > For example: The installer-kernel kept on crashing when trying to do an > > install on my little home server, which has a Via C3 processor (you > > know, soldered on one of those sweet mini-itx boards), which does not > > support the i686 instruction set (almost, but it doesn't support the > > 'cmov' instruction). > > The kernel on the CD is the i586 kernel with ACPI turned on. Not the > i686. The kernel on bootdisk.img is the i386 BOOT kernel without ACPI. > If you boot from CD with 'acpi=off', does it work better? > > Jeremy > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list > From Michael.Redinger at uibk.ac.at Mon Jul 28 09:26:12 2003 From: Michael.Redinger at uibk.ac.at (Michael Redinger) Date: Mon, 28 Jul 2003 11:26:12 +0200 (CEST) Subject: Diskless workstations In-Reply-To: <3F1FDDCE.4080702@redhat.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, redhat-config-netboot is included in Taroon (it is even mentioned in the README file). Any chance this will be added to Severn too? Michael On Thu, 24 Jul 2003, Daniel J Walsh wrote: > I have been working on a package called redhat-config-netboot that > allows you to setup diskless environments > using NFS, as well as network installations. It is based somewhat off > of LTSB. It is basically a series of scripts and python code that sets > up a PXE boot environment and an diskless NFS partition. > > ftp://people.redhat.com/dwalsh/netboot > > Comments welcome. > > Dan > > Chuck Wolber wrote: > > > > > > >>No we do everything via NFS at the moment. Using a big ramdisk would cut > >>into why all the machines have so much memory and CPU's. Basically the > >>idea is that all CPU cycles are local and all data is foreign. The > >>approach to this seems to follow either SGI or Sun ways of doing > >>diskless clients. I like the Sun way of doing it (with each client > >>getting its own tree) versus the SGI where most is common with the > >>server and clients need a rebuild if server code changes. > >> > >> > > > >Can a user move to another workstation and resume their session? I've seen > >this done with RFID tags that automatically detach your session if you > >move away from the terminal and re-attach you when you move closer. > > > >-Chuck - -- Michael Redinger Zentraler Informatikdienst (Computer Centre) Universitaet Innsbruck Technikerstrasse 13 Tel.: ++43 512 507 2335 6020 Innsbruck Fax.: ++43 512 507 2944 Austria Mail: Michael.Redinger at uibk.ac.at BB98 D2FE 0F2C 2658 3780 3CB1 0FD7 A9D9 65C2 C11D http://www.uibk.ac.at/~c102mr/mred-pubkey.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/JOw9D9ep2WXCwR0RAjXNAKCPZqS5+Ecnd1DtjJh9fLpHv+c7wwCgksNq 5/kMVFmhxik1MJ26hjdQlwM= =Bo4W -----END PGP SIGNATURE----- From msw at redhat.com Mon Jul 28 16:21:07 2003 From: msw at redhat.com (Matt Wilson) Date: Mon, 28 Jul 2003 12:21:07 -0400 Subject: gtkspell problem in Severn In-Reply-To: <1059209752.1859.2.camel@laptop>; from warren@togami.com on Fri, Jul 25, 2003 at 10:55:53PM -1000 References: <1059209752.1859.2.camel@laptop> Message-ID: <20030728122107.H10571@devserv.devel.redhat.com> On Fri, Jul 25, 2003 at 10:55:53PM -1000, Warren Togami wrote: > When I attempt to run gaim-0.66 from Fedora on Severn using > gtkspell-2.0.4-1 (included in Severn), it fails with this message. hmm, strange. I thought I fixed that before Severn got cut (with /sbin/ldconfig in %post). Cheers, Matt msw at redhat.com -- Matt Wilson Manager, Base Operating Systems Red Hat, Inc. From jbj at redhat.com Mon Jul 28 16:36:04 2003 From: jbj at redhat.com (Jeff Johnson) Date: Mon, 28 Jul 2003 12:36:04 -0400 Subject: RFC: i18n proposal In-Reply-To: <16161.41106.591644.103709@uebn.uddeborg.se>; from goeran@uddeborg.se on Fri, Jul 25, 2003 at 11:26:42PM +0200 References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> <16161.41106.591644.103709@uebn.uddeborg.se> Message-ID: <20030728123604.A6922@devserv.devel.redhat.com> On Fri, Jul 25, 2003 at 11:26:42PM +0200, G?ran Uddeborg wrote: > Havoc Pennington writes: > > I didn't mean to try to address that in detail. You could do it > > several ways. Maybe rpm-coreutils-X.Y-Z.mo ? > > Ok, so you mean a separate message catalog per package, containing the > translations related to the package. That makes sense to me. > > Now, let's see if I can imagine how this would be done. > > Preparation for translation: > > 1. Descriptions, summaries, and group information are extracted from > all SPEC files. Putting descriptions and summaries in the same po > file probably makes sense, the group names could be collected in a > separate po file if convenient. > 2. This/these po files are made available for translation. (Talking > of which, when will specspo appear in this cycle? :-) > 3. As translations arrive, they are put in some dedicated hierarchy. > Call this H. (/var/lib/rpm/locale/... maybe, I'm sure a nice macro > could be used to define this. :-) > > During package build: > > 1. Rpmbuild creates a pot file containing description, summary, and > group for the package being built. > 2. For each language defined in H, look for translations of the > messages in the pot file made. This would be something like > > msgmerge -C -C ... /dev/null > > Where are all translations found in H for this language. > If the resulting file contains any translations, it is included in > the package as the translations for that language. > > When running things like "rpm -qi" or redhat-config-packages > > 1. When a description, summary, or group is to be displayed, a > translation is sought by a call to dgettext() whith a domain name > derived from the package being inspected. > The only difference from the current specspo implementation (which uses dgettext) is: you are moving the package derived retrieval key from the 2nd MSGID arg to the 1st DOMAINNAME arg without specifiying what is to replace MSGID. If you are hoping to use the MSGID from package headers as the MSGID key, then your solution is inferior to the current specspo implementation because the Group/Summary/Description then *must* be built into packages. Several attempts to compile those tags directly into package headers have all failed here at Red Hat. So what specspo does instead is to use a two stage lookup using dgettext. Here's the (simplified) sequence of operations for specspo: langval = getenv(language); setenv(language, "en_US", 1); domain = "redhat"; msgid = dgettext(domain, "rpm(Group)"); setenv(language, langval, 1); msgid = dgettext(domain, msgid); Note that Using specspo maps msgid out of package metadata as well as msgstr. Note also that domain is already being used for much what you propose. There's absolutely nothing at all stopping anyone from adding a domain to the colon seperated set of domains in the macro %{_i18ndomains} and doing exactly what you propose. If there truly become thousands of 3rd party packagers, all clamoring for their own per-package domain, the current specspo scheme is quite sound, needs only a way to discover thousands of domains through configuration. > Would this make sense? Is it approximately along the lines you meant? > (To the extent you had them thought out.) > > Would it be appropriate to put these package po files in some specific > hierarchy, separate from /usr/share/locale? (And do a corresponding > call to bindtextdomain() before calling dgettext().) > > Is the needed information always available? Like, does rpm know > enough in time to find the po files when quering a package file, for > example? > > How would one handle building single packages, not being part of a > distribution? Maybe by having an RPM directive specifying a directory > in the build tree to search for further message catalogs? Then the > translations for this package would be part of the source of the > package, which I guess would make sense. > > Or am I missing too much here? > You're missing several important points: a) msgid's, not just msgstr's, need to be handled. msgid's are not necessarily constant, nor is there (or at least gas there been) sufficient time late in a release cycle to manage "make world" rebuilds to include i18n, too many things can break. b) whatever organization you wish has to be as simple as possible to set up in an empty chroot, i.e. the environment in which anaconda runs during install. c) the goal must be to have i18n tags in metadata, fetching from the payload is a costly decompression. Sure your scheme makes sense, but is possibly different than what rpm has been doing since 6.2. There are consequences for having to support multiple schemes for the indefinite future, not the least of which is the complexity involved. IMHO the apparent driving force for revisiting an already solved problem is the perceived need to accomodate 3rd party package group/summary/description. Personally, I have yet to meet (or hear of) any single person who has even attempted the translation. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From hp at redhat.com Mon Jul 28 17:07:00 2003 From: hp at redhat.com (Havoc Pennington) Date: Mon, 28 Jul 2003 13:07:00 -0400 Subject: RFC: i18n proposal In-Reply-To: <16161.41106.591644.103709@uebn.uddeborg.se> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> <16161.41106.591644.103709@uebn.uddeborg.se> Message-ID: <20030728130700.J7222@devserv.devel.redhat.com> On Fri, Jul 25, 2003 at 11:26:42PM +0200, G?ran Uddeborg wrote: > When running things like "rpm -qi" or redhat-config-packages > > 1. When a description, summary, or group is to be displayed, a > translation is sought by a call to dgettext() whith a domain name > derived from the package being inspected. > > Would this make sense? Is it approximately along the lines you meant? > (To the extent you had them thought out.) Yes, I think so. > Would it be appropriate to put these package po files in some specific > hierarchy, separate from /usr/share/locale? (And do a corresponding > call to bindtextdomain() before calling dgettext().) It seems to be just a namespace issue to me; either in /usr/share/locale with a prefixed name such as rpm- or in a separate directory both seem fine. Maybe a separate dir is cleaner. > Is the needed information always available? Like, does rpm know > enough in time to find the po files when quering a package file, for > example? Don't know. > How would one handle building single packages, not being part of a > distribution? Maybe by having an RPM directive specifying a directory > in the build tree to search for further message catalogs? Then the > translations for this package would be part of the source of the > package, which I guess would make sense. A fair question, and I'm not there's an answer. Seems like "if you rebuild, you lose the translations" Havoc From jjneely at pams.ncsu.edu Mon Jul 28 17:12:27 2003 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Mon, 28 Jul 2003 13:12:27 -0400 Subject: gdm and missing home directories Message-ID: <20030728171227.GA27264@anduril.pams.ncsu.edu> Hi, For several releases now (I think since 8.0) gdm has popped up this cute dialog box if your home directory didn't exist asking if you would like to log in with / as your home directory. You can click on Yes, you can click on No but you always just get the gdm screen asking you to enter your username. It doesn't fail...it just doesn't work. See bug #77354 http://bugzilla.gnome.org/show_bug.cgi?id=103258 In Gnome's bugzilla the PostLogin stuff is mentioned but I'm not sure if even the gdm in Severn supports that feature. Does anyone know of a way I can make this work? Ideally, I would like to use mktemp to create a temp home dir instead of just using /. The situation is the mentality that if your fileserver is down you should still be able to take an online test, surf the web, check your webmail, etc. (Which I see nothing wrong with.) Jack Neely -- Jack Neely Linux Realm Kit Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From hp at redhat.com Mon Jul 28 18:17:08 2003 From: hp at redhat.com (Havoc Pennington) Date: Mon, 28 Jul 2003 14:17:08 -0400 Subject: gdm and missing home directories In-Reply-To: <20030728171227.GA27264@anduril.pams.ncsu.edu> References: <20030728171227.GA27264@anduril.pams.ncsu.edu> Message-ID: <20030728141708.K7222@devserv.devel.redhat.com> On Mon, Jul 28, 2003 at 01:12:27PM -0400, Jack Neely wrote: > Does anyone know of a way I can make this work? You'd have to patch gdm and/or our gdm setup, I would think. George Lebl can probably help you figure out what to change... My guess is that gdm works OK and the issue is that gnome-session or other key apps puke if they can't write to homedir. Or at least that if gdm were fixed, you'd see this issue. So it may come down to fixing whatever bugs in gnome-session etc. cause that; which is worthwile since the "hard drive is full" case triggers the same bugs. If you get the desktop working right without being able to write to disk, then using '/' for a homedir would actually allow web browsing and such. > Ideally, I would like to use mktemp to create a temp home dir > instead of just using /. The situation is the mentality that if > your fileserver is down you should still be able to take an online > test, surf the web, check your webmail, etc. (Which I see nothing > wrong with.) The problem I'd expect here would be possible user data loss; they save stuff, no error is reported, but the stuff gets trashed later. Most apps will default to saving to the homedir... If you just handle not having a writable homedir, on the other hand, users will always get an error if they try to save something. (In addition to getting the "hard disk full" case solved as a side effect.) Havoc From johnsonm at redhat.com Mon Jul 28 18:29:57 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 28 Jul 2003 14:29:57 -0400 Subject: cipe In-Reply-To: <1058989176.3288.60.camel@zorak>; from tcallawa@redhat.com on Wed, Jul 23, 2003 at 02:39:37PM -0500 References: <20030722014002.GD22711@redhat.com> <1058989176.3288.60.camel@zorak> Message-ID: <20030728142957.A10000@devserv.devel.redhat.com> On Wed, Jul 23, 2003 at 02:39:37PM -0500, Tom 'spot' Callaway wrote: > I came across all of this while dealing with Aurora. The big question > is: how does the RH kernel team feel about adding four new directories > to drivers/addon: > > cipe3-bf/ cipe3-idea/ cipe4-bf/ cipe4-idea/ > > If they don't have a problem with doing that (I was planning on > encapsulating them within a single "cipe" directory), the patches I'm > doing for Aurora should work with RHL. As has been pointed out, ditch the IDEA stuff, just build blowfish. That leaves version. So how does the sysadmin choose which one is selected? Does the daemon autonegotiate which version module to load? michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From jbj at redhat.com Mon Jul 28 18:41:34 2003 From: jbj at redhat.com (Jeff Johnson) Date: Mon, 28 Jul 2003 14:41:34 -0400 Subject: RPM building section of RHL's developer guide In-Reply-To: <1059324234.15610.233.camel@bobcat.mine.nu>; from ville.skytta@iki.fi on Sun, Jul 27, 2003 at 07:43:54PM +0300 References: <20030722122604.624f3b23.matthias@rpmforge.net> <1059021299.1858.64.camel@laptop> <20030724100009.O18401@devserv.devel.redhat.com> <1059324234.15610.233.camel@bobcat.mine.nu> Message-ID: <20030728144134.G6922@devserv.devel.redhat.com> On Sun, Jul 27, 2003 at 07:43:54PM +0300, Ville Skytt? wrote: > On Thu, 2003-07-24 at 17:00, Jeff Johnson wrote: > > > Current behavior in rpm-4.2.1 (and all future versions of rpm) is > > A missing (i.e. unsepcified) Epoch: is exactly equivalent to Epoch: 0. > > > > Whether you choose to make the Epoch: explicit is a matter of style, the > > version comparison in rpm is now deterministic, the same answer is returned > > every time. > > Let's consider a specfile without an explicit Epoch that produces > packages foo and foo-devel. Does this work in foo-devel with rpm-4.2.1? > > Requires: foo = %{epoch}:%{version} > > IIRC it doesn't work in rpm-4.2 and earlier. It'd be nice if it worked, You do not recall correctly. Without "doesn't work" definition no further analysis is possible. There are 3 behaviors wrto epoch in rpm (well 4 or 5, but early one's don't really matter any more): a) Ignore Epoch: if either value is missing. This was the behavior from rpm-3.0.2 (when versioned dependencies were implemented) until rpm-4.1. The packageing rule that was mandated at the time rpm-3.0.2 was released was If foo has explicit epoch, then foo-devel must have Requires: foo = E:V Well that worked fine, until Red Hat released a package that was not upgradeable, libogg or vorbis. This became a MUSTFIX for Red Hat 8.0 and the constraint on the problem ws "No package upgrades.". So the only solution that I could devise was b) For added packages, use behavior a), otherwise treat missing Epoch: as Epoch: 0. This is seriously confusing as two answers for rpm version comparison become possible. So, to give absolutely deterministic behavior in the future, rpm-4.2.1 is going forward with c) A missing (unspecified) Epoch: is exactly equivalent to Epoch: 0. > in the case of an Epoch bump later the inter-subpackage dependencies > would automagically follow if one doesn't fancy putting the explicit > "Epoch: 0"'s in specfiles. > > Also, outputting the 0 in cases of a missing Epoch would be nice too, I > remember trying out rpm-4.2.1 on RHL 9, and trying to install glib and > glib-devel (Epoch: 1, but a buggy requires in -devel; fixed in Severn). > The error message IIRC was: > > glib = x.x.x is required by glib-devel > > ...whereas a less confusing one IMHO would have been: > > glib = 0:x.x.x is required by glib-devel > > Ditto for "rpm -q --qf '%{epoch}:%{version}-%{release}' foo", does/could > 4.2.1 print out "0:x.y-z" instead of "(none):x.y-z" if foo doesn't have > an explicit Epoch? > Please apply the rule: A missing (unspecified) Epoch: is exactly equivalent to Epoch: 0. *Please*. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From johnsonm at redhat.com Mon Jul 28 18:47:51 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 28 Jul 2003 14:47:51 -0400 Subject: the installer... In-Reply-To: <1059374436.21687.4.camel@owsdavid>; from david.paeme@belbone.net on Mon, Jul 28, 2003 at 08:40:36AM +0200 References: <1059117099.3457.103.camel@owsdavid> <1059143926.16814.59.camel@isengard> <1059374436.21687.4.camel@owsdavid> Message-ID: <20030728144751.B10000@devserv.devel.redhat.com> On Mon, Jul 28, 2003 at 08:40:36AM +0200, david paeme wrote: > I'm not getting any error directly related to power management... > the system kinda hangs on hd errors... (hard to recall which exactly) The "C" in "ACPI" stands for "Configuration" -- the ACPI in Severn doesn't have the power management stuff, it is only for the device enumeration parts. This includes interrupt routing, which means that anything that relies on interrupts (i.e. most device drivers) can fail to work if there's a bug there. That's why we keep asking whether "acpi=off" fixes problems, and if not, whether booting with the floppy image does. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From tcallawa at redhat.com Mon Jul 28 20:06:15 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: 28 Jul 2003 15:06:15 -0500 Subject: cipe In-Reply-To: <20030724085250.GA17871@redhat.com> References: <20030722014002.GD22711@redhat.com> <1058989176.3288.60.camel@zorak> <20030724085250.GA17871@redhat.com> Message-ID: <1059422775.4085.4.camel@zorak> I originally sent this on Jul 25th, 2003... but it got eaten by the "message too large" monster, and is likely still waiting approval from the list admin. This version does NOT have the attached patches, but they're on the bugzilla entry. (Perhaps we should up the size restriction limit a bit on the -devel list to allow patches to be posted?) On Thu, 2003-07-24 at 03:52, Joe Orton wrote: > > it only includes Blowfish, just like with Cipe 1.5.x. > > > > RH has, AFAIK, only shipped Cipe with Blowfish only, and I don't know of any > > reason why it would be necessary or even desirable to include IDEA support > > suddenly just because of moving to 1.5.x. > > Indeed, IDEA is patent encumbered, we couldn't ship this at all. Both valid points. Attached are the four patches to add Cipe 1.5.4 support into the kernel. The cipe3 and cipe4 patch add the two cipe protocol trees, configured for blowfish. These patches include all relevant diffs from Red Hat's 1.4.6 cipe implementation. I also removed the check for VERSION_MAGIC, since IMHO, it was just useless to force the daemon to be built at the same time as the kernel modules. The third patch is simply a fixed version of Patch5000: linux-2.4.9-addon.patch The fourth patch is simply a fixed version of Patch10010: linux-2.4.1-compilefailure.patch. All these patches obsolete the pre-existant core cipe patches in the RHL kernel tree (Patch5190-5193). Config files will need to be updated to point to CONFIG_CIPE3 and CONFIG_CIPE4 instead of CONFIG_CIPE. This is also attached to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=68066. ~spot --- Tom "spot" Callaway SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260 The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me. "Immature poets borrow, mature poets steal." --- T. S. Eliot From ville.skytta at iki.fi Mon Jul 28 20:21:20 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: 28 Jul 2003 23:21:20 +0300 Subject: RPM building section of RHL's developer guide In-Reply-To: <20030728144134.G6922@devserv.devel.redhat.com> References: <20030722122604.624f3b23.matthias@rpmforge.net> <1059021299.1858.64.camel@laptop> <20030724100009.O18401@devserv.devel.redhat.com> <1059324234.15610.233.camel@bobcat.mine.nu> <20030728144134.G6922@devserv.devel.redhat.com> Message-ID: <1059423679.23194.166.camel@bobcat.mine.nu> On Mon, 2003-07-28 at 21:41, Jeff Johnson wrote: > On Sun, Jul 27, 2003 at 07:43:54PM +0300, Ville Skytt? wrote: > > On Thu, 2003-07-24 at 17:00, Jeff Johnson wrote: > > > > > Current behavior in rpm-4.2.1 (and all future versions of rpm) is > > > A missing (i.e. unsepcified) Epoch: is exactly equivalent to Epoch: 0. > > > > > > Whether you choose to make the Epoch: explicit is a matter of style, the > > > version comparison in rpm is now deterministic, the same answer is returned > > > every time. Perhaps internally, when versioned dependencies are being resolved. But *not always*. The base assumption I'm making here is that eg. rpm-4.2.1-0.11 in Severn represents the "current behavior" as in the above. Believe me, I've followed the Epoch discussion closely enough, and have read the history why it was made the way it is in 4.2.1. IMO that's good. And yes, I'm nitpicking, very much so. See below, and beware, this is more verbose than I would like it to be. Sorry. > > Let's consider a specfile without an explicit Epoch that produces > > packages foo and foo-devel. Does this work in foo-devel with rpm-4.2.1? > > > > Requires: foo = %{epoch}:%{version} > > > > IIRC it doesn't work in rpm-4.2 and earlier. It'd be nice if it worked, > > You do not recall correctly. Without "doesn't work" definition no further > analysis is possible. "Doesn't work" == "The package cannot be built". And with this definition, it turns out that I do remember correctly; it "doesn't work" with 4.2. Nor does it with 4.2.1. See the attached specfile, here are some test results with it: rpm-4.2-1 on Shrike: $ rpmbuild -bb foo.spec error: line 8: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: %{epoch}:1-1.0 rpm-4.2.1-0.11 on Severn: $ rpmbuild -bb foo.spec error: line 8: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: %{epoch}:1-1.0 If "no Epoch" == "Epoch: 0" in 4.2.1, why the error? It is *not* a matter of style; if I add the explicit "Epoch: 0" in the attached foo.spec, the rpmbuild completes with both versions. > > Also, outputting the 0 in cases of a missing Epoch would be nice too, I > > remember trying out rpm-4.2.1 on RHL 9, and trying to install glib and > > glib-devel (Epoch: 1, but a buggy requires in -devel; fixed in Severn). > > The error message IIRC was: > > > > glib = x.x.x is required by glib-devel > > > > ...whereas a less confusing one IMHO would have been: > > > > glib = 0:x.x.x is required by glib-devel > > > > Ditto for "rpm -q --qf '%{epoch}:%{version}-%{release}' foo", does/could > > 4.2.1 print out "0:x.y-z" instead of "(none):x.y-z" if foo doesn't have > > an explicit Epoch? > > > > Please apply the rule: > A missing (unspecified) Epoch: is exactly equivalent to Epoch: 0. > > *Please*. I can apply that. But why? rpm has already applied the rule, why do I have to remember to apply it? Why not go all the way and make it explicit and clear everywhere by always outputting "0" instead of "(none)" (eg. in --qf %{epoch}) or leaving it out altogether as in the example above? Just for the record, here is the exact output of the case above, on a Shrike box after upgrading to rpm-4.2.1-0.15.fdr.1: # rpm -q --qf "%{name}-%{epoch}:%{version}-%{release}\n" glib glib-1:1.2.10-10 # rpm -Uvh glib-devel-1.2.10-10.i386.rpm error: Failed dependencies: glib = 1.2.10 is needed by glib-devel-1.2.10-10 Yes, *I know* there's a missing "1:" in this particular glib-devel-to-glib-dependency but why isn't the error message the following, IMO less confusing one? error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-1.2.10-10 Will shut up now. Hopefully I haven't annoyed anyone. -- \/ -------------- next part -------------- Name: foo Version: 1 Release: 1.0 License: foo Summary: foo Group: foo %package devel Requires: %{epoch}:%{version}-%{release} %files %files devel From johnsonm at redhat.com Mon Jul 28 20:21:32 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 28 Jul 2003 16:21:32 -0400 Subject: cipe In-Reply-To: <1059422775.4085.4.camel@zorak>; from tcallawa@redhat.com on Mon, Jul 28, 2003 at 03:06:15PM -0500 References: <20030722014002.GD22711@redhat.com> <1058989176.3288.60.camel@zorak> <20030724085250.GA17871@redhat.com> <1059422775.4085.4.camel@zorak> Message-ID: <20030728162132.C10000@devserv.devel.redhat.com> On Mon, Jul 28, 2003 at 03:06:15PM -0500, Tom 'spot' Callaway wrote: > (Perhaps we should up the size restriction limit a bit on the -devel > list to allow patches to be posted?) Or leave it the way it is to encourage aggressive use of bugzilla! > Both valid points. Attached are the four patches to add Cipe 1.5.4 > support into the kernel. The cipe3 and cipe4 patch add the two cipe > protocol trees, configured for blowfish. These patches include all > relevant diffs from Red Hat's 1.4.6 cipe implementation. I also removed > the check for VERSION_MAGIC, since IMHO, it was just useless to force > the daemon to be built at the same time as the kernel modules. With all your patches applied, what happens from the user perspective? How do they connect to a system only running protocol version 3? Ditto 4? michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From katzj at redhat.com Mon Jul 28 20:27:08 2003 From: katzj at redhat.com (Jeremy Katz) Date: 28 Jul 2003 16:27:08 -0400 Subject: patch submission and review (Was: Re: cipe) In-Reply-To: <20030728162132.C10000@devserv.devel.redhat.com> References: <20030722014002.GD22711@redhat.com> <1058989176.3288.60.camel@zorak> <20030724085250.GA17871@redhat.com> <1059422775.4085.4.camel@zorak> <20030728162132.C10000@devserv.devel.redhat.com> Message-ID: <1059424028.21365.104.camel@mirkwood.devel.redhat.com> On Mon, 2003-07-28 at 16:21, Michael K. Johnson wrote: > On Mon, Jul 28, 2003 at 03:06:15PM -0500, Tom 'spot' Callaway wrote: > > (Perhaps we should up the size restriction limit a bit on the -devel > > list to allow patches to be posted?) > > Or leave it the way it is to encourage aggressive use of bugzilla! It's nice having patches both on lists and in bugzilla, IMHO. Bugzilla helps to keep them from getting lost, but it's a lot easier to critique patches via mail where you can reply and quote the bits you want to critique. Jeremy From tcallawa at redhat.com Mon Jul 28 20:29:28 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: 28 Jul 2003 15:29:28 -0500 Subject: cipe In-Reply-To: <20030728162132.C10000@devserv.devel.redhat.com> References: <20030722014002.GD22711@redhat.com> <1058989176.3288.60.camel@zorak> <20030724085250.GA17871@redhat.com> <1059422775.4085.4.camel@zorak> <20030728162132.C10000@devserv.devel.redhat.com> Message-ID: <1059424167.4085.20.camel@zorak> On Mon, 2003-07-28 at 15:21, Michael K. Johnson wrote: > On Mon, Jul 28, 2003 at 03:06:15PM -0500, Tom 'spot' Callaway wrote: > > (Perhaps we should up the size restriction limit a bit on the -devel > > list to allow patches to be posted?) > > Or leave it the way it is to encourage aggressive use of bugzilla! I know to use bugzilla, others may not. Perhaps the "message too big" response could point patch submissions to bugzilla? > > Both valid points. Attached are the four patches to add Cipe 1.5.4 > > support into the kernel. The cipe3 and cipe4 patch add the two cipe > > protocol trees, configured for blowfish. These patches include all > > relevant diffs from Red Hat's 1.4.6 cipe implementation. I also removed > > the check for VERSION_MAGIC, since IMHO, it was just useless to force > > the daemon to be built at the same time as the kernel modules. > > With all your patches applied, what happens from the user perspective? > How do they connect to a system only running protocol version 3? > Ditto 4? Well, a kernel built with this (and CONFIG_CIPE3=m and CONFIG_CIPE4=m) generates two modules: cipcb.o (v3) cipdb.o (v4) If you need to connect to a v3 machine, use the cipcb.o module, v4, the latter. Admittedly, the userspace needs some fixups too. Basically, the cipe package needs to be split into a v3/v4 manner (think krb, but not quite so bad), so that you install what you need. However, getting the kernel to support it is the first step. I'm planning on doing the userspace work at some point this week. :) ~spot --- Tom "spot" Callaway SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260 The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me. "Immature poets borrow, mature poets steal." --- T. S. Eliot From ted at cypress.com Mon Jul 28 20:42:12 2003 From: ted at cypress.com (Thomas Dodd) Date: Mon, 28 Jul 2003 15:42:12 -0500 Subject: RPM building section of RHL's developer guide In-Reply-To: <1059423679.23194.166.camel@bobcat.mine.nu> References: <20030722122604.624f3b23.matthias@rpmforge.net> <1059021299.1858.64.camel@laptop> <20030724100009.O18401@devserv.devel.redhat.com> <1059324234.15610.233.camel@bobcat.mine.nu> <20030728144134.G6922@devserv.devel.redhat.com> <1059423679.23194.166.camel@bobcat.mine.nu> Message-ID: <3F258AA4.1040601@cypress.com> Ville Skytt? wrote: > And yes, I'm nitpicking, very much so. See below, and beware, this is > more verbose than I would like it to be. Sorry. > Just for the record, here is the exact output of the case above, on a > Shrike box after upgrading to rpm-4.2.1-0.15.fdr.1: > > # rpm -q --qf "%{name}-%{epoch}:%{version}-%{release}\n" glib > glib-1:1.2.10-10 > # rpm -Uvh glib-devel-1.2.10-10.i386.rpm > error: Failed dependencies: > glib = 1.2.10 is needed by glib-devel-1.2.10-10 > > Yes, *I know* there's a missing "1:" in this particular > glib-devel-to-glib-dependency but why isn't the error message the > following, IMO less confusing one? > > error: Failed dependencies: > glib = 0:1.2.10 is needed by glib-devel-1.2.10-10 Just to nitpick a little more, shouldn't that be: error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-0:1.2.10-10 For completeness? -Thomas From jbj at redhat.com Mon Jul 28 20:51:47 2003 From: jbj at redhat.com (Jeff Johnson) Date: Mon, 28 Jul 2003 16:51:47 -0400 Subject: RPM building section of RHL's developer guide In-Reply-To: <1059423679.23194.166.camel@bobcat.mine.nu>; from ville.skytta@iki.fi on Mon, Jul 28, 2003 at 11:21:20PM +0300 References: <20030722122604.624f3b23.matthias@rpmforge.net> <1059021299.1858.64.camel@laptop> <20030724100009.O18401@devserv.devel.redhat.com> <1059324234.15610.233.camel@bobcat.mine.nu> <20030728144134.G6922@devserv.devel.redhat.com> <1059423679.23194.166.camel@bobcat.mine.nu> Message-ID: <20030728165147.M6922@devserv.devel.redhat.com> On Mon, Jul 28, 2003 at 11:21:20PM +0300, Ville Skytt? wrote: > > rpm-4.2-1 on Shrike: > > $ rpmbuild -bb foo.spec > error: line 8: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: %{epoch}:1-1.0 > Bah, pure syntax, packaging error. Try Requires: %{name} = %{?epoch:%{epoch}:}%{version} If epoch exists, than prefix with epoch value and ':' etc, etc And this syntax is supported (or broken ;-), in almost all rpm releases back to rpm-3.0. > > I can apply that. But why? rpm has already applied the rule, why do I Above is a rule that applies. If epoch is used, then add; otherwise don't bother. > have to remember to apply it? Why not go all the way and make it > explicit and clear everywhere by always outputting "0" instead of > "(none)" (eg. in --qf %{epoch}) or leaving it out altogether as in the > example above? > > Just for the record, here is the exact output of the case above, on a > Shrike box after upgrading to rpm-4.2.1-0.15.fdr.1: > > # rpm -q --qf "%{name}-%{epoch}:%{version}-%{release}\n" glib > glib-1:1.2.10-10 > # rpm -Uvh glib-devel-1.2.10-10.i386.rpm > error: Failed dependencies: > glib = 1.2.10 is needed by glib-devel-1.2.10-10 > > Yes, *I know* there's a missing "1:" in this particular > glib-devel-to-glib-dependency but why isn't the error message the > following, IMO less confusing one? > > error: Failed dependencies: > glib = 0:1.2.10 is needed by glib-devel-1.2.10-10 > Not annoyed, Epoch: just gets old sometimes. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From johnsonm at redhat.com Mon Jul 28 20:55:05 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 28 Jul 2003 16:55:05 -0400 Subject: cipe In-Reply-To: <1059424167.4085.20.camel@zorak>; from tcallawa@redhat.com on Mon, Jul 28, 2003 at 03:29:28PM -0500 References: <20030722014002.GD22711@redhat.com> <1058989176.3288.60.camel@zorak> <20030724085250.GA17871@redhat.com> <1059422775.4085.4.camel@zorak> <20030728162132.C10000@devserv.devel.redhat.com> <1059424167.4085.20.camel@zorak> Message-ID: <20030728165505.D10000@devserv.devel.redhat.com> On Mon, Jul 28, 2003 at 03:29:28PM -0500, Tom 'spot' Callaway wrote: > I know to use bugzilla, others may not. Perhaps the "message too big" > response could point patch submissions to bugzilla? Jeremy's response was probably right -- good to be able to review patches in email. > Well, a kernel built with this (and CONFIG_CIPE3=m and CONFIG_CIPE4=m) > generates two modules: > cipcb.o (v3) > cipdb.o (v4) > > If you need to connect to a v3 machine, use the cipcb.o module, v4, the > latter. Or, more to the purpose: cipcb and cipdb as interface names. > Admittedly, the userspace needs some fixups too. Basically, the cipe > package needs to be split into a v3/v4 manner (think krb, but not quite > so bad), so that you install what you need. However, getting the kernel > to support it is the first step. I'm planning on doing the userspace > work at some point this week. :) No need to split into multiple cipe userspace packages (there's not a separate kernel package for each of the two cipe modules) -- it just needs to do the right thing automatically in each case. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From ville.skytta at iki.fi Mon Jul 28 20:55:29 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: 28 Jul 2003 23:55:29 +0300 Subject: RPM building section of RHL's developer guide In-Reply-To: <3F258AA4.1040601@cypress.com> References: <20030722122604.624f3b23.matthias@rpmforge.net> <1059021299.1858.64.camel@laptop> <20030724100009.O18401@devserv.devel.redhat.com> <1059324234.15610.233.camel@bobcat.mine.nu> <20030728144134.G6922@devserv.devel.redhat.com> <1059423679.23194.166.camel@bobcat.mine.nu> <3F258AA4.1040601@cypress.com> Message-ID: <1059425729.23194.186.camel@bobcat.mine.nu> On Mon, 2003-07-28 at 23:42, Thomas Dodd wrote: > Just to nitpick a little more, shouldn't that be: > > error: Failed dependencies: > glib = 0:1.2.10 is needed by glib-devel-0:1.2.10-10 > > For completeness? Couldn't resist to comment :) That would be sort of new functionality, epochs haven't traditionally appeared in foo-x.x-x -style outputs (not that I would have anything against it, +1 FWIW), whereas in foo = x:x.x-x they are and have been visible when _explicit_ epochs, for all values of them, are involved. But in this particular case, following your suggestion, the message should actually be this :} error: Failed dependencies: glib = 0:1.2.10 is needed by glib-devel-1:1.2.10-10 ^ -- \/ From aoliva at redhat.com Fri Jul 25 01:37:46 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Jul 2003 22:37:46 -0300 Subject: RFE: Other "Everything" installs In-Reply-To: <1059080055.31800.74.camel@mirkwood.devel.redhat.com> References: <1059078129.2622.67.camel@mentor.gurulabs.com> <1059080055.31800.74.camel@mirkwood.devel.redhat.com> Message-ID: On Jul 24, 2003, Jeremy Katz wrote: > Everything except some stuff has always seemed like a silly thing to me > because everybody is going to have a different idea of what "some stuff" > is for them. How about the following new categories (we can always work out what to place on each of them later): - Nearly everything - Pretty much everything - Everything I might want to use - Everything - Everything, really (currently known as everything) :-D /me runs -- Alexandre Oliva, GCC Team, Red Hat From tcallawa at redhat.com Fri Jul 25 16:25:12 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: 25 Jul 2003 11:25:12 -0500 Subject: cipe In-Reply-To: <20030724085250.GA17871@redhat.com> References: <20030722014002.GD22711@redhat.com> <1058989176.3288.60.camel@zorak> <20030724085250.GA17871@redhat.com> Message-ID: <1059150312.3253.105.camel@zorak> On Thu, 2003-07-24 at 03:52, Joe Orton wrote: > > it only includes Blowfish, just like with Cipe 1.5.x. > > > > RH has, AFAIK, only shipped Cipe with Blowfish only, and I don't know of any > > reason why it would be necessary or even desirable to include IDEA support > > suddenly just because of moving to 1.5.x. > > Indeed, IDEA is patent encumbered, we couldn't ship this at all. Both valid points. Attached are the four patches to add Cipe 1.5.4 support into the kernel. The cipe3 and cipe4 patch add the two cipe protocol trees, configured for blowfish. These patches include all relevant diffs from Red Hat's 1.4.6 cipe implementation. I also removed the check for VERSION_MAGIC, since IMHO, it was just useless to force the daemon to be built at the same time as the kernel modules. The third patch is simply a fixed version of Patch5000: linux-2.4.9-addon.patch The fourth patch is simply a fixed version of Patch10010: linux-2.4.1-compilefailure.patch. All these patches obsolete the pre-existant core cipe patches in the RHL kernel tree (Patch5190-5193). Config files will need to be updated to point to CONFIG_CIPE3 and CONFIG_CIPE4 instead of CONFIG_CIPE. This is also attached to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=68066. ~spot --- Tom "spot" Callaway SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260 The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me. "Immature poets borrow, mature poets steal." --- T. S. Eliot -------------- next part -------------- --- linux-2.4.21/drivers/addon/cipe3/Makefile.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/Makefile Fri Jul 25 15:02:11 2003 @@ -0,0 +1,23 @@ +# -*-Makefile-*- template for the CIPE kernel module and driver. +# Copyright 1996 Olaf Titz +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License +# as published by the Free Software Foundation; either version +# 2 of the License, or (at your option) any later version. + +O_TARGET := cipcb.o + +obj-y := module.o device.o sock.o output.o encaps.o crc32.o bf.o +obj-m := $(O_TARGET) + +ifeq ($(ARCH),i386) + obj-y += bf-i386.o +endif + +include $(TOPDIR)/Rules.make + +ifeq ($(ARCH),i386) +bf-i386.o: bf-i386.S + $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -c -o $@ $< +endif --- linux-2.4.21/drivers/addon/cipe3/bf.c.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/bf.c Fri Jul 25 15:02:11 2003 @@ -0,0 +1,552 @@ +/* + Bruce Schneier's Blowfish. + Author: Olaf Titz + + This code is in the public domain. + + $Id: bf.c,v 1.4 2000/10/26 10:11:08 olaf Exp $ +*/ + +#include "bf.h" + +#ifdef __KERNEL__ +#include +#include +#else +#include +#endif + +#ifndef ASM_BF_Crypt + +/* The generic big/little endian routines use the following imported + from under Linux: + __u32 __be32_to_cpup(__u32 *p); + __u32 __cpu_to_be32(__u32 x); + __u32 __le32_to_cpup(__u32 *p); + __u32 __cpu_to_le32(__u32 x); + These are macros. We provide replacements if necessary (non-Linux). + XXX the pointer types are wrong, but else a cast would be necessary. +*/ + +#ifdef __GNUC__ +#define INLINE static inline +#else +#define INLINE static +#endif + +#ifndef __be32_to_cpup +INLINE __u32 __be32_to_cpup(unsigned char *p) +{ + return (p[0]<<24)+(p[1]<<16)+(p[2]<<8)+p[3]; +} +#endif + +#ifndef __cpu_to_be32 +INLINE __u32 __cpu_to_be32(__u32 x) +{ + register unsigned char *p=(unsigned char *)&x; + return (p[0]<<24)+(p[1]<<16)+(p[2]<<8)+p[3]; +} +#endif + +#ifndef __le32_to_cpup +INLINE __u32 __le32_to_cpup(unsigned char *p) +{ + return (p[3]<<24)+(p[2]<<16)+(p[1]<<8)+p[0]; +} +#endif + +#ifndef __cpu_to_le32 +INLINE __u32 __cpu_to_le32(__u32 x) +{ + register unsigned char *p=(unsigned char *)&x; + return (p[3]<<24)+(p[2]<<16)+(p[1]<<8)+p[0]; +} +#endif + +/* Macros to implement the round function. */ + +/* access the P and S boxes in key array */ +#define P(n) (key[(n)]) +#define S0(n) (key[(n)+18]) +#define S1(n) (key[(n)+274]) +#define S2(n) (key[(n)+530]) +#define S3(n) (key[(n)+786]) +/* access byte in word */ +#define B0(x) (((x)>>24)&255) +#define B1(x) (((x)>>16)&255) +#define B2(x) (((x)>>8)&255) +#define B3(x) (((x))&255) +/* one raw round sans swap. p is running ptr into P box array */ +#define F(x) (((S0(B0(x))+S1(B1(x)))^S2(B2(x)))+S3(B3(x))) +#define RoundP(a,b) (a)^=(*p++)^F(b) +#define RoundN(a,b) (a)^=(*p--)^F(b) + +/* 16 rounds with running pointer and word swapping */ +#define RoundsP \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r) + +#define RoundsN \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r) + +/* Native byte order routines */ + +void _N_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=(const __u32 *)key; + register unsigned long + l=((__u32 *)dataIn)[0]^(*p++), + r=((__u32 *)dataIn)[1]; + RoundsP; + ((__u32 *)dataOut)[0]=r^(*p); + ((__u32 *)dataOut)[1]=l; +} + +void _N_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=((const __u32 *)key)+17; + register unsigned long + l=((__u32 *)dataIn)[0]^(*p--), + r=((__u32 *)dataIn)[1]; + RoundsN; + ((__u32 *)dataOut)[0]=r^(*p); + ((__u32 *)dataOut)[1]=l; +} + +/* Big-endian routines (i.e. real Blowfish) */ + +#ifndef BF_DONTNEED_BE +#ifndef BF_NATIVE_BE +void B_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=(const __u32 *)key; + register unsigned long + l=__be32_to_cpup(dataIn)^(*p++), + r=__be32_to_cpup(dataIn+4); + RoundsP; + ((__u32 *)dataOut)[0]=__cpu_to_be32(r^(*p)); + ((__u32 *)dataOut)[1]=__cpu_to_be32(l); +} + +void B_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=((const __u32 *)key)+17; + register unsigned long + l=__be32_to_cpup(dataIn)^(*p--), + r=__be32_to_cpup(dataIn+4); + RoundsN; + ((__u32 *)dataOut)[0]=__cpu_to_be32(r^(*p)); + ((__u32 *)dataOut)[1]=__cpu_to_be32(l); +} +#endif +#endif + +/* Little-endian routines */ + +#ifndef BF_DONTNEED_LE +#ifndef BF_NATIVE_LE +void L_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=key; + register unsigned long + l=__le32_to_cpup(dataIn)^(*p++), + r=__le32_to_cpup(dataIn+4); + RoundsP; + ((__u32 *)dataOut)[0]=__cpu_to_le32(r^(*p)); + ((__u32 *)dataOut)[1]=__cpu_to_le32(l); +} + +void L_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=key+17; + register unsigned long + l=__le32_to_cpup(dataIn)^(*p--), + r=__le32_to_cpup(dataIn+4); + RoundsN; + ((__u32 *)dataOut)[0]=__cpu_to_le32(r^(*p)); + ((__u32 *)dataOut)[1]=__cpu_to_le32(l); +} +#endif +#endif + +/* Key setup */ + +void Blowfish_ExpandUserKey(const char *userKey, int userKeyLen, + Blowfish_Key key) +{ + char d[8] = {0, 0, 0, 0, 0, 0, 0, 0}; + int i, j; + __u32 u; + + #define UK (userKey[j]&255) + #define UKI if (++j>=userKeyLen) j=0 + for (i=j=0; i<18; ++i) { + u=UK; UKI; + u=(u<<8)+UK; UKI; + u=(u<<8)+UK; UKI; + u=(u<<8)+UK; UKI; + key[i]=Blowfish_Init_Key[i]^u; + } + memcpy(key+18, Blowfish_Init_Key+18, 4096); + for (i=0; i<1042; i+=2) { + _N_Blowfish_Encrypt(d, d, key); + key[i]=((__u32 *)d)[0]; + key[i+1]=((__u32 *)d)[1]; + } +} + +#endif + +/* The initialization key. According to Schneier, this is not a magic + pattern but simply the first 33344 (after point) bits of "pi". */ + +const Blowfish_Key Blowfish_Init_Key = { + /* The eighteen P boxes @ 1 word */ + 0x243f6a88, 0x85a308d3, 0x13198a2e, 0x03707344, + 0xa4093822, 0x299f31d0, 0x082efa98, 0xec4e6c89, + 0x452821e6, 0x38d01377, 0xbe5466cf, 0x34e90c6c, + 0xc0ac29b7, 0xc97c50dd, 0x3f84d5b5, 0xb5470917, + 0x9216d5d9, 0x8979fb1b, + /* The four S boxes @ 256 words */ + 0xd1310ba6, 0x98dfb5ac, 0x2ffd72db, 0xd01adfb7, + 0xb8e1afed, 0x6a267e96, 0xba7c9045, 0xf12c7f99, + 0x24a19947, 0xb3916cf7, 0x0801f2e2, 0x858efc16, + 0x636920d8, 0x71574e69, 0xa458fea3, 0xf4933d7e, + 0x0d95748f, 0x728eb658, 0x718bcd58, 0x82154aee, + 0x7b54a41d, 0xc25a59b5, 0x9c30d539, 0x2af26013, + 0xc5d1b023, 0x286085f0, 0xca417918, 0xb8db38ef, + 0x8e79dcb0, 0x603a180e, 0x6c9e0e8b, 0xb01e8a3e, + 0xd71577c1, 0xbd314b27, 0x78af2fda, 0x55605c60, + 0xe65525f3, 0xaa55ab94, 0x57489862, 0x63e81440, + 0x55ca396a, 0x2aab10b6, 0xb4cc5c34, 0x1141e8ce, + 0xa15486af, 0x7c72e993, 0xb3ee1411, 0x636fbc2a, + 0x2ba9c55d, 0x741831f6, 0xce5c3e16, 0x9b87931e, + 0xafd6ba33, 0x6c24cf5c, 0x7a325381, 0x28958677, + 0x3b8f4898, 0x6b4bb9af, 0xc4bfe81b, 0x66282193, + 0x61d809cc, 0xfb21a991, 0x487cac60, 0x5dec8032, + 0xef845d5d, 0xe98575b1, 0xdc262302, 0xeb651b88, + 0x23893e81, 0xd396acc5, 0x0f6d6ff3, 0x83f44239, + 0x2e0b4482, 0xa4842004, 0x69c8f04a, 0x9e1f9b5e, + 0x21c66842, 0xf6e96c9a, 0x670c9c61, 0xabd388f0, + 0x6a51a0d2, 0xd8542f68, 0x960fa728, 0xab5133a3, + 0x6eef0b6c, 0x137a3be4, 0xba3bf050, 0x7efb2a98, + 0xa1f1651d, 0x39af0176, 0x66ca593e, 0x82430e88, + 0x8cee8619, 0x456f9fb4, 0x7d84a5c3, 0x3b8b5ebe, + 0xe06f75d8, 0x85c12073, 0x401a449f, 0x56c16aa6, + 0x4ed3aa62, 0x363f7706, 0x1bfedf72, 0x429b023d, + 0x37d0d724, 0xd00a1248, 0xdb0fead3, 0x49f1c09b, + 0x075372c9, 0x80991b7b, 0x25d479d8, 0xf6e8def7, + 0xe3fe501a, 0xb6794c3b, 0x976ce0bd, 0x04c006ba, + 0xc1a94fb6, 0x409f60c4, 0x5e5c9ec2, 0x196a2463, + 0x68fb6faf, 0x3e6c53b5, 0x1339b2eb, 0x3b52ec6f, + 0x6dfc511f, 0x9b30952c, 0xcc814544, 0xaf5ebd09, + 0xbee3d004, 0xde334afd, 0x660f2807, 0x192e4bb3, + 0xc0cba857, 0x45c8740f, 0xd20b5f39, 0xb9d3fbdb, + 0x5579c0bd, 0x1a60320a, 0xd6a100c6, 0x402c7279, + 0x679f25fe, 0xfb1fa3cc, 0x8ea5e9f8, 0xdb3222f8, + 0x3c7516df, 0xfd616b15, 0x2f501ec8, 0xad0552ab, + 0x323db5fa, 0xfd238760, 0x53317b48, 0x3e00df82, + 0x9e5c57bb, 0xca6f8ca0, 0x1a87562e, 0xdf1769db, + 0xd542a8f6, 0x287effc3, 0xac6732c6, 0x8c4f5573, + 0x695b27b0, 0xbbca58c8, 0xe1ffa35d, 0xb8f011a0, + 0x10fa3d98, 0xfd2183b8, 0x4afcb56c, 0x2dd1d35b, + 0x9a53e479, 0xb6f84565, 0xd28e49bc, 0x4bfb9790, + 0xe1ddf2da, 0xa4cb7e33, 0x62fb1341, 0xcee4c6e8, + 0xef20cada, 0x36774c01, 0xd07e9efe, 0x2bf11fb4, + 0x95dbda4d, 0xae909198, 0xeaad8e71, 0x6b93d5a0, + 0xd08ed1d0, 0xafc725e0, 0x8e3c5b2f, 0x8e7594b7, + 0x8ff6e2fb, 0xf2122b64, 0x8888b812, 0x900df01c, + 0x4fad5ea0, 0x688fc31c, 0xd1cff191, 0xb3a8c1ad, + 0x2f2f2218, 0xbe0e1777, 0xea752dfe, 0x8b021fa1, + 0xe5a0cc0f, 0xb56f74e8, 0x18acf3d6, 0xce89e299, + 0xb4a84fe0, 0xfd13e0b7, 0x7cc43b81, 0xd2ada8d9, + 0x165fa266, 0x80957705, 0x93cc7314, 0x211a1477, + 0xe6ad2065, 0x77b5fa86, 0xc75442f5, 0xfb9d35cf, + 0xebcdaf0c, 0x7b3e89a0, 0xd6411bd3, 0xae1e7e49, + 0x00250e2d, 0x2071b35e, 0x226800bb, 0x57b8e0af, + 0x2464369b, 0xf009b91e, 0x5563911d, 0x59dfa6aa, + 0x78c14389, 0xd95a537f, 0x207d5ba2, 0x02e5b9c5, + 0x83260376, 0x6295cfa9, 0x11c81968, 0x4e734a41, + 0xb3472dca, 0x7b14a94a, 0x1b510052, 0x9a532915, + 0xd60f573f, 0xbc9bc6e4, 0x2b60a476, 0x81e67400, + 0x08ba6fb5, 0x571be91f, 0xf296ec6b, 0x2a0dd915, + 0xb6636521, 0xe7b9f9b6, 0xff34052e, 0xc5855664, + 0x53b02d5d, 0xa99f8fa1, 0x08ba4799, 0x6e85076a, + 0x4b7a70e9, 0xb5b32944, 0xdb75092e, 0xc4192623, + 0xad6ea6b0, 0x49a7df7d, 0x9cee60b8, 0x8fedb266, + 0xecaa8c71, 0x699a17ff, 0x5664526c, 0xc2b19ee1, + 0x193602a5, 0x75094c29, 0xa0591340, 0xe4183a3e, + 0x3f54989a, 0x5b429d65, 0x6b8fe4d6, 0x99f73fd6, + 0xa1d29c07, 0xefe830f5, 0x4d2d38e6, 0xf0255dc1, + 0x4cdd2086, 0x8470eb26, 0x6382e9c6, 0x021ecc5e, + 0x09686b3f, 0x3ebaefc9, 0x3c971814, 0x6b6a70a1, + 0x687f3584, 0x52a0e286, 0xb79c5305, 0xaa500737, + 0x3e07841c, 0x7fdeae5c, 0x8e7d44ec, 0x5716f2b8, + 0xb03ada37, 0xf0500c0d, 0xf01c1f04, 0x0200b3ff, + 0xae0cf51a, 0x3cb574b2, 0x25837a58, 0xdc0921bd, + 0xd19113f9, 0x7ca92ff6, 0x94324773, 0x22f54701, + 0x3ae5e581, 0x37c2dadc, 0xc8b57634, 0x9af3dda7, + 0xa9446146, 0x0fd0030e, 0xecc8c73e, 0xa4751e41, + 0xe238cd99, 0x3bea0e2f, 0x3280bba1, 0x183eb331, + 0x4e548b38, 0x4f6db908, 0x6f420d03, 0xf60a04bf, + 0x2cb81290, 0x24977c79, 0x5679b072, 0xbcaf89af, + 0xde9a771f, 0xd9930810, 0xb38bae12, 0xdccf3f2e, + 0x5512721f, 0x2e6b7124, 0x501adde6, 0x9f84cd87, + 0x7a584718, 0x7408da17, 0xbc9f9abc, 0xe94b7d8c, + 0xec7aec3a, 0xdb851dfa, 0x63094366, 0xc464c3d2, + 0xef1c1847, 0x3215d908, 0xdd433b37, 0x24c2ba16, + 0x12a14d43, 0x2a65c451, 0x50940002, 0x133ae4dd, + 0x71dff89e, 0x10314e55, 0x81ac77d6, 0x5f11199b, + 0x043556f1, 0xd7a3c76b, 0x3c11183b, 0x5924a509, + 0xf28fe6ed, 0x97f1fbfa, 0x9ebabf2c, 0x1e153c6e, + 0x86e34570, 0xeae96fb1, 0x860e5e0a, 0x5a3e2ab3, + 0x771fe71c, 0x4e3d06fa, 0x2965dcb9, 0x99e71d0f, + 0x803e89d6, 0x5266c825, 0x2e4cc978, 0x9c10b36a, + 0xc6150eba, 0x94e2ea78, 0xa5fc3c53, 0x1e0a2df4, + 0xf2f74ea7, 0x361d2b3d, 0x1939260f, 0x19c27960, + 0x5223a708, 0xf71312b6, 0xebadfe6e, 0xeac31f66, + 0xe3bc4595, 0xa67bc883, 0xb17f37d1, 0x018cff28, + 0xc332ddef, 0xbe6c5aa5, 0x65582185, 0x68ab9802, + 0xeecea50f, 0xdb2f953b, 0x2aef7dad, 0x5b6e2f84, + 0x1521b628, 0x29076170, 0xecdd4775, 0x619f1510, + 0x13cca830, 0xeb61bd96, 0x0334fe1e, 0xaa0363cf, + 0xb5735c90, 0x4c70a239, 0xd59e9e0b, 0xcbaade14, + 0xeecc86bc, 0x60622ca7, 0x9cab5cab, 0xb2f3846e, + 0x648b1eaf, 0x19bdf0ca, 0xa02369b9, 0x655abb50, + 0x40685a32, 0x3c2ab4b3, 0x319ee9d5, 0xc021b8f7, + 0x9b540b19, 0x875fa099, 0x95f7997e, 0x623d7da8, + 0xf837889a, 0x97e32d77, 0x11ed935f, 0x16681281, + 0x0e358829, 0xc7e61fd6, 0x96dedfa1, 0x7858ba99, + 0x57f584a5, 0x1b227263, 0x9b83c3ff, 0x1ac24696, + 0xcdb30aeb, 0x532e3054, 0x8fd948e4, 0x6dbc3128, + 0x58ebf2ef, 0x34c6ffea, 0xfe28ed61, 0xee7c3c73, + 0x5d4a14d9, 0xe864b7e3, 0x42105d14, 0x203e13e0, + 0x45eee2b6, 0xa3aaabea, 0xdb6c4f15, 0xfacb4fd0, + 0xc742f442, 0xef6abbb5, 0x654f3b1d, 0x41cd2105, + 0xd81e799e, 0x86854dc7, 0xe44b476a, 0x3d816250, + 0xcf62a1f2, 0x5b8d2646, 0xfc8883a0, 0xc1c7b6a3, + 0x7f1524c3, 0x69cb7492, 0x47848a0b, 0x5692b285, + 0x095bbf00, 0xad19489d, 0x1462b174, 0x23820e00, + 0x58428d2a, 0x0c55f5ea, 0x1dadf43e, 0x233f7061, + 0x3372f092, 0x8d937e41, 0xd65fecf1, 0x6c223bdb, + 0x7cde3759, 0xcbee7460, 0x4085f2a7, 0xce77326e, + 0xa6078084, 0x19f8509e, 0xe8efd855, 0x61d99735, + 0xa969a7aa, 0xc50c06c2, 0x5a04abfc, 0x800bcadc, + 0x9e447a2e, 0xc3453484, 0xfdd56705, 0x0e1e9ec9, + 0xdb73dbd3, 0x105588cd, 0x675fda79, 0xe3674340, + 0xc5c43465, 0x713e38d8, 0x3d28f89e, 0xf16dff20, + 0x153e21e7, 0x8fb03d4a, 0xe6e39f2b, 0xdb83adf7, + 0xe93d5a68, 0x948140f7, 0xf64c261c, 0x94692934, + 0x411520f7, 0x7602d4f7, 0xbcf46b2e, 0xd4a20068, + 0xd4082471, 0x3320f46a, 0x43b7d4b7, 0x500061af, + 0x1e39f62e, 0x97244546, 0x14214f74, 0xbf8b8840, + 0x4d95fc1d, 0x96b591af, 0x70f4ddd3, 0x66a02f45, + 0xbfbc09ec, 0x03bd9785, 0x7fac6dd0, 0x31cb8504, + 0x96eb27b3, 0x55fd3941, 0xda2547e6, 0xabca0a9a, + 0x28507825, 0x530429f4, 0x0a2c86da, 0xe9b66dfb, + 0x68dc1462, 0xd7486900, 0x680ec0a4, 0x27a18dee, + 0x4f3ffea2, 0xe887ad8c, 0xb58ce006, 0x7af4d6b6, + 0xaace1e7c, 0xd3375fec, 0xce78a399, 0x406b2a42, + 0x20fe9e35, 0xd9f385b9, 0xee39d7ab, 0x3b124e8b, + 0x1dc9faf7, 0x4b6d1856, 0x26a36631, 0xeae397b2, + 0x3a6efa74, 0xdd5b4332, 0x6841e7f7, 0xca7820fb, + 0xfb0af54e, 0xd8feb397, 0x454056ac, 0xba489527, + 0x55533a3a, 0x20838d87, 0xfe6ba9b7, 0xd096954b, + 0x55a867bc, 0xa1159a58, 0xcca92963, 0x99e1db33, + 0xa62a4a56, 0x3f3125f9, 0x5ef47e1c, 0x9029317c, + 0xfdf8e802, 0x04272f70, 0x80bb155c, 0x05282ce3, + 0x95c11548, 0xe4c66d22, 0x48c1133f, 0xc70f86dc, + 0x07f9c9ee, 0x41041f0f, 0x404779a4, 0x5d886e17, + 0x325f51eb, 0xd59bc0d1, 0xf2bcc18f, 0x41113564, + 0x257b7834, 0x602a9c60, 0xdff8e8a3, 0x1f636c1b, + 0x0e12b4c2, 0x02e1329e, 0xaf664fd1, 0xcad18115, + 0x6b2395e0, 0x333e92e1, 0x3b240b62, 0xeebeb922, + 0x85b2a20e, 0xe6ba0d99, 0xde720c8c, 0x2da2f728, + 0xd0127845, 0x95b794fd, 0x647d0862, 0xe7ccf5f0, + 0x5449a36f, 0x877d48fa, 0xc39dfd27, 0xf33e8d1e, + 0x0a476341, 0x992eff74, 0x3a6f6eab, 0xf4f8fd37, + 0xa812dc60, 0xa1ebddf8, 0x991be14c, 0xdb6e6b0d, + 0xc67b5510, 0x6d672c37, 0x2765d43b, 0xdcd0e804, + 0xf1290dc7, 0xcc00ffa3, 0xb5390f92, 0x690fed0b, + 0x667b9ffb, 0xcedb7d9c, 0xa091cf0b, 0xd9155ea3, + 0xbb132f88, 0x515bad24, 0x7b9479bf, 0x763bd6eb, + 0x37392eb3, 0xcc115979, 0x8026e297, 0xf42e312d, + 0x6842ada7, 0xc66a2b3b, 0x12754ccc, 0x782ef11c, + 0x6a124237, 0xb79251e7, 0x06a1bbe6, 0x4bfb6350, + 0x1a6b1018, 0x11caedfa, 0x3d25bdd8, 0xe2e1c3c9, + 0x44421659, 0x0a121386, 0xd90cec6e, 0xd5abea2a, + 0x64af674e, 0xda86a85f, 0xbebfe988, 0x64e4c3fe, + 0x9dbc8057, 0xf0f7c086, 0x60787bf8, 0x6003604d, + 0xd1fd8346, 0xf6381fb0, 0x7745ae04, 0xd736fccc, + 0x83426b33, 0xf01eab71, 0xb0804187, 0x3c005e5f, + 0x77a057be, 0xbde8ae24, 0x55464299, 0xbf582e61, + 0x4e58f48f, 0xf2ddfda2, 0xf474ef38, 0x8789bdc2, + 0x5366f9c3, 0xc8b38e74, 0xb475f255, 0x46fcd9b9, + 0x7aeb2661, 0x8b1ddf84, 0x846a0e79, 0x915f95e2, + 0x466e598e, 0x20b45770, 0x8cd55591, 0xc902de4c, + 0xb90bace1, 0xbb8205d0, 0x11a86248, 0x7574a99e, + 0xb77f19b6, 0xe0a9dc09, 0x662d09a1, 0xc4324633, + 0xe85a1f02, 0x09f0be8c, 0x4a99a025, 0x1d6efe10, + 0x1ab93d1d, 0x0ba5a4df, 0xa186f20f, 0x2868f169, + 0xdcb7da83, 0x573906fe, 0xa1e2ce9b, 0x4fcd7f52, + 0x50115e01, 0xa70683fa, 0xa002b5c4, 0x0de6d027, + 0x9af88c27, 0x773f8641, 0xc3604c06, 0x61a806b5, + 0xf0177a28, 0xc0f586e0, 0x006058aa, 0x30dc7d62, + 0x11e69ed7, 0x2338ea63, 0x53c2dd94, 0xc2c21634, + 0xbbcbee56, 0x90bcb6de, 0xebfc7da1, 0xce591d76, + 0x6f05e409, 0x4b7c0188, 0x39720a3d, 0x7c927c24, + 0x86e3725f, 0x724d9db9, 0x1ac15bb4, 0xd39eb8fc, + 0xed545578, 0x08fca5b5, 0xd83d7cd3, 0x4dad0fc4, + 0x1e50ef5e, 0xb161e6f8, 0xa28514d9, 0x6c51133c, + 0x6fd5c7e7, 0x56e14ec4, 0x362abfce, 0xddc6c837, + 0xd79a3234, 0x92638212, 0x670efa8e, 0x406000e0, + 0x3a39ce37, 0xd3faf5cf, 0xabc27737, 0x5ac52d1b, + 0x5cb0679e, 0x4fa33742, 0xd3822740, 0x99bc9bbe, + 0xd5118e9d, 0xbf0f7315, 0xd62d1c7e, 0xc700c47b, + 0xb78c1b6b, 0x21a19045, 0xb26eb1be, 0x6a366eb4, + 0x5748ab2f, 0xbc946e79, 0xc6a376d2, 0x6549c2c8, + 0x530ff8ee, 0x468dde7d, 0xd5730a1d, 0x4cd04dc6, + 0x2939bbdb, 0xa9ba4650, 0xac9526e8, 0xbe5ee304, + 0xa1fad5f0, 0x6a2d519a, 0x63ef8ce2, 0x9a86ee22, + 0xc089c2b8, 0x43242ef6, 0xa51e03aa, 0x9cf2d0a4, + 0x83c061ba, 0x9be96a4d, 0x8fe51550, 0xba645bd6, + 0x2826a2f9, 0xa73a3ae1, 0x4ba99586, 0xef5562e9, + 0xc72fefd3, 0xf752f7da, 0x3f046f69, 0x77fa0a59, + 0x80e4a915, 0x87b08601, 0x9b09e6ad, 0x3b3ee593, + 0xe990fd5a, 0x9e34d797, 0x2cf0b7d9, 0x022b8b51, + 0x96d5ac3a, 0x017da67d, 0xd1cf3ed6, 0x7c7d2d28, + 0x1f9f25cf, 0xadf2b89b, 0x5ad6b472, 0x5a88f54c, + 0xe029ac71, 0xe019a5e6, 0x47b0acfd, 0xed93fa9b, + 0xe8d3c48d, 0x283b57cc, 0xf8d56629, 0x79132e28, + 0x785f0191, 0xed756055, 0xf7960e44, 0xe3d35e8c, + 0x15056dd4, 0x88f46dba, 0x03a16125, 0x0564f0bd, + 0xc3eb9e15, 0x3c9057a2, 0x97271aec, 0xa93a072a, + 0x1b3f6d9b, 0x1e6321f5, 0xf59c66fb, 0x26dcf319, + 0x7533d928, 0xb155fdf5, 0x03563482, 0x8aba3cbb, + 0x28517711, 0xc20ad9f8, 0xabcc5167, 0xccad925f, + 0x4de81751, 0x3830dc8e, 0x379d5862, 0x9320f991, + 0xea7a90c2, 0xfb3e7bce, 0x5121ce64, 0x774fbe32, + 0xa8b6e37e, 0xc3293d46, 0x48de5369, 0x6413e680, + 0xa2ae0810, 0xdd6db224, 0x69852dfd, 0x09072166, + 0xb39a460a, 0x6445c0dd, 0x586cdecf, 0x1c20c8ae, + 0x5bbef7dd, 0x1b588d40, 0xccd2017f, 0x6bb4e3bb, + 0xdda26a7e, 0x3a59ff45, 0x3e350a44, 0xbcb4cdd5, + 0x72eacea8, 0xfa6484bb, 0x8d6612ae, 0xbf3c6f47, + 0xd29be463, 0x542f5d9e, 0xaec2771b, 0xf64e6370, + 0x740e0d8d, 0xe75b1357, 0xf8721671, 0xaf537d5d, + 0x4040cb08, 0x4eb4e2cc, 0x34d2466a, 0x0115af84, + 0xe1b00428, 0x95983a1d, 0x06b89fb4, 0xce6ea048, + 0x6f3f3b82, 0x3520ab82, 0x011a1d4b, 0x277227f8, + 0x611560b1, 0xe7933fdc, 0xbb3a792b, 0x344525bd, + 0xa08839e1, 0x51ce794b, 0x2f32c9b7, 0xa01fbac9, + 0xe01cc87e, 0xbcc7d1f6, 0xcf0111c3, 0xa1e8aac7, + 0x1a908749, 0xd44fbd9a, 0xd0dadecb, 0xd50ada38, + 0x0339c32a, 0xc6913667, 0x8df9317c, 0xe0b12b4f, + 0xf79e59b7, 0x43f5bb3a, 0xf2d519ff, 0x27d9459c, + 0xbf97222c, 0x15e6fc2a, 0x0f91fc71, 0x9b941525, + 0xfae59361, 0xceb69ceb, 0xc2a86459, 0x12baa8d1, + 0xb6c1075e, 0xe3056a0c, 0x10d25065, 0xcb03a442, + 0xe0ec6e0e, 0x1698db3b, 0x4c98a0be, 0x3278e964, + 0x9f1f9532, 0xe0d392df, 0xd3a0342b, 0x8971f21e, + 0x1b0a7441, 0x4ba3348c, 0xc5be7120, 0xc37632d8, + 0xdf359f8d, 0x9b992f2e, 0xe60b6f47, 0x0fe3f11d, + 0xe54cda54, 0x1edad891, 0xce6279cf, 0xcd3e7e6f, + 0x1618b166, 0xfd2c1d05, 0x848fd2c5, 0xf6fb2299, + 0xf523f357, 0xa6327623, 0x93a83531, 0x56cccd02, + 0xacf08162, 0x5a75ebb5, 0x6e163697, 0x88d273cc, + 0xde966292, 0x81b949d0, 0x4c50901b, 0x71c65614, + 0xe6c6c7bd, 0x327a140a, 0x45e1d006, 0xc3f27b9a, + 0xc9aa53fd, 0x62a80f00, 0xbb25bfe2, 0x35bdd2f6, + 0x71126905, 0xb2040222, 0xb6cbcf7c, 0xcd769c2b, + 0x53113ec0, 0x1640e3d3, 0x38abbd60, 0x2547adf0, + 0xba38209c, 0xf746ce76, 0x77afa1c5, 0x20756060, + 0x85cbfe4e, 0x8ae88dd8, 0x7aaaf9b0, 0x4cf9aa7e, + 0x1948c25c, 0x02fb8a8c, 0x01c36ae4, 0xd6ebe1f9, + 0x90d4f869, 0xa65cdea0, 0x3f09252d, 0xc208e69f, + 0xb74e6132, 0xce77e25b, 0x578fdfe3, 0x3ac372e6 +}; + +#if (defined(TEST) && !defined(__KERNEL__)) + +#include + +/* Test vectors from Schneier's reference implementation */ + +char test1k[] = "abcdefghijklmnopqrstuvwxyz"; +char btest1p[] = { 0x42, 0x4c, 0x4f, 0x57, 0x46, 0x49, 0x53, 0x48 }; +char btest1c[] = { 0x32, 0x4e, 0xd0, 0xfe, 0xf4, 0x13, 0xa2, 0x03 }; + +char test2k[] = "Who is John Galt?"; +char btest2p[] = { 0xfe, 0xdc, 0xba, 0x98, 0x76, 0x54, 0x32, 0x10 }; +char btest2c[] = { 0xcc, 0x91, 0x73, 0x2b, 0x80, 0x22, 0xf6, 0x84 }; + +/* Non-official little endian test ciphertext vectors */ +char btest1l[] = { 0x82, 0x4d, 0x92, 0x0d, 0x00, 0x4d, 0x7e, 0xe3 }; +char btest2l[] = { 0xd4, 0xf9, 0xb0, 0x06, 0xd3, 0x84, 0x92, 0x7e }; + +typedef void (*BFTransform)(void *dataIn, void *dataOut, + const Blowfish_Key key); + +int ftest(char *k, char *p, char *c, + BFTransform Encrypt, BFTransform Decrypt) +{ + Blowfish_Key kk; + unsigned char dd[8]; + int e=0; + + Blowfish_ExpandUserKey(k, strlen(k), kk); + Encrypt(p, dd, kk); + printf(" %02x%02x%02x%02x %02x%02x%02x%02x ", + dd[0], dd[1], dd[2], dd[3], dd[4], dd[5], dd[6], dd[7]); + if (memcmp(dd, c, 8)) { + printf("encrypt failed "); + ++e; + } + Decrypt(dd, dd, kk); + printf(" %02x%02x%02x%02x %02x%02x%02x%02x ", + dd[0], dd[1], dd[2], dd[3], dd[4], dd[5], dd[6], dd[7]); + if (memcmp(dd, p, 8)) { + printf("decrypt failed "); + ++e; + } + printf("%s\n", e?"":"passed"); + return e; +} + +int main() +{ + int e=0; + printf("Big-endian:\n"); + printf(" Test 1: "); + e+=ftest(test1k, btest1p, btest1c, B_Blowfish_Encrypt, B_Blowfish_Decrypt); + printf(" Test 2: "); + e+=ftest(test2k, btest2p, btest2c, B_Blowfish_Encrypt, B_Blowfish_Decrypt); + printf("Little-endian:\n"); + printf(" Test 1: "); + e+=ftest(test1k, btest1p, btest1l, L_Blowfish_Encrypt, L_Blowfish_Decrypt); + printf(" Test 2: "); + e+=ftest(test2k, btest2p, btest2l, L_Blowfish_Encrypt, L_Blowfish_Decrypt); + return e; +} + +#endif --- linux-2.4.21/drivers/addon/cipe3/bf.h.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/bf.h Fri Jul 25 15:02:11 2003 @@ -0,0 +1,100 @@ +/* + Bruce Schneier's Blowfish. + Author: Olaf Titz + + This code is in the public domain. + + $Id: bf.h,v 1.4 2000/10/06 23:15:05 olaf Exp $ +*/ + +#ifndef _BF_H_ +#define _BF_H_ + +#include /* gives __u32 as an unsigned 32bit integer */ +/* PORTABILITY: under non-Linux, + omit this include and insert an appropriate typedef +*/ + +#ifdef __KERNEL__ +#include +#endif +/* PORTABILITY: under non-Linux, omit this include. + Generic, endian-neutral, slower C routines will be used instead of + the assembler versions found in the kernel includes. +*/ + +/* This is ugly, but seems the easiest way to find an endianness test + which works both in kernel and user mode. + This is only an optimization - everything works even if none of the + tests are defined. +*/ +#ifdef __BYTE_ORDER +#if __BYTE_ORDER == __BIG_ENDIAN +#define BF_NATIVE_BE +#endif +#if __BYTE_ORDER == __LITTLE_ENDIAN +#define BF_NATIVE_LE +#endif +#else +#ifdef __BIG_ENDIAN +#define BF_NATIVE_BE +#endif +#ifdef __LITTLE_ENDIAN +#define BF_NATIVE_LE +#endif +#endif + +/* The data block processed by the encryption algorithm - 64 bits */ +typedef __u32 Blowfish_Data[2]; +/* The key as entered by the user - size may vary */ +typedef char Blowfish_UserKey[16]; +/* The expanded key for internal use - 18+4*256 words*/ +typedef __u32 Blowfish_Key[1042]; + +/* Byteorder-dependent handling of data encryption: Blowfish is by + definition big-endian. However, there are broken implementations on + little-endian machines which treat the data as little-endian. + This module provides both variants. + */ + +/* Native byte order. For internal use ONLY. */ +extern void _N_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); +extern void _N_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); + +#ifndef BF_DONTNEED_BE +/* Big endian. This is the "real" Blowfish. */ +#ifdef BF_NATIVE_BE +#define B_Blowfish_Encrypt _N_Blowfish_Encrypt +#define B_Blowfish_Decrypt _N_Blowfish_Decrypt +#else +extern void B_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); +extern void B_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); +#endif +#endif + +#ifndef BF_DONTNEED_LE +/* Little endian. To be compatible with other LE implementations. */ +#ifdef BF_NATIVE_LE +#define L_Blowfish_Encrypt _N_Blowfish_Encrypt +#define L_Blowfish_Decrypt _N_Blowfish_Decrypt +#else +extern void L_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); +extern void L_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); +#endif +#endif + +/* User key expansion. This is not byteorder dependent as all common + implementations get it right (i.e. big-endian). */ + +extern void Blowfish_ExpandUserKey(const char *userKey, int userKeyLen, + Blowfish_Key key); + +extern const Blowfish_Key Blowfish_Init_Key; + +#endif --- linux-2.4.21/drivers/addon/cipe3/bf-i386.S.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/bf-i386.S Fri Jul 25 15:02:11 2003 @@ -0,0 +1,272 @@ +/* + Bruce Schneier's Blowfish in i386 assembler (for linux/gcc) + Author: Olaf Titz + + This code is in the public domain. + + $Id: bf-i386.S,v 1.6 2000/11/16 16:45:00 olaf Exp $ +*/ + +#ifdef ASM_BF_Crypt + +#ifndef __ASSEMBLY__ +#define __ASSEMBLY__ +#endif + +/* This header just defines ENTRY to make an appropriate global symbol */ +#include + +/* Look for CONFIG_X86_BSWAP (defined for 486 and up) */ +#include + +#define PosP0 0 +#define PosP17 68 +#define PosS0 72 +#define PosS1 1096 +#define PosS2 2120 +#define PosS3 3144 +#define KeyLenL 1042 +#define KeyLenB 521 + +/* This code is optimized for speed rather than size - loops unrolled. etc. */ + +/* + Endian-ness is taken care of by (a) the order of shifts in the Round + macro and (b) the order of shifts below under the ukx label. + The key tables and user data are stored and processed in the CPU + byte order. +*/ + +/* Do one round */ +#define Round(lw,rw) \ + movl rw, %edx; \ + shrl $24, %edx; \ + movl PosS0(%edi,%edx,4), %eax; \ + movl rw, %edx; \ + shrl $16, %edx; \ + andl $0xFF, %edx; \ + addl PosS1(%edi,%edx,4), %eax; \ + movl rw, %edx; \ + shrl $8, %edx; \ + andl $0xFF, %edx; \ + xorl PosS2(%edi,%edx,4), %eax; \ + movl rw, %edx; \ + andl $0xFF, %edx; \ + addl PosS3(%edi,%edx,4), %eax; \ + xorl %eax, lw; \ + lodsl; \ + xorl %eax, lw + +/* Words in %ebx, %ecx - Key in %edi - P-index in %esi - result swapped */ +blowfish: + lodsl + xorl %eax, %ebx + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + lodsl + xorl %eax, %ecx + ret + +/* Endianness swap operation. Is there an easier way to decompose + %ebx into %bl and %bh within a macro? */ +#ifdef CONFIG_X86_BSWAP +#define swab32(x,h,l) bswap x +#else +#define swab32(x,h,l) \ + xchgb h, l; \ + rorl $16, x; \ + xchgb h, l +#endif + + +/* Function prototype prologue/epilogue. Sets up registers etc. + This is all code common to the six encrypt/decrypt functions. + They have the prototype + extern void FUNCTION(void *dataIn, void *dataOut, const Blowfish_Key key); + for the following FUNCTIONs: + _N_Blowfish_Encrypt, _N_Blowfish_Decrypt (native-endian) + B_Blowfish_Encrypt, B_Blowfish_Decrypt (big-endian) + L_Blowfish_Encrypt, L_Blowfish_Decrypt (little-endian) + Of course, in the i386 implementation, native==little-endian. +*/ + +/* saved regs relative to %esp */ +#define sebx 0 +#define sebp 4 +#define sesi 8 +#define sedi 12 +#define SAVE 16 /* no. of bytes the saved registers occupy */ +/* arguments relative to %esp */ +#define dataIn SAVE+4(%esp) +#define dataOut SAVE+8(%esp) +#define key SAVE+12(%esp) + +#define PROLOG \ + /* save registers */ \ + subl $SAVE, %esp; \ + movl %ebx, sebx(%esp); \ + movl %ebp, sebp(%esp); \ + movl %esi, sesi(%esp); \ + movl %edi, sedi(%esp); \ + /* load data */ \ + movl dataIn, %esi; \ + movl (%esi), %ebx; \ + movl 4(%esi), %ecx; \ + /* load key */ \ + movl key, %edi; + +#define EPILOG \ + /* store data */ \ + movl dataOut, %edi; \ + movl %ebx, 4(%edi); \ + movl %ecx, (%edi); \ + /* restore registers */ \ + movl sedi(%esp), %edi; \ + movl sesi(%esp), %esi; \ + movl sebp(%esp), %ebp; \ + movl sebx(%esp), %ebx; \ + addl $SAVE, %esp; \ + ret + +#define FORWARD \ + movl %edi, %esi; \ + cld + +#define BACKWARD \ + leal PosP17(%edi), %esi; \ + std + +#define SWAP \ + swab32(%ebx,%bh,%bl); \ + swab32(%ecx,%ch,%cl) + +/* N.B. In Linux 2.3, the D flag is assumed to be zero all the time. + Thus after BACKWARD an additional cld is necessary. */ + +#ifndef BF_DONTNEED_LE +ENTRY(L_Blowfish_Encrypt) +#endif +ENTRY(_N_Blowfish_Encrypt) + PROLOG + FORWARD + call blowfish + EPILOG + +#ifndef BF_DONTNEED_LE +ENTRY(L_Blowfish_Decrypt) +#endif +ENTRY(_N_Blowfish_Decrypt) + PROLOG + BACKWARD + call blowfish + cld + EPILOG + +#ifndef BF_DONTNEED_BE +ENTRY(B_Blowfish_Encrypt) + PROLOG + SWAP + FORWARD + call blowfish + SWAP + EPILOG + +ENTRY(B_Blowfish_Decrypt) + PROLOG + SWAP + BACKWARD + call blowfish + cld + SWAP + EPILOG +#endif + + +/* load byte from key, start over if exhausted */ +#define lodsbw(base,len) \ + lodsb; \ + decl %ecx; \ + cmpl $0, %ecx; \ + jg 1f; \ + movl base, %esi; \ + movl len, %ecx; \ +1: + +/* + void Blowfish_ExpandUserKey(const char *userKey, int userKeyLen, + Blowfish_Key key); +*/ + +ENTRY(Blowfish_ExpandUserKey) + pushl %ebx + pushl %ebp + pushl %esi + pushl %edi +#define SAVE 16 /* no. of bytes the saved registers occupy */ +/* arguments relative to %esp */ +#define userKey SAVE+4(%esp) +#define userKeyLen SAVE+8(%esp) +#define key SAVE+12(%esp) +#define key_push SAVE+16(%esp) /* key with one word pushed */ + + /* Copy the init vector into key */ + leal SYMBOL_NAME(Blowfish_Init_Key), %esi + movl key, %edi + movl $KeyLenL, %ecx + cld + rep; movsl + /* XOR the user key into the P table */ + movl key, %edi + movl $18, %ebp + movl userKey, %esi + movl userKeyLen, %ecx +ukx: + /* process one 32-bit word swapped */ + lodsbw(userKey, userKeyLen) + shll $8, %eax + lodsbw(userKey, userKeyLen) + shll $8, %eax + lodsbw(userKey, userKeyLen) + shll $8, %eax + lodsbw(userKey, userKeyLen) + xorl %eax, (%edi) + addl $4, %edi + decl %ebp + cmpl $0, %ebp + jg ukx + + /* Now do the repeated encryption process */ + xorl %ebx, %ebx + xorl %ecx, %ecx + movl $KeyLenB, %ebp + movl key, %edi +ukb: + pushl %edi + movl key_push, %edi + movl %edi, %esi + call blowfish + popl %edi + xchgl %ebx, %ecx + movl %ebx, (%edi) + movl %ecx, 4(%edi) + addl $8, %edi + decl %ebp + cmpl $0, %ebp + jg ukb + + popl %edi + popl %esi + popl %ebp + popl %ebx + ret +#undef dataIn +#undef dataOut +#undef key + +#endif /* ASM_BF_Crypt */ --- linux-2.4.21/drivers/addon/cipe3/ciped.h.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/ciped.h Fri Jul 25 15:02:11 2003 @@ -0,0 +1,43 @@ +/* + CIPE - encrypted IP over UDP tunneling + + ciped.h - prototypes for user level routines + + Copyright 1997 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: ciped.h,v 1.6 2000/12/16 17:49:06 olaf Exp $ */ + +#include +#include +#include "cipe.h" +#include "options.h" + +/* options.c */ +struct options { + const char * const oname; + const char otyp; + union { + int ovint; + char *ovstr; + struct sockaddr_in *ovsaddr; + } ov; +}; +extern struct options opts[]; +#define Tbool 0 +#define Tint 1 +#define Tstr 2 +#define Taddr 3 +#define Tuaddr 4 +#define Ttaddr 5 +#define Tsecret 6 + +#define OI(x) (opts[O##x].ov.ovint) +#define OS(x) (opts[O##x].ov.ovstr) +#define OA(x) (opts[O##x].ov.ovsaddr) +#define OAaddr(x) (OA(x)->sin_addr) +#define OAport(x) (OA(x)->sin_port) --- linux-2.4.21/drivers/addon/cipe3/cipe.h.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/cipe.h Fri Jul 25 15:02:11 2003 @@ -0,0 +1,426 @@ +/* + CIPE - encrypted IP over UDP tunneling + + cipe.h - contains definitions, includes etc. common to all modules + + Copyright 1996-2000 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: cipe.h,v 1.38.2.2 2002/06/28 23:38:53 olaf Exp $ */ + +#ifndef _CIPE_H_ +#define _CIPE_H_ + +#include "crypto.h" +#ifdef __KERNEL__ +#include +#else +#include +#endif + +/*** The kernel/user IOCTL interface ***/ + +/* ioctls for setup and key exchange */ +/* #define SIOCxIFCIPxxx (SIOCDEVPRIVATE+x) */ +/* All ioctls are passed a struct ifreq which contains the + device name in ifr_name and a pointer to the actual control struct + in ifr_data. */ + +#if 0 +/* Get interface parameters. Currently unused */ +#define SIOCGIFCIPPAR (SIOCDEVPRIVATE+0) +struct siocgifcippar { + unsigned long magic; + /* SOCKS5 relayer */ + unsigned long sockshost; + unsigned short socksport; + /* Timeouts (in seconds) */ + int tmo_keyxchg; + int tmo_keylife; + /* Flags */ + int flags; + int cttl; +}; +#endif + +/* Set interface parameters. */ +#define SIOCSIFCIPPAR (SIOCDEVPRIVATE+1) +struct siocsifcippar { + unsigned long magic; + /* SOCKS5 relayer */ + unsigned long sockshost; + unsigned short socksport; + /* Timeouts (in seconds) */ + int tmo_keyxchg; + int tmo_keylife; + /* Flags */ + int flags; + int cttl; +}; + +/* Set a key. */ +#define SIOCSIFCIPKEY (SIOCDEVPRIVATE+2) +#define KEY_STATIC 1 +#define KEY_SEND 2 +#define KEY_RECV 3 +#define KEY_INVAL 8 +#define KEY_MAXLEN 32 +struct siocsifcipkey { + unsigned long magic; + int which; + char thekey[KEY_MAXLEN]; + int keylen; +}; + +/* Attach a socket. */ +#define SIOCSIFCIPATT (SIOCDEVPRIVATE+3) +struct siocsifcipatt { + unsigned long magic; + int fd; +}; + +/* Allocate/deallocate a device. */ +#define SIOCSIFCIPALL (SIOCDEVPRIVATE+4) +#define SIOCSIFCIPUNA (SIOCDEVPRIVATE+5) +struct siocsifcipall { + unsigned long magic; + int num; + char name[IFNAMSIZ]; +}; + +/* Flag values. */ +#define CIPF_MAY_CLEAR 0x0100 +#define CIPF_MAY_STKEY 0x0200 +#define CIPF_MAY_DYNIP 0x0400 +#define CIPF_DO_CSUM 0x0800 + +/*** Key exchange related definitions ***/ + +/* Minimum kxc block. */ +#define KEYXCHGBLKMIN 64 +/* Maximum kxc block, padded with random bytes */ +#define KEYXCHGBLKMAX (KEYXCHGBLKMIN+256) +/* Position of the timestamp */ +#define KEYXCHGTSPOS 56 +/* Type words. Only 4 are possible. */ +#define TW_DATA 0 +#define TW_NEWKEY 2 +#define TW_CTRL 4 +#define TW_RSVD2 6 +/* error indication, no valid type word */ +#define TW_ERROR 1 + +/* NEWKEY (key exchange mode 1) subtypes. */ +#define NK_RREQ 0 /* not used in protocol */ +#define NK_REQ 1 /* send me your new key */ +#define NK_IND 2 /* this is my new key */ +#define NK_ACK 3 /* i have your new key */ + +/* CTRL subtypes. By now sent in a TW_NEWKEY packet. */ +#define CT_DUMMY 0x70 /* ignore */ +#define CT_DEBUG 0x71 /* log */ +#define CT_PING 0x72 /* send PONG */ +#define CT_PONG 0x73 +#define CT_KILL 0x74 /* exit */ +#define CT_CONFREQ 0x75 /* log, send CONF */ +#define CT_CONF 0x76 /* log */ + +/*** Kernel-module internal stuff ***/ + +#ifdef __KERNEL__ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#ifndef KERNEL_VERSION +#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) +#endif +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,1,0) +#define LINUX_21 +#endif +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,0) +#define LINUX_23 +#endif +#if (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 91)) && defined(__i386__) +#define REGPARM /* __attribute__((regparm,3)) XX needs testing */ +#else +#define REGPARM +#endif + +#ifdef LINUX_21 +#ifndef SPIN_LOCK_UNLOCKED /* 2.2/2.4 incompat */ +#include +#endif +#endif + +#if 1 /* Lock tracing */ +#define DOLOCK(s) ({ printk(KERN_DEBUG DEVNAME ": " #s " at %s:%d\n", \ + __FILE__, __LINE__); s; }) +#else +#define DOLOCK(s) s +#endif + +#ifdef LINUX_23 +#define tasklist_LOCK() DOLOCK(read_lock(&tasklist_lock)) +#define tasklist_UNLOCK() DOLOCK(read_unlock(&tasklist_lock)) +#else +#define tasklist_LOCK() /* nop */ +#define tasklist_UNLOCK() /* nop */ +#endif + +#ifdef LINUX_21 +/* In 2.1 the ioctl operations are run under lock. Beware of deadlocks. */ +#define cipe_alloc_LOCK() 0 /* nop */ +#define cipe_alloc_UNLOCK() /* nop */ +#else +extern struct semaphore cipe_alloc_sem; +#define cipe_alloc_LOCK() DOLOCK(down_interruptible(&cipe_alloc_sem)) +#define cipe_alloc_UNLOCK() DOLOCK(up(&cipe_alloc_sem)) +#endif + +#ifdef LINUX_21 +#define FLEN "%d" +#else +#define FLEN "%ld" +#endif + +#ifdef LINUX_23 +#define rtnl_LOCK() DOLOCK(rtnl_lock()) +#define rtnl_UNLOCK() DOLOCK(rtnl_unlock()) +#else +#define rtnl_LOCK() /* nop */ +#define rtnl_UNLOCK() /* nop */ +#endif + +#ifdef LINUX_23 +#define NET_DEVICE net_device +#define DEV_STATS net_device_stats +#else +#define NET_DEVICE device +#define DEV_STATS enet_statistics +#endif + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,1,127) +#define timeout_t unsigned long +#else +#define timeout_t long +#endif + +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,3,99) +#define HAVE_DEVNAME_ARRAY +#endif + +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,4,17) +#define get_fast_time do_gettimeofday +#endif + +/* The header we add to each packet */ +#ifdef VER_ETH +#define cipehdrlen (sizeof(struct iphdr)+sizeof(struct udphdr)+blockSize+ETH_HLEN) +#else +#ifdef VER_SHORT +#define cipehdrlen (sizeof(struct iphdr)+sizeof(struct udphdr)) +#else +#define cipehdrlen (sizeof(struct iphdr)+sizeof(struct udphdr)+blockSize) +#endif +#endif +/* ...plus a real hardware header (common case) */ +#define cipexhdrl (cipehdrlen+((ETH_HLEN+15)&~15)) +/* max. padding at the end */ +#if ProtocolVersion >= 3 +#define cipefootlen 12 /* 7 bytes pad, 1 byte type, 4 bytes CRC */ +#else +#define cipefootlen 10 /* 8 bytes pad, 2 bytes CRC */ +#endif + +/* A CIPE device's parameter block */ + +#define CIPE_MAGIC (htonl(0x43495045)) +struct cipe { + __u32 magic; + struct NET_DEVICE *dev; + /* Set by user process */ + __u32 peeraddr; + __u32 myaddr; + __u16 peerport; + __u16 myport; + __u32 sockshost; + __u16 socksport; + short cttl; +#ifdef Crypto_IDEA + Key key_e, key_d, skey_e, rkey_d; +#endif +#ifdef Crypto_Blowfish + Key key, skey, rkey; + #define key_e key + #define key_d key + #define skey_e skey + #define rkey_d rkey +#endif + unsigned long tmo_keyxchg; + unsigned long tmo_keylife; + /* Internal */ + unsigned long timekx; + unsigned long timeskey; + unsigned long timerkey; + int cntskey; + int cntrkey; + struct sock *sock; + int flags; +#ifdef LINUX_21 + char recursion; +#endif + pid_t owner; + /* Statistics */ +#ifdef LINUX_21 + struct net_device_stats stat; +#else + struct enet_statistics stat; +#endif + /* Socket interface stuff */ + struct proto *udp_prot; + struct proto cipe_proto; +}; + +/* Flag values (internally used) */ +#define CIPF_HAVE_KEY 0x0001 +#define CIPF_HAVE_SKEY 0x0002 +#define CIPF_HAVE_RKEY 0x0004 +#define CIPF_MASK_INT 0x00FF +#define CIPF_MASK_EXT 0xFF00 + +#define MAXBLKS 32767 /* max # blocks to encrypt using one key */ + +/* Define, init and check a struct cipe * variable. */ +#define DEVTOCIPE(dev,c,err) \ + struct cipe *c = (struct cipe*)(dev->priv); \ + if (!c || c->magic!=CIPE_MAGIC) return err; + +/* Master control struct */ +struct cipe_ctrl { +#ifndef HAVE_DEVNAME_ARRAY + char name[IFNAMSIZ]; +#endif + struct cipe cipe; + struct NET_DEVICE dev; +}; + +extern struct cipe_ctrl **cipe_ctrls; +extern int cipe_maxdev; + +/* SOCKS5 encapsulation header */ +struct sockshdr { + char rsv[2]; + char frag; + char atyp; + __u32 dstaddr __attribute__((packed)); + __u16 dstport __attribute__((packed)); +}; + +#ifdef DEBUG +extern int cipe_debug; + +#if 0 +/* Lock around our printks, to avoid mixing up dumps. NOT for regular use. */ +extern spinlock_t cipe_printk_lock; +#define LOCK_PRINTK unsigned long flags; spin_lock_irqsave(&cipe_printk_lock, flags) +#define UNLOCK_PRINTK spin_unlock_irqrestore(&cipe_printk_lock, flags) +#else +#define LOCK_PRINTK /* nop */ +#define UNLOCK_PRINTK /* nop */ +#endif + +#define DEB_CALL 1 +#define DEB_INP 2 +#define DEB_OUT 4 +#define DEB_CRYPT 8 +#define DEB_KXC 16 +#define DEB_PKIN 32 +#define DEB_PKOU 64 +#define DEB_CHKP 128 + +#define dprintk(l,p) if(cipe_debug&l){LOCK_PRINTK; printk p; UNLOCK_PRINTK;} + +#else +#define dprintk(l,p) /* nop */ + +#endif /* DEBUG */ + +#if defined(DEBUG) && defined(LINUX_23) +#define __CHECKPOINT(F,L) printk(KERN_DEBUG "CHECKPOINT " F ":%d\n", L) +#define CHECKPOINT if (cipe_debug&DEB_CHKP){\ + LOCK_PRINTK; __CHECKPOINT(__FILE__,__LINE__); UNLOCK_PRINTK;\ + current->state=TASK_INTERRUPTIBLE; schedule_timeout(HZ/20); } +#else +#define CHECKPOINT /* nop */ +#endif + +static inline void nf_conntrack_null(struct sk_buff *skb) +{ +#ifdef CONFIG_NETFILTER + nf_conntrack_put(skb->nfct); + skb->nfct = NULL; +#ifdef CONFIG_NETFILTER_DEBUG + skb->nf_debug = 0; +#endif +#endif +} + +/* internal routines */ +/* module.c */ +extern void cipe_use_module(void); +extern void cipe_unuse_module(void); +extern int cipe_check_kernel(void); +/* device.c */ +extern void cipe_prnpad(unsigned char *buf, int len) REGPARM; +extern void cipe_close(struct cipe *c); +extern const char *cipe_ntoa(__u32 addr) REGPARM; +/* sock.c */ +extern int cipe_attach(struct NET_DEVICE *dev, struct siocsifcipatt *parm) + REGPARM; +extern void cipe_fakenkey(struct cipe *c, char typ) REGPARM; +/* output.c */ +#ifdef DEBUG +extern void cipe_dump_packet(char *title, struct sk_buff *skb, int dumpskb) + REGPARM; +#endif +extern int cipe_xmit(struct sk_buff *skb, struct NET_DEVICE *dev); +/* encaps.c */ +extern void cipe_encrypt(struct cipe *c, unsigned char *buf, + int *len, int typcode) REGPARM; +extern unsigned short cipe_decrypt(struct cipe *c, unsigned char *buf, + int *len) REGPARM; +#ifndef VER_SHORT +extern void cipe_cryptpad(unsigned char *buf) REGPARM; +extern void cipe_cryptpad_iv(unsigned char *buf) REGPARM; +#endif + +#endif /* __KERNEL__ */ + +#ifdef VER_CRC32 +/* crc32.c */ +extern unsigned long crc32(const unsigned char *s, unsigned int len); +#else +/* crc.c */ +extern unsigned short block_crc(unsigned char *d, int len); +#endif + +#define MIN(a,b) (((a)<(b))?(a):(b)) + +#ifndef DEVNAME +#define DEVNAME "cip" VERNAME CRNAME +#endif + +#endif /* _CIPE_H_ */ --- linux-2.4.21/drivers/addon/cipe3/config.h.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/config.h Fri Jul 25 15:09:02 2003 @@ -0,0 +1,54 @@ +/* config.h. Generated automatically by configure. */ +/* + CIPE - encrypted IP over UDP tunneling + + Copyright 1999 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ + +/* Config-dependent defines. Always include this first. */ +/* @api means the next line is used for determining the version magic */ + +/* Version of the CIPE package @api */ +#define VERSION "1.5.4" +#define VERSION_MAJ 1 + +/* Encapsulation protocol version @api */ +#define ProtocolVersion 3 + +/* Cipher algorithm selection @api */ +/* #undef Crypto_IDEA */ +/* Cipher algorithm selection @api */ +#define Crypto_Blowfish 1 + +/* Assembler module selection */ +/* #undef ASM_Idea_Crypt */ +#ifdef __i386 +#define ASM_BF_Crypt 1 +#endif + +/* Debug code in kernel */ +#define DEBUG 1 + +/* Use old key parser */ +/* #undef BUG_COMPATIBLE */ + +/* Dynamic device allocation @api */ +/* #undef NO_DYNDEV */ + +/* Syslog facility */ +#define LOGFAC LOG_DAEMON + +/* Memory management functions (kernel version dependent?) */ +#define HAVE_MLOCK 1 +#define HAVE_MLOCKALL 1 + +/* End of autoconf options */ + +/* This tells the Blowfish module to omit unneeded code */ +#define BF_DONTNEED_BE + --- linux-2.4.21/drivers/addon/cipe3/crc32.c.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/crc32.c Fri Jul 25 15:02:11 2003 @@ -0,0 +1,111 @@ + /* ============================================================= */ + /* COPYRIGHT (C) 1986 Gary S. Brown. You may use this program, or */ + /* code or tables extracted from it, as desired without restriction. */ + /* */ + /* First, the polynomial itself and its table of feedback terms. The */ + /* polynomial is */ + /* X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0 */ + /* */ + /* Note that we take it "backwards" and put the highest-order term in */ + /* the lowest-order bit. The X^32 term is "implied"; the LSB is the */ + /* X^31 term, etc. The X^0 term (usually shown as "+1") results in */ + /* the MSB being 1. */ + /* */ + /* Note that the usual hardware shift register implementation, which */ + /* is what we're using (we're merely optimizing it by doing eight-bit */ + /* chunks at a time) shifts bits into the lowest-order term. In our */ + /* implementation, that means shifting towards the right. Why do we */ + /* do it this way? Because the calculated CRC must be transmitted in */ + /* order from highest-order term to lowest-order term. UARTs transmit */ + /* characters in order from LSB to MSB. By storing the CRC this way, */ + /* we hand it to the UART in the order low-byte to high-byte; the UART */ + /* sends each low-bit to hight-bit; and the result is transmission bit */ + /* by bit from highest- to lowest-order term without requiring any bit */ + /* shuffling on our part. Reception works similarly. */ + /* */ + /* The feedback terms table consists of 256, 32-bit entries. Notes: */ + /* */ + /* The table can be generated at runtime if desired; code to do so */ + /* is shown later. It might not be obvious, but the feedback */ + /* terms simply represent the results of eight shift/xor opera- */ + /* tions for all combinations of data and CRC register values. */ + /* */ + /* The values must be right-shifted by eight bits by the "updcrc" */ + /* logic; the shift must be unsigned (bring in zeroes). On some */ + /* hardware you could probably optimize the shift in assembler by */ + /* using byte-swap instructions. */ + /* polynomial $edb88320 */ + /* */ + /* -------------------------------------------------------------------- */ + +static unsigned long crc32_tab[] = { + 0x00000000L, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L, + 0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L, + 0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L, + 0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL, + 0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L, + 0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L, + 0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L, + 0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL, + 0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L, + 0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL, + 0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L, + 0xb8bda50fL, 0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L, + 0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, 0x76dc4190L, + 0x01db7106L, 0x98d220bcL, 0xefd5102aL, 0x71b18589L, 0x06b6b51fL, + 0x9fbfe4a5L, 0xe8b8d433L, 0x7807c9a2L, 0x0f00f934L, 0x9609a88eL, + 0xe10e9818L, 0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L, + 0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, 0x6c0695edL, + 0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, 0x65b0d9c6L, 0x12b7e950L, + 0x8bbeb8eaL, 0xfcb9887cL, 0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L, + 0xfbd44c65L, 0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L, + 0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, 0x4369e96aL, + 0x346ed9fcL, 0xad678846L, 0xda60b8d0L, 0x44042d73L, 0x33031de5L, + 0xaa0a4c5fL, 0xdd0d7cc9L, 0x5005713cL, 0x270241aaL, 0xbe0b1010L, + 0xc90c2086L, 0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL, + 0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, 0x59b33d17L, + 0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, 0xedb88320L, 0x9abfb3b6L, + 0x03b6e20cL, 0x74b1d29aL, 0xead54739L, 0x9dd277afL, 0x04db2615L, + 0x73dc1683L, 0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L, + 0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, 0xf00f9344L, + 0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, 0xf762575dL, 0x806567cbL, + 0x196c3671L, 0x6e6b06e7L, 0xfed41b76L, 0x89d32be0L, 0x10da7a5aL, + 0x67dd4accL, 0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L, + 0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, 0xd1bb67f1L, + 0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, 0xd80d2bdaL, 0xaf0a1b4cL, + 0x36034af6L, 0x41047a60L, 0xdf60efc3L, 0xa867df55L, 0x316e8eefL, + 0x4669be79L, 0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0x5268e236L, + 0xcc0c7795L, 0xbb0b4703L, 0x220216b9L, 0x5505262fL, 0xc5ba3bbeL, + 0xb2bd0b28L, 0x2bb45a92L, 0x5cb36a04L, 0xc2d7ffa7L, 0xb5d0cf31L, + 0x2cd99e8bL, 0x5bdeae1dL, 0x9b64c2b0L, 0xec63f226L, 0x756aa39cL, + 0x026d930aL, 0x9c0906a9L, 0xeb0e363fL, 0x72076785L, 0x05005713L, + 0x95bf4a82L, 0xe2b87a14L, 0x7bb12baeL, 0x0cb61b38L, 0x92d28e9bL, + 0xe5d5be0dL, 0x7cdcefb7L, 0x0bdbdf21L, 0x86d3d2d4L, 0xf1d4e242L, + 0x68ddb3f8L, 0x1fda836eL, 0x81be16cdL, 0xf6b9265bL, 0x6fb077e1L, + 0x18b74777L, 0x88085ae6L, 0xff0f6a70L, 0x66063bcaL, 0x11010b5cL, + 0x8f659effL, 0xf862ae69L, 0x616bffd3L, 0x166ccf45L, 0xa00ae278L, + 0xd70dd2eeL, 0x4e048354L, 0x3903b3c2L, 0xa7672661L, 0xd06016f7L, + 0x4969474dL, 0x3e6e77dbL, 0xaed16a4aL, 0xd9d65adcL, 0x40df0b66L, + 0x37d83bf0L, 0xa9bcae53L, 0xdebb9ec5L, 0x47b2cf7fL, 0x30b5ffe9L, + 0xbdbdf21cL, 0xcabac28aL, 0x53b39330L, 0x24b4a3a6L, 0xbad03605L, + 0xcdd70693L, 0x54de5729L, 0x23d967bfL, 0xb3667a2eL, 0xc4614ab8L, + 0x5d681b02L, 0x2a6f2b94L, 0xb40bbe37L, 0xc30c8ea1L, 0x5a05df1bL, + 0x2d02ef8dL + }; + +/* Return a 32-bit CRC of the contents of the buffer. */ + +unsigned long crc32(const unsigned char *s, unsigned int len) +{ + unsigned int i; + unsigned long crc32val; + + crc32val = 0; + for (i = 0; i < len; i ++) + { + crc32val = + crc32_tab[(crc32val ^ s[i]) & 0xff] ^ + (crc32val >> 8); + } + return crc32val; +} --- linux-2.4.21/drivers/addon/cipe3/crypto.h.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/crypto.h Fri Jul 25 15:02:11 2003 @@ -0,0 +1,100 @@ +/* + CIPE - encrypted IP over UDP tunneling + + crypto.h - configuration of the crypto algorithm + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: crypto.h,v 1.8 2000/09/13 21:46:41 olaf Exp $ */ + +#ifndef _CRYPTO_H_ +#define _CRYPTO_H_ + +#include "version.h" + +typedef unsigned long part; +/* the longest integer so that sizeof(part) divides blockSize. + Used only for optimizing block-copy and block-XOR operations. */ + +#if ProtocolVersion == 1 + +#ifdef OLDNAMES +#define VERNAME "1" +#else +#define VERNAME "a" +#endif +#define VER_BACK /* encryption progress backwards */ +#define VER_SHORT /* no IV in packet */ + +#elif ProtocolVersion == 2 + +#ifdef OLDNAMES +#define VERNAME "2" +#else +#define VERNAME "b" +#endif + +#elif ProtocolVersion == 3 + +#ifdef OLDNAMES +#define VERNAME "3" +#else +#define VERNAME "c" +#endif +#define VER_CRC32 /* checksums are 32bit */ + +#elif ProtocolVersion == 4 + +#ifdef OLDNAMES +#define VERNAME "4" +#else +#define VERNAME "d" +#endif +#define VER_CRC32 +#define VER_ETH + +#else +#error "Must specify correct ProtocolVersion" +#endif + + +#ifdef Crypto_IDEA +#define CRYPTO "IDEA" +#define CRNAME "i" +#define CRNAMEC 'i' +#define CRNUM 0 +#include "idea0.h" +#define Key Idea_Key +#define keySize Idea_keySize +#define UserKey Idea_UserKey +#define userKeySize Idea_userKeySize +#define ExpandUserKey Idea_ExpandUserKey +#define InvertKey Idea_InvertKey +#define blockSize Idea_dataSize + +#else +#ifdef Crypto_Blowfish +#define CRYPTO "Blowfish" +#define CRNAME "b" +#define CRNAMEC 'b' +#define CRNUM 1 +#include "bf.h" +#define Key Blowfish_Key +#define keySize sizeof(Blowfish_Key) +#define UserKey Blowfish_UserKey +#define userKeySize 16 /* arbitrary, but matches IDEA */ +#define ExpandUserKey(u,k) Blowfish_ExpandUserKey(u,userKeySize,k) +#define InvertKey(x,y) /* noop */ +#define blockSize sizeof(Blowfish_Data) + +#else +#error "Must specify Crypto_IDEA or Crypto_Blowfish" +#endif +#endif + +#endif --- linux-2.4.21/drivers/addon/cipe3/device.c.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/device.c Fri Jul 25 15:08:13 2003 @@ -0,0 +1,636 @@ +/* + CIPE - encrypted IP over UDP tunneling + + device.c - the net device driver + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: device.c,v 1.42 2000/11/19 23:08:34 olaf Exp $ */ + +#include "cipe.h" +#include "version.h" +#include +#include +#include +#include + +#ifdef LINUX_21 +#include +#include +#else +#define register_netdevice register_netdev +#define unregister_netdevice unregister_netdev +#endif + +/*** Globals ***/ + +static const char driver_version[]=VERSION; + +struct cipe_ctrl **cipe_ctrls = NULL; +#ifdef NO_DYNDEV +int cipe_maxdev = 4; /* changeable via insmod */ +#else +int cipe_maxdev = 100; /* changeable via insmod */ +#endif +#ifdef DEBUG +int cipe_debug = DEB_CALL; /* changeable via insmod */ +#endif + +/* clear all potentially sensitive info and stats */ +static void cipe_zero_c(struct cipe *c) +{ + memset(&(c->peeraddr), 0, + offsetof(struct cipe, udp_prot)-offsetof(struct cipe, peeraddr)); + /* reset these to sensible values */ + c->tmo_keyxchg = 10*HZ; + c->tmo_keylife = 10*60*HZ; +} + +/* weak but fast PRNG, used for padding only */ +static __u32 prnseed; +void cipe_prnpad(unsigned char *buf, int len) +{ + while (len>0) { + prnseed=prnseed*0x01001001+1; + if (len>=2) { + *(__u16 *)buf=prnseed>>16; + len-=2; buf+=2; + } else { + *buf=(prnseed>>24)^jiffies; return; + } + } +} + +#ifdef DO_LOCK_PRINTK +spinlock_t cipe_printk_lock = SPIN_LOCK_UNLOCKED; +#endif + +/* inet_ntoa() for multiple use. */ +#ifdef __SMP__ +#define NTOABUFS 16 +#else +#define NTOABUFS 4 +#endif +static char ntoabuf[NTOABUFS][16]; +static int ntoaptr=0; +#ifdef LINUX_21 +spinlock_t cipe_ntoa_lock=SPIN_LOCK_UNLOCKED; +#endif + +const char *cipe_ntoa(const __u32 addr) +{ + const unsigned char *x=(const unsigned char *)&addr; + char *p; + int b, i; +#ifdef LINUX_21 + unsigned long flags; + spin_lock_irqsave(&cipe_ntoa_lock, flags); +#endif + b=ntoaptr; + if (++b>=NTOABUFS) + b=0; + ntoaptr=b; +#ifdef LINUX_21 + spin_unlock_irqrestore(&cipe_ntoa_lock, flags); +#endif + p=ntoabuf[b]; + for (i=0; i<4; ++i) { + int k=x[i]/100; + int l=(x[i]/10)%10; + if (k) + *p++=k+'0'; + if (k || l) + *p++=l+'0'; + *p++=(x[i]%10)+'0'; + if (i<3) + *p++='.'; + } + *p='\0'; + return ntoabuf[b]; +} + +/*** IOCTL handlers ***/ + +#ifdef SIOCGIFCIPPAR +static int cipe_getpar(struct NET_DEVICE *dev, struct siocgifcippar *parm) +{ + DEVTOCIPE(dev,c,-ENODEV); + + parm->sockshost=c->sockshost; + parm->socksport=c->socksport; + parm->tmo_keyxchg=c->tmo_keyxchg/HZ; + parm->tmo_keylife=c->tmo_keylife/HZ; + parm->flags=c->flags; + parm->cttl=c->cttl; + return 0; +} +#endif + +static int cipe_setpar(struct NET_DEVICE *dev, struct siocsifcippar *parm) +{ + DEVTOCIPE(dev,c,-ENODEV); + + if (parm->sockshost) + c->sockshost=parm->sockshost; + if (parm->socksport) + c->socksport=parm->socksport; + if (parm->tmo_keyxchg>10*60*HZ) + return -EINVAL; + if (parm->tmo_keyxchg) + c->tmo_keyxchg=parm->tmo_keyxchg*HZ; + if (parm->tmo_keylife>24*60*60*HZ) + return -EINVAL; + if (parm->tmo_keylife) + c->tmo_keylife=parm->tmo_keylife*HZ; + c->flags=(parm->flags&CIPF_MASK_EXT)|(c->flags&CIPF_MASK_INT); + c->cttl=parm->cttl; + dprintk(DEB_CALL, (KERN_DEBUG "%s: setpar %s:%d %ld %ld %04x %d\n", + dev->name, + cipe_ntoa(c->sockshost), ntohs(c->socksport), + c->tmo_keyxchg, c->tmo_keylife, + c->flags, c->cttl)); + return 0; +} + +static int cipe_setkey(struct NET_DEVICE *dev, struct siocsifcipkey *parm) +{ + DEVTOCIPE(dev,c,-ENODEV); + + dprintk(DEB_KXC, (KERN_INFO "%s: setkey %d\n", dev->name, parm->which)); + switch (parm->which) { + case KEY_STATIC: + ExpandUserKey(parm->thekey, c->key_e); +#if 0 + dprintk(DEB_CRYPT, (KERN_DEBUG "ExpandUserKey: %08x\n", + *(__u32*)(c->key_e))); +#endif + InvertKey(c->key_e, c->key_d); + c->flags|=CIPF_HAVE_KEY; + break; + case KEY_SEND: + ExpandUserKey(parm->thekey, c->skey_e); + c->timeskey=jiffies+c->tmo_keylife; + c->cntskey=0; + c->flags|=CIPF_HAVE_SKEY; + break; + case KEY_RECV: + ExpandUserKey(parm->thekey, c->rkey_d); + InvertKey(c->rkey_d, c->rkey_d); + c->timerkey=jiffies+2*c->tmo_keylife; /* allow for fuzz */ + c->cntrkey=0; + c->flags|=CIPF_HAVE_RKEY; + break; + case KEY_STATIC+KEY_INVAL: + c->flags&=~(CIPF_HAVE_KEY|CIPF_HAVE_SKEY|CIPF_HAVE_RKEY); + memset(&(c->key_e), 0, sizeof(c->key_e)); + memset(&(c->key_d), 0, sizeof(c->key_d)); + break; + case KEY_SEND+KEY_INVAL: + c->flags&=~CIPF_HAVE_SKEY; + memset(&(c->skey_e), 0, sizeof(c->skey_e)); + c->timeskey=jiffies+c->tmo_keyxchg; + break; + case KEY_RECV+KEY_INVAL: + c->flags&=~CIPF_HAVE_RKEY; + memset(&(c->rkey_d), 0, sizeof(c->rkey_d)); + c->timerkey=jiffies+c->tmo_keyxchg; + break; + default: + return -EINVAL; + } + return 0; +} + +static int cipe_alloc_dev(int n); +static void cipe_unalloc_dev(int n); + +static int cipe_owner(struct cipe *c) +{ + struct task_struct *p; + pid_t pid=c->owner; + if (!pid) return 0; + tasklist_LOCK(); + p=current; + do { + if (p->pid==pid) { + tasklist_UNLOCK(); + return pid; + } + p=p->next_task; + } while (p!=current); + tasklist_UNLOCK(); + return 0; +} + +#define cipe_nowner(n) cipe_owner(&cipe_ctrls[(n)]->cipe) + +static int cipe_alloc(struct NET_DEVICE *dev, struct siocsifcipall *parm) +{ +#ifdef NO_DYNDEV + return -ENOSYS; +#else + int n=parm->num; + int e; + if (n>=cipe_maxdev) + return -EINVAL; + if ((e=cipe_alloc_LOCK())) + return e; + if (n>=0) { + if (cipe_ctrls[n]) { + if (cipe_ctrls[n]->cipe.sock || (e=cipe_nowner(n))) { + printk(KERN_DEBUG DEVNAME ": dev %d busy pid=%d\n", n, e); + e=-EBUSY; + } else { + cipe_ctrls[n]->cipe.owner=current->pid; + } + } else { + e=cipe_alloc_dev(n); + } + } else { + e=-EMFILE; + for (n=0; ncipe.owner=current->pid; + e=0; + break; + } + } + } + if (!e) { + parm->num=n; + strncpy(parm->name, cipe_ctrls[n]->dev.name, sizeof(parm->name)-1); + parm->name[sizeof(parm->name)-1]='\0'; + } + cipe_alloc_UNLOCK(); + return e; +#endif +} + +static int cipe_unalloc(struct NET_DEVICE *dev, struct siocsifcipall *parm) +{ +#ifdef NO_DYNDEV + return -ENOSYS; +#else + int e; + if (parm->num<0 || parm->num>=cipe_maxdev) + return -EINVAL; + if ((e=cipe_alloc_LOCK())) + return e; + if (cipe_ctrls[parm->num]->cipe.sock) { + e=-EBUSY; + } else { + if (parm->num>0) + cipe_unalloc_dev(parm->num); + } + cipe_alloc_UNLOCK(); + return e; +#endif +} + + +/*** Device operation handlers ***/ + +int cipe_dev_ioctl(struct NET_DEVICE *dev, struct ifreq *ifr, int cmd) +{ + int e=-EINVAL; + +#ifdef LINUX_21 + + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + +#define doioctl(nam,fun,str) { \ + struct str parm; \ + dprintk(DEB_CALL, (KERN_INFO "%s: " nam "\n", dev->name)); \ + if ((e=copy_from_user((void*)&parm,(void*)ifr->ifr_data, \ + sizeof(parm)))<0) \ + goto out; \ + if ((e=fun(dev, &parm))<0) \ + goto out; \ + e=copy_to_user((void*)ifr->ifr_data, (void*)&parm, sizeof(parm)); \ + goto out; \ + } + +#else + + if (!suser()) + return -EPERM; + +#define doioctl(nam,fun,str) { \ + struct str parm; \ + dprintk(DEB_CALL, (KERN_INFO "%s: " nam "\n", dev->name)); \ + if ((e=verify_area(VERIFY_READ, ifr->ifr_data, sizeof(parm)))<0) \ + goto out; \ + memcpy_fromfs((void*)&parm, (void*)ifr->ifr_data, sizeof(parm)); \ + if ((e=fun(dev, &parm))<0) \ + goto out; \ + if ((e=verify_area(VERIFY_WRITE, ifr->ifr_data, sizeof(parm)))<0) \ + goto out; \ + memcpy_tofs((void*)ifr->ifr_data, (void*)&parm, sizeof(parm)); \ + goto out; \ + } + +#endif + + cipe_use_module(); + switch (cmd) { +#ifdef SIOCGIFCIPPAR + case SIOCGIFCIPPAR: + doioctl("getpar", cipe_getpar, siocgifcippar); +#endif + case SIOCSIFCIPPAR: + doioctl("setpar", cipe_setpar, siocsifcippar); + case SIOCSIFCIPKEY: + doioctl("setkey", cipe_setkey, siocsifcipkey); + case SIOCSIFCIPATT: + doioctl("attach", cipe_attach, siocsifcipatt); + case SIOCSIFCIPALL: + doioctl("alloc", cipe_alloc, siocsifcipall); + case SIOCSIFCIPUNA: + doioctl("unalloc", cipe_unalloc, siocsifcipall); + /* default: e=-EINVAL; */ + } + + out: + cipe_unuse_module(); + return e; + +#undef doioctl +} + +int cipe_dev_open(struct NET_DEVICE *dev) +{ + DEVTOCIPE(dev,c,-ENODEV); + if (!c->sock) + return -ENXIO; + dprintk(DEB_CALL, (KERN_INFO "%s: opened\n", dev->name)); + return 0; +} + +void cipe_close(struct cipe *c) +{ + cipe_zero_c(c); + dprintk(DEB_CALL, (KERN_INFO "%s: closed\n", c->dev->name)); + cipe_unuse_module(); +} + +int cipe_dev_close(struct NET_DEVICE *dev) +{ + struct cipe *c = (struct cipe*)(dev->priv); + if ((!c) || (c->magic!=CIPE_MAGIC)) { + printk(KERN_WARNING "%s: cipe_dev_close: no valid struct\n", + dev->name); + return 0; + } + if (c->sock) { + dprintk(DEB_CALL, (KERN_INFO "%s: closing\n", c->dev->name)); + /* Tell the attached socket we're going down */ + c->sock->shutdown=SHUTDOWN_MASK; + c->sock->zapped=1; + c->sock->err=ENXIO; + c->sock->error_report(c->sock); +#ifdef LINUX_21 + if (!cipe_owner(c)) { + /* SHOULD NOT HAPPEN. Socket is probably left orphaned. + This is really only an emergency path to allow closing + the device after an Oops. */ + printk(KERN_ERR "cipe_dev_close: not owned??\n"); + cipe_close(c); + } +#endif + } else { + cipe_close(c); + } + return 0; +} + +struct DEV_STATS *cipe_get_stats(struct NET_DEVICE *dev) +{ + DEVTOCIPE(dev,c,NULL); + return &(c->stat); +} + +int cipe_set_mac(struct NET_DEVICE *dev, void *p) +{ + struct sockaddr *addr=p; + memcpy(dev->dev_addr, addr->sa_data, dev->addr_len); + return 0; +} + + +/*** Initialization and finalization stuff ***/ + +#ifndef LINUX_21 +static inline void dev_init_buffers(struct NET_DEVICE *dev) +{ + int i; + for (i = 0; i < DEV_NUMBUFFS; i++) { + skb_queue_head_init(&dev->buffs[i]); + } +} +#endif + +static int cipe_init_dev(struct NET_DEVICE *dev) +{ + struct cipe *c = (struct cipe*)(dev->priv); + if (!c) + return -ENODEV; + + memset(c, 0, sizeof(struct cipe)); /* zero the device struct along */ + c->magic = CIPE_MAGIC; + c->dev = dev; + cipe_zero_c(c); + + /* Device parameters. */ +#ifdef VER_ETH + ether_setup(dev); /* sets hard_header etc. */ +#endif + /* Procedural */ + dev->open = cipe_dev_open; + dev->stop = cipe_dev_close; + dev->hard_start_xmit = cipe_xmit; + dev->set_mac_address = cipe_set_mac; + dev->do_ioctl = cipe_dev_ioctl; + dev->get_stats = cipe_get_stats; + + /* "Hardware" */ +#ifndef VER_ETH + dev->type = ARPHRD_TUNNEL; + dev->hard_header_len = 0; /* we copy anyway to expand */ + dev->tx_queue_len = 100; /* matches ethernet */ +#endif + dev->mtu = ETH_DATA_LEN + -sizeof(struct sockshdr) + -cipehdrlen + -cipefootlen; + + +#ifdef LINUX_21 + dev->iflink = -1; +#else + dev->family = AF_INET; + dev->pa_alen = 4; + dev->metric = 1; +#endif + dev_init_buffers(dev); + + /* New-style flags */ +#ifndef VER_ETH + dev->flags = IFF_POINTOPOINT|IFF_NOARP; +#endif + return 0; +} + +#ifndef LINUX_21 +struct semaphore cipe_alloc_sem=MUTEX; +#endif + +static int cipe_alloc_dev(int n) +{ + int e=0; + struct cipe_ctrl *cc; + struct NET_DEVICE *d; + + dprintk(DEB_CALL, (KERN_INFO DEVNAME ": cipe_alloc_dev %d\n", n)); + if (!(cc=kmalloc(sizeof(struct cipe_ctrl), GFP_KERNEL))) { + cipe_ctrls[n]=NULL; + printk(KERN_ERR DEVNAME ": failed to allocate device %d\n", n); + return -ENOMEM; + } + + memset((void *)cc, 0, sizeof(*cc)); +/* If this doesn't compile, define or undefine HAVE_DEVNAME_ARRAY + in cipe.h accordingly. */ +#ifdef HAVE_DEVNAME_ARRAY + sprintf(cc->dev.name, DEVNAME "%d", n); +#else + sprintf(cc->name, DEVNAME "%d", n); + cc->dev.name = cc->name; +#endif + cc->dev.base_addr = n; /* dummy */ + cc->dev.priv = (void*)&(cc->cipe); + cc->dev.next = NULL; + cc->dev.init = cipe_init_dev; /* called by register_netdevice */ + +#if 1 + /* Generate a dummy MAC address. This code seems to be in accordance + to the address assignments as of RFC1700, pp.172f. + We use 00-00-5E-vv-nn-zz with + vv=1pppccc0, p=protocol, c=crypto, + nn=device number, zz=from MAC of first eth device. + */ + cc->dev.dev_addr[2]=0x5E; + cc->dev.dev_addr[3]=0x80+(ProtocolVersion<<4)+(CRNUM<<1); + cc->dev.dev_addr[4]=n; + for (d=dev_base; d; d=d->next) + if (d->type==ARPHRD_ETHER) { + cc->dev.dev_addr[5]=d->dev_addr[5]; + break; + } +#else + /* MAC address will be generated from IP as with PLIP. FC-FC-ip-ip-ip-ip */ + cc->dev.dev_addr[1]=cc->dev.dev_addr[0]=0xFC; +#endif + memset(d->broadcast, 0xFF, ETH_ALEN); + cc->dev.addr_len=ETH_ALEN; + + e=register_netdevice(&(cc->dev)); + if (e<0) { + kfree(cc); + printk(KERN_ERR + "%s: register_netdevice() failed\n", cc->dev.name); + cc=NULL; + } else { + cc->cipe.owner=current->pid; + } + cipe_ctrls[n]=cc; + return e; +} + +static void cipe_unalloc_dev(int n) +{ + struct cipe_ctrl *cc=cipe_ctrls[n]; + if (!cc) + return; + dprintk(DEB_CALL, (KERN_INFO DEVNAME ": cipe_unalloc_dev %d\n", n)); + if (cc->cipe.magic!=CIPE_MAGIC) { + printk(KERN_WARNING DEVNAME ": Ouch: cipe_unalloc_dev() wrong struct\n"); + return; + } + unregister_netdevice(&(cc->dev)); + cipe_ctrls[n]=NULL; + kfree(cc); +} + +int init_module(void) +{ + int e=cipe_check_kernel(); + if (e<0) + return e; + + /* sanity check on insmod-provided data */ + if (cipe_maxdev<1) cipe_maxdev=1; +#ifdef NO_DYNDEV + if (cipe_maxdev>100) cipe_maxdev=100; +#else + if (cipe_maxdev>10000) cipe_maxdev=10000; +#endif + +#ifdef DEBUG + printk(KERN_INFO + DEVNAME ": CIPE driver vers %s (c) Olaf Titz 1996-2000, %d channels, debug=%d\n", + driver_version, cipe_maxdev, cipe_debug); +#else + printk(KERN_INFO + DEVNAME ": CIPE driver vers %s (c) Olaf Titz 1996-2000, %d channels\n", + driver_version, cipe_maxdev); +#endif + + prnseed=(~jiffies)^CURRENT_TIME; + cipe_ctrls = (struct cipe_ctrl **) kmalloc(sizeof(void*)*cipe_maxdev, + GFP_KERNEL); + if (!cipe_ctrls) { + printk(KERN_ERR + DEVNAME ": failed to allocate master control structure\n"); + return -ENOMEM; + } + memset(cipe_ctrls, 0, sizeof(void*)*cipe_maxdev); +#ifdef NO_DYNDEV + { + int i; + rtnl_LOCK(); + for (i=0; i + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: encaps.c,v 1.18 2000/09/13 21:46:41 olaf Exp $ */ + +#include "cipe.h" +#include +#include + +static inline void xorbuf(part *dst, part *src) +{ + int i; + for (i=0; i0) { + memcpy(r, p, blockSize); + ecb_dec(p, p, key); + xorbuf(p, q); + s=q; q=r; r=s; + p-=blockSize/sizeof(part); + } + } else { + while (i-->0) { + xorbuf(p, q); + ecb_enc(p, p, key); + q=p; + p-=blockSize/sizeof(part); + } + } +} + +#else + +/* + CBC encryption/decryption routines. + Note: the block to encrypt includes the IV, while decryption swallows + the IV. Length is always including IV. +*/ + +#define partinc(p) ((p)+blockSize/sizeof(part)) + +static void cbc_enc(unsigned char *msg, int len, Key * const key) +{ + part *p=(part *)msg; + int i=len/blockSize; + +#if 0 + dprintk(DEB_CRYPT, (KERN_DEBUG "cbc_enc: %08x %08x ", + *((__u32*)partinc(msg)), *(__u32*)key)); +#endif + while (--i>0) { + xorbuf(partinc(p), p); + p=partinc(p); + ecb_enc(p, p, *key); + } +#if 0 + dprintk(DEB_CRYPT, ("%08x\n", *((__u32*)partinc(msg)))); +#endif +} + +static void cbc_dec(unsigned char *msg, int len, Key * const key) +{ + part *p=(part *)msg; + int i=len/blockSize; + part r[blockSize/sizeof(part)]; + +#if 0 + dprintk(DEB_CRYPT, (KERN_DEBUG "cbc_dec: %08x %08x ", + *(__u32*)msg, *(__u32*)key)); +#endif + while (--i>0) { + ecb_dec(partinc(p), r, *key); + xorbuf(p, r); + p=partinc(p); + } +#if 0 + dprintk(DEB_CRYPT, ("%08x\n", *(__u32*)msg)); +#endif +} + +#endif + +#ifndef VER_SHORT +/* Fill a block of length blockSize with strong random numbers. + Used for generating IVs. */ +void cipe_cryptpad(unsigned char *buf) +{ + static int padcnt=MAXBLKS; + static Key padkey; + + if (++padcnt>MAXBLKS) { + /* make a new random key */ + UserKey k; + dprintk(DEB_CRYPT, (KERN_INFO "%s: re-keying cryptpad\n", DEVNAME)); + cipe_prnpad((unsigned char*)k, sizeof(UserKey)); + ExpandUserKey(k, padkey); + padcnt=0; + } + *(int *)(buf)=padcnt; + cipe_prnpad(buf+sizeof(int), blockSize-sizeof(int)); + ecb_enc((part*)buf, (part*)buf, padkey); +} + +void cipe_cryptpad_iv(unsigned char *buf) +{ + int i=5; + do { + cipe_cryptpad(buf); + if (*((__u32 *)buf) & htonl(0x7FFFFFFF)) + break; + } while (i-->0); + if (!i) + printk(KERN_CRIT "cipe_cryptpad_iv failed"); +} +#endif + + +void cipe_checkskey(struct cipe *c) +{ + if ((++c->cntskey>MAXBLKS) || (jiffies>c->timeskey)) { + /* make the control process send an NK_IND */ + cipe_fakenkey(c, NK_REQ); + c->timeskey=jiffies+c->tmo_keyxchg; + if (c->cntskey>MAXBLKS) + c->cntskey-=1000; + } +} + +void cipe_checkrkey(struct cipe *c) +{ + if ((c->flags&CIPF_HAVE_RKEY) && + ((++c->cntrkey>MAXBLKS*2) || (jiffies>c->timerkey))) { + /* make the control process send an NK_REQ */ + cipe_fakenkey(c, NK_RREQ); + c->flags&=~CIPF_HAVE_RKEY; + c->timerkey=jiffies+c->tmo_keyxchg; + if (c->cntrkey>MAXBLKS*2) + c->cntrkey-=1000; + } +} + +void cipe_nodynkey(struct cipe *c) +{ + if (jiffies>c->timerkey) { + /* make the control process send an NK_REQ */ + cipe_fakenkey(c, NK_RREQ); + c->timerkey=jiffies+c->tmo_keyxchg; + } + dprintk(DEB_CRYPT, (KERN_INFO "%s: missing dynamic key\n", + c->dev->name)); +} + +#if ProtocolVersion >= 3 + +/* Encryption/decryption version 3 */ + +void cipe_encrypt(struct cipe *c, unsigned char *buf, int *len, int typ) +{ + unsigned char p=7-(((*len)+4)&7); + /* merge key flag in IV */ + *buf&=0x7F; + if (c->flags&CIPF_HAVE_SKEY) + *buf|=0x80; + /* pad */ + cipe_prnpad(buf+(*len), p); + (*len)+=p+5; + /* set type and crc */ + *(buf+(*len)-5)=typ|(p<<4); + *((unsigned long *)(buf+(*len)-4))= + htonl(crc32(buf+blockSize, (*len)-blockSize-4)); + + dprintk(DEB_CRYPT, (KERN_INFO "%s: encrypt typ %d pad %d len %d\n", + c->dev->name, typ, p, *len)); + cbc_enc(buf, *len, c->flags&CIPF_HAVE_SKEY ? &c->skey_e : &c->key_e); + cipe_checkskey(c); +} + +unsigned short cipe_decrypt(struct cipe *c, unsigned char *buf, int *len) +{ + unsigned char p; + + if (((*buf)&0x80) && !(c->flags&CIPF_HAVE_RKEY)) { + cipe_nodynkey(c); + return TW_ERROR; /* can't decrypt - no valid key */ + } + cbc_dec(buf, *len, ((*buf)&0x80) ? &c->rkey_d : &c->key_d); + (*len)-=blockSize; + if (*((unsigned long *)(buf+(*len)-4)) != htonl(crc32(buf, (*len)-4))) { + dprintk(DEB_CRYPT, (KERN_INFO "%s: decrypt CRC error\n", + c->dev->name)); + return TW_ERROR; + } + p=*(buf+(*len)-5); + (*len)-=(p>>4)&7; + cipe_checkrkey(c); +#define CTLBITS 0x06 + dprintk(DEB_CRYPT, (KERN_INFO "%s: decrypt len=%d pad=%d typ=%02X\n", + c->dev->name, (*len), (p>>4)&7, p&CTLBITS)); + return (p&CTLBITS); +} + +#else + +/* Encryption/decryption version 1 and 2 */ + +void cipe_encrypt(struct cipe *c, unsigned char *buf, int *len, int typ) +{ + unsigned short x; + unsigned char p; + + p=8-((*len)&7); + cipe_prnpad(buf+(*len), p); + (*len)+=p; + +#ifdef VER_SHORT + x=((block_crc(buf, *len)&0xFFFE)^((p&7)<<8)^typ)|(c->haveskey); +#else + x=((block_crc(buf+blockSize, (*len)-blockSize)&0xFFFE) + ^((p&7)<<8)^typ)|(c->haveskey); +#endif +#ifdef VER_BACK + cbc_b(buf, *len, c->haveskey ? &c->skey_e : &c->key_e, 0); +#else + cbc_enc(buf, *len, c->haveskey ? &c->skey_e : &c->key_e); +#endif + + dprintk(DEB_CRYPT, (KERN_INFO "%s: encrypt pad %d\n", c->dev->name, p)); + buf[(*len)++]=x>>8; + buf[(*len)++]=x&255; + cipe_checkskey(c); +} + +unsigned short cipe_decrypt(struct cipe *c, unsigned char *buf, int *len) +{ + unsigned short x=(buf[(*len)-1])+(buf[(*len)-2]<<8); + unsigned char p; + + if ((x&1) && !(c->haverkey)) { + cipe_nodynkey(c); + return TW_ERROR; /* can't decrypt - no valid key */ + } + (*len)-=2; + if (*len<9 +#ifndef VER_SHORT + +blockSize +#endif + ) + return TW_ERROR; /* short packet */ + +#ifdef VER_BACK + cbc_b(buf, *len, (x&1) ? &c->rkey_d : &c->key_d, 1); +#else + cbc_dec(buf, *len, (x&1) ? &c->rkey_d : &c->key_d); +#endif +#ifndef VER_SHORT + (*len)-=blockSize; +#endif + + x^=block_crc(buf, *len); + p=(x>>8)&7; if (!p) p=8; + (*len)-=p; + cipe_checkrkey(c); + +#define CTLBITS 0xF8FE + dprintk(DEB_CRYPT, (KERN_INFO "%s: decrypt pad %d typ %04X\n", + c->dev->name, (x>>8)&7, x&CTLBITS)); + return (x&CTLBITS); /* delete the control bits */ +} + +#endif --- linux-2.4.21/drivers/addon/cipe3/ioctl.h.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/ioctl.h Fri Jul 25 15:02:11 2003 @@ -0,0 +1,24 @@ +/* + CIPE - encrypted IP over UDP tunneling + + ioctl.h - prototype for the ioctl interface, user part + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: ioctl.h,v 1.3 2000/03/27 17:38:23 olaf Exp $ */ + +#include "cipe.h" + +#ifdef SIOCGIFCIPPAR +extern int ioctl_getpar(int fd, char *ifname, struct siocgifcippar *sio); +#endif +extern int ioctl_setpar(int fd, char *ifname, struct siocsifcippar *sio); +extern int ioctl_setkey(int fd, char *ifname, struct siocsifcipkey *sio); +extern int ioctl_attach(int fd, char *ifname, struct siocsifcipatt *sio); +extern int ioctl_alloc(int fd, char *ifname, struct siocsifcipall *sio); +extern int ioctl_unalloc(int fd, char *ifname, struct siocsifcipall *sio); --- linux-2.4.21/drivers/addon/cipe3/module.c.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/module.c Fri Jul 25 15:02:11 2003 @@ -0,0 +1,89 @@ +/* + CIPE - encrypted IP over UDP tunneling + + module.c - kernel module interface stuff + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: module.c,v 1.5.2.1 2002/05/30 11:49:17 olaf Exp $ */ + +#include "cipe.h" +#include +#include + +/* We put this all here so that none of the other source files needs + to include , which could lead to collisions. */ + +#ifdef LINUX_21 +MODULE_AUTHOR("Olaf Titz "); +MODULE_DESCRIPTION("Encrypting IP-over-UDP tunnel"); +#ifdef MODULE_LICENSE +MODULE_LICENSE("GPL"); +#endif +MODULE_SUPPORTED_DEVICE(DEVNAME); +MODULE_PARM(cipe_maxdev,"i"); +MODULE_PARM_DESC(cipe_maxdev,"Maximum device number supported"); +#ifdef DEBUG +MODULE_PARM(cipe_debug,"i"); +MODULE_PARM_DESC(cipe_debug,"Debugging level"); +#endif +#endif + +void cipe_use_module(void) +{ + MOD_INC_USE_COUNT; +} + +void cipe_unuse_module(void) +{ + MOD_DEC_USE_COUNT; +} + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,0,30) +/* older kernel not always exported this */ + +int bad_user_access_length(void) +{ + panic("bad_user_access_length in " DEVNAME); +} + +#endif + +/* HACK: sanity check on SMP/non-SMP. + Is this really necessary? */ +int cipe_check_kernel(void) +{ + int s=0; + const char *p=system_utsname.version; + while (p[0] && p[1] && p[2]) { + if (p[0]=='S' && p[1]=='M' && p[2]=='P') { + s=1; + break; + } + ++p; + } + if ( +#ifdef __SMP__ + ! +#endif + s) { + printk(KERN_ERR + DEVNAME ": driver (" +#ifndef __SMP__ + "not " +#endif + "SMP) " + "mismatches kernel (" +#ifdef __SMP__ + "not " +#endif + "SMP)\n"); + return -EINVAL; + } + return 0; +} --- linux-2.4.21/drivers/addon/cipe3/options.h.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/options.h Fri Jul 25 15:02:11 2003 @@ -0,0 +1,29 @@ +/* File generated by genoptions.pl, do not edit */ + +#define Odevice 0 +#define Odebug 1 +#define Oipaddr 2 +#define Optpaddr 3 +#define Omask 4 +#define Obcast 5 +#define Omtu 6 +#define Ometric 7 +#define Octtl 8 +#define Ome 9 +#define Opeer 10 +#define Okey 11 +#define Onokey 12 +#define Osocks 13 +#define Otokxc 14 +#define Otokey 15 +#define Oipup 16 +#define Oipdown 17 +#define Oarg 18 +#define Omaxerr 19 +#define Otokxts 20 +#define Oping 21 +#define Otoping 22 +#define Odynip 23 +#define Ohwaddr 24 +#define Oifconfig 25 +#define Ochecksum 26 --- linux-2.4.21/drivers/addon/cipe3/output.c.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/output.c Fri Jul 25 15:02:11 2003 @@ -0,0 +1,621 @@ +/* + CIPE - encrypted IP over UDP tunneling + + output.c - the sending part of the CIPE device + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: output.c,v 1.40.2.2 2002/06/28 23:38:53 olaf Exp $ */ + +#include "cipe.h" + +#include +#include +#include +#include +#include +#include +#ifdef LINUX_24 +#include +#include +#endif + +#ifdef DEBUG + +#include "../lib/hexdump.c" + +void cipe_dump_packet(char *title, struct sk_buff *skb, int dumpskb) +{ + LOCK_PRINTK; + if (dumpskb) { + printk(KERN_DEBUG "SKB (%s):\n", skb->dev?skb->dev->name:""); + cipe_hexdump((unsigned char *)skb, sizeof(*skb)); + } + printk(KERN_DEBUG + "%s: packet len=" FLEN " dev=%s\n", + title, skb->len, skb->dev?skb->dev->name:""); + cipe_hexdump((unsigned char *)skb->data, skb->tail-skb->data); + UNLOCK_PRINTK; +} +#endif + +#ifdef LINUX_21 + +/* An adapted version of Linux 2.1 net/ipv4/ipip.c output routine. */ + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,37) +#define ip_ident(h,d) (h)->id=htons(ip_id_count++) +#else +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,4) +#define ip_ident(h,d) ip_select_ident(h,d) +#else +#define ip_ident(h,d) ip_select_ident(h,d,NULL) +#endif +#endif + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,36) +/* this is not exactly the newer kernel's routine, it just does what we need */ +struct sk_buff *skb_copy_expand(struct sk_buff *skb, int max_headroom, + int max_tailroom, int gfp) +{ + struct sk_buff *n=alloc_skb(skb->len+max_headroom+max_tailroom, gfp); + if (n) { + skb_reserve(n, max_headroom); + skb_put(n,skb->len); + memcpy(n->data,skb->data,skb->len); + n->priority=skb->priority; + n->protocol=skb->protocol; + n->dev=skb->dev; + n->dst=dst_clone(skb->dst); + memcpy(n->cb, skb->cb, sizeof(skb->cb)); + n->used=skb->used; + n->is_clone=0; + atomic_set(&n->users, 1); + n->pkt_type=skb->pkt_type; + n->stamp=skb->stamp; + n->security=skb->security; +#ifdef CONFIG_IP_FIREWALL + n->fwmark = skb->fwmark; +#endif + } + return n; +} +#endif + +int cipe_xmit(struct sk_buff *skb, struct NET_DEVICE *dev) +{ + struct cipe *tunnel = (struct cipe*)(dev->priv); + struct rtable *rt = NULL; /* Route to the other host */ + struct NET_DEVICE *tdev; /* Device to other host */ + struct iphdr *old_iph; + u8 tos = 0; + u16 df = 0; + u8 ttl; + + struct iphdr *iph; /* Our new IP header */ + struct udphdr *udph; + int max_headroom; /* The extra header space needed */ + int max_tailroom; + u32 dst = tunnel->peeraddr; + int mtu; + int length = skb->len; + + dprintk(DEB_OUT, (KERN_INFO "%s: cipe_xmit len=%d\n", dev->name, + length)); + if (tunnel->magic!=CIPE_MAGIC) { + printk(KERN_ERR DEVNAME + ": cipe_xmit called with wrong struct\n"); + return 0; + } +#ifdef DEBUG + if (cipe_debug&DEB_PKOU) + cipe_dump_packet("original", skb, 1); +#endif +#ifdef VER_ETH + /* A packet can contain anything. If sending from a bridge, + the header pointers are invalid. So compute our own. */ + old_iph = (skb->protocol==htons(ETH_P_IP)) + ? (struct iphdr*)(skb->data+ETH_HLEN) + : NULL; +#else + old_iph = skb->nh.iph; /* we get only proper IP packets */ +#endif + if (old_iph) { + int ilen = ntohs(old_iph->tot_len) +#ifdef VER_ETH + +ETH_HLEN +#endif + ; + if (length!=ilen) { + printk(KERN_ERR "%s: cipe_xmit packet length problem %d/%d\n", + dev->name, length, ilen); + goto tx_error_out; + } + tos = old_iph->tos; + df = old_iph->frag_off&__constant_htons(IP_DF); + ttl = tunnel->cttl ? tunnel->cttl : old_iph->ttl; + } else { + ttl = tunnel->cttl ? tunnel->cttl : 64; /* XX */ + } + + if (tunnel->recursion++) { + printk(KERN_ERR "%s: cipe_xmit reentrance\n", dev->name); + tunnel->stat.collisions++; + goto tx_error_out; + } +#ifndef VER_ETH + if (skb->protocol != __constant_htons(ETH_P_IP)) + goto tx_error_out; +#endif + +#if 0 + dprintk(DEB_OUT, (KERN_DEBUG "routing dst=%s src=%s tos=%x oif=%d\n", + cipe_ntoa(0, dst), cipe_ntoa(1, tunnel->myaddr), + RT_TOS(tos), tunnel->sock->bound_dev_if)); +#endif + if (ip_route_output(&rt, dst, tunnel->sock->rcv_saddr, RT_TOS(tos), + tunnel->sock->bound_dev_if)) { + dprintk(DEB_OUT, (KERN_NOTICE "%s: no route\n", dev->name)); + tunnel->stat.tx_carrier_errors++; + dst_link_failure(skb); + goto tx_error_out; + } + if (rt->rt_src!=tunnel->myaddr) { + printk(KERN_NOTICE "%s: changing my address: %s\n", dev->name, + cipe_ntoa(rt->rt_src)); + tunnel->myaddr=tunnel->sock->saddr=rt->rt_src; + } + + tdev = rt->u.dst.dev; + dprintk(DEB_OUT, (KERN_DEBUG "route dev=%s flags=%x type=%x\n", + tdev->name, rt->rt_flags, rt->rt_type)); + + if (tdev == dev) { + printk(KERN_ERR "%s: looped route\n", dev->name); + tunnel->stat.collisions++; + goto tx_error; + } + + mtu = rt->u.dst.pmtu - (cipehdrlen+cipefootlen); + if (tunnel->sockshost) + mtu -= sizeof(struct sockshdr); + + dprintk(DEB_OUT, (KERN_DEBUG "pmtu=%d dmtu=%d size=%d\n", + mtu, tdev->mtu, skb->len)); + + if (mtu < 68) { + printk(KERN_ERR "%s: MTU too small\n", dev->name); + tunnel->stat.collisions++; + goto tx_error; + } + if (skb->dst && mtu < skb->dst->pmtu) { + skb->dst->pmtu = mtu; + dprintk(DEB_OUT, (KERN_NOTICE "%s: adjusting PMTU\n", dev->name)); +#if 0 + /* TEST: is this OK? */ + icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); + goto tx_error; +#endif + } + + if (old_iph && (old_iph->frag_off&__constant_htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { + dprintk(DEB_OUT, (KERN_NOTICE "%s: fragmentation needed\n", dev->name)); + icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); + goto tx_error; + } + + max_headroom = ((tdev->hard_header_len+cipehdrlen+ + ((tunnel->sockshost) ? sizeof(struct sockshdr) : 0) + )+16)&(~15); + max_tailroom = (tunnel->flags&CIPF_HAVE_KEY) ? cipefootlen : 0; + { + struct sk_buff *n= skb_copy_expand(skb, max_headroom, + max_tailroom, GFP_ATOMIC); + if (!n) { + printk(KERN_INFO "%s: Out of memory, dropped packet\n", + dev->name); + goto tx_error; + } + if (skb->sk) + skb_set_owner_w(n, skb->sk); + dev_kfree_skb(skb); + skb = n; + } + memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt)); + dst_release(skb->dst); + skb->dst = &rt->u.dst; + skb->protocol = htons(ETH_P_IP); + + if (tunnel->flags&CIPF_HAVE_KEY) { +#ifndef VER_SHORT + /* Add an IV */ + cipe_cryptpad_iv(skb_push(skb, blockSize)); + length+=blockSize; +#endif + if (!tunnel->flags&CIPF_MAY_STKEY && !tunnel->flags&CIPF_HAVE_SKEY) + /* Attempt to encrypt data using invalid static key */ + goto tx_error; + cipe_encrypt(tunnel, skb->data, &length, TW_DATA); + /* This is incorrect - the tail room gets first used and then + reserved. Doesn't matter in the current (2.0.29) implementation + of skb_put though. Alternative solution would ruin the nice + module separation - we don't need to know the real amount + of padding here. */ + if (length-skb->len > skb->end-skb->tail) { + printk(KERN_ERR "%s: tailroom problem %d %d %ld\n", + dev->name, length, skb->len, skb->end-skb->tail); + goto tx_error; + } + (void) skb_put(skb, length-skb->len); + } else if (!tunnel->flags&CIPF_MAY_CLEAR) { + goto tx_error; + } + + if (tunnel->sockshost) { + /* Install a SOCKS header */ + struct sockshdr *sh = (struct sockshdr *) + skb_push(skb, sizeof(struct sockshdr)); + memset(sh, 0, 4); + sh->atyp=1; + /* sockshost and socksport contain the real peer's address + and the configured/guessed peer is really the socks relayer! */ + sh->dstaddr=tunnel->sockshost; + sh->dstport=tunnel->socksport; + length+=sizeof(struct sockshdr); + } + + /* Install our new headers */ + udph = skb->h.uh = (struct udphdr *) skb_push(skb, sizeof(struct udphdr)); + skb->mac.raw = skb_push(skb, sizeof(struct iphdr)); + iph = skb->nh.iph = (struct iphdr *) skb->mac.raw; + + /* + * Push down and install the CIPE/UDP header. + */ + iph->version = 4; + iph->ihl = sizeof(struct iphdr)>>2; + iph->tos = tos; + iph->tot_len = htons(skb->len); + ip_ident(iph, &rt->u.dst); + iph->frag_off = df; + iph->ttl = ttl; + iph->protocol = IPPROTO_UDP; + iph->saddr = rt->rt_src; + iph->daddr = rt->rt_dst; + + ip_send_check(iph); + + udph->source = tunnel->myport; + udph->dest = tunnel->peerport; + udph->len = htons(length+sizeof(struct udphdr)); + /* Encrypted packets are checksummed already, so we can safely + ignore the UDP checksum. Provide a means to do it nonetheless */ + udph->check = 0; + if (tunnel->flags&CIPF_DO_CSUM) { + udph->check=csum_tcpudp_magic( + iph->saddr, iph->daddr, + length+sizeof(struct udphdr), IPPROTO_UDP, + csum_partial((char *)udph, length+sizeof(struct udphdr), 0)); + if (!udph->check) + udph->check=-1; + } + + tunnel->stat.tx_bytes += skb->len; + tunnel->stat.tx_packets++; + dprintk(DEB_OUT, (KERN_INFO + "%s: sending %d from %s:%d to %s:%d\n", + dev->name, skb->len, + cipe_ntoa(iph->saddr), ntohs(udph->source), + cipe_ntoa(iph->daddr), ntohs(udph->dest))); + if (tunnel->sockshost) + dprintk(DEB_OUT, (KERN_INFO "%s: via SOCKS to %s:%d\n", dev->name, + cipe_ntoa(tunnel->sockshost), + ntohs(tunnel->socksport))); +#if 0 + dprintk(DEB_OUT, (KERN_INFO "dst: (%d,%d) %s %d %d\n", + skb->dst->refcnt, skb->dst->use, + skb->dst->dev->name, skb->dst->pmtu, + skb->dst->error)); +#endif +#ifdef DEBUG + if (cipe_debug&DEB_PKOU) + cipe_dump_packet("sending", skb, 0); +#endif + nf_conntrack_null(skb); +#ifdef LINUX_24 + { + int err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, + rt->u.dst.dev, ip_send); + if (err==NET_XMIT_SUCCESS || err==NET_XMIT_CN) { + tunnel->stat.tx_bytes += skb->len; + tunnel->stat.tx_packets++; + } else { + tunnel->stat.tx_errors++; + tunnel->stat.tx_aborted_errors++; + } + } +#else + ip_send(skb); +#endif + tunnel->recursion--; + return 0; + + tx_error: + ip_rt_put(rt); + tx_error_out: + tunnel->stat.tx_errors++; + dev_kfree_skb(skb); + tunnel->recursion--; + return 0; +} + +#else /* LINUX_21 */ + +/* An adapted version of Linux 2.0 drivers/net/new_tunnel.c. */ + +#ifdef SO_BINDTODEVICE + #define iproute(t,o,d) ip_rt_route(t,o,d) +#else + #define iproute(t,o,d) ip_rt_route(t,o) +#endif + +#if LINUX_VERSION_CODE < 131102 /* < 2.0.30 */ + #include + #ifdef CONFIG_IP_FORWARD + #define ipforward(s,d,o,t) ip_forward(s,d,o,t) + #else + #error "Requires IP forwarding enabled in kernel" + #endif +#else /* >= 2.0.30 */ + #define ipforward(s,d,o,t) (sysctl_ip_forward ? ip_forward(s,d,o,t) : -1) +#endif + +int cipe_xmit(struct sk_buff *skb, struct NET_DEVICE *dev) +{ + struct enet_statistics *stats; /* This device's statistics */ + struct rtable *rt; /* Route to the other host */ + struct NET_DEVICE *tdev; /* Device to other host */ + struct iphdr *iph; /* Our new IP header */ + struct udphdr *udph; + __u32 target; /* The other host's IP address */ + int max_headroom; /* The extra header space needed */ + int max_tailroom; + int tos, ttl, length; + DEVTOCIPE(dev,c,0); + + if (skb == NULL || dev == NULL) { + dprintk(DEB_OUT, (KERN_INFO "%s: nothing to do\n", dev->name)); + return 0; + } + + /* + * Make sure we are not busy (check lock variable) + */ + stats = &(c->stat); + if (dev->tbusy != 0) + { + printk(KERN_WARNING "%s: device timeout (really possible?)\n", + dev->name); + dev->tbusy=0; + stats->tx_errors++; + return(1); + } + +#ifdef DEBUG + if (cipe_debug&DEB_PKOU) + cipe_dump_packet("original", skb, 0); +#endif + /* + * First things first. Look up the destination address in the + * routing tables + */ + target = c->peeraddr; + if ((!target) || (!c->peerport) || (!c->myport)) { + /* unconfigured device */ + printk(KERN_INFO "%s: unconfigured\n", dev->name); + goto error; + } + if ((rt = iproute(target, 0, skb->sk?skb->sk->bound_device:NULL)) == NULL) + { + /* No route to host */ + printk(KERN_INFO "%s: target unreachable\n", dev->name); + goto error; + } + dprintk(DEB_OUT, (KERN_INFO + "%s: routing to %08lX from %08lX via %08lX dev %s\n", + dev->name, ntohl(rt->rt_dst), ntohl(rt->rt_src), + ntohl(rt->rt_gateway), rt->rt_dev->name)); + + tdev = rt->rt_dev; + ip_rt_put(rt); + + if (tdev == dev) + { + /* Tunnel to ourselves? -- I don't think so. */ + printk ( KERN_INFO "%s: Packet targetted at myself!\n" , dev->name); + goto error; + } + + /* + * Okay, now see if we can stuff it in the buffer as-is. We can not. + */ + max_headroom = (((tdev->hard_header_len+15)&~15)+cipehdrlen+ + ((c->sockshost) ? sizeof(struct sockshdr) : 0)); + max_tailroom = (c->flags&CIPF_HAVE_KEY) ? cipefootlen : 0; + { + struct sk_buff *new_skb; + + if ( !(new_skb = + dev_alloc_skb(skb->len+max_headroom+max_tailroom)) ) + { + printk(KERN_INFO "%s: Out of memory, dropped packet\n", + dev->name); + dev->tbusy = 0; + stats->tx_dropped++; + dev_kfree_skb(skb, FREE_WRITE); + return 0; + } + new_skb->free = 1; + + /* + * Reserve space for our header and the lower device header + */ + skb_reserve(new_skb, max_headroom); + + /* + * Copy the old packet to the new buffer. + * Note that new_skb->h.iph will be our (tunnel driver's) header + * and new_skb->ip_hdr is the IP header of the old packet. + */ + new_skb->ip_hdr = (struct iphdr *) skb_put(new_skb, skb->len); + new_skb->mac.raw = new_skb->data; + new_skb->dev = skb->dev; + memcpy(new_skb->ip_hdr, skb->data, skb->len); + memset(new_skb->proto_priv, 0, sizeof(skb->proto_priv)); + + /* Free the old packet, we no longer need it */ + dev_kfree_skb(skb, FREE_WRITE); + skb = new_skb; + } +#ifdef VER_ETH + if (skb->mac.ethernet->h_proto==htons(ETH_P_IP)) { +#endif + tos = skb->ip_hdr->tos; + ttl = skb->ip_hdr->ttl; +#ifdef VER_ETH + } else { + tos = 0; + ttl = 64; + } +#endif + length = skb->len; + if (c->flags&CIPF_HAVE_KEY) { +#ifndef VER_SHORT + /* Add an IV */ + cipe_cryptpad(skb_push(skb, blockSize)); + length+=blockSize; +#endif + if (!c->flags&CIPF_MAY_STKEY && !c->flags&CIPF_HAVE_SKEY) + /* Attempt to encrypt data using invalid static key */ + goto error; + cipe_encrypt(c, skb->data, &length, TW_DATA); + /* This is incorrect - the tail room gets first used and then + reserved. Doesn't matter in the current (2.0.29) implementation + of skb_put though. Alternative solution would ruin the nice + module separation - we don't need to know the real amount + of padding here. */ + (void) skb_put(skb, length-skb->len); + } else if (!c->flags&CIPF_MAY_CLEAR) { + goto error; + } + + if (c->sockshost) { + /* Install a SOCKS header */ + struct sockshdr *sh = (struct sockshdr *) + skb_push(skb, sizeof(struct sockshdr)); + memset(sh, 0, 4); + sh->atyp=1; + /* sockshost and socksport contain the real peer's address + and the configured/guessed peer is really the socks relayer! */ + sh->dstaddr=c->sockshost; + sh->dstport=c->socksport; + length+=sizeof(struct sockshdr); + } + + /* Install our new headers */ + udph = (struct udphdr *) skb_push(skb, sizeof(struct udphdr)); + skb->h.iph = (struct iphdr *) skb_push(skb, sizeof(struct iphdr)); + + /* + * Push down and install the CIPE/UDP header. + */ + + iph = skb->h.iph; + iph->version = 4; + iph->tos = tos; + + /* In new_tunnel.c, we use the original packet's TTL here. + Setting a new TTL behaves better to the user, and RFC2003 + recommends it too. But this doesn't fully protect against + routing loops. So make it configurable via an argument: + "cttl" gives the TTL value; if 0 use the packet's + value. Default should be 64, as with the other protocols + (ip_statistics.IpDefaultTTL, but this variable is not + available for modules). */ + + iph->ttl = c->cttl ? c->cttl : ttl; + + iph->frag_off = 0; + iph->daddr = target; + iph->saddr = c->myaddr; /* tdev->pa_addr; */ + iph->protocol = IPPROTO_UDP; + iph->ihl = 5; + iph->tot_len = htons(skb->len); + iph->id = htons(ip_id_count++); /* Race condition here? */ + ip_send_check(iph); + + udph->source = c->myport; + udph->dest = c->peerport; + udph->len = htons(length+sizeof(struct udphdr)); + /* Encrypted packets are checksummed already, so we can safely + ignore the UDP checksum. Provide a means to do it nonetheless */ + udph->check = 0; + if (c->flags&CIPF_DO_CSUM) { + udph->check=csum_tcpudp_magic( + iph->saddr, iph->daddr, + length+sizeof(struct udphdr), IPPROTO_UDP, + csum_partial((char *)udph, length+sizeof(struct udphdr), 0)); + if (!udph->check) + udph->check=-1; + } + + skb->ip_hdr = skb->h.iph; + skb->protocol = htons(ETH_P_IP); + + /* + * Send the packet on its way! + * Note that dev_queue_xmit() will eventually free the skb. + * If ip_forward() made a copy, it will return 1 so we can free. + */ + + dprintk(DEB_OUT, (KERN_INFO "%s: send to %s via %s\n", + dev->name, cipe_ntoa(target), tdev->name)); + +#ifdef DEBUG + if (cipe_debug&DEB_PKOU) + cipe_dump_packet("sending", skb, 0); +#endif + switch (ipforward(skb, dev, IPFWD_NOTTLDEC, target)) { + case -1: + printk(KERN_INFO "%s: forwarding failed\n", dev->name); + /* fall thru */ + case 1: + dev_kfree_skb(skb, FREE_WRITE); + /* Does it really need dev_ here? I think so. */ + break; + default: + /* nothing to do */ + } + + /* + * Clean up: We're done with the route and the packet + */ + + /* Record statistics and return */ + stats->tx_packets++; + dev->tbusy=0; + return 0; + + error: + stats->tx_errors++; + dev_kfree_skb(skb, FREE_WRITE); + dev->tbusy=0; + return 0; +} + +#endif /* LINUX_21 */ --- linux-2.4.21/drivers/addon/cipe3/sock.c.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/sock.c Fri Jul 25 15:02:11 2003 @@ -0,0 +1,731 @@ +/* + CIPE - encrypted IP over UDP tunneling + + sock.c - socket/input interface + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: sock.c,v 1.33.2.3 2002/06/28 23:38:53 olaf Exp $ */ + +#include "cipe.h" + +#include +#include +#include +#include +#include +#ifdef LINUX_21 +#include +#else +typedef unsigned short mm_segment_t; +#endif + +#ifdef LINUX_21 +#define kfreeskb(s,t) kfree_skb(s) +#define saddr(skb) ((skb)->nh.iph->saddr) +#define daddr(skb) ((skb)->nh.iph->daddr) +#else +#define kfreeskb(s,t) kfree_skb(s,t) +#define saddr(skb) ((skb)->saddr) +#define daddr(skb) ((skb)->daddr) +#endif + +/* Rewire generic socket operations to our device-specific ones. + We have new routines for close, sendmsg, recvmsg. */ + +#ifndef LINUX_21 +#define user_data protinfo.af_packet.bound_dev +#endif + +/* init struct cipe *c based on struct sock *sk */ +#define SOCKTOC(nam,sk,c,r) \ + struct cipe *c=(struct cipe *)sk->user_data; \ + if ((!c) || (c->magic!=CIPE_MAGIC)) { \ + printk(KERN_ERR "Ouch: SOCKTOC " nam "\n"); return r; } \ + else { \ + dprintk(DEB_CALL, (KERN_INFO "%s: " nam "\n", c->dev->name)); } + + +/* Close the socket */ +void cipe_sock_close(struct sock *sock, timeout_t timeout) +{ + SOCKTOC("sock_close",sock,c,); + c->sock=NULL; + + /* Put back the old protocol block and let it do the close */ + sock->prot=c->udp_prot; + sock->prot->close(sock, timeout); + if (c->dev->flags&IFF_UP) { + rtnl_LOCK(); + dev_close(c->dev); + rtnl_UNLOCK(); + } else { + cipe_close(c); + } +} + +/* Anything we send to this socket is in fact a key exchange block. + Encode and encrypt it accordingly. +*/ +int cipe_sendmsg(struct sock *sock, struct msghdr *msg, int len +#ifndef LINUX_21 + , int nonblock, int flags +#endif + ) +{ + struct msghdr mymsg; + struct iovec myio[2]; + struct sockaddr_in sa; + struct sockshdr sh; + int e, n=0; + unsigned char buf[KEYXCHGBLKMAX+blockSize]; + SOCKTOC("cipe_sendmsg",sock,c,-ENOSYS); + + if (len>KEYXCHGBLKMAX) + return -EMSGSIZE; +#ifdef VER_SHORT + if (msg->msg_flags&MSG_OOB) + return -EINVAL; +#endif + cipe_prnpad(buf, sizeof(buf)); +#ifdef VER_SHORT + memcpy_fromiovec(buf, msg->msg_iov, len); +#else + memcpy_fromiovec(buf+blockSize, msg->msg_iov, len); + len+=blockSize; +#endif + if (!(msg->msg_flags&MSG_OOB)) { + if (buf[0 +#ifndef VER_SHORT + +blockSize +#endif + ]>=CT_DUMMY) { + if (!c->flags&CIPF_HAVE_KEY) + return -EINVAL; + buf[KEYXCHGTSPOS-1]='\0'; + } else { + if (lenmsg_flags&MSG_OOB) { + memset(buf, 0, blockSize); + } else { + len=KEYXCHGBLKMIN+buf[sizeof(buf)-1]; /* random */ + cipe_encrypt(c, buf, &len, TW_NEWKEY); + } + + sa.sin_family=AF_INET; + sa.sin_addr.s_addr=c->peeraddr; + sa.sin_port=c->peerport; + + if (c->sockshost) { + /* Prepend a socks header. */ + memset(&sh, 0, sizeof(sh)); + sh.atyp=1; + sh.dstaddr=c->sockshost; + sh.dstport=c->socksport; + myio[n].iov_base=&sh; + myio[n].iov_len=sizeof(sh); + ++n; + } + myio[n].iov_base=&buf; + myio[n].iov_len=len; + /* mymsg=*msg; */ + mymsg.msg_name=&sa; + mymsg.msg_namelen=sizeof(sa); + mymsg.msg_iov=myio; + mymsg.msg_iovlen=n+1; + /* just to be sure */ + mymsg.msg_control=NULL; + mymsg.msg_controllen=0; + mymsg.msg_flags=0; + + /* Call the real thing. Pretend this is user space segment. */ + { + mm_segment_t fs=get_fs(); + set_fs(get_ds()); + if (c->sockshost) + len+=sizeof(struct sockshdr); + dprintk(DEB_KXC, (KERN_INFO "%s: real sendmsg len %d text=%04x...\n", + c->dev->name, len, + ntohs(*((unsigned short *)(myio[n].iov_base))))); + e=c->udp_prot->sendmsg(sock, &mymsg, len +#ifndef LINUX_21 + , nonblock, flags +#endif + ); + set_fs(fs); + } + return e; +} + +/* Check if we have a new peer */ +static void checkpeer(struct cipe *c, __u32 saddr, __u16 sport) +{ + if (c->sockshost) { + if (c->sockshost==saddr && c->socksport==sport) + return; + /* sockshost and socksport contain the real peer's address + and the configured/guessed peer is really the socks relayer! */ + c->sockshost=saddr; + c->socksport=sport; + } else { + if (c->peeraddr==saddr && c->peerport==sport) + return; + c->peeraddr=saddr; + c->peerport=sport; + } + printk(KERN_NOTICE "%s: new peer %s:%d\n", + c->dev->name, cipe_ntoa(saddr), ntohs(sport)); +} + +/* Decrypt a received packet. Requeue it or return kxc block. */ +/* On entry the packet starts with the original UDP header, + ip_hdr and h.uh are set to the IP and UDP headers. */ +struct sk_buff *cipe_decrypt_skb(struct cipe *c, struct sock *sk, + struct sk_buff *skb, + int *msgflag) +{ + struct sk_buff *n=NULL; + int length; + __u32 rsaddr; + __u16 rsport; + +#ifdef DEBUG + if (cipe_debug&DEB_PKIN) + cipe_dump_packet("received", skb, 1); +#endif + length=ntohs(skb->h.uh->len)-sizeof(struct udphdr); +#if 0 /* UDP should check this */ + if (length!=skb->len-sizeof(struct udphdr)) { + dprintk(DEB_INP, (KERN_INFO "%s: bogus UDP length (%d/%d)\n", + c->dev->name, length, + skb->len-sizeof(struct udphdr))); + goto framerr; + } +#endif + if (length<9+(c->sockshost?sizeof(struct sockshdr):0)) { + /* XX hardcoded IV size */ + printk(KERN_INFO "%s: got short packet from %s\n", c->dev->name, + cipe_ntoa(saddr(skb))); + goto framerr; + } + + n=alloc_skb(skb->len, GFP_KERNEL); + if (!n) { + printk(KERN_WARNING "%s: cipe_decrypt_skb: out of memory\n", + c->dev->name); + ++c->stat.rx_dropped; + return NULL; + } +#if 0 /*def LINUX_21*/ + if (skb->sk) + skb_set_owner_r(n, skb->sk); +#endif +#ifndef LINUX_21 + n->free=1; +#endif + n->dev=c->dev; + + /* Copy the datagram into new buffer, skip IP header */ + /* We must copy here because raw sockets get only a clone of the + skbuff, so they would receive the plaintext */ + dprintk(DEB_INP, (KERN_INFO DEVNAME + ": sa=%s da=%s us=%d ud=%d ul=%d\n", + cipe_ntoa(saddr(skb)), cipe_ntoa(daddr(skb)), + ntohs(skb->h.uh->source), ntohs(skb->h.uh->dest), + ntohs(skb->h.uh->len))); + + /* why did this get swapped?? */ +#ifdef LINUX_21 + rsaddr=saddr(skb); +#else + rsaddr=daddr(skb); +#endif + rsport=skb->h.uh->source; + skb_put(n,skb->len); + memcpy(n->data, skb->h.raw, skb->len); + n->h.uh=(struct udphdr *)n->data; + + if (c->sockshost) { + /* Pull out the SOCKS header and correct the peer's address. */ + struct sockshdr *sh; + sh=(struct sockshdr *)skb_pull(n, sizeof(struct udphdr)); + dprintk(DEB_INP, (KERN_INFO "socks: fr=%d at=%d da=%s dp=%d\n", + sh->frag, sh->atyp, + cipe_ntoa(sh->dstaddr), ntohs(sh->dstport))); + if (sh->frag || (sh->atyp!=1)) + goto error; + /* Pull out UDP header */ +#ifdef LINUX_21 + n->nh.iph=(struct iphdr *)skb_pull(n, sizeof(struct sockshdr)); +#else + n->ip_hdr=(struct iphdr *)skb_pull(n, sizeof(struct sockshdr)); +#endif + /***saddr(n)=sh->dstaddr;*/ + rsaddr=sh->dstaddr; + rsport=n->h.uh->source=sh->dstport; + length-=sizeof(struct sockshdr); + } else { + /* Pull out UDP header */ +#ifdef LINUX_21 + n->nh.iph=(struct iphdr *) skb_pull(n, sizeof(struct udphdr)); +#else + n->ip_hdr=(struct iphdr *) skb_pull(n, sizeof(struct udphdr)); +#endif + /***saddr(n)=rsaddr;*/ + n->h.uh->source=rsport; + } + +#ifndef VER_SHORT + if (!(*((__u32 *)n->data) & htonl(0x7FFFFFFF))) { + dprintk(DEB_INP, (KERN_INFO "got unencrypted packet (iv=0) len=%d\n", + length)); + skb_pull(n, blockSize); + /* XX not sure about TW_CTRL handling... */ + switch (*n->data) { + /* Restrict what can be received unencrypted. */ + case CT_DUMMY: case CT_DEBUG: case CT_CONFREQ: case CT_CONF: + break; + default: + printk(KERN_WARNING + "%s: got disallowed unencrypted control %02x\n", + c->dev->name, *n->data); + goto error; + } +#ifdef LINUX_21 + get_fast_time(&n->stamp); +#endif + /* No checkpeer() here because not authenticated! */ + n->h.uh->check=0; + return n; + } +#endif + if (c->flags&CIPF_HAVE_KEY) { + if (length%blockSize) { + printk(KERN_INFO "%s: got bogus length=%d\n", c->dev->name, + length); + goto error; + } + switch (cipe_decrypt(c, n->data, &length)) { + case TW_DATA: + if (!c->flags&CIPF_MAY_STKEY && !c->flags&CIPF_HAVE_RKEY) { + printk(KERN_ERR "%s: got data using invalid static key\n", + c->dev->name); + goto error; + } + break; + case TW_CTRL: + /* return it as a control block - out of band datagram */ + *msgflag|=MSG_OOB; + /* fall thru */ + case TW_NEWKEY: + /* return it as key exchange block - proper UDP datagram */ + dprintk(DEB_INP, (KERN_DEBUG "TW_NEWKEY data=%p len=" FLEN + " length=%d\n", n->data, n->len, length)); +#ifdef LINUX_21 + get_fast_time(&n->stamp); +#endif + skb_trim(n, length); + checkpeer(c, rsaddr, rsport); +#if 0 + n->saddr=c->myaddr; + n->daddr=c->peeraddr; +#endif + n->h.uh->check=0; + return n; + default: + /* Bogus packet etc. */ + ++c->stat.rx_crc_errors; + goto error; + } + } else if (!c->flags&CIPF_MAY_CLEAR) { + goto error; + } + + dprintk(DEB_INP, (KERN_DEBUG "TW_DATA data=%p len=" FLEN "length=%d\n", + n->data, n->len, length)); + skb_trim(n, length); + checkpeer(c, rsaddr, rsport); + /* adjust pointers */ +#ifdef VER_ETH + n->protocol = eth_type_trans(n, c->dev); + /* n->pkt_type = PACKET_HOST; */ +#else + n->mac.raw=n->data; /* no hw header */ + n->protocol = htons(ETH_P_IP); + n->pkt_type = PACKET_HOST; +#endif +#ifdef LINUX_21 + n->nh.raw=n->data; + memset(&(IPCB(n)->opt), 0, sizeof(IPCB(n)->opt)); +#else + n->h.iph=(struct iphdr *)n->data; + memset(n->proto_priv, 0, sizeof(struct options)); +#endif + if (lengthsockshost?sizeof(struct sockshdr):0)) { + printk(KERN_INFO "%s: got short packet from %s\n", c->dev->name, + cipe_ntoa(saddr(skb))); + goto framerr; + } + + n->ip_summed = 0; + /* this prints nonsense for non-IP packets. Ignore that. */ + dprintk(DEB_INP, (KERN_INFO "%s: real src %s dst %s len %d\n", + n->dev->name, cipe_ntoa(saddr(n)), + cipe_ntoa(daddr(n)), length)); + +#ifdef DEBUG + if (cipe_debug&DEB_PKIN) + cipe_dump_packet("decrypted", n, 1); +#ifdef LINUX_23 + dprintk(DEB_INP, (KERN_DEBUG "%s state=%ld refcnt=%d\n", n->dev->name, n->dev->state, + atomic_read(&n->dev->refcnt))); +#endif +#endif + + /* requeue */ + netif_rx(n); +#ifdef LINUX_21 + c->stat.rx_bytes+=skb->len; /* count carrier-level bytes */ +#endif + c->stat.rx_packets++; + return NULL; + + framerr: + ++c->stat.rx_frame_errors; /* slightly abuse this */ + error: + ++c->stat.rx_errors; + if (n) + kfreeskb(n, FREE_READ); + return NULL; +} + +/* Receive message. If encrypted, put it through the mill. + If decrypted, return it as key exchange block. + This is mostly from net/ipv4/udp.c, but cipe_decrypt_skb pulls the + UDP header. +*/ + +int cipe_recvmsg(struct sock *sk, struct msghdr *msg, int len, + int noblock, int flags,int *addr_len) +{ + int copied; + struct sk_buff *skb, *skn; + int er=0; + struct sockaddr_in *sin=(struct sockaddr_in *)msg->msg_name; + SOCKTOC("cipe_recvmsg",sk,c,-ENOSYS); + + /* + * Check any passed addresses + */ + + if (addr_len) + *addr_len=sizeof(*sin); + + /* + * From here the generic datagram does a lot of the work. Come + * the finished NET3, it will do _ALL_ the work! + */ + + do { + /* CIPE: look if the packet is encrypted, repeat until + a decrypted one is found */ + skn=NULL; + skb=skb_recv_datagram(sk,flags,noblock,&er); + if(skb==NULL) { + dprintk(DEB_KXC, (KERN_INFO "%s: skb_recv_datagram: %d\n", + c->dev->name, er)); + return er; + } + + if (!skb->h.uh->source) { + /* Synthetic KXC packets are marked by source port 0. + Correct this - we know the truth from our structure. + Perhaps it would be better to not correct it so the + user level daemon can spot the difference? */ + skb->h.uh->source=c->peerport; + skb_pull(skb, sizeof(struct udphdr)); + break; + } + skn=cipe_decrypt_skb(c, sk, skb, &(msg->msg_flags)); + skb_free_datagram(sk, skb); + skb=skn; + } while (skb==NULL); + + dprintk(DEB_INP, (KERN_INFO "%s: returning " FLEN " flags %04x\n", + c->dev->name, skb->len, msg->msg_flags)); + copied = skb->len; + if (copied > len) + { + copied = len; +#ifdef LINUX_21 + msg->msg_flags |= MSG_TRUNC; +#endif + } + if (copied<=0) { + printk(KERN_ERR "cipe_recvmsg: bogus length %d\n", copied); + goto out_free; + } + + /* + * FIXME : should use udp header size info value + */ +#ifdef LINUX_21 +#if 0 + er = skb_copy_datagram_iovec(skb, skb->data-skb-h.raw, + msg->msg_iov, copied); +#else + er = memcpy_toiovec(msg->msg_iov, skb->data, copied); +#endif + if (er<0) + goto out_free; +#else +#if 0 + skb_copy_datagram_iovec(skb,of,msg->msg_iov,copied); +#else + memcpy_toiovec(msg->msg_iov, skb->data, copied); +#endif +#endif + sk->stamp=skb->stamp; + + /* Copy the address. */ + if (sin +#ifdef LINUX_21 + && skb->nh.iph /* Fake KXC has no address */ +#endif + ) { + sin->sin_family = AF_INET; + sin->sin_port = skb->h.uh->source; + sin->sin_addr.s_addr = daddr(skb); + } + er=copied; + + out_free: + if (skb==skn) + /* the buffer was a copy made by decryption */ + kfreeskb(skb, FREE_READ); + else + skb_free_datagram(sk, skb); + + return(er); +} + +#ifdef LINUX_21 + +#include + +int cipe_attach(struct NET_DEVICE *dev, struct siocsifcipatt *parm) +{ + struct file *file; + struct inode *inode; + struct socket *sock; + struct sock *sk; +#if 0 + struct in_device *indev; +#endif + struct cipe *c0; + DEVTOCIPE(dev,c,-ENODEV); + + if (c->sock) + return -EBUSY; + if (!(file=fget(parm->fd))) + return(-EBADF); + inode = file->f_dentry->d_inode; + if (!inode || !inode->i_sock || !(sock=&inode->u.socket_i)) { + fput(file); + return(-ENOTSOCK); + } + if (sock->file != file) { + printk(KERN_ERR DEVNAME ": socki_lookup: socket file changed!\n"); + sock->file = file; + } + + fput(file); + if (sock->type!=SOCK_DGRAM) + return(-ESOCKTNOSUPPORT); + if (sock->ops->family!=AF_INET) + return(-EAFNOSUPPORT); + + sk=sock->sk; + if (sk->state!=TCP_ESTABLISHED) + return(-ENOTCONN); + if (((c0=(struct cipe *)sk->user_data)) && + (c0->magic==CIPE_MAGIC)) + return(-EBUSY); /* socket is already attached */ + + cipe_use_module(); + c->owner=current->pid; + c->sock=sk; + c->peeraddr=sk->daddr; + c->peerport=sk->dport; + c->myaddr=sk->saddr; + if (c->flags&CIPF_MAY_DYNIP) + sk->rcv_saddr=0; + c->myport=htons(sk->num); + /* Disconnect socket, we might receive from somewhere else */ + sk->daddr=0; + sk->dport=0; + + /* Fill an otherwise unused field in the sock struct with this info. + This field is conveniently named and the kernel uses it only for RPC. */ + sk->user_data=c; + sk->no_check=(c->flags&CIPF_DO_CSUM) ? 0 : 1; + + /* Set up new socket operations */ + c->udp_prot=sk->prot; + c->cipe_proto=*sk->prot; + c->cipe_proto.close=cipe_sock_close; + c->cipe_proto.sendmsg=cipe_sendmsg; + c->cipe_proto.recvmsg=cipe_recvmsg; + sk->prot=&c->cipe_proto; + +#if 0 + /* (Try to) Set our dummy hardware address from the IP address. */ + /* This does not work, because the IP address is set + _after_ the attach... */ + if ((indev=dev->ip_ptr)) { + struct in_ifaddr **ifap = NULL; + struct in_ifaddr *ifa = NULL; + for (ifap=&indev->ifa_list; (ifa=*ifap) != NULL; ifap=&ifa->ifa_next) + if (strcmp(dev->name, ifa->ifa_label) == 0) + break; + if (ifa) { + char *x=(char *)&ifa->ifa_local; + dev->dev_addr[3]=x[1]|0x80; + dev->dev_addr[4]=x[2]; + dev->dev_addr[5]=x[3]; + } + } +#endif + + return(0); +} + + +#else /* LINUX_21 */ + +#define sreturn(x) {sti(); return((x));} + +int cipe_attach(struct NET_DEVICE *dev, struct siocsifcipatt *parm) +{ + struct file *file; + struct inode *inode; + struct socket *sock; + struct sock *sk; + int fd=parm->fd; + struct cipe *c0; + DEVTOCIPE(dev,c,-ENODEV); + cli(); + if (c->sock) + sreturn(-EBUSY); + + /* Find the socket (from net/socket.c) */ + if (fd < 0 || fd >= NR_OPEN || !(file = current->files->fd[fd])) + sreturn(-EBADF); + inode = file->f_inode; + if (!inode || !inode->i_sock) + sreturn(-ENOTSOCK); + sock=&inode->u.socket_i; + if (sock->type!=SOCK_DGRAM) + sreturn(-ESOCKTNOSUPPORT); + if (sock->ops->family!=AF_INET) + sreturn(-EAFNOSUPPORT); + sk=(struct sock *)sock->data; + if (sk->state!=TCP_ESTABLISHED) + sreturn(-ENOTCONN); + if (((c0=(struct cipe *)sk->protinfo.af_packet.bound_dev)) && + (c0->magic==CIPE_MAGIC)) + sreturn(-EBUSY); /* socket is already attached */ + + cipe_use_module(); + c->owner=current->pid; + c->sock=sk; + c->peeraddr=sk->daddr; + c->peerport=sk->dummy_th.dest; + c->myaddr=sk->saddr; + if (c->flags&CIPF_MAY_DYNIP) + sk->rcv_saddr=0; + c->myport=sk->dummy_th.source; + /* Disconnect socket, we might receive from somewhere else */ + sk->daddr=0; + sk->dummy_th.dest=0; + + /* Set up new socket operations */ + c->udp_prot=sk->prot; + c->cipe_proto=*sk->prot; + c->cipe_proto.close=cipe_sock_close; + c->cipe_proto.sendmsg=cipe_sendmsg; + c->cipe_proto.recvmsg=cipe_recvmsg; + sk->prot=&c->cipe_proto; + + /* Fill an otherwise unused field in the sock struct with this info. + Actually, this is very similar to a packet socket! + The ugly cast saves us one deref in the actual ops */ + sk->protinfo.af_packet.bound_dev=(struct NET_DEVICE *)c; + sk->no_check=(c->flags&CIPF_DO_CSUM) ? 0 : 1; + + sti(); + return 0; +} + +#endif + + +/* Build and enqueue a fake UDP packet to receive. + Note that these are neither encrypted nor SOCKSed. +*/ +void cipe_fakenkey(struct cipe *c, char typ) +{ + int len=sizeof(struct udphdr)+KEYXCHGBLKMIN; + struct sk_buff *skb=alloc_skb(len, GFP_ATOMIC); + + if (!skb) { + printk(KERN_WARNING "%s: cipe_fakenkey: out of memory\n", + c->dev->name); + return; /* not much we can do */ + } + + dprintk(DEB_KXC, (KERN_INFO "%s: fake kxc block typ=%d\n", + c->dev->name, typ)); + + skb->sk=NULL; + skb->dev=c->dev; + + skb->h.uh=(struct udphdr *)skb->data; + skb->len=len; +#ifdef LINUX_21 + skb->nh.iph=NULL; +#else + saddr(skb)=c->myaddr; + daddr(skb)=c->peeraddr; + skb->free=1; /* Discard after use */ + skb->ip_hdr=NULL; +#endif + skb->h.uh->source=0; /* mark as KXC packet */ + skb->h.uh->dest=c->myport; + len-=sizeof(struct udphdr); + skb->h.uh->len=htons(len); + skb->h.uh->check=0; + skb->mac.raw=skb->data; /* no hardware header */ + + /* All those contortions for just one byte of payload data. + Since we generate only NK_RREQ and NK_REQ it's effectively + one _bit_... */ + skb->data[sizeof(struct udphdr)]=typ; + (*(__u32 *)(skb->data+sizeof(struct udphdr)+KEYXCHGTSPOS))= + htonl(CURRENT_TIME); /* even need timestamp */ + + if (sock_queue_rcv_skb(c->sock, skb)<0) { + printk(KERN_WARNING "%s: cipe_fakenkey: enqueuing failed\n", + c->dev->name); + kfreeskb(skb, FREE_WRITE); + } +} --- linux-2.4.21/drivers/addon/cipe3/version.h.CIPE3 Fri Jul 25 15:02:11 2003 +++ linux-2.4.21/drivers/addon/cipe3/version.h Fri Jul 25 15:07:36 2003 @@ -0,0 +1,5 @@ +#define VERSION "1.5.4" +#define ProtocolVersion 3 +#undef Crypto_IDEA +#define Crypto_Blowfish 1 +#undef NO_DYNDEV -------------- next part -------------- --- linux-2.4.21/drivers/addon/cipe4/Makefile.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/Makefile Fri Jul 25 15:12:33 2003 @@ -0,0 +1,23 @@ +# -*-Makefile-*- template for the CIPE kernel module and driver. +# Copyright 1996 Olaf Titz +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License +# as published by the Free Software Foundation; either version +# 2 of the License, or (at your option) any later version. + +O_TARGET := cipdb.o + +obj-y := module.o device.o sock.o output.o encaps.o crc32.o bf.o +obj-m := $(O_TARGET) + +ifeq ($(ARCH),i386) + obj-y += bf-i386.o +endif + +include $(TOPDIR)/Rules.make + +ifeq ($(ARCH),i386) +bf-i386.o: bf-i386.S + $(CC) $(CFLAGS) $(EXTRA_CFLAGS) -c -o $@ $< +endif --- linux-2.4.21/drivers/addon/cipe4/ciped.h.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/ciped.h Fri Jul 25 15:12:33 2003 @@ -0,0 +1,43 @@ +/* + CIPE - encrypted IP over UDP tunneling + + ciped.h - prototypes for user level routines + + Copyright 1997 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: ciped.h,v 1.6 2000/12/16 17:49:06 olaf Exp $ */ + +#include +#include +#include "cipe.h" +#include "options.h" + +/* options.c */ +struct options { + const char * const oname; + const char otyp; + union { + int ovint; + char *ovstr; + struct sockaddr_in *ovsaddr; + } ov; +}; +extern struct options opts[]; +#define Tbool 0 +#define Tint 1 +#define Tstr 2 +#define Taddr 3 +#define Tuaddr 4 +#define Ttaddr 5 +#define Tsecret 6 + +#define OI(x) (opts[O##x].ov.ovint) +#define OS(x) (opts[O##x].ov.ovstr) +#define OA(x) (opts[O##x].ov.ovsaddr) +#define OAaddr(x) (OA(x)->sin_addr) +#define OAport(x) (OA(x)->sin_port) --- linux-2.4.21/drivers/addon/cipe4/cipe.h.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/cipe.h Fri Jul 25 15:12:33 2003 @@ -0,0 +1,426 @@ +/* + CIPE - encrypted IP over UDP tunneling + + cipe.h - contains definitions, includes etc. common to all modules + + Copyright 1996-2000 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: cipe.h,v 1.38.2.2 2002/06/28 23:38:53 olaf Exp $ */ + +#ifndef _CIPE_H_ +#define _CIPE_H_ + +#include "crypto.h" +#ifdef __KERNEL__ +#include +#else +#include +#endif + +/*** The kernel/user IOCTL interface ***/ + +/* ioctls for setup and key exchange */ +/* #define SIOCxIFCIPxxx (SIOCDEVPRIVATE+x) */ +/* All ioctls are passed a struct ifreq which contains the + device name in ifr_name and a pointer to the actual control struct + in ifr_data. */ + +#if 0 +/* Get interface parameters. Currently unused */ +#define SIOCGIFCIPPAR (SIOCDEVPRIVATE+0) +struct siocgifcippar { + unsigned long magic; + /* SOCKS5 relayer */ + unsigned long sockshost; + unsigned short socksport; + /* Timeouts (in seconds) */ + int tmo_keyxchg; + int tmo_keylife; + /* Flags */ + int flags; + int cttl; +}; +#endif + +/* Set interface parameters. */ +#define SIOCSIFCIPPAR (SIOCDEVPRIVATE+1) +struct siocsifcippar { + unsigned long magic; + /* SOCKS5 relayer */ + unsigned long sockshost; + unsigned short socksport; + /* Timeouts (in seconds) */ + int tmo_keyxchg; + int tmo_keylife; + /* Flags */ + int flags; + int cttl; +}; + +/* Set a key. */ +#define SIOCSIFCIPKEY (SIOCDEVPRIVATE+2) +#define KEY_STATIC 1 +#define KEY_SEND 2 +#define KEY_RECV 3 +#define KEY_INVAL 8 +#define KEY_MAXLEN 32 +struct siocsifcipkey { + unsigned long magic; + int which; + char thekey[KEY_MAXLEN]; + int keylen; +}; + +/* Attach a socket. */ +#define SIOCSIFCIPATT (SIOCDEVPRIVATE+3) +struct siocsifcipatt { + unsigned long magic; + int fd; +}; + +/* Allocate/deallocate a device. */ +#define SIOCSIFCIPALL (SIOCDEVPRIVATE+4) +#define SIOCSIFCIPUNA (SIOCDEVPRIVATE+5) +struct siocsifcipall { + unsigned long magic; + int num; + char name[IFNAMSIZ]; +}; + +/* Flag values. */ +#define CIPF_MAY_CLEAR 0x0100 +#define CIPF_MAY_STKEY 0x0200 +#define CIPF_MAY_DYNIP 0x0400 +#define CIPF_DO_CSUM 0x0800 + +/*** Key exchange related definitions ***/ + +/* Minimum kxc block. */ +#define KEYXCHGBLKMIN 64 +/* Maximum kxc block, padded with random bytes */ +#define KEYXCHGBLKMAX (KEYXCHGBLKMIN+256) +/* Position of the timestamp */ +#define KEYXCHGTSPOS 56 +/* Type words. Only 4 are possible. */ +#define TW_DATA 0 +#define TW_NEWKEY 2 +#define TW_CTRL 4 +#define TW_RSVD2 6 +/* error indication, no valid type word */ +#define TW_ERROR 1 + +/* NEWKEY (key exchange mode 1) subtypes. */ +#define NK_RREQ 0 /* not used in protocol */ +#define NK_REQ 1 /* send me your new key */ +#define NK_IND 2 /* this is my new key */ +#define NK_ACK 3 /* i have your new key */ + +/* CTRL subtypes. By now sent in a TW_NEWKEY packet. */ +#define CT_DUMMY 0x70 /* ignore */ +#define CT_DEBUG 0x71 /* log */ +#define CT_PING 0x72 /* send PONG */ +#define CT_PONG 0x73 +#define CT_KILL 0x74 /* exit */ +#define CT_CONFREQ 0x75 /* log, send CONF */ +#define CT_CONF 0x76 /* log */ + +/*** Kernel-module internal stuff ***/ + +#ifdef __KERNEL__ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#ifndef KERNEL_VERSION +#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) +#endif +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,1,0) +#define LINUX_21 +#endif +#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,0) +#define LINUX_23 +#endif +#if (__GNUC__ > 2 || (__GNUC__ == 2 && __GNUC_MINOR__ >= 91)) && defined(__i386__) +#define REGPARM /* __attribute__((regparm,3)) XX needs testing */ +#else +#define REGPARM +#endif + +#ifdef LINUX_21 +#ifndef SPIN_LOCK_UNLOCKED /* 2.2/2.4 incompat */ +#include +#endif +#endif + +#if 1 /* Lock tracing */ +#define DOLOCK(s) ({ printk(KERN_DEBUG DEVNAME ": " #s " at %s:%d\n", \ + __FILE__, __LINE__); s; }) +#else +#define DOLOCK(s) s +#endif + +#ifdef LINUX_23 +#define tasklist_LOCK() DOLOCK(read_lock(&tasklist_lock)) +#define tasklist_UNLOCK() DOLOCK(read_unlock(&tasklist_lock)) +#else +#define tasklist_LOCK() /* nop */ +#define tasklist_UNLOCK() /* nop */ +#endif + +#ifdef LINUX_21 +/* In 2.1 the ioctl operations are run under lock. Beware of deadlocks. */ +#define cipe_alloc_LOCK() 0 /* nop */ +#define cipe_alloc_UNLOCK() /* nop */ +#else +extern struct semaphore cipe_alloc_sem; +#define cipe_alloc_LOCK() DOLOCK(down_interruptible(&cipe_alloc_sem)) +#define cipe_alloc_UNLOCK() DOLOCK(up(&cipe_alloc_sem)) +#endif + +#ifdef LINUX_21 +#define FLEN "%d" +#else +#define FLEN "%ld" +#endif + +#ifdef LINUX_23 +#define rtnl_LOCK() DOLOCK(rtnl_lock()) +#define rtnl_UNLOCK() DOLOCK(rtnl_unlock()) +#else +#define rtnl_LOCK() /* nop */ +#define rtnl_UNLOCK() /* nop */ +#endif + +#ifdef LINUX_23 +#define NET_DEVICE net_device +#define DEV_STATS net_device_stats +#else +#define NET_DEVICE device +#define DEV_STATS enet_statistics +#endif + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,1,127) +#define timeout_t unsigned long +#else +#define timeout_t long +#endif + +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,3,99) +#define HAVE_DEVNAME_ARRAY +#endif + +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,4,17) +#define get_fast_time do_gettimeofday +#endif + +/* The header we add to each packet */ +#ifdef VER_ETH +#define cipehdrlen (sizeof(struct iphdr)+sizeof(struct udphdr)+blockSize+ETH_HLEN) +#else +#ifdef VER_SHORT +#define cipehdrlen (sizeof(struct iphdr)+sizeof(struct udphdr)) +#else +#define cipehdrlen (sizeof(struct iphdr)+sizeof(struct udphdr)+blockSize) +#endif +#endif +/* ...plus a real hardware header (common case) */ +#define cipexhdrl (cipehdrlen+((ETH_HLEN+15)&~15)) +/* max. padding at the end */ +#if ProtocolVersion >= 3 +#define cipefootlen 12 /* 7 bytes pad, 1 byte type, 4 bytes CRC */ +#else +#define cipefootlen 10 /* 8 bytes pad, 2 bytes CRC */ +#endif + +/* A CIPE device's parameter block */ + +#define CIPE_MAGIC (htonl(0x43495045)) +struct cipe { + __u32 magic; + struct NET_DEVICE *dev; + /* Set by user process */ + __u32 peeraddr; + __u32 myaddr; + __u16 peerport; + __u16 myport; + __u32 sockshost; + __u16 socksport; + short cttl; +#ifdef Crypto_IDEA + Key key_e, key_d, skey_e, rkey_d; +#endif +#ifdef Crypto_Blowfish + Key key, skey, rkey; + #define key_e key + #define key_d key + #define skey_e skey + #define rkey_d rkey +#endif + unsigned long tmo_keyxchg; + unsigned long tmo_keylife; + /* Internal */ + unsigned long timekx; + unsigned long timeskey; + unsigned long timerkey; + int cntskey; + int cntrkey; + struct sock *sock; + int flags; +#ifdef LINUX_21 + char recursion; +#endif + pid_t owner; + /* Statistics */ +#ifdef LINUX_21 + struct net_device_stats stat; +#else + struct enet_statistics stat; +#endif + /* Socket interface stuff */ + struct proto *udp_prot; + struct proto cipe_proto; +}; + +/* Flag values (internally used) */ +#define CIPF_HAVE_KEY 0x0001 +#define CIPF_HAVE_SKEY 0x0002 +#define CIPF_HAVE_RKEY 0x0004 +#define CIPF_MASK_INT 0x00FF +#define CIPF_MASK_EXT 0xFF00 + +#define MAXBLKS 32767 /* max # blocks to encrypt using one key */ + +/* Define, init and check a struct cipe * variable. */ +#define DEVTOCIPE(dev,c,err) \ + struct cipe *c = (struct cipe*)(dev->priv); \ + if (!c || c->magic!=CIPE_MAGIC) return err; + +/* Master control struct */ +struct cipe_ctrl { +#ifndef HAVE_DEVNAME_ARRAY + char name[IFNAMSIZ]; +#endif + struct cipe cipe; + struct NET_DEVICE dev; +}; + +extern struct cipe_ctrl **cipe_ctrls; +extern int cipe_maxdev; + +/* SOCKS5 encapsulation header */ +struct sockshdr { + char rsv[2]; + char frag; + char atyp; + __u32 dstaddr __attribute__((packed)); + __u16 dstport __attribute__((packed)); +}; + +#ifdef DEBUG +extern int cipe_debug; + +#if 0 +/* Lock around our printks, to avoid mixing up dumps. NOT for regular use. */ +extern spinlock_t cipe_printk_lock; +#define LOCK_PRINTK unsigned long flags; spin_lock_irqsave(&cipe_printk_lock, flags) +#define UNLOCK_PRINTK spin_unlock_irqrestore(&cipe_printk_lock, flags) +#else +#define LOCK_PRINTK /* nop */ +#define UNLOCK_PRINTK /* nop */ +#endif + +#define DEB_CALL 1 +#define DEB_INP 2 +#define DEB_OUT 4 +#define DEB_CRYPT 8 +#define DEB_KXC 16 +#define DEB_PKIN 32 +#define DEB_PKOU 64 +#define DEB_CHKP 128 + +#define dprintk(l,p) if(cipe_debug&l){LOCK_PRINTK; printk p; UNLOCK_PRINTK;} + +#else +#define dprintk(l,p) /* nop */ + +#endif /* DEBUG */ + +#if defined(DEBUG) && defined(LINUX_23) +#define __CHECKPOINT(F,L) printk(KERN_DEBUG "CHECKPOINT " F ":%d\n", L) +#define CHECKPOINT if (cipe_debug&DEB_CHKP){\ + LOCK_PRINTK; __CHECKPOINT(__FILE__,__LINE__); UNLOCK_PRINTK;\ + current->state=TASK_INTERRUPTIBLE; schedule_timeout(HZ/20); } +#else +#define CHECKPOINT /* nop */ +#endif + +static inline void nf_conntrack_null(struct sk_buff *skb) +{ +#ifdef CONFIG_NETFILTER + nf_conntrack_put(skb->nfct); + skb->nfct = NULL; +#ifdef CONFIG_NETFILTER_DEBUG + skb->nf_debug = 0; +#endif +#endif +} + +/* internal routines */ +/* module.c */ +extern void cipe_use_module(void); +extern void cipe_unuse_module(void); +extern int cipe_check_kernel(void); +/* device.c */ +extern void cipe_prnpad(unsigned char *buf, int len) REGPARM; +extern void cipe_close(struct cipe *c); +extern const char *cipe_ntoa(__u32 addr) REGPARM; +/* sock.c */ +extern int cipe_attach(struct NET_DEVICE *dev, struct siocsifcipatt *parm) + REGPARM; +extern void cipe_fakenkey(struct cipe *c, char typ) REGPARM; +/* output.c */ +#ifdef DEBUG +extern void cipe_dump_packet(char *title, struct sk_buff *skb, int dumpskb) + REGPARM; +#endif +extern int cipe_xmit(struct sk_buff *skb, struct NET_DEVICE *dev); +/* encaps.c */ +extern void cipe_encrypt(struct cipe *c, unsigned char *buf, + int *len, int typcode) REGPARM; +extern unsigned short cipe_decrypt(struct cipe *c, unsigned char *buf, + int *len) REGPARM; +#ifndef VER_SHORT +extern void cipe_cryptpad(unsigned char *buf) REGPARM; +extern void cipe_cryptpad_iv(unsigned char *buf) REGPARM; +#endif + +#endif /* __KERNEL__ */ + +#ifdef VER_CRC32 +/* crc32.c */ +extern unsigned long crc32(const unsigned char *s, unsigned int len); +#else +/* crc.c */ +extern unsigned short block_crc(unsigned char *d, int len); +#endif + +#define MIN(a,b) (((a)<(b))?(a):(b)) + +#ifndef DEVNAME +#define DEVNAME "cip" VERNAME CRNAME +#endif + +#endif /* _CIPE_H_ */ --- linux-2.4.21/drivers/addon/cipe4/config.h.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/config.h Fri Jul 25 15:12:33 2003 @@ -0,0 +1,54 @@ +/* config.h. Generated automatically by configure. */ +/* + CIPE - encrypted IP over UDP tunneling + + Copyright 1999 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ + +/* Config-dependent defines. Always include this first. */ +/* @api means the next line is used for determining the version magic */ + +/* Version of the CIPE package @api */ +#define VERSION "1.5.4" +#define VERSION_MAJ 1 + +/* Encapsulation protocol version @api */ +#define ProtocolVersion 4 + +/* Cipher algorithm selection @api */ +/* #undef Crypto_IDEA */ +/* Cipher algorithm selection @api */ +#define Crypto_Blowfish 1 + +/* Assembler module selection */ +/* #undef ASM_IDEA_Crypt */ +#ifdef __i386 +#define ASM_BF_Crypt 1 +#endif + +/* Debug code in kernel */ +#define DEBUG 1 + +/* Use old key parser */ +/* #undef BUG_COMPATIBLE */ + +/* Dynamic device allocation @api */ +/* #undef NO_DYNDEV */ + +/* Syslog facility */ +#define LOGFAC LOG_DAEMON + +/* Memory management functions (kernel version dependent?) */ +#define HAVE_MLOCK 1 +#define HAVE_MLOCKALL 1 + +/* End of autoconf options */ + +/* This tells the Blowfish module to omit unneeded code */ +#define BF_DONTNEED_BE + --- linux-2.4.21/drivers/addon/cipe4/crc32.c.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/crc32.c Fri Jul 25 15:12:33 2003 @@ -0,0 +1,111 @@ + /* ============================================================= */ + /* COPYRIGHT (C) 1986 Gary S. Brown. You may use this program, or */ + /* code or tables extracted from it, as desired without restriction. */ + /* */ + /* First, the polynomial itself and its table of feedback terms. The */ + /* polynomial is */ + /* X^32+X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0 */ + /* */ + /* Note that we take it "backwards" and put the highest-order term in */ + /* the lowest-order bit. The X^32 term is "implied"; the LSB is the */ + /* X^31 term, etc. The X^0 term (usually shown as "+1") results in */ + /* the MSB being 1. */ + /* */ + /* Note that the usual hardware shift register implementation, which */ + /* is what we're using (we're merely optimizing it by doing eight-bit */ + /* chunks at a time) shifts bits into the lowest-order term. In our */ + /* implementation, that means shifting towards the right. Why do we */ + /* do it this way? Because the calculated CRC must be transmitted in */ + /* order from highest-order term to lowest-order term. UARTs transmit */ + /* characters in order from LSB to MSB. By storing the CRC this way, */ + /* we hand it to the UART in the order low-byte to high-byte; the UART */ + /* sends each low-bit to hight-bit; and the result is transmission bit */ + /* by bit from highest- to lowest-order term without requiring any bit */ + /* shuffling on our part. Reception works similarly. */ + /* */ + /* The feedback terms table consists of 256, 32-bit entries. Notes: */ + /* */ + /* The table can be generated at runtime if desired; code to do so */ + /* is shown later. It might not be obvious, but the feedback */ + /* terms simply represent the results of eight shift/xor opera- */ + /* tions for all combinations of data and CRC register values. */ + /* */ + /* The values must be right-shifted by eight bits by the "updcrc" */ + /* logic; the shift must be unsigned (bring in zeroes). On some */ + /* hardware you could probably optimize the shift in assembler by */ + /* using byte-swap instructions. */ + /* polynomial $edb88320 */ + /* */ + /* -------------------------------------------------------------------- */ + +static unsigned long crc32_tab[] = { + 0x00000000L, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L, + 0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L, + 0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L, + 0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL, + 0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L, + 0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L, + 0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L, + 0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL, + 0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L, + 0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL, + 0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L, + 0xb8bda50fL, 0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L, + 0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, 0x76dc4190L, + 0x01db7106L, 0x98d220bcL, 0xefd5102aL, 0x71b18589L, 0x06b6b51fL, + 0x9fbfe4a5L, 0xe8b8d433L, 0x7807c9a2L, 0x0f00f934L, 0x9609a88eL, + 0xe10e9818L, 0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L, + 0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, 0x6c0695edL, + 0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, 0x65b0d9c6L, 0x12b7e950L, + 0x8bbeb8eaL, 0xfcb9887cL, 0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L, + 0xfbd44c65L, 0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L, + 0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, 0x4369e96aL, + 0x346ed9fcL, 0xad678846L, 0xda60b8d0L, 0x44042d73L, 0x33031de5L, + 0xaa0a4c5fL, 0xdd0d7cc9L, 0x5005713cL, 0x270241aaL, 0xbe0b1010L, + 0xc90c2086L, 0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL, + 0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, 0x59b33d17L, + 0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, 0xedb88320L, 0x9abfb3b6L, + 0x03b6e20cL, 0x74b1d29aL, 0xead54739L, 0x9dd277afL, 0x04db2615L, + 0x73dc1683L, 0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L, + 0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, 0xf00f9344L, + 0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, 0xf762575dL, 0x806567cbL, + 0x196c3671L, 0x6e6b06e7L, 0xfed41b76L, 0x89d32be0L, 0x10da7a5aL, + 0x67dd4accL, 0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L, + 0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, 0xd1bb67f1L, + 0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, 0xd80d2bdaL, 0xaf0a1b4cL, + 0x36034af6L, 0x41047a60L, 0xdf60efc3L, 0xa867df55L, 0x316e8eefL, + 0x4669be79L, 0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0x5268e236L, + 0xcc0c7795L, 0xbb0b4703L, 0x220216b9L, 0x5505262fL, 0xc5ba3bbeL, + 0xb2bd0b28L, 0x2bb45a92L, 0x5cb36a04L, 0xc2d7ffa7L, 0xb5d0cf31L, + 0x2cd99e8bL, 0x5bdeae1dL, 0x9b64c2b0L, 0xec63f226L, 0x756aa39cL, + 0x026d930aL, 0x9c0906a9L, 0xeb0e363fL, 0x72076785L, 0x05005713L, + 0x95bf4a82L, 0xe2b87a14L, 0x7bb12baeL, 0x0cb61b38L, 0x92d28e9bL, + 0xe5d5be0dL, 0x7cdcefb7L, 0x0bdbdf21L, 0x86d3d2d4L, 0xf1d4e242L, + 0x68ddb3f8L, 0x1fda836eL, 0x81be16cdL, 0xf6b9265bL, 0x6fb077e1L, + 0x18b74777L, 0x88085ae6L, 0xff0f6a70L, 0x66063bcaL, 0x11010b5cL, + 0x8f659effL, 0xf862ae69L, 0x616bffd3L, 0x166ccf45L, 0xa00ae278L, + 0xd70dd2eeL, 0x4e048354L, 0x3903b3c2L, 0xa7672661L, 0xd06016f7L, + 0x4969474dL, 0x3e6e77dbL, 0xaed16a4aL, 0xd9d65adcL, 0x40df0b66L, + 0x37d83bf0L, 0xa9bcae53L, 0xdebb9ec5L, 0x47b2cf7fL, 0x30b5ffe9L, + 0xbdbdf21cL, 0xcabac28aL, 0x53b39330L, 0x24b4a3a6L, 0xbad03605L, + 0xcdd70693L, 0x54de5729L, 0x23d967bfL, 0xb3667a2eL, 0xc4614ab8L, + 0x5d681b02L, 0x2a6f2b94L, 0xb40bbe37L, 0xc30c8ea1L, 0x5a05df1bL, + 0x2d02ef8dL + }; + +/* Return a 32-bit CRC of the contents of the buffer. */ + +unsigned long crc32(const unsigned char *s, unsigned int len) +{ + unsigned int i; + unsigned long crc32val; + + crc32val = 0; + for (i = 0; i < len; i ++) + { + crc32val = + crc32_tab[(crc32val ^ s[i]) & 0xff] ^ + (crc32val >> 8); + } + return crc32val; +} --- linux-2.4.21/drivers/addon/cipe4/crypto.h.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/crypto.h Fri Jul 25 15:12:33 2003 @@ -0,0 +1,100 @@ +/* + CIPE - encrypted IP over UDP tunneling + + crypto.h - configuration of the crypto algorithm + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: crypto.h,v 1.8 2000/09/13 21:46:41 olaf Exp $ */ + +#ifndef _CRYPTO_H_ +#define _CRYPTO_H_ + +#include "version.h" + +typedef unsigned long part; +/* the longest integer so that sizeof(part) divides blockSize. + Used only for optimizing block-copy and block-XOR operations. */ + +#if ProtocolVersion == 1 + +#ifdef OLDNAMES +#define VERNAME "1" +#else +#define VERNAME "a" +#endif +#define VER_BACK /* encryption progress backwards */ +#define VER_SHORT /* no IV in packet */ + +#elif ProtocolVersion == 2 + +#ifdef OLDNAMES +#define VERNAME "2" +#else +#define VERNAME "b" +#endif + +#elif ProtocolVersion == 3 + +#ifdef OLDNAMES +#define VERNAME "3" +#else +#define VERNAME "c" +#endif +#define VER_CRC32 /* checksums are 32bit */ + +#elif ProtocolVersion == 4 + +#ifdef OLDNAMES +#define VERNAME "4" +#else +#define VERNAME "d" +#endif +#define VER_CRC32 +#define VER_ETH + +#else +#error "Must specify correct ProtocolVersion" +#endif + + +#ifdef Crypto_IDEA +#define CRYPTO "IDEA" +#define CRNAME "i" +#define CRNAMEC 'i' +#define CRNUM 0 +#include "idea0.h" +#define Key Idea_Key +#define keySize Idea_keySize +#define UserKey Idea_UserKey +#define userKeySize Idea_userKeySize +#define ExpandUserKey Idea_ExpandUserKey +#define InvertKey Idea_InvertKey +#define blockSize Idea_dataSize + +#else +#ifdef Crypto_Blowfish +#define CRYPTO "Blowfish" +#define CRNAME "b" +#define CRNAMEC 'b' +#define CRNUM 1 +#include "bf.h" +#define Key Blowfish_Key +#define keySize sizeof(Blowfish_Key) +#define UserKey Blowfish_UserKey +#define userKeySize 16 /* arbitrary, but matches IDEA */ +#define ExpandUserKey(u,k) Blowfish_ExpandUserKey(u,userKeySize,k) +#define InvertKey(x,y) /* noop */ +#define blockSize sizeof(Blowfish_Data) + +#else +#error "Must specify Crypto_IDEA or Crypto_Blowfish" +#endif +#endif + +#endif --- linux-2.4.21/drivers/addon/cipe4/encaps.c.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/encaps.c Fri Jul 25 15:12:33 2003 @@ -0,0 +1,313 @@ +/* + CIPE - encrypted IP over UDP tunneling + + encaps.c - do encryption + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: encaps.c,v 1.18 2000/09/13 21:46:41 olaf Exp $ */ + +#include "cipe.h" +#include +#include + +static inline void xorbuf(part *dst, part *src) +{ + int i; + for (i=0; i0) { + memcpy(r, p, blockSize); + ecb_dec(p, p, key); + xorbuf(p, q); + s=q; q=r; r=s; + p-=blockSize/sizeof(part); + } + } else { + while (i-->0) { + xorbuf(p, q); + ecb_enc(p, p, key); + q=p; + p-=blockSize/sizeof(part); + } + } +} + +#else + +/* + CBC encryption/decryption routines. + Note: the block to encrypt includes the IV, while decryption swallows + the IV. Length is always including IV. +*/ + +#define partinc(p) ((p)+blockSize/sizeof(part)) + +static void cbc_enc(unsigned char *msg, int len, Key * const key) +{ + part *p=(part *)msg; + int i=len/blockSize; + +#if 0 + dprintk(DEB_CRYPT, (KERN_DEBUG "cbc_enc: %08x %08x ", + *((__u32*)partinc(msg)), *(__u32*)key)); +#endif + while (--i>0) { + xorbuf(partinc(p), p); + p=partinc(p); + ecb_enc(p, p, *key); + } +#if 0 + dprintk(DEB_CRYPT, ("%08x\n", *((__u32*)partinc(msg)))); +#endif +} + +static void cbc_dec(unsigned char *msg, int len, Key * const key) +{ + part *p=(part *)msg; + int i=len/blockSize; + part r[blockSize/sizeof(part)]; + +#if 0 + dprintk(DEB_CRYPT, (KERN_DEBUG "cbc_dec: %08x %08x ", + *(__u32*)msg, *(__u32*)key)); +#endif + while (--i>0) { + ecb_dec(partinc(p), r, *key); + xorbuf(p, r); + p=partinc(p); + } +#if 0 + dprintk(DEB_CRYPT, ("%08x\n", *(__u32*)msg)); +#endif +} + +#endif + +#ifndef VER_SHORT +/* Fill a block of length blockSize with strong random numbers. + Used for generating IVs. */ +void cipe_cryptpad(unsigned char *buf) +{ + static int padcnt=MAXBLKS; + static Key padkey; + + if (++padcnt>MAXBLKS) { + /* make a new random key */ + UserKey k; + dprintk(DEB_CRYPT, (KERN_INFO "%s: re-keying cryptpad\n", DEVNAME)); + cipe_prnpad((unsigned char*)k, sizeof(UserKey)); + ExpandUserKey(k, padkey); + padcnt=0; + } + *(int *)(buf)=padcnt; + cipe_prnpad(buf+sizeof(int), blockSize-sizeof(int)); + ecb_enc((part*)buf, (part*)buf, padkey); +} + +void cipe_cryptpad_iv(unsigned char *buf) +{ + int i=5; + do { + cipe_cryptpad(buf); + if (*((__u32 *)buf) & htonl(0x7FFFFFFF)) + break; + } while (i-->0); + if (!i) + printk(KERN_CRIT "cipe_cryptpad_iv failed"); +} +#endif + + +void cipe_checkskey(struct cipe *c) +{ + if ((++c->cntskey>MAXBLKS) || (jiffies>c->timeskey)) { + /* make the control process send an NK_IND */ + cipe_fakenkey(c, NK_REQ); + c->timeskey=jiffies+c->tmo_keyxchg; + if (c->cntskey>MAXBLKS) + c->cntskey-=1000; + } +} + +void cipe_checkrkey(struct cipe *c) +{ + if ((c->flags&CIPF_HAVE_RKEY) && + ((++c->cntrkey>MAXBLKS*2) || (jiffies>c->timerkey))) { + /* make the control process send an NK_REQ */ + cipe_fakenkey(c, NK_RREQ); + c->flags&=~CIPF_HAVE_RKEY; + c->timerkey=jiffies+c->tmo_keyxchg; + if (c->cntrkey>MAXBLKS*2) + c->cntrkey-=1000; + } +} + +void cipe_nodynkey(struct cipe *c) +{ + if (jiffies>c->timerkey) { + /* make the control process send an NK_REQ */ + cipe_fakenkey(c, NK_RREQ); + c->timerkey=jiffies+c->tmo_keyxchg; + } + dprintk(DEB_CRYPT, (KERN_INFO "%s: missing dynamic key\n", + c->dev->name)); +} + +#if ProtocolVersion >= 3 + +/* Encryption/decryption version 3 */ + +void cipe_encrypt(struct cipe *c, unsigned char *buf, int *len, int typ) +{ + unsigned char p=7-(((*len)+4)&7); + /* merge key flag in IV */ + *buf&=0x7F; + if (c->flags&CIPF_HAVE_SKEY) + *buf|=0x80; + /* pad */ + cipe_prnpad(buf+(*len), p); + (*len)+=p+5; + /* set type and crc */ + *(buf+(*len)-5)=typ|(p<<4); + *((unsigned long *)(buf+(*len)-4))= + htonl(crc32(buf+blockSize, (*len)-blockSize-4)); + + dprintk(DEB_CRYPT, (KERN_INFO "%s: encrypt typ %d pad %d len %d\n", + c->dev->name, typ, p, *len)); + cbc_enc(buf, *len, c->flags&CIPF_HAVE_SKEY ? &c->skey_e : &c->key_e); + cipe_checkskey(c); +} + +unsigned short cipe_decrypt(struct cipe *c, unsigned char *buf, int *len) +{ + unsigned char p; + + if (((*buf)&0x80) && !(c->flags&CIPF_HAVE_RKEY)) { + cipe_nodynkey(c); + return TW_ERROR; /* can't decrypt - no valid key */ + } + cbc_dec(buf, *len, ((*buf)&0x80) ? &c->rkey_d : &c->key_d); + (*len)-=blockSize; + if (*((unsigned long *)(buf+(*len)-4)) != htonl(crc32(buf, (*len)-4))) { + dprintk(DEB_CRYPT, (KERN_INFO "%s: decrypt CRC error\n", + c->dev->name)); + return TW_ERROR; + } + p=*(buf+(*len)-5); + (*len)-=(p>>4)&7; + cipe_checkrkey(c); +#define CTLBITS 0x06 + dprintk(DEB_CRYPT, (KERN_INFO "%s: decrypt len=%d pad=%d typ=%02X\n", + c->dev->name, (*len), (p>>4)&7, p&CTLBITS)); + return (p&CTLBITS); +} + +#else + +/* Encryption/decryption version 1 and 2 */ + +void cipe_encrypt(struct cipe *c, unsigned char *buf, int *len, int typ) +{ + unsigned short x; + unsigned char p; + + p=8-((*len)&7); + cipe_prnpad(buf+(*len), p); + (*len)+=p; + +#ifdef VER_SHORT + x=((block_crc(buf, *len)&0xFFFE)^((p&7)<<8)^typ)|(c->haveskey); +#else + x=((block_crc(buf+blockSize, (*len)-blockSize)&0xFFFE) + ^((p&7)<<8)^typ)|(c->haveskey); +#endif +#ifdef VER_BACK + cbc_b(buf, *len, c->haveskey ? &c->skey_e : &c->key_e, 0); +#else + cbc_enc(buf, *len, c->haveskey ? &c->skey_e : &c->key_e); +#endif + + dprintk(DEB_CRYPT, (KERN_INFO "%s: encrypt pad %d\n", c->dev->name, p)); + buf[(*len)++]=x>>8; + buf[(*len)++]=x&255; + cipe_checkskey(c); +} + +unsigned short cipe_decrypt(struct cipe *c, unsigned char *buf, int *len) +{ + unsigned short x=(buf[(*len)-1])+(buf[(*len)-2]<<8); + unsigned char p; + + if ((x&1) && !(c->haverkey)) { + cipe_nodynkey(c); + return TW_ERROR; /* can't decrypt - no valid key */ + } + (*len)-=2; + if (*len<9 +#ifndef VER_SHORT + +blockSize +#endif + ) + return TW_ERROR; /* short packet */ + +#ifdef VER_BACK + cbc_b(buf, *len, (x&1) ? &c->rkey_d : &c->key_d, 1); +#else + cbc_dec(buf, *len, (x&1) ? &c->rkey_d : &c->key_d); +#endif +#ifndef VER_SHORT + (*len)-=blockSize; +#endif + + x^=block_crc(buf, *len); + p=(x>>8)&7; if (!p) p=8; + (*len)-=p; + cipe_checkrkey(c); + +#define CTLBITS 0xF8FE + dprintk(DEB_CRYPT, (KERN_INFO "%s: decrypt pad %d typ %04X\n", + c->dev->name, (x>>8)&7, x&CTLBITS)); + return (x&CTLBITS); /* delete the control bits */ +} + +#endif --- linux-2.4.21/drivers/addon/cipe4/ioctl.h.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/ioctl.h Fri Jul 25 15:12:33 2003 @@ -0,0 +1,24 @@ +/* + CIPE - encrypted IP over UDP tunneling + + ioctl.h - prototype for the ioctl interface, user part + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: ioctl.h,v 1.3 2000/03/27 17:38:23 olaf Exp $ */ + +#include "cipe.h" + +#ifdef SIOCGIFCIPPAR +extern int ioctl_getpar(int fd, char *ifname, struct siocgifcippar *sio); +#endif +extern int ioctl_setpar(int fd, char *ifname, struct siocsifcippar *sio); +extern int ioctl_setkey(int fd, char *ifname, struct siocsifcipkey *sio); +extern int ioctl_attach(int fd, char *ifname, struct siocsifcipatt *sio); +extern int ioctl_alloc(int fd, char *ifname, struct siocsifcipall *sio); +extern int ioctl_unalloc(int fd, char *ifname, struct siocsifcipall *sio); --- linux-2.4.21/drivers/addon/cipe4/module.c.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/module.c Fri Jul 25 15:12:33 2003 @@ -0,0 +1,89 @@ +/* + CIPE - encrypted IP over UDP tunneling + + module.c - kernel module interface stuff + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: module.c,v 1.5.2.1 2002/05/30 11:49:17 olaf Exp $ */ + +#include "cipe.h" +#include +#include + +/* We put this all here so that none of the other source files needs + to include , which could lead to collisions. */ + +#ifdef LINUX_21 +MODULE_AUTHOR("Olaf Titz "); +MODULE_DESCRIPTION("Encrypting IP-over-UDP tunnel"); +#ifdef MODULE_LICENSE +MODULE_LICENSE("GPL"); +#endif +MODULE_SUPPORTED_DEVICE(DEVNAME); +MODULE_PARM(cipe_maxdev,"i"); +MODULE_PARM_DESC(cipe_maxdev,"Maximum device number supported"); +#ifdef DEBUG +MODULE_PARM(cipe_debug,"i"); +MODULE_PARM_DESC(cipe_debug,"Debugging level"); +#endif +#endif + +void cipe_use_module(void) +{ + MOD_INC_USE_COUNT; +} + +void cipe_unuse_module(void) +{ + MOD_DEC_USE_COUNT; +} + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,0,30) +/* older kernel not always exported this */ + +int bad_user_access_length(void) +{ + panic("bad_user_access_length in " DEVNAME); +} + +#endif + +/* HACK: sanity check on SMP/non-SMP. + Is this really necessary? */ +int cipe_check_kernel(void) +{ + int s=0; + const char *p=system_utsname.version; + while (p[0] && p[1] && p[2]) { + if (p[0]=='S' && p[1]=='M' && p[2]=='P') { + s=1; + break; + } + ++p; + } + if ( +#ifdef __SMP__ + ! +#endif + s) { + printk(KERN_ERR + DEVNAME ": driver (" +#ifndef __SMP__ + "not " +#endif + "SMP) " + "mismatches kernel (" +#ifdef __SMP__ + "not " +#endif + "SMP)\n"); + return -EINVAL; + } + return 0; +} --- linux-2.4.21/drivers/addon/cipe4/options.h.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/options.h Fri Jul 25 15:12:33 2003 @@ -0,0 +1,29 @@ +/* File generated by genoptions.pl, do not edit */ + +#define Odevice 0 +#define Odebug 1 +#define Oipaddr 2 +#define Optpaddr 3 +#define Omask 4 +#define Obcast 5 +#define Omtu 6 +#define Ometric 7 +#define Octtl 8 +#define Ome 9 +#define Opeer 10 +#define Okey 11 +#define Onokey 12 +#define Osocks 13 +#define Otokxc 14 +#define Otokey 15 +#define Oipup 16 +#define Oipdown 17 +#define Oarg 18 +#define Omaxerr 19 +#define Otokxts 20 +#define Oping 21 +#define Otoping 22 +#define Odynip 23 +#define Ohwaddr 24 +#define Oifconfig 25 +#define Ochecksum 26 --- linux-2.4.21/drivers/addon/cipe4/output.c.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/output.c Fri Jul 25 15:12:33 2003 @@ -0,0 +1,621 @@ +/* + CIPE - encrypted IP over UDP tunneling + + output.c - the sending part of the CIPE device + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: output.c,v 1.40.2.2 2002/06/28 23:38:53 olaf Exp $ */ + +#include "cipe.h" + +#include +#include +#include +#include +#include +#include +#ifdef LINUX_24 +#include +#include +#endif + +#ifdef DEBUG + +#include "../lib/hexdump.c" + +void cipe_dump_packet(char *title, struct sk_buff *skb, int dumpskb) +{ + LOCK_PRINTK; + if (dumpskb) { + printk(KERN_DEBUG "SKB (%s):\n", skb->dev?skb->dev->name:""); + cipe_hexdump((unsigned char *)skb, sizeof(*skb)); + } + printk(KERN_DEBUG + "%s: packet len=" FLEN " dev=%s\n", + title, skb->len, skb->dev?skb->dev->name:""); + cipe_hexdump((unsigned char *)skb->data, skb->tail-skb->data); + UNLOCK_PRINTK; +} +#endif + +#ifdef LINUX_21 + +/* An adapted version of Linux 2.1 net/ipv4/ipip.c output routine. */ + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,37) +#define ip_ident(h,d) (h)->id=htons(ip_id_count++) +#else +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,4) +#define ip_ident(h,d) ip_select_ident(h,d) +#else +#define ip_ident(h,d) ip_select_ident(h,d,NULL) +#endif +#endif + +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,36) +/* this is not exactly the newer kernel's routine, it just does what we need */ +struct sk_buff *skb_copy_expand(struct sk_buff *skb, int max_headroom, + int max_tailroom, int gfp) +{ + struct sk_buff *n=alloc_skb(skb->len+max_headroom+max_tailroom, gfp); + if (n) { + skb_reserve(n, max_headroom); + skb_put(n,skb->len); + memcpy(n->data,skb->data,skb->len); + n->priority=skb->priority; + n->protocol=skb->protocol; + n->dev=skb->dev; + n->dst=dst_clone(skb->dst); + memcpy(n->cb, skb->cb, sizeof(skb->cb)); + n->used=skb->used; + n->is_clone=0; + atomic_set(&n->users, 1); + n->pkt_type=skb->pkt_type; + n->stamp=skb->stamp; + n->security=skb->security; +#ifdef CONFIG_IP_FIREWALL + n->fwmark = skb->fwmark; +#endif + } + return n; +} +#endif + +int cipe_xmit(struct sk_buff *skb, struct NET_DEVICE *dev) +{ + struct cipe *tunnel = (struct cipe*)(dev->priv); + struct rtable *rt = NULL; /* Route to the other host */ + struct NET_DEVICE *tdev; /* Device to other host */ + struct iphdr *old_iph; + u8 tos = 0; + u16 df = 0; + u8 ttl; + + struct iphdr *iph; /* Our new IP header */ + struct udphdr *udph; + int max_headroom; /* The extra header space needed */ + int max_tailroom; + u32 dst = tunnel->peeraddr; + int mtu; + int length = skb->len; + + dprintk(DEB_OUT, (KERN_INFO "%s: cipe_xmit len=%d\n", dev->name, + length)); + if (tunnel->magic!=CIPE_MAGIC) { + printk(KERN_ERR DEVNAME + ": cipe_xmit called with wrong struct\n"); + return 0; + } +#ifdef DEBUG + if (cipe_debug&DEB_PKOU) + cipe_dump_packet("original", skb, 1); +#endif +#ifdef VER_ETH + /* A packet can contain anything. If sending from a bridge, + the header pointers are invalid. So compute our own. */ + old_iph = (skb->protocol==htons(ETH_P_IP)) + ? (struct iphdr*)(skb->data+ETH_HLEN) + : NULL; +#else + old_iph = skb->nh.iph; /* we get only proper IP packets */ +#endif + if (old_iph) { + int ilen = ntohs(old_iph->tot_len) +#ifdef VER_ETH + +ETH_HLEN +#endif + ; + if (length!=ilen) { + printk(KERN_ERR "%s: cipe_xmit packet length problem %d/%d\n", + dev->name, length, ilen); + goto tx_error_out; + } + tos = old_iph->tos; + df = old_iph->frag_off&__constant_htons(IP_DF); + ttl = tunnel->cttl ? tunnel->cttl : old_iph->ttl; + } else { + ttl = tunnel->cttl ? tunnel->cttl : 64; /* XX */ + } + + if (tunnel->recursion++) { + printk(KERN_ERR "%s: cipe_xmit reentrance\n", dev->name); + tunnel->stat.collisions++; + goto tx_error_out; + } +#ifndef VER_ETH + if (skb->protocol != __constant_htons(ETH_P_IP)) + goto tx_error_out; +#endif + +#if 0 + dprintk(DEB_OUT, (KERN_DEBUG "routing dst=%s src=%s tos=%x oif=%d\n", + cipe_ntoa(0, dst), cipe_ntoa(1, tunnel->myaddr), + RT_TOS(tos), tunnel->sock->bound_dev_if)); +#endif + if (ip_route_output(&rt, dst, tunnel->sock->rcv_saddr, RT_TOS(tos), + tunnel->sock->bound_dev_if)) { + dprintk(DEB_OUT, (KERN_NOTICE "%s: no route\n", dev->name)); + tunnel->stat.tx_carrier_errors++; + dst_link_failure(skb); + goto tx_error_out; + } + if (rt->rt_src!=tunnel->myaddr) { + printk(KERN_NOTICE "%s: changing my address: %s\n", dev->name, + cipe_ntoa(rt->rt_src)); + tunnel->myaddr=tunnel->sock->saddr=rt->rt_src; + } + + tdev = rt->u.dst.dev; + dprintk(DEB_OUT, (KERN_DEBUG "route dev=%s flags=%x type=%x\n", + tdev->name, rt->rt_flags, rt->rt_type)); + + if (tdev == dev) { + printk(KERN_ERR "%s: looped route\n", dev->name); + tunnel->stat.collisions++; + goto tx_error; + } + + mtu = rt->u.dst.pmtu - (cipehdrlen+cipefootlen); + if (tunnel->sockshost) + mtu -= sizeof(struct sockshdr); + + dprintk(DEB_OUT, (KERN_DEBUG "pmtu=%d dmtu=%d size=%d\n", + mtu, tdev->mtu, skb->len)); + + if (mtu < 68) { + printk(KERN_ERR "%s: MTU too small\n", dev->name); + tunnel->stat.collisions++; + goto tx_error; + } + if (skb->dst && mtu < skb->dst->pmtu) { + skb->dst->pmtu = mtu; + dprintk(DEB_OUT, (KERN_NOTICE "%s: adjusting PMTU\n", dev->name)); +#if 0 + /* TEST: is this OK? */ + icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); + goto tx_error; +#endif + } + + if (old_iph && (old_iph->frag_off&__constant_htons(IP_DF)) && mtu < ntohs(old_iph->tot_len)) { + dprintk(DEB_OUT, (KERN_NOTICE "%s: fragmentation needed\n", dev->name)); + icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED, htonl(mtu)); + goto tx_error; + } + + max_headroom = ((tdev->hard_header_len+cipehdrlen+ + ((tunnel->sockshost) ? sizeof(struct sockshdr) : 0) + )+16)&(~15); + max_tailroom = (tunnel->flags&CIPF_HAVE_KEY) ? cipefootlen : 0; + { + struct sk_buff *n= skb_copy_expand(skb, max_headroom, + max_tailroom, GFP_ATOMIC); + if (!n) { + printk(KERN_INFO "%s: Out of memory, dropped packet\n", + dev->name); + goto tx_error; + } + if (skb->sk) + skb_set_owner_w(n, skb->sk); + dev_kfree_skb(skb); + skb = n; + } + memset(&(IPCB(skb)->opt), 0, sizeof(IPCB(skb)->opt)); + dst_release(skb->dst); + skb->dst = &rt->u.dst; + skb->protocol = htons(ETH_P_IP); + + if (tunnel->flags&CIPF_HAVE_KEY) { +#ifndef VER_SHORT + /* Add an IV */ + cipe_cryptpad_iv(skb_push(skb, blockSize)); + length+=blockSize; +#endif + if (!tunnel->flags&CIPF_MAY_STKEY && !tunnel->flags&CIPF_HAVE_SKEY) + /* Attempt to encrypt data using invalid static key */ + goto tx_error; + cipe_encrypt(tunnel, skb->data, &length, TW_DATA); + /* This is incorrect - the tail room gets first used and then + reserved. Doesn't matter in the current (2.0.29) implementation + of skb_put though. Alternative solution would ruin the nice + module separation - we don't need to know the real amount + of padding here. */ + if (length-skb->len > skb->end-skb->tail) { + printk(KERN_ERR "%s: tailroom problem %d %d %ld\n", + dev->name, length, skb->len, skb->end-skb->tail); + goto tx_error; + } + (void) skb_put(skb, length-skb->len); + } else if (!tunnel->flags&CIPF_MAY_CLEAR) { + goto tx_error; + } + + if (tunnel->sockshost) { + /* Install a SOCKS header */ + struct sockshdr *sh = (struct sockshdr *) + skb_push(skb, sizeof(struct sockshdr)); + memset(sh, 0, 4); + sh->atyp=1; + /* sockshost and socksport contain the real peer's address + and the configured/guessed peer is really the socks relayer! */ + sh->dstaddr=tunnel->sockshost; + sh->dstport=tunnel->socksport; + length+=sizeof(struct sockshdr); + } + + /* Install our new headers */ + udph = skb->h.uh = (struct udphdr *) skb_push(skb, sizeof(struct udphdr)); + skb->mac.raw = skb_push(skb, sizeof(struct iphdr)); + iph = skb->nh.iph = (struct iphdr *) skb->mac.raw; + + /* + * Push down and install the CIPE/UDP header. + */ + iph->version = 4; + iph->ihl = sizeof(struct iphdr)>>2; + iph->tos = tos; + iph->tot_len = htons(skb->len); + ip_ident(iph, &rt->u.dst); + iph->frag_off = df; + iph->ttl = ttl; + iph->protocol = IPPROTO_UDP; + iph->saddr = rt->rt_src; + iph->daddr = rt->rt_dst; + + ip_send_check(iph); + + udph->source = tunnel->myport; + udph->dest = tunnel->peerport; + udph->len = htons(length+sizeof(struct udphdr)); + /* Encrypted packets are checksummed already, so we can safely + ignore the UDP checksum. Provide a means to do it nonetheless */ + udph->check = 0; + if (tunnel->flags&CIPF_DO_CSUM) { + udph->check=csum_tcpudp_magic( + iph->saddr, iph->daddr, + length+sizeof(struct udphdr), IPPROTO_UDP, + csum_partial((char *)udph, length+sizeof(struct udphdr), 0)); + if (!udph->check) + udph->check=-1; + } + + tunnel->stat.tx_bytes += skb->len; + tunnel->stat.tx_packets++; + dprintk(DEB_OUT, (KERN_INFO + "%s: sending %d from %s:%d to %s:%d\n", + dev->name, skb->len, + cipe_ntoa(iph->saddr), ntohs(udph->source), + cipe_ntoa(iph->daddr), ntohs(udph->dest))); + if (tunnel->sockshost) + dprintk(DEB_OUT, (KERN_INFO "%s: via SOCKS to %s:%d\n", dev->name, + cipe_ntoa(tunnel->sockshost), + ntohs(tunnel->socksport))); +#if 0 + dprintk(DEB_OUT, (KERN_INFO "dst: (%d,%d) %s %d %d\n", + skb->dst->refcnt, skb->dst->use, + skb->dst->dev->name, skb->dst->pmtu, + skb->dst->error)); +#endif +#ifdef DEBUG + if (cipe_debug&DEB_PKOU) + cipe_dump_packet("sending", skb, 0); +#endif + nf_conntrack_null(skb); +#ifdef LINUX_24 + { + int err = NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, + rt->u.dst.dev, ip_send); + if (err==NET_XMIT_SUCCESS || err==NET_XMIT_CN) { + tunnel->stat.tx_bytes += skb->len; + tunnel->stat.tx_packets++; + } else { + tunnel->stat.tx_errors++; + tunnel->stat.tx_aborted_errors++; + } + } +#else + ip_send(skb); +#endif + tunnel->recursion--; + return 0; + + tx_error: + ip_rt_put(rt); + tx_error_out: + tunnel->stat.tx_errors++; + dev_kfree_skb(skb); + tunnel->recursion--; + return 0; +} + +#else /* LINUX_21 */ + +/* An adapted version of Linux 2.0 drivers/net/new_tunnel.c. */ + +#ifdef SO_BINDTODEVICE + #define iproute(t,o,d) ip_rt_route(t,o,d) +#else + #define iproute(t,o,d) ip_rt_route(t,o) +#endif + +#if LINUX_VERSION_CODE < 131102 /* < 2.0.30 */ + #include + #ifdef CONFIG_IP_FORWARD + #define ipforward(s,d,o,t) ip_forward(s,d,o,t) + #else + #error "Requires IP forwarding enabled in kernel" + #endif +#else /* >= 2.0.30 */ + #define ipforward(s,d,o,t) (sysctl_ip_forward ? ip_forward(s,d,o,t) : -1) +#endif + +int cipe_xmit(struct sk_buff *skb, struct NET_DEVICE *dev) +{ + struct enet_statistics *stats; /* This device's statistics */ + struct rtable *rt; /* Route to the other host */ + struct NET_DEVICE *tdev; /* Device to other host */ + struct iphdr *iph; /* Our new IP header */ + struct udphdr *udph; + __u32 target; /* The other host's IP address */ + int max_headroom; /* The extra header space needed */ + int max_tailroom; + int tos, ttl, length; + DEVTOCIPE(dev,c,0); + + if (skb == NULL || dev == NULL) { + dprintk(DEB_OUT, (KERN_INFO "%s: nothing to do\n", dev->name)); + return 0; + } + + /* + * Make sure we are not busy (check lock variable) + */ + stats = &(c->stat); + if (dev->tbusy != 0) + { + printk(KERN_WARNING "%s: device timeout (really possible?)\n", + dev->name); + dev->tbusy=0; + stats->tx_errors++; + return(1); + } + +#ifdef DEBUG + if (cipe_debug&DEB_PKOU) + cipe_dump_packet("original", skb, 0); +#endif + /* + * First things first. Look up the destination address in the + * routing tables + */ + target = c->peeraddr; + if ((!target) || (!c->peerport) || (!c->myport)) { + /* unconfigured device */ + printk(KERN_INFO "%s: unconfigured\n", dev->name); + goto error; + } + if ((rt = iproute(target, 0, skb->sk?skb->sk->bound_device:NULL)) == NULL) + { + /* No route to host */ + printk(KERN_INFO "%s: target unreachable\n", dev->name); + goto error; + } + dprintk(DEB_OUT, (KERN_INFO + "%s: routing to %08lX from %08lX via %08lX dev %s\n", + dev->name, ntohl(rt->rt_dst), ntohl(rt->rt_src), + ntohl(rt->rt_gateway), rt->rt_dev->name)); + + tdev = rt->rt_dev; + ip_rt_put(rt); + + if (tdev == dev) + { + /* Tunnel to ourselves? -- I don't think so. */ + printk ( KERN_INFO "%s: Packet targetted at myself!\n" , dev->name); + goto error; + } + + /* + * Okay, now see if we can stuff it in the buffer as-is. We can not. + */ + max_headroom = (((tdev->hard_header_len+15)&~15)+cipehdrlen+ + ((c->sockshost) ? sizeof(struct sockshdr) : 0)); + max_tailroom = (c->flags&CIPF_HAVE_KEY) ? cipefootlen : 0; + { + struct sk_buff *new_skb; + + if ( !(new_skb = + dev_alloc_skb(skb->len+max_headroom+max_tailroom)) ) + { + printk(KERN_INFO "%s: Out of memory, dropped packet\n", + dev->name); + dev->tbusy = 0; + stats->tx_dropped++; + dev_kfree_skb(skb, FREE_WRITE); + return 0; + } + new_skb->free = 1; + + /* + * Reserve space for our header and the lower device header + */ + skb_reserve(new_skb, max_headroom); + + /* + * Copy the old packet to the new buffer. + * Note that new_skb->h.iph will be our (tunnel driver's) header + * and new_skb->ip_hdr is the IP header of the old packet. + */ + new_skb->ip_hdr = (struct iphdr *) skb_put(new_skb, skb->len); + new_skb->mac.raw = new_skb->data; + new_skb->dev = skb->dev; + memcpy(new_skb->ip_hdr, skb->data, skb->len); + memset(new_skb->proto_priv, 0, sizeof(skb->proto_priv)); + + /* Free the old packet, we no longer need it */ + dev_kfree_skb(skb, FREE_WRITE); + skb = new_skb; + } +#ifdef VER_ETH + if (skb->mac.ethernet->h_proto==htons(ETH_P_IP)) { +#endif + tos = skb->ip_hdr->tos; + ttl = skb->ip_hdr->ttl; +#ifdef VER_ETH + } else { + tos = 0; + ttl = 64; + } +#endif + length = skb->len; + if (c->flags&CIPF_HAVE_KEY) { +#ifndef VER_SHORT + /* Add an IV */ + cipe_cryptpad(skb_push(skb, blockSize)); + length+=blockSize; +#endif + if (!c->flags&CIPF_MAY_STKEY && !c->flags&CIPF_HAVE_SKEY) + /* Attempt to encrypt data using invalid static key */ + goto error; + cipe_encrypt(c, skb->data, &length, TW_DATA); + /* This is incorrect - the tail room gets first used and then + reserved. Doesn't matter in the current (2.0.29) implementation + of skb_put though. Alternative solution would ruin the nice + module separation - we don't need to know the real amount + of padding here. */ + (void) skb_put(skb, length-skb->len); + } else if (!c->flags&CIPF_MAY_CLEAR) { + goto error; + } + + if (c->sockshost) { + /* Install a SOCKS header */ + struct sockshdr *sh = (struct sockshdr *) + skb_push(skb, sizeof(struct sockshdr)); + memset(sh, 0, 4); + sh->atyp=1; + /* sockshost and socksport contain the real peer's address + and the configured/guessed peer is really the socks relayer! */ + sh->dstaddr=c->sockshost; + sh->dstport=c->socksport; + length+=sizeof(struct sockshdr); + } + + /* Install our new headers */ + udph = (struct udphdr *) skb_push(skb, sizeof(struct udphdr)); + skb->h.iph = (struct iphdr *) skb_push(skb, sizeof(struct iphdr)); + + /* + * Push down and install the CIPE/UDP header. + */ + + iph = skb->h.iph; + iph->version = 4; + iph->tos = tos; + + /* In new_tunnel.c, we use the original packet's TTL here. + Setting a new TTL behaves better to the user, and RFC2003 + recommends it too. But this doesn't fully protect against + routing loops. So make it configurable via an argument: + "cttl" gives the TTL value; if 0 use the packet's + value. Default should be 64, as with the other protocols + (ip_statistics.IpDefaultTTL, but this variable is not + available for modules). */ + + iph->ttl = c->cttl ? c->cttl : ttl; + + iph->frag_off = 0; + iph->daddr = target; + iph->saddr = c->myaddr; /* tdev->pa_addr; */ + iph->protocol = IPPROTO_UDP; + iph->ihl = 5; + iph->tot_len = htons(skb->len); + iph->id = htons(ip_id_count++); /* Race condition here? */ + ip_send_check(iph); + + udph->source = c->myport; + udph->dest = c->peerport; + udph->len = htons(length+sizeof(struct udphdr)); + /* Encrypted packets are checksummed already, so we can safely + ignore the UDP checksum. Provide a means to do it nonetheless */ + udph->check = 0; + if (c->flags&CIPF_DO_CSUM) { + udph->check=csum_tcpudp_magic( + iph->saddr, iph->daddr, + length+sizeof(struct udphdr), IPPROTO_UDP, + csum_partial((char *)udph, length+sizeof(struct udphdr), 0)); + if (!udph->check) + udph->check=-1; + } + + skb->ip_hdr = skb->h.iph; + skb->protocol = htons(ETH_P_IP); + + /* + * Send the packet on its way! + * Note that dev_queue_xmit() will eventually free the skb. + * If ip_forward() made a copy, it will return 1 so we can free. + */ + + dprintk(DEB_OUT, (KERN_INFO "%s: send to %s via %s\n", + dev->name, cipe_ntoa(target), tdev->name)); + +#ifdef DEBUG + if (cipe_debug&DEB_PKOU) + cipe_dump_packet("sending", skb, 0); +#endif + switch (ipforward(skb, dev, IPFWD_NOTTLDEC, target)) { + case -1: + printk(KERN_INFO "%s: forwarding failed\n", dev->name); + /* fall thru */ + case 1: + dev_kfree_skb(skb, FREE_WRITE); + /* Does it really need dev_ here? I think so. */ + break; + default: + /* nothing to do */ + } + + /* + * Clean up: We're done with the route and the packet + */ + + /* Record statistics and return */ + stats->tx_packets++; + dev->tbusy=0; + return 0; + + error: + stats->tx_errors++; + dev_kfree_skb(skb, FREE_WRITE); + dev->tbusy=0; + return 0; +} + +#endif /* LINUX_21 */ --- linux-2.4.21/drivers/addon/cipe4/sock.c.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/sock.c Fri Jul 25 15:12:33 2003 @@ -0,0 +1,731 @@ +/* + CIPE - encrypted IP over UDP tunneling + + sock.c - socket/input interface + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: sock.c,v 1.33.2.3 2002/06/28 23:38:53 olaf Exp $ */ + +#include "cipe.h" + +#include +#include +#include +#include +#include +#ifdef LINUX_21 +#include +#else +typedef unsigned short mm_segment_t; +#endif + +#ifdef LINUX_21 +#define kfreeskb(s,t) kfree_skb(s) +#define saddr(skb) ((skb)->nh.iph->saddr) +#define daddr(skb) ((skb)->nh.iph->daddr) +#else +#define kfreeskb(s,t) kfree_skb(s,t) +#define saddr(skb) ((skb)->saddr) +#define daddr(skb) ((skb)->daddr) +#endif + +/* Rewire generic socket operations to our device-specific ones. + We have new routines for close, sendmsg, recvmsg. */ + +#ifndef LINUX_21 +#define user_data protinfo.af_packet.bound_dev +#endif + +/* init struct cipe *c based on struct sock *sk */ +#define SOCKTOC(nam,sk,c,r) \ + struct cipe *c=(struct cipe *)sk->user_data; \ + if ((!c) || (c->magic!=CIPE_MAGIC)) { \ + printk(KERN_ERR "Ouch: SOCKTOC " nam "\n"); return r; } \ + else { \ + dprintk(DEB_CALL, (KERN_INFO "%s: " nam "\n", c->dev->name)); } + + +/* Close the socket */ +void cipe_sock_close(struct sock *sock, timeout_t timeout) +{ + SOCKTOC("sock_close",sock,c,); + c->sock=NULL; + + /* Put back the old protocol block and let it do the close */ + sock->prot=c->udp_prot; + sock->prot->close(sock, timeout); + if (c->dev->flags&IFF_UP) { + rtnl_LOCK(); + dev_close(c->dev); + rtnl_UNLOCK(); + } else { + cipe_close(c); + } +} + +/* Anything we send to this socket is in fact a key exchange block. + Encode and encrypt it accordingly. +*/ +int cipe_sendmsg(struct sock *sock, struct msghdr *msg, int len +#ifndef LINUX_21 + , int nonblock, int flags +#endif + ) +{ + struct msghdr mymsg; + struct iovec myio[2]; + struct sockaddr_in sa; + struct sockshdr sh; + int e, n=0; + unsigned char buf[KEYXCHGBLKMAX+blockSize]; + SOCKTOC("cipe_sendmsg",sock,c,-ENOSYS); + + if (len>KEYXCHGBLKMAX) + return -EMSGSIZE; +#ifdef VER_SHORT + if (msg->msg_flags&MSG_OOB) + return -EINVAL; +#endif + cipe_prnpad(buf, sizeof(buf)); +#ifdef VER_SHORT + memcpy_fromiovec(buf, msg->msg_iov, len); +#else + memcpy_fromiovec(buf+blockSize, msg->msg_iov, len); + len+=blockSize; +#endif + if (!(msg->msg_flags&MSG_OOB)) { + if (buf[0 +#ifndef VER_SHORT + +blockSize +#endif + ]>=CT_DUMMY) { + if (!c->flags&CIPF_HAVE_KEY) + return -EINVAL; + buf[KEYXCHGTSPOS-1]='\0'; + } else { + if (lenmsg_flags&MSG_OOB) { + memset(buf, 0, blockSize); + } else { + len=KEYXCHGBLKMIN+buf[sizeof(buf)-1]; /* random */ + cipe_encrypt(c, buf, &len, TW_NEWKEY); + } + + sa.sin_family=AF_INET; + sa.sin_addr.s_addr=c->peeraddr; + sa.sin_port=c->peerport; + + if (c->sockshost) { + /* Prepend a socks header. */ + memset(&sh, 0, sizeof(sh)); + sh.atyp=1; + sh.dstaddr=c->sockshost; + sh.dstport=c->socksport; + myio[n].iov_base=&sh; + myio[n].iov_len=sizeof(sh); + ++n; + } + myio[n].iov_base=&buf; + myio[n].iov_len=len; + /* mymsg=*msg; */ + mymsg.msg_name=&sa; + mymsg.msg_namelen=sizeof(sa); + mymsg.msg_iov=myio; + mymsg.msg_iovlen=n+1; + /* just to be sure */ + mymsg.msg_control=NULL; + mymsg.msg_controllen=0; + mymsg.msg_flags=0; + + /* Call the real thing. Pretend this is user space segment. */ + { + mm_segment_t fs=get_fs(); + set_fs(get_ds()); + if (c->sockshost) + len+=sizeof(struct sockshdr); + dprintk(DEB_KXC, (KERN_INFO "%s: real sendmsg len %d text=%04x...\n", + c->dev->name, len, + ntohs(*((unsigned short *)(myio[n].iov_base))))); + e=c->udp_prot->sendmsg(sock, &mymsg, len +#ifndef LINUX_21 + , nonblock, flags +#endif + ); + set_fs(fs); + } + return e; +} + +/* Check if we have a new peer */ +static void checkpeer(struct cipe *c, __u32 saddr, __u16 sport) +{ + if (c->sockshost) { + if (c->sockshost==saddr && c->socksport==sport) + return; + /* sockshost and socksport contain the real peer's address + and the configured/guessed peer is really the socks relayer! */ + c->sockshost=saddr; + c->socksport=sport; + } else { + if (c->peeraddr==saddr && c->peerport==sport) + return; + c->peeraddr=saddr; + c->peerport=sport; + } + printk(KERN_NOTICE "%s: new peer %s:%d\n", + c->dev->name, cipe_ntoa(saddr), ntohs(sport)); +} + +/* Decrypt a received packet. Requeue it or return kxc block. */ +/* On entry the packet starts with the original UDP header, + ip_hdr and h.uh are set to the IP and UDP headers. */ +struct sk_buff *cipe_decrypt_skb(struct cipe *c, struct sock *sk, + struct sk_buff *skb, + int *msgflag) +{ + struct sk_buff *n=NULL; + int length; + __u32 rsaddr; + __u16 rsport; + +#ifdef DEBUG + if (cipe_debug&DEB_PKIN) + cipe_dump_packet("received", skb, 1); +#endif + length=ntohs(skb->h.uh->len)-sizeof(struct udphdr); +#if 0 /* UDP should check this */ + if (length!=skb->len-sizeof(struct udphdr)) { + dprintk(DEB_INP, (KERN_INFO "%s: bogus UDP length (%d/%d)\n", + c->dev->name, length, + skb->len-sizeof(struct udphdr))); + goto framerr; + } +#endif + if (length<9+(c->sockshost?sizeof(struct sockshdr):0)) { + /* XX hardcoded IV size */ + printk(KERN_INFO "%s: got short packet from %s\n", c->dev->name, + cipe_ntoa(saddr(skb))); + goto framerr; + } + + n=alloc_skb(skb->len, GFP_KERNEL); + if (!n) { + printk(KERN_WARNING "%s: cipe_decrypt_skb: out of memory\n", + c->dev->name); + ++c->stat.rx_dropped; + return NULL; + } +#if 0 /*def LINUX_21*/ + if (skb->sk) + skb_set_owner_r(n, skb->sk); +#endif +#ifndef LINUX_21 + n->free=1; +#endif + n->dev=c->dev; + + /* Copy the datagram into new buffer, skip IP header */ + /* We must copy here because raw sockets get only a clone of the + skbuff, so they would receive the plaintext */ + dprintk(DEB_INP, (KERN_INFO DEVNAME + ": sa=%s da=%s us=%d ud=%d ul=%d\n", + cipe_ntoa(saddr(skb)), cipe_ntoa(daddr(skb)), + ntohs(skb->h.uh->source), ntohs(skb->h.uh->dest), + ntohs(skb->h.uh->len))); + + /* why did this get swapped?? */ +#ifdef LINUX_21 + rsaddr=saddr(skb); +#else + rsaddr=daddr(skb); +#endif + rsport=skb->h.uh->source; + skb_put(n,skb->len); + memcpy(n->data, skb->h.raw, skb->len); + n->h.uh=(struct udphdr *)n->data; + + if (c->sockshost) { + /* Pull out the SOCKS header and correct the peer's address. */ + struct sockshdr *sh; + sh=(struct sockshdr *)skb_pull(n, sizeof(struct udphdr)); + dprintk(DEB_INP, (KERN_INFO "socks: fr=%d at=%d da=%s dp=%d\n", + sh->frag, sh->atyp, + cipe_ntoa(sh->dstaddr), ntohs(sh->dstport))); + if (sh->frag || (sh->atyp!=1)) + goto error; + /* Pull out UDP header */ +#ifdef LINUX_21 + n->nh.iph=(struct iphdr *)skb_pull(n, sizeof(struct sockshdr)); +#else + n->ip_hdr=(struct iphdr *)skb_pull(n, sizeof(struct sockshdr)); +#endif + /***saddr(n)=sh->dstaddr;*/ + rsaddr=sh->dstaddr; + rsport=n->h.uh->source=sh->dstport; + length-=sizeof(struct sockshdr); + } else { + /* Pull out UDP header */ +#ifdef LINUX_21 + n->nh.iph=(struct iphdr *) skb_pull(n, sizeof(struct udphdr)); +#else + n->ip_hdr=(struct iphdr *) skb_pull(n, sizeof(struct udphdr)); +#endif + /***saddr(n)=rsaddr;*/ + n->h.uh->source=rsport; + } + +#ifndef VER_SHORT + if (!(*((__u32 *)n->data) & htonl(0x7FFFFFFF))) { + dprintk(DEB_INP, (KERN_INFO "got unencrypted packet (iv=0) len=%d\n", + length)); + skb_pull(n, blockSize); + /* XX not sure about TW_CTRL handling... */ + switch (*n->data) { + /* Restrict what can be received unencrypted. */ + case CT_DUMMY: case CT_DEBUG: case CT_CONFREQ: case CT_CONF: + break; + default: + printk(KERN_WARNING + "%s: got disallowed unencrypted control %02x\n", + c->dev->name, *n->data); + goto error; + } +#ifdef LINUX_21 + get_fast_time(&n->stamp); +#endif + /* No checkpeer() here because not authenticated! */ + n->h.uh->check=0; + return n; + } +#endif + if (c->flags&CIPF_HAVE_KEY) { + if (length%blockSize) { + printk(KERN_INFO "%s: got bogus length=%d\n", c->dev->name, + length); + goto error; + } + switch (cipe_decrypt(c, n->data, &length)) { + case TW_DATA: + if (!c->flags&CIPF_MAY_STKEY && !c->flags&CIPF_HAVE_RKEY) { + printk(KERN_ERR "%s: got data using invalid static key\n", + c->dev->name); + goto error; + } + break; + case TW_CTRL: + /* return it as a control block - out of band datagram */ + *msgflag|=MSG_OOB; + /* fall thru */ + case TW_NEWKEY: + /* return it as key exchange block - proper UDP datagram */ + dprintk(DEB_INP, (KERN_DEBUG "TW_NEWKEY data=%p len=" FLEN + " length=%d\n", n->data, n->len, length)); +#ifdef LINUX_21 + get_fast_time(&n->stamp); +#endif + skb_trim(n, length); + checkpeer(c, rsaddr, rsport); +#if 0 + n->saddr=c->myaddr; + n->daddr=c->peeraddr; +#endif + n->h.uh->check=0; + return n; + default: + /* Bogus packet etc. */ + ++c->stat.rx_crc_errors; + goto error; + } + } else if (!c->flags&CIPF_MAY_CLEAR) { + goto error; + } + + dprintk(DEB_INP, (KERN_DEBUG "TW_DATA data=%p len=" FLEN "length=%d\n", + n->data, n->len, length)); + skb_trim(n, length); + checkpeer(c, rsaddr, rsport); + /* adjust pointers */ +#ifdef VER_ETH + n->protocol = eth_type_trans(n, c->dev); + /* n->pkt_type = PACKET_HOST; */ +#else + n->mac.raw=n->data; /* no hw header */ + n->protocol = htons(ETH_P_IP); + n->pkt_type = PACKET_HOST; +#endif +#ifdef LINUX_21 + n->nh.raw=n->data; + memset(&(IPCB(n)->opt), 0, sizeof(IPCB(n)->opt)); +#else + n->h.iph=(struct iphdr *)n->data; + memset(n->proto_priv, 0, sizeof(struct options)); +#endif + if (lengthsockshost?sizeof(struct sockshdr):0)) { + printk(KERN_INFO "%s: got short packet from %s\n", c->dev->name, + cipe_ntoa(saddr(skb))); + goto framerr; + } + + n->ip_summed = 0; + /* this prints nonsense for non-IP packets. Ignore that. */ + dprintk(DEB_INP, (KERN_INFO "%s: real src %s dst %s len %d\n", + n->dev->name, cipe_ntoa(saddr(n)), + cipe_ntoa(daddr(n)), length)); + +#ifdef DEBUG + if (cipe_debug&DEB_PKIN) + cipe_dump_packet("decrypted", n, 1); +#ifdef LINUX_23 + dprintk(DEB_INP, (KERN_DEBUG "%s state=%ld refcnt=%d\n", n->dev->name, n->dev->state, + atomic_read(&n->dev->refcnt))); +#endif +#endif + + /* requeue */ + netif_rx(n); +#ifdef LINUX_21 + c->stat.rx_bytes+=skb->len; /* count carrier-level bytes */ +#endif + c->stat.rx_packets++; + return NULL; + + framerr: + ++c->stat.rx_frame_errors; /* slightly abuse this */ + error: + ++c->stat.rx_errors; + if (n) + kfreeskb(n, FREE_READ); + return NULL; +} + +/* Receive message. If encrypted, put it through the mill. + If decrypted, return it as key exchange block. + This is mostly from net/ipv4/udp.c, but cipe_decrypt_skb pulls the + UDP header. +*/ + +int cipe_recvmsg(struct sock *sk, struct msghdr *msg, int len, + int noblock, int flags,int *addr_len) +{ + int copied; + struct sk_buff *skb, *skn; + int er=0; + struct sockaddr_in *sin=(struct sockaddr_in *)msg->msg_name; + SOCKTOC("cipe_recvmsg",sk,c,-ENOSYS); + + /* + * Check any passed addresses + */ + + if (addr_len) + *addr_len=sizeof(*sin); + + /* + * From here the generic datagram does a lot of the work. Come + * the finished NET3, it will do _ALL_ the work! + */ + + do { + /* CIPE: look if the packet is encrypted, repeat until + a decrypted one is found */ + skn=NULL; + skb=skb_recv_datagram(sk,flags,noblock,&er); + if(skb==NULL) { + dprintk(DEB_KXC, (KERN_INFO "%s: skb_recv_datagram: %d\n", + c->dev->name, er)); + return er; + } + + if (!skb->h.uh->source) { + /* Synthetic KXC packets are marked by source port 0. + Correct this - we know the truth from our structure. + Perhaps it would be better to not correct it so the + user level daemon can spot the difference? */ + skb->h.uh->source=c->peerport; + skb_pull(skb, sizeof(struct udphdr)); + break; + } + skn=cipe_decrypt_skb(c, sk, skb, &(msg->msg_flags)); + skb_free_datagram(sk, skb); + skb=skn; + } while (skb==NULL); + + dprintk(DEB_INP, (KERN_INFO "%s: returning " FLEN " flags %04x\n", + c->dev->name, skb->len, msg->msg_flags)); + copied = skb->len; + if (copied > len) + { + copied = len; +#ifdef LINUX_21 + msg->msg_flags |= MSG_TRUNC; +#endif + } + if (copied<=0) { + printk(KERN_ERR "cipe_recvmsg: bogus length %d\n", copied); + goto out_free; + } + + /* + * FIXME : should use udp header size info value + */ +#ifdef LINUX_21 +#if 0 + er = skb_copy_datagram_iovec(skb, skb->data-skb-h.raw, + msg->msg_iov, copied); +#else + er = memcpy_toiovec(msg->msg_iov, skb->data, copied); +#endif + if (er<0) + goto out_free; +#else +#if 0 + skb_copy_datagram_iovec(skb,of,msg->msg_iov,copied); +#else + memcpy_toiovec(msg->msg_iov, skb->data, copied); +#endif +#endif + sk->stamp=skb->stamp; + + /* Copy the address. */ + if (sin +#ifdef LINUX_21 + && skb->nh.iph /* Fake KXC has no address */ +#endif + ) { + sin->sin_family = AF_INET; + sin->sin_port = skb->h.uh->source; + sin->sin_addr.s_addr = daddr(skb); + } + er=copied; + + out_free: + if (skb==skn) + /* the buffer was a copy made by decryption */ + kfreeskb(skb, FREE_READ); + else + skb_free_datagram(sk, skb); + + return(er); +} + +#ifdef LINUX_21 + +#include + +int cipe_attach(struct NET_DEVICE *dev, struct siocsifcipatt *parm) +{ + struct file *file; + struct inode *inode; + struct socket *sock; + struct sock *sk; +#if 0 + struct in_device *indev; +#endif + struct cipe *c0; + DEVTOCIPE(dev,c,-ENODEV); + + if (c->sock) + return -EBUSY; + if (!(file=fget(parm->fd))) + return(-EBADF); + inode = file->f_dentry->d_inode; + if (!inode || !inode->i_sock || !(sock=&inode->u.socket_i)) { + fput(file); + return(-ENOTSOCK); + } + if (sock->file != file) { + printk(KERN_ERR DEVNAME ": socki_lookup: socket file changed!\n"); + sock->file = file; + } + + fput(file); + if (sock->type!=SOCK_DGRAM) + return(-ESOCKTNOSUPPORT); + if (sock->ops->family!=AF_INET) + return(-EAFNOSUPPORT); + + sk=sock->sk; + if (sk->state!=TCP_ESTABLISHED) + return(-ENOTCONN); + if (((c0=(struct cipe *)sk->user_data)) && + (c0->magic==CIPE_MAGIC)) + return(-EBUSY); /* socket is already attached */ + + cipe_use_module(); + c->owner=current->pid; + c->sock=sk; + c->peeraddr=sk->daddr; + c->peerport=sk->dport; + c->myaddr=sk->saddr; + if (c->flags&CIPF_MAY_DYNIP) + sk->rcv_saddr=0; + c->myport=htons(sk->num); + /* Disconnect socket, we might receive from somewhere else */ + sk->daddr=0; + sk->dport=0; + + /* Fill an otherwise unused field in the sock struct with this info. + This field is conveniently named and the kernel uses it only for RPC. */ + sk->user_data=c; + sk->no_check=(c->flags&CIPF_DO_CSUM) ? 0 : 1; + + /* Set up new socket operations */ + c->udp_prot=sk->prot; + c->cipe_proto=*sk->prot; + c->cipe_proto.close=cipe_sock_close; + c->cipe_proto.sendmsg=cipe_sendmsg; + c->cipe_proto.recvmsg=cipe_recvmsg; + sk->prot=&c->cipe_proto; + +#if 0 + /* (Try to) Set our dummy hardware address from the IP address. */ + /* This does not work, because the IP address is set + _after_ the attach... */ + if ((indev=dev->ip_ptr)) { + struct in_ifaddr **ifap = NULL; + struct in_ifaddr *ifa = NULL; + for (ifap=&indev->ifa_list; (ifa=*ifap) != NULL; ifap=&ifa->ifa_next) + if (strcmp(dev->name, ifa->ifa_label) == 0) + break; + if (ifa) { + char *x=(char *)&ifa->ifa_local; + dev->dev_addr[3]=x[1]|0x80; + dev->dev_addr[4]=x[2]; + dev->dev_addr[5]=x[3]; + } + } +#endif + + return(0); +} + + +#else /* LINUX_21 */ + +#define sreturn(x) {sti(); return((x));} + +int cipe_attach(struct NET_DEVICE *dev, struct siocsifcipatt *parm) +{ + struct file *file; + struct inode *inode; + struct socket *sock; + struct sock *sk; + int fd=parm->fd; + struct cipe *c0; + DEVTOCIPE(dev,c,-ENODEV); + cli(); + if (c->sock) + sreturn(-EBUSY); + + /* Find the socket (from net/socket.c) */ + if (fd < 0 || fd >= NR_OPEN || !(file = current->files->fd[fd])) + sreturn(-EBADF); + inode = file->f_inode; + if (!inode || !inode->i_sock) + sreturn(-ENOTSOCK); + sock=&inode->u.socket_i; + if (sock->type!=SOCK_DGRAM) + sreturn(-ESOCKTNOSUPPORT); + if (sock->ops->family!=AF_INET) + sreturn(-EAFNOSUPPORT); + sk=(struct sock *)sock->data; + if (sk->state!=TCP_ESTABLISHED) + sreturn(-ENOTCONN); + if (((c0=(struct cipe *)sk->protinfo.af_packet.bound_dev)) && + (c0->magic==CIPE_MAGIC)) + sreturn(-EBUSY); /* socket is already attached */ + + cipe_use_module(); + c->owner=current->pid; + c->sock=sk; + c->peeraddr=sk->daddr; + c->peerport=sk->dummy_th.dest; + c->myaddr=sk->saddr; + if (c->flags&CIPF_MAY_DYNIP) + sk->rcv_saddr=0; + c->myport=sk->dummy_th.source; + /* Disconnect socket, we might receive from somewhere else */ + sk->daddr=0; + sk->dummy_th.dest=0; + + /* Set up new socket operations */ + c->udp_prot=sk->prot; + c->cipe_proto=*sk->prot; + c->cipe_proto.close=cipe_sock_close; + c->cipe_proto.sendmsg=cipe_sendmsg; + c->cipe_proto.recvmsg=cipe_recvmsg; + sk->prot=&c->cipe_proto; + + /* Fill an otherwise unused field in the sock struct with this info. + Actually, this is very similar to a packet socket! + The ugly cast saves us one deref in the actual ops */ + sk->protinfo.af_packet.bound_dev=(struct NET_DEVICE *)c; + sk->no_check=(c->flags&CIPF_DO_CSUM) ? 0 : 1; + + sti(); + return 0; +} + +#endif + + +/* Build and enqueue a fake UDP packet to receive. + Note that these are neither encrypted nor SOCKSed. +*/ +void cipe_fakenkey(struct cipe *c, char typ) +{ + int len=sizeof(struct udphdr)+KEYXCHGBLKMIN; + struct sk_buff *skb=alloc_skb(len, GFP_ATOMIC); + + if (!skb) { + printk(KERN_WARNING "%s: cipe_fakenkey: out of memory\n", + c->dev->name); + return; /* not much we can do */ + } + + dprintk(DEB_KXC, (KERN_INFO "%s: fake kxc block typ=%d\n", + c->dev->name, typ)); + + skb->sk=NULL; + skb->dev=c->dev; + + skb->h.uh=(struct udphdr *)skb->data; + skb->len=len; +#ifdef LINUX_21 + skb->nh.iph=NULL; +#else + saddr(skb)=c->myaddr; + daddr(skb)=c->peeraddr; + skb->free=1; /* Discard after use */ + skb->ip_hdr=NULL; +#endif + skb->h.uh->source=0; /* mark as KXC packet */ + skb->h.uh->dest=c->myport; + len-=sizeof(struct udphdr); + skb->h.uh->len=htons(len); + skb->h.uh->check=0; + skb->mac.raw=skb->data; /* no hardware header */ + + /* All those contortions for just one byte of payload data. + Since we generate only NK_RREQ and NK_REQ it's effectively + one _bit_... */ + skb->data[sizeof(struct udphdr)]=typ; + (*(__u32 *)(skb->data+sizeof(struct udphdr)+KEYXCHGTSPOS))= + htonl(CURRENT_TIME); /* even need timestamp */ + + if (sock_queue_rcv_skb(c->sock, skb)<0) { + printk(KERN_WARNING "%s: cipe_fakenkey: enqueuing failed\n", + c->dev->name); + kfreeskb(skb, FREE_WRITE); + } +} --- linux-2.4.21/drivers/addon/cipe4/version.h.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/version.h Fri Jul 25 15:12:33 2003 @@ -0,0 +1,5 @@ +#define VERSION "1.5.4" +#define ProtocolVersion 3 +#define Crypto_IDEA 1 +#undef Crypto_Blowfish +#undef NO_DYNDEV --- linux-2.4.21/drivers/addon/cipe4/bf.c.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/bf.c Fri Jul 25 15:12:33 2003 @@ -0,0 +1,552 @@ +/* + Bruce Schneier's Blowfish. + Author: Olaf Titz + + This code is in the public domain. + + $Id: bf.c,v 1.4 2000/10/26 10:11:08 olaf Exp $ +*/ + +#include "bf.h" + +#ifdef __KERNEL__ +#include +#include +#else +#include +#endif + +#ifndef ASM_BF_Crypt + +/* The generic big/little endian routines use the following imported + from under Linux: + __u32 __be32_to_cpup(__u32 *p); + __u32 __cpu_to_be32(__u32 x); + __u32 __le32_to_cpup(__u32 *p); + __u32 __cpu_to_le32(__u32 x); + These are macros. We provide replacements if necessary (non-Linux). + XXX the pointer types are wrong, but else a cast would be necessary. +*/ + +#ifdef __GNUC__ +#define INLINE static inline +#else +#define INLINE static +#endif + +#ifndef __be32_to_cpup +INLINE __u32 __be32_to_cpup(unsigned char *p) +{ + return (p[0]<<24)+(p[1]<<16)+(p[2]<<8)+p[3]; +} +#endif + +#ifndef __cpu_to_be32 +INLINE __u32 __cpu_to_be32(__u32 x) +{ + register unsigned char *p=(unsigned char *)&x; + return (p[0]<<24)+(p[1]<<16)+(p[2]<<8)+p[3]; +} +#endif + +#ifndef __le32_to_cpup +INLINE __u32 __le32_to_cpup(unsigned char *p) +{ + return (p[3]<<24)+(p[2]<<16)+(p[1]<<8)+p[0]; +} +#endif + +#ifndef __cpu_to_le32 +INLINE __u32 __cpu_to_le32(__u32 x) +{ + register unsigned char *p=(unsigned char *)&x; + return (p[3]<<24)+(p[2]<<16)+(p[1]<<8)+p[0]; +} +#endif + +/* Macros to implement the round function. */ + +/* access the P and S boxes in key array */ +#define P(n) (key[(n)]) +#define S0(n) (key[(n)+18]) +#define S1(n) (key[(n)+274]) +#define S2(n) (key[(n)+530]) +#define S3(n) (key[(n)+786]) +/* access byte in word */ +#define B0(x) (((x)>>24)&255) +#define B1(x) (((x)>>16)&255) +#define B2(x) (((x)>>8)&255) +#define B3(x) (((x))&255) +/* one raw round sans swap. p is running ptr into P box array */ +#define F(x) (((S0(B0(x))+S1(B1(x)))^S2(B2(x)))+S3(B3(x))) +#define RoundP(a,b) (a)^=(*p++)^F(b) +#define RoundN(a,b) (a)^=(*p--)^F(b) + +/* 16 rounds with running pointer and word swapping */ +#define RoundsP \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r); \ + RoundP(r, l); RoundP(l, r) + +#define RoundsN \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r); \ + RoundN(r, l); RoundN(l, r) + +/* Native byte order routines */ + +void _N_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=(const __u32 *)key; + register unsigned long + l=((__u32 *)dataIn)[0]^(*p++), + r=((__u32 *)dataIn)[1]; + RoundsP; + ((__u32 *)dataOut)[0]=r^(*p); + ((__u32 *)dataOut)[1]=l; +} + +void _N_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=((const __u32 *)key)+17; + register unsigned long + l=((__u32 *)dataIn)[0]^(*p--), + r=((__u32 *)dataIn)[1]; + RoundsN; + ((__u32 *)dataOut)[0]=r^(*p); + ((__u32 *)dataOut)[1]=l; +} + +/* Big-endian routines (i.e. real Blowfish) */ + +#ifndef BF_DONTNEED_BE +#ifndef BF_NATIVE_BE +void B_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=(const __u32 *)key; + register unsigned long + l=__be32_to_cpup(dataIn)^(*p++), + r=__be32_to_cpup(dataIn+4); + RoundsP; + ((__u32 *)dataOut)[0]=__cpu_to_be32(r^(*p)); + ((__u32 *)dataOut)[1]=__cpu_to_be32(l); +} + +void B_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=((const __u32 *)key)+17; + register unsigned long + l=__be32_to_cpup(dataIn)^(*p--), + r=__be32_to_cpup(dataIn+4); + RoundsN; + ((__u32 *)dataOut)[0]=__cpu_to_be32(r^(*p)); + ((__u32 *)dataOut)[1]=__cpu_to_be32(l); +} +#endif +#endif + +/* Little-endian routines */ + +#ifndef BF_DONTNEED_LE +#ifndef BF_NATIVE_LE +void L_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=key; + register unsigned long + l=__le32_to_cpup(dataIn)^(*p++), + r=__le32_to_cpup(dataIn+4); + RoundsP; + ((__u32 *)dataOut)[0]=__cpu_to_le32(r^(*p)); + ((__u32 *)dataOut)[1]=__cpu_to_le32(l); +} + +void L_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key) +{ + register const __u32 *p=key+17; + register unsigned long + l=__le32_to_cpup(dataIn)^(*p--), + r=__le32_to_cpup(dataIn+4); + RoundsN; + ((__u32 *)dataOut)[0]=__cpu_to_le32(r^(*p)); + ((__u32 *)dataOut)[1]=__cpu_to_le32(l); +} +#endif +#endif + +/* Key setup */ + +void Blowfish_ExpandUserKey(const char *userKey, int userKeyLen, + Blowfish_Key key) +{ + char d[8] = {0, 0, 0, 0, 0, 0, 0, 0}; + int i, j; + __u32 u; + + #define UK (userKey[j]&255) + #define UKI if (++j>=userKeyLen) j=0 + for (i=j=0; i<18; ++i) { + u=UK; UKI; + u=(u<<8)+UK; UKI; + u=(u<<8)+UK; UKI; + u=(u<<8)+UK; UKI; + key[i]=Blowfish_Init_Key[i]^u; + } + memcpy(key+18, Blowfish_Init_Key+18, 4096); + for (i=0; i<1042; i+=2) { + _N_Blowfish_Encrypt(d, d, key); + key[i]=((__u32 *)d)[0]; + key[i+1]=((__u32 *)d)[1]; + } +} + +#endif + +/* The initialization key. According to Schneier, this is not a magic + pattern but simply the first 33344 (after point) bits of "pi". */ + +const Blowfish_Key Blowfish_Init_Key = { + /* The eighteen P boxes @ 1 word */ + 0x243f6a88, 0x85a308d3, 0x13198a2e, 0x03707344, + 0xa4093822, 0x299f31d0, 0x082efa98, 0xec4e6c89, + 0x452821e6, 0x38d01377, 0xbe5466cf, 0x34e90c6c, + 0xc0ac29b7, 0xc97c50dd, 0x3f84d5b5, 0xb5470917, + 0x9216d5d9, 0x8979fb1b, + /* The four S boxes @ 256 words */ + 0xd1310ba6, 0x98dfb5ac, 0x2ffd72db, 0xd01adfb7, + 0xb8e1afed, 0x6a267e96, 0xba7c9045, 0xf12c7f99, + 0x24a19947, 0xb3916cf7, 0x0801f2e2, 0x858efc16, + 0x636920d8, 0x71574e69, 0xa458fea3, 0xf4933d7e, + 0x0d95748f, 0x728eb658, 0x718bcd58, 0x82154aee, + 0x7b54a41d, 0xc25a59b5, 0x9c30d539, 0x2af26013, + 0xc5d1b023, 0x286085f0, 0xca417918, 0xb8db38ef, + 0x8e79dcb0, 0x603a180e, 0x6c9e0e8b, 0xb01e8a3e, + 0xd71577c1, 0xbd314b27, 0x78af2fda, 0x55605c60, + 0xe65525f3, 0xaa55ab94, 0x57489862, 0x63e81440, + 0x55ca396a, 0x2aab10b6, 0xb4cc5c34, 0x1141e8ce, + 0xa15486af, 0x7c72e993, 0xb3ee1411, 0x636fbc2a, + 0x2ba9c55d, 0x741831f6, 0xce5c3e16, 0x9b87931e, + 0xafd6ba33, 0x6c24cf5c, 0x7a325381, 0x28958677, + 0x3b8f4898, 0x6b4bb9af, 0xc4bfe81b, 0x66282193, + 0x61d809cc, 0xfb21a991, 0x487cac60, 0x5dec8032, + 0xef845d5d, 0xe98575b1, 0xdc262302, 0xeb651b88, + 0x23893e81, 0xd396acc5, 0x0f6d6ff3, 0x83f44239, + 0x2e0b4482, 0xa4842004, 0x69c8f04a, 0x9e1f9b5e, + 0x21c66842, 0xf6e96c9a, 0x670c9c61, 0xabd388f0, + 0x6a51a0d2, 0xd8542f68, 0x960fa728, 0xab5133a3, + 0x6eef0b6c, 0x137a3be4, 0xba3bf050, 0x7efb2a98, + 0xa1f1651d, 0x39af0176, 0x66ca593e, 0x82430e88, + 0x8cee8619, 0x456f9fb4, 0x7d84a5c3, 0x3b8b5ebe, + 0xe06f75d8, 0x85c12073, 0x401a449f, 0x56c16aa6, + 0x4ed3aa62, 0x363f7706, 0x1bfedf72, 0x429b023d, + 0x37d0d724, 0xd00a1248, 0xdb0fead3, 0x49f1c09b, + 0x075372c9, 0x80991b7b, 0x25d479d8, 0xf6e8def7, + 0xe3fe501a, 0xb6794c3b, 0x976ce0bd, 0x04c006ba, + 0xc1a94fb6, 0x409f60c4, 0x5e5c9ec2, 0x196a2463, + 0x68fb6faf, 0x3e6c53b5, 0x1339b2eb, 0x3b52ec6f, + 0x6dfc511f, 0x9b30952c, 0xcc814544, 0xaf5ebd09, + 0xbee3d004, 0xde334afd, 0x660f2807, 0x192e4bb3, + 0xc0cba857, 0x45c8740f, 0xd20b5f39, 0xb9d3fbdb, + 0x5579c0bd, 0x1a60320a, 0xd6a100c6, 0x402c7279, + 0x679f25fe, 0xfb1fa3cc, 0x8ea5e9f8, 0xdb3222f8, + 0x3c7516df, 0xfd616b15, 0x2f501ec8, 0xad0552ab, + 0x323db5fa, 0xfd238760, 0x53317b48, 0x3e00df82, + 0x9e5c57bb, 0xca6f8ca0, 0x1a87562e, 0xdf1769db, + 0xd542a8f6, 0x287effc3, 0xac6732c6, 0x8c4f5573, + 0x695b27b0, 0xbbca58c8, 0xe1ffa35d, 0xb8f011a0, + 0x10fa3d98, 0xfd2183b8, 0x4afcb56c, 0x2dd1d35b, + 0x9a53e479, 0xb6f84565, 0xd28e49bc, 0x4bfb9790, + 0xe1ddf2da, 0xa4cb7e33, 0x62fb1341, 0xcee4c6e8, + 0xef20cada, 0x36774c01, 0xd07e9efe, 0x2bf11fb4, + 0x95dbda4d, 0xae909198, 0xeaad8e71, 0x6b93d5a0, + 0xd08ed1d0, 0xafc725e0, 0x8e3c5b2f, 0x8e7594b7, + 0x8ff6e2fb, 0xf2122b64, 0x8888b812, 0x900df01c, + 0x4fad5ea0, 0x688fc31c, 0xd1cff191, 0xb3a8c1ad, + 0x2f2f2218, 0xbe0e1777, 0xea752dfe, 0x8b021fa1, + 0xe5a0cc0f, 0xb56f74e8, 0x18acf3d6, 0xce89e299, + 0xb4a84fe0, 0xfd13e0b7, 0x7cc43b81, 0xd2ada8d9, + 0x165fa266, 0x80957705, 0x93cc7314, 0x211a1477, + 0xe6ad2065, 0x77b5fa86, 0xc75442f5, 0xfb9d35cf, + 0xebcdaf0c, 0x7b3e89a0, 0xd6411bd3, 0xae1e7e49, + 0x00250e2d, 0x2071b35e, 0x226800bb, 0x57b8e0af, + 0x2464369b, 0xf009b91e, 0x5563911d, 0x59dfa6aa, + 0x78c14389, 0xd95a537f, 0x207d5ba2, 0x02e5b9c5, + 0x83260376, 0x6295cfa9, 0x11c81968, 0x4e734a41, + 0xb3472dca, 0x7b14a94a, 0x1b510052, 0x9a532915, + 0xd60f573f, 0xbc9bc6e4, 0x2b60a476, 0x81e67400, + 0x08ba6fb5, 0x571be91f, 0xf296ec6b, 0x2a0dd915, + 0xb6636521, 0xe7b9f9b6, 0xff34052e, 0xc5855664, + 0x53b02d5d, 0xa99f8fa1, 0x08ba4799, 0x6e85076a, + 0x4b7a70e9, 0xb5b32944, 0xdb75092e, 0xc4192623, + 0xad6ea6b0, 0x49a7df7d, 0x9cee60b8, 0x8fedb266, + 0xecaa8c71, 0x699a17ff, 0x5664526c, 0xc2b19ee1, + 0x193602a5, 0x75094c29, 0xa0591340, 0xe4183a3e, + 0x3f54989a, 0x5b429d65, 0x6b8fe4d6, 0x99f73fd6, + 0xa1d29c07, 0xefe830f5, 0x4d2d38e6, 0xf0255dc1, + 0x4cdd2086, 0x8470eb26, 0x6382e9c6, 0x021ecc5e, + 0x09686b3f, 0x3ebaefc9, 0x3c971814, 0x6b6a70a1, + 0x687f3584, 0x52a0e286, 0xb79c5305, 0xaa500737, + 0x3e07841c, 0x7fdeae5c, 0x8e7d44ec, 0x5716f2b8, + 0xb03ada37, 0xf0500c0d, 0xf01c1f04, 0x0200b3ff, + 0xae0cf51a, 0x3cb574b2, 0x25837a58, 0xdc0921bd, + 0xd19113f9, 0x7ca92ff6, 0x94324773, 0x22f54701, + 0x3ae5e581, 0x37c2dadc, 0xc8b57634, 0x9af3dda7, + 0xa9446146, 0x0fd0030e, 0xecc8c73e, 0xa4751e41, + 0xe238cd99, 0x3bea0e2f, 0x3280bba1, 0x183eb331, + 0x4e548b38, 0x4f6db908, 0x6f420d03, 0xf60a04bf, + 0x2cb81290, 0x24977c79, 0x5679b072, 0xbcaf89af, + 0xde9a771f, 0xd9930810, 0xb38bae12, 0xdccf3f2e, + 0x5512721f, 0x2e6b7124, 0x501adde6, 0x9f84cd87, + 0x7a584718, 0x7408da17, 0xbc9f9abc, 0xe94b7d8c, + 0xec7aec3a, 0xdb851dfa, 0x63094366, 0xc464c3d2, + 0xef1c1847, 0x3215d908, 0xdd433b37, 0x24c2ba16, + 0x12a14d43, 0x2a65c451, 0x50940002, 0x133ae4dd, + 0x71dff89e, 0x10314e55, 0x81ac77d6, 0x5f11199b, + 0x043556f1, 0xd7a3c76b, 0x3c11183b, 0x5924a509, + 0xf28fe6ed, 0x97f1fbfa, 0x9ebabf2c, 0x1e153c6e, + 0x86e34570, 0xeae96fb1, 0x860e5e0a, 0x5a3e2ab3, + 0x771fe71c, 0x4e3d06fa, 0x2965dcb9, 0x99e71d0f, + 0x803e89d6, 0x5266c825, 0x2e4cc978, 0x9c10b36a, + 0xc6150eba, 0x94e2ea78, 0xa5fc3c53, 0x1e0a2df4, + 0xf2f74ea7, 0x361d2b3d, 0x1939260f, 0x19c27960, + 0x5223a708, 0xf71312b6, 0xebadfe6e, 0xeac31f66, + 0xe3bc4595, 0xa67bc883, 0xb17f37d1, 0x018cff28, + 0xc332ddef, 0xbe6c5aa5, 0x65582185, 0x68ab9802, + 0xeecea50f, 0xdb2f953b, 0x2aef7dad, 0x5b6e2f84, + 0x1521b628, 0x29076170, 0xecdd4775, 0x619f1510, + 0x13cca830, 0xeb61bd96, 0x0334fe1e, 0xaa0363cf, + 0xb5735c90, 0x4c70a239, 0xd59e9e0b, 0xcbaade14, + 0xeecc86bc, 0x60622ca7, 0x9cab5cab, 0xb2f3846e, + 0x648b1eaf, 0x19bdf0ca, 0xa02369b9, 0x655abb50, + 0x40685a32, 0x3c2ab4b3, 0x319ee9d5, 0xc021b8f7, + 0x9b540b19, 0x875fa099, 0x95f7997e, 0x623d7da8, + 0xf837889a, 0x97e32d77, 0x11ed935f, 0x16681281, + 0x0e358829, 0xc7e61fd6, 0x96dedfa1, 0x7858ba99, + 0x57f584a5, 0x1b227263, 0x9b83c3ff, 0x1ac24696, + 0xcdb30aeb, 0x532e3054, 0x8fd948e4, 0x6dbc3128, + 0x58ebf2ef, 0x34c6ffea, 0xfe28ed61, 0xee7c3c73, + 0x5d4a14d9, 0xe864b7e3, 0x42105d14, 0x203e13e0, + 0x45eee2b6, 0xa3aaabea, 0xdb6c4f15, 0xfacb4fd0, + 0xc742f442, 0xef6abbb5, 0x654f3b1d, 0x41cd2105, + 0xd81e799e, 0x86854dc7, 0xe44b476a, 0x3d816250, + 0xcf62a1f2, 0x5b8d2646, 0xfc8883a0, 0xc1c7b6a3, + 0x7f1524c3, 0x69cb7492, 0x47848a0b, 0x5692b285, + 0x095bbf00, 0xad19489d, 0x1462b174, 0x23820e00, + 0x58428d2a, 0x0c55f5ea, 0x1dadf43e, 0x233f7061, + 0x3372f092, 0x8d937e41, 0xd65fecf1, 0x6c223bdb, + 0x7cde3759, 0xcbee7460, 0x4085f2a7, 0xce77326e, + 0xa6078084, 0x19f8509e, 0xe8efd855, 0x61d99735, + 0xa969a7aa, 0xc50c06c2, 0x5a04abfc, 0x800bcadc, + 0x9e447a2e, 0xc3453484, 0xfdd56705, 0x0e1e9ec9, + 0xdb73dbd3, 0x105588cd, 0x675fda79, 0xe3674340, + 0xc5c43465, 0x713e38d8, 0x3d28f89e, 0xf16dff20, + 0x153e21e7, 0x8fb03d4a, 0xe6e39f2b, 0xdb83adf7, + 0xe93d5a68, 0x948140f7, 0xf64c261c, 0x94692934, + 0x411520f7, 0x7602d4f7, 0xbcf46b2e, 0xd4a20068, + 0xd4082471, 0x3320f46a, 0x43b7d4b7, 0x500061af, + 0x1e39f62e, 0x97244546, 0x14214f74, 0xbf8b8840, + 0x4d95fc1d, 0x96b591af, 0x70f4ddd3, 0x66a02f45, + 0xbfbc09ec, 0x03bd9785, 0x7fac6dd0, 0x31cb8504, + 0x96eb27b3, 0x55fd3941, 0xda2547e6, 0xabca0a9a, + 0x28507825, 0x530429f4, 0x0a2c86da, 0xe9b66dfb, + 0x68dc1462, 0xd7486900, 0x680ec0a4, 0x27a18dee, + 0x4f3ffea2, 0xe887ad8c, 0xb58ce006, 0x7af4d6b6, + 0xaace1e7c, 0xd3375fec, 0xce78a399, 0x406b2a42, + 0x20fe9e35, 0xd9f385b9, 0xee39d7ab, 0x3b124e8b, + 0x1dc9faf7, 0x4b6d1856, 0x26a36631, 0xeae397b2, + 0x3a6efa74, 0xdd5b4332, 0x6841e7f7, 0xca7820fb, + 0xfb0af54e, 0xd8feb397, 0x454056ac, 0xba489527, + 0x55533a3a, 0x20838d87, 0xfe6ba9b7, 0xd096954b, + 0x55a867bc, 0xa1159a58, 0xcca92963, 0x99e1db33, + 0xa62a4a56, 0x3f3125f9, 0x5ef47e1c, 0x9029317c, + 0xfdf8e802, 0x04272f70, 0x80bb155c, 0x05282ce3, + 0x95c11548, 0xe4c66d22, 0x48c1133f, 0xc70f86dc, + 0x07f9c9ee, 0x41041f0f, 0x404779a4, 0x5d886e17, + 0x325f51eb, 0xd59bc0d1, 0xf2bcc18f, 0x41113564, + 0x257b7834, 0x602a9c60, 0xdff8e8a3, 0x1f636c1b, + 0x0e12b4c2, 0x02e1329e, 0xaf664fd1, 0xcad18115, + 0x6b2395e0, 0x333e92e1, 0x3b240b62, 0xeebeb922, + 0x85b2a20e, 0xe6ba0d99, 0xde720c8c, 0x2da2f728, + 0xd0127845, 0x95b794fd, 0x647d0862, 0xe7ccf5f0, + 0x5449a36f, 0x877d48fa, 0xc39dfd27, 0xf33e8d1e, + 0x0a476341, 0x992eff74, 0x3a6f6eab, 0xf4f8fd37, + 0xa812dc60, 0xa1ebddf8, 0x991be14c, 0xdb6e6b0d, + 0xc67b5510, 0x6d672c37, 0x2765d43b, 0xdcd0e804, + 0xf1290dc7, 0xcc00ffa3, 0xb5390f92, 0x690fed0b, + 0x667b9ffb, 0xcedb7d9c, 0xa091cf0b, 0xd9155ea3, + 0xbb132f88, 0x515bad24, 0x7b9479bf, 0x763bd6eb, + 0x37392eb3, 0xcc115979, 0x8026e297, 0xf42e312d, + 0x6842ada7, 0xc66a2b3b, 0x12754ccc, 0x782ef11c, + 0x6a124237, 0xb79251e7, 0x06a1bbe6, 0x4bfb6350, + 0x1a6b1018, 0x11caedfa, 0x3d25bdd8, 0xe2e1c3c9, + 0x44421659, 0x0a121386, 0xd90cec6e, 0xd5abea2a, + 0x64af674e, 0xda86a85f, 0xbebfe988, 0x64e4c3fe, + 0x9dbc8057, 0xf0f7c086, 0x60787bf8, 0x6003604d, + 0xd1fd8346, 0xf6381fb0, 0x7745ae04, 0xd736fccc, + 0x83426b33, 0xf01eab71, 0xb0804187, 0x3c005e5f, + 0x77a057be, 0xbde8ae24, 0x55464299, 0xbf582e61, + 0x4e58f48f, 0xf2ddfda2, 0xf474ef38, 0x8789bdc2, + 0x5366f9c3, 0xc8b38e74, 0xb475f255, 0x46fcd9b9, + 0x7aeb2661, 0x8b1ddf84, 0x846a0e79, 0x915f95e2, + 0x466e598e, 0x20b45770, 0x8cd55591, 0xc902de4c, + 0xb90bace1, 0xbb8205d0, 0x11a86248, 0x7574a99e, + 0xb77f19b6, 0xe0a9dc09, 0x662d09a1, 0xc4324633, + 0xe85a1f02, 0x09f0be8c, 0x4a99a025, 0x1d6efe10, + 0x1ab93d1d, 0x0ba5a4df, 0xa186f20f, 0x2868f169, + 0xdcb7da83, 0x573906fe, 0xa1e2ce9b, 0x4fcd7f52, + 0x50115e01, 0xa70683fa, 0xa002b5c4, 0x0de6d027, + 0x9af88c27, 0x773f8641, 0xc3604c06, 0x61a806b5, + 0xf0177a28, 0xc0f586e0, 0x006058aa, 0x30dc7d62, + 0x11e69ed7, 0x2338ea63, 0x53c2dd94, 0xc2c21634, + 0xbbcbee56, 0x90bcb6de, 0xebfc7da1, 0xce591d76, + 0x6f05e409, 0x4b7c0188, 0x39720a3d, 0x7c927c24, + 0x86e3725f, 0x724d9db9, 0x1ac15bb4, 0xd39eb8fc, + 0xed545578, 0x08fca5b5, 0xd83d7cd3, 0x4dad0fc4, + 0x1e50ef5e, 0xb161e6f8, 0xa28514d9, 0x6c51133c, + 0x6fd5c7e7, 0x56e14ec4, 0x362abfce, 0xddc6c837, + 0xd79a3234, 0x92638212, 0x670efa8e, 0x406000e0, + 0x3a39ce37, 0xd3faf5cf, 0xabc27737, 0x5ac52d1b, + 0x5cb0679e, 0x4fa33742, 0xd3822740, 0x99bc9bbe, + 0xd5118e9d, 0xbf0f7315, 0xd62d1c7e, 0xc700c47b, + 0xb78c1b6b, 0x21a19045, 0xb26eb1be, 0x6a366eb4, + 0x5748ab2f, 0xbc946e79, 0xc6a376d2, 0x6549c2c8, + 0x530ff8ee, 0x468dde7d, 0xd5730a1d, 0x4cd04dc6, + 0x2939bbdb, 0xa9ba4650, 0xac9526e8, 0xbe5ee304, + 0xa1fad5f0, 0x6a2d519a, 0x63ef8ce2, 0x9a86ee22, + 0xc089c2b8, 0x43242ef6, 0xa51e03aa, 0x9cf2d0a4, + 0x83c061ba, 0x9be96a4d, 0x8fe51550, 0xba645bd6, + 0x2826a2f9, 0xa73a3ae1, 0x4ba99586, 0xef5562e9, + 0xc72fefd3, 0xf752f7da, 0x3f046f69, 0x77fa0a59, + 0x80e4a915, 0x87b08601, 0x9b09e6ad, 0x3b3ee593, + 0xe990fd5a, 0x9e34d797, 0x2cf0b7d9, 0x022b8b51, + 0x96d5ac3a, 0x017da67d, 0xd1cf3ed6, 0x7c7d2d28, + 0x1f9f25cf, 0xadf2b89b, 0x5ad6b472, 0x5a88f54c, + 0xe029ac71, 0xe019a5e6, 0x47b0acfd, 0xed93fa9b, + 0xe8d3c48d, 0x283b57cc, 0xf8d56629, 0x79132e28, + 0x785f0191, 0xed756055, 0xf7960e44, 0xe3d35e8c, + 0x15056dd4, 0x88f46dba, 0x03a16125, 0x0564f0bd, + 0xc3eb9e15, 0x3c9057a2, 0x97271aec, 0xa93a072a, + 0x1b3f6d9b, 0x1e6321f5, 0xf59c66fb, 0x26dcf319, + 0x7533d928, 0xb155fdf5, 0x03563482, 0x8aba3cbb, + 0x28517711, 0xc20ad9f8, 0xabcc5167, 0xccad925f, + 0x4de81751, 0x3830dc8e, 0x379d5862, 0x9320f991, + 0xea7a90c2, 0xfb3e7bce, 0x5121ce64, 0x774fbe32, + 0xa8b6e37e, 0xc3293d46, 0x48de5369, 0x6413e680, + 0xa2ae0810, 0xdd6db224, 0x69852dfd, 0x09072166, + 0xb39a460a, 0x6445c0dd, 0x586cdecf, 0x1c20c8ae, + 0x5bbef7dd, 0x1b588d40, 0xccd2017f, 0x6bb4e3bb, + 0xdda26a7e, 0x3a59ff45, 0x3e350a44, 0xbcb4cdd5, + 0x72eacea8, 0xfa6484bb, 0x8d6612ae, 0xbf3c6f47, + 0xd29be463, 0x542f5d9e, 0xaec2771b, 0xf64e6370, + 0x740e0d8d, 0xe75b1357, 0xf8721671, 0xaf537d5d, + 0x4040cb08, 0x4eb4e2cc, 0x34d2466a, 0x0115af84, + 0xe1b00428, 0x95983a1d, 0x06b89fb4, 0xce6ea048, + 0x6f3f3b82, 0x3520ab82, 0x011a1d4b, 0x277227f8, + 0x611560b1, 0xe7933fdc, 0xbb3a792b, 0x344525bd, + 0xa08839e1, 0x51ce794b, 0x2f32c9b7, 0xa01fbac9, + 0xe01cc87e, 0xbcc7d1f6, 0xcf0111c3, 0xa1e8aac7, + 0x1a908749, 0xd44fbd9a, 0xd0dadecb, 0xd50ada38, + 0x0339c32a, 0xc6913667, 0x8df9317c, 0xe0b12b4f, + 0xf79e59b7, 0x43f5bb3a, 0xf2d519ff, 0x27d9459c, + 0xbf97222c, 0x15e6fc2a, 0x0f91fc71, 0x9b941525, + 0xfae59361, 0xceb69ceb, 0xc2a86459, 0x12baa8d1, + 0xb6c1075e, 0xe3056a0c, 0x10d25065, 0xcb03a442, + 0xe0ec6e0e, 0x1698db3b, 0x4c98a0be, 0x3278e964, + 0x9f1f9532, 0xe0d392df, 0xd3a0342b, 0x8971f21e, + 0x1b0a7441, 0x4ba3348c, 0xc5be7120, 0xc37632d8, + 0xdf359f8d, 0x9b992f2e, 0xe60b6f47, 0x0fe3f11d, + 0xe54cda54, 0x1edad891, 0xce6279cf, 0xcd3e7e6f, + 0x1618b166, 0xfd2c1d05, 0x848fd2c5, 0xf6fb2299, + 0xf523f357, 0xa6327623, 0x93a83531, 0x56cccd02, + 0xacf08162, 0x5a75ebb5, 0x6e163697, 0x88d273cc, + 0xde966292, 0x81b949d0, 0x4c50901b, 0x71c65614, + 0xe6c6c7bd, 0x327a140a, 0x45e1d006, 0xc3f27b9a, + 0xc9aa53fd, 0x62a80f00, 0xbb25bfe2, 0x35bdd2f6, + 0x71126905, 0xb2040222, 0xb6cbcf7c, 0xcd769c2b, + 0x53113ec0, 0x1640e3d3, 0x38abbd60, 0x2547adf0, + 0xba38209c, 0xf746ce76, 0x77afa1c5, 0x20756060, + 0x85cbfe4e, 0x8ae88dd8, 0x7aaaf9b0, 0x4cf9aa7e, + 0x1948c25c, 0x02fb8a8c, 0x01c36ae4, 0xd6ebe1f9, + 0x90d4f869, 0xa65cdea0, 0x3f09252d, 0xc208e69f, + 0xb74e6132, 0xce77e25b, 0x578fdfe3, 0x3ac372e6 +}; + +#if (defined(TEST) && !defined(__KERNEL__)) + +#include + +/* Test vectors from Schneier's reference implementation */ + +char test1k[] = "abcdefghijklmnopqrstuvwxyz"; +char btest1p[] = { 0x42, 0x4c, 0x4f, 0x57, 0x46, 0x49, 0x53, 0x48 }; +char btest1c[] = { 0x32, 0x4e, 0xd0, 0xfe, 0xf4, 0x13, 0xa2, 0x03 }; + +char test2k[] = "Who is John Galt?"; +char btest2p[] = { 0xfe, 0xdc, 0xba, 0x98, 0x76, 0x54, 0x32, 0x10 }; +char btest2c[] = { 0xcc, 0x91, 0x73, 0x2b, 0x80, 0x22, 0xf6, 0x84 }; + +/* Non-official little endian test ciphertext vectors */ +char btest1l[] = { 0x82, 0x4d, 0x92, 0x0d, 0x00, 0x4d, 0x7e, 0xe3 }; +char btest2l[] = { 0xd4, 0xf9, 0xb0, 0x06, 0xd3, 0x84, 0x92, 0x7e }; + +typedef void (*BFTransform)(void *dataIn, void *dataOut, + const Blowfish_Key key); + +int ftest(char *k, char *p, char *c, + BFTransform Encrypt, BFTransform Decrypt) +{ + Blowfish_Key kk; + unsigned char dd[8]; + int e=0; + + Blowfish_ExpandUserKey(k, strlen(k), kk); + Encrypt(p, dd, kk); + printf(" %02x%02x%02x%02x %02x%02x%02x%02x ", + dd[0], dd[1], dd[2], dd[3], dd[4], dd[5], dd[6], dd[7]); + if (memcmp(dd, c, 8)) { + printf("encrypt failed "); + ++e; + } + Decrypt(dd, dd, kk); + printf(" %02x%02x%02x%02x %02x%02x%02x%02x ", + dd[0], dd[1], dd[2], dd[3], dd[4], dd[5], dd[6], dd[7]); + if (memcmp(dd, p, 8)) { + printf("decrypt failed "); + ++e; + } + printf("%s\n", e?"":"passed"); + return e; +} + +int main() +{ + int e=0; + printf("Big-endian:\n"); + printf(" Test 1: "); + e+=ftest(test1k, btest1p, btest1c, B_Blowfish_Encrypt, B_Blowfish_Decrypt); + printf(" Test 2: "); + e+=ftest(test2k, btest2p, btest2c, B_Blowfish_Encrypt, B_Blowfish_Decrypt); + printf("Little-endian:\n"); + printf(" Test 1: "); + e+=ftest(test1k, btest1p, btest1l, L_Blowfish_Encrypt, L_Blowfish_Decrypt); + printf(" Test 2: "); + e+=ftest(test2k, btest2p, btest2l, L_Blowfish_Encrypt, L_Blowfish_Decrypt); + return e; +} + +#endif --- linux-2.4.21/drivers/addon/cipe4/bf.h.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/bf.h Fri Jul 25 15:12:33 2003 @@ -0,0 +1,100 @@ +/* + Bruce Schneier's Blowfish. + Author: Olaf Titz + + This code is in the public domain. + + $Id: bf.h,v 1.4 2000/10/06 23:15:05 olaf Exp $ +*/ + +#ifndef _BF_H_ +#define _BF_H_ + +#include /* gives __u32 as an unsigned 32bit integer */ +/* PORTABILITY: under non-Linux, + omit this include and insert an appropriate typedef +*/ + +#ifdef __KERNEL__ +#include +#endif +/* PORTABILITY: under non-Linux, omit this include. + Generic, endian-neutral, slower C routines will be used instead of + the assembler versions found in the kernel includes. +*/ + +/* This is ugly, but seems the easiest way to find an endianness test + which works both in kernel and user mode. + This is only an optimization - everything works even if none of the + tests are defined. +*/ +#ifdef __BYTE_ORDER +#if __BYTE_ORDER == __BIG_ENDIAN +#define BF_NATIVE_BE +#endif +#if __BYTE_ORDER == __LITTLE_ENDIAN +#define BF_NATIVE_LE +#endif +#else +#ifdef __BIG_ENDIAN +#define BF_NATIVE_BE +#endif +#ifdef __LITTLE_ENDIAN +#define BF_NATIVE_LE +#endif +#endif + +/* The data block processed by the encryption algorithm - 64 bits */ +typedef __u32 Blowfish_Data[2]; +/* The key as entered by the user - size may vary */ +typedef char Blowfish_UserKey[16]; +/* The expanded key for internal use - 18+4*256 words*/ +typedef __u32 Blowfish_Key[1042]; + +/* Byteorder-dependent handling of data encryption: Blowfish is by + definition big-endian. However, there are broken implementations on + little-endian machines which treat the data as little-endian. + This module provides both variants. + */ + +/* Native byte order. For internal use ONLY. */ +extern void _N_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); +extern void _N_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); + +#ifndef BF_DONTNEED_BE +/* Big endian. This is the "real" Blowfish. */ +#ifdef BF_NATIVE_BE +#define B_Blowfish_Encrypt _N_Blowfish_Encrypt +#define B_Blowfish_Decrypt _N_Blowfish_Decrypt +#else +extern void B_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); +extern void B_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); +#endif +#endif + +#ifndef BF_DONTNEED_LE +/* Little endian. To be compatible with other LE implementations. */ +#ifdef BF_NATIVE_LE +#define L_Blowfish_Encrypt _N_Blowfish_Encrypt +#define L_Blowfish_Decrypt _N_Blowfish_Decrypt +#else +extern void L_Blowfish_Encrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); +extern void L_Blowfish_Decrypt(void *dataIn, void *dataOut, + const Blowfish_Key key); +#endif +#endif + +/* User key expansion. This is not byteorder dependent as all common + implementations get it right (i.e. big-endian). */ + +extern void Blowfish_ExpandUserKey(const char *userKey, int userKeyLen, + Blowfish_Key key); + +extern const Blowfish_Key Blowfish_Init_Key; + +#endif --- linux-2.4.21/drivers/addon/cipe4/bf-i386.S.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/bf-i386.S Fri Jul 25 15:12:33 2003 @@ -0,0 +1,272 @@ +/* + Bruce Schneier's Blowfish in i386 assembler (for linux/gcc) + Author: Olaf Titz + + This code is in the public domain. + + $Id: bf-i386.S,v 1.6 2000/11/16 16:45:00 olaf Exp $ +*/ + +#ifdef ASM_BF_Crypt + +#ifndef __ASSEMBLY__ +#define __ASSEMBLY__ +#endif + +/* This header just defines ENTRY to make an appropriate global symbol */ +#include + +/* Look for CONFIG_X86_BSWAP (defined for 486 and up) */ +#include + +#define PosP0 0 +#define PosP17 68 +#define PosS0 72 +#define PosS1 1096 +#define PosS2 2120 +#define PosS3 3144 +#define KeyLenL 1042 +#define KeyLenB 521 + +/* This code is optimized for speed rather than size - loops unrolled. etc. */ + +/* + Endian-ness is taken care of by (a) the order of shifts in the Round + macro and (b) the order of shifts below under the ukx label. + The key tables and user data are stored and processed in the CPU + byte order. +*/ + +/* Do one round */ +#define Round(lw,rw) \ + movl rw, %edx; \ + shrl $24, %edx; \ + movl PosS0(%edi,%edx,4), %eax; \ + movl rw, %edx; \ + shrl $16, %edx; \ + andl $0xFF, %edx; \ + addl PosS1(%edi,%edx,4), %eax; \ + movl rw, %edx; \ + shrl $8, %edx; \ + andl $0xFF, %edx; \ + xorl PosS2(%edi,%edx,4), %eax; \ + movl rw, %edx; \ + andl $0xFF, %edx; \ + addl PosS3(%edi,%edx,4), %eax; \ + xorl %eax, lw; \ + lodsl; \ + xorl %eax, lw + +/* Words in %ebx, %ecx - Key in %edi - P-index in %esi - result swapped */ +blowfish: + lodsl + xorl %eax, %ebx + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + Round(%ecx,%ebx); Round(%ebx,%ecx) + lodsl + xorl %eax, %ecx + ret + +/* Endianness swap operation. Is there an easier way to decompose + %ebx into %bl and %bh within a macro? */ +#ifdef CONFIG_X86_BSWAP +#define swab32(x,h,l) bswap x +#else +#define swab32(x,h,l) \ + xchgb h, l; \ + rorl $16, x; \ + xchgb h, l +#endif + + +/* Function prototype prologue/epilogue. Sets up registers etc. + This is all code common to the six encrypt/decrypt functions. + They have the prototype + extern void FUNCTION(void *dataIn, void *dataOut, const Blowfish_Key key); + for the following FUNCTIONs: + _N_Blowfish_Encrypt, _N_Blowfish_Decrypt (native-endian) + B_Blowfish_Encrypt, B_Blowfish_Decrypt (big-endian) + L_Blowfish_Encrypt, L_Blowfish_Decrypt (little-endian) + Of course, in the i386 implementation, native==little-endian. +*/ + +/* saved regs relative to %esp */ +#define sebx 0 +#define sebp 4 +#define sesi 8 +#define sedi 12 +#define SAVE 16 /* no. of bytes the saved registers occupy */ +/* arguments relative to %esp */ +#define dataIn SAVE+4(%esp) +#define dataOut SAVE+8(%esp) +#define key SAVE+12(%esp) + +#define PROLOG \ + /* save registers */ \ + subl $SAVE, %esp; \ + movl %ebx, sebx(%esp); \ + movl %ebp, sebp(%esp); \ + movl %esi, sesi(%esp); \ + movl %edi, sedi(%esp); \ + /* load data */ \ + movl dataIn, %esi; \ + movl (%esi), %ebx; \ + movl 4(%esi), %ecx; \ + /* load key */ \ + movl key, %edi; + +#define EPILOG \ + /* store data */ \ + movl dataOut, %edi; \ + movl %ebx, 4(%edi); \ + movl %ecx, (%edi); \ + /* restore registers */ \ + movl sedi(%esp), %edi; \ + movl sesi(%esp), %esi; \ + movl sebp(%esp), %ebp; \ + movl sebx(%esp), %ebx; \ + addl $SAVE, %esp; \ + ret + +#define FORWARD \ + movl %edi, %esi; \ + cld + +#define BACKWARD \ + leal PosP17(%edi), %esi; \ + std + +#define SWAP \ + swab32(%ebx,%bh,%bl); \ + swab32(%ecx,%ch,%cl) + +/* N.B. In Linux 2.3, the D flag is assumed to be zero all the time. + Thus after BACKWARD an additional cld is necessary. */ + +#ifndef BF_DONTNEED_LE +ENTRY(L_Blowfish_Encrypt) +#endif +ENTRY(_N_Blowfish_Encrypt) + PROLOG + FORWARD + call blowfish + EPILOG + +#ifndef BF_DONTNEED_LE +ENTRY(L_Blowfish_Decrypt) +#endif +ENTRY(_N_Blowfish_Decrypt) + PROLOG + BACKWARD + call blowfish + cld + EPILOG + +#ifndef BF_DONTNEED_BE +ENTRY(B_Blowfish_Encrypt) + PROLOG + SWAP + FORWARD + call blowfish + SWAP + EPILOG + +ENTRY(B_Blowfish_Decrypt) + PROLOG + SWAP + BACKWARD + call blowfish + cld + SWAP + EPILOG +#endif + + +/* load byte from key, start over if exhausted */ +#define lodsbw(base,len) \ + lodsb; \ + decl %ecx; \ + cmpl $0, %ecx; \ + jg 1f; \ + movl base, %esi; \ + movl len, %ecx; \ +1: + +/* + void Blowfish_ExpandUserKey(const char *userKey, int userKeyLen, + Blowfish_Key key); +*/ + +ENTRY(Blowfish_ExpandUserKey) + pushl %ebx + pushl %ebp + pushl %esi + pushl %edi +#define SAVE 16 /* no. of bytes the saved registers occupy */ +/* arguments relative to %esp */ +#define userKey SAVE+4(%esp) +#define userKeyLen SAVE+8(%esp) +#define key SAVE+12(%esp) +#define key_push SAVE+16(%esp) /* key with one word pushed */ + + /* Copy the init vector into key */ + leal SYMBOL_NAME(Blowfish_Init_Key), %esi + movl key, %edi + movl $KeyLenL, %ecx + cld + rep; movsl + /* XOR the user key into the P table */ + movl key, %edi + movl $18, %ebp + movl userKey, %esi + movl userKeyLen, %ecx +ukx: + /* process one 32-bit word swapped */ + lodsbw(userKey, userKeyLen) + shll $8, %eax + lodsbw(userKey, userKeyLen) + shll $8, %eax + lodsbw(userKey, userKeyLen) + shll $8, %eax + lodsbw(userKey, userKeyLen) + xorl %eax, (%edi) + addl $4, %edi + decl %ebp + cmpl $0, %ebp + jg ukx + + /* Now do the repeated encryption process */ + xorl %ebx, %ebx + xorl %ecx, %ecx + movl $KeyLenB, %ebp + movl key, %edi +ukb: + pushl %edi + movl key_push, %edi + movl %edi, %esi + call blowfish + popl %edi + xchgl %ebx, %ecx + movl %ebx, (%edi) + movl %ecx, 4(%edi) + addl $8, %edi + decl %ebp + cmpl $0, %ebp + jg ukb + + popl %edi + popl %esi + popl %ebp + popl %ebx + ret +#undef dataIn +#undef dataOut +#undef key + +#endif /* ASM_BF_Crypt */ --- linux-2.4.21/drivers/addon/cipe4/device.c.CIPE4 Fri Jul 25 15:12:33 2003 +++ linux-2.4.21/drivers/addon/cipe4/device.c Fri Jul 25 15:13:36 2003 @@ -0,0 +1,636 @@ +/* + CIPE - encrypted IP over UDP tunneling + + device.c - the net device driver + + Copyright 1996 Olaf Titz + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version + 2 of the License, or (at your option) any later version. +*/ +/* $Id: device.c,v 1.42 2000/11/19 23:08:34 olaf Exp $ */ + +#include "cipe.h" +#include "version.h" +#include +#include +#include +#include + +#ifdef LINUX_21 +#include +#include +#else +#define register_netdevice register_netdev +#define unregister_netdevice unregister_netdev +#endif + +/*** Globals ***/ + +static const char driver_version[]=VERSION; + +struct cipe_ctrl **cipe_ctrls = NULL; +#ifdef NO_DYNDEV +int cipe_maxdev = 4; /* changeable via insmod */ +#else +int cipe_maxdev = 100; /* changeable via insmod */ +#endif +#ifdef DEBUG +int cipe_debug = DEB_CALL; /* changeable via insmod */ +#endif + +/* clear all potentially sensitive info and stats */ +static void cipe_zero_c(struct cipe *c) +{ + memset(&(c->peeraddr), 0, + offsetof(struct cipe, udp_prot)-offsetof(struct cipe, peeraddr)); + /* reset these to sensible values */ + c->tmo_keyxchg = 10*HZ; + c->tmo_keylife = 10*60*HZ; +} + +/* weak but fast PRNG, used for padding only */ +static __u32 prnseed; +void cipe_prnpad(unsigned char *buf, int len) +{ + while (len>0) { + prnseed=prnseed*0x01001001+1; + if (len>=2) { + *(__u16 *)buf=prnseed>>16; + len-=2; buf+=2; + } else { + *buf=(prnseed>>24)^jiffies; return; + } + } +} + +#ifdef DO_LOCK_PRINTK +spinlock_t cipe_printk_lock = SPIN_LOCK_UNLOCKED; +#endif + +/* inet_ntoa() for multiple use. */ +#ifdef __SMP__ +#define NTOABUFS 16 +#else +#define NTOABUFS 4 +#endif +static char ntoabuf[NTOABUFS][16]; +static int ntoaptr=0; +#ifdef LINUX_21 +spinlock_t cipe_ntoa_lock=SPIN_LOCK_UNLOCKED; +#endif + +const char *cipe_ntoa(const __u32 addr) +{ + const unsigned char *x=(const unsigned char *)&addr; + char *p; + int b, i; +#ifdef LINUX_21 + unsigned long flags; + spin_lock_irqsave(&cipe_ntoa_lock, flags); +#endif + b=ntoaptr; + if (++b>=NTOABUFS) + b=0; + ntoaptr=b; +#ifdef LINUX_21 + spin_unlock_irqrestore(&cipe_ntoa_lock, flags); +#endif + p=ntoabuf[b]; + for (i=0; i<4; ++i) { + int k=x[i]/100; + int l=(x[i]/10)%10; + if (k) + *p++=k+'0'; + if (k || l) + *p++=l+'0'; + *p++=(x[i]%10)+'0'; + if (i<3) + *p++='.'; + } + *p='\0'; + return ntoabuf[b]; +} + +/*** IOCTL handlers ***/ + +#ifdef SIOCGIFCIPPAR +static int cipe_getpar(struct NET_DEVICE *dev, struct siocgifcippar *parm) +{ + DEVTOCIPE(dev,c,-ENODEV); + + parm->sockshost=c->sockshost; + parm->socksport=c->socksport; + parm->tmo_keyxchg=c->tmo_keyxchg/HZ; + parm->tmo_keylife=c->tmo_keylife/HZ; + parm->flags=c->flags; + parm->cttl=c->cttl; + return 0; +} +#endif + +static int cipe_setpar(struct NET_DEVICE *dev, struct siocsifcippar *parm) +{ + DEVTOCIPE(dev,c,-ENODEV); + + if (parm->sockshost) + c->sockshost=parm->sockshost; + if (parm->socksport) + c->socksport=parm->socksport; + if (parm->tmo_keyxchg>10*60*HZ) + return -EINVAL; + if (parm->tmo_keyxchg) + c->tmo_keyxchg=parm->tmo_keyxchg*HZ; + if (parm->tmo_keylife>24*60*60*HZ) + return -EINVAL; + if (parm->tmo_keylife) + c->tmo_keylife=parm->tmo_keylife*HZ; + c->flags=(parm->flags&CIPF_MASK_EXT)|(c->flags&CIPF_MASK_INT); + c->cttl=parm->cttl; + dprintk(DEB_CALL, (KERN_DEBUG "%s: setpar %s:%d %ld %ld %04x %d\n", + dev->name, + cipe_ntoa(c->sockshost), ntohs(c->socksport), + c->tmo_keyxchg, c->tmo_keylife, + c->flags, c->cttl)); + return 0; +} + +static int cipe_setkey(struct NET_DEVICE *dev, struct siocsifcipkey *parm) +{ + DEVTOCIPE(dev,c,-ENODEV); + + dprintk(DEB_KXC, (KERN_INFO "%s: setkey %d\n", dev->name, parm->which)); + switch (parm->which) { + case KEY_STATIC: + ExpandUserKey(parm->thekey, c->key_e); +#if 0 + dprintk(DEB_CRYPT, (KERN_DEBUG "ExpandUserKey: %08x\n", + *(__u32*)(c->key_e))); +#endif + InvertKey(c->key_e, c->key_d); + c->flags|=CIPF_HAVE_KEY; + break; + case KEY_SEND: + ExpandUserKey(parm->thekey, c->skey_e); + c->timeskey=jiffies+c->tmo_keylife; + c->cntskey=0; + c->flags|=CIPF_HAVE_SKEY; + break; + case KEY_RECV: + ExpandUserKey(parm->thekey, c->rkey_d); + InvertKey(c->rkey_d, c->rkey_d); + c->timerkey=jiffies+2*c->tmo_keylife; /* allow for fuzz */ + c->cntrkey=0; + c->flags|=CIPF_HAVE_RKEY; + break; + case KEY_STATIC+KEY_INVAL: + c->flags&=~(CIPF_HAVE_KEY|CIPF_HAVE_SKEY|CIPF_HAVE_RKEY); + memset(&(c->key_e), 0, sizeof(c->key_e)); + memset(&(c->key_d), 0, sizeof(c->key_d)); + break; + case KEY_SEND+KEY_INVAL: + c->flags&=~CIPF_HAVE_SKEY; + memset(&(c->skey_e), 0, sizeof(c->skey_e)); + c->timeskey=jiffies+c->tmo_keyxchg; + break; + case KEY_RECV+KEY_INVAL: + c->flags&=~CIPF_HAVE_RKEY; + memset(&(c->rkey_d), 0, sizeof(c->rkey_d)); + c->timerkey=jiffies+c->tmo_keyxchg; + break; + default: + return -EINVAL; + } + return 0; +} + +static int cipe_alloc_dev(int n); +static void cipe_unalloc_dev(int n); + +static int cipe_owner(struct cipe *c) +{ + struct task_struct *p; + pid_t pid=c->owner; + if (!pid) return 0; + tasklist_LOCK(); + p=current; + do { + if (p->pid==pid) { + tasklist_UNLOCK(); + return pid; + } + p=p->next_task; + } while (p!=current); + tasklist_UNLOCK(); + return 0; +} + +#define cipe_nowner(n) cipe_owner(&cipe_ctrls[(n)]->cipe) + +static int cipe_alloc(struct NET_DEVICE *dev, struct siocsifcipall *parm) +{ +#ifdef NO_DYNDEV + return -ENOSYS; +#else + int n=parm->num; + int e; + if (n>=cipe_maxdev) + return -EINVAL; + if ((e=cipe_alloc_LOCK())) + return e; + if (n>=0) { + if (cipe_ctrls[n]) { + if (cipe_ctrls[n]->cipe.sock || (e=cipe_nowner(n))) { + printk(KERN_DEBUG DEVNAME ": dev %d busy pid=%d\n", n, e); + e=-EBUSY; + } else { + cipe_ctrls[n]->cipe.owner=current->pid; + } + } else { + e=cipe_alloc_dev(n); + } + } else { + e=-EMFILE; + for (n=0; ncipe.owner=current->pid; + e=0; + break; + } + } + } + if (!e) { + parm->num=n; + strncpy(parm->name, cipe_ctrls[n]->dev.name, sizeof(parm->name)-1); + parm->name[sizeof(parm->name)-1]='\0'; + } + cipe_alloc_UNLOCK(); + return e; +#endif +} + +static int cipe_unalloc(struct NET_DEVICE *dev, struct siocsifcipall *parm) +{ +#ifdef NO_DYNDEV + return -ENOSYS; +#else + int e; + if (parm->num<0 || parm->num>=cipe_maxdev) + return -EINVAL; + if ((e=cipe_alloc_LOCK())) + return e; + if (cipe_ctrls[parm->num]->cipe.sock) { + e=-EBUSY; + } else { + if (parm->num>0) + cipe_unalloc_dev(parm->num); + } + cipe_alloc_UNLOCK(); + return e; +#endif +} + + +/*** Device operation handlers ***/ + +int cipe_dev_ioctl(struct NET_DEVICE *dev, struct ifreq *ifr, int cmd) +{ + int e=-EINVAL; + +#ifdef LINUX_21 + + if (!capable(CAP_NET_ADMIN)) + return -EPERM; + +#define doioctl(nam,fun,str) { \ + struct str parm; \ + dprintk(DEB_CALL, (KERN_INFO "%s: " nam "\n", dev->name)); \ + if ((e=copy_from_user((void*)&parm,(void*)ifr->ifr_data, \ + sizeof(parm)))<0) \ + goto out; \ + if ((e=fun(dev, &parm))<0) \ + goto out; \ + e=copy_to_user((void*)ifr->ifr_data, (void*)&parm, sizeof(parm)); \ + goto out; \ + } + +#else + + if (!suser()) + return -EPERM; + +#define doioctl(nam,fun,str) { \ + struct str parm; \ + dprintk(DEB_CALL, (KERN_INFO "%s: " nam "\n", dev->name)); \ + if ((e=verify_area(VERIFY_READ, ifr->ifr_data, sizeof(parm)))<0) \ + goto out; \ + memcpy_fromfs((void*)&parm, (void*)ifr->ifr_data, sizeof(parm)); \ + if ((e=fun(dev, &parm))<0) \ + goto out; \ + if ((e=verify_area(VERIFY_WRITE, ifr->ifr_data, sizeof(parm)))<0) \ + goto out; \ + memcpy_tofs((void*)ifr->ifr_data, (void*)&parm, sizeof(parm)); \ + goto out; \ + } + +#endif + + cipe_use_module(); + switch (cmd) { +#ifdef SIOCGIFCIPPAR + case SIOCGIFCIPPAR: + doioctl("getpar", cipe_getpar, siocgifcippar); +#endif + case SIOCSIFCIPPAR: + doioctl("setpar", cipe_setpar, siocsifcippar); + case SIOCSIFCIPKEY: + doioctl("setkey", cipe_setkey, siocsifcipkey); + case SIOCSIFCIPATT: + doioctl("attach", cipe_attach, siocsifcipatt); + case SIOCSIFCIPALL: + doioctl("alloc", cipe_alloc, siocsifcipall); + case SIOCSIFCIPUNA: + doioctl("unalloc", cipe_unalloc, siocsifcipall); + /* default: e=-EINVAL; */ + } + + out: + cipe_unuse_module(); + return e; + +#undef doioctl +} + +int cipe_dev_open(struct NET_DEVICE *dev) +{ + DEVTOCIPE(dev,c,-ENODEV); + if (!c->sock) + return -ENXIO; + dprintk(DEB_CALL, (KERN_INFO "%s: opened\n", dev->name)); + return 0; +} + +void cipe_close(struct cipe *c) +{ + cipe_zero_c(c); + dprintk(DEB_CALL, (KERN_INFO "%s: closed\n", c->dev->name)); + cipe_unuse_module(); +} + +int cipe_dev_close(struct NET_DEVICE *dev) +{ + struct cipe *c = (struct cipe*)(dev->priv); + if ((!c) || (c->magic!=CIPE_MAGIC)) { + printk(KERN_WARNING "%s: cipe_dev_close: no valid struct\n", + dev->name); + return 0; + } + if (c->sock) { + dprintk(DEB_CALL, (KERN_INFO "%s: closing\n", c->dev->name)); + /* Tell the attached socket we're going down */ + c->sock->shutdown=SHUTDOWN_MASK; + c->sock->zapped=1; + c->sock->err=ENXIO; + c->sock->error_report(c->sock); +#ifdef LINUX_21 + if (!cipe_owner(c)) { + /* SHOULD NOT HAPPEN. Socket is probably left orphaned. + This is really only an emergency path to allow closing + the device after an Oops. */ + printk(KERN_ERR "cipe_dev_close: not owned??\n"); + cipe_close(c); + } +#endif + } else { + cipe_close(c); + } + return 0; +} + +struct DEV_STATS *cipe_get_stats(struct NET_DEVICE *dev) +{ + DEVTOCIPE(dev,c,NULL); + return &(c->stat); +} + +int cipe_set_mac(struct NET_DEVICE *dev, void *p) +{ + struct sockaddr *addr=p; + memcpy(dev->dev_addr, addr->sa_data, dev->addr_len); + return 0; +} + + +/*** Initialization and finalization stuff ***/ + +#ifndef LINUX_21 +static inline void dev_init_buffers(struct NET_DEVICE *dev) +{ + int i; + for (i = 0; i < DEV_NUMBUFFS; i++) { + skb_queue_head_init(&dev->buffs[i]); + } +} +#endif + +static int cipe_init_dev(struct NET_DEVICE *dev) +{ + struct cipe *c = (struct cipe*)(dev->priv); + if (!c) + return -ENODEV; + + memset(c, 0, sizeof(struct cipe)); /* zero the device struct along */ + c->magic = CIPE_MAGIC; + c->dev = dev; + cipe_zero_c(c); + + /* Device parameters. */ +#ifdef VER_ETH + ether_setup(dev); /* sets hard_header etc. */ +#endif + /* Procedural */ + dev->open = cipe_dev_open; + dev->stop = cipe_dev_close; + dev->hard_start_xmit = cipe_xmit; + dev->set_mac_address = cipe_set_mac; + dev->do_ioctl = cipe_dev_ioctl; + dev->get_stats = cipe_get_stats; + + /* "Hardware" */ +#ifndef VER_ETH + dev->type = ARPHRD_TUNNEL; + dev->hard_header_len = 0; /* we copy anyway to expand */ + dev->tx_queue_len = 100; /* matches ethernet */ +#endif + dev->mtu = ETH_DATA_LEN + -sizeof(struct sockshdr) + -cipehdrlen + -cipefootlen; + + +#ifdef LINUX_21 + dev->iflink = -1; +#else + dev->family = AF_INET; + dev->pa_alen = 4; + dev->metric = 1; +#endif + dev_init_buffers(dev); + + /* New-style flags */ +#ifndef VER_ETH + dev->flags = IFF_POINTOPOINT|IFF_NOARP; +#endif + return 0; +} + +#ifndef LINUX_21 +struct semaphore cipe_alloc_sem=MUTEX; +#endif + +static int cipe_alloc_dev(int n) +{ + int e=0; + struct cipe_ctrl *cc; + struct NET_DEVICE *d; + + dprintk(DEB_CALL, (KERN_INFO DEVNAME ": cipe_alloc_dev %d\n", n)); + if (!(cc=kmalloc(sizeof(struct cipe_ctrl), GFP_KERNEL))) { + cipe_ctrls[n]=NULL; + printk(KERN_ERR DEVNAME ": failed to allocate device %d\n", n); + return -ENOMEM; + } + + memset((void *)cc, 0, sizeof(*cc)); +/* If this doesn't compile, define or undefine HAVE_DEVNAME_ARRAY + in cipe.h accordingly. */ +#ifdef HAVE_DEVNAME_ARRAY + sprintf(cc->dev.name, DEVNAME "%d", n); +#else + sprintf(cc->name, DEVNAME "%d", n); + cc->dev.name = cc->name; +#endif + cc->dev.base_addr = n; /* dummy */ + cc->dev.priv = (void*)&(cc->cipe); + cc->dev.next = NULL; + cc->dev.init = cipe_init_dev; /* called by register_netdevice */ + +#if 1 + /* Generate a dummy MAC address. This code seems to be in accordance + to the address assignments as of RFC1700, pp.172f. + We use 00-00-5E-vv-nn-zz with + vv=1pppccc0, p=protocol, c=crypto, + nn=device number, zz=from MAC of first eth device. + */ + cc->dev.dev_addr[2]=0x5E; + cc->dev.dev_addr[3]=0x80+(ProtocolVersion<<4)+(CRNUM<<1); + cc->dev.dev_addr[4]=n; + for (d=dev_base; d; d=d->next) + if (d->type==ARPHRD_ETHER) { + cc->dev.dev_addr[5]=d->dev_addr[5]; + break; + } +#else + /* MAC address will be generated from IP as with PLIP. FC-FC-ip-ip-ip-ip */ + cc->dev.dev_addr[1]=cc->dev.dev_addr[0]=0xFC; +#endif + memset(d->broadcast, 0xFF, ETH_ALEN); + cc->dev.addr_len=ETH_ALEN; + + e=register_netdevice(&(cc->dev)); + if (e<0) { + kfree(cc); + printk(KERN_ERR + "%s: register_netdevice() failed\n", cc->dev.name); + cc=NULL; + } else { + cc->cipe.owner=current->pid; + } + cipe_ctrls[n]=cc; + return e; +} + +static void cipe_unalloc_dev(int n) +{ + struct cipe_ctrl *cc=cipe_ctrls[n]; + if (!cc) + return; + dprintk(DEB_CALL, (KERN_INFO DEVNAME ": cipe_unalloc_dev %d\n", n)); + if (cc->cipe.magic!=CIPE_MAGIC) { + printk(KERN_WARNING DEVNAME ": Ouch: cipe_unalloc_dev() wrong struct\n"); + return; + } + unregister_netdevice(&(cc->dev)); + cipe_ctrls[n]=NULL; + kfree(cc); +} + +int init_module(void) +{ + int e=cipe_check_kernel(); + if (e<0) + return e; + + /* sanity check on insmod-provided data */ + if (cipe_maxdev<1) cipe_maxdev=1; +#ifdef NO_DYNDEV + if (cipe_maxdev>100) cipe_maxdev=100; +#else + if (cipe_maxdev>10000) cipe_maxdev=10000; +#endif + +#ifdef DEBUG + printk(KERN_INFO + DEVNAME ": CIPE driver vers %s (c) Olaf Titz 1996-2000, %d channels, debug=%d\n", + driver_version, cipe_maxdev, cipe_debug); +#else + printk(KERN_INFO + DEVNAME ": CIPE driver vers %s (c) Olaf Titz 1996-2000, %d channels\n", + driver_version, cipe_maxdev); +#endif + + prnseed=(~jiffies)^CURRENT_TIME; + cipe_ctrls = (struct cipe_ctrl **) kmalloc(sizeof(void*)*cipe_maxdev, + GFP_KERNEL); + if (!cipe_ctrls) { + printk(KERN_ERR + DEVNAME ": failed to allocate master control structure\n"); + return -ENOMEM; + } + memset(cipe_ctrls, 0, sizeof(void*)*cipe_maxdev); +#ifdef NO_DYNDEV + { + int i; + rtnl_LOCK(); + for (i=0; i -------------- next part -------------- A non-text attachment was scrubbed... Name: linux-2.4.9-addon.patch Type: text/x-patch Size: 3513 bytes Desc: not available URL: From notting at redhat.com Tue Jul 29 02:18:54 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 28 Jul 2003 22:18:54 -0400 Subject: bugs, bugs, bugs! Message-ID: <20030728221854.A21358@devserv.devel.redhat.com> Just some intro for those who haven't played this game before... If you've reported a bug, you may have noticed in the past few days that the bug may now be listed as blocking bug 100643 or bug 100644. These bugs are the 'CambridgeBlocker' and 'CambridgeTarget' bugs What these bugs represent: - categorization of bugs into relative high and medium priorities What these bugs don't represent: - guarantees that the bug will be fixed Note that these lists are populated at first through cursory bug triage; issues in these bugs may eventually turn out to be NOTABUG or WONTFIX. How You Can Help (if you so desire): 1) If you've got a bug that appears to be overlooked in this categorization, feel free to nomintate it in the body of the appropriate tracking bug ('CambridgeBlocker', or 'CambridgeTarget'); then our crack (cracked?) bug triage team will review it again. (Note that all bugs opened against the beta are usually given a once-over within a day or two of being opened; this is how the list normally gets populated) 2) Look at the bugs on the list, and feel free to: - perform duplicate eliminations - verfiy reproducibility/create test cases - provide patches to fix them. (This option is preferred, of course.) Bugs may be moved from one list to the other at any time, or deescalated completely. The chances of an enhancement requests landing on either of these lists is fairly low. Bill From jjneely at pams.ncsu.edu Tue Jul 29 02:46:06 2003 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Mon, 28 Jul 2003 22:46:06 -0400 Subject: gdm and missing home directories In-Reply-To: <20030728141708.K7222@devserv.devel.redhat.com> References: <20030728171227.GA27264@anduril.pams.ncsu.edu> <20030728141708.K7222@devserv.devel.redhat.com> Message-ID: <20030729024606.GL27264@anduril.pams.ncsu.edu> I don't think I'm getting as far as starting Gnome. Looking at slave.c I don't see off hand what cases my session to end almost instantly. I put gdm in debug mode and get the same thing if I click on Yes or No. The following is what gets logged with me using the Yes option to log me in with / == HOME. Jack Jul 28 22:23:09 narsil gdm(pam_unix)[4100]: session opened for user slack by (uid=0) Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_wait_for_login: end verify for 'slack' Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_wait_for_login: got_login for 'slack' Jul 28 22:23:09 narsil gdm[4100]: Sending LOGGED_IN == 1 for slave 4100 Jul 28 22:23:09 narsil gdm[4100]: Sending LOGGED_IN 4100 1 Jul 28 22:23:09 narsil gdm[4051]: Handling message: 'LOGGED_IN 4100 1' Jul 28 22:23:09 narsil gdm[4051]: Got logged in == TRUE Jul 28 22:23:09 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal Jul 28 22:23:09 narsil gdm[4100]: Sending LOGIN == slack for slave 4100 Jul 28 22:23:09 narsil gdm[4100]: Sending LOGIN 4100 slack Jul 28 22:23:09 narsil gdm[4051]: Handling message: 'LOGIN 4100 slack' Jul 28 22:23:09 narsil gdm[4051]: Got LOGIN == slack Jul 28 22:23:09 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_session_start: Attempting session for user 'slack' Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_session_start: Home directory for slack: '/home/slack' does not exist! Jul 28 22:23:12 narsil gdm(pam_unix)[4100]: session closed for user slack Jul 28 22:23:12 narsil gdm[4051]: (child 4100) gdm_slave_child_handler Jul 28 22:23:12 narsil gdm[4100]: Sending LOGGED_IN == 0 for slave 4100 Jul 28 22:23:12 narsil gdm[4100]: Sending LOGGED_IN 4100 0 Jul 28 22:23:12 narsil gdm[4051]: Handling message: 'LOGGED_IN 4100 0' Jul 28 22:23:12 narsil gdm[4051]: Got logged in == FALSE Jul 28 22:23:12 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal Jul 28 22:23:12 narsil gdm[4100]: Sending LOGIN == for slave 4100 Jul 28 22:23:12 narsil gdm[4100]: Sending LOGIN 4100 Jul 28 22:23:12 narsil gdm[4051]: Handling message: 'LOGIN 4100 ' Jul 28 22:23:12 narsil gdm[4051]: Got LOGIN == Jul 28 22:23:12 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal Jul 28 22:23:12 narsil gdm[4100]: gdm_slave_wait_for_login: In loop -- Jack Neely Linux Realm Kit Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From hp at redhat.com Tue Jul 29 05:11:44 2003 From: hp at redhat.com (Havoc Pennington) Date: Tue, 29 Jul 2003 01:11:44 -0400 Subject: gdm and missing home directories In-Reply-To: <20030729024606.GL27264@anduril.pams.ncsu.edu> References: <20030728171227.GA27264@anduril.pams.ncsu.edu> <20030728141708.K7222@devserv.devel.redhat.com> <20030729024606.GL27264@anduril.pams.ncsu.edu> Message-ID: <20030729011144.I24506@devserv.devel.redhat.com> On Mon, Jul 28, 2003 at 10:46:06PM -0400, Jack Neely wrote: > I don't think I'm getting as far as starting Gnome. Looking at slave.c > I don't see off hand what cases my session to end almost instantly. I > put gdm in debug mode and get the same thing if I click on Yes or No. > > The following is what gets logged with me using the Yes option to log me > in with / == HOME. > Need to get this info to George Lebl, either via filing a bug and I'll cc him or by mailing jirka at 5z.com I do think there's almost a 100% chance that GNOME itself will fail once you get gdm to log you in, though. Havoc From hp at redhat.com Tue Jul 29 05:13:38 2003 From: hp at redhat.com (Havoc Pennington) Date: Tue, 29 Jul 2003 01:13:38 -0400 Subject: gdm and missing home directories In-Reply-To: <20030729011144.I24506@devserv.devel.redhat.com> References: <20030728171227.GA27264@anduril.pams.ncsu.edu> <20030728141708.K7222@devserv.devel.redhat.com> <20030729024606.GL27264@anduril.pams.ncsu.edu> <20030729011144.I24506@devserv.devel.redhat.com> Message-ID: <20030729011338.J24506@devserv.devel.redhat.com> On Tue, Jul 29, 2003 at 01:11:44AM -0400, Havoc Pennington wrote: > Need to get this info to George Lebl, either via filing a bug and I'll > cc him or by mailing jirka at 5z.com I forgot he was already blaming PostLogin or whatever - let me revise, we need to get George to explain better what he's saying the problem is and how we should fix it. ;-) > I do think there's almost a 100% chance that GNOME itself will fail > once you get gdm to log you in, though. > Fail with read-only '/' homedir that is, it would probably work with the tmpdir thing. Havoc From harald at redhat.com Tue Jul 29 15:36:30 2003 From: harald at redhat.com (Harald Hoyer) Date: 29 Jul 2003 17:36:30 +0200 Subject: %configure and RPM_OPT_FLAGS Message-ID: <1059492990.27247.43.camel@faro.stuttgart.redhat.com> I wanted to modify CXXFLAGS and stumbled across the %configure definition... CFLAGS="${CFLAGS:-%optflags}" CXXFLAGS="${CXXFLAGS:-%optflags}" FFLAGS="${FFLAGS:-%optflags}" Wouldn't it be better to have this in /usr/lib/rpm/redhat/macros: RPM_OPT_FLAGS="%{optflags}" CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" CXXFLAGS="${CXXFLAGS:-${RPM_OPT_FLAGS}}" FFLAGS="${FFLAGS:-${RPM_OPT_FLAGS}}" so that I can modify RPM_OPT_FLAGS prior to calling %configure?? -- Harald Hoyer, Senior Software Engineer Harald.Hoyer at redhat.de Red Hat GmbH Tel. : +49-711-96437-0 D-70178 Stuttgart, Germany Web : http://www.redhat.de gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From sopwith at redhat.com Tue Jul 29 15:41:44 2003 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 29 Jul 2003 11:41:44 -0400 (EDT) Subject: %configure and RPM_OPT_FLAGS In-Reply-To: <1059481704.27247.13.camel@faro.stuttgart.redhat.com> Message-ID: On 29 Jul 2003, Harald Hoyer wrote: > I wanted to modify CXXFLAGS and stumbled across the %configure > definition... > CFLAGS="${CFLAGS:-%optflags}" > CXXFLAGS="${CXXFLAGS:-%optflags}" > FFLAGS="${FFLAGS:-%optflags}" > > > Wouldn't it be better to have this in /usr/lib/rpm/redhat/macros: > > RPM_OPT_FLAGS="%{optflags}" This part already happens automatically and is unnecessary. > CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" > CXXFLAGS="${CXXFLAGS:-${RPM_OPT_FLAGS}}" > FFLAGS="${FFLAGS:-${RPM_OPT_FLAGS}}" > > so that I can modify RPM_OPT_FLAGS prior to calling %configure?? If it is safe to assume that $RPM_OPT_FLAGS is only ever used in %build, then please commit the change to redhat-rpm-config in devel CVS, and build the update into dist-3.0E and dist-10. -- Elliot Humpty Dumpty was pushed. From rezso at rdsor.ro Tue Jul 29 23:42:43 2003 From: rezso at rdsor.ro (Balint Cristian) Date: Tue, 29 Jul 2003 19:42:43 -0400 Subject: miss of reiserfs/jfs/xfs from Severn In-Reply-To: <1059424167.4085.20.camel@zorak> References: <20030728162132.C10000@devserv.devel.redhat.com> <1059424167.4085.20.camel@zorak> Message-ID: <200307291942.43959.rezso@rdsor.ro> Observed that install guide from Severn miss riserfs module at install guide. There was a trik in Rh 9 that allow to instal on reiserfs, i just swich AltF2 format partitions using mkreiserfs, and to DiskDruid tell to mount only not to format. Severn miss reisefs.o during instal stage ... DiscDruid not allow to define mountpoint because i think reiserfs.o miss so /proc/filesystem not reports reiserfs. I use lot of Rh's 7.3/8.0/9 in production instaled with that trick whithout any kind of problem why dont add reiserfs/xfs/jfs officialy in the list of diskdruid ? Yes yes of course not pass bonnie++ or other tools ? Suse allows it, but i dont like suse :)) Can manage in future to reenable reiserfs (mean to add kernels' reiserfs.o to instal stage) ? Today trying Severn i was disappointed when i realise the trick not work anymore ... Thanks a lot ! -- Life in itself has no meaning. Life is an opportunity to create meaning. \|/ ____ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ From ms-nospam-0306 at arcor.de Tue Jul 29 17:48:28 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 29 Jul 2003 19:48:28 +0200 Subject: %configure and RPM_OPT_FLAGS In-Reply-To: <1059492990.27247.43.camel@faro.stuttgart.redhat.com> References: <1059492990.27247.43.camel@faro.stuttgart.redhat.com> Message-ID: <20030729194828.5158f812.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29 Jul 2003 17:36:30 +0200, Harald Hoyer wrote: > I wanted to modify CXXFLAGS and stumbled across the %configure > definition... > CFLAGS="${CFLAGS:-%optflags}" > CXXFLAGS="${CXXFLAGS:-%optflags}" > FFLAGS="${FFLAGS:-%optflags}" > > > Wouldn't it be better to have this in /usr/lib/rpm/redhat/macros: > > RPM_OPT_FLAGS="%{optflags}" > > CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" > CXXFLAGS="${CXXFLAGS:-${RPM_OPT_FLAGS}}" > FFLAGS="${FFLAGS:-${RPM_OPT_FLAGS}}" > > so that I can modify RPM_OPT_FLAGS prior to calling %configure?? Funny you would post it right now. I have just ran into the same upon trying to override RPM_OPT_FLAGS in the spec file and finding out that I need to override %{optflags} instead. [+1 for changing it] - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/JrNs0iMVcrivHFQRAsohAKCDA7kzW1PdSS4vIApX81fdowOa4ACaA3C4 txr6FCwk0J3q0f+6tPIEZrE= =Pc/x -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Tue Jul 29 17:54:20 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 29 Jul 2003 19:54:20 +0200 Subject: people.redhat.com index In-Reply-To: <1059046368.2975.17.camel@localhost> References: <20030723192120.GC28315@raq465.uk2net.com> <1059043171.2975.6.camel@localhost> <1059043635.3457.80.camel@owsdavid> <1059044691.2975.11.camel@localhost> <1059045317.3457.88.camel@owsdavid> <1059046368.2975.17.camel@localhost> Message-ID: <20030729195420.25d050c2.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24 Jul 2003 13:32:48 +0200, Andr? Kelpe wrote: > Am Don, 2003-07-24 um 13.15 schrieb david paeme: > > > |---------------script starts here------------------| > > > > #!/bin/sh > > wget ftp://people.redhat.com > > > > |---------------script ends here--------------------| > > This does not work on my machine. I don't know why, but I get just some > error messages from wget. If it will work on my machine, you are the > winner of > "the-shortest-script-to-get-the-index-of-peple.redhat.com-contest" ;-) Certainly works like expected, just that you get ftp:// links instead of the http:// you prefer. ;) $ wget ftp://people.redhat.com - --19:53:17-- ftp://people.redhat.com/ => `.listing' Resolving people.redhat.com... done. Connecting to people.redhat.com[66.187.233.237]:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD not needed. ==> PORT ... done. ==> LIST ... done. 0K .......... . 24.84 KB/s 19:53:20 (24.84 KB/s) - `.listing' saved [12135] Removed `.listing'. Wrote HTML-ized index to `index.html' [17485]. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/JrTM0iMVcrivHFQRAlVkAJ99Q7VRUGozSYBoDEPzlILEDbOatwCfUbk9 fpnJJYpu30X3ZZhsL+D0+3c= =Yezf -----END PGP SIGNATURE----- From hbo at egbok.com Tue Jul 29 18:07:42 2003 From: hbo at egbok.com (Howard Owen) Date: 29 Jul 2003 11:07:42 -0700 Subject: people.redhat.com index In-Reply-To: <20030729195420.25d050c2.ms-nospam-0306@arcor.de> References: <20030723192120.GC28315@raq465.uk2net.com> <1059043171.2975.6.camel@localhost> <1059043635.3457.80.camel@owsdavid> <1059044691.2975.11.camel@localhost> <1059045317.3457.88.camel@owsdavid> <1059046368.2975.17.camel@localhost> <20030729195420.25d050c2.ms-nospam-0306@arcor.de> Message-ID: <1059502062.3231.120.camel@owen.egbok.com> If you are behind a firewall, you might have to add --passive-ftp On Tue, 2003-07-29 at 10:54, Michael Schwendt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 24 Jul 2003 13:32:48 +0200, Andr? Kelpe wrote: > > > Am Don, 2003-07-24 um 13.15 schrieb david paeme: > > > > > |---------------script starts here------------------| > > > > > > #!/bin/sh > > > wget ftp://people.redhat.com > > > > > > |---------------script ends here--------------------| > > > > This does not work on my machine. I don't know why, but I get just some > > error messages from wget. If it will work on my machine, you are the > > winner of > > "the-shortest-script-to-get-the-index-of-peple.redhat.com-contest" ;-) > > Certainly works like expected, just that you get ftp:// links instead > of the http:// you prefer. ;) > > $ wget ftp://people.redhat.com > - --19:53:17-- ftp://people.redhat.com/ > => `.listing' > Resolving people.redhat.com... done. > Connecting to people.redhat.com[66.187.233.237]:21... connected. > Logging in as anonymous ... Logged in! > ==> SYST ... done. ==> PWD ... done. > ==> TYPE I ... done. ==> CWD not needed. > ==> PORT ... done. ==> LIST ... done. > > 0K .......... . 24.84 KB/s > > 19:53:20 (24.84 KB/s) - `.listing' saved [12135] > > Removed `.listing'. > Wrote HTML-ized index to `index.html' [17485]. > > - -- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > > iD8DBQE/JrTM0iMVcrivHFQRAlVkAJ99Q7VRUGozSYBoDEPzlILEDbOatwCfUbk9 > fpnJJYpu30X3ZZhsL+D0+3c= > =Yezf > -----END PGP SIGNATURE----- > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From ville.skytta at iki.fi Tue Jul 29 20:23:07 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: 29 Jul 2003 23:23:07 +0300 Subject: %configure and RPM_OPT_FLAGS In-Reply-To: References: Message-ID: <1059510187.12758.33.camel@bobcat.mine.nu> On Tue, 2003-07-29 at 18:41, Elliot Lee wrote: > > CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" > > CXXFLAGS="${CXXFLAGS:-${RPM_OPT_FLAGS}}" > > FFLAGS="${FFLAGS:-${RPM_OPT_FLAGS}}" > > > > so that I can modify RPM_OPT_FLAGS prior to calling %configure?? > > If it is safe to assume that $RPM_OPT_FLAGS is only ever used in %build, > then please commit the change to redhat-rpm-config in devel CVS, and build > the update into dist-3.0E and dist-10. Note that a lot of packages exist that do things like perl -pi -e "s|-O2|$RPM_OPT_FLAGS|" Makefile in %prep. Dunno about the effects, but just pointing out that $RPM_OPT_FLAGS is sometimes used outside of %build. (Yep, it would be better to do 's|-O2|\$(RPM_OPT_FLAGS)|' or something else that doesn't use the actual value of $RPM_OPT_FLAGS at the time the perl/sed'ing occurs). -- \/ From goeran at uddeborg.se Tue Jul 29 21:39:47 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran?= Uddeborg) Date: Tue, 29 Jul 2003 23:39:47 +0200 Subject: RFC: i18n proposal In-Reply-To: <20030728123604.A6922@devserv.devel.redhat.com> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> <16161.41106.591644.103709@uebn.uddeborg.se> <20030728123604.A6922@devserv.devel.redhat.com> Message-ID: <16166.59811.357179.684255@uebn.uddeborg.se> Jeff Johnson writes: > The only difference from the current specspo implementation (which uses > dgettext) is: > you are moving the package derived retrieval key from the > 2nd MSGID arg to the 1st DOMAINNAME arg without specifiying > what is to replace MSGID. The specspo implementation creates one huge database of descriptions for all and only packages of one release. My intention was to try to envision a scheme, inspired by the ideas in Havoc's letters, where this was split up per package instead. > If you are hoping to use the MSGID from package headers as the MSGID key, > then your solution is inferior to the current specspo implementation > because the Group/Summary/Description then *must* be built into packages. That was how I thought about it. But I guess it is not really critical. You could continue the current practice of using a po-file for a key-value lookup, and still have one po file per package as I suggested. I haven't fully understood why it is such a good idea. I thougt gettext was designed to avoid having opaque keys, and instead use the English language message directly as the key. And this seems to go contrary to that, back to the catgets() inteface. But again, this is not really the same issue. > There's absolutely nothing at all stopping anyone from adding a domain > to the colon seperated set of domains in the macro %{_i18ndomains} > and doing exactly what you propose. But I want each package to have its own domain. There is no easy way to automatically add a domain to i18ndomains on package installation, and remove it on uninstall, is it? > You're missing several important points: I'm sure I am. > a) msgid's, not just msgstr's, need to be handled. msgid's are not > necessarily constant, If I update specspo, it may result in that descriptions of already installed packages change or disappear. Is it this sense of "not ... constant" you refer to? I consider that a bug. One of the bugs I'm trying to solve here. If I do "rpm -qip xmms-1.2.7-1.i386.rpm", with specspo installed, I get a description not mentioning MP3. If I uninstall specspo, or change to locale C or so, I get the package's original description, mentioning MP3. Similarily, if I to "rpm -qi mpg321" on a system which still has this package, but current specspo, I don't get the description translatied. There was a translation, but it is not part of current specspo. In both cases, the messages, and translations of them, which existed at the time of package generation is better than the current situation. They ought to come and go with the package itself. > nor is there (or at least gas there been) > sufficient time late in a release cycle to manage "make world" > rebuilds to include i18n, too many things can break. That could of course be a problem. To me it seems it would be possible to freeze descriptions of the new packages earlier. Like already by now in the current cycle. And also make them available for translation at this time. Then they could be there when the final build is done. But I realise I don't know the internals of these routines. > c) the goal must be to have i18n tags in metadata, fetching from > the payload is a costly decompression. I must have misunderstood something. In message <20030724114226.Q18401 at devserv.devel.redhat.com> you said: > IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in > tar/cpio headers. Keep i18n out of packages, please. I understood that to mean that you did not want the translations in the metadata. So I tried to sketch things obeying that, putting them elsewhere. But maybe I misunderstood this comment. If so, I guess one could try to extend the current "%description -l ...". As I understand it, this does become package metadata; at least it winds up in the Packages database file. As you pointed out, this lacks coding information. Also, putting all translations in the spec file is not very convenient. They need to be fetched externally at build time. But if this is an acceptable method, these problems probably could be solved. > Sure your scheme makes sense, but is possibly different than what rpm > has been doing since 6.2. There are consequences for having to support > multiple schemes for the indefinite future, not the least of which is > the complexity involved. Point taken. > IMHO the apparent driving force for revisiting an already solved problem > is the perceived need to accomodate 3rd party package group/summary/description. > > Personally, I have yet to meet (or hear of) any single person who has even > attempted the translation. Are we talking about translations of descriptions at all? Or only through external po files? I always include Swedish versions when I build packages of my own. (After rhcontrib.bero.org died, I've mostly circulated them among friends. Some could probably still be found out there; rpmfind found a stickers package for example.) I may be uncommon doing this. But then again, including translations in the SPEC file is not very convenient. And is "%description -l" documented anywhere except for the change log and the source code? There is a chance not everybody is aware of the possibility. :-) From hp at redhat.com Wed Jul 30 00:52:04 2003 From: hp at redhat.com (Havoc Pennington) Date: Tue, 29 Jul 2003 20:52:04 -0400 Subject: RFC: i18n proposal In-Reply-To: <16166.59811.357179.684255@uebn.uddeborg.se> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> <16161.41106.591644.103709@uebn.uddeborg.se> <20030728123604.A6922@devserv.devel.redhat.com> <16166.59811.357179.684255@uebn.uddeborg.se> Message-ID: <20030729205204.B12088@devserv.devel.redhat.com> On Tue, Jul 29, 2003 at 11:39:47PM +0200, G?ran Uddeborg wrote: > The specspo implementation creates one huge database of descriptions > for all and only packages of one release. My intention was to try to > envision a scheme, inspired by the ideas in Havoc's letters, where > this was split up per package instead. Jeff made the point to me in a hallway conversation that a more appropriate split might be "per translation team." At least I think he'd agree with that. Havoc From skvidal at phy.duke.edu Wed Jul 30 04:06:42 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 30 Jul 2003 00:06:42 -0400 Subject: BitTorrent enabled downloads & updates In-Reply-To: <1059083610.23202.68.camel@amr.math.utah.edu> References: <1059083610.23202.68.camel@amr.math.utah.edu> Message-ID: <1059538002.28944.54.camel@binkley> On Thu, 2003-07-24 at 17:53, Elijah P Newren wrote: > Sorry for the cross-posting. I originally posted this idea on #fedora > at irc.freenode.net and Anvil suggested I email these two lists with > this idea. My idea was the following: > > Have apt-get/yum/up2date/ > use BitTorrent for file downloads. > > This would have the following benefits: > Users would get a much faster download rate (at least, that's > been my experience for the downloads I've done with > BitTorrent). > It would alleviate the 'which mirror should I use' problem. > Anyone could easily become a mirror. > It should keep any specific mirror from getting overloaded. > > I figured this made so much sense that someone else has already thought > of it and perhaps already implemented it. Anyone know if that's the > case? If not, does that idea sound interesting to others? It could be interesting but remember- bittorrent is mostly useful for large files - not for trivially sized things like any single rpm. -sv From ms-nospam-0306 at arcor.de Wed Jul 30 11:28:02 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 30 Jul 2003 13:28:02 +0200 Subject: RPM building section of RHL's developer guide In-Reply-To: <1059423679.23194.166.camel@bobcat.mine.nu> References: <20030722122604.624f3b23.matthias@rpmforge.net> <1059021299.1858.64.camel@laptop> <20030724100009.O18401@devserv.devel.redhat.com> <1059324234.15610.233.camel@bobcat.mine.nu> <20030728144134.G6922@devserv.devel.redhat.com> <1059423679.23194.166.camel@bobcat.mine.nu> Message-ID: <20030730132802.489eb20e.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28 Jul 2003 23:21:20 +0300, Ville Skytt? wrote: > "Doesn't work" == "The package cannot be built". And with this > definition, it turns out that I do remember correctly; it "doesn't work" > with 4.2. Nor does it with 4.2.1. See the attached specfile, here are > some test results with it: > > rpm-4.2-1 on Shrike: > > $ rpmbuild -bb foo.spec > error: line 8: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: %{epoch}:1-1.0 > > rpm-4.2.1-0.11 on Severn: > > $ rpmbuild -bb foo.spec > error: line 8: Dependency tokens must begin with alpha-numeric, '_' or '/': Requires: %{epoch}:1-1.0 > > If "no Epoch" == "Epoch: 0" in 4.2.1, why the error? It is *not* a > matter of style; if I add the explicit "Epoch: 0" in the attached > foo.spec, the rpmbuild completes with both versions. Package name is missing in here: Requires: %{epoch}:%{version}-%{release} - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/J6vC0iMVcrivHFQRApxfAJ9WDAC3BUWCDjXA0NP69vgmWYT/5gCghLid txtlbVRWiBoyva7iZ9yUPQw= =ymLt -----END PGP SIGNATURE----- From ms-nospam-0306 at arcor.de Wed Jul 30 11:34:53 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Wed, 30 Jul 2003 13:34:53 +0200 Subject: RPM building section of RHL's developer guide In-Reply-To: <3F258AA4.1040601@cypress.com> References: <20030722122604.624f3b23.matthias@rpmforge.net> <1059021299.1858.64.camel@laptop> <20030724100009.O18401@devserv.devel.redhat.com> <1059324234.15610.233.camel@bobcat.mine.nu> <20030728144134.G6922@devserv.devel.redhat.com> <1059423679.23194.166.camel@bobcat.mine.nu> <3F258AA4.1040601@cypress.com> Message-ID: <20030730133453.1cf518af.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 28 Jul 2003 15:42:12 -0500, Thomas Dodd wrote: > > error: Failed dependencies: > > glib = 0:1.2.10 is needed by glib-devel-1.2.10-10 > > Just to nitpick a little more, shouldn't that be: > > error: Failed dependencies: > glib = 0:1.2.10 is needed by glib-devel-0:1.2.10-10 > > For completeness? :) Because glib-devel-1.2.10-10 denotes a package file name and epochs have never been part of the rpm file name. In either place, the epoch would only cause more confusion among users: > error: Failed dependencies: > glib = 1.2.10 is needed by glib-devel-1.2.10-10 Is uncomprehensible for the user when he tried to install glib-devel-1.2.10-10 and doesn't know about epochs. > error: Failed dependencies: > glib = 0:1.2.10 is needed by glib-devel-1.2.10-10 Is uncomprehensible for the user when he has glib-1.2.10-10 and doesn't know where to get glib-0:1.2.10-10. ;-P - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/J61d0iMVcrivHFQRAuQXAJsHfa9yDF+n4XbTz100qEkYpqQUfwCfWiBB I8TZFN3i3szR676+vFvpiNY= =aZaP -----END PGP SIGNATURE----- From ville.skytta at iki.fi Wed Jul 30 11:47:51 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: 30 Jul 2003 14:47:51 +0300 Subject: RPM building section of RHL's developer guide In-Reply-To: <20030730132802.489eb20e.ms-nospam-0306@arcor.de> References: <20030722122604.624f3b23.matthias@rpmforge.net> <1059021299.1858.64.camel@laptop> <20030724100009.O18401@devserv.devel.redhat.com> <1059324234.15610.233.camel@bobcat.mine.nu> <20030728144134.G6922@devserv.devel.redhat.com> <1059423679.23194.166.camel@bobcat.mine.nu> <20030730132802.489eb20e.ms-nospam-0306@arcor.de> Message-ID: <1059565671.12758.136.camel@bobcat.mine.nu> On Wed, 2003-07-30 at 14:28, Michael Schwendt wrote: > > If "no Epoch" == "Epoch: 0" in 4.2.1, why the error? It is *not* a > > matter of style; if I add the explicit "Epoch: 0" in the attached > > foo.spec, the rpmbuild completes with both versions. > > Package name is missing in here: > > Requires: %{epoch}:%{version}-%{release} *blush* Note to self: no late-at-night posts. Anyway, when the spec is fixed, it builds w/ rpm 4.2 and 4.2.1 but results in "foo = %{epoch}:1-1.0" dependency (not 0:1-1.0) to the main package in -devel with both. Jeff's "%{name} = %{?epoch:%{epoch}:}%{version}" 'workaround' works. -- \/ From jjneely at pams.ncsu.edu Wed Jul 30 14:05:45 2003 From: jjneely at pams.ncsu.edu (Jack Neely) Date: Wed, 30 Jul 2003 10:05:45 -0400 Subject: [jjneely@pams.ncsu.edu: Re: gdm and missing home directories] Message-ID: <20030730140545.GT27264@anduril.pams.ncsu.edu> This didn't seem to make it the first time... ----- Forwarded message from Jack Neely ----- Date: Mon, 28 Jul 2003 22:46:06 -0400 From: Jack Neely To: rhl-devel-list at redhat.com Subject: Re: gdm and missing home directories I don't think I'm getting as far as starting Gnome. Looking at slave.c I don't see off hand what cases my session to end almost instantly. I put gdm in debug mode and get the same thing if I click on Yes or No. The following is what gets logged with me using the Yes option to log me in with / == HOME. Jack Jul 28 22:23:09 narsil gdm(pam_unix)[4100]: session opened for user slack by (uid=0) Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_wait_for_login: end verify for 'slack' Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_wait_for_login: got_login for 'slack' Jul 28 22:23:09 narsil gdm[4100]: Sending LOGGED_IN == 1 for slave 4100 Jul 28 22:23:09 narsil gdm[4100]: Sending LOGGED_IN 4100 1 Jul 28 22:23:09 narsil gdm[4051]: Handling message: 'LOGGED_IN 4100 1' Jul 28 22:23:09 narsil gdm[4051]: Got logged in == TRUE Jul 28 22:23:09 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal Jul 28 22:23:09 narsil gdm[4100]: Sending LOGIN == slack for slave 4100 Jul 28 22:23:09 narsil gdm[4100]: Sending LOGIN 4100 slack Jul 28 22:23:09 narsil gdm[4051]: Handling message: 'LOGIN 4100 slack' Jul 28 22:23:09 narsil gdm[4051]: Got LOGIN == slack Jul 28 22:23:09 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_session_start: Attempting session for user 'slack' Jul 28 22:23:09 narsil gdm[4100]: gdm_slave_session_start: Home directory for slack: '/home/slack' does not exist! Jul 28 22:23:12 narsil gdm(pam_unix)[4100]: session closed for user slack Jul 28 22:23:12 narsil gdm[4051]: (child 4100) gdm_slave_child_handler Jul 28 22:23:12 narsil gdm[4100]: Sending LOGGED_IN == 0 for slave 4100 Jul 28 22:23:12 narsil gdm[4100]: Sending LOGGED_IN 4100 0 Jul 28 22:23:12 narsil gdm[4051]: Handling message: 'LOGGED_IN 4100 0' Jul 28 22:23:12 narsil gdm[4051]: Got logged in == FALSE Jul 28 22:23:12 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal Jul 28 22:23:12 narsil gdm[4100]: Sending LOGIN == for slave 4100 Jul 28 22:23:12 narsil gdm[4100]: Sending LOGIN 4100 Jul 28 22:23:12 narsil gdm[4051]: Handling message: 'LOGIN 4100 ' Jul 28 22:23:12 narsil gdm[4051]: Got LOGIN == Jul 28 22:23:12 narsil gdm[4051]: (child 4100) gdm_slave_usr2_handler: :0 got USR2 signal Jul 28 22:23:12 narsil gdm[4100]: gdm_slave_wait_for_login: In loop -- Jack Neely Linux Realm Kit Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 ----- End forwarded message ----- -- Jack Neely Linux Realm Kit Administration and Development PAMS Computer Operations at NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 From jbj at redhat.com Wed Jul 30 16:01:43 2003 From: jbj at redhat.com (Jeff Johnson) Date: Wed, 30 Jul 2003 12:01:43 -0400 Subject: RFC: i18n proposal In-Reply-To: <20030729205204.B12088@devserv.devel.redhat.com>; from hp@redhat.com on Tue, Jul 29, 2003 at 08:52:04PM -0400 References: <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> <16161.41106.591644.103709@uebn.uddeborg.se> <20030728123604.A6922@devserv.devel.redhat.com> <16166.59811.357179.684255@uebn.uddeborg.se> <20030729205204.B12088@devserv.devel.redhat.com> Message-ID: <20030730120143.D32372@devserv.devel.redhat.com> On Tue, Jul 29, 2003 at 08:52:04PM -0400, Havoc Pennington wrote: > On Tue, Jul 29, 2003 at 11:39:47PM +0200, G?ran Uddeborg wrote: > > The specspo implementation creates one huge database of descriptions > > for all and only packages of one release. My intention was to try to > > envision a scheme, inspired by the ideas in Havoc's letters, where > > this was split up per package instead. > > Jeff made the point to me in a hallway conversation that a more > appropriate split might be "per translation team." At least I think > he'd agree with that. Good we appear to be moving to convergence ;-) If the intent is to have one domain per-package, the current implementation already supports this. For example, suppose you want a single domain for package "foo". This is the current process to create: a) configure the new translation domain in /etc/rpm/macros.specspo (or any of the zillions of places that a macro can be defined) %_i18ndomains redhat:foo b) add the msgid text in the usual places within the en_US locale. Here's what needs to be there for %description: msgid: "foo(Description)" msgstr: "This is foo's description." c) add the usual PO file in the usual places for domain "foo". Here's what needs to be there for the above: msgid: "This is foo's description." msgstr: "This is the translation of foo's description." This mechanism is sufficiently general to support thousands of teensy per-package domains without changing anything. Any wartlets, like linear search on domains, or abuse of en_US can be easily solved in the rpm implementation, not the package format, or rpmbuild process. Any other solution, like compiling in msgid's into packages again again again, or adding new-fangled tags, is gonna cause trouble imho. So what's wrong with the above? 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From johnsonm at redhat.com Wed Jul 30 16:17:18 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 30 Jul 2003 12:17:18 -0400 Subject: miss of reiserfs/jfs/xfs from Severn In-Reply-To: <200307291942.43959.rezso@rdsor.ro>; from rezso@rdsor.ro on Tue, Jul 29, 2003 at 07:42:43PM -0400 References: <20030728162132.C10000@devserv.devel.redhat.com> <1059424167.4085.20.camel@zorak> <200307291942.43959.rezso@rdsor.ro> Message-ID: <20030730121718.A10705@devserv.devel.redhat.com> reiserfs is in kernel-unsupported, and we're discussing changes to the way we build the distro to deal with this issue. We want to disambiguate "we expect this to work" from "we aren't so sure about this, and bug reports are likely to be WONTFIX"; the goal isn't to remove functionality and confuse people. :-) We're still working on this... michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ On Tue, Jul 29, 2003 at 07:42:43PM -0400, Balint Cristian wrote: > Observed that install guide from Severn miss riserfs module at install guide. > There was a trik in Rh 9 that allow to instal on reiserfs, i just > swich AltF2 format partitions using mkreiserfs, and to DiskDruid tell to mount only not > to format. > Severn miss reisefs.o during instal stage ... > DiscDruid not allow to define mountpoint because i think reiserfs.o miss > so /proc/filesystem not reports reiserfs. > > I use lot of Rh's 7.3/8.0/9 in production instaled with that trick whithout any kind of problem > why dont add reiserfs/xfs/jfs officialy in the list of diskdruid ? > > Yes yes of course not pass bonnie++ or other tools ? > Suse allows it, but i dont like suse :)) > > Can manage in future to reenable reiserfs (mean to add kernels' reiserfs.o to instal stage) ? > Today trying Severn i was disappointed when i realise the trick not work anymore ... > > Thanks a lot ! > > -- > Life in itself has no meaning. > Life is an opportunity to create meaning. > > \|/ ____ \|/ > "@'/ .. \`@" > /_| \__/ |_\ > \__U_/ > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list From jbj at redhat.com Wed Jul 30 16:32:08 2003 From: jbj at redhat.com (Jeff Johnson) Date: Wed, 30 Jul 2003 12:32:08 -0400 Subject: RFC: i18n proposal In-Reply-To: <16166.59811.357179.684255@uebn.uddeborg.se>; from goeran@uddeborg.se on Tue, Jul 29, 2003 at 11:39:47PM +0200 References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> <16161.41106.591644.103709@uebn.uddeborg.se> <20030728123604.A6922@devserv.devel.redhat.com> <16166.59811.357179.684255@uebn.uddeborg.se> Message-ID: <20030730123208.E32372@devserv.devel.redhat.com> On Tue, Jul 29, 2003 at 11:39:47PM +0200, G?ran Uddeborg wrote: > Jeff Johnson writes: > > The only difference from the current specspo implementation (which uses > > dgettext) is: > > you are moving the package derived retrieval key from the > > 2nd MSGID arg to the 1st DOMAINNAME arg without specifiying > > what is to replace MSGID. > > The specspo implementation creates one huge database of descriptions > for all and only packages of one release. My intention was to try to > envision a scheme, inspired by the ideas in Havoc's letters, where > this was split up per package instead. > (under seperate cover) > > If you are hoping to use the MSGID from package headers as the MSGID key, > > then your solution is inferior to the current specspo implementation > > because the Group/Summary/Description then *must* be built into packages. > > That was how I thought about it. But I guess it is not really > critical. You could continue the current practice of using a po-file > for a key-value lookup, and still have one po file per package as I > suggested. > > I haven't fully understood why it is such a good idea. I thougt > gettext was designed to avoid having opaque keys, and instead use the > English language message directly as the key. And this seems to go > contrary to that, back to the catgets() inteface. > The basic reason for splitting msgid from msgstr is that the docs team writes the msgid's, the translation team supplies msgstr's; hence package i18n is a little different than traditional xgettext on *.c. > > > a) msgid's, not just msgstr's, need to be handled. msgid's are not > > necessarily constant, > > If I update specspo, it may result in that descriptions of already > installed packages change or disappear. Is it this sense of "not > ... constant" you refer to? > Unlike, say, error messages with xgettext *.c, summary/description/group are much softer, so text divergence is acceptable. Yes, that's a feature, at least for the docs team editors, because text can be updated in the field without having to wait for "make world" \of the next distro release. It's also a feature for translation teams, which are no longer subject to the tyrrany of a distro release deadline, specspo could/should be released as needed (i.e. when msgid's change from docs team), not when there is a distro release. Sure, specspo needs to be burned on the CD, there are alternative update pathways that could/should be used for specspo. Again, these are process, not implementation, solutions so my feature may very well be your bug ;-) > I consider that a bug. One of the bugs I'm trying to solve here. > > If I do "rpm -qip xmms-1.2.7-1.i386.rpm", with specspo installed, I > get a description not mentioning MP3. If I uninstall specspo, or > change to locale C or so, I get the package's original description, > mentioning MP3. > > Similarily, if I to "rpm -qi mpg321" on a system which still has this > package, but current specspo, I don't get the description translatied. > There was a translation, but it is not part of current specspo. > > In both cases, the messages, and translations of them, which existed > at the time of package generation is better than the current > situation. They ought to come and go with the package itself. > Confusing? You betcha, many developers are suprised when they look for their edits to spec files to appear with "rpm -qi foo". But that's a process (i.e. send patch to docs team, not edit spec file) rather than a packaging problem. rpm can go several ways here. If I go the way I want, then description/summary/group will be removed from packages entirely and problem will cease to exist. Controversial? You betcha, as it appears that I'm trying to deny users access to descriptions of packages when in fact something else is intended. > > nor is there (or at least gas there been) > > sufficient time late in a release cycle to manage "make world" > > rebuilds to include i18n, too many things can break. > > That could of course be a problem. > > To me it seems it would be possible to freeze descriptions of the new > packages earlier. Like already by now in the current cycle. And also > make them available for translation at this time. Then they could be > there when the final build is done. > We've tried freeze, there's often too much package rearrangement during a release cycle for an early freeze to be effective. Might work now, but there's still lots of package churn. > > c) the goal must be to have i18n tags in metadata, fetching from > > the payload is a costly decompression. > > I must have misunderstood something. In message > <20030724114226.Q18401 at devserv.devel.redhat.com> you said: > > > IMHO: i18n does not belong in rpm metadata anymore than i18n belongs in > > tar/cpio headers. Keep i18n out of packages, please. > > I understood that to mean that you did not want the translations in > the metadata. So I tried to sketch things obeying that, putting them > elsewhere. > Sorry, my bad. There are 2 issues here: a) using already existing metadata tag values as retrieval keys for i18n from somewhere. b) the somewhere should not be the package payload because that will slow down the installer while the payload is read, looking for description/summary/group. In fact, because of genhdlist, anaconda does most of it's work without payloads being available. > But maybe I misunderstood this comment. If so, I guess one could try > to extend the current "%description -l ...". As I understand it, this > does become package metadata; at least it winds up in the Packages > database file. > > As you pointed out, this lacks coding information. Also, putting all > translations in the spec file is not very convenient. They need to be > fetched externally at build time. But if this is an acceptable > method, these problems probably could be solved. > And, yes, the old means of adding text to spec files still exists, will probably exist forever. Red Hat has not used this since 6.1, and is very unlikely to return to this mechanism. OTOH, it does mostly solve the 3rd party single package i18n problem, the only thing that breaks is when there are package name collisions, specspo is preferred to header content. I question whether identically named package is really 3rd party packaging, but making the header tag retrieval order configurable (i.e. prefer header over domains, or vice versa) is one approach if that too needs solving. > > Sure your scheme makes sense, but is possibly different than what rpm > > has been doing since 6.2. There are consequences for having to support > > multiple schemes for the indefinite future, not the least of which is > > the complexity involved. > > Point taken. > > > IMHO the apparent driving force for revisiting an already solved problem > > is the perceived need to accomodate 3rd party package group/summary/description. > > > > Personally, I have yet to meet (or hear of) any single person who has even > > attempted the translation. > > Are we talking about translations of descriptions at all? Or only > through external po files? I was referring to summary/description/group. > > I always include Swedish versions when I build packages of my own. > (After rhcontrib.bero.org died, I've mostly circulated them among > friends. Some could probably still be found out there; rpmfind found > a stickers package for example.) > > I may be uncommon doing this. But then again, including translations > in the SPEC file is not very convenient. And is "%description -l" > documented anywhere except for the change log and the source code? > There is a chance not everybody is aware of the possibility. :-) > Again, I'm not at all averse to improving the subtleties of i18n handling in packages as long as rpm package format doesn't have to change; afaict the existing specspo mechanism can be used to have per-package domains quite easily. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From P at draigBrady.com Wed Jul 30 16:36:48 2003 From: P at draigBrady.com (P at draigBrady.com) Date: Wed, 30 Jul 2003 17:36:48 +0100 Subject: new package Message-ID: <3F27F420.3060606@draigBrady.com> Hi, I noticed with great interest the announcement of the more open development model for rhl, and with that in mind I'm wondering about the process to follow for the possible inclusion of: http://www.pixelbeat.org/fslint cheers, P?draig. From jeremyp at pobox.com Wed Jul 30 21:07:56 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: 30 Jul 2003 17:07:56 -0400 Subject: BitTorrent enabled downloads & updates In-Reply-To: <1059538002.28944.54.camel@binkley> References: <1059083610.23202.68.camel@amr.math.utah.edu> <1059538002.28944.54.camel@binkley> Message-ID: <1059599276.24642.47.camel@jeremy.dtcc.cc.nc.us> On Wed, 2003-07-30 at 00:06, seth vidal wrote: > > > > I figured this made so much sense that someone else has already thought > > of it and perhaps already implemented it. Anyone know if that's the > > case? If not, does that idea sound interesting to others? > > It could be interesting but remember- bittorrent is mostly useful for > large files - not for trivially sized things like any single rpm. > Depends, somes RPMs are quite large -- mozilla, OpenOffice.org, kernel-source, etc. But the demand wouldn't be nearly as high, I don't think, and BitTorrent works well when there's high demand. Of course, demand is sometimes high when security errata come out...hmm. --Jeremy -- /---------------------------------------------------------------------\ | Jeremy Portzer jeremyp at pobox.com trilug.org/~jeremy | | GPG Fingerprint: 712D 77C7 AB2D 2130 989F E135 6F9F F7BC CC1A 7B92 | \---------------------------------------------------------------------/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alikins at redhat.com Wed Jul 30 22:32:28 2003 From: alikins at redhat.com (Adrian Likins) Date: Wed, 30 Jul 2003 18:32:28 -0400 Subject: BitTorrent enabled downloads & updates In-Reply-To: <1059599276.24642.47.camel@jeremy.dtcc.cc.nc.us>; from jeremyp@pobox.com on Wed, Jul 30, 2003 at 05:07:56PM -0400 References: <1059083610.23202.68.camel@amr.math.utah.edu> <1059538002.28944.54.camel@binkley> <1059599276.24642.47.camel@jeremy.dtcc.cc.nc.us> Message-ID: <20030730183228.D10926@redhat.com> On Wed, Jul 30, 2003 at 05:07:56PM -0400, Jeremy Portzer wrote: > On Wed, 2003-07-30 at 00:06, seth vidal wrote: > > > > > > > I figured this made so much sense that someone else has already thought > > > of it and perhaps already implemented it. Anyone know if that's the > > > case? If not, does that idea sound interesting to others? > > > > It could be interesting but remember- bittorrent is mostly useful for > > large files - not for trivially sized things like any single rpm. > > > > Depends, somes RPMs are quite large -- mozilla, OpenOffice.org, > kernel-source, etc. But the demand wouldn't be nearly as high, I don't > think, and BitTorrent works well when there's high demand. Of course, > demand is sometimes high when security errata come out...hmm. > Discussions with Bram Cohen seemed to indicate it probabaly wasn't workable for package updates, so the idea never really got off the backburner. Newer BitTorrents look like they might have some support for picking out small pieces of big archives, so maybe it could work. Adrian From jos at xos.nl Thu Jul 31 09:22:54 2003 From: jos at xos.nl (Jos Vos) Date: Thu, 31 Jul 2003 11:22:54 +0200 Subject: Perl module rpm dependency problem Message-ID: <200307310922.h6V9MsH04099@xos037.xos.nl> Hi, I'm trying to package the Perl XML-SAX module. I'm using the Perl __find_{requires,provides} redefines etc. in the spec file. I end up with a package containing (I've left the docs out of this list): /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/Base.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/DocumentLocator.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/Exception.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/Intro.pod /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/ParserFactory.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/DTDDecls.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/DebugHandler.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/DocType.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/EncodingDetect.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Exception.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/NoUnicodeExt.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Productions.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader/NoUnicodeExt.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader/Stream.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader/String.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader/URI.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/Reader/UnicodeExt.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/UnicodeExt.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/PurePerl/XMLDecl.pm /usr/lib/perl5/vendor_perl/5.8.0/XML/SAX/placeholder.pl The package says to require (I only list the perl(...) entries): perl(Carp) perl(Encode) perl(Exporter) perl(File::Basename) perl(File::Spec) perl(File::Temp) perl(IO::File) perl(Symbol) perl(XML::NamespaceSupport) perl(XML::SAX) perl(XML::SAX::Base) perl(XML::SAX::DocumentLocator) perl(XML::SAX::Exception) perl(XML::SAX::ParserFactory) perl(XML::SAX::PurePerl::DTDDecls) perl(XML::SAX::PurePerl::DocType) perl(XML::SAX::PurePerl::EncodingDetect) perl(XML::SAX::PurePerl::Productions) perl(XML::SAX::PurePerl::Reader) perl(XML::SAX::PurePerl::Reader::Stream) perl(XML::SAX::PurePerl::Reader::String) perl(XML::SAX::PurePerl::Reader::URI) perl(XML::SAX::PurePerl::XMLDecl) perl(constant) perl(overload) perl(strict) perl(utf8) perl(vars) But now the problem, it says to provide (I only list perl(...) entries): perl(XML::SAX) = 0.12 perl(XML::SAX::Base) = 1.04 perl(XML::SAX::Base::NoHandler) perl(XML::SAX::DocumentLocator) perl(XML::SAX::Exception) = 1.01 perl(XML::SAX::ParserFactory) = 1.01 perl(XML::SAX::PurePerl) perl(XML::SAX::PurePerl) = 0.90 perl(XML::SAX::PurePerl::DebugHandler) perl(XML::SAX::PurePerl::Exception) perl(XML::SAX::PurePerl::Productions) perl(XML::SAX::PurePerl::Reader) perl(XML::SAX::PurePerl::Reader::Stream) perl(XML::SAX::PurePerl::Reader::String) perl(XML::SAX::PurePerl::Reader::URI) So, when I try to install it, it says: error: Failed dependencies: perl(XML::SAX::PurePerl::DTDDecls) is needed by perl-XML-SAX-0.12-XOS.1beta1 perl(XML::SAX::PurePerl::DocType) is needed by perl-XML-SAX-0.12-XOS.1beta1 perl(XML::SAX::PurePerl::EncodingDetect) is needed by perl-XML-SAX-0.12-XOS.1beta1 perl(XML::SAX::PurePerl::XMLDecl) is needed by perl-XML-SAX-0.12-XOS.1beta1 But thes things *are* included, but not seen by the find_provides script? Puzzled... -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From ville.skytta at iki.fi Thu Jul 31 15:42:41 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: 31 Jul 2003 18:42:41 +0300 Subject: Perl module rpm dependency problem In-Reply-To: <200307310922.h6V9MsH04099@xos037.xos.nl> References: <200307310922.h6V9MsH04099@xos037.xos.nl> Message-ID: <1059666161.3458.26.camel@bobcat.mine.nu> On Thu, 2003-07-31 at 12:22, Jos Vos wrote: > Hi, > > I'm trying to package the Perl XML-SAX module. I'm using the > Perl __find_{requires,provides} redefines etc. in the spec file. [snip] > error: Failed dependencies: > perl(XML::SAX::PurePerl::DTDDecls) is needed by perl-XML-SAX-0.12-XOS.1beta1 > perl(XML::SAX::PurePerl::DocType) is needed by perl-XML-SAX-0.12-XOS.1beta1 > perl(XML::SAX::PurePerl::EncodingDetect) is needed by perl-XML-SAX-0.12-XOS.1beta1 > perl(XML::SAX::PurePerl::XMLDecl) is needed by perl-XML-SAX-0.12-XOS.1beta1 > > But thes things *are* included, but not seen by the find_provides script? If you peek at the affected files, you'll see that they actually are not "included" as far as rpm is concerned. rpm looks at the "package foo" statements when building the list of Provides, and "use/require foo" for Requires. Those files do not have a package of their own, instead they blend into the XML::SAX::PurePerl package. And perl allows one to use() them using the fully qualified, "fake" package name (based on the dir structure, I believe). The approach I took (see http://cachalot.mine.nu/9/) was to manually add the following to satisfy the deps (NoUnicodeExt and Unicode just for consistency): Provides: perl(XML::SAX::PurePerl::DocType) Provides: perl(XML::SAX::PurePerl::DTDDecls) Provides: perl(XML::SAX::PurePerl::EncodingDetect) Provides: perl(XML::SAX::PurePerl::NoUnicodeExt) Provides: perl(XML::SAX::PurePerl::UnicodeExt) Provides: perl(XML::SAX::PurePerl::XMLDecl) -- \/ From jos at xos.nl Thu Jul 31 21:17:47 2003 From: jos at xos.nl (Jos Vos) Date: Thu, 31 Jul 2003 23:17:47 +0200 Subject: Perl module rpm dependency problem In-Reply-To: <1059666161.3458.26.camel@bobcat.mine.nu>; from ville.skytta@iki.fi on Thu, Jul 31, 2003 at 06:42:41PM +0300 References: <200307310922.h6V9MsH04099@xos037.xos.nl> <1059666161.3458.26.camel@bobcat.mine.nu> Message-ID: <20030731231747.A6058@xos037.xos.nl> On Thu, Jul 31, 2003 at 06:42:41PM +0300, Ville Skytt? wrote: > If you peek at the affected files, you'll see that they actually are not > "included" as far as rpm is concerned. rpm looks at the "package foo" > statements when building the list of Provides, and "use/require foo" for > Requires. Ah yes, ok, then I shouldn't blame rpm's scripts. > Those files do not have a package of their own, instead they blend into > the XML::SAX::PurePerl package. And perl allows one to use() them using > the fully qualified, "fake" package name (based on the dir structure, I > believe). What about packaging XML-SAX-PurePerl? Shouldn't that solve the problem? I have to admit I don't know much about this area, but I needed XML-SAX because it is required by XML-LibXML. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jbj at redhat.com Thu Jul 31 21:26:44 2003 From: jbj at redhat.com (Jeff Johnson) Date: Thu, 31 Jul 2003 17:26:44 -0400 Subject: Perl module rpm dependency problem In-Reply-To: <20030731231747.A6058@xos037.xos.nl>; from jos@xos.nl on Thu, Jul 31, 2003 at 11:17:47PM +0200 References: <200307310922.h6V9MsH04099@xos037.xos.nl> <1059666161.3458.26.camel@bobcat.mine.nu> <20030731231747.A6058@xos037.xos.nl> Message-ID: <20030731172644.C32372@devserv.devel.redhat.com> On Thu, Jul 31, 2003 at 11:17:47PM +0200, Jos Vos wrote: > On Thu, Jul 31, 2003 at 06:42:41PM +0300, Ville Skytt? wrote: > > > If you peek at the affected files, you'll see that they actually are not > > "included" as far as rpm is concerned. rpm looks at the "package foo" > > statements when building the list of Provides, and "use/require foo" for > > Requires. > > Ah yes, ok, then I shouldn't blame rpm's scripts. Actually, the final fix needs to be in rpm helper scripts, there's a couple of regex's that need tweaking or special casing. Because of the nature of drilling an entire dependency tree, a global approach is needed, case by case is better hacked around with %__find_requires. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From dag at wieers.com Thu Jul 31 21:40:58 2003 From: dag at wieers.com (Dag Wieers) Date: Thu, 31 Jul 2003 23:40:58 +0200 (CEST) Subject: Perl module rpm dependency problem In-Reply-To: <20030731231747.A6058@xos037.xos.nl> Message-ID: On Thu, 31 Jul 2003, Jos Vos wrote: > On Thu, Jul 31, 2003 at 06:42:41PM +0300, Ville Skytt? wrote: > > > If you peek at the affected files, you'll see that they actually are not > > "included" as far as rpm is concerned. rpm looks at the "package foo" > > statements when building the list of Provides, and "use/require foo" for > > Requires. > > Ah yes, ok, then I shouldn't blame rpm's scripts. The find-requires.perl and find-provides.perl are obsoleted. They're just using the normal find-requires and find-provides scripts. It was Matthias who thaught me that ;) > > Those files do not have a package of their own, instead they blend into > > the XML::SAX::PurePerl package. And perl allows one to use() them using > > the fully qualified, "fake" package name (based on the dir structure, I > > believe). > > What about packaging XML-SAX-PurePerl? Shouldn't that solve the > problem? I have to admit I don't know much about this area, but > I needed XML-SAX because it is required by XML-LibXML. I have them packaged without the problems you mention. You can find them (and the SPEC files) at: http://dag.wieers.com/packages/ All my perl packages share the same logic (there's a small difference between binary and noarch packages though). Kind regards, -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From ville.skytta at iki.fi Thu Jul 31 21:44:36 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: 01 Aug 2003 00:44:36 +0300 Subject: Perl module rpm dependency problem In-Reply-To: <20030731231747.A6058@xos037.xos.nl> References: <200307310922.h6V9MsH04099@xos037.xos.nl> <1059666161.3458.26.camel@bobcat.mine.nu> <20030731231747.A6058@xos037.xos.nl> Message-ID: <1059687876.3458.102.camel@bobcat.mine.nu> On Fri, 2003-08-01 at 00:17, Jos Vos wrote: > > Those files do not have a package of their own, instead they blend into > > the XML::SAX::PurePerl package. And perl allows one to use() them using > > the fully qualified, "fake" package name (based on the dir structure, I > > believe). > > What about packaging XML-SAX-PurePerl? Shouldn't that solve the > problem? Hm, by XML::SAX::PurePerl "package" I meant the Perl module "namespace", not a RPM or any other package. And the PurePerl modules are already part of the XML-SAX CPAN distribution. Or did I miss something here? > I have to admit I don't know much about this area, but > I needed XML-SAX because it is required by XML-LibXML. Good luck! Tried it too and had to give up because of (IIRC) some libxml2 weirdness/incompatibilities (RHL9); "make test" resulted in segfaults, be sure to run it :) (libxml2 2.5.4 isn't explicitly listed in http://search.cpan.org/src/PHISH/XML-LibXML-1.54/README but 2.5.5 is "known as broken"...) -- \/ From goeran at uddeborg.se Thu Jul 31 22:22:30 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran?= Uddeborg) Date: Fri, 1 Aug 2003 00:22:30 +0200 Subject: RFC: i18n proposal In-Reply-To: <20030730120143.D32372@devserv.devel.redhat.com> References: <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> <16161.41106.591644.103709@uebn.uddeborg.se> <20030728123604.A6922@devserv.devel.redhat.com> <16166.59811.357179.684255@uebn.uddeborg.se> <20030729205204.B12088@devserv.devel.redhat.com> <20030730120143.D32372@devserv.devel.redhat.com> Message-ID: <16169.38566.288052.562054@uebn.uddeborg.se> Jeff Johnson writes: > If the intent is to have one domain per-package, the current implementation > already supports this. I start to feel, during this discussion, goal and implementation has become a bit confused. I'm surely guilty, starting my posts by an attempt to suggest an implementation of my interpretation of Havoc's suggestion. I'll try to clarify MY goals. As a RHL user I want the description (etc.), including translations, come, change, and go with the package. I don't want them to be modified when a different, technically unrelated, package is modified. Having one domain per package and including that domain with the package, is one way to implement that. Having all descriptions in the meta-data is another way. There are surely other ways. As a packager of third party packages I want an easy way to maintain the description, and to receive translations of it. That was why I thought around having rpmbuild pick up translations at build time from po-files laying around. If I also am the author of the software I package, it would be convenient to put all messages from the program(s) proper and the spec file description in one po file and make that available for translation. (Doing some kind of "gettext" on the spec file.) If I package someone elses software, it would be more reasonable to provide a separate po file for translators. Manually copying translations back and forth between po files and spec files is not very convenient, obviously. As a translator of RHL descriptions (a.k.a. "specspo") I want the descriptions be available in a format which is easy to translate and maintain. The current specspo is fine for this! (It is huge, and took a long time to do. But that would not have been different with some other packaging.) As a translator of other's third party packages I want the same thing as for RHL packages, a convenient format. Of course I would expect to get it individually for each package, and not collected together with other unrelated packages. But po files are good again. That's several "I want"s. I'm not saying one solution should fullfill all, and I'm not at all saying they MUST be fullfilled before any other problem. But if one of them could be fulfilled, it would be better than none. > a) configure the new translation domain in /etc/rpm/macros.specspo > (or any of the zillions of places that a macro can be defined) > %_i18ndomains redhat:foo Do you envisage some way to do this automatically on (un)installation of packages? So that each package can carry it's own translations? Or just a different default value coming with the same specspo package still carrying all translations? That's would be important given my first point above. And I'm not sure exactly what you are suggesting. From goeran at uddeborg.se Thu Jul 31 22:22:47 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran?= Uddeborg) Date: Fri, 1 Aug 2003 00:22:47 +0200 Subject: RFC: i18n proposal In-Reply-To: <20030730123208.E32372@devserv.devel.redhat.com> References: <87lluosufk.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030723213756.B9605@devserv.devel.redhat.com> <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> <16161.41106.591644.103709@uebn.uddeborg.se> <20030728123604.A6922@devserv.devel.redhat.com> <16166.59811.357179.684255@uebn.uddeborg.se> <20030730123208.E32372@devserv.devel.redhat.com> Message-ID: <16169.38583.311228.873941@uebn.uddeborg.se> Jeff Johnson writes: > Unlike, say, error messages with xgettext *.c, summary/description/group > are much softer, so text divergence is acceptable. > > Yes, that's a feature, at least for the docs team editors, because text > can be updated in the field without having to wait for "make world" > \of the next distro release. I'm not sure about your argumentation here. WHY are these particular messages "softer" than others, and divergence more acceptable for them. And WHY is it important to be able to update these particular messages in the field and not others. It could very well be that we simply have different opinions; that your feature is my bug. But I feel I don't understand your reasoning. I don't understand your motivation for the statements above. So I'm not sure. If a package needs to be updated, being because of a bug fix in the code, a changed description, or an corrected dependecy, the natural thing would be to issue an errata for that particular package, it seems to me. I fail to see why descriptions and summaries are so very different from other documentation in the package. > > But maybe I misunderstood this comment. If so, I guess one could try > > to extend the current "%description -l ...". > And, yes, the old means of adding text to spec files still exists, > will probably exist forever. [...] > OTOH, it does mostly > solve the 3rd party single package i18n problem, the only thing that > breaks is when there are package name collisions, specspo is preferred to > header content. Rather than name collisions I'm more concerned about the lack of coding information. And, AFAIK, the lack of tools to automatically pick up contributed translations.