From veillard at redhat.com Fri Aug 1 13:39:34 2003 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 1 Aug 2003 09:39:34 -0400 Subject: Perl module rpm dependency problem In-Reply-To: <20030731231747.A6058@xos037.xos.nl>; from jos@xos.nl on Thu, Jul 31, 2003 at 11:17:47PM +0200 References: <200307310922.h6V9MsH04099@xos037.xos.nl> <1059666161.3458.26.camel@bobcat.mine.nu> <20030731231747.A6058@xos037.xos.nl> Message-ID: <20030801093934.C21597@redhat.com> On Thu, Jul 31, 2003 at 11:17:47PM +0200, Jos Vos wrote: > What about packaging XML-SAX-PurePerl? Shouldn't that solve the > problem? I have to admit I don't know much about this area, but > I needed XML-SAX because it is required by XML-LibXML. Really ? Sounds strange to me, maybe it's just to inherit the SAX class interface ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From veillard at redhat.com Fri Aug 1 13:42:21 2003 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 1 Aug 2003 09:42:21 -0400 Subject: Perl module rpm dependency problem In-Reply-To: <1059687876.3458.102.camel@bobcat.mine.nu>; from ville.skytta@iki.fi on Fri, Aug 01, 2003 at 12:44:36AM +0300 References: <200307310922.h6V9MsH04099@xos037.xos.nl> <1059666161.3458.26.camel@bobcat.mine.nu> <20030731231747.A6058@xos037.xos.nl> <1059687876.3458.102.camel@bobcat.mine.nu> Message-ID: <20030801094221.D21597@redhat.com> On Fri, Aug 01, 2003 at 12:44:36AM +0300, Ville Skytt? wrote: > On Fri, 2003-08-01 at 00:17, Jos Vos wrote: > > I have to admit I don't know much about this area, but > > I needed XML-SAX because it is required by XML-LibXML. > > Good luck! Tried it too and had to give up because of (IIRC) some > libxml2 weirdness/incompatibilities (RHL9); "make test" resulted in > segfaults, be sure to run it :) > > (libxml2 2.5.4 isn't explicitly listed in > http://search.cpan.org/src/PHISH/XML-LibXML-1.54/README but 2.5.5 is > "known as broken"...) Well if they don't report the problem back to the list or the maintainer there is little chance of improvements! BTW the current libxml2 version is 2.5.8 and I expect to release 2.5.9 for next week ... Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From mandreiana at rdslink.ro Sat Aug 2 12:15:30 2003 From: mandreiana at rdslink.ro (Marius Andreiana) Date: 02 Aug 2003 15:15:30 +0300 Subject: including gnome 2.4 in next red hat release Message-ID: <1059826529.5277.11.camel@marte.biciclete.ro> Hi As you know, Gnome 2.4 final should be available on september 10, 5 days before last rhl-beta release. There has been a lot of work on HIGification and usability. gnome 2.3 bugs: http://bugzilla.gnome.org/gnome-23-report.html If red hat developers are able to dedicate some time on crasher bugs, it will help on making it stable faster. Please consider including gnome 2.4 in next Red Hat release. It doesn't bring major new features, but it's more polished. Mandrake is recognized as the desktop distribution and Suse is getting more and more sales on enterprise servers, both using KDE. If gnome 2.4 is not included in next red hat, it will delay it's adoption until next release ( no, it won't be installed separately when it's out. Companies have time only to apply red hat official updates ) Thanks, -- Marius Andreiana Solu?ii informatice bazate pe Linux / Linux-based IT solutions www.galuna.ro From david.paeme at belbone.net Mon Aug 4 12:44:52 2003 From: david.paeme at belbone.net (david paeme) Date: 04 Aug 2003 14:44:52 +0200 Subject: including gnome 2.4 in next red hat release In-Reply-To: <1059826529.5277.11.camel@marte.biciclete.ro> References: <1059826529.5277.11.camel@marte.biciclete.ro> Message-ID: <1060001091.4033.4.camel@owsdavid> sure hope it makes it! d. On Sat, 2003-08-02 at 14:15, Marius Andreiana wrote: > Hi > > As you know, Gnome 2.4 final should be available on september 10, 5 days > before last > rhl-beta release. There has been a lot of work on HIGification and > usability. > > gnome 2.3 bugs: > http://bugzilla.gnome.org/gnome-23-report.html > If red hat developers are able to dedicate some time on crasher bugs, it > will help on making it stable faster. > > Please consider including gnome 2.4 in next Red Hat release. It doesn't > bring major new features, but it's more polished. > > Mandrake is recognized as the desktop distribution and Suse is getting > more and more sales on enterprise servers, both using KDE. If gnome 2.4 > is not included in next red hat, it will delay it's adoption until next > release ( no, it won't be installed separately when it's out. Companies > have time only to apply red hat official updates ) > > Thanks, From alexl at redhat.com Mon Aug 4 14:29:23 2003 From: alexl at redhat.com (Alexander Larsson) Date: 04 Aug 2003 16:29:23 +0200 Subject: including gnome 2.4 in next red hat release In-Reply-To: <1059826529.5277.11.camel@marte.biciclete.ro> References: <1059826529.5277.11.camel@marte.biciclete.ro> Message-ID: <1060007362.2461.72.camel@localhost.localdomain> On Sat, 2003-08-02 at 14:15, Marius Andreiana wrote: > Hi > > As you know, Gnome 2.4 final should be available on september 10, 5 days > before last > rhl-beta release. There has been a lot of work on HIGification and > usability. > > gnome 2.3 bugs: > http://bugzilla.gnome.org/gnome-23-report.html > If red hat developers are able to dedicate some time on crasher bugs, it > will help on making it stable faster. > > Please consider including gnome 2.4 in next Red Hat release. It doesn't > bring major new features, but it's more polished. We are quite aware of Gnome 2.3, given that several of us are maintainers of core Gnome modules. This also means we are aware of the schedules involved. However, Red Hat Linux is on a time-based schedule, and it was clear long ago that Gnome 2.4 would be released too late to be in the current release. Luckily, both Gnome and Red Hat are using a time-based schedule with a pretty fast turnaround (both about 6 months). This means that even if the schedule of the two projects will not always be synchronized it will never take that long before the latest Gnome release will get into a Red Hat release. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a hate-fuelled amnesiac messiah in a wheelchair. She's a foxy hypochondriac schoolgirl who dreams of becoming Elvis. They fight crime! From jbj at redhat.com Mon Aug 4 17:48:02 2003 From: jbj at redhat.com (Jeff Johnson) Date: Mon, 4 Aug 2003 13:48:02 -0400 Subject: RFC: i18n proposal In-Reply-To: <16169.38566.288052.562054@uebn.uddeborg.se>; from goeran@uddeborg.se on Fri, Aug 01, 2003 at 12:22:30AM +0200 References: <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> <16161.41106.591644.103709@uebn.uddeborg.se> <20030728123604.A6922@devserv.devel.redhat.com> <16166.59811.357179.684255@uebn.uddeborg.se> <20030729205204.B12088@devserv.devel.redhat.com> <20030730120143.D32372@devserv.devel.redhat.com> <16169.38566.288052.562054@uebn.uddeborg.se> Message-ID: <20030804134802.S32372@devserv.devel.redhat.com> On Fri, Aug 01, 2003 at 12:22:30AM +0200, G?ran Uddeborg wrote: > Jeff Johnson writes: > > If the intent is to have one domain per-package, the current implementation > > already supports this. > > I start to feel, during this discussion, goal and implementation has > become a bit confused. I'm surely guilty, starting my posts by an > attempt to suggest an implementation of my interpretation of Havoc's > suggestion. > Yup, add LSB packaging standard, very hard to not be confused. > I'll try to clarify MY goals. > > As a RHL user I want > > the description (etc.), including translations, come, change, and go > with the package. I don't want them to be modified when a > different, technically unrelated, package is modified. > > Having one domain per package and including that domain with the > package, is one way to implement that. Having all descriptions in > the meta-data is another way. There are surely other ways. > All agreed, although "domain" is dangerously close to implementation. > As a packager of third party packages I want > > an easy way to maintain the description, and to receive translations > of it. > > That was why I thought around having rpmbuild pick up translations > at build time from po-files laying around. If I also am the author > of the software I package, it would be convenient to put all > messages from the program(s) proper and the spec file description in > one po file and make that available for translation. (Doing some > kind of "gettext" on the spec file.) If I package someone elses > software, it would be more reasonable to provide a separate po file > for translators. > > Manually copying translations back and forth between po files and > spec files is not very convenient, obviously. Also agreed, and noted that you (and Havoc) are also interested in the general problem, not just i18n for description/summary/group. I am mainly concerned about rpm package format changes, as retrofitting Yet Another Solution (the next will be like my 5th attempt to get it right, sigh) into package format is not fun at all. Other than package format changes -- a topic that I'm no longer sane about -- I'm perfectly prepared to admit that rpm currently serves neither of your goals above well, and would like to do something better. > > As a translator of RHL descriptions (a.k.a. "specspo") I want > > the descriptions be available in a format which is easy to translate > and maintain. > Yup, must be *.po, and I'll wave my hands about "implementation". > The current specspo is fine for this! (It is huge, and took a long > time to do. But that would not have been different with some other > packaging.) I'll take that as complement, just trying to do my job. Truly, what makes specspo possible -- msghack -- is a very, very tortured implementation. And implementation credit is gafton, idea was/is mine. > > As a translator of other's third party packages I want > > the same thing as for RHL packages, a convenient format. > > Of course I would expect to get it individually for each package, > and not collected together with other unrelated packages. But po > files are good again. > We agree that *.po is only conceivable (i.e. works/useful/adequate/your_criteria_here)? (implementation aside) Hacking xgettext quite possible. xgettext already knows about C and shell syntax, not hard at all to teach xgettext about *.rpm, no parsing needed. I do shudder when considering a dependency gettext -> librpm*.so, but a parallel implementation is quite sensible and doable. In fact, suggested to Drepper years ago, but there was little need. > That's several "I want"s. I'm not saying one solution should fullfill > all, and I'm not at all saying they MUST be fullfilled before any > other problem. But if one of them could be fulfilled, it would be > better than none. > I want the same things as you, with the further constraint: I want what you want. Nothing you have suggested is unreasonable or outlandish imho. > > a) configure the new translation domain in /etc/rpm/macros.specspo > > (or any of the zillions of places that a macro can be defined) > > %_i18ndomains redhat:foo > > Do you envisage some way to do this automatically on (un)installation > of packages? So that each package can carry it's own translations? > Or just a different default value coming with the same specspo package > still carrying all translations? That's would be important given my > first point above. And I'm not sure exactly what you are suggesting. > Sure, macros are easily changed into something more robust. In fact, that's what macros were intended for, a lightweight and cheap, proof-of-concept, prototyping mechanism. Note carefully that doing a) differently involves changing the rpm implementation, not the rpm package format, my only concern. Note also that additions, like adding a domain tag to metadata, are quite doable, as long as the legacy issues of fallback can be addressed in the rpm implementation adequately. Replacing and/or changing existing implementation is what gives me hives. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From mandreiana at rdslink.ro Mon Aug 4 17:54:48 2003 From: mandreiana at rdslink.ro (Marius Andreiana) Date: 04 Aug 2003 20:54:48 +0300 Subject: including gnome 2.4 in next red hat release In-Reply-To: <1060007362.2461.72.camel@localhost.localdomain> References: <1059826529.5277.11.camel@marte.biciclete.ro> <1060007362.2461.72.camel@localhost.localdomain> Message-ID: <1060019688.4207.3.camel@marte.biciclete.ro> On Lu, 2003-08-04 at 17:29, Alexander Larsson wrote: > We are quite aware of Gnome 2.3, given that several of us are > maintainers of core Gnome modules. This also means we are aware of the > schedules involved Yes. Talked with hp on irc after the rhl-beta release, he said including it *might* be possible. This was just a reminder before the feature freeze on August 8. > However, Red Hat Linux is on a time-based schedule, > and it was clear long ago that Gnome 2.4 would be released too late to > be in the current release. Thank you for clarification. Well, maybe next rhl-beta will sync with gnome 2.6 enterprise ready :) -- Marius Andreiana Solu?ii informatice bazate pe Linux / Linux-based IT solutions www.galuna.ro From ghenriks at rogers.com Mon Aug 4 18:06:05 2003 From: ghenriks at rogers.com (Gerald Henriksen) Date: Mon, 04 Aug 2003 14:06:05 -0400 Subject: including gnome 2.4 in next red hat release In-Reply-To: <1060007362.2461.72.camel@localhost.localdomain> References: <1059826529.5277.11.camel@marte.biciclete.ro> <1060007362.2461.72.camel@localhost.localdomain> Message-ID: On 04 Aug 2003 16:29:23 +0200, you wrote: >We are quite aware of Gnome 2.3, given that several of us are >maintainers of core Gnome modules. This also means we are aware of the >schedules involved. However, Red Hat Linux is on a time-based schedule, >and it was clear long ago that Gnome 2.4 would be released too late to >be in the current release. Well, Gnome 2.4 is basically in feature freeze with beta testing occurring. I guess the question is whether it would cause to many problems having the Red Hat and Gnome beta testing occur at the same time by including the Gnome beta in the Red Hat beta. >Luckily, both Gnome and Red Hat are using a time-based schedule with a >pretty fast turnaround (both about 6 months). This means that even if >the schedule of the two projects will not always be synchronized it will >never take that long before the latest Gnome release will get into a Red >Hat release. Or more accurately, that there will always be a needless 6 month delay between Gnome being released and then being included in Red Hat. Which, given the fact that most other commercial distributions tend to favour KDE, seems to be a serious negative for Gnome that the only distribution that actually supports it is *always* out of date. From jbj at redhat.com Mon Aug 4 18:08:32 2003 From: jbj at redhat.com (Jeff Johnson) Date: Mon, 4 Aug 2003 14:08:32 -0400 Subject: RFC: i18n proposal In-Reply-To: <16169.38583.311228.873941@uebn.uddeborg.se>; from goeran@uddeborg.se on Fri, Aug 01, 2003 at 12:22:47AM +0200 References: <878yqorn7d.fsf@kosh.ultra.csn.tu-chemnitz.de> <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> <16161.41106.591644.103709@uebn.uddeborg.se> <20030728123604.A6922@devserv.devel.redhat.com> <16166.59811.357179.684255@uebn.uddeborg.se> <20030730123208.E32372@devserv.devel.redhat.com> <16169.38583.311228.873941@uebn.uddeborg.se> Message-ID: <20030804140832.T32372@devserv.devel.redhat.com> On Fri, Aug 01, 2003 at 12:22:47AM +0200, G?ran Uddeborg wrote: > Jeff Johnson writes: > > Unlike, say, error messages with xgettext *.c, summary/description/group > > are much softer, so text divergence is acceptable. > > > > Yes, that's a feature, at least for the docs team editors, because text > > can be updated in the field without having to wait for "make world" > > \of the next distro release. > > I'm not sure about your argumentation here. WHY are these particular > messages "softer" than others, and divergence more acceptable for > them. And WHY is it important to be able to update these particular > messages in the field and not others. > description/summary/group are "softer" in the sense that the usage context of the output text is not quite as stringent as, say, strerror(3). There are many ways to convey the information accurately, I'm quite sure that you as a translator have taken some liberties in the interest of accurately conveying semantic content, the alternative is babelfish, ick. OTOH, the information in description/summary/group *MUST* be translated accurately, and it's quite possible to obliterate meaning with overly complicated mechanism. Fuzzies come to mind, often accurate, sometimes hilarious. Specspo has (potentially) the same problem as fuzzies, and the solution comes from solid process i.e. acceptance criteria for translation is "No fuzzies". The equivalent for specspo and package header contents is "Must match", the devil is in trying to make this happen becuase of rpm's design goal, binary rpm's must be built. Red Hat has tried 3 or 4 solutions, none were adequate, specspo has been the "best" so far. Updating msgid's seperately is a requirement imposed by the docs team on the implementor, me. I have no control over the constraint, you will need to explore WHY with the docs team (although you can probably guess the answers just as well). > It could very well be that we simply have different opinions; that > your feature is my bug. But I feel I don't understand your reasoning. > I don't understand your motivation for the statements above. So I'm > not sure. > > If a package needs to be updated, being because of a bug fix in the > code, a changed description, or an corrected dependecy, the natural > thing would be to issue an errata for that particular package, it > seems to me. > Sure, but I question whether adding, "Buffer overflow #5642 fixed in version 4-5." is really a satisfactory solution. I'd rather see the bugs tracked through other means than description. > I fail to see why descriptions and summaries are so very different > from other documentation in the package. description/summary are different because the values are located in the package header, not the package payload, and must be accessible to anaconda before the package is installed. In fact, the info must be accessible in an empty chroot, although anaconda is "cheating" these days. Demanding that rpm be able to extract text from payload before install breaks every known current use of rpm, and adds intolerable overhead as well, fishing the text out of payload. Far, far easier to have solely in metatdata, but that also means that traditional solutions, like gettext(3) and dgettext(3) are not at all useful for description/summary/group. > > > > But maybe I misunderstood this comment. If so, I guess one could try > > > to extend the current "%description -l ...". > > > And, yes, the old means of adding text to spec files still exists, > > will probably exist forever. [...] > > OTOH, it does mostly > > solve the 3rd party single package i18n problem, the only thing that > > breaks is when there are package name collisions, specspo is preferred to > > header content. > > Rather than name collisions I'm more concerned about the lack of > coding information. And, AFAIK, the lack of tools to automatically > pick up contributed translations. > All I meant is that, say, "name(Description)", if found in specspo, will be used before any header resident text. Quite easy to change lookup order. Lack of tools is a problem, yes. Lack of priority to write the tools is a problem for me as well. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From hp at redhat.com Mon Aug 4 19:02:58 2003 From: hp at redhat.com (Havoc Pennington) Date: Mon, 4 Aug 2003 15:02:58 -0400 Subject: including gnome 2.4 in next red hat release In-Reply-To: References: <1059826529.5277.11.camel@marte.biciclete.ro> <1060007362.2461.72.camel@localhost.localdomain> Message-ID: <20030804150258.B19296@devserv.devel.redhat.com> On Mon, Aug 04, 2003 at 02:06:05PM -0400, Gerald Henriksen wrote: > On 04 Aug 2003 16:29:23 +0200, you wrote: > > >We are quite aware of Gnome 2.3, given that several of us are > >maintainers of core Gnome modules. This also means we are aware of the > >schedules involved. However, Red Hat Linux is on a time-based schedule, > >and it was clear long ago that Gnome 2.4 would be released too late to > >be in the current release. > > Well, Gnome 2.4 is basically in feature freeze with beta testing > occurring. I guess the question is whether it would cause to many > problems having the Red Hat and Gnome beta testing occur at the same > time by including the Gnome beta in the Red Hat beta. It makes some sense, but would mean possibly delaying the Red Hat release a bit. Historically this was impossible because the gold date had to be planned months in advance to get all the physical aspects of the box set and distribution lined up. It's conceivably possible now but we have to remember that there are many pieces of software in the release and if we're always delaying for something we'll end up with 5 years between releases. > >Luckily, both Gnome and Red Hat are using a time-based schedule with a > >pretty fast turnaround (both about 6 months). This means that even if > >the schedule of the two projects will not always be synchronized it will > >never take that long before the latest Gnome release will get into a Red > >Hat release. > > Or more accurately, that there will always be a needless 6 month delay > between Gnome being released and then being included in Red Hat. 6 months *worst case* delay, *if* both GNOME and Red Hat stick to time-based releases. If either GNOME or Red Hat starts delaying for specific features - such as "the latest GNOME version" - the worst case for missing any specific feature becomes much worse. Suddenly it's possible to have needless 2 year delays. So time-based releases can mean missing a specific feature, but avoid worst-case behavior. Delays from 0 to 6 months between GNOME and Red Hat release are equally likely, 6 months is not any more likely than anything else. From a Red Hat standpoint, I think the ideal delay would actually be about 2 months, which gives us time to package and integrate. So with GNOME and Red Hat both doing time-based releases the average delay should be 3 months, not that far off from ideal. Still, we may want to consider tweaking the schedule a couple weeks to get 2.4 in. My main worry is just having people available to actually do the packaging work in the next few weeks, which I'm not sure we have. Havoc From felipe_alfaro at linuxmail.org Mon Aug 4 19:11:55 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 04 Aug 2003 21:11:55 +0200 Subject: including gnome 2.4 in next red hat release In-Reply-To: <20030804150258.B19296@devserv.devel.redhat.com> References: <1059826529.5277.11.camel@marte.biciclete.ro> <1060007362.2461.72.camel@localhost.localdomain> <20030804150258.B19296@devserv.devel.redhat.com> Message-ID: <1060024314.511.5.camel@teapot.felipe-alfaro.com> On Mon, 2003-08-04 at 21:02, Havoc Pennington wrote: > 6 months *worst case* delay, *if* both GNOME and Red Hat stick to > time-based releases. If either GNOME or Red Hat starts delaying for > specific features - such as "the latest GNOME version" - the worst > case for missing any specific feature becomes much worse. Suddenly > it's possible to have needless 2 year delays. Well, if we can't afford some delay, release RHL with Gnome 2.2 and once Gnome 2.4 is ready, launch a Service Pack or Add-on that will upgrade from 2.2 to 2.4. This will be easier for novice users. Instead of connecting to RHN to download updates, or even worse, manually downloading the updates, you download the Add-on, run it, and then, Gnome is automagically updated. A single, small ISO image with an Autorun-like feature for automated upgrading would suffice, I think. From goeran at uddeborg.se Mon Aug 4 20:07:12 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran?= Uddeborg) Date: Mon, 4 Aug 2003 22:07:12 +0200 Subject: RFC: i18n proposal In-Reply-To: <20030804134802.S32372@devserv.devel.redhat.com> References: <20030724114226.Q18401@devserv.devel.redhat.com> <20030724121143.D32225@devserv.devel.redhat.com> <16160.27860.553257.398777@uebn.uddeborg.se> <20030724193745.D29567@devserv.devel.redhat.com> <16161.41106.591644.103709@uebn.uddeborg.se> <20030728123604.A6922@devserv.devel.redhat.com> <16166.59811.357179.684255@uebn.uddeborg.se> <20030729205204.B12088@devserv.devel.redhat.com> <20030730120143.D32372@devserv.devel.redhat.com> <16169.38566.288052.562054@uebn.uddeborg.se> <20030804134802.S32372@devserv.devel.redhat.com> Message-ID: <16174.48368.320679.271696@uebn.uddeborg.se> Jeff Johnson writes: > On Fri, Aug 01, 2003 at 12:22:30AM +0200, G?ran Uddeborg wrote: > > Jeff Johnson writes: > > As a RHL user I want > > > > the description (etc.), including translations, come, change, and go > > with the package. I don't want them to be modified when a > > different, technically unrelated, package is modified. > > > > Having one domain per package and including that domain with the > > package, is one way to implement that. Having all descriptions in > > the meta-data is another way. There are surely other ways. > > > > All agreed, although "domain" is dangerously close to implementation. "Domain" is certainly implementation. I meant the FIRST paragraph to be a clean requirement specification. The SECOND was meant to show how the implementation I had suggested in earlier mails could meet the specification. You can't be too clear, I guess. :-) > I am mainly concerned about rpm package format changes, as retrofitting > Yet Another Solution (the next will be like my 5th attempt to get it right, > sigh) into package format is not fun at all. Quite reasonable, that is definitely constraints which should be taken into account. > > The current specspo is fine for this! [...] > > I'll take that as complement, [...] Please do! > We agree that *.po is only conceivable (i.e. > works/useful/adequate/your_criteria_here)? What about: "*.po is a good implementation meeting my requirements as a translator, and I am not aware of any other format/toolset which also does". It is true, and it doesn't actually specify an implementation. :-) I'm not a purist always keeping specification and implementation strictly apart. In this case I felt the discussion becoming confused, so I wanted to clarify, that was all. From hp at redhat.com Mon Aug 4 20:56:36 2003 From: hp at redhat.com (Havoc Pennington) Date: Mon, 4 Aug 2003 16:56:36 -0400 Subject: including gnome 2.4 in next red hat release In-Reply-To: <1060024314.511.5.camel@teapot.felipe-alfaro.com> References: <1059826529.5277.11.camel@marte.biciclete.ro> <1060007362.2461.72.camel@localhost.localdomain> <20030804150258.B19296@devserv.devel.redhat.com> <1060024314.511.5.camel@teapot.felipe-alfaro.com> Message-ID: <20030804165636.D19296@devserv.devel.redhat.com> On Mon, Aug 04, 2003 at 09:11:55PM +0200, Felipe Alfaro Solana wrote: > Well, if we can't afford some delay, release > RHL with Gnome 2.2 and once Gnome 2.4 > is ready, launch a Service Pack or Add-on that will upgrade from 2.2 to > 2.4. This is a ton of work, involving a couple months worth of betas on top of the month or two of developing the update; not worth it really, with releases already so tightly packed... at least that would be my view. By the time you get it done the next full OS release is out anyway... Havoc From johnsonm at redhat.com Mon Aug 4 21:33:07 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 4 Aug 2003 17:33:07 -0400 Subject: including gnome 2.4 in next red hat release In-Reply-To: <1060007362.2461.72.camel@localhost.localdomain>; from alexl@redhat.com on Mon, Aug 04, 2003 at 04:29:23PM +0200 References: <1059826529.5277.11.camel@marte.biciclete.ro> <1060007362.2461.72.camel@localhost.localdomain> Message-ID: <20030804173307.A694@devserv.devel.redhat.com> On Mon, Aug 04, 2003 at 04:29:23PM +0200, Alexander Larsson wrote: > Luckily, both Gnome and Red Hat are using a time-based schedule with a > pretty fast turnaround (both about 6 months). This means that even if > the schedule of the two projects will not always be synchronized it will > never take that long before the latest Gnome release will get into a Red > Hat release. One of the things that we have mentioned before is that we expect Cambridge++ (i.e. the next release cycle) to be based on the 2.6 kernel, and that we want to do a particularly short cycle in order to have a 2.6-based release out there ASAP. The initial impressions of the 2.6.0-test kernels are much better than 2.4.0-test kernels, so the cycle could be quite short. As the long discussions on rhl-beta-list about testing Arjan's 2.6.0-test kernels and other home-built 2.6.0-test kernels have indicated, some of the necessary testing is already going on. So Cambridge++ could debut Gnome 2.4 as well and it would show up in Cambridge++ betas soon after Cambridge. 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 mike at netlyncs.com Mon Aug 4 21:54:10 2003 From: mike at netlyncs.com (Mike Chambers) Date: 04 Aug 2003 16:54:10 -0500 Subject: including gnome 2.4 in next red hat release In-Reply-To: <20030804173307.A694@devserv.devel.redhat.com> References: <1059826529.5277.11.camel@marte.biciclete.ro> <1060007362.2461.72.camel@localhost.localdomain> <20030804173307.A694@devserv.devel.redhat.com> Message-ID: <1060034050.2612.4.camel@bart.netlyncs.com> On Mon, 2003-08-04 at 16:33, Michael K. Johnson wrote: > So Cambridge++ could debut Gnome 2.4 as well and it would show up in > Cambridge++ betas soon after Cambridge. Either I'm misunderstanding what your saying, or you've got the naming scheme wrong or you misunderstand. Cambridge++ is what is currently beta testing as this moment in time. After the official release, Cambridge won't exist unless it's referred to by name still for bug fixes and updates. Other than that, the next beta cycle will have a new name internally, as well as publically (unless they change things a bit). -- Mike Chambers Madisonville, KY "The road to to success is always under construction!" From johnsonm at redhat.com Mon Aug 4 22:09:12 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 4 Aug 2003 18:09:12 -0400 Subject: including gnome 2.4 in next red hat release In-Reply-To: <1060034050.2612.4.camel@bart.netlyncs.com>; from mike@netlyncs.com on Mon, Aug 04, 2003 at 04:54:10PM -0500 References: <1059826529.5277.11.camel@marte.biciclete.ro> <1060007362.2461.72.camel@localhost.localdomain> <20030804173307.A694@devserv.devel.redhat.com> <1060034050.2612.4.camel@bart.netlyncs.com> Message-ID: <20030804180912.A25506@devserv.devel.redhat.com> On Mon, Aug 04, 2003 at 04:54:10PM -0500, Mike Chambers wrote: > On Mon, 2003-08-04 at 16:33, Michael K. Johnson wrote: > > > So Cambridge++ could debut Gnome 2.4 as well and it would show up in > > Cambridge++ betas soon after Cambridge. > > Either I'm misunderstanding what your saying, or you've got the naming > scheme wrong or you misunderstand. I think *you* have the naming scheme wrong. Consider my email address and then think about whether it is likely that I've got the naming scheme wildly wrong. :-) > Cambridge++ is what is currently beta testing as this moment in time. No, Cambridge is what is currently beta testing at this moment in time, not Cambridge++. > After the official release, Cambridge won't exist unless it's referred > to by name still for bug fixes and updates. Other than that, the next > beta cycle will have a new name internally, as well as publically > (unless they change things a bit). Cambridge is the overall release name; the code name for the beta of Cambridge is Severn, and the code name for the final release of Cambridge has not yet been assigned. Cambridge exists now in beta form. When it is released, Cambridge will release in final form, but instead of being called Severn will be called something else. For now, we can call Cambridge final "Severn++". "Cambridge" under Red Hat's previous code of secrecy would have been a secret name which in theory would be divulged only under NDA, but in practice was often leaked. Cambridge++ is a placeholder for the not-yet-assigned release name for the release following Cambridge. Its betas and final release have also not yet been assigned code names. 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 goeran at uddeborg.se Mon Aug 4 22:12:18 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran?= Uddeborg) Date: Tue, 5 Aug 2003 00:12:18 +0200 Subject: including gnome 2.4 in next red hat release In-Reply-To: <1060034050.2612.4.camel@bart.netlyncs.com> References: <1059826529.5277.11.camel@marte.biciclete.ro> <1060007362.2461.72.camel@localhost.localdomain> <20030804173307.A694@devserv.devel.redhat.com> <1060034050.2612.4.camel@bart.netlyncs.com> Message-ID: <16174.55874.912112.961701@uebn.uddeborg.se> Mike Chambers writes: > Cambridge++ is what is currently beta testing as this moment in time. Isn't Cambridge what is beta testing at this moment, and Cambridge++ is what will be beta-testing in the next cycle? (With some real name probably not yet decided.) From mike at netlyncs.com Mon Aug 4 22:15:28 2003 From: mike at netlyncs.com (Mike Chambers) Date: 04 Aug 2003 17:15:28 -0500 Subject: including gnome 2.4 in next red hat release In-Reply-To: <20030804180912.A25506@devserv.devel.redhat.com> References: <1059826529.5277.11.camel@marte.biciclete.ro> <1060007362.2461.72.camel@localhost.localdomain> <20030804173307.A694@devserv.devel.redhat.com> <1060034050.2612.4.camel@bart.netlyncs.com> <20030804180912.A25506@devserv.devel.redhat.com> Message-ID: <1060035328.2612.7.camel@bart.netlyncs.com> On Mon, 2003-08-04 at 17:09, Michael K. Johnson wrote: > I think *you* have the naming scheme wrong. Consider my email address > and then think about whether it is likely that I've got the naming scheme > wildly wrong. :-) ROFLMAO, I just reread that whole thing before I reread who you were and your right. I don't even have an idea wtf I just said LOL Sowwy bout dat :P -- Mike Chambers Madisonville, KY "The road to to success is always under construction!" From chrish at trilug.org Tue Aug 5 00:37:40 2003 From: chrish at trilug.org (Magnus) Date: Mon, 4 Aug 2003 20:37:40 -0400 Subject: including gnome 2.4 in next red hat release In-Reply-To: <1060024314.511.5.camel@teapot.felipe-alfaro.com> Message-ID: <04DB43FA-C6DD-11D7-816F-0003939CC61E@trilug.org> On Monday, August 4, 2003, at 03:11 PM, Felipe Alfaro Solana wrote: > Well, if we can't afford some delay, release > RHL with Gnome 2.2 and once Gnome > 2.4 > is ready, launch a Service Pack or Add-on that will upgrade from 2.2 to > 2.4. This will be easier for novice users. Instead of connecting to RHN > to download updates, or even worse, manually downloading the updates, > you download the Add-on, run it, and then, Gnome is automagically > updated. There is always the Fedora project for upgrades like this. -- C. Magnus Hedemark http://trilug.org/~chrish PGP Key fingerprint = 984D 9A88 3D60 016F BE01 1506 60FB 85E1 9ABD 96F6 -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From skvidal at phy.duke.edu Tue Aug 5 00:51:33 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 04 Aug 2003 20:51:33 -0400 Subject: including gnome 2.4 in next red hat release In-Reply-To: <20030804180912.A25506@devserv.devel.redhat.com> References: <1059826529.5277.11.camel@marte.biciclete.ro> <1060007362.2461.72.camel@localhost.localdomain> <20030804173307.A694@devserv.devel.redhat.com> <1060034050.2612.4.camel@bart.netlyncs.com> <20030804180912.A25506@devserv.devel.redhat.com> Message-ID: <1060044692.1500.0.camel@binkley> > > I think *you* have the naming scheme wrong. Consider my email address > and then think about whether it is likely that I've got the naming scheme > wildly wrong. :-) > You know what would be great. If there was a webpage that described the names and what not. oh wait there was... :) -sv From pekkas at netcore.fi Tue Aug 5 14:51:27 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 5 Aug 2003 17:51:27 +0300 (EEST) Subject: RFE: Other "Everything" installs In-Reply-To: Message-ID: On Fri, 25 Jul 2003, Chuck Wolber wrote: > > > a "Everything" > > > b "Everything in the selected language" > > > > > > or making Everything do just packages for the selected language and > > > then to get **everything** you just select all languages > > > > packages don't provide any indication of "language". > > Apparently you aren't familiar with the %lang macro? Thanks for the pointer; I wasn't. But the problem in this context is more with how you export that information out of the packages, so that you can say to give a toggle to the installer that you want all packages with %lang FOO or %lang unspecified (implying english). I'm not sure how this is doable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pekkas at netcore.fi Wed Aug 6 11:33:04 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 6 Aug 2003 14:33:04 +0300 (EEST) Subject: X11 and -nolisten tcp [Re: How do I shut down this ports (fwd)] Message-ID: Just a thought.. Is there any reason '-nolisten tcp' is not the default? I haven't tested but I think the SSH forwards work nonetheless; only if you use $DISPLAY to direct output to your screen from remote machines you're likely in for trouble -- but that should not typically be done anyway. (only reason I can think of are those funky heavy graphics apps folks claim are too slow over SSH) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ---------- Forwarded message ---------- Date: Wed, 06 Aug 2003 12:35:09 +0200 From: "shrek-m at gmx.de" Reply-To: rhl-beta-list at redhat.com To: rhl-beta-list at redhat.com Subject: Re: How do I shut down this ports Michael Kearey wrote: > Louis Garcia wrote: > >> 6000/tcp open X11 > > > > In case you really must, I found in the man page for Xserver the option : > -nolisten trans-type > disables a transport type. For example, TCP/IP > connections can be disabled with -nolisten tcp. > > > The consequences of doing so , and where in the X configuration files > you might actually put it, I don't yet know... I have been trying to > find out how to set the option when starting X with xdm/gdm/kdm. > > In any case, startx -- -nolisten tcp will do it at commandline and so > far in Severn it's had no adverse impact for me... you can try or google for ... debian: /etc/X/xinit/xserverrc rhl ? : /etc/X11/xdm/Xservers :0 local /usr/X11R6/bin/X -nolisten tcp /etc/X11/gdm/gdm.conf [server-Standard] name=Standard server command=/usr/X11R6/bin/X -nolisten tcp flexible=true /etc/X11/xdm/kdmrc -- shrek-m -- Rhl-beta-list mailing list Rhl-beta-list at redhat.com http://www.redhat.com/mailman/listinfo/rhl-beta-list From dickson at permanentmail.com Wed Aug 6 13:09:39 2003 From: dickson at permanentmail.com (Paul Dickson) Date: Wed, 6 Aug 2003 06:09:39 -0700 Subject: My report on running 2.6.0-test2 on a Dell Inspiron 7000 (possible tty trouble) In-Reply-To: <20030806114234.GD814@wind.cocodriloo.com> References: <20030806021621.2da5a850.dickson@permanentmail.com> <20030806022256.4b4f967c.dickson@permanentmail.com> <20030806114234.GD814@wind.cocodriloo.com> Message-ID: <20030806060939.1b2a1521.dickson@permanentmail.com> On Wed, 6 Aug 2003 13:42:34 +0200, Antonio Vargas wrote: > On Wed, Aug 06, 2003 at 02:22:56AM -0700, Paul Dickson wrote: > > > I built 2.6.0-test2 for my Dell Inspiron 7000 notebook (PII, 300Mhz) with > > a RH9 distribution. I build the kernel on another system (1.33GHz) using > > ssh. > > > > I was missing some device support, so did a "make menuconfig". The > > configuration options were shown, I selected "Sound -->" and pressed > > enter. The terminal went back to text mode and then hung. Gnome-terminal > > started consuming all unused CPU cycles. > > > > I could recover the process by closing the tab or resetting the terminal, > > but this would only fix the problem for the moment. Frequently, it > > wouldn't even finish redisplaying the screen before it locked again. > > > > This would happen running "make menuconfig" locally or via ssh on another > > system. > > > > This is likely caused by some difference in the tty code in 2.6.0-test2. > > The problem does not occur under 2.4.20-18.9. If 2.6.0-test2 is correct, > > then I might need an updated version of gnome-terminal suitable for 2.6.0. > > This is a bug in gnome-terminal: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89151 > This bug is still in the gnome-terminal version included with Severn. -Paul From hp at redhat.com Wed Aug 6 14:12:50 2003 From: hp at redhat.com (Havoc Pennington) Date: Wed, 6 Aug 2003 10:12:50 -0400 Subject: My report on running 2.6.0-test2 on a Dell Inspiron 7000 (possible tty trouble) In-Reply-To: <20030806060939.1b2a1521.dickson@permanentmail.com> References: <20030806021621.2da5a850.dickson@permanentmail.com> <20030806022256.4b4f967c.dickson@permanentmail.com> <20030806114234.GD814@wind.cocodriloo.com> <20030806060939.1b2a1521.dickson@permanentmail.com> Message-ID: <20030806101250.K17064@devserv.devel.redhat.com> On Wed, Aug 06, 2003 at 06:09:39AM -0700, Paul Dickson wrote: > On Wed, 6 Aug 2003 13:42:34 +0200, Antonio Vargas wrote: > > This is a bug in gnome-terminal: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89151 > > > > This bug is still in the gnome-terminal version included with Severn. > Terminal emulation is vte, gnome-terminal is just the menubar and prefs dialog. I moved the bug now (it probably would have been closed already if Nalin had seen it, sorry about that). Havoc From peter.backlund at home.se Wed Aug 6 14:39:08 2003 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 6 Aug 2003 16:39:08 +0200 Subject: XFree86-Mesa-libGL packaging (mharris, read this please) Message-ID: <200308061639.08873.peter.backlund@home.se> Hi. Would it be possible to change packaging of XFree86 and XFree86-Mesa-libGL slightly, so that /usr/X11R6/lib/modules/extensions/libGLcore.a and /usr/X11R6/lib/modules/extensions/libglx.a could belong to XFree86-Mesa-libGL instead of XFree86? This would make it _so_ much easier to package replacement OpenGL libraries (Nvidia for example). One would just add a Conflicts: XFree86-Mesa-libGL, and all file conflicts would go away. /Peter From lenz at mysql.com Wed Aug 6 15:33:09 2003 From: lenz at mysql.com (Lenz Grimmer) Date: Wed, 6 Aug 2003 17:33:09 +0200 (CEST) Subject: MySQL version in next beta? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I must admit that I have not installed "Severn" yet (just downloaded the ISOs). Can anyone tell me, if you have already moved to MySQL 4.0? Or do you plan to still ship with 3.23? Let me know, if there is anything I can help you with regarding MySQL! Bye, LenZ - -- Lenz Grimmer Senior Production Engineer MySQL GmbH, http://www.mysql.de/ Hamburg, Germany For technical support contracts, visit https://order.mysql.com/?ref=mlgr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE/MR+3SVDhKrJykfIRAj77AJoDPrZwF4Ghri/AM/BeswtlE6Y1ggCdEveA G6WPLAN07Ei7nXQ9c9BrMlg= =AQGh -----END PGP SIGNATURE----- From rhldevel at assursys.co.uk Wed Aug 6 16:49:53 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Wed, 6 Aug 2003 17:49:53 +0100 (BST) Subject: XFree86-Mesa-libGL packaging (mharris, read this please) In-Reply-To: <200308061639.08873.peter.backlund@home.se> References: <200308061639.08873.peter.backlund@home.se> Message-ID: On Wed, 6 Aug 2003, Peter Backlund wrote: > Would it be possible to change packaging of XFree86 and XFree86-Mesa-libGL > slightly Whilst we're on this topic, how about a XFree86-SDK package (please excuse me if this is already done) so that new drivers (e.g. linuxwacom) that depend upon parts of the XFree86 source tree can be built easily? Ta! Alex. From gt at esi.ac.at Wed Aug 6 18:27:25 2003 From: gt at esi.ac.at (Gerald Teschl) Date: Wed, 6 Aug 2003 20:27:25 +0200 (CEST) Subject: XFree86-Mesa-libGL packaging (mharris, read this please) In-Reply-To: <200308061639.08873.peter.backlund@home.se> Message-ID: On Wed, 6 Aug 2003, Peter Backlund wrote: > could belong to XFree86-Mesa-libGL instead of XFree86? This would make it _so_ > much easier to package replacement OpenGL libraries (Nvidia for example). One > would just add a Conflicts: XFree86-Mesa-libGL, and all file conflicts would > go away. Seconded. Gerald From peter.backlund at home.se Wed Aug 6 18:46:35 2003 From: peter.backlund at home.se (Peter Backlund) Date: 06 Aug 2003 20:46:35 +0200 Subject: XFree86-Mesa-libGL packaging (mharris, read this please) In-Reply-To: References: Message-ID: <1060195595.7570.0.camel@h120n2fls33o1121.telia.com> > Seconded. Great, at least one person agrees :-). It's now in bugzilla, for those interested: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=101775 From ghenriks at rogers.com Wed Aug 6 21:34:17 2003 From: ghenriks at rogers.com (Gerald Henriksen) Date: Wed, 06 Aug 2003 17:34:17 -0400 Subject: MySQL version in next beta? In-Reply-To: References: Message-ID: On Wed, 6 Aug 2003 17:33:09 +0200 (CEST), you wrote: >I must admit that I have not installed "Severn" yet (just downloaded the >ISOs). Can anyone tell me, if you have already moved to MySQL 4.0? Or do >you plan to still ship with 3.23? > >Let me know, if there is anything I can help you with regarding MySQL! Currently is looks like 3.23 due to license problems with MySQL 4.0, take a look at the following message from the rhl-beta-list for an explanation: http://www.redhat.com/archives/rhl-beta-list/2003-July/msg00045.html From dax at gurulabs.com Wed Aug 6 22:06:44 2003 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 06 Aug 2003 16:06:44 -0600 Subject: further development of libuser's LDAP module In-Reply-To: <1059172469.705.8.camel@teapot.felipe-alfaro.com> References: <1059172469.705.8.camel@teapot.felipe-alfaro.com> Message-ID: <1060207604.4016.31.camel@mentor.gurulabs.com> On Fri, 2003-07-25 at 16:34, Felipe Alfaro Solana wrote: > Thus, I've modified and redeveloped the LDAP module of libuser a little > bit and I think I've got a 100%, fully functional LDAP backend module > which can be used to add, delete and modify user and group accounts. > > Are you interested in me posting a unified diff/patch (or the whole > sources)? Please, say yes ;-) This is a very interesting piece of > software I'm using in a real proyect to migrate a stinking farm of NT4 > boxes to Linux + Samba 3.0 and LDAP. Yes! I would very much like to test/use them. Dax Kelson Guru Labs From felipe_alfaro at linuxmail.org Wed Aug 6 23:14:09 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 07 Aug 2003 01:14:09 +0200 Subject: further development of libuser's LDAP module In-Reply-To: <1060207604.4016.31.camel@mentor.gurulabs.com> References: <1059172469.705.8.camel@teapot.felipe-alfaro.com> <1060207604.4016.31.camel@mentor.gurulabs.com> Message-ID: <1060211649.599.3.camel@teapot.felipe-alfaro.com> On Thu, 2003-08-07 at 00:06, Dax Kelson wrote: > On Fri, 2003-07-25 at 16:34, Felipe Alfaro Solana wrote: > > Thus, I've modified and redeveloped the LDAP module of libuser a little > > bit and I think I've got a 100%, fully functional LDAP backend module > > which can be used to add, delete and modify user and group accounts. > > > > Are you interested in me posting a unified diff/patch (or the whole > > sources)? Please, say yes ;-) This is a very interesting piece of > > software I'm using in a real proyect to migrate a stinking farm of NT4 > > boxes to Linux + Samba 3.0 and LDAP. > > Yes! > > I would very much like to test/use them. Please, look https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=99435, The bug report cotains a patch I submitted against libuser-0.51.7. Hope this helps! From pauln at truemesh.com Thu Aug 7 06:01:45 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Thu, 7 Aug 2003 07:01:45 +0100 Subject: XFree86-Mesa-libGL packaging (mharris, read this please) In-Reply-To: References: <200308061639.08873.peter.backlund@home.se> Message-ID: <20030807060144.GG3600@shitake.truemesh.com> On Wed, Aug 06, 2003 at 05:49:53PM +0100, rhldevel at assursys.co.uk wrote: > On Wed, 6 Aug 2003, Peter Backlund wrote: > > > Would it be possible to change packaging of XFree86 and XFree86-Mesa-libGL > > slightly > > Whilst we're on this topic, how about a XFree86-SDK package (please excuse > me if this is already done) so that new drivers (e.g. linuxwacom) that > depend upon parts of the XFree86 source tree can be built easily? Umm, this is buildable from the src.rpm but is a bit borked - make depend doesn't work so you cant just run mkmf script, I think the via driver Just change the first %define build_sdk to 1 and rebuild the rpm :) I've also found some stuff needs more than the sdk (synaptics and vnc) so in addition I've a bug out for XFree86-source as well, though I'm not an X hacker so it may be possible to build with the sdk using some voodo but the synaptics driver looked to need headers not available with -devel and -sdk. VNC also ships the whole XFree86 tgz in the src.rpm atm which sucks so using a -source package and lndir worked well for me. My bugzilla entry is here https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=99351 Paul From chuckw at quantumlinux.com Thu Aug 7 08:32:53 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Thu, 7 Aug 2003 01:32:53 -0700 (PDT) Subject: RFE: Other "Everything" installs In-Reply-To: Message-ID: > > Apparently you aren't familiar with the %lang macro? > > Thanks for the pointer; I wasn't. > > But the problem in this context is more with how you export that > information out of the packages, so that you can say to give a toggle to > the installer that you want all packages with %lang FOO or %lang > unspecified (implying english). I'm not familiar with the commandline options, but IIRC you can tease out %lang information from a package using the rpm command. I suspect that it may require some basic grep'ing and whatnot. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From hbo at egbok.com Thu Aug 7 09:05:37 2003 From: hbo at egbok.com (Howard Owen) Date: 07 Aug 2003 02:05:37 -0700 Subject: RFE: Other "Everything" installs In-Reply-To: References: Message-ID: <1060247135.9050.210.camel@owen.egbok.com> The rpm command you need is rpm -q --qf %{FILELANGS} . On my severn system: hbo at mycop|1016> rpm -q --qf %{FILELANGS} kde-i18n-British en_GB hbo at mycop|1017> Whereas: hbo at mycop|1017> rpm -q --qf %{FILELANGS} openssh hbo at mycop|1018> So, no output for packages without "FILELANGS". I haven't looked into whether FILELANGS corresponds to to %lang, but I assume it does. On Thu, 2003-08-07 at 01:32, Chuck Wolber wrote: > > > Apparently you aren't familiar with the %lang macro? > > > > Thanks for the pointer; I wasn't. > > > > But the problem in this context is more with how you export that > > information out of the packages, so that you can say to give a toggle to > > the installer that you want all packages with %lang FOO or %lang > > unspecified (implying english). > > I'm not familiar with the commandline options, but IIRC you can tease out > %lang information from a package using the rpm command. I suspect that it > may require some basic grep'ing and whatnot. > > -Chuck -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From arnaud.abelard at sciences.univ-nantes.fr Thu Aug 7 16:48:58 2003 From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard) Date: Thu, 7 Aug 2003 18:48:58 +0200 (CEST) Subject: dependency tool for RedHat Message-ID: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> Hello, RedHat Linux is one of the last modern linux distributions not to have a dependency tool like apt-get, urpmi or autopkg included in the default intstallation. Is there any plans on including apt-get for example in the next releases? Apt-get for rpm is GPL, even thought it still seems to lock the RPM db (on RH9) it's pretty stable and would be a good choice. I think that would be a really good point for RHL so have a kind of tool like that. There's more and more rpm depositories for apt-get (freshrpms.net, tuxfamily.org, etc) and people are starting to get used to it. Is there a way we could contribute and get apt-get perhaps, to be included in the future releases? Thanks, Arnaud Ab?lard. From skvidal at phy.duke.edu Thu Aug 7 16:51:23 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 07 Aug 2003 12:51:23 -0400 Subject: dependency tool for RedHat In-Reply-To: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> Message-ID: <1060275083.19551.9.camel@opus.phy.duke.edu> On Thu, 2003-08-07 at 12:48, Arnaud Abelard wrote: > Hello, > > RedHat Linux is one of the last modern linux distributions not to have a > dependency tool like apt-get, urpmi or autopkg included in the default > intstallation. > > Is there any plans on including apt-get for example in the next releases? > > Apt-get for rpm is GPL, even thought it still seems to lock the RPM db (on > RH9) it's pretty stable and would be a good choice. > > I think that would be a really good point for RHL so have a kind of tool > like that. There's more and more rpm depositories for apt-get > (freshrpms.net, tuxfamily.org, etc) and people are starting to get used to > it. > > Is there a way we could contribute and get apt-get perhaps, to be included > in the future releases? yum is in rawhide now: http://linux.duke.edu/yum/ and apt-get and yum are available from freshrpms and fedora all ready to go for red hat linux iirc. -sv From peter.backlund at home.se Thu Aug 7 16:59:08 2003 From: peter.backlund at home.se (Peter Backlund) Date: Thu, 7 Aug 2003 18:59:08 +0200 Subject: dependency tool for RedHat In-Reply-To: <1060275083.19551.9.camel@opus.phy.duke.edu> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060275083.19551.9.camel@opus.phy.duke.edu> Message-ID: <200308071859.08357.peter.backlund@home.se> > > RedHat Linux is one of the last modern linux distributions not to have a > > dependency tool like apt-get, urpmi or autopkg included in the default > > intstallation. up2date has been available since 6.2 I believe. Do you even use Red Hat? /Peter From arnaud.abelard at sciences.univ-nantes.fr Thu Aug 7 17:06:08 2003 From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard) Date: Thu, 7 Aug 2003 19:06:08 +0200 (CEST) Subject: dependency tool for RedHat In-Reply-To: <200308071859.08357.peter.backlund@home.se> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060275083.19551.9.camel@opus.phy.duke.edu> <200308071859.08357.peter.backlund@home.se> Message-ID: <55583.81.56.217.49.1060275968.squirrel@webmail.sciences.univ-nantes.fr> > up2date has been available since 6.2 I believe. Do you even use Red Hat? up2date isn't comparable to apt-get or yum by the way it can't retrieve non official packages from different sources. That's what i was talking about. Stay calm up2date like the name suggests it, is used to keep your linux up to date. Can't be used to install third party packages. RedHat actually doesn't provide anything like this yet. Apt-get for RPM or yum do. Glad yum is now in rawhide. RHL needed that. Arnaud Ab?lard > > /Peter > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list From dax at gurulabs.com Thu Aug 7 20:18:55 2003 From: dax at gurulabs.com (Dax Kelson) Date: Thu, 07 Aug 2003 14:18:55 -0600 Subject: dependency tool for RedHat In-Reply-To: <55583.81.56.217.49.1060275968.squirrel@webmail.sciences.univ-nantes.fr> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060275083.19551.9.camel@opus.phy.duke.edu> <200308071859.08357.peter.backlund@home.se> <55583.81.56.217.49.1060275968.squirrel@webmail.sciences.univ-nantes.fr> Message-ID: <1060287534.4571.7.camel@mentor.gurulabs.com> On Thu, 2003-08-07 at 11:06, Arnaud Abelard wrote: > > up2date has been available since 6.2 I believe. Do you even use Red Hat? > > up2date isn't comparable to apt-get or yum by the way it can't retrieve > non official packages from different sources. That's what i was talking > about. Stay calm Incorrect. up2date can be configured to use repositories other than just the official ones. Just like apt-get and yum, you need to setup the server piece and configure your clients to look at the server. There is an open source "server piece" for up2date called "current". http://current.tigris.org/ Dax Kelson Guru Labs From pri.rhl1 at iadonisi.to Thu Aug 7 20:22:41 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 07 Aug 2003 16:22:41 -0400 Subject: dependency tool for RedHat In-Reply-To: <55583.81.56.217.49.1060275968.squirrel@webmail.sciences.univ-nantes.fr> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060275083.19551.9.camel@opus.phy.duke.edu> <200308071859.08357.peter.backlund@home.se> <55583.81.56.217.49.1060275968.squirrel@webmail.sciences.univ-nantes.fr> Message-ID: <1060287760.13714.43.camel@va.local.linuxlobbyist.org> On Thu, 2003-08-07 at 13:06, Arnaud Abelard wrote: > > up2date has been available since 6.2 I believe. Do you even use Red Hat? > > up2date isn't comparable to apt-get or yum by the way it can't retrieve > non official packages from different sources. That's what i was talking > about. Stay calm > > up2date like the name suggests it, is used to keep your linux up to date. > Can't be used to install third party packages. RedHat actually doesn't > provide anything like this yet. Apt-get for RPM or yum do. > > Glad yum is now in rawhide. RHL needed that. As these tools go, yum is probably the better choice. At least according to the yum developer, apt re-implements a lot of stuff that rpm is already doing and there is likely a lot of Debian cruft in the code. (I'm not slighting Debian, btw, it's just that from the perspective of an rpm based system, much of the code could be considered cruft.) There's also the fact that most (all?) of Red Hat's config tools are written in python, so you can be fairly certain that the rpm-python bindings are being well maintained (yum is written in python). But from what I can tell, there is a problem with all of the tools that allow you specify multiple repositories. And it's the reason I won't use things like Ximian's (Novell's?) Desktop, even though it's cool. And that is that different versions of a specific package may be provided from multiple repositories. I know of no tools that, say, allow you to specify that if a package exists in repository #1, then never take any version of the package from repositories #2 - #5. Though it might be a lot more work, I should even be able specify that if a package from my lower priority repositories have any files that conflict with any files from any packages in my highest priority repository, then don't take that package from those lower priority repositories. Or at least not without making lots of noises about possible later conflicts with core distribution components. But I should definitely be able to do this at the package level so I could, for example, be able to specify a list of packages (Gnome and company) to get only from the Ximian repository and never get them from the Red Hat repository. Just my $0.02 worth. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From skvidal at phy.duke.edu Thu Aug 7 20:31:04 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 07 Aug 2003 16:31:04 -0400 Subject: dependency tool for RedHat In-Reply-To: <1060287760.13714.43.camel@va.local.linuxlobbyist.org> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060275083.19551.9.camel@opus.phy.duke.edu> <200308071859.08357.peter.backlund@home.se> <55583.81.56.217.49.1060275968.squirrel@webmail.sciences.univ-nantes.fr> <1060287760.13714.43.camel@va.local.linuxlobbyist.org> Message-ID: <1060288264.17358.10.camel@binkley> On Thu, 2003-08-07 at 16:22, Paul Iadonisi wrote: > As these tools go, yum is probably the better choice. At least > according to the yum developer, apt re-implements a lot of stuff that > rpm is already doing and there is likely a lot of Debian cruft in the > code. (I'm not slighting Debian, btw, it's just that from the > perspective of an rpm based system, much of the code could be considered > cruft.) There's also the fact that most (all?) of Red Hat's config > tools are written in python, so you can be fairly certain that the > rpm-python bindings are being well maintained (yum is written in > python). Well I'm the yum developer and you'll note I made an addendum to my reasons for not using apt-get on the yum webpage. I can no longer claim they are reimplementing a lot of things. Though some of it is still the case. I'll also note my reason for putting that list up there was to get people to stop telling me to just use apt. I have nothing against apt, I've talked with a number of apt developers and they are very bright and have a working program. > But from what I can tell, there is a problem with all of the tools > that allow you specify multiple repositories. And it's the reason I > won't use things like Ximian's (Novell's?) Desktop, even though it's > cool. And that is that different versions of a specific package may be > provided from multiple repositories. I know of no tools that, say, > allow you to specify that if a package exists in repository #1, then > never take any version of the package from repositories #2 - #5. Though > it might be a lot more work, I should even be able specify that if a > package from my lower priority repositories have any files that conflict > with any files from any packages in my highest priority repository, then > don't take that package from those lower priority repositories. Or at > least not without making lots of noises about possible later conflicts > with core distribution components. This concept is commonly called pinning - it is available in apt but it is 1. underdocumented and 2. not trivial for the complex cases or simple cases. We've fleshed out some options for doing this in yum and it will be something I'll be working on for 2.5 and above. > But I should definitely be able to do this at the package level so I > could, for example, be able to specify a list of packages (Gnome and > company) to get only from the Ximian repository and never get them from > the Red Hat repository. The tricky part is that it is very easy to get your system fairly seriously hosed if you mix-and-match a bit too much. Just b/c everything resolves correctly in rpm-land doesn't mean it's necessarily all correct. -sv From jos at xos.nl Thu Aug 7 20:56:11 2003 From: jos at xos.nl (Jos Vos) Date: Thu, 7 Aug 2003 22:56:11 +0200 Subject: dependency tool for RedHat In-Reply-To: <1060287534.4571.7.camel@mentor.gurulabs.com>; from dax@gurulabs.com on Thu, Aug 07, 2003 at 02:18:55PM -0600 References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060275083.19551.9.camel@opus.phy.duke.edu> <200308071859.08357.peter.backlund@home.se> <55583.81.56.217.49.1060275968.squirrel@webmail.sciences.univ-nantes.fr> <1060287534.4571.7.camel@mentor.gurulabs.com> Message-ID: <20030807225611.A10737@xos037.xos.nl> On Thu, Aug 07, 2003 at 02:18:55PM -0600, Dax Kelson wrote: > Incorrect. > > up2date can be configured to use repositories other than just the > official ones. Partly incorrect. You can configure *an* external repository (that is, one at a time), which is largely insufficient for serious use. > Just like apt-get and yum, you need to setup the server piece and > configure your clients to look at the server. Well, up2date needs a dedicated XMLRPC-talking server, i.s.o. any ordinary http/ftp repository that apt and yum need, which is *way* more complex than setting up an apt/yum repository. Another issue is the server load. With apt and yum calculations (e.g., dependency calculations) are done on the client, while the up2date server seems to have much work serving client requests (my experience with Current). > There is an open source "server piece" for up2date called "current". The total up2date architecture is much more powerfull than the functionality of apt and yum, but Current only implement the basic functionality, which means it doesn't offer more than apt and yum. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From pri.rhl1 at iadonisi.to Thu Aug 7 21:05:30 2003 From: pri.rhl1 at iadonisi.to (Paul Iadonisi) Date: 07 Aug 2003 17:05:30 -0400 Subject: dependency tool for RedHat In-Reply-To: <1060288264.17358.10.camel@binkley> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060275083.19551.9.camel@opus.phy.duke.edu> <200308071859.08357.peter.backlund@home.se> <55583.81.56.217.49.1060275968.squirrel@webmail.sciences.univ-nantes.fr> <1060287760.13714.43.camel@va.local.linuxlobbyist.org> <1060288264.17358.10.camel@binkley> Message-ID: <1060290329.13714.57.camel@va.local.linuxlobbyist.org> On Thu, 2003-08-07 at 16:31, seth vidal wrote: Hello, Seth! Thanks for developing yum. [snip] > Well I'm the yum developer and you'll note I made an addendum to my > reasons for not using apt-get on the yum webpage. I can no longer claim > they are reimplementing a lot of things. Though some of it is still the > case. I hadn't looked at the home page recently, so I hadn't noticed that. I will say that in a recent update using synaptic against freshrpms.net I noticed a *dramatic* speedup, so maybe that was when a lot of the code was cleaned up. > I'll also note my reason for putting that list up there was to get > people to stop telling me to just use apt. I have nothing against apt, > I've talked with a number of apt developers and they are very bright and > have a working program. I wasn't really implying that apt was bad. In fact, I had assumed that the main reason for the speedup mentioned above was that this at least some of that cleanup had taken place. I will say, and this probably has nothing to do with apt, per se, that synaptic has a really bizarre UI layout. It would probably fail to most of the HIG recommendations. Nonetheless, it's probably a good starting point for a gui for apt. At least as far as I know, there is *no* gui for yum. Is anyone working on one? [snip] > > > This concept is commonly called pinning - it is available in apt but it > is 1. underdocumented and 2. not trivial for the complex cases or simple > cases. > > We've fleshed out some options for doing this in yum and it will be > something I'll be working on for 2.5 and above. > > > > But I should definitely be able to do this at the package level so I > > could, for example, be able to specify a list of packages (Gnome and > > company) to get only from the Ximian repository and never get them from > > the Red Hat repository. > > The tricky part is that it is very easy to get your system fairly > seriously hosed if you mix-and-match a bit too much. Just b/c everything > resolves correctly in rpm-land doesn't mean it's necessarily all > correct. Yeah, and that's what contributes to the 'rpm dependency hell' that is the perception of many. Or sort of related in the rpm thinks everything is hunky dory, but in reality, it's not. I understand the problem...the solution is another story. The sheer volume of software available makes this problem all the more difficult. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From arnaud.abelard at sciences.univ-nantes.fr Thu Aug 7 21:33:02 2003 From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard) Date: Thu, 7 Aug 2003 23:33:02 +0200 (CEST) Subject: dependency tool for RedHat In-Reply-To: <1060287534.4571.7.camel@mentor.gurulabs.com> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060275083.19551.9.camel@opus.phy.duke.edu> <200308071859.08357.peter.backlund@home.se> <55583.81.56.217.49.1060275968.squirrel@webmail.sciences.univ-nantes.fr> <1060287534.4571.7.camel@mentor.gurulabs.com> Message-ID: <58761.81.56.217.49.1060291982.squirrel@webmail.sciences.univ-nantes.fr> > up2date can be configured to use repositories other than just the > official ones. > > Just like apt-get and yum, you need to setup the server piece and > configure your clients to look at the server. It's not configurable easily.. unfortunatly > > There is an open source "server piece" for up2date called "current". > > http://current.tigris.org/ Yup, been using it for a while now, unfortunatly it's still pretty basic even though it's progressing pretty fast. You're making a point there. But unfortunatly, once again, up2date/current aren't offering the same services as apt-get, yum, urpmi.. does up2date allow you to install new rpms instead of just keeping the installed one up to date? A. > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list From jos at xos.nl Thu Aug 7 21:42:12 2003 From: jos at xos.nl (Jos Vos) Date: Thu, 7 Aug 2003 23:42:12 +0200 Subject: dependency tool for RedHat In-Reply-To: <58761.81.56.217.49.1060291982.squirrel@webmail.sciences.univ-nantes.fr>; from arnaud.abelard@sciences.univ-nantes.fr on Thu, Aug 07, 2003 at 11:33:02PM +0200 References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060275083.19551.9.camel@opus.phy.duke.edu> <200308071859.08357.peter.backlund@home.se> <55583.81.56.217.49.1060275968.squirrel@webmail.sciences.univ-nantes.fr> <1060287534.4571.7.camel@mentor.gurulabs.com> <58761.81.56.217.49.1060291982.squirrel@webmail.sciences.univ-nantes.fr> Message-ID: <20030807234212.A10943@xos037.xos.nl> On Thu, Aug 07, 2003 at 11:33:02PM +0200, Arnaud Abelard wrote: > You're making a point there. But unfortunatly, once again, up2date/current > aren't offering the same services as apt-get, yum, urpmi.. does up2date > allow you to install new rpms instead of just keeping the installed one up > to date? AFAIK yes (but it doesn't offer some other things apt already has). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From peter.backlund at home.se Thu Aug 7 22:09:43 2003 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 8 Aug 2003 00:09:43 +0200 Subject: dependency tool for RedHat In-Reply-To: <58761.81.56.217.49.1060291982.squirrel@webmail.sciences.univ-nantes.fr> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060287534.4571.7.camel@mentor.gurulabs.com> <58761.81.56.217.49.1060291982.squirrel@webmail.sciences.univ-nantes.fr> Message-ID: <200308080009.43862.peter.backlund@home.se> > You're making a point there. But unfortunatly, once again, up2date/current > aren't offering the same services as apt-get, yum, urpmi.. does up2date > allow you to install new rpms instead of just keeping the installed one up > to date? Yes. Man is your friend :-) Actually, I think the name of up2date is what causes many people to erroneously think of it as "the windows update of red hat". The only major thing up2date doesn't do, that apt/yum/urpmi does, is cascade removal. From arnaud.abelard at sciences.univ-nantes.fr Thu Aug 7 22:26:40 2003 From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard) Date: Fri, 8 Aug 2003 00:26:40 +0200 (CEST) Subject: dependency tool for RedHat In-Reply-To: <200308080009.43862.peter.backlund@home.se> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060287534.4571.7.camel@mentor.gurulabs.com> <58761.81.56.217.49.1060291982.squirrel@webmail.sciences.univ-nantes.fr> <200308080009.43862.peter.backlund@home.se> Message-ID: <59461.81.56.217.49.1060295200.squirrel@webmail.sciences.univ-nantes.fr> > >> You're making a point there. But unfortunatly, once again, >> up2date/current aren't offering the same services as apt-get, yum, >> urpmi.. does up2date allow you to install new rpms instead of just >> keeping the installed one up to date? > > Yes. Man is your friend :-) > > Actually, I think the name of up2date is what causes many people to > erroneously think of it as "the windows update of red hat". Exactly... and the fact that current/up2date repositories are rare, very rare since current isn't finished and ready for mass use (which will come as soon as the mysql backend is ready and stable) yet and since Redhat up2date's server isn't publicly available. > > The only major thing up2date doesn't do, that apt/yum/urpmi does, is > cascade removal. Hmm.. i just thought of something about apt-get: it's useless if your rpmdb isn't consistant.. i mean if you install 1 rpm with --nodeps because, you have the lastest version of a lib and the rpm you want to install require a older version of this lib, apt-get will not want to install anything. Of course it's a good security, but still, it shouldn't refuse to install anything... i don't know what woud be YUM's behavior in that case... I have to admin from what i read on YUM's site, it indeed looks better than apt. Not only client side, but setting a YUM repository seems really simple. What's missing: more advertising of YUM, to get more repositories. Arnaud. From jos at xos.nl Thu Aug 7 22:43:39 2003 From: jos at xos.nl (Jos Vos) Date: Fri, 8 Aug 2003 00:43:39 +0200 Subject: dependency tool for RedHat In-Reply-To: <59461.81.56.217.49.1060295200.squirrel@webmail.sciences.univ-nantes.fr>; from arnaud.abelard@sciences.univ-nantes.fr on Fri, Aug 08, 2003 at 12:26:40AM +0200 References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060287534.4571.7.camel@mentor.gurulabs.com> <58761.81.56.217.49.1060291982.squirrel@webmail.sciences.univ-nantes.fr> <200308080009.43862.peter.backlund@home.se> <59461.81.56.217.49.1060295200.squirrel@webmail.sciences.univ-nantes.fr> Message-ID: <20030808004339.A11087@xos037.xos.nl> On Fri, Aug 08, 2003 at 12:26:40AM +0200, Arnaud Abelard wrote: > I have to admin from what i read on YUM's site, it indeed looks better > than apt. Not only client side, but setting a YUM repository seems really > simple. What's missing: more advertising of YUM, to get more repositories. See my recent postings on the yum mailing list. Apt currently has some features yum is missing (like downgrading in controlled circumstances, scripting) which are for me mandatory for enterprise use. I like yum because it's (much) smaller, Python (thus easier to understand extend yourself - if you need to), but for now I have to stick to apt. In the meantime I try to join the discussions on the yum list and see if I can help making it also for me a viable alternative to apt. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From alikins at redhat.com Thu Aug 7 23:16:11 2003 From: alikins at redhat.com (Adrian Likins) Date: Thu, 7 Aug 2003 19:16:11 -0400 Subject: dependency tool for RedHat In-Reply-To: <200308080009.43862.peter.backlund@home.se>; from peter.backlund@home.se on Fri, Aug 08, 2003 at 12:09:43AM +0200 References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060287534.4571.7.camel@mentor.gurulabs.com> <58761.81.56.217.49.1060291982.squirrel@webmail.sciences.univ-nantes.fr> <200308080009.43862.peter.backlund@home.se> Message-ID: <20030807191611.C26077@redhat.com> On Fri, Aug 08, 2003 at 12:09:43AM +0200, Peter Backlund wrote: > > > You're making a point there. But unfortunatly, once again, up2date/current > > aren't offering the same services as apt-get, yum, urpmi.. does up2date > > allow you to install new rpms instead of just keeping the installed one up > > to date? > > Yes. Man is your friend :-) > > Actually, I think the name of up2date is what causes many people to > erroneously think of it as "the windows update of red hat". > > The only major thing up2date doesn't do, that apt/yum/urpmi does, is cascade > removal. hmm, didnt realize yum did cascade removal. I admit I've put off adding that feature. Mainly because it seems pretty dangerous, especially without a concept of "pinning" or similar. And as seth already mentioned, that concept has some problems, most noteably the confusion it can cause users. And the confusion it can cause programmers is kind of harsh as well ;-> apt seems to use the pinning concept as the basis for its policy engine for removals. Deciding what packages are okay to remove in a caccade remove is a bit picky. Leaf nodes are easy enough. And packages that only depend on leaf nodes is probably doable. But what happens when a request to remove, say, "glib2" is made, is a bit more complicated. Keep in mind that commandline up2date (and the web triggered stuff) _has_ to work non-interactively. A simple rule of "dont ever remove anything in this list" would probabaly be a good start. I'll make a note to look into it again it people find it useful. Adrian From kewley at cns.caltech.edu Fri Aug 8 05:12:18 2003 From: kewley at cns.caltech.edu (David Kewley) Date: Thu, 7 Aug 2003 22:12:18 -0700 Subject: getting new driver into kernel, boot.iso Message-ID: <200308072212.18109.kewley@cns.caltech.edu> Hi all, I support a couple of machines with an Asus P4P800 motherboard. I anticipate building more machines with this board, and want it to be well-supported by Red Hat Linux in the future. The main problem I've run into so far is the on-board network interface. This board (and its sister the P4C800) have a 3Com 3C940 Gigabit ethernet chip onboard, which I want to use both to do a network kickstart and for normal operation, but there are no drivers for this chip in the RH kernels. If you go to the Asus website, they give you a driver to download, which appears to be a 3Com-hacked version of an old sk98lin driver from SysConnect. (It appears that the logic on the 3C940 is licensed from SysConnect.) The sk98lin in the kernel.org kernel, and in the RH kernel, do not support the 3C940. However, SysKonnect has since provided newer versions of sk98lin on their website which do support the 3C940: http://www.syskonnect.com/syskonnect/support/driver/htm/sk98lin.htm SysKonnect offers a patch for 2.4.21, 2.2.25, and 2.6.0. They also offer an install package that has a script that attempts to produce sk98lin.o for your currently-installed kernel. None of these seem appropriate for my needs (using the latest RHL 9 kernel), although I'm willing to hear suggestions. There is a RH Bugzilla bug regarding related issues: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=89680 I want to see the latest sk98lin integrated into the Red Hat kernel (for RHL 9, and for the beta or the next release). I'm willing to do work on this myself. Once I have something that works to my satisfaction, I'll offer it on my website for others to use. I'll also offer my work to RH, if they're interested. My goal is to integrate the latest sk98lin in a way that adheres to RH's practices and which promotes maintainability and portability to future kernel releases (until the latest sk98lin gets officially incorporated). But I need some guidance to arrive at this destination. I've already made a boot.iso which I can use to kickstart the P4P800. But I made it in an ugly, unmaintainable way (by hacking the initrd). I think I've figured out something close to the proper way to do it, but I have questions. It appears that what I want to do is to make a patch that can be incorporated into the kernel src.rpm. Then BOOT, i386, i686, athlon etc. kernels can be made from this. I have a few questions about how to produce this patch. First of all, it appears that I need to pick an appropriate patch serial number for the specfile. What should I use? Second, if my patch is applied midway through the patching process, I need to be careful how I produce the patch, so as not to interfere with later patches. How do I do this? Third, I expect that I'll have to pick a custom build string until and unless RH accepts my patch or builds their own. I suppose if I start with e.g. kernel-2.4.20-18.9, I could make mine by kernel-2.4.20-18.9.dk.1. Is that appropriate? Once I have a patch that applies cleanly, I expect a rebuild of the kernel packages from the kernel src.rpm will result in all desired kernel packages, including a BOOT kernel to put on the boot.iso. This leaves one more question, however: How is the initrd for the boot.iso produced? It looks like you have to specify each and every driver in the BOOT kernel to mkinitrd, but I'm not sure that's correct. Surely someone at RH knows exactly how to do this; I can't find it in the distrubution or on the web, however. Thanks very much for any help, David From pmatilai at welho.com Fri Aug 8 08:26:39 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 8 Aug 2003 11:26:39 +0300 Subject: dependency tool for RedHat In-Reply-To: <1060290329.13714.57.camel@va.local.linuxlobbyist.org> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060275083.19551.9.camel@opus.phy.duke.edu> <200308071859.08357.peter.backlund@home.se> <55583.81.56.217.49.1060275968.squirrel@webmail.sciences.univ-nantes.fr> <1060287760.13714.43.camel@va.local.linuxlobbyist.org> <1060288264.17358.10.camel@binkley> <1060290329.13714.57.camel@va.local.linuxlobbyist.org> Message-ID: <1060331199.3f335ebf067f2@webmail.welho.com> Quoting Paul Iadonisi : > On Thu, 2003-08-07 at 16:31, seth vidal wrote: > > Hello, Seth! Thanks for developing yum. > > [snip] > > > Well I'm the yum developer and you'll note I made an addendum to my > > reasons for not using apt-get on the yum webpage. I can no longer claim > > they are reimplementing a lot of things. Though some of it is still the > > case. Seth, to set the record straight apt *is* still using external rpm calls to do it's deeds. Gustavo said he's ok with making it use rpmlib instead of external rpm BUT the patch needs some serious testing + making it work with rpm-3.x first. It works for me, mostly (got it to segfault once, haven't been able to reproduce), but that's just me, haven't had a single report of success/failure from anybody :( Might as well use this as a call to testers: If you ain't afraid of no ghosts, grab the latest apt from Fedora, rebuild with "--with rpmlib" option and try it out. > > I hadn't looked at the home page recently, so I hadn't noticed that. > I will say that in a recent update using synaptic against freshrpms.net > I noticed a *dramatic* speedup, so maybe that was when a lot of the code > was cleaned up. Both apt and synaptic have seen some optimizations lately but the most dramatic speed improvement in fedora+freshrpms apt (and thus synaptic) comes from playing tricks with rpmlib at startup (disabling various signature etc verifications when it's just doing the equivalent of 'rpm -qa|wc -l'). That's not in upstream apt and Gustavo said it wont be applied as it's really an rpm configuration issue, not an apt issue. The speedup is dramatic enough to warrant the patch in Fedora's and Freshrpm's apt however :) -- - Panu - From johnsonm at redhat.com Fri Aug 8 15:01:23 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 8 Aug 2003 11:01:23 -0400 Subject: getting new driver into kernel, boot.iso In-Reply-To: <200308072212.18109.kewley@cns.caltech.edu>; from kewley@cns.caltech.edu on Thu, Aug 07, 2003 at 10:12:18PM -0700 References: <200308072212.18109.kewley@cns.caltech.edu> Message-ID: <20030808110123.A15668@devserv.devel.redhat.com> On Thu, Aug 07, 2003 at 10:12:18PM -0700, David Kewley wrote: > If you go to the Asus website, they give you a driver to download, which > appears to be a 3Com-hacked version of an old sk98lin driver from > SysConnect. (It appears that the logic on the 3C940 is licensed from > SysConnect.) The sk98lin in the kernel.org kernel, and in the RH kernel, > do not support the 3C940. However, SysKonnect has since provided newer > versions of sk98lin on their website which do support the 3C940: > > http://www.syskonnect.com/syskonnect/support/driver/htm/sk98lin.htm It's important for drivers to be submitted for inclusion in the upstream kernel. As I've written in other threads, it doesn't make sense to have Red Hat's kernel be comprised of parts we have to poll a large selection of sources for -- that way we'll always be behind on everything. The whole point of having a mainstream kernel is that it is mainstream, that all updates happen in that context, that there's one point of integration that all process participants push to. I find it interesting that the name of the patch isn't actually a link; in my quick perusal it wasn't even clear that it's available... I also find it interesting that it is listed as a >.5MB patch against 2.4.21; that's not small or easy to verify/review, even if you actually can get at the source, which it isn't clear from the page describing it: http://www.syskonnect.com/syskonnect/support/driver/htm/sk98lin_2.4.21.htm > I want to see the latest sk98lin integrated into the Red Hat kernel (for RHL > 9, and for the beta or the next release). I'm willing to do work on this > myself. Once I have something that works to my satisfaction, I'll offer it > on my website for others to use. I'll also offer my work to RH, if they're > interested. > > My goal is to integrate the latest sk98lin in a way that adheres to RH's > practices and which promotes maintainability and portability to future > kernel releases (until the latest sk98lin gets officially incorporated). > But I need some guidance to arrive at this destination. As I mentioned above, our first policy is to get things upstream. > I've already made a boot.iso which I can use to kickstart the P4P800. But I > made it in an ugly, unmaintainable way (by hacking the initrd). I think Actually, you can make driver disks (Doug Ledford has a kit on his page at http://people.redhat.com/dledford/ ) and I think you can drop the updates on the iso somehow (installer folks would have details on that; not my area of expertise). All that about upstream and driver kit said, I'll answer the rest of the questions about building kernel per se as best as I can, as they are probably more generically useful. > First of all, it appears that I need to pick an appropriate patch serial > number for the specfile. What should I use? Just grab one at the end of the block for new devices. We go by 10s so that we can interpolate later easily. # Patches 1000 to 5000 are reserved for bugfixes to drivers and filesystems This is not an entirely new driver; those go in the "addon" directory and are in the next block: # Patches 5000 to 6000 are reserved for new drivers > Second, if my patch is applied midway through the patching process, I need > to be careful how I produce the patch, so as not to interfere with later > patches. How do I do this? Well, which patches actually interfere? Often it just doesn't matter. In this case I doubt it will. There really aren't many patches applied after that block. When it does matter, and you do need to slot a patch in the middle, it does take some work. Usually, you put an "exit 0" in the spec file right before the place where you want to put the patch. Then you build the patch against the resulting source tree, and then you have to keep moving the exit 0 down through the spec file as you modify subsequent patches to deal with the conflict. You clearly need to understand that patch you are working with fully in order to do this manipulation correctly. This would include a clear understanding of why the patches go in the order your are putting them in. But a driver update won't normally create this hassle. > Third, I expect that I'll have to pick a custom build string until and > unless RH accepts my patch or builds their own. I suppose if I start with > e.g. kernel-2.4.20-18.9, I could make mine by kernel-2.4.20-18.9.dk.1. Is > that appropriate? Yup, that's exactly what we ask for! 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 kewley at cns.caltech.edu Fri Aug 8 15:42:35 2003 From: kewley at cns.caltech.edu (David Kewley) Date: Fri, 8 Aug 2003 08:42:35 -0700 Subject: getting new driver into kernel, boot.iso In-Reply-To: <20030808110123.A15668@devserv.devel.redhat.com> References: <200308072212.18109.kewley@cns.caltech.edu> <20030808110123.A15668@devserv.devel.redhat.com> Message-ID: <200308080842.35299.kewley@cns.caltech.edu> Michael K. Johnson wrote on Friday 08 August 2003 08:01: > It's important for drivers to be submitted for inclusion in the upstream > kernel. As I've written in other threads, it doesn't make sense to have > Red Hat's kernel be comprised of parts we have to poll a large selection > of sources for -- that way we'll always be behind on everything. The > whole point of having a mainstream kernel is that it is mainstream, that > all updates happen in that context, that there's one point of integration > that all process participants push to. OK, thanks. SysKonnect seems kinda slow in incorporating their driver into the upstream kernel, but I'll try to push them again. Your reasoning makes eminent sense to me. > I find it interesting that the name of the patch isn't actually a link; > in my quick perusal it wasn't even clear that it's available... I also > find it interesting that it is listed as a >.5MB patch against 2.4.21; > that's not small or easy to verify/review, even if you actually can get at > the source, which it isn't clear from the page describing it: > http://www.syskonnect.com/syskonnect/support/driver/htm/sk98lin_2.4.21.htm If I recall correctly from building my boot.iso a month ago or so, I grabbed the config file changes etc. from the 2.4.21 patch you point to above. But I grabbed the sk98lin source itself from the "InstallPakage" [sic] at http://www.syskonnect.com/syskonnect/support/driver/htm/sk98lin_inst_p.htm I didn't try to patch the sk98lin source with the 2.4.21 patch, because it was too unclean; I simply replaced it wholesale from the InstallPakage. > Actually, you can make driver disks (Doug Ledford has a kit on his > page at http://people.redhat.com/dledford/ ) and I think you can drop > the updates on the iso somehow (installer folks would have details on > that; not my area of expertise). Thanks for the pointer! I tried making a driver disk at one point, but failed. With Doug's instructions, I'll try again. That does indeed seem the easiest path at this point (along with pushing SysKonnect to get their driver into the upstream kernel). And thanks for the rest of your clarifications about the process for patching the RH kernel -- that helps greatly. I had one question at the end of your email that you didn't touch, regarding producing the initrd for the boot.iso. That's less of an issue if the driver disk works, but I'd still like to hear any comments anyone can offer. David From davej at redhat.com Fri Aug 8 16:01:03 2003 From: davej at redhat.com (Dave Jones) Date: Fri, 8 Aug 2003 17:01:03 +0100 Subject: getting new driver into kernel, boot.iso In-Reply-To: <20030808110123.A15668@devserv.devel.redhat.com> References: <200308072212.18109.kewley@cns.caltech.edu> <20030808110123.A15668@devserv.devel.redhat.com> Message-ID: <20030808160103.GA14008@suse.de> On Fri, Aug 08, 2003 at 11:01:23AM -0400, Michael K. Johnson wrote: > I find it interesting that the name of the patch isn't actually a link; > in my quick perusal it wasn't even clear that it's available... I also > find it interesting that it is listed as a >.5MB patch against 2.4.21; > that's not small or easy to verify/review, even if you actually can get at > the source, which it isn't clear from the page describing it: > http://www.syskonnect.com/syskonnect/support/driver/htm/sk98lin_2.4.21.htm (click the disk icon 8-) http://www.syskonnect.com/syskonnect/support/driver/zip/linux/sk98lin_2.4.21_patch.gz >From a quick skim of the code, it seems largely made up of gratuitous whitespace changes, which makes it hard to see the real changes. Lots of changing comments from.. /* foo */ to /* ** foo */ Seems someone got a new text editor with macros for xmas.. Lots of hard coded values changed to #defines - a good thing. Some new cards supported - also a good thing. That aside ISTR someone mentioning that this update backs out some stuff that has been fixed in mainline since they last did a push, so that needs fixing, as do the memory leaks they introduce in their ioctls. They may also be other problems, but thats all I picked up from a quick 2 minute skim of the diff. Fishing out the good bits of the patch is a worthwhile thing for someone to do, but its not a 10 minute job. Dave From jrb at redhat.com Fri Aug 8 18:22:58 2003 From: jrb at redhat.com (Jonathan Blandford) Date: 08 Aug 2003 14:22:58 -0400 Subject: GNOME 2.4 in Cambridge Message-ID: After a bit of discussion, we[1] agreed that it makes sense to try to put GNOME 2.4 in Cambridge. Given the stability of the 2.3.x releases it seems to be a minimally risky proposition. Additionally, GNOME appears to be right on schedule. We may have to push out the Cambridge release date a little, but it's looking very good in general. Alex and I will be rebuilding and upgrading the packages in rawhide over the next week or so. Thanks, -Jonathan [1] Those of us on the desktop team, anyway. From elanthis at awesomeplay.com Fri Aug 8 18:27:14 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 08 Aug 2003 14:27:14 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: References: Message-ID: <1060367233.4730.2.camel@stargrazer.home.awesomeplay.com> On Fri, 2003-08-08 at 14:22, Jonathan Blandford wrote: > After a bit of discussion, we[1] agreed that it makes sense to try to > put GNOME 2.4 in Cambridge. Given the stability of the 2.3.x releases > it seems to be a minimally risky proposition. Additionally, GNOME > appears to be right on schedule. We may have to push out the Cambridge > release date a little, but it's looking very good in general. Alex and > I will be rebuilding and upgrading the packages in rawhide over the next > week or so. For those of us using NyQuist's apt repository - would it be a good idea to downgrade to RedHat's gnome packages now, or will the transition likely be smooth enough to just stop upgrading from nyquist's repository? > > Thanks, > -Jonathan > > [1] Those of us on the desktop team, anyway. > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From skvidal at phy.duke.edu Fri Aug 8 18:28:25 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 08 Aug 2003 14:28:25 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: References: Message-ID: <1060367305.22092.193.camel@opus.phy.duke.edu> On Fri, 2003-08-08 at 14:22, Jonathan Blandford wrote: > After a bit of discussion, we[1] agreed that it makes sense to try to > put GNOME 2.4 in Cambridge. Given the stability of the 2.3.x releases > it seems to be a minimally risky proposition. Additionally, GNOME > appears to be right on schedule. We may have to push out the Cambridge > release date a little, but it's looking very good in general. Alex and > I will be rebuilding and upgrading the packages in rawhide over the next > week or so. Out of curiosity - will the move to gnome 2.4 from 2.2 be relatively clean? How many config files will break? -sv From hp at redhat.com Fri Aug 8 18:52:24 2003 From: hp at redhat.com (Havoc Pennington) Date: Fri, 8 Aug 2003 14:52:24 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: <1060367305.22092.193.camel@opus.phy.duke.edu> References: <1060367305.22092.193.camel@opus.phy.duke.edu> Message-ID: <20030808145224.B17775@devserv.devel.redhat.com> On Fri, Aug 08, 2003 at 02:28:25PM -0400, seth vidal wrote: > Out of curiosity - will the move to gnome 2.4 from 2.2 be relatively > clean? > > How many config files will break? The stated objective with GNOME is that if you have an NFS home directory used by 2.0, 2.2, 2.4, 2.6, and 2.8 systems then everything still works. "Works" meaning nothing gets confused; it's possible you have have to configure something twice, for different GNOME versions, but the two configurations should coexist. If this doesn't hold true, it's a bug; file a bug report with details on where it breaks. Havoc From kaboom at gatech.edu Fri Aug 8 18:56:37 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Fri, 8 Aug 2003 12:56:37 -0600 (MDT) Subject: GNOME 2.4 in Cambridge In-Reply-To: <20030808145224.B17775@devserv.devel.redhat.com> References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> Message-ID: On Fri, 8 Aug 2003, Havoc Pennington wrote: > On Fri, Aug 08, 2003 at 02:28:25PM -0400, seth vidal wrote: > > Out of curiosity - will the move to gnome 2.4 from 2.2 be relatively > > clean? > > > > How many config files will break? > > The stated objective with GNOME is that if you have an NFS home > directory used by 2.0, 2.2, 2.4, 2.6, and 2.8 systems then everything > still works. "Works" meaning nothing gets confused; it's possible > you have have to configure something twice, for different GNOME > versions, but the two configurations should coexist. For those of us with NFS home dirs, is GNOME 2.4 supposed to work on two different machines at the same time off the same home dir? That, to me, would be the more useful objective.... later, chris From skvidal at phy.duke.edu Fri Aug 8 19:03:40 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 08 Aug 2003 15:03:40 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> Message-ID: <1060369420.22092.209.camel@opus.phy.duke.edu> > > For those of us with NFS home dirs, is GNOME 2.4 supposed to work on two > different machines at the same time off the same home dir? That, to me, > would be the more useful objective.... I have been told by others that I am 'beating a dead horse' when I bring up gconf sucking on network mounted homedirs with multiple simultaneous logins. so I think it is safe to assume that the answer to the above question is 'no'. -sv From hp at redhat.com Fri Aug 8 19:17:48 2003 From: hp at redhat.com (Havoc Pennington) Date: Fri, 8 Aug 2003 15:17:48 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> Message-ID: <20030808151748.C17775@devserv.devel.redhat.com> On Fri, Aug 08, 2003 at 12:56:37PM -0600, Chris Ricker wrote: > For those of us with NFS home dirs, is GNOME 2.4 supposed to work on two > different machines at the same time off the same home dir? That, to me, > would be the more useful objective.... It is if you enable TCP CORBA connections between the two machines, or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1 Given that preliminary setup, the last bugs in multiple logins should have been fixed in RHL 9. But as Seth says the "real fix" is well-known and it's just a matter of someone having time to implement it. It is certainly known that opening TCP between machines isn't a great solution. Havoc From skvidal at phy.duke.edu Fri Aug 8 19:20:48 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 08 Aug 2003 15:20:48 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: <20030808151748.C17775@devserv.devel.redhat.com> References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> <20030808151748.C17775@devserv.devel.redhat.com> Message-ID: <1060370447.22092.221.camel@opus.phy.duke.edu> > It is if you enable TCP CORBA connections between the two machines, > or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1 > What makes this one so much more dangerous? > Given that preliminary setup, the last bugs in multiple logins should > have been fixed in RHL 9. > > But as Seth says the "real fix" is well-known and it's just a matter > of someone having time to implement it. It is certainly known that > opening TCP between machines isn't a great solution. > And as you and I have talked about before. In some cases it is impossible. b/c the two machines might not be able to see each other. -sv From kaboom at gatech.edu Fri Aug 8 19:24:35 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Fri, 8 Aug 2003 13:24:35 -0600 (MDT) Subject: GNOME 2.4 in Cambridge In-Reply-To: <20030808151748.C17775@devserv.devel.redhat.com> References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> <20030808151748.C17775@devserv.devel.redhat.com> Message-ID: On Fri, 8 Aug 2003, Havoc Pennington wrote: > On Fri, Aug 08, 2003 at 12:56:37PM -0600, Chris Ricker wrote: > > For those of us with NFS home dirs, is GNOME 2.4 supposed to work on two > > different machines at the same time off the same home dir? That, to me, > > would be the more useful objective.... > > It is if you enable TCP CORBA connections between the two machines, > or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1 How does one do these? I assume the second is an env variable, but what's the first? And what's more dangerous about the second? later, chris From hp at redhat.com Fri Aug 8 19:25:36 2003 From: hp at redhat.com (Havoc Pennington) Date: Fri, 8 Aug 2003 15:25:36 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: <1060370447.22092.221.camel@opus.phy.duke.edu> References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> <20030808151748.C17775@devserv.devel.redhat.com> <1060370447.22092.221.camel@opus.phy.duke.edu> Message-ID: <20030808152536.D17775@devserv.devel.redhat.com> On Fri, Aug 08, 2003 at 03:20:48PM -0400, seth vidal wrote: > > > It is if you enable TCP CORBA connections between the two machines, > > or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1 > > > > What makes this one so much more dangerous? Because you can sometimes get inconsistent configuration state that confuses the panel or gnome-terminal. Usually would show up as losing terminal profiles or losing panels probably. I would expect this to be rare but Owen argues it will happen a lot, and there have been a couple reports. > And as you and I have talked about before. In some cases it is > impossible. b/c the two machines might not be able to see each > other. Yep. Havoc From hp at redhat.com Fri Aug 8 19:26:40 2003 From: hp at redhat.com (Havoc Pennington) Date: Fri, 8 Aug 2003 15:26:40 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> <20030808151748.C17775@devserv.devel.redhat.com> Message-ID: <20030808152640.E17775@devserv.devel.redhat.com> On Fri, Aug 08, 2003 at 01:24:35PM -0600, Chris Ricker wrote: > On Fri, 8 Aug 2003, Havoc Pennington wrote: > > > On Fri, Aug 08, 2003 at 12:56:37PM -0600, Chris Ricker wrote: > > > For those of us with NFS home dirs, is GNOME 2.4 supposed to work on two > > > different machines at the same time off the same home dir? That, to me, > > > would be the more useful objective.... > > > > It is if you enable TCP CORBA connections between the two machines, > > or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1 > > How does one do these? I assume the second is an env variable, but what's > the first? And what's more dangerous about the second? > See www.gnome.org/projects/gconf/, conceivably the GNOME admin guide at www.gnome.org/learn/ has something on it too. For dangerousness see my reply to Seth just now. Havoc From sopwith at redhat.com Fri Aug 8 19:30:36 2003 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 8 Aug 2003 15:30:36 -0400 (EDT) Subject: GNOME 2.4 in Cambridge In-Reply-To: Message-ID: On Fri, 8 Aug 2003, Chris Ricker wrote: > > It is if you enable TCP CORBA connections between the two machines, > > or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1 > > How does one do these? I assume the second is an env variable, but > what's the first? echo ORBIIOPIPv4=1 > ~/.orbitrc Can also be done per-machine using /etc/orbitrc. IPv6 should also work, if that's your piece of cake. -- Elliot Humpty Dumpty was pushed. From skvidal at phy.duke.edu Fri Aug 8 19:31:39 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 08 Aug 2003 15:31:39 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: <20030808152536.D17775@devserv.devel.redhat.com> References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> <20030808151748.C17775@devserv.devel.redhat.com> <1060370447.22092.221.camel@opus.phy.duke.edu> <20030808152536.D17775@devserv.devel.redhat.com> Message-ID: <1060371099.22092.227.camel@opus.phy.duke.edu> On Fri, 2003-08-08 at 15:25, Havoc Pennington wrote: > On Fri, Aug 08, 2003 at 03:20:48PM -0400, seth vidal wrote: > > > > > It is if you enable TCP CORBA connections between the two machines, > > > or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1 > > > > > > > What makes this one so much more dangerous? > > Because you can sometimes get inconsistent configuration state that > confuses the panel or gnome-terminal. Usually would show up as losing > terminal profiles or losing panels probably. I would expect this to be > rare but Owen argues it will happen a lot, and there have been a > couple reports. oh - you mean dangerous in that sense. Yah. ok. I was one of the reporters of this - and yah - we got the configuration corruption to occur with relative ease. ok. Thanks -sv From chuckw at quantumlinux.com Fri Aug 8 19:38:03 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Fri, 8 Aug 2003 12:38:03 -0700 (PDT) Subject: dependency tool for RedHat In-Reply-To: <200308071859.08357.peter.backlund@home.se> Message-ID: > > > RedHat Linux is one of the last modern linux distributions not to > > > have a dependency tool like apt-get, urpmi or autopkg included in > > > the default intstallation. > > up2date has been available since 6.2 I believe. Do you even use Red Hat? up2date is not an appropriate tool for resolving dependencies. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From enrico.scholz at informatik.tu-chemnitz.de Fri Aug 8 19:52:43 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 08 Aug 2003 21:52:43 +0200 Subject: GNOME 2.4 in Cambridge In-Reply-To: <1060369420.22092.209.camel@opus.phy.duke.edu> (seth vidal's message of "08 Aug 2003 15:03:40 -0400") References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> <1060369420.22092.209.camel@opus.phy.duke.edu> Message-ID: <87ptjgncz8.fsf@kosh.ultra.csn.tu-chemnitz.de> skvidal at phy.duke.edu (seth vidal) writes: > I have been told by others that I am 'beating a dead horse' when I bring > up gconf sucking on network mounted homedirs with multiple simultaneous > logins. What is with non-simultaneous logins? How can I prevent the .fonts.cache-regeneration-memorial-minute after logging in on another machine? Enrico From peter.backlund at home.se Fri Aug 8 21:03:58 2003 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 8 Aug 2003 23:03:58 +0200 Subject: dependency tool for RedHat In-Reply-To: References: Message-ID: <200308082303.58323.peter.backlund@home.se> > up2date is not an appropriate tool for resolving dependencies. No? How do you define "resolve dependencies"? From jrb at redhat.com Fri Aug 8 21:48:16 2003 From: jrb at redhat.com (Jonathan Blandford) Date: 08 Aug 2003 17:48:16 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: <1060367305.22092.193.camel@opus.phy.duke.edu> References: <1060367305.22092.193.camel@opus.phy.duke.edu> Message-ID: seth vidal writes: > On Fri, 2003-08-08 at 14:22, Jonathan Blandford wrote: > > After a bit of discussion, we[1] agreed that it makes sense to try to > > put GNOME 2.4 in Cambridge. Given the stability of the 2.3.x releases > > it seems to be a minimally risky proposition. Additionally, GNOME > > appears to be right on schedule. We may have to push out the Cambridge > > release date a little, but it's looking very good in general. Alex and > > I will be rebuilding and upgrading the packages in rawhide over the next > > week or so. > > Out of curiosity - will the move to gnome 2.4 from 2.2 be relatively > clean? The big thing I can think of is that we now use ~/Desktop instead of ~/.gnome-desktop for the users desktop by default. -Jonathan From kaboom at gatech.edu Fri Aug 8 21:52:21 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Fri, 8 Aug 2003 15:52:21 -0600 (MDT) Subject: GNOME 2.4 in Cambridge In-Reply-To: References: Message-ID: On Fri, 8 Aug 2003, Elliot Lee wrote: > On Fri, 8 Aug 2003, Chris Ricker wrote: > > > > It is if you enable TCP CORBA connections between the two machines, > > > or somewhat more dangerously if you use GCONF_LOCAL_LOCKS=1 > > > > How does one do these? I assume the second is an env variable, but > > what's the first? > > echo ORBIIOPIPv4=1 > ~/.orbitrc > > Can also be done per-machine using /etc/orbitrc. IPv6 should also work, if > that's your piece of cake. Hmm, when I try that, either .orbitrc or /etc, when I start GNOME I get: "There was an error starting the GNOME Settings Daemon. Some things, such as themes, sounds, or background settings may not work correctly. The Settings Daemon restarted too many times. GNOME will still try to restart the Settings Daemon next time you log in." This is on rawhide later, chris From skvidal at phy.duke.edu Fri Aug 8 23:10:25 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 08 Aug 2003 19:10:25 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: References: <1060367305.22092.193.camel@opus.phy.duke.edu> Message-ID: <1060384225.20279.0.camel@binkley> > The big thing I can think of is that we now use ~/Desktop instead of > ~/.gnome-desktop for the users desktop by default. > Great. I always hated not being able to easily browse to my desktop dir from most of the file selection dialogs. -sv From skvidal at phy.duke.edu Sat Aug 9 00:58:25 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 08 Aug 2003 20:58:25 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: <87ptjgncz8.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> <1060369420.22092.209.camel@opus.phy.duke.edu> <87ptjgncz8.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1060390705.3499.17.camel@binkley> On Fri, 2003-08-08 at 15:52, Enrico Scholz wrote: > skvidal at phy.duke.edu (seth vidal) writes: > > > I have been told by others that I am 'beating a dead horse' when I bring > > up gconf sucking on network mounted homedirs with multiple simultaneous > > logins. > > What is with non-simultaneous logins? How can I prevent the > .fonts.cache-regeneration-memorial-minute after logging in on another > machine? hmm I've not experienced that. Can you describe it some more or link to a bug? -sv From thomas at apestaart.org Sat Aug 9 08:45:32 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Sat, 09 Aug 2003 10:45:32 +0200 Subject: dependency tool for RedHat In-Reply-To: <59461.81.56.217.49.1060295200.squirrel@webmail.sciences.univ-nantes.fr> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060287534.4571.7.camel@mentor.gurulabs.com> <58761.81.56.217.49.1060291982.squirrel@webmail.sciences.univ-nantes.fr> <200308080009.43862.peter.backlund@home.se> <59461.81.56.217.49.1060295200.squirrel@webmail.sciences.univ-nantes.fr> Message-ID: <1060418732.24119.12.camel@thocra> On Fri, 2003-08-08 at 00:26, Arnaud Abelard wrote: > > The only major thing up2date doesn't do, that apt/yum/urpmi does, is > > cascade removal. > > Hmm.. i just thought of something about apt-get: it's useless if your > rpmdb isn't consistant.. i mean if you install 1 rpm with --nodeps > because, you have the lastest version of a lib and the rpm you want to > install require a older version of this lib, apt-get will not want to > install anything. Which is a good thing. If you insist on running with inconsistent rpm databases, then your system is hosed by definition. In the case above, if the rpm you want to install insists on the lower library (I don't think I ever see many that do Requires: ... < (version)), then either it's a packaging bug (the software works fine with this newer version) or it's an actual situation where the newer lib doesn't work well (in which case using --nodeps won't make the software magically work). The only good argument for ever having an inconsistent database is those precious few instances where you have to change versions on some packages and between those versions the package set is done differently, so you need to be inconsistent to remove parts and upgrade parts at the same time. So, thank you apt-get for not working when being inconsistent. Thomas Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> Now, if it were called the Orgasmator, I'd be the first to try your basic button-press approach ... <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ From dag at wieers.com Sat Aug 9 10:06:37 2003 From: dag at wieers.com (Dag Wieers) Date: Sat, 9 Aug 2003 12:06:37 +0200 (CEST) Subject: dependency tool for RedHat In-Reply-To: <1060418732.24119.12.camel@thocra> Message-ID: On Sat, 9 Aug 2003, Thomas Vander Stichele wrote: > So, thank you apt-get for not working when being inconsistent. Actually, if there's no relation between the inconsistency and the packages apt-get wants to update/remove, apt-get could work without any problem. So it is a PITA if it just refuses to work because the whole is inconsistent. I once send a mail to the apt development ml about this with some examples in which cases an inconsistent rpm database is unavoidable for end-users and apt-get becomes useless. Which is unfortunately the case for the machine-park I maintain. Nobody replied to it ;) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [Any errors in spelling, tact or fact are transmission errors] From arnaud.abelard at sciences.univ-nantes.fr Sat Aug 9 10:26:58 2003 From: arnaud.abelard at sciences.univ-nantes.fr (Arnaud Abelard) Date: Sat, 9 Aug 2003 12:26:58 +0200 (CEST) Subject: dependency tool for RedHat In-Reply-To: <1060418732.24119.12.camel@thocra> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060287534.4571.7.camel@mentor.gurulabs.com> <58761.81.56.217.49.1060291982.squirrel@webmail.sciences.univ-nantes.fr> <200308080009.43862.peter.backlund@home.se> <59461.81.56.217.49.1060295200.squirrel@webmail.sciences.univ-nantes.fr> <1060418732.24119.12.camel@thocra> Message-ID: <54631.81.56.217.49.1060424818.squirrel@webmail.sciences.univ-nantes.fr> > Which is a good thing. If you insist on running with inconsistent rpm > databases, then your system is hosed by definition. In the case above, > if the rpm you want to install insists on the lower library (I don't > think I ever see many that do Requires: ... < (version)), then either > it's a packaging bug (the software works fine with this newer version) > or it's an actual situation where the newer lib doesn't work well (in > which case using --nodeps won't make the software magically work). That's true, but in some case the inconsistency is unavoidable.. a compiled library, or a more recent library than the one required by a rpm (require: libsomething1.2.1 for example) apt-get could warn the user and prompt them: "this can cause harm to your system, are you sure you want to continue [Y/N]" or maybe implements a --force mode. Of course that could be dangerous in certain cases.. not all the time. > > > The only good argument for ever having an inconsistent database is those > precious few instances where you have to change versions on some > packages and between those versions the package set is done differently, > so you need to be inconsistent to remove parts and upgrade parts at the > same time. > > So, thank you apt-get for not working when being inconsistent. Yes, sometimes it's important to refuse working with a inconsistent rpm db, but could be usefull to...security is important.. but sometimes taking risks is the only solution I can't figure what's YUM's behavior in that case.. will it refuse to install new rpms too? > > Thomas > Arnaud From dave.bevan at bbc.co.uk Sat Aug 9 10:34:33 2003 From: dave.bevan at bbc.co.uk (Dave Bevan) Date: Sat, 9 Aug 2003 11:34:33 +0100 Subject: Opteron / AGP Message-ID: Hi, I guess this should partly be aimed at Dave Jones (ex. Suse, now Red Hat) who has maintained AGPGART. Is support for the AMD AGP Chipset - 8151 complete ? I was reading some stuff that suggested that on a 'full' dual-Opteron rig (with AMD's AGP 8151, PCI-X 8131 and IO 8111 controllers all in place), the AGP bus would not always show up as PCI Device 0. Any thoughts ? Rgds, -- Dave. BBC TV News, London, UK. BBCi at http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system, do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From pauln at truemesh.com Sat Aug 9 10:43:12 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Sat, 9 Aug 2003 11:43:12 +0100 Subject: Automated Testing Message-ID: <20030809104311.GG8712@shitake.truemesh.com> I was just wondering if anyone does any automated testing/continuous integration with package trees and wondered what system setup you use. Theoretically you could pull rawhide, cvs ( cvsup for jbj ) and kick off package builds and run some tests. I'm considering writing some integration tests for one of the projects I work on, and thought I'd see what other people do before re-inventing the wheel. Cheers Paul From veillard at redhat.com Sat Aug 9 11:58:56 2003 From: veillard at redhat.com (Daniel Veillard) Date: Sat, 9 Aug 2003 07:58:56 -0400 Subject: Automated Testing In-Reply-To: <20030809104311.GG8712@shitake.truemesh.com>; from pauln@truemesh.com on Sat, Aug 09, 2003 at 11:43:12AM +0100 References: <20030809104311.GG8712@shitake.truemesh.com> Message-ID: <20030809075856.W21443@redhat.com> On Sat, Aug 09, 2003 at 11:43:12AM +0100, Paul Nasrat wrote: > I was just wondering if anyone does any automated testing/continuous > integration with package trees and wondered what system setup you use. > > Theoretically you could pull rawhide, cvs ( cvsup for jbj ) and kick off > package builds and run some tests. I'm considering writing some > integration tests for one of the projects I work on, and thought I'd see > what other people do before re-inventing the wheel. Well one thing could be to run/collect/compare output from the "make test(s)" or "make check(s)" that the makefile of the program or library may provide. It's not done but could help finding regression troubles between releases or platforms. But I doubt it's an easy task, fist one need to find if those makefile target exists, then run them from the build tree, deal with possible missing shared libs and design checking code to dig and compare the possibly huge amount of data it would generate into a human usable result. Hard but if done well could be quite useful ! Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From pmatilai at welho.com Sat Aug 9 13:26:43 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Sat, 9 Aug 2003 16:26:43 +0300 Subject: dependency tool for RedHat In-Reply-To: <54631.81.56.217.49.1060424818.squirrel@webmail.sciences.univ-nantes.fr> References: <55302.81.56.217.49.1060274938.squirrel@webmail.sciences.univ-nantes.fr> <1060287534.4571.7.camel@mentor.gurulabs.com> <58761.81.56.217.49.1060291982.squirrel@webmail.sciences.univ-nantes.fr> <200308080009.43862.peter.backlund@home.se> <59461.81.56.217.49.1060295200.squirrel@webmail.sciences.univ-nantes.fr> <1060418732.24119.12.camel@thocra> <54631.81.56.217.49.1060424818.squirrel@webmail.sciences.univ-nantes.fr> Message-ID: <1060435603.3f34f693411eb@webmail.welho.com> Quoting Arnaud Abelard : > > Which is a good thing. If you insist on running with inconsistent rpm > > databases, then your system is hosed by definition. In the case above, > > if the rpm you want to install insists on the lower library (I don't > > think I ever see many that do Requires: ... < (version)), then either > > it's a packaging bug (the software works fine with this newer version) > > or it's an actual situation where the newer lib doesn't work well (in > > which case using --nodeps won't make the software magically work). > > That's true, but in some case the inconsistency is unavoidable.. a > compiled library, or a more recent library than the one required by a rpm > (require: libsomething1.2.1 for example) > apt-get could warn the user and prompt them: "this can cause harm to your > system, are you sure you want to continue [Y/N]" or maybe implements a > --force mode. Of course that could be dangerous in certain cases.. not all > the time. No. Like Thomas said, using --nodeps doesn't make the software magically work. That's a packaging issue, nothing to do with the tools - if rpm/apt/yum/etc start second-guessing "hmm we have a dependency on foo-2.2 and we only got foo- 2.1 available here, oh i guess thats close enough" we're in deep trouble. > > > > > > > The only good argument for ever having an inconsistent database is those > > precious few instances where you have to change versions on some > > packages and between those versions the package set is done differently, > > so you need to be inconsistent to remove parts and upgrade parts at the > > same time. > > > > > So, thank you apt-get for not working when being inconsistent. > > Yes, sometimes it's important to refuse working with a inconsistent rpm > db, but could be usefull to...security is important.. but sometimes taking > risks is the only solution Purposefully installing software with incorrect dependencies and hoping it'll work anyway is not a solution. However there *are* times when overriding the normal check on rpmdb consistency would be extremely handy: usually when a dist- upgrade has blown up in middle leaving the rpmdb in a state which is impossible to fix by any single operation ("-f install" or manually upgrading things). Then it becomes really painfull trying to salvage the system by manually downloading and installing rpm's when apt *could* do it as well, weren't it for the consistency checks. I once tried adding an option to disable the checks but it's far from trivial, the "package database must be consistent at all times" is bolted deep into the design. > > I can't figure what's YUM's behavior in that case.. will it refuse to > install new rpms too? Yum only cares about the transaction at hand being consistent, it doesn't check rpmdb consistence as such. Ditto for up2date and anaconda, don't know about rc. -- - Panu - From dave.bevan at bbc.co.uk Sat Aug 9 21:27:08 2003 From: dave.bevan at bbc.co.uk (Dave Bevan) Date: Sat, 9 Aug 2003 22:27:08 +0100 Subject: Gigabyte 8KNXP Mobo and Severn Message-ID: Hi, My rig is working fine - above mobo + Nvidia Quadro FX1000 + P4 3.2+HT/800fsb, but I found this when checking thru dmesg: [root at togdev1 log]# egrep -i "nvidia|agp" dmesg 1: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4496 Wed Jul 16 19:03:09 PDT 2003 Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 941M agpgart: Unsupported Intel chipset (device id: 2578), you might want to try agp_try_unsupported=1. agpgart: no supported devices found. 0: NVRM: AGPGART: unable to retrieve symbol table [root at togdev1 log]# I'm using the NVIDIA module, not AGPGART, so the 'Unsupported Intel chipset' does not bother me, but it might be an issue for someone else. If reqd, I can supply full dmesg, /proc/pci etc, etc. -- Dave. BBC TV News,, London, UK. BBCi at http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system, do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From skvidal at phy.duke.edu Sat Aug 9 23:07:50 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 09 Aug 2003 19:07:50 -0400 Subject: acpi confusion Message-ID: <1060470470.12013.9.camel@binkley> Hi all, So I have an ibm x23 laptop. nothing terribly fancy. With severn I noticed that the sound played far too slowly. Meaning - when I played an ogg it sounded like it was being played at the wrong speed if it were a record. So I filed a bug about it b/c the sound worked under rhl 9 just fine. The suggestion was to disable acpi and see if that fixed it. it did. the sound works as expected now. However, the laptop runs a lot hotter than it used to. So I was wondering if someone could explain the acpi stuff in more details. It was proposed to me by someone on #rhl-devel that maybe someone here could give an uncensored summary of the acpi stuff in the kernel and it's relative stability level, etc. Thanks -sv From elanthis at awesomeplay.com Sat Aug 9 23:23:56 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 09 Aug 2003 19:23:56 -0400 Subject: acpi confusion In-Reply-To: <1060470470.12013.9.camel@binkley> References: <1060470470.12013.9.camel@binkley> Message-ID: <1060471435.4747.3.camel@stargrazer.home.awesomeplay.com> acpi does a lot of things. the reason your laptop runs hot is that acpi is required to keep it cool. acpi controls power levels, throttling, etc., which you _really_ want on - i _hightly_ suggest you do not run your laptop without it, or you risk severely damaging the hardware. so far as the sound card, acpi _also_ controls the configuration of devices. if the acpi system configures the card wrong, slow-playback may be one side-effect. with recent linux acpi versions, any problems you have are quite likely to be in the machine's bios (where the acpi code is stored) rather than linux; you might want to check w/ the linux acpi project to see if anyone has a corrected dsdt for your machine. you can configure the kernel to use acpi for power management (i.e., keeping your laptop from over heating or eating the battery life), but keep the configure stuff off (so standard plug-n-play detection stuff is used). http://acpi.sf.net i believe is the sight for linux acpi information and so on. On Sat, 2003-08-09 at 19:07, seth vidal wrote: > Hi all, > So I have an ibm x23 laptop. nothing terribly fancy. With severn I > noticed that the sound played far too slowly. Meaning - when I played an > ogg it sounded like it was being played at the wrong speed if it were a > record. > > So I filed a bug about it b/c the sound worked under rhl 9 just fine. > The suggestion was to disable acpi and see if that fixed it. > > it did. the sound works as expected now. However, the laptop runs a lot > hotter than it used to. > > So I was wondering if someone could explain the acpi stuff in more > details. It was proposed to me by someone on #rhl-devel that maybe > someone here could give an uncensored summary of the acpi stuff in the > kernel and it's relative stability level, etc. > > Thanks > -sv > > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From skvidal at phy.duke.edu Sun Aug 10 00:20:12 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 09 Aug 2003 20:20:12 -0400 Subject: acpi confusion In-Reply-To: <1060471435.4747.3.camel@stargrazer.home.awesomeplay.com> References: <1060470470.12013.9.camel@binkley> <1060471435.4747.3.camel@stargrazer.home.awesomeplay.com> Message-ID: <1060474811.3514.7.camel@binkley> > you can configure the kernel to use acpi for power management (i.e., > keeping your laptop from over heating or eating the battery life), but > keep the configure stuff off (so standard plug-n-play detection stuff is > used). > > http://acpi.sf.net i believe is the sight for linux acpi information and > so on. > so I read that site. very informative and useful. then I look at my system, booted without acpi=off in the kernel boot line, and I have none of the /proc entries of which they speak. Does that make sense? -sv From elanthis at awesomeplay.com Sun Aug 10 00:22:53 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 09 Aug 2003 20:22:53 -0400 Subject: acpi confusion In-Reply-To: <1060474811.3514.7.camel@binkley> References: <1060470470.12013.9.camel@binkley> <1060471435.4747.3.camel@stargrazer.home.awesomeplay.com> <1060474811.3514.7.camel@binkley> Message-ID: <1060474973.4747.5.camel@stargrazer.home.awesomeplay.com> On Sat, 2003-08-09 at 20:20, seth vidal wrote: > > http://acpi.sf.net i believe is the sight for linux acpi information and > > so on. > > > > so I read that site. very informative and useful. then I look at my > system, booted without acpi=off in the kernel boot line, and I have none > of the /proc entries of which they speak. Does that make sense? Well, if you have ACPI off, I wouldn't imagine the /proc entries would be there. The configuration part of ACPI needs to be disabled int he kernel build, btw - changing /proc entries is going to help for bootup sequence. ;-) > > -sv > > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From skvidal at phy.duke.edu Sun Aug 10 00:26:20 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 09 Aug 2003 20:26:20 -0400 Subject: acpi confusion In-Reply-To: <1060474973.4747.5.camel@stargrazer.home.awesomeplay.com> References: <1060470470.12013.9.camel@binkley> <1060471435.4747.3.camel@stargrazer.home.awesomeplay.com> <1060474811.3514.7.camel@binkley> <1060474973.4747.5.camel@stargrazer.home.awesomeplay.com> Message-ID: <1060475180.3514.10.camel@binkley> > > so I read that site. very informative and useful. then I look at my > > system, booted without acpi=off in the kernel boot line, and I have none > > of the /proc entries of which they speak. Does that make sense? > > Well, if you have ACPI off, I wouldn't imagine the /proc entries would > be there. I said I did NOT have acpi=off which, I assume, means I have it on. I checked /proc/cmdline and grub - I definitely removed acpi=off > The configuration part of ACPI needs to be disabled int he kernel build, > btw - changing /proc entries is going to help for bootup sequence. ;-) Can you restate this? I don't think I'm getting your meaning. -sv From elanthis at awesomeplay.com Sun Aug 10 00:37:49 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 09 Aug 2003 20:37:49 -0400 Subject: acpi confusion In-Reply-To: <1060475180.3514.10.camel@binkley> References: <1060470470.12013.9.camel@binkley> <1060471435.4747.3.camel@stargrazer.home.awesomeplay.com> <1060474811.3514.7.camel@binkley> <1060474973.4747.5.camel@stargrazer.home.awesomeplay.com> <1060475180.3514.10.camel@binkley> Message-ID: <1060475869.4747.8.camel@stargrazer.home.awesomeplay.com> On Sat, 2003-08-09 at 20:26, seth vidal wrote: > > > so I read that site. very informative and useful. then I look at my > > > system, booted without acpi=off in the kernel boot line, and I have none > > > of the /proc entries of which they speak. Does that make sense? > > > > Well, if you have ACPI off, I wouldn't imagine the /proc entries would > > be there. > > I said I did NOT have acpi=off which, I assume, means I have it on. > I checked /proc/cmdline and grub - I definitely removed acpi=off whoops. sorry. ^^; in that case, you may not have it enabled int he kernel config. that seems most likely. > > > The configuration part of ACPI needs to be disabled int he kernel build, > > btw - changing /proc entries is going to help for bootup sequence. ;-) > > Can you restate this? I don't think I'm getting your meaning. > -sv I thought you wanted the /proc entries to disable ACPI. sorry, further misunderstanding. when you enable ACPI in the kernel config, just only enable the power management, which should let the laptop run properly, without acpi messing up the sound card. > > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From skvidal at phy.duke.edu Sun Aug 10 00:45:37 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 09 Aug 2003 20:45:37 -0400 Subject: acpi confusion In-Reply-To: <1060475869.4747.8.camel@stargrazer.home.awesomeplay.com> References: <1060470470.12013.9.camel@binkley> <1060471435.4747.3.camel@stargrazer.home.awesomeplay.com> <1060474811.3514.7.camel@binkley> <1060474973.4747.5.camel@stargrazer.home.awesomeplay.com> <1060475180.3514.10.camel@binkley> <1060475869.4747.8.camel@stargrazer.home.awesomeplay.com> Message-ID: <1060476336.3938.6.camel@binkley> On Sat, 2003-08-09 at 20:37, Sean Middleditch wrote: > On Sat, 2003-08-09 at 20:26, seth vidal wrote: > > > > so I read that site. very informative and useful. then I look at my > > > > system, booted without acpi=off in the kernel boot line, and I have none > > > > of the /proc entries of which they speak. Does that make sense? > > > > > > Well, if you have ACPI off, I wouldn't imagine the /proc entries would > > > be there. > > > > I said I did NOT have acpi=off which, I assume, means I have it on. > > I checked /proc/cmdline and grub - I definitely removed acpi=off > > whoops. sorry. ^^; in that case, you may not have it enabled int he > kernel config. that seems most likely. > I'm not using custom kernels. I'm using the stock kernel that came in the rhl beta severn. 2.4.21-20.1.2024.2.1.nptl - I thought it was enabled in that kernel. > I thought you wanted the /proc entries to disable ACPI. sorry, further > misunderstanding. when you enable ACPI in the kernel config, just only > enable the power management, which should let the laptop run properly, > without acpi messing up the sound card. I'll look into it. thanks. -sv From skvidal at phy.duke.edu Sun Aug 10 00:54:15 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 09 Aug 2003 20:54:15 -0400 Subject: acpi confusion, redux Message-ID: <1060476854.3938.9.camel@binkley> So if the release notes are accurate then acpi is only on for device enumeration, hence my problems. That must mean that the heat was either 1. coincidental 2. all in my head 3. something very bizarre. does anyone else have an Xseries ibm laptop and would like to confirm this? Thanks -sv From elanthis at awesomeplay.com Sun Aug 10 01:03:46 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 09 Aug 2003 21:03:46 -0400 Subject: acpi confusion, redux In-Reply-To: <1060476854.3938.9.camel@binkley> References: <1060476854.3938.9.camel@binkley> Message-ID: <1060477425.4747.15.camel@stargrazer.home.awesomeplay.com> On Sat, 2003-08-09 at 20:54, seth vidal wrote: > So if the release notes are accurate then acpi is only on for device > enumeration, hence my problems. That must mean that the heat was either > 1. coincidental > 2. all in my head > 3. something very bizarre. no, the heat is there because your laptop requires acpi power management - no power management, the laptop gets hots, and the battery life is very short. the laptop may even suffer permanent, severe damage if it runs too long without power management. more information from other x23 owners can be found here: http://www.linux-on-laptops.com/ibm.html > > does anyone else have an Xseries ibm laptop and would like to confirm > this? > > Thanks > -sv > > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From skvidal at phy.duke.edu Sun Aug 10 01:06:21 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 09 Aug 2003 21:06:21 -0400 Subject: acpi confusion, redux In-Reply-To: <1060477425.4747.15.camel@stargrazer.home.awesomeplay.com> References: <1060476854.3938.9.camel@binkley> <1060477425.4747.15.camel@stargrazer.home.awesomeplay.com> Message-ID: <1060477580.3938.14.camel@binkley> On Sat, 2003-08-09 at 21:03, Sean Middleditch wrote: > On Sat, 2003-08-09 at 20:54, seth vidal wrote: > > So if the release notes are accurate then acpi is only on for device > > enumeration, hence my problems. That must mean that the heat was either > > 1. coincidental > > 2. all in my head > > 3. something very bizarre. > > no, the heat is there because your laptop requires acpi power management > - no power management, the laptop gets hots, and the battery life is > very short. the laptop may even suffer permanent, severe damage if it > runs too long without power management. > It seems like apm is on for power mgmt. when I cat /proc/apm it's there. I got the part about acpi only being on for device enumeration from the red hat release notes for severn. -sv From elanthis at awesomeplay.com Sun Aug 10 01:23:52 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 09 Aug 2003 21:23:52 -0400 Subject: acpi confusion, redux In-Reply-To: <1060477580.3938.14.camel@binkley> References: <1060476854.3938.9.camel@binkley> <1060477425.4747.15.camel@stargrazer.home.awesomeplay.com> <1060477580.3938.14.camel@binkley> Message-ID: <1060478631.4747.18.camel@stargrazer.home.awesomeplay.com> On Sat, 2003-08-09 at 21:06, seth vidal wrote: > On Sat, 2003-08-09 at 21:03, Sean Middleditch wrote: > > On Sat, 2003-08-09 at 20:54, seth vidal wrote: > > > So if the release notes are accurate then acpi is only on for device > > > enumeration, hence my problems. That must mean that the heat was either > > > 1. coincidental > > > 2. all in my head > > > 3. something very bizarre. > > > > no, the heat is there because your laptop requires acpi power management > > - no power management, the laptop gets hots, and the battery life is > > very short. the laptop may even suffer permanent, severe damage if it > > runs too long without power management. > > > > It seems like apm is on for power mgmt. > > when I cat /proc/apm it's there. hmm, weird - i looked up your laptop (thinkpad x23, yes?) and I read it's only ACPI - perhaps the site I read was simply wrong. are you sure APM is actually working (i.e., it sees your battery, is handling throttling/power-control, etc.) ? also, did using acpi=off fix your sound card issue? > > I got the part about acpi only being on for device enumeration from the > red hat release notes for severn. > > -sv > > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From skvidal at phy.duke.edu Sun Aug 10 01:34:07 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 09 Aug 2003 21:34:07 -0400 Subject: acpi confusion, redux In-Reply-To: <1060478631.4747.18.camel@stargrazer.home.awesomeplay.com> References: <1060476854.3938.9.camel@binkley> <1060477425.4747.15.camel@stargrazer.home.awesomeplay.com> <1060477580.3938.14.camel@binkley> <1060478631.4747.18.camel@stargrazer.home.awesomeplay.com> Message-ID: <1060479247.3938.18.camel@binkley> > hmm, weird - i looked up your laptop (thinkpad x23, yes?) and I read > it's only ACPI - perhaps the site I read was simply wrong. are you sure > APM is actually working (i.e., it sees your battery, is handling > throttling/power-control, etc.) ? $ apm -m AC off-line, battery status high: 99% (141 min) looks like it. it's always been happy under 7.3, 8.0 and 9 > also, did using acpi=off fix your sound card issue? yes. -sv From sopwith at redhat.com Mon Aug 11 10:15:18 2003 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 11 Aug 2003 06:15:18 -0400 (EDT) Subject: Automated Testing In-Reply-To: <20030809104311.GG8712@shitake.truemesh.com> Message-ID: On Sat, 9 Aug 2003, Paul Nasrat wrote: > I was just wondering if anyone does any automated testing/continuous > integration with package trees and wondered what system setup you use. > > Theoretically you could pull rawhide, cvs ( cvsup for jbj ) and kick off > package builds and run some tests. We have an internal tool that does a mass rebuild test of the whole distribution every night, by creating a chroot build environment from the current package set, and then rebuilding all those packages inside that chroot. Logs are saved from the build failures, and it all goes up on a nice web page, etc. At some point I'd like to start making the results public. Once the web site gets sorted out, this will be easier to do. -- Elliot Humpty Dumpty was pushed. From florin at sgi.com Mon Aug 11 17:56:24 2003 From: florin at sgi.com (Florin Andrei) Date: 11 Aug 2003 10:56:24 -0700 Subject: GNOME 2.4 in Cambridge In-Reply-To: References: <1060367305.22092.193.camel@opus.phy.duke.edu> Message-ID: <1060624584.5778.3.camel@stantz.corp.sgi.com> On Fri, 2003-08-08 at 14:48, Jonathan Blandford wrote: > The big thing I can think of is that we now use ~/Desktop instead of > ~/.gnome-desktop for the users desktop by default. On one hand, that's a very small change. On the other... Great! In many ways - it's not a hidden directory anymore, it's the same dir used by KDE, etc. I love when things get compatible. :-) -- Florin Andrei "Never send a human to do a machine's job." - Agent Smith From johnsonm at redhat.com Mon Aug 11 18:41:54 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 11 Aug 2003 14:41:54 -0400 Subject: acpi confusion In-Reply-To: <1060470470.12013.9.camel@binkley>; from skvidal@phy.duke.edu on Sat, Aug 09, 2003 at 07:07:50PM -0400 References: <1060470470.12013.9.camel@binkley> Message-ID: <20030811144154.A15893@devserv.devel.redhat.com> On Sat, Aug 09, 2003 at 07:07:50PM -0400, seth vidal wrote: > So I have an ibm x23 laptop. nothing terribly fancy. With severn I > noticed that the sound played far too slowly. Meaning - when I played an > ogg it sounded like it was being played at the wrong speed if it were a > record. > > So I filed a bug about it b/c the sound worked under rhl 9 just fine. > The suggestion was to disable acpi and see if that fixed it. > > it did. the sound works as expected now. However, the laptop runs a lot > hotter than it used to. That sounds like a bug -- you should get APM if acpi is disabled; if you don't, then filing a bug would be good. > So I was wondering if someone could explain the acpi stuff in more > details. It was proposed to me by someone on #rhl-devel that maybe > someone here could give an uncensored summary of the acpi stuff in the > kernel and it's relative stability level, etc. Well, IRT relative stability, go to bugzilla and do a query for kernel bugs, and look to see how many of them go away when acpi=off is specified. A lot of the bits of ACPI don't really work under 2.4, including sleeping. The only reason we included it was for the configuration bits -- device enumeration. As an "APM replacement" it really isn't quite all there in 2.4. michaelkjohnson "He that composes himself is wiser than he that composes a book." Linux Application Development -- Ben Franklin http://people.redhat.com/johnsonm/lad/ From johnsonm at redhat.com Mon Aug 11 18:45:07 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 11 Aug 2003 14:45:07 -0400 Subject: acpi confusion In-Reply-To: <1060471435.4747.3.camel@stargrazer.home.awesomeplay.com>; from elanthis@awesomeplay.com on Sat, Aug 09, 2003 at 07:23:56PM -0400 References: <1060470470.12013.9.camel@binkley> <1060471435.4747.3.camel@stargrazer.home.awesomeplay.com> Message-ID: <20030811144507.B15893@devserv.devel.redhat.com> On Sat, Aug 09, 2003 at 07:23:56PM -0400, Sean Middleditch wrote: > acpi does a lot of things. the reason your laptop runs hot is that acpi > is required to keep it cool. acpi controls power levels, throttling, > etc., which you _really_ want on - i _hightly_ suggest you do not run > your laptop without it, or you risk severely damaging the hardware. You shouldn't. The ACPI standard requires that your hardware power off without damage to any components in case of ACPI software failure. Now, whether your system complies with that part of the standard may be another question, but it should be OK. Of course, if you are using APM then ACPI as a cooling mechanism is not relevant. 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 johnsonm at redhat.com Mon Aug 11 18:49:40 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 11 Aug 2003 14:49:40 -0400 Subject: acpi confusion, redux In-Reply-To: <1060476854.3938.9.camel@binkley>; from skvidal@phy.duke.edu on Sat, Aug 09, 2003 at 08:54:15PM -0400 References: <1060476854.3938.9.camel@binkley> Message-ID: <20030811144940.C15893@devserv.devel.redhat.com> On Sat, Aug 09, 2003 at 08:54:15PM -0400, seth vidal wrote: > So if the release notes are accurate then acpi is only on for device > enumeration, hence my problems. Sorry, enabled only for the purpose of device enumeration. Enabling it still has the effect of disabling APM. > That must mean that the heat was either > 1. coincidental > 2. all in my head > 3. something very bizarre. You probably want to load some of the ACPI modules: /lib/modules/2.4.21-20.1.2024.2.1.nptl/kernel/drivers/acpi/ac.o /lib/modules/2.4.21-20.1.2024.2.1.nptl/kernel/drivers/acpi/battery.o /lib/modules/2.4.21-20.1.2024.2.1.nptl/kernel/drivers/acpi/button.o /lib/modules/2.4.21-20.1.2024.2.1.nptl/kernel/drivers/acpi/fan.o /lib/modules/2.4.21-20.1.2024.2.1.nptl/kernel/drivers/acpi/processor.o /lib/modules/2.4.21-20.1.2024.2.1.nptl/kernel/drivers/acpi/thermal.o In particular, I would expect that fan and thermal would be important to you. 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 florin at sgi.com Mon Aug 11 20:42:32 2003 From: florin at sgi.com (Florin Andrei) Date: 11 Aug 2003 13:42:32 -0700 Subject: FSDB Message-ID: <1060634552.5778.20.camel@stantz.corp.sgi.com> "Hewlett-Packard, IBM, RSA Security, InstallShield Software, and Sun Microsystems are also involved in the File Signature Database (FSDB) effort. The repository will store metadata about individual files created by each of the vendors, such as the file's name, a ?born-on? date and its digital hash values." http://www.techworld.com/news/index.cfm?fuseaction=displaynews&NewsID=349 Any plans to do that with Red Hat as well? -- Florin Andrei "Never send a human to do a machine's job." - Agent Smith From skvidal at phy.duke.edu Mon Aug 11 20:49:23 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 11 Aug 2003 16:49:23 -0400 Subject: FSDB In-Reply-To: <1060634552.5778.20.camel@stantz.corp.sgi.com> References: <1060634552.5778.20.camel@stantz.corp.sgi.com> Message-ID: <1060634963.19823.4.camel@opus.phy.duke.edu> On Mon, 2003-08-11 at 16:42, Florin Andrei wrote: > "Hewlett-Packard, IBM, RSA Security, InstallShield Software, and Sun > Microsystems are also involved in the File Signature Database (FSDB) > effort. The repository will store metadata about individual files > created by each of the vendors, such as the file's name, a ?born-on? > date and its digital hash values." > > http://www.techworld.com/news/index.cfm?fuseaction=displaynews&NewsID=349 > > Any plans to do that with Red Hat as well? a neat mechanism to doing this would be: store the rpm package header from every package released by red hat on every ver, etc etc. then you'd be able to go through the header and compare it to what your ondisk system says to see which files have changed from the original. it'd be possible to write this in python using the rpmbindings to dump the file info out of a file from your system, compare it to a remote header and report back. it'd be a neat trick too. -sv From vader21 at imsa.edu Mon Aug 11 21:02:54 2003 From: vader21 at imsa.edu (Geoff Reedy) Date: Mon, 11 Aug 2003 16:02:54 -0500 Subject: FSDB In-Reply-To: <1060634552.5778.20.camel@stantz.corp.sgi.com>; from florin@sgi.com on Mon, Aug 11, 2003 at 01:42:32PM -0700 References: <1060634552.5778.20.camel@stantz.corp.sgi.com> Message-ID: <20030811160254.B24244@shell.imsa.edu> On Mon, Aug 11, 2003 at 01:42:32PM -0700, Florin Andrei said > "Hewlett-Packard, IBM, RSA Security, InstallShield Software, and Sun > Microsystems are also involved in the File Signature Database (FSDB) > effort. The repository will store metadata about individual files > created by each of the vendors, such as the file's name, a ?born-on? > date and its digital hash values." > > Any plans to do that with Red Hat as well? This sounds a lot like what can already be done with a command like rpm -Va. The rpm database already stores MD5 sums, file sizes, modification timestamps, file permissions, etc. for every installed package. Packages themselves can be GPG signed to guarantee authenticity. For added security a copy of the rpm database along with an rpm executable could be stored on some read only media and the verify happen from there. Geoff Reedy -- Geoffrey Reedy vader21 at imsa.edu From florin at sgi.com Mon Aug 11 21:14:11 2003 From: florin at sgi.com (Florin Andrei) Date: 11 Aug 2003 14:14:11 -0700 Subject: FSDB In-Reply-To: <20030811160254.B24244@shell.imsa.edu> References: <1060634552.5778.20.camel@stantz.corp.sgi.com> <20030811160254.B24244@shell.imsa.edu> Message-ID: <1060636451.5778.24.camel@stantz.corp.sgi.com> On Mon, 2003-08-11 at 14:02, Geoff Reedy wrote: > On Mon, Aug 11, 2003 at 01:42:32PM -0700, Florin Andrei said > > "Hewlett-Packard, IBM, RSA Security, InstallShield Software, and Sun > > Microsystems are also involved in the File Signature Database (FSDB) > > effort. The repository will store metadata about individual files > > created by each of the vendors, such as the file's name, a ?born-on? > > date and its digital hash values." > > > > Any plans to do that with Red Hat as well? > > This sounds a lot like what can already be done with a command like rpm -Va. Yes and no. Yes, it's the same idea. No, because with FSDB the signatures will be stored somewhere else, on a trusted site, not on the system itself (not even on the owner's network). Hence, even if your entire network gets compromised (unlikely, but still...) you still have a trusted signature database to compare with. -- Florin Andrei "Never send a human to do a machine's job." - Agent Smith From enrico.scholz at informatik.tu-chemnitz.de Mon Aug 11 21:51:44 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 11 Aug 2003 23:51:44 +0200 Subject: GNOME 2.4 in Cambridge In-Reply-To: <1060390705.3499.17.camel@binkley> (seth vidal's message of "08 Aug 2003 20:58:25 -0400") References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> <1060369420.22092.209.camel@opus.phy.duke.edu> <87ptjgncz8.fsf@kosh.ultra.csn.tu-chemnitz.de> <1060390705.3499.17.camel@binkley> Message-ID: <87oeyvdfrj.fsf@kosh.ultra.csn.tu-chemnitz.de> skvidal at phy.duke.edu (seth vidal) writes: >> What is with non-simultaneous logins? How can I prevent the >> .fonts.cache-regeneration-memorial-minute after logging in on >> another machine? > > hmm I've not experienced that. Can you describe it some more ~/.fonts.cache-1 is shared between machines whose font-directories might have different timestamps. When started on machine A, the ~/.fonts.cache-1 file can contain the timestamps of machine B and applications will regenerate the cache therefore. The same repeats on machine B because fonts.cache-1 has now the machine A timestamps. Now, the recursion starts at A again... Enrico From feliciano.matias at free.fr Mon Aug 11 23:07:31 2003 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: 12 Aug 2003 01:07:31 +0200 Subject: FSDB In-Reply-To: <1060636451.5778.24.camel@stantz.corp.sgi.com> References: <1060634552.5778.20.camel@stantz.corp.sgi.com> <20030811160254.B24244@shell.imsa.edu> <1060636451.5778.24.camel@stantz.corp.sgi.com> Message-ID: <1060643250.8549.24.camel@one.myworld> Le lun 11/08/2003 ? 23:14, Florin Andrei a ?crit : > On Mon, 2003-08-11 at 14:02, Geoff Reedy wrote: > > On Mon, Aug 11, 2003 at 01:42:32PM -0700, Florin Andrei said > > > "Hewlett-Packard, IBM, RSA Security, InstallShield Software, and Sun > > > Microsystems are also involved in the File Signature Database (FSDB) > > > effort. The repository will store metadata about individual files > > > created by each of the vendors, such as the file's name, a ?born-on? > > > date and its digital hash values." > > > > > > Any plans to do that with Red Hat as well? > > > > This sounds a lot like what can already be done with a command like rpm -Va. > > Yes and no. > > Yes, it's the same idea. > > No, because with FSDB the signatures will be stored somewhere else, on a > trusted site, not on the system itself (not even on the owner's > network). Hence, even if your entire network gets compromised (unlikely, > but still...) you still have a trusted signature database to compare > with. Authenticate the package : # rpm --checksig http://updates.redhat.com/9/en/os/i386/eog-2.2.0-2.i386.rpm http://updates.redhat.com/9/en/os/i386/eog-2.2.0-2.i386.rpm: (sha1) dsa sha1 md5 gpg OK Check the installation again the trusted package : # rpm -V -p http://updates.redhat.com/9/en/os/i386/eog-2.2.0-2.i386.rpm If the gpg key is not imported or the package have a bad signature : # rpm --checksig apt-0.5.5cnc6-fr1.i386.rpm apt-0.5.5cnc6-fr1.i386.rpm: (SHA1) DSA sha1 md5 (GPG) NOT OK (MISSING KEYS: GPG#e42d547b) -- F?liciano Matias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From otaylor at redhat.com Mon Aug 11 23:39:15 2003 From: otaylor at redhat.com (Owen Taylor) Date: 11 Aug 2003 19:39:15 -0400 Subject: GNOME 2.4 in Cambridge In-Reply-To: <87oeyvdfrj.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> <1060369420.22092.209.camel@opus.phy.duke.edu> <87ptjgncz8.fsf@kosh.ultra.csn.tu-chemnitz.de> <1060390705.3499.17.camel@binkley> <87oeyvdfrj.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1060645155.1981.264.camel@poincare.devel.redhat.com> On Mon, 2003-08-11 at 17:51, Enrico Scholz wrote: > skvidal at phy.duke.edu (seth vidal) writes: > > >> What is with non-simultaneous logins? How can I prevent the > >> .fonts.cache-regeneration-memorial-minute after logging in on > >> another machine? > > > > hmm I've not experienced that. Can you describe it some more > > ~/.fonts.cache-1 is shared between machines whose font-directories might have > different timestamps. When started on machine A, the ~/.fonts.cache-1 file > can contain the timestamps of machine B and applications will regenerate the > cache therefore. The same repeats on machine B because fonts.cache-1 has now > the machine A timestamps. Now, the recursion starts at A again... If you always run fc-cache on the parent directory (*) of any place you install fonts, then this shouldn't be an issue. ~/.fonts.cache-1 is only for font directories that don't have proper fonts.cache-1 files in them. Regards, Owen (*) Parent directory or directory itself depends on the details, but if you install stuff in /usr/share/fonts/foo it's better to run fc-cache /usr/share/fonts. From enrico.scholz at informatik.tu-chemnitz.de Tue Aug 12 01:05:52 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 12 Aug 2003 03:05:52 +0200 Subject: GNOME 2.4 in Cambridge In-Reply-To: <1060645155.1981.264.camel@poincare.devel.redhat.com> (Owen Taylor's message of "11 Aug 2003 19:39:15 -0400") References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> <1060369420.22092.209.camel@opus.phy.duke.edu> <87ptjgncz8.fsf@kosh.ultra.csn.tu-chemnitz.de> <1060390705.3499.17.camel@binkley> <87oeyvdfrj.fsf@kosh.ultra.csn.tu-chemnitz.de> <1060645155.1981.264.camel@poincare.devel.redhat.com> Message-ID: <87k79jd6rz.fsf@kosh.ultra.csn.tu-chemnitz.de> otaylor at redhat.com (Owen Taylor) writes: >> ~/.fonts.cache-1 is shared between machines whose font-directories >> might have different timestamps. When started on machine A, the >> ~/.fonts.cache-1 file can contain the timestamps of machine B and >> applications will regenerate the cache therefore. The same repeats >> on machine B because fonts.cache-1 has now the machine A >> timestamps. Now, the recursion starts at A again... > > If you always run fc-cache on the parent directory (*) of any place you > install fonts, then this shouldn't be an issue. This seems to be a bug in the %post scriptlets of the font-packages. E.g. /usr/share/fonts/zh_TW/TrueType/ contains | -rw-r--r-- 1 root root 8586 25. Jul 14:11 fonts.cache-1 | -rw-r--r-- 1 root root 945 28. Jul 21:26 fonts.dir When calling the questionable /usr/bin/redhat-update-gnome-font-install* programs manually, the timestamp of fonts.cache-1 does not change. But since the directory is changed by rpm's cpio, the local ~/.fonts.cache-1 will be updated. The same happens with /usr/X11R6/lib/X11/fonts/{75dpi,Type1,misc} which are having very old fonts.cache-1 files (Jan 08, 2003). Enrico From enrico.scholz at informatik.tu-chemnitz.de Tue Aug 12 01:28:00 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 12 Aug 2003 03:28:00 +0200 Subject: GNOME 2.4 in Cambridge References: <1060367305.22092.193.camel@opus.phy.duke.edu> <20030808145224.B17775@devserv.devel.redhat.com> <1060369420.22092.209.camel@opus.phy.duke.edu> <87ptjgncz8.fsf@kosh.ultra.csn.tu-chemnitz.de> <1060390705.3499.17.camel@binkley> <87oeyvdfrj.fsf@kosh.ultra.csn.tu-chemnitz.de> <1060645155.1981.264.camel@poincare.devel.redhat.com> <87k79jd6rz.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <87vft3ekbj.fsf@kosh.ultra.csn.tu-chemnitz.de> enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) writes: >>> ~/.fonts.cache-1 is shared between machines whose font-directories >>> might have different timestamps... >> >> If you always run fc-cache on the parent directory (*) of any place you >> install fonts, then this shouldn't be an issue. > > This seems to be a bug in the %post scriptlets of the font-packages. Hmm, I am wrong; the scriptlets are ok. Problem happens since something (XFree86 update, xfs startup?) triggered the regeneration of fonts.dir/scale without doing 'fc-cache' also. Enrico From pauln at truemesh.com Tue Aug 12 04:44:23 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 12 Aug 2003 05:44:23 +0100 Subject: FSDB In-Reply-To: <1060636451.5778.24.camel@stantz.corp.sgi.com> References: <1060634552.5778.20.camel@stantz.corp.sgi.com> <20030811160254.B24244@shell.imsa.edu> <1060636451.5778.24.camel@stantz.corp.sgi.com> Message-ID: <20030812044422.GA413@shitake.truemesh.com> On Mon, Aug 11, 2003 at 02:14:11PM -0700, Florin Andrei wrote: > On Mon, 2003-08-11 at 14:02, Geoff Reedy wrote: > > On Mon, Aug 11, 2003 at 01:42:32PM -0700, Florin Andrei said > > This sounds a lot like what can already be done with a command like rpm -Va. > > Yes and no. > > Yes, it's the same idea. > > No, because with FSDB the signatures will be stored somewhere else, on a > trusted site, not on the system itself (not even on the owner's > network). There already exists rpmdb-redhat, which you can use (possibly from readonly media): rpm -V --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ foo However a couple of caveats apply: 1) This doesn't seem to be kept in sync with errata, which I can understand as if you have it installed it's an extra package to update each time, I guess you could have rpmdb-redhat-errata too. 2) You can't trust it on your system, but no reason you can't have it from ro media as it's static 3) You don't know you can trust your rpm binary, so I guess a statically linked one on ro media along with the db would be useful 4) This possibly doesn't help with lkm/rootkits which may be able to do evil things intercepting your rpm calls. I don't know of any that do this automagically (quick google), but certainly a bootable cd with rpm, rpmdb-redhat pluss errata db entries would be simple to maintain. Paul From skvidal at phy.duke.edu Tue Aug 12 04:56:18 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 12 Aug 2003 00:56:18 -0400 Subject: FSDB In-Reply-To: <20030812044422.GA413@shitake.truemesh.com> References: <1060634552.5778.20.camel@stantz.corp.sgi.com> <20030811160254.B24244@shell.imsa.edu> <1060636451.5778.24.camel@stantz.corp.sgi.com> <20030812044422.GA413@shitake.truemesh.com> Message-ID: <1060664177.21235.22.camel@binkley> > There already exists rpmdb-redhat, which you can use (possibly from > readonly media): > > rpm -V --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ foo > > However a couple of caveats apply: > > 1) This doesn't seem to be kept in sync with errata, which I can > understand as if you have it installed it's an extra package to update > each time, I guess you could have rpmdb-redhat-errata too. > 2) You can't trust it on your system, but no reason you can't have it > from ro media as it's static > 3) You don't know you can trust your rpm binary, so I guess a statically > linked one on ro media along with the db would be useful > 4) This possibly doesn't help with lkm/rootkits which may be able to do > evil things intercepting your rpm calls. I don't know of any that do > this automagically (quick google), but certainly a bootable cd with rpm, > rpmdb-redhat pluss errata db entries would be simple to maintain. I think I mentioned this before but it would be a neat idea and it could help with this problem: have a db of the rpm headers for a long time back - this would be dramatically smaller than keeping the actual files - on average an rpm header is 1% the size of the rpm it is from. so then you could do the following: request that a check be done on package foobar on your system that would - get the epoch,ver,release,arch from your rpmdb for that package. look up the header for that package in the remote headers. Download it. Compare the files on your system to the file/md5sum list in the header it downloaded. If they don't match return the failures. If the remote header doesn't exist for the package you requested then name-epoch-ver-rel-arch then return a failure. That way the only trust you'd have in your local rpmdb is to tell you the ver of the package you have installed. And even then it wouldn't be trusted for the file list. seriously the functions that would need to be written to perform this are not hard: 1. md5sum of files on your disk 2. system acl checks of files on your disk 3. matching and downloading hdrs from remote everything else is interface and glue. I think this would be a great project to work on if someone had some time to devote to it. maybe if I get some time later I'll try to work on it. -sv From skvidal at phy.duke.edu Tue Aug 12 06:13:01 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 12 Aug 2003 02:13:01 -0400 Subject: acpi confusion In-Reply-To: <20030811144154.A15893@devserv.devel.redhat.com> References: <1060470470.12013.9.camel@binkley> <20030811144154.A15893@devserv.devel.redhat.com> Message-ID: <1060668781.21235.116.camel@binkley> > > > > it did. the sound works as expected now. However, the laptop runs a lot > > hotter than it used to. > > That sounds like a bug -- you should get APM if acpi is disabled; > if you don't, then filing a bug would be good. I filed a bug about the sound problem. I'm going to test with acpi=off again and see if apm is doing what I think it should be. > A lot of the bits of ACPI don't really work under 2.4, including sleeping. > The only reason we included it was for the configuration bits -- device > enumeration. As an "APM replacement" it really isn't quite all there in > 2.4. thanks. -sv From feliciano.matias at free.fr Tue Aug 12 10:27:59 2003 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: 12 Aug 2003 12:27:59 +0200 Subject: FSDB In-Reply-To: <1060664177.21235.22.camel@binkley> References: <1060634552.5778.20.camel@stantz.corp.sgi.com> <20030811160254.B24244@shell.imsa.edu> <1060636451.5778.24.camel@stantz.corp.sgi.com> <20030812044422.GA413@shitake.truemesh.com> <1060664177.21235.22.camel@binkley> Message-ID: <1060684077.17926.94.camel@one.myworld> Le mar 12/08/2003 ? 06:56, seth vidal a ?crit : > That way the only trust you'd have in your local rpmdb is to tell you About rpmdb, i have a question that you may find "stupid". Important : i am not a hacker and my english is poor. Why yum don't use something like rpmdb for the client part rather than .hdr files ? We can gain the power full of the rpm command line tool. It should be great if yum and redhat-config-packages get on together to store informations in rpmdb. So we will have all tools (rpm, yum, redhat-config-packages) that use the same informations. -- F?liciano Matias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Tue Aug 12 11:47:41 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 12 Aug 2003 07:47:41 -0400 Subject: FSDB In-Reply-To: <1060684077.17926.94.camel@one.myworld> References: <1060634552.5778.20.camel@stantz.corp.sgi.com> <20030811160254.B24244@shell.imsa.edu> <1060636451.5778.24.camel@stantz.corp.sgi.com> <20030812044422.GA413@shitake.truemesh.com> <1060664177.21235.22.camel@binkley> <1060684077.17926.94.camel@one.myworld> Message-ID: <1060688860.21235.163.camel@binkley> > Why yum don't use something like rpmdb for the client part rather than > .hdr files ? what do you mean? Yum uses the rpmdb and .hdr files for the information - it just depends on if the package is installed or not. -sv From feliciano.matias at free.fr Tue Aug 12 12:29:11 2003 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: 12 Aug 2003 14:29:11 +0200 Subject: FSDB In-Reply-To: <1060688860.21235.163.camel@binkley> References: <1060634552.5778.20.camel@stantz.corp.sgi.com> <20030811160254.B24244@shell.imsa.edu> <1060636451.5778.24.camel@stantz.corp.sgi.com> <20030812044422.GA413@shitake.truemesh.com> <1060664177.21235.22.camel@binkley> <1060684077.17926.94.camel@one.myworld> <1060688860.21235.163.camel@binkley> Message-ID: <1060691350.17926.110.camel@one.myworld> Le mar 12/08/2003 ? 13:47, seth vidal a ?crit : > > Why yum don't use something like rpmdb for the client part rather than > > .hdr files ? > > what do you mean? Yum uses the rpmdb and .hdr files for the information > - it just depends on if the package is installed or not. > Sorry. I am talking about rpmdb-redhat witch represent the whole distribution (/usr/lib/rpmdb/i386-redhat-linux/redhat) and not the rpm database in /var/lib/rpm that correspond only to packages currently installed. $ rpm -i kdegraphics-devel-3.1.2-4.i386.rpm error: Failed dependencies: kdegraphics = 7:3.1.2-4 is needed by kdegraphics-devel-3.1.2-4 Suggested resolutions: kdegraphics-3.1.2-4.i386.rpm <= this come from rpmdb-redhat. So rpm use /var/lib/rpm and rpmdb-redhat "like" yum use /var/lib/rpm and and .hdr files. rpmdb-redhat and .hdr files represent the whole distribution. > -sv > > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- F?liciano Matias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From icon at linux.duke.edu Tue Aug 12 14:43:22 2003 From: icon at linux.duke.edu (Konstantin Riabitsev) Date: 12 Aug 2003 10:43:22 -0400 Subject: USB storage hotplug code. Message-ID: <1060699402.19303.16.camel@hagrid.phy.duke.edu> Hey, all: I thought I'd share this little bit of code that I've written to handle usb-pen/thumbdrive devices that seem to be pretty popular these days (certainly beats floppies). It is pretty simplistic and will work in 99% of cases, by my estimates. Benefits: 1. Automatically create /dev/diskonkey pointing to the correct device. 2. Automatically create /mnt/diskonkey if missing. 3. Automatically add fstab entries if missing. 4. Automatically set ownership to the console user (if anyone is logged in -- if not, then the ownership will be set by the /mnt/diskonkey* rule in /etc/security/console.perms). Drawbacks: 1. Currently only supports one thumbdrive device at a time, though support for more should be easy to add (I only have one to play with. :)). 2. No way to tell nautilus to re-read /etc/fstab to add diskonkey to the list of mountable devices in rightclick->disks (they claim it's fixed in the newer version of nautilus, but that doesn't help. Currently sending killall -$(anysignal) nautilus will kill it, though theoretically a -HUP should tell it to reread the config). A workaround -- tell your users to plug in the device before they log in. 3. If partition info changes on the device, then things go screwey, as devlabel gets confused (e.g. someone deletes /dev/sda1 and decides to use the entire /dev/sda device instead). This rarely, if ever, happens. 4. This hasn't been overly extensively tested. Installation instructions are in the file itself. I would love to hear any feedback on this. Regards, -- Konstantin ("Icon") Riabitsev Duke Physics Sysadmin, RHCE -------------- next part -------------- A non-text attachment was scrubbed... Name: diskonkey Type: text/x-sh Size: 4227 bytes Desc: not available URL: From skvidal at phy.duke.edu Tue Aug 12 15:00:39 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 12 Aug 2003 11:00:39 -0400 Subject: FSDB In-Reply-To: <1060691350.17926.110.camel@one.myworld> References: <1060634552.5778.20.camel@stantz.corp.sgi.com> <20030811160254.B24244@shell.imsa.edu> <1060636451.5778.24.camel@stantz.corp.sgi.com> <20030812044422.GA413@shitake.truemesh.com> <1060664177.21235.22.camel@binkley> <1060684077.17926.94.camel@one.myworld> <1060688860.21235.163.camel@binkley> <1060691350.17926.110.camel@one.myworld> Message-ID: <1060700439.20564.57.camel@opus.phy.duke.edu> > Sorry. I am talking about rpmdb-redhat witch represent the whole > distribution (/usr/lib/rpmdb/i386-redhat-linux/redhat) and not the rpm > database in /var/lib/rpm that correspond only to packages currently > installed. > > $ rpm -i kdegraphics-devel-3.1.2-4.i386.rpm > error: Failed dependencies: > kdegraphics = 7:3.1.2-4 is needed by kdegraphics-devel-3.1.2-4 > Suggested resolutions: > kdegraphics-3.1.2-4.i386.rpm <= this come from rpmdb-redhat. > > So rpm use /var/lib/rpm and rpmdb-redhat "like" yum use /var/lib/rpm and > and .hdr files. Here are my reasons for not using rpmdb-redhat: 1. rpmdb-redhat only represents the stuff that came originally with the release, not the updates. 2. rpmdb-redhat is specific to red hat. Yum is not specific to red hat. In truth I use it on red hat systems but I didn't want to write a tool that would only work on one distribution. 3. rpmdb-redhat doesn't help with external repositories and that was one of the goals. -sv From garrett at redhat.com Tue Aug 12 20:28:44 2003 From: garrett at redhat.com (Garrett LeSage) Date: Tue, 12 Aug 2003 16:28:44 -0400 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) Message-ID: <3F394DFC.8040508@redhat.com> Hey all, I have recently posted a few new screenshots which demonstrate some of the latest updates in the "redhat-artwork" package. You can see screenshots at the following URLs: http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview.png http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-slate.png http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-purple.png http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-orange.png http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-green.png http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-gnome.png You can get the most recent version in Rawhide or out of CVS. As of this writing, the current Rawhide URL for redhat-artwork is: http://rawhide.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/redhat-artwork-0.78-1.i386.rpm Brief overview of a few changes since the Red Hat Linux 9 time frame: Icons ===== * Reworked the entire icon set, now generated by XML configs and icon sheets * Multiple icon sizes are now available (not fully complete yet) * All icons are now pixel optimized per size * New mimetype file icons * Updated stock icons * Initial support for KDE stock icons (actions) now available (size issues need to be sorted out, so it's not working quite yet) * Gnome panel icons are 36x36 instead of 24x24 (for the time being, at least...) Window Decorations ================ * Window frame decorations have a new style * Metacity theme implemented * KDE's KWin theme needs to be updated still Widgets ======= * A few tweaks for the GTK+ theme configuration. * Additional color schemes are now available for Bluecurve Access these additional themes by selecting "desktop menu > preferences > theme" from the panel, hitting the "Details..." button, and in the "Controls" tab, select "Bluecurve-Slate" or some other Bluecurve color scheme. Of course, there is still work to be done. Please file bugs, help out, and/or provide feedback on the package. Thanks, Garrett From otaylor at redhat.com Tue Aug 12 20:49:14 2003 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 12 Aug 2003 16:49:14 -0400 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <3F394DFC.8040508@redhat.com> References: <3F394DFC.8040508@redhat.com> Message-ID: <1060721354.11725.1.camel@poincare.devel.redhat.com> On Tue, 2003-08-12 at 16:28, Garrett LeSage wrote: > Hey all, > > I have recently posted a few new screenshots which demonstrate some of > the latest updates in the "redhat-artwork" package. > > You can see screenshots at the following URLs: > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview.png > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-slate.png > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-purple.png > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-orange.png > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-green.png > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-gnome.png > > Window Decorations > ================ > > * Window frame decorations have a new style > * Metacity theme implemented > * KDE's KWin theme needs to be updated still I'm a little concerend by the visually smaller window buttons. I think it's likely that people will think they have to click inside the small button. Which makes it a harder, more precision operation. The new icons and color schemes look nice. Regards, Owen From alikins at redhat.com Wed Aug 13 03:19:44 2003 From: alikins at redhat.com (Adrian Likins) Date: Tue, 12 Aug 2003 23:19:44 -0400 Subject: up2date for testing (with apt/yum/dir repo support) Message-ID: <20030812231944.E27241@redhat.com> http://people.redhat.com/~alikins/up2date/severn/ New up2date for testing. Somewhat notable new feature of support for 3rd party yum and apt repos. See /etc/sysconfig/rhn/sources for info on configuring them (docs to come). In addition to the apt/yum repos, it also now supports using a local dir of rpms as a "repo" Feedback appreciated (usually ;-> ) (sorry for crosspost to rhl-beta) Adrian From elanthis at awesomeplay.com Wed Aug 13 03:39:56 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 12 Aug 2003 23:39:56 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <20030812231944.E27241@redhat.com> References: <20030812231944.E27241@redhat.com> Message-ID: <1060745996.5003.1.camel@stargrazer.home.awesomeplay.com> On Tue, 2003-08-12 at 23:19, Adrian Likins wrote: > http://people.redhat.com/~alikins/up2date/severn/ > > New up2date for testing. Somewhat notable new > feature of support for 3rd party yum and apt > repos. See /etc/sysconfig/rhn/sources for info > on configuring them (docs to come). > > In addition to the apt/yum repos, it also > now supports using a local dir of rpms as > a "repo" > > Feedback appreciated (usually ;-> ) Hmm, it kept telling me that I had no channel for the Redhat release I have. (Rawhide.) After uninstalling and reinstalling up2date, I know get this running any rhn/up2date apps: [root at stargrazer rhn]# /usr/sbin/rhn_register Traceback (most recent call last): File "/usr/sbin/rhn_register", line 22, in ? from up2date_client import repoDirector File "repoDirector.py", line 12, in ? File "rhnChannel.py", line 129, in getChannels AttributeError: 'NoneType' object has no attribute 'get' > > > (sorry for crosspost to rhl-beta) > Adrian > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From alikins at redhat.com Wed Aug 13 04:04:06 2003 From: alikins at redhat.com (Adrian Likins) Date: Wed, 13 Aug 2003 00:04:06 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <1060745996.5003.1.camel@stargrazer.home.awesomeplay.com>; from elanthis@awesomeplay.com on Tue, Aug 12, 2003 at 11:39:56PM -0400 References: <20030812231944.E27241@redhat.com> <1060745996.5003.1.camel@stargrazer.home.awesomeplay.com> Message-ID: <20030813000406.F27241@redhat.com> On Tue, Aug 12, 2003 at 11:39:56PM -0400, Sean Middleditch wrote: > On Tue, 2003-08-12 at 23:19, Adrian Likins wrote: > > http://people.redhat.com/~alikins/up2date/severn/ > > > > New up2date for testing. Somewhat notable new > > feature of support for 3rd party yum and apt > > repos. See /etc/sysconfig/rhn/sources for info > > on configuring them (docs to come). > > > > In addition to the apt/yum repos, it also > > now supports using a local dir of rpms as > > a "repo" > > > > Feedback appreciated (usually ;-> ) > > Hmm, it kept telling me that I had no channel for the Redhat release I > have. (Rawhide.) > > After uninstalling and reinstalling up2date, I know get this running any > rhn/up2date apps: > > [root at stargrazer rhn]# /usr/sbin/rhn_register > Traceback (most recent call last): > File "/usr/sbin/rhn_register", line 22, in ? > from up2date_client import repoDirector > File "repoDirector.py", line 12, in ? > File "rhnChannel.py", line 129, in getChannels > AttributeError: 'NoneType' object has no attribute 'get' Oh yeah, thats it's subtle way of saying the RHn login failed. I'll try to clean that up for the next version. But in general, you still need to be registered with RHN (demo accounts or whatever), so rawhide might not have a channel atm. Adrian From kewley at cns.caltech.edu Wed Aug 13 04:16:39 2003 From: kewley at cns.caltech.edu (David Kewley) Date: Tue, 12 Aug 2003 21:16:39 -0700 Subject: getting new driver into kernel, boot.iso In-Reply-To: <200308080842.35299.kewley@cns.caltech.edu> References: <200308072212.18109.kewley@cns.caltech.edu> <20030808110123.A15668@devserv.devel.redhat.com> <200308080842.35299.kewley@cns.caltech.edu> Message-ID: <200308122116.39182.kewley@cns.caltech.edu> I got the updated sk98lin (version 6.14) driver disk working, and successfully used it along with a modified boot.iso CD to do a network kickstart using the on-board ethernet chip. I'll be writing up what I did, and posting the writeup and the driver disk files to the web soon. Thanks again, Michael, for the pointer to Doug Ledford's driver disk kit. I haven't contacted SysKonnect yet, but I'll be doing that, to urge them to submit their driver for inclusion in the kernel, and to offer them the driver disks I made, and the method for making them in the future. I wanted to reply to a few of Dave Jones' comments: Dave Jones wrote on Friday 08 August 2003 09:01: > (click the disk icon 8-) http://www.syskonnect.com/syskonnect/support/driver/zip/linux/sk98lin_2.4.21_patch.gz Yeah, I know. :) The problem is, the previous version of the patch (for kernel 2.4.20) didn't apply cleanly to the RH kernel, and I didn't feel like struggling through the minutae of making it fit. > From a quick skim of the code, it seems largely made up of gratuitous > whitespace changes, which makes it hard to see the real changes. > > Lots of changing comments from.. > > /* foo */ > > to > /* > ** foo > */ > > Seems someone got a new text editor with macros for xmas.. Thanks for taking a look at the patch, but I beg to differ. :) There are a fair number of whitespace changes, but there are (by my eye) lots more logic changes, plus many added comments and a fair number of non-whitespace reformats. I actually saw very few of the comment reformats of the type you show above. Of course, this all matters little. :) I guess my point is that it seems to me the patch is not trivial (which is what your comment suggested to me). It weighs in at nearly 18000 lines and 1/2 MB, and I'd guess around 1/4 of that is substantive. > Lots of hard coded values changed to #defines - a good thing. > Some new cards supported - also a good thing. I didn't notice the hard-coded values changing, but yes, there are lots of #defines added or changed. And the key thing to me, I think, is the new card support. > That aside ISTR someone mentioning that this update backs out > some stuff that has been fixed in mainline since they last did a push, > so that needs fixing, Huh, that could be, I don't know the mainline history of changes to this driver (and didn't attempt to look them up). I see that there's one RH patch in 2.4.21 (rawhide) that affects sk98lin slightly, in linux-2.4.1-compilefailure.patch. It'd be useful for someone who knows the history of sk98lin to give SK feedback about what needs patching... > as do the memory leaks they introduce in their > ioctls. They may also be other problems, but thats all I picked up > from a quick 2 minute skim of the diff. OK, I'll take your word for it. I'm way too inexperienced to judge that, even in my 30-minute skim of the diff. :) > Fishing out the good bits of the patch is a worthwhile thing for > someone to do, but its not a 10 minute job. I imagine so. What would be the most useful way for this to happen? Who would best do this? The SK developers? (Then I guess they'd need to know what was fixed in the mainline kernel version of sk98lin.) Or Alan or a kernel net driver hacker? David From elanthis at awesomeplay.com Wed Aug 13 04:27:43 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 13 Aug 2003 00:27:43 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <20030813000406.F27241@redhat.com> References: <20030812231944.E27241@redhat.com> <1060745996.5003.1.camel@stargrazer.home.awesomeplay.com> <20030813000406.F27241@redhat.com> Message-ID: <1060748863.5003.3.camel@stargrazer.home.awesomeplay.com> On Wed, 2003-08-13 at 00:04, Adrian Likins wrote: > Oh yeah, thats it's subtle way of saying > the RHn login failed. I'll try to clean that up for > the next version. > > But in general, you still need to be > registered with RHN (demo accounts or whatever), > so rawhide might not have a channel atm. Hmm, so there's no way to play with this on this system, then? Or is there a way to fool up2date into thinking this is RH 9 without mucking up the rest of the system? > > Adrian > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Sean Middleditch AwesomePlay Productions, Inc. From skvidal at phy.duke.edu Wed Aug 13 04:33:18 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 13 Aug 2003 00:33:18 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <1060748863.5003.3.camel@stargrazer.home.awesomeplay.com> References: <20030812231944.E27241@redhat.com> <1060745996.5003.1.camel@stargrazer.home.awesomeplay.com> <20030813000406.F27241@redhat.com> <1060748863.5003.3.camel@stargrazer.home.awesomeplay.com> Message-ID: <1060749197.3772.11.camel@binkley> On Wed, 2003-08-13 at 00:27, Sean Middleditch wrote: > > Hmm, so there's no way to play with this on this system, then? Or is > there a way to fool up2date into thinking this is RH 9 without mucking > up the rest of the system? downgrade to the older up2date register for a demo account upgrade to the new up2date setup a repo done; -sv From icon at linux.duke.edu Wed Aug 13 05:11:55 2003 From: icon at linux.duke.edu (Konstantin Riabitsev) Date: Wed, 13 Aug 2003 01:11:55 -0400 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <3F394DFC.8040508@redhat.com> References: <3F394DFC.8040508@redhat.com> Message-ID: <1060751514.4740.4.camel@localhost.localdomain> On Tue, 2003-08-12 at 16:28, Garrett LeSage wrote: > Hey all, > > I have recently posted a few new screenshots which demonstrate some of > the latest updates in the "redhat-artwork" package. Looks pretty spiffing! Something I've noticed, though -- maximized inactive windows blend a little too well with the foobar. E.g. observe: http://www.linux.duke.edu/~icon/sshots/garrett-bluecurve-new.png Is that intentional? -icon From alikins at redhat.com Wed Aug 13 05:23:45 2003 From: alikins at redhat.com (Adrian Likins) Date: Wed, 13 Aug 2003 01:23:45 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <1060748863.5003.3.camel@stargrazer.home.awesomeplay.com>; from elanthis@awesomeplay.com on Wed, Aug 13, 2003 at 12:27:43AM -0400 References: <20030812231944.E27241@redhat.com> <1060745996.5003.1.camel@stargrazer.home.awesomeplay.com> <20030813000406.F27241@redhat.com> <1060748863.5003.3.camel@stargrazer.home.awesomeplay.com> Message-ID: <20030813012345.G27241@redhat.com> On Wed, Aug 13, 2003 at 12:27:43AM -0400, Sean Middleditch wrote: > On Wed, 2003-08-13 at 00:04, Adrian Likins wrote: > > > Oh yeah, thats it's subtle way of saying > > the RHn login failed. I'll try to clean that up for > > the next version. > > > > But in general, you still need to be > > registered with RHN (demo accounts or whatever), > > so rawhide might not have a channel atm. > > Hmm, so there's no way to play with this on this system, then? Or is > there a way to fool up2date into thinking this is RH 9 without mucking > up the rest of the system? > New packages (3.9.6) up that should fix the registration problems. Adrian From kjb at dds.nl Wed Aug 13 07:43:33 2003 From: kjb at dds.nl (Klaasjan Brand) Date: 13 Aug 2003 09:43:33 +0200 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <1060721354.11725.1.camel@poincare.devel.redhat.com> References: <3F394DFC.8040508@redhat.com> <1060721354.11725.1.camel@poincare.devel.redhat.com> Message-ID: <1060760612.15779.21.camel@topicus6> On Tue, 2003-08-12 at 22:49, Owen Taylor wrote: > > > I'm a little concerend by the visually smaller window buttons. I think > it's likely that people will think they have to click inside the small > button. Which makes it a harder, more precision operation. > > The new icons and color schemes look nice. I'm no user interface authority either, but that was exactly my first concern when I saw that. I'm also not totally impressed by the menu fonts, but since that's a preference it's no problem. Is the bug which mis-renders the Luxi fonts in severn fixed yet? -- Klaasjan Brand From pmatilai at welho.com Wed Aug 13 08:13:50 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Wed, 13 Aug 2003 11:13:50 +0300 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <20030812231944.E27241@redhat.com> References: <20030812231944.E27241@redhat.com> Message-ID: <1060762430.3f39f33e50f03@webmail.welho.com> Quoting Adrian Likins : > > http://people.redhat.com/~alikins/up2date/severn/ > > New up2date for testing. Somewhat notable new > feature of support for 3rd party yum and apt > repos. See /etc/sysconfig/rhn/sources for info > on configuring them (docs to come). Whoa.. cool! :) Had a quick look over aptRepo.py, a couple of comments on findings in there: 1) "# assuming this is always bz2?" - yes, it's always bz2. There can be an uncompressed version of the file as well but then who the heck wants to download an uncompressed file when the .bz2 file is there... legacy stuff. 2) "# FIXME .." comment wrt the repository layout and finding the package - yes there are basically two kinds of repositories, "traditional" and "flat", of which flat one is what almost everybody uses nowadays. Supporting to trad layout where RPMS and SRPMS are on a different directory level would be nice but I wouldn't consider lack of it as a showstopper at all. > > In addition to the apt/yum repos, it also > now supports using a local dir of rpms as > a "repo" This is really nice one! -- - Panu - From johnsonm at redhat.com Wed Aug 13 13:12:53 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 13 Aug 2003 09:12:53 -0400 Subject: getting new driver into kernel, boot.iso In-Reply-To: <200308122116.39182.kewley@cns.caltech.edu>; from kewley@cns.caltech.edu on Tue, Aug 12, 2003 at 09:16:39PM -0700 References: <200308072212.18109.kewley@cns.caltech.edu> <20030808110123.A15668@devserv.devel.redhat.com> <200308080842.35299.kewley@cns.caltech.edu> <200308122116.39182.kewley@cns.caltech.edu> Message-ID: <20030813091253.B12652@devserv.devel.redhat.com> On Tue, Aug 12, 2003 at 09:16:39PM -0700, David Kewley wrote: > I got the updated sk98lin (version 6.14) driver disk working, and > successfully used it along with a modified boot.iso CD to do a network > kickstart using the on-board ethernet chip. I'll be writing up what I did, > and posting the writeup and the driver disk files to the web soon. Thanks > again, Michael, for the pointer to Doug Ledford's driver disk kit. NP :-) > I haven't contacted SysKonnect yet, but I'll be doing that, to urge them to > submit their driver for inclusion in the kernel, and to offer them the > driver disks I made, and the method for making them in the future. In particular, they need to incorporate into their driver upstream bugfixes, then submit it upstream... > I wanted to reply to a few of Dave Jones' comments: > > Dave Jones wrote on Friday 08 August 2003 09:01: > > (click the disk icon 8-) Dave was telling me where to find it when it didn't occur to me that the icon was clickable... > > That aside ISTR someone mentioning that this update backs out > > some stuff that has been fixed in mainline since they last did a push, > > so that needs fixing, > > Huh, that could be, I don't know the mainline history of changes to this > driver (and didn't attempt to look them up). I see that there's one RH > patch in 2.4.21 (rawhide) that affects sk98lin slightly, in > linux-2.4.1-compilefailure.patch. > > It'd be useful for someone who knows the history of sk98lin to give SK > feedback about what needs patching... That's really their job -- to follow the changes made upstream and make sure that they keep their updates in sync. > > Fishing out the good bits of the patch is a worthwhile thing for > > someone to do, but its not a 10 minute job. > > I imagine so. What would be the most useful way for this to happen? Who > would best do this? The SK developers? Absolutely. No other solution scales. There are lots of drivers out there, and for someone else besides the driver author to be responsible for this just doesn't work in practice. > (Then I guess they'd need to know > what was fixed in the mainline kernel version of sk98lin.) And they will have in their internal version control all the versions of sk98lin they have worked on; they should diff the version they previously submitted against what is upstream, and intelligently apply that patch to their sources. 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 kaboom at gatech.edu Wed Aug 13 13:52:57 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 13 Aug 2003 07:52:57 -0600 (MDT) Subject: APT, Yum and Red Carpet In-Reply-To: <200308121710.h7CHAwD17778@devserv.devel.redhat.com> References: <200308121710.h7CHAwD17778@devserv.devel.redhat.com> Message-ID: On Tue, 12 Aug 2003, Alan Cox wrote: > Its also not just a case of "root" either, on a really locked down system > with something like SELinux or RSBAC installed you not only don't give > people root you make it impossible for anything to create executables or > any scripts for shells to be run unless they have been "blessed" by some > sysadmin controlled tool. That turns "I got this cool screensaver.." into > "I got this cool screensaver but it wont run" which allows the sysadmin to > explain to the staff member why not and why that wont be changing. Speaking of which, is there any interest in incorporating RSBAC (preferably) or SELinux into RHLP, long-term? later, chris From pauln at truemesh.com Wed Aug 13 14:05:52 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Wed, 13 Aug 2003 15:05:52 +0100 Subject: APT, Yum and Red Carpet In-Reply-To: References: <200308121710.h7CHAwD17778@devserv.devel.redhat.com> Message-ID: <20030813140551.GS3676@shitake.truemesh.com> On Wed, Aug 13, 2003 at 07:52:57AM -0600, Chris Ricker wrote: > > Speaking of which, is there any interest in incorporating RSBAC (preferably) > or SELinux into RHLP, long-term? SELinux architecture has been merged in 2.6.0-test3, so I imagine that Cambridge++ will have that SELinux in it. It seems to be compiled into Arjans 2.6 kernels but I haven't played with it yet. Paul From mike at netlyncs.com Wed Aug 13 14:22:42 2003 From: mike at netlyncs.com (Mike Chambers) Date: Wed, 13 Aug 2003 09:22:42 -0500 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <20030813012345.G27241@redhat.com> References: <20030812231944.E27241@redhat.com> <1060745996.5003.1.camel@stargrazer.home.awesomeplay.com> <20030813000406.F27241@redhat.com> <1060748863.5003.3.camel@stargrazer.home.awesomeplay.com> <20030813012345.G27241@redhat.com> Message-ID: <1060784562.2291.14.camel@bart.netlyncs.com> On Wed, 2003-08-13 at 00:23, Adrian Likins wrote: > New packages (3.9.6) up that should fix the registration > problems. Yep, that fixed the registration problem and so far so good. About to test using a yum repository on fedora and a local dir that mirrors rawhide. -- Mike Chambers Madisonville, KY "The road to to success is always under construction!" From alikins at redhat.com Wed Aug 13 16:04:19 2003 From: alikins at redhat.com (Adrian Likins) Date: Wed, 13 Aug 2003 12:04:19 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <1060762430.3f39f33e50f03@webmail.welho.com>; from pmatilai@welho.com on Wed, Aug 13, 2003 at 11:13:50AM +0300 References: <20030812231944.E27241@redhat.com> <1060762430.3f39f33e50f03@webmail.welho.com> Message-ID: <20030813120419.D4548@redhat.com> On Wed, Aug 13, 2003 at 11:13:50AM +0300, Panu Matilainen wrote: > Quoting Adrian Likins : > > > > > http://people.redhat.com/~alikins/up2date/severn/ > > > > New up2date for testing. Somewhat notable new > > feature of support for 3rd party yum and apt > > repos. See /etc/sysconfig/rhn/sources for info > > on configuring them (docs to come). > > Whoa.. cool! :) Had a quick look over aptRepo.py, a couple of comments on > findings in there: > 1) "# assuming this is always bz2?" - yes, it's always bz2. There can be an > uncompressed version of the file as well but then who the heck wants to download > an uncompressed file when the .bz2 file is there... legacy stuff. fallback to gz/uncompressed should be easy enough, I'll refresh the TODO list > 2) "# FIXME .." comment wrt the repository layout and finding the package - > yes there are basically two kinds of repositories, "traditional" and "flat", > of which flat one is what almost everybody uses nowadays. Supporting to trad > layout where RPMS and SRPMS are on a different directory level would be nice but > I wouldn't consider lack of it as a showstopper at all. > On the TODO list... Next step is to grab base/release and use it to find the pkglists, and to verify there md5sums. Also poplate a more useful channel description and other details. That should help cover most of the potential layouts. Adrian From seanlkml at rogers.com Wed Aug 13 17:32:05 2003 From: seanlkml at rogers.com (Sean Estabrooks) Date: Wed, 13 Aug 2003 13:32:05 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <20030812231944.E27241@redhat.com> References: <20030812231944.E27241@redhat.com> Message-ID: <20030813133205.3953ef48.seanlkml@rogers.com> On Tue, 12 Aug 2003 23:19:44 -0400 Adrian Likins wrote: > > http://people.redhat.com/~alikins/up2date/severn/ > > New up2date for testing. Somewhat notable new > feature of support for 3rd party yum and apt > repos. See /etc/sysconfig/rhn/sources for info > on configuring them (docs to come). > > In addition to the apt/yum repos, it also > now supports using a local dir of rpms as > a "repo" > > Feedback appreciated (usually ;-> ) > > Must one register with redhat to use up2date against a local repo? One problem i had was caused by an old systemid file from the 7.3 era. No matter what i typed i got the error shown below. It would be nice if rhn_register had a --force option or even better ask if it should ignore or use the the current systemid file. Cheers, Sean # rhn_register Traceback (most recent call last): File "/usr/sbin/rhn_register", line 25, in ? from up2date_client import repoDirector File "repoDirector.py", line 12, in ? File "rhnChannel.py", line 128, in getChannels File "up2dateAuth.py", line 150, in getLoginInfo File "up2dateAuth.py", line 104, in login File "up2dateAuth.py", line 60, in maybeUpdateVersion up2date_client.up2dateErrors.CommunicationError: Error communicating with server. The message was: Error Message: Please run rhn_register (or up2date --register on Red Hat Linux 8.0) as root on this client Error Class Code: 9 Error Class Info: Invalid Server Certificate. Explanation: An error has occurred while processing your request. If this problem persists please enter a bug report at bugzilla.redhat.com. If you choose to submit the bug report, please be sure to include details of what you were trying to do when this error occurred and details on how to reproduce this problem. Cheers, Sean From alikins at redhat.com Wed Aug 13 18:30:34 2003 From: alikins at redhat.com (Adrian Likins) Date: Wed, 13 Aug 2003 14:30:34 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <20030813133205.3953ef48.seanlkml@rogers.com>; from seanlkml@rogers.com on Wed, Aug 13, 2003 at 01:32:05PM -0400 References: <20030812231944.E27241@redhat.com> <20030813133205.3953ef48.seanlkml@rogers.com> Message-ID: <20030813143034.B5175@redhat.com> On Wed, Aug 13, 2003 at 01:32:05PM -0400, Sean Estabrooks wrote: > On Tue, 12 Aug 2003 23:19:44 -0400 > Adrian Likins wrote: > > > > > http://people.redhat.com/~alikins/up2date/severn/ > > > > New up2date for testing. Somewhat notable new > > feature of support for 3rd party yum and apt > > repos. See /etc/sysconfig/rhn/sources for info > > on configuring them (docs to come). > > > > In addition to the apt/yum repos, it also > > now supports using a local dir of rpms as > > a "repo" > > > > Feedback appreciated (usually ;-> ) > > > > > > Must one register with redhat to use up2date against a local repo? > Yes. At the moment at least, though I don't have any plans to change that at this point. > One problem i had was caused by an old systemid file from the 7.3 era. > No matter what i typed i got the error shown below. It would be nice > if rhn_register had a --force option or even better ask if it should > ignore or use the the current systemid file. > `up2date --register` or `rhn_register --register` will "force" a reregister. Adrian From garrett at redhat.com Wed Aug 13 18:32:45 2003 From: garrett at redhat.com (Garrett LeSage) Date: Wed, 13 Aug 2003 14:32:45 -0400 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <1060760612.15779.21.camel@topicus6> References: <3F394DFC.8040508@redhat.com> <1060721354.11725.1.camel@poincare.devel.redhat.com> <1060760612.15779.21.camel@topicus6> Message-ID: <3F3A844D.9060103@redhat.com> Klaasjan Brand wrote: >On Tue, 2003-08-12 at 22:49, Owen Taylor wrote: > > > >> >> >>I'm a little concerend by the visually smaller window buttons. I think >>it's likely that people will think they have to click inside the small >>button. Which makes it a harder, more precision operation. >> >>The new icons and color schemes look nice. >> >> > >I'm no user interface authority either, but that was exactly my first >concern when I saw that. > The difference in size is only by a pixel (on all sides). They are inset by two, but the buttons have a 1-pixel clickable area on the outside of each. The reason why there are two pixels from the border to the button is because it looks bad otherwise. Bluecurve's new buttons do look more like buttons now, a bit more consistent with the rest of the Bluecurve widget themes (with the exception of being slightly rounded). I have been thinking about changing things in the widget theme also, but that requires a bit of code modification, so it's not as easy to do. I know that the buttons in question are actually quite larger than the ones on Mac OS X, especially when you consider the utility palettes (which also have no title because the "title" bar is so small). Also, the size of the window decoration buttons, as pictured in the screen shots, is approximately the same as scrollbar buttons, and I haven't seen a single person complain about the inability to click those. In addition, the whole title bar scales depending on the font size. >I'm also not totally impressed by the menu >fonts, but since that's a preference it's no problem. > > Actually, I did not change the default font preferences. The ones in the screen shots are set by my preference. They're the Bitstream fonts from the GNOME project, set a little smaller than most people typically would have their fonts. Garrett From seanlkml at rogers.com Wed Aug 13 18:37:12 2003 From: seanlkml at rogers.com (Sean Estabrooks) Date: Wed, 13 Aug 2003 14:37:12 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <20030813143034.B5175@redhat.com> References: <20030812231944.E27241@redhat.com> <20030813133205.3953ef48.seanlkml@rogers.com> <20030813143034.B5175@redhat.com> Message-ID: <20030813143712.2bafb893.seanlkml@rogers.com> > > Must one register with redhat to use up2date against a local repo? > > > Yes. At the moment at least, though I don't have any > plans to change that at this point. > fair enough. > > One problem i had was caused by an old systemid file from the 7.3 era. > > No matter what i typed i got the error shown below. It would be nice > > if rhn_register had a --force option or even better ask if it should > > ignore or use the the current systemid file. > > > `up2date --register` or `rhn_register --register` will > "force" a reregister. > Isn't rhn_register --register a bit redundant? ;o) Anyway after restoring the _old_ systemid file the problem still existed: # up2date --register Traceback (most recent call last): File "/usr/sbin/up2date", line 25, in ? from up2date_client import repoDirector File "repoDirector.py", line 12, in ? File "rhnChannel.py", line 128, in getChannels File "up2dateAuth.py", line 150, in getLoginInfo File "up2dateAuth.py", line 104, in login File "up2dateAuth.py", line 60, in maybeUpdateVersion up2date_client.up2dateErrors.CommunicationError: Error communicating with server. The message was: Error Message: Please run rhn_register (or up2date --register on Red Hat Linux 8.0) as root on this client Error Class Code: 9 Error Class Info: Invalid Server Certificate. Explanation: An error has occurred while processing your request. If this problem persists please enter a bug report at bugzilla.redhat.com. If you choose to submit the bug report, please be sure to include details of what you were trying to do when this error occurred and details on how to reproduce this problem. Thanks for the reply Adrian, Sean From alikins at redhat.com Wed Aug 13 18:49:20 2003 From: alikins at redhat.com (Adrian Likins) Date: Wed, 13 Aug 2003 14:49:20 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <20030813143712.2bafb893.seanlkml@rogers.com>; from seanlkml@rogers.com on Wed, Aug 13, 2003 at 02:37:12PM -0400 References: <20030812231944.E27241@redhat.com> <20030813133205.3953ef48.seanlkml@rogers.com> <20030813143034.B5175@redhat.com> <20030813143712.2bafb893.seanlkml@rogers.com> Message-ID: <20030813144920.C5175@redhat.com> On Wed, Aug 13, 2003 at 02:37:12PM -0400, Sean Estabrooks wrote: > > > One problem i had was caused by an old systemid file from the 7.3 era. > > > No matter what i typed i got the error shown below. It would be nice > > > if rhn_register had a --force option or even better ask if it should > > > ignore or use the the current systemid file. > > > > > `up2date --register` or `rhn_register --register` will > > "force" a reregister. > > > > Isn't rhn_register --register a bit redundant? ;o) > It is. But rhn_register is just a symlink to up2date these days, so... > Anyway after restoring the _old_ systemid file the problem still existed: > > Hmm, indeed. Looks like the refactor may have broken forced reregistering. I'll take a look and see what I can figure out. > # up2date --register > Traceback (most recent call last): > File "/usr/sbin/up2date", line 25, in ? > from up2date_client import repoDirector > File "repoDirector.py", line 12, in ? > File "rhnChannel.py", line 128, in getChannels > File "up2dateAuth.py", line 150, in getLoginInfo > File "up2dateAuth.py", line 104, in login > File "up2dateAuth.py", line 60, in maybeUpdateVersion > up2date_client.up2dateErrors.CommunicationError: Error communicating with server. The message was: Adrian From johnsonm at redhat.com Wed Aug 13 19:15:26 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 13 Aug 2003 15:15:26 -0400 Subject: APT, Yum and Red Carpet In-Reply-To: <20030813140551.GS3676@shitake.truemesh.com>; from pauln@truemesh.com on Wed, Aug 13, 2003 at 03:05:52PM +0100 References: <200308121710.h7CHAwD17778@devserv.devel.redhat.com> <20030813140551.GS3676@shitake.truemesh.com> Message-ID: <20030813151526.A12687@devserv.devel.redhat.com> On Wed, Aug 13, 2003 at 03:05:52PM +0100, Paul Nasrat wrote: > On Wed, Aug 13, 2003 at 07:52:57AM -0600, Chris Ricker wrote: > > > > > Speaking of which, is there any interest in incorporating RSBAC (preferably) > > or SELinux into RHLP, long-term? > > SELinux architecture has been merged in 2.6.0-test3, so I imagine that > Cambridge++ will have that SELinux in it. Well, the technology exists in the kernel source tree, and we encouraged its inclusion in the mainline tree. But SELinux has other components, particularly userland code changes and policy. Policy management is a major job in and of itself. Also, there's a performance cost to enabling SELinux that needs to be considered. As I've mentioned before, upstream acceptance is a key point; this distinguishes SELinux. In addition, Red Hat is specifically working on SELinux, as mentioned in a webcast we did recently: https://www.redhat.com/apps/webform.html?event_type=webcast&eid=225 And the top search response on SELinux on our web site is this page: http://www.redhat.com/solutions/security/SELinux.html We haven't made a committment to include SELinux in Cambridge++, nor to not include it. :-) We're certainly actively working on SELinux, and if there are like-minded developers who want to, say, participate with us in doing policy work, speak up, and maybe it will make sense. I'm personally curious: how many people on this list have worked on SELinux policy and/or policy tools? 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 dawson at fnal.gov Wed Aug 13 21:12:59 2003 From: dawson at fnal.gov (Troy Dawson) Date: Wed, 13 Aug 2003 16:12:59 -0500 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <3F394DFC.8040508@redhat.com> References: <3F394DFC.8040508@redhat.com> Message-ID: <3F3AA9DB.9070101@fnal.gov> Very nice. I think the shades of green of bluecurve-lime have been very well balanced. The other color schemes are nice as well, but the lime is clearly my favorite. As for the window buttons, I have to say I prefer them this new way. Although the old way, of using the entire bar, may have looked bigger, but I always found myself clicking on the line, or X within the button anyway. I think the icons look very good, though I should have looked closer at them before installing, so I could have compared them better. What to critique or make better? Well, I'll wait until you get the KDE section done before I do that, as I'm much more familier with KDE. I just wanted to let you know I thought things looked good. Troy Dawson Garrett LeSage wrote: > Hey all, > > I have recently posted a few new screenshots which demonstrate some of > the latest updates in the "redhat-artwork" package. > > You can see screenshots at the following URLs: > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview.png > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-slate.png > > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-purple.png > > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-orange.png > > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-green.png > > http://people.redhat.com/glesage/screenshots/bluecurve_nextgen-preview-gnome.png > > > You can get the most recent version in Rawhide or out of CVS. As of this > writing, the current Rawhide URL for redhat-artwork is: > http://rawhide.redhat.com/pub/redhat/linux/rawhide/i386/RedHat/RPMS/redhat-artwork-0.78-1.i386.rpm > > > Brief overview of a few changes since the Red Hat Linux 9 time frame: > > Icons > ===== > > * Reworked the entire icon set, now generated by XML configs and > icon sheets > * Multiple icon sizes are now available (not fully complete yet) > * All icons are now pixel optimized per size > * New mimetype file icons > * Updated stock icons > * Initial support for KDE stock icons (actions) now available (size > issues need to be sorted out, so it's not working quite yet) > * Gnome panel icons are 36x36 instead of 24x24 (for the time being, > at least...) > > > Window Decorations > ================ > > * Window frame decorations have a new style > * Metacity theme implemented > * KDE's KWin theme needs to be updated still > > > Widgets > ======= > > * A few tweaks for the GTK+ theme configuration. > * Additional color schemes are now available for Bluecurve > > Access these additional themes by selecting "desktop menu > preferences > > theme" from the panel, hitting the "Details..." button, and in the > "Controls" tab, select "Bluecurve-Slate" or some other Bluecurve color > scheme. > > Of course, there is still work to be done. Please file bugs, help out, > and/or provide feedback on the package. > > Thanks, > Garrett -- __________________________________________________ Troy Dawson dawson at fnal.gov (630)840-6468 Fermilab ComputingDivision/OSS CSI Group __________________________________________________ From florin at sgi.com Wed Aug 13 21:29:54 2003 From: florin at sgi.com (Florin Andrei) Date: 13 Aug 2003 14:29:54 -0700 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <1060721354.11725.1.camel@poincare.devel.redhat.com> References: <3F394DFC.8040508@redhat.com> <1060721354.11725.1.camel@poincare.devel.redhat.com> Message-ID: <1060810193.2410.114.camel@stantz.corp.sgi.com> On Tue, 2003-08-12 at 13:49, Owen Taylor wrote: > I'm a little concerend by the visually smaller window buttons. I think > it's likely that people will think they have to click inside the small > button. Which makes it a harder, more precision operation. OTOH, not having buttons that touch each other might keep some people from clicking on the X by mistake, when all they want is to click on Maximize. I always found it uncomfortable from a usability perspective that the Close Window button stays together with the other ones. If i had a dollar for every time i closed a window by mistake because of that... > The new icons and color schemes look nice. yup -- Florin Andrei http://florin.myip.org/ From barryn at pobox.com Thu Aug 14 02:27:18 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Wed, 13 Aug 2003 19:27:18 -0700 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <20030813144920.C5175@redhat.com> References: <20030812231944.E27241@redhat.com> <20030813133205.3953ef48.seanlkml@rogers.com> <20030813143034.B5175@redhat.com> <20030813143712.2bafb893.seanlkml@rogers.com> <20030813144920.C5175@redhat.com> Message-ID: <20030814022718.GB16090@ip68-4-255-84.oc.oc.cox.net> [root at i5000e root]# up2date -ui Traceback (most recent call last): File "/usr/sbin/up2date", line 25, in ? from up2date_client import repoDirector File "repoDirector.py", line 12, in ? File "rhnChannel.py", line 128, in getChannels File "up2dateAuth.py", line 150, in getLoginInfo File "up2dateAuth.py", line 112, in login File "rpcServer.py", line 114, in doCall File "/usr/lib/python2.2/xmlrpclib.py", line 821, in __call__ return self.__send(self.__name, args) File "/usr/lib/python2.2/site-packages/rhn/rpclib.py", line 302, in _request verbose=self._verbose File "/usr/lib/python2.2/site-packages/rhn/transports.py", line 167, in request headers, fd = req.send_http(host, handler) File "/usr/lib/python2.2/site-packages/rhn/transports.py", line 680, in send_http headers=self.headers) File "/usr/lib/python2.2/httplib.py", line 701, in request self._send_request(method, url, body, headers) File "/usr/lib/python2.2/httplib.py", line 723, in _send_request self.endheaders() File "/usr/lib/python2.2/httplib.py", line 695, in endheaders self._send_output() File "/usr/lib/python2.2/httplib.py", line 581, in _send_output self.send(msg) File "/usr/lib/python2.2/httplib.py", line 560, in send self.sock.sendall(str) File "/usr/lib/python2.2/site-packages/rhn/SSL.py", line 191, in write sent = self._connection.send(data) SSL.Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate verify failed')] I'm using a Current server, but I do think I've stubled upon another client bug here. [root at i5000e root]# fgrep -B1 RHNS-CA-CERT /etc/sysconfig/rhn/up2date sslCACert[comment]=The CA cert used to verify the ssl server sslCACert=/usr/share/rhn/RHNS-CA-CERT.rula So, my SSL cert is in RHNS-CA-CERT.rula, not RHNS-CA-CERT. (If that filename makes no sense, don't worry about that. The important thing here is that the filename is not RHNS-CA-CERT.) This always worked with previous up2date releases in somewhat recent memory. I had to copy /usr/share/rhn/RHNS-CA-CERT.rula to /usr/share/rhn/RHNS-CA-CERT before things worked again. I haven't had to do that since Red Hat 7.x. (What's really new and annoying here is that if I don't copy the cert over, up2date-config blows up with the same traceback!) Another weird quirk: If I delete RHNS-CA-CERT, up2date-config just dies silently: [root at i5000e rhn]# up2date-config --nox [root at i5000e rhn]# Same goes for up2date itself: [root at i5000e rhn]# up2date [root at i5000e rhn]# I grepped through the up2date 3.9.6 source code once and wasn't able to find the culprit, but I think I'll try again in a few minutes... I haven't actually tried to apply updates with the new up2date -- the most I've done is trying to reregister my machine with my Current 1.4.4 server (that succeeded once I copied over the SSL cert to RHNS-CA-CERT). Anyway, this is what I've discovered so far... -Barry K. Nathan From alikins at redhat.com Thu Aug 14 02:44:22 2003 From: alikins at redhat.com (Adrian Likins) Date: Wed, 13 Aug 2003 22:44:22 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <20030814022718.GB16090@ip68-4-255-84.oc.oc.cox.net>; from barryn@pobox.com on Wed, Aug 13, 2003 at 07:27:18PM -0700 References: <20030812231944.E27241@redhat.com> <20030813133205.3953ef48.seanlkml@rogers.com> <20030813143034.B5175@redhat.com> <20030813143712.2bafb893.seanlkml@rogers.com> <20030813144920.C5175@redhat.com> <20030814022718.GB16090@ip68-4-255-84.oc.oc.cox.net> Message-ID: <20030813224422.D26065@redhat.com> On Wed, Aug 13, 2003 at 07:27:18PM -0700, Barry K. Nathan wrote: > [root at i5000e root]# up2date -ui > SSL.Error: [('SSL routines', 'SSL3_GET_SERVER_CERTIFICATE', 'certificate > verify failed')] > > I'm using a Current server, but I do think I've stubled upon another > client bug here. > > [root at i5000e root]# fgrep -B1 RHNS-CA-CERT /etc/sysconfig/rhn/up2date > sslCACert[comment]=The CA cert used to verify the ssl server > sslCACert=/usr/share/rhn/RHNS-CA-CERT.rula > rpcServer.py: # Where do we keep the CA certificate for RHNS? # The servers we're talking to need to have their certs # signed by one of these CA. -ca = cfg["sslCACerts"] +ca = cfg["sslCACert"] that fixes it. It was looking for the wrong config name (changed this code recently to support multiple ca certs, and missed this name). For our cert it fails back to a hardcoded value. Nice find. > Another weird quirk: If I delete RHNS-CA-CERT, up2date-config just dies > silently: > same bug. Should be fixed in 3.9.7 at some point. Adrian From jamil at ssl-idt.net Thu Aug 14 04:49:48 2003 From: jamil at ssl-idt.net (Jamil Ahmed) Date: Thu, 14 Aug 2003 10:49:48 +0600 Subject: Including new OT Fonts Message-ID: <00d501c3621f$7e99c220$0a01a8c0@jamil> Hi, May I know who is in charge of Font management of RH linux? We [http://www.bengalinux.org/] are working for Bengali/Bangla translation. We have already submitted a request to include Bangla OTF thru bugzilla. But I think, that request is not closed yet. We are hoping that Bangla language will be included in the next release of RH distro. Please let me know asap what should we do? Cause there is not enough time. BTW, we have already submited translated versions of the required packages in i18n's cvs server. Thanks, `Jamil From pauln at truemesh.com Thu Aug 14 07:32:18 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Thu, 14 Aug 2003 08:32:18 +0100 Subject: APT, Yum and Red Carpet In-Reply-To: <20030813151526.A12687@devserv.devel.redhat.com> References: <200308121710.h7CHAwD17778@devserv.devel.redhat.com> <20030813140551.GS3676@shitake.truemesh.com> <20030813151526.A12687@devserv.devel.redhat.com> Message-ID: <20030814073217.GA13037@shitake.truemesh.com> On Wed, Aug 13, 2003 at 03:15:26PM -0400, Michael K. Johnson wrote: > We haven't made a committment to include SELinux in Cambridge++, > nor to not include it. :-) We're certainly actively working on > SELinux, and if there are like-minded developers who want to, say, > participate with us in doing policy work, speak up, and maybe it > will make sense. This sounds like a good idea. Personally policy is an important part of systems administration, so I'd imagine that enterprise customers/developers/sysadmins would fit in here. > I'm personally curious: how many people on this list have worked on > SELinux policy and/or policy tools? Well I'm just building rpms from the tar.gz's and there's work to be don there. The policy rpm isn't buildable by non-root users out of the box, well I've been meaning to play for a while so I'll look at fixing the spec and pushing patches upstream. Paul From csm at fx.ro Thu Aug 14 10:31:29 2003 From: csm at fx.ro (Cosmin Hanulescu) Date: Thu, 14 Aug 2003 13:31:29 +0300 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <3F394DFC.8040508@redhat.com> References: <3F394DFC.8040508@redhat.com> Message-ID: <3F3B6501.3080101@fx.ro> Garrett LeSage wrote: > the latest updates in the "redhat-artwork" package. > You can get the most recent version in Rawhide or out of CVS. Nice work, I do like the new one. I just have a couple of comments, hopefully not duplicating some old FAQs... I did update my RHEL 3 Beta WS with the redhat-artwork package from rawhide. I don't seem to be able to find where I can tell to the "foot" menu to show small icons... Along with that, I notice that there are some icons which are somehow blurred, while others have a good looking sharpness. Has anyone noticed these differences? Greetings, Cosmin -- I submit that the world would be much happier, if men were as fully able to keep silence as they are to speak. - Spinoza From coomsie at coomsie.no-ip.com Thu Aug 14 11:12:17 2003 From: coomsie at coomsie.no-ip.com (coomsie) Date: Thu, 14 Aug 2003 23:12:17 +1200 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <1060762430.3f39f33e50f03@webmail.welho.com> References: <20030812231944.E27241@redhat.com> <1060762430.3f39f33e50f03@webmail.welho.com> Message-ID: <200308142312.17604.coomsie@coomsie.no-ip.com> On Wednesday 13 August 2003 20:13, Panu Matilainen wrote: > Quoting Adrian Likins : > > http://people.redhat.com/~alikins/up2date/severn/ > > > > New up2date for testing. Somewhat notable new > > feature of support for 3rd party yum and apt > > repos. See /etc/sysconfig/rhn/sources for info > > on configuring them (docs to come). > > Whoa.. cool! :) Had a quick look over aptRepo.py, a couple of comments on > findings in there: > 1) "# assuming this is always bz2?" - yes, it's always bz2. There can be an > uncompressed version of the file as well but then who the heck wants to > download an uncompressed file when the .bz2 file is there... legacy stuff. > 2) "# FIXME .." comment wrt the repository layout and finding the package - > yes there are basically two kinds of repositories, "traditional" and > "flat", of which flat one is what almost everybody uses nowadays. > Supporting to trad layout where RPMS and SRPMS are on a different directory > level would be nice but I wouldn't consider lack of it as a showstopper at > all. > > > In addition to the apt/yum repos, it also > > now supports using a local dir of rpms as > > a "repo" > > This is really nice one! I can second that ..... This is really cool ... how about getting rawhide on this as well for people who want to have the latest and greatest ..... maybe through yum/apt (not sure what is involved in setting this up) or just like the local directory but the ftp/http site for rawhide (if apt/yum is a bit of work to maintain) It would be great for us to just view the new packages through the up2date tool and choose through this to update that package or not. ============== Cheers Coomsie :3) From mike at netlyncs.com Thu Aug 14 11:30:47 2003 From: mike at netlyncs.com (Mike Chambers) Date: Thu, 14 Aug 2003 06:30:47 -0500 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <3F3B6501.3080101@fx.ro> References: <3F394DFC.8040508@redhat.com> <3F3B6501.3080101@fx.ro> Message-ID: <1060860647.5862.1.camel@bart.netlyncs.com> On Thu, 2003-08-14 at 05:31, Cosmin Hanulescu wrote: > I did update my RHEL 3 Beta WS with the redhat-artwork package from > rawhide. I don't seem to be able to find where I can tell to the "foot" > menu to show small icons... Along with that, I notice that there are > some icons which are somehow blurred, while others have a good looking > sharpness. Has anyone noticed these differences? Same problem here on same type system. The icons are bigger, therefore the menu is bigger/longer and no where near as small as it was. Is there a way to fix that besides hat/preferences/fonts? -- Mike Chambers Madisonville, KY "The road to to success is always under construction!" From mike at netlyncs.com Thu Aug 14 11:32:46 2003 From: mike at netlyncs.com (Mike Chambers) Date: Thu, 14 Aug 2003 06:32:46 -0500 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <200308142312.17604.coomsie@coomsie.no-ip.com> References: <20030812231944.E27241@redhat.com> <1060762430.3f39f33e50f03@webmail.welho.com> <200308142312.17604.coomsie@coomsie.no-ip.com> Message-ID: <1060860765.5862.4.camel@bart.netlyncs.com> On Thu, 2003-08-14 at 06:12, coomsie wrote: > how about getting rawhide on this as well for people who want to have the > latest and greatest ..... You could do as I do, and mirror rawhide yourself and then set it up as a local directory via up2date. But I believe fedora and/or freshrpms or someone has rawhide available already on their site. So you might find that out, redirect up2date to point to it and your all set. -- Mike Chambers Madisonville, KY "The road to to success is always under construction!" From pmatilai at welho.com Thu Aug 14 11:38:02 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Thu, 14 Aug 2003 14:38:02 +0300 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <1060860765.5862.4.camel@bart.netlyncs.com> References: <20030812231944.E27241@redhat.com> <1060762430.3f39f33e50f03@webmail.welho.com> <200308142312.17604.coomsie@coomsie.no-ip.com> <1060860765.5862.4.camel@bart.netlyncs.com> Message-ID: <1060861082.3f3b749a94a81@webmail.welho.com> Quoting Mike Chambers : > On Thu, 2003-08-14 at 06:12, coomsie wrote: > > > how about getting rawhide on this as well for people who want to have the > > > latest and greatest ..... > > You could do as I do, and mirror rawhide yourself and then set it up as > a local directory via up2date. > > But I believe fedora and/or freshrpms or someone has rawhide available > already on their site. So you might find that out, redirect up2date to > point to it and your all set. IIRC Freshrpms at least has "apt-enabled" rawhide, probably yum as well nowadays. -- - Panu - From matthias at rpmforge.net Thu Aug 14 11:46:14 2003 From: matthias at rpmforge.net (Matthias Saou) Date: Thu, 14 Aug 2003 13:46:14 +0200 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <1060861082.3f3b749a94a81@webmail.welho.com> References: <20030812231944.E27241@redhat.com> <1060762430.3f39f33e50f03@webmail.welho.com> <200308142312.17604.coomsie@coomsie.no-ip.com> <1060860765.5862.4.camel@bart.netlyncs.com> <1060861082.3f3b749a94a81@webmail.welho.com> Message-ID: <20030814134614.66085274.matthias@rpmforge.net> Panu Matilainen wrote : > Quoting Mike Chambers : > > > On Thu, 2003-08-14 at 06:12, coomsie wrote: > > > > > how about getting rawhide on this as well for people who want to have > > > the > > > > > latest and greatest ..... > > > > You could do as I do, and mirror rawhide yourself and then set it up as > > a local directory via up2date. > > > > But I believe fedora and/or freshrpms or someone has rawhide available > > already on their site. So you might find that out, redirect up2date to > > point to it and your all set. > > IIRC Freshrpms at least has "apt-enabled" rawhide, probably yum as well > nowadays. Absolutely. Servern ("beta") and Rawhide ("rawhide") are both accessible through apt and yum. See http://ayo.freshrpms.net/ And browse through http://ayo.freshrpms.net/redhat/ to see what else is there. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Raw Hide 20030813 running Linux kernel 2.4.21-20.1.2024.2.1.nptl Load : 0.49 0.34 0.29 From coomsie at coomsie.no-ip.com Thu Aug 14 12:12:49 2003 From: coomsie at coomsie.no-ip.com (coomsie) Date: Fri, 15 Aug 2003 00:12:49 +1200 Subject: Using up2date with rawhide from freshrpms .... In-Reply-To: <20030814134614.66085274.matthias@rpmforge.net> References: <20030812231944.E27241@redhat.com> <1060861082.3f3b749a94a81@webmail.welho.com> <20030814134614.66085274.matthias@rpmforge.net> Message-ID: <200308150012.49936.coomsie@coomsie.no-ip.com> .............. rawhide, probably yum as well > > nowadays. > > Absolutely. Servern ("beta") and Rawhide ("rawhide") are both accessible > through apt and yum. > > See http://ayo.freshrpms.net/ > > And browse through http://ayo.freshrpms.net/redhat/ to see what else is > there. > > Matthias Gidday everyone, I couldnt get apt to work, I must have had the wrong url :p .... But this works for yum in the sources file .. in => /etc/sysconfig/rhn/sources yum rawhide-frm-freshrpms http://ayo.freshrpms.net/redhat/rawhide/i386/os/ ============== Cheers Coomsie :3) From garrett at redhat.com Thu Aug 14 15:40:36 2003 From: garrett at redhat.com (Garrett LeSage) Date: Thu, 14 Aug 2003 11:40:36 -0400 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <1060860647.5862.1.camel@bart.netlyncs.com> References: <3F394DFC.8040508@redhat.com> <3F3B6501.3080101@fx.ro> <1060860647.5862.1.camel@bart.netlyncs.com> Message-ID: <3F3BAD74.6070603@redhat.com> Mike Chambers wrote: >On Thu, 2003-08-14 at 05:31, Cosmin Hanulescu wrote: > > > >>I did update my RHEL 3 Beta WS with the redhat-artwork package from >>rawhide. I don't seem to be able to find where I can tell to the "foot" >>menu to show small icons... Along with that, I notice that there are >>some icons which are somehow blurred, while others have a good looking >>sharpness. Has anyone noticed these differences? >> >> > >Same problem here on same type system. The icons are bigger, therefore >the menu is bigger/longer and no where near as small as it was. Is >there a way to fix that besides hat/preferences/fonts? > Edit /usr/share/themes/Bluecurve/gtk-2.0/gtkrc and change the top line: gtk-icon-sizes = "panel-menu=36,36" to gtk-icon-sizes = "panel-menu=24,24" ...and you should have the smaller versions of the icons. Because the color versions inherit from the main Bluecurve theme file, the icons should change no matter which version of the Bluecurve theme you run. You will probably have to restart the panel after making the change, however. Hitting Alt-F2 and typing "killall gnome-panel" should do the trick. As it stands, there are a few issues with having larger icons in the panel (some related to the way GTK+ and the panel are currently not picking up the multiple sizes, another is that the panel menu is quite large on the top-level). I figured that it made sense to have the larger icons for the time being so that some of the icon sizing stuff might get sorted out. I will probably switch back the icons to the smaller size regardless -- it depends on what makes the most sense, though. Garrett From otaylor at redhat.com Thu Aug 14 16:29:19 2003 From: otaylor at redhat.com (Owen Taylor) Date: Thu, 14 Aug 2003 12:29:19 -0400 Subject: Including new OT Fonts In-Reply-To: <00d501c3621f$7e99c220$0a01a8c0@jamil> References: <00d501c3621f$7e99c220$0a01a8c0@jamil> Message-ID: <1060878559.10084.18.camel@poincare.devel.redhat.com> On Thu, 2003-08-14 at 00:49, Jamil Ahmed wrote: > Hi, > May I know who is in charge of Font management of RH linux? We > [http://www.bengalinux.org/] are working for Bengali/Bangla translation. We > have already submitted a request to include Bangla OTF thru bugzilla. But I > think, that request is not closed yet. > We are hoping that Bangla language will be included in the next release > of RH distro. Please let me know asap what should we do? Cause there is not > enough time. > BTW, we have already submited translated versions of the required > packages in i18n's cvs server. I'm basically the responsible person. I last looked at the Bengali font issue a few months ago. At that point, it didn't look like things were quite ready for adding to the distribution. - There were some issues mentioned on the freebangfonts website with inclusion of glyphs from non-free fonts that I assume have been sorted out now. - There were a large number of different fonts listed; I tried out a few; some didn't render correctly, some were horribly ugly. It wasn't at all clear what fonts should be added. I hope to have a chance fairly soon to write up a policy for font inclusion in RHL from both a technical and legal perspective. ("fairly soon", unfortunately, might be a few months away.) For including Bengali fonts in Red Hat, what would really help wouuld be a proposal: * What set of fonts should be included, each font really should be justified as serving a different purpose. What I mean by a purpose is: - This font looks good on the screen - This font exhibits the style of Bengali script, people expect to have fonts with both the and styles of scripts available. Or whatever. Microsoft XP comes with one or maybe two Bengali fonts. If we are going to have more available, that needs to be justified. * For each font, a summary of: - What is the license of the fonts? - Who drew the glyphs? If the font contains Roman characters as well, where did they come from? - Where did the design of the glyphs come from? (In some countries, font designs are patentable or otherwise protected, so a exact copy of an existing commerical font is not a good idea.) - Where did the name come from? (Font names are trademarkable) * Some indication of how useful the bugs are with the software we ship currently. Screenshots of what works, and what doesn't might be useful. (There are various open bugs against Pango about Bengali rendering problems. I don't think the fixes for them will make Cambridge, unfortunately.) I dont' want to just dump all the Bengali fonts available into the distribution. We need to make sure that anything we add to the distribution is legally solid (and fonts are way more complex here than code), and that people can find the fonts they need easily, rather than getting confused with a long list of fonts that don't quite work. Regards, Owen From m.a.young at durham.ac.uk Thu Aug 14 17:16:35 2003 From: m.a.young at durham.ac.uk (M A Young) Date: Thu, 14 Aug 2003 18:16:35 +0100 (BST) Subject: UML project for Cambridge++ Message-ID: I am trying to put together a Red Hat Linux Project project to develop User Mode Linux aiming for inclusion in Cambridge++. I don't know how this is supposed to work (I am not sure anyone does yet), but I have put together an initial project page at http://toast.debian.net/~may/umlproject/index.html Michael Young From i.pilcher at comcast.net Thu Aug 14 17:57:03 2003 From: i.pilcher at comcast.net (Ian Pilcher) Date: Thu, 14 Aug 2003 12:57:03 -0500 Subject: UML project for Cambridge++ In-Reply-To: References: Message-ID: <3F3BCD6F.8040807@comcast.net> M A Young wrote: > I am trying to put together a Red Hat Linux Project project to develop > User Mode Linux aiming for inclusion in Cambridge++. I don't know how this > is supposed to work (I am not sure anyone does yet), but I have put > together an initial project page at > http://toast.debian.net/~may/umlproject/index.html You can count me as interested. I can volunteer to help out with RPM packaging (SPEC files). -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From sabdelg at redhat.com Thu Aug 14 18:31:51 2003 From: sabdelg at redhat.com (Sherif R. Abdelgawad) Date: Thu, 14 Aug 2003 14:31:51 -0400 (EDT) Subject: Red Hat Linux Arabic Localization Project Message-ID: <1060885911.3f3bd59776467@mayberry.redhat.com> With the help of Linux-ME.org (Linux Middle East), Linux-Egypt.org (LUG), and ITI (Information Technology Institute)in Egypt (http://www.iti.gov.eg ), a project for providing Arabic Support to RHL. The aim of this project is to collect the efforts and contribute in RHL to solve the issues and problems wrt full arabic support in RHL (right-to-left, fotns, rendering ...etc). An initial page for the project, with call for participation is located at: http://www.linux-me.org/ This effort also includes proper translation, validate the already translation efforts and provide standard good translation as well as put the efforts to solve the technical issues wrt to Arabic. Cheers, -Sherif From chuckw at quantumlinux.com Thu Aug 14 18:04:05 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Thu, 14 Aug 2003 11:04:05 -0700 (PDT) Subject: OS Support Message-ID: So... Is the rumor true that as of December 31, 2003 there won't be any supported OS from RH other than the Enterprise line? If so, what will happen to this list and the initiative behind it? -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From tcallawa at redhat.com Thu Aug 14 19:24:16 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: 14 Aug 2003 14:24:16 -0500 Subject: OS Support In-Reply-To: References: Message-ID: <1060889056.3252.105.camel@zorak> On Thu, 2003-08-14 at 13:04, Chuck Wolber wrote: > So... Is the rumor true that as of December 31, 2003 there won't be any > supported OS from RH other than the Enterprise line? If so, what will > happen to this list and the initiative behind it? Let us be really careful how we use the word "support". Maintenance for all existing RHL products (Maintenance is defined as bugfix, security fix, and enhancement packages) is set on a timetable for each release. The timetable for maintenance for a release is "at least twelve months", with no guarantees beyond that. So, lets look at the RHL products that still exist: Red Hat Linux 9 (Shrike) April 30, 2004 Red Hat Linux 8.0 (Psyche) December 31, 2003 Red Hat Linux 7.3 (Valhalla) December 31, 2003 Red Hat Linux 7.2 (Enigma) December 31, 2003 Red Hat Linux 7.1 (Seawolf) December 31, 2003 (pulled from http://www.redhat.com/apps/support/errata/) All older RHL products have been End-Of-Lifed. RHEL has a longer maintenance life-cycle. RHEL products have maintenance "for a period of 5 years from initial release", with no guarantees beyond that. This means that RHEL 2.1 has maintenance until May 31, 2007 (happy birthday to me). Lots more details about RHEL's maintenance policy at: http://www.redhat.com/apps/support/errata/rhlas_errata_policy.html Now Support (note that I've capitalized it), in the sense of being able to file a trouble ticket (by phone, email, or web) with Red Hat Global Support Services (GSS) is only available for RHEL. So, there is currently no Support for RHL products (7.1-9). In the past, we were Supporting the RHL 7.* series for RHEL customers who planned to migrate, but that offer has expired. You can still file Bugzilla reports on products that are not end-of-lifed (actually, i think you can file them on eol'd products too, we're just not going to do much about them), and Red Hat still encourages this, but there is no SLA (Service Level Agreement) around the resolution of RHL bugs. Now, how does all of this affect RHLP? Not much. If you want guaranteed errata from Red Hat for more than a year or Support, RHEL is where you need to be looking. RHLP serves to meet the needs of Linux users who do not need a long-life-cycle product with guaranteed Support & Maintenance. We're just taking RHL from a product to a project (with scheduled point releases). Does that help to clear it up? ~spot --- Tom "spot" Callaway SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260 The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me. "Immature poets borrow, mature poets steal." --- T. S. Eliot From mike at netlyncs.com Thu Aug 14 20:37:54 2003 From: mike at netlyncs.com (Mike Chambers) Date: Thu, 14 Aug 2003 15:37:54 -0500 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <3F3BAD74.6070603@redhat.com> References: <3F394DFC.8040508@redhat.com> <3F3B6501.3080101@fx.ro> <1060860647.5862.1.camel@bart.netlyncs.com> <3F3BAD74.6070603@redhat.com> Message-ID: <1060893473.6484.3.camel@bart.netlyncs.com> On Thu, 2003-08-14 at 10:40, Garrett LeSage wrote: > Edit /usr/share/themes/Bluecurve/gtk-2.0/gtkrc and change the top line: > > gtk-icon-sizes = "panel-menu=36,36" > to > gtk-icon-sizes = "panel-menu=24,24" > > You will probably have to restart the panel after making the change, > however. Hitting Alt-F2 and typing "killall gnome-panel" should do the > trick. That did the trick and back to normal, thanks. -- Mike Chambers Madisonville, KY "The road to to success is always under construction!" From pekkas at netcore.fi Fri Aug 15 09:24:55 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 15 Aug 2003 12:24:55 +0300 (EEST) Subject: bug fixes/patches and developer round-trip time Message-ID: Hi, Perhaps I should bring up one issue that may have not been discussed too much. A lot of bug reports which no one has time to fix is bad, of course. But what's worse, is that when someone from the community provides e.g. patches or works for fixing those issues, it takes a LONG time to actually get a developer to commit such a fix and get the problem solved. IMHO, in cases I've seen this, most of the time it has taken entirely too long (even many weeks or months, even for trivial fixes). This alienates people who actually sometimes fix problems rather than "just" complain about them. (Complaining, when done properly, is very important too, of course :-). This is something that needs to be fixed, and should be a first priority item to fix in the RHL project. Whether that requires new priorization for developers, giving out CVS commit access, or whatever, I don't know .. but the situation MUST improve, and soon. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From pmatilai at welho.com Fri Aug 15 10:17:08 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 15 Aug 2003 13:17:08 +0300 Subject: bug fixes/patches and developer round-trip time In-Reply-To: References: Message-ID: <1060942628.3f3cb324c80d3@webmail.welho.com> Quoting Pekka Savola : > Hi, > > Perhaps I should bring up one issue that may have not been discussed too > much. > > A lot of bug reports which no one has time to fix is bad, of course. > > But what's worse, is that when someone from the community provides e.g. > patches or works for fixing those issues, it takes a LONG time to actually > get a developer to commit such a fix and get the problem solved. > > IMHO, in cases I've seen this, most of the time it has taken entirely too > long (even many weeks or months, even for trivial fixes). Indeed... One such example is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81438 which was reported soon after RH9 beta testing begun, pointed out where the fault is and that upgrading the package to newer version fixes it. RH9 still shipped couple of months later with the buggy version. Ok, the bug may be a bit esoteric (how common it's to have that big groups in LDAP, dunno?) but since the fix is trivial, it was early in beta ... Severn finally has the updated package but it's *eight months* without even a single comment from the developer :( > > This alienates people who actually sometimes fix problems rather than > "just" complain about them. (Complaining, when done properly, is very > important too, of course :-). > > This is something that needs to be fixed, and should be a first priority > item to fix in the RHL project. > > Whether that requires new priorization for developers, giving out CVS > commit access, or whatever, I don't know .. but the situation MUST > improve, and soon. Amen. Even something like a keyword/flag to point out that this bugzilla entry contains a fix to a problem ought to stick out to developers eyes... -- - Panu - From veillard at redhat.com Fri Aug 15 11:59:06 2003 From: veillard at redhat.com (Daniel Veillard) Date: Fri, 15 Aug 2003 07:59:06 -0400 Subject: bug fixes/patches and developer round-trip time In-Reply-To: ; from pekkas@netcore.fi on Fri, Aug 15, 2003 at 12:24:55PM +0300 References: Message-ID: <20030815075906.K9929@redhat.com> On Fri, Aug 15, 2003 at 12:24:55PM +0300, Pekka Savola wrote: > Hi, > > Perhaps I should bring up one issue that may have not been discussed too > much. > > A lot of bug reports which no one has time to fix is bad, of course. > > But what's worse, is that when someone from the community provides e.g. > patches or works for fixing those issues, it takes a LONG time to actually > get a developer to commit such a fix and get the problem solved. > > IMHO, in cases I've seen this, most of the time it has taken entirely too > long (even many weeks or months, even for trivial fixes). Yep, actually it's a process which can be improved easilly in the context of Red hat Linux Project, because it's parallelizable. What it takes is work as part of the bug report triaging to identify bug reports with patches and make sure they are immediately sent upstream to the maintainer or project bugzilla. That does not require any priviledged access to bugzilla, can be split between a pool of volunteers, but can be a boring task. Availability of patches detection can be mostly automated if the change is given as an attachment and not as a human language explanation. If you have the energy, building querying tools and setting up instructions for other to use should not be that difficult. One of the data which would be useful but might be missing right now is a database associating the package names to their corresponding upstream contact and bugzilla informations. The URL field present in the RPM header is a good fist step to lookup the information (I use it to provide project pointers on rpmfind.net queries, I could make that database available). Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From pekkas at netcore.fi Fri Aug 15 12:05:49 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 15 Aug 2003 15:05:49 +0300 (EEST) Subject: bug fixes/patches and developer round-trip time In-Reply-To: <20030815075906.K9929@redhat.com> Message-ID: On Fri, 15 Aug 2003, Daniel Veillard wrote: > On Fri, Aug 15, 2003 at 12:24:55PM +0300, Pekka Savola wrote: > > Hi, > > > > Perhaps I should bring up one issue that may have not been discussed too > > much. > > > > A lot of bug reports which no one has time to fix is bad, of course. > > > > But what's worse, is that when someone from the community provides e.g. > > patches or works for fixing those issues, it takes a LONG time to actually > > get a developer to commit such a fix and get the problem solved. > > > > IMHO, in cases I've seen this, most of the time it has taken entirely too > > long (even many weeks or months, even for trivial fixes). > > Yep, actually it's a process which can be improved easilly in the > context of Red hat Linux Project, because it's parallelizable. What it > takes is work as part of the bug report triaging to identify bug reports > with patches and make sure they are immediately sent upstream to the > maintainer or project bugzilla. [...] I guess this is a case too, but not really my point. What if there is no upstream, i.e. Red Hat has developed the software? What if the fix is already implemented in upstream, but the question is getting the upstream version merged or the same patch added? (note: merging to a new upstream release may be a LOT of more work in some cases; adding patches as implemented in upstream may be easier, sometimes, and there would not be the "patch merge horror when we move to a new upstream release"). More often than not, these things have bitten me at least. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From hp at redhat.com Fri Aug 15 14:25:54 2003 From: hp at redhat.com (Havoc Pennington) Date: Fri, 15 Aug 2003 10:25:54 -0400 Subject: bug fixes/patches and developer round-trip time In-Reply-To: References: Message-ID: <20030815102554.F17414@devserv.devel.redhat.com> On Fri, Aug 15, 2003 at 12:24:55PM +0300, Pekka Savola wrote: > Whether that requires new priorization for developers, giving out CVS > commit access, or whatever, I don't know .. but the situation MUST > improve, and soon. Prioritization doesn't scale - you can only prioritize so many things/patches. One real fix here is bug triage improvement (as I discussed at length in an earlier mail) - see http://bugzilla.gnome.org/gnome-23-report.html which has quick links to all bugs with patches for example. The other real fix is commit access to non-RH developers, so we can increase the number of people who can apply a patch. In my opinion our focus/priority has to be on making the project scalable by allowing external contribution, if we focus on doing all/more work ourselves we will just get further and further behind as more people try to contribute. Making external contribution possible and then getting a significant number of contributors will be a long process, so don't be too impatient. Havoc From johnsonm at redhat.com Fri Aug 15 14:36:33 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 15 Aug 2003 10:36:33 -0400 Subject: bug fixes/patches and developer round-trip time In-Reply-To: ; from pekkas@netcore.fi on Fri, Aug 15, 2003 at 12:24:55PM +0300 References: Message-ID: <20030815103633.A13833@devserv.devel.redhat.com> On Fri, Aug 15, 2003 at 12:24:55PM +0300, Pekka Savola wrote: > This is something that needs to be fixed, and should be a first priority > item to fix in the RHL project. It is one of the reasons for the project. > Whether that requires new priorization for developers, giving out CVS > commit access, or whatever, I don't know .. but the situation MUST > improve, and soon. As you point out, the solution isn't necessarily obvious. It's also not necessarily only one thing. One thing that comes to mind for immediate improvement (not the only possible improvement) is that we now have this list for development discussions -- an bug with a fix that is not acted on can be brought up on this list for discussion. One thing that sometimes happens in cases like this where a developer does see the patch is that there's a subtlety that the developer needs a bit more time to analyze than he has available at that immediate moment, and so intends to come back to it soon, and looses track. Asking about a specific patch here might be a way to remind people of forgotten bits and provoke any necessary discussion to resolve questions. Again, it's not a complete answer, but it might be an improvement. Of course, starting out by asking about every lost patch at once wouldn't help either, for obvious reasons. :-) 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 thomas at apestaart.org Fri Aug 15 17:06:01 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 15 Aug 2003 19:06:01 +0200 Subject: ways to build a modified red hat kernel Message-ID: <1060967160.3000.127.camel@thocra> Hi, while trying to get modified red hat kernels to build for a project of mine, I came across something I did not completely understand. So I backstepped and tried to build a general Red Hat kernel with no other modifications than the red hat patches. Attempt 1 consisted of downloading the kernel-source RPM, going into the /usr/src/linux-(version) tree, copying the BOOT config from configs to .config, then running make dep modules. The build fails for the first time while building megarac.o After removing this from .config, I run into the next module problem, and then the next, and the next, and so on, I quickly gave up because I had to take out modules I needed. I tried this both on the original RH9 kernel-source rpm and the most recent one. Attempt 2 consisted of downloading the kernel src.rpm, installing that, then just building from the installed spec file. That seems to work a lot better. Now, my question. I was under the impression that the source tree installed by the kernel-source rpm was the same source tree as the stock kernel tree, with all the redhat patches applied. Is this not (or no longer) the case ? Why would there be a difference ? Is it reasonable for me to expect kernel-source to build out of the box ? Thanks Thomas Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> My shite shits on your shite <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ From chuckw at quantumlinux.com Fri Aug 15 17:44:02 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Fri, 15 Aug 2003 10:44:02 -0700 (PDT) Subject: ways to build a modified red hat kernel In-Reply-To: <1060967160.3000.127.camel@thocra> Message-ID: > while trying to get modified red hat kernels to build for a project of > mine, I came across something I did not completely understand. So I > backstepped and tried to build a general Red Hat kernel with no other > modifications than the red hat patches. Did you remember to start out with a "make mrproper"? If you don't do that, the kernel will *NOT* compile. > Attempt 2 consisted of downloading the kernel src.rpm, installing that, > then just building from the installed spec file. That seems to work a > lot better. That's a bit ambiguous to me. Did you install the src.rpm and then do a rpmbuild -ba kernel-x.x-x.x Otherwise, I'm not sure just from what you wrote how you used the spec file to build a new kernel. > Now, my question. I was under the impression that the source tree > installed by the kernel-source rpm was the same source tree as the stock > kernel tree, with all the redhat patches applied. Is this not (or no > longer) the case ? Nope. The only place you have the pristine kernel source is in the .src.rpm. In the build process (as detailed in the spec file) a *TON* of patches are applied. > Why would there be a difference ? Is it reasonable for me to expect > kernel-source to build out of the box ? Yes. I'd guess you forgot the "make mrproper" part. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From johnsonm at redhat.com Fri Aug 15 17:44:10 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 15 Aug 2003 13:44:10 -0400 Subject: ways to build a modified red hat kernel In-Reply-To: <1060967160.3000.127.camel@thocra>; from thomas@apestaart.org on Fri, Aug 15, 2003 at 07:06:01PM +0200 References: <1060967160.3000.127.camel@thocra> Message-ID: <20030815134410.A18668@devserv.devel.redhat.com> On Fri, Aug 15, 2003 at 07:06:01PM +0200, Thomas Vander Stichele wrote: > Attempt 1 consisted of downloading the kernel-source RPM, going into the > /usr/src/linux-(version) tree, copying the BOOT config from configs to > .config, then running make dep modules. You need "make mrproper" first. 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 riel at redhat.com Fri Aug 15 18:33:36 2003 From: riel at redhat.com (Rik van Riel) Date: Fri, 15 Aug 2003 14:33:36 -0400 (EDT) Subject: UML project for Cambridge++ In-Reply-To: <3F3BCD6F.8040807@comcast.net> Message-ID: On Thu, 14 Aug 2003, Ian Pilcher wrote: > M A Young wrote: > > I am trying to put together a Red Hat Linux Project project to develop > > User Mode Linux aiming for inclusion in Cambridge++. I don't know how this > > is supposed to work (I am not sure anyone does yet), but I have put > > together an initial project page at > > http://toast.debian.net/~may/umlproject/index.html > > You can count me as interested. I can volunteer to help out with RPM > packaging (SPEC files). I'll help getting the configuration and architecture added to the kernel RPM, and probably the SKAS patches (if they aren't in 2.6 yet). cheers, Rik -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From m.a.young at durham.ac.uk Fri Aug 15 19:22:30 2003 From: m.a.young at durham.ac.uk (M A Young) Date: Fri, 15 Aug 2003 20:22:30 +0100 (BST) Subject: UML project for Cambridge++ In-Reply-To: References: Message-ID: On Fri, 15 Aug 2003, Rik van Riel wrote: > On Thu, 14 Aug 2003, Ian Pilcher wrote: > > M A Young wrote: > > > I am trying to put together a Red Hat Linux Project project to develop > > > User Mode Linux aiming for inclusion in Cambridge++. I don't know how this > > > is supposed to work (I am not sure anyone does yet), but I have put > > > together an initial project page at > > > http://toast.debian.net/~may/umlproject/index.html > > > > You can count me as interested. I can volunteer to help out with RPM > > packaging (SPEC files). > > I'll help getting the configuration and architecture > added to the kernel RPM, and probably the SKAS patches > (if they aren't in 2.6 yet). I don't believe the SKAS patches are in the main 2.6 kernel yet, though people have already tried to port them to 2.6 (eg. see http://sourceforge.net/mailarchive/forum.php?thread_id=2845093&forum_id=3648 ). At the moment the configuration is dictated somewhat by what will compile (SCSI and modules are broken in the current release), which I am trying at the moment. If the build is reasonable, I may put it up on the web site. Michael Young From brugolsky at telemetry-investments.com Fri Aug 15 20:17:13 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Fri, 15 Aug 2003 16:17:13 -0400 Subject: UML project for Cambridge++ In-Reply-To: References: Message-ID: <20030815201712.GB12196@ti19> On Thu, Aug 14, 2003 at 06:16:35PM +0100, M A Young wrote: > I am trying to put together a Red Hat Linux Project project to develop > User Mode Linux aiming for inclusion in Cambridge++. I don't know how this > is supposed to work (I am not sure anyone does yet), but I have put > together an initial project page at > http://toast.debian.net/~may/umlproject/index.html This cries out for getting a working unionfs or cachefs, so that one can use hostfs to mount the underlying system tree, and overlay the parts that one wants to change (parts of /etc, /var). I suppose that for now a little copying and scripting can help. If using Device Mapper, one can create writable snapshots, overwrite /etc with the appropriate config, and start the UML. I was musing on uses of UML and thought that it would be cool to live-upgrade a service by using HA failover to a service instance running in a UML. Doing it with UML leverages all the high-availability work that has already been done. Regards, Bill Rugolsky From john at radiomind.com Fri Aug 15 22:55:53 2003 From: john at radiomind.com (John Beimler) Date: Fri, 15 Aug 2003 18:55:53 -0400 Subject: RHL Project Status? -- It appears stalled at the moment Message-ID: <3F3D64F9.9060001@radiomind.com> I know people have asked before, but what is the status of community building? The website disappeared, and is now a single page. There is a lot of discussion on what should and should not be done, but no opportunity for anyone to do it. A lot of developers, including myself, are not going to put in any time or effort until there is a clear indication that this is something serious. Right now it looks like a well intentioned failed attempt. Red Hat is pulling back inside, the web site got pulled down and has not been replaced, and there is no clear plan on where any of this is going. I was really excited when I saw got the announcement of the Red Hat Linux project, I really thought that Red Hat, Inc. had gotten on the Clue Train, but right now, it looks like they are going to be left behind. Red Hat needs to move this project forward somehow, perhaps setting up a contribution area, setting up CVS for people, or some other service to show that Red Hat is serious about this. I'm sure there are a number of people that would really like to work with Red Hat to make their distribution the best, only if Red Hat would let us. Peace. john From smoogen at lanl.gov Fri Aug 15 23:27:01 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Fri, 15 Aug 2003 17:27:01 -0600 Subject: RHL Project Status? -- It appears stalled at the moment In-Reply-To: <3F3D64F9.9060001@radiomind.com> References: <3F3D64F9.9060001@radiomind.com> Message-ID: <1060990021.4847.19.camel@smoogen1.lanl.gov> This is getting asked daily. They are working on it. It takes time to deal with concerns from outside parties and the fact that there are a lot of conferences in the last month where people were at. Not the answer you want? So sorry. On Fri, 2003-08-15 at 16:55, John Beimler wrote: > I know people have asked before, but what is the status of community > building? The website disappeared, and is now a single page. There is a > lot of discussion on what should and should not be done, but no > opportunity for anyone to do it. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From hp at redhat.com Fri Aug 15 23:47:01 2003 From: hp at redhat.com (Havoc Pennington) Date: Fri, 15 Aug 2003 19:47:01 -0400 Subject: RHL Project Status? -- It appears stalled at the moment In-Reply-To: <3F3D64F9.9060001@radiomind.com> References: <3F3D64F9.9060001@radiomind.com> Message-ID: <20030815194701.A10042@devserv.devel.redhat.com> On Fri, Aug 15, 2003 at 06:55:53PM -0400, John Beimler wrote: > Red Hat needs to move this project forward somehow, perhaps setting up a > contribution area, setting up CVS for people, or some other service to > show that Red Hat is serious about this. I'm sure there are a number of > people that would really like to work with Red Hat to make their > distribution the best, only if Red Hat would let us. We've said since day 1 that it will take time to set up the infrastructure for external contribution. We want to plan that infrastructure in public though, which means we can't set it up prior to announcing the project. We have also prioritized finishing the Cambridge release ahead of working on the infrastructure in earnest. One way to start participating today is to work on getting your package into Fedora. Another way is to start in on the infrastructure issues; simply posting a good description of what's existing/planned for Fedora or Debian or whatever for example would probably give us a starting point, since not all Red Hat developers will be familiar with everything that's out there. I believe the key infrastructure issues to be: 1. allow external bugzilla accounts to modify bugs in order to do triage; allow external default owners for particular components 2. externally-accessible spec file and source repository 3. externally-accessible build system 4. allow external authoring of web content One issue is already addressed, which is external development discussion; that's this list and #rhl-devel. Granted development is pretty boring right now since we're in feature freeze. Havoc From john at radiomind.com Sat Aug 16 00:28:00 2003 From: john at radiomind.com (John Beimler) Date: Fri, 15 Aug 2003 20:28:00 -0400 Subject: RHL Project Status? -- It appears stalled at the moment In-Reply-To: <1060990021.4847.19.camel@smoogen1.lanl.gov> References: <3F3D64F9.9060001@radiomind.com> <1060990021.4847.19.camel@smoogen1.lanl.gov> Message-ID: <3F3D7A90.6070609@radiomind.com> Stephen Smoogen wrote: > This is getting asked daily. > Must be on a different list, sorry, I don't subscribe to all of Red Hat's lists. > They are working on it. It takes time to deal with concerns from outside > parties and the fact that there are a lot of conferences in the last > month where people were at. > > Not the answer you want? So sorry. > I appreciate your polite response. Thanks for being such a good represenative for the Red Hat Linux community. If they weren't ready to do something about it, they shouldn't have announced it. The conferences didn't happen on a random dates, they are planned in advance. Red Hat should be used to working with outside parties by now, as you know, they've been in business for ten years now and have worked with a lot of heavy hitters. People are looking for visible signs they are working on it. Customers are looking, and all they see is a web site that got pulled down, and a lot of whiners telling red hat how to run their business. I'm not discussing this as a technical issue, but as a marketing issue. It looks bad. People were all ready to jump in and help, and now thats wearing off as nothing happens. From where I am it looks like a lot of vaopr. I want to see this work, and I know the developers at red hat do too, but all the waiting and thrashing is only chasing more and more people and corporate participants away. Peace. john From hbo at egbok.com Sat Aug 16 01:07:59 2003 From: hbo at egbok.com (Howard Owen) Date: 15 Aug 2003 18:07:59 -0700 Subject: RHL Project Status? -- It appears stalled at the moment In-Reply-To: <3F3D7A90.6070609@radiomind.com> References: <3F3D64F9.9060001@radiomind.com> <1060990021.4847.19.camel@smoogen1.lanl.gov> <3F3D7A90.6070609@radiomind.com> Message-ID: <2c58g6$1gfvp8@sj-iport-1.cisco.com> Read Havoc Pennington's answer. It's reasonable, and I believe he's telling the truth. If he is, what's the beef? Obviously there was some confusion at Red Hat in that there was an announcement and a website launched that later got taken down. But the message is still a very good one coming from a company that has held its own counsel regarding the distribution for many years. Havoc's suggestion that you check out the Fedora project (http://www.fedora.us) is also very good. Those guys are developing packaging standards that are likely to be close to those the new RHL project will use. If you can get your package in there, you'll have a leg up, and it'll keep you busy while you wait for RHL to launch. Regarding vaporware, from this outsider's perspective, opening up the "consumer" distro (there's got to be a better term for it than that) appears strategic for Red Hat. They need to engage the broader Open Source community, and the way to do that is through opening their process. It's strategic because that community is the life's blood of their business. I know a lot of Linux geeks who hated the idea of RHEL with the prices being asked by Red Hat. But the enterprise initiative, in which Red Hat is selling relationships, not bits, allows them pursue the enterprise business and make profits, which will keep them a going concern. This means that all the great engineering they do will continue to benefit the broader community since the RHEL work is mostly GPLd. On the other hand, opening up the non-Enterprise distro gives us all a field in which to play in return. Vaporware is a product announcement, for something you don't have, intended to freeze your market. Microsoft is a past master at this. That's not what Red Hat has done here. They've announced a strategic realignment of their relationship with the Open Source community, that benefits that community significantly. Giving them a little time to get such a major change done right is common sense.. On Fri, 2003-08-15 at 17:28, John Beimler wrote: > Stephen Smoogen wrote: > > This is getting asked daily. > > > Must be on a different list, sorry, I don't subscribe to all of Red > Hat's lists. > > > They are working on it. It takes time to deal with concerns from outside > > parties and the fact that there are a lot of conferences in the last > > month where people were at. > > > > Not the answer you want? So sorry. > > > > I appreciate your polite response. Thanks for being such a good > represenative for the Red Hat Linux community. > > If they weren't ready to do something about it, they shouldn't have > announced it. The conferences didn't happen on a random dates, they are > planned in advance. Red Hat should be used to working with outside > parties by now, as you know, they've been in business for ten years now > and have worked with a lot of heavy hitters. > > People are looking for visible signs they are working on it. Customers > are looking, and all they see is a web site that got pulled down, and a > lot of whiners telling red hat how to run their business. > > I'm not discussing this as a technical issue, but as a marketing issue. > It looks bad. People were all ready to jump in and help, and now thats > wearing off as nothing happens. > > From where I am it looks like a lot of vaopr. I want to see this work, > and I know the developers at red hat do too, but all the waiting and > thrashing is only chasing more and more people and corporate > participants away. > > > Peace. > > john > > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list > From tcallawa at redhat.com Sat Aug 16 05:00:11 2003 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: 16 Aug 2003 00:00:11 -0500 Subject: RHL Project Status? -- It appears stalled at the moment In-Reply-To: <1060996079.3181.21.camel@sivakuma-lnx.cisco.com> References: <3F3D64F9.9060001@radiomind.com> <1060990021.4847.19.camel@smoogen1.lanl.gov> <3F3D7A90.6070609@radiomind.com> <1060996079.3181.21.camel@sivakuma-lnx.cisco.com> Message-ID: <1061010011.7883.20.camel@zorak> On Fri, 2003-08-15 at 20:07, Howard Owen wrote: > This means that all the great engineering they do will > continue to benefit the broader community since the RHEL work is mostly > GPLd. Minor correction: All Red Hat work done on RHEL is GPL'd. In fact, all of RHEL has source code available for download, with the sole exception of the IBM/Sun Java implementations. I personally found it odd that Mr. Perens chose to single out RHEL as a "Proprietary Open Source" offering, when our competitors in the Enterprise Linux space include proprietary applications and code, and only give what source is open to the customers who purchase it. Its only a little sore spot for me (no pun intended). ;) Everyone at Red Hat is very excited about the RHLP, but our timing was a little off, we jumped the gun a little bit. The core tenets that we announced originally are still going to be the same, we just need to make sure we have all our i's dotted and t's crossed. Be patient with us, we want this to roll into full swing as much as you do. ~spot --- Tom "spot" Callaway SAIR LCA, RHCE Red Hat Enterprise Architect :: http://www.redhat.com Project Leader for Aurora Sparc Linux :: http://auroralinux.org GPG: D786 8B22 D9DB 1F8B 4AB7 448E 3C5E 99AD 9305 4260 The words and opinions reflected in this message do not necessarily reflect those of my employer, Red Hat, and belong solely to me. "Immature poets borrow, mature poets steal." --- T. S. Eliot From riel at redhat.com Sat Aug 16 14:18:40 2003 From: riel at redhat.com (Rik van Riel) Date: Sat, 16 Aug 2003 10:18:40 -0400 (EDT) Subject: dependency tool for RedHat In-Reply-To: Message-ID: On Fri, 8 Aug 2003, Chuck Wolber wrote: > > > > RedHat Linux is one of the last modern linux distributions not to > > > > have a dependency tool like apt-get, urpmi or autopkg included in > > > > the default intstallation. > > > > up2date has been available since 6.2 I believe. Do you even use Red Hat? > > up2date is not an appropriate tool for resolving dependencies. I would have to agree here. The way up2date behaves when the repository is 100% correct is wonderful, but the moment there are missing dependencies or inconsistencies in the repository the user will have to unselect packages by hand until things work. No such thing as up2date --fix-missing (yet?) ... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From skvidal at phy.duke.edu Sat Aug 16 16:36:44 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 16 Aug 2003 12:36:44 -0400 Subject: dependency tool for RedHat In-Reply-To: References: Message-ID: <1061051804.3505.145.camel@binkley> On Sat, 2003-08-16 at 10:18, Rik van Riel wrote: > On Fri, 8 Aug 2003, Chuck Wolber wrote: > > > > > > RedHat Linux is one of the last modern linux distributions not to > > > > > have a dependency tool like apt-get, urpmi or autopkg included in > > > > > the default intstallation. > > > > > > up2date has been available since 6.2 I believe. Do you even use Red Hat? > > > > up2date is not an appropriate tool for resolving dependencies. > > I would have to agree here. The way up2date behaves when the > repository is 100% correct is wonderful, but the moment there > are missing dependencies or inconsistencies in the repository > the user will have to unselect packages by hand until things > work. so I'm confused - what would you have it do when it can't find a dependency in any of the provided repository? Say for example some package needs libfoo.so.1. Nothing provides that, up2date and yum and apt will all give you a big " I dunno, looks like you need something that provides libfoo.so.1" Is there another way of resolving this you can think of? -sv From smoogen at lanl.gov Sat Aug 16 23:55:55 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Sat, 16 Aug 2003 17:55:55 -0600 (MDT) Subject: RHL Project Status? -- It appears stalled at the moment In-Reply-To: <3F3D7A90.6070609@radiomind.com> Message-ID: On Fri, 15 Aug 2003, John Beimler wrote: >Stephen Smoogen wrote: >> This is getting asked daily. >> >Must be on a different list, sorry, I don't subscribe to all of Red >Hat's lists. > >> They are working on it. It takes time to deal with concerns from outside >> parties and the fact that there are a lot of conferences in the last >> month where people were at. >> >> Not the answer you want? So sorry. >> > >I appreciate your polite response. Thanks for being such a good >represenative for the Red Hat Linux community. Your welcome, thankyou for writing a letter that was so fairly balanced and un-critical of any possible problems. I am tired of letters that demand perfection from someone else. No one is perfect.. we all make mistakes, but we all seem to want to take the easy route and demand the impossible from others instead of working on ourselves. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 5-8058 Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From ckloiber at redhat.com Sun Aug 17 01:09:34 2003 From: ckloiber at redhat.com (Chris Kloiber) Date: Sat, 16 Aug 2003 21:09:34 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <20030813143034.B5175@redhat.com> References: <20030812231944.E27241@redhat.com> <20030813133205.3953ef48.seanlkml@rogers.com> <20030813143034.B5175@redhat.com> Message-ID: <1061082574.4530.14.camel@luser.ckloiber.com> On Wed, 2003-08-13 at 14:30, Adrian Likins wrote: > On Wed, Aug 13, 2003 at 01:32:05PM -0400, Sean Estabrooks wrote: > > On Tue, 12 Aug 2003 23:19:44 -0400 > > Adrian Likins wrote: > > > > > > > > http://people.redhat.com/~alikins/up2date/severn/ > > > > > > New up2date for testing. Somewhat notable new > > > feature of support for 3rd party yum and apt > > > repos. See /etc/sysconfig/rhn/sources for info > > > on configuring them (docs to come). > > > > > > In addition to the apt/yum repos, it also > > > now supports using a local dir of rpms as > > > a "repo" > > > > > > Feedback appreciated (usually ;-> ) > > > > > > > > > > Must one register with redhat to use up2date against a local repo? > > > Yes. At the moment at least, though I don't have any > plans to change that at this point. > > > One problem i had was caused by an old systemid file from the 7.3 era. > > No matter what i typed i got the error shown below. It would be nice > > if rhn_register had a --force option or even better ask if it should > > ignore or use the the current systemid file. > > > `up2date --register` or `rhn_register --register` will > "force" a reregister. > > Adrian A few little problems I noted, first was that the file sizes of any packages from an apt or yum repo are listed as '0', which made me hesitate to install from them until I verified I was getting real files. Second, it might be nice to have up2date offer to download the GPG-KEY from those apt and yum repos that support GPG, of course that might require mods to apt and yum first, or you could assume the GPG key to be at the same location as the repository. Lastly, I noticed that freshrpms has an apt/yum rawhide channel with newer packages than I had installed. I had noted the anaconda package with a version of 9.0.94. I used up2date-config to change the versionOverride=9.0.94 in the hopes that there was an official channel. I was wrong of course, and it prevented both up2date and up2date-config from running. I had to edit the config file manually to recover from my stupidity. I don't think up2date-config should require you to be in a valid channel to start up and change settings. You want these in Bugzilla, I presume? -- Chris Kloiber Red Hat, Inc. From jensknutson at yahoo.com Sun Aug 17 03:27:29 2003 From: jensknutson at yahoo.com (Jens Knutson) Date: 16 Aug 2003 22:27:29 -0500 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) Message-ID: <1061090849.26667.36.camel@binah.upevil.net> [Whoops.. I sent this directly to Garrett a few days ago, meant it to go to the list. Anyhow, here goes...] The new Bluecurve looks very nice, espcially the "Slate" variant! I did have a couple things that I thought need attention, though... * the stock mime type icons have one major annoyance - despite their otherwise very pleasing appearance, they all seem to use the awful (IMHO) "piece of paper" anachronism. The HIG does a great job of explaining why this is a Bad Idea(TM) here: http://developer.gnome.org/projects/gup/hig/1.0/icons.html#document_icons Is there a particular reason for using the "piece of paper" idea, or is it just because it's a (unfortunate) de-facto standard? * the new color variants on Bluecurve are cool, but what happened to that nice yellowish theme from back in the Bluecurve .5x days? I was rather fond of that... any chance that'll go back in? * the new Metacity theme also looks great, but the new, smaller buttons are not Fitt's Law compliant - the buttons really ought to stretch to the edges of the window border, despite the fact that it looks much better the way you're doing it now... :-/ * all menus now have a thick border around them - this also creates Fitt's Law problems. For example - open Epiphany, visit a few websites, and then right-click to get the context menu, and hit the "Back" menu entry. You'll have to move your mouse to get to the target. If the border weren't there (like in older versions of Bluecurve!), you'd already be at your target, and would only have to click. * Finally, Bluecurve could use a few more... well, curves? The new curved bottom window corners look awesome, but what about the widgets? They're so straight-edge and right-angled. Ximian's Industrial is a nice compromise between softer, rounded edges, and maintaining a professional look, and Mandrake's Galaxy theme isn't too bad in this regard either. Toning down Bluecurve's harsh edges might be a nice enhancement. That's it! I wish I could to more than just complain, but I've got approximately *zero* art skill. ;-) I hope this feedback is useful to you - let me know if you want me to bugzilla all this stuff! Thanks, - jck -- "The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." - George Bernard Shaw From pmatilai at welho.com Sun Aug 17 10:13:45 2003 From: pmatilai at welho.com (Panu Matilainen) Date: 17 Aug 2003 13:13:45 +0300 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <1061082574.4530.14.camel@luser.ckloiber.com> References: <20030812231944.E27241@redhat.com> <20030813133205.3953ef48.seanlkml@rogers.com> <20030813143034.B5175@redhat.com> <1061082574.4530.14.camel@luser.ckloiber.com> Message-ID: <1061115225.4478.20.camel@chip.ath.cx> On Sun, 2003-08-17 at 04:09, Chris Kloiber wrote: > > A few little problems I noted, first was that the file sizes of any > packages from an apt or yum repo are listed as '0', which made me > hesitate to install from them until I verified I was getting real files. > Second, it might be nice to have up2date offer to download the GPG-KEY > from those apt and yum repos that support GPG, of course that might > require mods to apt and yum first, or you could assume the GPG key to be > at the same location as the repository. Note that apt itself doesn't understand about signed *packages*, that's achieved with scripts (lua in Fedora's apt, others can be used as well). Apt does however have notion of signed *repositories*, meaning the package lists can be GPG-signed and verified from the release file in the repo against GPG-fingerprints found in /etc/apt/vendors.list. - Panu - From ckloiber at redhat.com Sun Aug 17 14:12:19 2003 From: ckloiber at redhat.com (Chris Kloiber) Date: Sun, 17 Aug 2003 10:12:19 -0400 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <1061115225.4478.20.camel@chip.ath.cx> References: <20030812231944.E27241@redhat.com> <20030813133205.3953ef48.seanlkml@rogers.com> <20030813143034.B5175@redhat.com> <1061082574.4530.14.camel@luser.ckloiber.com> <1061115225.4478.20.camel@chip.ath.cx> Message-ID: <1061129539.1290.26.camel@luser.ckloiber.com> On Sun, 2003-08-17 at 06:13, Panu Matilainen wrote: > On Sun, 2003-08-17 at 04:09, Chris Kloiber wrote: > > > > > A few little problems I noted, first was that the file sizes of any > > packages from an apt or yum repo are listed as '0', which made me > > hesitate to install from them until I verified I was getting real files. > > Second, it might be nice to have up2date offer to download the GPG-KEY > > from those apt and yum repos that support GPG, of course that might > > require mods to apt and yum first, or you could assume the GPG key to be > > at the same location as the repository. > > Note that apt itself doesn't understand about signed *packages*, that's > achieved with scripts (lua in Fedora's apt, others can be used as well). > Apt does however have notion of signed *repositories*, meaning the > package lists can be GPG-signed and verified from the release file in > the repo against GPG-fingerprints found in /etc/apt/vendors.list. > > - Panu - Well I meant the GPG-KEY that the packages were signed with for the purposes on not having up2date complain about them not having a "valid" (as in the local keyring has a copy) key so you don't have to click "yes" to continue all the time. Apt doesn't really need to know about the GPG key at all, (but it would be nice) -- Chris Kloiber Red Hat, Inc. From pmatilai at welho.com Sun Aug 17 14:17:23 2003 From: pmatilai at welho.com (Panu Matilainen) Date: 17 Aug 2003 17:17:23 +0300 Subject: up2date for testing (with apt/yum/dir repo support) In-Reply-To: <1061129539.1290.26.camel@luser.ckloiber.com> References: <20030812231944.E27241@redhat.com> <20030813133205.3953ef48.seanlkml@rogers.com> <20030813143034.B5175@redhat.com> <1061082574.4530.14.camel@luser.ckloiber.com> <1061115225.4478.20.camel@chip.ath.cx> <1061129539.1290.26.camel@luser.ckloiber.com> Message-ID: <1061129841.4478.99.camel@chip.ath.cx> On Sun, 2003-08-17 at 17:12, Chris Kloiber wrote: > On Sun, 2003-08-17 at 06:13, Panu Matilainen wrote: > > On Sun, 2003-08-17 at 04:09, Chris Kloiber wrote: > > > > > > > > A few little problems I noted, first was that the file sizes of any > > > packages from an apt or yum repo are listed as '0', which made me > > > hesitate to install from them until I verified I was getting real files. > > > Second, it might be nice to have up2date offer to download the GPG-KEY > > > from those apt and yum repos that support GPG, of course that might > > > require mods to apt and yum first, or you could assume the GPG key to be > > > at the same location as the repository. > > > > Note that apt itself doesn't understand about signed *packages*, that's > > achieved with scripts (lua in Fedora's apt, others can be used as well). > > Apt does however have notion of signed *repositories*, meaning the > > package lists can be GPG-signed and verified from the release file in > > the repo against GPG-fingerprints found in /etc/apt/vendors.list. > > > > - Panu - > > Well I meant the GPG-KEY that the packages were signed with for the > purposes on not having up2date complain about them not having a "valid" > (as in the local keyring has a copy) key so you don't have to click > "yes" to continue all the time. Apt doesn't really need to know about > the GPG key at all, (but it would be nice) Sure, would be nice. Something to consider for the common repository metadata thingy: how to find the GPG key(s) used to sign the packages in repository X. - Panu - From chris at webarchitects.co.uk Sun Aug 17 21:53:12 2003 From: chris at webarchitects.co.uk (Chris Croome) Date: Sun, 17 Aug 2003 22:53:12 +0100 Subject: RHL Project Status? -- It appears stalled at the moment In-Reply-To: <20030815194701.A10042@devserv.devel.redhat.com> References: <3F3D64F9.9060001@radiomind.com> <20030815194701.A10042@devserv.devel.redhat.com> Message-ID: <20030817215312.GA21212@webarchitects.co.uk> Hi On Fri 15-Aug-2003 at 07:47:01PM -0400, Havoc Pennington wrote: > > I believe the key infrastructure issues to be: > > 4. allow external authoring of web content A Wiki with versioning might be good for some if not all of the web site? Chris -- Chris Croome web design http://www.webarchitects.co.uk/ web content management http://mkdoc.com/ From thomas at apestaart.org Sun Aug 17 22:57:12 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 18 Aug 2003 00:57:12 +0200 Subject: serial driver and lirc Message-ID: <1061161031.9171.2.camel@thocra> Hi, I would like to get lirc into the main distribution, as well as some of the kernel modules for it. For me personally there's only one blocker; I have a bunch of soldered receivers that work with the COM port. However, for that to work, the serial driver needs to be compiled as a module. AFAIK, in Red Hat kernels it's always compiled in. The only thing I could think of that would require it to be compiled in, is kernel debugging over a serial link. Can someone tell me what would be the objections of making the serial driver module in the mainline Red Hat kernel, so the lirc driver can be easily provided for stock kernels ? Thanks Thomas Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> If you want love we'll make it <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ From sharuzzaman at netscape.net Mon Aug 18 08:15:50 2003 From: sharuzzaman at netscape.net (Sharuzzaman Ahmat Raslan) Date: Mon, 18 Aug 2003 04:15:50 -0400 Subject: Red Hat Linux Arabic Localization Project Message-ID: <2088966D.31916453.51F8F3BC@netscape.net> Are you planning to include other Arabic character language such as the Old Malay (Jawi)? There are several people in Malaysia that are interested on having a Jawi-enabled Linux, but the problem is they are not really sure how to do it properly (the font, the encoding, the input method, etc.) I hope you can put this issue in your thought list, so that they can learn how to experiment with the Arabic localization. "Sherif R. Abdelgawad" wrote: > >With the help of Linux-ME.org (Linux Middle East), Linux-Egypt.org (LUG), >and ITI (Information Technology Institute)in Egypt (http://www.iti.gov.eg ), >a project for providing Arabic Support to RHL. > >The aim of this project is to collect the efforts and contribute in RHL >to solve the issues and problems wrt full arabic support in RHL (right-to-left, >fotns, rendering ...etc). > >An initial page for the project, with call for participation is located at: > >http://www.linux-me.org/ > >This effort also includes proper translation, validate the already translation >efforts and provide standard good translation as well as put the efforts to >solve the technical issues wrt to Arabic. > >Cheers, > >-Sherif > > >-- >Rhl-devel-list mailing list >Rhl-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/rhl-devel-list > -- ------------------------ Sharuzzaman Ahmat Raslan __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 From johnsonm at redhat.com Mon Aug 18 13:32:49 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 18 Aug 2003 09:32:49 -0400 Subject: Bug 69903 newt -- Why no progress? In-Reply-To: <20030807175105.GQ23903@rednote.net>; from janina@rednote.net on Thu, Aug 07, 2003 at 01:51:06PM -0400 References: <1060176206.20277.12.camel@ip68-12-228-23.ok.ok.cox.net> <1060177024.6347.4.camel@one.myworld> <1060223689.20277.55.camel@ip68-12-228-23.ok.ok.cox.net> <20030807122920.A16702@devserv.devel.redhat.com> <3F32807D.1010503@micromuse.com> <20030807175105.GQ23903@rednote.net> Message-ID: <20030818093249.A16286@devserv.devel.redhat.com> Because this is a development issue, please followup to rhl-devel-list. On Thu, Aug 07, 2003 at 01:51:06PM -0400, Janina Sajka wrote: > The cursor tracking problem first reported against newt well over a year > ago, and recently re-opened as the community of blind users tracked down > the problem and created the resolution patch, continues unresolved as > shown by Bugzilla just a few moments ago. May I point out that this fix > is extremely important to thousands of users of Speakup worldwide? > > So, is there a problem with the fix submitted? It would be most helpful > to have newt working properly in Cambridge. The problem is, I think, reviewing it to make sure that it doesn't break anything else. A description of exactly why the change is a fix can help for things like this. - newtGotorc(co->top + (li->currItem - li->startShowItem) + 1, co->left + 1);+ newtGotorc(co->top + (li->currItem - li->startShowItem) + li->bdyAdjust, + co->left + li->bdxAdjust); I note that bdxAdjust is set only to 0 or 2, and it's not at all clear to me how changing bdxAdjust applies to this bug report from the description. It might still be correct or an improvement, but it is not clear at a short read why it is either. The change to bdyAdjust makes sense to me as a fix for this bug report. 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 johnsonm at redhat.com Mon Aug 18 13:40:35 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 18 Aug 2003 09:40:35 -0400 Subject: /usr boot time dependencies In-Reply-To: ; from paul@dishone.st on Sat, Aug 16, 2003 at 04:18:57PM +0100 References: <20030815110544.A2054@devserv.devel.redhat.com> Message-ID: <20030818094035.B16286@devserv.devel.redhat.com> Since this is really a development discussion, please followup to rhl-devel-list. Thanks! On Sat, Aug 16, 2003 at 04:18:57PM +0100, Paul Jakma wrote: > On Fri, 15 Aug 2003, Michael K. Johnson wrote: > > > That /usr is required to init IPv6 would be a bug. > > Indeed. > > [root at fogarty network-scripts]# egrep '\<(id|uniq)\>' * > init.ipv6-global: sysctl -a | grep "^net\.ipv6\.conf\." > | awk -F. '{ print $4 }' | sort | uniq | while read interface; do > init.ipv6-global: sysctl -a | grep "^net\.ipv6\.conf\." > | awk -F. '{ print $4 }' | sort | uniq | while read interface; do > init.ipv6-global: sysctl -a | grep "^net\.ipv6\.conf\." > | awk -F. '{ print $4 }' | sort | uniq | while read interface; do > network-functions: if [ "`id -u`" = "0" ]; then > > neither id nor uniq should be considered available before netfs and > autofs have run. OK, sort -u is the obvious answer IRT uniq. do_netreport will never need to call id if it doesn't exist, so ! -x /usr/bin/id -o ... should resolve that issue. > either these 2 utils should be installed to /bin, not /usr/bin (sort > is installed to /bin) or network init scripts should not use them. In these cases, the latter. > > > - portmap resides in /bin but links to libwrap.so - which is in > > > /usr/lib and may not be available. > > > > Again, a bug one way or another. > > I suggest either portmap should statically link libwrap, or > libwrap.so should install to /lib. In either case, bugzilla. :-) 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 sabdelg at redhat.com Mon Aug 18 13:55:18 2003 From: sabdelg at redhat.com (Sherif R. Abdelgawad) Date: Mon, 18 Aug 2003 09:55:18 -0400 (EDT) Subject: Red Hat Linux Arabic Localization Project In-Reply-To: <2088966D.31916453.51F8F3BC@netscape.net> References: <2088966D.31916453.51F8F3BC@netscape.net> Message-ID: <1061214918.3f40dac60ab62@mayberry.redhat.com> > Are you planning to include other Arabic character language such as the > Old Malay (Jawi)? You are most welcome to lead an effort if you would like. I am not familiar with the Jawi, and not sure what are the challanges. Is that Lang still being used in Maly? From laroche at redhat.com Mon Aug 18 14:00:00 2003 From: laroche at redhat.com (Florian La Roche) Date: Mon, 18 Aug 2003 16:00:00 +0200 Subject: /usr boot time dependencies In-Reply-To: <20030818094035.B16286@devserv.devel.redhat.com> References: <20030815110544.A2054@devserv.devel.redhat.com> <20030818094035.B16286@devserv.devel.redhat.com> Message-ID: <20030818140000.GA14659@dudweiler.stuttgart.redhat.com> > > > > - portmap resides in /bin but links to libwrap.so - which is in > > > > /usr/lib and may not be available. > > > > > > Again, a bug one way or another. > > > > I suggest either portmap should statically link libwrap, or > > libwrap.so should install to /lib. > > In either case, bugzilla. :-) It has been changed to link statically against portmap and don't use "id" in the initscripts. Not really a very nice setup to have it statically linked, I really think more longterm we should nuke tcp_wrappers. greetings, Florian La Roche From dwalsh at redhat.com Mon Aug 18 14:03:50 2003 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 18 Aug 2003 10:03:50 -0400 Subject: APT, Yum and Red Carpet In-Reply-To: <20030813151526.A12687@devserv.devel.redhat.com> References: <200308121710.h7CHAwD17778@devserv.devel.redhat.com> <20030813140551.GS3676@shitake.truemesh.com> <20030813151526.A12687@devserv.devel.redhat.com> Message-ID: <3F40DCC6.4010200@redhat.com> A lot of the userspace changes are in the SRPMs but turned off. You can rebuild using rpmbuild --define "WITH_SELINUX 1" XYZ.rpm to activate the changes. The SELinux userspace packages are available on ftp://people.redhat.com/dwalsh/SELinux/packages This stuff is very experimental. The code checks to see if there is an SELinux aware kernel, if not it should work just like the non patched code. Any help would be appreciated. Dan Michael K. Johnson wrote: >On Wed, Aug 13, 2003 at 03:05:52PM +0100, Paul Nasrat wrote: > > >>On Wed, Aug 13, 2003 at 07:52:57AM -0600, Chris Ricker wrote: >> >> >>> >>> >>> >> >> >> >>>Speaking of which, is there any interest in incorporating RSBAC (preferably) >>>or SELinux into RHLP, long-term? >>> >>> >>SELinux architecture has been merged in 2.6.0-test3, so I imagine that >>Cambridge++ will have that SELinux in it. >> >> > >Well, the technology exists in the kernel source tree, and we >encouraged its inclusion in the mainline tree. But SELinux has >other components, particularly userland code changes and policy. >Policy management is a major job in and of itself. Also, there's >a performance cost to enabling SELinux that needs to be considered. > >As I've mentioned before, upstream acceptance is a key point; this >distinguishes SELinux. In addition, Red Hat is specifically working >on SELinux, as mentioned in a webcast we did recently: >https://www.redhat.com/apps/webform.html?event_type=webcast&eid=225 >And the top search response on SELinux on our web site is this page: >http://www.redhat.com/solutions/security/SELinux.html > >We haven't made a committment to include SELinux in Cambridge++, >nor to not include it. :-) We're certainly actively working on >SELinux, and if there are like-minded developers who want to, say, >participate with us in doing policy work, speak up, and maybe it >will make sense. > >I'm personally curious: how many people on this list have worked on >SELinux policy and/or policy tools? > >michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > >-- >Rhl-devel-list mailing list >Rhl-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/rhl-devel-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauln at truemesh.com Mon Aug 18 14:25:15 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Mon, 18 Aug 2003 15:25:15 +0100 Subject: APT, Yum and Red Carpet In-Reply-To: <3F40DCC6.4010200@redhat.com> References: <200308121710.h7CHAwD17778@devserv.devel.redhat.com> <20030813140551.GS3676@shitake.truemesh.com> <20030813151526.A12687@devserv.devel.redhat.com> <3F40DCC6.4010200@redhat.com> Message-ID: <20030818142514.GD27789@shitake.truemesh.com> On Mon, Aug 18, 2003 at 10:03:50AM -0400, Daniel J Walsh wrote: > A lot of the userspace changes are in the SRPMs but turned off. You can > rebuild using > rpmbuild --define "WITH_SELINUX 1" XYZ.rpm to activate the changes. The > SELinux > userspace packages are available on > > ftp://people.redhat.com/dwalsh/SELinux/packages policy requires checkpolicy and doesn't let you build as non-root. I'm just starting to play so this could be misplaced but I don't like rpmbuild's messing with the root filesystem :) Speculative patch, yell if you want it bugzilla'd. Paul -------------- next part -------------- --- ./policy.spec.orig 2003-07-23 19:37:32.000000000 +0100 +++ ./policy.spec 2003-08-18 15:25:20.000000000 +0100 @@ -1,13 +1,15 @@ Summary: SELinux example policy configuration Name: policy Version: 1.1 -Release: 1 +Release: 2 License: GPL Group: System Environment/Base Source: http://www.nsa.gov/selinux/archives/policy-1.1.tgz Prefix: %{_prefix} BuildRoot: %{_tmppath}/%{name}-buildroot BuildArch: noarch +BuildRequires: checkpolicy +BuildRequires: perl Requires: checkpolicy %description @@ -27,9 +29,10 @@ %prep %setup -q +perl -pi -e 's/-o root -g root//' Makefile %build -make +make policy %install rm -rf ${RPM_BUILD_ROOT} @@ -63,6 +66,9 @@ %{_sysconfdir}/security/selinux/src/policy/* %changelog +* Mon Aug 18 2003 Paul Nasrat 2.5-2 +- Enable non-root build + * Mon Jun 2 2003 Dan Walsh 2.5-1 - Initial version From johnsonm at redhat.com Mon Aug 18 15:10:47 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 18 Aug 2003 11:10:47 -0400 Subject: RHL Project Status? -- It appears stalled at the moment In-Reply-To: <20030817215312.GA21212@webarchitects.co.uk>; from chris@webarchitects.co.uk on Sun, Aug 17, 2003 at 10:53:12PM +0100 References: <3F3D64F9.9060001@radiomind.com> <20030815194701.A10042@devserv.devel.redhat.com> <20030817215312.GA21212@webarchitects.co.uk> Message-ID: <20030818111047.A9513@devserv.devel.redhat.com> On Sun, Aug 17, 2003 at 10:53:12PM +0100, Chris Croome wrote: > A Wiki with versioning might be good for some if not all of the web > site? Yeah, it might. A wiki has definitely been one of the things that we've been considering. One of the areas that seemed particularly useful for a wiki is a shared space for discussing hardware {,in}compatibility, but others are possible as well. But it will be a bit yet. One step at a time... 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 johnsonm at redhat.com Mon Aug 18 15:12:26 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 18 Aug 2003 11:12:26 -0400 Subject: serial driver and lirc In-Reply-To: <1061161031.9171.2.camel@thocra>; from thomas@apestaart.org on Mon, Aug 18, 2003 at 12:57:12AM +0200 References: <1061161031.9171.2.camel@thocra> Message-ID: <20030818111226.B9513@devserv.devel.redhat.com> On Mon, Aug 18, 2003 at 12:57:12AM +0200, Thomas Vander Stichele wrote: > However, for that to work, the serial driver needs to be compiled as a > module. AFAIK, in Red Hat kernels it's always compiled in. > > The only thing I could think of that would require it to be compiled in, > is kernel debugging over a serial link. Serial console from initial boot is in fact critical to our ability to debug user problems. You have answered your own question. 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 thomas at apestaart.org Mon Aug 18 15:46:28 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 18 Aug 2003 17:46:28 +0200 Subject: serial driver and lirc In-Reply-To: <20030818111226.B9513@devserv.devel.redhat.com> References: <1061161031.9171.2.camel@thocra> <20030818111226.B9513@devserv.devel.redhat.com> Message-ID: <1061221587.2273.7.camel@thocra> On Mon, 2003-08-18 at 17:12, Michael K. Johnson wrote: > On Mon, Aug 18, 2003 at 12:57:12AM +0200, Thomas Vander Stichele wrote: > > However, for that to work, the serial driver needs to be compiled as a > > module. AFAIK, in Red Hat kernels it's always compiled in. > > > > The only thing I could think of that would require it to be compiled in, > > is kernel debugging over a serial link. > > Serial console from initial boot is in fact critical to our ability > to debug user problems. You have answered your own question. major suckage then :) So, failing that, is there (I'm speaking theoretically here, I'm not a kernel hacker) some way that the kernel could grab serial at boot time, but release it when the boot has finished and the rest of the system is started ? I somehow somewhere feel that this might be possible :) If it is, would something like that be considered if someone did the code ? Thomas > michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> Cause baby ooh if heaven calls I'm coming too Just like you said You leave my life I'm better off dead <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ From johnsonm at redhat.com Mon Aug 18 16:13:34 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 18 Aug 2003 12:13:34 -0400 Subject: serial driver and lirc In-Reply-To: <1061221587.2273.7.camel@thocra>; from thomas@apestaart.org on Mon, Aug 18, 2003 at 05:46:28PM +0200 References: <1061161031.9171.2.camel@thocra> <20030818111226.B9513@devserv.devel.redhat.com> <1061221587.2273.7.camel@thocra> Message-ID: <20030818121334.C9513@devserv.devel.redhat.com> On Mon, Aug 18, 2003 at 05:46:28PM +0200, Thomas Vander Stichele wrote: > major suckage then :) So, failing that, is there (I'm speaking > theoretically here, I'm not a kernel hacker) some way that the kernel > could grab serial at boot time, but release it when the boot has > finished and the rest of the system is started ? I somehow somewhere > feel that this might be possible :) If it is, would something like that > be considered if someone did the code ? We could consider it if it were accepted upstream and didn't cause other trouble I haven't thought of here... :-) 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 johnsonm at redhat.com Mon Aug 18 18:41:00 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 18 Aug 2003 14:41:00 -0400 Subject: Goats... [was: Include OpenOffice.org 1.1 in Severn?] In-Reply-To: <1060982877.5914.4.camel@banff.drgutah.com>; from jsmith@drgutah.com on Fri, Aug 15, 2003 at 03:27:57PM -0600 References: <1060946720.14255.15.camel@guru.puzzled.xs4all.nl> <20030815101732.E17414@devserv.devel.redhat.com> <200308151219.05340.hoyt@cavtel.net> <20030815152410.E13852@devserv.devel.redhat.com> <1060978920.29829.402.camel@opus.phy.duke.edu> <20030815163853.G16406@devserv.devel.redhat.com> <1060982164.4847.7.camel@smoogen1.lanl.gov> <1060982877.5914.4.camel@banff.drgutah.com> Message-ID: <20030818144100.A30036@devserv.devel.redhat.com> I suppose this is going off in the direction of being a development-related discussion, so rhl-devel-list is probably the best place to discuss it. On Fri, Aug 15, 2003 at 03:27:57PM -0600, Jared Smith wrote: > Actually, I was just wondering... What parts of Red Hat Linux require > the most work to get ready for a new version? Is there anything mere > mortals like myself can do to help out the situation, with a little > effort, in our spare time? Hmm. One of the things that fits the "spare time" model better than trying to contribute to packaging is probably bugzilla triage. In particular, looking for dups, bugs filed against the wrong component, and bugs that need more info would be quite helpful. When you have a set of duplicate bugs, the first thing to do is to find not the earliest report of the bug, but the clearest one with the most information. This is often not the earliest report; if it were, chances are better it would have been resolved already. Then mark the other bugs as duplicates of the best report, with like "this bug might be a duplicate of bug #nnnnn". If you use that exact form, "bug #" followed by the bug number, bugzilla will helpfully convert the text into a hyperlink. :-) When you are looking for bugs filed against the wrong component, there are two possibilities: bugs that filed against 4suite (the first component in the list) and bugs that are more subtly wrong. Common "subtle wrongness" includes bugs filed against mount, pppd, acpid, etc. that are really kernel bugs (and vice versa), and bugs filed against applications that are really in libraries used by the applications. Bugs that need more info are often "foo breaks" without much more information. If you see a vague bug report that you know how to get more information on, you can chime in and politely suggest some ways to get more information. If you can actually reproduce the bug, providing more information, especially on how to reproduce it, is wonderful. If you are a developer, you can even write candidate patches. When you have one, please feel free to bring it to rhl-devel-list for discussion if the bug owner doesn't respond within a few business days. The GNOME triage guidelines are at http://developer.gnome.org/projects/bugsquad/triage/ and aren't bad reading, though our process is a bit different. We should probably write up our own triage guidelines; I guess this email (and perhaps a thread it might spawn) could be the start of that. 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 aaron.bennett at olin.edu Mon Aug 18 18:57:06 2003 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Mon, 18 Aug 2003 14:57:06 -0400 Subject: Goats... [was: Include OpenOffice.org 1.1 in Severn?] In-Reply-To: <20030818144100.A30036@devserv.devel.redhat.com> References: <1060946720.14255.15.camel@guru.puzzled.xs4all.nl> <20030815101732.E17414@devserv.devel.redhat.com> <200308151219.05340.hoyt@cavtel.net> <20030815152410.E13852@devserv.devel.redhat.com> <1060978920.29829.402.camel@opus.phy.duke.edu> <20030815163853.G16406@devserv.devel.redhat.com> <1060982164.4847.7.camel@smoogen1.lanl.gov> <1060982877.5914.4.camel@banff.drgutah.com> <20030818144100.A30036@devserv.devel.redhat.com> Message-ID: <3F412182.5090204@olin.edu> This is very interesting. I hope someone is writing a quick "how-to: participate in the Red Hat development process" or something similar, with instructions for using bugzilla, the URL to red hat's bugzilla server, who to contact for logins, policies on cvs access, as well as red-hat specific triage procedures, etc. Michael K. Johnson wrote: >I suppose this is going off in the direction of being a development-related >discussion, so rhl-devel-list is probably the best place to discuss it. > >On Fri, Aug 15, 2003 at 03:27:57PM -0600, Jared Smith wrote: > > >>Actually, I was just wondering... What parts of Red Hat Linux require >>the most work to get ready for a new version? Is there anything mere >>mortals like myself can do to help out the situation, with a little >>effort, in our spare time? >> >> > >Hmm. One of the things that fits the "spare time" model better than >trying to contribute to packaging is probably bugzilla triage. In >particular, looking for dups, bugs filed against the wrong component, >and bugs that need more info would be quite helpful. > >When you have a set of duplicate bugs, the first thing to do is >to find not the earliest report of the bug, but the clearest one >with the most information. This is often not the earliest report; >if it were, chances are better it would have been resolved already. >Then mark the other bugs as duplicates of the best report, with >like "this bug might be a duplicate of bug #nnnnn". If you use >that exact form, "bug #" followed by the bug number, bugzilla will >helpfully convert the text into a hyperlink. :-) > >When you are looking for bugs filed against the wrong component, >there are two possibilities: bugs that filed against 4suite (the >first component in the list) and bugs that are more subtly wrong. >Common "subtle wrongness" includes bugs filed against mount, pppd, >acpid, etc. that are really kernel bugs (and vice versa), and bugs >filed against applications that are really in libraries used by >the applications. > >Bugs that need more info are often "foo breaks" without much >more information. If you see a vague bug report that you know >how to get more information on, you can chime in and politely >suggest some ways to get more information. If you can actually >reproduce the bug, providing more information, especially on >how to reproduce it, is wonderful. > >If you are a developer, you can even write candidate patches. >When you have one, please feel free to bring it to rhl-devel-list >for discussion if the bug owner doesn't respond within a few >business days. > >The GNOME triage guidelines are at >http://developer.gnome.org/projects/bugsquad/triage/ >and aren't bad reading, though our process is a bit different. >We should probably write up our own triage guidelines; I guess >this email (and perhaps a thread it might spawn) could be the >start of that. > >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/ > > >-- >Rhl-devel-list mailing list >Rhl-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/rhl-devel-list > > -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering From janina at rednote.net Mon Aug 18 19:07:20 2003 From: janina at rednote.net (Janina Sajka) Date: Mon, 18 Aug 2003 15:07:20 -0400 Subject: Bug 69903 newt -- Why no progress? In-Reply-To: <20030818093249.A16286@devserv.devel.redhat.com> References: <1060176206.20277.12.camel@ip68-12-228-23.ok.ok.cox.net> <1060177024.6347.4.camel@one.myworld> <1060223689.20277.55.camel@ip68-12-228-23.ok.ok.cox.net> <20030807122920.A16702@devserv.devel.redhat.com> <3F32807D.1010503@micromuse.com> <20030807175105.GQ23903@rednote.net> <20030818093249.A16286@devserv.devel.redhat.com> Message-ID: <20030818190719.GE17062@rednote.net> Dear Michael: May I please point out that I ask as a user, and as a disability professional on behalf of thousands of existing users--to say nothing of yet more users who won't give Red Hat the time of day right now because of issues like this? Please pardon me if this sounds harsh, but the bug report is old. And, the submitted fix is also not new. And, the need is profound--though you will not see it on a monitor. You must listen to a speech synthesizer read out the screen (or read the dots on a refreshable braille display screen) to observe the glaring problem: Now, I happen to know that Red Hat has a capable hardware speech synthesizer at its disposal, because I personally provided it free of charge for testing purposes over a year ago. Why a company with millions in annual revenue couldn't come up with $300 for a simple computer part is something I have not previously questioned. I simply provided the part. So, let me question the issue at hand. Has the fix been tested? What is the report? If there's a problem, wouldn't you agree we're entitled to know about it? And, if there isn't a problem, shouldn't the fix be in? Again, I apologize for my strident tone. I am simply unwilling to hear this fix didn't make the cut for the next release. To my mind that would be unconsionable on Red Hat's part given the circumstances. So, one more time, what's been done vis a vis this bug report? Michael K. Johnson writes: > From: "Michael K. Johnson" > > Because this is a development issue, please followup to rhl-devel-list. > > On Thu, Aug 07, 2003 at 01:51:06PM -0400, Janina Sajka wrote: > > The cursor tracking problem first reported against newt well over a year > > ago, and recently re-opened as the community of blind users tracked down > > the problem and created the resolution patch, continues unresolved as > > shown by Bugzilla just a few moments ago. May I point out that this fix > > is extremely important to thousands of users of Speakup worldwide? > > > > So, is there a problem with the fix submitted? It would be most helpful > > to have newt working properly in Cambridge. > > The problem is, I think, reviewing it to make sure that it doesn't break > anything else. A description of exactly why the change is a fix can help > for things like this. > > - newtGotorc(co->top + (li->currItem - li->startShowItem) + 1, co->left + 1);+ newtGotorc(co->top + (li->currItem - li->startShowItem) + li->bdyAdjust, > + co->left + li->bdxAdjust); > > I note that bdxAdjust is set only to 0 or 2, and it's not at all clear > to me how changing bdxAdjust applies to this bug report from the > description. It might still be correct or an improvement, but it is > not clear at a short read why it is either. > > The change to bdyAdjust makes sense to me as a fix for this bug report. > > michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > > -- > Rhl-list mailing list > Rhl-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-list -- Janina Sajka, Director Technology Research and Development Governmental Relations Group American Foundation for the Blind (AFB) Email: janina at afb.net Phone: (202) 408-8175 From thomas at apestaart.org Mon Aug 18 20:08:28 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 18 Aug 2003 22:08:28 +0200 Subject: Goats... [was: Include OpenOffice.org 1.1 in Severn?] In-Reply-To: <20030818144100.A30036@devserv.devel.redhat.com> References: <1060946720.14255.15.camel@guru.puzzled.xs4all.nl> <20030815101732.E17414@devserv.devel.redhat.com> <200308151219.05340.hoyt@cavtel.net> <20030815152410.E13852@devserv.devel.redhat.com> <1060978920.29829.402.camel@opus.phy.duke.edu> <20030815163853.G16406@devserv.devel.redhat.com> <1060982164.4847.7.camel@smoogen1.lanl.gov> <1060982877.5914.4.camel@banff.drgutah.com> <20030818144100.A30036@devserv.devel.redhat.com> Message-ID: <1061237308.366.19.camel@thocra> On Mon, 2003-08-18 at 20:41, Michael K. Johnson wrote: > When you are looking for bugs filed against the wrong component, > there are two possibilities: bugs that filed against 4suite (the > first component in the list) Seriously ? I can't help, in that case, but suggest you create a 101readthereadme module :) you'll soon enough find that all the bugs filed there are lazy files :) Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> The blood before me makes me open up my heart again And I feel it coming over like a storm again <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ From hp at redhat.com Mon Aug 18 20:27:31 2003 From: hp at redhat.com (Havoc Pennington) Date: Mon, 18 Aug 2003 16:27:31 -0400 Subject: Goats... [was: Include OpenOffice.org 1.1 in Severn?] In-Reply-To: <20030818144100.A30036@devserv.devel.redhat.com> References: <1060946720.14255.15.camel@guru.puzzled.xs4all.nl> <20030815101732.E17414@devserv.devel.redhat.com> <200308151219.05340.hoyt@cavtel.net> <20030815152410.E13852@devserv.devel.redhat.com> <1060978920.29829.402.camel@opus.phy.duke.edu> <20030815163853.G16406@devserv.devel.redhat.com> <1060982164.4847.7.camel@smoogen1.lanl.gov> <1060982877.5914.4.camel@banff.drgutah.com> <20030818144100.A30036@devserv.devel.redhat.com> Message-ID: <20030818162731.H13199@devserv.devel.redhat.com> On Mon, Aug 18, 2003 at 02:41:00PM -0400, Michael K. Johnson wrote: > When you are looking for bugs filed against the wrong component, > there are two possibilities: bugs that filed against 4suite (the > first component in the list) and bugs that are more subtly wrong. > Common "subtle wrongness" includes bugs filed against mount, pppd, > acpid, etc. that are really kernel bugs (and vice versa), and bugs > filed against applications that are really in libraries used by > the applications. Another popular choice is "file all bugs in any GTK-linked app against gnome-desktop or gnome-core components" Havoc From johnsonm at redhat.com Mon Aug 18 20:47:51 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Mon, 18 Aug 2003 16:47:51 -0400 Subject: Bug 69903 newt -- Why no progress? In-Reply-To: <20030818190719.GE17062@rednote.net>; from janina@rednote.net on Mon, Aug 18, 2003 at 03:07:20PM -0400 References: <1060176206.20277.12.camel@ip68-12-228-23.ok.ok.cox.net> <1060177024.6347.4.camel@one.myworld> <1060223689.20277.55.camel@ip68-12-228-23.ok.ok.cox.net> <20030807122920.A16702@devserv.devel.redhat.com> <3F32807D.1010503@micromuse.com> <20030807175105.GQ23903@rednote.net> <20030818093249.A16286@devserv.devel.redhat.com> <20030818190719.GE17062@rednote.net> Message-ID: <20030818164751.A15030@devserv.devel.redhat.com> On Mon, Aug 18, 2003 at 03:07:20PM -0400, Janina Sajka wrote: > May I please point out that I ask as a user, and as a disability > professional on behalf of thousands of existing users--to say nothing of > yet more users who won't give Red Hat the time of day right now because > of issues like this? I'm actually not in charge of newt, but jumped in to work on this because I care about the issue; I'm the one who asked Red Hat to host blinux-list years ago... So please cut me a little slack while I jump into something -- newt -- that I'm not normally involved in, source code that I've never read before. The closest I've gotten to newt before is using the python interface (snack.py) years ago. I gave an honest answer about what might have prevented the bug report from being expeditiously handled before. I have also been chasing this down internally, in addition to posting that initial response and doing some initial analysis and pointing out a potential question about the patch. > So, let me question the issue at hand. Has the fix been tested? What is > the report? If there's a problem, wouldn't you agree we're entitled to know > about it? And, if there isn't a problem, shouldn't the fix be in? The problem doesn't have to do with testing. This is an excellent opportunity to discuss a subtlety of development. Many times, a patch is provided which fixes the bug in question, and it is easy to determine that it fixes the bug in question, but it's still not a correct patch for one reason or another. Often it is because it introduces other bugs in other places. Fundamentally, patches require review not just for whether they fix the reported bug, but also for whether they are a correct modification. The changes to this patch were not described, it was just provided with "this patch fixes this bug". That's GREAT. It's VERY useful information. But it does not mean that it's necessarily the right patch, it does not mean that it doesn't create other bugs. The analysis is a key part of the process. The "problem" here is not a known bug; it's precisely an unknown. Speaking for myself as a developer, I can't vouch for the patch as a correct modification to newt even though I have zero doubt that it fixes the particular bug reported in 69903. I followed up with an honest expression of the remaining problem -- one of analysis -- so that other list members would have the opportunity to contribute analysis that could speed the handling of this bug report. I'm not demanding that anyone else do the analysis. I'm only making the opportunity to participate in the analysis available so that anyone -- inside our outside Red Hat -- with the desire to contribute to the analysis can speed the process. That's how our new open process works. What I did was exactly what anyone inside or outside of Red Hat who is not the package developer could do to speed resolution of a problem. Please remember that rhl-devel-list is where we're trying to have the bulk of the development discussions for the distro. This means that not every answer you see here will be complete. You should expect many emails to be part of a process of discovery. If the response to opening up our process is that everyone takes offense when partial answers are posted, it doesn't bode well for the move to open development. To be quite clear, the mail I posted here is essentially the same email (the technical analysis part, that is) that I would have sent to our internal development list to speed progress toward resolving the problem, before this list existed. Hope that helps, 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 sharuzzaman at netscape.net Tue Aug 19 01:58:52 2003 From: sharuzzaman at netscape.net (Sharuzzaman Ahmat Raslan) Date: Mon, 18 Aug 2003 21:58:52 -0400 Subject: Red Hat Linux Arabic Localization Project Message-ID: <622DB304.49C23A9E.51F8F3BC@netscape.net> The language is still used today, even though most of us will use the Romanised Malay. I will forward the info to the interested parties and ask them to join this mailing list or the one you mention in your first email. "Sherif R. Abdelgawad" wrote: > >> Are you planning to include other Arabic character language such as the >> Old Malay (Jawi)? > >You are most welcome to lead an effort if you would like. I am not >familiar with the Jawi, and not sure what are the challanges. >Is that Lang still being used in Maly? > > > >-- >Rhl-devel-list mailing list >Rhl-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/rhl-devel-list > -- ------------------------ Sharuzzaman Ahmat Raslan __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455 From blocke at shivan.org Tue Aug 19 02:24:22 2003 From: blocke at shivan.org (Bruce A. Locke) Date: Mon, 18 Aug 2003 22:24:22 -0400 Subject: Misleading message in 'su' info document Message-ID: <1061259862.6424.6.camel@localhost> I'm sure by now most of you have read the "Why GNU 'su' does not support the 'wheel' group" rant from RMS written years ago. If you have not seen it yet do a quick 'info su' and scroll down to the bottom. What surprises me is this has not been pulled from the 'su' info page years(?) after pam_wheel showed up in pam. The statement that GNU 'su' does not support the 'wheel' group may be technically true in the form shipped by the GNU but it is misleading when used in Red Hat. If I were looking for wheel support and decided to check the su info page (as suggested by the su man page) I would have read this statement and may never have figured out the functionality was actually being provided! In my opinion such historical baggage is harmful and should be pulled from at least Red Hat's copy of the 'su' info page. Any opinions? -- --------------------------------------------------------------------- Bruce A. Locke blocke at shivan.org From jeremyp at pobox.com Tue Aug 19 12:50:02 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: 19 Aug 2003 08:50:02 -0400 Subject: Misleading message in 'su' info document In-Reply-To: <1061259862.6424.6.camel@localhost> References: <1061259862.6424.6.camel@localhost> Message-ID: <1061297402.8846.3.camel@jeremy.dtcc.cc.nc.us> On Mon, 2003-08-18 at 22:24, Bruce A. Locke wrote: > I'm sure by now most of you have read the "Why GNU 'su' does not support > the 'wheel' group" rant from RMS written years ago. If you have not > seen it yet do a quick 'info su' and scroll down to the bottom. > > What surprises me is this has not been pulled from the 'su' info page > years(?) after pam_wheel showed up in pam. The statement that GNU 'su' > does not support the 'wheel' group may be technically true in the form > shipped by the GNU but it is misleading when used in Red Hat. If I were > looking for wheel support and decided to check the su info page (as > suggested by the su man page) I would have read this statement and may > never have figured out the functionality was actually being provided! > > In my opinion such historical baggage is harmful and should be pulled > from at least Red Hat's copy of the 'su' info page. > > Any opinions? I suspect this is just an oversight. Have you filed a bugzilla bug? --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 thornton at yoyoweb.com Tue Aug 19 13:55:28 2003 From: thornton at yoyoweb.com (Thornton Prime) Date: 19 Aug 2003 06:55:28 -0700 Subject: Misleading message in 'su' info document In-Reply-To: <1061297402.8846.3.camel@jeremy.dtcc.cc.nc.us> References: <1061259862.6424.6.camel@localhost> <1061297402.8846.3.camel@jeremy.dtcc.cc.nc.us> Message-ID: <1061301328.10635.13.camel@vimalakirti.anatman.org> > > In my opinion such historical baggage is harmful and should be pulled > > from at least Red Hat's copy of the 'su' info page. > > > > Any opinions? I am against any change. The default behavior is documented correctly. The fact that one can achieve a different result has nothing to do specifically with su. There are a few different ways of limiting su privileges, one being PAM, another by removing the public execute bit of su and making the file group wheel. The GNU su code itself does not impose limits, and probably never should. RMS's antecdote is amusing, and one may not agree with it, but it both states the default behavior and it provides a rationale for it. thornton From johnsonm at redhat.com Tue Aug 19 14:06:58 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 19 Aug 2003 10:06:58 -0400 Subject: Misleading message in 'su' info document In-Reply-To: <1061297402.8846.3.camel@jeremy.dtcc.cc.nc.us>; from jeremyp@pobox.com on Tue, Aug 19, 2003 at 08:50:02AM -0400 References: <1061259862.6424.6.camel@localhost> <1061297402.8846.3.camel@jeremy.dtcc.cc.nc.us> Message-ID: <20030819100658.A11834@devserv.devel.redhat.com> On Tue, Aug 19, 2003 at 08:50:02AM -0400, Jeremy Portzer wrote: > On Mon, 2003-08-18 at 22:24, Bruce A. Locke wrote: > > I'm sure by now most of you have read the "Why GNU 'su' does not support > > the 'wheel' group" rant from RMS written years ago. If you have not > > seen it yet do a quick 'info su' and scroll down to the bottom. > > > > What surprises me is this has not been pulled from the 'su' info page > > years(?) after pam_wheel showed up in pam. The statement that GNU 'su' > > does not support the 'wheel' group may be technically true in the form > > shipped by the GNU but it is misleading when used in Red Hat. If I were > > looking for wheel support and decided to check the su info page (as > > suggested by the su man page) I would have read this statement and may > > never have figured out the functionality was actually being provided! > > > > In my opinion such historical baggage is harmful and should be pulled > > from at least Red Hat's copy of the 'su' info page. > > > > Any opinions? > > I suspect this is just an oversight. Have you filed a bugzilla bug? Yes, it is an oversight. When I first added PAM support to su, I simultaneously created a patch to remove the rant and replace it with somethign meaningful. Must have been droped in the meantime. Definitely, please file a bugzilla report. 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 goeran at uddeborg.se Tue Aug 19 16:15:48 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran?= Uddeborg) Date: Tue, 19 Aug 2003 18:15:48 +0200 Subject: bug fixes/patches and developer round-trip time In-Reply-To: References: Message-ID: <16194.19764.27080.197817@uebn.uddeborg.se> Pekka Savola writes: > IMHO, in cases I've seen this, most of the time it has taken entirely too > long (even many weeks or months, even for trivial fixes). Months? That's nothing! :-) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=41991 (A local Red Hat problem, one of the patches to the upstream tar archive is broken. Bug report submitted 2001-05-23, patch provided 2001-06-13. Now it's 2003-08-19 ...) What is the oldest case with complete patch available? From jos at xos.nl Tue Aug 19 17:04:21 2003 From: jos at xos.nl (Jos Vos) Date: Tue, 19 Aug 2003 19:04:21 +0200 Subject: RPM dependency rationale (and kernel packages)? Message-ID: <200308191704.h7JH4L503670@xos037.xos.nl> Hi, Short intro: Every package provides itself implicitly, as if the line "Provides: foo = 5.0-2" was in the spec file. This means that any dependency on "foo", "foo = 5.0", or "foo = 5.0-2" is satisfied (as well as relational dependencies, like "foo >= 5.0" etc.). This is all the basic RPM dependency behaviour and pretty straightforward. It now seems that rpm also has the following behaviour: If you put an explicit "Provides" line in the spec file *omitting* the release, say "Provides: foo = 5.0", then *any* dependency on version 5.0 of foo, whatever release is required (!), is satisfied. So, a package having "Require: foo = 5.0-6" happily coexists with the foo-5.0-2 package. I don't understand this. Or it's a bug, or there is some rationale for this that I don't know of (yet). It also is the case that every kernel package provides "kernel = %{version}" explicitly. AFAIK this is mainly done to let kernel-smp, kernel-bigmem, etc. all "provide" the basic kernel too (but Arjan can tell much more about this, see also our disussion on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102639 earlier today). In my case, I wanted to let a pseudo-package require specifically "kernel = 2.4.20-18.9", to pull that kernel package in with APT (more details on request) and I then detected that "kernel-2.4.20-8" was good enough for rpm (and APT) to satisfy "kernel = 2.4.20-18.9". So, now the main issues: - Is the rpm bahaviour a bug or a feauture (if a feature, why)? - Arjan has good reasons for the current kernel provides lines, but I'm mainly objecting against the rpm bahaviour, so could a different behaviour coexist with Arjans kernel packaging goals? Note that the bug report Panu submitted (see above) mainly resulted in a kernel packaging discussion, although the core question lays at the rpm level. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From jbj at redhat.com Tue Aug 19 17:23:11 2003 From: jbj at redhat.com (Jeff Johnson) Date: Tue, 19 Aug 2003 13:23:11 -0400 Subject: RPM dependency rationale (and kernel packages)? In-Reply-To: <200308191704.h7JH4L503670@xos037.xos.nl>; from jos@xos.nl on Tue, Aug 19, 2003 at 07:04:21PM +0200 References: <200308191704.h7JH4L503670@xos037.xos.nl> Message-ID: <20030819132311.J12976@devserv.devel.redhat.com> On Tue, Aug 19, 2003 at 07:04:21PM +0200, Jos Vos wrote: > Hi, > > Short intro: > > Every package provides itself implicitly, as if the line > "Provides: foo = 5.0-2" was in the spec file. This means that any > dependency on "foo", "foo = 5.0", or "foo = 5.0-2" is satisfied > (as well as relational dependencies, like "foo >= 5.0" etc.). > This is all the basic RPM dependency behaviour and pretty > straightforward. > > It now seems that rpm also has the following behaviour: > > If you put an explicit "Provides" line in the spec file *omitting* > the release, say "Provides: foo = 5.0", then *any* dependency on > version 5.0 of foo, whatever release is required (!), is satisfied. > So, a package having "Require: foo = 5.0-6" happily coexists with > the foo-5.0-2 package. I don't understand this. Or it's a bug, > or there is some rationale for this that I don't know of (yet). > > It also is the case that every kernel package provides > "kernel = %{version}" explicitly. AFAIK this is mainly done to let > kernel-smp, kernel-bigmem, etc. all "provide" the basic kernel too > (but Arjan can tell much more about this, see also our disussion > on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102639 > earlier today). > > In my case, I wanted to let a pseudo-package require specifically > "kernel = 2.4.20-18.9", to pull that kernel package in with APT > (more details on request) and I then detected that "kernel-2.4.20-8" > was good enough for rpm (and APT) to satisfy "kernel = 2.4.20-18.9". > > So, now the main issues: > > - Is the rpm bahaviour a bug or a feauture (if a feature, why)? > Feature, or at least necessity for legacy compatibility. Before rpm-3.0.2, only Requires: and Conflicts: permitted versions. In order to implement versioning for PreReq:, Obsoletes: and Provides:, some way of not breaking backward<->forward compatibility had to be devised. The scheme is that a missing value (as found in legacy packages) provides all possible or requires any possible match. For example, Requires: kernel = 2.4.20-18.9 is satisfied by the Provides: kernel = 2.4.20 i.e. the provides without an explicit Release: matches any Requires:. > - Arjan has good reasons for the current kernel provides lines, > but I'm mainly objecting against the rpm bahaviour, so could > a different behaviour coexist with Arjans kernel packaging goals? > And there are even better reasons for not changing rpm's behavior. Add a file requires on a file in the kernel package that has both the Version: and Release: appended as suffix, almost every file in the package as both V-R appended. > Note that the bug report Panu submitted (see above) mainly resulted > in a kernel packaging discussion, although the core question lays > at the rpm level. > 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From jos at xos.nl Tue Aug 19 17:36:19 2003 From: jos at xos.nl (Jos Vos) Date: Tue, 19 Aug 2003 19:36:19 +0200 Subject: RPM dependency rationale (and kernel packages)? In-Reply-To: <20030819132311.J12976@devserv.devel.redhat.com>; from jbj@redhat.com on Tue, Aug 19, 2003 at 01:23:11PM -0400 References: <200308191704.h7JH4L503670@xos037.xos.nl> <20030819132311.J12976@devserv.devel.redhat.com> Message-ID: <20030819193619.A3764@xos037.xos.nl> On Tue, Aug 19, 2003 at 01:23:11PM -0400, Jeff Johnson wrote: > Feature, or at least necessity for legacy compatibility. > > Before rpm-3.0.2, only Requires: and Conflicts: permitted versions. > > In order to implement versioning for PreReq:, Obsoletes: and Provides:, > some way of not breaking backward<->forward compatibility had to be devised. I now vaguely remember that this had been discussed years ago... Despite the possible workaround in the case of the kernel package, I still suggest to consider changing rpm's behaviour at some point in time, as it is unlogical, IMHO. Furthermore, the kernel package does not really use this "feature", as far as I can see, it would be fine to have version-release in the provides line too (Arjan: is this true?). > Add a file requires on a file in the kernel package that has both the > Version: and Release: appended as suffix, almost every file in the > package as both V-R appended. Great hack, thanks! I should have thought of that myself... ;-). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From Axel.Thimm at physik.fu-berlin.de Tue Aug 19 17:49:38 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Tue, 19 Aug 2003 20:49:38 +0300 Subject: Strict kernel module dependencies (was: RPM dependency rationale (and kernel packages)?) In-Reply-To: <20030819132311.J12976@devserv.devel.redhat.com> References: <200308191704.h7JH4L503670@xos037.xos.nl> <20030819132311.J12976@devserv.devel.redhat.com> Message-ID: <20030819174938.GJ2099@pua.nirvana> On Tue, Aug 19, 2003 at 01:23:11PM -0400, Jeff Johnson wrote: > On Tue, Aug 19, 2003 at 07:04:21PM +0200, Jos Vos wrote: > > Every package provides itself implicitly, as if the line > > "Provides: foo = 5.0-2" was in the spec file. This means that any > > dependency on "foo", "foo = 5.0", or "foo = 5.0-2" is satisfied > > (as well as relational dependencies, like "foo >= 5.0" etc.). > > This is all the basic RPM dependency behaviour and pretty > > straightforward. > > [...] > > It also is the case that every kernel package provides > > "kernel = %{version}" explicitly. AFAIK this is mainly done to let > > kernel-smp, kernel-bigmem, etc. all "provide" the basic kernel too > > (but Arjan can tell much more about this, see also our disussion > > on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102639 > > earlier today). > > > > In my case, I wanted to let a pseudo-package require specifically > > "kernel = 2.4.20-18.9", to pull that kernel package in with APT > > (more details on request) and I then detected that "kernel-2.4.20-8" > > was good enough for rpm (and APT) to satisfy "kernel = 2.4.20-18.9". > > Feature, or at least necessity for legacy compatibility. > Before rpm-3.0.2, only Requires: and Conflicts: permitted versions. > [...] > And there are even better reasons for not changing rpm's behavior. > > Add a file requires on a file in the kernel package that has both the > Version: and Release: appended as suffix, almost every file in the > package as both V-R appended. I am using this workaround for the kernel modules I build, but it still does not do an exact nevra dependency, i.e. arch is missing (but it helped lowering support queries to a minimum, almost nobody has multiple kernels installed differing only in arch). Arjan, how about adding a new tag like Provides: strictdep-kernel[-]-%{_target_cpu} = %{?epoch:%{epoch}:}%{version}-%{release} and letting kernel modules depend on that? It won't spoil legacy behaviour and keep kernel module provider happy :) -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jbj at redhat.com Tue Aug 19 18:07:17 2003 From: jbj at redhat.com (Jeff Johnson) Date: Tue, 19 Aug 2003 14:07:17 -0400 Subject: RPM dependency rationale (and kernel packages)? In-Reply-To: <20030819193619.A3764@xos037.xos.nl>; from jos@xos.nl on Tue, Aug 19, 2003 at 07:36:19PM +0200 References: <200308191704.h7JH4L503670@xos037.xos.nl> <20030819132311.J12976@devserv.devel.redhat.com> <20030819193619.A3764@xos037.xos.nl> Message-ID: <20030819140717.K12976@devserv.devel.redhat.com> On Tue, Aug 19, 2003 at 07:36:19PM +0200, Jos Vos wrote: > On Tue, Aug 19, 2003 at 01:23:11PM -0400, Jeff Johnson wrote: > > > Feature, or at least necessity for legacy compatibility. > > > > Before rpm-3.0.2, only Requires: and Conflicts: permitted versions. > > > > In order to implement versioning for PreReq:, Obsoletes: and Provides:, > > some way of not breaking backward<->forward compatibility had to be devised. > > I now vaguely remember that this had been discussed years ago... > Despite the possible workaround in the case of the kernel package, > I still suggest to consider changing rpm's behaviour at some point > in time, as it is unlogical, IMHO. > Changing rpm's behavior? Surely you jest, there is simply no way to change rpmvercmp behavior compatibly, and I do not wish to waste the next couple of years explaining. In fact, it's taken since rpm-3.0.2 to fix the last remaining piece of this puzzle A missing Epoch: is now equivalent to Epoch: 0 everywhere and always forevermore. That's like a 4 year deployment for a tedious missing value problem with an obvious solution. > Furthermore, the kernel package does not really use this "feature", > as far as I can see, it would be fine to have version-release in > the provides line too (Arjan: is this true?). > Talk to Arjan. In fact, I had exactly this conversation regarding Requires: kernel = V-R with Arjan about 6 months ago due to a brain fart on my part. Adding a Release: to the Provides: causes any Requires: (as you wish to write) in a package to be recompiled each and every time the kernel gets rebuilt. That's unnecessarily Draconian imho. OTOH, you are probably trying to roll 3rd party kernel modules, duh, and there needs to be a better solution. I've been nudging the kernel dilletantes for years, sigh. Put needed kernel symbols directly into package Provides: and 3rd party kernel module packaging instantly becomes more reliable. (donning asbestos suit and tie ...) 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From jbj at redhat.com Tue Aug 19 18:12:33 2003 From: jbj at redhat.com (Jeff Johnson) Date: Tue, 19 Aug 2003 14:12:33 -0400 Subject: Strict kernel module dependencies (was: RPM dependency rationale (and kernel packages)?) In-Reply-To: <20030819174938.GJ2099@pua.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Tue, Aug 19, 2003 at 08:49:38PM +0300 References: <200308191704.h7JH4L503670@xos037.xos.nl> <20030819132311.J12976@devserv.devel.redhat.com> <20030819174938.GJ2099@pua.nirvana> Message-ID: <20030819141233.L12976@devserv.devel.redhat.com> On Tue, Aug 19, 2003 at 08:49:38PM +0300, Axel Thimm wrote: > On Tue, Aug 19, 2003 at 01:23:11PM -0400, Jeff Johnson wrote: > > On Tue, Aug 19, 2003 at 07:04:21PM +0200, Jos Vos wrote: > > > Every package provides itself implicitly, as if the line > > > "Provides: foo = 5.0-2" was in the spec file. This means that any > > > dependency on "foo", "foo = 5.0", or "foo = 5.0-2" is satisfied > > > (as well as relational dependencies, like "foo >= 5.0" etc.). > > > This is all the basic RPM dependency behaviour and pretty > > > straightforward. > > > [...] > > > It also is the case that every kernel package provides > > > "kernel = %{version}" explicitly. AFAIK this is mainly done to let > > > kernel-smp, kernel-bigmem, etc. all "provide" the basic kernel too > > > (but Arjan can tell much more about this, see also our disussion > > > on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102639 > > > earlier today). > > > > > > In my case, I wanted to let a pseudo-package require specifically > > > "kernel = 2.4.20-18.9", to pull that kernel package in with APT > > > (more details on request) and I then detected that "kernel-2.4.20-8" > > > was good enough for rpm (and APT) to satisfy "kernel = 2.4.20-18.9". > > > > Feature, or at least necessity for legacy compatibility. > > Before rpm-3.0.2, only Requires: and Conflicts: permitted versions. > > [...] > > And there are even better reasons for not changing rpm's behavior. > > > > Add a file requires on a file in the kernel package that has both the > > Version: and Release: appended as suffix, almost every file in the > > package as both V-R appended. > > I am using this workaround for the kernel modules I build, but it > still does not do an exact nevra dependency, i.e. arch is missing (but > it helped lowering support queries to a minimum, almost nobody has > multiple kernels installed differing only in arch). > > Arjan, how about adding a new tag like > Provides: strictdep-kernel[-]-%{_target_cpu} = %{?epoch:%{epoch}:}%{version}-%{release} > and letting kernel modules depend on that? > > It won't spoil legacy behaviour and keep kernel module provider happy :) Adding arch to a static provides is insufficient, arch alone is not sufficient clue. Consider the optional CMOV instruction on i686. Better is to add a probe dependency, basically the contents of /proc/cpuinfo with some charatcer adornment, that (and that alone) starts to provide sufficient granularity to add more precise dependencies. Even probe dependencies fail with run-time (i.e. mobo replacement) changes, however. There's no easy answer, but more than adding arch to a kernel Provide: is needed. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From blocke at shivan.org Tue Aug 19 18:51:06 2003 From: blocke at shivan.org (blocke at shivan.org) Date: Tue, 19 Aug 2003 11:51:06 -0700 (PDT) Subject: Misleading message in 'su' info document In-Reply-To: <1061301328.10635.13.camel@vimalakirti.anatman.org> References: <1061259862.6424.6.camel@localhost> <1061297402.8846.3.camel@jeremy.dtcc.cc.nc.us> <1061301328.10635.13.camel@vimalakirti.anatman.org> Message-ID: <37190.137.140.21.100.1061319066.squirrel@webmail.shivan.org> > >> > In my opinion such historical baggage is harmful and should be pulled >> > from at least Red Hat's copy of the 'su' info page. >> > >> > Any opinions? > > I am against any change. The default behavior is documented correctly. This is not documenting a default behaviour. This is documenting that the functionality is not provided at all when it is and gives an ancient rant as an excuse why. In my opinion if people want to preserve the rant for historical rants it should be moved into its own file under /usr/share/doc with a disclaimer saying its ancient information. > The fact that one can achieve a different result has nothing to do > specifically with su. There are a few different ways of limiting su > privileges, one being PAM, another by removing the public execute bit of > su and making the file group wheel. Thus breaking user to user su for non-wheel users. It is not the same. > The GNU su code itself does not > impose limits, and probably never should. But in Red Hat it does, via pam, and should be documented as such. - Bruce From janina at rednote.net Tue Aug 19 19:10:59 2003 From: janina at rednote.net (Janina Sajka) Date: Tue, 19 Aug 2003 15:10:59 -0400 Subject: Bug 69903 newt -- Why no progress? In-Reply-To: <20030818164751.A15030@devserv.devel.redhat.com> References: <1060176206.20277.12.camel@ip68-12-228-23.ok.ok.cox.net> <1060177024.6347.4.camel@one.myworld> <1060223689.20277.55.camel@ip68-12-228-23.ok.ok.cox.net> <20030807122920.A16702@devserv.devel.redhat.com> <3F32807D.1010503@micromuse.com> <20030807175105.GQ23903@rednote.net> <20030818093249.A16286@devserv.devel.redhat.com> <20030818190719.GE17062@rednote.net> <20030818164751.A15030@devserv.devel.redhat.com> Message-ID: <20030819191059.GN13227@rednote.net> Michael K. Johnson writes: > > > I'm actually not in charge of newt, but jumped in to work on this > because I care about the issue; I'm the one who asked Red Hat to > host blinux-list years ago... So please cut me a little slack > while I jump into something -- newt -- that I'm not normally involved > in, source code that I've never read before. The closest I've gotten > to newt before is using the python interface (snack.py) years ago. I certainly intend no disparagment of you, personally. I appreciate that you are the one who responded on this issue when others have not. I certainly intend no disparagment of you, personally. I appreciate that you are the one who responded on this issue when others have not. Frankly, I also feel I should not have to get involved in this. But, here we are. Frankly, I also feel that I should not have had to get involved in this. But, here we are. > > I gave an honest answer about what might have prevented the bug > report from being expeditiously handled before. I have also been > chasing this down internally, in addition to posting that initial > response and doing some initial analysis and pointing out a > potential question about the patch. If I missed the question, I apologize. Please forgive me and repeat it. I, too, want to help speed the resolution. For the eyes-free user, this bug is a showstopper--as the analogous situation would be in the visual interface if pressing enter on "English" brought up the Danish install screens visually, forexample, as they actually do with eyes-free. I see two points that I want to respond to: 1.) The issue of process. 2.) The issue of this particular bug. About the process ... > The problem doesn't have to do with testing. This is an excellent > opportunity to discuss a subtlety of development. Many times, a > patch is provided which fixes the bug in question, and it is easy > to determine that it fixes the bug in question, but it's still not > a correct patch for one reason or another. Often it is because it > introduces other bugs in other places. Fundamentally, patches > require review not just for whether they fix the reported bug, but > also for whether they are a correct modification. Absolutely agree, but this also illustrates my problem with the extant Red Hat process--the much more important issue here. You see, there was never a problem with newt for eyes-free interfaces through Enigma (Red Hat 7.2) The problem appeared in Valhalla, and was reported before Psyche was released. Since then we've gone through Shrike and are now in Severn, a beta preceeding yet another release with no actioni on a showstopping issue for an entire class of users. Clearly, this principle of not breaking things has not served us at all in this instance though we have screamed "ouch." This is what I mean when I characterize the RH process as "unconsionable." And, I do mean the process, and not just this particular bug because basic knowledge of accessibility would have prevented this problem from ever cropping up in Valhalla. The technical accessibility issue is well known. To put it in simple terms, the highlight bar says the focus is one place,while the console cursor says it's elsewhere. more fundamentally, how does such a profound stumbling blockfor an entire class of users make it past QC at Red Hat? I appreciate your (and others) efforts to chase this process issue down inside Red Hat, for it surely will reoccur if it isnot ameliorated. o, to the specific bug at hand ... > > The changes to this patch were not described, it was just provided > with "this patch fixes this bug". That's GREAT. It's VERY useful > information. But it does not mean that it's necessarily the right > patch, it does not mean that it doesn't create other bugs. The > analysis is a key part of the process. > > The "problem" here is not a known bug; it's precisely an unknown. > Speaking for myself as a developer, I can't vouch for the patch as > a correct modification to newt even though I have zero doubt that > it fixes the particular bug reported in 69903. Of course, but how does that proceed? Who's to do it? What are the known potential conflicts that need evaluation? And, when can we expect this to move to resolution? And, if no one steps up to the discussion, as no one else has as of yet, does that mean the fix is in for the next release and we should expect it in the forthcoming beta? I expect it at least in the next release. It's just that much of a showstopper where I sit. What, exactly, do you mean when you write "the changes to this patch were not described?" What additional information or description is needed? By who? Surely you aren't waiting on us to prove a negative? > r long silence on a showstopping issue is deafening. We had silence > whilst the process was Red Hat's alone, and we've had silence since it > was opened up to the community--until you came along. So, I hope that > I'm helping explain, but if I'm explaining the wrong things--tell me. > Because, this is a showstopper, and likely to be evaluated as such in > a Sec. 508 procurment context, for example--far more so than the > absence of a capable screen reader. Thank you for taking this on and moving it forward. Please let me know how to help. > I followed up with an honest expression of the remaining problem > -- one of analysis -- so that other list members would have the > opportunity to contribute analysis that could speed the handling > of this bug report. > > I'm not demanding that anyone else do the analysis. I'm only > making the opportunity to participate in the analysis available > so that anyone -- inside our outside Red Hat -- with the desire > to contribute to the analysis can speed the process. That's how > our new open process works. What I did was exactly what anyone > inside or outside of Red Hat who is not the package developer > could do to speed resolution of a problem. > > Please remember that rhl-devel-list is where we're trying to have > the bulk of the development discussions for the distro. This means > that not every answer you see here will be complete. You should > expect many emails to be part of a process of discovery. If the > response to opening up our process is that everyone takes offense > when partial answers are posted, it doesn't bode well for the > move to open development. To be quite clear, the mail I posted > here is essentially the same email (the technical analysis part, > that is) that I would have sent to our internal development list > to speed progress toward resolving the problem, before this list > existed. > > Hope that helps, And I would echo your sentiment. > > michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Janina Sajka, Director Technology Research and Development Governmental Relations Group American Foundation for the Blind (AFB) Email: janina at afb.net Phone: (202) 408-8175 From johnsonm at redhat.com Tue Aug 19 20:33:31 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 19 Aug 2003 16:33:31 -0400 Subject: Bug 69903 newt -- Why no progress? In-Reply-To: <20030819191059.GN13227@rednote.net>; from janina@rednote.net on Tue, Aug 19, 2003 at 03:10:59PM -0400 References: <1060176206.20277.12.camel@ip68-12-228-23.ok.ok.cox.net> <1060177024.6347.4.camel@one.myworld> <1060223689.20277.55.camel@ip68-12-228-23.ok.ok.cox.net> <20030807122920.A16702@devserv.devel.redhat.com> <3F32807D.1010503@micromuse.com> <20030807175105.GQ23903@rednote.net> <20030818093249.A16286@devserv.devel.redhat.com> <20030818190719.GE17062@rednote.net> <20030818164751.A15030@devserv.devel.redhat.com> <20030819191059.GN13227@rednote.net> Message-ID: <20030819163331.A15240@devserv.devel.redhat.com> I think that there might have been some confusion; I moved the conversation over to the development list to handle the development side of the conversation, and this might not have been obvious. I expressly wasn't really trying to deal with this as a user-level issue, rather trying to bring out some development points. So please forgive the development view you'll see in this conversation; I didn't mean to imply that only developers are welcome! And see the end for some good news on this particular bug report... On Tue, Aug 19, 2003 at 03:10:59PM -0400, Janina Sajka wrote: > I certainly intend no disparagment of you, personally. I appreciate that > you are the one who responded on this issue when others have not. > Frankly, I also feel that I should not have had to get involved in this. But, > here we are. Thanks, and agreed. We're trying to make progress from where we are. > > response and doing some initial analysis and pointing out a > > potential question about the patch. > > If I missed the question, I apologize. Please forgive me and repeat it. It's about the purpose of half the change in the patch; the change to the horizontal positioning, whereas the bug report is about the vertical positioning. > I, too, want to help speed the resolution. For the eyes-free user, this > bug is a showstopper--as the analogous situation would be in the visual > interface if pressing enter on "English" brought up the Danish install > screens visually, forexample, as they actually do with eyes-free. I understand that. And, in fact, so do our QA staff, who regularly run our installer in languages they do not know, and rely on their knowledge of the installer to verify its operation in an unfamiliar language. > I see two points that I want to respond to: > > 1.) The issue of process. > 2.) The issue of this particular bug. Thank you for separating them. > Absolutely agree, but this also illustrates my problem with the extant > Red Hat process--the much more important issue here. You see, there was > never a problem with newt for eyes-free interfaces through Enigma (Red > Hat 7.2) The problem appeared in Valhalla, and was reported before > Psyche was released. Since then we've gone through Shrike and are now in > Severn, a beta preceeding yet another release with no actioni on a > showstopping issue for an entire class of users. Clearly, > this principle of not breaking things has not served us at all in this > instance though we have screamed "ouch." This is what I mean when I > characterize the RH process as "unconsionable." ... > more fundamentally, how does such a profound stumbling block for an > entire class of users make it past QC at Red Hat? I appreciate your > (and others) efforts to chase this process issue down inside Red Hat, > for it surely will reoccur if it is not ameliorated. One of the changes we have made recently to address this has been to involve a developer more closely in the process. Before, non-developers had assistive hardware and attempted to confirm, but were insufficiently integrated into the process, and since they were not themselves visually impaired, the degree of the problem was possibly not as obvious to them. There are two problems here, both of which are addressed. Let me start with the later: Because Red Hat is opening up the process, visually impaired community members can find these problems quickly when they occur; it will be more obvious to them than to the community of developers and QA at Red Hat; we do not currently have any visually impaired developers or QA staff and so it just isn't as obvious within Red Hat when something breaks. For example, for someone who has a braille cheat sheet written up on his whiteboard, problems with braille terminals are just not going to be as obvious as for someone who depends on them daily. The former problem has been addressed by moving the test hardware over to a developer, thus integrating them earlier into the development cycle and hopefully expediting fixes. We won't be perfect, we will have bugs, but we made two general process improvements that I hope will help. Time will, of course, tell. > Of course, but how does that proceed? Who's to do it? I just realized that I forgot to put my description of the question into bugzilla as well as sending it to the list. I have just rectified that. In general (that's important) Red Hat gets more patches submitted than we can fully analyze. Part of the process of submitting a patch should be describing why the patch is correct, not just confirming that it somehow addresses the bug being reported. In this particular case, Red Hat can try to analyze it. However, whowever created the patch should have already done the analysis, so it is silly for us to re-do the analysis from scratch instead of having the initial analysis provided with the patch. So *anyone* has the option of doing the analysis, but the patch author is the obvious person for the task. > What are the known potential conflicts that need evaluation? Unfortunately, wrong question. It's the unknowns that need to be addressed through proper analysis of the change. > And, when can we expect this to move to resolution? I do not have an answer for that right now. By discussing the potential for anyone with the ability to analyze code to participate in the path toward the solution, I have attempted to speed up the movement to resolution. > And, if no one steps up to the discussion, as no > one else has as of yet, does that mean the fix is in for the next > release and we should expect it in the forthcoming beta? I expect it at > least in the next release. It's just that much of a showstopper where I > sit. ... > Surely you aren't waiting on us to prove a negative? Proof of a negative, as I think Sayers remarked, is notoriously hard to come by. Analysis, however, can demonstrate WHY the patch is correct, and analysis that demonstrates that the patch is correct is a necessary precursor to applying the patch. My mails here have been trying to show how, especially with our new, more open process, people who do not work for Red Hat can speed things along by participating in the process. ... Update: I just got an internal analysis from someone who knows newt better than I do (msw), who says that from his analysis the patch is "clearly correct", so I can change my tune. He explicitly reviewed the horizontal as well as vertical positioning. So the fix will go in. The point I've been trying to make (remember, I have no experience in the newt source code) is that anyone could contribute this analysis. 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 johnsonm at redhat.com Tue Aug 19 21:05:59 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Tue, 19 Aug 2003 17:05:59 -0400 Subject: Bug 69903 newt -- Why no progress? In-Reply-To: <20030819163331.A15240@devserv.devel.redhat.com>; from johnsonm@redhat.com on Tue, Aug 19, 2003 at 04:33:31PM -0400 References: <1060177024.6347.4.camel@one.myworld> <1060223689.20277.55.camel@ip68-12-228-23.ok.ok.cox.net> <20030807122920.A16702@devserv.devel.redhat.com> <3F32807D.1010503@micromuse.com> <20030807175105.GQ23903@rednote.net> <20030818093249.A16286@devserv.devel.redhat.com> <20030818190719.GE17062@rednote.net> <20030818164751.A15030@devserv.devel.redhat.com> <20030819191059.GN13227@rednote.net> <20030819163331.A15240@devserv.devel.redhat.com> Message-ID: <20030819170559.A1198@devserv.devel.redhat.com> On Tue, Aug 19, 2003 at 04:33:31PM -0400, Michael K. Johnson wrote: > development points. So please forgive the development view > you'll see in this conversation; I didn't mean to imply that > only developers are welcome! The other thing I wanted to say was a strong thanks to Janina for following up on this bug instead of just writing it off. Discussing things directly is one of the points of our having these lists. 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 blocke at shivan.org Tue Aug 19 23:03:42 2003 From: blocke at shivan.org (Bruce A. Locke) Date: Tue, 19 Aug 2003 19:03:42 -0400 Subject: Misleading message in 'su' info document In-Reply-To: <20030819100658.A11834@devserv.devel.redhat.com> References: <1061259862.6424.6.camel@localhost> <1061297402.8846.3.camel@jeremy.dtcc.cc.nc.us> <20030819100658.A11834@devserv.devel.redhat.com> Message-ID: <1061334221.4851.0.camel@localhost> On Tue, 2003-08-19 at 10:06, Michael K. Johnson wrote: > Definitely, please file a bugzilla report. Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102697 -- --------------------------------------------------------------------- Bruce A. Locke blocke at shivan.org From thornton at yoyoweb.com Wed Aug 20 00:39:02 2003 From: thornton at yoyoweb.com (Thornton Prime) Date: 19 Aug 2003 17:39:02 -0700 Subject: Misleading message in 'su' info document In-Reply-To: <37190.137.140.21.100.1061319066.squirrel@webmail.shivan.org> References: <1061259862.6424.6.camel@localhost> <1061297402.8846.3.camel@jeremy.dtcc.cc.nc.us> <1061301328.10635.13.camel@vimalakirti.anatman.org> <37190.137.140.21.100.1061319066.squirrel@webmail.shivan.org> Message-ID: <1061339942.12210.12.camel@vimalakirti.anatman.org> On Tue, 2003-08-19 at 11:51, blocke at shivan.org wrote:> > > I am against any change. The default behavior is documented correctly. > > This is not documenting a default behaviour. This is documenting that the > functionality is not provided at all when it is and gives an ancient rant > as an excuse why. In my opinion if people want to preserve the rant for I think it would be a mistake to document PAM functionality in the su info pages. You may be right about the historical rant. Even though I disagree with RMS, I think it is a nice bit of history, and I like your idea of preserving it elsewhere. > Thus breaking user to user su for non-wheel users. It is not the same. I don't know how to do this with PAM. Can you explain how this is done? On my systems, when I add auth required /path/pam_wheel.so use_uid it limits user to user su also. Is there an option I'm missing? > But in Red Hat it does, via pam, and should be documented as such. And it could be done just as easily with other methods, like RBAC and stuff. My concern is that pam_wheel is a generic PAM module which can provide the functionality that RMS rants against, but it is not limited to su, is not part of the su code, and it is not the default configuration of su. I guess I don't have a problem mentioning in the su info that there ways of getting wheel limits (and pointing to PAM as one), but the su doc is not the place to document pam_wheel. thornton From paul at dishone.st Wed Aug 20 01:28:52 2003 From: paul at dishone.st (Paul Jakma) Date: Wed, 20 Aug 2003 02:28:52 +0100 (IST) Subject: /usr boot time dependencies In-Reply-To: <20030818094035.B16286@devserv.devel.redhat.com> Message-ID: On Mon, 18 Aug 2003, Michael K. Johnson wrote: > Since this is really a development discussion, please followup to > rhl-devel-list. Thanks! noted. > > neither id nor uniq should be considered available before netfs and > > autofs have run. > > OK, sort -u is the obvious answer IRT uniq. well, the use of sort and grep in pipelines including awk always bugs me a bit: sysctl -a | awk '$0 ~ /^net\.ipv6\.conf\./ { split($1,a,/\./); foo[a[4]] = a[4]; } END {asort(foo); for (i in foo) { if (foo[i] != "all" && foo[i] != "default") print foo[i];}}' at a minimum, grep regex | awk '....' can nearly always trivially be replaced with: awk '$0 ~ /regex/ ....' - grep | awk -> no! :) > do_netreport will never need to call id if it doesn't exist, so > ! -x /usr/bin/id -o ... > should resolve that issue. use the bash EUID builtin variable :) > In either case, bugzilla. :-) see: 102702 - tcp_wrappers install libwrap to /usr/lib 102703 - portmap links to /usr/lib/libwrap (comment refers to 102702) 102704 - portmap init script uses /usr/bin/id 102706 - initscripts network-functions uses uniq > michaelkjohnson thanks! regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: In less than a century, computers will be making substantial progress on ... the overriding problem of war and peace. -- James Slagle From blocke at shivan.org Wed Aug 20 02:20:42 2003 From: blocke at shivan.org (Bruce A. Locke) Date: Tue, 19 Aug 2003 22:20:42 -0400 Subject: Misleading message in 'su' info document In-Reply-To: <1061339942.12210.12.camel@vimalakirti.anatman.org> References: <1061259862.6424.6.camel@localhost> <1061297402.8846.3.camel@jeremy.dtcc.cc.nc.us> <1061301328.10635.13.camel@vimalakirti.anatman.org> <37190.137.140.21.100.1061319066.squirrel@webmail.shivan.org> <1061339942.12210.12.camel@vimalakirti.anatman.org> Message-ID: <1061346042.4851.8.camel@localhost> On Tue, 2003-08-19 at 20:39, Thornton Prime wrote: > I think it would be a mistake to document PAM functionality in the su > info pages. > > You may be right about the historical rant. Even though I disagree with > RMS, I think it is a nice bit of history, and I like your idea of > preserving it elsewhere. I agree. > I don't know how to do this with PAM. Can you explain how this is done? > On my systems, when I add > > auth required /path/pam_wheel.so use_uid > > it limits user to user su also. Is there an option I'm missing? I'm afraid I'm wrong. I assumed pam_wheel behaved like the wheel group does in *BSD. I'm disappointed that it has such a limitation. > And it could be done just as easily with other methods, like RBAC and > stuff. Of course that would be the better solution but for now we are left with suid binaries and su and sudo. :) > I guess I don't have a problem mentioning in the su info that there ways > of getting wheel limits (and pointing to PAM as one), but the su doc is > not the place to document pam_wheel. Yes, I agree. I think simply removing the rant (and moving it to another file for historical/humor purposes) would be good enough. At least that way users are not being told that the functionality is not being provided when there are ways of getting it (aka uncommenting a single line in a single file). -- --------------------------------------------------------------------- Bruce A. Locke blocke at shivan.org From laroche at redhat.com Wed Aug 20 05:13:24 2003 From: laroche at redhat.com (Florian La Roche) Date: Wed, 20 Aug 2003 07:13:24 +0200 Subject: /usr boot time dependencies In-Reply-To: References: <20030818094035.B16286@devserv.devel.redhat.com> Message-ID: <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> > well, the use of sort and grep in pipelines including awk always bugs > me a bit: > > sysctl -a | awk '$0 ~ /^net\.ipv6\.conf\./ { split($1,a,/\./); > foo[a[4]] = a[4]; } END {asort(foo); for (i in foo) { if (foo[i] != > "all" && foo[i] != "default") print foo[i];}}' > > at a minimum, grep regex | awk '....' can nearly always trivially be > replaced with: awk '$0 ~ /regex/ ....' - grep | awk -> no! :) Please submit patches into bugzilla, if you want to have those replaced. I also think that some of those constructs should be replaced. "sort -u" is a GNU extension. I am not sure we should rely on it. > > do_netreport will never need to call id if it doesn't exist, so > > ! -x /usr/bin/id -o ... > > should resolve that issue. > > use the bash EUID builtin variable :) I don't think we should add further things that rely on bash specifics. > > In either case, bugzilla. :-) > > see: > > 102702 - tcp_wrappers install libwrap to /usr/lib > 102703 - portmap links to /usr/lib/libwrap (comment refers to 102702) > 102704 - portmap init script uses /usr/bin/id portmap was changed to not use id and link statically against libwrap. (This should be mentioned here twice on this list and rawhide should have new rpms.) > 102706 - initscripts network-functions uses uniq Up to someone else to decide. I wouldn't use "sort -u". greetings, Florian La Roche From pekkas at netcore.fi Wed Aug 20 05:45:33 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 20 Aug 2003 08:45:33 +0300 (EEST) Subject: /usr boot time dependencies In-Reply-To: <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> Message-ID: On Wed, 20 Aug 2003, Florian La Roche wrote: > > well, the use of sort and grep in pipelines including awk always bugs > > me a bit: > > > > sysctl -a | awk '$0 ~ /^net\.ipv6\.conf\./ { split($1,a,/\./); > > foo[a[4]] = a[4]; } END {asort(foo); for (i in foo) { if (foo[i] != > > "all" && foo[i] != "default") print foo[i];}}' > > > > at a minimum, grep regex | awk '....' can nearly always trivially be > > replaced with: awk '$0 ~ /regex/ ....' - grep | awk -> no! :) > > Please submit patches into bugzilla, if you want to have those > replaced. I also think that some of those constructs should be > replaced. At least the first three-line systctl -a parsing is WAY too confusing to a random John Doe reading the code. Just because we can do it doesn't mean we have to. This is not an obfuscated string parsing contest :-), when we could just have: sysctl -a | grep "^net\.ipv6\.conf\." | awk -F. '{ print $4 }' | sort -u | while read interface; perhaps the first grep could be eliminated, but it's much more readable if we keep it in. Another fix, in this particular case, might be to augment sysctl to be able to print all the sub-branches of a given value, like: sysctl -a net.ipv6.conf would print out: eth0.router_solicitation_delay = 1 eth0.router_solicitation_interval = 4 .... could be usable otherwise too. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From yeti at physics.muni.cz Wed Aug 20 07:36:38 2003 From: yeti at physics.muni.cz (David Necas (Yeti)) Date: Wed, 20 Aug 2003 09:36:38 +0200 Subject: /usr boot time dependencies In-Reply-To: <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> References: <20030818094035.B16286@devserv.devel.redhat.com> <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> Message-ID: <20030820073638.GX8440@potato.brno.mistral.cz> On Wed, Aug 20, 2003 at 07:13:24AM +0200, Florian La Roche wrote: > > "sort -u" is a GNU extension. I am not sure we should rely on it. > ... > Up to someone else to decide. I wouldn't use "sort -u". Are there any plans (or even real possibility) to replace GNU textutils (coreutils) with something else in RHL? Or is the script intended to work on IRIX too? If no, what's the problem with using a GNU extension on an essentially GNU system? Regards, Yeti -- Do not use tab characters. Their effect is not predictable. From laroche at redhat.com Wed Aug 20 09:11:27 2003 From: laroche at redhat.com (Florian La Roche) Date: Wed, 20 Aug 2003 11:11:27 +0200 Subject: /usr boot time dependencies In-Reply-To: <20030820073638.GX8440@potato.brno.mistral.cz> References: <20030818094035.B16286@devserv.devel.redhat.com> <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> <20030820073638.GX8440@potato.brno.mistral.cz> Message-ID: <20030820091127.GA3889@dudweiler.stuttgart.redhat.com> > If no, what's the problem with using a GNU extension on > an essentially GNU system? I could envision someone using busybox "sort" and I don't know if that is then working ok. But that is an unsupported setup and overall my main point has been that I don't want to decide on a "sort | uniq" -> "sort -u" transition. More important would be to get some awk/grep lines into a form that people feel is well supportable as well as being fast enough and sane. greetings, Florian La Roche From pekkas at netcore.fi Wed Aug 20 16:57:10 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 20 Aug 2003 19:57:10 +0300 (EEST) Subject: /usr boot time dependencies In-Reply-To: Message-ID: On Wed, 20 Aug 2003, Paul Jakma wrote: > On Wed, 20 Aug 2003, Pekka Savola wrote: > > > > > > > > sysctl -a | awk '$0 ~ /^net\.ipv6\.conf\./ { split($1,a,/\./); > > > > foo[a[4]] = a[4]; } END {asort(foo); for (i in foo) { if (foo[i] != > > > > "all" && foo[i] != "default") print foo[i];}}' > > > > > > > > at a minimum, grep regex | awk '....' can nearly always trivially be > > > > replaced with: awk '$0 ~ /regex/ ....' - grep | awk -> no! :) > > > At least the first three-line systctl -a parsing is WAY too > > confusing to a random John Doe reading the code. Just because we > > can do it doesn't mean we have to. This is not an obfuscated > > string parsing contest :-), > > :) > > but look on it as: > > $0 ~ /^net\.ipv6\.conf\./ { > split($1,a,/\./); > foo[a[4]] = a[4]; > } > > END { > asort(foo); > for (i in foo) { > if (foo[i] != "all" && foo[i] != "default") > print foo[i]; > } > } > > and perhaps it makes more sense. NB: the above also strips out the > 'all' and 'default' interfaces which i dont think the while read > interfaces needs. Yes, now it makes much more sense (I _think_ I understand what it tries to do, except for the stuff around "split"), but I fear that really just proves the point: that code is very unreadable when compressed, and still difficult to read even if spelled out. > Indeed, this is all a lot of work just to get the list of interfaces > on a system, no? why not just read /proc directly instead of using > sysctl? (sysctl uses proc, so proc must be available anyway): > > interfaces=`ls /proc/sys/net/ipv6/conf/` Yeah, if we can assume proc, that would probably be the simplest thing. I don't know about this either way. Opinions? > or if you want to avoid the dependency on /proc, use the ip tool: > > /sbin/ip -6 link | awk '$1 ~ /^[0-9]/ { gsub(":","",$2); print $2}' The use of /sbin/ip is non-trivial, for example here it prints out: lo sit0 at NONE eth0 sit1 at NONE cipcb0 while the interface list (from proc) really is: all default eth0 lo sit1 (and I think the awk thing is a bit too fancy still, but that's just my opinion :-) > > perhaps the first grep could be eliminated, but it's much more > > readable if we keep it in. > > dont see how. :) > > (NB: I do have a penchant for awk) Yeah, I figured :-) > > could be usable otherwise too. > > Thinking about it, i think 'ip link' and 'ip -6 link' should be > canonical source of interface info, no? Should be, perhaps, but the information will be used to change values in the sysctl variables, and these bits of information (for whatever reason) don't seem to be in sync and in the same format.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From katzj at redhat.com Wed Aug 20 11:57:31 2003 From: katzj at redhat.com (Jeremy Katz) Date: 20 Aug 2003 07:57:31 -0400 Subject: /usr boot time dependencies In-Reply-To: <20030820091127.GA3889@dudweiler.stuttgart.redhat.com> References: <20030818094035.B16286@devserv.devel.redhat.com> <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> <20030820073638.GX8440@potato.brno.mistral.cz> <20030820091127.GA3889@dudweiler.stuttgart.redhat.com> Message-ID: <1061380651.1139.4.camel@isengard> On Wed, 2003-08-20 at 05:11, Florian La Roche wrote: > > If no, what's the problem with using a GNU extension on > > an essentially GNU system? > > I could envision someone using busybox "sort" and I don't know if > that is then working ok. busybox supports "sort -u" :) Jeremy From thomas at apestaart.org Wed Aug 20 12:20:33 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 20 Aug 2003 14:20:33 +0200 Subject: RPM dependency rationale (and kernel packages)? In-Reply-To: <20030819140717.K12976@devserv.devel.redhat.com> References: <200308191704.h7JH4L503670@xos037.xos.nl> <20030819132311.J12976@devserv.devel.redhat.com> <20030819193619.A3764@xos037.xos.nl> <20030819140717.K12976@devserv.devel.redhat.com> Message-ID: <1061382033.2009.31.camel@thocra> > Put needed kernel symbols directly into package Provides: and 3rd party > kernel module packaging instantly becomes more reliable. You're making me very curious now. Care to explain this a bit more ? :) Thanks Thomas Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> I'm alive. I can tell because of the pain. <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ From johnsonm at redhat.com Wed Aug 20 13:18:01 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 20 Aug 2003 09:18:01 -0400 Subject: /usr boot time dependencies In-Reply-To: <20030820051324.GA3156@dudweiler.stuttgart.redhat.com>; from laroche@redhat.com on Wed, Aug 20, 2003 at 07:13:24AM +0200 References: <20030818094035.B16286@devserv.devel.redhat.com> <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> Message-ID: <20030820091801.A20329@devserv.devel.redhat.com> On Wed, Aug 20, 2003 at 07:13:24AM +0200, Florian La Roche wrote: > "sort -u" is a GNU extension. I am not sure we should rely on it. It's incredibly common and we could never replace our sort implementation with one that did not implement -u. When relying on it will speed up the boot process, ignoring it would be silly. > > use the bash EUID builtin variable :) > > I don't think we should add further things that rely on bash specifics. Other advanced shells have similar things. 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 janina at rednote.net Wed Aug 20 14:06:12 2003 From: janina at rednote.net (Janina Sajka) Date: Wed, 20 Aug 2003 10:06:12 -0400 Subject: Bug 69903 newt -- Why no progress? In-Reply-To: <20030819163331.A15240@devserv.devel.redhat.com> References: <1060177024.6347.4.camel@one.myworld> <1060223689.20277.55.camel@ip68-12-228-23.ok.ok.cox.net> <20030807122920.A16702@devserv.devel.redhat.com> <3F32807D.1010503@micromuse.com> <20030807175105.GQ23903@rednote.net> <20030818093249.A16286@devserv.devel.redhat.com> <20030818190719.GE17062@rednote.net> <20030818164751.A15030@devserv.devel.redhat.com> <20030819191059.GN13227@rednote.net> <20030819163331.A15240@devserv.devel.redhat.com> Message-ID: <20030820140612.GL15725@rednote.net> Wow, Michael! That was fast. We're very happy campers over here now. Thanks to you for taking this on and moving it so expeditiously and so effectively. PS: The horizontal positioning would benefit braille displays and people using software based magnification. The reason is that no braille display (or magnified screen segment) can contain all the data displayed by the 25 X 80 display. The effect is rather like looking at the screen through a soda straw. One uses smart scrolling strategies to move the straw around and get the information. Therefore, you want to park the cursor where the most important information is. That's the theory. I am only presuming that Mario Lang, the maintainer of brltty and of accessibility for Debian, did the job right. I do trust him, though. Michael K. Johnson writes: > From: "Michael K. Johnson" > > I think that there might have been some confusion; I moved the > conversation over to the development list to handle the > development side of the conversation, and this might not have > been obvious. I expressly wasn't really trying to deal with > this as a user-level issue, rather trying to bring out some > development points. So please forgive the development view > you'll see in this conversation; I didn't mean to imply that > only developers are welcome! > > And see the end for some good news on this particular bug > report... > > On Tue, Aug 19, 2003 at 03:10:59PM -0400, Janina Sajka wrote: > > I certainly intend no disparagment of you, personally. I appreciate that > > you are the one who responded on this issue when others have not. > > Frankly, I also feel that I should not have had to get involved in this. But, > > here we are. > > Thanks, and agreed. We're trying to make progress from where we are. > > > > response and doing some initial analysis and pointing out a > > > potential question about the patch. > > > > If I missed the question, I apologize. Please forgive me and repeat it. > > It's about the purpose of half the change in the patch; the change > to the horizontal positioning, whereas the bug report is about the > vertical positioning. > > > I, too, want to help speed the resolution. For the eyes-free user, this > > bug is a showstopper--as the analogous situation would be in the visual > > interface if pressing enter on "English" brought up the Danish install > > screens visually, forexample, as they actually do with eyes-free. > > I understand that. And, in fact, so do our QA staff, who regularly > run our installer in languages they do not know, and rely on their > knowledge of the installer to verify its operation in an unfamiliar > language. > > > I see two points that I want to respond to: > > > > 1.) The issue of process. > > 2.) The issue of this particular bug. > > Thank you for separating them. > > > Absolutely agree, but this also illustrates my problem with the extant > > Red Hat process--the much more important issue here. You see, there was > > never a problem with newt for eyes-free interfaces through Enigma (Red > > Hat 7.2) The problem appeared in Valhalla, and was reported before > > Psyche was released. Since then we've gone through Shrike and are now in > > Severn, a beta preceeding yet another release with no actioni on a > > showstopping issue for an entire class of users. Clearly, > > this principle of not breaking things has not served us at all in this > > instance though we have screamed "ouch." This is what I mean when I > > characterize the RH process as "unconsionable." > ... > > more fundamentally, how does such a profound stumbling block for an > > entire class of users make it past QC at Red Hat? I appreciate your > > (and others) efforts to chase this process issue down inside Red Hat, > > for it surely will reoccur if it is not ameliorated. > > One of the changes we have made recently to address this has been to > involve a developer more closely in the process. Before, non-developers > had assistive hardware and attempted to confirm, but were insufficiently > integrated into the process, and since they were not themselves visually > impaired, the degree of the problem was possibly not as obvious to them. > > There are two problems here, both of which are addressed. Let me start > with the later: Because Red Hat is opening up the process, visually > impaired community members can find these problems quickly when they > occur; it will be more obvious to them than to the community of developers > and QA at Red Hat; we do not currently have any visually impaired developers > or QA staff and so it just isn't as obvious within Red Hat when something > breaks. For example, for someone who has a braille cheat sheet written > up on his whiteboard, problems with braille terminals are just not going > to be as obvious as for someone who depends on them daily. > > The former problem has been addressed by moving the test hardware over > to a developer, thus integrating them earlier into the development > cycle and hopefully expediting fixes. > > We won't be perfect, we will have bugs, but we made two general process > improvements that I hope will help. Time will, of course, tell. > > > Of course, but how does that proceed? Who's to do it? > > I just realized that I forgot to put my description of the question > into bugzilla as well as sending it to the list. I have just > rectified that. > > In general (that's important) Red Hat gets more patches submitted > than we can fully analyze. Part of the process of submitting a > patch should be describing why the patch is correct, not just > confirming that it somehow addresses the bug being reported. > > In this particular case, Red Hat can try to analyze it. However, > whowever created the patch should have already done the analysis, > so it is silly for us to re-do the analysis from scratch instead > of having the initial analysis provided with the patch. > > So *anyone* has the option of doing the analysis, but the patch > author is the obvious person for the task. > > > What are the known potential conflicts that need evaluation? > > Unfortunately, wrong question. It's the unknowns that need to be > addressed through proper analysis of the change. > > > And, when can we expect this to move to resolution? > > I do not have an answer for that right now. By discussing the > potential for anyone with the ability to analyze code to participate > in the path toward the solution, I have attempted to speed up the > movement to resolution. > > > And, if no one steps up to the discussion, as no > > one else has as of yet, does that mean the fix is in for the next > > release and we should expect it in the forthcoming beta? I expect it at > > least in the next release. It's just that much of a showstopper where I > > sit. > ... > > Surely you aren't waiting on us to prove a negative? > > Proof of a negative, as I think Sayers remarked, is notoriously > hard to come by. Analysis, however, can demonstrate WHY the patch > is correct, and analysis that demonstrates that the patch is correct > is a necessary precursor to applying the patch. My mails here have > been trying to show how, especially with our new, more open process, > people who do not work for Red Hat can speed things along by > participating in the process. > > ... > > Update: I just got an internal analysis from someone who knows newt > better than I do (msw), who says that from his analysis the patch is > "clearly correct", so I can change my tune. He explicitly reviewed > the horizontal as well as vertical positioning. So the fix will go > in. > > The point I've been trying to make (remember, I have no experience > in the newt source code) is that anyone could contribute this > analysis. > > michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Janina Sajka, Director Technology Research and Development Governmental Relations Group American Foundation for the Blind (AFB) Email: janina at afb.net Phone: (202) 408-8175 From janina at rednote.net Wed Aug 20 14:07:37 2003 From: janina at rednote.net (Janina Sajka) Date: Wed, 20 Aug 2003 10:07:37 -0400 Subject: Bug 69903 newt -- Why no progress? In-Reply-To: <20030819170559.A1198@devserv.devel.redhat.com> References: <1060223689.20277.55.camel@ip68-12-228-23.ok.ok.cox.net> <20030807122920.A16702@devserv.devel.redhat.com> <3F32807D.1010503@micromuse.com> <20030807175105.GQ23903@rednote.net> <20030818093249.A16286@devserv.devel.redhat.com> <20030818190719.GE17062@rednote.net> <20030818164751.A15030@devserv.devel.redhat.com> <20030819191059.GN13227@rednote.net> <20030819163331.A15240@devserv.devel.redhat.com> <20030819170559.A1198@devserv.devel.redhat.com> Message-ID: <20030820140736.GM15725@rednote.net> Michael K. Johnson writes: > From: "Michael K. Johnson" > > On Tue, Aug 19, 2003 at 04:33:31PM -0400, Michael K. Johnson wrote: > > development points. So please forgive the development view > > you'll see in this conversation; I didn't mean to imply that > > only developers are welcome! > > The other thing I wanted to say was a strong thanks to Janina > for following up on this bug instead of just writing it off. > Discussing things directly is one of the points of our having > these lists. > > michaelkjohnson > > "He that composes himself is wiser than he that composes a book." > Linux Application Development -- Ben Franklin > http://people.redhat.com/johnsonm/lad/ > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Janina Sajka, Director Technology Research and Development Governmental Relations Group American Foundation for the Blind (AFB) Email: janina at afb.net Phone: (202) 408-8175 From paul at dishone.st Wed Aug 20 14:08:39 2003 From: paul at dishone.st (Paul Jakma) Date: Wed, 20 Aug 2003 15:08:39 +0100 (IST) Subject: /usr boot time dependencies In-Reply-To: Message-ID: On Wed, 20 Aug 2003, Pekka Savola wrote: > > > > > > sysctl -a | awk '$0 ~ /^net\.ipv6\.conf\./ { split($1,a,/\./); > > > foo[a[4]] = a[4]; } END {asort(foo); for (i in foo) { if (foo[i] != > > > "all" && foo[i] != "default") print foo[i];}}' > > > > > > at a minimum, grep regex | awk '....' can nearly always trivially be > > > replaced with: awk '$0 ~ /regex/ ....' - grep | awk -> no! :) > At least the first three-line systctl -a parsing is WAY too > confusing to a random John Doe reading the code. Just because we > can do it doesn't mean we have to. This is not an obfuscated > string parsing contest :-), :) but look on it as: $0 ~ /^net\.ipv6\.conf\./ { split($1,a,/\./); foo[a[4]] = a[4]; } END { asort(foo); for (i in foo) { if (foo[i] != "all" && foo[i] != "default") print foo[i]; } } and perhaps it makes more sense. NB: the above also strips out the 'all' and 'default' interfaces which i dont think the while read interfaces needs. Indeed, this is all a lot of work just to get the list of interfaces on a system, no? why not just read /proc directly instead of using sysctl? (sysctl uses proc, so proc must be available anyway): interfaces=`ls /proc/sys/net/ipv6/conf/` or if you want to avoid the dependency on /proc, use the ip tool: /sbin/ip -6 link | awk '$1 ~ /^[0-9]/ { gsub(":","",$2); print $2}' > when we could just have: > > sysctl -a | grep "^net\.ipv6\.conf\." | awk -F. '{ print $4 }' | > sort -u | while read interface; no, at least get rid of the grep: sysctl -a | grep "^net\.ipv6\.conf\." | awk -F. \ '$0 ~ /^net\.ipv6\.conf\./ { print $4 }' | sort -u | while read interface or use the ip -6 link method :) > perhaps the first grep could be eliminated, but it's much more > readable if we keep it in. dont see how. :) (NB: I do have a penchant for awk) > could be usable otherwise too. Thinking about it, i think 'ip link' and 'ip -6 link' should be canonical source of interface info, no? regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: Life would be so much easier if we could just look at the source code. -- Dave Olson From paul at dishone.st Wed Aug 20 14:10:26 2003 From: paul at dishone.st (Paul Jakma) Date: Wed, 20 Aug 2003 15:10:26 +0100 (IST) Subject: /usr boot time dependencies In-Reply-To: <20030820091127.GA3889@dudweiler.stuttgart.redhat.com> Message-ID: On Wed, 20 Aug 2003, Florian La Roche wrote: > More important would be to get some awk/grep lines into a form that > people feel is well supportable as well as being fast enough and > sane. For the case of getting interface information, the 'ip link' and 'ip -6 link' examples i gave in my mail to Pekka should be quite portable and are dependent only on ip and awk. pekka? > greetings, > > Florian La Roche regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: She sells cshs by the cshore. From paul at dishone.st Wed Aug 20 14:17:01 2003 From: paul at dishone.st (Paul Jakma) Date: Wed, 20 Aug 2003 15:17:01 +0100 (IST) Subject: /usr boot time dependencies In-Reply-To: <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> Message-ID: On Wed, 20 Aug 2003, Florian La Roche wrote: > Please submit patches into bugzilla, if you want to have those > replaced. I also think that some of those constructs should be > replaced. I'll post my ip link example as a suggestion. > > use the bash EUID builtin variable :) > > I don't think we should add further things that rely on bash specifics. hmm.. how so? otherwise, use the USER or UID shell variables (sh has at least USER, not sure about UID) - but these may not neccessarily be == root/0 even if euid is 0. > portmap was changed to not use id and link statically against > libwrap. (This should be mentioned here twice on this list and > rawhide should have new rpms.) thanks! > Up to someone else to decide. I wouldn't use "sort -u". ip ... | awk then. in fact, why not rewrite the entire init scripts in gawk? much more expressive language than shell while actually being a smaller binary than bash (and probably faster). (i'm actually half-serious :) ). > greetings, > > Florian La Roche regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: It's a poor workman who blames his tools. From Axel.Thimm at physik.fu-berlin.de Wed Aug 20 08:55:51 2003 From: Axel.Thimm at physik.fu-berlin.de (Axel Thimm) Date: Wed, 20 Aug 2003 11:55:51 +0300 Subject: Strict kernel module dependencies (was: RPM dependency rationale (and kernel packages)?) In-Reply-To: <20030819141233.L12976@devserv.devel.redhat.com> References: <200308191704.h7JH4L503670@xos037.xos.nl> <20030819132311.J12976@devserv.devel.redhat.com> <20030819174938.GJ2099@pua.nirvana> <20030819141233.L12976@devserv.devel.redhat.com> Message-ID: <20030820085551.GA4395@pua.nirvana> On Tue, Aug 19, 2003 at 02:12:33PM -0400, Jeff Johnson wrote: > On Tue, Aug 19, 2003 at 08:49:38PM +0300, Axel Thimm wrote: > > I am using this workaround for the kernel modules I build, but it > > still does not do an exact nevra dependency, i.e. arch is missing (but > > it helped lowering support queries to a minimum, almost nobody has > > multiple kernels installed differing only in arch). > > > > Arjan, how about adding a new tag like > > Provides: strictdep-kernel[-]-%{_target_cpu} = %{?epoch:%{epoch}:}%{version}-%{release} > > and letting kernel modules depend on that? > > > > It won't spoil legacy behaviour and keep kernel module provider happy :) > > Adding arch to a static provides is insufficient, arch alone is not sufficient > clue. Consider the optional CMOV instruction on i686. The Red Hat kernel model already takes care of that. Since arch alone cannot describe the properties of the kernel a flavour was invented and shoved into the kernel rpm name. I.e. Red Hat builds not for archs, but for (arch, flavour) tuples, where flavour is one of smp, bigmem, jensen, enterprise, etc. This tupel defines the used .config file which contains all the required information (including a cmov* enabled kernel or other fancy stuff). Depending on the impact of a difference like cmov* one would consider a new arch, or simply a new flavour (or even simpler discard the extra instructions). > Better is to add a probe dependency, basically the contents of > /proc/cpuinfo with some charatcer adornment, that (and that alone) > starts to provide sufficient granularity to add more precise > dependencies. > > Even probe dependencies fail with run-time (i.e. mobo replacement) > changes, however. This would munge the separation of build and target hosts. It would be alright for custom kernels, where build host = target host, but not for providing third party kernel modules package in rpms and matching a set of kernel rpms. But you have this information in the (arch, flavour) tuple. > There's no easy answer, but more than adding arch to a kernel Provide: > is needed. If Red Hat doesn't change the current (arch, flavour) policy (and there is no reason to) the suggested Provides would suffice for exact kernel module dependencies. -- Axel.Thimm at physik.fu-berlin.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From janina at rednote.net Wed Aug 20 17:44:29 2003 From: janina at rednote.net (Janina Sajka) Date: Wed, 20 Aug 2003 13:44:29 -0400 Subject: Bug 69903 newt -- Why no progress? In-Reply-To: <20030820140736.GM15725@rednote.net> References: <20030807122920.A16702@devserv.devel.redhat.com> <3F32807D.1010503@micromuse.com> <20030807175105.GQ23903@rednote.net> <20030818093249.A16286@devserv.devel.redhat.com> <20030818190719.GE17062@rednote.net> <20030818164751.A15030@devserv.devel.redhat.com> <20030819191059.GN13227@rednote.net> <20030819163331.A15240@devserv.devel.redhat.com> <20030819170559.A1198@devserv.devel.redhat.com> <20030820140736.GM15725@rednote.net> Message-ID: <20030820174429.GY15725@rednote.net> And I see the fix is already in rawhide. Not sure I can keep up with this kind of speed! Think I might be blushing, too. Thanks, again, Michael. You're the best. Janina Sajka writes: > From: Janina Sajka > > Michael K. Johnson writes: > > From: "Michael K. Johnson" > > > > On Tue, Aug 19, 2003 at 04:33:31PM -0400, Michael K. Johnson wrote: > > > development points. So please forgive the development view > > > you'll see in this conversation; I didn't mean to imply that > > > only developers are welcome! > > > > The other thing I wanted to say was a strong thanks to Janina > > for following up on this bug instead of just writing it off. > > Discussing things directly is one of the points of our having > > these lists. > > > > michaelkjohnson > > > > "He that composes himself is wiser than he that composes a book." > > Linux Application Development -- Ben Franklin > > http://people.redhat.com/johnsonm/lad/ > > > > > > -- > > Rhl-devel-list mailing list > > Rhl-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/rhl-devel-list > > -- > > Janina Sajka, Director > Technology Research and Development > Governmental Relations Group > American Foundation for the Blind (AFB) > > Email: janina at afb.net Phone: (202) 408-8175 > > > -- > Rhl-list mailing list > Rhl-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-list -- Janina Sajka, Director Technology Research and Development Governmental Relations Group American Foundation for the Blind (AFB) Email: janina at afb.net Phone: (202) 408-8175 From jbj at redhat.com Wed Aug 20 17:58:24 2003 From: jbj at redhat.com (Jeff Johnson) Date: Wed, 20 Aug 2003 13:58:24 -0400 Subject: RPM dependency rationale (and kernel packages)? In-Reply-To: <1061382033.2009.31.camel@thocra>; from thomas@apestaart.org on Wed, Aug 20, 2003 at 02:20:33PM +0200 References: <200308191704.h7JH4L503670@xos037.xos.nl> <20030819132311.J12976@devserv.devel.redhat.com> <20030819193619.A3764@xos037.xos.nl> <20030819140717.K12976@devserv.devel.redhat.com> <1061382033.2009.31.camel@thocra> Message-ID: <20030820135823.B1213@devserv.devel.redhat.com> On Wed, Aug 20, 2003 at 02:20:33PM +0200, Thomas Vander Stichele wrote: > > > Put needed kernel symbols directly into package Provides: and 3rd party > > kernel module packaging instantly becomes more reliable. > > You're making me very curious now. Care to explain this a bit more ? > :) > Sure. Forgive me if I miss details -- I don't build kernels by choice -- but I'm confident that I have the concepts. The kernel has an ABI, exported in System.map, used by insmod, to load modules. In order to produce 3rd party loadable modules outside of the kernel, that same mechanism and information would have to be sufficiently duplicated into package metadata so that an insmod failure could be detected at install, not run time. Automagically processing System.map and emitting dependency strings ain't exactly rocket science, that's all that find-requires in rpm has been doing for years. Hack, works. For (a totally artificial and probably insane) example, let's say a kernel module was built against some kernel on a build machine and needed the symbol (early in System.map was the criteria of choice) c0100218 T stack_start A little bit of sed magic might automagically generate a dependency like Requires: ksym(stack_start) Then the magic construct "ksym(...)" could grovel through the System.map (or whatever insmod uses these days) at install time to check to see whether yes, indeed, there was an already installed kernel that might satisy each and every symbol. It's not a whole lot harder to construct a policy driven path for install if, say, several kernels had the symbols necessary for insmod functionality, and place the module in the correct /lib/modules directories. Note plural. None of the above is impossibly hard to conceive of. The impediment is more one of GPL ideology, not actually implementation. 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From jbj at redhat.com Wed Aug 20 18:03:34 2003 From: jbj at redhat.com (Jeff Johnson) Date: Wed, 20 Aug 2003 14:03:34 -0400 Subject: Strict kernel module dependencies (was: RPM dependency rationale (and kernel packages)?) In-Reply-To: <20030820085551.GA4395@pua.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Wed, Aug 20, 2003 at 11:55:51AM +0300 References: <200308191704.h7JH4L503670@xos037.xos.nl> <20030819132311.J12976@devserv.devel.redhat.com> <20030819174938.GJ2099@pua.nirvana> <20030819141233.L12976@devserv.devel.redhat.com> <20030820085551.GA4395@pua.nirvana> Message-ID: <20030820140334.C1213@devserv.devel.redhat.com> On Wed, Aug 20, 2003 at 11:55:51AM +0300, Axel Thimm wrote: > (snipped, but basically we agree, except "flavor" is different than "arch" because there are different set values involved). > > There's no easy answer, but more than adding arch to a kernel Provide: > > is needed. > > If Red Hat doesn't change the current (arch, flavour) policy (and > there is no reason to) the suggested Provides would suffice for exact > kernel module dependencies. "exact" is the easy case, set up a Provides: and Requires: dependency match on, say, the MD5 of /boot/vmlinuz. What's trickier is the fuzzy match across a range of kernels that might reasonably run a given build of a module. If insmod can figger out that problem at run time, then rpm can figger out the same problem at build/install time. Assuming that insmod doesn't change, of course. ;-) 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From nphilipp at redhat.com Wed Aug 20 18:50:31 2003 From: nphilipp at redhat.com (Nils Philippsen) Date: Wed, 20 Aug 2003 20:50:31 +0200 Subject: RPM dependency rationale (and kernel packages)? In-Reply-To: <20030820135823.B1213@devserv.devel.redhat.com> References: <200308191704.h7JH4L503670@xos037.xos.nl> <20030819132311.J12976@devserv.devel.redhat.com> <20030819193619.A3764@xos037.xos.nl> <20030819140717.K12976@devserv.devel.redhat.com> <1061382033.2009.31.camel@thocra> <20030820135823.B1213@devserv.devel.redhat.com> Message-ID: <1061405430.5945.9.camel@wombat.dialup.fht-esslingen.de> On Wed, 2003-08-20 at 19:58, Jeff Johnson wrote: > For (a totally artificial and probably insane) example, let's say a > kernel module was built against some kernel on a build machine and > needed the symbol (early in System.map was the criteria of choice) > c0100218 T stack_start > A little bit of sed magic might automagically generate a dependency > like > Requires: ksym(stack_start) > > Then the magic construct "ksym(...)" could grovel through the System.map > (or whatever insmod uses these days) at install time to check to see > whether yes, indeed, there was an already installed kernel that might > satisy each and every symbol. Or could be checked against an (equally automatically generated) Provides: ksym(stack_start) (which admittedly would cause quite some bloat in /var/lib/rpm). Though that wouldn't help if the required symbols are scattered over a number of kernels (yes, this is an improbable scenario). If we had such a scheme, the user should be able to select which requirements to show with '--requires' (unless he's a fan of sifting through pages of output). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jbj at redhat.com Wed Aug 20 19:13:37 2003 From: jbj at redhat.com (Jeff Johnson) Date: Wed, 20 Aug 2003 15:13:37 -0400 Subject: RPM dependency rationale (and kernel packages)? In-Reply-To: <1061405430.5945.9.camel@wombat.dialup.fht-esslingen.de>; from nphilipp@redhat.com on Wed, Aug 20, 2003 at 08:50:31PM +0200 References: <200308191704.h7JH4L503670@xos037.xos.nl> <20030819132311.J12976@devserv.devel.redhat.com> <20030819193619.A3764@xos037.xos.nl> <20030819140717.K12976@devserv.devel.redhat.com> <1061382033.2009.31.camel@thocra> <20030820135823.B1213@devserv.devel.redhat.com> <1061405430.5945.9.camel@wombat.dialup.fht-esslingen.de> Message-ID: <20030820151337.E1213@devserv.devel.redhat.com> On Wed, Aug 20, 2003 at 08:50:31PM +0200, Nils Philippsen wrote: > On Wed, 2003-08-20 at 19:58, Jeff Johnson wrote: > > > For (a totally artificial and probably insane) example, let's say a > > kernel module was built against some kernel on a build machine and > > needed the symbol (early in System.map was the criteria of choice) > > c0100218 T stack_start > > A little bit of sed magic might automagically generate a dependency > > like > > Requires: ksym(stack_start) > > > > Then the magic construct "ksym(...)" could grovel through the System.map > > (or whatever insmod uses these days) at install time to check to see > > whether yes, indeed, there was an already installed kernel that might > > satisy each and every symbol. > > Or could be checked against an (equally automatically generated) > > Provides: ksym(stack_start) > > (which admittedly would cause quite some bloat in /var/lib/rpm). Depends on your definition of bloat. For a handful of 3rd party packages, each of which is chasing a moderate number of symbols, the added dependencies is a small amount of data to be saved. ymmv, but then it's your bloat. There are -- of course -- smarter things that could be done if, say, the existence of one symbol implied another, then one of the dependencies could be dispensed with. (aside) In fact, removing the automagically generated dependency on ld-linux.so.2 that is implied by libc.so.6 (at least until LSB gets its act together) from each and every package has already saved more space in /var/lib/rpm than would be consumed by my hand-waving proposal. But that's a different matter ... ;-) > > Though that wouldn't help if the required symbols are scattered over a > number of kernels (yes, this is an improbable scenario). > > If we had such a scheme, the user should be able to select which > requirements to show with '--requires' (unless he's a fan of sifting > through pages of output). > rpm -q --requires pkga pkgb ... | grep some_regex WORKSFORME 73 de Jeff -- Jeff Johnson ARS N3NPQ jbj at redhat.com (jbj at jbj.org) Chapel Hill, NC From notting at redhat.com Wed Aug 20 19:21:07 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Aug 2003 15:21:07 -0400 Subject: /usr boot time dependencies In-Reply-To: ; from paul@dishone.st on Wed, Aug 20, 2003 at 03:17:01PM +0100 References: <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> Message-ID: <20030820152107.B5089@devserv.devel.redhat.com> Paul Jakma (paul at dishone.st) said: > in fact, why not rewrite the entire init scripts in gawk? You'd have to get that one by the package maintainer. I don't see a very good chance of succeeding with that. >:) Bill From smoogen at lanl.gov Wed Aug 20 19:37:43 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Wed, 20 Aug 2003 13:37:43 -0600 Subject: /usr boot time dependencies In-Reply-To: <20030820152107.B5089@devserv.devel.redhat.com> References: <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> <20030820152107.B5089@devserv.devel.redhat.com> Message-ID: <1061408263.6643.24.camel@smoogen1.lanl.gov> Thats because none of you guys are old-timers anymore. In my day we wrote everything in awk, up hill both ways.. and we liked it! [Looking at his long list of awk scripts because he could nver get that perl thing in his head.] On Wed, 2003-08-20 at 13:21, Bill Nottingham wrote: > Paul Jakma (paul at dishone.st) said: > > in fact, why not rewrite the entire init scripts in gawk? > > You'd have to get that one by the package maintainer. I don't see > a very good chance of succeeding with that. >:) > > Bill > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From laroche at redhat.com Wed Aug 20 20:31:37 2003 From: laroche at redhat.com (Florian La Roche) Date: Wed, 20 Aug 2003 22:31:37 +0200 Subject: /usr boot time dependencies In-Reply-To: References: <20030820091127.GA3889@dudweiler.stuttgart.redhat.com> Message-ID: <20030820203137.GC2759@dudweiler.stuttgart.redhat.com> On Wed, Aug 20, 2003 at 03:10:26PM +0100, Paul Jakma wrote: > On Wed, 20 Aug 2003, Florian La Roche wrote: > > > More important would be to get some awk/grep lines into a form that > > people feel is well supportable as well as being fast enough and > > sane. > > For the case of getting interface information, the 'ip link' and 'ip > -6 link' examples i gave in my mail to Pekka should be quite portable > and are dependent only on ip and awk. > pekka? He's catching up. While I also own the awk rpm for RHL, I am myself not using it too much. Improving exactly those places in our scripts has several times been decided within RH, but then got also dropped due to resource problems. Mixture between you and Pekka looks promising. ;-) greetings, Florian La Roche From johnsonm at redhat.com Wed Aug 20 20:36:43 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Wed, 20 Aug 2003 16:36:43 -0400 Subject: Bug 69903 newt -- Why no progress? In-Reply-To: <20030820140612.GL15725@rednote.net>; from janina@rednote.net on Wed, Aug 20, 2003 at 10:06:12AM -0400 References: <1060223689.20277.55.camel@ip68-12-228-23.ok.ok.cox.net> <20030807122920.A16702@devserv.devel.redhat.com> <3F32807D.1010503@micromuse.com> <20030807175105.GQ23903@rednote.net> <20030818093249.A16286@devserv.devel.redhat.com> <20030818190719.GE17062@rednote.net> <20030818164751.A15030@devserv.devel.redhat.com> <20030819191059.GN13227@rednote.net> <20030819163331.A15240@devserv.devel.redhat.com> <20030820140612.GL15725@rednote.net> Message-ID: <20030820163643.A12263@devserv.devel.redhat.com> On Wed, Aug 20, 2003 at 10:06:12AM -0400, Janina Sajka wrote: > Wow, Michael! That was fast. We're very happy campers over here now. Glad to hear it! :-) > Thanks to you for taking this on and moving it so expeditiously and so > effectively. My pleasure. > PS: The horizontal positioning would benefit braille displays and people > using software based magnification. The reason is that no braille > display (or magnified screen segment) can contain all the data displayed > by the 25 X 80 display. The effect is rather like looking at the screen > through a soda straw. One uses smart scrolling strategies to move the > straw around and get the information. Therefore, you want to park the > cursor where the most important information is. I'm simply in awe of anyone who can keep track of so much context while "looking through a straw". :-) The change in horizontal position in question is one position, but I suppose (without direct experience) that if the cursor is positioned off the word, that a screen reader in particular might not know that the word needed to be read... > That's the theory. I am only presuming that Mario Lang, the maintainer > of brltty and of accessibility for Debian, did the job right. I do trust > him, though. Again, not blame, just describing process: That was one of the other missing pieces -- the bug report (I know, hard to read through the soda straw, but Dave is working on improving bugzilla's accessibility) doesn't have any information associating the patch with Mario, so I had no way of knowing to ask him about it. In any case, this is useful not only for visually impaired users, but also for anyone doing an installation over serial, because it uses VT100 without color and it's always been difficult even for users with perfect vision to do those installs because of the exact same problem; the cursor is simply in the wrong place. 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 paul at dishone.st Wed Aug 20 22:06:29 2003 From: paul at dishone.st (Paul Jakma) Date: Wed, 20 Aug 2003 23:06:29 +0100 (IST) Subject: /usr boot time dependencies In-Reply-To: <20030820152107.B5089@devserv.devel.redhat.com> Message-ID: On Wed, 20 Aug 2003, Bill Nottingham wrote: > Paul Jakma (paul at dishone.st) said: > > in fact, why not rewrite the entire init scripts in gawk? > > You'd have to get that one by the package maintainer. I don't see > a very good chance of succeeding with that. >:) :) it'd be worth it though! certainly be cleaner, awk is far more expressive and featured than shell. > Bill regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: For large values of one, one equals two, for small values of two. From paul at dishone.st Wed Aug 20 22:15:11 2003 From: paul at dishone.st (Paul Jakma) Date: Wed, 20 Aug 2003 23:15:11 +0100 (IST) Subject: /usr boot time dependencies In-Reply-To: Message-ID: On Wed, 20 Aug 2003, Pekka Savola wrote: > > interfaces=`ls /proc/sys/net/ipv6/conf/` > > Yeah, if we can assume proc, that would probably be the simplest thing. well, sysctl -a afaik requires /proc (can it fall back to sysctl()?) > I don't know about this either way. Opinions? unless sysctl (8) supports sysctl (2) if /proc is absent, read the dirs straight from /proc. > > /sbin/ip -6 link | awk '$1 ~ /^[0-9]/ { gsub(":","",$2); print $2}' > > The use of /sbin/ip is non-trivial, for example here it prints out: > > lo > sit0 at NONE > eth0 > sit1 at NONE > cipcb0 > > while the interface list (from proc) really is: > > all default eth0 lo sit1 ah yes.. have to remove everything after [:@], this will work: /sbin/ip -6 link | awk '$1 ~ /^[0-9]/ { sub(/[:@].*/,"",$2); print $2}' > (and I think the awk thing is a bit too fancy still, but that's > just my opinion :-) it means you havnt discovered awk. :) > Should be, perhaps, but the information will be used to change > values in the sysctl variables, and these bits of information (for > whatever reason) don't seem to be in sync and in the same format.. isnt it fairly much a given that interfaces listed by ip will match the sysctl interface config entries? regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: Teamwork is essential -- it allows you to blame someone else. From kaboom at gatech.edu Wed Aug 20 22:45:06 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 20 Aug 2003 16:45:06 -0600 (MDT) Subject: /usr boot time dependencies In-Reply-To: References: Message-ID: On Wed, 20 Aug 2003, Paul Jakma wrote: > it'd be worth it though! certainly be cleaner, awk is far more > expressive and featured than shell. But shell is much more widely known. New admins today seem to learn shell, then perl, and skip right over awk. Things like that are important now that it's a community project.... later, chris From notting at redhat.com Wed Aug 20 22:48:05 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Aug 2003 18:48:05 -0400 Subject: /usr boot time dependencies In-Reply-To: ; from paul@dishone.st on Wed, Aug 20, 2003 at 11:15:11PM +0100 References: Message-ID: <20030820184805.A3442@devserv.devel.redhat.com> Paul Jakma (paul at dishone.st) said: > > Should be, perhaps, but the information will be used to change > > values in the sysctl variables, and these bits of information (for > > whatever reason) don't seem to be in sync and in the same format.. > > isnt it fairly much a given that interfaces listed by ip will match > the sysctl interface config entries? No, changes to device name with nameif don't change things in /proc/sys. (Yes, this is bad.) Bill From pekkas at netcore.fi Thu Aug 21 06:37:44 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 21 Aug 2003 09:37:44 +0300 (EEST) Subject: feature request: additional IPs assign to real device via ip addr add In-Reply-To: <005c01c36783$8af98190$0700a8c0@sandbox> Message-ID: I think this discussion should go rhl-devel list. Please send the followups only there. On Thu, 21 Aug 2003, Alexander Dalloz wrote: > I would like a feature for setting up additional IPs to a real device by > just giving it a list of IPs. Well, I know it is possible to use aliased > devices, but that is not often neccessary, even more work. And those > aliased devices are not usable by iptables rules as device instructions. > > In /etc/sysconfig/network-scripts/ifup the real device is already set up by > the command "ip addr add". So it would be nice to give the script just a > list of IPs to be added to the real device. It could be done by a variable > in /etc/sysconfig/network-scripts/ifcfg-ethX in which the administrator will > just put the space separated list of additional IPs. Note that this is how it's done with IPv6. A problem, at least in the past, was that ifconfig(8) would not show these addresses at all. I'm not sure if that has been fixed. Anyone remember the details of this case? Personally I also think that the concept of alias interfaces is a bit obsolete. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From alexl at redhat.com Thu Aug 21 10:07:07 2003 From: alexl at redhat.com (Alexander Larsson) Date: 21 Aug 2003 12:07:07 +0200 Subject: librt.so TLS issues Message-ID: <1061460427.6035.26.camel@localhost.localdomain> There was a change in glibc somewhere between 2.3.2-57 and 2.3.2-66 that adds /usr/lib/librt.so.1 to glibc-devel. The file is just a symlink to librt.so. This change seems wrong to me, and its causing breakage with TLS. I have an app not linking to librt, but it dlopens a library that links to librt.so.1. The app gets the tls libc at /lib/tls/libc.so.6, but when resolving the librt.so.1 DT_NEEDED it first looks in the system library, finding /usr/lib/librt.so.1. However, following this symlink gets you /lib/librt.so.1 which is the non-TLS version of librt. This means we have mismatched librt and libc versions, causing: /usr/lib/librt.so.1: symbol __librt_disable_asynccancel, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference Having the soname librt in /usr/lib just seems wrong to me. What was the reason for introducing it? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an obese moralistic sorceror with a passion for fast cars. She's a strong-willed goth cab driver fleeing from a Satanic cult. They fight crime! From alexander.dalloz at uni-bielefeld.de Thu Aug 21 13:27:21 2003 From: alexander.dalloz at uni-bielefeld.de (Alexander Dalloz) Date: Thu, 21 Aug 2003 15:27:21 +0200 Subject: feature request: additional IPs assign to real device via ip addr add In-Reply-To: Message-ID: <00a901c367e7$f3d56260$0700a8c0@sandbox> Hi! > I think this discussion should go rhl-devel list. Please send the > followups only there. > > On Thu, 21 Aug 2003, Alexander Dalloz wrote: > > I would like a feature for setting up additional IPs to a > real device byjust giving it a list of IPs. Well, I know it is possible > to use aliased devices, but that is not often neccessary, even more work. > And those aliased devices are not usable by iptables rules as device > instructions. > > > > In /etc/sysconfig/network-scripts/ifup the real device is already set up by > > the command "ip addr add". So it would be nice to give the script just a > > list of IPs to be added to the real device. It could be done by a variable > > in /etc/sysconfig/network-scripts/ifcfg-ethX in which the administrator will > > just put the space separated list of additional IPs. > > Note that this is how it's done with IPv6. > > A problem, at least in the past, was that ifconfig(8) would > not show these addresses at all. I'm not sure if that has been fixed. I think this is still the case. But you can list all assigned IPs with the "ip addr list" command. So in long run ifconfig is obsolete and iproute2 will do all neccessary. > Anyone remember the details of this case? > > Personally I also think that the concept of alias interfaces is a bit > obsolete. This is my opinion too. Alexander -- Alexander Dalloz | Enger, Germany PGP key valid: made 13.07.1999 PGP fingerprint: 2307 88FD 2D41 038E 7416 14CD E197 6E88 ED69 5653 From gkarabin at pobox.com Fri Aug 22 04:47:08 2003 From: gkarabin at pobox.com (George J Karabin) Date: Thu, 21 Aug 2003 21:47:08 -0700 Subject: 2 package patching questions Message-ID: <1061527627.9194.43.camel@localhost.localdomain> I've got two questions that have come up while making some minor patches lately. Hopefully the answers (if forthcoming) will be useful to others who are starting to get more involved with RHLP. Question #1: Are all of the packages in RHL/RHLP available for anonymous CVS access at this point in time, or just the subset that I see on rhlinux.redhat.com? Every once in a while I find a trivial bug in some package and want to make a patch against its .spec file, or usually, its .spec.in file. If the package is hosted on the one anonymous RedHat CVS server that I know of - CVSROOT=pserver:anoncvs at rhlinux.redhat.com:/usr/local/CVS - no problems. If it's a package that's not in CVSROOT/modules, then I'm at a loss. Question #2: Does anyone have a take on whether or not it's appropriate to use the "-a" option to add binary files (like graphics) to a patch? I can't recall ever seeing a patch distributed with one, and reading such a thing probably does wonders for terminals (random escaped character sequences) but the following page seems to indicate that it's an OK practice: http://www.gnu.org/manual/diffutils/html_node/Tips-for-Patch-Producers.html#Tips%20for%20Patch%20Producers Thanks, - George From alexl at redhat.com Fri Aug 22 09:06:24 2003 From: alexl at redhat.com (Alexander Larsson) Date: 22 Aug 2003 11:06:24 +0200 Subject: librt.so TLS issues In-Reply-To: <1061460427.6035.26.camel@localhost.localdomain> References: <1061460427.6035.26.camel@localhost.localdomain> Message-ID: <1061543183.6035.82.camel@localhost.localdomain> On Thu, 2003-08-21 at 12:07, Alexander Larsson wrote: > There was a change in glibc somewhere between 2.3.2-57 and 2.3.2-66 that > adds /usr/lib/librt.so.1 to glibc-devel. The file is just a symlink to > librt.so. This change seems wrong to me, and its causing breakage with > TLS. > > I have an app not linking to librt, but it dlopens a library that links > to librt.so.1. The app gets the tls libc at /lib/tls/libc.so.6, but when > resolving the librt.so.1 DT_NEEDED it first looks in the system library, > finding /usr/lib/librt.so.1. However, following this symlink gets you > /lib/librt.so.1 which is the non-TLS version of librt. This means we > have mismatched librt and libc versions, causing: > > /usr/lib/librt.so.1: symbol __librt_disable_asynccancel, version > GLIBC_PRIVATE not defined in file libc.so.6 with link time reference > > Having the soname librt in /usr/lib just seems wrong to me. What was the > reason for introducing it? I put this in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102879 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an all-American hunchbacked gangster possessed of the uncanny powers of an insect. She's an orphaned bisexual bodyguard with an incredible destiny. They fight crime! From notting at redhat.com Fri Aug 22 15:23:22 2003 From: notting at redhat.com (Bill Nottingham) Date: Fri, 22 Aug 2003 11:23:22 -0400 Subject: 2 package patching questions In-Reply-To: <1061527627.9194.43.camel@localhost.localdomain>; from gkarabin@pobox.com on Thu, Aug 21, 2003 at 09:47:08PM -0700 References: <1061527627.9194.43.camel@localhost.localdomain> Message-ID: <20030822112322.A27504@devserv.devel.redhat.com> George J Karabin (gkarabin at pobox.com) said: > Question #1: > > Are all of the packages in RHL/RHLP available for anonymous CVS access > at this point in time No. Bill From johnsonm at redhat.com Fri Aug 22 17:21:04 2003 From: johnsonm at redhat.com (Michael K. Johnson) Date: Fri, 22 Aug 2003 13:21:04 -0400 Subject: 2 package patching questions In-Reply-To: <1061527627.9194.43.camel@localhost.localdomain>; from gkarabin@pobox.com on Thu, Aug 21, 2003 at 09:47:08PM -0700 References: <1061527627.9194.43.camel@localhost.localdomain> Message-ID: <20030822132104.A26440@devserv.devel.redhat.com> On Thu, Aug 21, 2003 at 09:47:08PM -0700, George J Karabin wrote: > Question #2: > > Does anyone have a take on whether or not it's appropriate to use the > "-a" option to add binary files (like graphics) to a patch? I can't > recall ever seeing a patch distributed with one, and reading such a > thing probably does wonders for terminals (random escaped character > sequences) but the following page seems to indicate that it's an OK > practice: > http://www.gnu.org/manual/diffutils/html_node/Tips-for-Patch-Producers.html#Tips%20for%20Patch%20Producers In the RPM universe, it's normally better to make it a separate source file rather than a patch. 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 m.a.young at durham.ac.uk Fri Aug 22 19:10:37 2003 From: m.a.young at durham.ac.uk (M A Young) Date: Fri, 22 Aug 2003 20:10:37 +0100 (BST) Subject: UML project for Cambridge++ (update 1) In-Reply-To: References: Message-ID: This is the first of an intended weekly update on this project. I have had several problems getting a working uml kernel, but there is now a kernel available to test from the directory http://toast.debian.net/~may/umlproject/unpackaged/ which will work in at least some circumstances. It doesn't work with a severn host kernel, (this message http://marc.theaimsgroup.com/?l=user-mode-linux-devel&m=106156343822138&w=2 may explain why), and crashes later in the boot with a 2.6.0 host kernel. It does work more me on shrike. It also doesn't work if the uml image has tls libraries installed, as the 2.6 uml is missing the set_thread_area and get_thread_area syscalls, and even though I have patched the kernel to return ENOSYS rather than crashing, glibc still doesn't cope. For the moment renaming /usr/tls or using the i386 glibc should work. The configuration is arjan's base i686 configuration, with some uml options added and some options like modules, scsi and networking removed so that the kernel compiles. There have also been some minor updates to the website http://toast.debian.net/~may/umlproject/ Michael Young From gkarabin at pobox.com Sat Aug 23 02:10:19 2003 From: gkarabin at pobox.com (George J Karabin) Date: Fri, 22 Aug 2003 19:10:19 -0700 Subject: 2 package patching questions In-Reply-To: <20030822132104.A26440@devserv.devel.redhat.com> References: <1061527627.9194.43.camel@localhost.localdomain> <20030822132104.A26440@devserv.devel.redhat.com> Message-ID: <1061604619.8908.2.camel@localhost.localdomain> Thanks Bill, Michael. I'm looking forward to seeing RHLP making more packages visible via public anonymous CVS. I hope that's a reasonable assumption. - George From dave.bevan at bbc.co.uk Sat Aug 23 02:12:41 2003 From: dave.bevan at bbc.co.uk (Dave Bevan) Date: Sat, 23 Aug 2003 03:12:41 +0100 Subject: AGPGART Message-ID: Does anyone know (for Severn-Beta-1 or Severn-Beta-1+Arjanv's 2.6-test3.1.31 kernel) the following: a) If AGPGART does AGP 8X on Intel 875p AGP chipsets? b) A way of querying AGPGART settings, in particular AGP Window Size, on a running kernel? -- Dave. Dave Bevan | New Media Support Specialist BBC News Support | London BBCi at http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From goeran at uddeborg.se Sat Aug 23 21:16:10 2003 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran?= Uddeborg) Date: Sat, 23 Aug 2003 23:16:10 +0200 Subject: /usr boot time dependencies In-Reply-To: <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> References: <20030818094035.B16286@devserv.devel.redhat.com> <20030820051324.GA3156@dudweiler.stuttgart.redhat.com> Message-ID: <16199.55706.645527.189240@uebn.uddeborg.se> Florian La Roche writes: > "sort -u" is a GNU extension. I don't think so. Option -u to sort is required by the Unix standard (as seen at http://www.opengroup.org/ both version 2 and 3). I also looked up my BSD manual from 1980, and "sort -u" was supported in that one too. :-) From barryn at pobox.com Sat Aug 23 22:49:45 2003 From: barryn at pobox.com (Barry K. Nathan) Date: Sat, 23 Aug 2003 15:49:45 -0700 Subject: librt.so TLS issues In-Reply-To: <1061460427.6035.26.camel@localhost.localdomain> References: <1061460427.6035.26.camel@localhost.localdomain> Message-ID: <20030823224945.GA1336@ip68-4-255-84.oc.oc.cox.net> On Thu, Aug 21, 2003 at 12:07:07PM +0200, Alexander Larsson wrote: > There was a change in glibc somewhere between 2.3.2-57 and 2.3.2-66 that > adds /usr/lib/librt.so.1 to glibc-devel. The file is just a symlink to > librt.so. This change seems wrong to me, and its causing breakage with > TLS. [snip] > Having the soname librt in /usr/lib just seems wrong to me. What was the > reason for introducing it? Another question: Was the link introduced intentionally? I've noticed that if I rm the link, it's recreated the next time I run /sbin/ldconfig. -Barry K. Nathan From dee at renaissoft.com Mon Aug 25 07:52:52 2003 From: dee at renaissoft.com (Dee-Ann LeBlanc) Date: 25 Aug 2003 00:52:52 -0700 Subject: Athlon 64 support? Message-ID: <1061797972.29854.95.camel@localhost.localdomain> I understand that Red Hat is planning to support Athlon 64 machines specifically in the Enterprise line? Is this correct? (I'm not bashing or judging, just confirming a fact. :) -- Dee-Ann LeBlanc, RHCE Lots of things Linux http://www.Dee-AnnLeBlanc.com/ From feliciano.matias at free.fr Mon Aug 25 09:07:17 2003 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: 25 Aug 2003 11:07:17 +0200 Subject: linux/autoconf.h and RED_HAT_LINUX_KERNEL Message-ID: <1061802436.1133.145.camel@one.myworld> First, i am not a "kernel hacker". If /usr/src/linux-2.4/include/linux/autoconf.h is generated by "make menuconfig" or "oldconfig", ... the news autoconf.h doesn't include linux/rhconfig.h. It's normal since the original autoconf.h and rhconfig.h conform with binary Redhat kernel supply with the distribution. If i let autoconf.h untouched, "#include " define the RED_HAD_LINUX_KERNEL macro. That's nice. But if a use a "custom" kernel (make mrproper, make...) , RED_HAT_LINUX_KERNEL macro is not more defined. This cause some trouble with alsa-driver. I try to build alsa for RH9 from freshrpms : http://shrike.freshrpms.net/rpm.html?id=856 Alsa's configure try to find out if a RedHat kernel is used : boolvar=RED_HAT_LINUX_KERNEL echo "$as_me:3104: checking for redhat kernel" >&5 echo $ECHO_N "checking for redhat kernel... $ECHO_C" >&6 ac_save_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS -I$CONFIG_SND_KERNELDIR/include" boolchk="" if test "$cross_compiling" = yes; then echo "$as_me:3110: result: \"unknown\"" >&5 echo "${ECHO_T}\"unknown\"" >&6;boolchk="" else cat >conftest.$ac_ext <<_ACEOF #line 3115 "configure" #include "confdefs.h" #include "$CONFIG_SND_KERNELDIR/include/linux/autoconf.h" int main( void ) { #ifndef $boolvar exit(1); #else exit(0); #endif } _ACEOF This doesn't work with a custom kernel. Even with a not so custom kernel : $ make mrproper $ cp configs/kernel___config .config $ make dep Perhaps, you can add RED_HAT_LINUX_KERNEL_SOURCE in autoconf.h and leave RED_HAT_LINUX_KERNEL only in rhconfig.h. -- F?liciano Matias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rhldevel at assursys.co.uk Mon Aug 25 11:50:23 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Mon, 25 Aug 2003 12:50:23 +0100 (BST) Subject: RH Taroon Beta Open Ports Message-ID: Hi - I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled. The following services are listening on external network interfaces: Port State Service 22/tcp open ssh 68/udp open dhcpclient 111/tcp open sunrpc 111/udp open sunrpc 123/udp open ntp 1010/udp open unknown 6000/tcp open X11 ssh (we don't want to lock users out after an upgrade), ntp and dhcpclient (both manually configured during install) are reasonably justified, IMHO, but what is the justification for having rpc.statd, portmap and X11 listening by *default* (especially on a machine that hasn't been configured to use NIS)? Given the problems that Windows has with network services listening by default, shouldn't we be learning from their mistakes? Yes, the user needs to disable firewalling at install time to expose these services, but I can't help thinking that plenty of na?ve users will do so... Best Regards, Alex. From thomas at apestaart.org Mon Aug 25 12:04:10 2003 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 25 Aug 2003 14:04:10 +0200 Subject: RH Taroon Beta Open Ports In-Reply-To: References: Message-ID: <1061813049.19296.1923.camel@thocra> On Mon, 2003-08-25 at 13:50, rhldevel at assursys.co.uk wrote: > 111/tcp open sunrpc > 111/udp open sunrpc both are necessary for NFS mounts to work, since these requests go through portmap. > 1010/udp open unknown check with netstat to see what is running here, have no idea. > 6000/tcp open X11 AFAIK this doesn't mean anyone can connect; there's still a lot of X authority stuff to get through (specifically, the X runner needs to authorize outside connections). I think this setup is pretty safe :) What exactly do you not trust ? Thomas Dave/Dina : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> en in jouw handen was ik een zieke hond die je smeekte geef je over <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.rug.ac.be/ From rhldevel at assursys.co.uk Mon Aug 25 12:11:12 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Mon, 25 Aug 2003 13:11:12 +0100 (BST) Subject: RH Taroon Beta Open Ports In-Reply-To: <1061813049.19296.1923.camel@thocra> References: <1061813049.19296.1923.camel@thocra> Message-ID: On Mon, 25 Aug 2003, Thomas Vander Stichele wrote: > On Mon, 2003-08-25 at 13:50, rhldevel at assursys.co.uk wrote: > > 111/tcp open sunrpc > > 111/udp open sunrpc > > both are necessary for NFS mounts to work, since these requests go > through portmap. Sure, but no NFS mounts were configured on install. Perhaps anaconda should parse /etc/fstab if an upgrade install is being performed to determine whether portmap is likely to be necessary or not. > > 1010/udp open unknown > > check with netstat to see what is running here, have no idea. rpc.statd. See above. > > 6000/tcp open X11 > > AFAIK this doesn't mean anyone can connect; there's still a lot of X > authority stuff to get through (specifically, the X runner needs to > authorize outside connections). I'm thinking in terms of DoS and zombies-via-buffer-overflow of the X server (which is running with root privs, too, of course). Any listening service is a potential risk, even if it requires authentication before it can be used in the "normal" way. > I think this setup is pretty safe :) What exactly do you not trust ? Everyone and everything, but that's a topic for another thread entirely. ;-) > Thomas Best Regards, Alex. From felipe_alfaro at linuxmail.org Mon Aug 25 12:13:21 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 25 Aug 2003 14:13:21 +0200 Subject: RH Taroon Beta Open Ports In-Reply-To: References: Message-ID: <1061813601.710.12.camel@teapot.felipe-alfaro.com> On Mon, 2003-08-25 at 13:50, rhldevel at assursys.co.uk wrote: > Hi - > > I've just done a "complete" install of Taroon on a scratch box, with > iptables firewalling disabled. The following services are listening on > external network interfaces: > > Port State Service > 22/tcp open ssh > 68/udp open dhcpclient > 111/tcp open sunrpc > 111/udp open sunrpc > 123/udp open ntp > 1010/udp open unknown > 6000/tcp open X11 > > ssh (we don't want to lock users out after an upgrade), ntp and dhcpclient > (both manually configured during install) are reasonably justified, IMHO, > but what is the justification for having rpc.statd, portmap and X11 > listening by *default* (especially on a machine that hasn't been configured > to use NIS)? rpc.statd and portmap aren't the exclusive domain of NIS. Both are enabled by default and used by NFS as client or server. I think they could be disabled by default instead of being enabled by default. You can disable both services: # chkconfig --level 12345 portmap off # chkconfig --level 12345 nfslock off If you don't want the NFS server: # chkconfig --level 12345 nfs off From rhldevel at assursys.co.uk Mon Aug 25 12:28:26 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Mon, 25 Aug 2003 13:28:26 +0100 (BST) Subject: RH Taroon Beta Open Ports In-Reply-To: <1061813601.710.12.camel@teapot.felipe-alfaro.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> Message-ID: On Mon, 25 Aug 2003, Felipe Alfaro Solana wrote: > On Mon, 2003-08-25 at 13:50, rhldevel at assursys.co.uk wrote: > > Hi - > > > > I've just done a "complete" install of Taroon on a scratch box, with > > iptables firewalling disabled. The following services are listening on > > external network interfaces: > > > > Port State Service > > 22/tcp open ssh > > 68/udp open dhcpclient > > 111/tcp open sunrpc > > 111/udp open sunrpc > > 123/udp open ntp > > 1010/udp open unknown > > 6000/tcp open X11 > > > > ssh (we don't want to lock users out after an upgrade), ntp and dhcpclient > > (both manually configured during install) are reasonably justified, IMHO, > > but what is the justification for having rpc.statd, portmap and X11 > > listening by *default* (especially on a machine that hasn't been configured > > to use NIS)? > > rpc.statd and portmap aren't the exclusive domain of NIS. Sure, but that was my best guess as to why they might be enabled by default (but which would still be irrelevant to the installation scenario I gave). > Both are enabled by default and used by NFS as client or server. I think > they could be disabled by default instead of being enabled by default. > > You can disable both services: > > # chkconfig --level 12345 portmap off > # chkconfig --level 12345 nfslock off > > If you don't want the NFS server: > > # chkconfig --level 12345 nfs off *We* know this, but I suspect a large number of users don't and won't. I wouldn't like for RH Linux to become the target of a worm with the impact of Blaster, /even if/ the default RH firewall setup would prevent it, and errata had already been released. Leaving unnecessary ports open on a default install (firewall or not) is a security and PR disaster waiting to happen, IMHO. There's no reason why a install shouldn't be more tolerant of user stupidity, especially when turning those services on is no more difficult than turning them off. ;-) Best Regards, Alex. From paul at dishone.st Mon Aug 25 12:52:57 2003 From: paul at dishone.st (Paul Jakma) Date: Mon, 25 Aug 2003 13:52:57 +0100 (IST) Subject: RH Taroon Beta Open Ports In-Reply-To: <1061813601.710.12.camel@teapot.felipe-alfaro.com> Message-ID: On Mon, 25 Aug 2003, Felipe Alfaro Solana wrote: > rpc.statd and portmap aren't the exclusive domain of NIS. Both are > enabled by default and used by NFS as client or server. I think they > could be disabled by default instead of being enabled by default. sgi_fam is an RPC service and needs portmap and is used, i think, by some of the GUI stuff (eg nautilus). portmap needs to be locally accessible. i do think portmap and rpc.statd should be firewalled off by default though. redhat-config-nfs or similar could enable portmap access if nfs mounts are configured. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: The avoidance of taxes is the only intellectual pursuit that carries any reward. -- John Maynard Keynes From pekkas at netcore.fi Mon Aug 25 13:25:45 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Mon, 25 Aug 2003 16:25:45 +0300 (EEST) Subject: RH Taroon Beta Open Ports In-Reply-To: Message-ID: On Mon, 25 Aug 2003, Paul Jakma wrote: > On Mon, 25 Aug 2003, Felipe Alfaro Solana wrote: > > > rpc.statd and portmap aren't the exclusive domain of NIS. Both are > > enabled by default and used by NFS as client or server. I think they > > could be disabled by default instead of being enabled by default. > > sgi_fam is an RPC service and needs portmap and is used, i think, by > some of the GUI stuff (eg nautilus). portmap needs to be locally > accessible. > > i do think portmap and rpc.statd should be firewalled off by default > though. redhat-config-nfs or similar could enable portmap access if > nfs mounts are configured. .. and maybe even a default /etc/hosts.allow deny for portmap etc. to be double sure and protect against people turning off the firewall. :-) Could create a lot of confusion and support reqs though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From icon at linux.duke.edu Mon Aug 25 13:30:43 2003 From: icon at linux.duke.edu (Konstantin Riabitsev) Date: 25 Aug 2003 09:30:43 -0400 Subject: gconfd logs Message-ID: <1061818243.10124.6.camel@hagrid.phy.duke.edu> Hello, all: This is aimed at Havoc mostly -- I think it's a bad idea to i18n-ize the stuff that goes into syslog, which is what gconfd currently does. We have many users using various languages, and it doesn't help to see gconfd error reports in Chinese or Korean. Can we just stick to English for the backend stuff that the user never sees? Alternatively, it would be good to have two settings for the locale -- one for the user currently logged in at the console, and another set by the sysadmin for the stuff they want to see in the logs. Really, seeing error reports in Chinese does me little good, and can't be analyzed by various log-reporting tools. Any thoughts? Regards, -- Konstantin ("Icon") Riabitsev Duke Physics Sysadmin, RHCE From rhldevel at assursys.co.uk Mon Aug 25 13:33:58 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Mon, 25 Aug 2003 14:33:58 +0100 (BST) Subject: RH Taroon Beta Open Ports In-Reply-To: References: Message-ID: On Mon, 25 Aug 2003, Paul Jakma wrote: > On Mon, 25 Aug 2003, Felipe Alfaro Solana wrote: > > > rpc.statd and portmap aren't the exclusive domain of NIS. Both are > > enabled by default and used by NFS as client or server. I think they > > could be disabled by default instead of being enabled by default. > > sgi_fam is an RPC service and needs portmap and is used, i think, by > some of the GUI stuff (eg nautilus). portmap needs to be locally > accessible. > > i do think portmap and rpc.statd should be firewalled off by default > though. I'm pretty sure they are. What I object to is having them listen on *non-loopback* interfaces needlessly. > redhat-config-nfs or similar could enable portmap access if > nfs mounts are configured. Quite. Best Regards, Alex. From felipe_alfaro at linuxmail.org Mon Aug 25 14:12:13 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 25 Aug 2003 16:12:13 +0200 Subject: RH Taroon Beta Open Ports In-Reply-To: <1061813049.19296.1923.camel@thocra> References: <1061813049.19296.1923.camel@thocra> Message-ID: <1061820733.681.1.camel@teapot.felipe-alfaro.com> On Mon, 2003-08-25 at 14:04, Thomas Vander Stichele wrote: > check with netstat to see what is running here, have no idea. > > > 6000/tcp open X11 If you intend to only run X11 apps locally (DISPLAY=:0.0 using local socket transport), you can add "-nolisten tcp" to /etc/X11/xdm/Xservers. This will definitively close the port 6000/tcp. From SteveD at redhat.com Mon Aug 25 14:57:38 2003 From: SteveD at redhat.com (Steve Dickson) Date: Mon, 25 Aug 2003 10:57:38 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <1061813601.710.12.camel@teapot.felipe-alfaro.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> Message-ID: <3F4A23E2.3020907@RedHat.com> Felipe Alfaro Solana wrote: >On Mon, 2003-08-25 at 13:50, rhldevel at assursys.co.uk wrote: > > >>Hi - >> >>I've just done a "complete" install of Taroon on a scratch box, with >>iptables firewalling disabled. The following services are listening on >>external network interfaces: >> >>Port State Service >>22/tcp open ssh >>68/udp open dhcpclient >>111/tcp open sunrpc >>111/udp open sunrpc >>123/udp open ntp >>1010/udp open unknown >>6000/tcp open X11 >> >>ssh (we don't want to lock users out after an upgrade), ntp and dhcpclient >>(both manually configured during install) are reasonably justified, IMHO, >>but what is the justification for having rpc.statd, portmap and X11 >>listening by *default* (especially on a machine that hasn't been configured >>to use NIS)? >> >> > >rpc.statd and portmap aren't the exclusive domain of NIS. Both are >enabled by default and used by NFS as client or server. I think they >could be disabled by default instead of being enabled by default. > >You can disable both services: > ># chkconfig --level 12345 portmap off ># chkconfig --level 12345 nfslock off > >If you don't want the NFS server: > ># chkconfig --level 12345 nfs off > > statd (i.e. nfslock) probably does not need to be running if NFS is not configured but tunning off portmapper is a bit extreme... Not only do local process expect portmapper to be there, remote process also expect portmapper to be there ... The point being turning off portmapper could (and probably will) cause unexpect process to fail in unexpect ways making very difficult to debug especially during installation... Portmapper has been around quite a long time making it pretty bullet proof... So I see no reason what so ever to turn off portmapper. Lets not make a system more difficult to deal with for simply no reason... SteveD. From laroche at redhat.com Mon Aug 25 14:59:53 2003 From: laroche at redhat.com (Florian La Roche) Date: Mon, 25 Aug 2003 16:59:53 +0200 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A23E2.3020907@RedHat.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> Message-ID: <20030825145953.GA14676@dudweiler.stuttgart.redhat.com> > So I see no reason what so ever to turn off portmapper. Lets not make a > system more difficult to deal with for simply no reason... I agree. It makes "client usage" much easier and servers should anyway get protection via firewalls and special security changes. greetings, Florian La Roche From davej at redhat.com Mon Aug 25 15:09:54 2003 From: davej at redhat.com (Dave Jones) Date: Mon, 25 Aug 2003 16:09:54 +0100 Subject: AGPGART In-Reply-To: References: Message-ID: <20030825150954.GA12943@redhat.com> On Sat, Aug 23, 2003 at 03:12:41AM +0100, Dave Bevan wrote: > Does anyone know (for Severn-Beta-1 or Severn-Beta-1+Arjanv's 2.6-test3.1.31 kernel) the following: > > a) If AGPGART does AGP 8X on Intel 875p AGP chipsets? Untested. It may need specific chipset magic to make it work, but it should be calling the generic routines to try and make stuff work in AGP 3.0 mode if it's capable. > b) A way of querying AGPGART settings, in particular AGP Window Size, on a running kernel? Aperture size is reported when the module initialises (ie, after modprobe intel-agp in your case). Dave -- Dave Jones http://www.codemonkey.org.uk From elanthis at awesomeplay.com Mon Aug 25 14:54:18 2003 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 25 Aug 2003 10:54:18 -0400 Subject: Athlon 64 support? In-Reply-To: <1061797972.29854.95.camel@localhost.localdomain> References: <1061797972.29854.95.camel@localhost.localdomain> Message-ID: <1061823257.13015.9.camel@smiddle.civic.twp.ypsilanti.mi.us> On Mon, 2003-08-25 at 03:52, Dee-Ann LeBlanc wrote: > I understand that Red Hat is planning to support Athlon 64 machines > specifically in the Enterprise line? Is this correct? (I'm not bashing > or judging, just confirming a fact. :) Supporting Athlon 64 in the Enterprise line only would be daft, as Athlon 64 is a consumer chip. Perhaps you meant Opteron, the server/workstation AMD64 CPU? But speaking of Athlon 64, will a consumer RHL project release be made for it? -- Sean Middleditch AwesomePlay Productions, Inc. From rhldevel at assursys.co.uk Mon Aug 25 15:27:07 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Mon, 25 Aug 2003 16:27:07 +0100 (BST) Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A23E2.3020907@RedHat.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> Message-ID: On Mon, 25 Aug 2003, Steve Dickson wrote: > Felipe Alfaro Solana wrote: > >On Mon, 2003-08-25 at 13:50, rhldevel at assursys.co.uk wrote: > >>I've just done a "complete" install of Taroon on a scratch box, with > >>iptables firewalling disabled. The following services are listening on > >>external network interfaces: > >> > >>Port State Service > >>22/tcp open ssh > >>68/udp open dhcpclient > >>111/tcp open sunrpc > >>111/udp open sunrpc > >>123/udp open ntp > >>1010/udp open unknown > >>6000/tcp open X11 > >> > >>ssh (we don't want to lock users out after an upgrade), ntp and dhcpclient > >>(both manually configured during install) are reasonably justified, IMHO, > >>but what is the justification for having rpc.statd, portmap and X11 > >>listening by *default* (especially on a machine that hasn't been configured > >>to use NIS)? [snip] > statd (i.e. nfslock) probably does not need to be running if NFS is not > configured but > tunning off portmapper is a bit extreme... Not only do local process > expect portmapper > to be there, Which local processes? We've already heard about sgi_fam, and we already know about NIS and NFS, but is this really worth leaving it listening on external interfaces in a _default_ install? > remote process also expect portmapper to be there ... And I expect there have been similar arguments in Redmond regarding their RPC implementation. In my experience it's not used commonly enough that it deserves to be listening for random connections. > The > point being turning off portmapper could (and probably will) cause > unexpect process > to fail in unexpect ways making very difficult to debug especially > during installation... As a matter of course, I disable portmap and rpc.statd on any machine not expected to perform NFS or NIS and have not noticed any side effects as a result. > Portmapper has been around quite a long time making it pretty bullet > proof... Funny, 'cos in my universe, the portmapper is regarded as one of the most vulnerable pieces of UNIX software, along with rpc.statd, sendmail and BIND. > So I see no reason what so ever to turn off portmapper. Lets not make a > system more difficult to deal with for simply no reason... ...but there is a reason - making new installs secure by default. For a admin who's already configuring NFS or similar, the extra step of chkconfig'ing portmap and rpc.statd isn't much of a burden. > SteveD. Best Regards, Alex. From notting at redhat.com Mon Aug 25 15:30:22 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 25 Aug 2003 11:30:22 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: ; from rhldevel@assursys.co.uk on Mon, Aug 25, 2003 at 04:27:07PM +0100 References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> Message-ID: <20030825113022.A29673@devserv.devel.redhat.com> rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) said: > Which local processes? We've already heard about sgi_fam, and we already > know about NIS and NFS, but is this really worth leaving it listening on > external interfaces in a _default_ install? Set up a firewall, as is the default in the install... Bill From rhldevel at assursys.co.uk Mon Aug 25 15:31:12 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Mon, 25 Aug 2003 16:31:12 +0100 (BST) Subject: RH Taroon Beta Open Ports In-Reply-To: <20030825145953.GA14676@dudweiler.stuttgart.redhat.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825145953.GA14676@dudweiler.stuttgart.redhat.com> Message-ID: On Mon, 25 Aug 2003, Florian La Roche wrote: > > So I see no reason what so ever to turn off portmapper. Lets not make a > > system more difficult to deal with for simply no reason... > > I agree. It makes "client usage" much easier and There's always a trade-off between security and ease-of-use. What proportion of the installed base of Linux clients use RPC-based protocols? Not many I'd wager, suggesting that the trade-off can be biased towards security, with little-to-no impact on the majority of users. > servers should anyway get protection via firewalls and special security > changes. "should" and "do" are quite different things. Servers should also have security updates applied in a timely manner, but they frequently tend not to in the real world. Where security is concerned, it's best not to rely upon single points of failure. > greetings, > Florian La Roche Best Regards, Alex. From kaboom at gatech.edu Mon Aug 25 15:34:59 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Mon, 25 Aug 2003 09:34:59 -0600 (MDT) Subject: RH Taroon Beta Open Ports In-Reply-To: References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825145953.GA14676@dudweiler.stuttgart.redhat.com> Message-ID: On Mon, 25 Aug 2003 rhldevel at assursys.co.uk wrote: > There's always a trade-off between security and ease-of-use. What proportion > of the installed base of Linux clients use RPC-based protocols? Not many I'd > wager, suggesting that the trade-off can be biased towards security, with > little-to-no impact on the majority of users. Most Linux client systems, in my experience, are NFS clients and therefore need portmap, statd, and lockd out-of-the-box. later, chris From rhldevel at assursys.co.uk Mon Aug 25 15:45:22 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Mon, 25 Aug 2003 16:45:22 +0100 (BST) Subject: RH Taroon Beta Open Ports In-Reply-To: <20030825113022.A29673@devserv.devel.redhat.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825113022.A29673@devserv.devel.redhat.com> Message-ID: On Mon, 25 Aug 2003, Bill Nottingham wrote: > rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) said: > > Which local processes? We've already heard about sgi_fam, and we already > > know about NIS and NFS, but is this really worth leaving it listening on > > external interfaces in a _default_ install? > > Set up a firewall, as is the default in the install... Certainly, and allowing easy configuration of Linux's IP filtering functionality at install time was a very responsible move by RH. But to a lot of na?ve users, firewalls are deeply technical things, that they worry will interfere with normal usage. As a result, I believe a number of such users will install with the firewall disabled, or stop it when attempting to get things working - perhaps never to (re-)enable it. Having things like X11, portmapper and rpc.statd listening on an external interface is asking for trouble, IMHO. > Bill Best Regards, Alex. From hbo at egbok.com Mon Aug 25 16:04:48 2003 From: hbo at egbok.com (Howard Owen) Date: 25 Aug 2003 09:04:48 -0700 Subject: RH Taroon Beta Open Ports In-Reply-To: References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825113022.A29673@devserv.devel.redhat.com> Message-ID: <1061827487.1328.10.camel@owen.egbok.com> Why not configure portmapper to listen on localhost, then have the services (mountd, ypserv, etc.) that need it enable listening on the wire when they start? You'd need a cooperative arrangement whereby the init scripts would shut down external portmapper if they were the last service that needed it on service shutdown. Of course, you can argue that an admin that is configuring NFS or NIS should understand the security implications and other requirements of these services, but we don't live in a perfect world. and therefore be able to On Mon, 2003-08-25 at 08:45, rhldevel at assursys.co.uk wrote: > On Mon, 25 Aug 2003, Bill Nottingham wrote: > > > rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) said: > > > Which local processes? We've already heard about sgi_fam, and we already > > > know about NIS and NFS, but is this really worth leaving it listening on > > > external interfaces in a _default_ install? > > > > Set up a firewall, as is the default in the install... > > Certainly, and allowing easy configuration of Linux's IP filtering > functionality at install time was a very responsible move by RH. > > But to a lot of na?ve users, firewalls are deeply technical things, that > they worry will interfere with normal usage. As a result, I believe a number > of such users will install with the firewall disabled, or stop it when > attempting to get things working - perhaps never to (re-)enable it. Having > things like X11, portmapper and rpc.statd listening on an external interface > is asking for trouble, IMHO. > > > Bill > > Best Regards, > Alex. > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From notting at redhat.com Mon Aug 25 16:09:16 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 25 Aug 2003 12:09:16 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <1061827487.1328.10.camel@owen.egbok.com>; from hbo@egbok.com on Mon, Aug 25, 2003 at 09:04:48AM -0700 References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825113022.A29673@devserv.devel.redhat.com> <1061827487.1328.10.camel@owen.egbok.com> Message-ID: <20030825120916.A26653@devserv.devel.redhat.com> Howard Owen (hbo at egbok.com) said: > Why not configure portmapper to listen on localhost, then have the > services (mountd, ypserv, etc.) that need it enable listening on the > wire when they start? You'd need a cooperative arrangement whereby the > init scripts would shut down external portmapper if they were the last > service that needed it on service shutdown. Having 'mount' try and configure services would be exceedingly messy. Bill From rhldevel at assursys.co.uk Mon Aug 25 15:50:27 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Mon, 25 Aug 2003 16:50:27 +0100 (BST) Subject: RH Taroon Beta Open Ports In-Reply-To: References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825145953.GA14676@dudweiler.stuttgart.redhat.com> Message-ID: On Mon, 25 Aug 2003, Chris Ricker wrote: > On Mon, 25 Aug 2003 rhldevel at assursys.co.uk wrote: > > > There's always a trade-off between security and ease-of-use. What proportion > > of the installed base of Linux clients use RPC-based protocols? Not many I'd > > wager, suggesting that the trade-off can be biased towards security, with > > little-to-no impact on the majority of users. > > Most Linux client systems, in my experience, are NFS clients and therefore > need portmap, statd, and lockd out-of-the-box. For libraries, labs, schools and universities, that wouldn't surprise me. Such organisations generally have good-to-excellent security awareness. But for small-to-medium businesses (who have the least security awareness and infrastructure) and home users (similarly), I'd categorically disagree. If any file/print sharing is happening in these environments, it's usually SMB based. Samba doesn't get enabled by default, so why the exception for portmap and rpc.statd? > later, > chris Best Regards, Alex. From dhollis at davehollis.com Mon Aug 25 17:05:57 2003 From: dhollis at davehollis.com (David T Hollis) Date: Mon, 25 Aug 2003 13:05:57 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825145953.GA14676@dudweiler.stuttgart.redhat.com> Message-ID: <3F4A41F5.1070802@davehollis.com> rhldevel at assursys.co.uk wrote: >On Mon, 25 Aug 2003, Chris Ricker wrote: > > > >>On Mon, 25 Aug 2003 rhldevel at assursys.co.uk wrote: >> >> >> >>>There's always a trade-off between security and ease-of-use. What proportion >>>of the installed base of Linux clients use RPC-based protocols? Not many I'd >>>wager, suggesting that the trade-off can be biased towards security, with >>>little-to-no impact on the majority of users. >>> >>> >>Most Linux client systems, in my experience, are NFS clients and therefore >>need portmap, statd, and lockd out-of-the-box. >> >> > >For libraries, labs, schools and universities, that wouldn't surprise me. >Such organisations generally have good-to-excellent security awareness. > >But for small-to-medium businesses (who have the least security awareness >and infrastructure) and home users (similarly), I'd categorically disagree. >If any file/print sharing is happening in these environments, it's usually >SMB based. Samba doesn't get enabled by default, so why the exception for >portmap and rpc.statd? > > > >>later, >>chris >> >> > >Best Regards, >Alex. > > >-- >Rhl-devel-list mailing list >Rhl-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/rhl-devel-list > > Apache is quite possibly used in by more users than NFS and it is not enabled by default either. I think that if portmap is really that necessary, and I don't think it is, having it configured to only listen on loopback - akin to the stock sendmail configuration - would be a good step. If the admin wants to enable NFS, they tweak the config or a sysconfig entry and voila, they are on the network. Asking an admin that wants to use NFS to do a couple of chkconfig statements is not much, especially when it reduces the network footprint of the stock install. From ghenriks at rogers.com Mon Aug 25 17:08:48 2003 From: ghenriks at rogers.com (Gerald Henriksen) Date: Mon, 25 Aug 2003 13:08:48 -0400 Subject: Athlon 64 support? In-Reply-To: <1061823257.13015.9.camel@smiddle.civic.twp.ypsilanti.mi.us> References: <1061797972.29854.95.camel@localhost.localdomain> <1061823257.13015.9.camel@smiddle.civic.twp.ypsilanti.mi.us> Message-ID: <5bgkkvc073uamsd3pnmocqrag3t9g09l9g@4ax.com> On Mon, 25 Aug 2003 10:54:18 -0400, you wrote: >On Mon, 2003-08-25 at 03:52, Dee-Ann LeBlanc wrote: >> I understand that Red Hat is planning to support Athlon 64 machines >> specifically in the Enterprise line? Is this correct? (I'm not bashing >> or judging, just confirming a fact. :) > >Supporting Athlon 64 in the Enterprise line only would be daft, as >Athlon 64 is a consumer chip. Perhaps you meant Opteron, the >server/workstation AMD64 CPU? But speaking of Athlon 64, will a >consumer RHL project release be made for it? The Enterprise line does have AMD64 version for the next release (which is currently in beta - named taroon). Red Hat Linux 10 (currently in beta - severn) supports IA32 (Pentium, PII, PIII, PIV, Athlon) only. It is expected as the Red Hat Linux Project gets going the community will provide an AMD64 version in the future. From jim at rossberry.com Mon Aug 25 17:29:38 2003 From: jim at rossberry.com (Jim Wildman) Date: Mon, 25 Aug 2003 13:29:38 -0400 (EDT) Subject: RH Taroon Beta Open Ports In-Reply-To: Message-ID: On Mon, 25 Aug 2003 rhldevel at assursys.co.uk wrote: > But to a lot of na?ve users, firewalls are deeply technical things, that > they worry will interfere with normal usage. As a result, I believe a number > of such users will install with the firewall disabled, or stop it when > attempting to get things working - perhaps never to (re-)enable it. Having > things like X11, portmapper and rpc.statd listening on an external interface > is asking for trouble, IMHO. > > > Bill > > Best Regards, > Alex. > I agree with Alex. If nfs is being used, it is because there is a knowledgeable person around to set it up. (Is there a client included by default with MS systems?). Better to have it off and close one more potential hole. ------------------------------------------------------------------------ Jim Wildman, CISSP, RHCE jim at rossberry.com http://www.rossberry.com From notting at redhat.com Mon Aug 25 17:44:54 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 25 Aug 2003 13:44:54 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: ; from jim@rossberry.com on Mon, Aug 25, 2003 at 01:29:38PM -0400 References: Message-ID: <20030825134454.A8928@devserv.devel.redhat.com> Jim Wildman (jim at rossberry.com) said: > I agree with Alex. If nfs is being used, it is because there is a > knowledgeable person around to set it up. (Is there a client included > by default with MS systems?). Better to have it off and close one > more potential hole. Counterargument: If the default firewall that already protects you is changed, it is because there is a knowledgeable person that changed it, right? You can't have it both ways. Bill From chuckw at quantumlinux.com Mon Aug 25 18:03:21 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 25 Aug 2003 11:03:21 -0700 (PDT) Subject: RH Taroon Beta Open Ports In-Reply-To: <1061813049.19296.1923.camel@thocra> Message-ID: > > 111/tcp open sunrpc > > 111/udp open sunrpc > > both are necessary for NFS mounts to work, since these requests go > through portmap. Yes, that is true, but they shouldn't be open at all until the user configures them to be open. IIRC, the installer doesn't set up nfs mounts. Personally, I'm of the opinion that nfs in particular should be deliberately hard to setup for newbs. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From i.pilcher at comcast.net Mon Aug 25 18:06:09 2003 From: i.pilcher at comcast.net (Ian Pilcher) Date: Mon, 25 Aug 2003 13:06:09 -0500 Subject: Services & firewall configuration Message-ID: <3F4A5011.9010109@comcast.net> Reading the discussion about Taroon, portmapper, ports, etc., reminded me of one of the shortcomings of Red Hat Linux (and all other distributions AFAIK). It seems to me that the fundamental problem is the lack of "linkage" (for lack of a better word) between service configuration and firewall configuration. In an ideal world, the network access required by a service would be easy to determine -- perhaps with chkconfig-like meta- data in the init script. The firewall configuration program could then be enhanced to prompt accordingly. Even better, to my mind, would be to actually combine the services and firewall configuration programs. Instead of a single checkbox for each service, each service would have a checkbox for each interface. The network configuration program should probably prompt the user to run the firewall configuration when an interface is added. Just some thoughts on future directions. Flame away! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From chuckw at quantumlinux.com Mon Aug 25 18:16:43 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 25 Aug 2003 11:16:43 -0700 (PDT) Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A23E2.3020907@RedHat.com> Message-ID: > Portmapper has been around quite a long time making it pretty bullet > proof... Longevity has nothing to do with how secure an app is. Any evidence to the contrary is anecdotal ;) -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From SteveD at redhat.com Mon Aug 25 18:18:35 2003 From: SteveD at redhat.com (Steve Dickson) Date: Mon, 25 Aug 2003 14:18:35 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> Message-ID: <3F4A52FB.1030103@RedHat.com> rhldevel at assursys.co.uk wrote: >>statd (i.e. nfslock) probably does not need to be running if NFS is not >>configured but >>tunning off portmapper is a bit extreme... Not only do local process >>expect portmapper >>to be there, >> >> > >Which local processes? We've already heard about sgi_fam, and we already >know about NIS and NFS, but is this really worth leaving it listening on >external interfaces in a _default_ install? > third party applications of our beloved customers... There are *probably* a few more applications other than NFS and NIS that need to advertise ports.... Remember the RPC subsystem has been around for a very long time which means we really don't what we would be breaking by turning it off... Just because you don't know about something..... does not mean they don't exist.... >>The >>point being turning off portmapper could (and probably will) cause >>unexpect process >>to fail in unexpect ways making very difficult to debug especially >>during installation... >> >> > >As a matter of course, I disable portmap and rpc.statd on any machine not >expected to perform NFS or NIS and have not noticed any side effects as a >result. > So we can assume that your system is an *exact* clone of every other linux system out there... so what works in your world will work everywhere.... I'm sorry but I just don't by your logic... > > > >>Portmapper has been around quite a long time making it pretty bullet >>proof... >> >> > >Funny, 'cos in my universe, the portmapper is regarded as one of the most >vulnerable pieces of UNIX software, along with rpc.statd, sendmail and BIND. > Educate me... How has it *recently* (i.e within the that 3 years) been exploited? And what damage was caused? >>So I see no reason what so ever to turn off portmapper. Lets not make a >>system more difficult to deal with for simply no reason... >> >> > >...but there is a reason - making new installs secure by default. For a >admin who's already configuring NFS or similar, the extra step of >chkconfig'ing portmap and rpc.statd isn't much of a burden. > Again.... NFS and NIS are not the only user of portmapper... We have to keep in mind the entire industry... not just or own little worlds.... SteveD. From SteveD at redhat.com Mon Aug 25 18:20:01 2003 From: SteveD at redhat.com (Steve Dickson) Date: Mon, 25 Aug 2003 14:20:01 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <20030825113022.A29673@devserv.devel.redhat.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825113022.A29673@devserv.devel.redhat.com> Message-ID: <3F4A5351.3000600@RedHat.com> Bill Nottingham wrote: >rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) said: > > >>Which local processes? We've already heard about sgi_fam, and we already >>know about NIS and NFS, but is this really worth leaving it listening on >>external interfaces in a _default_ install? >> >> > >Set up a firewall, as is the default in the install... > > Yes.... firewalls the answer..... SteveD. From chuckw at quantumlinux.com Mon Aug 25 18:23:03 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 25 Aug 2003 11:23:03 -0700 (PDT) Subject: RH Taroon Beta Open Ports In-Reply-To: <20030825145953.GA14676@dudweiler.stuttgart.redhat.com> Message-ID: > > So I see no reason what so ever to turn off portmapper. Lets not make > > a system more difficult to deal with for simply no reason... > > I agree. It makes "client usage" much easier and servers should anyway > get protection via firewalls and special security changes. And Microsoft issued fixes for the exploited holes a long time ago. You'd be amazed at how many of my customers don't realize the need for a firewall. Some of them became my customers because they did an "everything" install and put the box right on the net. I agree, that's just an absurd thing to do. The fact remains, they do do it. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From SteveD at redhat.com Mon Aug 25 18:28:17 2003 From: SteveD at redhat.com (Steve Dickson) Date: Mon, 25 Aug 2003 14:28:17 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825113022.A29673@devserv.devel.redhat.com> Message-ID: <3F4A5541.9070007@RedHat.com> rhldevel at assursys.co.uk wrote: >On Mon, 25 Aug 2003, Bill Nottingham wrote: > >But to a lot of na?ve users, firewalls are deeply technical things, that >they worry will interfere with normal usage. As a result, I believe a number >of such users will install with the firewall disabled, or stop it when >attempting to get things working - perhaps never to (re-)enable it. Having >things like X11, portmapper and rpc.statd listening on an external interface >is asking for trouble, IMHO. > For network security firewalls are the answer... not disabling network applications... All we can do is give them the tools... but we can not shooting themselves in the foot... SteveD. From wcooley at nakedape.cc Mon Aug 25 18:28:14 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Mon, 25 Aug 2003 11:28:14 -0700 Subject: RH Taroon Beta Open Ports In-Reply-To: <20030825134454.A8928@devserv.devel.redhat.com> References: <20030825134454.A8928@devserv.devel.redhat.com> Message-ID: <1061836094.803.49.camel@denk.nakedape.priv> On Mon, 2003-08-25 at 10:44, Bill Nottingham wrote: > Counterargument: If the default firewall that already protects you > is changed, it is because there is a knowledgeable person that changed > it, right? > > You can't have it both ways. Except that's not following the KISS principle; turning the services off is. Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Naked Ape Consulting http://nakedape.cc * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wcooley at nakedape.cc Mon Aug 25 18:33:44 2003 From: wcooley at nakedape.cc (Wil Cooley) Date: Mon, 25 Aug 2003 11:33:44 -0700 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A5541.9070007@RedHat.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825113022.A29673@devserv.devel.redhat.com> <3F4A5541.9070007@RedHat.com> Message-ID: <1061836423.803.51.camel@denk.nakedape.priv> On Mon, 2003-08-25 at 11:28, Steve Dickson wrote: > For network security firewalls are the answer... not disabling network > applications... > All we can do is give them the tools... but we can not shooting > themselves in the foot... How is leaving something turned off shooting them in the foot? Wil -- Wil Cooley wcooley at nakedape.cc Naked Ape Consulting http://nakedape.cc * * * * Linux, UNIX, Networking and Security Solutions * * * * * Naked Ape Consulting http://nakedape.cc * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dhollis at davehollis.com Mon Aug 25 18:38:59 2003 From: dhollis at davehollis.com (David T Hollis) Date: Mon, 25 Aug 2003 14:38:59 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A52FB.1030103@RedHat.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <3F4A52FB.1030103@RedHat.com> Message-ID: <3F4A57C3.7090409@davehollis.com> Steve Dickson wrote: > rhldevel at assursys.co.uk wrote: > >>> statd (i.e. nfslock) probably does not need to be running if NFS is >>> not configured but >>> tunning off portmapper is a bit extreme... Not only do local process >>> expect portmapper >>> to be there, >>> >> >> >> Which local processes? We've already heard about sgi_fam, and we already >> know about NIS and NFS, but is this really worth leaving it listening on >> external interfaces in a _default_ install? >> > third party applications of our beloved customers... There are > *probably* a few more > applications other than NFS and NIS that need to advertise ports.... > Remember the > RPC subsystem has been around for a very long time which means we > really don't > what we would be breaking by turning it off... Just because you don't > know about > something..... does not mean they don't exist.... Your missing the point here. No one is saying don't ship portmap or nfs utilities. Just raising the question as to whether they should be enabled by default. > >>> The >>> point being turning off portmapper could (and probably will) cause >>> unexpect process >>> to fail in unexpect ways making very difficult to debug especially >>> during installation... >>> >> >> >> As a matter of course, I disable portmap and rpc.statd on any machine >> not >> expected to perform NFS or NIS and have not noticed any side effects >> as a >> result. >> > So we can assume that your system is an *exact* clone of every other > linux system > out there... so what works in your world will work everywhere.... I'm > sorry but > I just don't by your logic... I also disable them on my systems since I don't typically utilize NFS (nor NIS, or any other RPC based service) and I have not had any problems either. Using the recent MS DCOM problems, MS' technical information for the problem suggested a workaround of disabling DCOM with the following nebulous disclaimer: *Warning* If you disable DCOM, may you may lose operating system functionality. After you disable support for DCOM, the following may result: * Any COM objects that can be activated remotely may not function correctly. * The local COM+ snap-in will not be able to connect to remote servers to enumerate their COM+ catalog. * Certificate auto-enrollment may not function correctly. * Windows Management Instrumentation (WMI) queries against remote servers may not function correctly. (http://support.microsoft.com/default.aspx?scid=kb;en-us;825750) It translates to most folks as "If I disable DCOM, no one knows what is going to break". With a stock RH install, how many RPC using services are available? NFS, NIS, sgi_fam, and?? Unlike MS, you know what will not function if portmap is not running. 3rd party apps are certainly a different ballgame, but that is the 3rd parties responsibility to mention the requirement of portmap. > >> >> >> >>> Portmapper has been around quite a long time making it pretty bullet >>> proof... >>> >> >> >> Funny, 'cos in my universe, the portmapper is regarded as one of the >> most >> vulnerable pieces of UNIX software, along with rpc.statd, sendmail >> and BIND. >> > Educate me... How has it *recently* (i.e within the that 3 years) > been exploited? > And what damage was caused? > >>> So I see no reason what so ever to turn off portmapper. Lets not make a >>> system more difficult to deal with for simply no reason... >>> >> >> >> ...but there is a reason - making new installs secure by default. For a >> admin who's already configuring NFS or similar, the extra step of >> chkconfig'ing portmap and rpc.statd isn't much of a burden. >> > Again.... NFS and NIS are not the only user of portmapper... We have > to keep > in mind the entire industry... not just or own little worlds.... > > > SteveD. > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list From SteveD at redhat.com Mon Aug 25 18:39:32 2003 From: SteveD at redhat.com (Steve Dickson) Date: Mon, 25 Aug 2003 14:39:32 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: References: Message-ID: <3F4A57E4.8010701@RedHat.com> Chuck Wolber wrote: >You'd be amazed at how many of my customers don't realize the need for a >firewall. Some of them became my customers because they did an >"everything" install and put the box right on the net. I agree, that's >just an absurd thing to do. The fact remains, they do do it. > So are support to try to build a systems that are idiot proof? I would say not... If someone neglect to lock their front door and is robbed, is that the builders fault because he didn't install automatic locking doors? Firewalls is the best way to deal with network security.... and there no system configuration that we can do to change that fact... SteveD. From dhollis at davehollis.com Mon Aug 25 18:41:09 2003 From: dhollis at davehollis.com (David T Hollis) Date: Mon, 25 Aug 2003 14:41:09 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A5541.9070007@RedHat.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825113022.A29673@devserv.devel.redhat.com> <3F4A5541.9070007@RedHat.com> Message-ID: <3F4A5845.8090905@davehollis.com> Steve Dickson wrote: > rhldevel at assursys.co.uk wrote: > >> On Mon, 25 Aug 2003, Bill Nottingham wrote: >> >> But to a lot of na?ve users, firewalls are deeply technical things, that >> they worry will interfere with normal usage. As a result, I believe a >> number >> of such users will install with the firewall disabled, or stop it when >> attempting to get things working - perhaps never to (re-)enable it. >> Having >> things like X11, portmapper and rpc.statd listening on an external >> interface >> is asking for trouble, IMHO. >> > For network security firewalls are the answer... not disabling network > applications... > All we can do is give them the tools... but we can not shooting > themselves in the foot... > > SteveD. > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list Wrong. Security in-depth is the answer. Good - IP ports are firewalled Better - application is not running Best - application is not even installed From chuckw at quantumlinux.com Mon Aug 25 19:03:04 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Mon, 25 Aug 2003 12:03:04 -0700 (PDT) Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A57E4.8010701@RedHat.com> Message-ID: > >You'd be amazed at how many of my customers don't realize the need for a > >firewall. Some of them became my customers because they did an > >"everything" install and put the box right on the net. I agree, that's > >just an absurd thing to do. The fact remains, they do do it. > > So are support to try to build a systems that are idiot proof? I would > say not... If someone neglect to lock their front door and is robbed, is > that the builders fault because he didn't install automatic locking > doors? No, it's absurd to say that we should build something idiot proof. My point is that even when the fixes are in, people just don't apply them. > Firewalls is the best way to deal with network security.... and there no > system configuration that we can do to change that fact... I think we're in violent agreement here... -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From SteveD at redhat.com Mon Aug 25 19:11:37 2003 From: SteveD at redhat.com (Steve Dickson) Date: Mon, 25 Aug 2003 15:11:37 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A57C3.7090409@davehollis.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <3F4A52FB.1030103@RedHat.com> <3F4A57C3.7090409@davehollis.com> Message-ID: <3F4A5F69.7070907@RedHat.com> David T Hollis wrote: >> third party applications of our beloved customers... There are >> *probably* a few more >> applications other than NFS and NIS that need to advertise ports.... >> Remember the >> RPC subsystem has been around for a very long time which means we >> really don't >> what we would be breaking by turning it off... Just because you don't >> know about >> something..... does not mean they don't exist.... > > > Your missing the point here. No one is saying don't ship portmap or > nfs utilities. Just raising the question as to whether they should be > enabled by default. I'm not sure how you interpreted that I want to stop ship nfs or portmapper..... but let me assure that is *NOT* the case... I just don't want to turn of a long standing subsystem that third parties my or may not depend for simply no good reason.... Steved From yeti at physics.muni.cz Mon Aug 25 19:27:14 2003 From: yeti at physics.muni.cz (David Necas (Yeti)) Date: Mon, 25 Aug 2003 21:27:14 +0200 Subject: RH Taroon Beta Open Ports In-Reply-To: References: <3F4A57E4.8010701@RedHat.com> Message-ID: <20030825192714.GG13767@potato.brno.mistral.cz> On Mon, Aug 25, 2003 at 12:03:04PM -0700, Chuck Wolber wrote: > > > Firewalls is the best way to deal with network security.... and there no > > system configuration that we can do to change that fact... > > I think we're in violent agreement here... However, this is the basic nonsense upon which the others are built on. The best way to deal with network security is not relying on a single thing; but using firewalls, configuration, IDS, policies, ... literarly anything you can, to support it. Too many people thinking `I'm safe, I have a firewall' have been 0wned... Firewall is no excuse for running redundant services. Thus the question is not about what firewalls are good for, but how much or how often is portmap (and others) redundant. Regards, Yeti -- Do not use tab characters. Their effect is not predictable. From felipe_alfaro at linuxmail.org Mon Aug 25 19:36:11 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 25 Aug 2003 21:36:11 +0200 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A52FB.1030103@RedHat.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <3F4A52FB.1030103@RedHat.com> Message-ID: <1061840170.704.5.camel@teapot.felipe-alfaro.com> On Mon, 2003-08-25 at 20:18, Steve Dickson wrote: > >Which local processes? We've already heard about sgi_fam, and we already > >know about NIS and NFS, but is this really worth leaving it listening on > >external interfaces in a _default_ install? > > > third party applications of our beloved customers... There are > *probably* a few more > applications other than NFS and NIS that need to advertise ports.... > Remember the > RPC subsystem has been around for a very long time which means we really > don't > what we would be breaking by turning it off... Just because you don't > know about > something..... does not mean they don't exist.... In my humble opinion, sometimes we must take decisions that make difficult mantaining compatibility. However, if these decisions are targeted to achieve improved security, I think we have a reason in our favor. NFS is not very secure by nature (except NFSv4). If we want to mantain compatiblity with third-party products, I suggest that during upgrades, the portmap and company be left at their original settings. However, for new installations, I think we should disable them, or at least, force them to bind to the loopback interface exclusively. Then, I would put a *big* note into the Release Notes stating behavior changes in those services. Red Hat (or anyone) can't be liable for a behavior change that is well documented in the Release Notes and aims at security: if an administrator performs a fresh install of Red Hat Linux, then installs third-party products and checks that some things don't work, then, if he/she hasn't read the Release Notes, he/she should be sent to the IT hell ;-) Just my two cents of Euro. From felipe_alfaro at linuxmail.org Mon Aug 25 19:40:24 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 25 Aug 2003 21:40:24 +0200 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A57E4.8010701@RedHat.com> References: <3F4A57E4.8010701@RedHat.com> Message-ID: <1061840424.704.9.camel@teapot.felipe-alfaro.com> On Mon, 2003-08-25 at 20:39, Steve Dickson wrote: > So are support to try to build a systems that are idiot proof? I would > say not... If someone neglect to lock their front door and is robbed, > is that the builders fault because he didn't install automatic locking > doors? Of course no, but we need to build idiot-proof doors. In security I think that "you'd better disable it if you don't know for sure if you're going to use it" is the way to go. We all should run firewalls, we all should run antivirus, we all shouldn't open attachments from unknown parties... and so on, but *we* doesn't mean the whole world. Thus, we must build idiot-proof systems, with high security enabled by default, if we don't want to become News Headlines (i.e. Another Worm Exploits a Vulnerability in Red Hat Linux Portmap Daemon). Just my 0,0172 Euros. From dee at renaissoft.com Mon Aug 25 19:42:07 2003 From: dee at renaissoft.com (Dee-Ann LeBlanc) Date: 25 Aug 2003 12:42:07 -0700 Subject: Athlon 64 support? In-Reply-To: <20030825160100.21677.98101.Mailman@listman.back-rdu.redhat.com> References: <20030825160100.21677.98101.Mailman@listman.back-rdu.redhat.com> Message-ID: <1061840526.29854.128.camel@localhost.localdomain> Sean Middleditch wrote: > Supporting Athlon 64 in the Enterprise line only would be daft, as > Athlon 64 is a consumer chip. Perhaps you meant Opteron, the > server/workstation AMD64 CPU? But speaking of Athlon 64, will a > consumer RHL project release be made for it? Actually, someone didn't do enough reading before she posted that. I am indeed asking about support for the Athlon 64, which indeed Red Hat has not made a public statement on at all as far as I can tell. So now my question is whether Athlon 64 support is going to be bundled in with the main RHLP or a separate one. :) -- Dee-Ann LeBlanc, RHCE Lots of things Linux http://www.Dee-AnnLeBlanc.com/ From felipe_alfaro at linuxmail.org Mon Aug 25 19:42:19 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 25 Aug 2003 21:42:19 +0200 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A5845.8090905@davehollis.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825113022.A29673@devserv.devel.redhat.com> <3F4A5541.9070007@RedHat.com> <3F4A5845.8090905@davehollis.com> Message-ID: <1061840539.704.12.camel@teapot.felipe-alfaro.com> On Mon, 2003-08-25 at 20:41, David T Hollis wrote: > Wrong. Security in-depth is the answer. > > Good - IP ports are firewalled > Better - application is not running > Best - application is not even installed I agree 500% ... If we can: 1. We shouldn't even install portmap or nfs-utils 2. If we can't do 1, then disable portmap and nfs* 3. If we can't achieve neither 1 nor 2, make them bind to localhost 4. Else, enable firewall by default and get picky if the user tries to disable it. From hp at redhat.com Mon Aug 25 19:56:24 2003 From: hp at redhat.com (Havoc Pennington) Date: Mon, 25 Aug 2003 15:56:24 -0400 Subject: gconfd logs In-Reply-To: <1061818243.10124.6.camel@hagrid.phy.duke.edu> References: <1061818243.10124.6.camel@hagrid.phy.duke.edu> Message-ID: <20030825155624.D29588@devserv.devel.redhat.com> Hi, Really the place for this discussion is gconf-list at gnome.org; there's nothing Red Hat specific about it. The translators would generally say that all strings should be translatable. Though I think gconf has a bunch of strings that don't even make sense in English. Perhaps the issue is that the encoding of the syslog needs to be defined and gconfd needs to output in that encoding. It's also pretty possible the log messages should simply not exist. Havoc From feliciano.matias at free.fr Mon Aug 25 20:19:36 2003 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: 25 Aug 2003 22:19:36 +0200 Subject: Athlon 64 support? In-Reply-To: <1061840526.29854.128.camel@localhost.localdomain> References: <20030825160100.21677.98101.Mailman@listman.back-rdu.redhat.com> <1061840526.29854.128.camel@localhost.localdomain> Message-ID: <1061842775.3109.121.camel@one.myworld> Le lun 25/08/2003 ? 21:42, Dee-Ann LeBlanc a ?crit : > Sean Middleditch wrote: > > > Supporting Athlon 64 in the Enterprise line only would be daft, as > > Athlon 64 is a consumer chip. Perhaps you meant Opteron, the > > server/workstation AMD64 CPU? But speaking of Athlon 64, will a > > consumer RHL project release be made for it? > > Actually, someone didn't do enough reading before she posted that. I am > indeed asking about support for the Athlon 64, which indeed Red Hat has > not made a public statement on at all as far as I can tell. So now my > question is whether Athlon 64 support is going to be bundled in with the > main RHLP or a separate one. :) Here is a thread about Opteron and RHLP : http://www.redhat.com/archives/rhl-beta-list/2003-July/msg00051.html -- F?liciano Matias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From hbo at egbok.com Mon Aug 25 20:41:20 2003 From: hbo at egbok.com (Howard Owen) Date: 25 Aug 2003 13:41:20 -0700 Subject: RH Taroon Beta Open Ports In-Reply-To: <20030825120916.A26653@devserv.devel.redhat.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825113022.A29673@devserv.devel.redhat.com> <1061827487.1328.10.camel@owen.egbok.com> <20030825120916.A26653@devserv.devel.redhat.com> Message-ID: <1061844080.2123.52.camel@sivakuma-lnx.cisco.com> I actually was thinking the init script could do it, though that too would be contrary to standard practice. On Mon, 2003-08-25 at 09:09, Bill Nottingham wrote: > Howard Owen (hbo at egbok.com) said: > > Why not configure portmapper to listen on localhost, then have the > > services (mountd, ypserv, etc.) that need it enable listening on the > > wire when they start? You'd need a cooperative arrangement whereby the > > init scripts would shut down external portmapper if they were the last > > service that needed it on service shutdown. > > Having 'mount' try and configure services would be exceedingly messy. > > Bill > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From hbo at egbok.com Mon Aug 25 21:15:22 2003 From: hbo at egbok.com (Howard Owen) Date: 25 Aug 2003 14:15:22 -0700 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A5845.8090905@davehollis.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825113022.A29673@devserv.devel.redhat.com> <3F4A5541.9070007@RedHat.com> <3F4A5845.8090905@davehollis.com> Message-ID: <1061846121.2123.65.camel@sivakuma-lnx.cisco.com> Hear, hear! The "soft chewy inside" is dead. Long live defense-in-depth! On Mon, 2003-08-25 at 11:41, David T Hollis wrote: > Steve Dickson wrote: > > > rhldevel at assursys.co.uk wrote: > > > >> On Mon, 25 Aug 2003, Bill Nottingham wrote: > >> > >> But to a lot of na?ve users, firewalls are deeply technical things, that > >> they worry will interfere with normal usage. As a result, I believe a > >> number > >> of such users will install with the firewall disabled, or stop it when > >> attempting to get things working - perhaps never to (re-)enable it. > >> Having > >> things like X11, portmapper and rpc.statd listening on an external > >> interface > >> is asking for trouble, IMHO. > >> > > For network security firewalls are the answer... not disabling network > > applications... > > All we can do is give them the tools... but we can not shooting > > themselves in the foot... > > > > SteveD. > > > > > > -- > > Rhl-devel-list mailing list > > Rhl-devel-list at redhat.com > > http://www.redhat.com/mailman/listinfo/rhl-devel-list > > Wrong. Security in-depth is the answer. > > Good - IP ports are firewalled > Better - application is not running > Best - application is not even installed > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From hbo at egbok.com Mon Aug 25 21:35:03 2003 From: hbo at egbok.com (Howard Owen) Date: 25 Aug 2003 14:35:03 -0700 Subject: RH Taroon Beta Open Ports In-Reply-To: <1061840170.704.5.camel@teapot.felipe-alfaro.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <3F4A52FB.1030103@RedHat.com> <1061840170.704.5.camel@teapot.felipe-alfaro.com> Message-ID: <1061847303.2117.84.camel@sivakuma-lnx.cisco.com> I agree with this. While it wouldn't help with third party apps, the init scripts for nfs and ypserv could (briefly) explain the changed behavior wrt the portmapper. In this way the admin could be pointed to documentation that would explain how to turn on the service, together with why you really shouldn't. 8) As Linux gets more and more market penetration, particularly on the desktop, we will start to suffer from many of the syndromes that Microsoft is so poor at coping with. I'm confident we will do better when dealing with increased visibility and less clueful users and admins. That's because of an inherently better platform, and because people will have thought longer, better and with more experience backing them about the challenges widespread success will raise. On Mon, 2003-08-25 at 12:36, Felipe Alfaro Solana wrote: > On Mon, 2003-08-25 at 20:18, Steve Dickson wrote: > > > >Which local processes? We've already heard about sgi_fam, and we already > > >know about NIS and NFS, but is this really worth leaving it listening on > > >external interfaces in a _default_ install? > > > > > third party applications of our beloved customers... There are > > *probably* a few more > > applications other than NFS and NIS that need to advertise ports.... > > Remember the > > RPC subsystem has been around for a very long time which means we really > > don't > > what we would be breaking by turning it off... Just because you don't > > know about > > something..... does not mean they don't exist.... > > In my humble opinion, sometimes we must take decisions that make > difficult mantaining compatibility. However, if these decisions are > targeted to achieve improved security, I think we have a reason in our > favor. NFS is not very secure by nature (except NFSv4). > > If we want to mantain compatiblity with third-party products, I suggest > that during upgrades, the portmap and company be left at their original > settings. However, for new installations, I think we should disable > them, or at least, force them to bind to the loopback interface > exclusively. Then, I would put a *big* note into the Release Notes > stating behavior changes in those services. > > Red Hat (or anyone) can't be liable for a behavior change that is well > documented in the Release Notes and aims at security: if an > administrator performs a fresh install of Red Hat Linux, then installs > third-party products and checks that some things don't work, then, if > he/she hasn't read the Release Notes, he/she should be sent to the IT > hell ;-) > > Just my two cents of Euro. > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From notting at redhat.com Mon Aug 25 21:50:22 2003 From: notting at redhat.com (Bill Nottingham) Date: Mon, 25 Aug 2003 17:50:22 -0400 Subject: Services & firewall configuration In-Reply-To: <3F4A5011.9010109@comcast.net>; from i.pilcher@comcast.net on Mon, Aug 25, 2003 at 01:06:09PM -0500 References: <3F4A5011.9010109@comcast.net> Message-ID: <20030825175022.A19274@devserv.devel.redhat.com> Ian Pilcher (i.pilcher at comcast.net) said: > Reading the discussion about Taroon, portmapper, ports, etc., reminded > me of one of the shortcomings of Red Hat Linux (and all other > distributions AFAIK). > > It seems to me that the fundamental problem is the lack of "linkage" > (for lack of a better word) between service configuration and firewall > configuration. In an ideal world, the network access required by a > service would be easy to determine -- perhaps with chkconfig-like meta- > data in the init script. The firewall configuration program could then > be enhanced to prompt accordingly. > > Even better, to my mind, would be to actually combine the services and > firewall configuration programs. Instead of a single checkbox for each > service, each service would have a checkbox for each interface. The > network configuration program should probably prompt the user to run the > firewall configuration when an interface is added. > > Just some thoughts on future directions. Flame away! As it currently stands, things like portmap don't need to tweak the firewall config; they will work just fine with the firewall (allow connections initated from the host.) Where you run into issues are if you *specifically* want to expose a service, such as ssh, FTP, or HTTP. Bill From lowen at pari.edu Tue Aug 26 01:34:02 2003 From: lowen at pari.edu (Lamar Owen) Date: Mon, 25 Aug 2003 21:34:02 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A57E4.8010701@RedHat.com> References: <3F4A57E4.8010701@RedHat.com> Message-ID: <200308252134.02495.lowen@pari.edu> On Monday 25 August 2003 14:39, Steve Dickson wrote: > Firewalls is the best way to deal with network security.... and there > no system configuration that we can do to change that fact... Security is not so one-dimensional to fall to a one-dimensional solution. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute From ghenriks at rogers.com Tue Aug 26 02:21:07 2003 From: ghenriks at rogers.com (Gerald Henriksen) Date: Mon, 25 Aug 2003 22:21:07 -0400 Subject: Athlon 64 support? In-Reply-To: <1061840526.29854.128.camel@localhost.localdomain> References: <20030825160100.21677.98101.Mailman@listman.back-rdu.redhat.com> <1061840526.29854.128.camel@localhost.localdomain> Message-ID: <8mglkvgu26jkr5bl79li0cd7956b8er047@4ax.com> On 25 Aug 2003 12:42:07 -0700, you wrote: >Actually, someone didn't do enough reading before she posted that. I am >indeed asking about support for the Athlon 64, which indeed Red Hat has >not made a public statement on at all as far as I can tell. So now my >question is whether Athlon 64 support is going to be bundled in with the >main RHLP or a separate one. :) As far as the CPU instruction set is concerned Athlon64 and Opteron are identical as they are both AMD64 processors. So the OS won't care whether you have an Opteron or Athlon64. At some point in the future there likely will be an AMD64 version of RHLP, as the community will likely build it if necessary. However this won't happen in time for the release of Red Hat 10 given that Athlon64 is not yet available, and reportedly won't be available in volume for many months yet. However the normal version of Red Hat 9/10/etc. will work fine on an Athlon64 machine albeit without support for the new features of the AMD64 architecture (no 64bit stuff, no additional registers, etc). From smoogen at lanl.gov Tue Aug 26 03:06:09 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Mon, 25 Aug 2003 21:06:09 -0600 (MDT) Subject: Open Ports for Linux (was a very different topic) In-Reply-To: <200308252134.02495.lowen@pari.edu> Message-ID: I would say that people who are interested in this problem should look at offering patches. Looking over the list in /etc/rc.d/rc.sysinit the proper runtime level people who want complete lockdown is RunLevel 2 or configuring 4 to be that. Depending on a firewall as the only protection is not a solution. There are too many people who probably will turn off RH firewalls because the one in 8 and 9 broke too many NFS etc environments. Also a complete audit of portmap should be in order because it has had a long history of problems. [That may be a bit hard as it seems to have been written by Wietse Venema, but the readme hasnt been touched since 1996 so bit rot may have occured.] XFree86 should have stronger protection than just the firewall. Having it only listen locally with the best practices of using SSH to forward connections would seem to be best. On Mon, 25 Aug 2003, Lamar Owen wrote: >On Monday 25 August 2003 14:39, Steve Dickson wrote: >> Firewalls is the best way to deal with network security.... and there >> no system configuration that we can do to change that fact... > >Security is not so one-dimensional to fall to a one-dimensional solution. > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 5-8058 Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From paul at dishone.st Tue Aug 26 03:16:16 2003 From: paul at dishone.st (Paul Jakma) Date: Tue, 26 Aug 2003 04:16:16 +0100 (IST) Subject: Services & firewall configuration In-Reply-To: <3F4A5011.9010109@comcast.net> Message-ID: On Mon, 25 Aug 2003, Ian Pilcher wrote: > It seems to me that the fundamental problem is the lack of "linkage" > (for lack of a better word) between service configuration and > firewall configuration. well, there's so much policy involved. Eg you could perhaps add special comment lines to init scripts (ala the chkconfig lines) to indicate ports which are used by an app - but how do you tell whether the user wants them accessible to the network? and if so, the whole internet? his local network? ??? > Just some thoughts on future directions. Flame away! got any ideas? :) one thing i would like is a portmap with hooks on rpc client registration/deregister (ie to setup firewalls). regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: It is difficult to legislate morality in the absence of moral legislators. From paul at dishone.st Tue Aug 26 03:24:35 2003 From: paul at dishone.st (Paul Jakma) Date: Tue, 26 Aug 2003 04:24:35 +0100 (IST) Subject: RH Taroon Beta Open Ports In-Reply-To: <1061840170.704.5.camel@teapot.felipe-alfaro.com> Message-ID: On Mon, 25 Aug 2003, Felipe Alfaro Solana wrote: > favor. NFS is not very secure by nature (except NFSv4). hmm... just to but in, but the above is a common myth: - whatever security problems NFS has, they are /not/ the fault of the NFS - connection authorisation/transport security are /not/ within the remit of NFS, it is the /RPC/ layer which is responsible. - NFSv4 is /not/ more secure than NFSv3. However, NFSv4 makes secure RPC mechanisms mandatory. NB: NFSv3 will (should) be able to avail of this too. anyway, blame RPC and the lack of secure RPC mechs in glibc/linux - not NFS, if authunix is the only mech available, then authunix is all NFS can make use of. regards, -- Paul Jakma paul at clubi.ie paul at jakma.org Key ID: 64A2FF6A warning: do not ever send email to spam at dishone.st Fortune: There's no easy quick way out, we're gonna have to live through our whole lives, win, lose, or draw. -- Walt Kelly From pmatilai at welho.com Tue Aug 26 05:47:53 2003 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 26 Aug 2003 08:47:53 +0300 Subject: RH Taroon Beta Open Ports In-Reply-To: <20030825134454.A8928@devserv.devel.redhat.com> References: <20030825134454.A8928@devserv.devel.redhat.com> Message-ID: <1061876873.3f4af489aebfc@webmail.welho.com> Quoting Bill Nottingham : > Jim Wildman (jim at rossberry.com) said: > > I agree with Alex. If nfs is being used, it is because there is a > > knowledgeable person around to set it up. (Is there a client included > > by default with MS systems?). Better to have it off and close one > > more potential hole. > > Counterargument: If the default firewall that already protects you > is changed, it is because there is a knowledgeable person that changed > it, right? > > You can't have it both ways. The difference is that enabling/disabling firewall is a single click of mouse in the installer in all of the installation modes and IIRC anaconda doesn't nag about dangers of disabling the fw in any way (apart from help text perhaps) -> you don't need much knowledge to disable that, but you do need a little bit of knowledge to turn on services post install. I'd have to agree with Alex & others: most home users are not going to use/need NFS and where NFS servers exist, there exists knowledgeable persons to set the clients up. My +1 for disabling NFS client services by default. -- - Panu - From felipe_alfaro at linuxmail.org Tue Aug 26 08:37:56 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Tue, 26 Aug 2003 10:37:56 +0200 Subject: RH Taroon Beta Open Ports In-Reply-To: <1061876873.3f4af489aebfc@webmail.welho.com> References: <20030825134454.A8928@devserv.devel.redhat.com> <1061876873.3f4af489aebfc@webmail.welho.com> Message-ID: <1061887076.678.22.camel@teapot.felipe-alfaro.com> On Tue, 2003-08-26 at 07:47, Panu Matilainen wrote: > The difference is that enabling/disabling firewall is a single click of mouse in > the installer in all of the installation modes and IIRC anaconda doesn't nag > about dangers of disabling the fw in any way (apart from help text perhaps) -> > you don't need much knowledge to disable that, but you do need a little bit of > knowledge to turn on services post install. > > I'd have to agree with Alex & others: most home users are not going to use/need > NFS and where NFS servers exist, there exists knowledgeable persons to set the > clients up. My +1 for disabling NFS client services by default. I would say that, additionally, running a firewall shouldn't be the only line of defense. Imagine that, by any reason, a non-root user downloads a compromised binary that tries to use an unknown exploit on portmap, for example. By not running portmap, we eliminate one additional piece of trouble. From Dax at GuruLabs.com Tue Aug 26 08:14:45 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Tue, 26 Aug 2003 02:14:45 -0600 Subject: Open Ports for Linux (was a very different topic) In-Reply-To: References: Message-ID: <1061885685.3600.37.camel@mentor.gurulabs.com> On Mon, 2003-08-25 at 21:06, Stephen Smoogen wrote: > Depending on a firewall as the only protection is not a solution. There > are too many people who probably will turn off RH firewalls because the > one in 8 and 9 broke too many NFS etc environments. I got fed up with breakage and submitted a patch that was accepted. The *new* RH firewall that will be in 10 and RHAS3 no longer breaks RPC apps. Tell Bryan Croft hi for me when you see him tomorrow. Dax Kelson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Dax at GuruLabs.com Tue Aug 26 07:52:38 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Tue, 26 Aug 2003 01:52:38 -0600 Subject: RH Taroon Beta Open Ports In-Reply-To: References: Message-ID: <1061884358.3600.26.camel@mentor.gurulabs.com> On Mon, 2003-08-25 at 05:50, rhldevel at assursys.co.uk wrote: > Hi - > > I've just done a "complete" install of Taroon on a scratch box, with > iptables firewalling disabled Realize at this point you are NO longer talking about securing a "stock" install. You are now running a "custom" install, the responsibility now rests on your shoulders. If you remove the installed-by-default air filter from your automobile, that is your prerogative. Deal with the consequences. The stock RH install is secure by default. The firewall created at installation time prohibits ALL inbound connection requests except for ICMP echo requests (ping). The firewall created at install time allows ALL outbound connection requests initiated by the host to work with no problems (this was not the case in previous RHL versions). There is an extremely simple UI for the user to manually ENABLE selected inbound connection requests while leaving the rest of the firewall intact. I strongly disagree with claim that very few small and medium business Linux environments use NFS and instead use Samba. Leave my daemons required for client-side NFS running by default please. I'm all for security in-depth, however, a tunnel vision approach to this results in the end game of setting your default runlevel to 0. Dax Kelson Guru Labs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Dax at GuruLabs.com Tue Aug 26 07:33:04 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Tue, 26 Aug 2003 01:33:04 -0600 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A41F5.1070802@davehollis.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <20030825145953.GA14676@dudweiler.stuttgart.redhat.com> <3F4A41F5.1070802@davehollis.com> Message-ID: <1061883183.3600.11.camel@mentor.gurulabs.com> On Mon, 2003-08-25 at 11:05, David T Hollis wrote: > that wants to use NFS to do a couple of chkconfig statements is not > much, especially when it reduces the network footprint of the stock install. Incorrect. A "stock" install has the firewall "enabled" (the high/medium stuff is gone) and no remote hosts can initiate RPC/NFS connections to a "stock" installed machine. A "stock" machine can act a NFS client with no problem however. Dax Kelson Guru Labs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Dax at GuruLabs.com Tue Aug 26 08:05:13 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Tue, 26 Aug 2003 02:05:13 -0600 Subject: RH Taroon Beta Open Ports In-Reply-To: References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> Message-ID: <1061885113.3600.31.camel@mentor.gurulabs.com> On Mon, 2003-08-25 at 09:27, rhldevel at assursys.co.uk wrote: > Which local processes? We've already heard about sgi_fam, and we already > know about NIS and NFS, but is this really worth leaving it listening on > external interfaces in a _default_ install? Incorrect. You are forgetting what you yourself stated in the message that started this whole thread. You said, "I've just done a "complete" install of Taroon on a scratch box, with iptables firewalling disabled." We/you are NOT talking about a _default_ install. The whole premise for this entire discussion is flawed. Dax Kelson -------------- 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 rhldevel at assursys.co.uk Tue Aug 26 10:15:37 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Tue, 26 Aug 2003 11:15:37 +0100 (BST) Subject: RH Taroon Beta Open Ports In-Reply-To: <1061885113.3600.31.camel@mentor.gurulabs.com> References: <1061813601.710.12.camel@teapot.felipe-alfaro.com> <3F4A23E2.3020907@RedHat.com> <1061885113.3600.31.camel@mentor.gurulabs.com> Message-ID: On Tue, 26 Aug 2003, Dax Kelson wrote: > On Mon, 2003-08-25 at 09:27, rhldevel at assursys.co.uk wrote: > > Which local processes? We've already heard about sgi_fam, and we already > > know about NIS and NFS, but is this really worth leaving it listening on > > external interfaces in a _default_ install? > > Incorrect. > > You are forgetting what you yourself stated in the message that started > this whole thread. > > You said, "I've just done a "complete" install of Taroon on a scratch > box, with iptables firewalling disabled." > > We/you are NOT talking about a _default_ install. > > The whole premise for this entire discussion is flawed. Read one of my later posts where I explain that I believe that a number of inexperienced users will disable the firewall either fearing it will cause unknown breakage, or leave it as "something to configure once I've got the machine working". Regardless, through experience, I'm a firm believer in defense-in-depth, and nothing will change that belief. I think I've said all I can on the topic now. Red Hat can choose to do whatever they wish, and I'll continue to disable unnecessary services regardless of whether they're firewalled. But if they continue to ship OSs with unnecessary services running, they may end up regretting this discussion... (not a threat, just a prediction - my hat is white!) > Dax Kelson Best Regards, Alex. From pauln at truemesh.com Tue Aug 26 11:55:42 2003 From: pauln at truemesh.com (Paul Nasrat) Date: Tue, 26 Aug 2003 12:55:42 +0100 Subject: up2date and apt/yum repositories Message-ID: <20030826115541.GR27789@shitake.truemesh.com> I've been doing some testing using up2date-3.9.13-2 Firstly an obvious should bail is: up2date --get-source against a yum url, I believe yum-arch now indexes headers of src.rpms but when running against fedora I get: up2date --get-source synaptic ... synaptic-0.43.1-0.fdr.1.rh90.93.src.rpm... There was some sort of I/O error: HTTP Error 404: Not Found Should we ignore src.rpm headers in yum archives as the path to them is not necessarily obvious (parallel with yum directory, or a subdirectory, etc). This is better than with up2date-3.9.6-1 where it would download the html error page :) In addition I just tried to update to kernel test4 from arjanv's repository (using apt up2date): up2date --nox --force kernel ... Test install failed because of package conflicts: file /lib/modules from install of kernel-2.6.0-0.test4.1.32 conflicts with file from package filesystem-2.2.1-4 rpm -qf /lib/modules/ filesystem-2.2.1-4 kernel-2.4.21-20.1.2024.2.1.nptl kernel-2.6.0-0.test3.1.31 This seems odd to me as both kernel-2.4 spec and kernel 2.6 specs are consistent in having /lib/modules in them, am I missing something obvious as this should work. Paul From smoogen at lanl.gov Tue Aug 26 12:12:15 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 26 Aug 2003 06:12:15 -0600 (MDT) Subject: RH Taroon Beta Open Ports In-Reply-To: <1061876873.3f4af489aebfc@webmail.welho.com> Message-ID: On Tue, 26 Aug 2003, Panu Matilainen wrote: >I'd have to agree with Alex & others: most home users are not going to use/need >NFS and where NFS servers exist, there exists knowledgeable persons to set the >clients up. My +1 for disabling NFS client services by default. I dont think that Taroon is meant for Home Users... -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 5-8058 Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From mharris at redhat.com Tue Aug 26 11:52:23 2003 From: mharris at redhat.com (Mike A. Harris) Date: Tue, 26 Aug 2003 07:52:23 -0400 (EDT) Subject: Athlon 64 support? In-Reply-To: <5bgkkvc073uamsd3pnmocqrag3t9g09l9g@4ax.com> References: <1061797972.29854.95.camel@localhost.localdomain> <1061823257.13015.9.camel@smiddle.civic.twp.ypsilanti.mi.us> <5bgkkvc073uamsd3pnmocqrag3t9g09l9g@4ax.com> Message-ID: On Mon, 25 Aug 2003, Gerald Henriksen wrote: >>> I understand that Red Hat is planning to support Athlon 64 machines >>> specifically in the Enterprise line? Is this correct? (I'm not bashing >>> or judging, just confirming a fact. :) >> >>Supporting Athlon 64 in the Enterprise line only would be daft, as >>Athlon 64 is a consumer chip. Perhaps you meant Opteron, the >>server/workstation AMD64 CPU? But speaking of Athlon 64, will a >>consumer RHL project release be made for it? > >The Enterprise line does have AMD64 version for the next release >(which is currently in beta - named taroon). Correct. >It is expected as the Red Hat Linux Project gets going the community >will provide an AMD64 version in the future. It's unknown at this point in time wether or not an official AMD64 release will be done for the RHLP. That is yet to be decided. On a personal note however, if an official release doesn't occur, I will be volunteering personal time to work on a community driven release along with other interested parties if possible. Once the Athlon 64 consumer chip becomes available, I believe that there will definitely be a quickly forming enthusiast community for this new chip, and I know what OS I'd like to see people running on it. ;o) Of course this is all just personal speculation of my own, and I do not speak for Red Hat in any way. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat From dwmw2 at infradead.org Tue Aug 26 12:23:01 2003 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 26 Aug 2003 13:23:01 +0100 Subject: gnome-bluetooth gnome-vfs module. Message-ID: <1061900581.8465.20.camel@hades.cambridge.redhat.com> Shouldn't /usr/lib/gnome-vfs-2.0/modules/libbluetooth in the gnome-bluetooth package be called libbluetooth.so? Renaming it makes Nautilus a lot happier. Gnome-bluetooth doesn't seem to exist in Bugzilla, either. And although I can drop a vcard file onto my phone, I can't drop a contact from Evolution. -- dwmw2 From ms-nospam-0306 at arcor.de Tue Aug 26 13:12:30 2003 From: ms-nospam-0306 at arcor.de (Michael Schwendt) Date: Tue, 26 Aug 2003 15:12:30 +0200 Subject: bugzilla: See bugs in this component Message-ID: <20030826151230.11050249.ms-nospam-0306@arcor.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The "See bugs in this component" button at step 4 of bugzilla Bug Wizard bugs me: https://bugzilla.redhat.com/bugzilla/easy_enter_bug.cgi It is brain-dead, because it queries the database only for the specific product chosen in the previous step. It is misleading, because it reports "Zarro Boogs found" for a component which clearly has bugs in the same version of a package in Raw Hide or a different "Product". Probably not easily possible without hacking the bugzilla code, but for instance, when reporting bugs against the latest Red Hat Linux Beta, the button should at least find open bugs in Raw Hide, too. - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/S1y+0iMVcrivHFQRAoD0AJ0R6A29eyBfmMhDVNuEY55SQMD/VwCdH2Ry T8jOxQ28zNzJ33bQckoUv90= =VM+c -----END PGP SIGNATURE----- From rhldevel at assursys.co.uk Tue Aug 26 14:16:55 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Tue, 26 Aug 2003 15:16:55 +0100 (BST) Subject: RH Taroon Beta Open Ports In-Reply-To: References: Message-ID: On Tue, 26 Aug 2003, Stephen Smoogen wrote: > On Tue, 26 Aug 2003, Panu Matilainen wrote: > > >I'd have to agree with Alex & others: most home users are not going to use/need > >NFS and where NFS servers exist, there exists knowledgeable persons to set the > >clients up. My +1 for disabling NFS client services by default. > > I dont think that Taroon is meant for Home Users... No, but it gives an insight into what's planned for Red Hat 10 (X?) and the AS/WS 3.0 products. Best Regards, Alex. From katzj at redhat.com Tue Aug 26 15:12:40 2003 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 26 Aug 2003 11:12:40 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <1061876873.3f4af489aebfc@webmail.welho.com> References: <20030825134454.A8928@devserv.devel.redhat.com> <1061876873.3f4af489aebfc@webmail.welho.com> Message-ID: <1061910760.14879.6.camel@mirkwood.devel.redhat.com> On Tue, 2003-08-26 at 01:47, Panu Matilainen wrote: > The difference is that enabling/disabling firewall is a single click of mouse in > the installer in all of the installation modes and IIRC anaconda doesn't nag > about dangers of disabling the fw in any way (apart from help text perhaps) -> > you don't need much knowledge to disable that, but you do need a little bit of > knowledge to turn on services post install. It's easy enough to add a nag to the installer about turning the firewall off if someone files an RFE (otherwise, I'll forget by the time I have a round 'tuit :) Jeremy From alexl at redhat.com Tue Aug 26 15:55:30 2003 From: alexl at redhat.com (Alexander Larsson) Date: 26 Aug 2003 17:55:30 +0200 Subject: gnome-bluetooth gnome-vfs module. In-Reply-To: <1061900581.8465.20.camel@hades.cambridge.redhat.com> References: <1061900581.8465.20.camel@hades.cambridge.redhat.com> Message-ID: <1061913330.22694.67.camel@localhost.localdomain> On Tue, 2003-08-26 at 14:23, David Woodhouse wrote: > Shouldn't /usr/lib/gnome-vfs-2.0/modules/libbluetooth in the > gnome-bluetooth package be called libbluetooth.so? Renaming it makes > Nautilus a lot happier. That looks like a libtool issue. I've seen that happen before. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a globe-trotting chivalrous cyborg in drag. She's a beautiful out-of-work vampire from the wrong side of the tracks. They fight crime! From ghenriks at rogers.com Tue Aug 26 16:20:23 2003 From: ghenriks at rogers.com (Gerald Henriksen) Date: Tue, 26 Aug 2003 12:20:23 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: References: Message-ID: <012nkvouiovebupmh3gdp2naprb3n895ml@4ax.com> On Tue, 26 Aug 2003 15:16:55 +0100 (BST), you wrote: >> I dont think that Taroon is meant for Home Users... > >No, but it gives an insight into what's planned for Red Hat 10 (X?) and the >AS/WS 3.0 products. Taroon has nothing do to with Red Hat 10, the severn beta is what will become Red Hat 10. Taroon is what will be the next release of the Red Hat Enterprise line, and NFS is appropriate for a business oriented product. From jeremyp at pobox.com Tue Aug 26 16:33:51 2003 From: jeremyp at pobox.com (Jeremy Portzer) Date: 26 Aug 2003 12:33:51 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <1061910760.14879.6.camel@mirkwood.devel.redhat.com> References: <20030825134454.A8928@devserv.devel.redhat.com> <1061876873.3f4af489aebfc@webmail.welho.com> <1061910760.14879.6.camel@mirkwood.devel.redhat.com> Message-ID: <1061915630.29771.60.camel@jeremy.dtcc.cc.nc.us> On Tue, 2003-08-26 at 11:12, Jeremy Katz wrote: > On Tue, 2003-08-26 at 01:47, Panu Matilainen wrote: > > The difference is that enabling/disabling firewall is a single click of mouse in > > the installer in all of the installation modes and IIRC anaconda doesn't nag > > about dangers of disabling the fw in any way (apart from help text perhaps) -> > > you don't need much knowledge to disable that, but you do need a little bit of > > knowledge to turn on services post install. > > It's easy enough to add a nag to the installer about turning the > firewall off if someone files an RFE (otherwise, I'll forget by the time > I have a round 'tuit :) Done; see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103102 --Jeremy P. -- /---------------------------------------------------------------------\ | 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 rhldevel at assursys.co.uk Tue Aug 26 17:21:55 2003 From: rhldevel at assursys.co.uk (rhldevel at assursys.co.uk) Date: Tue, 26 Aug 2003 18:21:55 +0100 (BST) Subject: RH Taroon Beta Open Ports In-Reply-To: <012nkvouiovebupmh3gdp2naprb3n895ml@4ax.com> References: <012nkvouiovebupmh3gdp2naprb3n895ml@4ax.com> Message-ID: On Tue, 26 Aug 2003, Gerald Henriksen wrote: > On Tue, 26 Aug 2003 15:16:55 +0100 (BST), you wrote: > > >> I dont think that Taroon is meant for Home Users... > > > >No, but it gives an insight into what's planned for Red Hat 10 (X?) and the > >AS/WS 3.0 products. > > Taroon has nothing do to with Red Hat 10, the severn beta is what will > become Red Hat 10. Beg pardon. I wasn't paying attention to the beta announcements... ;-) > Taroon is what will be the next release of the Red Hat Enterprise > line, and NFS is appropriate for a business oriented product. ...but I bet Severn has the same (or larger) set of services enabled by default. Anyone care to comment? Best Regards, Alex. From alikins at redhat.com Tue Aug 26 17:48:13 2003 From: alikins at redhat.com (Adrian Likins) Date: Tue, 26 Aug 2003 13:48:13 -0400 Subject: up2date and apt/yum repositories In-Reply-To: <20030826115541.GR27789@shitake.truemesh.com>; from pauln@truemesh.com on Tue, Aug 26, 2003 at 12:55:42PM +0100 References: <20030826115541.GR27789@shitake.truemesh.com> Message-ID: <20030826134813.A11820@redhat.com> On Tue, Aug 26, 2003 at 12:55:42PM +0100, Paul Nasrat wrote: > I've been doing some testing using > > up2date-3.9.13-2 > > Firstly an obvious should bail is: > > up2date --get-source against a yum url, I believe yum-arch now indexes > headers of src.rpms but when running against fedora I get: > > up2date --get-source synaptic > ... > synaptic-0.43.1-0.fdr.1.rh90.93.src.rpm... > There was some sort of I/O error: HTTP Error 404: Not Found > > Should we ignore src.rpm headers in yum archives as the path to them is > not necessarily obvious (parallel with yum directory, or a subdirectory, > etc). > Right now it guesses it's parallel with the yum directory, since this seemed the most popular layout after a quick survery. But yum doesnt indicate where SRPMS are stashed in any obvious way, so it's currently a guess. If the SRPMS stuff gets standardized, I can make it respect that. > In addition I just tried to update to kernel test4 from arjanv's > repository (using apt up2date): > > up2date --nox --force kernel > ... > Test install failed because of package conflicts: > file /lib/modules from install of kernel-2.6.0-0.test4.1.32 conflicts > with file from package filesystem-2.2.1-4 > > rpm -qf /lib/modules/ > filesystem-2.2.1-4 > kernel-2.4.21-20.1.2024.2.1.nptl > kernel-2.6.0-0.test3.1.31 > > This seems odd to me as both kernel-2.4 spec and kernel 2.6 specs are > consistent in having /lib/modules in them, am I missing something > obvious as this should work. Odd to get a conflict on a dir... I'll investigate. Adrian From ghenriks at rogers.com Tue Aug 26 18:59:00 2003 From: ghenriks at rogers.com (Gerald Henriksen) Date: Tue, 26 Aug 2003 14:59:00 -0400 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <3F3BAD74.6070603@redhat.com> References: <3F394DFC.8040508@redhat.com> <3F3B6501.3080101@fx.ro> <1060860647.5862.1.camel@bart.netlyncs.com> <3F3BAD74.6070603@redhat.com> Message-ID: <7pankvsir4qpqgr6oga26h1n3q54j2qsuj@4ax.com> On Thu, 14 Aug 2003 11:40:36 -0400, you wrote: >I figured that it made sense to have the larger icons for the time being >so that some of the icon sizing stuff might get sorted out. I will >probably switch back the icons to the smaller size regardless -- it >depends on what makes the most sense, though. Well I also vote for the smaller size icons after my brief try of the new theme today. However to me the biggest problem (and why I have gone back to the original version) is the removal of the visual hints of the boundaries of the in use window. With the original version there appears to be some 3D hinting as well as the blue corners at the bottom. Thus I can quickly see the limits of the current window on a screen that as 10 or so applications open. The new version I found that the various applications blended together and I had to stop and think which part of the screen belonged to the app I was using and which was from an app that was behind the current one. From chuckw at quantumlinux.com Tue Aug 26 19:17:30 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 26 Aug 2003 12:17:30 -0700 (PDT) Subject: RH Taroon Beta Open Ports In-Reply-To: <1061884358.3600.26.camel@mentor.gurulabs.com> Message-ID: > > I've just done a "complete" install of Taroon on a scratch box, with > > iptables firewalling disabled > > Realize at this point you are NO longer talking about securing a "stock" > install. That's simply not the case. It's an option during the install, hence it's a stock install. Going beyond a stock install should mean bolting stuff on after the new machine has come up and is ready for general use. > You are now running a "custom" install, the responsibility now rests on > your shoulders. If you remove the installed-by-default air filter from > your automobile, that is your prerogative. Deal with the consequences. Removing the installed-by-default air filter is something that happens after the car arrives in your driveway. What happened above, happened while the "car" was still in the factory. Sure, the customer asked for some "special options". In that case, the factory shouldn't break the "car" just because you asked for options. To use your terminology... > The stock RH install is secure by default. The firewall created at > installation time prohibits ALL inbound connection requests except for > ICMP echo requests (ping). Which stock install is that? The desktop? The server? Perhaps you mean the laptop? Or were you talking about the upgrade install? > I strongly disagree with claim that very few small and medium business > Linux environments use NFS and instead use Samba. Agreed. Samba uses SMB locking semantics and NFS uses POSIX locking semantics. Don't call a plumber to do your brain surgery... -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From skvidal at phy.duke.edu Tue Aug 26 19:24:06 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 26 Aug 2003 15:24:06 -0400 Subject: up2date and apt/yum repositories In-Reply-To: <20030826134813.A11820@redhat.com> References: <20030826115541.GR27789@shitake.truemesh.com> <20030826134813.A11820@redhat.com> Message-ID: <1061925846.27068.113.camel@opus.phy.duke.edu> On Tue, 2003-08-26 at 13:48, Adrian Likins wrote: > On Tue, Aug 26, 2003 at 12:55:42PM +0100, Paul Nasrat wrote: > > I've been doing some testing using > > > > up2date-3.9.13-2 > > > > Firstly an obvious should bail is: > > > > up2date --get-source against a yum url, I believe yum-arch now indexes > > headers of src.rpms but when running against fedora I get: > > > > up2date --get-source synaptic > > ... > > synaptic-0.43.1-0.fdr.1.rh90.93.src.rpm... > > There was some sort of I/O error: HTTP Error 404: Not Found > > > > Should we ignore src.rpm headers in yum archives as the path to them is > > not necessarily obvious (parallel with yum directory, or a subdirectory, > > etc). > > > Right now it guesses it's parallel with the yum directory, > since this seemed the most popular layout after a quick survery. > But yum doesnt indicate where SRPMS are stashed in any obvious > way, so it's currently a guess. If the SRPMS stuff gets standardized, > I can make it respect that. > You can't just use whatever the header.src.info points stuff to? or is it the arch thing that's holding it up? -sv From yeti at physics.muni.cz Tue Aug 26 19:32:11 2003 From: yeti at physics.muni.cz (David Necas (Yeti)) Date: Tue, 26 Aug 2003 21:32:11 +0200 Subject: RH Taroon Beta Open Ports In-Reply-To: References: <1061884358.3600.26.camel@mentor.gurulabs.com> Message-ID: <20030826193211.GA4716@potato.brno.mistral.cz> On Tue, Aug 26, 2003 at 12:17:30PM -0700, Chuck Wolber wrote: > > I strongly disagree with claim that very few small and medium business > > Linux environments use NFS and instead use Samba. > > Agreed. Samba uses SMB locking semantics and NFS uses POSIX locking > semantics. Don't call a plumber to do your brain surgery... We can care about POSIX locking sematics. But do you really think the small businesses care about it too? They often had a mixed environment for some time (or still have it) so Samba was necessary, and once Samba works, they will hardly replace it with NFS. Yeti -- Do not use tab characters. Their effect is not predictable. From alikins at redhat.com Tue Aug 26 19:34:33 2003 From: alikins at redhat.com (Adrian Likins) Date: Tue, 26 Aug 2003 15:34:33 -0400 Subject: up2date and apt/yum repositories In-Reply-To: <1061925846.27068.113.camel@opus.phy.duke.edu>; from skvidal@phy.duke.edu on Tue, Aug 26, 2003 at 03:24:06PM -0400 References: <20030826115541.GR27789@shitake.truemesh.com> <20030826134813.A11820@redhat.com> <1061925846.27068.113.camel@opus.phy.duke.edu> Message-ID: <20030826153433.D11820@redhat.com> On Tue, Aug 26, 2003 at 03:24:06PM -0400, seth vidal wrote: > On Tue, 2003-08-26 at 13:48, Adrian Likins wrote: > > On Tue, Aug 26, 2003 at 12:55:42PM +0100, Paul Nasrat wrote: > > > I've been doing some testing using > > > > > > up2date-3.9.13-2 > > > > > > Firstly an obvious should bail is: > > > > > > up2date --get-source against a yum url, I believe yum-arch now indexes > > > headers of src.rpms but when running against fedora I get: > > > > > > up2date --get-source synaptic > > > ... > > > synaptic-0.43.1-0.fdr.1.rh90.93.src.rpm... > > > There was some sort of I/O error: HTTP Error 404: Not Found > > > > > > Should we ignore src.rpm headers in yum archives as the path to them is > > > not necessarily obvious (parallel with yum directory, or a subdirectory, > > > etc). > > > > > Right now it guesses it's parallel with the yum directory, > > since this seemed the most popular layout after a quick survery. > > But yum doesnt indicate where SRPMS are stashed in any obvious > > way, so it's currently a guess. If the SRPMS stuff gets standardized, > > I can make it respect that. > > > You can't just use whatever the header.src.info points stuff to? How do I find the header.src.info file? Adrian From skvidal at phy.duke.edu Tue Aug 26 19:41:39 2003 From: skvidal at phy.duke.edu (seth vidal) Date: 26 Aug 2003 15:41:39 -0400 Subject: up2date and apt/yum repositories In-Reply-To: <20030826153433.D11820@redhat.com> References: <20030826115541.GR27789@shitake.truemesh.com> <20030826134813.A11820@redhat.com> <1061925846.27068.113.camel@opus.phy.duke.edu> <20030826153433.D11820@redhat.com> Message-ID: <1061926899.27068.115.camel@opus.phy.duke.edu> > > You can't just use whatever the header.src.info points stuff to? > > How do I find the header.src.info file? It's always in headers/ if the repository has had yum-arch -s run on it (in yum 2.0.1 or better) -sv From alikins at redhat.com Tue Aug 26 19:53:30 2003 From: alikins at redhat.com (Adrian Likins) Date: Tue, 26 Aug 2003 15:53:30 -0400 Subject: up2date and apt/yum repositories In-Reply-To: <1061926899.27068.115.camel@opus.phy.duke.edu>; from skvidal@phy.duke.edu on Tue, Aug 26, 2003 at 03:41:39PM -0400 References: <20030826115541.GR27789@shitake.truemesh.com> <20030826134813.A11820@redhat.com> <1061925846.27068.113.camel@opus.phy.duke.edu> <20030826153433.D11820@redhat.com> <1061926899.27068.115.camel@opus.phy.duke.edu> Message-ID: <20030826155330.E11820@redhat.com> On Tue, Aug 26, 2003 at 03:41:39PM -0400, seth vidal wrote: > > > You can't just use whatever the header.src.info points stuff to? > > > > How do I find the header.src.info file? > > It's always in headers/ if the repository has had yum-arch -s run on it > (in yum 2.0.1 or better) > I'm not seeing that. I'm seeing it placed into the headers/ subdir of SRPMS, which doesnt really help me, since I dont know how to find the SRPMS subdir (I don't specify them seperately atm... I suppose I could, but I'm not sure how to handle old non-src having yum repos). I would like to see the placement of the RPMS/ and SRPMS dirs standardized (or pointed at by some standard metadata file or whatever...). Basically, just looking for a way to specify one url and be able to reliably find src and bin. Having a seperate repo type for yum-src seems a bit odd as well. But I guess thats more inline with the way yum does it with seperate repos for src and bin packages. Adrian From chuckw at quantumlinux.com Tue Aug 26 20:01:34 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 26 Aug 2003 13:01:34 -0700 (PDT) Subject: RH Taroon Beta Open Ports In-Reply-To: <20030826193211.GA4716@potato.brno.mistral.cz> Message-ID: > > Agreed. Samba uses SMB locking semantics and NFS uses POSIX locking > > semantics. Don't call a plumber to do your brain surgery... > > We can care about POSIX locking sematics. But do you really think the > small businesses care about it too? Nope, not one single bit. They wouldn't know POSIX if it jumped out of the toilet while they were sitting on it. >From personal experience, what they do know is that NFS is for UNIX<->UNIX file sharing and SAMBA is for *<->WINDOWS file sharing (and printing). Inevitably the question comes up, "why can't we use just one or the other". I've posed this question directly to Jeremy Allison and he echoed the usual response that the behaviour is not predictable due to said locking semantics. In the end, the brain surgery and plumber analogy usually gets the point across. > They often had a mixed environment for some time (or still have it) so > Samba was necessary, and once Samba works, they will hardly replace it > with NFS. No reason to replace SAMBA with NFS. They work fine together. Just be aware that using 100% one or the other will lead to unpredictable results. -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From ted at cypress.com Tue Aug 26 20:38:37 2003 From: ted at cypress.com (Thomas Dodd) Date: Tue, 26 Aug 2003 15:38:37 -0500 Subject: RH Taroon Beta Open Ports In-Reply-To: References: Message-ID: <3F4BC54D.3030706@cypress.com> Chuck Wolber wrote: > > No reason to replace SAMBA with NFS. They work fine together. Just be > aware that using 100% one or the other will lead to unpredictable results. How's that? I've used 100% NFS setups without problems for a long time. Never had "unpredictible results". It's adding samba, more specifically MS Windows into the mix that causes problems. -Thomas From chuckw at quantumlinux.com Tue Aug 26 20:49:23 2003 From: chuckw at quantumlinux.com (Chuck Wolber) Date: Tue, 26 Aug 2003 13:49:23 -0700 (PDT) Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4BC54D.3030706@cypress.com> Message-ID: > > No reason to replace SAMBA with NFS. They work fine together. Just be > > aware that using 100% one or the other will lead to unpredictable > > results. > > How's that? I've used 100% NFS setups without problems for a long time. > Never had "unpredictible results". It's adding samba, more specifically > MS Windows into the mix that causes problems. I think you missed my point. If you are just using POSIX type systems, use a POSIX type file sharing protocol. If you are using SMB type systems use a SMB type file sharing protocol. If you are using both types of systems, use both sharing protocols... -Chuck -- Quantum Linux Laboratories - ACCELERATING Business with Open Technology * Education | -=^ Ad Astra Per Aspera ^=- * Integration | http://www.quantumlinux.com * Support | chuckw at quantumlinux.com From dee at renaissoft.com Tue Aug 26 20:52:07 2003 From: dee at renaissoft.com (Dee-Ann LeBlanc) Date: 26 Aug 2003 13:52:07 -0700 Subject: Athlon 64 support? (multiple responses) In-Reply-To: <20030826160010.13452.21344.Mailman@listman.back-rdu.redhat.com> References: <20030826160010.13452.21344.Mailman@listman.back-rdu.redhat.com> Message-ID: <1061931127.29854.337.camel@localhost.localdomain> Gerald Henriksen wrote: > As far as the CPU instruction set is concerned Athlon64 and Opteron > are identical as they are both AMD64 processors. Good to know. :) > At some point in the future there likely will be an AMD64 version of > RHLP, as the community will likely build it if necessary. However > this won't happen in time for the release of Red Hat 10 given that > Athlon64 is not yet available, and reportedly won't be available in > volume for many months yet. Oh sure, I didn't think it would be for 10. :) I'm asking in general. :) > > However the normal version of Red Hat 9/10/etc. will work fine on an > Athlon64 machine albeit without support for the new features of the > AMD64 architecture (no 64bit stuff, no additional registers, etc). Ah, okay, so that should be the same for any distro, really. Good good. Hardware isn't my specialty, can you tell? :) "Mike A. Harris" wrote: > It's unknown at this point in time wether or not an official > AMD64 release will be done for the RHLP. That is yet to be > decided. I expect I'll see something related to this asked in the next demo RHN survey then. :) > > On a personal note however, if an official release doesn't occur, > I will be volunteering personal time to work on a community > driven release along with other interested parties if possible. Awesome. :) > > Once the Athlon 64 consumer chip becomes available, I believe > that there will definitely be a quickly forming enthusiast > community for this new chip, and I know what OS I'd like to see > people running on it. ;o) Oh yes. I'm sure I won't be the only one salivating. :) > > Of course this is all just personal speculation of my own, and I > do not speak for Red Hat in any way. Understood! -- Dee-Ann LeBlanc, RHCE Lots of things Linux http://www.Dee-AnnLeBlanc.com/ From riel at redhat.com Tue Aug 26 20:57:26 2003 From: riel at redhat.com (Rik van Riel) Date: Tue, 26 Aug 2003 16:57:26 -0400 (EDT) Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4A23E2.3020907@RedHat.com> Message-ID: On Mon, 25 Aug 2003, Steve Dickson wrote: > Portmapper has been around quite a long time making it pretty bullet > proof... So I see no reason what so ever to turn off portmapper. General paranoia sounds like a legitimate enough reason to me. > Lets not make a system more difficult to deal with for simply no > reason... Meaning we should start the portmapper as soon as we start some service that needs it and not start the portmapper if it's not needed. If we can determine and configure this automagically, I don't see how we'd be making life harder for anyone. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From garrett at redhat.com Tue Aug 26 22:08:02 2003 From: garrett at redhat.com (Garrett LeSage) Date: Tue, 26 Aug 2003 18:08:02 -0400 Subject: recent redhat-artwork/Bluecurve updates (w/ screenshots) In-Reply-To: <7pankvsir4qpqgr6oga26h1n3q54j2qsuj@4ax.com> References: <3F394DFC.8040508@redhat.com> <3F3B6501.3080101@fx.ro> <1060860647.5862.1.camel@bart.netlyncs.com> <3F3BAD74.6070603@redhat.com> <7pankvsir4qpqgr6oga26h1n3q54j2qsuj@4ax.com> Message-ID: <3F4BDA42.1080409@redhat.com> Gerald Henriksen wrote: >On Thu, 14 Aug 2003 11:40:36 -0400, you wrote: > > > >>I figured that it made sense to have the larger icons for the time being >>so that some of the icon sizing stuff might get sorted out. I will >>probably switch back the icons to the smaller size regardless -- it >>depends on what makes the most sense, though. >> >> > >Well I also vote for the smaller size icons after my brief try of the >new theme today. > > I have reverted the icon size in CVS (probably to the relief of many, including myself after a few days of usage). It should be in the next version of redhat-artwork. >However to me the biggest problem (and why I have gone back to the >original version) is the removal of the visual hints of the boundaries >of the in use window. > >With the original version there appears to be some 3D hinting as well >as the blue corners at the bottom. Thus I can quickly see the limits >of the current window on a screen that as 10 or so applications open. > >The new version I found that the various applications blended together >and I had to stop and think which part of the screen belonged to the >app I was using and which was from an app that was behind the current >one. > > I'll have to think about this one a bit. I removed the corner handles because they did not really indicate resizing after I thought about it (as you could really resize from any corner). The handles merely indicated where a diagonal resize would take place. I really like the new borders where it puts less of an emphasis on the theme itself and makes the window frame feel more like a part of the application window. I will try thinking of some alternatives, but I'm not going to promise anything at this point. No matter what changes, someone will like it better one way than the other. I want to try to do what's best. Garrett From jaboutboul at speakeasy.net Tue Aug 26 22:52:41 2003 From: jaboutboul at speakeasy.net (Jack Aboutboul) Date: Wed, 27 Aug 2003 01:52:41 +0300 Subject: /etc/sysconfig/network-scripts Message-ID: Hello All, Anyone know where we can get some documentation on the whole mess that is /etc/sysconfig/network*. A few of us in #rhl-devel have been looking for info on static-routes and other functions of the scripts. The man pages dont get very in depth here. Another issue that also comes up is that neat sometimes randomly uses either sysconfig/networking and sometimes sysconfig/network-scripts. For the well being off the openness of the rhlp there needs to be more documentation on this topic. --Jack From skvidal at phy.duke.edu Tue Aug 26 23:04:35 2003 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 26 Aug 2003 19:04:35 -0400 Subject: /etc/sysconfig/network-scripts In-Reply-To: References: Message-ID: <1061939075.3514.0.camel@binkley> On Tue, 2003-08-26 at 18:52, Jack Aboutboul wrote: > Hello All, > > Anyone know where we can get some documentation on the whole mess that > is /etc/sysconfig/network*. A few of us in #rhl-devel have been > looking for info on static-routes and other functions of the scripts. > The man pages dont get very in depth here. Another issue that also > comes up is that neat sometimes randomly uses either > sysconfig/networking and sometimes sysconfig/network-scripts. For the > well being off the openness of the rhlp there needs to be more > documentation on this topic. I coulda sworn this was documented in /usr/share/docs/initscript* -sv From katzj at redhat.com Tue Aug 26 23:06:24 2003 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 26 Aug 2003 19:06:24 -0400 Subject: /etc/sysconfig/network-scripts In-Reply-To: References: Message-ID: <1061939184.15528.15.camel@mirkwood.devel.redhat.com> On Tue, 2003-08-26 at 18:52, Jack Aboutboul wrote: > Anyone know where we can get some documentation on the whole mess that > is /etc/sysconfig/network*. /usr/share/doc/initscripts-*/* (especially sysconfig.txt) > For the well being off the openness of the rhlp there needs to be more > documentation on this topic. I'm sure Bill would accept patches :-) Jeremy From garrett at redhat.com Tue Aug 26 23:13:08 2003 From: garrett at redhat.com (Garrett LeSage) Date: Tue, 26 Aug 2003 19:13:08 -0400 Subject: new redhat-artwork updates in cvs! Message-ID: <3F4BE984.6030609@redhat.com> Hello, I have committed a few changes to redhat-artwork today. The changes are, as follows: * New GTK+ color scheme: "Bluecurve-BerriesAndCream". It is based on the theme that was originally introduced in an earlier beta cycle (for the 9 time frame, iirc), and has a blueberry blue selection color (blue with a tint of purple) and a creamy warm widget color. * Fixed Metacity theme titlebar height (mostly a problem for Japanese text -- and possibly other languages). * Updated Metacity theme style (more contrast for titlebar text, less of a titlebar shine, the focused titlebar selection color is richer, and insensitive titlebars now are colored slightly darker). * File manager icons (mime types) do not display text unless the icon is a plain text icon with the little text viewing area. Let me know what you think of the changes. I think I am now going to go celebrate my birthday today with some cake and/or ice cream. (: Garrett PS: Rawhide RPMs of redhat-artwork should hopefully appear soon. I'll ask Alex to build a fresh version tomorrow. From smoogen at lanl.gov Wed Aug 27 01:47:43 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 26 Aug 2003 19:47:43 -0600 (MDT) Subject: RH Taroon Beta Open Ports In-Reply-To: Message-ID: On Tue, 26 Aug 2003, Chuck Wolber wrote: > >> > I've just done a "complete" install of Taroon on a scratch box, with >> > iptables firewalling disabled >> >> Realize at this point you are NO longer talking about securing a "stock" >> install. > >That's simply not the case. It's an option during the install, hence it's >a stock install. Going beyond a stock install should mean bolting stuff on >after the new machine has come up and is ready for general use. > And so is a 'custom' install by this logic. I am guessing that Red Hat should really just have a Henry Ford[1] install option with one choice of minimal for installing. Makes Red Hat's job much easier.. you can always customize the distro afterwords. [1] Paraphrase of Henry Ford: You can have a model T in any color you want, as long as it is black. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 5-8058 Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From dwalsh at redhat.com Wed Aug 27 02:23:39 2003 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 26 Aug 2003 22:23:39 -0400 Subject: RH Taroon Beta Open Ports References: Message-ID: <3F4C162B.4090702@redhat.com> I also think minimal ports should be the default. Maybe adding some inteligence to the scripts or redhat-config-services to allow know that if you start NFS you also need to start portmapper. Maybe by adding a requires flag to the NFS init script. Why do we have a bias towards the machine being a server machine? If we argue that we should start portmapper because alot of Unix machines use it to intercommunicate, the same argument could be used for other protocols like FTP, Telnet, samba ... A machine should be running minimal services to start and then make it easy for the user to start up services. Interaction between tools like redhat-config-services and the firewall would be nice. Dan From jensknutson at yahoo.com Wed Aug 27 02:33:19 2003 From: jensknutson at yahoo.com (Jens Knutson) Date: Tue, 26 Aug 2003 19:33:19 -0700 (PDT) Subject: new redhat-artwork updates in cvs! In-Reply-To: <3F4BE984.6030609@redhat.com> Message-ID: <20030827023319.73639.qmail@web14205.mail.yahoo.com> --- Garrett LeSage wrote: > The changes are, as follows: > > * New GTK+ color scheme: "Bluecurve-BerriesAndCream". It is > based > on the theme that was originally introduced in an earlier beta > cycle (for the 9 time frame, iirc), and has a blueberry blue > selection color (blue with a tint of purple) and a creamy warm > widget color. Wahoo! This was SO nice, I've missed it! Thanks for reinstating it! > Let me know what you think of the changes. I think I am now going to > go celebrate my birthday today with some cake and/or ice cream. (: Happy birthday, man! :) Enjoy your sweets and other celebratory foodstuffs! - jck __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From feliciano.matias at free.fr Wed Aug 27 06:54:15 2003 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: 27 Aug 2003 08:54:15 +0200 Subject: Text console port of GTK+ Message-ID: <1061967254.21665.4.camel@one.myworld> Text console port of GTK+ : http://zemljanka.sourceforge.net/cursed/ Interesting for anaconda, redhat-config-*. Perhaps for (Cambridge++)++ -- F?liciano Matias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jaboutboul at speakeasy.net Wed Aug 27 08:34:27 2003 From: jaboutboul at speakeasy.net (Jack Aboutboul) Date: Wed, 27 Aug 2003 11:34:27 +0300 Subject: /etc/sysconfig/network-scripts In-Reply-To: <1061939184.15528.15.camel@mirkwood.devel.redhat.com> Message-ID: <455A2EBE-D869-11D7-88B1-000A95689082@speakeasy.net> On Wednesday, Aug 27, 2003, at 02:06 Asia/Jerusalem, Jeremy Katz wrote: > On Tue, 2003-08-26 at 18:52, Jack Aboutboul wrote: >> Anyone know where we can get some documentation on the whole mess >> that >> is /etc/sysconfig/network*. > > /usr/share/doc/initscripts-*/* (especially sysconfig.txt) Thanks Jeremy!! --Jack From dhollis at davehollis.com Wed Aug 27 14:36:49 2003 From: dhollis at davehollis.com (David T Hollis) Date: Wed, 27 Aug 2003 10:36:49 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: References: Message-ID: <3F4CC201.6040001@davehollis.com> Rik van Riel wrote: >On Mon, 25 Aug 2003, Steve Dickson wrote: > > > >>Portmapper has been around quite a long time making it pretty bullet >>proof... So I see no reason what so ever to turn off portmapper. >> >> > >General paranoia sounds like a legitimate enough reason >to me. > > > >>Lets not make a system more difficult to deal with for simply no >>reason... >> >> > >Meaning we should start the portmapper as soon as we start >some service that needs it and not start the portmapper if >it's not needed. > >If we can determine and configure this automagically, I >don't see how we'd be making life harder for anyone. > > > Begins to suggest that program that I can't remember the name of for the life of me. It actually in Rawhide briefly before 9 came out. It used an XML format to define services and what they depended on. With that app, you would add portmap as a dependency for nfs or xinetd (for sgi_fam) or any other apps and it would ensure that portmap was started before them. Now I certainly realize that going towards something like that is a massive change to the boot process and is not something that would happen anytime soon, but it is an interesting idea. From notting at redhat.com Wed Aug 27 15:33:29 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Aug 2003 11:33:29 -0400 Subject: Text console port of GTK+ In-Reply-To: <1061967254.21665.4.camel@one.myworld>; from feliciano.matias@free.fr on Wed, Aug 27, 2003 at 08:54:15AM +0200 References: <1061967254.21665.4.camel@one.myworld> Message-ID: <20030827113329.A28947@devserv.devel.redhat.com> F?liciano Matias (feliciano.matias at free.fr) said: > Text console port of GTK+ : > http://zemljanka.sourceforge.net/cursed/ > > Interesting for anaconda Why? Anaconda already has a text mode, and by sticking with a native text mode, you have a much better chance of having dialogs fitting in a sane manner. Bill From harald at redhat.com Wed Aug 27 15:52:06 2003 From: harald at redhat.com (Harald Hoyer) Date: Wed, 27 Aug 2003 17:52:06 +0200 Subject: /etc/sysconfig/network-scripts In-Reply-To: References: Message-ID: <1061999526.8078.6.camel@faro.stuttgart.redhat.com> /etc/sysconfig/networking could go away, so it is not documented.. All scripts should stick with what is in /etc/sysconfig/network-scripts. Am Mi, 2003-08-27 um 00.52 schrieb Jack Aboutboul: > Hello All, > > Anyone know where we can get some documentation on the whole mess that > is /etc/sysconfig/network*. A few of us in #rhl-devel have been > looking for info on static-routes and other functions of the scripts. > The man pages dont get very in depth here. Another issue that also > comes up is that neat sometimes randomly uses either > sysconfig/networking and sometimes sysconfig/network-scripts. For the > well being off the openness of the rhlp there needs to be more > documentation on this topic. > > --Jack > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Harald Hoyer, Senior Software Engineer Harald.Hoyer at redhat.de Red Hat GmbH Tel. : +49-711-96437-0 D-70178 Stuttgart, Germany Web : http://www.redhat.de gpg fingerprint E930 20E6 CCF8 C76C 8582 CF9F B7B7 45C2 C557 5542 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From kaboom at gatech.edu Wed Aug 27 15:56:16 2003 From: kaboom at gatech.edu (Chris Ricker) Date: Wed, 27 Aug 2003 09:56:16 -0600 (MDT) Subject: /etc/sysconfig/network-scripts In-Reply-To: <1061999526.8078.6.camel@faro.stuttgart.redhat.com> References: <1061999526.8078.6.camel@faro.stuttgart.redhat.com> Message-ID: On Wed, 27 Aug 2003, Harald Hoyer wrote: > /etc/sysconfig/networking could go away, so it is not documented.. > All scripts should stick with what is in /etc/sysconfig/network-scripts. Please make it go away One set of config files for anything is enough, thank you ;-) later, chris From hbo at egbok.com Wed Aug 27 16:04:20 2003 From: hbo at egbok.com (Howard Owen) Date: 27 Aug 2003 09:04:20 -0700 Subject: Text console port of GTK+ In-Reply-To: <20030827113329.A28947@devserv.devel.redhat.com> References: <1061967254.21665.4.camel@one.myworld> <20030827113329.A28947@devserv.devel.redhat.com> Message-ID: <1062000259.1328.36.camel@owen.egbok.com> Agreed. But don't tell me that some,small,irrational part of your consciousness didn't gasp "that would be unbelievably cool!" when you saw that puppy. 8) On Wed, 2003-08-27 at 08:33, Bill Nottingham wrote: > F?liciano Matias (feliciano.matias at free.fr) said: > > Text console port of GTK+ : > > http://zemljanka.sourceforge.net/cursed/ > > > > Interesting for anaconda > > Why? Anaconda already has a text mode, and by sticking with a native > text mode, you have a much better chance of having dialogs fitting > in a sane manner. > > Bill > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From brugolsky at telemetry-investments.com Wed Aug 27 16:13:27 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Wed, 27 Aug 2003 12:13:27 -0400 Subject: Text console port of GTK+ In-Reply-To: <20030827113329.A28947@devserv.devel.redhat.com> References: <1061967254.21665.4.camel@one.myworld> <20030827113329.A28947@devserv.devel.redhat.com> Message-ID: <20030827161326.GA26032@ti19> On Wed, Aug 27, 2003 at 11:33:29AM -0400, Bill Nottingham wrote: > Why? Anaconda already has a text mode, and by sticking with a native > text mode, you have a much better chance of having dialogs fitting > in a sane manner. True, but -tui and -cmd versions of *all* the redhat-config tools, along with an audit trail of changes would be nice. AFAIK, right now it is basically necessary to save /etc in CVS or similar if one wants a record of what is going on. (And that still neglects state changes.) This is a step backwards from earlier attempts (linuxconf, etc.). Regards, Bill Rugolsky From feliciano.matias at free.fr Wed Aug 27 17:03:50 2003 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: 27 Aug 2003 19:03:50 +0200 Subject: Text console port of GTK+ In-Reply-To: <20030827113329.A28947@devserv.devel.redhat.com> References: <1061967254.21665.4.camel@one.myworld> <20030827113329.A28947@devserv.devel.redhat.com> Message-ID: <1062003829.1004.32.camel@one.myworld> Le mer 27/08/2003 ? 17:33, Bill Nottingham a ?crit : > F?liciano Matias (feliciano.matias at free.fr) said: > > Text console port of GTK+ : > > http://zemljanka.sourceforge.net/cursed/ > > > > Interesting for anaconda > > Why? Seems to me that anaconda in text mode doesn't have all feature of anaconda in graphic mode. > Anaconda already has a text mode, and by sticking with a native > text mode, you have a much better chance of having dialogs fitting > in a sane manner. I would like to see rhgb in text mode. Is there any plan ? :-) > Bill > -- F?liciano Matias -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From sbonnevi at redhat.com Wed Aug 27 17:15:53 2003 From: sbonnevi at redhat.com (Steven Bonneville) Date: Wed, 27 Aug 2003 13:15:53 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <20030827155502.24437.1756.Mailman@listman.back-rdu.redhat.com> References: <20030827155502.24437.1756.Mailman@listman.back-rdu.redhat.com> Message-ID: <20030827171553.GA12436@sbonnevi.rdu.redhat.com> Dan Walsh wrote: > I also think minimal ports should be the default. Maybe adding some > inteligence to the scripts or redhat-config-services to allow know that > if you start NFS you also need to start portmapper. Maybe > by adding a requires flag to the NFS init script. > > Why do we have a bias towards the machine being a server machine? Don't forget that the client side also needs to have portmap running in order to mount an NFS share. So the mount command would have to start up or make sure portmap and nfslock are running, too. -- Steve Bonneville From notting at redhat.com Wed Aug 27 17:22:38 2003 From: notting at redhat.com (Bill Nottingham) Date: Wed, 27 Aug 2003 13:22:38 -0400 Subject: Text console port of GTK+ In-Reply-To: <1062003829.1004.32.camel@one.myworld>; from feliciano.matias@free.fr on Wed, Aug 27, 2003 at 07:03:50PM +0200 References: <1061967254.21665.4.camel@one.myworld> <20030827113329.A28947@devserv.devel.redhat.com> <1062003829.1004.32.camel@one.myworld> Message-ID: <20030827132237.A27449@devserv.devel.redhat.com> F?liciano Matias (feliciano.matias at free.fr) said: > > Why? > > Seems to me that anaconda in text mode doesn't have all feature of > anaconda in graphic mode. Yes, but rebasing the entire text mode isn't the solution to that problem. > > Anaconda already has a text mode, and by sticking with a native > > text mode, you have a much better chance of having dialogs fitting > > in a sane manner. > > I would like to see rhgb in text mode. rhtb? > Is there any plan ? :-) Not currently. Bill From dwalsh at redhat.com Wed Aug 27 18:45:27 2003 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 27 Aug 2003 14:45:27 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <20030827171553.GA12436@sbonnevi.rdu.redhat.com> References: <20030827155502.24437.1756.Mailman@listman.back-rdu.redhat.com> <20030827171553.GA12436@sbonnevi.rdu.redhat.com> Message-ID: <3F4CFC47.7040606@redhat.com> Just tried it and it does a nice job of hanging my terminal. :^( Steven Bonneville wrote: >Dan Walsh wrote: > > >>I also think minimal ports should be the default. Maybe adding some >>inteligence to the scripts or redhat-config-services to allow know that >>if you start NFS you also need to start portmapper. Maybe >>by adding a requires flag to the NFS init script. >> >>Why do we have a bias towards the machine being a server machine? >> >> > >Don't forget that the client side also needs to have portmap running >in order to mount an NFS share. So the mount command would have to >start up or make sure portmap and nfslock are running, too. > > -- Steve Bonneville > > >-- >Rhl-devel-list mailing list >Rhl-devel-list at redhat.com >http://www.redhat.com/mailman/listinfo/rhl-devel-list > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Wed Aug 27 19:10:53 2003 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 27 Aug 2003 15:10:53 -0400 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4CFC47.7040606@redhat.com> References: <20030827155502.24437.1756.Mailman@listman.back-rdu.redhat.com> <20030827171553.GA12436@sbonnevi.rdu.redhat.com> <3F4CFC47.7040606@redhat.com> Message-ID: <3F4D023D.3060706@redhat.com> Nope it eventually worked. Not sure what the hang was. I am mounting remote NFS machines without portmap running. Daniel J Walsh wrote: > Just tried it and it does a nice job of hanging my terminal. :^( > > Steven Bonneville wrote: > >>Dan Walsh wrote: >> >> >>>I also think minimal ports should be the default. Maybe adding some >>>inteligence to the scripts or redhat-config-services to allow know that >>>if you start NFS you also need to start portmapper. Maybe >>>by adding a requires flag to the NFS init script. >>> >>>Why do we have a bias towards the machine being a server machine? >>> >>> >> >>Don't forget that the client side also needs to have portmap running >>in order to mount an NFS share. So the mount command would have to >>start up or make sure portmap and nfslock are running, too. >> >> -- Steve Bonneville >> >> >>-- >>Rhl-devel-list mailing list >>Rhl-devel-list at redhat.com >>http://www.redhat.com/mailman/listinfo/rhl-devel-list >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dax at GuruLabs.com Wed Aug 27 19:26:01 2003 From: Dax at GuruLabs.com (Dax Kelson) Date: Wed, 27 Aug 2003 13:26:01 -0600 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4D023D.3060706@redhat.com> References: <20030827155502.24437.1756.Mailman@listman.back-rdu.redhat.com> <20030827171553.GA12436@sbonnevi.rdu.redhat.com> <3F4CFC47.7040606@redhat.com> <3F4D023D.3060706@redhat.com> Message-ID: <1062012360.2761.29.camel@mentor.gurulabs.com> On Wed, 2003-08-27 at 13:10, Daniel J Walsh wrote: > Nope it eventually worked. Not sure what the hang was. I am mounting > remote NFS machines > without portmap running. If you use the "nolock" option, then portmap need not be running and there will be no hangs. For example: mount -o nolock remotebox:/some/dir /local/mntpoint Note: I'm not saying that this is what you should normally do. I've done this within the %post section of Kickstart before or in the rescue environment. Dax Kelson Guru Labs -------------- 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 felipe_alfaro at linuxmail.org Wed Aug 27 19:54:46 2003 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 27 Aug 2003 21:54:46 +0200 Subject: RH Taroon Beta Open Ports In-Reply-To: <3F4D023D.3060706@redhat.com> References: <20030827155502.24437.1756.Mailman@listman.back-rdu.redhat.com> <20030827171553.GA12436@sbonnevi.rdu.redhat.com> <3F4CFC47.7040606@redhat.com> <3F4D023D.3060706@redhat.com> Message-ID: <1062014085.666.6.camel@teapot.felipe-alfaro.com> On Wed, 2003-08-27 at 21:10, Daniel J Walsh wrote: > Nope it eventually worked. Not sure what the hang was. I am mounting > remote NFS machines without portmap running. AFAIK, to mount a remote NFS share without relaying on a local portmap daemon, you must use static port assignment for the remote rpc.nfsd and rpc.mountd daemons. This can be achieved with: # mount remote_machine:/share /mount_point -o port=nfsd_port,mountport=mountd_port However, I haven't found a way to specify the port for the local nfs.lockd daemon. Thus, if I want to disable portmap locally, I must append the nolock option to the previous mount command. From m.a.young at durham.ac.uk Wed Aug 27 20:11:49 2003 From: m.a.young at durham.ac.uk (M A Young) Date: Wed, 27 Aug 2003 21:11:49 +0100 (BST) Subject: Question about installing Oracle 9i Rel2 on RH AS 3.0 In-Reply-To: References: Message-ID: On Wed, 27 Aug 2003, Andy Kar wrote: > > I got your name from the RHAT beta list. I saw that you've successfully > installed Ora 9i on RH 3.0. I've tried to install it but keep getting > errors. Do you have a procedure or doc about installing Orac9i on RH 3.0 ? Not quite, but I have installed the 9ias mid tier on RedHat 9, and have played with installing ocsv2 mid tier on severn, so some of the same tricks may work. I know about the following problems, 1. OUI2.3 worked on severn did with LD_ASSUME_KERNEL=2.4.19 set though it may complain at the os version, use the -ignoreSysPrereqs flag if it does. With other OUI versions you may need to replace the java software - copy oraparam.ini to a writable location and edit the JRE_LOCATION to point to a recent java version, eg. Sun's 1.4.2. Then run runInstaller --paramFile oraparam.ini.copy If you have this problem, you may also need to replace oracle installed 1.3.1 or 1.4 java (eg. at the end of disk 1) 2. Oracle links against various internal glibc and gcc symbols. You can build a ctype library at the first linking error in $ORACLE_HOME/lib by getting http://intel.forums.liveworld.com/servlet/JiveServlet/download/121-5821-19468-493/ctype.c and running gcc -c ctype.c ctype.o ar cr libctype.a ctype.o Then append to sysliblist (possibly with version corrections) -lctype -L/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/ -lgcc then run bin/genclntsh (with $ORACLE_HOME set) and press retry on the error. 3. Some parts use errno incorrectly, but you can use the same library trick by creating a file errno.c with the single line int errno=0; build a library as above and edit the appropriate makefile to use it. 4. forms, reports etc., expect version 2 the libXm library, but the version 3 one in /usr/X11R6/lib/ should work, create a symbolic link called libXm.so.2 to it in $ORACLE_HOME/lib , and edit the appropriate makefile to use it, then press retry on the error. I hope this is useful. Michael Young From m.a.young at durham.ac.uk Wed Aug 27 20:18:26 2003 From: m.a.young at durham.ac.uk (M A Young) Date: Wed, 27 Aug 2003 21:18:26 +0100 (BST) Subject: Question about installing Oracle 9i Rel2 on RH AS 3.0 In-Reply-To: References: Message-ID: On Wed, 27 Aug 2003, M A Young wrote: > Oracle hacking stuff. Sorry, wrong list. Michael Young From jrb at redhat.com Thu Aug 28 04:44:39 2003 From: jrb at redhat.com (Jonathan Blandford) Date: 28 Aug 2003 00:44:39 -0400 Subject: Text console port of GTK+ In-Reply-To: <1062003829.1004.32.camel@one.myworld> References: <1061967254.21665.4.camel@one.myworld> <20030827113329.A28947@devserv.devel.redhat.com> <1062003829.1004.32.camel@one.myworld> Message-ID: F?liciano Matias writes: > I would like to see rhgb in text mode. > Is there any plan ? :-) There have been a lot of feature requests to display the boot messages in a window in rhgb, but this is the first reverse of that to be requested. -Jonathan From hbo at egbok.com Thu Aug 28 06:39:33 2003 From: hbo at egbok.com (Howard Owen) Date: 27 Aug 2003 23:39:33 -0700 Subject: Text console port of GTK+ In-Reply-To: References: <1061967254.21665.4.camel@one.myworld> <20030827113329.A28947@devserv.devel.redhat.com> <1062003829.1004.32.camel@one.myworld> Message-ID: <1062052772.1328.68.camel@owen.egbok.com> That would then have to be "rhngb" them, wouldn't it? 8) Or just "rhb." Or LILO.8) On Wed, 2003-08-27 at 21:44, Jonathan Blandford wrote: > F?liciano Matias writes: > > > I would like to see rhgb in text mode. > > Is there any plan ? :-) > > There have been a lot of feature requests to display the boot messages > in a window in rhgb, but this is the first reverse of that to be > requested. > > -Jonathan > > > -- > Rhl-devel-list mailing list > Rhl-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/rhl-devel-list -- Howard Owen "Even if you are on the right EGBOK Consultants track, you'll get run over if you hbo at egbok.com +1-650-339-5733 just sit there." - Will Rogers From harald at redhat.com Thu Aug 28 12:48:33 2003 From: harald at redhat.com (Harald Hoyer) Date: Thu, 28 Aug 2003 14:48:33 +0200 Subject: /etc/sysconfig/network-scripts In-Reply-To: References: <1061999526.8078.6.camel@faro.stuttgart.redhat.com> Message-ID: <1062074912.12355.21.camel@faro.stuttgart.redhat.com> No, I won't in the near future, cause that's the way redhat-config-network manages its profiles currently and the easiest way for a vi user or shell script to change things.. Am Mi, 2003-08-27 um 17.56 schrieb Chris Ricker: > On Wed, 27 Aug 2003, Harald Hoyer wrote: > > > /etc/sysconfig/networking could go away, so it is not documented.. > > All scripts should stick with what is in /etc/sysconfig/network-scripts From enrico.scholz at informatik.tu-chemnitz.de Thu Aug 28 13:13:44 2003 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 28 Aug 2003 15:13:44 +0200 Subject: How to package execute-on-stack programs? Message-ID: <874r01j56f.fsf@kosh.ultra.csn.tu-chemnitz.de> Hello, what is the way to package programs which are containing code which will be executed on stack? Since this "feature" conflicts with exec-shield, the package-build may fail in the %check stage, or on the user-side. A program suffering from this is qemu[1]; I tried the chstk tool[2], but it fails with | ./qemu: Unknown file type which is probably caused by a "strange" (but required) linking. I read the RELEASE-NOTES also which state that | NOTE: Binary marking (the ability to identify those binaries that | should run with Exec-shield enabled/disabled) is not yet implemented. Does there exist a clean way to mark execute-on-stack programs in the meantime? Enrico Footnotes: [1] http://fabrice.bellard.free.fr/qemu/ https://bugzilla.fedora.us/show_bug.cgi?id=623 [2] http://people.redhat.com/mingo/exec-shield/chstk.c From ted at cypress.com Thu Aug 28 18:12:48 2003 From: ted at cypress.com (Thomas Dodd) Date: Thu, 28 Aug 2003 13:12:48 -0500 Subject: Text console port of GTK+ In-Reply-To: References: <1061967254.21665.4.camel@one.myworld> <20030827113329.A28947@devserv.devel.redhat.com> <1062003829.1004.32.camel@one.myworld> Message-ID: <3F4E4620.5060300@cypress.com> Jonathan Blandford wrote: > F?liciano Matias writes: >>I would like to see rhgb in text mode. >>Is there any plan ? :-) > > There have been a lot of feature requests to display the boot messages > in a window in rhgb, but this is the first reverse of that to be > requested. I've seen many request for quiet boot/init system. Something like rhgb does now, but without the delay/overhead of X. Speaking of which, any plans to improve the frambuffer console support for those of us that like it? How about a frambuffer version of rhgb :) Nice pretty penguins, and a simple status window instead of pages of text messages. -Thomas From jos at xos.nl Fri Aug 29 07:08:40 2003 From: jos at xos.nl (Jos Vos) Date: Fri, 29 Aug 2003 09:08:40 +0200 Subject: LVM + RAID not correct handled in rc.sysinit? Message-ID: <200308290708.h7T78es31986@xos037.xos.nl> Hi, I have a problem on RHL 9 (didn't check with Severn yet): In rc.sysinit LVM activation is done on 2 places with a comment for the second time "it could be on top of RAID". This is correct, but the RAID volumes are *only* started if they appear in /etc/fstab (without noauto), so RAID volumes used in LVM will never be started, and 2nd take of LVM initialization will never have any effect! I see at least that it is not working in a case I have here, and looking at the rc.sysinit script I think this will never work. Is this indeed the case? I'll look at Severn later today and bugzilla it. Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From lenz at mysql.com Fri Aug 29 10:05:12 2003 From: lenz at mysql.com (Lenz Grimmer) Date: Fri, 29 Aug 2003 12:05:12 +0200 (CEST) Subject: Text console port of GTK+ In-Reply-To: <3F4E4620.5060300@cypress.com> References: <1061967254.21665.4.camel@one.myworld> <20030827113329.A28947@devserv.devel.redhat.com> <1062003829.1004.32.camel@one.myworld> <3F4E4620.5060300@cypress.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Thu, 28 Aug 2003, Thomas Dodd wrote: > Jonathan Blandford wrote: > > > There have been a lot of feature requests to display the boot messages > > in a window in rhgb, but this is the first reverse of that to be > > requested. > > I've seen many request for quiet boot/init system. Something like rhgb > does now, but without the delay/overhead of X. > > Speaking of which, any plans to improve the frambuffer console support > for those of us that like it? How about a frambuffer version of rhgb :) > Nice pretty penguins, and a simple status window instead of pages of > text messages. http://www.bootsplash.org/ would be a good solution. It's being used by SuSE and Mandrake, too. Bye, LenZ - -- Lenz Grimmer Senior Production Engineer MySQL GmbH, http://www.mysql.de/ Hamburg, Germany For technical support contracts, visit https://order.mysql.com/?ref=mlgr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iD8DBQE/TyVaSVDhKrJykfIRAidDAJwIDZUqsBD79xtWVVj8QrLbzrPduQCfQa3P MaJJCIQUjPq3CrF5w2NAQZc= =PXJp -----END PGP SIGNATURE-----