From caw at cs.mu.oz.au Tue Dec 2 01:08:51 2003 From: caw at cs.mu.oz.au (Chris Wright) Date: Tue, 02 Dec 2003 12:08:51 +1100 Subject: python / tkinter interaction Message-ID: <1070327331.3046.47.camel@localhost.localdomain> Tkinter seems to fail [root at localhost caw]# apt-get install tkinter Reading Package Lists... Done Building Dependency Tree... Done tkinter is already the newest version. 0 upgraded, 0 newly installed, 0 removed and 0 not upgraded. [root at localhost caw]# python Python 2.2.3 (#1, Oct 15 2003, 23:33:35) [GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> Tkinter._test() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 3118, in _test label = Label(root, text=text) File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 2285, in __init__ Widget.__init__(self, master, 'label', cnf, kw) File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 1780, in __init__ self.tk.call( SystemError: Py_UNICODE and Tcl_UniChar differ in size >>> What's the right place to help sort this out? cheers Chris -- Chris Wright Medical Director, ICU Monash Medical Centre Clayton, VIC AUSTRALIA From livelinux at nwst.de Mon Dec 1 08:47:14 2003 From: livelinux at nwst.de (we) Date: Mon, 1 Dec 2003 09:47:14 +0100 Subject: comps - xml/xls file parser Message-ID: <200312010947.14799.livelinux@nwst.de> Hi all, while porting my livecd from redhat 9 to fedora core 1, i wrote a simple xsl processor script to inspect redhat comps installation files. The script also gives a quick overview about package/group dependencies : the installation state (mandatory, default or optional) is indicated by the colors red, green and blue. The script parses the comps.xml tree and outputs each group and package nodes, showing information such as package name and description, required groups and packages etc. Default output language is 'de', can be tweaked in the xls script.. To work, the comps file must include the xsl file using this tag : You can see a screenshot and download the script (73kb) at: http://www.linux4all.de/distribution/comps/ Notes: - Works reliable with mozilla 1.5. - Internet Explorer works not. (as expected.) - tested with fedora core 1 comps.xml file. - Please drop me a line if you find it usefull. greetings, Dirk From livelinux at nwst.de Mon Dec 1 09:29:07 2003 From: livelinux at nwst.de (Dirk Westfal) Date: Mon, 1 Dec 2003 10:29:07 +0100 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 Message-ID: <200312011029.07917.livelinux@nwst.de> Hi, I've already developed a redhat 9.0 based xkde live cd , and this weekend i've ported this cd to fedora core 1. Now I'm looking for beta - testers as well as opinions and suggestions what software should be included etc. If anyone out there is interested in this project (testing, suggesting etc), please drop me a line ;-) The current package list for fedora based livecd is aviable here: http://www.linux4all.de/distribution/fedora-core-1/comps/rpmlist-ws-fedora-core1-A.txt thanks in advance, Dirk ( for the redhat 9.0 cd : see : http://www.linux4all.de/ws-basilisk-1.0-guide/index.htm download : http://www.linux4all.de/downloads/basilisk-1.0.iso.bz2 ) From buildsys at porkchop.devel.redhat.com Mon Dec 1 12:08:45 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Mon, 1 Dec 2003 07:08:45 -0500 Subject: rawhide report: 20031201 changes Message-ID: <200312011208.hB1C8j722594@porkchop.devel.redhat.com> Updated Packages: XFree86-4.3.0-45 ---------------- * Sun Nov 30 2003 Mike A. Harris 4.3.0-45 - Implemented new AGP/PCI autodetection in the Radeon driver by examining PCI configuration space and walking the PCI extended capabilities list in order to determine if the device implements the AGP capability. This code should work on _any_ AGP/PCI hardware generically and should be factored out into generic X server code in future XFree86 releases so all drivers can benefit from it. XFree86-4.3.0-radeon-agp-detection-using-capability-list-walk.patch should fix all Radeon PCI/AGP autodetection bugs, including (#111191). Some AGP Radeon users may experience a performance boost with this new driver if their card was misdetected and treated as PCI before, as pcigart mode works on AGP hardware, but is slower than using AGP. - Fixed build_rawhide to work the same as build_yarrow everywhere since the two are functionally identical for the time being. * Wed Nov 26 2003 Mike A. Harris 4.3.0-44.EL - Rebuilt 4.3.0-44 as 4.3.0-44.EL for RHEL3 QU1 update make-3.80-1 ----------- * Sun Nov 30 2003 Florian La Roche - update to 3.80 openssl-0.9.7a-26 ----------------- * Sun Nov 30 2003 Tim Waugh 0.9.7a-26 - Fix link line for libssl (bug #111154). rpmdb-fedora-1.90-0.20031201 ---------------------------- xmlto-0.0.17-1 -------------- * Mon Dec 01 2003 Tim Waugh 0.0.17-1 - 0.0.17. zlib-1.2.1-1 ------------ * Sun Nov 30 2003 Florian La Roche - update to 1.2.1 release From Nicolas.Mailhot at laPoste.net Mon Dec 1 13:16:09 2003 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 01 Dec 2003 14:16:09 +0100 Subject: rawhide report: 20031201 changes In-Reply-To: <200312011208.hB1C8j722594@porkchop.devel.redhat.com> References: <200312011208.hB1C8j722594@porkchop.devel.redhat.com> Message-ID: <1070284569.12200.58.camel@ulysse.olympe.o2t> Le lun 01/12/2003 ? 13:08, Build System a ?crit : > > > Updated Packages: > > XFree86-4.3.0-45 > ---------------- > * Sun Nov 30 2003 Mike A. Harris 4.3.0-45 > > - Implemented new AGP/PCI autodetection in the Radeon driver by examining PCI > configuration space and walking the PCI extended capabilities list in order > to determine if the device implements the AGP capability. BTW since XFree86-4.3.0 seems to be still alive Rawhide XFree86 gaves me whitewhashed screens on a radeon 9200 while it's ok using Alan Hourihane binary snapshot. Cheers, -- Nicolas Mailhot -------------- 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 raven at themaw.net Mon Dec 1 14:22:38 2003 From: raven at themaw.net (Ian Kent) Date: Mon, 1 Dec 2003 22:22:38 +0800 (WST) Subject: Self-Introduction: Ian Kent Message-ID: Ian Maxwell Kent Australia, Perth Profession: Computing - Infrastructure and Operations Company: Woodside Energy - on contract via Icon Recruitment I don't speak for Woodside, Open Source development is a part time activity for me. Goals here: 1) As maintainer of the autofs v4 package I would like to see my package included in Fedora and hopefully have it migrated into the RedHat Professional distribution. 2) Have my autofs4 kernel module patch (supporting above package) into the distribution kernel. 3) Have the QA system of Fedora help with the testing of above packages. Historical qualifications: None really! Languages are C, Perl, Fortran and a little C++ and Java. Trust me? Well you will have to work that out for yourselves. There is no reason not to trust me. I have contributed considerable time to my automounter project over the last couple of years and would like to see a wider audience take advantage of the enhancements I have made. GPG KEYID: pub 1024D/D4BEE989 2003-09-03 Ian Kent Key fingerprint = E16B E1A9 F99B 3413 B903 613C 7966 66EC D4BE E989 sub 1024g/42074EC9 2003-09-03 -- ,-._|\ Ian Kent / \ Perth, Western Australia *_.--._/ E-mail: raven at themaw.net v Web: http://themaw.net/ From stan at ccs.neu.edu Mon Dec 1 14:44:15 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Mon, 01 Dec 2003 09:44:15 -0500 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <200312011029.07917.livelinux@nwst.de> References: <200312011029.07917.livelinux@nwst.de> Message-ID: <1070289854.1693.25.camel@duergar> On Mon, 2003-12-01 at 04:29, Dirk Westfal wrote: > Hi, > > I've already developed a redhat 9.0 based xkde live cd , > and this weekend i've ported this cd to fedora core 1. > > Now I'm looking for beta - testers as well as opinions and suggestions > what software should be included etc. > > If anyone out there is interested in this project (testing, suggesting etc), > please drop me a line ;-) > > The current package list for fedora based livecd is aviable here: > http://www.linux4all.de/distribution/fedora-core-1/comps/rpmlist-ws-fedora-core1-A.txt > > > thanks in advance, > > Dirk > > ( for the redhat 9.0 cd : > see : http://www.linux4all.de/ws-basilisk-1.0-guide/index.htm > download : http://www.linux4all.de/downloads/basilisk-1.0.iso.bz2 ) > Dirk, I think its a great idea. I'll gladly help test if you point me to the image(s). I've been using Knoppix to get friends to try out Linux, I could definitely get a few more computer science science students to test it as well. -sb From orospakr at infomaninc.dyndns.org Mon Dec 1 16:25:54 2003 From: orospakr at infomaninc.dyndns.org (Andrew Clunis) Date: Mon, 01 Dec 2003 11:25:54 -0500 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <200312011029.07917.livelinux@nwst.de> References: <200312011029.07917.livelinux@nwst.de> Message-ID: <1070295953.6386.3.camel@localhost.localdomain> Hello, I'd be very interested in seeing a FC1 LiveCD, I'd like to test it, and I have a number of friends and colleagues who would be very interested too. BTW, please include GNU Parted... unbelievably handy to have on a bootable CD. Many thanks, Andrew On Mon, 2003-12-01 at 04:29, Dirk Westfal wrote: > Hi, > > I've already developed a redhat 9.0 based xkde live cd , > and this weekend i've ported this cd to fedora core 1. > > Now I'm looking for beta - testers as well as opinions and suggestions > what software should be included etc. > > If anyone out there is interested in this project (testing, suggesting etc), > please drop me a line ;-) > > The current package list for fedora based livecd is aviable here: > http://www.linux4all.de/distribution/fedora-core-1/comps/rpmlist-ws-fedora-core1-A.txt > > > thanks in advance, > > Dirk > > ( for the redhat 9.0 cd : > see : http://www.linux4all.de/ws-basilisk-1.0-guide/index.htm > download : http://www.linux4all.de/downloads/basilisk-1.0.iso.bz2 ) > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- 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 johnsonm at redhat.com Mon Dec 1 18:27:31 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 1 Dec 2003 13:27:31 -0500 Subject: FC1 tag in ethereal-0.9.16-2.FC1.1.i386.rpm In-Reply-To: <20031126213409.GB27249@puariko.nirvana> References: <87smkbq71l.fsf@kosh.ultra.csn.tu-chemnitz.de> <20031126194413.GA9437@devserv.devel.redhat.com> <1069820616.13740.10.camel@proton.cygnusx-1.org> <20031126074437.GD7622@puariko.nirvana> <20031126182028.GA13830@devserv.devel.redhat.com> <87smkbq71l.fsf@kosh.ultra.csn.tu-chemnitz.de> <1069820616.13740.10.camel@proton.cygnusx-1.org> <20031126074437.GD7622@puariko.nirvana> <20031126182028.GA13830@devserv.devel.redhat.com> <20031126213409.GB27249@puariko.nirvana> Message-ID: <20031201182731.GA23751@devserv.devel.redhat.com> On Wed, Nov 26, 2003 at 10:34:09PM +0100, Axel Thimm wrote: > On Wed, Nov 26, 2003 at 01:20:28PM -0500, Michael K. Johnson wrote: > On Wed, Nov 26, 2003 at 02:44:13PM -0500, Michael K. Johnson wrote: > > Sorry, I think I was operating on insufficient context. I was > > stuck in the base distribution -- Fedora Core, not third party > > repositories. Please excuse that... > > Even within the Red Hat ecosystem a standardized way to tag concurrent > versions for different distros would not hurt. Currently it is really > up to the (redhat.com) packager to decide on versioning. This freedom > is sometimes used like an artistic freedom (yes, packagers are artists ;) We put any tags far enough down in the revision number not to generate any need for epoch. We basically use suficiently consistent revision numbers, and then put any additional information beyond them off at the very end of the string, and they add information without creating an epoch problem. 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 Dec 1 19:06:10 2003 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 01 Dec 2003 21:06:10 +0200 Subject: CPAN RPM archive? In-Reply-To: <1070268624.1693.21.camel@duergar> References: <1070142405.19063.10.camel@duergar> <20031130005200.GA15845@chrisgrau.com> <1070175886.19063.23.camel@duergar> <20031130081032.GA17351@chrisgrau.com> <1070193762.6099.9.camel@laptop> <1070198108.25525.130.camel@bobcat.mine.nu> <1070268624.1693.21.camel@duergar> Message-ID: <1070305570.4377.24.camel@bobcat.mine.nu> [fedora-devel-list back to Cc and quoted in full, I don't know if the copy was accidentally omitted] On Mon, 2003-12-01 at 10:50, Stan Bubrouski wrote: > On Sun, 2003-11-30 at 08:15, Ville Skytt?? wrote: > > Some minor corrections and my IMHO, YMMV status: > > > > I haven't really looked into cpan2rpm but I have made some improvements > > to the perl-RPM-Specfile package (be sure to grab the fedora.us version > > as all changes have been submitted upstream, but not applied yet). > > Good to know, but this is not enough. I agree. But for whatever reason, since people tend to use these tools anyway, improving them shouldn't hurt. > > Anyway, both cpanflute2 and cpan2rpm produce pretty obfuscated > > specfiles. Instead of using them, there's a bunch of perl-* packages in > > the www.fedora.us/QA queue (and lots more not-yet-submitted ones at > > cachalot.mine.nu/1/SRPMS.fdr/) which are based on a template which is > > based on earlier discussions in bugzilla.fedora.us and fedora-devel at > > fedora.us list. > > > Still there are not enough packages handled to be useful for the masses > of perl programmers. But of course not. I have no intention to package the whole CPAN, and I hope nobody else tries it alone either :) 20-30 modules is pretty manageable per packager though. > I myself typically end up requiring 20-30 modules > for one project alone. This has given me the motivation to pursue this > fully and I intend to begin the process of creating packages for every > perl module to start with, then automating building from there. I have more confidence in packagers continuously cross-QA'ing each others work than the above (alone). Automating is good whenever it makes sense though. > > I've just submitted the specfile template to > > https://bugzilla.fedora.us/show_bug.cgi?id=1010 for comments. > > cpanflute2 and/or cpan2rpm could possibly be tweaked more towards this. > > The main difference currently with the template and cpanflute2 is that > > the template takes care of removing more unneeded files and bluntly > > works around the unowned dirs issue in the past and current RH and FC > > perl packages, > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73970 > > > > I'm past thinking of using those automated cpan2rpm type tools. I've > gotten enough response where I feel that we need to handle each package > individually and build a repository from there. +1 > Contributions are more than welcome (of spec files of course). > ATRPMs is willing to accept > submissions, which works for me. In the meantime I can host a testing > repository for packages until something more formal is worked out. I'm personally more comfortable with the fedora.us process, it has been designed for submissions and has almost all the building blocks in place already, even if there are some rough edges here and there. > > For some weird reason, even though perl module packages (especially when > > a template is consistently used) are trivial to review, the QA process > > seems to take a long time. Help is certainly welcome in this area. > > > > It's not wierd at all. Let me rephrase: I find the (lack|rarity) of reviews weird, given that interested folks certainly exist. > It takes a long time to ensure that everything > in a perl CPAN module is handled correctly. And correctness is exactly > what I'm striving for. Little bugs will not do. My intention is to get > this started right from the get-go, that means cpan2rpm for instance > is out. Individual spec files need to be made for each module initially > (although a template would be great for about half, and if you can help > with this please let me know). I appreciate any and all help, afterall > we are a community (feel free to make suggestions or call me an idiot, I > thrive off of criticism) ;-) Well, we seem to have similar goals. I'd suggest taking advantage of the fedora.us submission/QA procedures at least until the corresponding fedora.redhat.com is completely up and running. From stan at ccs.neu.edu Mon Dec 1 19:37:45 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Mon, 01 Dec 2003 14:37:45 -0500 Subject: CPAN RPM archive? In-Reply-To: <1070305570.4377.24.camel@bobcat.mine.nu> References: <1070142405.19063.10.camel@duergar> <20031130005200.GA15845@chrisgrau.com> <1070175886.19063.23.camel@duergar> <20031130081032.GA17351@chrisgrau.com> <1070193762.6099.9.camel@laptop> <1070198108.25525.130.camel@bobcat.mine.nu> <1070268624.1693.21.camel@duergar> <1070305570.4377.24.camel@bobcat.mine.nu> Message-ID: <1070307464.1693.39.camel@duergar> On Mon, 2003-12-01 at 14:06, Ville Skytt?? wrote: > [fedora-devel-list back to Cc and quoted in full, I don't know if the > copy was accidentally omitted] > Was a pm. Heh. Don't worry about it. > I agree. But for whatever reason, since people tend to use these tools > anyway, improving them shouldn't hurt. > I agree, but I don't feel like taking on anything that complicated. > But of course not. I have no intention to package the whole CPAN, and I > hope nobody else tries it alone either :) 20-30 modules is pretty > manageable per packager though. > I know that's why I want some help doing. I do however want all of CPAN packaged. This is something I think all distributions lack and something the community would definitely want. > > I myself typically end up requiring 20-30 modules > > for one project alone. This has given me the motivation to pursue this > > fully and I intend to begin the process of creating packages for every > > perl module to start with, then automating building from there. > > I have more confidence in packagers continuously cross-QA'ing each > others work than the above (alone). Automating is good whenever it > makes sense though. > I think the QA process is fine, but I think it would be burdonsome for the process. I dunno. > > > I've just submitted the specfile template to > > > https://bugzilla.fedora.us/show_bug.cgi?id=1010 for comments. > > > cpanflute2 and/or cpan2rpm could possibly be tweaked more towards this. > > > The main difference currently with the template and cpanflute2 is that > > > the template takes care of removing more unneeded files and bluntly > > > works around the unowned dirs issue in the past and current RH and FC > > > perl packages, > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73970 > > > > > > > I'm past thinking of using those automated cpan2rpm type tools. I've > > gotten enough response where I feel that we need to handle each package > > individually and build a repository from there. > > +1 > > > Contributions are more than welcome (of spec files of course). > > ATRPMs is willing to accept > > submissions, which works for me. In the meantime I can host a testing > > repository for packages until something more formal is worked out. > > I'm personally more comfortable with the fedora.us process, it has been > designed for submissions and has almost all the building blocks in place > already, even if there are some rough edges here and there. > Ok agreed, but this probably needs to coordinated externally to get it up and running. > > > For some weird reason, even though perl module packages (especially when > > > a template is consistently used) are trivial to review, the QA process > > > seems to take a long time. Help is certainly welcome in this area. > > > > > > > It's not wierd at all. > > Let me rephrase: I find the (lack|rarity) of reviews weird, given that > interested folks certainly exist. > Heh that makes more sense than what I thought you were saying. Agreed. > off of criticism) ;-) > > Well, we seem to have similar goals. I'd suggest taking advantage of > the fedora.us submission/QA procedures at least until the corresponding > fedora.redhat.com is completely up and running. > Ok so lets try to get some volunteers and get into planning :) -sb > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From stan at ccs.neu.edu Mon Dec 1 19:28:14 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Mon, 01 Dec 2003 14:28:14 -0500 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <1070295953.6386.3.camel@localhost.localdomain> References: <200312011029.07917.livelinux@nwst.de> <1070295953.6386.3.camel@localhost.localdomain> Message-ID: <1070306893.1693.33.camel@duergar> On Mon, 2003-12-01 at 11:25, Andrew Clunis wrote: > Hello, > > I'd be very interested in seeing a FC1 LiveCD, I'd like to test it, and > I have a number of friends and colleagues who would be very interested > too. BTW, please include GNU Parted... unbelievably handy to have on a > bootable CD. > I totally agree, its adds to the useful of the CD tenfold. -sb > Many thanks, > Andrew > From enrico.scholz at informatik.tu-chemnitz.de Mon Dec 1 19:51:26 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 01 Dec 2003 20:51:26 +0100 Subject: The current fedora.us buildsystem and future directions In-Reply-To: <1070061174.4351.8.camel@nexus.verbum.private> (Colin Walters's message of "Fri, 28 Nov 2003 18:12:55 -0500") References: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> <1070061174.4351.8.camel@nexus.verbum.private> Message-ID: <87r7zoiaf5.fsf@kosh.ultra.csn.tu-chemnitz.de> walters at verbum.org (Colin Walters) writes: >> 2. Is chroot(2) implemented in a safe manner? Or, can parent directories >> of build-roots be protected with SELinux policies? Is a safe chroot(2) >> required at all? > > Using SELinux, a chroot doesn't provide any additional direct security. > However, you may find it convenient to use a chroot in this instance so > that different sets of packages can be installed, etc. I am asking because of the following situation: there are two, (nearly) equal buildroots A & B in the directory tree like |- A `- B Can it be prohibited that A modifies files within B? Would it be possible to forbid any kind of access at for buildprocesses? >> 5. Can special mount-operations (e.g. /proc filesystem) be allowed by >> the policy, or does this require userspace helper also? > > The mount system call is restricted, yes. We will have to deal with mount -t proc none /proc vs. mount --bind trojan /bin/sh The first command MUST be supported, but the second one (inclusive variants) be forbidden. Enrico From enrico.scholz at informatik.tu-chemnitz.de Mon Dec 1 19:55:41 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 01 Dec 2003 20:55:41 +0100 Subject: The current fedora.us buildsystem and future directions In-Reply-To: <20031129022551.GA31280@devserv.devel.redhat.com> (Bill Nottingham's message of "Fri, 28 Nov 2003 21:25:51 -0500") References: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> <20031129022551.GA31280@devserv.devel.redhat.com> Message-ID: <87n0acia82.fsf@kosh.ultra.csn.tu-chemnitz.de> notting at redhat.com (Bill Nottingham) writes: >> 1. SELinux can protect foreign processes. But is it possible to hide >> them in /proc also? > > If you cannot access it, why does it matter if it is visible? E.g. 'service xyz stop' in rpm-scriptlets may have an unwanted behavior when it sees 'xyz' processes in other "contexts". >> 5. Can special mount-operations (e.g. /proc filesystem) be allowed by >> the policy, or does this require userspace helper also? > > Not sure what you're asking here. Mount can be allowed or disallowed > based on the policy. We have to allow *some* kinds of mount but forbid all other ones. Enrico From notting at redhat.com Mon Dec 1 20:00:51 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 1 Dec 2003 15:00:51 -0500 Subject: The current fedora.us buildsystem and future directions In-Reply-To: <87n0acia82.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> <20031129022551.GA31280@devserv.devel.redhat.com> <87n0acia82.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20031201200051.GB23909@devserv.devel.redhat.com> Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > >> 1. SELinux can protect foreign processes. But is it possible to hide > >> them in /proc also? > > > > If you cannot access it, why does it matter if it is visible? > > E.g. 'service xyz stop' in rpm-scriptlets may have an unwanted behavior > when it sees 'xyz' processes in other "contexts". In general, you'll be able to tell that there's a process at pid , but not what process it is. Note that scriplets in a build root very very very very very rarely need to kick processes, if ever. > >> 5. Can special mount-operations (e.g. /proc filesystem) be allowed by > >> the policy, or does this require userspace helper also? > > > > Not sure what you're asking here. Mount can be allowed or disallowed > > based on the policy. > > We have to allow *some* kinds of mount but forbid all other ones. I would think that the buildroot filesystem setup & mounting would be done outside of the chroot process. Bill From walters at verbum.org Mon Dec 1 20:41:52 2003 From: walters at verbum.org (Colin Walters) Date: Mon, 01 Dec 2003 15:41:52 -0500 Subject: The current fedora.us buildsystem and future directions In-Reply-To: <87r7zoiaf5.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> <1070061174.4351.8.camel@nexus.verbum.private> <87r7zoiaf5.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1070311312.11092.30.camel@nexus.verbum.private> On Mon, 2003-12-01 at 14:51, Enrico Scholz wrote: > walters at verbum.org (Colin Walters) writes: > > >> 2. Is chroot(2) implemented in a safe manner? Or, can parent directories > >> of build-roots be protected with SELinux policies? Is a safe chroot(2) > >> required at all? > > > > Using SELinux, a chroot doesn't provide any additional direct security. > > However, you may find it convenient to use a chroot in this instance so > > that different sets of packages can be installed, etc. > > I am asking because of the following situation: there are two, (nearly) > equal buildroots A & B in the directory tree like > > > |- A > `- B > > Can it be prohibited that A modifies files within B? Yes. You ensure that the set of types associated with the files and processes of A is disjoint from those of B, and that no interaction between them is allowed by your security policy. Russell Coker has done work on restricting chroots with SELinux - check out macros/chroot_macros.te in the latest sample policy. Essentially you say something like this: chroot(fedora_group1_t, fedora_group1) Assuming you have defined a user fedora_group1 with role fedora_group1_r and type fedora_group1_t. > Would it be possible to forbid any kind of access at for > buildprocesses? That would be very easy, yes - just don't mention the type of in your policy relating to the chroot types. > We will have to deal with > > mount -t proc none /proc > vs. > mount --bind trojan /bin/sh > > The first command MUST be supported, but the second one (inclusive > variants) be forbidden. AFAIK all these mount types are multiplexed through the one mount system call. SELinux appears to have two checks; first, they need the "mount" permission of the source filesystem type (such as proc_t or device_t). However I believe a mount operation has to pass a secondary check - they need access to the "mounton" operation for the object (file/directory) that is the destination of the mount. So since the type of /bin/sh would be shell_exec_t, your chrooted user presumably wouldn't have permission to bind mount on top of it. I'll try to verify this when I get a chance. But as Bill said, it seems to me you could just set up the chroot (including /proc mount), and not allow the user permission to mount/unmount anything at all. Why would a build root need to mount/umount proc? By the way - one general point about SELinux. So far you have generally been asking about access to specific files and whether or not the user execute "mount --blah...". With SELinux, *everything* has a type. This includes files, but also things like file descriptors and ports. Any interaction between two types that is not expressly permitted is denied. So you really want to think in terms of the types of objects and the operations permitted on them, rather than secondary characteristics such as their pathnames (/bin/sh, /var/buildroot). -------------- 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 johnsonm at redhat.com Mon Dec 1 21:22:41 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 1 Dec 2003 16:22:41 -0500 Subject: new leadership draft being posted... Message-ID: <20031201212241.GA12103@devserv.devel.redhat.com> The page http://fedora.redhat.com/about/leadership.html will be updated in the next update to the web site. I want to remind everyone when you see it that it's DRAFT II, not "FINAL", and ask that discussion happen on this list. Thanks, 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 xose at wanadoo.es Mon Dec 1 21:29:38 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Mon, 01 Dec 2003 22:29:38 +0100 Subject: new leadership draft being posted... References: <20031201212241.GA12103@devserv.devel.redhat.com> Message-ID: <3FCBB2C2.4000509@wanadoo.es> Michael K. Johnson wrote: > The page > http://fedora.redhat.com/about/leadership.html > will be updated in the next update to the web site. would you mind to place the date of the latest modification on bottom of all the web pages ? Now, it's nearly impossible to know when somebody modify a page. -thanks- From josh at bress.net Mon Dec 1 23:30:06 2003 From: josh at bress.net (Josh Bressers) Date: Mon, 01 Dec 2003 18:30:06 -0500 Subject: new leadership draft being posted... In-Reply-To: Your message of "Mon, 01 Dec 2003 16:22:41 EST." <20031201212241.GA12103@devserv.devel.redhat.com> Message-ID: <20031201233006.E2C4483@feh.bress.net> > The page > http://fedora.redhat.com/about/leadership.html > will be updated in the next update to the web site. > > I want to remind everyone when you see it that it's DRAFT II, not > "FINAL", and ask that discussion happen on this list. I will admit, I don't have full background on all of the Fedora policies, I've only been on this list for a week. What makes me curious is the intense RedHat involvement from the top. I understand that this project is funded by RedHat, but it's going to raise some complaints from the community. I deal with Debian developers on a daily basis and their biggest complaint seems to be the heavy RedHat involvement. I don't think this is all bad (I get the impression RedHat has a clue), but it may be wise to bring a few non RedHat people onto the Steering Commitee. This would help mitigate any complaints from some of the more "left" community members we'll say :) -- JB From redhat-forums at genesis-x.nildram.co.uk Mon Dec 1 23:34:27 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Mon, 01 Dec 2003 23:34:27 +0000 Subject: MapiVi - Linux Image Management Software Message-ID: Image Management Software is a bit thin on the ground in the Linux world. Apart from Kalbum and Gthumb (neither one of which has IPTC editing) the only app available seems to be MapiVi (Martin's Picture Viewer - http://herrmanns-stern.de/software/mapivi/mapivi.shtml After some considerable effort, I managed to get this installed on Yarrow, however I'd like to do something to make this available as a Fedora'ized set of RPMs. The problem is, that MapiVi is dependent on a number of components that are poorly maintained and almost impossible to acquire in RPM or even SRPM form. The Perl module sources I worked from were obtained mainly using the cpan tool, but if anyone has any links to either RPMs or SRPMs that install/compile properly under Yarrow, I'd be very grateful. Here's the components I need, preferably in SRPM form: MapiVi - I'm working on an RPM now - Work In Progress libjpeg-6b-29 - With the lossless patch - Done Image Magick - Included with Yarrow - Done **** Perl/Tk - Where's the source, Luke? - Lost In Space Image::Info - Ditto - Ditto **** Tk::JPEG - Done - Done Image::IPTCInfo - Done - Done The Perl/Tk thing has me stumped. Has it been dropped? Is GTk the new Tk? What is the relationship between Tk, GTk and tcl? What is the specific reason that Perl/Tk is not a core part of the distro? Is it too old and crap ... to put it bluntly? -- Keith G. Robertson-Turner "The only liberties people have, are those they take." Palladium is not the solution, it is the problem. www.antitcpa.com From rhl at reachone.com Mon Dec 1 23:56:51 2003 From: rhl at reachone.com (Adam Debus) Date: Mon, 1 Dec 2003 15:56:51 -0800 Subject: new leadership draft being posted... References: <20031201233006.E2C4483@feh.bress.net> Message-ID: <00a001c3b866$ca64bb40$e2e8b1d8@adam12> > What makes me curious is the intense RedHat involvement from the top. I > understand that this project is funded by RedHat, but it's going to raise > some complaints from the community. I deal with Debian developers on a > daily basis and their biggest complaint seems to be the heavy RedHat > involvement. I don't think this is all bad (I get the impression RedHat > has a clue), but it may be wise to bring a few non RedHat people onto the > Steering Commitee. This would help mitigate any complaints from some of > the more "left" community members we'll say :) It's worth pointing out that at the moment, it's difficult to put anyone else there. As has been said a few times before, many of the procedures that goes into making Fedora are still very much, from both a technical and political standpoint, RedHat proprietary. And are the same, or are extremely similar, to the building that gets done for RHEL. For what it's worth, Fedora, as a project of it's own, has only been around since September. And at the time it happened, very much smelled of a decision that had happened 3-4 days before it was announced. The political side was there, but the technical side is going to need quite a bit of time to de-integrate itself from RHEL. I'm not saying that there shouldn't be some non-RedHat people on the Steering Committee, but at the moment, I don't think there are many, if any, non-RedHat people who can step into that role. Too much of the finer detail is still being worked out. And not to stir the fires of inter-distro flame wars, but I suspect that how the core Debian developers feel about how Fedora is being run is fairly low on the "to be worried about" list of most of the people on this list. Thanks, Adam Debus Network Engineer, ReachONE Internet adam at reachone.com * Opinions expressed in this e-mail are not necessarially the opinions of my company. From redhat-forums at genesis-x.nildram.co.uk Tue Dec 2 00:13:27 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Tue, 02 Dec 2003 00:13:27 +0000 Subject: MapiVi - Linux Image Management Software References: Message-ID: On Mon, 01 Dec 2003 23:34:27 +0000, Keith G. Robertson-Turner wrote: > Here's the components I need, preferably in SRPM form: > **** > Perl/Tk - Where's the source, Luke? - Lost In Space > Image::Info - Ditto - Ditto > **** I should add, that I'm looking for clean upstream sources. So far the only source for Perl/Tk I've found, was in a Connectiva src.rpm, and there's no mention in the .spec where the upstream source is. Also, there's no mention of the source at all on the Perl/Tk home page at http://www.perltk.org/ nor at SourceForge. From sflory at rackable.com Tue Dec 2 02:23:46 2003 From: sflory at rackable.com (Samuel Flory) Date: Mon, 01 Dec 2003 18:23:46 -0800 Subject: Vic^H^Holunteers needed for updated SATA code testing In-Reply-To: <20031130001635.GA12006@comcast.net> References: <20031116183756.GA21083@ee.oulu.fi> <20031128235827.GA23027@ee.oulu.fi> <20031130001635.GA12006@comcast.net> Message-ID: <3FCBF7B2.3060900@rackable.com> Justin M. Forbes wrote: >>Positive comments so far from Promise and VIA users, so I reused someones RFE >>in bugzilla for this (#103980) to possibly get it in a future kernel >>update. > > > I have merged these patches into the current Fedora kernel for AMD64, > hopefully it will stay there until release, in which case, it should ship > with an errata kernel for i386 users as well. > > >>I've also not heard of anyone managing a working install image, if anyone >>got it running, would they mind sharing? ;-) > > > It is in the install image for x86_64, when I get some spare cycles I will > do an install image for i?86 with this kernel. > Which sata chipsets are we looking for? I've got a wide range of SI, ICH5, Promise, Highpoint, and God knows what else. Other than a few wierd software raid SATA controllers, and one ebedded promise controllers it all works with the libata patches. -- There is no such thing as obsolete hardware. Merely hardware that other people don't want. (The Second Rule of Hardware Acquisition) Sam Flory From stan at ccs.neu.edu Tue Dec 2 03:13:46 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Mon, 01 Dec 2003 22:13:46 -0500 Subject: MapiVi - Linux Image Management Software In-Reply-To: References: Message-ID: <1070334826.1693.44.camel@duergar> On Mon, 2003-12-01 at 19:13, Keith G. Robertson-Turner wrote: > On Mon, 01 Dec 2003 23:34:27 +0000, Keith G. Robertson-Turner wrote: > > > Here's the components I need, preferably in SRPM form: > > > **** > > Perl/Tk - Where's the source, Luke? - Lost In Space > > Image::Info - Ditto - Ditto > > **** > > I should add, that I'm looking for clean upstream sources. > > So far the only source for Perl/Tk I've found, was in a Connectiva > src.rpm, and there's no mention in the .spec where the upstream source is. > Also, there's no mention of the source at all on the Perl/Tk home page at > http://www.perltk.org/ nor at SourceForge. > Instructions on obtaining source here: http://www.perltk.org/articles/pm1.htm -sb > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From redhat-forums at genesis-x.nildram.co.uk Tue Dec 2 03:26:13 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Tue, 02 Dec 2003 03:26:13 +0000 Subject: MapiVi - Linux Image Management Software References: <1070334826.1693.44.camel@duergar> Message-ID: On Mon, 01 Dec 2003 22:13:46 -0500, Stan Bubrouski wrote: > On Mon, 2003-12-01 at 19:13, Keith G. Robertson-Turner wrote: >> So far the only source for Perl/Tk I've found, was in a Connectiva >> src.rpm, and there's no mention in the .spec where the upstream source >> is. Also, there's no mention of the source at all on the Perl/Tk home >> page at http://www.perltk.org/ nor at SourceForge. >> >> > Instructions on obtaining source here: > http://www.perltk.org/articles/pm1.htm Ah, that's where it's hiding :) Thanks. From behdad at cs.toronto.edu Tue Dec 2 05:12:35 2003 From: behdad at cs.toronto.edu (Behdad Esfahbod) Date: Tue, 2 Dec 2003 00:12:35 -0500 Subject: Some Logo work Message-ID: Hi, I myself like the idea of the red fedora. I've just edited a photo of a real Red Hat Fedora I found on web and put it here: http://www.cs.toronto.edu/~behdad/fedoralogo/fedora.html The one on panel is poorly shaded. The Gimp source is at http://www.cs.toronto.edu/~behdad/fedoralogo/fedora.xcf To me these look more modern than the current ones ;-). behdad From nutello at sweetness.com Tue Dec 2 05:21:42 2003 From: nutello at sweetness.com (Rudi Chiarito) Date: Tue, 2 Dec 2003 06:21:42 +0100 Subject: MapiVi - Linux Image Management Software In-Reply-To: References: Message-ID: <20031202052142.GA28557@server4.8080.it> On Tue, Dec 02, 2003 at 12:13:27AM +0000, Keith G. Robertson-Turner wrote: > On Mon, 01 Dec 2003 23:34:27 +0000, Keith G. Robertson-Turner wrote: > > Here's the components I need, preferably in SRPM form: > So far the only source for Perl/Tk I've found, was in a Connectiva > src.rpm, and there's no mention in the .spec where the upstream source is. A few months ago I built a package by porting the Conectiva rpm to RH9 (also upgrading to 800.025 and enabling parallel builds on SMP systems). It can be found at http://www.uberh4x0r.org/~yax/biorpm/src/perl-Tk-800.025-0.br.2.src.rpm http://www.uberh4x0r.org/~yax/biorpm/txt/perl-Tk-800.025-0.br.2.i386.txt http://www.uberh4x0r.org/~yax/biorpm/perl-Tk-800.025-0.br.2.i386.rpm http://www.uberh4x0r.org/~yax/biorpm/txt/perl-Tk-demos-800.025-0.br.2.i386.txt http://www.uberh4x0r.org/~yax/biorpm/perl-Tk-demos-800.025-0.br.2.i386.rpm The URL in the spec file points to the upstream source, that is http://search.cpan.org/~ni-s/Tk800.025/ Rudi From stan at ccs.neu.edu Tue Dec 2 07:49:32 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Tue, 02 Dec 2003 02:49:32 -0500 Subject: MapiVi - Linux Image Management Software In-Reply-To: References: <1070334826.1693.44.camel@duergar> Message-ID: <1070351371.1215.20.camel@duergar> On Mon, 2003-12-01 at 22:26, Keith G. Robertson-Turner wrote: > On Mon, 01 Dec 2003 22:13:46 -0500, Stan Bubrouski wrote: > > Instructions on obtaining source here: > > http://www.perltk.org/articles/pm1.htm > > Ah, that's where it's hiding :) > > Thanks. > No problem. I was wondering, cause I haven't used Perl/Tk but I do know it is very widely used, I've seen major corporations using it on Windows as well. O'Reilly makes a great book on Perl/Tk if you are interested in learning it. I haven't gotten around to it yet, but its definitely high on my list of things to learn before the end of the year rolls around (time what's that? ;-) -sb > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From linux at bytebot.net Tue Dec 2 09:52:45 2003 From: linux at bytebot.net (Colin Charles) Date: Tue, 02 Dec 2003 17:52:45 +0800 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <1070306893.1693.33.camel@duergar> References: <200312011029.07917.livelinux@nwst.de> <1070295953.6386.3.camel@localhost.localdomain> <1070306893.1693.33.camel@duergar> Message-ID: <1070332179.26308.24.camel@hermione> On Tue, 2003-12-02 at 03:28, Stan Bubrouski wrote: > > I'd be very interested in seeing a FC1 LiveCD, I'd like to test it, and > > I have a number of friends and colleagues who would be very interested > > too. BTW, please include GNU Parted... unbelievably handy to have on a > > bootable CD. > > > > I totally agree, its adds to the useful of the CD tenfold. QtParted is something we tend to use a lot at install fests - it allows partitioning to be done by those less experienced. If GNU Parted goes in, please try and include the front-end as well. If its not too much to ask, the Fedora kernel should be re-rolled for some NTFS support, so that we can also have ntfsresize on there (though those two may be independent of each other, I'm not certain). If we want a useful Fedora LiveCD, it should be as useful as the Knoppix LiveCD (if not more useful!). -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ From linux at bytebot.net Tue Dec 2 11:28:27 2003 From: linux at bytebot.net (Colin Charles) Date: Tue, 02 Dec 2003 19:28:27 +0800 Subject: Some Logo work In-Reply-To: References: Message-ID: <1070360828.28143.6.camel@hermione> On Tue, 2003-12-02 at 13:12, Behdad Esfahbod wrote: > Hi, > > I myself like the idea of the red fedora. I've just edited a > photo of a real Red Hat Fedora I found on web and put it here: > > http://www.cs.toronto.edu/~behdad/fedoralogo/fedora.html > > The one on panel is poorly shaded. The Gimp source is at > http://www.cs.toronto.edu/~behdad/fedoralogo/fedora.xcf > > To me these look more modern than the current ones ;-). Behdad, This is best discussed on the fedora-desktop-list. Do go ahead and subscribe at fedora-desktop-list at redhat.com (where the reply-to) is set incidentally. -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ From rms at 1407.org Tue Dec 2 11:21:39 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 02 Dec 2003 11:21:39 +0000 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <1070332179.26308.24.camel@hermione> References: <200312011029.07917.livelinux@nwst.de> <1070295953.6386.3.camel@localhost.localdomain> <1070306893.1693.33.camel@duergar> <1070332179.26308.24.camel@hermione> Message-ID: <1070364098.4435.8.camel@roque> On Tue, 2003-12-02 at 09:52, Colin Charles wrote: > If its not too much to ask, the Fedora kernel should be re-rolled for > some NTFS support, so that we can also have ntfsresize on there (though > those two may be independent of each other, I'm not certain). Fedora is an USA based project. The USA have Software Patents (which is a true horror). NTFS is patent encumbered... Hence, it is asking too much, right now, unfortunately. :| Maybe if you add your help to ending Software Patents everywhere? :) Hugs, Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 livelinux at nwst.de Tue Dec 2 12:00:14 2003 From: livelinux at nwst.de (Dirk Westfal) Date: Tue, 2 Dec 2003 13:00:14 +0100 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <1070332179.26308.24.camel@hermione> References: <200312011029.07917.livelinux@nwst.de> <1070306893.1693.33.camel@duergar> <1070332179.26308.24.camel@hermione> Message-ID: <200312021300.15121.livelinux@nwst.de> Hi, thanks to all! On Tuesday 02 December 2003 10:52, Colin Charles wrote: > On Tue, 2003-12-02 at 03:28, Stan Bubrouski wrote: > > > I'd be very interested in seeing a FC1 LiveCD, I'd like to test it, and > > > I have a number of friends and colleagues who would be very interested > > > too. ... Great. I think i will make a beta-version aviable this weekend. > BTW, please include GNU Parted... unbelievably handy to have on a > bootable CD. This one is already included . > QtParted is something we tend to use a lot at install fests - it allows > partitioning to be done by those less experienced. If GNU Parted goes > in, please try and include the front-end as well. I will try it. > If its not too much to ask, the Fedora kernel should be re-rolled for > some NTFS support, so that we can also have ntfsresize on there (though > those two may be independent of each other, I'm not certain). I'm currently using a fresh compiled 2.4.22 kernel from kernel.org with openmosix patches. Ntfs Read-Support is already included, write support is still too dangerous - i hoangpe this will change somewhat with 2.6. > If we want a useful Fedora LiveCD, it should be as useful as the Knoppix > LiveCD (if not more useful!). sure! ;-) Question about themes: I think the default theme should be bluecurve, right ? thanks and so long, Dirk From pauln at truemesh.com Tue Dec 2 12:51:17 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 2 Dec 2003 12:51:17 +0000 Subject: new leadership draft being posted... In-Reply-To: <20031201212241.GA12103@devserv.devel.redhat.com> References: <20031201212241.GA12103@devserv.devel.redhat.com> Message-ID: <20031202125116.GA26011@ensim.rackshack.net> On Mon, Dec 01, 2003 at 04:22:41PM -0500, Michael K. Johnson wrote: > The page > http://fedora.redhat.com/about/leadership.html > will be updated in the next update to the web site. > > I want to remind everyone when you see it that it's DRAFT II, not > "FINAL", and ask that discussion happen on this list. One inconsistency I noted is that the Changes section mentions a: "Infrastructure Team" Which isn't detailed in the rest of the document. Paul From jspaleta at princeton.edu Tue Dec 2 13:43:23 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Tue, 02 Dec 2003 08:43:23 -0500 Subject: new leadership draft being posted... Message-ID: <1070372603.10872.13.camel@spatula.pppl.gov> Paul Nasrat wrote: > "Infrastructure Team" > > Which isn't detailed in the rest of the document. Sure it is...in the paragraph describing the merge team: The Merge Team has the "simple" goal to make the merge between the old Fedora Linux project and the new Fedora Project happen. This includes policy merges and infrastructure management. This team will be reduced and reconstituted as the >>>>>>>>******Infrastructure Team******<<<<<<<< once the merge has been completed. The Merge Team and later the Infrastructure Team will have participants from inside and outside of Red Hat. -jef"still pulling for the official Fedora logo to be 'Scapegoat:the hat eating goat'"spaleta From linux at bytebot.net Tue Dec 2 13:56:52 2003 From: linux at bytebot.net (Colin Charles) Date: Tue, 02 Dec 2003 21:56:52 +0800 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <1070364098.4435.8.camel@roque> References: <200312011029.07917.livelinux@nwst.de> <1070295953.6386.3.camel@localhost.localdomain> <1070306893.1693.33.camel@duergar> <1070332179.26308.24.camel@hermione> <1070364098.4435.8.camel@roque> Message-ID: <1070372826.28145.26.camel@hermione> On Tue, 2003-12-02 at 19:21, Rui Miguel Seabra wrote: > On Tue, 2003-12-02 at 09:52, Colin Charles wrote: > > If its not too much to ask, the Fedora kernel should be re-rolled for > > some NTFS support, so that we can also have ntfsresize on there (though > > those two may be independent of each other, I'm not certain). > > Fedora is an USA based project. > The USA have Software Patents (which is a true horror). > > NTFS is patent encumbered... > > Hence, it is asking too much, right now, unfortunately. :| Hmm, Debian is a USA based project, and Knoppix, it's spin-off is based in Germany. > Maybe if you add your help to ending Software Patents everywhere? :) So, is this software patent thing really an issue? ntfsresize is kind of handy (lots of PCs tend to have it taking up the entire disk these days!) to have around, methinks. -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ From pauln at truemesh.com Tue Dec 2 14:06:31 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 2 Dec 2003 14:06:31 +0000 Subject: new leadership draft being posted... In-Reply-To: <1070372603.10872.13.camel@spatula.pppl.gov> References: <1070372603.10872.13.camel@spatula.pppl.gov> Message-ID: <20031202140629.GB26011@ensim.rackshack.net> On Tue, Dec 02, 2003 at 08:43:23AM -0500, Jef Spaleta wrote: > Paul Nasrat wrote: > > > "Infrastructure Team" > > > > Which isn't detailed in the rest of the document. > Sure it is...in the paragraph describing the merge team: Grr, ok I must have completely missed that. Paul From julo at altern.org Tue Dec 2 14:16:39 2003 From: julo at altern.org (Julien Olivier) Date: Tue, 02 Dec 2003 14:16:39 +0000 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <1070372826.28145.26.camel@hermione> References: <200312011029.07917.livelinux@nwst.de> <1070295953.6386.3.camel@localhost.localdomain> <1070306893.1693.33.camel@duergar> <1070332179.26308.24.camel@hermione> <1070364098.4435.8.camel@roque> <1070372826.28145.26.camel@hermione> Message-ID: <1070374599.5720.4.camel@localhost.localdomain> > So, is this software patent thing really an issue? ntfsresize is kind of > handy (lots of PCs tend to have it taking up the entire disk these > days!) to have around, methinks. That's not just "handy", that's an absolute need for most users, as long as computers come with Windows pre-loaded. Very few people will remove Windows without even testing Linux once on their computer. Ideally, if you install Fedora on a hard-drive containing only a NTFS partition, the default action should be to resize it and install linux in dual boot next to it. That said, if it's really a legal problem (again), there is nothing Fedora can do, I guess... -- Julien Olivier From linux at bytebot.net Tue Dec 2 14:07:05 2003 From: linux at bytebot.net (Colin Charles) Date: Tue, 02 Dec 2003 22:07:05 +0800 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <200312021300.15121.livelinux@nwst.de> References: <200312011029.07917.livelinux@nwst.de> <1070306893.1693.33.camel@duergar> <1070332179.26308.24.camel@hermione> <200312021300.15121.livelinux@nwst.de> Message-ID: <1070374025.28038.34.camel@hermione> On Tue, 2003-12-02 at 20:00, Dirk Westfal wrote: > > QtParted is something we tend to use a lot at install fests - it allows > > partitioning to be done by those less experienced. If GNU Parted goes > > in, please try and include the front-end as well. > > I will try it. The name implies that it possibly requires the Qt libraries... not certain myself. http://qtparted.sf.net/ > Ntfs Read-Support is already included, write support is still too dangerous - > i hoangpe this will change somewhat with 2.6. To make things work, more patching needs to be done (or so say's the FAQ - http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html). Anyhow, ntfsresize doesn't need kernel support it seems, so all's well. > Question about themes: I think the default theme should be bluecurve, right ? Keep it simple first, and maybe with a swapped background which instead of reading Fedora Core, reads... FedoraLiveLinuxCD (ok, that's just plain wordy, but I'm sure you get the idea!). Being in beta, we can make changes later ;) -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ From makgab at freemail.hu Tue Dec 2 14:49:11 2003 From: makgab at freemail.hu (Mako Gabor) Date: Tue, 02 Dec 2003 15:49:11 +0100 (CET) Subject: Fedora minimal install option Message-ID: Hi! I'm Gabor from Hungary, new one in the mailing list! I'm RedHat/Fedora fan. :) (I didn't speak English well. :)) I have a suggest for Fedora Linux. :) There isn't Minimum Install option (only console with base rpm packages ~150MB?) and Mininum XWindow Install options in Fedora/RedHat Install. (There are only Workstation, Dekstop, Server, Custom options.) I like to use the minimal install options often. Can you implement them into the install options? Bye! Gabor From jspaleta at princeton.edu Tue Dec 2 14:52:10 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Tue, 02 Dec 2003 09:52:10 -0500 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0base to fedora core 1 Message-ID: <1070376729.10872.59.camel@spatula.pppl.gov> Colin Charles: >Hmm, Debian is a USA based project, and Knoppix, it's spin-off is >based in Germany. The KEY to this statement of fact is that Knoppix is spelled differently than Debian, and I would hope Knoppix refrains from using Debian's trademarks and logos inside the Knoppix isos. There is more than enough room for a derivative work that begins with software provided by Fedora to create a liveCD that is legal in other countries. BUT, it should not use trademarked Fedora images or logos. In fact if you read through the trademark guidelines at fedora.redhat.com ... I'm really not sure that you should use the Fedora name associated at all, even to say its a derivative work, with a livecd that is rolled up outside of the 'official' structure. What if the LiveCD I roll up..totally sucks? I assure you it would. Should I be allowed to say that its based on Fedora Core? I don't think so, because my crappy attempt at liveCD building would tarnish the official work done as part of the official Fedora community effort. And don't try to argue that people using and reviewing my crappy little liveCD should know better than to link the very bad craftmanship of MY customized work to the craftsmanship of the Fedora project in general. In an effort to avoid tarnishing the reputation of the Fedora name...i should NOT be allowed to use or even to refer to Fedora when advertising my co-mingled customized liveCD image. In fact... i would suggest(from a fairplay point of view) that ALL custom liveCD's should have to live outside the allowable usage of the Fedora trademarks because the liveCD distribution format makes it very difficult to distiguish what is customized and what is original Fedora craftsmanship. Which is very different than something like an OEM pre-install, where the OEM can give the customer a set of Fedora Core disks as well as a seperate piece of media for the OEM addon packages making up the full OEM pre-install of Fedora. Of course pulling out ALL the text that refers to the distro as Fedora(not to mention all the lingering Red Hat references) is probably a non trivial task at the moment....maybe there is room in the continuing dialog for an official liveCD image, but somehow i doubt an officially blessed liveCD image would fill the niche well, considering the non-technical limitations being 'officially' blessed would carry. -jef"if the point of a liveCD is to demo a distro...but the liveCD ends up having many custom features the base distro does not have like ntfs support...what's the point again?"spaleta From robert at marcanoonline.com Tue Dec 2 15:11:20 2003 From: robert at marcanoonline.com (Robert Marcano) Date: Tue, 02 Dec 2003 11:11:20 -0400 Subject: Fedora minimal install option In-Reply-To: References: Message-ID: <1070377879.4613.13.camel@pcrobert.intranet.promca.com> On Tue, 2003-12-02 at 10:49, Mako Gabor wrote: > Hi! > > I'm Gabor from Hungary, new one in the mailing list! I'm RedHat/Fedora fan. :) > (I didn't speak English well. :)) > > I have a suggest for Fedora Linux. :) > There isn't Minimum Install option (only console with base rpm packages > ~150MB?) and Mininum XWindow Install options in Fedora/RedHat Install. > (There are only Workstation, Dekstop, Server, Custom options.) > I like to use the minimal install options often. If I remember correctly, you can use the custom option, and on the package selection screen yo can choose Minimum Install or Full Install, the last two options (The last time i saw those options was using RH9, i don't remember if Fedora still has them) > > Can you implement them into the install options? > > Bye! > Gabor From kjb at dds.nl Tue Dec 2 15:15:35 2003 From: kjb at dds.nl (Klaasjan Brand) Date: Tue, 02 Dec 2003 16:15:35 +0100 Subject: Fedora minimal install option In-Reply-To: References: Message-ID: <3FCCAC97.7050406@dds.nl> Mako Gabor wrote: >There isn't Minimum Install option (only console with base rpm packages >~150MB?) and Mininum XWindow Install options in Fedora/RedHat Install. >(There are only Workstation, Dekstop, Server, Custom options.) >I like to use the minimal install options often. > > I don't know exactly how small you can get Fedora (anyone? :), but you can do a custom install and only install packages you really need. If you create a "kickstart" install script you can repeat the same installation for multiple systems. Klaasjan From notting at redhat.com Tue Dec 2 16:03:54 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 2 Dec 2003 11:03:54 -0500 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <200312021300.15121.livelinux@nwst.de> References: <200312011029.07917.livelinux@nwst.de> <1070306893.1693.33.camel@duergar> <1070332179.26308.24.camel@hermione> <200312021300.15121.livelinux@nwst.de> Message-ID: <20031202160354.GA8979@devserv.devel.redhat.com> Dirk Westfal (livelinux at nwst.de) said: > I'm currently using a fresh compiled 2.4.22 kernel from kernel.org with > openmosix patches. Why do you need a separate kernel? OpenMosix seems like and odd requirement for a live filesystem CD to me... Bill From jspaleta at princeton.edu Tue Dec 2 16:11:00 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Tue, 02 Dec 2003 11:11:00 -0500 Subject: Bug Day 8: Dec 03,2003: For a change of pace, this reminder is a a day before the actual bugday Message-ID: <1070381460.10872.130.camel@spatula.pppl.gov> Do NOT be alarmed! Today is not Wednesday! But tomorrow is! and that means..... Fedora Bug Day Tomorrow!!!!!! Theme: A general call to arms, for bugbusting!!!!! Not really sure there is a specific issue that needs to be addressed from the community side of things, other than the increasing and consistent pile-up of packages sitting at fedora.us waiting for community QA. Or at least developers haven't pulled my ear about it. So there is no specific bughunting theme. There are in fact several long term issues that I personally want to encourage several segments of the community to help me explore in the bughunting and bug triaging solution space. This is probably going to be an extremely rambling email. package maintainers specifically: *not necessarily tomorrow but as soon as you can find the time.... I'm trying to establish a collection of biolerplate responses that a crack triage team can use when hunting over reported bugs concerning a set of packages. My hope is that a triager can save package maintainers some time, by using a 'stock' reply that maintainers find themselves using in needsinfo bug reports situations. http://www.fedora.us/wiki/BoilerPlate. *please try to run bugzilla queries against the triage comments http://www.fedora.us/wiki/CannedQueries i would enjoy feedback on the usefulness or abuse of the triage comment concept. everybody else: *Become involved in the fedora.us QA process and help QA packages that are waiting to be published in the fedora.us addon repo: http://www.fedora.us/QA . There are 293 packages sitting waiting for QA. That's 293 packages the Fedora community could be enjoying in the published fedora.us repository trees, once they have made it through the community QA process. Remember, until the full merge is completed and Fedora Extras and Alternatives is up and running...community packagers are being advised to use fedora.us's process. How do you become involved in the fedora.us QA process? Easy, read: http://www.fedora.us/wiki/PackageSubmissionQAPolicy *Help triage the fedora core bugzilla reports by reviewing open bugzilla bug tickets and trying to use simple comment strings as a way to categorize bug reports to make it easier for developers to quickly find bugs that can be marked closed. For more information take a look at: http://www.fedora.us/wiki/TriageComment http://www.fedora.us/wiki/CannedQueries But if you are unsure on how to use the triage comment idea, discussion in #fedora-bugs on the freenode irc network is encouraged. *there is also going to be an opportunity for bug triagers to test a set of xmlrpc bugzilla interface tools, very soon now. I'm not directly involved with the tool building, but Mr. Nasrat should be sending a follow up post with some more detailed directions about some example tools...its all too very exciting for me to talk about in a fashion approximating coherence. -jef"all this and only on one cup of coffee"spaleta From rms at 1407.org Tue Dec 2 16:39:56 2003 From: rms at 1407.org (Rui Miguel Seabra) Date: Tue, 02 Dec 2003 16:39:56 +0000 Subject: Fedora minimal install option In-Reply-To: <1070377879.4613.13.camel@pcrobert.intranet.promca.com> References: <1070377879.4613.13.camel@pcrobert.intranet.promca.com> Message-ID: <1070383196.7322.4.camel@roque> I haven't looked into Fedora Core's Minimum Install yet, but RedHat's Minimum Install is _all_but_minimal_. A Minimum Install should look _almost_ like an OpenBSD default boot: No services active (BECAUSE THEY'RE NOT EVEN INSTALLED) NO X. Just the necessary to boot and make post install installations. This is what a Minimum should be. Anything more and it doesn't deserve the term Minimal Hugs, Rui ps: then you could have things like Minimum( + GROUP)* where you'd add whatever kind of service groups you'd like your machine to do. On Tue, 2003-12-02 at 15:11, Robert Marcano wrote: > On Tue, 2003-12-02 at 10:49, Mako Gabor wrote: > > Hi! > > > > I'm Gabor from Hungary, new one in the mailing list! I'm RedHat/Fedora fan. :) > > (I didn't speak English well. :)) > > > > I have a suggest for Fedora Linux. :) > > There isn't Minimum Install option (only console with base rpm packages > > ~150MB?) and Mininum XWindow Install options in Fedora/RedHat Install. > > (There are only Workstation, Dekstop, Server, Custom options.) > > I like to use the minimal install options often. > > If I remember correctly, you can use the custom option, and on the > package selection screen yo can choose Minimum Install or Full Install, > the last two options (The last time i saw those options was using RH9, i > don't remember if Fedora still has them) > > > > > Can you implement them into the install options? > > > > Bye! > > Gabor > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- 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 redhat-forums at genesis-x.nildram.co.uk Tue Dec 2 18:00:57 2003 From: redhat-forums at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Tue, 02 Dec 2003 18:00:57 +0000 Subject: MapiVi - Linux Image Management Software References: <20031202052142.GA28557@server4.8080.it> Message-ID: On Tue, 02 Dec 2003 06:21:42 +0100, Rudi Chiarito wrote: > A few months ago I built a package by porting the Conectiva rpm to RH9 > (also upgrading to 800.025 and enabling parallel builds on SMP systems). > It can be found at Great! That's really useful, and will save me a lot of time. Thanks! From stan at ccs.neu.edu Tue Dec 2 18:12:06 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Tue, 02 Dec 2003 13:12:06 -0500 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <200312021300.15121.livelinux@nwst.de> References: <200312011029.07917.livelinux@nwst.de> <1070306893.1693.33.camel@duergar> <1070332179.26308.24.camel@hermione> <200312021300.15121.livelinux@nwst.de> Message-ID: <1070388726.1215.49.camel@duergar> On Tue, 2003-12-02 at 07:00, Dirk Westfal wrote: > Ntfs Read-Support is already included, write support is still too dangerous - > i hoangpe this will change somewhat with 2.6. > I hope not. 2.6 DOES NOT have stable write support for NTFS, it says it everywhere in the docs. It IS a complete rewrite from the 2.4 NTFS code but it will not be stable enough to use write support in 2.6 and I have no idea at what point it will be remotely safe. -sb > > > > If we want a useful Fedora LiveCD, it should be as useful as the Knoppix > > LiveCD (if not more useful!). > > sure! ;-) > > > Question about themes: I think the default theme should be bluecurve, right ? > > > thanks and so long, > > Dirk > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From jeremyp at pobox.com Tue Dec 2 18:40:52 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: Tue, 02 Dec 2003 13:40:52 -0500 Subject: new leadership draft being posted... In-Reply-To: <20031202125116.GA26011@ensim.rackshack.net> References: <20031201212241.GA12103@devserv.devel.redhat.com> <20031202125116.GA26011@ensim.rackshack.net> Message-ID: <1070390451.19274.20.camel@jeremy.dtcc.cc.nc.us> On Tue, 2003-12-02 at 07:51, Paul Nasrat wrote: > One inconsistency I noted is that the Changes section mentions a: > > "Infrastructure Team" > > Which isn't detailed in the rest of the document. > The Infrastructure Team is indeed explained, in the "Technical Committee" section. "The Merge Team has the 'simple' goal to make the merge between the old Fedora Linux project and the new Fedora Project happen. This includes policy merges and infrastructure management. This team will be reduced and reconstituted as the Infrastructure Team once the merge has been completed. The Merge Team and later the Infrastructure Team will have participants from inside and outside of Red Hat." --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 alan at redhat.com Tue Dec 2 18:38:23 2003 From: alan at redhat.com (Alan Cox) Date: Tue, 2 Dec 2003 13:38:23 -0500 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0base to fedora core 1 In-Reply-To: <1070376729.10872.59.camel@spatula.pppl.gov> References: <1070376729.10872.59.camel@spatula.pppl.gov> Message-ID: <20031202183823.GF27398@devserv.devel.redhat.com> On Tue, Dec 02, 2003 at 09:52:10AM -0500, Jef Spaleta wrote: > What if the LiveCD I roll up..totally sucks? I assure you it would. > Should I be allowed to say that its based on Fedora Core? I don't think > so, because my crappy attempt at liveCD building would tarnish the > official work done as part of the official Fedora community effort. And Sure, and thats one of the big reasons that Fedora is a trademark, so it stands for something in terms of quality and protects the name and the users. However if someone puts together a LiveCD worthy of the Fedora name there is no fundamental reason it can't become a "Fedora LiveCD" providing its up to it. From nosp at xades.com Tue Dec 2 19:20:30 2003 From: nosp at xades.com (nosp) Date: Tue, 02 Dec 2003 19:20:30 +0000 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <20031202160354.GA8979@devserv.devel.redhat.com> References: <200312011029.07917.livelinux@nwst.de> <1070306893.1693.33.camel@duergar> <1070332179.26308.24.camel@hermione> <200312021300.15121.livelinux@nwst.de> <20031202160354.GA8979@devserv.devel.redhat.com> Message-ID: <1070392830.19593.82.camel@earth.xades.com> On Tue, 2003-12-02 at 16:03, Bill Nottingham wrote: > Dirk Westfal (livelinux at nwst.de) said: > > I'm currently using a fresh compiled 2.4.22 kernel from kernel.org with > > openmosix patches. > > Why do you need a separate kernel? OpenMosix seems like and odd requirement > for a live filesystem CD to me... The openmosix kernel patch doesn't play nice with the ones from the RH kernels. NPTL, especially. It's doable but non-trivial to amend the OM patches to work on NPTL. I started a while ago and got about halfway through the rejects but didn't have the time to finish. I suppose the motivation for OM is to be able to take the CD and some machines and be able to create a cluster without even adding water :). How useful/manageable that cluster would be, I don't know. From jspaleta at princeton.edu Tue Dec 2 21:07:28 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Tue, 02 Dec 2003 16:07:28 -0500 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0base to fedora core 1 Message-ID: <1070399248.10872.228.camel@spatula.pppl.gov> Alan Cox wrote: > Sure, and thats one of the big reasons that Fedora is a trademark, so > it stands for something in terms of quality and protects the name and > the users. > However if someone puts together a LiveCD worthy of the Fedora name there > is no fundamental reason it can't become a "Fedora LiveCD" providing its > up to it. Sure, no fundamental reason that this community could not embrace a liveCD or even several liveCD images that filled specific niche roles (like an easy bake mosix cluster node.) As long as the software incorporated into the liveCD was all officially blessed code. I think i even weakly held out an olive branch about that in my wrap up paragraph. I did most of the fist pounding in that post because the discussion was veering off about features that fedora core will not have, like ntfs support were claiming are prerequisites for a 'useful' demoing liveCD. So their might not be a fundamental issue with having a blessed liveCD image...but somehow, given the non-technical constraints, I'm not all that sure there is going to be a groundswell of community desire to build a liveCD image that stays within the non-technical constraints that a trademark blessing would demand. If a demo liveCD image requires ntfs support, then official demo liveCD image is pretty much a non-starter. Though fedora branded easy-bake cluster node liveCD would be..fascinating, though somewhat resource limited if they had to run out of ramdisk, which would take away from the available ram resources to run on each cluster node. -jef From pp at ee.oulu.fi Tue Dec 2 22:26:35 2003 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Wed, 3 Dec 2003 00:26:35 +0200 Subject: Vic^H^Holunteers needed for updated SATA code testing In-Reply-To: <3FCBF7B2.3060900@rackable.com> References: <20031116183756.GA21083@ee.oulu.fi> <20031128235827.GA23027@ee.oulu.fi> <20031130001635.GA12006@comcast.net> <3FCBF7B2.3060900@rackable.com> Message-ID: <20031202222635.GA12427@ee.oulu.fi> On Mon, Dec 01, 2003 at 06:23:46PM -0800, Samuel Flory wrote: > Which sata chipsets are we looking for? I've got a wide range of SI, > ICH5, Promise, Highpoint, and God knows what else. Other than a few > wierd software raid SATA controllers, and one ebedded promise > controllers it all works with the libata patches. If so even with the fc1 kernel with the updated patch, excellent! Actually I just put up a newer version of the patch (with the fixes in 2.4.23-libata1.patch merged). Also nuked the 0x3378 ID since the promise driver has 378 as 0x3373, which was already there, and nobody has said they needed it. Apparently there was some confusion when I asked someone on fedora whether their 378's ID was 0x3378 and they answered "yes", which is why I added it in the first place. Has gone through "it boots and detects the drive" testing, apparently selinux security labels screw up 2.4 kernels (not just this one) quite completely so that's all the testing I could do. Anyone know if there's an easy way to remove them apart from backup, mke2fs and restore? Same place as before, http://www.ee.oulu.fi/~pp/fc1-libata. Only athlon kernel+src.rpm+patch up, i686 coming up soon. I don't think I'll do a full set this time, it takes pretty long :/ -- Pekka Pietikainen From stan at ccs.neu.edu Tue Dec 2 23:19:21 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Tue, 02 Dec 2003 18:19:21 -0500 Subject: Unmaintained packages? Message-ID: <1070407160.1215.57.camel@duergar> Hey, Can we get a list of unmaintained projects/packages on this list that it is the communities to continue development on? I haven't seen such a list and this is the right place to start one, right? -sb From notting at redhat.com Tue Dec 2 23:21:38 2003 From: notting at redhat.com (Bill Nottingham) Date: Tue, 2 Dec 2003 18:21:38 -0500 Subject: Unmaintained packages? In-Reply-To: <1070407160.1215.57.camel@duergar> References: <1070407160.1215.57.camel@duergar> Message-ID: <20031202232138.GA13039@devserv.devel.redhat.com> Stan Bubrouski (stan at ccs.neu.edu) said: > Can we get a list of unmaintained projects/packages on this list that it > is the communities to continue development on? You mean ones in Fedora Core that might be moved out? Or just generally-unmaintained-in-open-source-land packages? Bill From stan at ccs.neu.edu Tue Dec 2 23:36:47 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Tue, 02 Dec 2003 18:36:47 -0500 Subject: Unmaintained packages? In-Reply-To: <20031202232138.GA13039@devserv.devel.redhat.com> References: <1070407160.1215.57.camel@duergar> <20031202232138.GA13039@devserv.devel.redhat.com> Message-ID: <1070408207.1215.61.camel@duergar> On Tue, 2003-12-02 at 18:21, Bill Nottingham wrote: > Stan Bubrouski (stan at ccs.neu.edu) said: > > Can we get a list of unmaintained projects/packages on this list that it > > is the communities to continue development on? > > You mean ones in Fedora Core that might be moved out? Or just > generally-unmaintained-in-open-source-land packages? > > Bill I was referring to open-source packages in general that are in use in fedora. I'll use libpng as an example, there hasn't been a patch or an update or ANY sign of development for over a year now. There would be no way to find and maintain every useful open-source package outside of Fedora IMHO. Hope that clarifies. So off the top of my head I'll start the list: libpng heh. -sb From steve at rueb.com Wed Dec 3 00:05:15 2003 From: steve at rueb.com (Steve Bergman) Date: Tue, 02 Dec 2003 18:05:15 -0600 Subject: Updating to the development channel Message-ID: <1070409915.19250.15.camel@localhost.localdomain> What is the best way to tell up2date to update my fedora-core 1 box to the latest development version of fedora-core? I tried: yum updates-devel http://download.fedora.redhat.com/pub/fedora/linux/core/development and get: Fetching http://download.fedora.redhat.com/pub/fedora/linux/core/development/headers/header.info... ######################################## #################### Fetching rpm headers... Traceback (most recent call last): File "/usr/sbin/up2date", line 1188, in ? sys.exit(main() or 0) File "/usr/sbin/up2date", line 766, in main fullUpdate, dryRun=options.dry_run)) File "/usr/sbin/up2date", line 1051, in batchRun batch.run() File "up2dateBatch.py", line 58, in run File "up2dateBatch.py", line 99, in __findPackagesToUpdate File "packageList.py", line 520, in getPackagesToInstall File "packageList.py", line 549, in __skipPackages File "packageList.py", line 570, in __skipFiles File "packageList.py", line 609, in buildHeaderList File "headers.py", line 37, in __getitem__ File "headers.py", line 42, in __retrievePackage File "rpcServer.py", line 110, in doCall File "repoDirector.py", line 31, in getHeader File "rpmSource.py", line 210, in getHeader File "/usr/share/rhn/up2date_client/repoBackends/yumRepo.py", line 96, in getHeader hdrBuf = fh.read() File "/usr/lib/python2.2/gzip.py", line 156, in read self._read(readsize) File "/usr/lib/python2.2/gzip.py", line 210, in _read self._read_eof() File "/usr/lib/python2.2/gzip.py", line 245, in _read_eof raise ValueError, "CRC check failed" ValueError: CRC check failed From stan at ccs.neu.edu Tue Dec 2 23:37:59 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Tue, 02 Dec 2003 18:37:59 -0500 Subject: Unmaintained packages? In-Reply-To: <20031202232138.GA13039@devserv.devel.redhat.com> References: <1070407160.1215.57.camel@duergar> <20031202232138.GA13039@devserv.devel.redhat.com> Message-ID: <1070408278.1215.63.camel@duergar> On Tue, 2003-12-02 at 18:21, Bill Nottingham wrote: > Stan Bubrouski (stan at ccs.neu.edu) said: > > Can we get a list of unmaintained projects/packages on this list that it > > is the communities to continue development on? > > You mean ones in Fedora Core that might be moved out? Or just > generally-unmaintained-in-open-source-land packages? > > Bill > Oh and let me clarify one more thing: I'm only talking about useful packages in Fedora that shouldn't be going anywhere but back into development. -sb > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From warren at togami.com Wed Dec 3 02:41:35 2003 From: warren at togami.com (Warren Togami) Date: Tue, 02 Dec 2003 16:41:35 -1000 Subject: Unmaintained packages? In-Reply-To: <1070408278.1215.63.camel@duergar> References: <1070407160.1215.57.camel@duergar> <20031202232138.GA13039@devserv.devel.redhat.com> <1070408278.1215.63.camel@duergar> Message-ID: <1070419294.10532.16.camel@laptop> On Tue, 2003-12-02 at 13:37, Stan Bubrouski wrote: > On Tue, 2003-12-02 at 18:21, Bill Nottingham wrote: > > Stan Bubrouski (stan at ccs.neu.edu) said: > > > Can we get a list of unmaintained projects/packages on this list that it > > > is the communities to continue development on? > > > > You mean ones in Fedora Core that might be moved out? Or just > > generally-unmaintained-in-open-source-land packages? > > > > Bill > > > > Oh and let me clarify one more thing: I'm only talking about useful > packages in Fedora that shouldn't be going anywhere but back into > development. http://www.fedora.us/QA Here are a ton of packages that need more developers to review and test. http://www.fedora.us/wiki/PackageSubmissionQAPolicy If you are interested, this is how you can get involved. Warren From xose at wanadoo.es Wed Dec 3 03:22:47 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 03 Dec 2003 04:22:47 +0100 Subject: Fedora minimal install option References: Message-ID: <3FCD5707.8060504@wanadoo.es> Mako Gabor wrote: > I have a suggest for Fedora Linux. :) > There isn't Minimum Install option (only console with base rpm packages > ~150MB?) and Mininum XWindow Install options in Fedora/RedHat Install. > (There are only Workstation, Dekstop, Server, Custom options.) > I like to use the minimal install options often. > > Can you implement them into the install options? This is a classical RFE: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89747 And I don't see any problem to implemented it. But RH people doen's like it. From makgab at freemail.hu Wed Dec 3 07:12:13 2003 From: makgab at freemail.hu (Mako Gabor) Date: Wed, 03 Dec 2003 08:12:13 +0100 (CET) Subject: Fedora minimal install option In-Reply-To: <20031202170011.27831.49863.Mailman@listman.back-rdu.redhat.com> Message-ID: 02-Dec-2003 fedora-devel-list-request at redhat.com: > From: Robert Marcano > > If I remember correctly, you can use the custom option, and on the > package selection screen yo can choose Minimum Install or Full Install, > the last two options (The last time i saw those options was using RH9, i > don't remember if Fedora still has them) > The custom install allow the packages selection. But I could not see it in the Fedore Core 1. :( If I don't select packages in the custom install option, then the Linux (Fedora and RH9) install ~900MB. It is too many for minimal. It contains many packages that are not necessary (for examples redhat-artwork etc.). > From: Klaasjan Brand > > I don't know exactly how small you can get Fedora (anyone? :), but you I would like the absolute minimal packages! :) > can do a custom install and only install packages you really need. If > you create a "kickstart" install script you can repeat the same > installation for multiple systems. > Kickstart? How can I create it? > From: Rui Miguel Seabra > > I haven't looked into Fedora Core's Minimum Install yet, but RedHat's > Minimum Install is _all_but_minimal_. > I haven't seen the minimal install option in RedHat. > A Minimum Install should look _almost_ like an OpenBSD default boot: > > No services active (BECAUSE THEY'RE NOT EVEN INSTALLED) > NO X. > Just the necessary to boot and make post install installations. > Yes, I want it! :) I would like minimal install then reboot system and if necessary I install the additional packages (like Debian Linux :)). Bye! Gabor From linux at bytebot.net Wed Dec 3 08:57:46 2003 From: linux at bytebot.net (Colin Charles) Date: Wed, 03 Dec 2003 16:57:46 +0800 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0base to fedora core 1 In-Reply-To: <1070376729.10872.59.camel@spatula.pppl.gov> References: <1070376729.10872.59.camel@spatula.pppl.gov> Message-ID: <1070435639.28141.82.camel@hermione> On Tue, 2003-12-02 at 22:52, Jef Spaleta wrote: > >Hmm, Debian is a USA based project, and Knoppix, it's spin-off is > >based in Germany. > > The KEY to this statement of fact is that Knoppix is spelled differently > than Debian, and I would hope Knoppix refrains from using Debian's > trademarks and logos inside the Knoppix isos. There is more than enough > room for a derivative work that begins with software provided by Fedora > to create a liveCD that is legal in other countries. BUT, it should not > use trademarked Fedora images or logos. In fact if you read through the > trademark guidelines at fedora.redhat.com ... I'm really not sure that > you should use the Fedora name associated at all, even to say its a > derivative work, with a livecd that is rolled up outside of the > 'official' structure. Fair enough. I think Dirk Westfal better be reading, lest he lands up in trouble. Alan Cox has mentioned that if its worthy, it could be called the "Fedora LiveCD". Who decides its worthiness? > What if the LiveCD I roll up..totally sucks? I assure you it would. > Should I be allowed to say that its based on Fedora Core? I don't think > so, because my crappy attempt at liveCD building would tarnish the > official work done as part of the official Fedora community effort. And > don't try to argue that people using and reviewing my crappy little > liveCD should know better than to link the very bad craftmanship of MY > customized work to the craftsmanship of the Fedora project in general. > In an effort to avoid tarnishing the reputation of the Fedora name...i > should NOT be allowed to use or even to refer to Fedora when advertising > my co-mingled customized liveCD image. In fact... i would suggest(from a > fairplay point of view) that ALL custom liveCD's should have to live > outside the allowable usage of the Fedora trademarks because the liveCD > distribution format makes it very difficult to distiguish what is > customized and what is original Fedora craftsmanship. Which is very > different than something like an OEM pre-install, where the OEM can give > the customer a set of Fedora Core disks as well as a seperate piece of > media for the OEM addon packages making up the full OEM pre-install of > Fedora. Yes, I didn't look at it from this point of view. Naming seems to be everything these days. > Of course pulling out ALL the text that refers to the distro as > Fedora(not to mention all the lingering Red Hat references) is probably > a non trivial task at the moment....maybe there is room in the > continuing dialog for an official liveCD image, but somehow i doubt an > officially blessed liveCD image would fill the niche well, considering > the non-technical limitations being 'officially' blessed would carry. Well, to some degree, I guess the LiveCD project is in beta and can't be "officially" blessed, because it doesn't even run the regular Fedora kernel. It's a stock kernel with openmosix patches applied. > -jef"if the point of a liveCD is to demo a distro...but the liveCD ends > up having many custom features the base distro does not have like ntfs > support...what's the point again?"spaleta There exists ntfs read support apparently. Actually, veering from this, maybe we should be creating a Fedora non-us archive of sorts? Or is Fedora Extras a project that'll keep the NTFS stuff, and the non-blessed Core stuff? (currently, that seems to be the case, with the mplayer/divx/mp3 archives). -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ From keithl at kl-ic.com Wed Dec 3 09:01:33 2003 From: keithl at kl-ic.com (Keith Lofstrom) Date: Wed, 3 Dec 2003 01:01:33 -0800 Subject: Fedora LiveCD / Emergency Boot CD Message-ID: <20031203090133.GA31472@gate.kl-ic.com> When designing the Fedora LiveCD - think about a future version that works with the "create boot disk" function. Imagine creating a boot CD that has everything necessary to rebuild the main hard drive, including partition info, net configuration, etc, as well as Mozilla and other tools, so one can look on the net for more clues, learn about replacement hardware, etc. Another generalization would be tools that help build custom versions of LiveCD. That is probably too large a task for the first version of LiveCD, but having these future goals in mind probably influences design choices now. And please forgive this suggestion from someone who probably doesn't have the skills to contribute. Keith -- Keith Lofstrom keithl at ieee.org Voice (503)-520-1993 KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon" Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs From qralston+ml.redhat-fedora-devel at andrew.cmu.edu Wed Dec 3 09:13:44 2003 From: qralston+ml.redhat-fedora-devel at andrew.cmu.edu (James Ralston) Date: Wed, 03 Dec 2003 04:13:44 -0500 Subject: integrate cryptoloop patch into Fedora kernel? Message-ID: <33140000.1070442824@shieldbreaker.l33tskillz.org> See my "Encrypted loopback devices in Fedora Core 1" section, here: http://www.pobox.com/~ralston/dev/ Any chance of integrating at least the kernel patch into the FC development kernel? Having to patch the kernel itself is a giant PITA. Honestly, I was expecting that updating to util-linux-2.12 would be a nightmare, but it was a breeze. (Elliot, if you're reading this, Just Do It; it'll take a lot less time than you probably think.) The hashalot program needs some work; it's using the obsolete getpass() function, and the memset call that is clearing the password is almost certainly being optimized away by gcc. :( I'll fix the latter for sure, and work on the former. -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA From livelinux at nwst.de Wed Dec 3 10:43:23 2003 From: livelinux at nwst.de (Dirk Westfal) Date: Wed, 3 Dec 2003 11:43:23 +0100 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0base to fedora core 1 / Legal issue Discussion In-Reply-To: <1070435639.28141.82.camel@hermione> References: <1070376729.10872.59.camel@spatula.pppl.gov> <1070435639.28141.82.camel@hermione> Message-ID: <200312031143.23928.livelinux@nwst.de> Hi all, thanks for the feedback and hints/headsups (it never occurred to me, that ntfs read support might be a problem ...) : On Wednesday 03 December 2003 09:57, Colin Charles wrote: > On Tue, 2003-12-02 at 22:52, Jef Spaleta wrote: > > >Hmm, Debian is a USA based project, and Knoppix, it's spin-off is .... > Fair enough. I think Dirk Westfal better be reading, lest he lands up in > trouble. That's why I'm using the term 'based on' or 'uses packages of'. Currently (and also in future) my cd does not use any official logos of neither redhat nor fedora. I did not (and do not ;) intend to claim to build the 'official' demo cd, I'm merely porting my existing system(s) to fedora to look how it will work out. (since rh9.0 will end in april 2004 i had to decide wether to switch to debian, rh enterprise or fedora. ) A cd that i create will most likely be named somthing like 'xkde/ basilisk, using packages of fedora core 1' > Alan Cox has mentioned that if its worthy, it could be called the > "Fedora LiveCD". Who decides its worthiness? in short: fedora staff and developer community ? ;-) > > What if the LiveCD I roll up..totally sucks? I assure you it would. ... Full ACK! here. > > Yes, I didn't look at it from this point of view. Naming seems to be > everything these days. Again, full ACK. .... > Well, to some degree, I guess the LiveCD project is in beta and can't be > "officially" blessed, because it doesn't even run the regular Fedora > kernel. It's a stock kernel with openmosix patches applied. so i'm not too much under pressure here ... > > -jef"if the point of a liveCD is to demo a distro...but the liveCD ends > > up having many custom features the base distro does not have like ntfs > > support...what's the point again?"spaleta I think a 'officially blessed' live cd should truly include only packages and features that the fedora developer community agrees on - I think it's a little to early for this. > > There exists ntfs read support apparently. > > Actually, veering from this, maybe we should be creating a Fedora non-us > archive of sorts? Or is Fedora Extras a project that'll keep the NTFS > stuff, and the non-blessed Core stuff? (currently, that seems to be the > case, with the mplayer/divx/mp3 archives). That could be a great idea - especially for a non us customer... so long, Dirk Westfal -- Dirk Westfal //Admin//RHCE/6.2//QB/DGQ mailto: root[/livelinux]@nwst.de livecd based on Redhat 9.0 : server / xkde + openmosix : www.nwst.de / www.linux4all.de From livelinux at nwst.de Wed Dec 3 10:45:44 2003 From: livelinux at nwst.de (Dirk Westfal) Date: Wed, 3 Dec 2003 11:45:44 +0100 Subject: Fedora LiveCD / Emergency Boot CD In-Reply-To: <20031203090133.GA31472@gate.kl-ic.com> References: <20031203090133.GA31472@gate.kl-ic.com> Message-ID: <200312031145.44632.livelinux@nwst.de> On Wednesday 03 December 2003 10:01, Keith Lofstrom wrote: ... > Another generalization would be tools that help build custom versions > of LiveCD. ... > Keith That's one of my 'focus' point's since live cd's mostly need some special applications to be really usefull for a customer. Question: would it be possible and usefull to add something like an 'createlivecd' install option to the installer ? I currently use a shellscript to create the livecd master - (=/) filesystem on a running system from a comps file. (it dropps priviliges to an 'installuser' to prevent damage to the host system and then just runs a relocated rpm installation.) I think it would be nice to do this from the common fedora installer - this would greatly ease the creation and maintenance of images for cd's, usb-sticks, ext. usb drives etc.). Maybe there are some other people (like me ;-) who would find it usefull ? greetings, Dirk -- Dirk Westfal //Admin//RHCE/6.2//QB/DGQ mailto: root[/livelinux]@nwst.de livecd based on Redhat 9.0 : server / xkde + openmosix : www.nwst.de / www.linux4all.de From livelinux at nwst.de Wed Dec 3 10:49:52 2003 From: livelinux at nwst.de (Dirk Westfal) Date: Wed, 3 Dec 2003 11:49:52 +0100 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0 base to fedora core 1 In-Reply-To: <20031202160354.GA8979@devserv.devel.redhat.com> References: <200312011029.07917.livelinux@nwst.de> <200312021300.15121.livelinux@nwst.de> <20031202160354.GA8979@devserv.devel.redhat.com> Message-ID: <200312031149.52674.livelinux@nwst.de> On Tuesday 02 December 2003 17:03, Bill Nottingham wrote: .. > Why do you need a separate kernel? OpenMosix seems like and odd requirement > for a live filesystem CD to me... > > Bill > True, but i'm also doing clustering and it's just great to get a 10 Node cluster up and running in less than 15 Minutes by just booting from cd. In fact only inital ramdisk and tmpfs support are required for the kernel of my livecd. bye, Dirk -- Dirk Westfal //Admin//RHCE/6.2//QB/DGQ mailto: root[/livelinux]@nwst.de livecd based on Redhat 9.0 : server / xkde + openmosix : www.nwst.de / www.linux4all.de From pauln at truemesh.com Wed Dec 3 11:21:13 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 3 Dec 2003 11:21:13 +0000 Subject: A beginners guide to bugtool Message-ID: <20031203112109.GH26011@ensim.rackshack.net> Bugtool can be found here: http://people.redhat.com/jrb/files/ A sample .bugzrc with some custom queries can be found here: http://pauln.truemesh.com/bugzrc Drop the rc file into ~/.bugzrc, edit to change username and password. Run bugtool Your drop down menu now contains some of my custom queries. Creating query support to be written, but should give you a flavour of the tool. Probably will only run on RH9/FC1 and above - if you are running rawhide be sure to have gnome-python-* updated. I'd be intrested if people doing triaging today who want to play with bugtool let me know via #fedora-bugs on freenode. Unfortunately some queries don't return at the moment (essentially they timeout) but hopefully some more use will help the developers figure out what the priorites are in terms of features. Paul From buildsys at porkchop.devel.redhat.com Wed Dec 3 12:32:10 2003 From: buildsys at porkchop.devel.redhat.com (Build System) Date: Wed, 3 Dec 2003 07:32:10 -0500 Subject: rawhide report: 20031203 changes Message-ID: <200312031232.hB3CWAk08180@porkchop.devel.redhat.com> New package device-mapper device mapper library New package lvm2 Userland logical volume management tools Updated Packages: SysVinit-2.85-11.sel -------------------- * Mon Dec 01 2003 Dan Walsh 2.85-11.sel - Don't umount /selinux, this is required for selinux to work correctly. coreutils-5.0-33.sel -------------------- * Tue Dec 02 2003 Tim Waugh 5.0-33.sel - Speed up md5sum by disabling speed-up asm. cyrus-imapd-2.1.15-3 -------------------- * Mon Dec 01 2003 Karsten Hopp 2.1.15-3 - fix RPATH the hard way dhcp-3.0pl2-6.17 ---------------- * Sun Nov 30 2003 Dan Walsh 1:3.0pl2-6.17 - Add obsoletes dhcpcd freeciv-1.14.1-1 ---------------- * Wed Dec 03 2003 Karsten Hopp 1.14.1-1 - update to bugfix release 1.14.1 gnome-pilot-2.0.10-5 -------------------- * Tue Dec 02 2003 Thomas Woerner 2.0.10-5 - removed rpath (patched libtool, removed LIBTOOL=%{_bindir}/libtool from make call in %build) * Fri Nov 28 2003 Jeremy Katz - call scrollkeeper update in %post (#111159) - prereq scrollkeeper and GConf2 - -devel should require libgnomeui-devel (#111160) librep-0.16.1-4 --------------- * Tue Dec 02 2003 Thomas Woerner 1:0.16.1-4 - removed rpath from rep-config make-3.80-2 ----------- * Tue Dec 02 2003 Florian La Roche - add important bug-fixes from make home-page mozilla-1.4.1-18 ---------------- * Thu Nov 13 2003 Christopher Blizzard 37:1.4.1-18 - Include patch that fixes crashing problems with fonts that can't be read nss_db-2.2-23 ------------- * Tue Dec 02 2003 Nalin Dahyabhai 2.2-23 - find bundled libdb again (#111004) * Tue Aug 12 2003 Nalin Dahyabhai 2.2-21.1 - rebuild pmake-1.45-13 ------------- * Tue Dec 02 2003 Jakub Jelinek - fix #111033 policy-1.3.2-1 -------------- * Tue Dec 02 2003 Dan Walsh 1.3.2-1 - Latest policy from Russell * Tue Nov 04 2003 Dan Walsh 1.3-3 - Patch to make minimal policy work * Fri Oct 24 2003 Dan Walsh 1.3-1 - Russel's policy file * Thu Oct 02 2003 Dan Walsh 1.0-3 - Latest from NSA * Mon Aug 18 2003 Paul Nasrat 1.2-1 - Enable non-root build * Mon Jun 02 2003 Dan Walsh 1.0-1 - Initial version rpmdb-fedora-1.90-0.20031203 ---------------------------- texinfo-4.6-1 ------------- * Tue Dec 02 2003 Tim Waugh 4.6-1 - Fixed compiler warning (bug #111279). - 4.6. * Tue Jun 17 2003 Tim Waugh 4.5-3 - Rebuilt. vim-6.2.154-3 ------------- * Tue Dec 02 2003 Karsten Hopp 1:6.2.154-3 - perl interface was disabled when perl had thread support. From peter.backlund at home.se Wed Dec 3 12:39:33 2003 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 03 Dec 2003 13:39:33 +0100 Subject: Failsafe XFree config Message-ID: <3FCDD985.4060402@home.se> Hi. Would it be possible to keep a failsafe X config for using when X won't start under normal cirumstances? Say, 16 bit color, 60 Hz, 640x480, vesa driver and AllowMouseOpenFail? One quite common scenario is when you're using ati or nvidia drivers, and you update the kernel without installing the new ati/nvidia kernel modules. As it works now, you're dropped to a console after being prompted with the possibility to read the X logs. I believe the XKeepsCrashing script is invoked here...it would be a lot easier to fix these problems if you at least get a basic X environment to work with. One would pass this alternative config to xinit, with a window prompt telling you that a problem occured yada yada and you're running a failsafe X mode. What do you think? /Peter From jspaleta at princeton.edu Wed Dec 3 15:03:46 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 03 Dec 2003 10:03:46 -0500 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0base to fedora core 1 / Legal issue Discussion Message-ID: <1070463826.13370.39.camel@spatula.pppl.gov> Dirk Westfal wrote: > That's why I'm using the term 'based on' or 'uses packages of'. > Currently (and also in future) my cd does not use any official logos of > neither redhat nor fedora. Personally, I'd be wary of even doing that. The right answer of course is, trademark is a crappy legal issue..and therefore the only way to really settle it is to talk to a lawyer. The src code is of course there to be used...but the point at which one can claim a specialized distro is 'based on' Fedora is a not well defined in layspeak. Nothing I've read so far in the trademark section of the fedora.redhat.com website jumps out and says yes/no to this specific sort of 'based on' or 'packages from' advertising. My reading of http://fedora.redhat.com/about/trademarks/guidelines/ tells me you should get clarification from some form of legal counsel. But stepping back from the legalese arguments for a moment. Are you prepared to remove advertising that says your liveCD was based on Fedora, if the Fedora leadership made that request? Legally binding trademark issues aside. I think there are pros/cons to having experimental development to be able to use 'based on' Fedora advertising. On the pro side...its a PR win for Fedora to be seen as enabling a range of experimental development, thats a PR win for a more open process. On the con side... any problems with a custom distro picking up and using pieces of Fedora make it harder to distinguish where bug reports go and could become a drag on the official development process. What happens if your patched kernel exposes a bug in a fedora package that you are using in your liveCD? Where do those bug reports live? Is it even appropriate for users of your liveCD to report back any problems to the Fedora development process? Is the real value in the Fedora brand going to be the bits and pieces or is it going to be the development process and structure? If the value is in the development process...the saying 'based on' Fedora would be interpreted as 'based on' the development process. >> >> There exists ntfs read support apparently. >> >> Actually, veering from this, maybe we should be creating a Fedora non-us >> archive of sorts? Or is Fedora Extras a project that'll keep the NTFS >> stuff, and the non-blessed Core stuff? (currently, that seems to be the >> case, with the mplayer/divx/mp3 archives). >That could be a great idea - especially for a non us customer... Again there are going to be issues with calling anything 'Fedora.' There is clearly a place and a demand for a 'freeworld' shadow community process and repository structure that builds on top of the base Fedora process to provide open-source solutions that a US based organization is prohibited from providing for non-technical reasons. But for the same non-technical reasons, it will be very difficult for the official Fedora process to even link or to talk about the 'freeworld' structure that springs up. -jef From brugolsky at telemetry-investments.com Wed Dec 3 15:24:18 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Wed, 3 Dec 2003 10:24:18 -0500 Subject: Fedora LiveCD : Looking for Betatesters - Port of redhat 9.0base to fedora core 1 / Legal issue Discussion In-Reply-To: <1070463826.13370.39.camel@spatula.pppl.gov> References: <1070463826.13370.39.camel@spatula.pppl.gov> Message-ID: <20031203152418.GB2945@ti19.telemetry-investments.com> On Wed, Dec 03, 2003 at 10:03:46AM -0500, Jef Spaleta wrote: > Again there are going to be issues with calling anything 'Fedora.' > There is clearly a place and a demand for a 'freeworld' shadow community > process and repository structure that builds on top of > the base Fedora process to provide open-source solutions that a US based > organization is prohibited from providing for non-technical reasons. But > for the same non-technical reasons, it will be very difficult for the > official Fedora process to even link or to talk about the 'freeworld' > structure that springs up. Easily solved by a level of indirection. Simply bless a *canonical* search string (e.g. "Fedora-compatible") for finding Fedora-related resources, encourage site operators to use it, and leave it up to the users to find them. A Fedora free world web ring might also have some value. Regards, Bill Rugolsky From jspaleta at princeton.edu Wed Dec 3 15:24:06 2003 From: jspaleta at princeton.edu (Jef Spaleta) Date: Wed, 03 Dec 2003 10:24:06 -0500 Subject: Fedora LiveCD / Emergency Boot CD Message-ID: <1070465046.13370.51.camel@spatula.pppl.gov> Dirk Westfal wrote: > Question: would it be possible and usefull to add something like > an 'createlivecd' install option to the installer ? Now thats a very good question that has NOTHING to do with trademarks....and everything to do with development. i personally LOVE the idea of a livecd building toolbox as something that can be added to the Fedora distro. But I don't think it makes sense as an installer option....but maybe this is a direction to extend kickstart? I think a stand-alone post install tool sitting on a 'mastering' Fedora Core install that knew how to access multiple rpm souces like yum repos to grab packages needed for the livecd would be more useful than something the installer would have to manage from a ramdisk image. I don't a lot about kickstart, but how kickstart creates kickstart files via redhat-config-kickstart seems an obvious starting point example of a tool that can look at setup of a 'mastering' host. -jef -jef From thomas at apestaart.org Wed Dec 3 15:46:26 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 03 Dec 2003 16:46:26 +0100 Subject: The current fedora.us buildsystem and future directions In-Reply-To: <20031201200051.GB23909@devserv.devel.redhat.com> References: <877k1lqctg.fsf@kosh.ultra.csn.tu-chemnitz.de> <20031129022551.GA31280@devserv.devel.redhat.com> <87n0acia82.fsf@kosh.ultra.csn.tu-chemnitz.de> <20031201200051.GB23909@devserv.devel.redhat.com> Message-ID: <1070466385.5414.58.camel@otto.onshuis> ?? > Enrico Scholz (enrico.scholz at informatik.tu-chemnitz.de) said: > > >> 1. SELinux can protect foreign processes. But is it possible to hide > > >> them in /proc also? > > > > > > If you cannot access it, why does it matter if it is visible? > > > > E.g. 'service xyz stop' in rpm-scriptlets may have an unwanted behavior > > when it sees 'xyz' processes in other "contexts". > > In general, you'll be able to tell that there's a process at pid , > but not what process it is. > > Note that scriplets in a build root very very very very very rarely > need to kick processes, if ever. One particularly embarassing test run of mach comes to mind where I tried rebuilding and installing the patched openssh rpms and it shut down the sshd process in the main context because the install scriptlet restarts sshd. So it might happen very very very very rarely, but it was also very very very very painful at that particular time. So I'm down with Enrico, as always. Thomas From thomas at apestaart.org Wed Dec 3 16:27:20 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 03 Dec 2003 17:27:20 +0100 Subject: I gotta ask this ... In-Reply-To: References: Message-ID: <1070468840.5414.60.camel@otto.onshuis> As for general package building inside clean chroots, mach may be of use to you. http://thomas.apestaart.org/projects/mach/ I'm in the process of updating it so it builds for Fedora Core 1 as well, almost there but I have some heads to butt together before I can finish it. Thomas ?? > Hi everyone, > > I have seen several posts in the past where someone asks about building > Fedora ISO images. I have yet to see a response. > > Surely _someone_ must know how this is done. Why is there never a response? > Is this knowledge a 'secret sauce' that nobody wishes to share? > > F > > _________________________________________________________________ > The new MSN 8: advanced junk mail protection and 2 months FREE* > http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From m.a.young at durham.ac.uk Wed Dec 3 16:33:02 2003 From: m.a.young at durham.ac.uk (M A Young) Date: Wed, 3 Dec 2003 16:33:02 +0000 (GMT) Subject: Fedora minimal install option In-Reply-To: References: Message-ID: On Wed, 3 Dec 2003, Mako Gabor wrote: > The custom install allow the packages selection. But I could not see it in the > Fedore Core 1. :( > If I don't select packages in the custom install option, then the Linux (Fedora > and RH9) install ~900MB. It is too many for minimal. It contains many > packages that are not necessary (for examples redhat-artwork etc.). The actually minimal install using the standard installer is about 510Mb, which you get by deselecting all the optional packages at the right point, though you need over 600Mb of diskspace to actually install this. The absolute minimum presumably consists of a handful of key packages (such as kernel, glibc, initscripts) plus any dependent packages, which prbably comes to 2-300 Mb, though this may be too minimal to do anything with. Michael Young From thomas at apestaart.org Wed Dec 3 17:37:45 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 03 Dec 2003 18:37:45 +0100 Subject: Red Carpet ? In-Reply-To: <3FC2E456.40900@wilcoxon.org> References: <3d9873790106da07d3@[192.168.170.10]> <3FC2E456.40900@wilcoxon.org> Message-ID: <1070473065.5032.1.camel@otto.onshuis> The number one advantage of red carpet is the use of channels. This means you can actively browse a channel for software and just install the one package from there plus it's dependencies, but it doesn't lock you into that channel for the future. In practice this means that, for example, I could have gotten the latest gaim rpm from updates-testing without having to chain my whole system to testing. I understand apt allows something called pinning but I have never had the courage to configure it :) red-carpet makes stuff like this dead easy. Thomas El mar, 25-11-2003 a las 06:10, Elliott Wilcoxon escribi??: > Is it just me, or does red carpet's use sound an awful lot like > apt/yum/up2date? Does it offer something that's above and beyond their > existing feature sets? > > Elliott Wilcoxon > > Nils O. Sel??sdal wrote: > > > Ximian just released a new version of Red-Carpet. Would it be an idea > > to make RC channels of fedora.us(and Fedora for that matter) ? > > RedCarpet does in my opinion make software installation a no brainer > > for most people. > > > > http://www.ximian.com/products/redcarpet/ > > http://www.opencarpet.org/ > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From avery at loran.com Wed Dec 3 18:42:45 2003 From: avery at loran.com (Mike Avery) Date: Wed, 03 Dec 2003 13:42:45 -0500 Subject: Self Introduction: Mike Avery Message-ID: <3FCE2EA5.1050401@loran.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Following the suggestion at http://www.fedora.us/wiki/SelfIntroduction Here is my info! I'm answering the questions posted at the page above.. Mike Avery Ottawa, Canada IT Manager Can't post Company name in public I'd like to help out with the system-config tools. I've send a note to Brent regarding creation of a system-config-nis. I have begun work on this now. My goal in contributing to The Fedora Project is aiding in the creation and refinement of powerful but intuitive tools for both GUI and CLI users. I'd like to see system-config-nis incorporated in the stable Fedora releases eventually. I'd also like to get involved in lower level systems programing for Fedora, but I'll get my feet wet with something new first. I don't mind doing QA as time permits. Here come the qualifications since I have to list them.. I have been a UNIX administrator for 11 years. I've used Linux and other free operating systems anywhere possible (exclusively when possible) since 1994. Same goes for the software that runs on those systems. I have deployed and administered many flavours on several hardware platforms. My strength in this area has been in the development and maintenance of UNIX development environments (GNU tools) on HP-UX, Linux, AIX, Solaris, and BSD(s). I can manage Windows environments as well, although I don't enjoy doing it. I consider myself a lucky person, who has been paid to work with free software for nearly 10 years. I have contributed to the (former) UCD-SNMP project in the form of a GUI for SNMP management of network devices. It was an experimentation in GUI design for me. I still use it today, although I doubt anyone else does :) It can be found here: http://savannah.nongnu.org/projects/x-snmp I have done some combat and play mechanics development for Adonthell, a graphical RPG written in C/C++. This work is/was experimental, but very fun and challenging. I have done quite a bit of work related coding. Mostly systems programing. I have developed Linux/UNIX hardware detection routines for PCI controllers, PnP, SMBios, and NICs. This was proprietary work and is not freely available. I have also developed some proprietary tools for UNIX application inventory a detection. These are also proprietary and not available. I have good experience in UNIX/C, somewhat less in C++. I know several interpreted languages (Tcl/tk, awk, shells, Python, perl, yadda yadda) in varying degrees, although I can get what I need done in all of them. I have used a few GUI different tool kits. I have limited experience with GTK, but I think my limitations at this point are syntax and familiarity. Why should you trust me? Don't until convinced to. Thanks, Mike Avery -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/zi6lN3sECpyP0qERAnFwAKDGPeiILcTxLa8ns0LFXQFYbNNaswCg6XlO HtENkk66mCRl69CG/cVojHo= =85ve -----END PGP SIGNATURE----- From stan at ccs.neu.edu Wed Dec 3 18:48:12 2003 From: stan at ccs.neu.edu (Stan Bubrouski) Date: Wed, 03 Dec 2003 13:48:12 -0500 Subject: Fedora minimal install option In-Reply-To: References: Message-ID: <1070477291.1215.75.camel@duergar> On Wed, 2003-12-03 at 11:33, M A Young wrote: > The absolute minimum presumably consists of a handful of key packages > (such as kernel, glibc, initscripts) plus any dependent packages, which > prbably comes to 2-300 Mb, though this may be too minimal to do anything > with. > Not at all. Minimal installs are great on older machines where only a couple basic services need to be offered. For instance an old 166MHz pentium used for a gateway or as an SMTP relay. -sb > Michael Young > > From xose at wanadoo.es Wed Dec 3 19:14:38 2003 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Wed, 03 Dec 2003 20:14:38 +0100 Subject: Fedora minimal install option References: <1070477291.1215.75.camel@duergar> Message-ID: <3FCE361E.6050308@wanadoo.es> Stan Bubrouski wrote: > On Wed, 2003-12-03 at 11:33, M A Young wrote: >>The absolute minimum presumably consists of a handful of key packages >>(such as kernel, glibc, initscripts) plus any dependent packages, which >>prbably comes to 2-300 Mb, though this may be too minimal to do anything >>with. > Not at all. Minimal installs are great on older machines where only a > couple basic services need to be offered. For instance an old 166MHz > pentium used for a gateway or as an SMTP relay. Not necessarily only in old hardware. There are a lot of places where a _spartan_ installation is great idea: web nfs database... servers, snort , firewalls, ... usually with *dedicated* services. And there are important benefits: installations, re-installations and crash recovery are faster, it's more secure, less packages to maintain ... From enrico.scholz at informatik.tu-chemnitz.de Wed Dec 3 19:32:57 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 03 Dec 2003 20:32:57 +0100 Subject: Fedora minimal install option In-Reply-To: (M. A. Young's message of "Wed, 3 Dec 2003 16:33:02 +0000 (GMT)") References: Message-ID: <87zne93dee.fsf@kosh.ultra.csn.tu-chemnitz.de> m.a.young at durham.ac.uk (M A Young) writes: > [... minimal FC1 installation ...] > The absolute minimum presumably consists of a handful of key packages > (such as kernel, glibc, initscripts) plus any dependent packages, which > prbably comes to 2-300 Mb, though this may be too minimal to do anything > with. The Absolute (non-empty) minimum are 6 packages (glibc, glibc-common, tzdata, basesystem, filesystem, setup). The next step are 56 packages[1] which are needing 71 MiB (installed languages: C,de,en,es,fr); an oldish deptree of them is available at http://www.tu-chemnitz.de/~ensc/rpmDirectoryCheck/results/rpm.png Then, adding the kernel + its deps, you will end in 63 packages which are taking 104 MiB. There is a potential to reduce this numbers by omitting all non-C languages, but rpm has a bug[2] which prevents this. Numbers are valid for Fedora Core 1 + current updates. Enrico Footnotes: [1] based on the apt rpmpriority file available at http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/distrib/fc1/apt/rpmpriorities?rev=HEAD [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108686 From steve at silug.org Wed Dec 3 19:46:59 2003 From: steve at silug.org (Steven Pritchard) Date: Wed, 3 Dec 2003 13:46:59 -0600 Subject: Red Carpet ? In-Reply-To: <1070473065.5032.1.camel@otto.onshuis> References: <3d9873790106da07d3@[192.168.170.10]> <3FC2E456.40900@wilcoxon.org> <1070473065.5032.1.camel@otto.onshuis> Message-ID: <20031203194659.GA17165@osiris.silug.org> On Wed, Dec 03, 2003 at 06:37:45PM +0100, Thomas Vander Stichele wrote: > I understand apt allows something called pinning but I have never had > the courage to configure it :) You should. Try the following in /etc/apt/preferences: Package: * Pin: release c=os Pin-Priority: 992 Package: * Pin: release c=stable Pin-Priority: 991 See the following for a little background, if you are interested: http://www.silug.org/lists/silug-discuss/200311/msg00079.html http://www.silug.org/lists/silug-discuss/200311/msg00080.html Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-7360 Mobile: (618)567-7320 From johnsonm at redhat.com Wed Dec 3 19:54:21 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 3 Dec 2003 14:54:21 -0500 Subject: new leadership draft being posted... In-Reply-To: <3FCBB2C2.4000509@wanadoo.es> References: <20031201212241.GA12103@devserv.devel.redhat.com> <3FCBB2C2.4000509@wanadoo.es> Message-ID: <20031203195421.GA8228@devserv.devel.redhat.com> On Mon, Dec 01, 2003 at 10:29:38PM +0100, Xose Vazquez Perez wrote: > would you mind to place the date of the latest modification > on bottom of all the web pages ? > > Now, it's nearly impossible to know when somebody modify a page. I'll get it started. There are a few pages in sufficient flux that I might miss adding the $Date$ strings in, but I think that once you see "This page last modified at:" on the web site, you can be reasonably sure that pages that don't show that text at the bottom haven't been recently modified. There's only one fly in this ointment: EVERY page will initially show modification because I have to modify the source to every page to put in $Date$ tags. Such is life, I guess. Heisenberg at work! ;-) 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 esr at thyrsus.com Wed Dec 3 20:02:50 2003 From: esr at thyrsus.com (Eric S. Raymond) Date: Wed, 3 Dec 2003 15:02:50 -0500 Subject: new leadership draft being posted... In-Reply-To: <20031203195421.GA8228@devserv.devel.redhat.com> References: <20031201212241.GA12103@devserv.devel.redhat.com> <3FCBB2C2.4000509@wanadoo.es> <20031203195421.GA8228@devserv.devel.redhat.com> Message-ID: <20031203200250.GC14401@thyrsus.com> Michael K. Johnson : > On Mon, Dec 01, 2003 at 10:29:38PM +0100, Xose Vazquez Perez wrote: > > would you mind to place the date of the latest modification > > on bottom of all the web pages ? > > > > Now, it's nearly impossible to know when somebody modify a page. > > I'll get it started. There are a few pages in sufficient flux that I > might miss adding the $Date$ strings in, but I think that once you see > "This page last modified at:" on the web site, you can be reasonably > sure that pages that don't show that text at the bottom haven't been > recently modified. There's a easier way. I use this Javascript fragment in my headers: